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

Komponent Rola
API Server Jedyny punkt wejścia — kubectl, UI i inne komponenty komunikują się przez API
etcd Rozproszona baza klucz-wartość przechowująca cały stan klastra
Scheduler Wybiera Node dla nowo utworzonych Podów na podstawie zasobów i ograniczeń
Controller Manager Uruchamia kontrolery pilnujące, że stan klastra odpowiada deklaracji (np. “chcę 3 repliki”)

Komponenty Worker Node

Komponent Rola
kubelet Agent na każdym Node — odbiera polecenia z API Server i zarządza Podami
kube-proxy Zarządza regułami sieciowymi — zapewnia, że ruch trafia do właściwych Podów
Container Runtime Silnik uruchamiający kontenery (np. containerd)

Słownik pojęć

Pojęcie Co to Analogia Ćwiczenie
Pod Najmniejsza jednostka — 1 lub więcej kontenerów Pokój hotelowy (kontenery = goście) 01, 03
Namespace Wirtualny klaster — izolacja zasobów Piętro w hotelu 02
ConfigMap Konfiguracja jako pary klucz-wartość Karteczka z ustawieniami 05
Secret Wrażliwe dane (zakodowane base64) Sejf w pokoju 06
Volume Montowanie plików/katalogów do kontenera Pendrive podpięty do komputera 07
Deployment Zarządza cyklem życia: repliki, aktualizacje, rollbacki, self-healing Kierownik produkcji — pilnuje obsady, wymienia pracowników bez przestoju, cofa zmiany gdy coś nie gra 11-13
Service Stały adres sieciowy do grupy Podów Recepcja hotelowa — nie musisz znać numeru pokoju 14
Ingress Routing HTTP z zewnątrz do Service’ów Portier kierujący gości do odpowiedniego wejścia 18

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 kursu

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

Moduł 1: Pierwsze kroki

Cel: Uruchomić pierwszego Poda i zrozumieć podstawowe komendy

01 Imperatywne zarządzanie Podami — kubectl run, exec, logs, port-forward 02 Namespace’y — izolacja zasobów 03 Pod z YAML — deklaratywne podejście, anatomia manifestu

Moduł 2: Konfiguracja aplikacji

Cel: Oddzielić konfigurację od kodu, zarządzać wrażliwymi danymi

04 Zmienne środowiskowe — env w YAML 05 ConfigMap — konfiguracja jako osobny obiekt 06 Secrets — wrażliwe dane (base64) 07 Wolumeny — montowanie ConfigMap i Secrets jako pliki 08 Secrets TLS — certyfikaty i wiele źródeł

Moduł 3: Niezawodność i Deployments

Cel: Zapewnić stabilność, limity zasobów i automatyczne aktualizacje

09 Resources i QoS — requests, limits, klasy QoS 10 Probes — Liveness i Readiness 11 Deployment — podstawy i skalowanie 12 Deployment z pełną konfiguracją — łączymy wszystko 13 Strategie aktualizacji — Recreate vs RollingUpdate

Moduł 4: Sieć wewnętrzna

Cel: Zrozumieć komunikację między Podami wewnątrz klastra

14 Service ClusterIP — stały adres wewnętrzny 15 DNS — rozwiązywanie nazw w klastrze 16 Readiness Probe a Service — wpływ health checków na routing

Moduł 5: Sieć zewnętrzna

Cel: Udostępnić aplikację światu zewnętrznemu

17 Service LoadBalancer — publiczny dostęp 18 Ingress podstawy — routing HTTP 19 Ingress path-based — routing po ścieżkach URL 20 Ingress URL rewriting — przepisywanie adresów

Zacznij od ćwiczenia 01 →

results matching ""

    No results matching ""