00: Kubernetes — przegląd

Kubernetes — przegląd

Zanim zaczniesz ćwiczenia, poznaj ogólny obraz: po co jest Kubernetes, z jakich elementów się składa i jak te elementy współpracują.

Po co Kubernetes?

Wyobraź sobie port kontenerowy. Masz setki kontenerów (aplikacji), które trzeba:

• Rozmieścić na odpowiednich statkach (serwerach)
• Pilnować — jeśli kontener spadnie, ktoś musi go podnieść
• Skalować — w sezonie potrzebujesz więcej kontenerów
• Aktualizować — wymiana towaru bez zamykania portu

Problem: “Mam aplikację w kontenerze Docker. Jak ją uruchomić na wielu maszynach, skalować, aktualizować bez przestoju i automatycznie naprawiać awarie?”

Odpowiedź: Kubernetes (K8s) — orkiestrator kontenerów, który automatyzuje deploy, skalowanie i self-healing.

Architektura klastra

Klaster Kubernetes składa się z dwóch warstw:

graph TB
    subgraph CP["Control Plane (mózg klastra)"]
        API["API Server<br/>Brama wejściowa — każde polecenie przechodzi przez API"]
        ETCD["etcd<br/>Baza danych — przechowuje cały stan klastra"]
        SCHED["Scheduler<br/>Planista — decyduje na którym Node uruchomić Pod"]
        CM["Controller Manager<br/>Nadzorca — pilnuje że stan rzeczywisty = stan pożądany"]
    end

    subgraph W1["Worker Node 1"]
        KL1["kubelet<br/>Agent na Node — uruchamia i monitoruje Pody"]
        KP1["kube-proxy<br/>Sieć — routing ruchu do Podów"]
        CR1["Container Runtime<br/>Silnik kontenerów (containerd)"]
        P1["Pod A"]
        P2["Pod B"]
    end

    subgraph W2["Worker Node 2"]
        KL2["kubelet"]
        KP2["kube-proxy"]
        CR2["Container Runtime"]
        P3["Pod C"]
        P4["Pod D"]
    end

    API <-->|"watch/sync"| ETCD
    API --> SCHED
    API --> CM
    API <-->|"polecenia"| KL1
    API <-->|"polecenia"| KL2
    KL1 --> CR1
    CR1 --> P1
    CR1 --> P2
    KL2 --> CR2
    CR2 --> P3
    CR2 --> P4

Komponenty Control Plane

Komponenty Worker Node

kubectl i kubeconfig

kubectl — narzędzie do zarządzania klastrem

kubectl to CLI (Command Line Interface) do komunikacji z klastrem Kubernetes. Każde polecenie kubectl trafia do API Servera, który je przetwarza i wykonuje.

graph LR
    YOU["Ty<br/>(terminal)"]
    KC["kubectl"]
    API["API Server<br/>(Control Plane)"]

    YOU -->|"kubectl get pods"| KC
    KC -->|"HTTPS"| API
    API -->|"odpowiedź"| KC

    style YOU fill:#e3f2fd
    style KC fill:#fff3e0
    style API fill:#e8f5e9

kubeconfig — plik konfiguracyjny

Skąd kubectl wie, z którym klastrem się połączyć? Z pliku kubeconfig (~/.kube/config). Zawiera on:

# Uproszczony przykład ~/.kube/config
apiVersion: v1
kind: Config
clusters:
- cluster:
    server: https://k8s-training-xyz.hcp.swedencentral.azmk8s.io:443
    certificate-authority-data: LS0tLS1C...   # certyfikat CA
  name: k8s-training
users:
- name: k8s-training-admin
  user:
    token: eyJhbGci...                        # token uwierzytelniający
contexts:
- context:
    cluster: k8s-training
    user: k8s-training-admin
  name: k8s-training
current-context: k8s-training

Ważne: Plik kubeconfig zawiera dane uwierzytelniające — traktuj go jak hasło. Nie udostępniaj publicznie.

Słownik pojęć

Jak elementy się łączą

graph LR
    U["Użytkownik<br/>(przeglądarka)"]
    ING["Ingress<br/>routing HTTP"]
    SVC["Service<br/>stały adres + load balancing"]
    DEP["Deployment<br/>repliki + aktualizacje"]
    POD["Pod"]

    subgraph PODINT["Wnętrze Poda"]
        CONT["Kontener<br/>(aplikacja)"]
        CM["ConfigMap<br/>(konfiguracja)"]
        SEC["Secret<br/>(hasła, certyfikaty)"]
        PROBE["Probes<br/>(health checks)"]
        RES["Resources<br/>(CPU/Memory limits)"]
    end

    U -->|"HTTP request"| ING
    ING -->|"reguły routingu"| SVC
    SVC -->|"selector → Endpoints"| DEP
    DEP -->|"zarządza"| POD
    POD --- PODINT

    style PODINT fill:#f0f4ff,stroke:#4a6fa5

Mapa szkolenia

Szkolenie składa się z 5 modułów i 20 ćwiczeń. Każdy moduł buduje na wiedzy z poprzedniego:

Pełny spis ćwiczeń z linkami znajdziesz na stronie startowej.

Zacznij od ćwiczenia 01 →