kubernetes kubernetes/networking kubernetes/primer
Core Idea
Kubernetes sits between application and infrastructure like the OS of the cloud: you declare desired state, and the clusterâs control plane works to make it real.
- Cluster anatomy: control plane nodes and services, worker nodes (kubelet, runtime, kube-proxy), and hosted Kubernetes options.
- The declarative model and desired state, plus how you package apps for K8s.
- Core objects: pods, and service objects for stable networking.
K8s from 40K1 feet
K8s sits between application and infrastructure and acts like the OS of the cloud.
- A cluster
- An orchestrator
Cluster
A Kubernetes cluster is one or more nodes providing CPU, memory, and other resources for use by applications.
- Control plane nodes
- Worker nodes
Both types can be physical servers, virtual machines, or cloud instances, and both can run on ARM and AMD64/x86-64.
Control plane nodes must be Linux, but worker nodes can be Linux or Windows.
Control plane nodes implement the Kubernetes intelligence, and every cluster needs at least one. However, you should have three or five for high availability (HA).
Every control plane node runs every control plane service. These include the API server, the scheduler, and the controllers that implement cloud-native features such as self- healing, autoscaling, and rollouts.
Worker nodes are for running user applications.
Important
A Kubernetes node is a single machine inside a Kubernetes cluster and is responsible for running the containers that make up the applications deployed on the cluster. A K8s cluster contains one or more Kubernetes nodes.
Control Plane Nodes (Master Nodes)
- Run the internal k8s system services.
- Each control plane node runs every control plane service.
Good Practice
Itâs a good practice to have multiple control plane nodes for high availability (HA). This way, if one of them fails, the cluster keeps running. In the real world, itâs common for production clusters to have three or five control plane nodes and to spread them across failure domains. Do not put them all in the same rack under the same leaky aircon unit on the same glitchy power supply.
Control Plane Services
API Server (kube-apiserver)
The API Server is the only part of a Kubernetes cluster you interact directly with. its the frontend of k8s.
It exposes a RESTful API over HTTPS, and all requests are subject to authentication and authorization
Deploying or updating an app follows this process:
- Describe the requirements in a YAML configuration file
- Post the configuration file to the API server
- The request will be authenticated and authorized
- The updates will be persisted in the cluster store
- The updates will be scheduled to the cluster
Store (Etcd)
The cluster store holds the desired state of all applications and cluster components and is the **only stateful** part of the control plane.
Base on etcd distributed database.
most Kubernetes clusters run an etcd replica on every control plane node for HA.
Regarding availability, etcd prefers an odd number of replicas to help avoid split brain conditions. (HA & Split Brain Condition; The Kubernetes Book pg:14)
đ ETCD
đ Split Brain Condition
Controllers & Controller Manager (kube-controller-manager)
Kubernetes uses controllers to implement a lot of the cluster intelligence.
- The Deployment controller
- The StatefulSet controller
- The ReplicaSet controller
They all run as background watch loops, reconciling observed state with desired state.
Kubernetes also runs a controller manager that is responsible for spawning and managing the individual controllers.
Scheduler (kube-scheduler)
The scheduler watches the API server for new work tasks and assigns them to healthy worker nodes.
It implements the following process:
- Watch the API server for new tasks
- Identify capable nodes
- Assign tasks to nodes
The scheduler marks tasks as pending if it canât find a suitable node
Cloud Controller Manager
If your cluster is on a public cloud, such as AWS, Azure, GCP, or Civo Cloud, it will run a cloud controller manager that integrates the cluster with cloud services, such as instances, load balancers, and storage.
Worker Nodes
Kubelet
The kubelet is the main Kubernetes agent and handles all communication with the cluster.
It performs the following key tasks:
- Watches the API server for new tasks
- Instructs the appropriate runtime to execute tasks
- Reports the status of tasks to the API server
If a task wonât run, the kubelet reports the problem to the API server and lets the control plane decide what actions to take.
Runtime
Every worker node has one or more runtimes for executing tasks.
Most new Kubernetes clusters pre-install the containerd runtime and use it to execute tasks. These tasks include:
- Pulling container images
- Managing lifecycle operations such as starting and stopping containers
đ Most Popular Container Runtimes
đ Ctr, Crictl & Nerdctl
â Docker, containerd, CRI-O and runc
Kube Proxy
Every worker node runs a kube-proxy service that implements cluster networking and load balances traffic to tasks running on the node.
Hosted Kubernetes
Hosted Kubernetes is a consumption model where a cloud provider rents you a production-grade Kubernetes cluster.
- AWS: Elastic Kubernetes Service (EKS)
- Azure: Azure Kubernetes Service (AKS)
- Civo: Civo Cloud Kubernetes
- DO: Digital Ocean Kubernetes Service (DOKS)
- GCP: Google Kubernetes Engine (GKE)
- Linode: Linode Kubernetes Engine (LKE)
Packaging app for k8s
k8s runs containers, VMs, Wasm apps and more. however the all have to wrapped in pods.
- The container wraps the app and provides dependencies
- The Pod wraps the container so it can run on Kubernetes
- The Deployment wraps the Pod and adds self-healing, scaling, and more
Declarative model and desired state
Observed state is what you have, desired state is what you want, and reconciliation2 is the process of keeping observed state in sync with desired state.
actual state = current state = observed state
đ Replicaset > Reconciliation Loop
- We write manifest files in YAML that tell k8s ,what a desired state look like.
- We post it to the API server where itâs authenticated and authorized.
- After that configuration is persisted to the cluster store as a record of intent.
- Now, Desired state != Observed state
- A controller will notice this and begin the process of reconciliation
- This will involve making all the changes described in the YAML file and is likely to include scheduling new Pods, pulling images, starting containers, attaching them to networks, and starting application processes.
- After reconciliation, Desired state == Observed state
- The controllers keep running in the background, ready to reconcile any future differences.
Imperative and Declarative
- The imperative model requires complex scripts of platform-specific commands to achieve an end-state
- The declarative model is a simple platform-agnostic way of describing an end state
K8s Object
In Kubernetes, anything a user creates and retains is referred to as an âObject.â These can include various items such as namespaces, pods, deployments, DaemonSet, volumes, or sPodscts Vs Resources Vs Custom Resource]]
Pods
05004 [[Podsyments
Even though Kubernetes works with Pods, youâll almost always deploy them via higher- level controllers such as Deployments, StatefulSets, and DaemonSets.
Service objects and stable networking
Service provide reliable networking for group of pods.
