Craig Bowers, développeur principal de systèmes Cloud, ajoute un nouvel article à sa série de blogs Kubernetes 101. Cet article vise à donner un aperçu de la manière d’interagir avec le cluster de différentes façons pour déployer des pods.
Dans le troisième volet de la série k8s 101, je vais donner un aperçu de la façon d’interagir avec le cluster de différentes manières pour déployer des pods. Il s’agit de la suite du deuxième blog. Si vous ne l’avez pas déjà lu, vous pouvez le lire ici.
J’ai parlé de tous les composants qui constituent un environnement Kubernetes, du plan de contrôle aux nœuds de travail, en passant par les ressources qui sont déployées pour rendre un cluster k8s fonctionnel. Vous vous demandez peut-être comment réaliser les déploiements de ressources et gérer leur cycle de vie. Laissez-moi vous présenter l’utilitaire kubectl, prononcé kube-CTL ou kube-cuttle. Kubectl est une interface de ligne de commande pour exécuter des commandes sur votre cluster. Vous devez être authentifié(e) et disposer des configurations locales appropriées pour que l’utilitaire fonctionne correctement, mais j’aborderai ce point dans la prochaine série.
Gestion des ressources
En général, pour la plupart des ressources, vous générez un fichier YAML qui décrit la ressource que vous créez, communément appelé manifeste. Le déploiement de vos ressources k8s via YAML vous permet de contrôler la version de vos ressources de cluster, ainsi que de redéployer une réplique exacte de l’environnement en cas de catastrophe. Dans le manifeste, le mot-clé Kind indique à k8s quel type, ou sorte, de ressource nous créons ou manipulons. C’est ici que nous spécifions Namespace, Pod, ServiceAccount, Role, RoleBinding, etc…
Voici à quoi ressemblerait le fichier foo.yaml pour créer un pod Nginx :
apiVersion: v1
kind: Pod
metadata:
labels:
app: nginx
name: nginx-pod-foo
namespace: foo
spec:
containers:
- image: nginx
name: nginx-container-foo Puis j’exécute la commande:
kubectl create -f foo.yaml
Cela envoie une demande POST au serveur API qui validera la syntaxe YAML et essaiera ensuite de créer/mettre à jour ce que vous avez demandé. Une réponse sera envoyée indiquant si la ressource a été créée avec succès ou non.
Pour valider, j’exécute cette commande :
kubectl get pods --namespace foo
Output:
NAME READY STATUS RESTARTS AGE
nginx-pod-foo 1/1 Running 0 24s
Si vous regardez de près ces deux commandes, vous verrez que nous avons exécuté une action create et get sur la ressource Pod. Si vous vous souvenez de mon article précédent, j’ai dit que les politiques RBAC spécifiaient les actions (créer, obtenir, etc…) sur les ressources (Pods, ServiceAccounts, Role, etc…). Pour exécuter ces deux commandes, j’aurais besoin d’une autorisation appropriée.
Dans la section métadonnées du fichier foo.yaml, j’ai spécifié le nom de mon Pod et le namespace dans lequel le créer. Remarquez que la commande « kubectl gete »’ possède l’option « –namespace ». Si je n’avais pas inclus cette option, l’API n’aurait renvoyé que les détails de l’espace de noms par défaut et n’aurait montré aucun pod puisque aucun n’a été déployé dans ce namespace.
Déploiements
Très bien ! J’ai maintenant un pod déployé, mais un pod unique n’est pas hautement disponible et constitue une source unique de défaillance. Si vous souhaitez déployer plusieurs pods de la même image de conteneur, vous devez définir plusieurs ressources de pods dans votre fichier YAML, chacune ayant un nom unique. Pour prendre en charge un modèle HA, nous devons utiliser la ressource Déploiement, qui représente un niveau d’abstraction plus élevé par rapport à un Pod et est considérée comme une meilleure pratique. On peut considérer qu’il s’agit d’une enveloppe autour de la ressource Pod, dont l’un des principaux éléments différenciateurs est le paramètre des répliques. Il s’agit d’une valeur numérique qui indique à k8s le nombre d’instances du pod à déployer.
J’ai modifié foo.yaml pour ressembler à ceci :
apiVersion: apps/v1beta1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx-pod-foo
namespace: foo
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
serviceAccountName: foo-user
containers:
- image: nginx
name: nginx-container-foo
Notez également le paramètre serviceAccountName. Je demande au déploiement de lancer 3 instances de mon Pod et de s’exécuter en tant que compte de service foo-user. Kubernetes surveille en permanence ces pods et si l’un d’entre eux rencontrait un problème, il tenterait de lancer une nouvelle instance afin de respecter l’état souhaité de 3 instances.
DaemonSets
Dans certaines circonstances, vous pouvez avoir besoin d’exécuter un pod particulier sur chaque nœud de travail, mais comment pouvons-nous accomplir ceci quand le planificateur est en contrôle de placer les pods sur les nœuds de travail ? Kubernetes dispose d’une ressource appelée DaemonSet qui déploie une copie de l’espace sur chaque nœud de travail. Les démons de stockage en cluster, les démons de journalisation et les démons de surveillance en sont des exemples. Un DaemonSet est très similaire à la ressource Déploiement car il s’agit d’un wrapper de niveau supérieur d’un pod. Les deux ont leur propre gestionnaire de contrôleur qui gère les différences subtiles entre les deux, c’est-à-dire déployer le pod sur chaque nœud de travail, ou déployer un nombre spécifique de pods.
Mettre à jour le foo.yaml pour qu’il ressemble à ceci :
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
app: nginx
name: nginx-pod-foo
namespace: foo
spec:
selector:
matchLabels:
app: nginx
template:
;"> metadata:
"> labels:
app: nginx
spec:
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: nginx-container-foo
image: nginx
Vous pouvez voir qu’ils sont presque identiques. Avec les DaemonSets, vous ne devez pas spécifier le paramètre replicas car votre pod sera déployé sur chaque nœud de travail. Notez le paramètre tolérances. Ceci indique à k8s de ne PAS exécuter le pod sur le(s) nœud(s) maître(s), mais seulement sur les nœuds de travail. Les tolérances sont un sujet avancé et je vous encourage à vous y intéresser !
Références :
https://kubernetes.io/docs/reference/kubectl/
https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
