Kniha „Kubernetes for DevOps“

Kniha „Kubernetes for DevOps“ Dobrý deň, obyvatelia Khabra! Kubernetes je jedným z kľúčových prvkov moderného cloudového ekosystému. Táto technológia poskytuje spoľahlivosť, škálovateľnosť a odolnosť voči virtualizácii kontajnerov. John Arundel a Justin Domingus hovoria o ekosystéme Kubernetes a predstavujú osvedčené riešenia každodenných problémov. Krok za krokom si vytvoríte vlastnú cloudovú natívnu aplikáciu a vytvoríte infraštruktúru na jej podporu, nastavíte vývojové prostredie a priebežné nasadzovanie, ktoré vám pomôže pri práci na vašich ďalších aplikáciách.

• Začnite s kontajnermi a Kubernetes od základov: na naučenie sa témy nie sú potrebné žiadne špeciálne skúsenosti. • Spustite svoje vlastné klastre alebo si vyberte spravovanú službu Kubernetes od Amazonu, Google atď. • Použite Kubernetes na správu životného cyklu kontajnera a spotreby zdrojov. • Optimalizujte klastre na základe nákladov, výkonu, odolnosti, výkonu a škálovateľnosti. • Naučte sa najlepšie nástroje na vývoj, testovanie a nasadzovanie vašich aplikácií. • Využite súčasné priemyselné postupy na zaistenie bezpečnosti a kontroly. • Implementujte princípy DevOps vo vašej spoločnosti, 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 administratívnych oddelení zodpovedných za servery, aplikácie a služby, ako aj pre vývojárov zapojených do budovania nových cloudových služieb alebo migrácie existujúcich aplikácií do Kubernetes a cloudu. Nebojte sa, nemusíte vedieť pracovať s Kubernetes alebo kontajnermi – všetko vás naučíme.

Skúsení používatelia Kubernetes tiež nájdu veľkú hodnotu, s hĺbkovým pokrytím tém, ako je RBAC, nepretržité nasadenie, správa citlivých údajov a pozorovateľnosť. Dúfame, že stránky knihy budú určite obsahovať niečo zaujímavé pre vás, bez ohľadu na vaše schopnosti 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í, hovorili sme s lídrami a odborníkmi v tomto odvetví, ako aj s úplnými nováčikami. Nižšie sú uvedené vybrané otázky, na ktoré by chceli nájsť odpoveď v tejto publikácii.

  • „Zaujíma ma, prečo by ste mali venovať čas tejto technológii. Aké problémy to pomôže mne a môjmu tímu vyriešiť?“
  • „Kubernetes vyzerá zaujímavo, ale má pomerne vysokú prekážku vstupu. Príprava jednoduchého príkladu nie je náročná, no ďalšia administrácia a ladenie je náročné. Radi by sme získali spoľahlivé rady o tom, ako ľudia spravujú klastre Kubernetes v reálnom svete a s akými problémami sa pravdepodobne stretneme.“
  • „Pomohla by subjektívna rada. Ekosystém Kubernetes dáva novým tímom príliš veľa možností na výber. Keď existuje niekoľko spôsobov, ako urobiť to isté, ako viete, ktorý z nich je najlepší? Ako si vybrať?

A možno tá najdôležitejšia zo všetkých otázok:

  • "Ako môžem používať Kubernetes bez toho, aby som narušil svoju spoločnosť?"

Úryvok. Konfigurácia a tajné objekty

Schopnosť oddeliť logiku aplikácie Kubernetes od jej konfigurácie (to znamená od akýchkoľvek hodnôt alebo nastavení, ktoré sa môžu časom meniť) je veľmi užitočná. Hodnoty konfigurácie zvyčajne zahŕňajú nastavenia špecifické pre prostredie, adresy DNS služieb tretích strán a overovacie poverenia.

Samozrejme, toto všetko je možné vložiť priamo do kódu, ale tento prístup nie je dostatočne flexibilný. Napríklad zmena konfiguračnej hodnoty by potom vyžadovala, aby ste znova zostavili a nasadili svoj kód. Oveľa lepším riešením by bolo oddeliť konfiguráciu od kódu a prečítať ju zo súboru alebo premenných prostredia.

Kubernetes poskytuje niekoľko rôznych spôsobov správy konfigurácie. Najprv môžete odovzdať hodnoty aplikácii prostredníctvom premenných prostredia špecifikovaných v špecifikácii obalu pod (pozrite si “Premenné prostredia” na strane 192). Po druhé, konfiguračné údaje môžu byť uložené priamo v Kubernetes pomocou objektov ConfigMap a Secret.

V tejto kapitole podrobne preskúmame tieto objekty a pozrieme sa na niektoré praktické prístupy k správe konfigurácie a citlivých údajov pomocou demo aplikácie.

