0Pricing
Azure Fundamentals · Lekcja

Podstawy Kubernetes na platformie Azure

Powtórz podstawowe konstrukcje Kubernetes — pody, wdrożenia, usługi i przestrzenie nazw — oraz dowiedz się, jak AKS zarządza płaszczyzną sterowania w Państwa imieniu.

Podstawy Kubernetes na platformie Azure to bezpłatna lekcja Azure Fundamentals na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Azure Fundamentals, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Czym jest Kubernetes?

Kubernetes (K8s) to platforma open source do orkiestracji kontenerów, pierwotnie opracowana przez firmę Google. Automatyzuje wdrażanie, skalowanie i zarządzanie skonteneryzowanymi aplikacjami. Zamiast ręcznie uruchamiać kontenery, deklaruje się stan pożądany aplikacji w manifestach YAML, a Kubernetes nieustannie dąży do uzgodnienia stanu rzeczywistego ze stanem pożądanym — uruchamia ponownie kontenery, które uległy awarii, planuje obciążenia na zdrowych węzłach i skaluje repliki.

Architektura klastra: płaszczyzna sterowania i węzły

Klaster Kubernetes składa się z płaszczyzny sterowania i węzłów roboczych. Płaszczyzna sterowania zawiera serwer API (punkt wejścia dla wszystkich poleceń kubectl), etcd (rozproszony magazyn stanu), harmonogram (przypisujący pody do węzłów) oraz menedżera kontrolerów (utrzymującego stan pożądany). Na węzłach roboczych działają kubelet (agent węzła), kube-proxy (reguły sieciowe) i środowisko uruchomieniowe kontenerów (containerd). W AKS firma Microsoft zarządza płaszczyzną sterowania — użytkownik zarządza tylko węzłami roboczymi.

# 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)

Pody: najmniejsza jednostka możliwa do wdrożenia

Pod to najmniejsza jednostka możliwa do wdrożenia w Kubernetes. Pod obejmuje jeden lub więcej kontenerów współdzielących przestrzeń nazw sieci (ten sam adres IP), woluminy magazynu i cykl życia. Kontenery w podzie komunikują się za pośrednictwem localhost. Pody są efemeryczne — gdy ulegną awarii, są zastępowane nowymi podami z innymi adresami IP. Zwykle nie tworzy się podów bezpośrednio, lecz zasoby wyższego poziomu, które nimi zarządzają.

# 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'

Deploymenty: zarządzanie zestawami replik

Deployment to standardowy sposób uruchamiania bezstanowych aplikacji w Kubernetes. Tworzy on obiekt ReplicaSet i zarządza nim, utrzymując żądaną liczbę identycznych replik podów. Deploymenty obsługują aktualizacje kroczące — stopniowo zastępują stare pody nowymi — oraz wycofywanie zmian do wcześniejszych wersji. Użytkownik opisuje żądany szablon poda i liczbę replik, a Kubernetes zajmuje się resztą.

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

Usługi: stabilne punkty końcowe sieci

Ponieważ pody są efemeryczne, a ich adresy IP się zmieniają, usługi zapewniają stabilny punkt końcowy sieci, który równoważy ruch między pasującymi podami. Usługa używa selektora etykiet do wyszukiwania podów. Typy usług: ClusterIP (tylko wewnętrzna, domyślna), NodePort (udostępnia port na każdym węźle), LoadBalancer (aprowizuje usługę Azure Load Balancer z publicznym adresem IP) oraz ExternalName (alias DNS prowadzący do usługi zewnętrznej).

# 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

Przestrzenie nazw dla obsługi wielu dzierżawców

Przestrzenie nazw dzielą pojedynczy klaster Kubernetes na wiele klastrów wirtualnych. Zasoby w różnych przestrzeniach nazw są od siebie odizolowane pod względem nazw — można jednocześnie mieć obiekt myapp typu Deployment w przestrzeniach nazw development i production. Przestrzenie nazw są podstawową jednostką stosowania RBAC, limitów zasobów i zasad sieciowych wobec zespołu lub środowiska. Domyślne przestrzenie nazw to między innymi default, kube-system i 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 i Secrets

