Kubernetes Blog

Ideas you will meet

Kubernetes

Container orchestration, scheduling and service discovery.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Advanced Distributed Systems · 13 minKubernetes essentialsPods, deployments, services, ingress and operators: the building blocks of the most common container platform and how a request reaches a pod.Read hereClose

  What Kubernetes does

  Kubernetes (K8s) runs containers across a cluster of machines. You describe the desired state (for example "three copies of this image, reachable at this address") and controllers continuously make reality match it: restarting failed containers, replacing lost nodes and rolling out new versions. (Containers themselves are introduced in the cloud models lesson.)

  The cluster

  • Control plane: the API server (everything talks to it), etcd (the consistent store of cluster state, built on Raft; see the consensus lesson), the scheduler (decides which node runs a pod) and controllers (reconcile desired and actual state).
  • Nodes: machines that run pods, each with a node agent (kubelet), a container runtime and a networking component.

  The core objects

  100%

  Figure SDA-ADS-07-1 · From request to pod · © forcsguy.com

  Object	Purpose
  Pod	Smallest unit: one or more containers sharing network and volumes
  ReplicaSet / Deployment	Keep N pods running; roll out updates and roll back
  Service	Stable virtual IP and DNS name that load balances to matching pods
  Ingress	HTTP routing from outside to services (host, path, TLS), handled by an ingress controller
  ConfigMap / Secret	Configuration and sensitive values injected as environment variables or files
  StatefulSet	Pods with stable identity and storage, for databases and brokers
  DaemonSet	One pod per node (log shippers, agents)
  Job / CronJob	Run to completion, once or on a schedule
  Namespace	Logical separation of resources and quotas
  PersistentVolume(Claim)	Durable storage requested by pods

  Networking in one paragraph

  Every pod gets its own IP and can reach every other pod without NAT. Because pods are short-lived, clients use Services (found through cluster DNS such as orders.shop.svc). Network policies restrict which pods may talk to which. An Ingress (or the newer Gateway API) handles external HTTP(S) traffic.

  A deployment and a rolling update

  apiVersion: apps/v1
  kind: Deployment
  metadata: { name: web }
  spec:
    replicas: 3
    selector: { matchLabels: { app: web } }
    strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 0 } }
    template:
      metadata: { labels: { app: web } }
      spec:
        containers:
          - name: web
            image: example/web:1.4.2
            resources: { requests: { cpu: 200m, memory: 256Mi }, limits: { memory: 512Mi } }
            readinessProbe: { httpGet: { path: /healthz, port: 8080 } }
  

  100%

  Figure SDA-ADS-07-2 · Rolling update · © forcsguy.com

  Probes: readiness decides if a pod receives traffic; liveness decides if it should be restarted; startup gives slow starters time. Requests and limits tell the scheduler how much CPU and memory a pod needs and cap what it can use.

  Autoscaling

  A Horizontal Pod Autoscaler adds or removes pods by metrics such as CPU or request rate; a cluster autoscaler adds or removes nodes when pods cannot be placed. Scaling is useless without correct resource requests.

  Extending Kubernetes: operators and CRDs

  A Custom Resource Definition (CRD) adds a new object type (for example PostgresCluster). An operator is a controller that watches those objects and does the operational work (create replicas, take backups, fail over), encoding human runbooks as code. Many databases and brokers ship operators.

  Things that often go wrong

  Missing readiness probes (traffic to pods not ready), no resource requests (noisy neighbours, evictions), latest image tags (unrepeatable deploys), secrets in plain config, a single replica for a critical service, and running stateful systems without understanding storage and failure behaviour.

  Real-world reading

  Related reading

  • TechWorld with Nana: Docker & KubernetesNana Janashia · TechWorld with NanaYouTube
  • AWS Containers BlogAmazon Web Services engineers · Amazon Web ServicesBlogs
  • Awesome KubernetesRamit Surana · ramitsuranaGitHub
  • Kubernetes ConceptsKubernetes Authors · CNCF / KubernetesDocumentation

  Show 6 moreShow fewer

  • Kubernetes: IngressKubernetes · CNCF / KubernetesDocumentation
  • Docker BlogDocker engineers · DockerBlogs
  • DevOps Roadmaproadmap.sh community · roadmap.shCourses
  • Kubernetes BlogKubernetes community · CNCF / KubernetesBlogs
  • From bare-metal to Kubernetes at BetabrandBetabrand engineers · BetabrandCase Studies
  • Large-scale cluster management at Google with Borg (paper)Verma et al. · GooglePapers

  Open this lesson with its quiz and exercise

