Get best of the week

RĂ©servez Kubernetes pour DevOps

imageBonjour, habrozhiteli! Kubernetes est l'un des éléments clés de l'écosystème cloud moderne. Cette technologie offre la fiabilité, l'évolutivité et la résilience de la virtualisation de 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 allez créer votre propre application cloud et créer l'infrastructure pour la prendre en charge, configurer l'environnement de développement et le pipeline de déploiement continu, qui vous seront utiles lorsque vous travaillerez sur les applications suivantes.

• Commencez avec les conteneurs et Kubernetes à partir de zéro: aucune expérience particulière n'est requise pour apprendre le sujet. • Démarrez 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 pour le coût, les performances, la résilience, la puissance et l'évolutivité. • Apprenez les meilleurs outils pour développer, tester et déployer vos applications. • Profitez des pratiques actuelles de l'industrie en matière de sécurité et de contrôle. • Mettez en œuvre les principes DevOps dans votre entreprise afin que les équipes de développement deviennent plus flexibles, rapides et efficaces.

Ă€ qui s'adresse le livre?


Le livre est le plus pertinent pour les employés des services administratifs responsables des serveurs, des applications et des services, ainsi que pour les développeurs impliqués dans la création de nouveaux services cloud ou la migration des applications existantes vers Kubernetes et le cloud. Ne vous inquiétez pas, il n'est pas nécessaire de savoir comment travailler avec Kubernetes et les conteneurs - nous vous apprendrons tout.

Les utilisateurs expérimentés de Kubernetes trouveront également beaucoup de valeur: des sujets tels que RBAC, le déploiement continu, la gestion des données sensibles et l'observabilité sont traités en profondeur. Nous espérons que les pages du livre auront sûrement quelque chose d'intéressant pour vous, quelles que soient vos compétences et votre expérience.

À quelles questions le livre répond-il


Au cours de la planification et de la rédaction du livre, nous avons discuté des technologies cloud et de Kubernetes avec des centaines de personnes, discuté avec des dirigeants et des experts de l'industrie, ainsi qu'avec des débutants absolus. Voici les questions individuelles auxquelles ils aimeraient voir des réponses dans cette publication.

  • «Je voudrais savoir pourquoi il faut consacrer du temps Ă  cette technologie. Quels problèmes m'aidera-t-elle, moi et mon Ă©quipe, Ă  rĂ©soudre? »
  • «Kubernetes semble intĂ©ressant, mais a un seuil d'entrĂ©e assez Ă©levĂ©. PrĂ©parer un exemple simple n'est pas difficile, mais une administration et un dĂ©bogage supplĂ©mentaires sont effrayants. Nous aimerions obtenir des conseils fiables sur la façon dont les gens gèrent les clusters Kubernetes dans la vie rĂ©elle et sur les problèmes que nous sommes susceptibles de rencontrer. »
  • «Des conseils subjectifs seraient utiles. L'Ă©cosystème Kubernetes offre aux Ă©quipes novices un trop grand nombre d'options. Quand la mĂŞme chose peut se faire de plusieurs manières, comment comprendre laquelle est la meilleure? Comment faire un choix? "

Et, probablement, la plus importante de toutes les questions:

  • "Comment utiliser Kubernetes sans perturber mon entreprise?"

Extrait. Configuration et objets secrets


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

Bien sûr, tout cela peut être placé directement dans le code, mais cette approche n'est pas assez flexible. Par exemple, pour modifier la valeur de configuration, vous devrez alors réassembler et déployer votre code. Une bien meilleure solution serait de séparer la configuration du code et de la lire du fichier ou des variables d'environnement.

Kubernetes propose plusieurs façons différentes de gérer votre configuration. Tout d'abord, vous pouvez transmettre des valeurs à l'application via les variables d'environnement spécifiées dans la spécification du shell du pod (voir la section "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 examinerons ces objets en détail et envisagerons des approches pratiques pour gérer la configuration et les données sensibles à l'aide d'un exemple d'application de démonstration.

Mise Ă  jour des shells de pod lors du changement de configurations


Imaginez que votre cluster dispose d'un déploiement et que vous souhaitez modifier certaines valeurs dans son ConfigMap. Si vous utilisez le graphique Helm (voir la section «Helm: Gestionnaire de packages pour Kubernetes» à la page 102), vous pouvez détecter un changement de configuration et redémarrer vos shells de pod avec une astuce élégante. Ajoutez l'annotation suivante à votre spécification de déploiement:

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

Maintenant, le modèle de déploiement contient la somme de contrôle des paramètres de configuration: lorsque les paramètres sont modifiés, la somme est mise à jour. Si vous exécutez la commande de mise à niveau de helm, Helm constatera que la spécification de déploiement a changé et redémarrera tous les shells de pod.

Données confidentielles chez 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 secrètes et confidentielles: par exemple, des mots de passe ou des clés API. Il peut également être stocké dans ConfigMap, mais une telle 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. Ensuite, nous considérons un exemple de la façon dont cet objet peut être appliqué 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 des ordinateurs. Semblable à ConfigMap, vous pouvez placer de nombreuses clés et valeurs dans un objet Secret. Ici, pour plus de simplicité, nous n'utilisons qu'une seule paire clé-valeur.

Utilisation d'objets secrets comme variables d'environnement


Comme ConfigMap, l'objet Secret peut ĂŞtre rendu disponible dans le conteneur en tant que variables d'environnement ou fichier sur son disque. Dans l'exemple suivant, nous assignerons Ă  la 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 référentiel de démonstration pour appliquer les manifestes:

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

