Platforma umożliwia zautomatyzowanie procesu tworzenia , w tym w infrastrukturze dostawców usług chmurowych, na platformach wirtualizacji lub w systemach bare-metal. Aby stworzyć w pełni chmurową platformę, musieliśmy ściśle kontrolować wszystkie wykorzystywane elementy, co pozwoliło zwiększyć niezawodność skomplikowanego procesu automatyzacji.
Oczywistym rozwiązaniem okazało się przyjęcie za standard Red Hat Enterprise Linux CoreOS (wersji Red Hat Enterprise Linux) oraz CRI-O, i oto dlaczego…
Ponieważ temat żeglugi doskonale nadaje się do poszukiwania analogii w wyjaśnianiu działania Kubernetes i kontenerów, spróbujmy przedstawić problemy biznesowe, które rozwiązują CoreOS i CRI-O, na przykładzie . W 1803 roku przed Markiem Brunellem stanęło zadanie wyprodukowania 100 tysięcy bloczków takielunkowych dla potrzeb rosnącej floty morskiej Wielkiej Brytanii. Bloczek takielunkowy to rodzaj osprzętu, który służy do mocowania lin do żagli. Aż do początku XIX wieku bloczki te były wytwarzane ręcznie, ale Brunelowi udało się zautomatyzować produkcję i rozpocząć wytwarzanie znormalizowanych bloczków przy pomocy maszyn. Automatyzacja tego procesu oznaczała, że wszystkie bloczki były praktycznie identyczne, mogły być łatwo wymieniane w przypadku uszkodzenia i mogły być produkowane w dużych ilościach.
A teraz wyobraźcie sobie, że Brunel musiałby wykonać tę pracę dla 20 różnych modeli statków (wersji Kubernetes) oraz pięciu różnych planet z całkowicie różnymi prądami morskimi i wiatrami (dostawcy chmur). Co więcej, wszystkie statki (klastry OpenShift) musiałyby, niezależnie od planet, po których nawigują, zachowywać się w taki sam sposób z perspektywy kapitanów (operatorów zarządzających działaniem klastrów). Kontynuując morską analogię, kapitanom statków nie ma znaczenia, jakie bloczki takielunkowe (CRI-O) są stosowane na ich statkach – dla nich najważniejsze, aby te bloczki były mocne i niezawodne.
Przed OpenShift 4, jako platformą chmurową, stoi bardzo podobne zadanie biznesowe. Nowe węzły muszą być tworzone podczas zakupu klastra, w przypadku awarii jednego z węzłów lub podczas skalowania klastra. Przy tworzeniu i inicjalizacji nowego węzła należy również odpowiednio skonfigurować krytyczne komponenty hosta, w tym CRI-O. Jak w każdej produkcji, na początku należy dostarczyć "surowce". W przypadku statków surowcem są metal i drewno. Jednak przy tworzeniu hosta do wdrażania kontenerów w klastrze OpenShift 4, na wejściu potrzebne są pliki konfiguracyjne oraz udostępnione serwery API. Po tym OpenShift zapewni odpowiedni poziom automatyzacji przez cały cykl życia, oferując potrzebne wsparcie produktowe dla końcowych użytkowników i w ten sposób spłacając inwestycje w platformę.
OpenShift 4 została stworzona w taki sposób, aby umożliwić wygodne aktualizacje systemu przez cały cykl życia platformy (dla wersji 4.X) dla wszystkich głównych dostawców chmur obliczeniowych, platform wirtualizacyjnych i nawet systemów bare metal. Aby to osiągnąć, węzły muszą być tworzone z wymiennych elementów. Gdy klaster wymaga nowej wersji Kubernetes, otrzymuje również odpowiednią wersję CRI-O na CoreOS. Ponieważ wersja CRI-O jest bezpośrednio powiązana z Kubernetes, wszystko to w dużym stopniu upraszcza wszelkie przemieszczenia w celu testowania, rozwiązywania problemów lub wsparcia. Dodatkowo takie podejście pozwala obniżyć koszty dla końcowych użytkowników i Red Hat.
To zasadniczo nowe spojrzenie na klastry Kubernetes, które kładzie podstawy dla planowania nowych bardzo użytecznych i atrakcyjnych funkcji. CRI-O (projekt otwartego interfejsu kontenerów Container Runtime Interface — Open Container Initiative, w skrócie CRI-OCI) okazał się najbardziej odpowiednim wyborem do masowego tworzenia węzłów, które są niezbędne do pracy z OpenShift. CRI-O zastąpi wcześniej używany silnik Docker, oferując użytkownikom OpenShift – tak, nie przesłyszeliście się – nudny silnik kontenerowy, stworzony specjalnie do pracy z Kubernetes.
Świat otwartych kontenerów
Świat od dawna zmierza w kierunku otwartych kontenerów. Niezależnie od tego, czy w Kubernetes, czy na niższych poziomach, prowadzi do powstania ekosystemu innowacji na każdym poziomie.
Wszystko zaczęło się od utworzenia inicjatywy Open Containers Initiative Na tym wczesnym etapie pracy sformułowano specyfikacje kontenerowego i To umożliwiło zapewnienie, że narzędzia mogą używać jednego standardu i jednego formatu do pracy z nimi. Później dodano specyfikacje co pozwoliło użytkownikom łatwo wymieniać się .
Następnie społeczność Kubernetes opracowała jednolity standard interfejsu podłączeniowego (pluggable interface), znanego jako Dzięki temu użytkownicy Kubernetes mogli podłączać różne silniki do pracy z kontenerami oprócz Dockera.
Inżynierowie Red Hat i Google dostrzegli istniejące zapotrzebowanie na rynku na silnik kontenerowy, który mógłby przyjmować zapytania od Kubelet za pomocą protokołu CRI i przedstawili kontenery, które były zgodne z wcześniej wspomnianymi specyfikacjami OCI. Tak Ale poczekaj, powiedzieliśmy, że ten materiał będzie poświęcony CRI-O? W rzeczy samej, tak, tylko przy wydaniu projekt został przemianowany na CRI-O.
Rys. 1.
Innowacje z CRI-O i CoreOS.
Z uruchomieniem platformy OpenShift 4 zmieniono , który był używany w platformie domyślnie, a na miejsce Dockera przyszedł CRI-O, oferujący oszczędne, stabilne, proste i mało skomplikowane środowisko uruchamiania kontenerów, które rozwija się równolegle z Kubernetes. To znacznie upraszcza wsparcie i konfigurację klastra. Konfigurowanie silnika kontenerowego i hosta oraz zarządzanie nimi staje się zautomatyzowane w ramach OpenShift 4.
Zaraz, jak to?
Dokładnie tak, z pojawieniem się OpenShift 4, nie ma już potrzeby łączenia się z oddzielnymi hostami i instalowania silnika kontenerowego, konfigurowania magazynu, ustawiania serwerów do wyszukiwania czy konfigurowania sieci. Platforma OpenShift 4 została całkowicie przeprojektowana do użycia. nie tylko z punktu widzenia aplikacji użytkowników końcowych, ale także z punktu widzenia podstawowych operacji na poziomie platformy, takich jak wdrażanie obrazów, konfigurowanie systemu czy instalacja aktualizacji.
Kubernetes zawsze pozwalał użytkownikom zarządzać aplikacjami, określając pożądany stan i wykorzystując , aby zapewnić, że rzeczywisty stan jest jak najbliżej stanu zadanego. To podejście z użyciem stanu zadanego i rzeczywistego przekazać go Korzystając z operatorów (Operators) w platformie, OpenShift 4 wprowadza tę nową paradygmatę (wykorzystując koncepcję stanu zadanego i rzeczywistego) w zarządzaniu RHEL CoreOS i CRI-O. Zadania konfigurowania i zarządzania wersjami systemu operacyjnego i silnika kontenerowego są automatyzowane za pomocą tzw.
operatora konfiguracji maszyny (Machine Config Operator, MCO) Uruchamianie kontenerów
Użytkownicy mieli możliwość korzystania z silnika CRI-O w platformie OpenShift od wersji 3.7 w statusie Tech Preview i od wersji 3.9 w statusie Generally Available (obecnie wspierane). Ponadto Red Hat masowo wykorzystuje
CRI-O do uruchamiania produkcyjnych obciążeń roboczych Rys. 2. Jak działają kontenery w klastrze Kubernetes
Rys. 2. Jak działają kontenery w klastrze Kubernetes
CRI-O ułatwia tworzenie nowych hostów kontenerowych przez synchronizację całego górnego poziomu podczas inicjalizacji nowych węzłów i przy wydaniu nowych wersji platformy OpenShift. Przegląd całej platformy umożliwia przeprowadzanie transakcyjnych aktualizacji / wycofań, a także zapobiega wzajemnym blokadom w zależnościach między rdzeniem hosta kontenerowego, silnikiem kontenerowym, węzłami (Kubeletami) i głównym węzłem Kubernetes Master. Przy centralnym zarządzaniu wszystkimi komponentami platformy, z kontrolą i zarządzaniem wersjami, można zawsze śledzić jasną ścieżkę z punktu A do punktu B. Ułatwia to proces aktualizacji, zwiększa bezpieczeństwo, poprawia raportowanie wyników wydajności i pomaga obniżyć koszty aktualizacji oraz instalacji nowych wersji.
Demonstracja mocy wymiennych elementów
Jak już wcześniej wspomniano, użycie Machine Config Operator do zarządzania hostem kontenera i silnikiem kontenerowym w OpenShift 4 zapewnia nowy poziom automatyzacji, który wcześniej nie był możliwy na platformie Kubernetes. Aby pokazać nowe możliwości, zaprezentujemy, jak można wprowadzać zmiany w pliku crio.conf. Aby uniknąć zamieszania terminologicznego, staraj się skoncentrować na wynikach.
Najpierw stwórzmy to, co nazywamy konfiguracją środowiska uruchomieniowego kontenera – Container Runtime Config. Uważaj to za pewien zasób Kubernetes, który przedstawia konfigurację dla CRI-O. W rzeczywistości jest to specjalizowana wersja tego, co nazywa się MachineConfig, co stanowi każdą konfigurację wdrażaną na maszynie RHEL CoreOS w ramach klastra OpenShift.
Ten niestandardowy zasób, zwany ContainerRuntimeConfig, został wymyślony, aby ułatwić administratorom klastra konfigurację CRI-O. To wystarczająco potężne narzędzie, które można stosować tylko do określonych węzłów, w zależności od ustawień MachineConfigPool. Uważaj to za grupę maszyn, które służą temu samemu celowi.
Zwróć uwagę na dwie ostatnie linie, które zamierzamy zmienić w pliku /etc/crio/crio.conf. Te dwie linie są bardzo podobne do linii w pliku crio.conf, to:
vi ContainerRuntimeConfig.yaml
Wynik:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Teraz wyślemy ten plik do klastra Kubernetes i sprawdzimy, czy został rzeczywiście utworzony. Zauważ, że proces jest dokładnie taki sam, jak w przypadku innych zasobów Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Wynik:
NAZWA WIEK
set-log-and-pid 22h
Po utworzeniu ContainerRuntimeConfig musimy zmienić jeden z MachineConfigPools, aby poinformować Kubernetes, że chcemy zastosować tę konfigurację do określonej grupy maszyn w klastrze. W tym przypadku zmienimy MachineConfigPool dla węzłów master:
oc edit MachineConfigPool/master
Wyjście (dla przejrzystości pozostawiono główną istotę):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
W tym momencie MCO zaczyna tworzyć nowy plik crio.conf dla klastra. W pełni gotowy plik konfiguracyjny można przeglądać za pomocą API Kubernetes. Pamiętaj, że ContainerRuntimeConfig to tylko wyspecjalizowana wersja MachineConfig, więc możemy zobaczyć efekt, przyglądając się odpowiednim wierszom w MachineConfigs:
oc get MachineConfigs | grep rendered
Wynik:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Zauważ, że uzyskany plik konfiguracyjny dla węzłów master okazał się nowszą wersją niż oryginalne konfiguracje. Aby go wyświetlić, uruchom następujące polecenie. Warto zauważyć, że to być może jeden z najlepszych jednolitych skryptów w historii Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Wynik:
pids_limit = 2048
Teraz upewnimy się, że konfiguracja została zastosowana do wszystkich węzłów master. Najpierw uzyskamy listę węzłów w klastrze:
oc get node | grep master
Wyjście:
ip-10-0-135-153.us-east-2.compute.internal Gotowy master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Gotowy master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Gotowy master 23h v1.12.4+509916ce1
Teraz przejrzymy zainstalowany plik. Zobaczysz, że plik został zaktualizowany zgodnie z nowymi wartościami dyrektyw pid i debug, które wskazaliśmy w zasobie ContainerRuntimeConfig. Sama elegancja:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Wynik:
...
pids_limit = 2048
...
log_level = "debug"
...
Wszystkie te zmiany w klastrze zostały wprowadzone nawet bez uruchamiania SSH. Cała praca została wykonana poprzez odwołanie się do węzła głównego Kubernetes. Oznacza to, że te nowe parametry zostały skonfigurowane tylko na węzłach głównych. Węzły robocze nie zostały zmienione, co pokazuje zalety metodyki Kubernetes wykorzystującej zadane i aktualne stany odnoszące się do hostów kontenerów i silników kontenerowych z wymiennymi elementami.
Powyższy przykład pokazuje możliwość wprowadzania zmian w małym klastrze OpenShift Container Platform 4 z trzema węzłami roboczymi, lub w ogromnym klastrze produkcyjnym z 3000 węzłami. W każdym przypadku zakres prac będzie taki sam – i całkiem mały – wystarczy skonfigurować plik ContainerRuntimeConfig i zmienić jedną etykietę (label) w MachineConfigPool. Możesz to zrobić z każdą wersją używanej platformy Kubernetes OpenShift Container Platform 4.X przez cały jej cykl życia.
Często firmy technologiczne rozwijają się na tyle szybko, że nie jesteśmy w stanie wyjaśnić, dlaczego wybieramy określone technologie dla podstawowych komponentów. Silniki kontenerowe historycznie były tym komponentem, z którym użytkownicy mają bezpośrednią interakcję. Ponieważ popularność kontenerów naturalnie zaczęła się od pojawienia się silników kontenerowych, użytkownicy często są nimi zainteresowani. To kolejny powód, dla którego Red Hat zdecydowała się na CRI-O. Kontenery się rozwijają, a dzisiaj skupiamy się głównie na orkiestracji i doszliśmy do wniosku, że CRI-O zapewnia najlepsze doświadczenia w pracy z OpenShift 4.
Źródło: habr.com
