Domyślne szablony klastrów Kubernetes w NSIS Cloud
W tym artykule wymienimy szablony klastrów Kubernetes dostępne w NSIS i wyjaśnimy różnice między nimi.
Co będziemy omawiać
Lista szablonów dostępnych w chmurze
Wyjaśnij różnicę między sterownikami sieciowymi calico i cilium.
Jak wybrać odpowiedni szablon
Przegląd i zalety szablonów localstorage
Przykład tworzenia szablonu localstorage przy użyciu smaków HMD i HMAD
Wymagania wstępne
Nr 1 Konto
Potrzebne jest konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Klucze prywatne i publiczne
Do utworzenia klastra potrzebna jest dostępna para kluczy SSH. Jeśli jeszcze jej nie masz, postępuj zgodnie z tym artykułem, aby utworzyć ją w dashboardzie OpenStack: Jak utworzyć parę kluczy w OpenStack Dashboard na NSIS Cloud.
Nr 3 Dokumentacja dla standardowych szablonów
Dokumentacja dla wszystkich sterowników 1.23.16 znajduje się tutaj.
Dokumentacja dla szablonów localstorage:
k8s-stable-localstorage-1.21.5
k8s-stable-localstorage-1.22.5
k8s-stable-localstorage-1.23.5
Nr 4 Jak tworzyć klastry Kubernetes
Ogólna procedura jest wyjaśniona w Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum.
Nr 5 Używanie vGPU w klastrach Kubernetes
Jeśli nazwa szablonu zawiera „vgpu”, szablon ten może być używany do tworzenia tzw. klastrów „vGPU-first”.
Aby dowiedzieć się, jak skonfigurować vGPU w klastrach Kubernetes w chmurze NSIS, zobacz Wdrażanie obciążeń vGPU w NSIS Kubernetes.
Szablony dostępne w chmurze
Dokładna liczba dostępnych domyślnych szablonów klastrów Kubernetes zależy od wybranej chmury.
- WAW4-1
Są to domyślne szablony klastra Kubernetes w chmurze WAW4-1:
Odwrotna sytuacja jest również prawdą, możesz chcieć wybrać chmurę, której chcesz użyć, zgodnie z typem klastra, którego chcesz użyć. Na przykład, jeśli chcesz używać vGPU w swoim klastrze, musisz wybrać chmurę WAW3-1.
Jak wybrać odpowiedni szablon
Standardowe szablony
Standardowe szablony mają charakter ogólny i można ich używać do dowolnego typu klastra Kubernetes. Każdy z nich utworzy działający klaster Kubernetes na hostingu NSIS OpenStack Magnum. Domyślnym sterownikiem sieciowym jest calico. Szablon, który nie określa calico, k8s-1.23.16-v1.0.3, i jest identyczny z szablonem, który określa calico w swojej nazwie. Oba są umieszczone w lewej kolumnie w poniższej tabeli:
| calico | cilium |
|---|---|
| k8s-1.23.16-v1.0.3 | k8s-1.23.16-cilium-v1.0.3 |
| k8s-1.23.16-calico-v1.0.3 |
Jeśli aplikacja nie wymaga wielu operacji, standardowy szablon powinien być wystarczający.
Możesz także sięgnąć głębiej i wybrać szablon zgodnie z używaną wtyczką sieciową.
Wtyczki sieciowe dla klastrów Kubernetes
Szablony klastrów Kubernetes w chmurze NSIS używają wtyczek calico lub cilium do kontrolowania ruchu sieciowego. Oba są zgodne z CNI. Calico jest domyślną wtyczką, co oznacza, że jeśli nazwa szablonu nie określa wtyczki, używany jest sterownik calico. Jeśli nazwa szablonu określa cilium, to oczywiście używany jest sterownik cilium.
Calico (domyślnie)
Calico wykorzystuje protokół BGP do przenoszenia pakietów sieciowych w kierunku adresów IP podów. Calico może być szybsze od swoich konkurentów, ale jego najbardziej niezwykłą cechą jest obsługa polityk sieciowych. Dzięki nim można zdefiniować, które pody mogą wysyłać i odbierać ruch, a także zarządzać bezpieczeństwem sieci.
Calico może stosować zasady do wielu typów punktów końcowych, takich jak strąki, maszyny wirtualne i interfejsy hosta. Obsługuje również tożsamość kryptograficzną. Zasady Calico mogą być stosowane samodzielnie lub razem z zasadami sieci Kubernetes.
Cilium
Cilium czerpie swoją moc z technologii zwanej eBPF. Udostępnia ona programowalne haki do stosu sieciowego w jądrze Linuksa. eBPF wykorzystuje te haki do przeprogramowania zachowania środowiska wykonawczego Linuksa bez utraty szybkości lub bezpieczeństwa. Nie ma również potrzeby ponownej kompilacji jądra Linux, aby być świadomym zdarzeń w klastrach Kubernetes. Zasadniczo, eBPF umożliwia Linuksowi obserwowanie Kubernetes i odpowiednie reagowanie.
W Cilium relacje między różnymi częściami klastra są następujące:
Pods w klastrze (jak również sam sterownik Cilium) używają eBPF zamiast bezpośrednio korzystać z jądra Linux,
kubelet korzysta ze sterownika Cilium poprzez zgodność z CNI i
Sterownik Cilium implementuje politykę sieciową, usługi i równoważenie obciążenia, rejestrowanie przepływu i polityki, a także oblicza różne metryki.
Korzystanie z Cilium jest szczególnie sensowne, jeśli wymagana jest szczegółowa kontrola bezpieczeństwa lub zmniejszenie opóźnień w dużych klastrach Kubernetes.
Przegląd i zalety szablonów localstorage
W porównaniu ze standardowymi szablonami, szablony localstorage mogą być lepiej dopasowane do aplikacji wymagających dużej ilości zasobów.
NVMe oznacza Nonvolatile Memory Express i jest nowszym protokołem dostępu i transportu pamięci masowej dla dysków flash i półprzewodnikowych (SSD). Szablony localstorage zapewniają klastrowi wersje maszyn wirtualnych z dostępną pamięcią masową NVMe.
Każdy klaster zawiera instancję woluminu etcd, który służy jako zewnętrzna baza danych. Korzystanie z pamięci masowej NVMe przyspieszy dostęp do etcd i z definicji przyspieszy operacje klastra.
Aplikacje takie jak handel dzienny, finanse osobiste, przetwarzanie EODATA, sztuczna inteligencja i podobne mogą mieć tak wiele transakcji, że korzystanie z szablonów localstorage może stać się realną opcją.
W chmurze WAW3-1 maszyny wirtualne z NVMe mają prefiks HMD i są zasobochłonne:
openstack flavor list
+--------------+--------+------+-----------+-------+
| Name | RAM | Disk | Ephemeral | VCPUs |
+--------------+--------+------+-----------+-------+
| hmd.xlarge | 65536 | 200 | 0 | 8 |
| hmd.medium | 16384 | 50 | 0 | 2 |
| hmd.large | 32768 | 100 | 0 | 4 |
Wersja HMD będzie używana głównie dla węzłów głównych w klastrze.
Przykładowe parametry do utworzenia nowego klastra z localstorage i NVMe
Ogólne omówienie parametrów znajduje się w Warunku wstępnym nr 4. Poniżej znajduje się uproszczony przykład tworzenia klastra przy użyciu localstorage.
Jedynym odstępstwem od zwykłej procedury jest obowiązkowe dodanie etykiety etcd_volume_size=0 w oknie Advanced. Bez tego szablon localstorage nie będzie działał.
Rozpocznij tworzenie klastra za pomocą zwykłego łańcucha poleceń Container Infra -> Clusters -> + Create New Cluster.
Na poniższym zrzucie ekranu wybraliśmy k8s-stable-localstorage-1.23.5 jako nasz lokalny szablon pamięci masowej, w obowiązkowym polu Cluster Template.
W polu Keypair użyj klucza SSH, który już posiadasz, a jeśli jeszcze go nie masz, użyj warunku nr 2, aby go uzyskać.
Niech węzły główne używają jednej z wersji HMD:
Następnie wprowadź zwykłe parametry w oknach Network (Sieć) i Management (Zarządzanie).
Ostatnie okno, Zaawansowane, jest miejscem do dodania etykiety etcd_volume_size=0.
Wynikiem będzie utworzony klaster NVMe:
