"Kubernetes DevOps" liburua

Kaixo, Khabro bizilagunak! Kubernetes hodei modernoaren ekosistemaren funtsezko elementuetako bat da. Teknologia honek fidagarritasuna, eskalagarritasuna eta erresilientzia eskaintzen ditu edukiontzien birtualizazioari. John Arundelek eta Justin Domingusek Kubernetes ekosistemari buruz hitz egiten dute eta eguneroko arazoei irtenbide frogatuak aurkezten dizkiete. Pausoz pauso, zure hodeiko jatorrizko aplikazioa sortuko duzu eta berau laguntzeko azpiegitura sortuko duzu, garapen-ingurune bat eta etengabeko inplementazio kanala ezarriko duzu, zure hurrengo aplikazioetan lan egiten duzun bitartean.

• Hasi edukiontziekin eta Kubernetesekin oinarrietatik: ez da esperientzia berezirik behar gaia ikasteko. • Exekutatu zure klusterrak edo aukeratu Kubernetes zerbitzu kudeatu bat Amazon, Google, etab. • Erabili Kubernetes edukiontzien bizi-zikloa eta baliabideen kontsumoa kudeatzeko. • Optimizatu klusterrak kostuan, errendimenduan, erresilientzian, potentzian eta eskalagarritasunean oinarrituta. • Ikasi zure aplikazioak garatzeko, probatzeko eta zabaltzeko tresnarik onenak. • Gaur egungo industria-praktikak aprobetxatu segurtasuna eta kontrola bermatzeko. • Inplementatu DevOps printzipioak zure enpresan, garapen-taldeek malgutasun, azkar eta eraginkortasun handiagoz jokatu dezaten.

Norentzat da liburua?

Liburua zerbitzari, aplikazio eta zerbitzuez arduratzen diren administrazio-sailetako langileentzat da garrantzitsuena, baita hodeiko zerbitzu berriak eraikitzen edo lehendik dauden aplikazioak Kubernetesera eta hodeira migratzen parte hartzen duten garatzaileentzat ere. Ez kezkatu, ez duzu Kubernetesekin edo edukiontziekin lan egiten jakin behar - dena irakatsiko dizugu.

Kubernetes-eko erabiltzaile esperientziadunek ere balio handia aurkituko dute, RBAC, etengabeko hedapena, datu sentikorrak eta behagarritasuna bezalako gaien estaldura sakonarekin. Espero dugu liburuaren orrialdeek zuretzako zerbait interesgarria izango dutela zalantzarik gabe, zure trebetasun eta esperientzia edozein dela ere.

Zer galderei erantzuten die liburuak?

Liburua planifikatzen eta idazten ari ginen bitartean, hodeiko teknologiaz eta Kubernetesez hitz egin genuen ehunka lagunekin, industriako liderrekin eta adituekin eta baita hasiberriekin ere. Jarraian, argitalpen honetan erantzun nahi luketen galdera hautatuak daude.

• “Interesatzen zait zergatik eman behar duzun denbora teknologia honetan. Zein arazo lagunduko dizkizu eta nire taldeari konpontzen?».
• «Kubernetes interesgarria dirudi, baina sartzeko oztopo nahiko altua du. Adibide sinple bat prestatzea ez da zaila, baina administrazio eta arazketa gehiago ikaragarriak dira. Aholku fidagarriak jaso nahi ditugu jendeak Kubernetes klusterrak mundu errealean nola kudeatzen dituen eta zer arazo aurki ditzakegun".
• «Aholku subjektiboak lagungarriak izango lirateke. Kubernetes ekosistemak aukera gehiegi ematen dizkie talde berriei. Gauza bera egiteko hainbat modu daudenean, nola dakizu zein den onena? Nola egin aukeraketa?

Eta agian galdera guztien artean garrantzitsuena:

• "Nola erabil dezaket Kubernetes nire enpresa eten gabe?"

Laburpena. Konfigurazioa eta objektu sekretuak

