Üdvözöljük a Hub közösség tagjait! A Kubernetes a modern felhő-ökológiai rendszer egyik kulcsfontosságú eleme. Ez a technológia megbízhatóságot, skálázhatóságot és a konténeres virtualizáció stabilitását biztosítja. John Arundel és Justin Domingus a Kubernetes ökoszisztémájáról beszél, és bemutatják a mindennapi problémák megoldására vonatkozó bevált megoldásokat. Lépésről-lépésre saját felhő-centrikus alkalmazást fog létrehozni, valamint megépíti a támogatásához szükséges infrastruktúrát, beállítja a fejlesztési környezetet és egy folyamatos telepítési folyamatot, amely hasznos lesz a következő alkalmazások fejlesztéséhez.
• A tartályokkal és a Kubernetes-szel alapoktól kezdve fog dolgozni: nem szükséges különleges tapasztalat a téma megismeréséhez. • Indítson saját klasztereket, vagy válasszon menedzselt Kubernetes szolgáltatást az Amazon, Google és más szolgáltatóktól. • Alkalmazza a Kubernetes-t a konténerek életciklusának és az erőforrások felhasználásának kezelésére. • Optimalizálja a klasztereket a költségek, teljesítmény, megbízhatóság, kapacitás és skálázhatóság szempontjából. • Fedezze fel a legjobb eszközöket az alkalmazások fejlesztéséhez, teszteléséhez és telepítéséhez. • Használja ki a legfrissebb iparági gyakorlatokat a biztonság és a felügyelet érdekében. • Implementálja a DevOps alapelveit a cégnél, hogy a fejlesztőcsapatok rugalmasabban, gyorsabban és hatékonyabban tudjanak működni.
Kinek szól a könyv
A könyv legnagyobb hasznát az adminisztratív osztályok munkatársai érzik, akik a szerverekért, alkalmazásokért és szolgáltatásokért felelősek, valamint azoknak a fejlesztőknek, akik új felhőszolgáltatások kiépítésével vagy a meglévő alkalmazások Kubernetesbe és a felhőbe történő migrálásával foglalkoznak. Ne aggódjon, a Kubernetes és a konténerek használata nem szükséges - mindent megtanítunk.
A Kubernetes tapasztalt felhasználói is sok értékes információt találhatnak: a könyvben mélyebb szinten vizsgáljuk az RBAC-t, a folyamatos telepítést, a bizalmas adatok kezelését és a megfigyelhetőséget. Reméljük, hogy a könyv lapjain érdekes tartalomra bukkannak, függetlenül a készségeiktől és tapasztalataiktó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ákról és a Kubernetesről, mind az iparági vezetőkkel és szakértőkkel, mind az abszolút újoncokkal. Az alábbiakban néhány olyan kérdést találhat, amelyekre válaszokat szeretnének látni ebben a kiadványban.
- »Engem az érdekel, miért érdemes időt szánni erre a technológiára. Milyen problémákat segít megoldani nekem és a csapatomnak?«
- »A Kubernetes érdekesnek tűnik, de eléggé magas a belépési küszöbe. Egy egyszerű példa elkészítése nem nehéz, de a további adminisztráció és hibaelhárítás ijesztő. Szeretnénk megbízható tanácsokat kapni arról, hogy az emberek hogyan kezelik a Kubernetes klasztereket valódi környezetben és milyen problémákkal valószínűleg szembesülünk.«
- »Hasznos lenne egy szubjektív tanács. A Kubernetes ökoszisztéma túl sok lehetőséget kínál a kezdő csapatoknak. Amikor ugyanazt többféleképpen is meg lehet valósítani, hogyan értsük meg, melyik a legjobb? Hogyan válasszunk?«
És talán a legfontosabb kérdés mind közül:
- »Hogyan lehet használni a Kubernetes-t anélkül, hogy megszakítanám a cégem működését?«
Kivonat. Konfiguráció és Secret objektumok
Nagyon hasznos a Kubernetes alkalmazás logikáját elválasztani annak konfigurációjától (azaz bármilyen értéktől vagy beállítástól, amely idővel megváltozhat). A konfigurációs értékek általában a meghatározott környezethez szükséges paramétereket, harmadik féltől származó szolgáltatások DNS-címeit és hitelesítő adatokat tartalmaznak.
Természetesen mindezt közvetlenül a kódba is be lehet helyezni, de ez a megközelítés nem elég rugalmas. Például a konfigurációs érték megváltoztatásához újra kellene fordítani és telepíteni a kódját. Sokkal jobb megoldás lenne a konfigurációt elválasztani a kódtól, és egy fájlból vagy környezeti változókból olvasni.
A Kubernetes több különböző módot kínál a konfiguráció kezelésére. Először is, átadhat értékeket az alkalmazásnak a pod-felületen (lásd a „Környezeti változók” részt a 192. oldalon) megadott környezeti változókon keresztül. Másodszor, a konfigurációs adatokat közvetlenül a Kubernetesben is tárolhatja, ConfigMap és Secret objektumok használatával.
Ebben a fejezetben részletesen megvizsgáljuk ezeket az objektumokat, és megfontolunk néhány gyakorlati megközelítést a konfiguráció és a bizalmas adatok kezelésére egy bemutatóalkalmazás példáján keresztül.
Pod-burok frissítése a konfiguráció megváltozásakor
Képzelje el, hogy a klaszterében van egy telepítés, és szeretne megváltoztatni néhány értéket a ConfigMap-ben. Ha Helm chartot használ (lásd a "Helm: csomagkezelő Kuberneteshez" című részt a 102. oldalon), a konfigurációs változások és a pod-burok újraindítása automatikusan történhet egy elegáns trükk segítségével. Adja hozzá a következő annotációt a telepítése specifikációjához:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Most a telepítés sablonja tartalmazza a konfigurációs paraméterek ellenőrző összegét: a paraméterek megváltozásakor az összeg frissül. Ha végrehajtja a helm upgrade parancsot, a Helm észleli, hogy a telepítés specifikációja megváltozott, és újraindítja az összes pod-burok.
Bizalmas 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 a klaszterben. Azonban a legtöbb alkalmazásnak vannak titkos és bizalmas információi, mint például jelszavak vagy API-kulcsok. Ezeket a ConfigMap-ben is tárolhatja, de ez a megoldás nem ideális.
Ehelyett a Kubernetes egy különleges típusú objektumot kínál, amely kifejezetten bizalmas adatok tárolására szolgál: Secret. Nézzük meg a következő példán, hogyan alkalmazható ez az objektum a bemutatóalkalmazásunkban.
Első lépésként nézze meg a Kubernetes manifestet a Secret objektumhoz (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 titkos kulcs értéke xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Az xyzzy szó általában nagyon hasznos a számítástechnikában. A ConfigMap-hoz hasonlóan a Secret objektumban is több kulcs-érték pár tárolható. Itt egyszerűség kedvéért csak egy "kulcs-érték" párt használunk.
A Secret objektumok használata környezeti változókként
A ConfigMap-hez hasonlóan a Secret objektumot is hozzáférhetővé tehetjük a konténerben környezeti változókként vagy fájlként a lemezen. A következő példában egy környezeti változónak értéket rendelünk a Secret-ből:
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 demo tárolóban a manifesztok alkalmazásához:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" konfigurálva
secret "demo-secret" létrehozvaMint korábban, irányítsa át a helyi portot a telepítéshez, hogy láthassa az eredményt a böngészőjében:
kubectl port-forward deploy/demo 9999:8888
Átirányítás a 127.0.0.1:9999 -> 8888
Átirányítás a [::1]:9999 -> 8888A cím megnyitásakor :9999/ látnia kell a következőt:
A varázsszó: "xyzzy"
A Secret objektumok fájlokba írása
Ebben a példában a Secret objektumot fájlként csatlakoztatjuk a tárolóhoz. A kód a demo tároló hello-secret-file mappájában található.
A Secret fájlként történő csatlakoztatásához az alábbi telepítést fogjuk használni:
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-secretAhogyan a "Konfigurációs fájlok létrehozása ConfigMap objektumokból" szakaszban a 240. oldalon, létrehozunk egy kötetet (jelen esetben a demo-secret-volume-t), és csatlakoztatjuk a tárolóhoz a volumeMounts szakaszban. A mountPath mező a /secrets-re van beállítva, így a Kubernetes létrehoz egy fájlt minden egyes "kulcs-érték" párhoz, amely a Secret objektumban van definiálva.
Példánkban csak egy "kulcs-érték" párt definiáltunk, amelynek neve magicWord, így a manifeszt egy fájlt hoz létre a tárolóban a /secrets/magicWord helyen, amely tartalmazza a bizalmas adatokat, és csak olvasásra érhető el.
Ha ezt a manifesztet ugyanúgy alkalmazza, mint az előző példában, ugyanazt az eredményt kell kapnia:
A varázsszó: "xyzzy"
Secret objektumok olvasása
Az előző szakaszban a kubectl describe parancsot használtuk a ConfigMap tartalmának megjelenítésére. Ugyanezt meg lehet csinálni a Secret-tel is?
kubectl describe secret/demo-secret
Név: demo-secret
Namespace: default
Címkék: <none>
Megjegyzések:
Típus: Opaque
Adatok
====
magicWord: 5 bájtVegye figyelembe, hogy maguk az adatok nem jelennek meg. A Kubernetes Secret objektumai Opaque típusúak: ez azt jelenti, hogy tartalmuk nem jelenik meg a kubectl describe kimenetéből, naplókból és a terminálból, lehetővé téve, hogy ne szivárogjon ki véletlenül bizalmas információ.
A titkos adatok YAML formátumban való 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=, ami egyáltalán nem hasonlít az eredeti értékünkre? Valójában ez egy Secret objektum, amely base64 kódolásban van megjelenítve. A Base64 egy kódolási séma, amely bármilyen bináris adatot karakterlánc formájában ábrázol.
Mivel a titkos információk binárisak lehetnek, és nem elérhetőek a kimenetben (mint például a TLS titkosítási kulcs esetében), a Secret objektumokat mindig base64 formátumban tárolják.
A beHl6enk= szöveg a titkos szavunk, a xyzzy base64 kódolt változata. Ezt könnyedén ellenőrizheti, ha a terminálba beírja a base64 --decode parancsot:
echo "eHl6enk=" | base64 --decode
xyzzyTehát, bár a Kubernetes megvéd attól, hogy véletlenül megjelenítse a titkos adatokat a terminálban vagy a naplófájlokban, ha van olvasási jogosultsága a Secret objektumokhoz egy adott névtérben, ezeket az adatokat base64 formátumban hozzáférhetjük és később dekódolhatjuk.
Ha bármilyen szöveget base64-be szeretne kódolni (például hogy elhelyezze Secret-ben), használja a base64 parancsot argumentumok nélkül:
echo xyzzy | base64
eHl6enkKHozzáférés a Secret objektumokhoz
Ki olvashatja és szerkesztheti a Secret objektumokat? Ezt az RBAC — a hozzáférés-ellenőrzés mechanizmusa határozza meg (erről részletesebben beszélünk a "Szerepkör-alapú hozzáférés-ellenőrzés bevezetése" alfejezetben a 258. oldalon). Ha olyan klasztert használ, amelyben az RBAC hiányzik vagy nincs engedélyezve, minden Secret objektum elérhető bármely felhasználó és konténer számára (később megmagyarázzuk, hogy nem szabad olyan ipari klasztert használni, amely nem rendelkezik RBAC-val).
Passzív adatok titkosítása
És mi a helyzet azokkal, akik hozzáféréssel rendelkeznek az etcd adatbázishoz, ahol a Kubernetes tárolja az összes információját? Olvashatják a titkos adatokat API-n keresztül anélkül, hogy jogosultságuk lenne a Secret objektumok olvasására?
A 1.7-es verziótól kezdve a Kubernetes támogatja az adatok passzív titkosítását. Ez azt jelenti, hogy az érzékeny információk az etcd-ben titkosított formában kerülnek tárolásra a lemezen, és még azok sem olvashatják el, akik közvetlenül hozzáférnek az adatbázishoz. A visszafejtéshez szükséges kulcs csak a Kubernetes API szerveren található. Egy helyesen konfigurált klaszterben a passzív titkosításnak be kell lennie kapcsolva.
A passzív titkosítás működésének ellenőrzésére a klaszterében a következő módon járhat el:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Ha nem látja az experimental-encryption-provider-config flagot, akkor a passzív titkosítás nincs engedélyezve. A Google Kubernetes Engine vagy más Kubernetes menedzsment szolgáltatások használata során az adatai egy másik mechanizmussal vannak titkosítva, ezért a flag hiányozni fog. Kérdezze meg Kubernetes szolgáltatóját, hogy az etcd tartalma titkosítva van-e.
Érzékeny adatok tárolása
Vannak olyan Kubernetes erőforrások, amelyeket soha nem szabad eltávolítani a klaszterből: például a különösen fontos Secret objektumok. Az erőforrást megvédheti az eltávolítástól a Helm ügynök által biztosított annotáció segítségével:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepSecret objektumok kezelési stratégiái
Az előző rész példájában az érzékeny adatokat a klaszterbe való mentés után azonnal megvédték az illetéktelen hozzáféréstől. Azonban a manifest fájlokban ezek sima szövegként voltak tárolva.
Soha ne helyezzen érzékeny információt olyan fájlokba, amelyek verziókezelő rendszerben vannak. Hogyan lehet biztonságosan adminisztrálni és tárolni ezeket az információkat a Kubernetes klaszterhez való alkalmazás előtt?
Bármilyen eszközt vagy stratégiát választhat az alkalmazásaiban található érzékeny adatok kezelésére, de mindenképpen meg kell válaszolnia a következő kérdéseket.
- Hol tárolja az érzékeny adatokat, hogy azok magas rendelkezésre állásúak legyenek?
- Hogyan teheti elérhetővé az érzékeny adatokat aktív alkalmazásai számára?
- Mi történjen az alkalmazásaival, amikor helyettesíti vagy szerkeszti az érzékeny adatokat?
A szerzőkről
John Arundel 30 éves tapasztalattal rendelkező számítástechnikai tanácsadó. Számos könyvet írt, és sok különböző országbeli céggel dolgozik együtt, tanácsot adva nekik a felhőalapú infrastruktúrával és a Kubernetes használatával kapcsolatban. Szabadidejében szörfözni, jól lőni és zongorázni szeret. Egy mesés kis házban él Cornwallban, Angliában.
Justin Domingus — rendszeradminisztrációs mérnök, aki DevOps környezetben dolgozik Kubernetes és felhőtechnológiák terén. Szeret a szabadban lenni, kávét fogyasztani, rákot fogni és a számítógép előtt ülni. Seattle-ben él, Washington államban, egy csodálatos macskával és még csodálatosabb feleségével, aki egyben a legjobb barátja, Adrienne.
» Részletesebben a könyvről a
»
»
A Habr lakói számára 25% kedvezmény a kuponnal — Kubernetes
A papíralapú könyv kifizetése után elektronikus könyv kerül kiküldésre e-mailben.
Forrás: habr.com
