Boek “Kubernetes voor DevOps”

Hallo, inwoners van Khabro! Kubernetes is een van de belangrijkste elementen van het moderne cloud-ecosysteem. Deze technologie biedt betrouwbaarheid, schaalbaarheid en veerkracht voor containervirtualisatie. John Arundel en Justin Domingus praten over het Kubernetes-ecosysteem en introduceren bewezen oplossingen voor alledaagse problemen. Stap voor stap bouwt u uw eigen cloud-native applicatie en creëert u de infrastructuur om deze te ondersteunen, zet u een ontwikkelomgeving en een continue implementatiepijplijn op die u zullen helpen bij het werken aan uw volgende applicaties.

• Ga vanaf de basis aan de slag met containers en Kubernetes: er is geen speciale ervaring vereist om het onderwerp te leren. • Voer uw eigen clusters uit of kies een beheerde Kubernetes-service van Amazon, Google, enz. • Gebruik Kubernetes om de levenscyclus van containers en het resourceverbruik te beheren. • Optimaliseer clusters op basis van kosten, prestaties, veerkracht, kracht en schaalbaarheid. • Leer de beste tools om uw applicaties te ontwikkelen, testen en implementeren. • Maak gebruik van de huidige praktijken in de sector om veiligheid en controle te garanderen. • Implementeer DevOps-principes in uw hele bedrijf, zodat ontwikkelteams flexibeler, sneller en efficiënter kunnen handelen.

Voor wie is het boek bedoeld?

Het boek is het meest relevant voor medewerkers van administratieve afdelingen die verantwoordelijk zijn voor servers, applicaties en diensten, maar ook voor ontwikkelaars die betrokken zijn bij het bouwen van nieuwe clouddiensten of het migreren van bestaande applicaties naar Kubernetes en de cloud. Maak je geen zorgen, je hoeft niet te weten hoe je met Kubernetes of containers moet werken: wij leren je alles.

Ervaren Kubernetes-gebruikers zullen ook veel waarde vinden, met een diepgaande dekking van onderwerpen als RBAC, continue implementatie, gevoelig gegevensbeheer en observatie. We hopen dat de pagina's van het boek zeker iets interessants voor u zullen bevatten, ongeacht uw vaardigheden en ervaring.

Welke vragen beantwoordt het boek?

Tijdens het plannen en schrijven van het boek bespraken we cloudtechnologie en Kubernetes met honderden mensen, waarbij we spraken met marktleiders en experts, maar ook met complete beginners. Hieronder vindt u een aantal vragen die zij graag beantwoord zouden zien in deze publicatie.

• “Ik ben geïnteresseerd in waarom je tijd aan deze technologie zou moeten besteden. Welke problemen zal het mij en mijn team helpen oplossen?”
• “Kubernetes lijkt interessant, maar kent een vrij hoge toetredingsdrempel. Het voorbereiden van een eenvoudig voorbeeld is niet moeilijk, maar verder beheer en debuggen is lastig. We willen graag betrouwbaar advies krijgen over hoe mensen Kubernetes-clusters in de echte wereld beheren en welke problemen we waarschijnlijk tegenkomen."
• “Subjectief advies zou nuttig zijn. Het Kubernetes-ecosysteem geeft nieuwe teams te veel opties om uit te kiezen. Als er meerdere manieren zijn om hetzelfde te doen, hoe weet je dan welke de beste is? Hoe maak je een keuze?

En misschien wel de belangrijkste van alle vragen:

• “Hoe kan ik Kubernetes gebruiken zonder mijn bedrijf te ontwrichten?”

Uittreksel. Configuratie en geheime objecten

De mogelijkheid om de logica van een Kubernetes-applicatie te scheiden van de configuratie ervan (dat wil zeggen, van eventuele waarden of instellingen die in de loop van de tijd kunnen veranderen) is erg handig. Configuratiewaarden omvatten doorgaans omgevingsspecifieke instellingen, DNS-adressen van services van derden en authenticatiereferenties.