Kubernetes aplikazio baten logika bere konfiguraziotik (hau da, denboran zehar alda daitezkeen balio edo ezarpenetatik) bereizteko gaitasuna oso erabilgarria da. Konfigurazio-balioek normalean inguruneko ezarpen espezifikoak, hirugarrenen zerbitzuen DNS helbideak eta autentifikazio-kredentzialak barne hartzen dituzte.

Jakina, hori guztia zuzenean sartu daiteke kodean, baina ikuspegi hau ez da nahikoa malgua. Adibidez, konfigurazio-balio bat aldatzeak zure kodea berriro eraiki eta zabaldu beharko zenuke. Askoz irtenbide hobea litzateke konfigurazioa kodeatik bereiztea eta fitxategi edo ingurune-aldagai batetik irakurtzea.

Kubernetes-ek konfigurazioa kudeatzeko hainbat modu eskaintzen ditu. Lehenik eta behin, aplikazioari balioak pasa ditzakezu pod wrapper-en zehaztapenean zehaztutako ingurune-aldagaien bidez (ikus "Ingurumen aldagaiak" 192. orrialdean). Bigarrenik, konfigurazio-datuak zuzenean Kubernetes-en gorde daitezke ConfigMap eta Secret objektuak erabiliz.

Kapitulu honetan, objektu hauek zehatz-mehatz aztertzen ditugu eta demo aplikazio bat erabiliz konfigurazio eta datu sentikorrak kudeatzeko zenbait ikuspegi praktiko aztertuko ditugu.

Pod shell-ak eguneratzea konfigurazioa aldatzen denean

Imajinatu zure klusterrean inplementazio bat duzula eta bere ConfigMap-en balio batzuk aldatu nahi dituzula. Helm diagrama erabiltzen baduzu (ikus "Helm: Kubernetes-erako paketeen kudeatzailea" 102. orrialdean), automatikoki detekta dezakezu konfigurazio-aldaketa bat eta zure pod shell-ak birkargatu trikimailu bikain batean. Gehitu ohar hau zure inplementazioaren zehaztapenari:

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

Inplementazio txantiloiak konfigurazio-parametroen kontrol batura dauka orain: parametroak aldatzen badira, batura eguneratuko da. Helm-en eguneratzea exekutatzen baduzu, Helm-ek inplementazio-zehaztapena aldatu dela detektatuko du eta pod shell guztiak berrabiaraziko ditu.

Datu sentikorrak Kubernetes-en

Dagoeneko badakigu ConfigMap objektuak kluster batean konfigurazio datuak gordetzeko eta atzitzeko mekanismo malgua eskaintzen duela. Hala ere, aplikazio gehienek sentikorra eta sentikorra den informazioa dute, hala nola pasahitzak edo API gakoak. ConfigMap-en ere gorde daiteke, baina irtenbide hau ez da aproposa.

Horren ordez, Kubernetes-ek datu sentikorrak gordetzeko diseinatutako objektu mota berezi bat eskaintzen du: Sekretua. Jarraian, ikus dezagun objektu hau gure demo aplikazioan nola erabil daitekeen adibide bat.

Hasteko, begiratu Kubernetesen manifestuari Sekretua objektuari (ikus hello-secret-env/k8s/secret.yaml):

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

Adibide honetan, magicWord gako pribatua xyzzy da (en.wikipedia.org/wiki/Xyzzy_(informatika)). Xyzzy hitza, oro har, oso erabilgarria da ordenagailuen munduan. ConfigMap-en antzera, objektu sekretu batean hainbat gako eta balio gorde ditzakezu. Hemen, sinpletasunerako, gako-balio bikote bakarra erabiltzen dugu.

Objektu sekretuak ingurune-aldagai gisa erabiltzea

ConfigMap bezala, Secret objektua edukiontzian erabil daiteke ingurune-aldagai gisa edo bere diskoko fitxategi gisa. Hurrengo adibidean, Secret-eko balioari ingurune-aldagai bat esleituko diogu:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

Exekutatu komando hau demo-biltegian manifestuak aplikatzeko:

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

