As your team updates an app with new features or solves for bugs, you’ll be pushing the latest image to your Docker registry. In Kubernetes, Docker's latest tag is applied by default to images where a tag hasn't been specified. However, not specifying a specific version of an image can lead to a wide variety of problems:
The underlying image could include unexpected changes that break your application whenever the latest image is pulled.
Reusing the same tag for multiple versions of an image can lead to different nodes in the same cluster having different versions of an image, even if the tag is identical.
The latest tag can get accidentally overwritten really easily, and can lead to you pulling e.g. a development branch into production.
Kubernetes documentation advises: “Note: You should avoid using the :latest tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.”
Identify Docker :latest Tag in Kubernetes Clusters
Identifying what clusters are using Docker latest tag should be done regularly to avoid issues. Using a Kubernetes configuration validation platform, you’ll be alerted whenever the latest tag is identified. Your team can then easily fix the manifest helping to avoid problems with your application (downtime, bugs, etc).
Fairwinds Insights community edition is free to use forever. Try the full edition for 30 days by signing up here. Test in GKE, AKS or EKS or run on a test cluster.
Fairwinds Insights is able to enforce Kubernetes policies throughout your entire deployment process so that from CI/CD through production, there are no default latest tags. And while this blog post discusses how to identify offending workloads, Fairwinds Insights also helps to prevent those workloads from getting into your cluster in the first place by scanning Infrastructure-as-Code in CI, and running as an Admission Controller in front of the Kubernetes API.