I have a cluster in gcp and a azure-pipeline.yml file for the pipeline config and a deplyoment.yaml file for the deployment in the cluster / pod.
So my problem: I specify the tag "latest" in my azure-pipelines.yml. So far so good, the image is pushed with the correct tag to the docker registry. But after triggering the deploy_dev stage, the pod in the cluster doesnt pull the new image again. I think thats bacause the image tag is already "latest". But i updated the docker image... xd
I also tried to add a "buildid" variable. But there the problem is, that i cant add an variable in the deplyoment.yaml after the image name...
Can someone help me pls, thanks.
i've tried it with the same variable (buildid) in the azure-pipelines.yml and deployment.yaml but that doesnt worked for me, because the deployment.yaml cant include the variable after the image name
i also tried the imagePullPolicy flag.
Kubernetes is smart. Or it tries to be! That being said, K8S is based on reconciliation loops: It tries to meet the cluster state equal to the provided YAML definition.
In your case, you provide a deployment, with a LATEST image tags. K8S will check its state and figure out the task to achieve to meet the new definition. In your case, the LATEST image is already pulled and present on the cluster, no need to pull it again.
It's a common issue that you can have with reconciliation loop product (like Terraform also). In fact, you do not use LATEST image, but a dedicated name: a tag, a commit SHA or whatever which change every time.
Then, you have to update your deployment file to add the correct image version to deploy. And finally apply your deployment. This time, your new image will be taken into account.
You have also a more "tank" version: because it's a state comparison, you can delete the LATEST image from the state and then deploy it again.
Following this idea, you need to delete your deployment from the cluster, and then deploy it again.
If it's a batch process, it's a suitable solution. If it's a webservice, it's a bad idea because you will create service unavailability.