Configuration réseau requise

Ce document décrit les exigences de mise en réseau requises pour l'installation et l'exploitation de GKE sur une solution Bare Metal.

Configuration réseau externe requise

GKE sur Bare Metal nécessite une connexion Internet à des fins opérationnelles. GKE sur Bare Metal récupère les composants de cluster de Container Registry, et le cluster est enregistré auprès de Connect.

Vous pouvez vous connecter à Google en utilisant l'Internet public via HTTPS, un réseau privé virtuel (VPN) ou une connexion d'interconnexion dédiée.

Si les machines que vous utilisez pour le poste de travail d'administrateur et les nœuds de cluster utilisent un serveur proxy pour accéder à Internet, ce serveur proxy doit autoriser certaines connexions spécifiques. Pour en savoir plus, consultez la section Installer derrière un proxy.

Configuration réseau interne requise

GKE sur Bare Metal peut fonctionner avec la connectivité de couche 2 ou de couche 3 entre les nœuds de cluster. Les nœuds de l'équilibreur de charge peuvent être les nœuds du plan de contrôle ou un ensemble de nœuds dédié. Pour en savoir plus, consultez la page Choisir et configurer des équilibreurs de charge.

Lorsque vous utilisez l'équilibrage de charge de couche 2 groupé avec MetalLB (spec.loadBalancer.mode: bundled et spec.loadBalancer.type: layer2), les nœuds d'équilibreur de charge nécessitent une contrainte de couche 2. L'exigence de contrainte de couche 2 s'applique que vous exécutiez l'équilibreur de charge sur des nœuds du plan de contrôle ou dans un ensemble dédié de nœuds d'équilibrage de charge. L'équilibrage de charge groupé avec BGP est compatible avec le protocole de couche 3. Une adjacence de couche 2 stricte n'est donc pas requise.

Les conditions requises pour les machines d'équilibrage de charge sont les suivantes :

  • Pour l'équilibrage de charge de couche 2 groupé, tous les équilibreurs de charge d'un cluster donné se trouvent dans le même domaine de couche 2. Les nœuds du plan de contrôle doivent également se trouver dans le même domaine de couche 2.
  • Pour l'équilibrage de charge de couche 2 groupé, toutes les adresses IP virtuelles (VIP) doivent se trouver dans le sous-réseau de la machine de l'équilibreur de charge et être routables vers la passerelle du sous-réseau.
  • Les utilisateurs sont responsables de l'autorisation du trafic de l'équilibreur de charge entrant.

Mise en réseau de pods

GKE sur Bare Metal 1.7.0 et versions ultérieures vous permet de configurer jusqu'à 250 pods par nœud. Kubernetes attribue un bloc CIDR (Classless Inter-Domain Routing) à chaque nœud afin que chaque pod puisse avoir une adresse IP unique. La taille du bloc CIDR correspond au nombre maximal de pods par nœud. Le tableau suivant répertorie la taille du bloc CIDR que Kubernetes affecte à chaque nœud en fonction du nombre maximal de pods configurés par nœud :

Nombre maximal de pods par nœud Bloc CIDR par nœud Nombre d'adresses IP
32 /26 64
33 – 64 /25 128
65-128 /24 256
129-250 /23 512

L'exécution de 250 pods par nœud nécessite que Kubernetes réserve un bloc CIDR /23 pour chaque nœud. Si votre cluster utilise la valeur par défaut /16 pour le champ clusterNetwork.pods.cidrBlocks, il a une limite de (2(23-16)) = 128 nœuds Si vous avez l'intention de développer le cluster au-delà de cette limite, vous pouvez augmenter la valeur de clusterNetwork.pods.cidrBlocks ou diminuer celle de nodeConfig.podDensity.maxPodsPerNode. Cette méthode présentait quelques inconvénients.

Déploiement sur un seul cluster d'utilisateur à haute disponibilité

Le schéma suivant illustre un certain nombre de concepts de mise en réseau clés liés à la GDCV pour Bare Metal, dans une configuration réseau possible.

Configuration réseau standard de GKE sur Bare Metal

Tenez compte des informations suivantes pour répondre aux exigences de réseau :

  • Les nœuds du plan de contrôle exécutent les équilibreurs de charge, qui disposent tous d'une connectivité de couche 2, tandis que les autres connexions, y compris les nœuds de calcul, ne nécessitent qu'une connectivité de couche 3.
  • Les fichiers de configuration définissent les adresses IP des pools de nœuds de calcul. Les fichiers de configuration définissent également des adresses IP virtuelles aux fins suivantes :
    • Services
    • Entrée
    • Accès au plan de contrôle via l'API Kubernetes
  • Vous avez besoin d'une connexion à Google Cloud.

Utilisation du port

Cette section explique comment les ports UDP et TCP sont utilisés sur les nœuds de cluster et d'équilibrage de charge.

Nœuds de plan de contrôle

ProtocoleDirectionPlage de portsObjectifUtilisée par
UDPEntrant6081Encapsulation du protocole GENEVEPerso
TCPEntrant22Provisionnement et mises à jour des nœuds d'un cluster d'administrateurPoste de travail administrateur
TCPEntrant6444Serveur d'API KubernetesTout
TCPEntrant2 379 à 2 381API client serveur etcdkube-apiserver et etcd
TCPEntrant2 382 à 2 384API cliente de serveur etcd-eventskube-apiserver et etcd-events
TCPEntrant10250kubelet APILui-même et plan de contrôle
TCPEntrant10251kube-schedulerPerso
TCPEntrant10252kube-controller-managerPerso
TCPEntrant10256Vérification d'état des nœudsAll
TCPLes deux4240Vérification de l'état CNITout

Nœuds de calcul

