Kubernetes

Architektura rozwiązania
Tags:

  5 minute read  

Wdrożenie klastra Kubernetes zostanie zrealizowane na infrastrukturze Proxmox z uwzględnieniem wysokiej dostępności warstwy sieciowej, control-plane oraz storage. Architektura została podzielona na warstwy funkcjonalne: load balancing, control-plane, worker nodes, storage, ingress, sieć, monitoring, logowanie oraz procesy backup/DR. Poniższy opis stanowi kompletny model docelowy dla środowiska.

// to do cert menager, sprzęg z vault

//

flowchart LR
 subgraph External["External"]
        U["Users"]
  end
 subgraph LB["HA Layer"]
        VIP[("VIP 80 443 6443")]
        HA1["HAProxy 1"]
        HA2["HAProxy 2"]
        HA3["HAProxy 3"]
  end
 subgraph CP["Control Plane"]
        M1["Master 1"]
        M2["Master 2"]
        M3["Master 3"]
  end
 subgraph WK["Worker Nodes"]
        W1["Worker 1"]
        W2["Worker 2"]
        W3["Worker 3"]
        W4["Worker 4"]
        W5["Worker 5"]
        W6["Worker 6"]
  end
 subgraph ING["Ingress Layer"]
        T["Traefik"]
  end
 subgraph SYS["System Components"]
        Mon["Monitoring Stack"]
        Logs["Logging Stack"]
  end
 subgraph K8S["Kubernetes Cluster"]
    direction TB
        CP
        WK
        ING
        SYS
  end
 subgraph STORAGE["NFS Storage"]
        NFSProd[("NFS Export Prod")]
        NFSNonProd[("NFS Export NonProd")]
        NFSProv["NFS Provisioner"]
  end
    U --> VIP
    VIP --> HA1 & HA2 & HA3
    HA1 -- 80 443 --> T
    HA1 -- 6443 --> M1
    HA2 -- 80 443 --> T
    HA2 -- 6443 --> M2
    HA3 -- 80 443 --> T
    HA3 -- 6443 --> M3
    T --> W1 & W2 & W3 & W4 & W5 & W6
    NFSProd --> NFSProv
    NFSNonProd --> NFSProv
    NFSProv --> W1 & W2 & W3 & W4 & W5 & W6
    M1 --> Mon & Logs
    M2 --> Mon & Logs
    M3 --> Mon & Logs
    W1 --> Mon & Logs
    W2 --> Mon & Logs
    W3 --> Mon & Logs
    W4 --> Mon & Logs
    W5 --> Mon & Logs
    W6 --> Mon & Logs

    style CP fill:#FFF9C4,color:#000000
    style WK fill:#BBDEFB,color:#000000
    style ING fill:#C8E6C9,color:#000000
    style SYS fill:#E1BEE7,color:#000000
    style STORAGE fill:#FFCDD2,color:#000000
    style CP fill:#FFF9C4,color:#000000
    style WK fill:#BBDEFB,color:#000000
    style ING fill:#C8E6C9,color:#000000
    style SYS fill:#E1BEE7,color:#000000
    style STORAGE fill:#FFCDD2,color:#000000
flowchart LR
    U[Users]

    subgraph LB[HAProxy layer]
        VIP[(VIP)]
        HA1[HAProxy_1]
        HA2[HAProxy_2]
        HA3[HAProxy_3]
    end

    subgraph K8S[Kubernetes_cluster]
        subgraph CP[Control_plane]
            M1[Master_1]
            M2[Master_2]
            M3[Master_3]
        end

        subgraph WK[Worker_nodes]
            W1[Worker_1]
            W2[Worker_2]
            W3[Worker_3]
            W4[Worker_4]
            W5[Worker_5]
            W6[Worker_6]
        end

        T[Traefik_ingress]
    end

    subgraph STORAGE[NFS_server]
        NFS1[NFS_exports]
    end

    subgraph VAULT[Vault_cluster]
        V1[Vault_1]
        V2[Vault_2]
        V3[Vault_3]
    end

    U --> VIP
    VIP --> HA1
    VIP --> HA2
    VIP --> HA3

    VIP --> M1
    VIP --> M2
    VIP --> M3

    HA1 --> T
    HA2 --> T
    HA3 --> T

    T --> W1
    T --> W2
    T --> W3
    T --> W4
    T --> W5
    T --> W6

    W1 --> NFS1
    W2 --> NFS1
    W3 --> NFS1
    W4 --> NFS1
    W5 --> NFS1
    W6 --> NFS1

    W1 --> V1
    W2 --> V1
    W3 --> V2
    W4 --> V2
    W5 --> V3
    W6 --> V3

Warstwa Load Balancing – HAProxy

Warstwa wejściowa systemu składa się z trzech instancji HAProxy uruchomionych jako maszyny wirtualne, każda na innym węźle Proxmox. HAProxy pełni dwie kluczowe funkcje:

1.1. Balansowanie ruchu do API Kubernetes

  • Wszyscy klienci oraz komponenty klastra łączą się z jednym adresem wirtualnym (VIP) obsługiwanym przez HAProxy.
  • VIP jest utrzymywany mechanizmem VRRP (keepalived).
  • HAProxy kieruje ruch na port 6443 do trzech masternodów.

1.2. Balansowanie ruchu HTTP/HTTPS aplikacji

  • Ruch użytkowników trafia do HAProxy, które przekazuje go do Ingress Controllerów (Traefik) działających w klastrze.
  • HAProxy pracuje w trybie L4 (TCP passthrough) dla TLS lub L7 dla terminacji TLS – w zależności od scenariusza.

