Zarezerwuj „Kubernetes dla DevOps”

Witam mieszkańców Khabro! Kubernetes to jeden z kluczowych elementów współczesnego ekosystemu chmurowego. Technologia ta zapewnia niezawodność, skalowalność i odporność na wirtualizację kontenerów. John Arundel i Justin Domingus opowiadają o ekosystemie Kubernetes i przedstawiają sprawdzone rozwiązania codziennych problemów. Krok po kroku zbudujesz własną aplikację natywną w chmurze i utworzysz infrastrukturę do jej obsługi, skonfigurujesz środowisko programistyczne i potok ciągłego wdrażania, które pomogą Ci w pracy nad kolejnymi aplikacjami.

• Zacznij korzystać z kontenerów i Kubernetesa od podstaw: nie jest wymagane żadne specjalne doświadczenie, aby poznać ten temat. • Uruchom własne klastry lub wybierz zarządzaną usługę Kubernetes od Amazon, Google itp. • Używaj Kubernetes do zarządzania cyklem życia kontenerów i zużyciem zasobów. • Optymalizuj klastry w oparciu o koszt, wydajność, odporność, moc i skalowalność. • Poznaj najlepsze narzędzia do tworzenia, testowania i wdrażania aplikacji. • Wykorzystaj aktualne praktyki branżowe, aby zapewnić bezpieczeństwo i kontrolę. • Wdrażaj zasady DevOps w całej firmie, aby zespoły programistów mogły działać bardziej elastycznie, szybciej i wydajniej.

Dla kogo jest książka?

Książka jest szczególnie przydatna dla pracowników działów administracji odpowiedzialnych za serwery, aplikacje i usługi, a także dla programistów zajmujących się budową nowych usług chmurowych lub migracją istniejących aplikacji do Kubernetes i chmury. Nie martw się, nie musisz umieć pracować z Kubernetesem ani kontenerami – wszystkiego Cię nauczymy.

Doświadczeni użytkownicy Kubernetes również znajdą wiele wartości dzięki dogłębnemu omówieniu tematów, takich jak RBAC, ciągłe wdrażanie, zarządzanie wrażliwymi danymi i obserwowalność. Mamy nadzieję, że strony tej książki z pewnością znajdą dla Ciebie coś interesującego, niezależnie od Twoich umiejętności i doświadczenia.

Na jakie pytania odpowiada książka?

Planując i pisząc książkę, rozmawialiśmy o technologii chmurowej i Kubernetesie z setkami osób, rozmawiając z liderami i ekspertami branży, a także zupełnymi nowicjuszami. Poniżej znajdują się wybrane pytania, na które chcieliby, aby odpowiedzi znalazły się w tej publikacji.

• „Interesuje mnie, dlaczego warto spędzać czas na tej technologii. Jakie problemy pomoże mi i mojemu zespołowi rozwiązać?”
• „Kubernetes wydaje się interesujący, ale ma dość wysoką barierę wejścia. Przygotowanie prostego przykładu nie jest trudne, ale dalsza administracja i debugowanie jest zniechęcające. Chcielibyśmy uzyskać rzetelne porady na temat tego, jak ludzie zarządzają klastrami Kubernetes w świecie rzeczywistym i jakie problemy możemy napotkać.”
• „Subiektywna rada byłaby pomocna. Ekosystem Kubernetes daje nowym zespołom zbyt wiele opcji do wyboru. Jeśli to samo można zrobić na kilka sposobów, skąd wiesz, który z nich jest najlepszy? Jak dokonać wyboru?

I być może najważniejsze ze wszystkich pytań:

• „Jak mogę korzystać z Kubernetesa, nie zakłócając pracy mojej firmy?”

Fragment. Konfiguracja i tajne obiekty

Bardzo przydatna jest możliwość oddzielenia logiki aplikacji Kubernetes od jej konfiguracji (czyli od wszelkich wartości czy ustawień, które mogą zmieniać się w czasie). Wartości konfiguracyjne obejmują zazwyczaj ustawienia specyficzne dla środowiska, adresy DNS usług innych firm i dane uwierzytelniające.

Oczywiście wszystko to można umieścić bezpośrednio w kodzie, jednak takie podejście nie jest wystarczająco elastyczne. Na przykład zmiana wartości konfiguracyjnej wymagałaby ponownego skompilowania i wdrożenia kodu. Dużo lepszym rozwiązaniem byłoby oddzielenie konfiguracji od kodu i odczytanie jej z pliku lub zmiennych środowiskowych.

Kubernetes udostępnia kilka różnych sposobów zarządzania konfiguracją. Po pierwsze, możesz przekazać wartości do aplikacji poprzez zmienne środowiskowe określone w specyfikacji opakowania poda (patrz „Zmienne środowiskowe” na stronie 192). Po drugie, dane konfiguracyjne można przechowywać bezpośrednio w Kubernetesie przy użyciu obiektów ConfigMap i Secret.

