1~
2Jeśli pracujesz w świecie tworzenia oprogramowania, na pewno słyszałeś o Kubernetes. Ale czym dokładnie jest i dlaczego stał się standardem de facto do zarządzania aplikacjami kontenerowymi? Ten przewodnik poprowadzi cię od podstaw do fundamentalnych koncepcji, z praktycznymi przykładami i diagramami, które pomogą ci zrozumieć.
3~
4## Przed Kubernetes: trochę historii
5~
6Aby zrozumieć, dlaczego Kubernetes jest tak rewolucyjny, cofnijmy się o krok.
7~
81.  **Tradycyjne wdrażanie**: Początkowo aplikacje uruchamiano na serwerach fizycznych. To podejście było kosztowne, trudne do skalowania i podatne na konflikty zasobów.
92.  **Wdrażanie zwirtualizowane**: Potem pojawiły się maszyny wirtualne (VM). VM pozwalały na uruchamianie wielu izolowanych aplikacji na tym samym sprzęcie, poprawiając wykorzystanie zasobów i bezpieczeństwo. Jednak każda VM uruchamia cały system operacyjny, zużywając dużo zasobów.
103.  **Wdrażanie kontenerowe**: Kontenery (jak Docker) to kolejna ewolucja. Dzielą ten sam system operacyjny hosta, ale uruchamiają izolowane procesy. Są lekkie, szybko się uruchamiają i są przenośne.
11~
12Kontenery rozwiązały problem przenośności, ale stworzyły inny: jak zarządzać setkami (lub tysiącami) kontenerów w środowisku produkcyjnym? Jak zapewnić, że zawsze działają, mogą się ze sobą komunikować i skalować w zależności od obciążenia?
13~
14Tu wkracza **Kubernetes**.
15~
16## Czym jest Kubernetes?
17~
18Kubernetes (często skracany do **K8s**) to platforma open-source do orkiestracji kontenerów. W prostych słowach, automatyzuje wdrażanie, skalowanie i zarządzanie aplikacjami kontenerowymi. Stworzony przez Google i obecnie utrzymywany przez Cloud Native Computing Foundation (CNCF), Kubernetes stał się podstawowym narzędziem dla każdego, kto pracuje z mikroserwisami na dużą skalę.
19~
20## Architektura klastra Kubernetes
21~
22Środowisko Kubernetes nazywane jest **klastrem**. Klaster składa się ze zbioru maszyn, nazywanych **węzłami** (nodes), które uruchamiają nasze aplikacje. Architektura dzieli się na dwie główne części: Control Plane i 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 to „mózg" klastra. Podejmuje globalne decyzje (takie jak planowanie) oraz wykrywa zdarzenia klastra i na nie reaguje. Jego główne komponenty to:
57~
58-   **API Server (`kube-apiserver`)**: Brama do klastra. Udostępnia API Kubernetes, z którego korzystają użytkownicy (przez `kubectl`), komponenty klastra i zewnętrzne narzędzia do komunikacji.
59-   **etcd**: Spójna i wysoko dostępna baza danych klucz-wartość. Przechowuje wszystkie dane klastra, reprezentujące pożądany i aktualny stan systemu.
60-   **Scheduler (`kube-scheduler`)**: Przydziela nowo utworzone Pods do dostępnych Worker Nodes, uwzględniając wymagania zasobowe, polityki i inne ograniczenia.
61-   **Controller Manager (`kube-controller-manager`)**: Uruchamia kontrolery  -  pętle sterujące, które obserwują stan klastra i pracują, aby doprowadzić go do pożądanego stanu. Na przykład `Node Controller` zarządza węzłami, a `Replication Controller` zapewnia, że działa prawidłowa liczba Pods.
62~
63### Worker Node
64~
65Worker Nodes to maszyny (fizyczne lub wirtualne), na których faktycznie uruchamiane są aplikacje. Każdy węzeł jest zarządzany przez Control Plane i zawiera następujące komponenty:
66~
67-   **Kubelet**: Agent działający na każdym węźle. Zapewnia, że kontenery opisane w Pods działają i są zdrowe.
68-   **Kube-proxy**: Proxy sieciowy zarządzający regułami sieciowymi na węzłach. Umożliwia komunikację sieciową z Pods z sesji sieciowych wewnątrz lub na zewnątrz klastra.
69-   **Container Runtime**: Oprogramowanie odpowiedzialne za uruchamianie kontenerów. Docker jest najbardziej znany, ale Kubernetes obsługuje również inne środowiska uruchomieniowe, takie jak `containerd` i `CRI-O`.
70~
71## Podstawowe obiekty Kubernetes
72~
73W Kubernetes wszystko jest reprezentowane przez **obiekty**. Te obiekty to „zapisy intencji": po utworzeniu obiektu Kubernetes stale pracuje, aby zapewnić, że istnieje i odpowiada pożądanemu stanowi.
74~
75Oto najważniejsze z nich:
76~
77### Pod
78~
79**Pod** to najmniejsza jednostka wykonawcza w Kubernetes. Reprezentuje jeden lub więcej kontenerów uruchamianych razem na tym samym węźle, dzielących zasoby takie jak sieć i pamięć masowa.
80~
81Zazwyczaj uruchamiasz tylko jeden kontener na Pod, ale w zaawansowanych scenariuszach (np. „sidecar containers" do logowania lub monitorowania) może być ich więcej.
82~
83Prawie nigdy nie tworzysz Pods bezpośrednio. Używasz abstrakcji wyższego poziomu, takich jak Deployments.
84~
85### Deployment
86~
87**Deployment** to obiekt, którego będziesz używać najczęściej. Opisuje pożądany stan grupy identycznych Pods. Kontroler Deployment jest odpowiedzialny za:
88~
89-   Tworzenie i zarządzanie **ReplicaSet** (inny obiekt zapewniający, że określona liczba replik Pod zawsze działa).
90-   **Skalowanie** liczby Pods w górę lub w dół.
91-   Zarządzanie **aktualizacjami** aplikacji w kontrolowany sposób (np. *Rolling Update*), bez przestojów.
92~
93Przykładowy plik YAML dla Deployment uruchamiającego 3 repliki serwera NGINX:
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### Service
119~
120Pods w Kubernetes są efemeryczne: mogą być tworzone i niszczone w dowolnym momencie. Każdy Pod ma własny adres IP, ale ten IP nie jest stabilny. Jak więc niezawodnie udostępnić naszą aplikację?
121~
122Za pomocą **Service**. Service to abstrakcja definiująca logiczny zbiór Pods i politykę dostępu do nich. Zapewnia **stabilny punkt dostępu** (wirtualny adres IP i nazwę DNS) dla grupy Pods.
123~
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129~
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135~
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139~
140    Client -- "Request to nginx-service" --> A
141```
142~
143Service używa `selector` opartego na `labels`, aby znaleźć Pods, do których powinien kierować ruch.
144~
145Jak stworzyć Service dla naszego NGINX Deployment:
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Default - exposes the service only within the cluster
161```
162~
163Istnieją różne typy Services:
164- `ClusterIP`: Udostępnia usługę pod wewnętrznym IP klastra (domyślnie).
165- `NodePort`: Udostępnia usługę na statycznym porcie na każdym Worker Node.
166- `LoadBalancer`: Tworzy zewnętrzny load balancer u dostawcy chmury (np. AWS, GCP) i przypisuje publiczny IP do usługi.
167~
168### Ingress
169~
170Service typu `LoadBalancer` jest świetny, ale tworzenie go dla każdej usługi może być kosztowne. Aby udostępnić wiele usług HTTP/HTTPS na zewnątrz, używasz **Ingress**.
171~
172Ingress działa jako „inteligentny router" dla ruchu zewnętrznego. Pozwala definiować reguły routingu na podstawie hosta (np. `api.mysite.com`) lub ścieżki (np. `mysite.com/api`).
173~
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185~
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190~
191Przykład Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### Inne przydatne obiekty
220~
221-   **Namespace**: Pozwala tworzyć „wirtualne klastry" wewnątrz fizycznego klastra. Przydatny do izolowania środowisk (np. `development`, `staging`, `production`) lub zespołów.
222-   **ConfigMap i Secret**: Do zarządzania danymi konfiguracyjnymi i sekretami (jak hasła lub klucze API) oddzielonymi od obrazu kontenera.
223-   **StatefulSet**: Podobny do Deployment, ale specyficzny dla aplikacji stanowych (jak bazy danych) wymagających stabilnych tożsamości sieciowych i trwałej pamięci masowej.
224-   **PersistentVolume (PV) i PersistentVolumeClaim (PVC)**: Do zarządzania trwałą pamięcią masową w klastrze.
225~
226## Podsumowanie
227~
228Kubernetes to niesamowicie potężne narzędzie, ale jego krzywa uczenia się może być stroma. Ten przewodnik tylko zarysował temat, ale mamy nadzieję, że dał ci solidne zrozumienie podstawowych koncepcji.
229~
230**Co teraz?**
231- **Eksperymentuj lokalnie**: Zainstaluj [Minikube](https://minikube.sigs.k8s.io/docs/start/) lub [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/), aby stworzyć klaster Kubernetes na swoim komputerze.
232- **Używaj `kubectl`**: Zapoznaj się z poleceniem `kubectl`, swoim głównym narzędziem do interakcji z klastrem. Spróbuj stworzyć NGINX Deployment i Service z tego artykułu.
233- **Przejrzyj oficjalne tutoriale**: [Dokumentacja Kubernetes](https://kubernetes.io/docs/tutorials/) to fantastyczne źródło pełne przykładów.
234~
235Orkiestracja kontenerów to fundamentalna umiejętność w świecie cloud-native, a opanowanie Kubernetes otworzy przed tobą świat możliwości. Baw się dobrze!
236~