ProHoster > Log > administrasjon > Bestill "Kubernetes for DevOps"

Bestill "Kubernetes for DevOps"

Bestill "Kubernetes for DevOps" Hei Khabro-beboere! Kubernetes er et av nøkkelelementene i det moderne skyøkosystemet. Denne teknologien gir pålitelighet, skalerbarhet og motstandskraft til containervirtualisering. John Arundel og Justin Domingus snakker om Kubernetes-økosystemet og introduserer utprøvde løsninger på hverdagslige problemer. Trinn for trinn vil du bygge din egen skybaserte applikasjon og lage infrastrukturen for å støtte den, sette opp et utviklingsmiljø og en kontinuerlig distribusjonspipeline som vil hjelpe deg mens du jobber med de neste applikasjonene dine.

• Kom i gang med containere og Kubernetes fra det grunnleggende: ingen spesiell erfaring kreves for å lære emnet. • Kjør dine egne klynger eller velg en administrert Kubernetes-tjeneste fra Amazon, Google osv. • Bruk Kubernetes til å administrere beholderens livssyklus og ressursforbruk. • Optimaliser klynger basert på kostnader, ytelse, robusthet, kraft og skalerbarhet. • Lær de beste verktøyene for å utvikle, teste og distribuere applikasjonene dine. • Utnytt gjeldende bransjepraksis for å sikre sikkerhet og kontroll. • Implementer DevOps-prinsipper i hele bedriften din slik at utviklingsteam kan handle mer fleksibelt, raskt og effektivt.

Hvem er boken for?

Boken er mest relevant for ansatte i administrasjonsavdelinger med ansvar for servere, applikasjoner og tjenester, samt for utviklere som er involvert i enten å bygge nye skytjenester eller migrere eksisterende applikasjoner til Kubernetes og skyen. Ikke bekymre deg, du trenger ikke vite hvordan du jobber med Kubernetes eller containere - vi lærer deg alt.

Erfarne Kubernetes-brukere vil også finne mye verdi, med grundig dekning av emner som RBAC, kontinuerlig distribusjon, sensitiv databehandling og observerbarhet. Vi håper at sidene i boken definitivt vil inneholde noe interessant for deg, uavhengig av dine ferdigheter og erfaring.

Hvilke spørsmål svarer boken på?

Mens vi planla og skrev boken, diskuterte vi skyteknologi og Kubernetes med hundrevis av mennesker, og snakket med bransjeledere og eksperter så vel som helt nybegynnere. Nedenfor er utvalgte spørsmål de gjerne vil ha svar på i denne publikasjonen.

  • «Jeg er interessert i hvorfor du bør bruke tid på denne teknologien. Hvilke problemer vil det hjelpe meg og teamet mitt å løse?»
  • «Kubernetes virker interessant, men har en ganske høy inngangsbarriere. Det er ikke vanskelig å lage et enkelt eksempel, men ytterligere administrasjon og feilsøking er skremmende. Vi vil gjerne ha pålitelige råd om hvordan folk administrerer Kubernetes-klynger i den virkelige verden og hvilke problemer vi sannsynligvis vil møte."
  • "Subjektive råd vil være nyttige. Kubernetes-økosystemet gir nye team for mange alternativer å velge mellom. Når det er flere måter å gjøre det samme på, hvordan vet du hvilken som er best? Hvordan ta et valg?

Og kanskje det viktigste av alle spørsmål:

  • "Hvordan kan jeg bruke Kubernetes uten å forstyrre selskapet mitt?"

Utdrag. Konfigurasjon og hemmelige objekter

Muligheten til å skille logikken til en Kubernetes-applikasjon fra konfigurasjonen (det vil si fra alle verdier eller innstillinger som kan endres over tid) er veldig nyttig. Konfigurasjonsverdier inkluderer vanligvis miljøspesifikke innstillinger, DNS-adresser for tredjepartstjenester og autentiseringslegitimasjon.

Alt dette kan selvfølgelig legges direkte inn i koden, men denne tilnærmingen er ikke fleksibel nok. For eksempel vil endring av en konfigurasjonsverdi kreve at du bygger og distribuerer koden på nytt. En mye bedre løsning ville være å skille konfigurasjonen fra koden og lese den fra en fil eller miljøvariabler.

Kubernetes tilbyr flere forskjellige måter å administrere konfigurasjon på. Først kan du sende verdier til applikasjonen gjennom miljøvariabler spesifisert i pod-innpakningsspesifikasjonen (se "Miljøvariabler" på side 192). For det andre kan konfigurasjonsdata lagres direkte i Kubernetes ved å bruke ConfigMap og Secret-objekter.

