2

At the moment I'm performing Kubernetes deployments by applying deployment.yaml then updating the container/pod image versions with kubectl set-image as outlined in the docs. I'm doing this using Jenkins.

If I understand correctly, each time I apply kubectl set-image it updates the deployment in situ creating a new ReplicaSet meaning that I don't need to create a new deployment.yaml for each version bump.

Is this best practice or should I be creating a new deployment.yaml every time we bump version?

My next question concerns rollbacks, if I run kubectl rollout history deployment/name, I see three revisions but no 'cause'. I think this is because I've not specified --record on the initial deployment, and does that record each time we do a set-version too?

Improve this question

2 Answers 2

Reset to default
2

I think it might be a good idea to update deployment.yaml for each version/release and commit to git so that later, any other person may follow through and even revert back to an earlier release/version.

Improve this answer
1
  • You can also use helm or terraform so that you update image names/tags using environment variables.
    – SamwelOpiyo
    Jun 4, 2019 at 10:30
0

When we started to use Kubernetes at my current job we just re-applied the deployment manifest, updating the DATE on a annotation, this worked fine for some time, then we switched to use HELM https://helm.sh/

My recommendation is to switch to Helm since it manages deployments in a better way, even config maps are versioned between releases and also you can roll-back as you want.

Makes life easier when integration with CI/CD pipeline cause everything is parameterized/configurable.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.