Kubernetes na Proxmox VE – własna platforma aplikacyjna w firmowej infrastrukturze

Spis treści

Czy Kubernetes potrzebuje chmury publicznej?

Dwie warstwy, dwa różne zadania

Schemat warstw architektury

Dlaczego warto rozważyć takie połączenie?

Jak zaprojektować klaster na potrzeby firmy?

Wysoka dostępność: trzy mechanizmy

Od pierwszego klastra do platformy produkcyjnej

Czy sprawdzi się w każdym przedsiębiorstwie?

Podsumowanie

Źródła i dalsza lektura

Czy Kubernetes potrzebuje chmury publicznej?

Kubernetes często kojarzy się z usługami AWS, Azure lub Google Cloud. W praktyce klaster kontenerowy można z powodzeniem uruchomić również we własnym centrum danych. Jednym z interesujących fundamentów takiego środowiska jest Proxmox Virtual Environment (VE) – platforma wirtualizacyjna oparta na technologiach open source.

Połączenie obu rozwiązań pozwala wykorzystać posiadane serwery i storage do budowy środowiska, w którym aplikacje mogą być wdrażane, aktualizowane i skalowane w uporządkowany sposób. Nie oznacza to jednak, że Proxmox zastępuje Kubernetes albo odwrotnie. Te technologie rozwiązują inne problemy i właśnie dlatego mogą się uzupełniać.

Dwie warstwy, dwa różne zadania

Proxmox VE odpowiada za zasoby infrastruktury: fizyczne hosty, maszyny wirtualne, pamięć, sieć oraz magazyny danych. Kubernetes zarządza aplikacjami uruchamianymi w kontenerach: rozmieszcza je na dostępnych węzłach, monitoruje stan i potrafi odtwarzać niezdrowe instancje.

Typowa architektura wygląda następująco:

1. Kilka fizycznych serwerów tworzy klaster Proxmox VE.
2. Na hostach powstają maszyny wirtualne Linux pełniące role węzłów Kubernetes.
3. Węzły control plane zarządzają stanem klastra, a węzły worker wykonują obciążenia aplikacyjne.
4. Aplikacje są publikowane za pośrednictwem odpowiednio skonfigurowanej sieci, kontrolerów Ingress lub Gateway API i mechanizmu udostępniania adresów IP.
5. Trwałe dane aplikacji korzystają ze świadomie dobranego storage, niezależnego od cyklu życia pojedynczego kontenera.

To rozdzielenie daje zespołom IT kontrolę nad infrastrukturą, a zespołom programistycznym – powtarzalny sposób dostarczania aplikacji.

Dlaczego warto rozważyć takie połączenie?

Wykorzystanie istniejących serwerów

Firmy posiadające infrastrukturę Proxmox nie muszą od razu inwestować w osobną platformę sprzętową do konteneryzacji. Węzły Kubernetes mogą działać jako maszyny wirtualne, współdzieląc pulę zasobów z innymi systemami. Należy jednak uwzględnić rezerwę wydajnościową i unikać nadmiernego przydziału zasobów.

Izolacja i łatwiejszy cykl życia węzłów

Maszyny wirtualne pozwalają stosować szablony systemów, automatyzację Cloud-Init i odtwarzalne konfiguracje. Łatwiej również oddzielić środowiska testowe, produkcyjne i deweloperskie. W przypadku wymiany węzła zwykle bardziej przewidywalne jest utworzenie nowej VM i dołączenie jej do klastra niż ręczna naprawa wielokrotnie modyfikowanego systemu.

Możliwość budowy środowiska on-premises i hybrydowego

Lokalny Kubernetes jest szczególnie interesujący tam, gdzie liczą się kontrola nad danymi, integracja z siecią przedsiębiorstwa, niskie opóźnienia do systemów wewnętrznych lub przewidywalne wykorzystanie własnego sprzętu. Nie wyklucza przy tym łączenia z usługami chmurowymi.

