how to run patch commands on deployment?

[rubenrajkowski-nbcuni]

I've looked at the examples and can't find the kubectl equivalent to patch a deployment (restart all pods in a deployment):
kubectl patch deployment my-test-deployment -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"$(date +%s)\"}}}}}

and patch status which report which pods are terminated /rolled out

Waiting for deployment my-test-deployment rollout to finish: 1 out of 5 new replicas have been updated...
Waiting for deployment my-test-deployment rollout to finish: 1 old replicas are pending termination...
...
deployment my-test-deployment successfully rolled out

I've found these.. but doesn't seem to work with these params:

k8sApi.patchNamespace(targetDeploymentName, body, undefined, undefined, undefined, true, options)
k8sApi.patchNamespaceStatus(targetDeploymentName, body, undefined, undefined, undefined, true, options)

Any help would be appreciated.
Ruben

[brendandburns]

Please have a look at the example here:

#508

If you still need assistance please reply to this issue.

[rubenrajkowski-nbcuni]

Thanks for the quick reply and the example code @brendanburns
We are trying to patch the deployment (which has the pod manifest) to restart all the pods in the deployment.
Your example is for restarting individual pods.

I was hoping there was a Deployment level patch command in the API.

[rubenrajkowski-nbcuni]

I was also looking at @godaddy/kubernetes-client which has some similar apis for patching deployments. My colleague stumbled upon this post regarding merging with the official k8 JS library. Do you know the timetable of this merge? And will Godaddy's be deprecated or included in v9.0?
https://github.com/godaddy/kubernetes-client/blob/master/merging-with-kubernetes.md

[brendandburns]

There are equivalent patchNamespacedDeployment(...) calls that allow you to patch a deployment.

[brendandburns]

Also, there has been some discussion w/ the Godady folks, and one PR that got semi-abandoned.

We'd welcome more of a merger, but at the same time having multiple clients provides choice which is a good thing too, so if they'd prefer to stay separate that's great as well.

[brendandburns]

I'm going to close this issue since I think the question is answered, please use /reopen if you need further assitance.

[justinmchase]

What is the structure of the patch object? Are there docs on that? Is it kubernetes specific or part of this library?

EDIT:

It appears that is a Kubernetes construct independent of this library:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#use-a-strategic-merge-patch-to-update-a-deployment

And it wasn't clear to me but it appears that the code to automatically use one of the headers doesn't work by default but I managed to make it work like this:

const deployment: V1Deployment = ...;
const { metadata, spec } = deployment
const options = { "headers": { "Content-type": PatchUtils.PATCH_FORMAT_STRATEGIC_MERGE_PATCH } }
await this.apps.patchNamespacedDeployment(deploymentName, namespaceName, { metadata, spec }, undefined, undefined, undefined, undefined, options)

Using the strategic merge I was able to just pass in parts of the simple deployment object and it strategically merges the objects. The trick was just that the header is not set without manually specifying which type of merge I wanted.

[brendandburns]

There are three patch types supported:
Strategic merge patch - Kubernetes specific
JSON and JSON Merge Patch - RFCs non-kubernetes
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#use-a-json-merge-patch-to-update-a-deployment