> ## Content Index
> Fetch the complete content index at: https://lsdev.pl/llms.txt
> Use this file to discover other available public pages before exploring further.

# Kubernetes - jak to zrozumieć i użyć w praktyce?
- URL: https://lsdev.pl/posts/kubernetes-krok-po-kroku/
- Published: 2024-02-04T22:51:34.000Z
- Updated: 2024-02-04T22:51:34.000Z
- Author: Dawid Warzocha
- Tags: Kubernetes, docker, Software, DevOps, #Import 2026-08-18 22:07

Jeśli to czytasz, zapewne słyszałeś już termin Kubernetes. Zapewne czytałeś już gdzieś, że jest to narzędzie do orkiestracji kontenerów, że ma jakieś powiązania z Dockerem, że używa się tego w chmurach, że ma super mechanizm automatycznego skalowania i że jest rozwiązaniem na wszelkie zło panujące przy ciągle rosnącym środowisku produkcyjnym. 

Jednocześnie jednak masz świadomość, że nie jest to łatwa technologia, ponieważ prawie wszędzie czytasz, że próg wejścia w tę technologię jest wysoki, a gdy próbujesz ruszyć coś z dokumentacją Kubernetesa, ciężko Ci się zmierzyć z ogromem różnych nowych terminów. 

Na dodatek gdy próbujesz uruchomić środowisko u siebie na komputerze, to ciągle coś nie działa, a oficjalna dokumentacja wydaje Ci się niejasna i zbyt ogólnikowa.

Zgadłem? Jeśli nie to bardzo przepraszam. Ale właściwie dlaczego zakładam, że jesteś taką osobą? Bo w rozmowach o Kubernetesie z innymi, właśnie z takimi osobami najczęściej się spotykałem. W tym artykule chcę udowodnić, że Kubernetes nie jest tak trudny jak się wydaje i można o nim opowiedzieć nieco... prościej.

Żeby jednak nie powtarzać wiedzy i ze względu na to, że Kubernetesa nie warto ruszać jeśli nie słyszałeś nigdy wcześniej o Dockerze, przed dalszą lekturą zalecam się zapoznać z artykułem o tym jak działa sam Docker:

[Docker w praktyce. Dobre praktyki i przydatne poleceniaDocker \[https://www.docker.com/\] jest przydatnym narzędziem służącym do wirtualizacji na poziomie systemu operacyjnego. Oprogramowanie to pozwala na uruchamianie procesów aplikacji w “lekkich” kontenerach odizolowanych od systemu operacyjnego hosta. W pewnym sensie kontenery przypominają maszyny wir…![](https://lsdev.pl/assets/apple-touch-icon.png?v=f1baa8b3e2)lsdev.plŁukasz![](https://lsdev.pl/content/images/2022/05/docker.webp)](https://lsdev.pl/posts/docker-w-praktyce/)

Jeśli przeczytałeś już artykuł powyżej i wiesz już wszystko o Dockerze to w takim razie teraz...

# Zapomnij o Dockerze

Pewnie powiesz: "Zaraz chwila... Ale jak to zapomnij? Pierw kazałeś przeczytać artykuł o Dockerze i teraz mam o nim zapomnieć?".

W sumie tak, no może nie do końca. Ogólnie rzecz biorąc, kilka lat temu Kubernetes korzystał z Dockera. Jednak od wersji 1.24 Kubernetes przestał to robić i oficjalnie już nie wspiera Dockera ([Is Your Cluster Ready for v1.24? | Kubernetes](https://kubernetes.io/blog/2022/03/31/ready-for-dockershim-removal/?ref=lsdev.pl)).

Czemu Kubernetes przestał wspierać Dockera? Bo nie miało to większego sensu. Docker wbrew temu co można przeczytać na niektórych portalach, samemu nie uruchamia kontenerów. Do uruchomienia kontenerów używa innego narzędzia, które nazywa się Containerd ([containerd – An industry-standard container runtime with an emphasis on simplicity, robustness and portability](https://containerd.io/?ref=lsdev.pl)).

Można powiedzieć, że Docker jest nakładką na Containerd, która sprawia, że uruchamianie kontenerów jest szybkie i proste.

Dlatego przed wersją **1.24** Kubernetesa:

**Kubernetes** przekazywał polecenia do **Dockera** \-> **Docker** przekazywał polecenia do **Containerd** \-> **Containerd** operował na kontenerach.

Od wersji **1.24** Kubernetesa:

**Kubernetes** przekazuje polecenia do **Containerd** \-> **Containerd** operuje na kontenerach.

Oczywiście jest to bardzo uproszczony obraz, ale myślę, że wystarczający do tego aby zrozumieć wcześniejsze zależności z *Dockerem*.

## Ale po co mi właściwie Kubernetes?

 Sam Docker został stworzony głównie z myślą o programistach. Aplikacja umieszczona w kontenerze zadziała na każdym komputerze i to jest jedna z mocnych stron tego rozwiązania. Aplikację umieszczoną w Dockerze możemy przekazać innej osobie bez obaw o to, czy dana osoba ma na komputerze zainstalowane odpowiednie zależności, bo wiemy, że wszystko co potrzebne już jest obecne w kontenerze. Mamy więc pewność, że aplikacja zadziała zawsze, na każdym systemie z zainstalowanym jedynie *Dockerem*.

Takie rozwiązanie może wydawać się bardzo kuszące jeżeli chodzi o środowiska produkcyjne. W końcu nie musimy się martwić, czy nasza aplikacja zadziała w tak często stresującym momencie, którym jest wdrażanie aplikacji na produkcję. I co ciekawe *Docker* często jest również właśnie w taki sposób wykorzystywany.

Jednak pomimo tego, że *Docker* wiele spraw ułatwia, w **większym** środowisku produkcyjnym może być problematyczny w utrzymaniu. Żeby jednak lepiej to wyjaśnić, posłużę się przykładem.

## Krótka Historia pewnej aplikacji

Załóżmy, że masz napisaną aplikację, która została umieszczona w kontenerze *Dockerowym*. Coś bardzo prostego, jakaś aplikacja napisana w PHP. Postanawiasz, że kupisz serwer, postawisz na tym jakiegoś *Linuxa*, zainstalujesz *Dockera* i opublikujesz stronę w internecie.

Strona okazuje się sukcesem, klientów przybywa i Twój serwer powoli niedomaga. Decydujesz się na kupno kolejnego serwera, na którym też instalujesz *Dockera*. Na pierwszym serwerze instalujesz usługę load balancer typu *HAproxy*, aby rozłożyć ruch na obu serwerach.

Sukces aplikacji jednak jest tak duży, że z czasem i drugi serwer zaczyna Ci nie wystarczać, dlatego dokładasz kolejne serwery i kolejne... Na każdym instalujesz *Dockera* i swoją aplikację. Każdy serwer dodajesz do backendu w *HAproxy*.

Aż w końcu kiedy dodajesz już 20 serwer uświadamiasz sobie, że trzeba zaktualizować aplikację. Dlatego logujesz się na każdy serwer i uruchamiasz nową wersję aplikacji w *Dockerze*. Żeby klienci nie odczuli zmian, przed aktualizacją każdego z serwerów, po kolei zatrzymujesz na HAproxy ruch do obecnie aktualizowanego serwera.

Niestety, okazuje się, że nowa wersja aplikacji ma błąd i szybko musisz wrócić do poprzedniej wersji. Dlatego znowu logujesz się na każdy serwer i przywracasz poprzednią wersję. 

Żeby temu zaradzić na następny raz automatyzujesz sobie wdrażanie aplikacji pisząc odpowiedni Playbook do Ansible.

 Pewnego dnia z jakiegoś powodu pierwszy serwer, na którym jest *HAproxy*, ulega uszkodzeniu. Aplikacja przestaje działać. Po jakimś czasie udaje Ci się ożywić serwer, ale klienci są niepocieszeni.

Żeby się przed tym uchronić na następny raz, postanawiasz zrobić drugi serwer z HAproxy i tworzysz pływający pomiędzy load balancerami adres IP, aby utrzymać usługę ciągle aktywną nawet w przypadku awarii.

Po tym incydencie napotykasz kolejny problem, szał na Twoją aplikację minął, jest już mniej eksploatowana i serwery się nudzą. Żeby zminimalizować koszty, rezygnujesz z kilku serwerów. Znowu wdrażasz odpowiednie zmiany w konfiguracji tym razem już na dwóch serwerach z HAproxy.

 Po odłączeniu serwerów okazuje się, że jednak źle obliczyłeś obecne zużycie i zrezygnowałeś ze zbyt dużej liczby serwerów, więc znowu dokupujesz kilka serwerów, znowu instalujesz na nich Dockera, wgrywasz aplikację i znowu dodajesz serwery do konfiguracji w *HAproxy*. 

Po jakimś czasie masz pomysł na inną aplikację, którą postanawiasz wrzucić na kilka serwerów jednak szybko okazuje się, że serwery z zainstalowanymi dwoma aplikacjami jednocześnie niedomagają. Postanawiasz więc, że jedna część serwerów będzie obsługiwać jedną aplikację, a druga część drugą aplikację. 

W głowie masz już jednak pomysł na trzecią, niewielką aplikację i żeby sobie ułatwić sprawę, zatrudniasz kolejnych administratorów, żeby wdrożenia robiło kilka osób. 

Niestety przy wdrożeniu trzeciej aplikacji na istniejące już serwery z poprzednimi aplikacjami, zaczynają szwankować dwie pierwsze, ze względu na to, że nowy administrator popełnił przypadkiem jakiś błąd. 

Żeby temu zaradzić, ograniczasz dostęp dla innych administratorów do części serwerów i nowe osoby wykonują wdrożenia tylko na specjalnie wydzielonych do tego celu serwerach.

Podsumujmy. Żeby środowisko oparte o Dockery bez orkiestracji działało bez problemów przy dużej ilości serwerów, zarządzanych przez kilku administratorów, musisz samemu, za pomocą różnych odpowiednich technologii zadbać o:

1. odporność na awarię
2. automatyzację wdrożeń aplikacji ze strategią zachowania 100% dostępności
3. równoważenie ruchu i ewentualną migrację kontenerów
4. monitoring każdego serwera pod względem zużycia zasobów
5. ograniczanie dostępu do serwerów

I oczywiście wszystkie powyższe problemy można rozwiązać na kilka sposobów jednak...

# Czy można prościej?

Oczywiście, i właśnie po to jest Kubernetes. Klaster Kubernetes:

1. Ma wbudowane mechanizmy, które odpowiadają za odporność na awarie (sprzętową jak i również awarię aplikacji w kontenerze)
2. Ma API, dzięki czemu wdrożenie aplikacji jest wykonywane poprzez połączenie do jednego API, które łączy wszystkie serwery połączone w jeden klaster Kubernetesa
3. Ma wbudowane mechnizmy do równoważenia obciążenia i automatycznej migracji kontenerów
4. Ma wbudowany monitoring (w tym monitoring obciążenia) oraz mechanizmy logowania błędów
5. Każde wdrożenie może mieć swoje wydzielone miejsce (namespace), z ograniczonym dostępem oraz zasobami, bez konieczności ograniczania go do konkretnych maszyn

## W porządku, ale jak to działa?

Najczęściej w tym momencie wielu zaczyna tłumaczyć Ci czym są terminy takie jak: pod, service, ingress, deployment, daemonset, replicaset, persistent volume, persistent volume claim, horizontal pod autoscaler i... inne.

Oczywiście warto znać te terminy, jednak uważam, że zaczynanie nauki od studiowania definicji każdego z powyższych elementów, może zniechęcić do dalszego zdobywania wiedzy. Tak naprawdę, aby zrozumieć jak działa *Kubernetes*, najlepiej go po prostu użyć do czegoś prostego w praktyce.

Problem w tym, że jeśli chcemy użyć *Kubernetesa* w praktyce, korzystając z narzędzia **kubectl** i tak potrzebujemy znać powyższe terminy. 

![](https://lsdev.pl/content/images/2024/02/meme-4.webp)

Poza tym, tworzenie nowych wdrożeń w *Kubernetesie*, zwykle wiąże się z pisaniem tak zwanych manifestów, czyli zestawu poleceń, które Kubernetes ma dla nas wykonać co dla niektórych może wydawać się ścianą nie do przeskoczenia.

Dlatego, żeby było prościej, posłużymy się czytelnym i łatwym w obsłudze **Rancherem**.

## Czym jest Rancher?

Krótko mówiąc jest to bardzo zaawansowany i popularny panel do zarządzania klastrami *Kubernetesa*. 

![](https://lsdev.pl/content/images/2023/09/image.png)

Shell uruchomiony w Rancherze do połączenia z Podem zawierającym kontener z Nginxem na Debianie

Z uwagi na bardzo prosty i przejrzysty interfejs, Rancher jest bardzo łatwy w użyciu. Poza tym jest darmowy i co najlepsze, Rancher potrafi napisać manifesty za nas. Użytkownik musi jedynie wpisać odpowiednie dane w bardzo prostym w użyciu formularzu.

Ciekawostką jest to, że Rancher działa w Kubernetesie. Postaram się jednak ułatwić proces instalacji lokalnego klastra Kubernetes oraz Ranchera do minimum.

## Instalacja K3s i Ranchera

Rancher nie należy do najlżejszych, dlatego komputer na którym go uruchomimy, najlepiej żeby miał przynajmniej 16 GB RAM. Osobiście uruchomiłem go bez problemu na Surface Pro 8 na CPU i5 11 generacji od Intela i 16 GB RAM. Nie zalecam instalacji Ranchera w ten sposób przy mniejszej ilości dostępnej pamięci. 

Jednak jeśli twój komputer ma mniejszą ilość pamięci, nadal możesz nauczyć się z tego poradnika jak zainstalować K3S w WSL v2 (i ewentualnie na własną rękę zainstalować coś lżejszego, np. Kubernetes Dashboard). 

Czym jednak jest **K3S**? Jest to lekka ale jednocześnie bardzo potężna dystrybucja Kubernetesa. Jest bardzo prosta w instalacji i świetnie sprawdzi się w ewentualnym wysoko dostępnym środowisku produkcyjnym.

Statystycznie rzecz biorąc, większość osób korzysta z Windowsa, dlatego pokażę, jak zainstalować Ranchera używając:

**Windows -> WSL (z systemem AlmaLinux 9) -> K3S**

WSL (Windows Subsystem for Linux) pozwoli nam na szybką instalację lekkiego Linuxa, na którym będziemy mogli eksperymentować.

Oczywiście nic nie stoi na przeszkodzie, aby uruchomić inną dystrybucję Linuxa na VirtualBoxie, Hyper-V, Proxmoxie czy Vmware, a następnie na niej K3S. Jednak w tym poradniku użyjemy WSL v2 ponieważ wydaje się najwygodniejszą i najszybszą opcją.

Instalację WSL dla Windows 10 i 11 można znaleźć tutaj (będzie to niezbędne aby przejść dalej):

[Install WSLInstall Windows Subsystem for Linux with the command, wsl --install. Use a Bash terminal on your Windows machine run by your preferred Linux distribution - Ubuntu, Debian, SUSE, Kali, Fedora, Pengwin, Alpine, and more are available.![](https://learn.microsoft.com/favicon.ico)Microsoft Learncraigloewen-msft![](https://learn.microsoft.com/en-us/media/open-graph-image.png)](https://learn.microsoft.com/en-us/windows/wsl/install?ref=lsdev.pl)

Jeśli masz już WSL, możemy zainstalować tam Linuxa. Osobiście proponuję AlmaLinux 9, który znajdziesz w Microsoft Store:

![](https://lsdev.pl/content/images/2023/09/image-1.png)

Po zainstalowaniu naszego nowego Linuxa pod WSL, uruchamiamy go i tworzymy nowego użytkownika:

![](https://lsdev.pl/content/images/2023/09/image-25.png)

Domyślnie, Linux uruchomiony w WSL nie obsługuje systemd, które jest potrzebne do instalacji **K3S**. Dlatego, żeby uruchomić systemd, musimy jako root edytować plik **/etc/wsl.conf** i dodać do niego następujące linie:

```bash
[boot]
systemd=true
```

![](https://lsdev.pl/content/images/2023/09/image-38.png)

Żeby powyższa zmiana została zastosowana w Linuxie, musimy go zrestartować. W tym celu zamykamy kartę z naszym Linuxem i otwieramy kartę z PowerShellem w którym uruchamiamy polecenie **wsl --shutdown**:

![](https://lsdev.pl/content/images/2023/09/image-39.png)

To polecenie zamyka wszystkie systemy uruchomione w WSL.

Teraz możemy ponownie uruchomić kartę z AlmaLinuxem i sprawdzić czy systemd działa prawidłowo:

![](https://lsdev.pl/content/images/2023/09/image-40.png)

Kiedy mamy już gotowy system do instalacji Kubernetesa, jako root uruchamiamy polecenie:

```bash
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.26.9+k3s1 sh -s - server --cluster-init
```

![](https://lsdev.pl/content/images/2023/09/image-41.png)

Jak widzimy, skrypt instalacyjny umieścił kilka plików w **/usr/local/bin/**. Dlatego dla ułatwienia dodajemy tę ścieżkę do PATH poleceniem:

```bash
export PATH=$PATH:/usr/local/bin
```

Żeby przy każdym uruchomieniu terminala nie musieć za każdym razem wykonywać tego polecenia, warto dodać je na końcu pliku **/root/.bashrc**. 

Teraz powinniśmy mieć możliwość używania poleceń **kubectl**:

![](https://lsdev.pl/content/images/2023/09/image-42.png)

Nasz w pełni funkcjonalny Kubernetes jest już gotowy. Powyżej widzimy listę **Podów** w **Namespace** o nazwie **kube-system**, odpowiedzialnych za działanie Kubernetesa.

Tutaj możemy się na chwilę zatrzymać aby wytłumaczyć kilka terminów.

**Pody** to w zasadzie kontenery, w których są uruchomione aplikacje. Dlaczego więc nazywa się to **Pod** zamiast po prostu kontener? Przede wszystkim dlatego, że jeden **Pod** może zawierać w sobie więcej niż jeden kontener. Poza tym **Pod** oprócz tego, że zawiera w sobie kontenery, ma również logikę, która na przykład sprawdza czy kontener w **Podzie** jest aktywny. **Pod** pomimo tego że może zawierać kilka kontenerów, zawsze ma jeden adres IP, które kontenery wewnątrz współdzielą. Na powyższym zrzucie ekranu widzimy między innymi uruchomione **Pody**:

- **coredns** \- wewnętrzna usługa DNS służąca do komunikacji pomiędzy **Podami** w sieci Kubernetesa
- **metrics-server** \- serwer metryk zbierający dane o zużyciu CPU i pamięci przez kontenery. Potrzebny do działania polecenia **kubectl top node** czy autoskalowania.
- **traefik** \- krótko mówiąc jest to proxy, które w nomenklaturze Kubernetesa nazywane jest **Ingress Controllerem**. Żeby zrozumieć jak działa posłużmy się przykładem bardzo popularnego serwera WWW, czyli Apache. W Apache tworzymy VirtualHosty (czyli jeszcze inaczej: podpięte domeny w np. cPanel), żeby przekierować użytkownika po wykrytej nazwie domenowej na jakiś plik lub inny serwer. W Kubernetesie tworzymy **Ingressy** aby przekierować użytkownika po wykrytej nazwie domenowej na daną usługę (**Service**), która końcowo, przekieruje nas na jakiś **Pod**.

Z kolei **Namespace** to przestrzeń w której tworzone są Pody. Możemy tworzyć kilka **Namespace'ów**, żeby uporządkować nasze Pody. Poza tym, jeśli chcemy na przykład, komuś udostępnić klaster Kubernetes, możemy ograniczyć dostęp do jednego **Namespace,** w którym ktoś będzie mógł wykonać deploy swojej aplikacji.

Wróćmy jednak do instalacji panelu Rancher. Przed instalacją potrzebujemy przygotować jakąś domenę, którą przekierujemy na IP naszego Linuxa. Żeby jednak poznać IP Linuxa uruchomionego w WSL, potrzebujemy zainstalować pakiet hostname:

![](https://lsdev.pl/content/images/2023/09/image-43.png)

Jak widać powyżej, po zainstalowaniu pakietu hostname i wykonaniu polecenia **hostname -I** możemy zobaczyć adres IP systemu uruchomionego w WSL (adres pierwszy od lewej).

Teraz uruchamiamy w Windowsie uruchamiamy notatnik jako administrator i edytujemy plik **/etc/hosts**

![](https://lsdev.pl/content/images/2023/09/image-44.png)

Po otwarciu tego pliku, dodajemy domenę np. **rancher.local**, którą przekierowujemy na adres IP Linuxa uruchomionego w WSL i zapisujemy plik

![](https://lsdev.pl/content/images/2023/09/image-45.png)

Teraz prawie jesteśmy gotowi do instalacji Ranchera. Prawie ponieważ będziemy potrzebować jeszcze narzędzia **Helm.**

**Helm** jest menedżerem pakietów. Jest to taki trochę yum/dnf/apt/zypper tylko dla Kubernetesa.

Żeby zainstalować **Helma**, wystarczy wykonać polecenie:

```bash
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
```

![](https://lsdev.pl/content/images/2023/09/image-46.png)

Teraz mamy wszystko gotowe do tego, aby zainstalować Ranchera.

Dlatego teraz wykonujemy po kolei poniższe polecenia:

```bash
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

kubectl create namespace cattle-system

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

helm repo add jetstack https://charts.jetstack.io

helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.11.0

helm install rancher rancher-latest/rancher \
  --namespace cattle-system \
  --set hostname=rancher.local \
  --set replicas=1 \
  --set bootstrapPassword=Haslo_do_panelu_rancher
```

Po wykonaniu ostatniego polecenia, powinien przywitać nas następujący komunikat:

![](https://lsdev.pl/content/images/2023/09/image-47.png)

Teraz wykonując polecenie:

```bash
echo https://rancher.local/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')
```

Otrzymamy adres, którym możemy zalogować się do naszego panelu Rancher. Po uruchomieniu tego adresu IP w przeglądarce, powinien ukazać się nam komunikat o nieprawidłowym certyfikacie (który oczywiście pomijamy), a następnie panel Rancher:

![](https://lsdev.pl/content/images/2023/09/image-48.png)

Akceptujemy licencję i przechodzimy dalej.

![](https://lsdev.pl/content/images/2024/02/image.png)

Gotowe! Rancher jest gotowy do zarządzania naszym Kubernetesem.

Teraz klikamy na nazwę naszego klastra (local) i możemy zaczynać naszą zabawę z Kubernetesem.

![](https://lsdev.pl/content/images/2024/02/image-1.png)

##  Tworzymy pierwszy Deployment

Kiedy mamy już postawiony panel Rancher, możemy w prosty sposób spróbować coś umieścić w klastrze Kubernetes. 

Dla przykładu spróbujemy na naszym klastrze Kubernetes uruchomić... **WordPressa**.

Jednak, żeby uruchomić WordPressa, potrzebujemy bazy danych MySQL. Oczywiście moglibyśmy zainstalować MySQL na naszym Linuxie, ale po co skoro w prosty i szybki sposób, możemy uruchomić ją na naszym Kubernetesie.

W tym celu przechodzimy do zakładki **Workloads** \-> **Deployments**, a następnie klikamy **Create**.

W polu **Name** wpisujemy np. **mariadb**, a następnie w polu **Container image** wpisujemy **mariadb**. W polu **Container image** istotne, żebyśmy nie zrobili literówki, ponieważ tutaj decydujemy, jaki obraz ma zostać pobrany.

Przy tym polu warto też dodać, że możemy w nim wpisać nazwę dowolnego kontenera dostępnego w [Docker Hub](https://hub.docker.com/search?q=&ref=lsdev.pl)

Teraz musimy sprawić, aby nasz MySQL był dostępny w sieci klastra Kubernetes. W tym celu w sekcji **Networking** dodajemy **Service** typu **Cluster IP** o nazwie **mariadb**, i **Private Container Port** ustawiamy na **3306**.

![](https://lsdev.pl/content/images/2024/02/image-2.png)

Teraz schodzimy niżej do sekcji **Environment Variables** i dodajemy następujące zmienne typu **Key/Value Pair** (zgodnie z dokumentacją[Docker Hub](https://hub.docker.com/%5F/mariadb?ref=lsdev.pl)):

```bash
MARIADB_RANDOM_ROOT_PASSWORD = 1
MARIADB_USER = wordpress
MARIADB_PASSWORD = password
MARIADB_DATABASE = wordpress
```

Całość będzie wyglądać następująco:

![](https://lsdev.pl/content/images/2024/02/image-3.png)

Po wypełnieniu powyższych pul, klikamy **Create**.

![](https://lsdev.pl/content/images/2024/02/image-4.png)

Jeśli wszystko wypełniliśmy prawidłowo, nasz kontener z MySQL powinien być aktywny.

Jeśli chcemy dla zabawy wejść do utworzonego kontenera, możemy kliknąć 3 kropki po prawej stronie i wybrać **Execute Shell.**

![](https://lsdev.pl/content/images/2024/02/image-5.png)

Domyślny kontener z Mariadb jest uruchomiony na systemie Ubuntu 

Skoro nasza baza danych jest już gotowa, możemy teraz uruchomić naszego WordPressa. Żeby to zrobić, tworzymy kolejny Deployment.

Tym razem w polu **Name** wpisujemy np. **wordpress**, następnie w polu **Container image** wpisujemy **wordpress**.

Następnie w sekcji **Networking** dodajemy **Service** typu **Node Port** o nazwie **wordpress. Private Container Port** ustawiamy na 80, z kolei **Listening Port** ustawiamy na **30001**.

![](https://lsdev.pl/content/images/2024/02/image-6.png)

Teraz schodzimy niżej do sekcji **Environment Variables** i dodajemy następujące zmienne typu **Key/Value Pair**:

```bash
WORDPRESS_DB_HOST = mariadb
WORDPRESS_DB_USER = wordpress
WORDPRESS_DB_PASSWORD = password
WORDPRESS_DB_NAME = wordpress
```

Tutaj warto się zatrzymać przy zmiennej **WORDPRESS\_DB\_HOST**. Tutaj w standardowej instalacji np. na hostingu współdzielonym, podalibyśmy IP lub nazwę domenową serwera MySQL.

Jednak w Kubernetesie, musimy podać nazwę stworzonego **Service**, kierującego na **Pod** z serwerem **MySQL**.W naszym przypadku **Service** nazywa się po prostu **mariadb**. Jednak jeśli nie wiedzielibyśmy jaką nazwę ma nasz **Service**, można to sprawdzićw zakładce **Service Discovery** \-> **Services**

![](https://lsdev.pl/content/images/2024/02/image-12.png)

Całość będzie więc wyglądać następująco:

![](https://lsdev.pl/content/images/2024/02/image-7.png)

Klikamy **Create** i po kilku chwilach powinniśmy zobaczyć taki oto widok:

![](https://lsdev.pl/content/images/2024/02/image-8.png)

W porządku, kontenery działają. Ale co z naszym WordPressem?

Otóż wystawiliśmy go na porcie 30001\. Wchodzimy więc pod adres:

http://rancher.local:30001

Jeśli wszystko zrobiliśmy prawidłowo, powinniśmy ujrzeć instalator Wordpressa:

![](https://lsdev.pl/content/images/2024/02/image-9.png)

Prawda, że to było proste?

No tak, ale co my właściwie zrobiliśmy? 

1. Utworzyliśmy **Deployment**, który utworzył nam **Pod** z kontenerem zwierającym MySQL, oraz **Service** nasłuchujący na porcie 3306 w sieci **klastra Kubernetes** (**Cluster IP**) i kierujący na ten Pod.
2. Utworzyliśmy drugi **Deployment**, który utworzył nam **Pod** z kontenerem zawierającym **WordPressa**, oraz **Service** typu **Node Port** nasłuchujący na zewnątrz na porcie 30001 i kierujący na ten **Pod**.

Gdybym napisałbym to na początku, można by było uznać powyższe słowa za jakąś czarną magię. Jednak użycie odpowiedniego narzędzia potrafi zmienić perspektywę. 

Kiedy mamy już gotowy Deployment z WordPressem, zobaczmy jeszcze jak w bardzo prosty sposób, możemy skalować naszą aplikację.

Żeby to zrobić wystarczy, że w zakładce **Health** klikniemy strzałkę w dół, a następnie klikniemy znak +

![](https://lsdev.pl/content/images/2024/02/image-10.png)

Po kilku chwilach powinien się pojawić kolejny kontener z naszym WordPressem.

Możemy to zobaczyć w zakładce **Workloads** \-> **Pods**

![](https://lsdev.pl/content/images/2024/02/image-11.png)

Teraz ruch na stronie http://rancher.local:30001 będzie rozłożony jednocześnie na dwóch kontenerach. Możesz oczywiście utworzyć więcej Podów, jeśli Twój komputer to udźwignie.

Przy skalowaniu ciekawą rzeczą, która może wydawać się nieintuicyjna jest to, że gdy spróbujesz usunąć dany Pod, zaraz po jego usunięciu na jego miejsce pojawi się drugi. Odpowiada za to tak zwany **ReplicaSet** jednak to już jest materiał na inny artykuł 😊

## Podsumowanie

Jak widzisz, używając odpowiednich narzędzi, utworzenie czegoś w klastrze i zarządzanie klastrem Kubernetes nie musi być trudne. 

Oczywiście to co opisałem wyżej to zaledwie kropla tego, co możemy zrobić w Kubernetesie. Na Kubernetesie złożonym z jednej maszyny, nie możemy w praktyce doświadczyć potęgi tego rozwiązania. Potraktuj jednak ten artykuł jako taki całkowicie podstawowy wstęp do nauki tej technologii. 

Narzędzia takie jak K3S i Rancher skutecznie pozwalają pokonać stromą krzywą uczenia się Kubernetesa, a jednocześnie często są używane w środowiskach produkcyjnych, dlatego na pewno warto je znać.

Na koniec zachęcam Cię do eksperymentowania z Kubernetesem w panelu Rancher i próbowania różnych konfiguracji i obrazów kontenerów. 

Mam nadzieję, że chociaż trochę pomogłem Ci się oswoić z tą technologią oraz oczywiście życzę powodzenia w nauce Kubernetesa 😊