Very Brief intro TO

docker &
Kubernetes (k8s)

February 2024 | Vašek Lorenc

Index

The beginning

Docker

Kubernetes (k8s)

The end

Expectations

What you won't learn today

  • how to develop for Docker/k8s
  • how to administer k8s
  • how to secure these things

 

What you might learn

  • (not-so-simple) basics
  • (hidden) complexity of container solutions
  • (incorrect) abstractions used

The Beginning

Based on

true story

The Beginning

Production vs Development

  • operating system version
  • installed packages (versions)
  • compiler discrepancies
  • differences in service configurations
    • ​DB tables, schema, ...
  • various production environments
    • on-prem, AWS, VPS, ...
  • ...

Motivation for containers

Build once, run everywhere

Containers

A bit of history

Not a brand new idea

  • 20 years history
    • zones (Solaris, 2004)
    • wpars (AIX)
    • jails (BSD)
    • chroot (Linux)
    • ...
  • Docker
    • released in 2013
    • ​great ecosystem built on known principles

Docker

Three pillars

namespaces

  • logical isolation of resources
    • processes, users, network connections, ...

cgroups

  • resource constrains
    • ​memory, CPU, permissions, ...

overlay filesystem

  • improved distribution of the images

Docker

Terminology

containers

  • isolated/constrained processes

images

  • layers
  • base image
  • parent image
  • Dockerfile

hub

  • (de-)centralized repository for container images

Docker

Dockerfile

Drives building of container images

  • stable build process, stable builds
  • same recipe works everywhere
# syntax=docker/dockerfile:1

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN yarn install --production
CMD ["node", "src/index.js"]
EXPOSE 3000

DockeR

technical notes

Containers are NOT VMs

  • very thin layer between Linux OS and containers
  • you can create a "container" by manipulating a Linux process
    • thus, think of them as of processes, it's more accurate

 

Docker isn't the only containerization runtime

  • It's popular, but not the only (or even the best) one
  • podman, containerd, runC, rkt, ...

Docker

technical INFO

We could go deeper!

  • docker-in-docker (DinD) solutions used
    • ​used for Gitlab runners
  • ​multi-stage docker builds
  • "rootless" containers​

Mapping resources from the host system

  • containers aren't isolated from external world
    • exposed ports
    • filesystem objects
    • environmental variables

Docker

Security summary

Not going there today

All is great,

problems solved!

Well YES,

but actually

no

Docker

Docker compose

Multiple services needed!

  • reverse proxy
  • ​identity management
  • databases
    • stateful services in a stateless world
  • ​logging/data analysis
  • ...

Docker

Docker compose

Standardized YAML configuration file

  • covers all the Docker configuration aspects
  • easy to write, easy to understand
  • no need to remember all runtime parameters
$ docker compose up web

Docker

Docker compose

docker-compose.yml

services:
  web:
    build: .
    ports:
      - "8000:5000"
    volumes:
      - .:/code
      - logvolume01:/var/log
    depends_on:
      - redis
  redis:
    image: redis
    
volumes:
  logvolume01: {}

All is great,

problems solved!

Well YES,

but actually

no

Kubernetes

The "F" in

Kubernetes

stands for "FUN".

Kubernetes

Sometimes, we need more

  • (auto-)scaling
    • and service recovery
  • multiple nodes
    • end even mixed cloud environments
  • service discovery
  • configuration management and secrets handling
  • rolling upgrades
  • "deployment packages"
  • ....

Motivation

microservices!

Kubernetes

workload

  • application/software

pod

  • a logically associated set of container(s)
  • can share resources (like IP, i/o stack, ...)

node

  • a machine, might be virtual

cluster

  • set of nodes

(Updated) terminology

scheduling

  • deployment

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: marcocodes-web
spec:
  containers:
    - image: gcr.io/marco/marcocodes:1.4
      name: marcocodes-web
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

sample-pod.yml

POD Manifest

Kubernetes

TBD

Kubernetes

Resiliency & Load Balancing

  • redundant instances of our application
  • load-balancing
    • requests handled by multiple instances, not just one
  • added resiliency

Replicasets

Kubernetes

apiVersion: apps/v1
kind: ReplicaSet
# metadata:
# ...
spec:
  replicas: 2
  selector: "you will learn this later"
  # ...
  template:
    metadata: "you will learn this later"
      # ...
    spec:
      containers:
        - name: marcocodes-web
          image: "gcr.io/marco/marcocodes:3.85"

sample-pod-replicas.yml

Replicasets

Kubernetes

Resiliency & Load Balancing

  • redundant instances of our application
  • load-balancing
    • requests handled by multiple instances, not just one
  • added resiliency

Replicasets

However

  • They are app-version specific ==> DEPLOYMENTS
    • ​rolling-updates for the win!
    • another gazillion of YAML key-values to learn & use

Kubernetes

Not-so-static (micro)services

  • discovering things in a highly dynamic world
  • various options
    • varies by expected use, protocols, way of working
    • even depends on "fanciness"
      • but that doesn't surprise you, right?

Service discovery

Kubernetes

"Packages" for Kubernetes

  • usually in repos
  • makes deployments of easier
  • de-facto standard in k8s world when it comes to complex services

Example: WordPress Helm Chart

  • Deployment, ConfigMap, Secrets, multiple services, ...

HELM Charts

$ helm install my-release oci://registry-1.docker.io/bitnamicharts/wordpress

And we are done!

Well YES,

but actually

no

Kubernetes

What else we need to consider/build/maintain/learn?

  • auto-scaling!
    • various options with varying complexity
  • CNI (Container Network Interface)
    • welcome to the real hell of networking options
  • service mesh
    • i'd repeat myself here, you got the point
  • authentication
    • backend/frontend
    • OIDC, JWT, ...
  • ...

Aditional components

Kubernetes

What else we need to consider/build/maintain/learn?

  • ingress & egress
    • load-balancing, policies, API gateways, ...
  • config maps
    • key-value configuration store
  • secrets management
    • in AWS, Azure, HashiCorp Vault, ...
  • daemonsets
    • CrowdStrike Falcon is deployed like this, for example
  • ...

Aditional components...

Kubernetes

What else we need to consider/build/maintain/learn?

  • sidecar containers
    • another way of running CrowdStrike Falcon in k8s
  • GitOps
    • aka integration with some Gitlab/Github solution & workflow
  • problems with stateful applications
    • aka databases
  • and security! :)

Aditional components...

Kubernetes

Crowdstrike sensor Helm chart

Kubernetes

Kubernetes at HERE

DP Stratus

  • AWS orchestrated -- Amazon Elastic Kubernetes Service
    • and probably hybrid
  • single OIDC provider
    • ​plus some magic to be compatible with the old solution

Current DP

  • AWS hosted (walle_p, dl_p, borg_p)
  • using AWS components
  • multiple OIDC providers

Kubernetes

Containers are not VMs.

things to remember

Neither are kubernetes pods.

Kubernetes

Kubernetes isn't terraform.

things to remember

Kubernetes

Security &
BEST PRACTICEs

Further topics

KÜbernetes

Press F for fun.

Made with Slides.com