Livre « Kubernetes pour DevOps »

Bonjour, résidents de Khabro ! Kubernetes est l'un des éléments clés de l'écosystème cloud moderne. Cette technologie offre fiabilité, évolutivité et résilience à la virtualisation des conteneurs. John Arundel et Justin Domingus parlent de l'écosystème Kubernetes et présentent des solutions éprouvées aux problèmes quotidiens. Étape par étape, vous créerez votre propre application cloud native et créerez l'infrastructure pour la prendre en charge, mettrez en place un environnement de développement et un pipeline de déploiement continu qui vous aideront dans votre travail sur vos prochaines applications.

• Démarrez avec les conteneurs et Kubernetes à partir des bases : aucune expérience particulière n'est requise pour apprendre le sujet. • Exécutez vos propres clusters ou choisissez un service Kubernetes géré d'Amazon, Google, etc. • Utilisez Kubernetes pour gérer le cycle de vie des conteneurs et la consommation des ressources. • Optimiser les clusters en fonction du coût, des performances, de la résilience, de la puissance et de l'évolutivité. • Découvrez les meilleurs outils pour développer, tester et déployer vos applications. • Tirer parti des pratiques actuelles de l'industrie pour garantir la sécurité et le contrôle. • Mettez en œuvre les principes DevOps dans toute votre entreprise afin que les équipes de développement puissent agir de manière plus flexible, plus rapide et plus efficace.

A qui s'adresse le livre ?

Le livre s'adresse particulièrement aux employés des services d'administration responsables des serveurs, des applications et des services, ainsi qu'aux développeurs impliqués soit dans la création de nouveaux services cloud, soit dans la migration d'applications existantes vers Kubernetes et le cloud. Ne vous inquiétez pas, vous n'avez pas besoin de savoir travailler avec Kubernetes ou des conteneurs : nous vous apprendrons tout.

Les utilisateurs expérimentés de Kubernetes y trouveront également beaucoup de valeur, avec une couverture approfondie de sujets tels que RBAC, le déploiement continu, la gestion des données sensibles et l'observabilité. Nous espérons que les pages du livre contiendront certainement quelque chose d'intéressant pour vous, quelles que soient vos compétences et votre expérience.

À quelles questions répond le livre ?

Lors de la planification et de la rédaction du livre, nous avons discuté de la technologie cloud et de Kubernetes avec des centaines de personnes, en discutant avec des leaders et des experts du secteur ainsi qu'avec de parfaits novices. Vous trouverez ci-dessous une sélection de questions auxquelles ils aimeraient voir une réponse dans cette publication.

• « Je voudrais savoir pourquoi vous devriez consacrer du temps à cette technologie. Quels problèmes cela va-t-il aider, moi et mon équipe, à résoudre ? »
• « Kubernetes semble intéressant, mais présente une barrière à l'entrée assez élevée. Préparer un exemple simple n’est pas difficile, mais la poursuite de l’administration et du débogage est intimidante. Nous aimerions obtenir des conseils fiables sur la manière dont les gens gèrent les clusters Kubernetes dans le monde réel et sur les problèmes que nous sommes susceptibles de rencontrer. »
• « Des conseils subjectifs seraient utiles. L’écosystème Kubernetes offre aux nouvelles équipes trop d’options parmi lesquelles choisir. Lorsqu’il existe plusieurs façons de faire la même chose, comment savoir laquelle est la meilleure ? Comment faire un choix ?

Et peut-être la plus importante de toutes les questions :

• « Comment puis-je utiliser Kubernetes sans perturber mon entreprise ? »

Extrait. Objets de configuration et secrets

La possibilité de séparer la logique d'une application Kubernetes de sa configuration (c'est-à-dire de toute valeur ou paramètre susceptible de changer au fil du temps) est très utile. Les valeurs de configuration incluent généralement des paramètres spécifiques à l'environnement, des adresses DNS de services tiers et des informations d'authentification.

Bien entendu, tout cela peut être mis directement dans le code, mais cette approche n’est pas assez flexible. Par exemple, la modification d’une valeur de configuration vous obligerait alors à créer et à déployer à nouveau votre code. Une bien meilleure solution serait de séparer la configuration du code et de la lire à partir d'un fichier ou de variables d'environnement.

Kubernetes propose plusieurs manières différentes de gérer la configuration. Tout d'abord, vous pouvez transmettre des valeurs à l'application via les variables d'environnement spécifiées dans la spécification du wrapper de pod (voir « Variables d'environnement » à la page 192). Deuxièmement, les données de configuration peuvent être stockées directement dans Kubernetes à l'aide des objets ConfigMap et Secret.

