Kubernetes能否自动检测镜像新版本并自动更新Pod？

Question #

I've created a basic application with the following configuration (myapp.yml):

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  type: LoadBalancer
  ports:
    - port: 5035
      targetPort: 5035
      protocol: TCP
      name: http
  selector:
    app: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: monapp
          image: xxxxxxx.container-registry.ovh.net/private/myimage
          ports:
            - containerPort: 5035
      imagePullSecrets:
        - name: regcred

Whenever I need to update the app, I push a new image to the registry and run kubectl rollout restart deployment/myapp-deployment to get Kubernetes to pull the new image and update the pods. Is there a way to make Kubernetes automatically detect new image versions in the registry and update the pods without manual intervention?

Answer #

Absolutely, there are several practical ways to automate this process so you don’t have to run that rollout command manually every time. Let’s break down the most reliable options for your setup:

1. GitOps Tools (Recommended Best Practice) #

Tools like Flux CD or Argo CD are built to solve exactly this problem—they keep your cluster’s state synced with your Git repository, and can actively monitor your container registry for new image versions. Here’s how to set this up with Flux:

• First, install Flux in your cluster and link it to the Git repo where your myapp.yml is stored.
• Create an ImageRepository resource that points to your OVH private registry; make sure to reference your regcred secret so Flux can authenticate and pull image metadata.
• Define an ImagePolicy to specify which image versions you want to track (e.g., semantic versions like v1.*, or the latest build from a specific branch).
• Finally, set up an ImageUpdateAutomation resource. This will automatically update the image tag in your myapp.yml file in Git, and Flux will apply the change to your cluster, triggering a rolling update of your deployment.

This approach is clean, audit-friendly, and aligns with modern Kubernetes best practices since all changes are tracked in Git.

2. CronJob for Periodic Image Checks (Quick, Lightweight Option) #

If you don’t want to set up a full GitOps pipeline, you can use a CronJob to periodically check for new image digests and restart the deployment if a new version is detected. Here’s a rough outline:

• Build a small custom container image that includes kubectl and a bash script to compare the current image digest in your deployment with the latest one in the registry.
• The script would use commands like:

  CURRENT_IMAGE=$(kubectl get deployment myapp-deployment -o jsonpath='{.spec.template.spec.containers[0].image}')
  

  to fetch the current image, then query your registry’s API (using credentials from regcred mounted into the CronJob pod) to get the latest image digest.
• If the digests don’t match, the script runs kubectl rollout restart deployment/myapp-deployment.
• Schedule the CronJob to run at your preferred interval (e.g., every hour).

Note: This is a simpler solution but less robust—you’ll need to maintain the script and handle edge cases like registry downtime or authentication issues.

3. Why latest Tags + imagePullPolicy: Always Isn’t Enough #

You might have considered using the latest tag with imagePullPolicy: Always, but this won’t automatically update your pods. Kubernetes only pulls the image when creating a new pod; existing pods won’t refresh even if latest points to a new image. You’d still need to manually restart the deployment, so this isn’t a reliable automation method.

内容的提问来源于stack exchange，提问作者Bob5421