Lehen bezala, birbidali tokiko ataka inplementaziora, emaitza zure arakatzailean ikusteko:

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

Helbide bat irekitzean localhost:9999/ honako hau ikusi beharko zenuke:

The magic word is "xyzzy"

Objektu sekretuak fitxategietan idaztea

Adibide honetan, Secret objektua edukiontziari erantsiko diogu fitxategi gisa. Kodea demo-biltegiko hello-secret-file karpetan dago.

Secret fitxategi gisa konektatzeko, inplementazio hau erabiliko dugu:

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

"ConfigMap objektuetatik konfigurazio fitxategiak sortzea" azpiatalean bezala. 240, bolumen bat sortzen dugu (kasu honetan demo-sekretua-bolumena) eta ontzian muntatzen dugu zehaztapeneko bolumen-muntaketak atalean. mountPath eremua /secrets da, beraz, Kubernetes-ek fitxategi bat sortuko du karpeta honetan Sekretua objektuan definitutako gako/balio bikote bakoitzeko.

Gure adibidean, magicWord izeneko gako-balio bikote bakarra definitu dugu, beraz, manifestuak irakurtzeko soilik den fitxategi bakarra sortuko du /secrets/magicWord edukiontzian datu sentikorrak dituena.

Manifestu hau aurreko adibidearen modu berean aplikatzen baduzu, emaitza bera lortu beharko zenuke:

The magic word is "xyzzy"

Objektu sekretuak irakurtzea

Aurreko atalean, kubectl describe komandoa erabili dugu ConfigMap baten edukia bistaratzeko. Gauza bera egin al daiteke Secret-ekin?

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

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

Data
====
magicWord: 5   bytes

Kontuan izan datuak berak ez direla bistaratzen. Kubernetes-en objektu sekretuak Opaque motakoak dira, hau da, haien edukia ez da erakusten kubectl-en irteeran, erregistroko sarreretan edo terminalean, eta ezinezkoa da ustekabean informazio sentikorra agertzea.

Datu sentikorren YAML bertsio kodetua ikusteko, erabili kubectl get komandoa:

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

base64

Zer da eHl6enk=, gure jatorrizko baliotik guztiz ezberdina? Hau benetan objektu sekretua da, base64 kodifikazioan irudikatua. Base64 datu bitar arbitrarioak karaktere kate gisa kodetzeko eskema bat da.

Informazio sentikorra bitarra izan daitekeenez eta ez atera daitekeenez (TLS enkriptazio-gakoarekin gertatzen den bezala), objektu sekretuak base64 formatuan gordetzen dira beti.

BeHl6enk= testua gure xyzzy hitz sekretuaren base64 kodetutako bertsioa da. Hau egiazta dezakezu base64 —decode komandoa terminalean exekutatuz:

echo "eHl6enk=" | base64 --decode
xyzzy

Beraz, Kubernetes-ek terminalean edo erregistro-fitxategietan datu sentikorrak ustekabean ateratzetik babesten zaituen arren, izen-espazio zehatz batean objektu sekretuei buruzko baimenak irakurri badituzu, datu horiek oinarri64 egin eta gero deskodetu daitezke.

Base64 testuren bat kodetu behar baduzu (adibidez, Sekretu batean jartzeko), erabili base64 komandoa argumenturik gabe:

echo xyzzy | base64
eHl6enkK

Objektu sekretuak atzitzea

Nork irakurri eta edita ditzake objektu sekretuak? Hau RBAC-ek zehazten du, sarbide-kontroleko mekanismo batek (xehe-xehe eztabaidatuko dugu "Roletan oinarritutako sarbide-kontrolaren sarrera" azpiatalean 258. orrialdean). RBAC ez duen edo gaituta ez dagoen kluster bat exekutatzen ari bazara, zure objektu sekretu guztiak erabilgarri egongo dira edozein erabiltzaile eta edukiontzirentzat (geroago azalduko dugu ez duzula ekoizpen-klusterrik izan behar RBAC gabe).

