Czym są kontenery aprowizacji Kubernetes i kiedy należy ich używać?

Kontenery obsługi administracyjnej to mechanizm Kubernetes służący do obsługi administracyjnej nowych podów. Kontenery inicjujące są uruchamiane i zamykane przed głównymi kontenerami aplikacji pod, umożliwiając uruchamianie skryptów ładowania początkowego w kolejności sekwencyjnej.

W tym artykule pokażemy, jak dodać kontenery init do zasobnika i przyjrzymy się niektórym typowym przypadkom użycia. Chociaż kontenery init są konfigurowane podobnie do zwykłych kontenerów, różnią się między sobą ze względu na ich specjalne przeznaczenie.

Rola kontenerów początkowych

Kontenery aprowizacji rozwiązują problemy związane z inicjowaniem aplikacji przy pierwszym uruchomieniu. Zazwyczaj usługi zależą od pomyślnego zakończenia skryptu instalacyjnego, zanim będą mogły zostać w pełni uruchomione.

W mniejszych systemach można dodać skrypt do istniejącego obrazu kontenera aplikacji. Nie jest to jednak idealne rozwiązanie, ponieważ dodaje obrazowi kolejną odpowiedzialność. Możesz nawet mieć wiele oddzielnych etapów, każdy z własnymi zależnościami i relacjami. Dodanie wszystkich tych jednorazowych operacji do głównego obrazu kontenera może szybko stworzyć nadmierną złożoność, która jest trudna do utrzymania.

Kontenery init rozwiązują ten problem, umożliwiając uruchamianie kontenerów niestandardowych przed uruchomieniem kontenerów aplikacji pod. Każdy moduł może mieć wiele kontenerów inicjujących; mają gwarancję, że będą działać sekwencyjnie, dopiero po pomyślnym zakończeniu poprzedniego.

Kubernetes uruchamia zwykłe pody po zakończeniu wszystkich kontenerów inicjujących. Jeśli kontener inicjujący nie powiedzie się, zostanie ponownie uruchomiony przed zakończeniem. Jeśli Pod restartPolicyjest ustawiony na Never , zamiast tego jest oznaczany jako nieudany.

Dodawanie kontenerów startowych do pod

Kontenery inicjujące są zdefiniowane w spec.initContainerspolu manifestu pod. Jest to bardzo podobne do zwykłej spec.containersdefinicji.

Oto przykład poda z dwoma połączonymi kontenerami startowymi:

Użyj Kubectl, aby dodać pod do swojego klastra:

$ kubectl apply -f pod.yaml

pod/init-containers-pod created

Teraz wyodrębnij dzienniki powiązane z każdym z kontenerów init, aby upewnić się, że zostały uruchomione:

$ kubectl logs init-containers-pod -c first-init-container

To jest pierwszy kontener startowy

$ kubectl logs init-containers-pod -c second-init-container

This is the second init container

W tym polu możesz korzystać z większości właściwości dostępnych dla manifestów kontenera Kubernetes initContainers. Należą do nich woluminy, porty, zmienne środowiskowe i konteksty bezpieczeństwa.

Kontenery init obsługują również limity zasobów, ale są obsługiwane inaczej niż zwykłe kontenery. Jako efektywny limit modułu wybierana jest największa wartość limitów zasobów zadeklarowanych przez wszystkie kontenery aprowizacji, chyba że jest mniejsza niż suma limitów kontenerów aplikacji modułu. Ta obliczona wartość zostanie wykorzystana do celów planowania.

Jednym z ograniczeń aprowizacji kontenerów jest brak obsługi sond. Nie można przypisywać pól do obiektów livenessProbe, readinessProbeani startupProbekontenerów w initContainerspolu. Kontenery init to osobny mechanizm, którego można używać zamiast lub w połączeniu z sondami dołączonymi do kontenerów głównej aplikacji.

Typowe błędy

Istnieje kilka typowych błędów podczas korzystania z kontenerów startowych. Oto kilka szczegółów, o których należy pamiętać:

• Kontenery Init są uruchamiane przy każdym ponownym uruchomieniu ich pod. Oznacza to, że operacje na kontenerze init muszą być idempotentne, aby można je było uruchomić dwukrotnie w tym samym podzie. Jeśli pod zostanie ponownie uruchomiony, wszystkie jego kontenery inicjujące zostaną wykonane ponownie.
• Zmiany initContainersw polu Pod nie są obsługiwane, z jednym wyjątkiem. Możesz zmienić imagepole. Spowoduje to ponowne uruchomienie modułu i uruchomienie nowych kontenerów init.
• Nazwy kontenerów startowych muszą być unikalne we wszystkich kontenerach w pode. Obejmuje to inne kontenery inicjujące i kontenery aplikacji. Jeśli spróbujesz zastosować manifest, który narusza tę regułę, zobaczysz w konsoli błąd weryfikacji YAML.
• Pody mają Initialized: Falsewarunek, gdy kontenery startowe są uruchomione. Jest to widoczne pod Conditionsnagłówkiem podczas uruchamiania kubectl describe my-pod.

Możesz również sprawdzić, czy kontenery pod init zostały zakończone za pomocą kubectl getpolecenia:

$ kubectl get init-containers-pod

NAZWA STATUS GOTOWY PONOWNIE URUCHAMIA WIEK

init-containers-pod 0/1 Init:1/2 0 1m

W tym przypadku STATUSkolumna wskazuje, że moduł ma dwa kontenery inicjujące, z których jeden zakończył się pomyślnie. Gdy wszystkie kontenery startowe zostaną ukończone, Kubernetes uruchomi kontenery aplikacji, a stan pod zmieni się na Running.

Kiedy używać kontenerów startowych

Kontenery aprowizacji są idealne, gdy trzeba w jakiś sposób zainicjować nowe wdrożenia aplikacji. Obsługują one specjalne zadania wstępne, które zależą od narzędzi spoza głównego obrazu kontenera.

Oto kilka sytuacji, w których możesz chcieć użyć kontenerów init:

• Tworzenie plików konfiguracyjnych ze zmiennych środowiskowych.
• Wstępne wypełnianie pamięci podręcznych używanych przez Twoją aplikację.
• Migracja i zapełnianie instancji bazy danych.
• Pobierz i zainstaluj wtyczki aplikacji w woluminie.
• Blokowanie uruchamiania aplikacji do momentu udostępnienia zależności (takich jak bazy danych lub zewnętrzne interfejsy API).

Innym sposobem wykonania niektórych z tych zadań jest skorzystanie z wersji próbnej Ready lub Run . Istnieje jednak różnica w intencjach: sondy są przeznaczone głównie do komunikowania stanu kontenera z Kubernetes, podczas gdy kontenery aprowizacji są zaprojektowane do wykonywania działań podczas inicjowania pod.

Streszczenie

Kontenery inicjujące to sposób na wykonywanie procedur inicjowania przy pierwszym uruchomieniu w pod Kubernetes. Mogą być używane do blokowania lub opóźniania uruchamiania kontenera aplikacji podczas oczekiwania na udostępnienie zależności lub ukończenia skryptów ładowania początkowego.

Funkcjonalność kontenerów init czasami nakłada się na sprawdzanie uruchamiania i gotowości. Możesz użyć sondy, gdy akcja, którą chcesz wykonać, polega w zasadzie na zablokowaniu uruchamiania aplikacji, dopóki warunek nie zostanie spełniony. Polegają na skrypcie już istniejącym w obrazie kontenera aplikacji. Kontener inicjujący jest najlepszym wyborem, jeśli chcesz wykonywać specjalne akcje bez przeciążania głównego obrazu jednorazowymi narzędziami.