Bonjour, membres de Habr! Kubernetes est un des éléments clés de l'écosystème cloud moderne. Cette technologie assure 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. Pas à pas, vous construirez votre propre application orientée cloud et créerez l'infrastructure pour la soutenir, configurerez l'environnement de développement et un pipeline de déploiement continu, qui vous sera utile pour vos prochaines applications.
• Vous commencerez à travailler avec des conteneurs et Kubernetes dès le début : aucune expérience particulière n'est requise pour étudier le sujet. • Lancez vos propres clusters ou optez pour un service Kubernetes géré proposé par Amazon, Google, etc. • Utilisez Kubernetes pour gérer le cycle de vie desconteneurs et la consommation des ressources. • Optimisez les clusters en fonction des coûts, des performances, de la résilience, de la puissance et de l'évolutivité. • Découvrez les meilleurs outils pour le développement, les tests et le déploiement de vos applications. • Appliquez les pratiques industrielles à jour pour garantir la sécurité et le contrôle. • Implémentez des principes DevOps dans votre entreprise afin que les équipes de développement agissent de manière plus agile, rapide et efficace.
À qui s'adresse le livre
Le livre est particulièrement pertinent pour les employés des départements d'administration responsables des serveurs, applications et services, ainsi que pour les développeurs concernéss par la création de nouveaux services cloud ou la migration d'applications existantes vers Kubernetes et le cloud. Ne vous inquiétez pas, il n'est pas nécessaire de savoir travailler avec Kubernetes et les conteneurs - nous vous apprendrons tout.
Les utilisateurs avancés de Kubernetes trouveront également de nombreuses informations précieuses : des sujets tels que RBAC, le déploiement continu, la gestion des données sensibles et la surveillance y sont abordés en profondeur. Nous espérons qu'il y aura quelque chose d'intéressant pour vous dans les pages du livre, quel que soit votre niveau de compétence et votre expérience.
À quelles questions répond le livre
Lors de la planification et de la rédaction de ce livre, nous avons discuté des technologies cloud et de Kubernetes avec des centaines de personnes, échangés avec des leaders et des experts du secteur, ainsi qu'avec des novices complets. Ci-dessous figurent quelques questions pour lesquelles ils souhaiteraient voir des réponses dans cette publication.
- « Je me demande pourquoi je devrais consacrer du temps à cette technologie. Quels problèmes cela aidera-t-il à résoudre pour moi et mon équipe ? »
- « Kubernetes semble intéressant, mais il a un seuil d'entrée assez élevé. Préparer un exemple simple n'est pas difficile, mais l'administration et le débogage ultérieurs peuvent être intimidants. Nous aimerions obtenir des conseils fiables sur la façon dont les gens gèrent des clusters Kubernetes dans des conditions réelles et les problèmes auxquels nous serons probablement confrontés. »
- « Un conseil subjectif serait utile. L'écosystème Kubernetes offre trop d'options pour les équipes débutantes. Quand il est possible d'accomplir la même tâche de plusieurs manières, comment savoir laquelle est la meilleure ? Comment faire un choix ? »
Et, c'est probablement la question la plus importante de toutes :
- « Comment utiliser Kubernetes sans perturber les opérations de mon entreprise ? »
Extrait. Configuration et objets Secret
La possibilité de séparer la logique de l'application Kubernetes de sa configuration (c'est-à-dire de toutes les valeurs ou réglages qui peuvent changer au fil du temps) est très utile. Les valeurs de configuration incluent généralement des paramètres destinés à un environnement spécifique, des adresses DNS de services tiers et des informations d'identification pour l'authentification.
Bien sûr, tout cela peut être intégré directement dans le code, mais cette approche n'est pas assez flexible. Par exemple, pour modifier une valeur de configuration, vous devrez reconstruire et redéployer 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 fournit plusieurs moyens différents de gérer la configuration. Tout d'abord, vous pouvez passer des valeurs à l'application via des variables d'environnement spécifiées dans la spécification de pod (voir la section « Variables d'environnement » à la page 192). Deuxièmement, les données de configuration peuvent être stockées directement dans Kubernetes en utilisant des objets ConfigMap et Secret.
Dans ce chapitre, nous allons examiner en détail ces objets et explorer certaines approches pratiques pour gérer la configuration et les données sensibles, à l'aide d'une application démonstration.
Mise à jour des pod lors de la modification de la configuration
Imaginez que vous avez un déploiement dans votre cluster et que vous souhaitez modifier certaines valeurs dans son ConfigMap. Si vous utilisez un chart Helm (voir la section « Helm : gestionnaire de packages pour Kubernetes » à la page 102), il est possible de détecter le changement de configuration et de redémarrer vos pods automatiquement grâce à une astuce élégante. Ajoutez l'annotation suivante à la spécification de votre déploiement :
checksum/config: {{ include (print $.Template.BasePath "\/configmap.yaml") .
| sha256sum }}Maintenant, le modèle de déploiement contient un checksum des paramètres de configuration : lorsqu'ils changent, le checksum sera mis à jour. En exécutant la commande helm upgrade, Helm détectera que la spécification du déploiement a été modifiée et redémarrera tous les pods.
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 le cluster. Cependant, la plupart des applications contiennent des informations qui sont secrètes et confidentielles, telles que des mots de passe ou des clés API. Ces données peuvent également être stockées dans un ConfigMap, mais ce n'est pas une solution idéale.
Au lieu de cela, Kubernetes propose un objet de type spécial destiné au stockage de données sensibles : Secret. Nous allons examiner, avec un exemple, comment cet objet peut être utilisé dans notre application de démonstration.
Pour commencer, regardez le 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é secrète magicWord a la valeur xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Le mot xyzzy est en fait très utile dans le monde de l'informatique. De la même manière qu'avec ConfigMap, il est possible d'avoir plusieurs clés et valeurs dans l'objet Secret. Ici, pour des raisons de simplicité, nous utilisons seulement une paire « clé - valeur ».
Utilisation des objets Secret comme variables d'environnement
Comme avec ConfigMap, l'objet Secret peut être rendu accessible dans le conteneur sous forme de variables d'environnement ou de fichier sur son disque. Dans l'exemple suivant, nous allons assigner une variable d'environnement une valeur provenant de Secret :
spécificités :
conteneurs :
- nom : demo
image : cloudnatived/demo:hello-secret-env
ports :
- containerPort : 8888
env :
- name : GREETING
valueFrom :
secretKeyRef :
name : demo-secret
key : magicWordExécutez la commande suivante dans le dépôt demo pour appliquer les manifestes :
kubectl apply -f hello-secret-env/k8s/
déploiement.extensions "demo" configuré
secret "demo-secret" crééComme auparavant, redirigez le port local vers le déploiement pour voir le résultat dans votre navigateur :
kubectl port-forward deploy/demo 9999:8888
Transfert de 127.0.0.1:9999 -> 8888
Transfert de [::1]:9999 -> 8888En ouvrant l'adresse :9999/ vous devez voir ce qui suit :
Le mot magique est "xyzzy"
Écriture des objets Secret dans des fichiers
Dans cet exemple, nous monterons l'objet Secret dans le conteneur sous forme de fichier. Le code se trouve dans le dossier hello-secret-file du dépôt demo.
Pour monter le Secret sous forme de fichier, nous utiliserons le déploiement suivant :
spécificités :
conteneurs :
- nom : 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-secretComme dans la section « Création de fichiers de configuration à partir d'objets ConfigMap » à la page 240, nous créons un volume (dans ce cas, il s'agit de demo-secret-volume) et le montons dans le conteneur au niveau de la spécification volumeMounts. Le champ mountPath indique /secrets, donc Kubernetes créera un fichier pour chaque paire « clé - valeur » définie dans l'objet Secret.
Dans notre exemple, nous avons défini une seule paire « clé - valeur » nommée magicWord, donc le manifeste créera dans le conteneur un seul fichier /secrets/magicWord avec des données sensibles, accessible en lecture seule.
Si ce manifeste est appliqué de la même manière que dans l'exemple précédent, le même résultat doit être obtenu :
Le mot magique est "xyzzy"
Lecture des objets Secret
Dans la section précédente, nous avons utilisé la commande kubectl describe pour afficher le contenu de ConfigMap. Peut-on faire de même avec Secret ?
kubectl describe secret/demo-secret
Nom : demo-secret
Namespace : default
Labels :
Annotations :
Type : Opaque
Données
====
magicWord : 5 octetsNotez que les données elles-mêmes ne s'affichent pas. Les objets Secret dans Kubernetes sont de type Opaque : cela signifie que leur contenu n'apparaît pas dans la sortie de kubectl describe, dans les journaux et dans le terminal, ce qui empêche la divulgation accidentelle d'informations sensibles.
Pour visualiser 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: Opaquebase64
Qu'est-ce que eHl6enk=, cela ne ressemble pas du tout à notre valeur d'origine ? En réalité, c'est un objet Secret, représenté en encodage base64. Base64 est un schéma d'encodage de données binaires arbitraires sous forme de chaînes de caractères.
Puisque les informations sensibles peuvent être binaires et non accessibles en sortie (comme dans le cas d'une clé de chiffrement TLS), les objets Secret sont toujours stockés au format base64.
Le texte beHl6enk= est une version de notre mot secret xyzzy, encodée en base64. On peut le vérifier en exécutant dans le terminal la commande base64 --decode :
echo "eHl6enk=" | base64 --decode
xyzzyAinsi, bien que Kubernetes vous protège contre l'affichage accidentel de données sensibles dans le terminal ou les fichiers journaux, si vous avez des droits de lecture sur les objets Secret dans un espace de noms donné, ces données peuvent être obtenues au format base64 et ensuite décodées.
Si vous devez encoder du texte en base64 (par exemple, pour l'incorporer dans un Secret), utilisez la commande base64 sans arguments :
echo xyzzy | base64
eHl6enkKAccès aux objets Secret
Qui peut lire et éditer les objets Secret ? Cela est déterminé par RBAC — un mécanisme de contrôle d'accès (nous en discuterons en détail dans la section « Introduction à la gestion des accès basée sur les rôles » à la page 258). Si vous utilisez un cluster dans lequel le système RBAC est absent ou désactivé, tous vos objets Secret sont accessibles par n'importe quel utilisateur et conteneur (nous expliquerons plus tard que vous ne devriez pas avoir de cluster de production sans RBAC).
Chiffrement passif des données
Et 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 les données sensibles sans avoir de droits de lecture sur les objets Secret via l'API ?
À partir de la version 1.7, Kubernetes prend en charge le chiffrement passif des données. Cela signifie que les informations sensibles au sein de etcd sont stockées sur le disque sous forme chiffrée et ne peuvent pas être lues même par ceux ayant un accès direct à la base de données. Pour les déchiffrer, il faut une clé qui n'est détenue que par le serveur API Kubernetes. Dans un cluster correctement configuré, le chiffrement passif doit être activé.
Vous pouvez vérifier si le chiffrement passif fonctionne dans votre cluster de la manière suivante :
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Si vous ne voyez pas le drapeau experimental-encryption-provider-config, le chiffrement passif n'est pas activé. En utilisant Google Kubernetes Engine ou d'autres services de gestion de Kubernetes, vos données sont chiffrées par un autre mécanisme, donc le drapeau sera absent. Demandez à votre fournisseur Kubernetes si le contenu d'etcd est chiffré.
Stockage des données sensibles
Il existe des ressources Kubernetes qui ne doivent jamais être supprimées du cluster : par exemple, des objets Secret particulièrement importants. Vous pouvez protéger une ressource contre la suppression en utilisant une annotation fournie par le gestionnaire Helm :
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepStratégies de gestion des objets Secret
Dans l'exemple de la section précédente, les données sensibles étaient protégées contre l'accès non autorisé dès leur enregistrement dans le cluster. Cependant, dans les fichiers de manifestes, elles étaient stockées sous forme de texte clair.
Vous ne devez jamais placer d'informations sensibles dans des fichiers qui sont dans un 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 devrez néanmoins répondre à au moins les questions suivantes.
- Où stocker des données sensibles pour qu'elles soient hautement disponibles ?
- Comment rendre les données sensibles accessibles à vos applications actives ?
- Que doit-il se passer avec vos applications lorsque vous remplacez ou modifiez des données sensibles ?
À propos des auteurs
John Arundel est 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 les infrastructures cloud et Kubernetes. Dans son temps libre, il aime surfer, tir au pistolet et joue du piano en amateur. Il vit dans un cottage féerique en Cornouailles, en Angleterre.
Justin Domingus — ingénieur 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 être devant l'ordinateur. Il vit à Seattle, Washington, avec son chat fantastique et sa femme encore plus incroyable, qui est en même temps sa meilleure amie, Édriane.
» Pour plus de détails sur le livre, vous pouvez consulter
»
»
Pour les membres de Habr, une remise de 25 % avec le code promotionnel — Kubernetes
Après le paiement de la version papier du livre, un livre électronique sera envoyé par e-mail.
Source : habr.com
