Bog "Kubernetes for DevOps"

Hej Khabro beboere! Kubernetes er et af nøgleelementerne i det moderne sky-økosystem. Denne teknologi giver pålidelighed, skalerbarhed og modstandsdygtighed til containervirtualisering. John Arundel og Justin Domingus taler om Kubernetes-økosystemet og introducerer gennemprøvede løsninger på hverdagens problemer. Trin for trin bygger du din egen cloud-native applikation og skaber infrastrukturen til at understøtte den, opsætter et udviklingsmiljø og en kontinuerlig implementeringspipeline, der vil hjælpe dig, mens du arbejder på dine næste applikationer.

• Kom godt i gang med containere og Kubernetes fra det grundlæggende: Der kræves ingen særlig erfaring for at lære emnet. • Kør dine egne klynger eller vælg en administreret Kubernetes-tjeneste fra Amazon, Google osv. • Brug Kubernetes til at administrere containerlivscyklus og ressourceforbrug. • Optimer klynger baseret på omkostninger, ydeevne, robusthed, kraft og skalerbarhed. • Lær de bedste værktøjer til at udvikle, teste og implementere dine applikationer. • Udnyt nuværende industripraksis for at sikre sikkerhed og kontrol. • Implementer DevOps-principper i hele din virksomhed, så udviklingsteams kan handle mere fleksibelt, hurtigt og effektivt.

Hvem er bogen til?

Bogen er mest relevant for medarbejdere i administrationsafdelinger med ansvar for servere, applikationer og tjenester, samt for udviklere, der er involveret i enten at bygge nye cloud-tjenester eller migrere eksisterende applikationer til Kubernetes og skyen. Bare rolig, du behøver ikke at vide, hvordan du arbejder med Kubernetes eller containere - vi lærer dig alt.

Erfarne Kubernetes-brugere vil også finde en masse værdi med dybdegående dækning af emner som RBAC, kontinuerlig implementering, følsom datastyring og observerbarhed. Vi håber, at bogens sider helt sikkert vil indeholde noget interessant for dig, uanset dine kompetencer og erfaring.

Hvilke spørgsmål besvarer bogen?

Mens vi planlagde og skrev bogen, diskuterede vi cloud-teknologi og Kubernetes med hundredvis af mennesker, hvor vi talte med brancheledere og eksperter såvel som helt nybegyndere. Nedenfor er udvalgte spørgsmål, de gerne vil have besvaret i denne publikation.

• ”Jeg er interesseret i, hvorfor du skal bruge tid på denne teknologi. Hvilke problemer vil det hjælpe mig og mit team med at løse?"
• “Kubernetes virker interessant, men har en ret høj adgangsbarriere. At forberede et simpelt eksempel er ikke svært, men yderligere administration og fejlretning er skræmmende. Vi vil gerne have pålidelige råd om, hvordan folk administrerer Kubernetes-klynger i den virkelige verden, og hvilke problemer vi sandsynligvis vil støde på."
• "Subjektive råd ville være nyttige. Kubernetes-økosystemet giver nye teams for mange muligheder at vælge imellem. Når der er flere måder at gøre det samme på, hvordan ved du så, hvilken der er bedst? Hvordan træffer man et valg?

Og måske det vigtigste af alle spørgsmål:

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

Uddrag. Konfiguration og hemmelige objekter

Evnen til at adskille logikken i en Kubernetes-applikation fra dens konfiguration (det vil sige fra alle værdier eller indstillinger, der kan ændre sig over tid) er meget nyttig. Konfigurationsværdier inkluderer typisk miljøspecifikke indstillinger, tredjepartstjeneste DNS-adresser og godkendelsesoplysninger.

Alt dette kan selvfølgelig lægges direkte ind i koden, men denne tilgang er ikke fleksibel nok. For eksempel vil ændring af en konfigurationsværdi kræve, at du bygger og implementerer din kode igen. 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 konfiguration på. For det første kan du sende værdier til applikationen gennem miljøvariabler specificeret i pod-indpakningsspecifikationen (se "Miljøvariabler" på side 192). For det andet kan konfigurationsdata gemmes direkte i Kubernetes ved hjælp af ConfigMap og Secret-objekter.

I dette kapitel udforsker vi disse objekter i detaljer og ser på nogle praktiske tilgange til styring af konfiguration og følsomme data ved hjælp af en demoapplikation.