I dette kapittelet utforsker vi disse objektene i detalj og ser på noen praktiske tilnærminger til å administrere konfigurasjon og sensitive data ved hjelp av en demoapplikasjon.

Oppdaterer pod-skall når konfigurasjonen endres

Tenk deg at du har en distribusjon i klyngen din og du vil endre noen verdier i ConfigMap. Hvis du bruker Helm-diagrammet (se "Helm: Pakkebehandling for Kubernetes" på side 102), kan du automatisk oppdage en konfigurasjonsendring og laste inn pod-skallene på nytt med ett enkelt triks. Legg til følgende merknad til distribusjonsspesifikasjonen din:

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

Implementeringsmalen inneholder nå en kontrollsum av konfigurasjonsparametere: hvis parameterne endres, vil summen bli oppdatert. Hvis du kjører roroppgradering, vil Helm oppdage at distribusjonsspesifikasjonen er endret og vil starte alle pod-skall på nytt.

Sensitive data i Kubernetes

Vi vet allerede at ConfigMap-objektet gir en fleksibel mekanisme for lagring og tilgang til konfigurasjonsdata i en klynge. De fleste applikasjoner har imidlertid informasjon som er sensitiv og sensitiv, for eksempel passord eller API-nøkler. Den kan også lagres i ConfigMap, men denne løsningen er ikke ideell.

I stedet tilbyr Kubernetes en spesiell type objekt designet for å lagre sensitive data: Hemmelig. La oss deretter se på et eksempel på hvordan dette objektet kan brukes i vår demoapplikasjon.

For å komme i gang, ta en titt på Kubernetes-manifestet for det hemmelige objektet (se hello-secret-env/k8s/secret.yaml):

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

I dette eksemplet er den private nøkkelen magicWord xyzzy (en.wikipedia.org/wiki/Xyzzy_(databehandling)). Ordet xyzzy er generelt veldig nyttig i datamaskinens verden. I likhet med ConfigMap kan du lagre flere nøkler og verdier i et hemmelig objekt. Her bruker vi for enkelhets skyld kun ett nøkkelverdi-par.

Bruke hemmelige objekter som miljøvariabler

Som ConfigMap kan Secret-objektet gjøres tilgjengelig i beholderen som miljøvariabler eller som en fil på disken. I følgende eksempel vil vi tilordne en miljøvariabel til verdien 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

Kjør følgende kommando i demolageret for å bruke manifestene:

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

Som før, videresend den lokale porten til distribusjonen for å se resultatet i nettleseren din:

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

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

The magic word is "xyzzy"

Skrive hemmelige objekter til filer

I dette eksemplet vil vi legge ved det hemmelige objektet til beholderen som en fil. Koden er plassert i hello-secret-filemappen til demolageret.

For å koble til Secret som en fil, bruker vi følgende distribusjon:

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 underavsnittet "Opprette konfigurasjonsfiler fra ConfigMap-objekter" på s. 240, lager vi et volum (i dette tilfellet demo-hemmelig-volum) og monterer det til beholderen i volumeMounts-delen av spesifikasjonen. MountPath-feltet er /secrets, så Kubernetes vil opprette én fil i denne mappen for hvert nøkkel/verdi-par som er definert i Secret-objektet.

I vårt eksempel definerte vi bare ett nøkkelverdi-par kalt magicWord, så manifestet vil lage en enkelt skrivebeskyttet fil /secrets/magicWord med sensitive data i beholderen.

Hvis du bruker dette manifestet på samme måte som det forrige eksemplet, bør du få samme resultat:

The magic word is "xyzzy"

Lese hemmelige gjenstander

I forrige seksjon brukte vi kommandoen kubectl describe for å vise innholdet i et ConfigMap. Kan det samme gjøres med Secret?

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

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

Data
====
magicWord: 5   bytes

Vær oppmerksom på at selve dataene ikke vises. Hemmelige objekter i Kubernetes er av typen Opaque, noe som betyr at innholdet ikke vises i kubectl describe output, loggoppføringer eller terminalen, noe som gjør det umulig å avsløre sensitiv informasjon ved et uhell.

For å se en kodet YAML-versjon av sensitive data, bruk kommandoen kubectl get:

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

base64

Hva er eHl6enk=, helt forskjellig fra vår opprinnelige verdi? Dette er faktisk et hemmelig objekt, representert i base64-koding. Base64 er et opplegg for koding av vilkårlige binære data som en streng med tegn.

Fordi sensitiv informasjon kan være binær og ikke utdata (som tilfellet er med en TLS-krypteringsnøkkel), blir hemmelige objekter alltid lagret i base64-format.