Uiteraard kan dit allemaal direct in de code worden gezet, maar deze aanpak is niet flexibel genoeg. Als u bijvoorbeeld een configuratiewaarde wijzigt, moet u uw 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 de configuratie te beheren. Ten eerste kunt u waarden doorgeven aan de toepassing via omgevingsvariabelen die zijn opgegeven in de pod-wrapperspecificatie (zie “Omgevingsvariabelen” op pagina 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 bekijken we enkele praktische benaderingen voor het beheren van configuratie- en gevoelige gegevens met behulp van een demotoepassing.

Podshells bijwerken wanneer de configuratie verandert

Stel je voor dat je een implementatie in je cluster hebt en dat je enkele waarden in de ConfigMap ervan wilt wijzigen. Als u het Helm-diagram gebruikt (zie “Helm: Pakketbeheer voor Kubernetes” op pagina 102), kunt u automatisch een configuratiewijziging detecteren en uw podshells in één handig trucje opnieuw laden. Voeg de volgende annotatie toe aan uw implementatiespecificatie:

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

De implementatiesjabloon bevat nu een controlesom van configuratieparameters: als de parameters worden gewijzigd, wordt de som bijgewerkt. Als u een helm-upgrade uitvoert, detecteert Helm dat de implementatiespecificatie is gewijzigd en worden alle pod-shells opnieuw opgestart.

Gevoelige gegevens in Kubernetes

We weten al dat het ConfigMap-object een flexibel mechanisme biedt voor het opslaan en openen van configuratiegegevens in een cluster. De meeste applicaties beschikken echter over informatie die gevoelig en gevoelig is, zoals wachtwoorden of API-sleutels. Het kan ook worden opgeslagen in ConfigMap, maar deze oplossing is niet ideaal.

In plaats daarvan biedt Kubernetes een speciaal type object dat is ontworpen om gevoelige gegevens op te slaan: geheim. Laten we vervolgens eens kijken naar een voorbeeld van hoe dit object kan worden gebruikt in onze demo-applicatie.

Bekijk om te beginnen 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 is de privésleutel van magicWord xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Het woord xyzzy is over het algemeen erg handig in de computerwereld. Net als bij ConfigMap kunt u meerdere sleutels en waarden opslaan in een geheim object. Voor de eenvoud gebruiken we hier slechts één sleutel-waardepaar.

Geheime objecten gebruiken als omgevingsvariabelen

Net als ConfigMap kan het Secret-object in de container beschikbaar worden gemaakt als omgevingsvariabelen of als een bestand op de schijf. In het volgende voorbeeld wijzen we een omgevingsvariabele toe aan de waarde uit Secret:

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 demorepository om de manifesten toe te passen:

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

Stuur net als voorheen de lokale poort door naar de implementatie om het resultaat in uw browser te bekijken:

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

Bij het openen van een adres localhost:9999/ je zou het volgende moeten zien:

The magic word is "xyzzy"

Geheime objecten naar bestanden schrijven

In dit voorbeeld zullen we het Secret-object als bestand aan de container koppelen. De code bevindt zich in de map hello-secret-file van de demorepository.

Om Secret als bestand te koppelen, gebruiken we de volgende inzet:

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 subsectie “Configuratiebestanden maken van ConfigMap-objecten” op p. 240 maken we een volume (in dit geval demo-secret-volume) en koppelen dit aan de container in de volumeMounts-sectie van de specificatie. Het mountPath-veld is /secrets, dus Kubernetes maakt één bestand in deze map voor elk sleutel/waarde-paar dat is gedefinieerd in het Secret-object.

In ons voorbeeld hebben we slechts één sleutel-waardepaar gedefinieerd, genaamd magicWord, dus het manifest zal een enkel alleen-lezen bestand /secrets/magicWord creëren met gevoelige gegevens in de container.

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

The magic word is "xyzzy"

Geheime voorwerpen lezen

In de vorige sectie hebben we de opdracht kubectl write gebruikt om de inhoud van een ConfigMap weer te geven. Kan hetzelfde worden gedaan met Secret?

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

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

Data
====
magicWord: 5   bytes

Houd er rekening mee dat de gegevens zelf niet worden weergegeven. Geheime objecten in Kubernetes zijn van het type Opaque, wat betekent dat hun inhoud niet wordt weergegeven in de uitvoer van kubectl, logboekinvoer of de terminal, waardoor het onmogelijk wordt om per ongeluk gevoelige informatie te onthullen.

Om een ​​gecodeerde YAML-versie van gevoelige gegevens te bekijken, gebruikt u de opdracht kubectl get:

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

base64

Wat is eHl6enk=, totaal anders dan onze oorspronkelijke waarde? Dit is eigenlijk een geheim object, weergegeven in base64-codering. Base64 is een schema voor het coderen van willekeurige binaire gegevens als een reeks tekens.

Omdat gevoelige informatie binair kan zijn en niet wordt uitgevoerd (zoals het geval is bij een TLS-coderingssleutel), worden geheime objecten altijd opgeslagen in het base64-formaat.

De tekst beHl6enk= is de base64-gecodeerde versie van ons geheime woord xyzzy. U kunt dit verifiëren door de opdracht base64 —decode in de terminal uit te voeren:

echo "eHl6enk=" | base64 --decode
xyzzy

Dus hoewel Kubernetes u beschermt tegen het per ongeluk uitvoeren van gevoelige gegevens in de terminal- of logbestanden, kunnen die gegevens worden gebase64ed en vervolgens gedecodeerd als u leesrechten hebt voor geheime objecten in een specifieke naamruimte.

Als u tekst met base64 moet coderen (bijvoorbeeld om deze in een geheim te plaatsen), gebruikt u de opdracht base64 zonder argumenten:

echo xyzzy | base64
eHl6enkK

Toegang tot geheime objecten

Wie kan geheime objecten lezen en bewerken? Dit wordt bepaald door RBAC, een toegangscontrolemechanisme (we zullen dit in detail bespreken in de subsectie “Inleiding tot op rollen gebaseerde toegangscontrole” op pagina 258). Als u een cluster gebruikt dat geen RBAC heeft of niet is ingeschakeld, zijn al uw geheime objecten beschikbaar voor alle gebruikers en containers (we zullen later uitleggen dat u geen productieclusters zou moeten hebben zonder RBAC).

Passieve gegevensversleuteling

Hoe zit het met degenen die toegang hebben tot de etcd-database waar Kubernetes al zijn informatie opslaat? Kunnen ze gevoelige gegevens lezen zonder toestemming te hebben om geheime objecten via de API te lezen?

Sinds versie 1.7 ondersteunt Kubernetes passieve gegevensversleuteling. Dit betekent dat gevoelige informatie binnen etcd gecodeerd op schijf wordt opgeslagen en niet kan worden gelezen, zelfs niet door degenen met directe toegang tot de database. Om het te decoderen heb je een sleutel nodig die alleen de Kubernetes API-server heeft. In een correct geconfigureerd cluster moet passieve versleuteling zijn ingeschakeld.

U kunt op deze manier controleren of passieve versleuteling in uw cluster werkt:

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

Als u de vlag experimentele-encryption-provider-config niet ziet, is passieve codering niet ingeschakeld. Wanneer u Google Kubernetes Engine of andere Kubernetes-beheerdiensten gebruikt, worden uw gegevens via een ander mechanisme versleuteld, zodat de vlag niet aanwezig is. Neem contact op met uw Kubernetes-leverancier om te zien of etcd-inhoud is gecodeerd.

Het opslaan van vertrouwelijke gegevens

Er zijn enkele Kubernetes-bronnen die nooit uit het cluster mogen worden verwijderd, zoals zeer gevoelige geheime objecten. U kunt voorkomen dat een bron wordt verwijderd met behulp van een annotatie van de Helm-manager:

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

Strategieën voor geheim objectbeheer

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

Plaats nooit vertrouwelijke informatie in bestanden die onder versiebeheer staan. Hoe kunt u deze informatie veilig beheren en opslaan voordat u deze toepast op uw Kubernetes-cluster?

U kunt alle tools of strategieën kiezen voor het omgaan met gevoelige gegevens in uw toepassingen, maar u moet nog steeds ten minste de volgende vragen beantwoorden.

• Waar moeten gevoelige gegevens worden opgeslagen, zodat deze zeer toegankelijk zijn?
• Hoe kunt u gevoelige gegevens toegankelijk maken voor uw actieve applicaties?
• Wat moet er met uw applicaties gebeuren als u gevoelige gegevens vervangt of bewerkt?

Over de Auteurs

Johannes Arundel is een consultant met 30 jaar ervaring in de computerindustrie. Hij heeft verschillende boeken geschreven en werkt met veel bedrijven uit verschillende landen, waarbij hij hen adviseert over cloud-native infrastructuur en Kubernetes. In zijn vrije tijd houdt hij van surfen, kan hij goed schieten en speelt hij piano als amateur. Woont in een sprookjesachtig huisje in Cornwall, Engeland.

Justin Domingus — systeembeheeringenieur werkzaam in een DevOps-omgeving met Kubernetes en cloudtechnologieën. Hij brengt graag tijd buitenshuis door, drinkt koffie, krabbelt en zit achter de computer. Woont in Seattle, Washington, met een geweldige kat en een nog geweldigere vrouw en beste vriendin, Adrienne.

» Meer details over het boek zijn te vinden op website van de uitgever
» inhoudsopgave
» Uittreksel

Voor Khabrozhiteley 25% korting met coupon - Kubernetes

Na betaling van de papieren versie van het boek wordt een elektronisch boek per e-mail verzonden.

Bron: www.habr.com