AWS Containers Blog

Ideas you will meet

Kubernetes

Container orchestration, scheduling and service discovery.

Docker

Package and ship applications as containers.

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

• Core Concepts: How Things Actually Work · 7 minIaaS, PaaS, SaaS, containers and serverlessWhat you manage and what the provider manages in each model, and when each one fits.Read hereClose

  The stack and who manages what

  Every application sits on layers: networking, storage, servers, virtualisation, operating system, runtime, application, data. Cloud models differ in how many layers the provider handles for you.

  Model	You manage	Provider manages	Example
  On premises	everything	nothing	your own data centre
  IaaS (infrastructure)	OS, runtime, app, data	hardware, virtualisation, network	virtual machines, block storage
  PaaS (platform)	app and data	OS, runtime, scaling	managed app platforms, managed databases
  FaaS / serverless	function code	everything else, including scaling	event-triggered functions
  SaaS (software)	your usage and settings	the whole application	email, CRM, collaboration tools

  More managed means less work and less control. Less managed means more flexibility, and more to operate.

  100%

  Figure SDA-CORE-13-1 · Who manages what in each model · © forcsguy.com

  Virtual machines and containers

  • A virtual machine emulates hardware and runs a complete guest OS. Strong isolation, heavier, slower to start.
  • A container packages an app and its dependencies and runs as an isolated process on the host's kernel. Lightweight, starts in seconds, and runs the same everywhere ("works on my machine" problems shrink).
  • Orchestrators such as Kubernetes schedule containers across machines, restart failed ones, scale and roll out updates.

  100%

  Figure SDA-CORE-13-2 · Virtual machines and containers · © forcsguy.com

  Serverless

  You provide a function; the platform runs it on demand and bills per execution. Strengths: no servers to manage, scales to zero and up automatically, and you pay for use. Limits: cold starts (first request after idle is slower), maximum run time, limited local state, and harder local testing. Best for event-driven, spiky or glue workloads.

  Choosing

  • Spiky or tiny workloads, small team: serverless or PaaS.
  • Steady high load or special needs: containers or VMs with more control, often cheaper at scale.
  • Need maximum control, compliance or custom hardware: IaaS or on premises.
  • Use managed databases and queues where you can: operating them well is hard.
  • Beware lock-in: prefer open formats (containers, standard SQL) when portability matters.

  More on this site

  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

  • Docker BlogDocker engineers · DockerBlogs
  • Docker OverviewDocker · Docker Inc.Documentation
  • Docker Containers that Power Over 100.000 Online Shops at ShopifyShopify engineers · ShopifyCase Studies
  • Build Your Own XCodeCrafters · GitHubGitHub
  • Docker Engineering BlogDocker engineers · DockerBlogs
  • Scaling Git at Microsoft - Saeed Noursalehi, Principal Program Manager at MicrosoftMicrosoftYouTube

  Open this lesson with its quiz and exercise