Datuen zifraketa pasiboa

Zer gertatzen da Kubernetes-ek bere informazio guztia gordetzen duen etcd datu-baserako sarbidea dutenekin? Datu sentikorrak irakur al ditzakete APIaren bidez objektu sekretuak irakurtzeko baimenik gabe?

1.7 bertsioaz geroztik, Kubernetes-ek datuen enkriptazio pasiboa onartzen du. Horrek esan nahi du etcd barruan dagoen informazio sentikorra diskoan zifratuta gordetzen dela eta datu-baserako sarbide zuzena dutenek ere ezin dutela irakurri. Deszifratzeko, Kubernetes API zerbitzariak soilik duen gako bat behar duzu. Behar bezala konfiguratutako kluster batean, enkriptazio pasiboa gaitu behar da.

Zifratze pasiboak zure klusterrean funtzionatzen duen egiazta dezakezu modu honetan:

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

Ez baduzu ikusten experimental-encryption-provider-config bandera, enkriptazio pasiboa ez dago gaituta. Google Kubernetes Engine edo Kubernetes kudeaketa-zerbitzu batzuk erabiltzen dituzunean, zure datuak beste mekanismo baten bidez enkriptatzen dira, beraz, bandera ez da egongo. Egiaztatu Kubernetes-en hornitzailearekin etcd edukia enkriptatuta dagoen ikusteko.

Isilpeko datuak gordetzea

Badira Kuberneteseko baliabide batzuk klusterretik inoiz kendu behar ez direnak, adibidez, sentikortasun handiko objektu sekretuak. Helm kudeatzaileak emandako ohar bat erabiliz baliabide bat ezabatzetik babes dezakezu:

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

Objektu sekretuak kudeatzeko estrategiak

Aurreko ataleko adibidean, datu sentikorrak baimenik gabeko sarbideetatik babestuta zeuden klusterean gorde eta berehala. Baina manifestu fitxategietan testu arrunt gisa gordetzen ziren.

Ez zenuke inoiz isilpeko informaziorik jarri behar bertsio-kontrolean dauden fitxategietan. Nola kudeatu eta gorde dezakezu informazio hori zure Kubernetes klusterean aplikatu aurretik?

Zure aplikazioetan datu sentikorrak kudeatzeko edozein tresna edo estrategia aukera ditzakezu, baina hala ere, gutxienez hurrengo galderak erantzun beharko dituzu.

• Non gorde behar dira datu sentikorrak oso eskuragarriak izan daitezen?
• Nola jarri datu sentikorrak zure aplikazio aktiboetarako eskuragarri?
• Zer gertatu beharko litzateke zure aplikazioekin datu sentikorrak ordezkatzen edo editatzen dituzunean?

Egileei buruz

John Arundel informatikaren industrian 30 urteko esperientzia duen aholkularia da. Hainbat liburu idatzi ditu eta hainbat herrialdetako enpresa askorekin lan egiten du, hodeiko natiboko azpiegituretan eta Kubernetesen aholkuak emanez. Aisialdian, surfa gustatzen zaio, pistola-jaurtitzaile ona da eta afizionatu gisa pianoa jotzen du. Ingalaterrako Cornualles-eko maitagarrien txabola batean bizi da.

Justin Domingus — Kubernetes eta hodeiko teknologiekin DevOps ingurunean lan egiten duen sistemen administrazio ingeniaria. Aire librean denbora pasatzea, kafea edatea, karramarroak egitea eta ordenagailuan eserita egotea gustatzen zaio. Seattle-n (Washington) bizi da, katu zoragarri batekin eta are emazte eta lagunik onenarekin, Adrienne.

» Liburuari buruzko xehetasun gehiago hemen aurki daitezke argitaletxearen webgunea
» Edukien taula
» Laburpena

Khabrozhiteleyrentzat % 25eko deskontua kupoia erabiliz - Kubernetes

Liburuaren paperezko bertsioa ordaintzean, liburu elektroniko bat bidaliko da posta elektronikoz.

Iturria: www.habr.com