Kubernetes: Initial Configuration Explanation

With a Kubernetes cluster set up and an introductory deployment, what is the configuration actually defining? What are the components in the YAML file? This article will summarize the components within the introductory YAML file and explain their relationships. For more detailed explanations of the components, see the links below in the official Kubernetes documentation:

Kubernetes Components

There are 3 components within in our test deployment. Actually, there were only 2 defined, because we used a shortcut. This article lays out the expanded and more detailed definition of all 3. (It’s still just a summary, so refer to the official documentation links above for more detail.)

Common YAML Keys

Each section of a Kubernetes component contains 4 top level keys:

apiVersion - This is what it says, but the value of the version depends on the kind. The official Kubernetes documentation has lists of proper values based on the kind.

kind - the type of resource described, such as Deployment or Service used in the previous article.

metadata - provides the name of the component and labels used for matching components to group together.

spec - the details of the resource to use in the cluster. Highly specific to the kind.

Pod

A Pod is the smallest unit of work in a cluster. It consists of one or more containers. The control plane can schedule pods on any node in the cluster. Each pod receives a unique IP address.

A sample Pod YAML file might look like, a single container running the whoami app on port 80:


apiVersion: v1
kind: Pod
metadata:
  name: whoami
	labels:
		app: whoami
spec:
  containers:
  - name: whoami
    image: traefik/whoami
    ports:
    - containerPort: 80

This should look a lot like the bottom section of the Deployment in the previous article. And it is.

The spec for this pod shows the container image to use and the ports it exposes, similar to what a Dockerfile might do with the EXPOSE statement. It also provides a label, which is a key/value pair that is used to associate this pod with higher level components. (Names must be unique, so labels are used to group like components together.)

Finally, pods are rarely defined by themselves, but as a subset of a higher level component, as with a Deployment.

Service

The pod and its IP address are not constant. The control plane deploys them at its discretion throughout the cluster. Any pod can appear on any node and be assigned any IP address (within the cluster’s range).

But an app must have a way to consistently communicate with its components; enter Services. A Service is a consistent endpoint which Kubernetes maps to the pod(s) that match the label of the the selector attribute in the Service spec.

Below is the Service defined in the test deployment. The selector in the spec is app: whoami, which matches the metadata label in the pod above and in the Deployment from the previous article.


apiVersion: v1
kind: Service
metadata:
  name: whoami
spec:
  type: NodePort
  ports:
    - port: 80
      nodePort: 31000
  selector:
    app: whoami

The spec for the Service also defines the ports.

Normally these IP are internal to the cluster, but using NodePort exposes the port to outside the cluster.

(How do apps in the cluster find the IP address of the service? In-cluster DNS, to be discussed later.)

Deployment

A Deployment is a high level component that ties together several components.

As mentioned above, a Deployment can create pods rather than rely on on the Pod kind to actually create them.

It does this via a lower level component called a ReplicaSet.

ReplicaSet

The ReplicaSet is responsible for maintaining a, wait for it… a set of replicas of pods as described in the Deployment spec.


spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami
          ports:
            - name: web
              containerPort: 80

The Deployment creates the ReplicaSet automatically. It’s possible to create a ReplicaSet by itself, but it’s easier to let the higher level Deployment manage it.

The above Deployment spec contains a template which is used to create the pods. To create more than a single pod, simply change the replicas value to the desired value. The Service will match find all the pods that match the service:spec:selector and call each pod round-robin. (A ReplicaSet backed by a Service can function as a simple load balancer.)

A Deployment and a ReplicaSet are known as Controllers. A controller in Kubernetes is resource that manages other resources. A Deployment is a controller that manages pods (with a ReplicaSet). There are several types of controllers to be covered in future articles.

Next Time

The pattern of one implementation and one explanation seems to work well.

Next article will begin the custom app implementation.