W tym rozdziale szczegółowo zbadamy te obiekty i przyjrzymy się praktycznym podejściu do zarządzania konfiguracją i wrażliwymi danymi za pomocą aplikacji demonstracyjnej.

Aktualizowanie powłok podów w przypadku zmiany konfiguracji

Wyobraź sobie, że masz wdrożenie w swoim klastrze i chcesz zmienić niektóre wartości w jego ConfigMap. Jeśli korzystasz z wykresu Helm (zobacz „Helm: Menedżer pakietów dla Kubernetes” na stronie 102), możesz automatycznie wykryć zmianę konfiguracji i ponownie załadować powłoki podów w ramach jednej sprytnej sztuczki. Dodaj następującą adnotację do specyfikacji wdrożenia:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

Szablon wdrożenia zawiera teraz sumę kontrolną parametrów konfiguracyjnych: jeśli parametry zostaną zmienione, suma zostanie zaktualizowana. Jeśli uruchomisz aktualizację hełmu, Helm wykryje, że specyfikacja wdrożenia uległa zmianie i ponownie uruchomi wszystkie powłoki pod.

Wrażliwe dane w Kubernetesie

Wiemy już, że obiekt ConfigMap zapewnia elastyczny mechanizm przechowywania i dostępu do danych konfiguracyjnych w klastrze. Jednak większość aplikacji zawiera wrażliwe i poufne informacje, takie jak hasła lub klucze API. Można go również przechowywać w ConfigMap, ale to rozwiązanie nie jest idealne.

Zamiast tego Kubernetes oferuje specjalny typ obiektu przeznaczony do przechowywania wrażliwych danych: Secret. Następnie przyjrzyjmy się przykładowi wykorzystania tego obiektu w naszej aplikacji demonstracyjnej.

Na początek przejrzyj 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 klucz prywatny magicWord to xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Słowo xyzzy jest ogólnie bardzo przydatne w świecie komputerów. Podobnie jak ConfigMap, możesz przechowywać wiele kluczy i wartości w obiekcie Secret. Tutaj, dla uproszczenia, używamy tylko jednej pary klucz-wartość.

Używanie tajnych obiektów jako zmiennych środowiskowych

Podobnie jak ConfigMap, obiekt Secret można udostępnić w kontenerze jako zmienne środowiskowe lub jako plik na dysku. W poniższym przykładzie przypiszemy zmienną środowiskową do wartości z Secret:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

Uruchom następującą komendę w repozytorium demonstracyjnym, aby zastosować manifesty:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created

Tak jak poprzednio, przekaż port lokalny do wdrożenia, aby zobaczyć wynik w przeglądarce:

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

Podczas otwierania adresu localhost:9999/ powinieneś zobaczyć co następuje:

The magic word is "xyzzy"

Zapisywanie tajnych obiektów do plików

W tym przykładzie dołączymy obiekt Secret do kontenera w postaci pliku. Kod znajduje się w folderze hello-secret-file w repozytorium wersji demonstracyjnej.

Aby połączyć Secret jako plik, 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-secret

Podobnie jak w podrozdziale „Tworzenie plików konfiguracyjnych z obiektów ConfigMap” na s. 240, tworzymy wolumen (w tym przypadku demo-secret-volume) i montujemy go w kontenerze w sekcji VolumeMounts specyfikacji. Pole mountPath to /secrets, więc Kubernetes utworzy jeden plik w tym folderze dla każdej pary klucz/wartość zdefiniowanej w obiekcie Secret.

W naszym przykładzie zdefiniowaliśmy tylko jedną parę klucz-wartość o nazwie magicWord, więc manifest utworzy pojedynczy plik tylko do odczytu /secrets/magicWord z wrażliwymi danymi w kontenerze.

Jeśli zastosujesz ten manifest w taki sam sposób, jak w poprzednim przykładzie, powinieneś uzyskać ten sam wynik:

The magic word is "xyzzy"

Czytanie tajnych obiektów

W poprzedniej sekcji użyliśmy polecenia kubectl opisz, aby wyświetlić zawartość ConfigMap. Czy to samo można zrobić z Secret?

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             <none>
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

Należy pamiętać, że same dane nie są wyświetlane. Tajne obiekty w Kubernetesie są typu Opaque, co oznacza, że ​​ich zawartość nie jest pokazywana w wynikach kubectl opisujących, wpisach w dzienniku ani w terminalu, co uniemożliwia przypadkowe ujawnienie wrażliwych informacji.

Aby wyświetlić zakodowaną wersję wrażliwych 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: Opaque

base64

Czym jest eHl6enk=, całkowicie różniące się od naszej pierwotnej wartości? W rzeczywistości jest to obiekt tajny, reprezentowany w kodowaniu base64. Base64 to schemat kodowania dowolnych danych binarnych jako ciąg znaków.

Ponieważ poufne informacje mogą być binarne i nie mogą być wyprowadzane (jak w przypadku klucza szyfrowania TLS), tajne obiekty są zawsze przechowywane w formacie base64.