Aktualizácia puzdier pod pri zmene konfigurácie

Predstavte si, že máte nasadenie vo svojom klastri a chcete zmeniť niektoré hodnoty v jeho ConfigMap. Ak použijete tabuľku Helm (pozrite si časť „Kelma: Správca balíkov pre Kubernetes“ na strane 102), môžete automaticky zistiť zmenu konfigurácie a znova načítať kryty modulov v jednom úhľadnom triku. Do špecifikácie nasadenia pridajte nasledujúcu anotáciu:

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

Šablóna nasadenia teraz obsahuje kontrolný súčet konfiguračných parametrov: ak sa parametre zmenia, súčet sa aktualizuje. Ak spustíte upgrade kormidla, Helm zistí, že sa zmenila špecifikácia nasadenia a reštartuje všetky moduly.

Citlivé údaje v Kubernetes

Už vieme, že objekt ConfigMap poskytuje flexibilný mechanizmus na ukladanie a prístup k konfiguračným údajom v klastri. Väčšina aplikácií však obsahuje citlivé a citlivé informácie, ako sú heslá alebo kľúče API. Dá sa uložiť aj do ConfigMap, no toto riešenie nie je ideálne.

Namiesto toho Kubernetes ponúka špeciálny typ objektu určený na ukladanie citlivých údajov: Secret. Ďalej sa pozrime na príklad, ako možno tento objekt použiť v našej demo aplikácii.