Jak zaprojektować klaster na potrzeby firmy?

Przykładowym punktem wyjścia dla środowiska wymagającego wysokiej dostępności są trzy fizyczne hosty Proxmox, na których rozkładamy maszyny wirtualne trzech węzłów control plane i kilku workerów. Nie jest to uniwersalny rozmiar klastra: zapotrzebowanie zależy od aplikacji, liczby użytkowników, wymagań SLA oraz dostępnych zasobów.

Kluczowa jest separacja awarii. Trzy węzły control plane uruchomione na jednym fizycznym serwerze nie zapewnią odporności na awarię tego serwera. Należy także zadbać o stabilny punkt dostępu do Kubernetes API, quorum etcd oraz rozdział maszyn na fizyczne hosty. Oficjalna dokumentacja Kubernetes opisuje zarówno topologię control plane z lokalnym etcd, jak i osobny klaster etcd.

Maszyny wirtualne czy LXC?

Choć Proxmox oferuje również lekkie kontenery LXC, dla typowego produkcyjnego klastra Kubernetes rekomendujemy pełne maszyny wirtualne KVM. Kubernetes i część rozwiązań sieciowych oraz storage wymagają funkcji jądra, uprawnień i interfejsów systemowych, które mogą sprawiać trudności wewnątrz LXC. LXC może być ciekawym rozwiązaniem laboratoryjnym, ale oszczędność zasobów nie powinna odbywać się kosztem przewidywalności operacyjnej.

Sieć to nie tylko adres IP maszyny

Plan sieciowy powinien rozróżniać ruch zarządzania Proxmox, ruch pomiędzy węzłami Kubernetes, komunikację pomiędzy Podami, publikację usług oraz ruch do storage. W zależności od skali warto zastosować VLAN-y, dedykowane interfejsy lub logiczną segmentację. Konieczny jest także wybór CNI, np. Cilium lub Calico, oraz metody udostępniania usług typu LoadBalancer w środowisku bez zarządzanej chmury, np. MetalLB – zgodnie z ograniczeniami danej sieci.

Przed wdrożeniem należy sprawdzić MTU, routing, DNS, reguły firewalla oraz zakresy adresów Podów i usług, aby nie kolidowały z istniejącymi podsieciami przedsiębiorstwa.

Storage – najważniejsza decyzja dla aplikacji stanowych

Kontenery są z założenia łatwe do zastępowania, ale bazy danych, repozytoria i systemy plików potrzebują trwałych wolumenów. W środowisku Proxmox jedną z możliwości jest Ceph i odpowiedni sterownik CSI, przez który Kubernetes może udostępniać wolumeny aplikacjom. Alternatywy obejmują zewnętrzne systemy storage i inne zgodne sterowniki CSI.

Należy dokładnie zaprojektować granicę odpowiedzialności między storage wykorzystywanym przez Proxmox na potrzeby dysków VM a storage aplikacyjnym Kubernetes. Nie należy zakładać, że sama obecność Ceph automatycznie daje gotowe, poprawnie skonfigurowane PersistentVolumes. Osobno trzeba ustalić zasady kopii zapasowych, spójności baz danych i odtwarzania po awarii.

Wysoka dostępność: trzy mechanizmy, których nie należy mylić

W tej architekturze działają różne poziomy odporności:

• HA Proxmox może wznowić maszynę wirtualną na innym hoście, gdy spełnione są wymagania klastra i storage. Nie zastępuje to mechanizmów aplikacyjnych.
• HA Kubernetes utrzymuje żądaną liczbę replik i rozmieszcza Pody na dostępnych workerach, jeśli aplikacja oraz klaster są do tego przygotowane.
• Backup i disaster recovery umożliwiają odzyskanie danych i konfiguracji po błędach, utracie danych lub większej awarii. Ani HA, ani repliki nie są zamiennikiem backupu.

