Video summary

KUBERNETES ЗА 13 МИНУТ

Main summary

Key takeaways

Educational

Main ideas / lessons conveyed

  • Kubernetes (K8s) is a container orchestration platform: it automates how containerized applications are deployed, updated, scaled, and kept running in production.
  • Architecture is logically split into a “Control Plane” and “Worker Nodes.”
    • Control Plane decides what should run and tracks desired state.
    • Worker Nodes run the actual containers and report status back to the control plane.
  • Kubernetes configurations are declared via YAML manifests (desired state).
  • Kubernetes uses core abstractions to manage applications:
    • Pod as the smallest deployable unit.
    • ReplicaSet to maintain the desired number of identical pods.
    • Deployment as the main tool for lifecycle management (updates, rollbacks, scaling).
    • StatefulSet for stateful workloads requiring stable identities and storage.
    • Service to provide stable networking for pods that may be recreated.
    • Ingress for HTTP(S) routing with domains/paths, typically fronted by a single load balancer.
    • ConfigMap and Secret to separate configuration and sensitive data from container images.
    • Volumes / PV / PVC for persistence beyond the lifetime of containers.

Architecture (Control Plane vs Worker Nodes)

Control Plane (“management”, “makes decisions”)

  • API server: the main entry point for communication with Kubernetes.
  • Scheduler (described via “sxid-controller”): decides which node should run workload components.
  • controller-manager (managing controllers):
    • includes controllers such as deployment/replica set controllers that reconcile actual vs desired state.
  • etcd: cluster database storing information/state about the cluster.

Worker Nodes (“do the work”)

Each node contains:

  • kubelet: agent that communicates with the control plane and ensures containers are running as expected.
  • network proxy (“proxy cube”): configures networking inside the cluster.
  • runtime / container runtime: actually launches containers.

Main Kubernetes entities and how they relate

1) Pod

  • Smallest unit of deployment.
  • Contains one or more containers that run together.
  • Commonly described in YAML manifests.
  • Pods can include:
    • Main application container
    • Init containers (run before the main container; configure/check prerequisites, then exit)
    • Sidecar containers (run in parallel; examples given: log collection, traffic proxying, updating RTMs)
    • A pause container (commonly present in the pod for networking)

2) How pods are “kept alive”: ReplicaSet

  • Problem addressed: pods are unreliable/ephemeral; they can die.
  • ReplicaSet ensures the cluster maintains the desired number of pod replicas.
  • Key settings:
    • replicas: desired pod count
    • selector / match labels: how the ReplicaSet finds which pods it owns (labels used for discovery)

3) Deployment (main lifecycle manager)

  • Deployment manages a ReplicaSet and therefore manages the application lifecycle.
  • In practice, people typically use Deployments rather than creating Pods/ReplicaSets directly.
  • Main features highlighted:
    • Rolling updates
    • Rollbacks
    • Scaling

Rolling update behavior (V1 → V2)

When updating from image version V1 to V2 with a rolling update:

  1. Kubernetes creates a new pod with version V2
  2. Waits for it to become ready
  3. Terminates the old pod with version V1
  4. Repeats until all required pods are updated

Readiness / liveness / startup probes (traffic readiness)

Kubernetes needs to know when a pod/container is ready.

  • liveness probe (“checks alive”)
    • If the container is not alive → restart it.
  • readiness probe (“checks ready”)
    • If not ready → the container does not receive traffic.
  • startup probe (“checks started”)
    • Verifies the container has started at all.

Rollback behavior

Deployments support rollback by:

  • rolling back to a previous version
  • viewing history
  • rolling back to a specific revision (via a to revision parameter)

Scaling behavior

Scaling up/down is done by changing the number of replicas.

What happens under the hood when applying a Deployment

Workflow sequence (step-by-step)

  1. User runs a kubectl apply-like action with the Deployment YAML.
  2. kubectl sends the YAML to the API server.
  3. API server validates the manifest and stores cluster state in etcd.
  4. Deployment controller (part of controller-manager) detects the Deployment and creates a ReplicaSet.
  5. ReplicaSet controller computes how many pods are needed and creates them.
  6. Scheduler/controller logic assigns pods to nodes.
  7. On each selected node:
    • kubelet receives the task
    • container runtime pulls the image
    • runtime creates and starts the container
  8. kubelet reports success.
  9. If a pod dies:
    • ReplicaSet controller notices the count drop (e.g., from 3 to 2)
    • it creates a replacement pod
    • the lifecycle repeats