Ak chcete začať, pozrite si manifest Kubernetes pre tajný objekt (pozri hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

V tomto príklade je súkromný kľúč magicWord xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Slovo xyzzy je vo svete počítačov všeobecne veľmi užitočné. Podobne ako v prípade ConfigMap môžete do tajného objektu uložiť viacero kľúčov a hodnôt. Tu pre jednoduchosť používame iba jeden pár kľúč – hodnota.

Používanie tajných objektov ako premenných prostredia

Podobne ako ConfigMap, aj objekt Secret môže byť sprístupnený v kontajneri ako premenné prostredia alebo ako súbor na jeho disku. V nasledujúcom príklade priradíme premennú prostredia k hodnote 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

Ak chcete použiť manifesty, spustite nasledujúci príkaz v úložisku ukážok:

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

Ako predtým, prepošlite lokálny port nasadeniu, aby ste videli výsledok vo svojom prehliadači:

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

Pri otváraní adresy localhost:9999/ mali by ste vidieť nasledovné:

The magic word is "xyzzy"

Zápis tajných objektov do súborov

V tomto príklade pripojíme objekt Secret ku kontajneru ako súbor. Kód sa nachádza v priečinku hello-secret-file demo úložiska.

Na pripojenie Secret ako súboru použijeme nasledujúce nasadenie:

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

Rovnako ako v podsekcii „Vytváranie konfiguračných súborov z objektov ConfigMap“ na str. 240, vytvoríme zväzok (v tomto prípade demo-secret-volume) a pripojíme ho ku kontajneru v sekcii volumeMounts v špecifikácii. Pole mountPath je /secrets, takže Kubernetes vytvorí jeden súbor v tomto priečinku pre každý pár kľúč/hodnota definovaný v objekte Secret.

V našom príklade sme definovali iba jeden pár kľúč – hodnota s názvom magicWord, takže manifest vytvorí jeden súbor /secrets/magicWord s citlivými údajmi v kontajneri.

Ak použijete tento manifest rovnakým spôsobom ako predchádzajúci príklad, mali by ste získať rovnaký výsledok:

The magic word is "xyzzy"

Čítanie tajných predmetov

V predchádzajúcej časti sme použili príkaz kubectl description na zobrazenie obsahu mapy ConfigMap. Dá sa to isté urobiť s Secret?

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

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

Data
====
magicWord: 5   bytes

Upozorňujeme, že samotné údaje sa nezobrazujú. Tajné objekty v Kubernetes sú typu Nepriehľadné, čo znamená, že ich obsah sa nezobrazuje v popise kubectl výstup, záznamy denníka alebo terminál, čo znemožňuje náhodné odhalenie citlivých informácií.

Ak chcete zobraziť zakódovanú verziu YAML citlivých údajov, použite príkaz kubectl get:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

base64

Čo je eHl6enk=, úplne odlišné od našej pôvodnej hodnoty? Toto je v skutočnosti tajný objekt reprezentovaný v kódovaní base64. Base64 je schéma na kódovanie ľubovoľných binárnych údajov ako reťazec znakov.

Pretože citlivé informácie môžu byť binárne a nie výstupné (ako je to v prípade šifrovacieho kľúča TLS), tajné objekty sú vždy uložené vo formáte base64.

Text beHl6enk= je verzia nášho tajného slova xyzzy zakódovaná v base64. Môžete to overiť spustením príkazu base64 —decode v termináli:

echo "eHl6enk=" | base64 --decode
xyzzy

Takže zatiaľ čo vás Kubernetes chráni pred náhodným výstupom citlivých údajov v termináli alebo súboroch denníka, ak máte povolenia na čítanie tajných objektov v konkrétnom priestore názvov, tieto údaje môžu byť base64ed a následne dekódované.

Ak potrebujete zakódovať nejaký text pomocou base64 (napríklad ho vložiť do tajomstva), použite príkaz base64 bez argumentov:

echo xyzzy | base64
eHl6enkK

Prístup k tajným objektom

Kto môže čítať a upravovať tajné objekty? Určuje to RBAC, mechanizmus kontroly prístupu (podrobne o tom budeme diskutovať v podsekcii „Úvod do kontroly prístupu na základe rolí“ na strane 258). Ak máte spustený klaster, ktorý nemá RBAC alebo nie je povolený, všetky vaše tajné objekty sú dostupné pre všetkých používateľov a kontajnery (neskôr vysvetlíme, že bez RBAC by ste nemali mať žiadne produkčné klastre).

Pasívne šifrovanie dát

A čo tí, ktorí majú prístup k databáze etcd, kde Kubernetes ukladá všetky svoje informácie? Môžu čítať citlivé údaje bez povolenia na čítanie tajných objektov cez API?

Od verzie 1.7 podporuje Kubernetes pasívne šifrovanie údajov. To znamená, že citlivé informácie vo vnútri etcd sú uložené zašifrované na disku a nemôžu ich prečítať ani tí, ktorí majú priamy prístup k databáze. Na dešifrovanie potrebujete kľúč, ktorý má iba server Kubernetes API. V správne nakonfigurovanom klastri by malo byť povolené pasívne šifrovanie.

Týmto spôsobom môžete skontrolovať, či pasívne šifrovanie vo vašom klastri funguje:

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é. Keď používate Google Kubernetes Engine alebo iné služby správy Kubernetes, vaše údaje sú šifrované pomocou iného mechanizmu, takže príznak nebude prítomný. Overte si u svojho dodávateľa Kubernetes, či je obsah etcd šifrovaný.

Uchovávanie dôverných údajov

Existujú niektoré zdroje Kubernetes, ktoré by sa nikdy nemali odstraňovať z klastra, ako sú napríklad vysoko citlivé tajné objekty. Zdroj môžete chrániť pred odstránením pomocou anotácie poskytnutej správcom Helm:

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

Stratégie správy tajných objektov

V príklade z predchádzajúcej časti boli citlivé dáta chránené pred neoprávneným prístupom ihneď po uložení do klastra. Ale v súboroch manifestu boli uložené ako obyčajný text.

Nikdy by ste nemali umiestňovať dôverné informácie do súborov, ktoré sú v správe verzií. Ako môžete tieto informácie bezpečne spravovať a ukladať pred ich použitím v klastri Kubernetes?

Môžete si zvoliť ľubovoľné nástroje alebo stratégie na zaobchádzanie s citlivými údajmi vo vašich aplikáciách, no aj tak si budete musieť zodpovedať aspoň nasledujúce otázky.

  • Kde by sa mali uchovávať citlivé údaje, aby boli dobre dostupné?
  • Ako sprístupniť citlivé údaje pre vaše aktívne aplikácie?
  • Čo by sa malo stať s vašimi aplikáciami, keď nahradíte alebo upravíte citlivé údaje?

O autoroch

John Arundel je konzultant s 30-ročnými skúsenosťami v počítačovom priemysle. Napísal niekoľko kníh a spolupracuje s mnohými spoločnosťami z rôznych krajín, ktorým radí v oblasti cloudovej infraštruktúry a Kubernetes. Vo voľnom čase rád surfuje, je dobrý strelec z pištole a amatérsky hrá na klavíri. Žije v rozprávkovej chalúpke v Cornwalle v Anglicku.

Justin Domingus — inžinier správy systémov pracujúci v prostredí DevOps s Kubernetes a cloudovými technológiami. Rád trávi čas vonku, pije kávu, papá a sedí pri počítači. Žije v Seattli, Washington, s úžasnou mačkou a ešte úžasnejšou manželkou a najlepšou priateľkou Adrienne.

» Viac podrobností o knihe nájdete na webová stránka vydavateľa
» obsah
» Úryvok

Pre Khabrozhitely zľavu 25 % pomocou kupónu - Kubernetes

Po zaplatení papierovej verzie knihy bude elektronická kniha zaslaná e-mailom.

Zdroj: hab.com

Pridať komentár