Dans ce chapitre, nous explorons ces objets en détail et examinons quelques approches pratiques pour gérer la configuration et les données sensibles à l'aide d'une application de démonstration.

Mise à jour des shells de pods lorsque la configuration change

Imaginez que vous ayez un déploiement dans votre cluster et que vous souhaitiez modifier certaines valeurs dans son ConfigMap. Si vous utilisez le graphique Helm (voir « Helm : Package Manager for Kubernetes » à la page 102), vous pouvez détecter automatiquement un changement de configuration et recharger les shells de vos pods en une seule astuce. Ajoutez l'annotation suivante à votre spécification de déploiement :

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

Le modèle de déploiement contient désormais une somme de contrôle des paramètres de configuration : si les paramètres sont modifiés, la somme sera mise à jour. Si vous exécutez helm update, Helm détectera que la spécification de déploiement a changé et redémarrera tous les shells de pod.

Données sensibles dans Kubernetes

Nous savons déjà que l'objet ConfigMap fournit un mécanisme flexible pour stocker et accéder aux données de configuration dans un cluster. Cependant, la plupart des applications contiennent des informations sensibles et confidentielles, telles que des mots de passe ou des clés API. Il peut également être stocké dans ConfigMap, mais cette solution n'est pas idéale.

Au lieu de cela, Kubernetes propose un type spécial d'objet conçu pour stocker des données sensibles : Secret. Examinons ensuite un exemple de la façon dont cet objet peut être utilisé dans notre application de démonstration.

Pour commencer, jetez un œil au manifeste Kubernetes pour l'objet Secret (voir hello-secret-env/k8s/secret.yaml) :

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

Dans cet exemple, la clé privée magicWord est xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Le mot xyzzy est généralement très utile dans le monde informatique. Semblable à ConfigMap, vous pouvez stocker plusieurs clés et valeurs dans un objet Secret. Ici, par souci de simplicité, nous utilisons une seule paire clé-valeur.

Utilisation d'objets secrets comme variables d'environnement

Comme ConfigMap, l'objet Secret peut être mis à disposition dans le conteneur sous forme de variables d'environnement ou sous forme de fichier sur son disque. Dans l'exemple suivant, nous attribuerons une variable d'environnement à la valeur de Secret :

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

Exécutez la commande suivante dans le dépôt de démonstration pour appliquer les manifestes :

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

Comme auparavant, transférez le port local vers le déploiement pour voir le résultat dans votre navigateur :

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

Lors de l'ouverture d'une adresse localhost:9999/ vous devriez voir ce qui suit :

The magic word is "xyzzy"

Écrire des objets secrets dans des fichiers

Dans cet exemple, nous allons attacher l'objet Secret au conteneur sous forme de fichier. Le code se trouve dans le dossier hello-secret-file du référentiel de démonstration.

Pour connecter Secret sous forme de fichier, nous utiliserons le déploiement suivant :

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

Comme dans la sous-section « Création de fichiers de configuration à partir d'objets ConfigMap » à la p. 240, nous créons un volume (dans ce cas demo-secret-volume) et le montons sur le conteneur dans la section volumeMounts de la spécification. Le champ mountPath est /secrets, donc Kubernetes créera un fichier dans ce dossier pour chaque paire clé/valeur définie dans l'objet Secret.

Dans notre exemple, nous avons défini une seule paire clé-valeur appelée magicWord, de sorte que le manifeste créera un seul fichier en lecture seule /secrets/magicWord avec des données sensibles dans le conteneur.

Si vous appliquez ce manifeste de la même manière que l’exemple précédent, vous devriez obtenir le même résultat :

The magic word is "xyzzy"

Lire des objets secrets

Dans la section précédente, nous avons utilisé la commande kubectl décrire pour afficher le contenu d'un ConfigMap. Peut-on faire la même chose avec Secret ?

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

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

Data
====
magicWord: 5   bytes

Veuillez noter que les données elles-mêmes ne sont pas affichées. Les objets secrets dans Kubernetes sont de type Opaque, ce qui signifie que leur contenu n'est pas affiché dans la sortie de Kubectl, les entrées de journal ou le terminal, ce qui rend impossible la révélation accidentelle d'informations sensibles.

Pour afficher une version YAML codée de données sensibles, utilisez la commande kubectl get :

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

base64

Qu'est-ce que eHl6enk=, complètement différent de notre valeur originale ? Il s'agit en fait d'un objet Secret, représenté en codage base64. Base64 est un système permettant de coder des données binaires arbitraires sous forme de chaîne de caractères.

