Kubernetes Quick Review

• Introduction
  • Kubernetes
  • Container orchestration

Introduction

Kubernetes

Followed by trendy technology, modern application are developed into multiple microservices. This very architecture encourages everyone to containerize everything. That’s why Kubernetes comes to life.

Kubernetes are born to solve multiple problems from networking, storage, … in an automatic way in a large-scale infrastructure. Every component of any application are seen as “microservices” for efficient management. Also, thanks to Kubernetes, researchers or learner like me can make my living and pay my own bill :-)

Cluster

A Kubernetes system has various units. Each unit play a independent role with specific features. A common Kubernetes cluster looks like below:

In summary:

• Master Node is the headquarter which is responsible for management tasks like monitor Worker nodes’s health, decide and control rule for workloads to be placed on which Worker, store important data for cluster (etcd), … They also expose API on port 6443 for developers like us to interactive with cluster
• Worker Node - simple, receive commands from Master nodes to run workload like web, app, … Like me working for my boss -_-

Note: Worker’s resources are scaled to the demand of how heavy the application will run. While Master’s resources are scaled by number of Worker and depend on specific orchestration.

Component

Every kubernetes system has following main components. Have a look!

Quote from official Kubernetes document. Let’s review all!

Control plane components

kube-apiserver

• Exposes the Kubernetes API.

etcd

• Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.
• Make sure you have a back up plan for the data.

kube-scheduler

• Watches for newly created Pods with no assigned node, and selects a node for them to run on.
• Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.

kube-controller-manager

• Runs controller processes. Logically, each controller is a separate process.
• There are many different types of controllers. Some examples of them are:
  • Node controller: Responsible for noticing and responding when nodes go down.
  • Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion.
  • EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods).
  • ServiceAccount controller: Create default ServiceAccounts for new namespaces.
  • …

cloud-controller-manager

• Lets you link your cluster into your cloud provider’s API
• Only runs controllers that are specific to your cloud provider. If running Kubernetes on your own premises, the cluster does not have a cloud controller manager.

kubelet

• An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod.
• The kubelet doesn’t manage containers which were not created by Kubernetes.

kube-proxy (optional)

• A network proxy that runs on each node in your cluster, implementing part of the Kubernetes “Service” concept.
• Maintains network rules on nodes.
• Uses the operating system packet filtering layer (iptables) if there is one and it’s available. Otherwise, kube-proxy forwards the traffic itself.

Note: If you use a network plugin that implements packet forwarding for Services by itself, and providing equivalent behavior to kube-proxy, then you do not need to run kube-proxy on the nodes in your cluster.

Container runtime

• A fundamental component that empowers Kubernetes to run containers effectively.
• It is responsible for managing the execution and lifecycle of containers within the Kubernetes environment. For example: containerd, CRI-O, and any other implementation of the Kubernetes CRI (Container Runtime Interface).

There are Addons(DNS, Network plugins, Dashboard UI, …). We would dissect these in the incoming topics.

Container orchestration

A Kubernetes cluster are very complicated in general. Once upon a time, there is no definition about “orchestration”. All components are manually created, all keys or token are manually generated, … Joining nodes to cluster? - Manual too!

Refer to Kubernetes The Hard Way if you want to torture yourself. That’s why orchestration are introduced to automate these process. Each orchestration will have its advantages, upgrade components for more advanced features or change underlying technology to gain lightweight, … The table below lists some common orchestration and its prominent features:

Name	Features	Use cases	Lab/Production?
Minikube	All-in-one cluster in a single node Core components are installed	Ready for building containered applications Testing K8s ecosystem services	Lab Only
K3S	All-in-one cluster in a single node Light-weight components, less-consumed resources	Run non-critical applications that does not use much features of K8s (Storage, Networking, ...) i.e AWX, central dashboard, github, ... depend on contexts of "critical"	Both
Kubeadm	Manually install CRI Manually install CNI Partially self-managed Kubernetes cluster, require administrator skills	Researching the K8s architecture Free to install any kind of services, choose any CNI, CRI Running DEV/UAT/PROD applications	Both (Mainly for lab)
RKE2	Less self-managed K8s cluster Boot up cluster or join nodes via YAML config Easy set up	General purpose, all kind of domains Be able to run production applications Less taken actions when incidents happen	Production
Openshift	Less self-managed K8s cluster Focus on security Require Redhat licenses Not much easy to set up Benefits with features offered by Redhat	Mostly Banking and Finance applications	Production

Next: [Set up] Install New Cluster with HA Master