Teksten beHl6enk= er den base64-kodede versjonen av vårt hemmelige ord xyzzy. Du kan bekrefte dette ved å kjøre kommandoen base64 —decode i terminalen:

echo "eHl6enk=" | base64 --decode
xyzzy

Så, mens Kubernetes beskytter deg mot å sende ut sensitive data ved et uhell i terminalen eller loggfilene, hvis du har lesetillatelser på hemmelige objekter i et spesifikt navneområde, kan disse dataene baseres og deretter dekodes.

Hvis du trenger å base64 kode noe tekst (for eksempel for å sette den i en hemmelighet), bruk base64-kommandoen uten argumenter:

echo xyzzy | base64
eHl6enkK

Tilgang til hemmelige objekter

Hvem kan lese og redigere hemmelige objekter? Dette bestemmes av RBAC, en tilgangskontrollmekanisme (vi vil diskutere det i detalj i underavsnittet "Introduksjon til rollebasert tilgangskontroll" på side 258). Hvis du kjører en klynge som ikke har RBAC eller ikke er aktivert, er alle dine hemmelige objekter tilgjengelige for alle brukere og beholdere (vi vil forklare senere at du ikke bør ha noen produksjonsklynger uten RBAC).

Passiv datakryptering

Hva med de som har tilgang til etcd-databasen der Kubernetes lagrer all informasjonen? Kan de lese sensitive data uten å ha tillatelse til å lese hemmelige objekter via API?

Siden versjon 1.7 støtter Kubernetes passiv datakryptering. Dette betyr at sensitiv informasjon inne i etcd lagres kryptert på disk og ikke kan leses selv av de med direkte tilgang til databasen. For å dekryptere den trenger du en nøkkel som bare Kubernetes API-serveren har. I en riktig konfigurert klynge bør passiv kryptering være aktivert.

Du kan sjekke om passiv kryptering fungerer i klyngen din på denne måten:

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

Hvis du ikke ser flagget for experimental-encryption-provider-config, er ikke passiv kryptering aktivert. Når du bruker Google Kubernetes Engine eller andre Kubernetes-administrasjonstjenester, krypteres dataene dine med en annen mekanisme, så flagget vil ikke være til stede. Sjekk med Kubernetes-leverandøren din for å se om etcd-innhold er kryptert.

Lagring av konfidensielle data

Det er noen Kubernetes-ressurser som aldri bør fjernes fra klyngen, for eksempel svært sensitive hemmelige objekter. Du kan beskytte en ressurs fra å bli slettet ved å bruke en merknad levert av Helm-administratoren:

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

Hemmelige objektstyringsstrategier

I eksemplet fra forrige seksjon ble sensitive data beskyttet mot uautorisert tilgang umiddelbart etter å ha blitt lagret i klyngen. Men i manifestfiler ble de lagret som ren tekst.

Du bør aldri plassere konfidensiell informasjon i filer som er i versjonskontroll. Hvordan kan du sikkert administrere og lagre denne informasjonen før du bruker den på Kubernetes-klyngen?

Du kan velge hvilke som helst verktøy eller strategier for håndtering av sensitive data i applikasjonene dine, men du må fortsatt svare på minst følgende spørsmål.

  • Hvor skal sensitive data lagres slik at de er lett tilgjengelige?
  • Hvordan gjøre sensitive data tilgjengelige for dine aktive applikasjoner?
  • Hva skal skje med applikasjonene dine når du erstatter eller redigerer sensitive data?

Om forfattere

John Arundel er konsulent med 30 års erfaring i databransjen. Han har skrevet flere bøker og jobber med mange selskaper fra forskjellige land, og gir dem råd om skybasert infrastruktur og Kubernetes. På fritiden liker han å surfe, er en god pistolskytter og spiller piano som amatør. Bor i en eventyrlig hytte i Cornwall, England.

Justin Domingus — systemadministrasjonsingeniør som jobber i et DevOps-miljø med Kubernetes og skyteknologier. Han liker å tilbringe tid utendørs, drikke kaffe, krabbe og sitte ved datamaskinen. Bor i Seattle, Washington, med en fantastisk katt og en enda mer fantastisk kone og beste venn, Adrienne.

» For mer informasjon om boken, vennligst besøk forlagets nettside
» innholdsfortegnelsen
» Utdrag

For Khabrozhiteli 25% rabatt på kupongen - Kubernetes

Ved betaling av papirutgaven av boken sendes en e-bok til e-post.

Kilde: www.habr.com

Legg til en kommentar