Infra de A à Z 086 - Kubernetes : Network, CNI, services, pause conteneur...

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 : Network, CNI, services, pause conteneur…. Faire avancer la partie Kubernetes autour de "Kubernetes : Network, CNI, services, pause conteneur…": 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=QtZk8fJ7aO8

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 85-kubernetes-services-reseau.

Objectif précis de l épisode

Faire avancer la partie Kubernetes autour de "Kubernetes : Network, CNI, services, pause conteneur…": 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 : Network, CNI, services, pause conteneur…: 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: terraform, openstack, ansible, traefik, 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 : Network, CNI, services, pause conteneur….

Découvrez Infra de A à Z 009 - Terraform - network and git

Ce que la vidéo cherche à modifier

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
Kubernetes: Services & Network
physical interface
create interfaces

Indices extraits des slides

Kubernetes: Services & Network
physical interface
create interfaces
setup namespaces
add/setup routes

Notions et définitions des outils

terraform: Terraform décrit l infrastructure comme du code. Le provider OpenStack transforme des ressources HCL en objets cloud: réseaux, routeurs, instances, volumes, groupes de sécurité.
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.
traefik: Traefik est un reverse proxy dynamique. Il route HTTP/HTTPS vers des backends et peut se configurer via Consul ou annotations Kubernetes.
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 : Network, CNI, services, pause conteneur… 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.
Séparer clairement la création des ressources cloud du paramétrage applicatif.
Vérifier les inventaires, variables et rôles avant de lancer un playbook.

Approfondissement spécifique

Dans Kubernetes : Network, CNI, services, pause conteneur…, 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.

Découvrez Infra de A à Z 008 - The Network: router & floating IP (openstack)

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

Les exemples complets sont dans les répertoires du chapitre listés plus bas.

Chemin de diagnostic recommandé

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: 85-kubernetes-services-reseau

Pièges fréquents

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

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 087 – Kubernetes : installation de containerd & kubeadm init.

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 86 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.