Monter un Lab Kubernetes VirtualBox avec Fedora Server est un excellent choix technique, mais c'est aussi un redoutable test pour vos compétences réseau. Le symptôme est classique : vos VMs ne sortent pas sur Internet et votre Mac refuse de s'y connecter en SSH.
Le problème ne vient pas de Fedora, mais d'une confusion courante sur le rôle du NAT Network. Contrairement à une idée reçue, la VM ne doit pas "router" via votre host pour sortir. Elle doit utiliser l'abstraction fournie par VirtualBox.
1. Le Diagnostic : Pourquoi votre NAT Network échoue
En configurant vos IP manuellement sans activer de serveur DHCP sur le NAT Network, vous avez créé des nœuds isolés. Sans DHCP, Fedora ne reçoit pas de Default Gateway (passerelle par défaut). Sans passerelle, la VM ne sait pas par où envoyer ses paquets pour atteindre 8.8.8.8.
De plus, le NAT Network est un réseau privé. Par défaut, il n'autorise pas votre MacBook à "entrer" pour initier une session SSH sans une règle de Port Forwarding complexe.
[Image of the OSI model networking layers]
2. La Solution : L'Architecture à Double Interface
Pour un lab Kubernetes stable et conforme aux bonnes pratiques DevSecOps, nous allons utiliser deux cartes réseau par VM. Cette séparation des flux est la clé :
- NIC 1 (NAT Network) : Dédié à la sortie vers Internet (mises à jour dnf, téléchargement d'images Docker).
- NIC 2 (Host-Only) : Dédié à l'administration SSH depuis votre Mac et aux communications internes du cluster.
Schéma de flux :
VM (enp0s3) ----> VirtualBox NAT Engine ----> Internet
Mac (vboxnet0) <----> VM (enp0s8) [SSH & Kube API]
┌──────────────────────────┐
│ MacBook Pro │
│ │
│ 192.168.56.1 (vboxnet0) │
└────────────┬─────────────┘
│ Host-only
┌────────────────────┼────────────────────┐
│ │ │
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ ControlPlane │ │ Worker 1 │ │ Worker 2 │
│ │ │ │ │ │
│ enp0s8 │ │ enp0s8 │ │ enp0s8 │
│ 192.168.56.11│ │ 192.168.56.21│ │ 192.168.56.22│
│ (SSH/Admin) │ │ │ │ │
│ │ │ │ │ │
│ enp0s3 │ │ enp0s3 │ │ enp0s3 │
│ DHCP │ │ DHCP │ │ DHCP │
│ NAT Network │ │ NAT Network │ │ NAT Network │
└──────┬───────┘ └───────┬──────┘ └────────┬─────┘
│ │ │
└─────────────── VirtualBox NAT Network ────┘
(Internet, DNS, MAJ)
3. Configuration VirtualBox (Étape par Étape)
A. Paramétrer le NAT Network
Allez dans VirtualBox > Preferences > Network. Vérifiez votre NAT Network :
- CIDR : 10.0.2.0/24
- DHCP : DOIT être activé (C'est lui qui donnera la route par défaut).
B. Paramétrer le Host-Only
Vérifiez que vous avez une interface vboxnet0 (souvent en 192.168.56.1) créée dans le gestionnaire de réseau hôte.
4. Configuration Fedora via nmcli
Fedora Server utilise NetworkManager. Oubliez la modification manuelle des fichiers ifcfg, utilisez nmcli pour une configuration persistante et propre.
nmcli con add type ethernet ifname enp0s3 con-name internet ipv4.method auto
nmcli con up internet
nmcli con add type ethernet ifname enp0s8 con-name admin \
ipv4.method manual \
ipv4.addresses 192.168.56.11/24
nmcli con up admin
Crucial : En laissant la première interface en auto (DHCP), Fedora va automatiquement définir la passerelle 10.0.2.1 comme route par défaut. Votre VM peut maintenant sortir !
5. Automatisation avec Vagrant
Pour éviter de refaire cette configuration manuellement sur vos trois nœuds (Control-Plane, Worker1, Worker2), voici le Vagrantfile optimisé pour votre Lab Kubernetes VirtualBox.
Vagrant.configure("2") do |config|
config.vm.box = "fedora/40-cloud-base"
nodes = {
"cp-master" => "192.168.56.11",
"worker-1" => "192.168.56.21",
"worker-2" => "192.168.56.22"
}
nodes.each do |name, ip|
config.vm.define name do |node|
node.vm.hostname = name
node.vm.network "private_network", type: "dhcp", virtualbox__intnet: "nat-k8s"
node.vm.network "private_network", ip: ip
node.vm.provider "virtualbox" do |vb|
vb.memory = 2048
vb.cpus = 2
end
end
end
end
6. Conclusion : Une base saine pour Kubeadm
Une fois cette architecture réseau en place, vous verrez que l'installation de Kubernetes avec kubeadm devient fluide. Pourquoi ? Parce que les composants comme Etcd ou l'API Server pourront s'écouter sur l'interface Host-Only stable, tandis que les pods pourront sortir chercher leurs images via le NAT Network.
Rappelez-vous : dans un environnement virtualisé, la simplicité est une vertu. En séparant l'administration (Host-Only) de la sortie (NAT), vous imitez les architectures Cloud réelles.
