Boken "Kubernetes för DevOps"

Hej, Habr-medlemmar! Kubernetes är en av de centrala komponenterna i dagens molnekosystem. Denna teknik säkerställer tillförlitlighet, skalbarhet och motståndskraft i containerbaserad virtualisering. John Arundel och Justin Domingus diskuterar Kubernetes-ekosystemet och presenterar beprövade lösningar på vardagliga problem. Steg för steg bygger du din egen molnorienterade applikation och skapar infrastrukturen för dess stöd, sätter upp utvecklingsmiljön och en kontinuerlig distributionspipeline som kommer att vara till nytta när du arbetar med kommande applikationer.

• Du börjar arbeta med containrar och Kubernetes från grunden: ingen speciell erfarenhet krävs för att lära sig ämnet. • Starta dina egna kluster eller välj en hanterad Kubernetes-tjänst från Amazon, Google m.fl. • Använd Kubernetes för att hantera livscykeln av containrar och resursanvändning. • Optimera kluster baserat på kostnad, prestanda, motståndskraft, kapacitet och skalbarhet. • Utforska de bästa verktygen för att utveckla, testa och distribuera dina applikationer. • Utnyttja aktuella branschpraxis för att säkerställa säkerhet och kontroll. • Implementera DevOps-principer i företaget så att utvecklingsteam arbetar mer flexibelt, snabbt och effektivt.

För vem är boken avsedd

Boken är mest relevant för anställda på administrationsavdelningar som ansvarar för servrar, applikationer och tjänster, samt för utvecklare som antingen bygger nya molntjänster eller migrerar befintliga applikationer till Kubernetes och molnet. Oroa dig inte, att kunna arbeta med Kubernetes och containrar krävs inte — vi lär dig allt.

Erfarna användare av Kubernetes kommer också att hitta mycket värdefullt: detta verk avhandlar djupgående ämnen som RBAC, kontinuerlig distribution, hantering av känsliga data och insyn. Vi hoppas att det finns något intressant för dig på sidorna i boken, oavsett dina färdigheter och erfarenheter.

Vilka frågor besvarar boken

Under planering och skrivande av boken diskuterade vi molnteknologier och Kubernetes med hundratals människor, talade både med branschledare och experter och med fullständiga nybörjare. Nedan följer specifika frågor vars svar de skulle vilja se i denna utgåva.

• "Jag undrar varför jag ska lägga tid på denna teknik. Vilka problem kommer den att hjälpa mig och mitt team att lösa?"
• "Kubernetes verkar intressant, men har en ganska hög tröskel för inträde. Det är inte svårt att förbereda ett enkelt exempel, men vidare administration och felsökning är skrämmande. Vi skulle vilja ha pålitliga råd om hur människor hanterar Kubernetes-kluster i verkliga förhållanden och vilka problem vi sannolikt kommer att stöta på."
• "Subjektivt råd skulle vara användbart. Kubernetes ekosystem erbjuder nybörjarteam för många alternativ att välja mellan. När samma sak kan göras på flera sätt, hur förstår man vilket som är bäst? Hur gör man valet?"

Och kanske den viktigaste av alla frågor:

• "Hur kan jag använda Kubernetes utan att störa min företagsverksamhet?"

Utdrag. Konfiguration och objekt Secret

Möjligheten att separera Kubernetes-applikationens logik från dess konfiguration (dvs. från värden eller inställningar som kan ändras över tid) är mycket användbar. Konfigurationsvärden omfattar vanligtvis parametrar avsedda för specifika miljöer, DNS-adresser för tredjepartstjänster och autentiseringsuppgifter.

Självklart kan allt detta placeras direkt i koden, men en sådan metod är inte tillräckligt flexibel. Till exempel skulle du behöva återkompilera och distribuera din kod för att ändra ett konfigurationsvärde. Ett mycket bättre alternativ skulle vara att separera konfigurationen från koden och läsa in den från en fil eller miljövariabler.

Kubernetes erbjuder flera olika sätt att hantera konfiguration. För det första kan du överföra värden till applikationen via miljövariabler som anges i pod-specifikationen (se avsnittet "Miljövariabler" på s. 192). För det andra kan konfigurationsdata lagras direkt i Kubernetes med hjälp av objekten ConfigMap och Secret.

I detta kapitel kommer vi att noggrant undersöka dessa objekt och diskutera några praktiska metoder för hantering av konfiguration och känslig information med hjälp av ett demonstrationsprogram.

