Ce document décrit la configuration de mise en réseau requise pour installer et exploiter Google Distributed Cloud.
Configuration réseau externe requise
Google Distributed Cloud nécessite une connexion Internet pour des raisons 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 utiliser une connectivité de couche 2 ou de couche 3 entre les nœuds du cluster. Les nœuds de l'é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 groupé de couche 2 avec MetalLB (spec.loadBalancer.mode: bundled et spec.loadBalancer.type: layer2), les nœuds d'équilibreur de charge nécessitent une adjacence de couche 2. L'exigence de contiguïté de couche 2 s'applique que vous exécutiez l'équilibreur de charge sur des nœuds de 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. Par conséquent, la adjacence de couche 2 stricte n'est pas requise.
Les conditions requises pour les machines d'équilibrage de charge sont les suivantes :
- Pour l'équilibrage de charge groupé de couche 2, 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 groupé de couche 2, toutes les adresses IP virtuelles 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 chargés 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 clés 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 de 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 du cluster et de l'équilibreur de charge.
Nœuds du plan de contrôle
Version 1.28
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à jour des nœuds de cluster d'administrateur | Poste de travail administrateur |
| TCP | Entrant | 2379 - 2381 | API cliente du serveur etcd, métriques et état | kube-apiserver et etcd |
| TCP | Entrant | 2382 - 2384 | API cliente du 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 | Perso |
| TCP | Entrant | 6444 | Serveur d'API Kubernetes | Tous |
| TCP | Entrant | 8443 et 8444 | GKE Identity Service v2 | ais Déploiement exécuté dans l'espace de noms anthos-identity-service |
| TCP | Entrant | 9100 | proxy d'authentification | node-exporter |
| TCP | Entrant | 9101 | Diffuser les métriques de nœud sur localhost uniquement (Exigence relative au port ajoutée à partir de la version 1.28). |
node-exporter |
| TCP | Entrant | 9977 | Recevoir l'é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 | All |
| TCP | Entrant | 10257 | kube-controller-manager (Le numéro de port a été modifié pour les versions 1.28 et ultérieures.) |
Perso |
| TCP | Entrant | 10259 | kube-scheduler (Le numéro de port a été modifié pour les versions 1.28 et ultérieures.) |
Perso |
| TCP | Entrant | 14443 | Service de webhook ANG | kube-apiserver et ang-controller-manager |
Version 1.16
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à jour des nœuds de cluster d'administrateur | Poste de travail administrateur |
| TCP | Entrant | 2379 - 2381 | API cliente du serveur etcd, métriques et état | kube-apiserver et etcd |
| TCP | Entrant | 2382 - 2384 | API cliente du serveur etcd-events, métriques et état (Exigence pour les ports ajoutés à partir de la version 1.16). |
kube-apiserver et etcd-events |
| TCP | Les deux | 4240 | Vérification de l'état CNI | Tous |
| UDP | Entrant | 6081 | Encapsulation du protocole GENEVE | Perso |
| TCP | Entrant | 6444 | Serveur d'API Kubernetes | Tous |
| TCP | Entrant | 9100 | Diffuser des métriques | node-exporter |
| TCP | Entrant | 9443 | Métriques de diffusion/proxy pour les composants du plan de contrôle (port requis pour le cluster version 1.16 ou antérieure) | kube-control-plane-metrics-proxy |
| TCP | Entrant | 9977 | Recevoir l'é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 |
Perso |
| TCP | Entrant | 10252 | kube-controller-manager |
Perso |
| TCP | Entrant | 10256 | Vérification d'état des nœuds | All |
| TCP | Entrant | 14443 | Service de webhook ANG | kube-apiserver et ang-controller-manager |
Versions 1.15 et antérieures
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à jour des nœuds de cluster d'administrateur | Poste de travail administrateur |
| TCP | Entrant | 2379 - 2381 | API cliente du 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 | Perso |
| TCP | Entrant | 6444 | Serveur d'API Kubernetes | Tous |
| TCP | Entrant | 9100 | Diffuser des métriques | node-exporter |
| TCP | Entrant | 9443 | Métriques de diffusion/proxy pour les composants du plan de contrôle (port requis pour le cluster version 1.16 ou antérieure) | kube-control-plane-metrics-proxy |
| TCP | Entrant | 9977 | Recevoir l'é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 |
Perso |
| TCP | Entrant | 10252 | kube-controller-manager |
Perso |
| TCP | Entrant | 10256 | Vérification d'état des nœuds | All |
| TCP | Entrant | 14443 | Service de webhook ANG | kube-apiserver et ang-controller-manager |
Nœuds de calcul
Version 1.28
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à 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 | Perso |
| TCP | Entrant | 9100 | proxy d'authentification | node-exporter |
| TCP | Entrant | 9101 | Diffuser les métriques de nœud sur localhost uniquement (Exigence relative au port ajoutée à partir de la version 1.28). |
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 | All |
| TCP | Entrant | 30000 - 32767 | NodePort service |
Perso |
Version 1.16
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à 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 | Perso |
| TCP | Entrant | 9100 | Diffuser 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 | All |
| TCP | Entrant | 30000 - 32767 | NodePort service |
Perso |
Versions 1.15 et antérieures
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à 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 | Perso |
| TCP | Entrant | 10250 | kubelet API |
Lui-même et plan de contrôle |
| TCP | Entrant | 10256 | Vérification d'état des nœuds | All |
| TCP | Entrant | 30000 - 32767 | NodePort service |
Perso |
Nœuds d'équilibrage de charge
Version 1.28
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à 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 la configuration du cluster à l'aide du champ |
Tous |
| TCP | Les deux | 4240 | Vérification de l'état CNI | Tous |
| UDP | Entrant | 6081 | Encapsulation du protocole GENEVE | Perso |
| 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 |
Version 1.16
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à 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 la configuration du cluster à l'aide du champ |
Tous |
| TCP | Les deux | 4240 | Vérification de l'état CNI | Tous |
| UDP | Entrant | 6081 | Encapsulation du protocole GENEVE | Perso |
| 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 |
Versions 1.15 et antérieures
| Protocole | Direction | Plage de ports | Objectif | Utilisée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à 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 la configuration du cluster à l'aide du champ |
Tous |
| TCP | Les deux | 4240 | Vérification de l'état CNI | Tous |
| UDP | Entrant | 6081 | Encapsulation du protocole GENEVE | Perso |
| 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ée par |
|---|---|---|---|---|
| TCP | Entrant | 22 | Provisionner et mettre à 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 à l'aide du champ |
Nœuds de plan de contrôle et d'équilibreur de charge |
Configurer les ports de firewalld
Il n'est pas nécessaire de désactiver le pare-feu pour exécuter Google Distributed Cloud sur Red Hat Enterprise Linux (RHEL). Pour utiliser le pare-feu, vous devez ouvrir les ports UDP et TCP utilisés par les nœuds du plan de contrôle, des nœuds de calcul et des équilibreurs de charge, comme décrit dans la section Utilisation des ports de 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 :
Exécutez la commande Network Mapper suivante pour afficher les ports qui sont ouverts :
nmap localhostExé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-servicesSi 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 avec le pare-feu
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 de 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 de Cilium entraîne la perte de connectivité réseau du pod sur le nœud en dehors du nœud.
Les modifications apportées à firewalld qui suppriment les chaînes iptables incluent, sans s'y limiter:
Le redémarrage de
firewalldavecsystemctlActualiser
firewalldavec 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:
Recherchez et supprimez le pod
anetdà l'aide des commandes suivantes pour redémarreranetd:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZRemplacez ANETD_XYZ par le nom du pod
anetd.