Opdatering af pod-skaller, når konfigurationen ændres

Forestil dig, at du har en implementering i din klynge, og du vil ændre nogle værdier i dens ConfigMap. Hvis du bruger Helm-diagrammet (se "Helm: Pakkehåndtering til Kubernetes" på side 102), kan du automatisk registrere en konfigurationsændring og genindlæse dine pod-skaller med et enkelt trick. Tilføj følgende annotation til din implementeringsspecifikation:

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

Implementeringsskabelonen indeholder nu en kontrolsum af konfigurationsparametre: hvis parametrene ændres, vil summen blive opdateret. Hvis du kører roropgradering, vil Helm registrere, at installationsspecifikationen er ændret og genstarte alle pod-skaller.

Følsomme data i Kubernetes

Vi ved allerede, at ConfigMap-objektet giver en fleksibel mekanisme til lagring og adgang til konfigurationsdata i en klynge. De fleste applikationer har dog oplysninger, der er følsomme og følsomme, såsom adgangskoder eller API-nøgler. Det kan også gemmes i ConfigMap, men denne løsning er ikke ideel.

I stedet tilbyder Kubernetes en speciel type objekt, der er designet til at gemme følsomme data: Secret. Lad os derefter se på et eksempel på, hvordan dette objekt kan bruges i vores demo-applikation.

For at komme i gang skal du tage et kig på Kubernetes-manifestet for det hemmelige objekt (se hello-secret-env/k8s/secret.yaml):

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

I dette eksempel er magicWords private nøgle xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Ordet xyzzy er generelt meget nyttigt i computerverdenen. I lighed med ConfigMap kan du gemme flere nøgler og værdier i et hemmeligt objekt. Her bruger vi for nemheds skyld kun ét nøgleværdi-par.

Brug af hemmelige objekter som miljøvariabler

Ligesom ConfigMap kan det hemmelige objekt gøres tilgængeligt i containeren som miljøvariabler eller som en fil på dets disk. I det følgende eksempel vil vi tildele en miljøvariabel til værdien 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-lageret for at anvende manifesterne:

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

Som før videresend den lokale port til implementeringen for at se resultatet i din browser:

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

Når du åbner en adresse localhost:9999/ bør du se følgende:

The magic word is "xyzzy"

Skrivning af hemmelige objekter til filer

I dette eksempel vil vi vedhæfte det hemmelige objekt til containeren som en fil. Koden er placeret i mappen hello-secret-file i demo-lageret.

For at forbinde Secret som en fil, bruger vi 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 underafsnittet "Oprettelse af konfigurationsfiler fra ConfigMap-objekter" på s. 240, opretter vi en volumen (i dette tilfælde demo-secret-volume) og monterer den på beholderen i volumeMounts-sektionen i specifikationen. MountPath-feltet er /secrets, så Kubernetes vil oprette én fil i denne mappe for hvert nøgle/værdi-par, der er defineret i det hemmelige objekt.

I vores eksempel definerede vi kun ét nøgle-værdi-par kaldet magicWord, så manifestet vil skabe en enkelt skrivebeskyttet fil /secrets/magicWord med følsomme data i containeren.

Hvis du anvender dette manifest på samme måde som det foregående eksempel, skulle du få det samme resultat:

The magic word is "xyzzy"

Læsning af hemmelige genstande

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

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

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

Data
====
magicWord: 5   bytes

Bemærk, at selve dataene ikke vises. Hemmelige objekter i Kubernetes er af typen Uigennemsigtig, hvilket betyder, at deres indhold ikke vises i kubectl describe output, logindtastninger eller terminalen, hvilket gør det umuligt ved et uheld at afsløre følsomme oplysninger.

For at se en kodet YAML-version af følsomme data skal du bruge kommandoen kubectl get:

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

base64

Hvad er eHl6enk=, helt forskellig fra vores oprindelige værdi? Dette er faktisk et hemmeligt objekt, repræsenteret i base64-kodning. Base64 er et skema til kodning af vilkårlige binære data som en streng af tegn.

Fordi følsom information kan være binær og ikke output (som det er tilfældet med en TLS-krypteringsnøgle), gemmes hemmelige objekter altid i base64-format.

Teksten beHl6enk= er den base64-kodede version af vores hemmelige ord xyzzy. Du kan bekræfte dette ved at køre kommandoen base64 —decode i terminalen:

echo "eHl6enk=" | base64 --decode
xyzzy

Så mens Kubernetes beskytter dig mod at udsende følsomme data ved et uheld i terminalen eller logfilerne, hvis du har læsetilladelser på hemmelige objekter i et specifikt navneområde, kan disse data baseres og efterfølgende afkodes.

Hvis du har brug for at base64-kode noget tekst (for eksempel for at sætte den i en hemmelighed), skal du bruge base64-kommandoen uden argumenter:

echo xyzzy | base64
eHl6enkK

Adgang til hemmelige objekter

Hvem kan læse og redigere hemmelige objekter? Dette bestemmes af RBAC, en adgangskontrolmekanisme (vi vil diskutere det detaljeret i underafsnittet "Introduktion til rollebaseret adgangskontrol" på side 258). Hvis du kører en klynge, der ikke har RBAC eller ikke er aktiveret, er alle dine hemmelige objekter tilgængelige for alle brugere og containere (vi vil forklare senere, at du ikke bør have nogen produktionsklynger uden RBAC).

Passiv datakryptering

Hvad med dem, der har adgang til etcd-databasen, hvor Kubernetes gemmer alle sine oplysninger? Kan de læse følsomme data uden at have tilladelse til at læse hemmelige objekter via API'et?

Siden version 1.7 understøtter Kubernetes passiv datakryptering. Det betyder, at følsom information inde i etcd gemmes krypteret på disken og ikke kan læses selv af dem med direkte adgang til databasen. For at dekryptere den skal du bruge en nøgle, som kun Kubernetes API-serveren har. I en korrekt konfigureret klynge skal passiv kryptering være aktiveret.

Du kan kontrollere, om passiv kryptering fungerer i din klynge på denne måde:

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

Hvis du ikke kan se flaget experimental-encryption-provider-config, er passiv kryptering ikke aktiveret. Når du bruger Google Kubernetes Engine eller andre Kubernetes-administrationstjenester, krypteres dine data ved hjælp af en anden mekanisme, så flaget vil ikke være til stede. Spørg din Kubernetes-leverandør for at se, om etcd-indhold er krypteret.

Lagring af fortrolige data

Der er nogle Kubernetes-ressourcer, som aldrig bør fjernes fra klyngen, såsom meget følsomme hemmelige objekter. Du kan beskytte en ressource mod at blive slettet ved hjælp af en anmærkning leveret af Helm-manageren:

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

Hemmelige objektstyringsstrategier

I eksemplet fra forrige afsnit blev følsomme data beskyttet mod uautoriseret adgang umiddelbart efter at være blevet gemt i klyngen. Men i manifestfiler blev de gemt som almindelig tekst.

Du bør aldrig placere fortrolige oplysninger i filer, der er i versionskontrol. Hvordan kan du sikkert administrere og opbevare disse oplysninger, før du anvender dem på din Kubernetes-klynge?

Du kan vælge et hvilket som helst værktøj eller strategi til håndtering af følsomme data i dine applikationer, men du skal stadig besvare mindst følgende spørgsmål.

• Hvor skal følsomme data opbevares, så de er let tilgængelige?
• Hvordan gør man følsomme data tilgængelige for dine aktive applikationer?
• Hvad skal der ske med dine applikationer, når du erstatter eller redigerer følsomme data?

Om forfattere

John Arundel er konsulent med 30 års erfaring i computerbranchen. Han har skrevet flere bøger og arbejder med mange virksomheder fra forskellige lande, hvor han rådgiver dem om cloud-native infrastruktur og Kubernetes. I sin fritid nyder han at surfe, er en god pistolskytte og spiller klaver som amatør. Bor i et eventyrligt sommerhus i Cornwall, England.

Justin Domingus — systemadministrationsingeniør, der arbejder i et DevOps-miljø med Kubernetes og cloud-teknologier. Han nyder at bruge tid udendørs, drikke kaffe, krabbe og sidde ved computeren. Bor i Seattle, Washington, med en vidunderlig kat og en endnu mere vidunderlig kone og bedste ven, Adrienne.

» Flere detaljer om bogen kan findes på forlagets hjemmeside
» indholdsfortegnelse
» Uddrag

For Khabrozhiteley 25% rabat ved brug af kupon - Kubernetes

Ved betaling af papirversionen af ​​bogen fremsendes en elektronisk bog på e-mail.

Kilde: www.habr.com