Kubernetes.

Kubernetes is an open-source container orchestration platform that automates deploying, scaling and managing containerized applications. A cluster has a control plane and worker nodes that run the containers.

Control plane components:

• kube-apiserver exposes the API, validates requests, and is the hub every component talks to.
• etcd is a distributed key-value store for cluster state and configuration.
• kube-scheduler assigns Pods to nodes by resource needs and constraints.
• kube-controller-manager runs controllers that drive actual state toward desired state.

Worker node components:

• kubelet runs the Pods scheduled to its node.
• kube-proxy maintains the network rules that load-balance Service traffic.
• The container runtime, such as containerd or CRI-O, runs the containers. Built-in Docker Engine support ended in v1.24.

A Pod runs your containers, a Deployment keeps the right number of Pods running, and a Service gives those Pods one stable address.

• A Pod is the smallest deployable unit. It holds one or more containers that share storage and network. Pods are ephemeral, so you rarely create them directly.
• A Deployment is a higher-level object that manages ReplicaSets and rolls out changes to Pods declaratively. It keeps the desired number of replicas running.
• A Service selects a set of Pods by label and gives them stable networking, one IP and DNS name that outlives any Pod. Other parts of the application call the Service, not Pod IPs.

The Deployment below keeps three nginx Pods running, and a Service with the selector app: nginx would send traffic to them.

# Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.20

Namespaces partition one cluster into virtual clusters, so several teams or environments can share it. Each namespace gives its group:

• Name scoping. Names must be unique only within a namespace, so dev and prod can each have a Service called api.
• Environment separation. Dev, staging and prod objects are listed and deleted per namespace.
• Access control. A RoleBinding grants a team permissions in one namespace only.
• Resource quotas. A ResourceQuota caps the CPU, memory and object count a namespace can use.

Pods in different namespaces can still reach each other unless a NetworkPolicy blocks them. Node and PersistentVolume objects belong to no namespace.

kubectl create namespace development
kubectl get pods --namespace=development

Kubernetes has four Service types, and they differ in how clients reach the Service:

1. ClusterIP, the default, gives the Service an internal IP that works only inside the cluster.
2. NodePort also opens a static port on every node's IP, from 30000-32767 by default, for clients outside the cluster.
3. LoadBalancer also provisions the cloud provider's load balancer in front of the Service.
4. ExternalName makes cluster DNS return a CNAME for an external hostname, with no proxying.

Setting clusterIP: None makes a headless Service. DNS then returns the Pod IPs instead of one virtual IP, and StatefulSets use it to give each Pod its own DNS name.

# NodePort Service
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30007

Run kubectl describe pod first, because its events usually name the cause, and then read the container logs. What you find points to one of four common problems:

• Resource constraints. A Pod stuck in Pending cannot be scheduled, most often because no node has enough free CPU or memory. The events show the reason, and kubectl describe node shows each node's capacity.
• Image pull errors. ImagePullBackOff means Kubernetes cannot pull the image. Check the image name and tag, registry access and the pull secret.
• Configuration errors. A missing Secret or ConfigMap keeps the container from starting, and the events name it. Bad settings, such as an invalid environment variable, usually crash the app, so check kubectl logs --previous.
• Network issues. If the app starts but cannot reach its dependencies, test DNS resolution and whether those Services have endpoints.

# Check pod status
kubectl get pods -o wide
# Describe pod for events
kubectl describe pod <pod-name>
# Check logs
kubectl logs <pod-name>
# Check previous container logs if restarting
kubectl logs <pod-name> --previous
# Check node resources
kubectl top nodes
kubectl describe node <node-name>

Kubernetes is an open-source container orchestration platform that automates deploying, scaling and managing containerized applications. Google originally developed it, and the Cloud Native Computing Foundation (CNCF) now maintains it.

It is needed because managing hundreds or thousands of containers by hand is impractical. Kubernetes does that work for you:

• It restarts failed containers and replaces unhealthy instances, which keeps applications highly available.
• It scales applications with demand and spreads traffic across the instances.
• It packs containers onto nodes by their resource requests, which leaves less capacity sitting idle.
• Its rolling updates let a new version go out with zero downtime.

A Pod is the smallest and simplest Kubernetes unit: one or more containers that share a network namespace and storage. It is the smallest deployable unit because the scheduler places Pods, not containers, and the IP address belongs to the Pod.

Its containers:

