Advocate not to use `:latest`

docs/user-guide/config-best-practices.md

@@ -100,6 +100,9 @@ This document is meant to highlight and consolidate in one place configuration b
   address this by ensuring that any updates to an image bump the image tag as well (e.g.
   `myimage:v2`), and ensuring that your configs point to the correct version.
 
+  **Note:** you should avoid using `:latest` tag when deploying containers in production, because this makes it hard
+  to track which version of the image is running and hard to roll back.
+
 ## Using kubectl
 
 - Use `kubectl create -f <directory>` where possible. This looks for config objects in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes them to `create`.

docs/user-guide/images.md

@@ -21,6 +21,8 @@ your image.
 If you did not specify tag of your image, it will be assumed as `:latest`, with
 pull image policy of `Always` correspondingly.
 
+Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/user-guide/config-best-practices/#container-images) for more information.
+
 ## Using a Private Registry
 
 Private registries may require keys to read images from them.

docs/user-guide/rolling-updates.md

@@ -73,6 +73,8 @@ The update will fail if `IMAGE:TAG` is identical to the
 current value. For this reason, we recommend the use of versioned tags as
 opposed to values such as `:latest`. Doing a rolling update from `image:latest`
 to a new `image:latest` will fail, even if the image at that tag has changed.
+Moreover, the use of `:latest` is not recommended, see 
+[Best Practices for Configuration](/docs/user-guide/config-best-practices/#container-images) for more information.
 
 ### Examples