Ahoj, Habráři! Kubernetes je jednou z klíčových součástí moderní cloudové ekosystémové struktury. Tato technologie zajišťuje spolehlivost, škálovatelnost a odolnost kontejnerové virtualizace. John Arundel a Justin Domingus vás seznamují s ekosystémem Kubernetes a nabízejí osvědčená řešení každodenních problémů. Krok za krokem si postavíte vlastní cloudově orientované aplikace a vytvoříte infrastrukturu pro jejich podporu, nastavíte vývojové prostředí a kontinuální nasazovací kanál, který vám bude užitečný při práci na dalších aplikacích.
• Začnete pracovat s kontejnery a Kubernetes od základů: není třeba žádné speciální zkušenosti pro studium této problematiky. • Spustíte vlastní clustery nebo si vyberete spravovanou službu Kubernetes od Amazonu, Googlu a dalších. • Použijete Kubernetes pro správu životního cyklu kontejneru a spotřeby zdrojů. • Optimalizujete clustery podle nákladů, výkonu, odolnosti, síly a škálovatelnosti. • Seznámíte se s nejlepšími nástroji pro vývoj, testování a nasazení vašich aplikací. • Využijete aktuální průmyslové praktiky pro zajištění bezpečnosti a kontroly. • Implementujete v společnosti principy DevOps, aby se týmy vývojářů staly flexibilnějšími, rychlejšími a efektivnějšími.
Pro koho je kniha určena
Kniha je nejvíce aktuální pro zaměstnance administrativních oddělení, kteří jsou odpovědní za servery, aplikace a služby, stejně jako pro vývojáře, kteří se zabývají buď vývojem nových cloudových služeb, nebo migrací stávajících aplikací do Kubernetes a cloudu. Nebojte se, není nutné umět pracovat s Kubernetes a kontejnery — vše vás naučíme.
Zkušení uživatelé Kubernetes také naleznou spoustu cenného: kniha se podrobně zabývá takovými tématy, jako je RBAC, kontinuální nasazení, správa citlivých údajů a sledovatelnost. Doufáme, že na stránkách knihy najdete něco zajímavého i pro vás, bez ohledu na vaše dovednosti a zkušenosti.
Na jaké otázky kniha odpovídá
Při plánování a psaní knihy jsme diskutovali o cloudových technologiích a Kubernetes se stovkami lidí, mluvili jsme jak s lídry a experty v oboru, tak s naprostými nováčky. Níže uvádíme jednotlivé otázky, na které by chtěli vidět odpovědi v tomto vydání.
- „Zajímalo by mě, proč bych měl trávit čas touto technologií. Jaké problémy mi a mému týmu pomůže vyřešit?”
- „Kubernetes se zdá být zajímavý, ale má poměrně vysokou vstupní bariéru. Připravit jednoduchý příklad není těžké, ale další správa a ladění odradí. Chtěli bychom dostat spolehlivé rady, jak lidé spravují Kubernetes clustry v reálných podmínkách a s jakými problémy se pravděpodobně setkáme.“
- „Byla by užitečná subjektivní rada. Ekosystém Kubernetes nabízí začínajícím týmům příliš mnoho možností na výběr. Když je možné totéž udělat několika způsoby, jak pochopit, který z nich je nejlepší? Jak učinit výběr?“
A pravděpodobně nejdůležitější ze všech otázek:
- „Jak používat Kubernetes, aniž bychom narušili chod mé společnosti?”
Úryvek. Konfigurace a objekty Secret
Možnost oddělit logiku aplikace Kubernetes od její konfigurace (tj. od jakýchkoli hodnot nebo nastavení, které se mohou v průběhu času změnit) je velmi užitečná. Mezi konfigurační hodnoty obvykle patří parametry určené pro konkrétní prostředí, DNS adresy třetích stran a přihlašovací údaje pro autentizaci.
Samozřejmě, že to vše lze vložit přímo do kódu, ale takový přístup není dostatečně flexibilní. Například pro změnu konfigurační hodnoty by bylo nutné znovu sestavit a nasadit váš kód. Mnohem lepším řešením by bylo oddělit konfiguraci od kódu a načítat ji z souboru nebo proměnných prostředí.
Kubernetes poskytuje několik různých způsobů, jak spravovat konfiguraci. Zaprvé, můžete předávat hodnoty do aplikace prostřednictvím proměnných prostředí uvedených ve specifikaci podu (viz část „Proměnné prostředí“ na str. 192). Zadruhé, konfigurační data lze uchovávat přímo v Kubernetes pomocí objektů ConfigMap a Secret.
V této kapitole podrobně prozkoumáme tyto objekty a zvážíme některé praktické přístupy k řízení konfigurace a důvěrných údajů na příkladu demonstrační aplikace.
Aktualizace podů při změně konfigurace
Představte si, že ve vašem clusteru existuje nasazení a vy chcete změnit některé hodnoty v jeho ConfigMap. Pokud používáte Helm chart (viz část „Helm: správce balíčků pro Kubernetes“ na str. 102), můžete automaticky zjistit změnu konfigurace a restartovat své pady pomocí jednoho elegantního triku. Přidejte následující anotaci do specifikace svého nasazení:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Nyní šablona nasazení obsahuje kontrolní součet parametrů konfigurace: při změně parametrů se součet aktualizuje. Pokud spustíte příkaz helm upgrade, Helm zjistí, že specifikace nasazení byla změněna, a restartuje všechny pady.
Důvěrné údaje v Kubernetes
Již víme, že objekt ConfigMap poskytuje flexibilní mechanismus pro ukládání a přístup ke konfidenčním údajům v clusteru. Nicméně většina aplikací má informace, které jsou tajné a důvěrné: například hesla nebo API klíče. Tyto informace lze také ukládat do ConfigMap, ale toto řešení není ideální.
Místo toho Kubernetes nabízí objekt speciálního typu, který je určen pro ukládání důvěrných údajů: Secret. Dále se podíváme na příklad, jak tento objekt lze použít v naší demonstrační aplikaci.
Nejprve se podívejte na manifest Kubernetes pro objekt Secret (viz hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
V tomto příkladu má tajný klíč magicWord hodnotu xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Slovo xyzzy je obecně velmi užitečné ve světě počítačů. Podobně jako v ConfigMap lze v objektu Secret umístit více klíčů a hodnot. Zde pro jednoduchost používáme pouze jeden pár „klíč – hodnota“.
Použití objektů Secret jako proměnných prostředí
Stejně jako ConfigMap lze objekt Secret zpřístupnit v kontejneru jako proměnné prostředí nebo jako soubor na jeho disku. V následujícím příkladu přiřadíme proměnné prostředí hodnotu ze Secret:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordProveďte následující příkaz v repozitáři demo, abyste aplikovali manifesty:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" nakonfigurován
secret "demo-secret" vytvořenJak bylo dříve, přesměrujte místní port na nasazení, abyste viděli výsledek ve svém prohlížeči:
kubectl port-forward deploy/demo 9999:8888
Přesměrování z 127.0.0.1:9999 -> 8888
Přesměrování z [::1]:9999 -> 8888Při otevření adresy :9999/ byste měli vidět následující:
Tajemné slovo je "xyzzy"
Záznam objektů Secret do souborů
V tomto příkladu připojíme objekt Secret k kontejneru jako soubor. Kód se nachází ve složce hello-secret-file repozitáře demo.
Chcete-li připojit Secret jako soubor, použijeme následující nasazení:
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-secretJak je uvedeno v části "Vytváření konfiguračních souborů z objektů ConfigMap" na str. 240, vytvoříme svazek (v tomto případě demo-secret-volume) a připojíme ho k kontejneru v části specifikace volumeMounts. V poli mountPath je uvedena /secrets, takže Kubernetes vytvoří v této složce jeden soubor pro každý pár "klíč - hodnota" definovaný v objektu Secret.
V našem příkladu jsme definovali pouze jeden pár "klíč - hodnota" s názvem magicWord, takže manifest vytvoří v kontejneru jeden soubor /secrets/magicWord s důvěrnými údaji, přístupný pouze pro čtení.
Pokud použijete tento manifest stejným způsobem jako v předchozím příkladu, měl by být stejný výsledek:
Tajemné slovo je "xyzzy"
Čtení objektů Secret
V předchozí části jsme použili příkaz kubectl describe k výpisu obsahu ConfigMap. Můžeme totéž udělat s Secret?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels:
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesVšimněte si, že samotná data se nezobrazují. Objekty Secret v Kubernetes mají typ Opaque: to znamená, že jejich obsah se nezobrazuje ve výstupu kubectl describe, logách a terminálu, což brání náhodnému odhalení důvěrných informací.
Chcete-li zobrazit zakódovanou verzi citlivých dat ve formátu YAML, použijte příkaz kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Co je eHl6enk=, vůbec to není podobné našemu původnímu hodnotě? Ve skutečnosti je to objekt Secret, který je reprezentován ve kódování base64. Base64 je schéma kódování libovolných binárních dat jako řetězce znaků.
Protože citlivé informace mohou být binární a nedostupné pro výstup (například v případě klíče šifrování TLS), objekty Secret jsou vždy uloženy ve formátu base64.
Text beHl6enk= je verzí našeho tajného slova xyzzy, zakódovanou v base64. To lze ověřit, pokud v terminálu provedete příkaz base64 --decode:
echo "eHl6enk=" | base64 --decode
xyzzyTakže i když Kubernetes chrání vás před náhodným výstupem citlivých dat v terminálu nebo v logovacích souborech, pokud máte oprávnění k přečtení objektů Secret v určitém jmenném prostoru, lze tato data získat ve formátu base64 a poté je dekódovat.
Pokud potřebujete zakódovat nějaký text do base64 (například abyste jej umístili do Secret), použijte příkaz base64 bez argumentů:
echo xyzzy | base64
eHl6enkKPřístup k objektům Secret
Kdo může číst a upravovat objekty Secret? To se určuje pomocí RBAC — mechanismus kontroly přístupu (podrobněji to budeme probírat v části „Úvod do správy přístupu založené na rolích“ na str. 258). Pokud používáte klastr, ve kterém systém RBAC chybí nebo není povolen, všechny vaše objekty Secret jsou dostupné jakýmkoli uživatelům a kontejnerům (později vysvětlíme, že byste neměli mít žádný produkční klastr bez RBAC).
Pasivní šifrování dat
A co ti, kteří mají přístup k databázi etcd, ve které Kubernetes uchovává všechny své informace? Mohou číst citlivá data, aniž by měli práva na čtení objektů Secret přes API?
Od verze 1.7 podporuje Kubernetes pasivní šifrování dat. To znamená, že citlivé informace uvnitř etcd jsou na disku uloženy v zašifrované podobě a nemohou být přečteny ani těmi, kdo mají přímý přístup k databázi. K jejich dešifrování je potřeba klíč, který má pouze server API Kubernetes. V správně nakonfigurovaném klastru by mělo být pasivní šifrování povoleno.
Zkontrolovat, zda pasivní šifrování funguje ve vašem klastru, můžete následujícím způsobem:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Pokud nevidíte vlajku experimental-encryption-provider-config, pasivní šifrování není povoleno. Při použití Google Kubernetes Engine nebo jiných služeb pro správu Kubernetes jsou vaše data šifrována pomocí jiného mechanismu, takže vlajka nebude přítomna. Zeptejte se svého poskytovatele Kubernetes, zda je obsah etcd šifrován.
Ukládání citlivých dat
Existují takové prostředky Kubernetes, které by nikdy neměly být z klastru odstraněny: například zvlášť důležité objekty Secret. Můžete zabránit odstranění prostředku pomocí anotace poskytované správcem Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepStrategie správy objektů Secret
V příkladu z předchozího oddílu byla citlivá data chráněna před neoprávněným přístupem hned po jejich uložení do klastru. V souborech manifestů však byla uchovávána v podobě prostého textu.
Nikdy byste neměli ukládat citlivé informace do souborů, které jsou v systému správy verzí. Jak tedy bezpečně spravovat a uchovávat takové informace, než je aplikujete do klastru Kubernetes?
Můžete si zvolit jakékoli nástroje nebo strategie pro práci s citlivými daty ve svých aplikacích, ale stále budete muset odpovědět alespoň na následující otázky.
- Kde uchovávat citlivá data, aby byla vysoce dostupná?
- Jak zpřístupnit citlivá data vašim aktivním aplikacím?
- Co se má stát s vašimi aplikacemi, když nahrazujete nebo upravujete citlivá data?
O autorech
John Arundel je konzultantem s 30letou zkušeností v počítačovém průmyslu. Napsal několik knih a spolupracuje s mnoha společnostmi z různých zemí, poskytující poradenství v oblastech cloudové infrastruktury a Kubernetes. Ve volném čase se věnuje surfování, slušně střílí z pistole a amatérsky hraje na klavír. Žije v pohádkovém domku v Cornwallu, Anglie.
Justin Domingus je inženýr systémového administrativního, pracující v prostředí DevOps s Kubernetes a cloudovými technologiemi. Rád tráví čas venku, pije kávu, chytá kraby a sedí u počítače. Žije v Seattlu, stát Washington, spolu s úžasným kočkem a ještě úžasnější manželkou a zároveň nejlepším přítelem Adrienne.
» Podrobnosti o knize naleznete na
»
»
Pro uživatele Habr sleva 25 % s kupónem — Kubernetes
Po uhrazení tištěné verze knihy bude elektronická kniha zaslána na e-mail.
Zdroj: habr.com
