1 
2Hvis 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å.
3 
4## Før Kubernetes: Lidt historie
5 
6For at forstå, hvorfor Kubernetes er så revolutionerende, lad os tage et skridt tilbage.
7 
81.  **Traditionel deployment**: Oprindeligt kørte applikationer på fysiske servere. Denne tilgang var dyr, svær at skalere og udsat for ressourcekonflikter.
92.  **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.
103.  **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.
11 
12Containere 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?
13 
14Her kommer **Kubernetes** ind.
15 
16## Hvad er Kubernetes?
17 
18Kubernetes (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.
19 
20## Arkitekturen af en Kubernetes-klynge
21 
22Et 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.
23 
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32 
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39 
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45 
46    A -- "Communicates with" --> E
47    A -- "Communicates with" --> J
48    User -- "kubectl" --> A
49    C -- "Assigns Pods to Nodes" --> E
50    D -- "Maintains state" --> A
51    A -- "Saves/Reads state" --> B
52```
53 
54### Control Plane
55 
56Control Plane er klyngens "hjerne". Det træffer globale beslutninger (som scheduling) og opdager og reagerer på klyngehændelser. Dets hovedkomponenter er:
57 
58-   **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.
59-   **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.
60-   **Scheduler (`kube-scheduler`)**: Tildeler nyoprettede Pods til en tilgængelig Worker Node under hensyntagen til ressourcekrav, politikker og andre begrænsninger.
61-   **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.
62 
63### Worker Node
64 
65Worker Nodes er maskinerne (fysiske eller virtuelle), hvor applikationerne faktisk køres. Hver node styres af Control Plane og indeholder følgende komponenter:
66 
67-   **Kubelet**: En agent, der kører på hver node. Den sikrer, at containerne beskrevet i Pods kører og er sunde.
68-   **Kube-proxy**: En netværksproxy, der håndterer netværksregler på noderne.
69-   **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`.
70 
71## Fundamentale Kubernetes-objekter
72 
73I 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.
74 
75### Pod
76 
77**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.
78 
79### Deployment
80 
81Et **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.
82 
83```yaml
84# nginx-deployment.yaml
85apiVersion: apps/v1
86kind: Deployment
87metadata:
88  name: nginx-deployment
89spec:
90  replicas: 3
91  selector:
92    matchLabels:
93      app: nginx
94  template:
95    metadata:
96      labels:
97        app: nginx
98    spec:
99      containers:
100      - name: nginx
101        image: nginx:1.14.2
102        ports:
103        - containerPort: 80
104```
105 
106### Service
107 
108Pods 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?
109 
110Med 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.
111 
112```mermaid
113graph TD
114    subgraph "Service (nginx-service)"
115        A["ClusterIP: 10.96.0.10"]
116    end
117 
118    subgraph "Pods"
119        B("Pod 1 - IP: 192.168.1.2")
120        C("Pod 2 - IP: 192.168.1.3")
121        D("Pod 3 - IP: 192.168.1.4")
122    end
123 
124    A -- "Selector: app=nginx" --> B
125    A -- "Selector: app=nginx" --> C
126    A -- "Selector: app=nginx" --> D
127 
128    Client -- "Request to nginx-service" --> A
129```
130 
131```yaml
132# nginx-service.yaml
133apiVersion: v1
134kind: Service
135metadata:
136  name: nginx-service
137spec:
138  selector:
139    app: nginx
140  ports:
141    - protocol: TCP
142      port: 80
143      targetPort: 80
144  type: ClusterIP # Standard - eksponerer kun tjenesten inden for klyngen
145```
146 
147Der er forskellige typer Services:
148- `ClusterIP`: Eksponerer tjenesten på en klyngeintern IP (standard).
149- `NodePort`: Eksponerer tjenesten på en statisk port på hver Worker Node.
150- `LoadBalancer`: Opretter en ekstern load balancer hos cloud-udbyderen og tildeler en offentlig IP til tjenesten.
151 
152### Ingress
153 
154En `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**.
155 
156```mermaid
157graph LR
158    User -- "mysite.com/api" --> Ingress
159    User -- "mysite.com/ui" --> Ingress
160 
161    subgraph "Cluster"
162        Ingress -- "/api" --> ServiceA("api-service")
163        Ingress -- "/ui" --> ServiceB("ui-service")
164 
165        ServiceA --> PodA1("API Pod 1")
166        ServiceA --> PodA2("API Pod 2")
167 
168        ServiceB --> PodB1("UI Pod 1")
169        ServiceB --> PodB2("UI Pod 2")
170    end
171```
172 
173```yaml
174# example-ingress.yaml
175apiVersion: networking.k8s.io/v1
176kind: Ingress
177metadata:
178  name: example-ingress
179spec:
180  rules:
181  - host: mysite.com
182    http:
183      paths:
184      - path: /api
185        pathType: Prefix
186        backend:
187          service:
188            name: api-service
189            port:
190              number: 8080
191      - path: /ui
192        pathType: Prefix
193        backend:
194          service:
195            name: ui-service
196            port:
197              number: 3000
198```
199 
200### Andre nyttige objekter
201 
202-   **Namespace**: Giver dig mulighed for at oprette "virtuelle klynger" inde i en fysisk klynge.
203-   **ConfigMap og Secret**: Til håndtering af konfigurationsdata og hemmeligheder (som adgangskoder eller API-nøgler) adskilt fra container-imaget.
204-   **StatefulSet**: Svarer til et Deployment, men specifikt for tilstandsfulde applikationer (som databaser).
205-   **PersistentVolume (PV) og PersistentVolumeClaim (PVC)**: Til håndtering af persistent lagring i klyngen.
206 
207## Konklusion
208 
209Kubernetes 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.
210 
211**Hvad nu?**
212- **Eksperimenter lokalt**: Installer [Minikube](https://minikube.sigs.k8s.io/docs/start/) eller [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) for at oprette en Kubernetes-klynge på din computer.
213- **Brug `kubectl`**: Bliv fortrolig med `kubectl`-kommandoen, dit vigtigste værktøj til at interagere med klyngen.
214- **Udforsk de officielle tutorials**: [Kubernetes-dokumentationen](https://kubernetes.io/docs/tutorials/) er en fantastisk ressource fuld af eksempler.
215 
216Container-orkestrering er en fundamental færdighed i den cloud-native verden, og at mestre Kubernetes vil åbne en verden af muligheder. God fornøjelse!
217