utilization, on a nonproduction cluster, you may have mainly  Best-Effort  and  Bursta‐ ble  containers. In such a dynamic environment, many containers are starting up and shutting down at the same time, and even if a container gets killed by the platform during resource starvation, it is not fatal. On the production cluster where we want things to be more stable and predictable, the containers may be mainly of the Guar‐ anteed type and some  Burstable . If a container gets killed, that is most likely a sign that the capacity of the cluster should be increased. Table 2-2 presents a few services with CPU and memory demands. Of course, in a real-life scenario, the more likely reason you are using a platform such as Kubernetes would be because there are many more services to manage, some of which are about to retire, and some are still at the design and development phase. Even if it is a continually moving target, based on a similar approach as described previously, we can calculate the total amount of resources needed for all the services per environment. Keep in mind that in the different environments there are also a different number of containers, and you may even need to leave some room for autoscaling, build jobs, infrastructure containers, and more. Based on this information and the infrastructure provider, you can choose the most cost-effective compute instances that provide the required resources. Containers are useful not only for process isolation and as a packaging format. With identified resource profiles, they are also the building blocks for successful capacity planning. Perform some early tests to discover the resource needs for each container and use that information as a base for future capacity planning and prediction. However, more importantly, resource profiles are the way an application communi‐ cates with Kubernetes to assist in scheduling and managing decisions. If your applica‐ tion doesn’t provide any  requests  or  limits , all Kubernetes can do is treat your containers as opaque boxes that are dropped when the cluster gets full. So it is more Discussion  |  23 Discussion Table 2-2. Capacity planning example Pod CPU request CPU limit Memory request Memory limit Instances A 500m 500m 500Mi 500Mi 4 B 250m 500m 250Mi 1000Mi 2 C 500m 1000m 1000Mi 2000Mi 2 D 500m 500m 500Mi 500Mi 1 Total 4000m 5500m 5000Mi 8500Mi 9