Learn Kubernetes

What Will You Learn?

What are the basics of Kubernetes?
What are the use cases for Kubernetes?
What are the less suitable use cases for Kubernetes?
What are the core objects and components of Kubernetes?
What are the core networking concepts in Kubernetes?
What are the core storage concepts in Kubernetes?
Where can I learn more about Kubernetes?

The Basics

Google software engineers Craig McLuckie, Joe Beda, and Brendan Burns created Kubernetes (K8S) and shipped it in September 2014. Google’s Borg cluster manager, which deploys several billion containers per week and Omega influence its development.

Kubernetes is a greek word meaning captain. It’s an open-source container orchestration system for managing containerized applications.

It has a healthy community of 35K+ contributors. Joe Beda credits RedHat as a core contributor to the project, with RedHat OpenShift leading to simplified deployment options and Quarkus for efficient Java workloads.

Primary Use Cases

Consistent deployment of applications anywhere
Efficient resource utilization
Increased developer velocity
Consistent local and production deployments
A GitOps infrastructure

Less Suitable Use Cases

A simple solution for a simple problem
You’re a team of one with no Kubernetes experience
A low-cost application deployment solution

Objects and Components

Kubernetes is a vastly complex system. Let’s start with the core objects and components you’ll encounter immediately.

Nodes

Nodes are the machines that run your applications and cloud workflows. The Kubernetes master controls each node.

graph LR A[User Interface] --> B[API Server] B --> C[Master Node] C --> D[Worker Node 1] C --> E[Worker Node 2] classDef def stroke:blue,stroke-width:2px class C,D,E def

Master Node

The master node is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the kubectl command-line interface, you communicate with your cluster’s Kubernetes master node.

Worker Node

A worker node runs your application and cloud workflows and serves your requests. Kubernetes automatically handles scheduling workloads onto available nodes in a cluster.

Contexts

graph LR A[Context] --> B[Cluster] B --> C[Worker Node 1] B --> D[Worker Node 2] classDef def stroke:blue,stroke-width:2px class C,D def

A context is a cluster, namespace, and user. Contexts are used to determine which cluster and namespace commands operate. The name of the context is used to identify it from all other contexts you might have uniquely.

Pods

graph LR A[Pod] --> B[Container 1] A --> C[Container 2] classDef def stroke:blue,stroke-width:2px class A def

A pod is a group of one or more containers. It shares network, storage, and container specification. A pod’s contents are always co-located, co-scheduled, and run in a shared context.

A pod models an application-specific “logical host” containing one or more application containers that are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications run on the same logical host.

Labels

graph LR A[Label] --> B[Pod] B --> C[Container 1] B --> D[Container 2] classDef def stroke:blue,stroke-width:2px class A def

A label is a key/value pair attached to objects like pods. Labels are intended to specify identifying attributes of objects that are meaningful and relevant to users but do not directly imply semantics to the core system. Labels can be used to organize and select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time.

Label Selectors

graph LR A[Label Selector] --> B[Pod] B --> C[Container] B --> D[Container] classDef def stroke:blue,stroke-width:2px class A def

A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all objects. A null label selector matches no objects.

Services

graph LR A[Service] --> B[Pod] B --> C[Container 1] B --> D[Container 2] classDef def stroke:blue,stroke-width:2px class A def

A Kubernetes Service that identifies a set of pods using label selectors. ServiceTypes allow you to specify what kind of Service you want. The default is ClusterIP.

Namespaces

graph LR A[Namespace] --> B[Pod] B --> C[Container 1] B --> D[Container 2] classDef def stroke:blue,stroke-width:2px class A def

A Kubernetes Namespace provides scope for names. Names of resources need to be unique within a namespace but not across namespaces. Namespaces are intended for use in environments with many users across multiple teams or projects. Namespaces are a way to divide cluster resources between multiple users.

Replication Controllers

graph LR A[Replication Controller] --> B[Pod] B --> C[Container 1] B --> D[Container 2] classDef def stroke:blue,stroke-width:2px class A def