• Messaging and Microservice Patterns · 12 minService discovery, service mesh and sidecarsHow services find each other as instances come and go, and how sidecar proxies and a mesh move retries, security and telemetry out of application code.Read hereClose

  The problem: moving targets

  In a microservice system, instances are created and destroyed constantly by autoscaling, deployments and failures. A caller cannot rely on a fixed address. It needs an answer to "where are the healthy instances of the orders service right now?"

  Service discovery

  Instances register themselves (or are registered by the platform) in a registry; callers look up the current list.

  100%

  Figure SDA-MSV-04-1 · Service registry and lookup · © forcsguy.com

  • Client-side discovery: the caller queries the registry and balances itself (smart client library).
  • Server-side discovery: the caller talks to a load balancer or the platform's service address, which knows the instances (Kubernetes Services and cluster DNS work this way; see the Kubernetes lesson).
  • DNS-based discovery is simple but constrained by caching.
  • Registries must be highly available (often built on consensus; see the consensus lesson), and the system should keep working with the last known list if the registry is briefly unreachable.

  Sidecars

  A sidecar is a helper process or container deployed alongside each service instance (in Kubernetes, in the same pod). All the service's network traffic goes through it. It can take over cross-cutting jobs so application code does not have to implement them in every language:

  • retries, timeouts and circuit breaking (see the resilience lesson),
  • mutual TLS (encrypting and authenticating service-to-service traffic),
  • load balancing and service discovery,
  • metrics, logs and tracing headers,
  • access policy.

  Other sidecar uses: log shippers, config reloaders, secret agents.

  Service mesh

  A service mesh is a dedicated infrastructure layer made of two parts:

  • Data plane: the fleet of sidecar proxies (often Envoy) that carry the traffic.
  • Control plane: configures and secures the proxies, distributes certificates and policy (for example Istio, Linkerd, Consul).

  100%

  Figure SDA-MSV-04-2 · Control plane and data plane · © forcsguy.com

  What a mesh enables:

  • Traffic management: weighted routing for canary releases, mirroring, fault injection, timeouts and retries by route.
  • Security: automatic mutual TLS and service-level authorisation, giving each service a cryptographic identity.
  • Observability: uniform metrics, traces and access logs for every call, without code changes.

  Costs and alternatives

  • Resources and latency: a proxy per instance adds CPU, memory and a small latency per hop.
  • Operational complexity: another system to upgrade and debug; misconfiguration can break everything.
  • Learning curve and sometimes opaque behaviour.
  • Newer designs reduce per-pod cost (node-level or "ambient" proxies).

  Alternatives: a shared library for resilience and telemetry (language-bound, needs upgrades everywhere), a managed platform's built-in features, or an API gateway for north-south traffic only (see the load balancing lesson).

  When a mesh makes sense

  Many services, several languages, strong needs for mutual TLS or consistent policy, and a platform team able to run it. For a handful of services, platform defaults and a good library are usually enough. As ever, adopt the pattern for a problem you have.

  Real-world reading

  Related reading

  • CNCF BlogCNCF community · CNCFBlogs
  • CNCF Cloud Native LandscapeCNCFDocumentation
  • Kubernetes: IngressKubernetes · CNCF / KubernetesDocumentation
  • Kubernetes BlogKubernetes community · CNCF / KubernetesBlogs

  Show 6 moreShow fewer

  • Envoy ProxyEnvoy · CNCF / EnvoyGitHub
  • CNCFCloud Native Computing Foundation · CNCFYouTube
  • DevOps Roadmaproadmap.sh community · roadmap.shCourses
  • Operate Kubernetes Reliably at StripeStripe engineers · StripeCase Studies
  • Cloud Design PatternsMicrosoft · Microsoft AzureDocumentation
  • Kubernetes overviewKubernetes · CNCF / KubernetesDocumentation

  Open this lesson with its quiz and exercise