• share one IP address and port space, and reach each other on localhost
• can mount the same volumes
• are scheduled together onto the same node
• start and stop together as an atomic unit

That suits tightly coupled containers, such as an app and its log shipper.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: web-container
    image: nginx:1.20
    ports:
    - containerPort: 80

A container runs one application process, while a Pod is the Kubernetes unit that wraps one or more containers with shared networking and storage.

A container is an isolated process, created from a container image, with its own filesystem and resource limits. Outside Kubernetes it also gets its own network stack. Kubernetes never schedules a container on its own, though. It schedules Pods, the smallest deployable unit.

Inside a Pod, the containers share one IP address and port space and can mount the same volumes. That lets a sidecar, a helper such as a log shipper or proxy, run next to the main container and reach it over localhost.

The usual Pod holds one container. Extra containers join it only when they must run and scale together.

Helm is the package manager for Kubernetes, much as apt is for Ubuntu or npm is for Node.js. It bundles an application's Kubernetes manifests into a reusable package called a chart.

One application needs many YAML files that differ per environment, and Helm manages them as one unit.

• Charts use Go templates, so one chart takes different values for dev, staging and production.
• Each install is a release with a stored history, so you can upgrade, roll back or uninstall it as one unit.
• A chart declares the charts it depends on, such as a database, and Helm installs them together.
• Charts are versioned and shared through repositories, so an application is portable across clusters and environments.

Helm has three concepts, charts, releases and repositories, plus one client, the helm CLI:

1. The Helm client handles chart development, repository management and release operations. It talks directly to the Kubernetes API server.
2. A chart is a package of manifest templates, metadata and default values, stored locally or in a repository.
3. A release is one deployed instance of a chart, with its own name and values. Helm keeps its history for upgrades and rollbacks.
4. A repository stores and shares charts. It can be public or private, and Artifact Hub lists charts from many public ones.

Installing one chart twice creates two separate releases.

A Helm chart is a package containing all the resource definitions needed to run an application on Kubernetes, written as templates plus default values.

mychart/
  Chart.yaml          # Chart metadata
  values.yaml         # Default configuration values
  charts/             # Dependency charts
  templates/          # Kubernetes manifest templates
    deployment.yaml
    service.yaml
    ingress.yaml
    _helpers.tpl      # Template helpers
  .helmignore         # Files to ignore during packaging

• Chart.yaml holds the chart's name, version and description, and it lists the chart's dependencies.
• values.yaml holds the defaults the templates render with.
• templates/ holds the Kubernetes manifest templates.
• charts/ holds the charts this one depends on.
• A README.md, when present, documents how to use the chart.

Charts are portable and reusable across environments, because you set the configuration through values.

You pass your own values with --set flags or values files at install or upgrade time. Helm merges them over the chart's defaults in a fixed order of precedence, highest first:

1. --set on the command line wins over everything.
2. A custom values file passed with --values, or its short form -f.
3. When you pass several -f files, a later file overrides an earlier one.
4. The chart's own values.yaml supplies the defaults and has the lowest precedence.

helm install myapp ./mychart --set replicaCount=5 --set image.tag=2.0

helm install myapp ./mychart --values custom-values.yaml

helm install myapp ./mychart -f values.yaml -f production-values.yaml

A custom values file only needs the keys you want to change:

replicaCount: 3
image:
  repository: myapp
  tag: "v2.1.0"
service:
  type: LoadBalancer
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"

Helm merges maps deeply, so setting image.tag keeps the default image.repository. Arrays are replaced whole, so to change one item you pass the full list.

A Pod's phase starts at Pending, moves to Running on a node, and ends at Succeeded or Failed. The status.phase field shows the current one:

1. Pending means the cluster accepted the Pod, but one or more containers are not yet created and ready to run. It includes scheduling and image pulls.
2. Running means the Pod is bound to a node, all containers exist, and at least one is running or restarting.
3. Succeeded means every container exited successfully and none will restart.
4. Failed means every container has terminated and at least one failed.
5. Unknown means the Pod's state cannot be read, usually because the node is unreachable.

Init containers run during Pending, and container states such as Waiting and Terminated hold more detail. A failed liveness probe restarts the container under the Pod's restartPolicy, and a failed readiness probe removes the Pod from Service endpoints.

Deleting a Pod starts graceful termination. The kubelet sends SIGTERM to each container and waits up to the grace period, 30 seconds by default. Processes still running after that get SIGKILL.