TL;DR
Cette série construit progressivement une infrastructure cloud complète sur Infomaniak Public Cloud. Dans cet épisode, le sujet précis est: Kubernetes & Ansible : Initialisation du cluster. Faire avancer la partie Kubernetes autour de "Kubernetes & Ansible : Initialisation du cluster": objets cluster, réseau, stockage, monitoring ou packaging selon l épisode.
La vidéo de référence
Vidéo: https://www.youtube.com/watch?v=IBelE4nnzDE
Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWpehxly1wOT6eB2NvZX9A-X
Le dépôt support est disponible ici: https://gitlab.com/xavki/infrastructure-cloud-infomaniak. Le chapitre correspondant est 89-vagrant-ansible-initialisation-master.
Objectif précis de l épisode
Faire avancer la partie Kubernetes autour de "Kubernetes & Ansible : Initialisation du cluster": objets cluster, réseau, stockage, monitoring ou packaging selon l épisode.
Concrètement, cet épisode sert à passer d une intention formulée dans le titre à une modification vérifiable dans l infrastructure. Le dépôt donne les fichiers, la vidéo donne l ordre de manipulation, et la vérification doit confirmer que la brique fonctionne vraiment.
Kubernetes & Ansible : Initialisation du cluster: c est quoi exactement ?
Dans une infrastructure cloud réelle, chaque épisode ajoute une brique: réseau, compute, sécurité, automatisation, découverte de services, observabilité, sauvegardes ou orchestration. Ici, les outils détectés sont: openstack, ansible, kubernetes.
Dans cet épisode, il faut surtout regarder les éléments qui correspondent au titre: les ressources créées ou modifiées, les fichiers du chapitre, les services touchés et la preuve de fonctionnement. Les outils détectés donnent le contexte, mais le fil rouge reste Kubernetes & Ansible : Initialisation du cluster.
Ce que la vidéo cherche à modifier
- organiser inventaire, variables et playbooks du chapitre
- appliquer la configuration de manière reproductible
- vérifier les rôles réellement exécutés sur les hôtes ciblés
- modifier les manifests, charts ou playbooks liés au cluster
- vérifier l interaction entre Kubernetes et OpenStack
- garder un chemin de diagnostic kubectl clair
Indices extraits des slides
- Kubernetes: Ansible – initialisation and first master
- Check if the cluster is already init
- Run the kubadm init
- Check if we have a kubeconfig file
- Create the directory if not exists
Notions et définitions des outils
- openstack: OpenStack est la couche cloud IaaS: instances, réseaux, routeurs, IP flottantes, groupes de sécurité, volumes et images. Chez Infomaniak Public Cloud, il sert de socle programmable via GUI, CLI, Terraform et API.
- ansible: Ansible automatise la configuration des machines après leur création. Les playbooks, rôles, inventaires et variables transforment une VM brute en service exploitable.
- kubernetes: Kubernetes orchestre des conteneurs sur un cluster: pods, deployments, services, CNI, kubeadm, Helm et intégration avec Terraform/Consul/monitoring.
Ces définitions sont volontairement pratiques: elles expliquent à quoi sert l outil dans la chaîne, pas seulement ce qu il est sur le papier.
Points clés à retenir pour cet épisode
- Comprendre le rôle de Kubernetes & Ansible : Initialisation du cluster dans la progression globale de l infrastructure.
- Identifier la couche concernée: cloud, automatisation, réseau, service, observabilité ou orchestration.
- Relier les fichiers du dépôt au résultat attendu sur les machines ou dans le cloud.
- Vérifier les inventaires, variables et rôles avant de lancer un playbook.
- Valider les objets Kubernetes créés et leur intégration avec le réseau et le monitoring.
Approfondissement spécifique
Dans Kubernetes & Ansible : Initialisation du cluster, Ansible doit être lu comme la couche de convergence système. Le sujet n est pas uniquement le playbook lancé, mais la combinaison inventaire, variables, rôles et tâches qui transforme une machine provisionnée en service configuré.
Le diagnostic part de la cible: quel groupe d hôtes est visé, quelles variables sont chargées, quel rôle applique le changement et quel fichier ou service prouve le résultat sur la machine.
Dans Kubernetes & Ansible : Initialisation du cluster, Kubernetes doit être relié au socle OpenStack et aux playbooks du dépôt. Le cluster n est pas isolé: réseau, routes, volumes, DNS et monitoring dépendent encore des choix faits autour de l infrastructure.
La lecture utile part des objets Kubernetes concernés, puis descend vers les events, les services, le CNI, les routes OpenStack ou les volumes Cinder selon le sujet de l épisode.
Exemple de code ou configuration du dépôt
- name: Check if already init
stat:
path: /etc/kubernetes/admin.conf
register: __kubeadm_already_initCet extrait doit être lu comme un support pédagogique. Avant de l utiliser tel quel, vérifiez les variables, noms de réseau, plages CIDR, identifiants, secrets, régions, images et règles d exposition.
Chemin de diagnostic recommandé
- valider l inventaire Ansible
- relancer le playbook sans changement inattendu
- contrôler les services et fichiers modifiés sur la machine
- contrôler les pods, services et events
- vérifier les routes, CNI ou volumes si le sujet les touche
- tester la configuration depuis le cluster et depuis l extérieur
- Comparer l état attendu dans le dépôt et l état réel dans le cloud, la machine ou le cluster.
- Documenter la commande, l écran ou la métrique qui prouve que l étape est fonctionnelle.
Répertoires et commandes utiles
- Répertoire support: 89-vagrant-ansible-initialisation-master
- Répertoire support: 89-vagrant-ansible-initialisation-master/vagrant
- Répertoire support: 89-vagrant-ansible-initialisation-master/vagrant/roles
Pièges fréquents
- lancer un playbook sur le mauvais groupe
- mélanger variables de lab et variables sensibles
- ne pas vérifier l idempotence
- diagnostiquer Kubernetes sans regarder les events
- oublier le lien avec réseau OpenStack
- déployer un chart sans maîtriser les values
Liens utiles externes
- Dépôt Xavki infrastructure-cloud-infomaniak
- Playlist YouTube Infra de A à Z
- docs.infomaniak.cloud
- docs.infomaniak.cloud/getting_started/first_project
- docs.infomaniak.cloud/compute/instances
- docs.infomaniak.cloud/orchestration/terraform
- docs.infomaniak.cloud/network/networks
- docs.infomaniak.cloud/network/security_groups
Liens internes conseillés
- Parcours Kubernetes pour relier la partie cluster et orchestration.
- Prometheus, Grafana et observabilité pour approfondir métriques et dashboards.
- Kubernetes 003 – architecture pour revoir les composants du control plane.
Pour continuer, lire Infra A à Z 091 – Kubernetes & Ansible : Join des Masters & Workers.
FAQ
Pourquoi utiliser Terraform et Ansible ensemble ?
Terraform est adapté à la création et au cycle de vie des ressources cloud. Ansible est adapté à la configuration des machines et services. Les mélanger sans frontière claire rend les changements difficiles à relire.
Pourquoi Infomaniak/OpenStack dans cette série ?
Infomaniak Public Cloud expose des concepts OpenStack standards: compute, réseau, volumes, security groups, object storage, identity et orchestration. Cela permet d apprendre des notions transférables tout en travaillant sur un fournisseur concret.
Que faut-il sécuriser en premier ?
Les accès: credentials cloud, state Terraform, SSH, VPN, dashboards, secrets Ansible, tokens GitLab, consoles d administration et ports exposés publiquement. Une infrastructure automatisée amplifie aussi les erreurs de sécurité.
Comment savoir si une étape est terminée ?
Chaque étape doit produire une preuve: une ressource visible, un service joignable, une métrique collectée, un backup restaurable, une requête qui répond ou un déploiement qui converge.
Conclusion
L épisode 90 s inscrit dans une progression complète: construire, automatiser, sécuriser, observer et exploiter une infrastructure cloud. Le dépôt Xavki donne les exemples concrets, la documentation Infomaniak/OpenStack donne le cadre fournisseur, et le deep dive permet de comprendre le rôle des outils au lieu de seulement rejouer des commandes.