Boek "Kubernetes voor DevOps"

Hallo, Habr-Bewoners! Kubernetes is een van de essentiële elementen van de moderne cloud-ecosystemen. Deze technologie garandeert de betrouwbaarheid, schaalbaarheid en veerkracht van containervirtualisatie. John Arundel en Justin Domingus bespreken het Kubernetes-ecosysteem en introduceren bewezen oplossingen voor alledaagse problemen. Stap voor stap bouw je je eigen cloud-gebaseerde applicatie en creëer je de infrastructuur voor ondersteuning, configureer je de ontwikkelomgeving en een continue-uitrolpijplijn die je van pas zal komen bij het werken aan je volgende applicaties.

• Begin met werken met containers en Kubernetes vanaf de basis: er is geen speciale ervaring vereist om het onderwerp te leren. • Start je eigen clusters of kies voor een beheerde Kubernetes-service van Amazon, Google, enz. • Gebruik Kubernetes voor het beheren van de levenscyclus van containers en het beheren van middelen. • Optimaliseer clusters op basis van kosten, prestaties, veerkracht, capaciteit en schaalbaarheid. • Leer de beste tools voor het ontwikkelen, testen en uitrollen van je applicaties. • Maak gebruik van actuele branchepraktijken voor beveiliging en controle. • Implementeer de DevOps-principes in je bedrijf zodat ontwikkelteams flexibeler, sneller en efficiënter kunnen opereren.

Voor wie is het boek bedoeld

Het boek is vooral relevant voor medewerkers van de beheerdersafdelingen die verantwoordelijk zijn voor servers, applicaties en services, evenals voor ontwikkelaars die nieuwe cloudservices bouwen of bestaande applicaties naar Kubernetes en de cloud migreren. Maak je geen zorgen, je hoeft geen ervaring met Kubernetes en containers te hebben — we leren je alles.

Ervaren Kubernetes-gebruikers zullen ook veel waarde vinden: onderwerpen zoals RBAC, continue uitrol, het beheer van vertrouwelijke gegevens en observability worden hier diepgaand behandeld. We hopen dat er op de pagina's van het boek zeker iets interessants voor jou zal staan, ongeacht je vaardigheden en ervaring.

Op welke vragen beantwoordt het boek

Tijdens het plannen en schrijven van het boek hebben we met honderden mensen gesproken over cloudtechnologieën en Kubernetes. We hebben gesproken met zowel leiders en experts op dit gebied als met absolute beginners. Hieronder staan enkele vragen waarvan zij de antwoorden in deze uitgave zouden willen zien.

• «Ik ben benieuwd waarom ik tijd aan deze technologie zou moeten besteden. Welke problemen kan het voor mij en mijn team helpen oplossen?»
• «Kubernetes lijkt interessant, maar heeft een vrij hoge instapdrempel. Het voorbereiden van een eenvoudig voorbeeld is niet moeilijk, maar verder beheer en debugging zijn ontmoedigend. We zouden graag betrouwbare adviezen krijgen over hoe mensen Kubernetes-clusters in de praktijk beheren en met welke problemen we waarschijnlijk zullen worden geconfronteerd.»
• «Een subjectief advies zou nuttig zijn. Het Kubernetes-ecosysteem biedt te veel keuzes voor beginnende teams. Wanneer je hetzelfde op verschillende manieren kunt doen, hoe begrijp je dan welke beter is? Hoe maak je een keuze?»

En misschien wel de belangrijkste vraag van allemaal:

• «Hoe gebruik ik Kubernetes zonder de werking van mijn bedrijf te verstoren?»

Uittreksel. Configuratie en Secret-objecten

De mogelijkheid om de logica van een Kubernetes-applicatie van zijn configuratie te scheiden (dat wil zeggen van waarden of instellingen die in de loop van de tijd kunnen veranderen) is zeer nuttig. Configuratiewaarden zijn doorgaans parameters die zijn bedoeld voor een specifieke omgeving, DNS-adressen van externe diensten en inloggegevens voor authenticatie.

Natuurlijk kan dit allemaal rechtstreeks in de code worden geplaatst, maar deze aanpak is niet voldoende flexibel. Bijvoorbeeld, om een configuratiewaarde te wijzigen, moet je de code opnieuw bouwen en implementeren. Een veel betere oplossing zou zijn om de configuratie van de code te scheiden en deze uit een bestand of omgevingsvariabelen te lezen.

Kubernetes biedt verschillende manieren om configuratie te beheren. Ten eerste kun je waarden aan de applicatie doorgeven via omgevingsvariabelen, zoals gespecificeerd in de pod-spec. (zie het onderdeel 'Omgevingsvariabelen' op p. 192). Ten tweede kunnen configuratiegegevens rechtstreeks in Kubernetes worden opgeslagen met behulp van ConfigMap- en Secret-objecten.

In dit hoofdstuk onderzoeken we deze objecten in detail en bespreken we enkele praktische benaderingen voor configuratiebeheer en de omgang met gevoelige gegevens aan de hand van een voorbeeldapplicatie.

Bijwerken van pod-omslagen bij wijziging van configuratie