Étant donné que les informations sensibles peuvent être binaires et ne pas être affichées (comme c'est le cas avec une clé de chiffrement TLS), les objets secrets sont toujours stockés au format base64.

Le texte beHl6enk= est la version codée en base64 de notre mot secret xyzzy. Vous pouvez le vérifier en exécutant la commande base64 —decode dans le terminal :

echo "eHl6enk=" | base64 --decode
xyzzy

Ainsi, bien que Kubernetes vous protège contre la sortie accidentelle de données sensibles dans le terminal ou dans les fichiers journaux, si vous disposez d'autorisations de lecture sur les objets secrets dans un espace de noms spécifique, ces données peuvent être basées sur une base64 et ensuite décodées.

Si vous devez encoder du texte en base64 (par exemple, pour le mettre dans un secret), utilisez la commande base64 sans arguments :

echo xyzzy | base64
eHl6enkK

Accéder aux objets secrets

Qui peut lire et modifier les objets secrets ? Ceci est déterminé par RBAC, un mécanisme de contrôle d'accès (nous en discuterons en détail dans la sous-section « Introduction au contrôle d'accès basé sur les rôles » à la page 258). Si vous exécutez un cluster qui ne dispose pas de RBAC ou n'est pas activé, tous vos objets Secret sont disponibles pour tous les utilisateurs et conteneurs (nous expliquerons plus tard que vous ne devriez avoir aucun cluster de production sans RBAC).

Cryptage passif des données

Qu’en est-il de ceux qui ont accès à la base de données etcd où Kubernetes stocke toutes ses informations ? Peuvent-ils lire des données sensibles sans avoir l’autorisation de lire les objets secrets via l’API ?

Depuis la version 1.7, Kubernetes prend en charge le chiffrement passif des données. Cela signifie que les informations sensibles contenues dans etcd sont stockées cryptées sur le disque et ne peuvent pas être lues même par ceux ayant un accès direct à la base de données. Pour le déchiffrer, vous avez besoin d'une clé que seul le serveur API Kubernetes possède. Dans un cluster correctement configuré, le chiffrement passif doit être activé.

Vous pouvez vérifier si le chiffrement passif fonctionne dans votre cluster de cette manière :

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

Si vous ne voyez pas l’indicateur experimental-encryption-provider-config, le chiffrement passif n’est pas activé. Lorsque vous utilisez Google Kubernetes Engine ou d'autres services de gestion Kubernetes, vos données sont chiffrées à l'aide d'un mécanisme différent, l'indicateur ne sera donc pas présent. Vérifiez auprès de votre fournisseur Kubernetes si le contenu etcd est chiffré.

Stockage de données confidentielles

Certaines ressources Kubernetes ne doivent jamais être supprimées du cluster, telles que les objets secrets hautement sensibles. Vous pouvez protéger une ressource contre la suppression à l'aide d'une annotation fournie par le gestionnaire Helm :

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

Stratégies de gestion des objets secrets

Dans l'exemple de la section précédente, les données sensibles étaient protégées contre tout accès non autorisé immédiatement après avoir été stockées dans le cluster. Mais dans les fichiers manifestes, ils étaient stockés sous forme de texte brut.

Vous ne devez jamais placer d’informations confidentielles dans des fichiers sous contrôle de version. Comment gérer et stocker ces informations en toute sécurité avant de les appliquer à votre cluster Kubernetes ?

Vous pouvez choisir n’importe quel outil ou stratégie pour gérer les données sensibles dans vos applications, mais vous devrez quand même répondre au moins aux questions suivantes.

• Où les données sensibles doivent-elles être stockées pour qu’elles soient hautement accessibles ?
• Comment rendre les données sensibles accessibles à vos applications actives ?
• Que doit-il arriver à vos applications lorsque vous remplacez ou modifiez des données sensibles ?

À propos des auteurs

John Arundel est un consultant avec 30 ans d'expérience dans l'industrie informatique. Il a écrit plusieurs livres et travaille avec de nombreuses entreprises de différents pays, les conseillant sur l'infrastructure cloud native et Kubernetes. Dans ses temps libres, il aime surfer, est un bon tireur au pistolet et joue du piano en amateur. Vit dans un cottage de conte de fées à Cornwall, en Angleterre.

Justin Domingue — ingénieur en administration système travaillant dans un environnement DevOps avec Kubernetes et les technologies cloud. Il aime passer du temps dehors, boire du café, pêcher du crabe et s'asseoir devant l'ordinateur. Vit à Seattle, Washington, avec un chat merveilleux et une épouse et meilleure amie encore plus merveilleuse, Adrienne.

» Plus de détails sur le livre peuvent être trouvés sur site de l'éditeur
» table des matières
» Extrait

Pour Khabrozhiteley, 25 % de réduction en utilisant le coupon - Kubernetes

Dès paiement de la version papier du livre, un livre électronique sera envoyé par e-mail.

Source: habr.com