Update API Objects in Place Using kubectl patch [page]deterministic

This task shows how to use `kubectl patch` to update an API object in place. The exercises in this task demonstrate a strategic merge patch and a JSON merge patch.

##

## Use a strategic merge patch to update a Deployment

Here's the configuration file for a Deployment that has two replicas. Each replica is a Pod that has one container:

Create the Deployment:

```shell kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml ```

View the Pods associated with your Deployment:

```shell kubectl get pods ```

The output shows that the Deployment has two Pods. The `1/1` indicates that each Pod has one container:

``` NAME READY STATUS RESTARTS AGE patch-demo-28633765-670qr 1/1 Running 0 23s patch-demo-28633765-j5qs3 1/1 Running 0 23s ```

Make a note of the names of the running Pods. Later, you will see that these Pods get terminated and replaced by new ones.

At this point, each Pod has one Container that runs the nginx image. Now suppose you want each Pod to have two containers: one that runs nginx and one that runs redis.

Create a file named `patch-file.yaml` that has this content:

```yaml spec: template: spec: containers: - name: patch-demo-ctr-2 image: redis ```

Patch your Deployment:

```shell kubectl patch deployment patch-demo --patch-file patch-file.yaml ```

View the patched Deployment:

```shell kubectl get deployment patch-demo --output yaml ```

The output shows that the PodSpec in the Deployment has two Containers:

```yaml containers: - image: redis imagePullPolicy: Always name: patch-demo-ctr-2 ... - image: nginx imagePullPolicy: Always name: patch-demo-ctr ... ```

View the Pods associated with your patched Deployment:

```shell kubectl get pods ```

The output shows that the running Pods have different names from the Pods that were running previously. The Deployment terminated the old Pods and created two new Pods that comply with the updated Deployment spec. The `2/2` indicates that each Pod has two Containers:

``` NAME READY STATUS RESTARTS AGE patch-demo-1081991389-2wrn5 2/2 Running 0 1m patch-demo-1081991389-jmg7b 2/2 Running 0 1m ```

Take a closer look at one of the patch-demo Pods:

```shell kubectl get pod <your-pod-name> --output yaml ```

The output shows that the Pod has two Containers: one running nginx and one running redis:

``` containers: - image: redis ... - image: nginx ... ```

### Notes on the strategic merge patch

The patch you did in the preceding exercise is called a *strategic merge patch*. Notice that the patch did not replace the `containers` list. Instead it added a new Container to the list. In other words, the list in the patch was merged with the existing list. This is not always what happens when you use a strategic merge patch on a list. In some cases, the list is replaced, not merged.

With a strategic merge patch, a list is either replaced or merged depending on its patch strategy. The patch strategy is specified by the value of the `patchStrategy` key in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec` struct has a `patchStrategy` of `merge`:

```go type PodSpec struct { ... Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...` ... } ```

You can also see the patch strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):

```yaml "io.k8s.api.core.v1.PodSpec": { ..., "containers": { "description": "List of containers belonging to the pod. ...." }, "x-kubernetes-patch-merge-key": "name", "x-kubernetes-patch-strategy": "merge" } ```

And you can see the patch strategy in the [Kubernetes API documentation](/docs/reference/generated/kubernetes-api//#podspec-v1-core).

Create a fil …(trimmed)