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.

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 contenu Google 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 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

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 de pods

Google Distributed Cloud 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 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 avez besoin d'une connexion à 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

Version 1.29

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'administrateur	Poste de travail administrateur
TCP	Entrant	2379 - 2381	API client serveur etcd, métriques et état	kube-apiserver et etcd
TCP	Entrant	2382 - 2384	API client serveur etcd-events, métriques et état	kube-apiserver et etcd-events
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	6444	Serveur d'API Kubernetes	Tous
TCP	Entrant	9100	Proxy Auth	node-exporter
TCP	Entrant	9101	Livrer des métriques de nœud sur localhost uniquement (s'applique à la version 1.28 et aux versions ultérieures)	node-exporter
TCP	Entrant	9977	Recevoir un événement d'audit du serveur d'API	audit-proxy
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	10257	kube-controller-manager (changement de numéro de port pour la version 1.28 et les versions ultérieures)	Autonome
TCP	Entrant	10259	kube-scheduler (changement de numéro de port pour la version 1.28 et les versions ultérieures)	Autonome
TCP	Entrant	11002	Le conteneur principal de GKE Identity Service se lie au port via hostPort (s'applique à la version 1.29 et aux versions ultérieures)	Autonome
TCP	Entrant	14443	Service de webhook ANG	kube-apiserver et ang-controller-manager

Version 1.28

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'administrateur	Poste de travail administrateur
TCP	Entrant	2379 - 2381	API client serveur etcd, métriques et état	kube-apiserver et etcd
TCP	Entrant	2382 - 2384	API client serveur etcd-events, métriques et état	kube-apiserver et etcd-events
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	6444	Serveur d'API Kubernetes	Tous
TCP	Entrant	8444	Le conteneur principal de GKE Identity Service se lie au port via hostPort (s'applique à la version 1.28 uniquement)	Tous
TCP	Entrant	9100	Proxy Auth	node-exporter
TCP	Entrant	9101	Livrer des métriques de nœud sur localhost uniquement (s'applique à la version 1.28 et aux versions ultérieures)	node-exporter
TCP	Entrant	9977	Recevoir un événement d'audit du serveur d'API	audit-proxy
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	10257	kube-controller-manager (changement de numéro de port pour la version 1.28 et les versions ultérieures)	Autonome
TCP	Entrant	10259	kube-scheduler (changement de numéro de port pour la version 1.28 et les versions ultérieures)	Autonome
TCP	Entrant	14443	Service de webhook ANG	kube-apiserver et ang-controller-manager

Version 1.16

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'administrateur	Poste de travail administrateur
TCP	Entrant	2379 - 2381	API client serveur etcd, métriques et état	kube-apiserver et etcd
TCP	Entrant	2382 - 2384	API client serveur etcd-events, métriques et état (s'applique à la version 1.16 et aux versions ultérieures)	kube-apiserver et etcd-events
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	6444	Serveur d'API Kubernetes	Tous
TCP	Entrant	9100	Livrer des métriques	node-exporter
TCP	Entrant	9443	Livrer/relayer les métriques pour les composants du plan de contrôle (cette exigence de port s'applique aux clusters version 1.16 et antérieures.)	kube-control-plane-metrics-proxy
TCP	Entrant	9977	Recevoir un événement d'audit du serveur d'API	audit-proxy
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10251	kube-scheduler	Autonome
TCP	Entrant	10252	kube-controller-manager	Autonome
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	14443	Service de webhook ANG	kube-apiserver et ang-controller-manager

Version 1.15 et versions antérieures

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'administrateur	Poste de travail administrateur
TCP	Entrant	2379 - 2381	API client serveur etcd, métriques et état	kube-apiserver et etcd
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	6444	Serveur d'API Kubernetes	Tous
TCP	Entrant	9100	Livrer des métriques	node-exporter
TCP	Entrant	9443	Livrer/relayer les métriques pour les composants du plan de contrôle (cette exigence de port s'applique aux clusters version 1.16 et antérieures.)	kube-control-plane-metrics-proxy
TCP	Entrant	9977	Recevoir un événement d'audit du serveur d'API	audit-proxy
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10251	kube-scheduler	Autonome
TCP	Entrant	10252	kube-controller-manager	Autonome
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	14443	Service de webhook ANG	kube-apiserver et ang-controller-manager

Nœuds de calcul

Version 1.29

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	9100	Proxy Auth	node-exporter
TCP	Entrant	9101	Livrer des métriques de nœud sur localhost uniquement (s'applique à la version 1.28 et aux versions ultérieures)	node-exporter
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	30000 - 32767	NodePort services	Autonome

Version 1.28

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	9100	Proxy Auth	node-exporter
TCP	Entrant	9101	Livrer des métriques de nœud sur localhost uniquement (s'applique à la version 1.28 et aux versions ultérieures)	node-exporter
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	30000 - 32767	NodePort services	Autonome

Version 1.16

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	9100	Livrer des métriques	node-exporter
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	30000 - 32767	NodePort services	Autonome

Version 1.15 et versions antérieures

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	9100	Livrer des métriques	node-exporter
TCP	Entrant	10250	kubelet API	Lui-même et plan de contrôle
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	30000 - 32767	NodePort services	Autonome

Nœuds d'équilibrage de charge

Version 1.29

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Entrant	443	Gestion des clusters Ce port peut être configuré dans le fichier de configuration du cluster avec le champ controlPlaneLBPort.	Tous
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP et UDP	Entrant	7946	Vérification de l'état MetalLB	Nœuds d'équilibrage de charge
TCP	Entrant	10256	Vérification d'état des nœuds	Tous
TCP	Entrant	11000	Port d'écoute pour les métriques HAProxy (immuable) (s'applique à la version 1.29 et aux versions ultérieures)	Tous
TCP	Entrant	11001	Port d'écoute pour GKE Identity Service (immuable) (s'applique à la version 1.29 et aux versions ultérieures)	Tous

Version 1.28

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Entrant	443	Gestion des clusters Ce port peut être configuré dans le fichier de configuration du cluster avec le champ controlPlaneLBPort.	Tous
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP et UDP	Entrant	7946	Vérification de l'état MetalLB	Nœuds d'équilibrage de charge
TCP	Entrant	8443	Port d'écoute pour GKE Identity Service (immuable) (s'applique à la version 1.28 uniquement)	Tous
TCP	Entrant	10256	Vérification d'état des nœuds	Tous

Version 1.16

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Entrant	443	Gestion des clusters Ce port peut être configuré dans le fichier de configuration du cluster avec le champ controlPlaneLBPort.	Tous
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	7946	Vérification de l'état MetalLB	Nœuds d'équilibrage de charge
TCP	Entrant	10256	Vérification d'état des nœuds	Tous

Version 1.15 et versions antérieures

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mises à jour des nœuds de cluster d'utilisateur	Nœuds du cluster d'administrateur
TCP	Entrant	443	Gestion des clusters Ce port peut être configuré dans le fichier de configuration du cluster avec le champ controlPlaneLBPort.	Tous
TCP	Les deux	4240	Vérification de l'état CNI	Tous
UDP	Entrant	6081	Encapsulation du protocole GENEVE	Autonome
TCP	Entrant	7946	Vérification de l'état MetalLB	Nœuds d'équilibrage de charge
TCP	Entrant	10256	Vérification d'état des nœuds	Tous

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.

Protocole	Direction	Plage de ports	Objectif	Utilisé par
TCP	Entrant	22	Provisionnement et mise à jour des nœuds de cluster	Tous les nœuds
TCP	Entrant	443	Serveur d'API Kubernetes pour un cluster ajouté Ce port peut être configuré dans la configuration du cluster via le champ controlPlaneLBPort.	Nœuds de plan de contrôle et d'équilibreur de charge

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

Remarque : Un bug dans certains noyaux Linux pour Red Hat Enterprise Linux (RHEL) version 9.2 peut entraîner un téléchargement très lent des images. Pour en savoir plus et obtenir des instructions de solution de contournement, consultez la section Téléchargements lents dans des conteneurs sur RHEL 9.2.

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.