Cześć, Użytkownicy Habr! Kubernetes to jeden z kluczowych elementów nowoczesnego ekosystemu chmurowego. Ta technologia zapewnia niezawodność, skalowalność i odporność wirtualizacji kontenerów. John Arundel i Justin Domingus opowiadają o ekosystemie Kubernetes i dzielą się sprawdzonymi rozwiązaniami codziennych problemów. Krok po kroku zbudujesz swoją własną aplikację chmurową i stworzysz infrastrukturę do jej wsparcia, skonfigurujesz środowisko deweloperskie oraz ciągły proces wdrażania, który przyda się podczas pracy nad kolejnymi aplikacjami.
• Rozpocznie pracę z kontenerami i Kubernetes od podstaw: nie jest wymagane żadne specjalne doświadczenie do nauki tego tematu. • Uruchom swoje własne klastry lub wybierz zarządzaną usługę Kubernetes od Amazona, Google itd. • Zastosuj Kubernetes do zarządzania cyklem życia kontenera i zużyciem zasobów. • Optymalizuj klastry pod kątem kosztów, wydajności, odporności, mocy i skalowalności. • Poznaj najlepsze narzędzia do tworzenia, testowania i wdrażania swoich aplikacji. • Skorzystaj z aktualnych praktyk branżowych w celu zapewnienia bezpieczeństwa i kontroli. • Wprowadź w firmie zasady DevOps, aby zespoły deweloperskie mogły działać bardziej elastycznie, szybko i efektywnie.
Dla kogo jest ta książka
Książka jest szczególnie przydatna dla pracowników działów administracyjnych odpowiedzialnych za serwery, aplikacje i usługi, a także dla deweloperów zajmujących się tworzeniem nowych usług chmurowych lub migracją istniejących aplikacji do Kubernetes i chmury. Nie martw się, nie musisz umieć pracować z Kubernetes i kontenerami — wszystkiego cię nauczymy.
Doświadczeni użytkownicy Kubernetes również znajdą wiele cennych informacji: książka zawiera wnikliwe omówienia tematów takich jak RBAC, ciągłe wdrażanie, zarządzanie danymi poufnymi i monitorowanie. Mamy nadzieję, że na stronach książki znajdziesz coś interesującego, niezależnie od twoich umiejętności i doświadczenia.
Na jakie pytania odpowiada książka
Podczas planowania i pisania książki rozmawialiśmy o chmurze i Kubernetes z setkami osób, rozmawialiśmy zarówno z liderami i ekspertami w tej dziedzinie, jak i z absolutnymi nowicjuszami. Poniżej znajdują się pytania, na które chcieliby zobaczyć odpowiedzi w tym wydaniu.
- „Interesuje mnie, dlaczego warto poświęcać czas na tę technologię. Jakie problemy może rozwiązać dla mnie i mojego zespołu?”
- „Kubernetes wydaje się interesujący, ale ma dość wysoki próg wejścia. Przygotowanie prostego przykładu nie jest trudne, ale dalsze administrowanie i debugowanie przerażają. Chcielibyśmy uzyskać solidne porady, jak ludzie zarządzają klastrami Kubernetes w warunkach rzeczywistych i z jakimi problemami najprawdopodobniej się spotkamy.”
- „Byłaby przydatna subiektywna rada. Ekosystem Kubernetes oferuje początkującym zespołom zbyt wiele opcji do wyboru. Gdy to samo można zrobić na kilka sposobów, jak zrozumieć, który z nich jest lepszy? Jak dokonać wyboru?”
I, prawdopodobnie najważniejsze z wszystkich pytań:
- „Jak używać Kubernetes, nie zakłócając działania mojej firmy?”
Fragment. Konfiguracja i obiekty Secret
Możliwość oddzielenia logiki aplikacji Kubernetes od jej konfiguracji (czyli od wszelkich wartości lub ustawień, które mogą się zmienić w czasie) jest bardzo przydatna. Do wartości konfiguracyjnych zazwyczaj należą parametry przeznaczone dla konkretnego środowiska, adresy DNS zewnętrznych usług oraz dane uwierzytelniające do autoryzacji.
Oczywiście, wszystko to można umieścić bezpośrednio w kodzie, ale takie podejście nie jest wystarczająco elastyczne. Na przykład, aby zmienić wartość konfiguracyjną, trzeba by ponownie skompilować i wdrożyć kod. Dużo lepszym rozwiązaniem byłoby oddzielenie konfiguracji od kodu i odczytywanie jej z pliku lub zmiennych środowiskowych.
Kubernetes oferuje kilka różnych sposobów zarządzania konfiguracją. Po pierwsze, można przekazywać wartości do aplikacji za pomocą zmiennych środowiskowych określonych w specyfikacji pod-otoczenia (zob. sekcję „Zmienna środowiskowa” s. 192). Po drugie, dane konfiguracyjne można przechowywać bezpośrednio w Kubernetes, używając obiektów ConfigMap i Secret.
W tym rozdziale szczegółowo zbadamy te obiekty i omówimy kilka praktycznych podejść do zarządzania konfiguracjami oraz poufnymi danymi na przykładzie aplikacji demonstracyjnej.
Aktualizacja podów podczas zmiany konfiguracji
Wyobraź sobie, że w twoim klastrze istnieje wdrożenie i chcesz zmienić niektóre wartości w jego ConfigMap. Jeśli używasz Helm chart (zobacz rozdział „Helm: menedżer pakietów dla Kubernetes” na str. 102), możesz automatycznie wykryć zmianę konfiguracji i ponownie załadować swoje pody przy użyciu jednego sprytnego triku. Dodaj następującą adnotację do specyfikacji swojego wdrożenia:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Teraz szablon wdrożenia zawiera sumę kontrolną parametrów konfiguracyjnych: gdy parametry się zmieniają, suma zostanie zaktualizowana. Jeśli wykonasz polecenie helm upgrade, Helm wykryje, że specyfikacja wdrożenia została zmieniona i ponownie uruchomi wszystkie pody.
Poufne dane w Kubernetes
Już wiemy, że obiekt ConfigMap zapewnia elastyczny mechanizm przechowywania i dostępu do danych konfiguracyjnych w klastrze. Jednak większość aplikacji ma informacje, które są tajne i poufne: na przykład hasła lub klucze API. Można je przechowywać również w ConfigMap, ale takie rozwiązanie nie jest idealne.
Zamiast tego Kubernetes oferuje specjalny typ obiektu, przeznaczony do przechowywania poufnych danych: Secret. Poniżej omówimy na przykładzie, jak można zastosować ten obiekt w naszej aplikacji demonstracyjnej.
Na początek spojrz na manifest Kubernetes dla obiektu Secret (zobacz hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
W tym przykładzie tajny klucz magicWord ma wartość xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Słowo xyzzy jest bardzo przydatne w świecie komputerów. Podobnie jak w ConfigMap, w obiekcie Secret można umieszczać wiele kluczy i wartości. Tutaj dla uproszczenia używamy tylko jednej pary „klucz — wartość”.
Używanie obiektów Secret jako zmiennych środowiskowych
Podobnie jak ConfigMap, obiekt Secret można udostępnić w kontenerze jako zmienne środowiskowe lub plik na jego dysku. W następnym przykładzie przypiszemy zmiennej środowiskowej wartość z Secret:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordWykonaj następującą komendę w repozytorium demo, aby zastosować manifesty:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" skonfigurowano
secret "demo-secret" utworzonoJak wcześniej, przekieruj lokalny port do wdrożenia, aby zobaczyć wynik w przeglądarce:
kubectl port-forward deploy/demo 9999:8888
Przekierowywanie z 127.0.0.1:9999 -> 8888
Przekierowywanie z [::1]:9999 -> 8888Po otwarciu adresu :9999/ powinieneś zobaczyć następujące:
Magiczne słowo to "xyzzy"
Zapis obiektów Secret do plików
W tym przykładzie podłączymy obiekt Secret do kontenera w postaci pliku. Kod znajduje się w folderze hello-secret-file repozytorium demo.
Aby podłączyć Secret w postaci pliku, użyjemy następującego wdrożenia:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-file
ports:
- containerPort: 8888
volumeMounts:
- name: demo-secret-volume
mountPath: "/secrets/"
readOnly: true
volumes:
- name: demo-secret-volume
secret:
secretName: demo-secretPodobnie jak w podrozdziale „Tworzenie plików konfiguracyjnych z obiektów ConfigMap” na s. 240, tworzymy wolumen (w tym przypadku demo-secret-volume) i podpinamy go do kontenera w sekcji volumeMounts. W polu mountPath wskazano /secrets, dlatego Kubernetes utworzy w tym folderze po jednym pliku dla każdej pary „klucz — wartość” zdefiniowanej w obiekcie Secret.
W naszym przykładzie zdefiniowaliśmy tylko jedną parę „klucz — wartość” o nazwie magicWord, dlatego manifest utworzy w kontenerze jeden plik /secrets/magicWord z zaszyfrowanymi danymi, dostępnym wyłącznie do odczytu.
Jeśli zastosujesz ten manifest w taki sam sposób, jak w poprzednim przykładzie, powinieneś uzyskać ten sam rezultat:
Magiczne słowo to "xyzzy"
Odczyt obiektów Secret
W poprzednim rozdziale użyliśmy komendy kubectl describe, aby wyświetlić zawartość ConfigMap. Czy można to samo zrobić z Secret?
kubectl describe secret/demo-secret
Nazwa: demo-secret
Namespace: default
Etykiety:
Adnotacje:
Typ: Opaque
Dane
====
magicWord: 5 bajtówZauważ, że same dane nie są wyświetlane. Obiekty Secret w Kubernetes mają typ Opaque: oznacza to, że ich zawartość nie jest pokazywana w wyniku kubectl describe, w logach i terminalu, dzięki czemu niemożliwe jest przypadkowe ujawnienie poufnych informacji.
Aby wyświetlić zakodowaną wersję poufnych danych w formacie YAML, użyj polecenia kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Co to za eHl6enk=, zupełnie nie przypominające naszej wartości początkowej? W rzeczywistości jest to obiekt Secret przedstawiony w kodowaniu base64. Base64 to schemat kodowania dowolnych danych binarnych w postaci ciągu znaków.
Ponieważ poufne informacje mogą być binarne i niedostępne do wyprowadzenia (jak w przypadku klucza szyfrowania TLS), obiekty Secret zawsze są przechowywane w formacie base64.
Tekst beHl6enk= jest wersją naszego sekretnego słowa xyzzy, zakodowaną w base64. Można to potwierdzić, wykonując polecenie base64 —decode w terminalu:
echo "eHl6enk=" | base64 --decode
xyzzyTak więc, mimo że Kubernetes chroni Cię przed przypadkowym wyprowadzaniem poufnych danych w terminalu lub plikach dziennika, posiadając uprawnienia do odczytu obiektów Secret w danej przestrzeni nazw, można uzyskać te dane w formacie base64 i następnie je dekodować.
Jeśli musisz zakodować w base64 jakiś tekst (na przykład, aby umieścić go w Secret), użyj polecenia base64 bez argumentów:
echo xyzzy | base64
eHl6enkKDostęp do obiektów Secret
Kto może czytać i edytować obiekty Secret? To jest określane przez RBAC — mechanizm kontroli dostępu (omówimy to szczegółowo w rozdziale „Wprowadzenie do zarządzania dostępem na podstawie ról” na s. 258). Jeśli korzystasz z klastra, w którym system RBAC jest nieobecny lub nieaktywny, wszystkie Twoje obiekty Secret są dostępne dla wszystkich użytkowników i kontenerów (później wyjaśnimy, że nie powinieneś mieć żadnego komercyjnego klastra bez RBAC).
Pasywne szyfrowanie danych
A co z tymi, którzy mają dostęp do bazy danych etcd, w której Kubernetes przechowuje wszystkie swoje informacje? Czy mogą oni odczytać poufne dane, nie mając praw do odczytu obiektów Secret przez API?
Od wersji 1.7 Kubernetes obsługuje pasywne szyfrowanie danych. Oznacza to, że poufne informacje wewnątrz etcd są przechowywane na dysku w postaci zaszyfrowanej i nie mogą być odczytane nawet przez osoby posiadające bezpośredni dostęp do bazy danych. Do ich odszyfrowania potrzebny jest klucz, który posiada tylko serwer API Kubernetes. W prawidłowo skonfigurowanym klastrze pasywne szyfrowanie powinno być włączone.
Możesz sprawdzić, czy pasywne szyfrowanie działa w twoim klastrze, wykonując następujące polecenie:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Jeśli nie widzisz flagi experimental-encryption-provider-config, to pasywne szyfrowanie nie jest włączone. W przypadku korzystania z Google Kubernetes Engine lub innych usług zarządzających Kubernetes twoje dane są szyfrowane za pomocą innego mechanizmu, dlatego flaga ta będzie nieobecna. Zapytaj swojego dostawcę Kubernetes, czy zawartość etcd jest szyfrowana.
Przechowywanie poufnych danych
Są takie zasoby Kubernetes, których nigdy nie należy usuwać z klastra: na przykład wyjątkowo ważne obiekty Secret. Możesz zapobiec usunięciu zasobu za pomocą adnotacji dostarczanej przez menedżera Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepStrategie zarządzania obiektami Secret
W przykładzie z poprzedniej sekcji poufne dane były chronione przed nieautoryzowanym dostępem zaraz po zapisaniu w klastrze. Jednak w plikach manifestów były przechowywane w postaci zwykłego tekstu.
Nigdy nie powinieneś umieszczać poufnych informacji w plikach, które są w systemie kontroli wersji. Jak więc bezpiecznie zarządzać i przechowywać takie informacje, zanim zastosujesz je w klastrze Kubernetes?
Możesz wybrać dowolne narzędzia lub strategie do pracy z poufnymi danymi w swoich aplikacjach, ale mimo to będziesz musiał odpowiedzieć przynajmniej na następujące pytania.
- Gdzie przechowywać poufne dane, aby były wysoko dostępne?
- Jak udostępnić poufne dane dla swoich aktywnych aplikacji?
- Co powinno się dziać z twoimi aplikacjami, gdy zastępujesz lub edytujesz poufne dane?
O autorach
John Arundel jest konsultantem z 30-letnim doświadczeniem w branży komputerowej. Napisał kilka książek i współpracuje z wieloma firmami z różnych krajów, doradzając im w kwestiach infrastruktury opartej na chmurze oraz Kubernetes. W wolnym czasie interesuje się surfingiem, dobrze strzela z pistoletu i amatorsko gra na pianinie. Mieszka w bajkowym domku w Kornwalii, Anglia.
Justin Domingus — inżynier administracji systemów, pracujący w środowisku DevOps z Kubernetes i technologiami chmurowymi. Lubi spędzać czas na świeżym powietrzu, pić kawę, łowić kraby i siedzieć przy komputerze. Mieszka w Seattle, w stanie Waszyngton, razem z wspaniałym kotem i jeszcze wspanialszą żoną, która jednocześnie jest jego najlepszym przyjacielem, Edriann.
» Więcej szczegółów o książce można znaleźć na
»
»
Dla użytkowników Habr zniżka 25% przy użyciu kuponu — Kubernetes
Po dokonaniu płatności za wersję papierową książki, na e-mail zostanie wysłana elektroniczna wersja książki.
Źródło: habr.com