Zbyt wiele mechanizmów automatycznego restartu na różnych warstwach może utrudnić diagnozę. W praktyce warto określić, czy w danym scenariuszu VM ma być automatycznie odtwarzana przez Proxmox, czy aplikacja przenoszona przez Kubernetes – i przetestować zachowanie przy awarii hosta, VM, workera i storage.

HA Proxmox, HA Kubernetes i backup rozwiązują inne problemy. Ich pomylenie prowadzi do złudnego poczucia bezpieczeństwa.

Od pierwszego klastra do platformy produkcyjnej

Rozsądny projekt przebiega etapami:

1. Pilotaż. Utworzenie izolowanego środowiska, kilku VM oraz niewielkiego klastra Kubernetes, np. z kubeadm lub dystrybucją K3s.
2. Automatyzacja. Przygotowanie szablonów VM, Cloud-Init, infrastruktury jako kodu i deklaratywnej konfiguracji aplikacji.
3. Usługi platformowe. Konfiguracja CNI, DNS, ingress lub Gateway API, certyfikatów TLS, storage CSI, rejestru obrazów i zarządzania sekretami.
4. Odporność i bezpieczeństwo. Test awarii, polityki dostępu RBAC, segmentacja ruchu, aktualizacje, skanowanie obrazów oraz backup etcd i danych aplikacyjnych.
5. Eksploatacja. Monitoring Proxmox i Kubernetes, centralizacja logów, alertowanie, plan aktualizacji oraz testy odtwarzania.

Dopiero po przejściu tych etapów warto traktować środowisko jako platformę dla istotnych usług biznesowych.

Czy Kubernetes na Proxmox sprawdzi się w każdym przedsiębiorstwie?

Nie zawsze. Dla kilku prostych aplikacji działających na jednym serwerze zestaw VM i Docker Compose może być łatwiejszy w utrzymaniu. Kubernetes wnosi największą wartość, gdy aplikacji jest wiele, są regularnie wdrażane, wymagają automatycznego skalowania lub odporności na awarie i korzystają ze wspólnych standardów operacyjnych.

Trzeba też pamiętać o koszcie kompetencji. Kubernetes nie usuwa konieczności zarządzania siecią, bezpieczeństwem i danymi – dodaje własną warstwę, którą należy monitorować i aktualizować. Wysoka dostępność wymaga realnej redundancji sprzętowej, sieciowej i storage, a nie tylko odpowiedniej liczby maszyn wirtualnych.

Podsumowanie

Proxmox VE i Kubernetes tworzą interesującą podstawę nowoczesnej, lokalnej platformy aplikacyjnej. Proxmox zapewnia elastyczne środowisko wirtualne, a Kubernetes automatyzuje działanie kontenerów. Najlepsze rezultaty przynosi jednak nie sama instalacja klastra, lecz prawidłowy projekt jego architektury: separacja ról, sieć, trwały storage, bezpieczeństwo oraz procedury utrzymania.

Dla organizacji rozwijających własne portale, usługi API, automatyzację i rozwiązania AI może to być naturalny krok od pojedynczych kontenerów do uporządkowanego środowiska produkcyjnego. Warto zacząć od niewielkiego pilotażu i zweryfikować go na rzeczywistych obciążeniach.

Alterkom wspiera projektowanie i rozwój infrastruktury wirtualizacyjnej oraz środowisk aplikacyjnych – od analizy architektury po wdrożenie i utrzymanie.

Źródła i dalsza lektura

[1] Proxmox VE – oficjalny podręcznik administratora

[2] Kubernetes – tworzenie klastra o wysokiej dostępności

[3] Kubernetes – instalacja kubeadm

[4] Kubernetes – uruchomienie klastra

[5] Plural – Kubernetes on Proxmox: A Practical Guide

[6] HorizonIQ – Kubernetes on Proxmox

Tekst opracowany autorsko na podstawie dokumentacji technicznej i analizy zagadnienia; nie jest tłumaczeniem artykułów źródłowych.