Własny klaster Kubernetes

Jakieś 2 lata temu kupiłem używane terminale HP T630. Te komputerki typu thin client masowo pojawiły się na rynku wtórnym za nieduże pieniądze. Kupiłem początkowo jeden celem zrobienia środowiska testowego dla aplikacji .NET w moim domowym labie. Komputerek pobiera <10W, ma pasywne chłodzenie i idealnie się nadaje do pracy 24/7.
Potem zacząłęm myśleć o wystawieniu aplikacji .NET na świat. Mój pakiet hostingowy, z którego serwowany jest ten blog (standardowy hosting na Apache) nie nadaje się do tego. .NET wdrażam na Azure. Darmowy plan nie pozwala na podpięcie własnej domeny, więc adres usługi zdecydowanie nie jest przyjazny, bo wygląda tak https://github-stats-keyvault-demo-e5ewd7f8ezeva2cy.polandcentral-01.azurewebsites.net/. Dla celów laboratoryjnych może być, ale szału nie ma.
Ponieważ mam dobre łącze do Internetu, pomyślałem, że zamiast hostować aplikacje na Azure, zrobię to u siebie. I pod własną domeną. HP 630 nadal były tanie, więc dokupiłem jeszcze 3 i zacząłem kombinować, jak ogarnąć Kubernetes.

Założenia

Brzmi jak plan?
Nie do końca 😉 “Chcieć Kubernetes” to nie to samo co “uruchomić klaster”.
Po małej konwersacji z agentem wykluły się założenia, które przedstawiam poniżej:

Założenia funkcjonalne

  • Klaster K3s HA działa na trzech nodach control plane/etcd, np. k3s-1– k3s-3 pod adresami 192.0.2.11–192.0.2.13. Dostęp do API odbywa się przez VIP 192.0.2.100:6443.
  • Usługi są udostępniane przez Envoy Gateway i Kubernetes Gateway API. Ruch aplikacyjny trafia na VIP 192.0.2.101. Polityki pozwalają skierować ruch z Internetu do klastra, lub dowolnego hosta w LAN.
  • Monitoring klastra zapewniają Prometheus i Grafana, które zbierają metryki z nodów oraz komponentów Kubernetes i udostępniają dashboardy.
  • Konfiguracja aplikacji jest rozdzielona: ustawienia jawne trafiają do ConfigMap, a poufne do Secretów.
  • Adresy usług i dostęp Aplikacje publiczne są dostępne po https: pod nazwami subdomen w domenie, np. myapp.adameczek.pl. Natomiast aplikacje “wewnętrzne” dostępne są po http: pod adresami w rodzaju emailapi.test i grafana.test.

Założenia niefunkcjonalne

  • Dostępność klastra: trzy nody i VIP ograniczają zależność dostępu do API od pojedynczego noda. Nie gwarantuje to jednak wysokiej dostępności każdej aplikacji.
  • Ograniczenie dostępu: polityki bramy dopuszczają ruch z przykładowej sieci LAN 192.0.2.0/24.
  • Kontrola zasobów i danych: monitoring ma określone limity retencji oraz PVC. Dane są przechowywane lokalnie na jednym nodzie, więc jego awaria może zatrzymać monitoring do czasu przywrócenia noda. To założenie ma ograniczyć obciążenie i zajętość dysków.
  • Bezpieczeństwo: HTTPS jest szyfrowany do Gatewaya, gdzie TLS jest terminowany przy użyciu certyfikatu z nowo utworzonego CA. Dalej Gateway przekazuje ruch do usługi w klastrze.

Jeśli kusiło Cię wykonanie tego typu infraskruktury, ale z jakiegoś powodu ciągle to jest przed Tobą, to zapraszam do śledzenia postępów wdrożenia. Ono zakończyło się sukcesem, więc czytając wpisy, wiesz że nie będzie zaskoczenia tylko happy end 🙂 I możesz to zrobić sam(a) korzystając z praktycznych wskazówek.

Plan działania

Instalacja on-prem obejmuje następujące zadania:

  • przygotowanie sprzętu,
  • konfigurację sieci,
  • instalację narzędzi na komputerze administracyjnym,
  • instalację CA,
  • instalację klastra,
  • instalację infrastruktury monitorującej
  • testy po każdym etapie

W założeniu wszystko jest robione skryptami ansible i realizuje zasadę IaC. Dzięki temu później można praktycznie od zera odtworzyć cały system, czyli

  • konfigurację hostów,
  • K3s,
  • token klastra,
  • kube-vip,
  • konfigurację VIP,
  • certyfikaty/endpointy,
  • ewentualnie kolejne komponenty.

Etapy

Prace wykonywane są etapami, a efekt każdego można sprawdzić przed przejściem do kolejnego. Takie podejście ma efekt edukacyjny, bo widać co jest po czym i dlaczego.

Etapów jest 6. Poniżej przedstawiam harmonogram pierwszego z nich. Potem przyjdą kolejne.

Etap I

  • konfigurację hostów,
  • K3s,
  • token klastra,
  • kube-vip,
  • konfigurację VIP,
  • certyfikaty/endpointy,
  • ewentualnie kolejne komponenty.

Architektura

Sam klaster będzie wyglądać tak:

          LAN 192.0.2.0/24
                 │
          192.0.2.151 VIP
                 │
              kube-vip
                 │
       ┌─────────┼──────────┐
       │         │          │
    k3s-1       k3s-2      k3s-3
 192.0.2.11  192.0.2.12  192.0.2.13
       │         │          │
       └─── K3s HA cluster ─┘


API: https://192.0.2.152:6443

To jest pierwszy wpis cyklu. Śledź blog aby poznać kolejne 😄