kube play: support auto updates and rollbacks

Add auto-update support to `podman kube play`.  Auto-update policies can
be configured for:
 * the entire pod via the `io.containers.autoupdate` annotation
 * a specific container via the `io.containers.autoupdate/$name` annotation

To make use of rollbacks, the `io.containers.sdnotify` policy should be
set to `container` such that the workload running _inside_ the container
can send the READY message via the NOTIFY_SOCKET once ready.  For
further details on auto updates and rollbacks, please refer to the
specific article [1].

Since auto updates and rollbacks bases on Podman's systemd integration,
the k8s YAML must be executed in the `podman-kube@` systemd template.
For further details on how to run k8s YAML in systemd via Podman, please
refer to the specific article [2].

An examplary k8s YAML may look as follows:
```YAML
apiVersion: v1
kind: Pod
metadata:
  annotations:
      io.containers.autoupdate: "local"
      io.containers.autoupdate/b: "registry"
  labels:
    app: test
  name: test_pod
spec:
  containers:
  - command:
    - top
    image: alpine
    name: a
  - command:
    - top
    image: alpine
    name: b
```

[1] https://www.redhat.com/sysadmin/podman-auto-updates-rollbacks
[2] https://www.redhat.com/sysadmin/kubernetes-workloads-podman-systemd

Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>

1 files changed, 12 insertions, 0 deletions

diff --git a/docs/source/markdown/podman-auto-update.1.md.in b/docs/source/markdown/podman-auto-update.1.md.in
index bc92d6165..b724f1157 100644
--- a/docs/source/markdown/podman-auto-update.1.md.in
+++ b/docs/source/markdown/podman-auto-update.1.md.in
@@ -29,6 +29,18 @@ This data is then being used in the auto-update sequence to instruct systemd (vi
 Note that **podman auto-update** relies on systemd. The systemd units are expected to be generated with **[podman-generate-systemd --new](podman-generate-systemd.1.md#--new)**, or similar units that create new containers in order to run the updated images.
 Systemd units that start and stop a container cannot run a new image.
 
+### Auto Updates and Kubernetes YAML
+
+Podman supports auto updates for Kubernetes workloads.  As mentioned above, `podman auto-update` requires the containers to be running systemd.  Podman ships with a systemd template that can be instantiated with a Kubernetes YAML file, see podman-generate-systemd(1).
+
+To enable auto updates for containers running in a Kubernetes workload, set the following Podman-specific annotations in the YAML:
+ * `io.containers.autoupdate: "registry|local"` to apply the auto-update policy to all containers
+ * `io.containers.autoupdate/$container: "registry|local"` to apply the auto-update policy to `$container` only
+ * `io.containers.sdnotify: "conmon|container"` to apply the sdnotify policy to all containers
+ * `io.containers.sdnotify/$container: "conmon|container"` to apply the sdnotify policy to `$container` only
+
+By default, the autoupdate policy is set to "disabled", the sdnotify policy is set to "conmon".
+
 ### Systemd Unit and Timer
 
 Podman ships with a `podman-auto-update.service` systemd unit. This unit is triggered daily at midnight by the `podman-auto-update.timer` systemd timer.  The timer can be altered for custom time-based updates if desired.  The unit can further be invoked by other systemd units (e.g., via the dependency tree) or manually via **systemctl start podman-auto-update.service**.