A replication controller’s purpose is to maintain a stable set of replica pods running at any given time. In other words, a replication controller ensures that a pod or homogeneous set of pods is always up and available. If there are too many pods, it will kill some. If there are too few, the replication controller will start more.

Deployments

graph LR A[Deployment] --> B[Pod] B --> C[Container 1] B --> D[Container 2] classDef def stroke:blue,stroke-width:2px class A def

A deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

ConfigMaps and Secrets

graph LR A[ConfigMap] --> B[Pod] B --> C[Container] B --> D[Container] classDef def stroke:blue,stroke-width:2px class A def

A ConfigMap is an API object that stores non-confidential data in key-value pairs. It can store container command-line arguments, configuration settings, and other data to configure applications. ConfigMaps are similar to Secrets but designed to more conveniently support working with strings that do not contain sensitive information.

Storage in Kubernetes

Kubernetes has a rich storage ecosystem. Let’s take a look at the core concepts.

graph LR A[Node] --> B[Pod] B --> C[Container 1] B --> D[Container 2] B --> F[Volume] classDef def stroke:blue,stroke-width:2px class F def

Persistent Volumes and Persistent Volume Claims

graph LR A[Node] --> B[Pod] B --> C[Container 1] B --> D[Container 2] B --> F[Volume] F --> G[Persistent Volume Claim] G --> H[Persistent Volume] classDef def stroke:blue,stroke-width:2px class G,H def

A PersistentVolume (PV) is a storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage.

Storage Classes

graph LR A[Node] --> B[Pod] B --> C[Container 1] B --> D[Container 2] B --> F[Volume] F --> G[Persistent Volume Claim] G --> H[Persistent Volume] H --> I[Storage Class] classDef def stroke:blue,stroke-width:2px class I def

A StorageClass provides a way for administrators to describe the “classes” of storage they offer. Kubernetes itself defines what classes represent. This concept is sometimes called “profiles” in other storage systems.

StatefulSets

graph LR A[Node] --> B[Pod] B --> C[Container 1] B --> D[Container 2] B --> F[Volume] F --> G[Persistent Volume Claim] G --> H[Persistent Volume] H --> I[Storage Class] B --> J[StatefulSet] classDef def stroke:blue,stroke-width:2px class J def

A StatefulSet is a workload API object used to manage stateful applications. StatefulSets are valuable for applications that require one or more of the following.

Networking in Kubernetes

Kubernetes has a rich networking ecosystem. Let’s take a look at the core concepts.

Ingress

graph LR A[Ingress] --> B[Service] B --> C[Pod] C --> D[Container 1] C --> E[Container 2] classDef def stroke:blue,stroke-width:2px class A def

An Ingress is a collection of rules that allow inbound connections to reach the cluster services. An Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, offer name-based virtual hosting, and more. Users request ingress by POSTing the Ingress resource to the API server.

Ingress Controllers

graph LR A[Ingress] --> B[Service] B --> C[Pod] C --> D[Container] C --> E[Container] A --> F[Ingress Controller] classDef def stroke:blue,stroke-width:2px class F def

An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic. The controller fulfills the Ingress by reading the rules specified in the Ingress resource.

Cluster Network Model

The Cluster Network Model describes how Kubernetes networking is implemented. It is a set of rules that define how pods can communicate with each other and other network endpoints. The model describes the behavior of pods, namespaces, and network interfaces.

A network cluster is contained within a node.

graph LR CNM["Cluster Network Model"] CNM --> P["Pods"] CNM --> N["Namespaces"] CNM --> NI["Network Interfaces"] P -- "Communicate with" --> P2["Other Pods"] P -- "Communicate with" --> NE["Network Endpoints"] N -- "Define scope for" --> P NI -- "Enable connectivity for" --> P classDef def stroke:blue,stroke-width:2px class CNM def

Conclusion

Kubernetes is a powerful tool for managing containerized applications. It is a complex system, but it may be worth learning depending on your use cases. We’ve only seen the tip of the Kubernetes iceberg.