Hvis du arbejder i softwareudviklingsverdenen, har du helt sikkert hørt om Kubernetes. Men hvad er det præcist, og hvorfor er det blevet den de facto-standard for håndtering af containeriserede applikationer? Denne guide tager dig fra det grundlæggende til de fundamentale koncepter med praktiske eksempler og diagrammer til at hjælpe dig med at forstå.

Før Kubernetes: Lidt historie

For at forstå, hvorfor Kubernetes er så revolutionerende, lad os tage et skridt tilbage.

1. Traditionel deployment: Oprindeligt kørte applikationer på fysiske servere. Denne tilgang var dyr, svær at skalere og udsat for ressourcekonflikter.
2. Virtualiseret deployment: Derefter kom Virtual Machines (VM'er). VM'er tillod flere isolerede applikationer at køre på den samme hardware, hvilket forbedrede ressourceudnyttelsen og sikkerheden. Dog kører hver VM et helt operativsystem, hvilket forbruger mange ressourcer.
3. Containeriseret deployment: Containere (som Docker) er den næste evolution. De deler det samme værts-operativsystem, men kører isolerede processer. De er lette, hurtige at starte og portable.

Containere løste portabilitetsproblemet, men skabte et nyt: hvordan håndterer man hundredvis (eller tusindvis) af containere i et produktionsmiljø? Hvordan sikrer man, at de altid kører, kan kommunikere med hinanden og skalerer baseret på belastning?

Her kommer Kubernetes ind.

Hvad er Kubernetes?

Kubernetes (ofte forkortet K8s) er en open source-platform til container-orkestrering. Med enkle ord automatiserer det deployment, skalering og håndtering af containeriserede applikationer. Skabt af Google og nu vedligeholdt af Cloud Native Computing Foundation (CNCF), er Kubernetes blevet det foretrukne værktøj for alle, der arbejder med microservices i stor skala.

Arkitekturen af en Kubernetes-klynge

Et Kubernetes-miljø kaldes en klynge. En klynge består af et sæt maskiner, kaldet noder, der kører vores applikationer. Arkitekturen er opdelt i to hoveddele: Control Plane og Worker Nodes.

Control Plane

Control Plane er klyngens "hjerne". Det træffer globale beslutninger (som scheduling) og opdager og reagerer på klyngehændelser. Dets hovedkomponenter er:

• API Server (kube-apiserver): Porten til klyngen. Den eksponerer Kubernetes API, som bruges af brugere (via kubectl), klyngekomponenter og eksterne værktøjer til at kommunikere.
• etcd: En konsistent og højt tilgængelig nøgle-værdi-database. Den gemmer alle klyngedata og repræsenterer systemets ønskede og aktuelle tilstand.
• Scheduler (kube-scheduler): Tildeler nyoprettede Pods til en tilgængelig Worker Node under hensyntagen til ressourcekrav, politikker og andre begrænsninger.
• Controller Manager (kube-controller-manager): Kører controllere, som er kontrolsløjfer, der overvåger klyngens tilstand og arbejder for at bringe den til den ønskede tilstand.

Worker Node

Worker Nodes er maskinerne (fysiske eller virtuelle), hvor applikationerne faktisk køres. Hver node styres af Control Plane og indeholder følgende komponenter:

• Kubelet: En agent, der kører på hver node. Den sikrer, at containerne beskrevet i Pods kører og er sunde.
• Kube-proxy: En netværksproxy, der håndterer netværksregler på noderne.
• Container Runtime: Softwaren, der er ansvarlig for at køre containere. Docker er den mest kendte, men Kubernetes understøtter også andre runtimes som containerd og CRI-O.

Fundamentale Kubernetes-objekter

I Kubernetes er alt repræsenteret af objekter. Disse objekter er "hensigtsregistreringer": når du opretter et objekt, arbejder Kubernetes konstant for at sikre, at det eksisterer og matcher den ønskede tilstand.

Pod

Pod er den mindste udførelsesenhed i Kubernetes. Den repræsenterer en eller flere containere, der køres sammen på den samme node og deler ressourcer som netværk og lagring.

Deployment

Et Deployment er det objekt, du vil bruge oftest. Det beskriver den ønskede tilstand for en gruppe af identiske Pods. Deployment-controlleren er ansvarlig for at skabe og håndtere et ReplicaSet, skalere antallet af Pods op eller ned og håndtere applikations-opdateringer på en kontrolleret måde.

# nginx-deployment.yaml
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.14.2
        ports:
        - containerPort: 80

Service

Pods i Kubernetes er flygtige: de kan oprettes og destrueres når som helst. Hver Pod har sin egen IP-adresse, men denne IP er ikke stabil. Så hvordan eksponerer vi pålideligt vores applikation?

Med en Service. En Service er en abstraktion, der definerer et logisk sæt af Pods og en politik for adgang til dem. Den giver et stabilt adgangspunkt (en virtuel IP-adresse og et DNS-navn) for en gruppe af Pods.

# nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP # Standard - eksponerer kun tjenesten inden for klyngen

Der er forskellige typer Services:

• ClusterIP: Eksponerer tjenesten på en klyngeintern IP (standard).
• NodePort: Eksponerer tjenesten på en statisk port på hver Worker Node.
• LoadBalancer: Opretter en ekstern load balancer hos cloud-udbyderen og tildeler en offentlig IP til tjenesten.

Ingress

En LoadBalancer Service er god, men at oprette en for hver tjeneste kan være dyrt. For at eksponere flere HTTP/HTTPS-tjenester til omverdenen bruger man en Ingress.

# example-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: mysite.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /ui
        pathType: Prefix
        backend:
          service:
            name: ui-service
            port:
              number: 3000

Andre nyttige objekter

• Namespace: Giver dig mulighed for at oprette "virtuelle klynger" inde i en fysisk klynge.
• ConfigMap og Secret: Til håndtering af konfigurationsdata og hemmeligheder (som adgangskoder eller API-nøgler) adskilt fra container-imaget.
• StatefulSet: Svarer til et Deployment, men specifikt for tilstandsfulde applikationer (som databaser).
• PersistentVolume (PV) og PersistentVolumeClaim (PVC): Til håndtering af persistent lagring i klyngen.

Konklusion

Kubernetes er et utroligt kraftfuldt værktøj, men dets indlæringskurve kan være stejl. Denne guide har kun skrabet overfladen, men vi håber, den har givet dig en solid forståelse af de grundlæggende koncepter.

Hvad nu?

• Eksperimenter lokalt: Installer Minikube eller Kind for at oprette en Kubernetes-klynge på din computer.
• Brug kubectl: Bliv fortrolig med kubectl-kommandoen, dit vigtigste værktøj til at interagere med klyngen.
• Udforsk de officielle tutorials: Kubernetes-dokumentationen er en fantastisk ressource fuld af eksempler.

Container-orkestrering er en fundamental færdighed i den cloud-native verden, og at mestre Kubernetes vil åbne en verden af muligheder. God fornøjelse!