Hola, residents de Khabro! Kubernetes és un dels elements clau de l'ecosistema del núvol modern. Aquesta tecnologia proporciona fiabilitat, escalabilitat i resistència a la virtualització de contenidors. John Arundel i Justin Domingus parlen de l'ecosistema Kubernetes i presenten solucions provades als problemes quotidians. Pas a pas, crearàs la teva pròpia aplicació nativa del núvol i crearàs la infraestructura per donar-hi suport, configuraràs un entorn de desenvolupament i una canalització de desplegament contínua que t'ajudarà a treballar en les teves properes aplicacions.
• Comenceu amb els contenidors i Kubernetes des de les bases: no cal experiència especial per aprendre el tema. • Executeu els vostres propis clústers o trieu un servei Kubernetes gestionat d'Amazon, Google, etc. • Utilitzeu Kubernetes per gestionar el cicle de vida dels contenidors i el consum de recursos. • Optimitzar els clústers en funció del cost, rendiment, resiliència, potència i escalabilitat. • Aprèn les millors eines per desenvolupar, provar i desplegar les teves aplicacions. • Aprofitar les pràctiques actuals del sector per garantir la seguretat i el control. • Implementeu els principis de DevOps a tota la vostra empresa perquè els equips de desenvolupament puguin actuar de manera més flexible, ràpida i eficient.
Per a qui va el llibre?
El llibre és més rellevant per als empleats dels departaments d'administració responsables de servidors, aplicacions i serveis, així com per als desenvolupadors que participen en la creació de nous serveis al núvol o en la migració d'aplicacions existents a Kubernetes i al núvol. No et preocupis, no cal que sàpigues com treballar amb Kubernetes o contenidors: t'ensenyarem tot.
Els usuaris experimentats de Kubernetes també trobaran molt de valor, amb una cobertura en profunditat de temes com ara RBAC, desplegament continu, gestió de dades sensibles i observabilitat. Esperem que les pàgines del llibre continguin alguna cosa interessant per a tu, independentment de les teves habilitats i experiència.
Quines preguntes respon el llibre?
Durant la planificació i l'escriptura del llibre, vam parlar de la tecnologia del núvol i de Kubernetes amb centenars de persones, parlant amb líders i experts del sector, així com amb novells complets. A continuació es mostren preguntes seleccionades que els agradaria que es responguessin en aquesta publicació.
- "Estic interessat en per què hauríeu de dedicar temps a aquesta tecnologia. Quins problemes m'ajudarà a resoldre'm a mi i al meu equip?"
- "Kubernetes sembla interessant, però té una barrera d'entrada força alta. Preparar un exemple senzill no és difícil, però una altra administració i depuració és descoratjador. Ens agradaria obtenir consells fiables sobre com la gent gestiona els clústers de Kubernetes al món real i quins problemes és probable que ens trobem".
- "Un consell subjectiu seria útil. L'ecosistema de Kubernetes ofereix als nous equips massa opcions per triar. Quan hi ha diverses maneres de fer el mateix, com saps quina és la millor? Com fer una elecció?
I potser la més important de totes les preguntes:
- "Com puc utilitzar Kubernetes sense interrompre la meva empresa?"
Fragment. Configuració i objectes secrets
La possibilitat de separar la lògica d'una aplicació Kubernetes de la seva configuració (és a dir, de qualsevol valor o configuració que pugui canviar amb el temps) és molt útil. Els valors de configuració solen incloure paràmetres específics de l'entorn, adreces DNS de serveis de tercers i credencials d'autenticació.
Per descomptat, tot això es pot posar directament al codi, però aquest enfocament no és prou flexible. Per exemple, canviar un valor de configuració requeriria que tornis a crear i desplegar el codi. Una solució molt millor seria separar la configuració del codi i llegir-la des d'un fitxer o variables d'entorn.
Kubernetes ofereix diverses maneres diferents de gestionar la configuració. En primer lloc, podeu passar valors a l'aplicació mitjançant les variables d'entorn especificades a l'especificació del pod wrapper (vegeu “Variables d'entorn” a la pàgina 192). En segon lloc, les dades de configuració es poden emmagatzemar directament a Kubernetes mitjançant ConfigMap i objectes Secret.
En aquest capítol, explorem aquests objectes en detall i analitzem alguns enfocaments pràctics per gestionar la configuració i les dades sensibles mitjançant una aplicació de demostració.
Actualització de pod shells quan canvia la configuració
Imagineu que teniu un desplegament al vostre clúster i voleu canviar alguns valors al seu ConfigMap. Si utilitzeu el gràfic Helm (vegeu “Helm: Gestor de paquets per a Kubernetes” a la pàgina 102), podeu detectar automàticament un canvi de configuració i tornar a carregar els vostres pod shells amb un senzill truc. Afegiu l'anotació següent a la vostra especificació de desplegament:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}La plantilla de desplegament ara conté una suma de control dels paràmetres de configuració: si es canvien els paràmetres, la suma s'actualitzarà. Si executeu l'actualització de Helm, Helm detectarà que l'especificació de desplegament ha canviat i reiniciarà tots els pod shells.
Dades sensibles a Kubernetes
Ja sabem que l'objecte ConfigMap proporciona un mecanisme flexible per emmagatzemar i accedir a les dades de configuració en un clúster. Tanmateix, la majoria de les aplicacions tenen informació sensible i sensible, com ara contrasenyes o claus API. També es pot emmagatzemar a ConfigMap, però aquesta solució no és ideal.
En canvi, Kubernetes ofereix un tipus especial d'objecte dissenyat per emmagatzemar dades sensibles: Secret. A continuació, mirem un exemple de com es pot utilitzar aquest objecte a la nostra aplicació de demostració.
Per començar, mireu el manifest de Kubernetes per a l'objecte Secret (vegeu hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
En aquest exemple, la clau privada magicWord és xyzzy (en.wikipedia.org/wiki/Xyzzy_(informàtica)). La paraula xyzzy és generalment molt útil en el món de la informàtica. De manera similar a ConfigMap, podeu emmagatzemar diverses claus i valors en un objecte Secret. Aquí, per simplificar, només fem servir un parell clau-valor.
Ús d'objectes secrets com a variables d'entorn
Igual que ConfigMap, l'objecte Secret es pot fer disponible al contenidor com a variables d'entorn o com a fitxer al seu disc. En l'exemple següent, assignarem una variable d'entorn al valor de Secret:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordExecuteu l'ordre següent al repositori de demostració per aplicar els manifests:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" createdCom abans, reenvieu el port local al desplegament per veure el resultat al vostre navegador:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888En obrir una adreça :9999/ hauríeu de veure el següent:
The magic word is "xyzzy"
Escriptura d'objectes secrets en fitxers
En aquest exemple, adjuntarem l'objecte Secret al contenidor com a fitxer. El codi es troba a la carpeta hello-secret-file del dipòsit de demostració.
Per connectar Secret com a fitxer, farem servir el desplegament següent:
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-secretCom a la subsecció "Creació de fitxers de configuració a partir d'objectes ConfigMap" a la p. 240, creem un volum (en aquest cas demo-secret-volume) i el muntem al contenidor a la secció volumMounts de l'especificació. El camp mountPath és /secrets, de manera que Kubernetes crearà un fitxer en aquesta carpeta per a cada parell clau/valor definit a l'objecte Secret.
Al nostre exemple, només hem definit un parell clau-valor anomenat magicWord, de manera que el manifest crearà un únic fitxer de només lectura /secrets/magicWord amb dades sensibles al contenidor.
Si apliqueu aquest manifest de la mateixa manera que l'exemple anterior, hauríeu d'obtenir el mateix resultat:
The magic word is "xyzzy"
Lectura d'objectes secrets
A la secció anterior, hem utilitzat l'ordre kubectl describe per mostrar el contingut d'un ConfigMap. Es pot fer el mateix amb Secret?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesTingueu en compte que les dades en si no es mostren. Els objectes secrets de Kubernetes són de tipus Opac, la qual cosa significa que el seu contingut no es mostra a la sortida de Kubectl describe, les entrades de registre o el terminal, cosa que fa impossible revelar accidentalment informació sensible.
Per veure una versió YAML codificada de dades sensibles, utilitzeu l'ordre kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase 64
Què és eHl6enk=, completament diferent del nostre valor original? Aquest és en realitat un objecte secret, representat en la codificació base64. Base64 és un esquema per codificar dades binàries arbitràries com una cadena de caràcters.
Com que la informació sensible pot ser binària i no sortir (com és el cas d'una clau de xifratge TLS), els objectes secrets sempre s'emmagatzemen en format base64.
El text beHl6enk= és la versió codificada en base64 de la nostra paraula secreta xyzzy. Podeu verificar-ho executant l'ordre base64 —decode al terminal:
echo "eHl6enk=" | base64 --decode
xyzzyAixí, tot i que Kubernetes us protegeix de la sortida accidental de dades sensibles al terminal o als fitxers de registre, si teniu permisos de lectura sobre objectes secrets en un espai de noms específic, aquestes dades es poden basar i posteriorment descodificar.
Si necessiteu codificar un text en base64 (per exemple, per posar-lo en un secret), utilitzeu l'ordre base64 sense arguments:
echo xyzzy | base64
eHl6enkKAccés a objectes secrets
Qui pot llegir i editar objectes secrets? Això ho determina l'RBAC, un mecanisme de control d'accés (ho parlarem amb detall a la subsecció “Introducció al control d'accés basat en rols” a la pàgina 258). Si esteu executant un clúster que no té RBAC o no està habilitat, tots els vostres objectes secrets estan disponibles per a qualsevol usuari i contenidor (explicarem més endavant que no hauríeu de tenir cap clúster de producció sense RBAC).
Xifratge passiu de dades
Què passa amb els que tenen accés a la base de dades etcd on Kubernetes emmagatzema tota la seva informació? Poden llegir dades sensibles sense tenir permís per llegir objectes secrets mitjançant l'API?
Des de la versió 1.7, Kubernetes admet el xifratge passiu de dades. Això significa que la informació sensible dins d'etcd s'emmagatzema xifrada al disc i no pot ser llegida ni tan sols per aquells que tinguin accés directe a la base de dades. Per desxifrar-lo, necessiteu una clau que només té el servidor de l'API de Kubernetes. En un clúster configurat correctament, s'hauria d'habilitar el xifratge passiu.
Podeu comprovar si el xifratge passiu funciona al vostre clúster d'aquesta manera:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Si no veieu la marca experimental-encryption-provider-config, el xifratge passiu no està habilitat. Quan utilitzeu Google Kubernetes Engine o altres serveis de gestió de Kubernetes, les vostres dades s'encripten mitjançant un mecanisme diferent, de manera que la marca no estarà present. Consulteu amb el vostre proveïdor de Kubernetes per veure si el contingut etcd està xifrat.
Emmagatzematge de dades confidencials
Hi ha alguns recursos de Kubernetes que mai s'han d'eliminar del clúster, com ara objectes secrets altament sensibles. Podeu protegir un recurs perquè no s'elimini mitjançant una anotació proporcionada pel gestor de Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepEstratègies secretes de gestió d'objectes
A l'exemple de la secció anterior, les dades sensibles estaven protegides de l'accés no autoritzat immediatament després d'haver-se emmagatzemat al clúster. Però als fitxers de manifest s'emmagatzemaven com a text senzill.
No heu de col·locar mai informació confidencial en fitxers que es troben en control de versions. Com podeu gestionar i emmagatzemar de manera segura aquesta informació abans d'aplicar-la al vostre clúster de Kubernetes?
Podeu triar qualsevol eina o estratègia per gestionar dades sensibles a les vostres aplicacions, però encara haureu de respondre almenys les preguntes següents.
- On s'han d'emmagatzemar les dades sensibles perquè siguin molt accessibles?
- Com fer que les dades sensibles siguin accessibles a les vostres aplicacions actives?
- Què hauria de passar amb les vostres aplicacions quan substituïu o editeu dades sensibles?
Sobre els autors
Joan Arundel és un consultor amb 30 anys d'experiència en el sector informàtic. Ha escrit diversos llibres i treballa amb moltes empreses de diferents països, assessorant-los sobre infraestructures natives del núvol i Kubernetes. En el seu temps lliure, li agrada fer surf, és un bon tirador de pistoles i toca el piano com a aficionat. Viu en una casa de contes de fades a Cornualla, Anglaterra.
Justin Domingus — enginyer d'administració de sistemes que treballa en un entorn DevOps amb Kubernetes i tecnologies al núvol. Li agrada passar temps a l'aire lliure, beure cafè, cranc i asseure's a l'ordinador. Viu a Seattle, Washington, amb un gat meravellós i una dona i millor amiga encara més meravellosa, Adrienne.
» Podeu trobar més detalls sobre el llibre a
»
»
Per a Khabrozhiteley 25% de descompte amb cupó - Kubernetes
Un cop pagada la versió en paper del llibre, s'enviarà un llibre electrònic per correu electrònic.
Font: www.habr.com