Stel je voor dat je een deployment in je cluster hebt en je enkele waarden wilt wijzigen in zijn ConfigMap. Als je een Helm-chart gebruikt (zie de sectie 'Helm: pakketbeheerder voor Kubernetes' op blz. 102), kun je wijzigingen in de configuratie automatisch detecteren en je pod-omslagen herstarten met een elegante truc. Voeg de volgende annotatie toe aan de specificatie van je deployment:

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

Nu bevat het deployment-sjabloon de checksum van de configuratieparameters: wanneer de parameters veranderen, wordt de checksum bijgewerkt. Als je de helm upgrade-opdracht uitvoert, zal Helm ontdekken dat de specificatie van het deployment is gewijzigd en alle pod-omslagen herstarten.

Gevoelige gegevens in Kubernetes

We weten al dat het ConfigMap-object een flexibele manier biedt om configuratiegegevens op te slaan en toegang te krijgen in het cluster. De meeste toepassingen bevatten echter informatie die geheim en vertrouwelijk is: zoals wachtwoorden of API-sleutels. Deze kunnen ook in ConfigMap worden opgeslagen, maar deze oplossing is niet ideaal.

In plaats daarvan biedt Kubernetes een object van een speciaal type, ontworpen voor het opslaan van gevoelige gegevens: Secret. Laten we aan de hand van een voorbeeld bekijken hoe dit object kan worden toegepast in onze demonstratie-applicatie.

Laten we beginnen met het Kubernetes-manifest voor het Secret-object (zie hello-secret-env/k8s/secret.yaml):

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

In dit voorbeeld heeft de geheime sleutel magicWord de waarde xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Het woord xyzzy is in de wereld van computers zeer nuttig. Net als bij ConfigMap kunnen in het Secret-object meerdere sleutels en waarden worden geplaatst. Hier gebruiken we voor de eenvoud slechts één paar 'sleutel - waarde'.

Het gebruik van Secret-objecten als omgevingsveranderingen

Net als ConfigMap kan het Secret-object beschikbaar worden gemaakt in de container als omgevingsveranderingen of als bestand op zijn schijf. In het volgende voorbeeld zullen we de omgevingsverandering een waarde uit Secret geven:

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

Voer de volgende opdracht uit in de demo-repository om de manifesten toe te passen:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" geconfigureerd
secret "demo-secret" aangemaakt

Verbind zoals eerder de lokale poort met de implementatie om het resultaat in uw browser te zien:

kubectl port-forward deploy/demo 9999:8888
Doorsturen vanaf 127.0.0.1:9999 -> 8888
Doorsturen vanaf [::1]:9999 -> 8888

Wanneer u het adres opent localhost:9999/ zou u het volgende moeten zien:

Het magische woord is "xyzzy"

Schrijf secret-objecten naar bestanden

In dit voorbeeld zullen we een secret-object als bestand in de container koppelen. De code bevindt zich in de map hello-secret-file van de demo-repository.

Om de secret als bestand te koppelen, gebruiken we de volgende implementatie:

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

Zoals in de sectie "Configuratiebestanden maken uit ConfigMap-objecten" op pagina 240, maken we een volume (in dit geval demo-secret-volume) en koppelen het aan de container in het volumeMounts-gedeelte. In het mountPath-veld staat "/secrets", zodat Kubernetes in deze map voor elk "sleutel-waarde" paar dat in het secret-object is gedefinieerd, één bestand zal aanmaken.

In ons voorbeeld hebben we slechts één "sleutel-waarde" paar gedefinieerd met de naam magicWord, dus het manifest maakt één bestand "/secrets/magicWord" met vertrouwelijke gegevens in de container, alleen-lezen beschikbaar.

Als je dit manifest op dezelfde manier toepast als in het vorige voorbeeld, zou je hetzelfde resultaat moeten krijgen:

Het magische woord is "xyzzy"

Lezen van secret-objecten

In de vorige sectie hebben we de kubectl describe-opdracht gebruikt om de inhoud van de ConfigMap weer te geven. Is het mogelijk om hetzelfde te doen met een secret?

kubectl describe secret/demo-secret
Naam:          demo-secret

Namespace:      default
Labels:             
Annotaties:
Type:               Opaque

Gegevens
====
magicWord: 5 bytes

Let op dat de gegevens zelf niet worden weergegeven. Secret-objecten in Kubernetes zijn van het type Opaque: dit betekent dat hun inhoud niet wordt weergegeven in de uitvoer van kubectl describe, logboeken en terminal, waardoor het onmogelijk is om per ongeluk vertrouwelijke informatie te onthullen.

Om de gecodeerde versie van vertrouwelijke gegevens in YAML-formaat te bekijken, gebruik de kubectl get-opdracht:

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

base64

Wat is eHl6enk=, het lijkt helemaal niet op onze oorspronkelijke waarde? In werkelijkheid is dit een Secret-object, gepresenteerd in base64-codering. Base64 is een codering schema voor willekeurige binaire gegevens als een tekenreeks.

Aangezien vertrouwelijke informatie binaire gegevens kan zijn en niet beschikbaar is voor uitvoer (zoals in het geval van een TLS-sleutel), worden Secret-objecten altijd opgeslagen in base64-formaat.

