Bogen "Kubernetes for DevOps"

Hej, Habr-borgere! Kubernetes er et af de centrale elementer i det moderne cloud-økosystem. Denne teknologi sikrer pålidelighed, skalerbarhed og robusthed i container-virtualisering. John Arundel og Justin Domingus fortæller om Kubernetes-økosystemet og præsenterer beprøvede løsninger på daglige problemer. Trin for trin vil du opbygge din egen cloud-baserede applikation og skabe en infrastruktur til at understøtte den, konfigurere udviklingsmiljøet og en kontinuerlig implementeringspipeline, der vil være nyttig, når du arbejder på de næste applikationer.

• Du begynder arbejdet med containere og Kubernetes fra bunden: ingen speciel erfaring er nødvendig for at lære om emnet. • Start dine egne klynger eller vælg en administreret Kubernetes-tjeneste fra Amazon, Google mv. • Anvend Kubernetes til at styre containerens livscyklus og ressourceforbrug. • Optimer klynger baseret på omkostninger, ydeevne, robusthed, kapacitet og skalerbarhed. • Udforsk de bedste værktøjer til udvikling, test og implementering af dine applikationer. • Benyt dig af aktuelle branchepraksis for at sikre sikkerhed og kontrol. • Implementer DevOps-principper i virksomheden, så udviklingsteamene kan arbejde mere fleksibelt, hurtigt og effektivt.

For hvem bogen er skrevet

Bogen er særligt relevant for medarbejdere i administrationsafdelinger, der er ansvarlige for servere, applikationer og tjenester, samt for udviklere, der arbejder med enten opbygning af nye cloud-tjenester eller migration af eksisterende applikationer til Kubernetes og skyen. Bekymr dig ikke, du behøver ikke at kunne arbejde med Kubernetes og containere — vi vil lære dig det hele.

Erfarne brugere af Kubernetes vil også finde mange værdifulde indsigter: emner som RBAC, kontinuerlig implementering, håndtering af følsomme data og overvågning vil blive dybdegående behandlet. Vi håber, der vil være noget interessant for dig på bogens sider, uanset dine færdigheder og erfaring.

Hvilke spørgsmål besvarer bogen

Under planlægning og skrivning af bogen diskuterede vi cloud-teknologier og Kubernetes med hundredevis af mennesker, talte både med ledere og eksperter inden for området samt med helt nye brugere. Nedenfor er en række individuelle spørgsmål, hvis svar de gerne vil se i denne publikation.

• "Jeg er interesseret i, hvorfor jeg skal bruge tid på denne teknologi. Hvilke problemer vil den hjælpe mig og mit team med at løse?"
• "Kubernetes virker interessant, men har en ret høj indlæringskurve. At forberede et simpelt eksempel er ikke svært, men den videre administration og fejlfinding kan virke skræmmende. Vi vil gerne have pålidelige råd om, hvordan folk håndterer Kubernetes-klynger under virkelige forhold, og hvilke problemer vi sandsynligvis vil møde."
• "Det ville være nyttigt med subjektiv rådgivning. Kubernetes-økosystemet tilbyder nybegyndervirksomheder alt for mange muligheder at vælge imellem. Når det samme kan gøres på flere måder, hvordan kan man så forstå, hvilken der er den bedste? Hvordan træffer man valget?"

Og måske vigtigst af alt:

• "Hvordan kan jeg bruge Kubernetes uden at forstyrre driften af min virksomhed?"

Uddrag. Konfiguration og Secret-objekter

Muligheden for at adskille Kubernetes-applikationens logik fra dens konfiguration (dvs. fra eventuelle værdier eller indstillinger, der kan ændre sig over tid) er meget nyttig. Konfigurationsværdier omfatter typisk parametre, der er specifikke for et bestemt miljø, DNS-adresser for tredjeparts tjenester og legitimationsoplysninger til godkendelse.

Selvfølgelig kan alle disse placeres direkte i koden, men en sådan tilgang er ikke tilstrækkeligt fleksibel. For eksempel vil det kræve, at du genopbygger og genudruller din kode for at ændre en konfigurationsværdi. En meget bedre løsning ville være at adskille konfigurationen fra koden og læse den fra en fil eller miljøvariabler.

Kubernetes tilbyder flere forskellige måder at administrere konfigurationen på. For det første kan du sende værdier til applikationen via miljøvariabler angivet i pod-specifikationen (se underafsnittet "Miljøvariabler" på s. 192). For det andet kan konfigurationsdata opbevares direkte i Kubernetes ved hjælp af ConfigMap- og Secret-objekter.

I dette kapitel undersøger vi disse objekter detaljeret og ser på nogle praktiske tilgange til konfigurationsstyring og beskyttelse af følsomme data med eksemplet på en demonstrationsapplikation.

