Azure Fundamentals · leksjon

Kubernetes-konsepter for Azure

Gå gjennom sentrale Kubernetes-konstruksjoner — pods, deployments, services og namespaces — og forstå hvordan AKS administrerer kontrollplanet på dine vegne.

Leksjon 3 av 413 trinn

Kubernetes-konsepter for Azure er en gratis leksjon i Azure Fundamentals på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Azure Fundamentals, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Azure Fundamentals inneholder totalt 4 leksjoner.

Hva er Kubernetes?

Kubernetes (K8s) er en åpen kildekode-plattform for containerorkestrering som opprinnelig ble utviklet av Google. Den automatiserer distribusjon, skalering og administrasjon av containeriserte applikasjoner. I stedet for å kjøre containere manuelt erklærer De applikasjonens ønskede tilstand i YAML-manifester, og Kubernetes arbeider kontinuerlig for å samsvare den faktiske tilstanden med den ønskede tilstanden — ved å starte mislykkede containere på nytt, planlegge arbeidsbelastninger på friske noder og skalere replikaer.

Klyngearkitektur: kontrollplan og noder

En Kubernetes-klynge består av en kontrollplan og arbeidernoder. Kontrollplanet inneholder API-serveren (inngangspunktet for alle kubectl-kommandoer), etcd (distribuert tilstandslager), planleggeren (tilordner pods til noder) og kontrollermodulen (opprettholder ønsket tilstand). Arbeidernodene kjører kubelet (nodeagent), kube-proxy (nettverksregler) og en containerruntime (containerd). I AKS administrerer Microsoft kontrollplanet — De administrerer bare arbeidernodene.

# Kubernetes control plane components
# kube-apiserver    - REST API for all cluster operations
# etcd              - Distributed key-value store (cluster state)
# kube-scheduler    - Assigns pending pods to nodes
# kube-controller-manager  - Runs reconciliation controllers

# Worker node components
# kubelet           - Node agent, ensures containers run
# kube-proxy        - Network routing for services
# containerd        - Container runtime (runs containers)

Pods: den minste enheten som kan distribueres

En pod er den minste enheten som kan distribueres i Kubernetes. En pod omslutter én eller flere containere som deler nettverksnavneområde (samme IP-adresse), lagringsvolumer og livssyklus. Containere i en pod kommuniserer via localhost. Pods er kortvarige — når de mislykkes, erstattes de av nye pods med andre IP-adresser. De oppretter sjelden pods direkte; i stedet oppretter De ressurser på høyere nivå som administrerer pods.

# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: mycontainerregistry.azurecr.io/myapp:v1.0
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: '100m'
        memory: '128Mi'
      limits:
        cpu: '500m'
        memory: '512Mi'

Deployment: administrere ReplicaSet-er

En Deployment er standardmåten å kjøre tilstandsløse applikasjoner på i Kubernetes. Den oppretter og administrerer et ReplicaSet som opprettholder det ønskede antallet identiske pod-replikaer. Deployments støtter rullerende oppdateringer — der gamle pods gradvis erstattes med nye — og tilbakerullinger til tidligere versjoner. De beskriver ønsket pod-mal og antall replikaer; Kubernetes håndterer resten.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Create 1 extra pod during update
      maxUnavailable: 0 # Never reduce below desired count
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: mycontainerregistry.azurecr.io/myapp:v1.0
        ports:
        - containerPort: 80

Tjenester: stabile nettverkssluttpunkter

Siden pods er kortvarige og IP-adressene deres endres, tilbyr Services et stabilt nettverkssluttpunkt som lastbalanserer trafikk på tvers av samsvarende pods. Tjenesten bruker en etikettvelger til å finne pods. Tjenestetyper: ClusterIP (bare intern, standard), NodePort (eksponerer en port på hver node), LoadBalancer (klargjør en Azure Load Balancer med en offentlig IP-adresse) og ExternalName (DNS-alias til en ekstern tjeneste).

# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: LoadBalancer  # Creates Azure Load Balancer
  selector:
    app: myapp        # Routes traffic to pods with this label
  ports:
  - port: 80          # Service port
    targetPort: 80    # Pod/container port

# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svc

Navneområder for flerleietakervirksomhet

Namespaces deler én Kubernetes-klynge inn i flere virtuelle klynger. Ressurser i forskjellige navneområder er isolert etter navn — De kan ha en myapp-Deployment i både development- og production-navneområdet samtidig. Navneområder er den primære enheten for bruk av RBAC, ressurskvoter og nettverkspolicyer på et team eller miljø. Standardnavneområder inkluderer default, kube-system og kube-public.

# Create a namespace for the dev team
kubectl create namespace dev-team

# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team

# List all resources in a namespace
kubectl get all --namespace dev-team

# Set default namespace for current context
kubectl config set-context --current --namespace dev-team

ConfigMaps og Secrets

