Przyp. tłum.: Autor oryginalnego artykułu — Théo Chamley, architekt rozwiązań chmurowych Google. W tej publikacji na blogu Google Cloud przedstawił krótkie podsumowanie bardziej szczegółowego przewodnika swojej firmy, zatytułowanego „”. W nim specjaliści Google zebrali najlepsze praktyki dotyczące eksploatacji kontenerów w kontekście użycia Google Kubernetes Engine i nie tylko, poruszając szeroki zakres tematów: od bezpieczeństwa po monitorowanie i rejestrowanie. Jakie zatem praktyki w pracy z kontenerami są według Google najważniejsze?
(usługa oparta na Kubernetes do uruchamiania aplikacji konteneryzowanych w Google Cloud — przyp. tłum.) — to jeden z najlepszych sposobów uruchamiania obciążeń wymagających skalowania. zapewni bezproblemowe działanie większości aplikacji, jeśli są one konteneryzowane. Ale jeśli chcesz, aby aplikacja była łatwa w zarządzaniu i chciałbyś skorzystać ze wszystkich zalet Kubernetes, musisz stosować najlepsze praktyki. Ułatwią one eksploatację aplikacji, jej monitorowanie i debugowanie, a także zwiększą bezpieczeństwo.
W tym artykule przejdziemy przez listę rzeczy, które warto wiedzieć i robić, aby kontenery w Kubernetes działały efektywnie. Osoby chcące zagłębić się w szczegóły powinny przeczytać materiał , a także zwrócić uwagę na nasz na temat budowy kontenerów.
1. Używaj natywnych mechanizmów kontenerów do logowania
Jeśli aplikacja jest uruchomiona w klastrze Kubernetes, do logów nie trzeba wiele. Zcentralizowany system logowania prawdopodobnie już jest wbudowany w używany klaster. W przypadku korzystania z Kubernetes Engine odpowiada za to . (Przyp. tłum.: A w przypadku korzystania z własnej instalacji Kubernetes polecamy zwrócić uwagę na nasze rozwiązanie Open Source — .) Nie komplikuj sobie życia i korzystaj z natywnych mechanizmów logowania kontenerów. Pisz logi do stdout i stderr — zostaną one automatycznie przechwycone, zapisane i zaindeksowane.
W razie potrzeby można również pisać logi do . Takie podejście umożliwi łatwe dodawanie do nich metadanych. A wraz z nimi w Stackdriver Logging pojawi się możliwość przeszukiwania logów z użyciem tych metadanych.
2. Upewnij się, że kontenery są stateless i immutable
Aby kontenery w klastrze Kubernetes działały poprawnie, muszą być stateless i immutable. Kiedy te warunki są spełnione, Kubernetes może wykonywać swoją pracę, tworząc i niszcząc byty aplikacji, kiedy i gdzie to konieczne.
Stateless oznacza, że jakiekolwiek stany (trwałe dane wszelkiego rodzaju) są przechowywane poza kontenerem. W tym celu, w zależności od potrzeb, mogą być wykorzystywane różne rodzaje zewnętrznych magazynów: , , , lub inne zarządzane bazy danych. (Przyp. tłum.: Więcej na ten temat przeczytasz także w naszym artykule „».)
Immutable oznacza, że kontener nie będzie modyfikowany w trakcie swojego życia: żadnych aktualizacji, poprawek, zmian w konfiguracji. Jeśli musisz zaktualizować kod aplikacji lub zastosować poprawkę, stwórz nowy obraz i wdroż go. Zaleca się przeniesienie konfiguracji kontenera (port do nasłuchiwania, parametry środowiska wykonawczego itp.) na zewnątrz — do i . Można je aktualizować bez potrzeby ponownej budowy nowego obrazu kontenera. Do prostego tworzenia pipeline'ów do budowy obrazów można użyć . (Przyp. tłum.: Dla tych celów używamy narzędzia Open Source .)
Przykład aktualizacji konfiguracji Deployment w Kubernetes przy użyciu ConfigMap, zamontowanego w podach jako config
3. Unikaj uruchamiania kontenerów z uprawnieniami
Nie uruchamiasz przecież aplikacji jako root na swoich serwerach, prawda? Jeśli złośliwiec włamie się do aplikacji, uzyska dostęp z uprawnieniami root. Te same zasady dotyczą unikania uruchamiania kontenerów z uprawnieniami. Jeśli konieczne jest zmienienie ustawień na hoście, możesz przyznać kontenerowi konkretne zdolnościami za pomocą opcji w Kubernetes. Jeśli konieczne jest zmienienie sysctls, Kubernetes ma do tego. Ogólnie rzecz biorąc, staraj się maksymalnie wykorzystać i kontenery sidecar do wykonywania podobnych uprzywilejowanych operacji. Nie muszą być dostępne ani dla ruchu wewnętrznego, ani zewnętrznego.
Jeśli zarządzasz klastrem, możesz skorzystać z do ograniczeń w stosowaniu uprzywilejowanych kontenerów.
4. Unikaj uruchamiania jako root
O kontenerach uprzywilejowanych już wspomniano, ale będzie jeszcze lepiej, jeśli oprócz tego nie będziecie uruchamiać aplikacji wewnątrz kontenera z uprawnieniami root. Jeśli złośliwy użytkownik znajdzie w aplikacji z prawami root zdalną lukę, która pozwala na wykonanie kodu, a następnie będzie mógł wyjść poza kontener przez jeszcze nieznaną lukę, to uzyska dostęp do root'a na hoście.
Najlepszym sposobem, aby tego uniknąć, jest przede wszystkim nie uruchamianie czegokolwiek z uprawnieniami root. Dlatego można skorzystać z dyrektywy USER do Dockerfile lub runAsUser w Kubernetes. Administrator klastra może również skonfigurować wymuszone zachowanie przy pomocy .
5. Ułatwiaj monitorowanie aplikacji
Podobnie jak logowanie, monitorowanie jest nieodłączną częścią zarządzania aplikacją. Popularnym rozwiązaniem do monitorowania w społeczności Kubernetes jest — system, który automatycznie wykrywa pody i usługi wymagające monitorowania. (Przyp. tłum.: Zobacz także nasz na temat monitorowania za pomocą Prometheus i Kubernetes.) może monitorować klastry Kubernetes i zawiera swoją wersję Prometheus do monitorowania aplikacji.
Panel monitorowania Kubernetes w Stackdriver
Prometheus oczekuje, że aplikacja udostępni metryki na końcówce HTTP. W tym celu dostępne są Taki sam format stosują inne narzędzia, takie jak i .
6. Umożliwiaj dostęp do stanu zdrowia aplikacji
Zarządzaniu aplikacją w produkcji pomaga jej zdolność do raportowania swojego stanu całemu systemowi. Czy aplikacja jest uruchomiona? Czy działa prawidłowo? Czy jest gotowa do obsługi ruchu? Jak się zachowuje? Najbardziej powszechnym sposobem rozwiązania tego problemu jest implementacja kontrolnych punktów zdrowia (health checks). Kubernetes ma dwa ich typy: .
Dla liveness probe (sprawdzanie żywotności) aplikacja musi mieć końcówkę HTTP, która zwraca odpowiedź „200 OK”, jeśli działa i jej podstawowe zależności są spełnione. Dla readiness probe (sprawdzanie gotowości do obsługi) Aplikacja powinna mieć inny punkt końcowy HTTP, który zwraca odpowiedź „200 OK”, jeśli aplikacja jest w zdrowym stanie, kroki inicjalizacji zostały wykonane, a każdy poprawny request nie powoduje błędu. Kubernetes będzie kierować ruch do kontenera tylko wtedy, gdy aplikacja będzie gotowa zgodnie z tymi kontrolami. Dwa punkty końcowe mogą być połączone, jeśli nie ma różnicy między stanami żywotności (liveness) i gotowości (readiness).
Więcej informacji można znaleźć w odpowiednim artykule autorstwa Sandeep Dinesha, rzecznika dewelopera z Google: „».
7. Starannie wybieraj wersję obrazu
Większość publicznych i prywatnych obrazów używa systemu tagowania podobnego do opisanego w . Gdy obraz stosuje system zbliżony do , należy uwzględnić specyfikę tagowania. Na przykład tag latest może często przechodzić z obrazu na obraz — nie można na nim polegać, jeśli potrzebujesz przewidywalnych i odtwarzalnych wersji i instalacji.
Możesz użyć tagu X.Y.Z (zazwyczaj pozostaje niezmienny), jednak w takim przypadku śledź wszystkie łatki i aktualizacje obrazu. Jeśli używany obraz ma tag X.Y, to dobry wybór złotego środka. Wybierając go, automatycznie otrzymujesz łatki, jednocześnie opierając się na stabilnej wersji aplikacji.
P.S. od tłumacza
Przeczytaj także na naszym blogu:
- «»;
- «»;
- «»;
- «» (przegląd i wideo z prezentacji);
- «» (przegląd i wideo z prezentacji);
- «» (przegląd i wideo z prezentacji);
- «» (przegląd i wideo z prezentacji);
- «».
Źródło: habr.com