Opdatering af pod-skaller ved ændring af konfiguration

Forestil dig, at du har en deployment i dit cluster, og du vil ændre nogle værdier i dens ConfigMap. Hvis du bruger Helm-diagrammet (se afsnittet 'Helm: pakkeadministrator til Kubernetes' på s. 102), kan du automatisk opdage ændringen i konfigurationen og genstarte dine pod-skaller ved hjælp af et enkelt trick. Tilføj følgende annotation til specifikationen af din deployment:

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

Nu indeholder deployment-skabelonen en kontrolsum af konfigurationsparametrene: når parametrene ændres, opdateres summen. Hvis du kører kommandoen helm upgrade, vil Helm opdage, at specificeringen af deployment er ændret, og genstarte alle pod-skaller.

Følsomme data i Kubernetes

Vi ved allerede, at ConfigMap-objektet giver et fleksibelt mekanisme til opbevaring og adgang til konfigurationsdata i clusteret. Men de fleste applikationer har information, der er hemmelig og følsom: for eksempel adgangskoder eller API-nøgler. Det er muligt at opbevare dem i ConfigMap, men denne løsning er ikke ideel.

I stedet tilbyder Kubernetes et objekt af en særlig type, der er designet til at opbevare følsomme data: Secret. Lad os se på et eksempel på, hvordan dette objekt kan bruges i vores demonstrationsapplikation.

Først skal vi tage et kig på Kubernetes-manifestet for Secret-objektet (se hello-secret-env\/k8s\/secret.yaml):

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

I dette eksempel har den hemmelige nøgle magicWord værdien xyzzy (en.wikipedia.org\/wiki\/Xyzzy_(computing)). Ordet xyzzy er faktisk meget nyttigt i computerverdenen. På samme måde som med ConfigMap kan der i Secret-objektet placeres mange nøgler og værdier. Her bruger vi for enkelhedens skyld kun ét nøgle-værdi-par.

Brug af Secret-objekter som miljøvariabler

Ligesom ConfigMap kan Secret-objektet gøres tilgængeligt i containeren som miljøvariabler eller en fil på dens disk. I det følgende eksempel vil vi tildele en miljøvariabel en værdi fra Secret:

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

Kør følgende kommando i demo-repositoriet for at anvende manifests:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" konfigureret
secret "demo-secret" oprettet

Som tidligere, viderefør den lokale port til implementeringen for at se resultatet i din browser:

kubectl port-forward deploy/demo 9999:8888
Viderekobler fra 127.0.0.1:9999 -> 8888
Viderekobler fra [::1]:9999 -> 8888

Når du åbner adressen localhost:9999/ skal du se følgende:

Det magiske ord er "xyzzy"

Skrive objekter Secret til filer

I dette eksempel vil vi tilslutte objektet Secret til containeren som en fil. Koden findes i mappen hello-secret-file i demo-repositoriet.

For at tilslutte Secret som en fil, vil vi bruge følgende implementering:

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

Som i sektionen "Oprettelse af konfigurationsfiler fra ConfigMap-objekter" på s. 240, opretter vi et volumen (i dette tilfælde demo-secret-volume) og tilslutter det til containeren i volumenMounts-sektionen. I feltet mountPath er angivet /secrets, så Kubernetes opretter en fil for hvert "nøgle-værdi" par defineret i Secret-objektet.

I vores eksempel har vi kun defineret ét "nøgle-værdi" par med navnet magicWord, så manifestet vil oprette en fil /secrets/magicWord med de fortrolige data, tilgængelig kun til læsning.

Hvis du anvender dette manifest på samme måde som i det forrige eksempel, skulle resultatet blive det samme:

Det magiske ord er "xyzzy"

Læsning af objekter Secret

I det foregående afsnit brugte vi kommandoen kubectl describe til at udskrive indholdet af ConfigMap. Kan man gøre det samme med Secret?

kubectl describe secret/demo-secret
Navn:          demo-secret

Namespace:      default
Labels:             
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

Bemærk, at selve dataene ikke vises. Secret-objekter i Kubernetes har typen Opaque: det betyder, at deres indhold ikke vises i output fra kubectl describe, logfiler og terminal, hvilket forhindrer utilsigtet afsløring af fortrolige oplysninger.

For at se den kodede version af fortrolige data i YAML-format, brug kommandoen kubectl get:

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

base64

Hvad er eHl6enk=, som slet ikke ligner vores oprindelige værdi? Faktisk er det et Secret-objekt, der præsenteres i base64-kodning. Base64 er en kodningsskema for vilkårlige binære data som en stræng af tegn.