Comme précédemment, redirigez 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

Lorsque vous ouvrez l'adresse de l' hĂ´te local : 9999 / vous devriez voir ce qui suit:

The magic word is "xyzzy"

Écriture d'objets secrets dans des fichiers


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

Pour connecter Secret en tant que 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» sur p. 240, nous créons un volume (dans ce cas, demo-secret-volume) et le connectons au conteneur dans la section des spécifications de volumeMounts. MountPath étant / secrets, Kubernetes créera donc un fichier pour chaque paire clé-valeur définie dans l'objet Secret de ce dossier.

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 / secrets / magicWord avec des données confidentielles dans le conteneur en lecture seule.

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

The magic word is "xyzzy"

Lecture d'objets secrets


Dans la section précédente, nous avons utilisé la commande kubectl describe pour afficher le contenu de ConfigMap. Pouvez-vous faire de même 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: cela signifie que leur contenu n'est pas affiché dans la sortie de kubectl decrire, les entrées de journal et le terminal, ce qui rend impossible de révéler accidentellement des informations sensibles.

Pour afficher la version encodée des données sensibles au format YAML, 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 =, qui est complètement différent de notre valeur d'origine? Il s'agit en fait d'un objet Secret, représenté dans le codage base64. Base64 est un schéma de codage pour les données binaires arbitraires sous la forme d'une chaîne de caractères.

Étant donné que les informations confidentielles peuvent être binaires et inaccessibles pour la sortie (comme, par exemple, dans le cas de la clé de chiffrement TLS), les objets secrets sont toujours stockés au format base64.

Le texte beHl6enk = est la version encodée en base64 de notre mot secret xyzzy. Vous pouvez le vérifier si vous exécutez la commande base64 --decode dans le terminal:

echo "eHl6enk=" | base64 --decode
xyzzy

Ainsi, malgré le fait que Kubernetes vous protège contre l'affichage accidentel de données sensibles dans le terminal ou les fichiers journaux, si vous avez le droit de lire des objets secrets dans un espace de noms spécifique, ces données peuvent être reçues au format base64 puis décodées.

Si vous devez coder du texte en base64 (par exemple, pour le mettre en secret), utilisez la commande base64 sans argument:

echo xyzzy | base64
eHl6enkK

Accès aux objets secrets


Qui peut lire et modifier des objets secrets? Ceci est déterminé par RBAC, le mécanisme de contrôle d'accès (nous en discuterons en détail dans la section «Introduction au contrôle d'accès basé sur les rôles» à la page 258). Si vous utilisez un cluster dans lequel le système RBAC est absent ou non activé, tous vos objets Secret sont accessibles à tous les utilisateurs et conteneurs (nous expliquerons plus loin que vous ne devriez pas avoir de cluster industriel sans RBAC).

Cryptage passif des données


Qu'en est-il de ceux qui ont accès à la base de données etcd, dans laquelle Kubernetes stocke toutes ses informations? Peuvent-ils lire des données sensibles sans avoir le droit de lire des 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 confidentielles à l'intérieur de etcd sont stockées sur le disque sous forme cryptée et ne peuvent pas être lues même par ceux qui ont 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é.

Vérifiez si le chiffrement passif fonctionne dans votre cluster en procédant comme suit:

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 cryptage passif n'est pas activé. Lorsque vous utilisez le moteur Google Kubernetes ou d'autres services de gestion Kubernetes, vos données sont cryptées à l'aide d'un mécanisme différent, de sorte que l'indicateur sera absent. Vérifiez auprès de votre fournisseur Kubernetes pour voir si le contenu de etcd est crypté.

Stockage de données confidentielles


Il existe des ressources Kubernetes qui ne doivent jamais être supprimées d'un cluster: par exemple, des objets secrets particulièrement importants. Vous pouvez protéger la ressource contre la suppression à l'aide de l'annotation fournie par Helm Manager:

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

Stratégies de gestion d'objets secrets


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

Vous ne devez jamais placer d'informations confidentielles dans des fichiers qui se trouvent dans le système de contrôle de version. Comment administrer et stocker ces informations en toute sécurité avant de les appliquer à un cluster Kubernetes?

Vous pouvez choisir n'importe quel outil ou stratégie pour travailler avec des données sensibles dans vos applications, mais vous devez toujours répondre au moins aux questions suivantes.

  • OĂą stocker les donnĂ©es sensibles afin qu'elles soient hautement accessibles?
  • Comment mettre des donnĂ©es sensibles Ă  la disposition de vos applications actives?
  • , ?


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 basée sur le cloud et Kubernetes. Pendant son temps libre, il aime surfer, tire avec un bon pistolet et joue du piano de façon amateur. Vit dans un fabuleux chalet à Cornwall, en Angleterre.

Justin Domingus est un ingénieur d'administration système travaillant dans un environnement DevOps avec Kubernetes et les technologies cloud. Il aime passer du temps à l'extérieur, boire du café, attraper des crabes et s'asseoir devant l'ordinateur. Vit à Seattle, Washington, avec un chat merveilleux et une femme encore plus merveilleuse et la meilleure amie à temps partiel Adrienne.

»Plus d'informations sur le livre peuvent être trouvées sur le site Web de l'éditeur
» Contenu
» Extrait

pour Khabrozhiteley 25% de réduction sur le coupon - Kubernetes

Lors du paiement de la version papier du livre, un livre électronique est envoyé par e-mail.

More articles:


All Articles