Kniha „Kubernetes pro DevOps“

Dobrý den, obyvatelé Khabra! Kubernetes je jedním z klíčových prvků moderního cloudového ekosystému. Tato technologie poskytuje spolehlivost, škálovatelnost a odolnost vůči virtualizaci kontejnerů. John Arundel a Justin Domingus hovoří o ekosystému Kubernetes a představují osvědčená řešení každodenních problémů. Krok za krokem si vytvoříte vlastní cloudovou nativní aplikaci a vytvoříte infrastrukturu pro její podporu, nastavíte vývojové prostředí a průběžné nasazování, které vám pomůže při práci na vašich dalších aplikacích.

• Začněte s kontejnery a Kubernetes od základů: k osvojení tématu nejsou potřeba žádné speciální zkušenosti. • Provozujte své vlastní clustery nebo si vyberte spravovanou službu Kubernetes od Amazonu, Google atd. • Použijte Kubernetes ke správě životního cyklu kontejneru a spotřeby zdrojů. • Optimalizujte clustery na základě nákladů, výkonu, odolnosti, výkonu a škálovatelnosti. • Naučte se nejlepší nástroje pro vývoj, testování a nasazení vašich aplikací. • Využijte současné průmyslové postupy k zajištění bezpečnosti a kontroly. • Implementujte principy DevOps v celé vaší společnosti, aby vývojové týmy mohly jednat flexibilněji, rychleji a efektivněji.

Pro koho je kniha určena?

Kniha je nejrelevantnější pro zaměstnance administrativních oddělení odpovědných za servery, aplikace a služby a také pro vývojáře, kteří se podílejí na budování nových cloudových služeb nebo migraci stávajících aplikací do Kubernetes a cloudu. Nebojte se, nemusíte umět pracovat s Kubernetes nebo kontejnery – vše vás naučíme.

Zkušení uživatelé Kubernetes také najdou velkou hodnotu, s hloubkovým pokrytím témat, jako je RBAC, nepřetržité nasazení, správa citlivých dat a pozorovatelnost. Doufáme, že stránky knihy pro vás určitě budou obsahovat něco zajímavého, bez ohledu na vaše schopnosti a zkušenosti.

Na jaké otázky kniha odpovídá?

Při plánování a psaní knihy jsme diskutovali o cloudové technologii a Kubernetes se stovkami lidí, hovořili jsme s lídry v oboru a odborníky i s úplnými nováčky. Níže jsou uvedeny vybrané otázky, na které by rádi viděli odpověď v této publikaci.

• "Zajímá mě, proč byste měli věnovat čas této technologii." Jaké problémy to pomůže mně a mému týmu vyřešit?“
• „Kubernetes vypadá zajímavě, ale má poměrně vysokou bariéru vstupu. Připravit jednoduchý příklad není těžké, ale další administrace a ladění je skličující. Rádi bychom získali spolehlivé rady o tom, jak lidé spravují clustery Kubernetes v reálném světě a s jakými problémy se pravděpodobně setkáme.“
• „Pomohla by subjektivní rada. Ekosystém Kubernetes dává novým týmům příliš mnoho možností na výběr. Když existuje několik způsobů, jak udělat stejnou věc, jak víte, který z nich je nejlepší? Jak si vybrat?

A možná nejdůležitější ze všech otázek:

• "Jak mohu používat Kubernetes, aniž bych narušil svou společnost?"

Výňatek. Konfigurace a tajné objekty

Schopnost oddělit logiku aplikace Kubernetes od její konfigurace (to znamená od jakýchkoli hodnot nebo nastavení, které se mohou v průběhu času měnit) je velmi užitečná. Hodnoty konfigurace obvykle zahrnují nastavení specifická pro prostředí, adresy DNS služeb třetích stran a ověřovací údaje.

To vše lze samozřejmě vložit přímo do kódu, ale tento přístup není dostatečně flexibilní. Například změna hodnoty konfigurace by pak vyžadovala, abyste znovu vytvořili a nasadili svůj kód. Mnohem lepším řešením by bylo oddělit konfiguraci od kódu a načíst ji ze souboru nebo proměnných prostředí.

Kubernetes poskytuje několik různých způsobů správy konfigurace. Nejprve můžete aplikaci předat hodnoty prostřednictvím proměnných prostředí zadaných ve specifikaci modulu wrapper (viz „Proměnné prostředí“ na stránce 192). Za druhé, konfigurační data mohou být uložena přímo v Kubernetes pomocí objektů ConfigMap a Secret.