Tekst beHl6enk= jest zakodowaną w formacie Base64 wersją naszego tajnego słowa xyzzy. Możesz to sprawdzić, uruchamiając polecenie base64 —decode w terminalu:

echo "eHl6enk=" | base64 --decode
xyzzy

Tak więc, chociaż Kubernetes chroni Cię przed przypadkowym wyświetleniem wrażliwych danych w terminalu lub plikach dziennika, jeśli masz uprawnienia do odczytu tajnych obiektów w określonej przestrzeni nazw, dane te mogą zostać zdekodowane w formacie Base64, a następnie zdekodowane.

Jeśli chcesz zakodować tekst w formacie base64 (na przykład, aby umieścić go w tajemnicy), użyj polecenia base64 bez argumentów:

echo xyzzy | base64
eHl6enkK

Dostęp do tajnych obiektów

Kto może czytać i edytować tajne obiekty? Jest to określane przez RBAC, mechanizm kontroli dostępu (omówimy to szczegółowo w podsekcji „Wprowadzenie do kontroli dostępu opartej na rolach” na stronie 258). Jeśli używasz klastra, który nie ma funkcji RBAC lub nie jest włączony, wszystkie Twoje tajne obiekty są dostępne dla wszystkich użytkowników i kontenerów (później wyjaśnimy, że nie powinieneś mieć żadnych klastrów produkcyjnych bez kontroli 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ą czytać wrażliwe dane bez uprawnień do odczytu tajnych obiektów za pośrednictwem interfejsu API?

Od wersji 1.7 Kubernetes obsługuje pasywne szyfrowanie danych. Oznacza to, że poufne informacje zawarte w etcd są przechowywane w postaci zaszyfrowanej na dysku i nie mogą być odczytane nawet przez osoby mające bezpośredni dostęp do bazy danych. Do jego odszyfrowania potrzebny jest klucz, który posiada jedynie serwer Kubernetes API. W prawidłowo skonfigurowanym klastrze powinno być włączone szyfrowanie pasywne.

Możesz sprawdzić, czy szyfrowanie pasywne działa w Twoim klastrze w ten sposób:

kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
        --experimental-encryption-provider-config=...

Jeśli nie widzisz flagi eksperymentalnej-szyfrowania-dostawcy-config, szyfrowanie pasywne nie jest włączone. Podczas korzystania z Google Kubernetes Engine lub innych usług zarządzania Kubernetes Twoje dane są szyfrowane przy użyciu innego mechanizmu, więc flaga nie będzie widoczna. Skontaktuj się ze swoim dostawcą Kubernetes, aby sprawdzić, czy zawartość etcd jest szyfrowana.

Przechowywanie poufnych danych

Istnieją pewne zasoby Kubernetes, których nigdy nie należy usuwać z klastra, takie jak bardzo wrażliwe tajne obiekty. Możesz zabezpieczyć zasób przed usunięciem, korzystając z adnotacji dostarczonej przez menedżera Helm:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

Strategie zarządzania tajnymi obiektami

W przykładzie z poprzedniego rozdziału wrażliwe dane zostały zabezpieczone przed nieuprawnionym dostępem natychmiast po ich zapisaniu w klastrze. Ale w plikach manifestu były one przechowywane jako zwykły tekst.

Nigdy nie należy umieszczać poufnych informacji w plikach objętych kontrolą wersji. Jak bezpiecznie zarządzać tymi informacjami i je przechowywać przed zastosowaniem ich w klastrze Kubernetes?

Możesz wybrać dowolne narzędzia lub strategie obsługi wrażliwych danych w swoich aplikacjach, ale nadal będziesz musiał odpowiedzieć przynajmniej na poniższe pytania.

• Gdzie należy przechowywać wrażliwe dane, aby były łatwo dostępne?
• Jak udostępnić wrażliwe dane aktywnym aplikacjom?
• Co powinno się stać z Twoimi aplikacjami, gdy zastąpisz lub edytujesz wrażliwe dane?

O autorach

Johna Arundela 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 zakresie infrastruktury chmurowej i Kubernetes. W wolnym czasie surfuje, dobrze strzela z pistoletu i amatorsko gra na pianinie. Mieszka w bajkowym domku w Kornwalii w Anglii.

Justin Domingus — inżynier administracji systemami pracujący w środowisku DevOps z technologiami Kubernetes i cloud. Lubi spędzać czas na świeżym powietrzu, pić kawę, krabować i siedzieć przy komputerze. Mieszka w Seattle w stanie Waszyngton ze wspaniałym kotem i jeszcze cudowniejszą żoną i najlepszą przyjaciółką Adrienne.

» Więcej szczegółów na temat książki można znaleźć na stronie strona wydawcy
» Spis treści
» Fragment

Dla Khabrozhiteley 25% zniżki przy użyciu kuponu - Kubernetes

Po opłaceniu papierowej wersji książki, e-mailem zostanie wysłana książka elektroniczna.

Źródło: www.habr.com