Da fortrolige oplysninger kan være binære og utilgængelige for output (som i tilfælde med TLS-krypteringsnøglen), gemmes Secret-objekter altid i base64-format.

Teksten beHl6enk= er en version af vores hemmelige ord xyzzy, kodet i base64. Det kan bekræftes, hvis du kører kommandoen base64 —decode i terminalen:

echo "eHl6enk=" | base64 --decode
xyzzy

Dermed, selvom Kubernetes beskytter dig mod utilsigtet output af fortrolige data i terminalen eller logfiler, kan disse data, hvis du har læseadgang til Secret-objekter i et givet namespace, hentes i base64-format og derefter dekodes.

Hvis du skal kode en tekst i base64 (for eksempel for at placere den i et Secret), skal du bruge kommandoen base64 uden argumenter:

echo xyzzy | base64
eHl6enkK

Adgang til Secret-objekter

Hvem kan læse og redigere Secret-objekter? Det bestemmes af RBAC - mekanismen for adgangskontrol (som vi diskuterer nærmere i afsnittet "Introduktion til rollebaseret adgangskontrol" på s. 258). Hvis du bruger en klynge, hvor RBAC-systemet ikke er til stede eller ikke er aktiveret, er alle dine Secret-objekter tilgængelige for enhver bruger og container (senere vil vi forklare, at du ikke bør have nogen produktionsklynge uden RBAC).

Passiv kryptering af data

Hvad med dem, der har adgang til databasen etcd, hvor Kubernetes gemmer al sin information? Kan de læse fortrolige data uden at have læseadgang til Secret-objekter via API?

Fra version 1.7 understøtter Kubernetes passiv kryptering af data. Det betyder, at fortrolige oplysninger inde i etcd opbevares på disken i krypteret form og ikke kan læses, selv af dem, der har direkte adgang til databasen. For at dekryptere disse oplysninger kræves en nøgle, som kun Kubernetes API-serveren har. I et korrekt konfigureret cluster bør passiv kryptering være aktiveret.

Du kan kontrollere, om passiv kryptering fungerer i dit cluster på følgende måde:

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

Hvis du ikke ser flaget experimental-encryption-provider-config, er passiv kryptering ikke aktiveret. Ved brug af Google Kubernetes Engine eller andre Kubernetes administrations tjenester krypteres dine data med en anden mekanisme, så flaget vil være fraværende. Spørg din Kubernetes-leverandør, om indholdet af etcd er krypteret.

Opbevaring af fortrolige data

Der er visse Kubernetes-ressourcer, som aldrig bør slettes fra clustret: for eksempel meget vigtige objekter som Secret. Du kan beskytte ressourcen mod sletning ved hjælp af en annotation leveret af Helm-udbyderen:

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

Strategier til håndtering af Secret-objekter

I det tidligere eksempel var de fortrolige data beskyttet mod uautoriseret adgang umiddelbart efter at de blev gemt i clustret. Men i manifestfilerne blev de opbevaret som almindelig tekst.

Du skal aldrig placere fortrolige oplysninger i filer, der er under versionkontrol. Hvordan kan du sikkert administrere og opbevare sådanne oplysninger, inden de anvendes i Kubernetes-clustret?

Du kan vælge enhver værktøjer eller strategier til at arbejde med fortrolige data i dine applikationer, men du skal stadig besvare mindst følgende spørgsmål.

• Hvor skal fortrolige data opbevares, så de er højt tilgængelige?
• Hvordan gør du fortrolige data tilgængelige for dine aktive applikationer?
• Hvad skal der ske med dine applikationer, når du udskifter eller redigerer fortrolige data?

Om forfatterne

John Arundel er en konsulent med 30 års erfaring i it-branchen. Han har skrevet flere bøger og arbejder sammen med mange virksomheder fra forskellige lande, hvor han rådgiver dem om cloud-baseret infrastruktur og Kubernetes. I sin fritid nyder han at surfe, er dygtig til at skyde med pistol og spiller amatørklaver. Han bor i en eventyrlig hytte i Cornwall, England.

Justin Domingus — systemadministrationsingeniør, der arbejder i en DevOps-omgivelse med Kubernetes og cloud-teknologier. Han elsker at tilbringe tid udendørs, drikke kaffe, fange krabber og sidde ved computeren. Han bor i Seattle, Washington, sammen med sin fantastiske kat og sin endnu mere fantastiske kone, som også er hans bedste ven, Adrienne.

» Mere information om bogen kan findes på forlagets hjemmeside
» Indholdsfortegnelse
» Uddrag

For Habr-læsere er der 25% rabat med koden — Kubernetes

Ved betaling af den fysiske version af bogen sendes e-bogen til e-mail.

Kilde: habr.com