Application Readiness Checklist

Application runs in a container

For the workload to run in a Kubernetes Pod, it must be packaged in a container.

Application / container is not dependent on host configuration

Pods are scheduled across multiple hosts and may be rescheduled based on the needs of the system. Relying on a static host to run your workloads may cause issues.

Logging occurs to stdout or stderr

In Kubernetes, it’s considered an anti-pattern to concern the workload with logging mechanisms beyond the formatting of the logs. Kubernetes-based platforms almost always feature log shipping mechanisms. This means, applications should log to stdout and/or stderr.

For more details, see the Logging Practices guide.

Does not run as root

Kubernetes is a multi-tenant environment where workloads may run side-by-side on the same host. To mitigate privilege escalation allowing one container to impact other on the host, applications should not run as a root user.

Does not require elevated privileges (added Linux capabilities).

Ideally your application does not require or add Linux capabilities to the deployment. This better ensures isolation of the workload in Kubernetes-based environments. For more detailed examples, see the Security Context documentation.

Handles the TERM Linux signal.

When a pod is being deleted, moved, or recreated each container’s PID 1 receives a SIG TERM. The process then has a grace-period to do what it needs and exit. The default grace-period is 30 seconds; check with your cluster administrator to understand what your cluster is set to. If the grace period expires, a SIG KILL is sent. For more details, see the Termination of Pods documentation.

If a process, script, or HTTP endpoints must be called to terminate gracefully, you can also add a preStop hook to your Kubernetes manifest.

Readiness is reported by application.

Readiness probes allow your application to report when it should start receiving traffic. This is always what marks a pod ‘Ready’ in the cluster. see the Probing Application State guide.

Configuration is externalized.

To support configuration of your application, it’s best to place it in the cluster using constructs like configmaps and secrets. This empowers you to make configuration changes to new and running applications using the Kubernetes API. For more details, see the Externalizing Configuration guide.

Able to run with multiple replicas.

In a Kubernetes environment, workloads are moved around based on needs of the platform. This means a workload could be deleted and recreated from time to time. With this and general HA practices in mind, your workload should be able to run with more than one replica.

Prevent replicas of your application from being co-located.

The Kubernetes scheduler does not guarantee application replicas run on different hosts, VMs, or hypervisors. Ensure you have appropriate anti-affinity setup based on the fault requirements of your application. For more details, see the Affinity and anti-affinity documentation.

Application resource requirements are known.

Applications should claim the CPU, memory, and other resources they require. This allows the scheduler to know the best place to run the application based on resources available. Once your resource requirements are known, visit Managing Compute Resources for Containers.

Important state does not persist in container filesystem.

Your application’s container filesystem is considered ephemeral. Meaning it will not move with the workload. This ephemeral storage is typically resource constrained and should not be used for anything more than small write needs, where loss of data is not a concern. If you need data persistence for your application, work with your platform team to understand how to request a persistent volume.

Session affinity is not required.

Requiring a request hits the same instance of an application each time is an anti-pattern in Kubernetes. While it is possible to solve for this use case, you should consider running or architecting your application in such a way that affinity of sessions is a non-requirement.

Metrics are exposed using an exporter.

Most Kubernetes clusters use a metrics collector such as Prometheus. Adding exporters to your application is trivial and support many different programming languages. For more details, see the observability documentation.