Ahojte, Habržité! Kubernetes je jednou z kľúčových súčastí modernej cloudovej ekosystémy. Táto technológia zabezpečuje spoľahlivosť, škálovateľnosť a odolnosť kontajnerovej virtualizácie. John Arundel a Justin Domingus rozprávajú o ekosystéme Kubernetes a zoznamujú s overenými riešeniami každodenných problémov. Krok za krokom si vybudujete svoju vlastnú cloudovo orientovanú aplikáciu a vytvoríte infraštruktúru na jej podporu, nastavíte vývojové prostredie a potrubie kontinuálneho nasadzovania, ktoré vám bude užitočné pri práci na nasledujúcich aplikáciách.
• Začnete pracovať s kontajnermi a Kubernetes od základov: na štúdium témy nie sú potrebné žiadne špeciálne skúsenosti. • Spustíte vlastné klastry alebo si vyberiete spravovanú službu Kubernetes od Amazonu, Google a ďalších. • Aplikujete Kubernetes na riadenie životného cyklu kontajnera a spotreby zdrojov. • Optimalizujete klastry podľa ukazovateľov nákladov, výkonu, odolnosti, kapacity a škálovateľnosti. • Preskúmate najlepšie nástroje na vývoj, testovanie a nasadzovanie vašich aplikácií. • Využijete aktuálne priemyselné praktiky na zabezpečenie bezpečnosti a kontroly. • Implementujete v spoločnosti princípy DevOps, aby vývojové tímy mohli konať flexibilnejšie, rýchlejšie a efektívnejšie.
Pre koho je kniha určená
Kniha je najrelevantnejšia pre zamestnancov oddelení administrácie, zodpovedných za servery, aplikácie a služby, ako aj pre vývojárov, ktorí sa zaoberajú buď vytváraním nových cloudových služieb, alebo migráciou existujúcich aplikácií do Kubernetes a cloudu. Nemajte obavy, nie je potrebné vedieť pracovať s Kubernetes a kontajnermi — všetko vás naučíme.
Skúsení používatelia Kubernetes si tu tiež nájdu veľa cenného: zameriava sa na hĺbkové témy, ako sú RBAC, kontinuálne nasadzovanie, správa citlivých údajov a pozorovateľnosť. Dúfame, že na stránkach knihy nájdete niečo zaujímavé aj pre vás, bez ohľadu na vaše zručnosti a skúsenosti.
Na aké otázky kniha odpovedá
Počas plánovania a písania knihy sme diskutovali o cloudových technológiách a Kubernetes so stovkami ľudí, rozprávali sme sa ako s lídrami a odborníkmi v tejto oblasti, tak aj s absolútnymi nováčikmi. Nižšie sú uvedené jednotlivé otázky, na ktoré by radi videli odpovede v tomto vydaní.
- „Zaujíma ma, prečo by som mal tráviť čas touto technológiou. Aké problémy mi a mojej skupine pomôže vyriešiť?“
- „Kubernetes sa javí ako zaujímavá, ale má pomerne vysokú prahovú hodnotu vstupu. Pripraviť jednoduchý príklad nie je problém, ale ďalšie administrácie a ladenie sú zastrašujúce. Rádi by sme dostali spoľahlivé rady o tom, ako ľudia spravujú clustre Kubernetes v reálnych podmienkach a s akými problémami sa pravdepodobne stretneme.“
- „Bola by užitočná subjektívna rada. Ekosystém Kubernetes ponúka začiatočníckym tímom príliš veľa možností na výber. Keď je možné to isté urobiť viacerými spôsobmi, ako si vybrať, ktorý z nich je lepší? Ako urobiť rozhodnutie?“
A pravdepodobne najdôležitejšia zo všetkých otázok:
- „Ako používať Kubernetes, aby sme neohrozili chod mojej firmy?“
Úryvok. Konfigurácia a objekty Secret
Možnosť oddeľovať logiku aplikácie Kubernetes od jej konfigurácie (t.j. akýchkoľvek hodnôt alebo nastavení, ktoré sa môžu časom zmeniť) je veľmi užitočná. Konfiguračné hodnoty sa zvyčajne týkajú parametrov určených pre konkrétne prostredie, DNS adries externých služieb a poverení pre autentifikáciu.
Samozrejme, všetko toto sa dá vložiť priamo do kódu, ale takýto prístup nie je dostatočne flexibilný. Napríklad, na zmenu konfiguračnej hodnoty by ste museli znovu zostaviť a nasadiť svoj kód. Omnoho lepším riešením by bolo oddeliť konfiguráciu od kódu a načítavať ju z súboru alebo premenných prostredia.
Kubernetes poskytuje niekoľko rôznych spôsobov správy konfigurácie. Po prvé, môžete odovzdávať hodnoty do aplikácie prostredníctvom premenných prostredia uvedených v špecifikácii podzložitosti (pozri podsekciu „Premenné prostredia“ na s. 192). Po druhé, konfiguračné údaje je možné uchovávať priamo v Kubernetes pomocou objektov ConfigMap a Secret.
V tejto kapitole podrobne preskúmame tieto objekty a zvážime niektoré praktické prístupy k správe konfigurácie a citlivých údajov na príklade demonštračnej aplikácie.
Aktualizácia pod-obálok pri zmene konfigurácie
Predstavte si, že vo vašom klastri je nasadenie a chcete zmeniť niektoré hodnoty v jeho ConfigMap. Ak používate Helm chart (pozrite si časť "Helm: balíkový správca pre Kubernetes" na str. 102), zmenu konfigurácie a reštart vašich pod-obálok môžete automaticky zistiť pomocou jedného elegantného triku. Pridajte nasledujúcu anotáciu do špecifikácie vášho nasadenia:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Teraz šablóna nasadenia obsahuje kontrolný súčet konfiguračných parametrov: pri zmene parametrov sa súčet aktualizuje. Ak vykonáte príkaz helm upgrade, Helm zistí, že špecifikácia nasadenia sa zmenila, a reštartuje všetky pod-obálky.
Citlivé údaje v Kubernetes
Už vieme, že objekt ConfigMap poskytuje flexibilný mechanizmus na uloženie a prístup k konfiguračným údajom v klastri. Avšak väčšina aplikácií obsahuje informácie, ktoré sú tajné a citlivé: napríklad heslá alebo API kľúče. Tieto údaje je možné uložiť aj v ConfigMap, ale takéto riešenie nie je ideálne.
Namiesto toho Kubernetes ponúka objekt špeciálneho typu, určený na uloženie citlivých údajov: Secret. Nižšie si ukážeme na príklade, ako môže byť tento objekt použitý v našej demonštračnej aplikácii.
Najprv sa pozrite na manifest Kubernetes pre objekt Secret (pozrite si hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
V tomto príklade má tajný kľúč magicWord hodnotu xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Slovo xyzzy je v počítačovom svete veľmi užitočné. Podobne ako v ConfigMap, aj v objekte Secret je možné umiestniť množstvo kľúčov a hodnôt. Tu na zjednodušenie používame iba jeden pár „kľúč - hodnota.“
Používanie objektov Secret ako premenných prostredia
Rovnako ako ConfigMap, aj objekt Secret je možné sprístupniť v kontajneri vo forme premenných prostredia alebo súboru na jeho disku. V nasledujúcom príklade priradíme premenné prostredia hodnotu z Secret:
špec:
kontejnery:
- názov: demo
obraz: cloudnatived/demo:hello-secret-env
porty:
- kontajnerPort: 8888
env:
- názov: GREETING
valueFrom:
secretKeyRef:
názov: demo-secret
kľúč: magicWordVykonajte nasledujúcu príkaz v repozitári demo, aby ste uplatnili manifesty:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" nakonfigurované
secret "demo-secret" vytvorenéAko predtým, presmerujte lokálny port k nasadeniu, aby ste videli výsledok vo svojom prehliadači:
kubectl port-forward deploy/demo 9999:8888
Presmerovanie z 127.0.0.1:9999 -> 8888
Presmerovanie z [::1]:9999 -> 8888Pri otvorení adresy :9999/ by ste mali vidieť nasledovné:
Magické slovo je "xyzzy"
Zápis objektov Secret do súborov
V tomto príklade pripojíme objekt Secret k kontajneru ako súbor. Kód sa nachádza vo foldri hello-secret-file repozitára demo.
Aby sme pripojili Secret ako súbor, použijeme nasledujúce nasadenie:
špec:
kontejnery:
- názov: demo
obraz: cloudnatived/demo:hello-secret-file
porty:
- kontajnerPort: 8888
volumeMounts:
- názov: demo-secret-volume
mountPath: "/secrets/"
readOnly: true
objemy:
- názov: demo-secret-volume
tajný:
secretName: demo-secretTak ako v podkapitole „Vytváranie konfiguračných súborov z objektov ConfigMap“ na s. 240, vytvárame objem (v tomto prípade je to demo-secret-volume) a pripojujeme ho k kontajneru v časti špecifikácie volumeMounts. V poli mountPath je uvedené /secrets, takže Kubernetes vytvorí v tejto zložke jeden súbor pre každú dvojicu „kľúč — hodnota“, definovanú v objekte Secret.
V našom príklade sme definovali iba jednu dvojicu „kľúč — hodnota“ s názvom magicWord, preto manifest vytvorí v kontajneri jeden súbor /secrets/magicWord s dôvernými údajmi, dostupný výlučne na čítanie.
Ak aplikuje tento manifest rovnakým spôsobom ako v predchádzajúcom príklade, mal by sa dosiahnuť rovnaký výsledok:
Magické slovo je "xyzzy"
Čítanie objektov Secret
V predchádzajúcej časti sme použili príkaz kubectl describe na zobrazenie obsahu ConfigMap. Môžeme to isté urobiť so Secret?
kubectl describe secret/demo-secret
Názov: demo-secret
Namespace: default
Štítky:
Poznámky:
Typ: Opaque
Data
====
magicWord: 5 bajtyVšimnite si, že samotné údaje sa nezobrazujú. Objekty Secret v Kubernetes majú typ Opaque: to znamená, že ich obsah nie je zobrazený vo výstupe kubectl describe, zápisoch a termináli, čím sa zabraňuje neúmyselnému odhaleniu dôverných informácií.
Ak chcete zobraziť zašifrovanú verziu dôverných údajov vo formáte YAML, použite príkaz kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Čo je eHl6enk=, vôbec sa to nepodobá na našu pôvodnú hodnotu? V skutočnosti ide o objekt Secret, ktorý je prezentovaný v kódovaní base64. Base64 je schéma kódovania ľubovoľných binárnych údajov do podoby reťazca znakov.
Keďže dôverné informácie môžu byť binárne a neprístupné na výstup (ako napríklad v prípade kľúča šifrovania TLS), objekty Secret sú vždy uchovávané v formáte base64.
Text beHl6enk= je verzia nášho tajného slova xyzzy, kódovaná v base64. Môžete to overiť, ak v termináli spustíte príkaz base64 --decode:
echo "eHl6enk=" | base64 --decode
xyzzyTakže hoci Kubernetes chráni pred náhodným výstupom dôverných údajov v termináli alebo logoch, ak máte práva čítať objekty Secret v určitej namespace, tieto údaje môžete získať vo formáte base64 a následne ich dekódovať.
Ak potrebujete zašifrovať text do formátu base64 (napríklad na jeho umiestnenie do Secret), použite príkaz base64 bez argumentov:
echo xyzzy | base64
eHl6enkKPrístup k objektom Secret
Kto môže čítať a upravovať objekty Secret? To určuje RBAC - mechanizmus kontroly prístupu (podrobnejšie to preberieme v podsekcii „Úvod do správy prístupu na základe rolí“ na str. 258). Ak používate klaster, v ktorom RBAC nie je prítomný alebo je vypnutý, všetky vaše objekty Secret sú dostupné všetkým používateľom a kontajnerom (neskôr vysvetlíme, že by ste nemali mať žiadny priemyselný klaster bez RBAC).
Pasívne šifrovanie údajov
A čo tí, ktorí majú prístup k databáze etcd, v ktorej Kubernetes uchováva všetky svoje informácie? Môžu čítať dôverné údaje bez práv na čítanie objektov Secret cez API?
Od verzie 1.7 Kubernetes podporuje pasívne šifrovanie dát. To znamená, že dôverné informácie vo vnútri etcd sú uložené na disku v zašifrovanej podobe a nemôžu byť prečítané ani tými, ktorí majú priamy prístup k databáze. Na ich dešifrovanie je potrebný kľúč, ktorý má iba server API Kubernetes. V správne nakonfigurovanom klastri by malo byť pasívne šifrovanie povolené.
Overiť, či funguje pasívne šifrovanie vo vašom klastri môžete nasledovne:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Ak nevidíte príznak experimental-encryption-provider-config, pasívne šifrovanie nie je povolené. Pri používaní Google Kubernetes Engine alebo iných služieb na správu Kubernetes sú vaše dáta šifrované pomocou iného mechanizmu, preto táto vlajka bude chýbať. Opýtajte sa svojho poskytovateľa Kubernetes, či je obsah etcd šifrovaný.
Ukladanie dôverných údajov
Existujú také zdroje Kubernetes, ktoré nikdy nemožno odstrániť z klastra: napríklad obzvlášť dôležité objekty Secret. Môžete zabezpečiť, aby bol zdroj chránený pred odstránením pomocou anotácie, ktorú poskytuje správca Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepStratégie správy objektov Secret
V príklade z predchádzajúcej sekcie boli dôverné údaje chránené pred neoprávneným prístupom hneď po uložení do klastra. Ale v súboroch manifestov boli uložené ako obyčajný text.
Nikdy by ste nemali umiestňovať dôverné informácie do súborov, ktoré sú v systéme správy verzií. Ako teda bezpečne spravovať a ukladať takéto informácie pred ich použitím v klase Kubernetes?
Môžete si vybrať akékoľvek nástroje alebo stratégie na prácu s dôvernými údajmi vo svojich aplikáciách, ale aj tak budete musieť aspoň na nasledujúce otázky odpovedať.
- Kde ukladať dôverné údaje, aby boli vysoko dostupné?
- Ako sprístupniť dôverné údaje pre vaše aktívne aplikácie?
- Čo by sa malo stať s vašimi aplikáciami, keď nahrádzate alebo upravujete dôverné údaje?
O autoroch
John Arundel je konzultant s 30-ročnými skúsenosťami v IT sektore. Napísal niekoľko kníh a spolupracuje s mnohými spoločnosťami z rôznych krajín, poskytujúc im poradenstvo v oblasti cloudovej infraštruktúry a Kubernetes. Vo voľnom čase sa venuje surfovaniu, dobre strieľa z pištole a amatérsky hrá na klavíri. Žije v kúzelnom chalúpke v Cornwallu, Anglicko.
Justin Domingus je inžinier systémového administrácie pracujúci v prostredí DevOps s Kubernetes a cloudovými technológiami. Rád trávi čas vonku, pije kávu, loví kraby a sedí za počítačom. Žije v Seattli, štát Washington, spolu so svojím úžasným mačiatkom a ešte úžasnejšou manželkou, ktorá je zároveň jeho najlepším priateľom, Edrienn.
» Podrobnejšie informácie o knihe nájdete na
»
»
Pre Habr čitateľov zľava 25% s kupónom — Kubernetes
Po zaplatení tlačenej verzie knihy vám na e-mail bude zaslaná elektronická kniha.
Zdroj: habr.com
