Kubernetes is not known for being approachable. To master Kubernetes, you need to understand how the abstractions fit together. Kubernetes comes with dozens of resource types that you can use in your applications. Let’s take a look at the roles of the most commonly used sources.
If there is one Kubernetes term to learn, it is ̵
This similarity is not exact as a single Kubernetes pod can contain multiple containers. Pods are better thought of as a “group” of containers with a shared execution context. The Pod’s environment is isolated; the individual container environments inside are further subordinate.
Containers in a pod are always scheduled on the same Kubernetes node. They run on the same physical machine and can share storage and network resources.
apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: my-image:latest
The above manifest would manually create a single pod. The pod would run a container using the
Normally, you don’t manage Pods directly in Kubernetes. Pods are created as a result of adding other resources, such as an implementation (see below). You should treat your pods as ephemeral units. Kubernetes has control over the pod and can reschedule it to another node if cluster resources are limited.
Replica Sets (usually written as
ReplicaSets, without space) are another abstraction layer on top of pods. ReplicaSets guarantee that a specific number of identical pods are active at any time.
When using ReplicaSets, you may enforce a minimum number of pods for your application. You specify the number of pods to run simultaneously. Kubernetes then plans enough pods to meet the minimum availability you define. Keep in mind that each pod can consist of multiple active containers, depending on how your application is configured.
When a pod is created by a ReplicaSet, Kubernetes updates the pods
metadata.ownerReferences field to include the identity of the ReplicaSet. The ReplicaSet can then determine the pods it controls so that it knows if the minimum availability target has been reached.
ReplicaSets have a
replicas field defining the number of pods to run. Change this value and apply the updated ReplicaSet manifest to your cluster to have Kubernetes reschedule your pods to match the number of new replicas.
This detail highlights an important point about ReplicaSets: Kubernetes only guarantees the number of active pods in the end match the number of replicas you specified. If you change the number of replicas, there will be a period of time when more or less pods are running than your manifest specifies. The ReplicaSet will create or delete pods until the desired number is operational.
apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-replicaset labels: my-label: my-value spec: replicas: 3 selector: matchLabels: my-label: my-value template: metadata: labels: my-label: my-value spec: containers: - name: app-container image: my-image:latest
The above manifest would be three replicas of it
my-image:latest container image using a ReplicaSet. You can change the number of replicas by updating the value in the manifest and reapplying it (
kubectl apply -f my-manifest.yml
While ReplicaSets make it easier to work with pods, they are also rarely used directly. Implementations are an abstraction on top of ReplicaSets. Typically, you create a deployment when you add a new workload to a cluster.
Deployment sources enable declarative updates to Pods and ReplicaSets. It allows you to perform continuous updates of ReplicaSets, rescheduling pods without any interruption to the service. The Pods and ReplicaSets are replaced separately, so that old and new versions can coexist briefly.
The need for implementations grew out of Kubernetes’ historical approach to replicas. ReplicaSets evolved from Replication Controllers. Replication Controllers offered functionality similar to ReplicaSets, but with built-in scaling support.
However, Replication Controllers did not offer declarative scaling. You had to use it manually
kubectl rolling-update to scale the replicas without downtime. This was at odds with the declarative, manifest-based approach of other Kubernetes resources.
Compared to ReplicaSets, the main benefit of deployments is their support for rolling updates. Changing the number of replicas in a ReplicaSet does not guarantee that a number of pods will remain in a particular state during the rollout. With a deployment, you can be sure that your application will continue to process traffic even if the deployment is not yet complete.
Today, Kubernetes recommends using deployments to display your workloads. Your deployments will run and scale ReplicaSets automatically; ReplicaSets, in turn, manages your pods. You can perform a rolling update of a deployment by using the
replicas field in his manifesto. Kubernetes then ensures that your application remains available during the change, allowing new and old pods to coexist temporarily.
apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment labels: my-label: my-value spec: replicas: 3 selector: matchLabels: my-label: my-value template: metadata: labels: my-label: my-value spec: containers: - name: app-container image: my-image:latest
The above manifest would create an implementation consisting of three replicas, each of which contains the
my-image:latest container image. Changing it
replicas value would trigger a continuous update of the underlying ReplicaSets and Pods.
Other types of sources
The three types of resources we looked at are the most common objects you will encounter when working with Kubernetes. They are used to configure your application workloads and manage your containers.
You will need to use different resource types as you work more with Kubernetes. ConfigMaps and Secrets allow you to inject configuration into your pods, giving them access to external values. Volumes and persistent volumes provide pods with a shared writable file system that can be used to store data, rather than the standard temporary storage that is lost when the pod is shut down.
Another set of resources help you manage the network options of your workload. Services allow you to display a set of pods as a single network service with a single IP address. With Ingresses you can display services externally. They direct traffic to your cluster to a target service based on attributes such as host name, port, and URL path.
Finally, there are meta sources that describe your cluster. Namespaces are used to isolate individual workloads, preventing name conflicts. You usually need to create a new namespace for each of your independent workloads. Nodes are a kind of resource that represent the physical machines your pods run on. Typically, each node will host multiple pods. Kubernetes works out how to schedule workloads based on the availability of each node and the constraints you enforce.
You can view the full list of resources for your cluster by running
kubectl api-resourcesIn addition to the built-in resources, workloads can add their own Custom Resource Definitions (CRDs) that allow you to create new types of objects. Kubernetes automatically provides API endpoints for custom resource definitions.
Learning Kubernetes means becoming familiar with new abstractions and terminologies. While this provides a broad API surface, each Kubernetes object has a relatively narrow purpose.
You can often stick to high-level abstractions, such as implementations. You don’t need to micro-manage basic resource types, such as pods, unless you have complex requirements that can’t be solved with deployments and replica sets alone.