Kubernetes Basics
Bases de Kubernetes
L'auteur original de cette page est Jorge (lisez son post original ici)
Architecture et bases
Que fait Kubernetes ?
Permet d'exécuter un ou des conteneurs dans un moteur de conteneurs.
La planification permet d'optimiser les missions des conteneurs.
Garde les conteneurs en vie.
Permet les communications entre les conteneurs.
Permet les techniques de déploiement.
Gère des volumes d'informations.
Architecture
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-68.jpg&width=768&dpr=4&quality=100&sign=4902871c&sv=1)
Node : système d'exploitation avec un pod ou des pods.
Pod : Enveloppe autour d'un conteneur ou de plusieurs conteneurs. Un pod ne devrait contenir qu'une seule application (donc généralement, un pod exécute juste 1 conteneur). Le pod est la façon dont Kubernetes abstrait la technologie des conteneurs en cours d'exécution.
Service : Chaque pod a une adresse IP interne de la plage interne du nœud. Cependant, il peut également être exposé via un service. Le service a également une adresse IP et son objectif est de maintenir la communication entre les pods, donc si l'un meurt, le nouveau remplacement (avec une adresse IP interne différente) sera accessible exposé dans la même IP du service. Il peut être configuré comme interne ou externe. Le service agit également comme un équilibreur de charge lorsque 2 pods sont connectés au même service. Lorsqu'un service est créé, vous pouvez trouver les points de terminaison de chaque service en exécutant
kubectl get endpoints
Kubelet : Agent principal du nœud. Le composant qui établit la communication entre le nœud et kubectl, et ne peut exécuter que des pods (via le serveur API). Le kubelet ne gère pas les conteneurs qui n'ont pas été créés par Kubernetes.
Kube-proxy : est le service chargé des communications (services) entre l'apiserver et le nœud. La base est un IPtables pour les nœuds. Les utilisateurs les plus expérimentés pourraient installer d'autres kube-proxies provenant d'autres fournisseurs.
Conteneur Sidecar : Les conteneurs Sidecar sont les conteneurs qui doivent s'exécuter aux côtés du conteneur principal dans le pod. Ce modèle Sidecar étend et améliore la fonctionnalité des conteneurs actuels sans les modifier. De nos jours, nous savons que nous utilisons la technologie des conteneurs pour encapsuler toutes les dépendances nécessaires à l'exécution de l'application n'importe où. Un conteneur ne fait qu'une seule chose et le fait très bien.
Processus maître :
Serveur API : C'est la façon dont les utilisateurs et les pods communiquent avec le processus maître. Seules les demandes authentifiées doivent être autorisées.
Ordonnanceur : L'ordonnancement consiste à s'assurer que les Pods sont associés à des nœuds pour que Kubelet puisse les exécuter. Il a suffisamment d'intelligence pour décider quel nœud a plus de ressources disponibles et attribuer le nouveau pod à celui-ci. Notez que l'ordonnanceur ne démarre pas de nouveaux pods, il communique simplement avec le processus Kubelet s'exécutant à l'intérieur du nœud, qui lancera le nouveau pod.
Gestionnaire de contrôleur Kube : Il vérifie les ressources comme les ensembles de réplicas ou les déploiements pour vérifier si, par exemple, le bon nombre de pods ou de nœuds est en cours d'exécution. En cas de pod manquant, il communiquera avec l'ordonnanceur pour en démarrer un nouveau. Il contrôle la réplication, les jetons et les services de compte vers l'API.
etcd : Stockage de données, persistant, cohérent et distribué. C'est la base de données de Kubernetes et le stockage clé-valeur où il conserve l'état complet des clusters (chaque changement est consigné ici). Des composants comme l'Ordonnanceur ou le Gestionnaire de contrôle dépendent de ces données pour savoir quels changements se sont produits (ressources disponibles des nœuds, nombre de pods en cours d'exécution...)
Gestionnaire de contrôleur Cloud : C'est le contrôleur spécifique pour les contrôles de flux et les applications, par exemple : si vous avez des clusters sur AWS ou OpenStack.
Notez qu'il peut y avoir plusieurs nœuds (exécutant plusieurs pods), il peut également y avoir plusieurs processus maîtres dont l'accès à l'apiserver est équilibré et leur etcd synchronisé.
Volumes :
Lorsqu'un pod crée des données qui ne doivent pas être perdues lorsque le pod disparaît, elles doivent être stockées dans un volume physique. Kubernetes permet de joindre un volume à un pod pour persister les données. Le volume peut être sur la machine locale ou dans un stockage distant. Si vous exécutez des pods sur différents nœuds physiques, vous devriez utiliser un stockage distant pour que tous les pods puissent y accéder.
Autres configurations :
ConfigMap : Vous pouvez configurer des URL pour accéder aux services. Le pod obtiendra des données d'ici pour savoir comment communiquer avec le reste des services (pods). Notez que ce n'est pas l'endroit recommandé pour enregistrer des informations d'identification !
Secret : C'est l'endroit pour stocker des données secrètes comme des mots de passe, des clés API... encodés en B64. Le pod pourra accéder à ces données pour utiliser les informations d'identification requises.
Déploiements : C'est là que les composants à exécuter par Kubernetes sont indiqués. Un utilisateur ne travaillera généralement pas directement avec des pods, les pods sont abstraits dans des Répliques (nombre de mêmes pods répliqués), qui sont exécutés via des déploiements. Notez que les déploiements sont pour des applications sans état. La configuration minimale pour un déploiement est le nom et l'image à exécuter.
StatefulSet : Ce composant est spécifiquement destiné aux applications comme les bases de données qui ont besoin d'accéder au même stockage.
Ingress : C'est la configuration qui est utilisée pour exposer l'application publiquement avec une URL. Notez que cela peut également être fait en utilisant des services externes, mais c'est la bonne façon d'exposer l'application.
Si vous implémentez un Ingress, vous devrez créer des Contrôleurs Ingress. Le Contrôleur Ingress est un pod qui sera le point de terminaison qui recevra les demandes, les vérifiera et les équilibrera vers les services. le contrôleur Ingress enverra la demande en fonction des règles Ingress configurées. Notez que les règles Ingress peuvent pointer vers différents chemins ou même sous-domaines vers différents services internes de Kubernetes.
Une meilleure pratique de sécurité serait d'utiliser un équilibreur de charge cloud ou un serveur proxy comme point d'entrée pour ne pas exposer une partie du cluster Kubernetes.
Lorsqu'une demande qui ne correspond à aucune règle Ingress est reçue, le contrôleur Ingress la dirigera vers le "Backend par défaut". Vous pouvez
décrire
le contrôleur Ingress pour obtenir l'adresse de ce paramètre.minikube addons enable ingress
Infrastructure PKI - Autorité de certification CA :
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-66.jpg&width=768&dpr=4&quality=100&sign=ddfcd3be&sv=1)
CA est la racine de confiance pour tous les certificats à l'intérieur du cluster.
Permet aux composants de se valider mutuellement.
Tous les certificats du cluster sont signés par la CA.
ETCd a son propre certificat.
types :
certificat apiserver.
certificat kubelet.
certificat scheduler.
Actions de base
Minikube
Minikube peut être utilisé pour effectuer certains tests rapides sur Kubernetes sans avoir besoin de déployer tout un environnement Kubernetes. Il exécutera les processus maître et nœud sur une seule machine. Minikube utilisera virtualbox pour exécuter le nœud. Voir ici comment l'installer.
Bases de Kubectl
Kubectl
est l'outil en ligne de commande pour les clusters Kubernetes. Il communique avec le serveur Api du processus maître pour effectuer des actions dans Kubernetes ou demander des données.
Tableau de bord Minikube
Le tableau de bord vous permet de voir plus facilement ce que minikube exécute, vous pouvez trouver l'URL pour y accéder dans :
Exemples de fichiers de configuration YAML
Chaque fichier de configuration a 3 parties : métadonnées, spécification (ce qui doit être lancé), état (état souhaité). À l'intérieur de la spécification du fichier de configuration de déploiement, vous pouvez trouver le modèle défini avec une nouvelle structure de configuration définissant l'image à exécuter :
Exemple de déploiement + service déclaré dans le même fichier de configuration (à partir de ici)
Comme un service est généralement lié à un déploiement, il est possible de déclarer les deux dans le même fichier de configuration (le service déclaré dans cette configuration n'est accessible qu'en interne) :
Exemple de configuration de service externe
Ce service sera accessible de l'extérieur (vérifiez les attributs nodePort
et type: LoadBalancer
):
Ceci est utile pour les tests mais pour la production, vous devriez avoir uniquement des services internes et un Ingress pour exposer l'application.
Exemple de fichier de configuration Ingress
Cela exposera l'application sur http://dashboard.com
.
Exemple de fichier de configuration des secrets
Notez comment les mots de passe sont encodés en B64 (ce qui n'est pas sécurisé !)
Exemple de ConfigMap
Un ConfigMap est la configuration qui est donnée aux pods afin qu'ils sachent comment localiser et accéder à d'autres services. Dans ce cas, chaque pod saura que le nom mongodb-service
est l'adresse d'un pod avec lequel ils peuvent communiquer (ce pod exécutera un mongodb) :
Ensuite, à l'intérieur d'une configuration de déploiement, cette adresse peut être spécifiée de la manière suivante pour être chargée à l'intérieur de l'environnement de la capsule :
Exemple de configuration de volume
Vous pouvez trouver différents exemples de fichiers de configuration yaml de stockage sur https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes. Notez que les volumes ne sont pas à l'intérieur des espaces de noms
Espaces de noms
Kubernetes prend en charge plusieurs clusters virtuels pris en charge par le même cluster physique. Ces clusters virtuels sont appelés espaces de noms. Ils sont destinés à être utilisés dans des environnements avec de nombreux utilisateurs répartis sur plusieurs équipes ou projets. Pour les clusters avec quelques dizaines d'utilisateurs, vous ne devriez pas avoir besoin de créer ou de penser aux espaces de noms du tout. Vous devriez commencer à utiliser les espaces de noms pour avoir un meilleur contrôle et une meilleure organisation de chaque partie de l'application déployée dans Kubernetes.
Les espaces de noms fournissent une portée pour les noms. Les noms des ressources doivent être uniques dans un espace de noms, mais pas à travers les espaces de noms. Les espaces de noms ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut être que dans un espace de noms.
Il y a 4 espaces de noms par défaut si vous utilisez minikube:
kube-system: Ce n'est pas destiné à être utilisé par les utilisateurs et vous ne devriez pas y toucher. C'est pour les processus master et kubectl.
kube-public: Données accessibles publiquement. Contient un configmap qui contient des informations sur le cluster.
kube-node-lease: Détermine la disponibilité d'un nœud.
default: L'espace de noms que l'utilisateur utilisera pour créer des ressources.
Notez que la plupart des ressources Kubernetes (par exemple, pods, services, contrôleurs de réplication, et autres) sont dans certains espaces de noms. Cependant, d'autres ressources comme les ressources de namespace et les ressources de bas niveau, telles que les nœuds et les volumes persistants, ne sont pas dans un espace de noms. Pour voir quelles ressources Kubernetes sont et ne sont pas dans un espace de noms :
Vous pouvez enregistrer l'espace de noms pour toutes les commandes kubectl ultérieures dans ce contexte.
Helm
Helm est le gestionnaire de packages pour Kubernetes. Il permet de regrouper des fichiers YAML et de les distribuer dans des dépôts publics et privés. Ces packages sont appelés Helm Charts.
Secrets Kubernetes
Un Secret est un objet qui contient des données sensibles telles qu'un mot de passe, un jeton ou une clé. Ces informations pourraient autrement être placées dans une spécification de Pod ou dans une image. Les utilisateurs peuvent créer des Secrets et le système crée également des Secrets. Le nom d'un objet Secret doit être un nom de sous-domaine DNS valide. Lisez ici la documentation officielle.
Les Secrets peuvent être des choses comme :
Clés API, SSH.
Jetons OAuth.
Informations d'identification, mots de passe (en texte clair ou en base64 + chiffrement).
Informations ou commentaires.
Code de connexion à une base de données, chaînes… .
Il existe différents types de secrets dans Kubernetes
Type intégré | Utilisation |
---|---|
Opaque | données définies par l'utilisateur (par défaut) |
kubernetes.io/service-account-token | jeton de compte de service |
kubernetes.io/dockercfg | fichier ~/.dockercfg sérialisé |
kubernetes.io/dockerconfigjson | fichier ~/.docker/config.json sérialisé |
kubernetes.io/basic-auth | informations d'identification pour l'authentification de base |
kubernetes.io/ssh-auth | informations d'identification pour l'authentification SSH |
kubernetes.io/tls | données pour un client ou serveur TLS |
bootstrap.kubernetes.io/token | données de jeton d'amorçage |
Le type Opaque est celui par défaut, la paire clé-valeur typique définie par les utilisateurs.
Fonctionnement des secrets :
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-164.jpg&width=768&dpr=4&quality=100&sign=407ce89f&sv=1)
Le fichier de configuration suivant définit un secret appelé mysecret
avec 2 paires clé-valeur username: YWRtaW4=
et password: MWYyZDFlMmU2N2Rm
. Il définit également un pod appelé secretpod
qui aura les username
et password
définis dans mysecret
exposés dans les variables d'environnement SECRET_USERNAME
et SECRET_PASSWOR
. Il montera également le secret username
à l'intérieur de mysecret
dans le chemin /etc/foo/my-group/my-username
avec des permissions 0640
.
Secrets in etcd
etcd est un magasin de clés-valeurs cohérent et hautement disponible utilisé comme support de stockage Kubernetes pour toutes les données du cluster. Accédons aux secrets stockés dans etcd :
Vous verrez que les certificats, clés et URL sont situés dans le système de fichiers. Une fois que vous les aurez obtenus, vous pourrez vous connecter à etcd.
Une fois que vous avez établi la communication, vous pourriez obtenir les secrets :
Ajout de chiffrement à l'ETCD
Par défaut, tous les secrets sont stockés en clair à l'intérieur de etcd à moins que vous n'appliquiez une couche de chiffrement. L'exemple suivant est basé sur https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Après cela, vous devez définir le drapeau --encryption-provider-config
sur le kube-apiserver
pour pointer vers l'emplacement du fichier de configuration créé. Vous pouvez modifier /etc/kubernetes/manifest/kube-apiserver.yaml
et ajouter les lignes suivantes:
Faites défiler vers le bas dans les volumeMounts :
Faites défiler vers le bas dans les volumeMounts vers hostPath:
Vérification de l'encryption des données
Les données sont chiffrées lorsqu'elles sont écrites dans etcd. Après avoir redémarré votre kube-apiserver
, tout secret nouvellement créé ou mis à jour devrait être chiffré lorsqu'il est stocké. Pour vérifier, vous pouvez utiliser le programme en ligne de commande etcdctl
pour récupérer le contenu de votre secret.
Créez un nouveau secret appelé
secret1
dans l'espace de nomsdefault
:
En utilisant la ligne de commande
etcdctl
, lisez ce secret depuis etcd :
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
où [...]
doivent être les arguments supplémentaires pour se connecter au serveur etcd. 3. Vérifiez que le secret stocké est préfixé par k8s:enc:aescbc:v1:
, ce qui indique que le fournisseur aescbc
a chiffré les données résultantes. 4. Vérifiez que le secret est correctement déchiffré lorsqu'il est récupéré via l'API :
devrait correspondre à mykey: bXlkYXRh
, mydata est encodé, consultez le décodage d'un secret pour décoder complètement le secret.
Étant donné que les secrets sont chiffrés à l'écriture, toute mise à jour d'un secret chiffrera ce contenu :
Conseils finaux :
Essayez de ne pas garder de secrets dans le système de fichiers, obtenez-les d'ailleurs.
Consultez https://www.vaultproject.io/ pour ajouter une protection supplémentaire à vos secrets.
Références
Last updated