Jak stworzyć odporny na awarie klaster Kubernetes…

Aby utworzyć odporny na awarie klaster Kubernetes, konieczne jest zapewnienie nadmiarowości kluczowych komponentów i danych.

Główne kroki:

Węzły główne:
- Rozmieszczanie kilku węzłów głównych (minimum trzy) dla komponentu kube-apiserver, działających za load balancerem. Zapewnia to dostępność API nawet w przypadku awarii jednego z węzłów głównych.
- Każdy węzeł główny musi mieć dostęp do wspólnego magazynu stanu klastra — etcd.
etcd:
- Rozmieszczanie klastra etcd z wieloma węzłami (zaleca się nieparzystą liczbę, minimum trzy), rozproszonymi w różnych strefach dostępności lub na różnych serwerach fizycznych. Gwarantuje to integralność danych stanu klastra.
Load balancer:
- Użycie load balancera L4/L7 do rozkładania ruchu pomiędzy węzłami głównymi (kube-apiserver).
- Użycie innego load balancera do ruchu przychodzącego do aplikacji w klastrze (np. kontroler Ingress z obsługą wysokiej dostępności).
Węzły robocze:
- Rozmieszczanie odpowiedniej liczby węzłów roboczych do uruchamiania Podów.
- Rozproszenie węzłów roboczych w różnych strefach dostępności lub na różnych serwerach fizycznych, aby zapewnić odporność na awarie na poziomie infrastruktury.
- Konfiguracja Pod Disruption Budgets (PDBs) do określenia minimalnej liczby dostępnych Podów podczas dobrowolnych przerw (np. podczas aktualizacji węzłów).
Magazyn:
- Użycie rozproszonego magazynu lub chmury z własną wysoką dostępnością dla Persistent Volumes.
- Przykłady: Rook (Ceph), GlusterFS, dostawcy chmury (AWS EBS, GCP Persistent Disk, Azure Managed Disks) z replikacją.
Sieć:
- Użycie niezawodnego rozwiązania sieciowego CNI (Container Network Interface) z obsługą wysokiej dostępności (np. Calico, Cilium z replikowanymi komponentami).
- Zapewnienie łączności pomiędzy węzłami głównymi, węzłami etcd i węzłami roboczymi.
Kopie zapasowe:
- Regularne tworzenie kopii zapasowych danych etcd.
- Użycie narzędzi takich jak Velero do tworzenia kopii zapasowych i przywracania stanu klastra i Persistent Volumes.

Przykład architektury:

graph LR
    subgraph Użytkownicy
        A[Użytkownik] --> B(Load balancer aplikacji)
    end

    subgraph Klaster Kubernetes
        subgraph Węzły główne
            C1(Węzeł główny 1)
            C2(Węzeł główny 2)
            C3(Węzeł główny 3)
        end

        subgraph Klaster etcd
            D1(etcd 1)
            D2(etcd 2)
            D3(etcd 3)
        end

        subgraph Węzły robocze
            E1(Węzeł roboczy 1)
            E2(Węzeł roboczy 2)
            E3(Węzeł roboczy 3)
        end

        subgraph Magazyn
            F(Rozproszony magazyn)
        end

        subgraph Sieć
            G(Interfejs sieci CNI)
        end

        B --> LoadBalancer(Bilansowanie API serwera)
        LoadBalancer --> C1
        LoadBalancer --> C2
        LoadBalancer --> C3

        C1 <--> D1
        C1 <--> D2
        C1 <--> D3
        C2 <--> D1
        C2 <--> D2
        C2 <--> D3
        C3 <--> D1
        C3 <--> D2
        C3 <--> D3

        C1 --> G
        C2 --> G
        C3 --> G

        E1 <--> G
        E2 <--> G
        E3 <--> G

        E1 <--> F
        E2 <--> F
        E3 <--> F

        G --> E1: Deployment Podów
        G --> E2: Deployment Podów
        G --> E3: Deployment Podów

        E1 --> B: Ruch aplikacji
        E2 --> B: Ruch aplikacji
        E3 --> B: Ruch aplikacji
    end

Podczas wdrażania używa się narzędzi automatyzacji takich jak kubeadm, Kubespray lub zarządzane usługi Kubernetes w chmurze (EKS, GKE, AKS), które upraszczają tworzenie infrastruktury odpornej na awarie.

Jak stworzyć odporny na awarie klaster Kubernetes?