platforma pozwala usprawnić kreację m.in. w infrastrukturze dostawców usług chmurowych, na platformach wirtualizacyjnych czy w systemach bare-metal. Aby stworzyć platformę prawdziwie chmurową, musieliśmy przejąć ścisłą kontrolę nad wszystkimi zastosowanymi elementami i tym samym zwiększyć niezawodność złożonego procesu automatyzacji.
Oczywistym rozwiązaniem było użycie Red Hat Enterprise Linux CoreOS (wariant Red Hat Enterprise Linux) i CRI-O w standardzie, a oto dlaczego…
Ponieważ temat żeglarstwa jest bardzo dobry do szukania analogii przy wyjaśnianiu pracy Kubernetesa i kontenerów, spróbujmy porozmawiać o problemach biznesowych, które rozwiązuje CoreOS i CRI-O, na przykładzie . W 1803 roku Marc Brunel otrzymał zadanie wyprodukowania 100 19 bloków olinowania na potrzeby rosnącej brytyjskiej marynarki wojennej. Blok olinowania to rodzaj olinowania, który służy do mocowania lin do żagli. Do początków XIX wieku bloki te wykonywano ręcznie, jednak Brunelowi udało się zautomatyzować produkcję i zaczął wytwarzać znormalizowane bloki przy użyciu obrabiarek. Automatyzacja tego procesu oznaczała, że powstałe bloki były zasadniczo identyczne, można je było łatwo wymienić w przypadku uszkodzenia i można je było produkować w dużych ilościach.
Teraz wyobraźcie sobie, że Brunel musiałby wykonać tę pracę dla 20 różnych modeli statków (wersje Kubernetes) i dla pięciu różnych planet z zupełnie różnymi prądami morskimi i wiatrami (dostawcy chmury). Dodatkowo wymagano, aby wszystkie statki (klastry OpenShift), niezależnie od planet, na których prowadzona jest nawigacja, z punktu widzenia kapitanów (operatorów zarządzających pracą klastrów) zachowywały się tak samo. Kontynuując analogię morską, kapitanowie statków w ogóle nie dbają o to, jakiego rodzaju bloki olinowania (CRI-O) są używane na ich statkach - najważniejsze dla nich jest to, że bloki te są mocne i niezawodne.
OpenShift 4, jako platforma chmurowa, stoi przed bardzo podobnym wyzwaniem biznesowym. Nowe węzły muszą zostać utworzone w momencie tworzenia klastra, w przypadku awarii jednego z węzłów lub podczas skalowania klastra. Kiedy tworzony i inicjowany jest nowy węzeł, należy odpowiednio skonfigurować krytyczne komponenty hosta, w tym CRI-O. Jak w każdej innej produkcji, na początku trzeba dostarczyć „surowce”. W przypadku statków surowcami są metal i drewno. Jednak w przypadku tworzenia hosta do wdrażania kontenerów w klastrze OpenShift 4 jako dane wejściowe potrzebne są pliki konfiguracyjne i serwery udostępniane przez interfejs API. OpenShift zapewni wówczas wymagany poziom automatyzacji w całym cyklu życia, oferując niezbędne wsparcie produktowe użytkownikom końcowym i w ten sposób zwracając inwestycję w platformę.
OpenShift 4 został stworzony w taki sposób, aby zapewnić możliwość wygodnej aktualizacji systemu przez cały cykl życia platformy (dla wersji 4.X) dla wszystkich liczących się dostawców chmury obliczeniowej, platform wirtualizacyjnych, a nawet systemów bare metal. W tym celu należy utworzyć węzły w oparciu o elementy wymienne. Gdy klaster wymaga nowej wersji Kubernetes, otrzymuje również odpowiednią wersję CRI-O na CoreOS. Ponieważ wersja CRI-O jest powiązana bezpośrednio z Kubernetesem, znacznie upraszcza to wszelkie permutacje na potrzeby testowania, rozwiązywania problemów lub celów wsparcia. Ponadto takie podejście zmniejsza koszty dla użytkowników końcowych i firmy Red Hat.
Jest to całkowicie nowy sposób myślenia o klastrach Kubernetes i kładzie podwaliny pod planowanie kilku bardzo przydatnych i fascynujących nowych funkcji. CRI-O (Container Runtime Interface – Open Container Initiative, w skrócie CRI-OCI) okazał się najbardziej udanym wyborem do masowego tworzenia węzłów niezbędnych do pracy z OpenShift. CRI-O zastąpi dotychczas używany silnik Dockera, oferując użytkownikom OpenShift – tak, dobrze słyszeliście – nudny silnik kontenerowy stworzony specjalnie do pracy z Kubernetesem.
Świat otwartych kontenerów
Świat od dawna zmierza w stronę otwartych kontenerów. Czy to w Kubernetesie, czy na niższych poziomach, skutkuje ekosystemem innowacji na każdym poziomie.
Wszystko zaczęło się od powstania Inicjatywy Otwartych Kontenerów . Już na tym wczesnym etapie prac powstała specyfikacja kontenera и . Dzięki temu narzędzia mogły korzystać z jednego standardu oraz ujednolicony format pracy z nimi. Specyfikacje zostały później dodane , umożliwiając użytkownikom łatwe udostępnianie .
Następnie społeczność Kubernetes opracowała pojedynczy standard dla wtykowego interfejsu o nazwie . Dzięki temu użytkownicy Kubernetesa oprócz Dockera mogli podłączyć różne silniki do pracy z kontenerami.
Inżynierowie z Red Hat i Google dostrzegli zapotrzebowanie rynku na silnik kontenerowy, który mógłby akceptować żądania Kubelet za pośrednictwem protokołu CRI, i wprowadzili kontenery zgodne ze wspomnianymi powyżej specyfikacjami OCI. Więc . Ale przepraszam, czy nie mówiliśmy, że ten materiał będzie poświęcony CRI-O? Właściwie tak jest, tylko z wydaniem projekt został przemianowany na CRI-O.
Rys.. 1.
Innowacje dzięki CRI-O i CoreOS
Wraz z premierą platformy OpenShift 4 uległo to zmianie , używany domyślnie w platformie, a Docker został zastąpiony przez CRI-O, oferującym ekonomiczne, stabilne, proste i nudne środowisko do uruchamiania kontenera rozwijającego się równolegle z Kubernetesem. To znacznie upraszcza obsługę i konfigurację klastra. Konfiguracja silnika kontenera i hosta, a także zarządzanie nimi zostaje zautomatyzowane w OpenShift 4.
Czekaj, jak to jest?
Zgadza się, wraz z pojawieniem się OpenShift 4 nie ma już potrzeby łączenia się z indywidualnymi hostami i instalowania silnika kontenerowego, konfigurowania pamięci masowej, konfigurowania serwerów wyszukiwania ani konfigurowania sieci. Platforma OpenShift 4 została całkowicie przeprojektowana pod kątem obsługi nie tylko w zakresie aplikacji dla użytkowników końcowych, ale także w zakresie podstawowych operacji na poziomie platformy, takich jak wdrażanie obrazów, konfigurowanie systemu czy instalowanie aktualizacji.
Kubernetes zawsze umożliwiał użytkownikom zarządzanie aplikacjami poprzez definiowanie pożądanego stanu i używanie , aby upewnić się, że stan rzeczywisty odpowiada stanowi docelowemu tak blisko, jak to możliwe. Ten otwiera ogromne możliwości zarówno z perspektywy rozwojowej, jak i operacyjnej. Programiści mogą zdefiniować wymagany stan poprzez do operatora w postaci pliku YAML lub JSON, a następnie operator może utworzyć wymaganą instancję aplikacji w środowisku produkcyjnym, a stan pracy tej instancji będzie w pełni odpowiadał zadanemu.
Korzystając z operatorów na platformie, OpenShift 4 wprowadza ten nowy paradygmat (wykorzystując koncepcję stanu zadanego i rzeczywistego) do zarządzania RHEL CoreOS i CRI-O. Zadania konfigurowania i zarządzania wersjami systemu operacyjnego oraz silnika kontenerowego są zautomatyzowane za pomocą tzw . MCO znacznie upraszcza pracę administratora klastra, w zasadzie automatyzując ostatnie etapy instalacji, a także kolejne czynności poinstalacyjne (operacje drugiego dnia). Wszystko to sprawia, że OpenShift 4 jest prawdziwą platformą chmurową. Zajmiemy się tym nieco później.
Działające kontenery
Użytkownicy mieli możliwość wykorzystania silnika CRI-O w platformie OpenShift od wersji 3.7 w statusie Tech Preview oraz od wersji 3.9 w statusie Ogólnie Dostępny (obecnie obsługiwany). Ponadto Red Hat masowo wykorzystuje w OpenShift Online od wersji 3.10. Wszystko to pozwoliło zespołowi pracującemu nad CRI-O zdobyć szerokie doświadczenie w masowym uruchamianiu kontenerów na dużych klastrach Kubernetes. Aby uzyskać podstawowe zrozumienie, w jaki sposób Kubernetes wykorzystuje CRI-O, spójrzmy na poniższą ilustrację, która pokazuje, jak działa ta architektura.
Ryż. 2. Jak działają kontenery w klastrze Kubernetes
CRI-O upraszcza tworzenie nowych hostów kontenerów poprzez synchronizację całego najwyższego poziomu podczas inicjowania nowych węzłów i wydawania nowych wersji platformy OpenShift. Wersja całej platformy umożliwia transakcyjne aktualizacje/wycofanie zmian, a także zapobiega zakleszczeniom w zależnościach pomiędzy rdzeniem kontenera, silnikiem kontenera, węzłami (Kubelets) i węzłem Kubernetes Master. Dzięki centralnemu zarządzaniu wszystkimi komponentami platformy, z kontrolą i wersjonowaniem, zawsze istnieje jasna ścieżka od stanu A do stanu B. Upraszcza to proces aktualizacji, poprawia bezpieczeństwo, poprawia raportowanie wydajności i pomaga zmniejszyć koszty aktualizacji i instalacji nowych wersji .
Demonstracja mocy elementów zamiennych
Jak wspomniano wcześniej, użycie operatora Machine Config do zarządzania hostem kontenera i silnikiem kontenera w OpenShift 4 zapewnia nowy poziom automatyzacji, który wcześniej nie był możliwy na platformie Kubernetes. Aby zademonstrować nowe funkcje, pokażemy, jak można wprowadzić zmiany w pliku crio.conf. Aby uniknąć pomyłki w terminologii, spróbuj skupić się na wynikach.
Najpierw utwórzmy tak zwaną konfigurację środowiska wykonawczego kontenera — Konfiguracja środowiska uruchomieniowego kontenera. Pomyśl o tym jak o zasobie Kubernetes reprezentującym konfigurację CRI-O. W rzeczywistości jest to wyspecjalizowana wersja czegoś zwanego MachineConfig, czyli dowolnej konfiguracji wdrożonej na maszynie RHEL CoreOS jako część klastra OpenShift.
Ten niestandardowy zasób o nazwie ContainerRuntimeConfig został stworzony, aby ułatwić administratorom klastrów konfigurowanie CRI-O. To narzędzie jest na tyle potężne, że można je zastosować tylko do niektórych węzłów, w zależności od ustawień MachineConfigPool. Pomyśl o tym jak o grupie 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, są to:
vi ContainerRuntimeConfig.yaml
Wnioski:
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 wypchnijmy ten plik do klastra Kubernetes i sprawdźmy, czy faktycznie został utworzony. Należy pamiętać, że operacja jest dokładnie taka sama, jak w przypadku każdego innego zasobu Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Wnioski:
NAME AGE
set-log-and-pid 22h
Po utworzeniu ContainerRuntimeConfig musimy zmodyfikować jeden z MachineConfigPools, aby zasygnalizować Kubernetesowi, że chcemy zastosować tę konfigurację do określonej grupy maszyn w klastrze. W tym przypadku zmienimy MachineConfigPool dla węzłów głównych:
oc edit MachineConfigPool/master
Wniosek (dla jasności pozostawiono główną esencję):
...
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 takim przypadku całkowicie gotowy plik konfiguracyjny można obejrzeć za pomocą Kubernetes API. Pamiętaj, że ContainerRuntimeConfig to tylko wyspecjalizowana wersja MachineConfig, więc możemy zobaczyć wynik, patrząc na odpowiednie wiersze w MachineConfig:
oc get MachineConfigs | grep rendered
Wnioski:
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
Należy pamiętać, że wynikowy plik konfiguracyjny dla węzłów głównych był nowszą wersją niż oryginalne konfiguracje. Aby go wyświetlić, uruchom następujące polecenie. Na marginesie zauważamy, że jest to prawdopodobnie jeden z najlepszych jednowierszowych rozwiązań w historii Kubernetesa:
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
Wnioski:
pids_limit = 2048
Teraz upewnijmy się, że konfiguracja została zastosowana do wszystkich węzłów głównych. Najpierw otrzymujemy listę węzłów w klastrze:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Przyjrzyjmy się teraz zainstalowanemu plikowi. Zobaczysz, że plik został zaktualizowany o nowe wartości dla dyrektyw pid i debug, które określiliś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’
Wnioski:
...
pids_limit = 2048
...
log_level = "debug"
...
Wszystkie te zmiany w klastrze zostały wprowadzone nawet bez uruchamiania protokołu SSH. Cała praca została wykonana poprzez dostęp do głównego węzła Kuberentes. Oznacza to, że te nowe parametry zostały skonfigurowane tylko w węzłach głównych. Węzły robocze nie uległy zmianie, co pokazuje zalety metodyki Kubernetes polegającej na wykorzystaniu stanów określonych i rzeczywistych w odniesieniu do hostów kontenerów i silników kontenerów z elementami wymiennymi.
Powyższy przykład pokazuje możliwość wprowadzenia zmian w małym klastrze OpenShift Container Platform 4 z trzema węzłami produkcyjnymi lub w ogromnym klastrze produkcyjnym z 3000 węzłów. W każdym razie ilość pracy będzie taka sama - i bardzo mała - wystarczy skonfigurować plik ContainerRuntimeConfig i zmienić jedną etykietę w MachineConfigPool. Możesz to zrobić za pomocą dowolnej wersji OpenShift Container Platform 4.X obsługującej Kubernetes przez cały cykl jej życia.
Często firmy technologiczne ewoluują tak szybko, że nie jesteśmy w stanie wyjaśnić, dlaczego wybieramy określone technologie dla podstawowych komponentów. W przeszłości silniki kontenerowe były komponentem, z którym użytkownicy bezpośrednio wchodzą w interakcję. Ponieważ popularność kontenerów zaczęła się naturalnie wraz z pojawieniem się silników kontenerowych, użytkownicy często wykazują nimi zainteresowanie. To kolejny powód, dla którego Red Hat wybrał CRI-O. Kontenery ewoluują, koncentrując się obecnie na orkiestracji i odkryliśmy, że CRI-O zapewnia najlepsze wrażenia podczas pracy z OpenShift 4.
Źródło: www.habr.com