ConfigMaps przechowują niesensytywne dane konfiguracyjne w postaci par klucz–wartość lub plików, wstrzykiwane do podów jako zmienne środowiskowe albo montowane jako woluminy. Secrets przechowują dane wrażliwe (hasła, tokeny) zakodowane w formacie base64 (domyślnie nie są szyfrowane — aby zapewnić prawdziwe szyfrowanie danych w spoczynku, należy użyć Azure Key Vault Provider for Secrets Store CSI Driver). Oba zasoby są ograniczone do przestrzeni nazw, a w specyfikacjach podów odwołuje się do nich po nazwie.

# 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

Woluminy trwałe na platformie Azure

Aplikacje stanowe potrzebują magazynu, który wykracza poza cykl życia pojedynczych podów. Kubernetes używa obiektów PersistentVolumes (PVs) i PersistentVolumeClaims (PVCs), aby oddzielić magazyn od cyklu życia poda. W AKS wbudowane klasy magazynu Azure Disk i Azure Files automatycznie aprowizują zarządzane dyski i udziały plików po utworzeniu obiektu PVC. Azure Disk jest przeznaczony do dostępu z jednego poda, natomiast Azure Files umożliwia jednoczesny odczyt i zapis przez wiele podów.

# 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) automatycznie dostosowuje liczbę replik podów w obiekcie Deployment na podstawie obserwowanego wykorzystania CPU lub pamięci albo niestandardowych metryk. Kontroler HPA odpytuje serwer metryk co 15 sekund i zwiększa lub zmniejsza liczbę replik, aby utrzymać wykorzystanie w pobliżu wartości docelowej. Ustawienie minimalnej i maksymalnej liczby replik zapewnia bezpieczne wartości graniczne, które zapobiegają niekontrolowanemu skalowaniu.

# 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

Kontrole kondycji: sondy liveness i readiness

Kubernetes używa sond do monitorowania kondycji kontenerów. Sonda liveness sprawdza, czy kontener nadal działa — jeśli się nie powiedzie, Kubernetes uruchamia kontener ponownie. Sonda readiness sprawdza, czy kontener jest gotowy do obsługi ruchu — jeśli się nie powiedzie, pod zostaje usunięty z równoważenia obciążenia usługi, ale nie jest uruchamiany ponownie. Sonda startup opóźnia działanie pozostałych sond do czasu zainicjowania aplikacji, zapobiegając przedwczesnym ponownym uruchomieniom podczas powolnego startu.

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

Żądania i limity zasobów

Każdy kontener w Kubernetes powinien deklarować żądania zasobów (minimalny gwarantowany przydział używany przez harmonogram) oraz limity (maksymalny dozwolony przydział, po którego przekroczeniu kontener jest ograniczany lub zabijany). Żądania CPU wyraża się w milicore’ach (m) — 1000m = 1 rdzeń CPU. Dokładne ustawienie żądań i limitów zapobiega problemom z sąsiadem zużywającym nadmierne zasoby i umożliwia harmonogramowi efektywne rozmieszczanie podów na węzłach bez nadmiernego przydzielania zasobów.

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)

Szybki test

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) przedstawionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji nauczyłeś się, że: pody są najmniejszymi jednostkami możliwymi do wdrożenia, współdzielącymi sieć i pamięć masową; obiekty Deployment zarządzają bezstanowymi zestawami replik i obsługują aktualizacje kroczące; a obiekty Service zapewniają stabilne punkty końcowe i równoważą ruch między efemerycznymi podami. W następnej części omówimy wdrażanie obciążeń w AKS.

Często zadawane pytania

Czy lekcja „Podstawy Kubernetes na platformie Azure” jest bezpłatna?

Tak — pełny tekst „Podstawy Kubernetes na platformie Azure” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Azure Fundamentals, przejdź na CoddyKit PRO. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Co nauczysz się w „Podstawy Kubernetes na platformie Azure”?

Powtórz podstawowe konstrukcje Kubernetes — pody, wdrożenia, usługi i przestrzenie nazw — oraz dowiedz się, jak AKS zarządza płaszczyzną sterowania w Państwa imieniu. Ćwiczysz Azure Fundamentals z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Azure Fundamentals?

Nie wymagamy żadnego doświadczenia. Azure Fundamentals w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Podstawy Kubernetes na platformie Azure”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Azure Fundamentals?

Tak. Każda lekcja Azure Fundamentals zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Azure Container Registry
  2. Azure Container Instances
  3. Podstawy Kubernetes na platformie Azure
  4. Wdrażanie obciążeń w AKS
← Powrót do Azure Fundamentals