Uppdatering av pod-wraps vid ändring av konfiguration

Tänk dig att du har en distribution i din kluster och vill ändra vissa värden i dess ConfigMap. Om du använder en Helm-chart (se avsnittet "Helm: pakethanterare för Kubernetes" på s. 102), kan du automatiskt upptäcka ändringar i konfigurationen och starta om dina pod-wraps med hjälp av en elegant teknik. Lägg till följande annotation i din distributionsspecifikation:

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

Nu innehåller distributionsmallen en kontrollsumma av konfigurationsparametrarna: när parametrarna ändras, kommer summan att uppdateras. Om du kör kommandot helm upgrade, kommer Helm att upptäcka att distributionsspecifikationen har ändrats och starta om alla pod-wraps.

Känslig information i Kubernetes

Vi vet redan att ConfigMap-objektet erbjuder en flexibel funktion för lagring och åtkomst till konfigurationsdata i klustret. Men de flesta applikationer har information som är hemlig och konfidentiell: till exempel lösenord eller API-nycklar. Det går att lagra detta i en ConfigMap, men det är inte en idealisk lösning.

Istället erbjuder Kubernetes ett speciellt typ av objekt som är avsett för lagring av känslig information: Secret. Låt oss titta på ett exempel på hur detta objekt kan användas i vår demonstrationsapplikation.

Först, ta en titt på Kubernetes-manifestet för Secret-objektet (se hello-secret-env/k8s/secret.yaml):

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

I detta exempel har den hemliga nyckeln magicWord värdet xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Ordet xyzzy är faktiskt mycket användbart i datorsvärlden. På samma sätt som i ConfigMap kan du placera många nycklar och värden i Secret-objektet. Här använder vi bara ett par "nyckel - värde" för enkelhetens skull.

Användning av Secret-objekt som miljövariabler

Precis som ConfigMap kan Secret-objekt göras tillgängliga i containern som miljövariabler eller som filer på dess disk. I det följande exemplet kommer vi att tilldela en miljövariabel värdet från 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öljande kommando i demo-repositoriet för att tillämpa manifesten:

kubectl apply -f hello-secret-env/k8s/
department.extensions "demo" konfigurerad
secret "demo-secret" skapad

Som tidigare, vidarebefordra den lokala porten till distributionen för att se resultatet i din webbläsare:

kubectl port-forward deploy/demo 9999:8888
Vidarebefordrar från 127.0.0.1:9999 -> 8888
Vidarebefordrar från [::1]:9999 -> 8888

När du öppnar adressen localhost:9999/ bör du se följande:

Det magiska ordet är "xyzzy"

Skriva objekten Secret till filer

I det här exemplet kopplar vi objektet Secret till containern som en fil. Koden finns i mappen hello-secret-file i demo-repositoriet.

För att koppla Secret som en fil använder vi följande distribution:

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 avsnittet "Skapa konfigurationsfiler från ConfigMap-objekt" på s. 240 skapar vi en volym (i det här fallet demo-secret-volume) och kopplar den till containern i avsnittet volumeMounts-specifikationerna. I fältet mountPath anges /secrets, så Kubernetes skapar en fil i den mappen för varje "nyckel-värde"-par definierat i Secret-objektet.

I vårt exempel har vi definierat endast ett "nyckel-värde"-par med namnet magicWord, så manifestet skapar en fil /secrets/magicWord i containern med konfidentiell data, tillgänglig som skrivskyddad.

Om du tillämpar detta manifest på samma sätt som i det föregående exemplet, bör samma resultat erhållas:

Det magiska ordet är "xyzzy"

Läsa objekten Secret

I det föregående avsnittet använde vi kommandot kubectl describe för att visa innehållet i ConfigMap. Kan vi göra samma sak med Secret?

kubectl describe secret/demo-secret
Namn:          demo-secret

Namnrum:      standard
Etiketter:             
Anteckningar:
Typ:               Opaque

Data
====
magicWord: 5 bytes

Observera att själva datan inte visas. Secret-objekt i Kubernetes har typen Opaque: det innebär att deras innehåll inte visas i utskriften av kubectl describe, loggar och terminalen, vilket förhindrar oavsiktlig avslöjande av konfidentiell information.

För att visa den kodade versionen av känslig information i YAML-format, använd kommandot kubectl get:

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

base64

Vad är eHl6enk=, som inte alls liknar vårt ursprungliga värde? Det är faktiskt ett Secret-objekt, presenterat i base64-kodning. Base64 är ett kodningsschema för godtycklig binär data som representeras som en sträng av tecken.