Takie podejście zapewnia wysoki poziom redundancji oraz izolację ruchu przychodzącego.

2. Warstwa Control-Plane – 3× Master

Klaster Kubernetes wykorzystuje trzy węzły master, każdy ulokowany na osobnym węźle fizycznym Proxmox. Zastosowany model zapewnia:

  • pełne HA etcd (quorum 3/3),
  • odporność na awarię jednego węzła Proxmox,
  • stabilność kontrolera i procesów zarządzających klastrem.

Węzły master pełnią wyłącznie funkcję control-plane (bez uruchamiania workloadów), co zmniejsza ryzyko interferencji oraz upraszcza utrzymanie.

3. Warstwa Worker – 6× Worker Nodes

Warstwa obliczeniowa klastra składa się z sześciu nodów worker, rozmieszczonych równomiernie na węzłach Proxmox. Założenia:

  • nody worker służą do uruchamiania wszystkich aplikacji oraz komponentów systemowych (np. Traefik, Promtail),
  • zastosowane będą dedykowane labels/taints dla logicznych podziałów środowisk oraz typów workloadów.

Układ 6 nodów zapewnia elastyczne skalowanie oraz podział obciążeń.

4. Warstwa Storage – NFS z wieloma eksportami

Jako główna warstwa storage wykorzystany zostanie serwer NFS. Architektura przewiduje kilka eksportów, co umożliwia segregację środowisk oraz lepszą kontrolę nad backupami:

  • /srv/nfs/k8s-prod – dane środowiska produkcyjnego,
  • /srv/nfs/k8s-nonprod – dane środowisk deweloperskich i testowych.

W klastrze zastosowany zostanie NFS Subdir External Provisioner, tworzący dynamiczne katalogi per PVC. Dla środowiska przewidziane są oddzielne StorageClass:

  • nfs-prod
  • nfs-nonprod

Takie podejście zapewnia prosty, stabilny i łatwy do zarządzania system storage.

5. Sieć klastra (CNI) – Calico

W warstwie sieciowej klaster wykorzystuje Calico jako Container Network Interface. Calico zapewnia:

  • routing między pods i node’ami,
  • wsparcie dla NetworkPolicies,
  • wysoką wydajność i stabilność.

Cała komunikacja między node’ami (masters, workers, HAProxy, NFS) odbywa się w jednej sieci L2 Proxmox, co znacząco upraszcza zarządzanie.

6. Warstwa Ingress – Traefik

Klaster wykorzystuje Traefik jako Ingress Controller. Decyzja wynika m.in. z chęci wykorzystania nowoczesnego narzędzia i możliwości rozbudowy o middleware, automatyczne certyfikaty, routing oparty o CRD oraz integrację z HAProxy.

Architektura ruchu:

  1. Klient → HAProxy (VIP)
  2. HAProxy → Traefik (NodePort)
  3. Traefik → Service → Pod

Traefik odpowiada za routing HTTP/HTTPS, rewrites, TLS oraz polityki ruchu.

7. Obserwowalność – lekkie komponenty

7.1. Monitoring

Zastosowane zostaną lekkie komponenty:

  • Prometheus (pojedyncza instancja),
  • kube-state-metrics,
  • metrics-server,
  • Grafana (wizualizacja metryk).

Model ten jest wystarczający dla środowiska opartego o Proxmox i ma ograniczone zużycie zasobów.

7.2. Logowanie

Zestaw logowania oparty na:

  • Loki (storage logów),
  • Promtail (agent logujący na nodach).

Logi aplikacyjne będą dostępne w Grafanie.

8. Backup / Disaster Recovery

Model DR zakłada pełne podejście Infrastructure as Code (IaC):

  1. Cała infrastruktura (VM-ki Proxmox, konfiguracje sieci) – Terraform.
  2. Konfiguracja systemowa VM (kubelet, containerd, pakiety) – Ansible.
  3. Warstwa aplikacyjna K8S (Traefik, monitoring, provisioner NFS, CRD, deployed apps) – Helm/Kustomize w repo Git.

Backup kluczowych elementów:

  • backup eksportów NFS (najważniejsze dane – PV),
  • okresowy backup etcd,
  • przechowywanie manifestów i konfiguracji w repozytoriach Git (GitOps).

Odtworzenie klastra polega na odtworzeniu NFS, ponownym wdrożeniu klastra z IaC oraz podpięciu poprzednich wolumenów.

9. Proces instalacji – kubeadm (bootstrap)

Środowisko jest bootstrappowane narzędziem kubeadm:

  1. kubeadm init na pierwszym masterze z endpointem VIP API (HAProxy).
  2. Dołączenie pozostałych masterów z kubeadm join --control-plane.
  3. Dołączenie workerów.
  4. Instalacja Calico.
  5. Instalacja provisionera NFS.
  6. Instalacja Traefika.
  7. Instalacja komponentów obserwowalności.

Po etapie bootstrapu klaster może być rozbudowywany automatycznie przez IaC.

Podsumowanie

Przedstawiona architektura rozwiązania opiera się na trzech fundamentalnych filarach: wysoka dostępność, prostota operacyjna oraz możliwość rozwoju. Trzy HAProxy, trzy master nodes i sześć worker nodes tworzą stabilną i skalowalną podstawę dla aplikacji kontenerowych. Warstwa storage oparta o NFS jest celowo uproszczona, ale logicznie podzielona tak, aby wspierać porządek środowiskowy i backup. Wszystkie elementy klastra mogą być utrzymywane, odtwarzane i skalowane w podejściu Infrastructure as Code.

Last modified December 19, 2025: docs: Update (72bba37)