2 Why the Pod?

In the previous chapter, we provided a high-level overview of Kubernetes and an introduction to its features, core components and architecture, showcased a business case and outlined container definitions. As we are in the age of the containers, and because of the container, Kubernetes and the Pod was born.

In this chapter we are going to cover what Pods are and layout why Kubernetes was built to support the Pod.

A Pod is an object that is defined within the Kubernetes API, as the majority of things are defined in Kubernetes. The Pod is the smallest atomic unit that can be deployed to a Kubernetes cluster, and Kubernetes is built around the Pod definition. The Pod allows us to define an Object that can include multiple containers, which allows us to have Kubernetes create one or more containers hosted on a Node.

Many other Kubernetes API objects either use Pods directly, such as Deployments, or are API objects that support Pods, such as the Node object. A Deployment represents the primary source of Pods, as well as StatefulSets and DaemonSets.

2.1 An example web application

2.1.1 Infrastructure for our web application

2.1.2 Operational requirements

2.2 What is a Pod?

2.2.1 A bunch of Linux namespaces

2.2.2 Kubernetes, infrastructure and the Pod

2.2.3 The Node API object

2.2.4 Our web application and the Control Plane

2.3 Create a web application with Kubectl

2.3.1 Kube-apiserver

2.3.2 Kubernetes scheduler

2.3.3 Infrastructure controllers

2.4 Scaling and HA and the Control Plane

2.4.1 Autoscaling

2.4.2 Cost management

2.5 Summary