Configuration réseau requise

Ce document décrit les exigences de mise en réseau pour l'installation et l'utilisation de Google Distributed Cloud (logiciel uniquement) sur Bare Metal.

Cette page s'adresse aux administrateurs, aux architectes, aux opérateurs et aux spécialistes de la mise en réseau qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente, et conçoivent et implémentent le réseau pour leur organisation. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Configuration réseau externe requise

Google Distributed Cloud nécessite une connexion Internet à des fins opérationnelles. Google Distributed Cloud récupère les composants du cluster à partir de Artifact Registry, et le cluster est enregistré auprès de Connect Agent.

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

Google Distributed Cloud peut fonctionner avec une connectivité de couche 2 ou de couche 3 entre les nœuds de cluster. Les nœuds d'équilibreur de charge peuvent être les nœuds du plan de contrôle ou un ensemble dédié de nœuds. 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 contiguïté de couche 2. L'exigence d'une contiguïté 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 contiguïté 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 pour 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 doivent se trouver dans le sous-réseau de la machine de l'équilibreur de charge et doivent pouvoir être routées vers la passerelle du sous-réseau.
• Il appartient aux utilisateurs d'autoriser le trafic entrant de l'équilibreur de charge.

Mise en réseau des pods et des services

Les plages d'adresses IP disponibles pour les services et les pods sont spécifiées dans le fichier de configuration du cluster. Les sections suivantes décrivent les contraintes minimales et maximales pour les plages d'adresses, ainsi que certains des facteurs associés que vous devez prendre en compte lors de la planification de l'installation de votre cluster.

Le nombre de pods et de services que vous pouvez avoir dans vos clusters est contrôlé par les paramètres suivants :

• clusterNetwork.pods.cidrBlocks spécifie le nombre de pods autorisés dans votre cluster.

• clusterNetwork.services.cidrBlocks spécifie le nombre de services autorisés dans votre cluster.

• nodeConfig.podDensity.maxPodsPerNode Spécifie le nombre maximal de pods pouvant être exécutés sur un même nœud.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  ...
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Plages d'adresses IP pour les pods et les services

Vous spécifiez une plage d'adresses IP en tant que bloc CIDR (Classless Inter-Domain Routing) à utiliser pour les pods et un autre bloc CIDR à utiliser pour les adresses ClusterIP des services Kubernetes. Utilisez des adresses IP dans l'espace d'adressage privé, comme décrit dans la RFC 1918. Le fichier de configuration du cluster est prérempli avec des valeurs qui se situent dans les limites décrites dans le tableau suivant:

Pour éviter de chevaucher des adresses IP accessibles sur votre réseau, vous devrez peut-être utiliser des plages CIDR différentes des valeurs préremplies. En particulier, les plages de services et de pods ne doivent pas chevaucher les éléments suivants:

• Adresses IP des nœuds d'un cluster

• Adresses IP virtuelles utilisées par les nœuds de plan de contrôle et les équilibreurs de charge

• Adresses IP des serveurs DNS ou NTP

Les vérifications préliminaires bloquent la création et les mises à niveau de clusters si des adresses IP qui se chevauchent sont identifiées.

Vous pouvez augmenter la plage de réseau de service (clusterNetwork.services.cidrBlocks) après avoir créé un cluster, mais vous ne pouvez pas réduire le nombre d'adresses IP attribuées ni le modifier. Vous ne pouvez modifier que le suffixe du bloc CIDR, en réduisant la valeur du masque pour augmenter le nombre d'adresses IP.

clusterNetwork.pods.cidrBlocks et nodeConfig.podDensity.maxPodsPerNode (décrits dans la section suivante) sont immuables. Planifiez donc soigneusement la croissance future de votre cluster pour éviter de manquer de capacité sur les nœuds. Pour connaître les valeurs maximales recommandées pour les pods par cluster, les pods par nœud et les nœuds par cluster en fonction des tests, consultez la section Limites.

Nombre maximal de pods par nœud

Sur Bare Metal, Google Distributed Cloud vous permet de configurer jusqu'à 250 pods par nœud. Kubernetes attribue un bloc CIDR à chaque nœud afin que chaque pod puisse avoir une adresse IP unique. La taille du bloc CIDR du pod 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:

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, nous vous recommandons vivement de définir clusterNetwork.pods.cidrBlocks sur un bloc CIDR de pod beaucoup plus grand que la valeur préremplie.

