🥇 Boka "Kubernetes för DevOps"

Hej alla Khabrobor! Kubernetes är en av nyckeldelarna i det moderna molnets ekosystem. Denna teknik ger tillförlitlighet, skalbarhet och motståndskraft mot containervirtualisering. John Arundel och Justin Domingus pratar om Kubernetes ekosystem och introducerar beprövade lösningar på vardagliga problem. Steg för steg kommer du att bygga din egen molnbaserade applikation och skapa infrastrukturen för att stödja den, skapa en utvecklingsmiljö och en kontinuerlig distributionspipeline som hjälper dig när du arbetar med dina nästa applikationer.

• Kom igång med behållare och Kubernetes från grunderna: ingen speciell erfarenhet krävs för att lära sig ämnet. • Kör dina egna kluster eller välj en hanterad Kubernetes-tjänst från Amazon, Google, etc. • Använd Kubernetes för att hantera behållarens livscykel och resursförbrukning. • Optimera kluster baserat på kostnad, prestanda, motståndskraft, kraft och skalbarhet. • Lär dig de bästa verktygen för att utveckla, testa och distribuera dina applikationer. • Utnyttja nuvarande branschpraxis för att säkerställa säkerhet och kontroll. • Implementera DevOps-principer i hela ditt företag så att utvecklingsteam kan agera mer flexibelt, snabbt och effektivt.

Vem är boken till för?

Boken är mest relevant för anställda på administrativa avdelningar med ansvar för servrar, applikationer och tjänster, samt för utvecklare som är involverade i att antingen bygga nya molntjänster eller migrera befintliga applikationer till Kubernetes och molnet. Oroa dig inte, du behöver inte veta hur du arbetar med Kubernetes eller behållare – vi lär dig allt.

Erfarna Kubernetes-användare kommer också att finna mycket värde, med djupgående täckning av ämnen som RBAC, kontinuerlig distribution, hantering av känslig data och observerbarhet. Vi hoppas att sidorna i boken definitivt kommer att innehålla något intressant för dig, oavsett din kompetens och erfarenhet.

Vilka frågor svarar boken på?

När vi planerade och skrev boken diskuterade vi molnteknik och Kubernetes med hundratals människor, och pratade med branschledare och experter såväl som kompletta nybörjare. Nedan finns utvalda frågor som de skulle vilja se besvarade i denna publikation.

”Jag är intresserad av varför man ska lägga tid på den här tekniken. Vilka problem kommer det att hjälpa mig och mitt team att lösa?”
”Kubernetes verkar intressant, men har en ganska hög inträdesbarriär. Att förbereda ett enkelt exempel är inte svårt, men ytterligare administration och felsökning är skrämmande. Vi skulle vilja få pålitliga råd om hur människor hanterar Kubernetes-kluster i den verkliga världen och vilka problem vi sannolikt kommer att stöta på."
"Subjektiva råd skulle vara till hjälp. Kubernetes ekosystem ger nya team för många alternativ att välja mellan. När det finns flera sätt att göra samma sak, hur vet du vilket som är bäst? Hur gör man ett val?

Och kanske den viktigaste av alla frågor:

"Hur kan jag använda Kubernetes utan att störa mitt företag?"

Utdrag. Konfiguration och hemliga objekt

Möjligheten att separera logiken i en Kubernetes-applikation från dess konfiguration (det vill säga från alla värden eller inställningar som kan ändras över tiden) är mycket användbar. Konfigurationsvärden inkluderar vanligtvis miljöspecifika inställningar, DNS-adresser för tredjepartstjänster och autentiseringsuppgifter.

Allt detta kan naturligtvis läggas direkt i koden, men detta tillvägagångssätt är inte tillräckligt flexibelt. Om du till exempel ändrar ett konfigurationsvärde måste du bygga och distribuera din kod igen. En mycket bättre lösning skulle vara att separera konfigurationen från koden och läsa den från en fil eller miljövariabler.