De tekst beHl6enk= is een versie van ons geheime woord xyzzy, gecodeerd in base64. Dit kan worden bevestigd door het volgende commando in de terminal uit te voeren: base64 --decode:

echo "eHl6enk=" | base64 --decode
xyzzy

Dus, hoewel Kubernetes je beschermt tegen het per ongeluk weergeven van vertrouwelijke gegevens in de terminal of logbestanden, kunnen deze gegevens, mits je leesrechten hebt op Secret-objecten in een bepaalde namespace, in base64-formaat worden verkregen en later worden gedecodeerd.

Als je tekst in base64 wilt coderen (bijvoorbeeld om deze in een Secret te plaatsen), gebruik dan de base64-opdracht zonder argumenten:

echo xyzzy | base64
eHl6enkK

Toegang tot Secret-objecten

Wie kan Secret-objecten lezen en bewerken? Dit wordt bepaald door RBAC - een toegangscontrolesysteem (hierover zullen we meer bespreken in de sectie 'Inleiding tot rolgebaseerd toegangsbeheer' op blz. 258). Als je een cluster gebruikt waarin RBAC niet aanwezig of niet ingeschakeld is, zijn al je Secret-objecten toegankelijk voor alle gebruikers en containers (later zullen we uitleggen dat je geen enkele productiecluster zonder RBAC zou moeten hebben).

Passieve gegevensversleuteling

Maar wat met degenen die toegang hebben tot de etcd-database, waar Kubernetes al zijn informatie opslaat? Kunnen zij vertrouwelijke gegevens lezen zonder leesrechten op Secret-objecten via de API?

Vanaf versie 1.7 ondersteunt Kubernetes passieve versleuteling van gegevens. Dit betekent dat vertrouwelijke informatie binnen etcd op de schijf in versleutelde vorm wordt opgeslagen en niet kan worden gelezen, zelfs niet door degenen met directe toegang tot de database. Voor decryptie is een sleutel nodig die alleen op de Kubernetes API-server aanwezig is. In een correct geconfigureerde cluster moet passieve versleuteling ingeschakeld zijn.

Je kunt controleren of passieve versleuteling in je cluster werkt op de volgende manier:

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

Als je de vlag experimental-encryption-provider-config niet ziet, is passieve versleuteling niet ingeschakeld. Bij het gebruik van Google Kubernetes Engine of andere Kubernetes-beheerdiensten worden je gegevens versleuteld met een ander mechanisme, dus de vlag ontbreekt. Vraag je Kubernetes-leverancier of de inhoud van etcd versleuteld is.

Opslag van vertrouwelijke gegevens

Er zijn bepaalde Kubernetes-resources die je nooit uit de cluster moet verwijderen: bijvoorbeeld bijzonder belangrijke Secret-objecten. Je kunt een resource tegen verwijdering beschermen met behulp van een annotatie die door de Helm-manager wordt verstrekt:

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

Strategieën voor het beheer van Secret-objecten

In het voorbeeld uit het vorige gedeelte werden vertrouwelijke gegevens beschermd tegen ongeautoriseerde toegang direct na opslag in de cluster. Maar in manifestbestanden werden ze als platte tekst opgeslagen.

Je mag nooit vertrouwelijke informatie plaatsen in bestanden die onder versiebeheer vallen. Hoe beheer en bewaar je deze informatie veilig voordat je deze op de Kubernetes-cluster toepast?

Je kunt elk gereedschap of strategie kiezen voor het werken met vertrouwelijke gegevens in jouw applicaties, maar je moet ten minste de volgende vragen beantwoorden.

• Waar moet je vertrouwelijke gegevens opslaan zodat ze hoog beschikbaar zijn?
• Hoe maak je vertrouwelijke gegevens toegankelijk voor jouw actieve applicaties?
• Wat moet er gebeuren met jouw applicaties wanneer je vertrouwelijke gegevens vervangt of bewerkt?

Over de auteurs

John Arundel is een consultant met 30 jaar ervaring in de computerindustrie. Hij heeft verschillende boeken geschreven en werkt samen met veel bedrijven uit verschillende landen, waarbij hij hen adviseert over cloud-georiënteerde infrastructuur en Kubernetes. In zijn vrije tijd is hij geïnteresseerd in surfen, kan hij goed met een pistool schieten en speelt hij amateuristisch piano. Hij woont in een sprookjesachtig huisje in Cornwall, Engeland.

Justin Domingus is een systeembeheerder die werkt in een DevOps-omgeving met Kubernetes en cloudtechnologieën. Hij brengt graag tijd buiten door, drinkt koffie, vangt krabben en zit achter de computer. Hij woont in Seattle, Washington, samen met zijn geweldige kat en zijn nog geweldigere vrouw, die ook zijn beste vriendin is, Adrienn.

» Meer informatie over het boek is te vinden op de website van de uitgever
» Inhoudsopgave
» Fragment

Voor Habr-bewoners is er 25% korting met de coupon — Kubernetes

Na betaling van de papieren versie van het boek ontvangt u de elektronische versie per e-mail.

Bron: habr.com