ConfigMaps lagrer ikke-sensitive konfigurasjonsdata som nøkkel-verdi-par eller filer, som injiseres i pods som miljøvariabler eller volummonteringer. Secrets lagrer sensitive data (passord, tokens) base64-kodet (ikke kryptert som standard — bruk Azure Key Vault Provider for Secrets Store CSI Driver for reell kryptering ved lagring). Begge er avgrenset til et navneområde og refereres til i podspesifikasjoner med navn.

# Create a ConfigMap from literal values
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=info

# Create a Secret
kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD='super-secret'

# Reference in a pod spec
# env:
# - name: APP_ENV
#   valueFrom:
#     configMapKeyRef:
#       name: app-config
#       key: APP_ENV
# - name: DB_PASSWORD
#   valueFrom:
#     secretKeyRef:
#       name: db-secret
#       key: DB_PASSWORD

Persistente volumer i Azure

Tilstandfulle applikasjoner trenger lagring som varer lenger enn individuelle pods. Kubernetes bruker PersistentVolumes (PVs) og PersistentVolumeClaims (PVCs) for å frikoble lagring fra podens livssyklus. I AKS klargjør de innebygde lagringsklassene Azure Disk og Azure Files automatisk administrerte disker og filressurser når en PVC opprettes. Azure Disk er beregnet for tilgang fra én pod, mens Azure Files støtter at flere pods leser og skriver samtidig.

# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce   # Single-node read/write (Azure Disk)
  storageClassName: managed-csi
  resources:
    requests:
      storage: 10Gi

# Mount in a pod
# volumes:
# - name: data
#   persistentVolumeClaim:
#     claimName: my-disk-pvc
# volumeMounts:
# - name: data
#   mountPath: /data

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) justerer automatisk antallet pod-replikaer i en Deployment basert på observert CPU-/minneutnyttelse eller egendefinerte måledata. HPA-kontrolleren spør måleserveren hvert 15. sekund og skalerer replikaer opp eller ned for å holde utnyttelsen nær målet. De angir minimums- og maksimumsantall replikaer som sikkerhetsgrenser for å hindre ukontrollert skalering.

# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Helsesjekker: liveness- og readiness-prober

Kubernetes bruker prober til å overvåke containerhelsen. En liveness-probe kontrollerer om en container fortsatt kjører — hvis den mislykkes, starter Kubernetes containeren på nytt. En readiness-probe kontrollerer om en container er klar til å betjene trafikk — hvis den mislykkes, fjernes poden fra tjenestens lastbalansering uten at den startes på nytt. En startup-probe utsetter de andre probene til applikasjonen er initialisert, slik at for tidlige omstarter unngås under langsom oppstart.

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /startup
    port: 80
  failureThreshold: 30
  periodSeconds: 10  # Allow 300s for slow startup

Ressursforespørsler og -grenser

Hver container i Kubernetes bør deklarere ressursforespørsler (den minste garanterte tildelingen som planleggeren bruker) og grenser (det maksimalt tillatte, utover dette blir containeren strupet eller avsluttet). CPU-forespørsler angis i millicores (m) — 1000m = 1 CPU-kjerne. Nøyaktig angivelse av forespørsler og grenser hindrer problemer med støyende naboer og gjør det mulig for planleggeren å pakke pods effektivt på noder uten å overbooke ressurser.

resources:
  requests:
    cpu: '250m'      # 0.25 CPU core guaranteed
    memory: '256Mi'  # 256 MiB guaranteed
  limits:
    cpu: '1'         # Max 1 CPU core
    memory: '512Mi'  # Max 512 MiB (OOMKilled if exceeded)

Hurtigsjekk

Test forståelsen Deres av konseptene i Microsoft Azure Fundamentals (AZ-900) fra denne leksjonen.

Besvar den i den interaktive leksjonen

Oppsummering av leksjonen

I denne leksjonen lærte De at pods er de minste enhetene som kan distribueres, og som deler nettverk og lagring, at Deployments administrerer tilstandsløse replikasett med støtte for fortløpende oppdateringer, og at Services tilbyr stabile endepunkter som lastbalanserer trafikk på tvers av midlertidige pods. Neste steg er å utforske hvordan arbeidsbelastninger distribueres på AKS.

Gratis å komme i gang

Lær deg Azure Fundamentals med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 30
Leksjoner: 120

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Kubernetes-konsepter for Azure» gratis?

Ja – hele teksten i «Kubernetes-konsepter for Azure» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Azure Fundamentals-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Azure Fundamentals inneholder totalt 4 leksjoner.

Hva lærer jeg i «Kubernetes-konsepter for Azure»?

Gå gjennom sentrale Kubernetes-konstruksjoner — pods, deployments, services og namespaces — og forstå hvordan AKS administrerer kontrollplanet på dine vegne. Du øver på Azure Fundamentals med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Azure Fundamentals?

Ingen tidligere erfaring er nødvendig. Azure Fundamentals på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.

Hvor lang tid tar leksjonen «Kubernetes-konsepter for Azure»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Azure Fundamentals-leksjonen?

Ja. Alle Azure Fundamentals-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

← Tilbake til Azure Fundamentals