Kubernetes tillhandahåller flera olika sätt att hantera konfigurationen. Först kan du skicka värden till applikationen genom miljövariabler som anges i pod-omslagsspecifikationen (se "Miljövariabler" på sidan 192). För det andra kan konfigurationsdata lagras direkt i Kubernetes med hjälp av ConfigMap och Secret-objekt.

I det här kapitlet utforskar vi dessa objekt i detalj och tittar på några praktiska tillvägagångssätt för att hantera konfiguration och känslig data med hjälp av en demoapplikation.

Uppdaterar pod-skal när konfigurationen ändras

Föreställ dig att du har en distribution i ditt kluster och du vill ändra några värden i dess ConfigMap. Om du använder Helm-diagrammet (se "Helm: Pakethanterare för Kubernetes" på sidan 102), kan du automatiskt upptäcka en konfigurationsändring och ladda om dina poddskal i ett snyggt trick. Lägg till följande anteckning till din distributionsspecifikation:

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

Implementeringsmallen innehåller nu en kontrollsumma av konfigurationsparametrar: om parametrarna ändras kommer summan att uppdateras. Om du kör roderuppgradering kommer Helm att upptäcka att distributionsspecifikationen har ändrats och kommer att starta om alla podskal.

Känsliga data i Kubernetes

Vi vet redan att ConfigMap-objektet tillhandahåller en flexibel mekanism för att lagra och komma åt konfigurationsdata i ett kluster. De flesta applikationer har dock information som är känslig och känslig, som lösenord eller API-nycklar. Det kan också lagras i ConfigMap, men den här lösningen är inte idealisk.

Istället erbjuder Kubernetes en speciell typ av objekt som är utformat för att lagra känslig data: Hemlig. Låt oss sedan titta på ett exempel på hur detta objekt kan användas i vår demoapplikation.

För att komma igång, ta en titt på Kubernetes-manifestet för det hemliga objektet (se hello-secret-env/k8s/secret.yaml):

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

I det här exemplet är magicWords privata nyckel xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Ordet xyzzy är generellt mycket användbart i datorvärlden. I likhet med ConfigMap kan du lagra flera nycklar och värden i ett hemligt objekt. Här använder vi för enkelhetens skull endast ett nyckel-värdepar.

Använda hemliga objekt som miljövariabler

Liksom ConfigMap kan Secret-objektet göras tillgängligt i behållaren som miljövariabler eller som en fil på dess disk. I följande exempel kommer vi att tilldela en miljövariabel till 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 demoförvaret för att tillämpa manifesten:

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

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

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

När du öppnar en adress lokalvärd:9999/ bör du se följande:

The magic word is "xyzzy"

Skriva hemliga objekt till filer

I det här exemplet kommer vi att bifoga det hemliga objektet till behållaren som en fil. Koden finns i mappen hello-secret-file i demoförvaret.

För att ansluta Secret som en fil kommer vi att använda 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 underavsnittet "Skapa konfigurationsfiler från ConfigMap-objekt" på sid. 240 skapar vi en volym (i det här fallet demo-hemlig-volym) och monterar den på behållaren i volymmonteringssektionen i specifikationen. MountPath-fältet är /secrets, så Kubernetes kommer att skapa en fil i den här mappen för varje nyckel/värdepar som definieras i Secret-objektet.

I vårt exempel definierade vi bara ett nyckel-värdepar som heter magicWord, så manifestet kommer att skapa en enda skrivskyddad fil /secrets/magicWord med känslig data i behållaren.

Om du tillämpar detta manifest på samma sätt som föregående exempel, bör du få samma resultat:

The magic word is "xyzzy"

Läser hemliga föremål

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

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

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

Data
====
magicWord: 5   bytes

Observera att själva data inte visas. Hemliga objekt i Kubernetes är av typen Opaque, vilket innebär att deras innehåll inte visas i kubectl describe output, loggposter eller terminalen, vilket gör det omöjligt att avslöja känslig information av misstag.

För att se en kodad YAML-version av känslig data, 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=, helt annorlunda från vårt ursprungliga värde? Detta är faktiskt ett hemligt objekt, representerat i base64-kodning. Base64 är ett schema för att koda godtycklig binär data som en teckensträng.