Eftersom känslig information kan vara binär och otillgänglig för utdata (som i fallet med TLS-krypteringsnyckeln), lagras Secret-objekt alltid i base64-format.

Texten beHl6enk= är en version av vårt hemliga ord xyzzy, kodad i base64. Detta kan verifieras genom att köra kommandot base64 --decode i terminalen:

echo "eHl6enk=" | base64 --decode
xyzzy

Så trots att Kubernetes skyddar dig från oavsiktlig utmatning av känslig information i terminalen eller loggfiler, kan denna data, om man har läsrättigheter för Secret-objekt i ett visst namnrum, hämtas i base64-format och avkodas senare.

Om du behöver koda någon text i base64 (t.ex. för att placera den i ett Secret), använd kommandot base64 utan argument:

echo xyzzy | base64
eHl6enkK

Åtkomst till Secret-objekt

Vem kan läsa och redigera Secret-objekt? Detta bestäms av RBAC – en åtkomstkontrollmekanism (mer om detta i avsnittet "Introduktion till rollbaserad åtkomstkontroll" på s. 258). Om du använder en kluster där RBAC-systemet saknas eller inte är aktiverat, är alla dina Secret-objekt tillgängliga för alla användare och containrar (vi förklarar senare att du inte bör ha något produktionskluster utan RBAC).

Passiv datakryptering

Men vad sägs om dem som har tillgång till etcd-databasen där Kubernetes lagrar all sin information? Kan de läsa känsliga uppgifter utan läsrättigheter för Secret-objekt via API?

Sedan version 1.7 stöder Kubernetes passiv datakryptering. Det innebär att känslig information inuti etcd lagras på disk i krypterad form och inte kan läsas ens av dem som har direkt åtkomst till databasen. För att dekryptera den krävs en nyckel som endast API-servern för Kubernetes har. I en korrekt konfigurerad kluster ska passiv kryptering vara aktiverad.

Du kan kontrollera om passiv kryptering fungerar i din kluster på följande sätt:

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

Om du inte ser flaggan experimental-encryption-provider-config är passiv kryptering inte aktiverad. När du använder Google Kubernetes Engine eller andra tjänster för Kubernetes-hantering krypteras dina data med en annan mekanism, så flaggan kommer att saknas. Fråga din Kubernetes-leverantör om innehållet i etcd krypteras.

Lagring av känsliga data

Det finns sådana Kubernetes-resurser som aldrig bör raderas från klustret: till exempel särskilt viktiga objekt Secret. Du kan skydda en resurs från att raderas med en annotation som tillhandahålls av Helm-verktyget:

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

Strategier för hantering av Secret-objekt

I exemplet från föregående avsnitt skyddades känsliga data från obehörig åtkomst direkt efter lagring i klustret. Men i manifestfilerna lagrades de i klartext.

Du bör aldrig placera känslig information i filer som finns i versionskontrollsystemet. Hur kan man säkert administrera och lagra sådan information tills den tillämpas på klustret Kubernetes?

Du kan välja vilka verktyg eller strategier som helst för att arbeta med känsliga data i dina applikationer, men du måste fortfarande åtminstone svara på följande frågor.

• Var ska jag lagra känsliga data så att de är mycket tillgängliga?
• Hur gör jag känsliga data tillgängliga för mina aktiva applikationer?
• Vad ska hända med dina applikationer när du byter ut eller redigerar känsliga data?

Om författarna

John Arundel är en konsult med 30 års erfarenhet inom datorindustrin. Han har skrivit flera böcker och arbetar med många företag från olika länder, där han ger råd om molnbaserad infrastruktur och Kubernetes. På sin fritid gillar han att surfa, skjuta pistoltavla och spela piano på hobbybasis. Han bor i en sagolik stuga i Cornwall, England.

Justin Domingus är en systemadministrationsingenjör som arbetar i en DevOps-miljö med Kubernetes och molnteknologier. Han gillar att spendera tid utomhus, dricka kaffe, fånga krabbor och sitta vid datorn. Han bor i Seattle, Washington, tillsammans med sin fantastiska katt och sin ännu mer fantastiska fru och bästa vän Adrienn.

” För mer information om boken kan man läsa på förlagets webbplats
» Innehållsförteckning
» Utdrag

För Habr-följare är det 25 % rabatt med koden — Kubernetes

Vid betalning av den tryckta versionen av boken skickas en e-bok till e-post.

Källa: habr.com