V této kapitole tyto objekty podrobně prozkoumáme a podíváme se na některé praktické přístupy ke správě konfigurace a citlivých dat pomocí demo aplikace.

Aktualizace pouzdra podu při změně konfigurace

Představte si, že máte nasazení ve svém clusteru a chcete změnit některé hodnoty v jeho ConfigMap. Pokud použijete graf Helm (viz „Kormidla: Správce balíčků pro Kubernetes“ na stránce 102), můžete automaticky detekovat změnu konfigurace a znovu načíst své pouzdra pod jedním úhledným trikem. Přidejte do specifikace nasazení následující anotaci:

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

Šablona nasazení nyní obsahuje kontrolní součet konfiguračních parametrů: pokud se parametry změní, součet bude aktualizován. Pokud spustíte upgrade kormidla, Helm zjistí, že se specifikace nasazení změnila, a restartuje všechny kryty modulů.

Citlivá data v Kubernetes

Již víme, že objekt ConfigMap poskytuje flexibilní mechanismus pro ukládání a přístup ke konfiguračním datům v clusteru. Většina aplikací však obsahuje citlivé a citlivé informace, jako jsou hesla nebo klíče API. Lze jej uložit i do ConfigMap, ale toto řešení není ideální.

Místo toho Kubernetes nabízí speciální typ objektu určený k ukládání citlivých dat: Secret. Dále se podívejme na příklad, jak lze tento objekt použít v naší demo aplikaci.

Chcete-li začít, podívejte se 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 je soukromý klíč magicWord xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Slovo xyzzy je ve světě počítačů obecně velmi užitečné. Podobně jako u ConfigMap můžete do objektu Secret uložit více klíčů a hodnot. Zde pro jednoduchost používáme pouze jeden pár klíč–hodnota.

Použití tajných objektů jako proměnných prostředí

Stejně jako ConfigMap může být objekt Secret zpřístupněn 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ěnnou prostředí k hodnotě 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

Chcete-li použít manifesty, spusťte v demo úložišti následující příkaz:

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

Stejně jako dříve předejte místní port nasazení, abyste viděli výsledek ve svém prohlížeči:

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

Při otevření adresy localhost:9999/ měli byste vidět následující:

The magic word is "xyzzy"

Zápis tajných objektů do souborů

V tomto příkladu připojíme objekt Secret ke kontejneru jako soubor. Kód se nachází ve složce hello-secret-file demo úložiště.

K připojení Secret jako souboru 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-secret

Stejně jako v podsekci „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 jej ke kontejneru v sekci volumeMounts specifikace. Pole mountPath je /secrets, takže Kubernetes vytvoří jeden soubor v této složce pro každý pár klíč/hodnota definovaný v objektu Secret.

V našem příkladu jsme definovali pouze jeden pár klíč–hodnota nazvaný magicWord, takže manifest vytvoří jediný soubor /secrets/magicWord s citlivými daty v kontejneru.

Pokud použijete tento manifest stejným způsobem jako v předchozím příkladu, měli byste získat stejný výsledek:

The magic word is "xyzzy"

Čtení tajných předmětů

V předchozí části jsme použili příkaz kubectl description k zobrazení obsahu ConfigMap. Lze totéž udělat 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á data se nezobrazují. Tajné objekty v Kubernetes jsou typu Neprůhledné, což znamená, že jejich obsah se nezobrazuje v popisu kubectl výstupu, položek protokolu nebo terminálu, což znemožňuje náhodné odhalení citlivých informací.

Chcete-li zobrazit zakódovanou verzi YAML citlivých dat, použijte příkaz kubectl get:

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

base64

Co je eHl6enk=, zcela odlišné od naší původní hodnoty? Toto je ve skutečnosti tajný objekt reprezentovaný v kódování base64. Base64 je schéma pro kódování libovolných binárních dat jako řetězce znaků.

Protože citlivé informace mohou být binární a nevystupují (jako je tomu v případě šifrovacího klíče TLS), jsou tajné objekty vždy uloženy ve formátu base64.

Text beHl6enk= je verze našeho tajného slova xyzzy zakódovaná v base64. Můžete to ověřit spuštěním příkazu base64 —decode v terminálu:

echo "eHl6enk=" | base64 --decode
xyzzy

Takže zatímco vás Kubernetes chrání před náhodným výstupem citlivých dat v terminálu nebo souborech protokolu, pokud máte oprávnění ke čtení u tajných objektů v konkrétním jmenném prostoru, lze tato data base64ed a následně dekódovat.

Pokud potřebujete kódovat base64 nějaký text (například jej vložit do tajného klíče), použijte příkaz base64 bez argumentů:

echo xyzzy | base64
eHl6enkK

Přístup k tajným objektům

Kdo může číst a upravovat tajné objekty? To určuje RBAC, mechanismus řízení přístupu (podrobně o něm pojednáme v podsekci „Úvod do řízení přístupu založeného na rolích“ na straně 258). Pokud provozujete cluster, který nemá RBAC nebo není povolen, všechny vaše tajné objekty jsou dostupné všem uživatelům a kontejnerům (později vysvětlíme, že byste neměli mít žádné produkční clustery bez RBAC).

Pasivní šifrování dat

A co ti, kteří mají přístup k databázi etcd, kde Kubernetes ukládá všechny své informace? Mohou číst citlivá data, aniž by měli oprávnění číst tajné objekty přes API?

Od verze 1.7 podporuje Kubernetes pasivní šifrování dat. To znamená, že citlivé informace uvnitř etcd jsou uloženy zašifrované na disku a nemohou je číst ani ti, kteří mají přímý přístup k databázi. K jeho dešifrování potřebujete klíč, který má pouze server Kubernetes API. Ve správně nakonfigurovaném clusteru by mělo být povoleno pasivní šifrování.

Tímto způsobem můžete zkontrolovat, zda pasivní šifrování ve vašem clusteru funguje:

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

Pokud příznak experimental-encryption-provider-config nevidíte, pasivní šifrování není povoleno. Při používání Google Kubernetes Engine nebo jiných služeb správy Kubernetes jsou vaše data šifrována pomocí jiného mechanismu, takže příznak nebude přítomen. Ověřte si u svého dodavatele Kubernetes, zda je obsah etcd zašifrován.

Uchovávání důvěrných dat

Existují některé prostředky Kubernetes, které by nikdy neměly být z clusteru odstraněny, jako jsou například vysoce citlivé objekty Secret. Zdroj můžete chránit před smazáním pomocí anotace poskytnuté správcem Helm:

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

Strategie správy tajných objektů

V příkladu z předchozí části byla citlivá data chráněna před neoprávněným přístupem ihned po uložení do clusteru. Ale v souborech manifestu byly uloženy jako prostý text.

Nikdy byste neměli umisťovat důvěrné informace do souborů, které jsou ve správě verzí. Jak můžete tyto informace bezpečně spravovat a ukládat, než je použijete na cluster Kubernetes?

Pro nakládání s citlivými daty ve vašich aplikacích si můžete vybrat libovolné nástroje nebo strategie, ale i tak si budete muset odpovědět alespoň na následující otázky.

• Kde by měla být citlivá data uložena, aby byla dobře dostupná?
• Jak zpřístupnit citlivá data vašim aktivním aplikacím?
• Co by se mělo stát s vašimi aplikacemi, když nahradíte nebo upravíte citlivá data?

O autorech

John Arundel je konzultant s 30letou praxí v počítačovém průmyslu. Napsal několik knih a spolupracuje s mnoha společnostmi z různých zemí a radí jim v oblasti cloudové infrastruktury a Kubernetes. Ve volném čase rád surfuje, je dobrý střelec z pistole a amatérsky hraje na klavír. Žije v pohádkové chaloupce v Cornwallu v Anglii.

Justin Domingus — inženýr správy systémů pracující v prostředí DevOps s Kubernetes a cloudovými technologiemi. Rád tráví čas venku, pije kávu, mačká a sedí u počítače. Žije v Seattlu ve Washingtonu s úžasnou kočkou a ještě úžasnější manželkou a nejlepší kamarádkou Adrienne.

» Více podrobností o knize naleznete na webové stránky vydavatele
» obsah
» Výňatek

Pro Khabrozhiteley 25% slevu pomocí kupónu - Kubernetes

Po zaplacení papírové verze knihy bude elektronická kniha zaslána e-mailem.

Zdroj: www.habr.com