Pour en savoir plus sur l'impact du nombre de pods et de services, ainsi que d'autres facteurs, sur l'évolutivité des clusters, consultez la section Étendre les clusters Google Distributed Cloud.

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 importants pour Google Distributed Cloud dans une configuration réseau possible.

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 devez être connecté à Google Cloud.

Utilisation du port

Cette section identifie les exigences relatives aux ports pour les clusters Google Distributed Cloud. Les tableaux suivants montrent comment les ports UDP et TCP sont utilisés par les composants Kubernetes sur les nœuds de cluster et d'équilibreur de charge.

Nœuds du plan de contrôle

Nœuds de calcul

Nœuds d'équilibrage de charge

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.

Configurer les ports de firewalld

Vous n'avez pas besoin de désactiver firewalld pour exécuter Google Distributed Cloud sur Red Hat Enterprise Linux (RHEL). 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=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/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

Pour connaître les exigences de port spécifiques à la version de cluster que vous souhaitez utiliser, consultez la section Utilisation des ports précédente. Mettez à jour les exemples de commandes en conséquence.

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

Pour connaître les exigences de port spécifiques à la version de cluster que vous souhaitez utiliser, consultez la section Utilisation des ports précédente. Mettez à jour les exemples de commandes en conséquence.

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

Pour connaître les exigences de port spécifiques à la version de cluster que vous souhaitez utiliser, consultez la section Utilisation des ports précédente. Mettez à jour les exemples de commandes en conséquence.

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.

Configuration supplémentaire pour RHEL 9.2 et 9.4

Les versions 9.2 et 9.4 de Red Hat Enterprise Linux (RHEL) sont compatibles en disponibilité générale avec les versions 1.29.400 et ultérieures. Avec les versions 9.2 et 9.4 de RHEL, vous devez effectuer une configuration supplémentaire de firewalld sur les nœuds pour que vos services et pods fonctionnent correctement :

1. Listez les interfaces actives du nœud pour trouver l'interface du nœud principal :

   firewall-cmd --list-interfaces
   

   Selon les conventions de dénomination des interfaces de machine Linux, le nom de votre interface principale peut ressembler à l'un des éléments suivants : eth0, eno1, ens1 ou enp2s0.

2. Répertoriez les zones du nœud pour identifier celle utilisée par l'interface principale :

   firewall-cmd --list-all-zones
   

   Par exemple, si votre interface principale est eno1, la section suivante de la réponse indique que l'interface principale se trouve dans la zone public :

   ...
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eno1
     sources:
     ...
   

3. Exécutez les commandes firewalld suivantes pour configurer les détails de la zone et de la règle personnalisées pour RHEL 9.2 ou 9.4 :

   firewall-cmd --permanent --new-zone=cilium
   firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
   firewall-cmd --permanent --zone=cilium --set-target ACCEPT
   firewall-cmd --permanent --zone=cilium --add-masquerade
   firewall-cmd --permanent --zone=cilium --add-forward
   firewall-cmd --permanent --new-policy cilium-host-port-forwarding
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
   firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
   firewall-cmd --reload
   

   Remplacez IN_ZONE par l'une des valeurs suivantes, en fonction de ce que vous avez trouvé lors des étapes précédentes :

   • public : zone prédéfinie à utiliser dans les zones publiques où seules les connexions entrantes sélectionnées sont acceptées.
   • trusted : zone prédéfinie dans un environnement contrôlé où toutes les connexions réseau sont acceptées.
   • Nom d'une zone personnalisée que vous avez définie.

4. Suivez la documentation du fournisseur pour configurer votre solution de stockage.

   Par exemple, si vous utilisez Portworx pour gérer des charges de travail avec état, les exigences réseau Portworx listent les ports qui doivent rester ouverts.

   Pour chacun des ports répertoriés dans la documentation du fournisseur, exécutez la commande suivante :

   firewall-cmd --permanent --zone=public --add-port=PORT_INFO
   

   Remplacez PORT_INFO par le numéro de port ou la plage de numéros de port, suivis du protocole. Exemple :10250-10252/tcp

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 --info-zone=public
   firewall-cmd --info-zone=k8s-pods
   firewall-cmd --list-all-policies
   

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 pour firewalld

Lorsque vous exécutez Google Distributed Cloud avec firewalld activé sur Red Hat Enterprise Linux (RHEL), les modifications apportées à firewalld peuvent supprimer les chaînes iptables Cilium sur le 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 du pod en dehors du nœud.

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

• Le redémarrage de firewalld avec systemctl

• L'actualisation de 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.