242 lines
14 KiB
Markdown
242 lines
14 KiB
Markdown
---
|
||
id: mat-06-kubernetes-intro
|
||
title: Kubernetes Intro
|
||
---
|
||
|
||
# Kubernetes Intro
|
||
|
||
|
||
## What Kubernetes is
|
||
|
||
Kubernetes is an orchestrator for containerized, cloud-native microservices applications. In practice, it deploys applications, scales them, helps them recover from failures, and manages updates.
|
||
|
||
## Orchestration
|
||
|
||
An orchestrator deploys applications and dynamically responds to changes. Kubernetes can deploy apps, scale up/down, self-heal, perform rollouts and rollbacks, and more.
|
||
|
||
## Containerization
|
||
|
||
Containerization packages applications and their dependencies as images, then runs them as containers. Containers are often compared to the next generation of virtual machines: smaller, faster, and more portable, while still commonly used alongside VMs.
|
||
|
||
## Cloud native
|
||
|
||
Cloud-native applications exhibit properties such as auto-scaling, self-healing, automated updates, and rollbacks. Simply running an application in a public cloud does not automatically make it cloud-native.
|
||
|
||
## Microservices
|
||
|
||
A microservices application is composed of multiple small, specialized services that work together (for example: web front-end, catalog, cart, authentication, logging, and store). A common pattern is to deploy each microservice as one or more containers so each feature can be scaled and updated independently.
|
||
|
||
## Where Kubernetes came from
|
||
|
||
Kubernetes was developed by Google engineers partly in response to the rise of modern cloud computing (popularized by AWS) and explosive container adoption (accelerated by Docker). It was open-sourced in 2014 and donated to the Cloud Native Computing Foundation (CNCF). At its core, Kubernetes abstracts infrastructure and simplifies application portability.
|
||
|
||
## Kubernetes and Docker
|
||
|
||
Early Kubernetes versions used Docker as the container runtime for low-level tasks such as creating, starting, and stopping containers. Over time, Docker became bloated and alternatives emerged. Kubernetes introduced the Container Runtime Interface (CRI) so the runtime layer could be swapped. Kubernetes 1.24 removed support for Docker as a runtime, and many new clusters use containerd as the default runtime. Docker, containerd, and Kubernetes work with OCI-standard images and containers.
|
||
|
||
## Container runtime interface and OCI
|
||
|
||
The CRI makes the container runtime pluggable so clusters can select runtimes for different needs (for example isolation or performance). OCI standards define common formats and behaviors for images and containers so tooling can interoperate.
|
||
|
||
## Kubernetes, Borg, and CNCF
|
||
|
||
Google historically orchestrated containers at scale with internal tools (Borg and Omega). Kubernetes is not an open-source version of them, but shares related ideas and lessons learned. Kubernetes is an open-source CNCF project under the Apache 2.0 license.
|
||
|
||
## Whats in the name and K8s
|
||
|
||
The word "Kubernetes" comes from the Greek word for "helmsman" (a ship’s steersman). The logo is a ship’s wheel. You will often see Kubernetes shortened to K8s (pronounced "kates"), where the 8 replaces the eight letters between K and s.
|
||
|
||
## Kubernetes as the operating system of the cloud
|
||
|
||
Kubernetes is sometimes called the operating system of the cloud because it abstracts differences between cloud platforms similarly to how operating systems abstract differences between servers:
|
||
- Operating systems schedule application processes onto server resources.
|
||
- Kubernetes schedules application microservices onto cloud and data center resources.
|
||
|
||
This abstraction enables hybrid cloud, multi-cloud, and cloud migration scenarios.
|
||
|
||
## Application scheduling analogy
|
||
|
||
Just as developers usually do not choose CPU cores or memory DIMMs directly (the OS schedules work), Kubernetes hides much of the complexity of selecting nodes, zones, and volumes. You describe what you want, and Kubernetes decides where and how to run it.
|
||
|
||
# Kubernetes principles of operation
|
||
|
||
## Kubernetes from 40K feet
|
||
|
||
Kubernetes is both a cluster and an orchestrator.
|
||
|
||
### Kubernetes as a cluster
|
||
|
||
A Kubernetes cluster is one or more nodes providing compute and other resources for applications.
|
||
|
||
### Control plane nodes and worker nodes
|
||
|
||
Clusters have control plane nodes and worker nodes. Control plane nodes implement the Kubernetes intelligence and must be Linux; worker nodes run your applications and can be Linux or Windows. Production clusters typically use three or five control plane nodes for high availability.
|
||
|
||
### Kubernetes as an orchestrator
|
||
|
||
Kubernetes deploys and manages applications across nodes and failure zones, handles failures, scales when demand changes, and manages rollouts and rollbacks.
|
||
|
||
## Control plane and worker nodes
|
||
|
||
The control plane is the collection of system services that provide the "brains" of Kubernetes: it exposes the API, schedules apps, implements self-healing, and manages scaling operations. Worker nodes run business applications.
|
||
|
||
## Control plane services
|
||
|
||
### The API server
|
||
|
||
The API server is the front end of Kubernetes. All commands and requests go through it, and internal control plane components also communicate through it. It exposes a RESTful API over HTTPS and enforces authentication and authorization. A typical deploy/update flow is: write a YAML manifest, post it to the API server, authenticate/authorize, persist it in the cluster store, and schedule the app to nodes.
|
||
|
||
### The cluster store etcd high availability and split brain
|
||
|
||
The cluster store holds the desired state of applications and cluster components and is the only stateful part of the control plane. It is based on etcd. Many clusters run an etcd replica on every control plane node for high availability, though some large clusters run etcd separately for performance. etcd prefers an odd number of replicas to reduce split brain risk during network partitions. If etcd experiences split brain, it enters read-only mode: applications continue running, but Kubernetes cannot scale or update them.
|
||
|
||
### RAFT consensus and write consistency
|
||
|
||
etcd uses the RAFT consensus algorithm to keep writes consistent and prevent corruption.
|
||
|
||
### Controllers and the controller manager
|
||
|
||
Controllers implement much of the cluster intelligence. They run as background watch loops that reconcile observed state with desired state. Kubernetes also runs a controller manager that spawns and manages controllers.
|
||
|
||
### The scheduler
|
||
|
||
The scheduler watches the API server for new work and assigns it to healthy worker nodes. It filters nodes that cannot run the task and ranks the remaining ones using factors such as available CPU/memory and whether required images are already present. If no suitable node exists, tasks can remain pending; with node autoscaling enabled, pending tasks can trigger adding nodes.
|
||
|
||
### The cloud controller manager
|
||
|
||
In public-cloud clusters, a cloud controller manager integrates with cloud services such as instances, load balancers, and storage (for example provisioning a load balancer when an app requests one).
|
||
|
||
## Worker node components
|
||
|
||
### Kubelet
|
||
|
||
The kubelet is the main Kubernetes agent on every worker node. It watches the API server for new tasks, instructs the runtime to execute tasks, and reports status back to the API server.
|
||
|
||
### Runtime
|
||
|
||
Each worker node has one or more runtimes that execute tasks such as pulling images and managing container lifecycle operations. Many newer clusters use containerd; some platforms use other CRI-compatible runtimes.
|
||
|
||
### Kube-proxy
|
||
|
||
kube-proxy implements cluster networking on the node and load balances traffic to tasks running on that node.
|
||
|
||
## Packaging apps for Kubernetes
|
||
|
||
Workloads such as containers (and other types) need to be wrapped in Pods to run on Kubernetes. Pods are then commonly wrapped in higher-level controllers (such as Deployments) to add features like scaling, self-healing, and rollouts.
|
||
|
||
### Object nesting containers pods deployments
|
||
|
||
A common nesting is: container (app + dependencies) inside a Pod (so it can run on Kubernetes) inside a Deployment (adds self-healing, scaling, and rollout/rollback behaviors). You post the Deployment YAML to the API server as the desired state.
|
||
|
||
## The declarative model and desired state
|
||
|
||
Kubernetes prefers the declarative model, centered on desired state, observed state, and reconciliation.
|
||
|
||
### Desired state observed state and reconciliation
|
||
|
||
Desired state is what you want; observed (actual/current) state is what you have; reconciliation is the process of keeping observed state aligned with desired state. You describe desired state in a YAML manifest, post it to the API server, Kubernetes persists it in the cluster store, and controllers reconcile the cluster until observed state matches the desired state and keep watching for drift.
|
||
|
||
### Declarative versus imperative
|
||
|
||
Imperative approaches rely on sequences of platform-specific commands and scripts. Declarative approaches describe the end state in a platform-agnostic way and fit well with version control. They also enable self-healing, autoscaling, and rolling updates.
|
||
|
||
### Self-healing and rolling updates example
|
||
|
||
If desired state requests 10 replicas and failures reduce the observed state, controllers create replacement Pods to return to 10. If a manifest changes to a newer image version, controllers replace old Pods with new Pods running the updated version.
|
||
|
||
## Pods
|
||
|
||
Pods are the unit of scheduling in Kubernetes.
|
||
|
||
### Pods and containers
|
||
|
||
Single-container Pods are common, which is why "Pod" and "container" are sometimes used interchangeably. Multi-container Pods are also used (for example with service meshes, initialization helpers, or tightly coupled helpers such as log scrapers).
|
||
|
||
### Multi-container pods and sidecars
|
||
|
||
A sidecar is a helper container that runs in the same Pod as the main container, providing additional services (for example encryption and telemetry in a service-mesh sidecar). Multi-container Pods can help keep each container focused on a single responsibility.
|
||
|
||
### Pod anatomy shared execution environment
|
||
|
||
A Pod is a shared execution environment for one or more containers. The environment includes a network stack, shared memory, volumes, and more. Containers in the same Pod share a Pod IP address and can communicate via localhost.
|
||
|
||
### Pod scheduling atomic readiness
|
||
|
||
Kubernetes schedules Pods (not individual containers). All containers in a Pod are scheduled to the same node. A Pod is marked ready only when all its containers are running.
|
||
|
||
### Pods as the unit of scaling
|
||
|
||
Scaling up adds Pods; scaling down deletes Pods. You do not scale by adding containers to an existing Pod.
|
||
|
||
### Pod lifecycle
|
||
|
||
Pods are created, live, and die. When a Pod dies, Kubernetes replaces it with a new Pod with a new ID and a new IP address. This encourages loose coupling so apps tolerate individual Pod failures.
|
||
|
||
### Pod immutability
|
||
|
||
Pods are immutable. To change a Pod, you replace it with a new one rather than modifying it in place.
|
||
|
||
## Deployments
|
||
|
||
Deployments are a common higher-level controller for stateless apps. They add self-healing, scaling, rolling updates, and versioned rollbacks for Pods.
|
||
|
||
## Services and stable networking
|
||
|
||
Pod IPs change due to failures, rollouts, and scaling. Services provide stable networking for groups of Pods by giving a stable front end (DNS name, IP, and port) and load balancing to a dynamic back end of healthy Pods (selected via labels).
|
||
|
||
# Getting Kubernetes
|
||
|
||
## Install everything with Docker Desktop
|
||
|
||
Docker Desktop can install Docker, provide a built-in multi-node Kubernetes cluster, and install and configure kubectl. Some examples that integrate with cloud load balancers or cloud storage require a cloud cluster instead of Docker Desktop.
|
||
|
||
### Create a Docker account
|
||
|
||
Create a free Personal Docker account.
|
||
|
||
### Install Docker Desktop and verify docker and kubectl
|
||
|
||
Install Docker Desktop (version 4.38 or newer) and verify:
|
||
- docker --version
|
||
- kubectl version --client=true -o yaml
|
||
|
||
### Deploy Docker Desktop built-in multi-node cluster
|
||
|
||
In Docker Desktop settings:
|
||
- Ensure "Use containerd for pulling and storing images" is enabled.
|
||
- Enable Kubernetes and choose the "kind (sign-in required)" option (the alternative creates a single-node cluster).
|
||
- Set Node(s) to 3 and enable showing system containers (advanced).
|
||
Apply and restart, then wait for the cluster to show as running.
|
||
|
||
### Verify cluster with kubectl get nodes
|
||
|
||
Use:
|
||
- kubectl get nodes
|
||
You should see three nodes: one control plane and two workers (in the Docker Desktop example). Docker Desktop runs the nodes as containers, but the kubectl experience is the same.
|
||
|
||
## Linode Kubernetes Engine LKE
|
||
|
||
LKE is a hosted Kubernetes service where the provider builds and manages the control plane and cluster operations. You configure kubectl to connect to the hosted cluster.
|
||
|
||
### Create an LKE cluster
|
||
|
||
From the Linode Cloud console: create a Kubernetes cluster with a label, region, Kubernetes version, and node pool.
|
||
|
||
### Configure kubectl and kubeconfig
|
||
|
||
kubectl uses a kubeconfig file called config in your home directory's hidden .kube folder. You may need to create ~/.kube and place the downloaded kubeconfig there (renamed to config), or merge it with an existing config.
|
||
|
||
### Switch contexts and test LKE cluster
|
||
|
||
Use kubectl config get-contexts and kubectl config use-context to select the context for the cluster you want to target, then test with kubectl get nodes.
|
||
|
||
## More about kubectl and kubeconfig
|
||
|
||
### What kubectl does per command
|
||
|
||
Each kubectl command is converted to an HTTP REST request, sent to the cluster defined by the current context in the kubeconfig, using the credentials in that context.
|
||
|
||
### Kubeconfig structure clusters users contexts current context
|
||
|
||
A kubeconfig defines clusters, users (credentials), contexts that map a user to a cluster, and a current-context that kubectl uses by default.
|