ProtocoleDirectionPlage de portsObjectifUtilisée par
TCPEntrant22Provisionnement et mises à jour des nœuds d'un cluster d'utilisateurNœuds du cluster d'administrateur
UDPEntrant6081Encapsulation du protocole GENEVEPerso
TCPEntrant10250kubelet APILui-même et plan de contrôle
TCPEntrant10256Vérification d'état des nœudsAll
TCPEntrant30000 - 32767NodePort servicePerso
TCPLes deux4240Vérification de l'état CNITout

Nœuds d'équilibrage de charge

ProtocoleDirectionPlage de portsObjectifUtilisée par
TCPEntrant22Provisionnement et mises à jour des nœuds d'un cluster d'utilisateurNœuds du cluster d'administrateur
UDPEntrant6081Encapsulation du protocole GENEVEPerso
TCPEntrant443*Gestion des clustersTout
TCPLes deux4240Vérification de l'état CNITout
TCPEntrant7946Vérification de l'état de l'équilibreur de charge MetalNœuds d'équilibrage de charge
UDPEntrant7946Vérification de l'état de l'équilibreur de charge MetalNœuds d'équilibrage de charge
TCPEntrant10256Vérification d'état des nœudsAll

* Ce port peut être configuré dans la configuration du cluster via le champ controlPlaneLBPort.

Exigences concernant les ports multicluster

Dans une configuration multicluster, les clusters ajoutés doivent comporter les ports suivants pour pouvoir communiquer avec le cluster d'administrateur.

ProtocoleDirectionPlage de portsObjectifUtilisée par
TCPEntrant22Provisionnement et mises à jour des nœuds de clusterTous les nœuds
TCPEntrant443*Serveur d'API Kubernetes pour un cluster ajoutéNœuds de plan de contrôle et d'équilibreur de charge

* Ce port peut être configuré dans la configuration du cluster via le champ controlPlaneLBPort.

Configurer les ports de firewalld

Vous n'avez pas besoin de désactiver le pare-feu pour exécuter GKE sur une solution Bare Metal sous Red Hat Enterprise Linux (RHEL) ou CentOS. Pour utiliser firewalld, vous devez ouvrir les ports UDP et TCP utilisés par les nœuds de l'équilibreur de charge, de calcul et du plan de contrôle, comme décrit dans la section Utilisation des ports sur cette page. Les exemples de configuration suivants montrent comment ouvrir des ports avec firewall-cmd, l'utilitaire de ligne de commande de firewalld. Vous devez exécuter les commandes en tant qu'utilisateur racine.

Exemple de configuration des nœuds de plan de contrôle

Le bloc de commandes suivant montre un exemple d'ouverture des ports requis sur les serveurs exécutant des nœuds de plan de contrôle :

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250-10252/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Remplacez PODS_CIDR par les blocs CIDR réservés pour vos pods configurés dans le champ clusterNetwork.pods.cidrBlocks. Le bloc CIDR par défaut pour les pods est 192.168.0.0/16.

Exemple de configuration de nœud de calcul

Le bloc de commandes suivant montre un exemple d'ouverture des ports requis sur les serveurs exécutant des nœuds de calcul :

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Remplacez PODS_CIDR par les blocs CIDR réservés pour vos pods configurés dans le champ clusterNetwork.pods.cidrBlocks. Le bloc CIDR par défaut pour les pods est 192.168.0.0/16.

Exemple de configuration de nœud d'équilibreur de charge

Le bloc de commandes suivant montre un exemple d'ouverture des ports requis sur les serveurs exécutant des nœuds d'équilibreur de charge :

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Remplacez PODS_CIDR par les blocs CIDR réservés pour vos pods configurés dans le champ clusterNetwork.pods.cidrBlocks. Le bloc CIDR par défaut pour les pods est 192.168.0.0/16.

Confirmer la configuration du port

Pour vérifier la configuration de votre port, suivez les étapes ci-dessous sur les nœuds du plan de contrôle, du nœud de calcul et de l'équilibreur de charge :

  1. Exécutez la commande Network Mapper suivante pour afficher les ports qui sont ouverts :

    nmap localhost
    
  2. Exécutez les commandes suivantes pour obtenir les paramètres de configuration par le pare-feu :

    firewall-cmd --zone=public --list-all-policies
    firewall-cmd --zone=public --list-ports
    firewall-cmd --zone=public --list-services
    firewall-cmd --zone=k8s-pods --list-all-policies
    firewall-cmd --zone=k8s-pods --list-ports
    firewall-cmd --zone=k8s-pods --list-services
    
  3. Si nécessaire, exécutez à nouveau les commandes des sections précédentes pour configurer correctement vos nœuds. Vous devrez peut-être exécuter les commandes en tant qu'utilisateur racine.

Problème connu concernant le pare-feu

Lors de l'exécution de GKE sur une solution Bare Metal avec firewalld activé sur CentOS ou Red Hat Enterprise Linux (RHEL), les modifications apportées à firewalld peuvent supprimer les chaînes Cilium iptables du réseau hôte. Les chaînes iptables sont ajoutées par le pod anetd au démarrage. La perte des chaînes iptables Cilium entraîne la perte de la connectivité réseau en dehors du nœud du pod sur le nœud.

Les modifications apportées à firewalld qui suppriment les chaînes iptables incluent, sans s'y limiter:

  • Le redémarrage de firewalld avec systemctl

  • Actualiser firewalld avec le client de ligne de commande (firewall-cmd --reload)

Pour appliquer les modifications de firewalld sans supprimer les chaînes iptables, redémarrez anetd sur le nœud:

  1. Localisez et supprimez le pod anetd à l'aide des commandes suivantes pour redémarrer anetd:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    Remplacez ANETD_XYZ par le nom du pod anetd.