Sziasztok Khabro lakosai! A Kubernetes a modern felhő-ökoszisztéma egyik kulcseleme. Ez a technológia megbízhatóságot, méretezhetőséget és rugalmasságot biztosít a konténervirtualizációhoz. John Arundel és Justin Domingus a Kubernetes ökoszisztémáról beszélnek, és bevált megoldásokat mutatnak be a mindennapi problémákra. Lépésről lépésre elkészíti saját felhőalapú natív alkalmazását, és létrehozza az azt támogató infrastruktúrát, létrehoz egy fejlesztői környezetet és egy folyamatos telepítési folyamatot, amely segít a következő alkalmazásokon való munka során.
• Kezdje el a konténereket és a Kuberneteseket az alapoktól: nincs szükség különleges tapasztalatra a téma elsajátításához. • Futtassa saját fürtjeit, vagy válasszon felügyelt Kubernetes szolgáltatást az Amazontól, a Google-tól stb. • A Kubernetes segítségével kezelheti a tárolók életciklusát és erőforrás-felhasználását. • A fürtök optimalizálása költség, teljesítmény, rugalmasság, teljesítmény és méretezhetőség alapján. • Ismerje meg a legjobb eszközöket az alkalmazások fejlesztéséhez, teszteléséhez és üzembe helyezéséhez. • Használja ki a jelenlegi iparági gyakorlatokat a biztonság és az ellenőrzés biztosítása érdekében. • Alkalmazza a DevOps elveket az egész vállalaton belül, hogy a fejlesztőcsapatok rugalmasabban, gyorsabban és hatékonyabban tudjanak fellépni.
Kinek szól a könyv?
A könyv leginkább a szerverekért, alkalmazásokért és szolgáltatásokért felelős adminisztrációs részlegek alkalmazottai, valamint az új felhőszolgáltatások kiépítésében vagy a meglévő alkalmazások Kubernetesre és a felhőbe való migrálásában részt vevő fejlesztők számára releváns. Ne aggódjon, nem kell tudnia, hogyan kell Kubernetes-szel vagy konténerekkel dolgozni – mi mindent megtanítunk.
A tapasztalt Kubernetes-felhasználók is sok értéket találnak majd az olyan témák mélyreható ismertetésével, mint az RBAC, a folyamatos telepítés, az érzékeny adatok kezelése és a megfigyelhetőség. Reméljük, hogy a könyv oldalain minden bizonnyal találsz valami érdekeset az Ön számára, függetlenül az Ön képességeitől és tapasztalataitól.
Milyen kérdésekre ad választ a könyv?
A könyv tervezése és írása során több száz emberrel beszélgettünk a felhőtechnológiáról és a Kubernetesről, valamint az iparág vezetőivel és szakértőivel, valamint teljesen újoncokkal beszélgettünk. Az alábbiakban olyan kérdéseket sorolunk fel, amelyekre választ szeretnének kapni ebben a kiadványban.
- „Érdekel, miért érdemes időt szánni erre a technológiára. Milyen problémák megoldásában segít nekem és a csapatomnak?”
- „A Kubernetes érdekesnek tűnik, de meglehetősen magas belépési korlátja van. Egy egyszerű példa elkészítése nem nehéz, de a további adminisztráció és hibakeresés ijesztő. Szeretnénk megbízható tanácsokat kapni arról, hogyan kezelik az emberek a Kubernetes-klasztereket a való világban, és milyen problémákkal találkozhatunk majd."
- „A szubjektív tanács hasznos lenne. A Kubernetes ökoszisztéma túl sok választási lehetőséget kínál az új csapatoknak. Ha többféleképpen is megteheti ugyanazt, honnan tudja, melyik a legjobb? Hogyan válasszunk?
És talán a legfontosabb az összes kérdés közül:
- "Hogyan használhatom a Kubernetes-t anélkül, hogy megzavarnám a cégemet?"
Kivonat. Konfiguráció és titkos objektumok
Nagyon hasznos az a képesség, hogy a Kubernetes-alkalmazás logikáját elválasztja a konfigurációjától (vagyis minden olyan értéktől vagy beállítástól, amely idővel változhat). A konfigurációs értékek általában környezetspecifikus beállításokat, harmadik féltől származó DNS-címeket és hitelesítési adatokat tartalmaznak.
Természetesen mindezt közvetlenül bele lehet tenni a kódba, de ez a megközelítés nem elég rugalmas. Például egy konfigurációs érték megváltoztatásához újra létre kell hoznia és telepítenie kell a kódot. Sokkal jobb megoldás az lenne, ha a konfigurációt elválasztanánk a kódtól, és kiolvasnánk egy fájlból vagy környezeti változókból.
A Kubernetes számos különféle módot kínál a konfiguráció kezelésére. Először is átadhat értékeket az alkalmazásnak a pod wrapper specifikációjában megadott környezeti változókon keresztül (lásd: „Környezeti változók”, 192. Másodszor, a konfigurációs adatok közvetlenül a Kubernetesben tárolhatók ConfigMap és Secret objektumok használatával.
Ebben a fejezetben részletesen megvizsgáljuk ezeket az objektumokat, és megtekintünk néhány gyakorlati megközelítést a konfigurációk és az érzékeny adatok demóalkalmazással történő kezeléséhez.
A pod shellek frissítése a konfiguráció megváltozásakor
Képzelje el, hogy van egy központi telepítése a fürtben, és meg szeretne változtatni néhány értéket a ConfigMap-ben. Ha a Helm diagramot használja (lásd: „Helm: Kubernetes csomagkezelő”, 102. oldal), automatikusan észlelheti a konfigurációs változást, és egyetlen ügyes trükkel újratöltheti a pod shelleket. Adja hozzá a következő megjegyzést a telepítési specifikációhoz:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}A telepítési sablon most a konfigurációs paraméterek ellenőrző összegét tartalmazza: ha a paraméterek módosulnak, az összeg frissül. Ha futtatja a helm frissítést, a Helm észleli, hogy a telepítési specifikáció megváltozott, és újraindítja az összes pod shellt.
Érzékeny adatok a Kubernetesben
Már tudjuk, hogy a ConfigMap objektum rugalmas mechanizmust biztosít a konfigurációs adatok tárolására és elérésére egy fürtben. A legtöbb alkalmazás azonban érzékeny információkat tartalmaz, például jelszavakat vagy API-kulcsokat. ConfigMap-ben is tárolható, de ez a megoldás nem ideális.
Ehelyett a Kubernetes egy speciális típusú objektumot kínál érzékeny adatok tárolására: Secret. Ezután nézzünk meg egy példát arra, hogyan használható ez az objektum a bemutató alkalmazásunkban.
A kezdéshez vessen egy pillantást a Secret objektum Kubernetes jegyzékébe (lásd hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
Ebben a példában a magicWord privát kulcsa xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Az xyzzy szó általában nagyon hasznos a számítógépek világában. A ConfigMap-hez hasonlóan több kulcsot és értéket is tárolhat egy titkos objektumban. Itt az egyszerűség kedvéért csak egy kulcs-érték párt használunk.
Titkos objektumok használata környezeti változóként
A ConfigMap-hez hasonlóan a Secret objektum elérhetővé tehető a tárolóban környezeti változóként vagy fájlként a lemezén. A következő példában egy környezeti változót rendelünk a Secret értékhez:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordFuttassa a következő parancsot a bemutatótárban a jegyzékek alkalmazásához:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" createdMint korábban, továbbítsa a helyi portot a központi telepítéshez, hogy megtekinthesse az eredményt a böngészőben:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888Cím megnyitásakor :9999/ a következőket kell látnia:
The magic word is "xyzzy"
Titkos objektumok írása fájlokhoz
Ebben a példában a Secret objektumot fájlként csatoljuk a tárolóhoz. A kód a demótár hello-secret-file mappájában található.
A Secret fájlként való összekapcsolásához a következő telepítést használjuk:
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-secretUgyanúgy, mint a „Konfigurációs fájlok létrehozása ConfigMap objektumokból” alszakaszban a 240. o. XNUMX, létrehozunk egy kötetet (jelen esetben demo-secret-volume), és felcsatoljuk a specifikáció volumeMounts részében található tárolóhoz. A mountPath mező a /secrets, ezért a Kubernetes egy fájlt hoz létre ebben a mappában a Secret objektumban meghatározott minden kulcs/érték párhoz.
Példánkban csak egy magicWord nevű kulcs-érték párt definiáltunk, így a jegyzék egyetlen írásvédett /titkok/magicWord fájlt hoz létre érzékeny adatokkal a tárolóban.
Ha ezt a jegyzéket az előző példával megegyező módon alkalmazza, akkor ugyanazt az eredményt kell kapnia:
The magic word is "xyzzy"
Titkos tárgyak olvasása
Az előző részben a kubectl description parancsot használtuk a ConfigMap tartalmának megjelenítésére. Meg lehet csinálni ugyanezt a Secret-el is?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesKérjük, vegye figyelembe, hogy maguk az adatok nem jelennek meg. A Kubernetes titkos objektumai átlátszatlan típusúak, ami azt jelenti, hogy tartalmuk nem jelenik meg a kubectl leírásában, a naplóbejegyzésekben vagy a terminálban, így lehetetlen az érzékeny információk véletlen felfedése.
Az érzékeny adatok YAML kódolt verziójának megtekintéséhez használja a kubectl get parancsot:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Mi az eHl6enk=, teljesen eltér az eredeti értékünktől? Ez valójában egy titkos objektum, base64 kódolásban ábrázolva. A Base64 egy séma tetszőleges bináris adatok karaktersorozatként történő kódolására.
Mivel az érzékeny információk lehetnek binárisak, és nem adhatók ki (mint a TLS titkosítási kulcs esetében), a titkos objektumok mindig base64 formátumban kerülnek tárolásra.
A beHl6enk= szöveg az xyzzy titkos szavunk base64 kódolású változata. Ezt a base64 —decode parancs futtatásával ellenőrizheti a terminálban:
echo "eHl6enk=" | base64 --decode
xyzzyTehát bár a Kubernetes megvédi Önt attól, hogy véletlenül kényes adatokat adjanak ki a terminálban vagy a naplófájlokban, ha olvasási jogosultságai vannak a titkos objektumoknak egy adott névtérben, akkor ezek az adatok base64-re, majd dekódolhatók.
Ha valamilyen szöveget base64-ben kell kódolnia (például titkos kódba helyezni), használja a base64 parancsot argumentumok nélkül:
echo xyzzy | base64
eHl6enkKTitkos objektumok elérése
Ki olvashatja és szerkesztheti a titkos objektumokat? Ezt az RBAC, egy hozzáférés-vezérlési mechanizmus határozza meg (részletesen tárgyaljuk a „Bevezetés a szerepkör-alapú hozzáférés-vezérlésbe” alszakaszban, 258. oldal). Ha olyan fürtöt futtat, amely nem rendelkezik RBAC-val, vagy nincs engedélyezve, akkor az összes titkos objektuma elérhető bármely felhasználó és tároló számára (később elmagyarázzuk, hogy RBAC nélkül nem lehet éles fürtje).
Passzív adattitkosítás
Mi van azokkal, akik hozzáférnek az etcd adatbázishoz, ahol a Kubernetes az összes információt tárolja? Olvashatnak-e bizalmas adatokat anélkül, hogy engedélyük lenne titkos objektumok olvasására az API-n keresztül?
Az 1.7-es verzió óta a Kubernetes támogatja a passzív adattitkosítást. Ez azt jelenti, hogy az etcd-n belüli érzékeny információkat a lemezen titkosítva tárolják, és még azok sem tudják elolvasni, akik közvetlenül hozzáférnek az adatbázishoz. A visszafejtéshez olyan kulcsra van szükség, amellyel csak a Kubernetes API-kiszolgáló rendelkezik. Egy megfelelően konfigurált fürtben engedélyezni kell a passzív titkosítást.
A következőképpen ellenőrizheti, hogy a passzív titkosítás működik-e a fürtben:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Ha nem látja a kísérleti titkosítás-szolgáltató-konfiguráció jelzőt, akkor a passzív titkosítás nincs engedélyezve. A Google Kubernetes Engine vagy más Kubernetes-felügyeleti szolgáltatások használatakor az adatok egy másik mechanizmussal vannak titkosítva, így a jelző nem lesz jelen. Kérdezze meg Kubernetes szállítóját, hogy az etcd tartalom titkosítva van-e.
Bizalmas adatok tárolása
Vannak olyan Kubernetes-erőforrások, amelyeket soha nem szabad eltávolítani a fürtből, például a rendkívül érzékeny titkos objektumokat. A Helm manager által biztosított megjegyzés segítségével megvédheti az erőforrást a törléstől:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepTitkos objektumkezelési stratégiák
Az előző szakasz példájában az érzékeny adatok közvetlenül a fürtben való tárolásuk után védettek a jogosulatlan hozzáféréstől. De a jegyzékfájlokban egyszerű szövegként tárolták őket.
Soha ne helyezzen el bizalmas információkat a verziókezelés alatt álló fájlokba. Hogyan kezelheti és tárolhatja biztonságosan ezeket az információkat, mielőtt alkalmazná őket a Kubernetes-fürtre?
Bármilyen eszközt vagy stratégiát választhat az érzékeny adatok kezelésére az alkalmazásaiban, de továbbra is meg kell válaszolnia legalább a következő kérdéseket.
- Hol kell tárolni az érzékeny adatokat, hogy azok könnyen hozzáférhetők legyenek?
- Hogyan teheted hozzáférhetővé az érzékeny adatokat az aktív alkalmazásaid számára?
- Mi történjen az alkalmazásaival, ha érzékeny adatokat cserél vagy szerkeszt?
A szerzőkről
John Arundel egy tanácsadó, 30 éves tapasztalattal a számítástechnikában. Számos könyvet írt, és számos különböző országbeli céggel dolgozik együtt, tanácsot adva nekik a felhőalapú infrastruktúrával és a Kubernetes-szel kapcsolatban. Szabadidejében szívesen szörföz, jó pisztolylövő, és amatőrként zongorázik. Egy mesebeli nyaralóban él Cornwallban, Angliában.
Justin Domingus — rendszeradminisztrációs mérnök, aki DevOps környezetben dolgozik Kubernetes és felhőtechnológiákkal. Szívesen tölti az időt a szabadban, kávét iszik, rágcsál és a számítógép előtt ül. A washingtoni Seattle-ben él egy csodálatos macskával és egy még csodálatosabb feleségével és legjobb barátjával, Adrienne-nel.
» A könyvvel kapcsolatos további információkért látogasson el ide
»
»
Khabrozhiteli esetében 25% kedvezmény a kuponból - Kubernetes
A könyv papíralapú változatának befizetése után e-könyvet küldünk az e-mail címre.
Forrás: will.com