Stateful workloads: StatefulSet (versus Deployment)

Why Deployment isn’t enough

  • Deployment works best for stateless applications.
  • For databases / systems with identity and ordering, use StatefulSet.

Stateless vs Stateful (conceptual distinction)

  • Stateless
    • it doesn’t matter which instance handles a request (e.g., web servers)
    • if one pod dies, another can serve without users noticing
  • Stateful
    • instances have state and “personality”
    • examples mentioned: PostgreSQL, master/replica, brokers, ElasticSearch nodes
    • the system must avoid mixing data across restarted instances

StatefulSet solutions (guarantees)

StatefulSet provides:

  • Stable names (pods numbered like MySQL0, MySQL1, MySQL2)
    • always in the same order, not random
  • Stable network identity / DNS
    • each pod gets its own DNS entry
  • Stable startup/shutdown order
    • start: 0 → 1 → 2
    • delete/stop: reverse order
  • Persistent storage
    • each pod gets persistent volume access so it reconnects to the same disk
    • described as critical for database correctness

Networking stability: Services

The problem

  • Pods have changing IPs because they are recreated.
  • Other pods need a stable way to reach an application.

The solution: Service

A Service provides a stable address/DNS for accessing a set of pods.

  • The video describes:
    • a Service YAML example
    • traffic to a service port (e.g., “port 80”)
    • distribution across “all live pods” managed by Kubernetes

Types of Services mentioned

  • ClusterIP
    • accessible only within the cluster
    • for internal uses like databases/caches/internal APIs
  • NodePort
    • opens a port on each node
    • reachable from outside (noted as costly; often for testing rather than typical production)
  • External Load Balancer
    • typically used via a cloud LB; creates a dedicated LB per service (video highlights cost concerns)
    • in many microservices architectures, this can mean many load balancers/IPs

HTTP routing: Ingress

Why Ingress exists

Many services shouldn’t require a separate external load balancer per service.

Ingress concept and behavior

  • An Ingress controller (example mentioned: “Engins”, likely nginx ingress controller) is installed.
  • It:
    • monitors Ingress resources
    • configures routing rules
  • Result:
    • one load balancer for the cluster
    • multiple services routed under the same ingress using domains and paths

Configuring applications safely: ConfigMaps and Secrets

ConfigMap

  • Stores non-sensitive configuration separate from the image.
  • Mounted/used inside pods similarly to how secrets are used.

Secret

  • Stores sensitive data (passwords, tokens).
  • The video stresses:
    • Kubernetes “secrets” are not real encryption by default (Base64 is described as encoding, not security).
    • real protection requires external systems like:
      • HashiCorp Vault
      • Sealed Secrets
    • requires proper access controls and encryption mechanisms for stronger security.

Storage beyond container lifetime: Volumes, PV, PVC

The core issue

  • Containers are ephemeral: when a container dies, its data is lost.
  • Volumes are introduced to persist data needed for databases or user uploads.

Types / progression described

  • Temporary storage / ephemeral volumes
    • created with the pod
    • dies with the pod
    • useful for sharing data between containers in a pod or temporary cache
  • Persistent storage
    • Persistent Volume (PV): physical disk resource created by the admin (e.g., “100 GB on an SSD”)
    • Persistent Volume Claim (PVC): application request for storage (e.g., “give me N GB”)
    • Kubernetes binds a suitable PV to the PVC

Volume access modes mentioned

  • ReadWriteOnce: mounted to a single pod for read/write
  • ReadOnlyMany: many pods can read (write semantics implied as limited)
  • ReadWriteMany: many pods can write

Closing recap (base concepts)

The video emphasizes these core objects:

  • Pods
  • ReplicaSets
  • Deployments
  • Services
  • ConfigMaps
  • Secrets
  • Persistent Volumes (PV)
  • Persistent Volume Claims (PVC)
  • StatefulSets
  • Ingress

It also notes there are additional topics (e.g., network policies, etc.) beyond the basics.

Speakers / sources featured

  • No specific named external speaker or source is identified in the subtitles.
  • The subtitles reference the video author/narrator (course promotion and engagement prompts like “follow the link” and “subscribe”).
  • Named third-party systems/tools mentioned (as referenced technologies/providers, not as speakers):
    • Google (creator of Kubernetes, per the video)
    • HashiCorp Vault
    • Sealed Secrets
    • Kubernetes Dashboard and Lens (UI tools)
    • nginx (likely nginx ingress controller)
    • etcd (Kubernetes component)

Original video