Choisissez les plages NO_PROXY internes de Minikube pour son pilote actif
Utilisez le réseau réel du profil et sa plage de services ; un sous-réseau historique d'un autre pilote n'est pas une liste de contournement universelle.
Lorsque Minikube a besoin d'un proxy pour les téléchargements Internet, gardez les destinations propres au cluster en direct. Choisissez les contournements dans le profil et le pilote actifs, plutôt que de copier un sous-réseau depuis une autre machine.
Minikube documente ces valeurs par défaut :
| Usage | Plage par défaut |
|---|---|
| Certains pilotes de VM | 192.168.59.0/24 |
| kvm2 | 192.168.39.0/24 |
| Premier cluster du pilote Docker | 192.168.49.0/24 |
| IP du cluster de services | 10.96.0.0/12 |
Ajoutez les plages applicables et les destinations locales à NO_PROXY, en les adaptant aux réseaux personnalisés. Une 192.168.0.0/16 large ne décrit pas forcément les routes requises par le profil.
Pour un profil en cours d'exécution, minikube ip donne son adresse. Énumérez cette adresse explicitement lorsque l'analyseur de contournement du navigateur participant ou d'un autre client ne prend pas en charge CIDR.
Gardez ce choix de routes internes distinct de la phase de téléchargement. Les téléchargements côté hôte et les récupérations d'images du moteur d'exécution du nœud peuvent utiliser des environnements différents. Un téléchargement binaire réussi sur l'hôte ne prouve pas que le moteur d'exécution a reçu sa configuration de proxy.