Eftersom känslig information kan vara binär och inte matas ut (som är fallet med en TLS-krypteringsnyckel), lagras alltid hemliga objekt i base64-format.

Texten beHl6enk= är den base64-kodade versionen av vårt hemliga ord xyzzy. Du kan verifiera detta genom att köra kommandot base64 —decode i terminalen:

echo "eHl6enk=" | base64 --decode
xyzzy

Så även om Kubernetes skyddar dig från att oavsiktligt mata ut känsliga data i terminalen eller loggfilerna, om du har läsbehörighet för hemliga objekt i ett specifikt namnområde, kan den data baseras64 och sedan avkodas.

Om du behöver base64 koda viss text (till exempel för att lägga den i en hemlighet), använd kommandot base64 utan argument:

echo xyzzy | base64
eHl6enkK

Åtkomst till hemliga objekt

Vem kan läsa och redigera hemliga objekt? Detta bestäms av RBAC, en åtkomstkontrollmekanism (vi kommer att diskutera det i detalj i underavsnittet "Introduktion till rollbaserad åtkomstkontroll" på sidan 258). Om du kör ett kluster som inte har RBAC eller inte är aktiverat, är alla dina hemliga objekt tillgängliga för alla användare och behållare (vi kommer att förklara senare att du inte bör ha några produktionskluster utan RBAC).

Passiv datakryptering

Hur är det med de som har tillgång till etcd-databasen där Kubernetes lagrar all sin information? Kan de läsa känslig data utan att ha behörighet att läsa hemliga objekt via API:et?

Sedan version 1.7 stöder Kubernetes passiv datakryptering. Detta innebär att känslig information inuti etcd lagras krypterad på disk och inte kan läsas även av de som har direkt tillgång till databasen. För att dekryptera den behöver du en nyckel som bara Kubernetes API-server har. I ett korrekt konfigurerat kluster bör passiv kryptering vara aktiverad.

Du kan kontrollera om passiv kryptering fungerar i ditt kluster så här:

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 Kubernetes-hanteringstjänster krypteras dina data med en annan mekanism, så flaggan kommer inte att finnas. Kontrollera med din Kubernetes-leverantör för att se om etcd-innehåll är krypterat.

Lagring av konfidentiell data

Det finns några Kubernetes-resurser som aldrig bör tas bort från klustret, till exempel mycket känsliga hemliga objekt. Du kan skydda en resurs från att raderas med hjälp av en anteckning från Helm Manager:

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

Hemliga objekthanteringsstrategier

I exemplet från föregående avsnitt skyddades känslig data från obehörig åtkomst omedelbart efter att ha lagrats i klustret. Men i manifestfiler lagrades de som vanlig text.

Du bör aldrig placera konfidentiell information i filer som är i versionskontroll. Hur kan du säkert hantera och lagra denna information innan du applicerar den på ditt Kubernetes-kluster?

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

Var ska känsliga uppgifter lagras så att de är lättillgängliga?
Hur gör man känslig data tillgänglig för dina aktiva applikationer?
Vad ska hända med dina applikationer när du ersätter eller redigerar känslig data?

Om författare

John Arundel är konsult med 30 års erfarenhet inom databranschen. Han har skrivit flera böcker och arbetar med många företag från olika länder och ger dem råd om molnbaserad infrastruktur och Kubernetes. På fritiden tycker han om att surfa, är en duktig pistolskytt och spelar piano som amatör. Bor i en sagostuga i Cornwall, England.

Justin Domingus — systemadministratör som arbetar i en DevOps-miljö med Kubernetes och molnteknik. Han tycker om att vara utomhus, dricka kaffe, krabba och sitta vid datorn. Bor i Seattle, Washington, med en underbar katt och en ännu underbarare fru och bästa vän, Adrienne.

» Mer information om boken finns på förlagets webbplats
» innehållsförteckning
» Utdrag

För Khabrozhiteley 25% rabatt med kupong - Kubernetes

Vid betalning av pappersversionen av boken skickas en elektronisk bok via e-post.

Källa: will.com

Boka "Kubernetes för DevOps"