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.

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.

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.

# 1. Configurer l'interface Internet (NAT Network)
nmcli con add type ethernet ifname enp0s3 con-name internet ipv4.method auto
nmcli con up internet

# 2. Configurer l'interface SSH/Admin (Host-only)
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
      # Interface 1 : NAT Network (Auto DHCP via Vagrant)
      node.vm.network "private_network", type: "dhcp", virtualbox__intnet: "nat-k8s"
      
      # Interface 2 : Host-only (IP Statique pour SSH)
      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.