How to plan the network for an ACK managed cluster - Container Service for Kubernetes

Planification de l'échelle du réseau

Région et zone

Toutes les zones d'une région communiquent via le réseau interne, mais restent isolées des pannes survenant dans les autres zones. Un VPC est une ressource régionale et ne peut pas s'étendre sur plusieurs régions.

Lorsque vous sélectionnez une région et une zone, tenez compte des éléments suivants :

Critère	Description
Latence	Déployez vos ressources à proximité des utilisateurs finaux pour minimiser la latence réseau.
Disponibilité du service	Les services Alibaba Cloud varient selon les régions et les zones. Vérifiez la disponibilité dans la région cible.
Coût	La tarification des services cloud diffère d'une région à l'autre. Sélectionnez une région adaptée à votre budget.
Haute disponibilité et reprise après sinistre	Pour les charges de travail exigeant une haute disponibilité, déployez-les sur plusieurs zones au sein d'une même région. Pour une isolation renforcée, privilégiez un déploiement multi-régions.
Conformité	Choisissez une région conforme à vos exigences en matière de résidence des données et de réglementation.

Consultez la liste des régions disponibles.

Un VPC ne peut pas s'étendre sur plusieurs régions. Pour les systèmes multi-régions, créez un VPC par région et connectez-les à l'aide de connexions d'appairage VPC , VPN Gateway , ou Cloud Enterprise Network (CEN) . Un vSwitch est une ressource zonale.

Nombre de VPC

Les VPC sont totalement isolés. Par défaut, les ressources situées dans un même VPC communiquent via le réseau privé.

Scénario	Cas d'utilisation
VPC unique	Déploiement modeste sur une seule région, sans exigence d'isolation spécifique. Configurations sensibles aux coûts évitant la complexité liée aux communications inter-VPC.
Plusieurs VPC	Déploiements multi-régions. Systèmes nécessitant une isolation stricte (par exemple, production et préproduction). Architectures multi-équipes avec gestion indépendante des ressources.

Quota par défaut : 10 VPC par région. Augmentez ce quota via la page de gestion des quotas ou le Centre de quotas .

Nombre de vSwitch

Un vSwitch est une ressource zonale. Les ressources cloud d'un VPC sont associées à des vSwitch, qui communiquent entre eux par défaut.

Critère	Recommandation
Latence	La latence inter-zones reste faible, mais augmente avec la complexité des appels système et le trafic inter-zones. Trouvez le bon équilibre entre haute disponibilité et latence.
Haute disponibilité	Créez au moins deux vSwitch dans des zones différentes. En cas de panne d'une zone, l'autre continue de traiter le trafic.
Segmentation métier	Regroupez les vSwitch par fonctionnalité — par exemple, couches web, logique et données. Utilisez un vSwitch public dédié pour les services exposés à Internet afin de simplifier les règles de sécurité.

Quota par défaut : 150 vSwitch par VPC. Augmentez ce quota via la page de gestion des quotas ou le Centre de quotas .

Taille du cluster

Nombre de nœuds	Cas d'utilisation	Planification VPC	Planification des zones
Moins de 100 nœuds	Charges de travail non critiques	VPC unique	1 (2 ou plus recommandés)
100 nœuds ou plus	Charges de travail générales nécessitant une redondance multi-zones	VPC unique	2 ou plus
100 nœuds ou plus	Charges de travail critiques exigeant une fiabilité élevée sur plusieurs régions	Plusieurs VPC	2 ou plus

Planification de la connectivité réseau

Cluster unique dans un VPC unique

Le bloc CIDR d'un VPC est figé lors de sa création. Attribuez des blocs CIDR distincts pour les pods et les services de chaque cluster, sans chevauchement.

Plusieurs clusters dans un VPC unique

Plusieurs clusters peuvent partager un même VPC. Lors de la planification des blocs CIDR pour chaque cluster :

Le bloc CIDR du VPC est fixé à la création. Chaque cluster doit utiliser des blocs CIDR non chevauchants pour le VPC, les services et les pods.
Les blocs CIDR des pods ne doivent pas se chevaucher d'un cluster à l'autre. Les blocs CIDR de service constituent des réseaux virtuels et peuvent se chevaucher entre clusters.
En mode Flannel, les paquets des pods transitent par le VPC. ACK ajoute automatiquement les routes vers chaque bloc CIDR de pod dans la table de routage du VPC.

Dans cette topologie, les pods d'un cluster peuvent accéder aux pods et aux instances ECS des autres clusters, mais pas à leurs services ClusterIP, qui sont locaux au cluster. Utilisez LoadBalancer ou Ingress pour accéder aux services d'un autre cluster.

Connectivité inter-VPC multi-clusters

Planifiez la connectivité inter-VPC pour les scénarios suivants.

Déploiement multi-régions

Un VPC est une ressource régionale. Pour les systèmes multi-régions, créez un VPC et un cluster par région, puis connectez-les à l'aide de connexions d'appairage VPC, de VPN Gateway ou de Cloud Enterprise Network (CEN).

Isolation de plusieurs systèmes métier

Pour assurer une isolation réseau stricte entre systèmes au sein d'une même région — comme la production et la préproduction — déployez chacun d'eux dans un VPC séparé. Connectez-les à l'aide de connexions d'appairage VPC, de VPN Gateway ou de Cloud Enterprise Network (CEN).

Architecture multi-équipes à grande échelle

Déployez des VPC séparés par équipe pour une gestion indépendante des clusters et des ressources. Cette approche simplifie le contrôle d'accès et améliore la flexibilité.

Important

Pour éviter les conflits IP dans les configurations inter-VPC multi-clusters, vérifiez que les blocs CIDR de chaque nouveau cluster ne chevauchent pas :

Aucun bloc CIDR de VPC présent dans le réseau connecté
Aucun bloc CIDR d'un autre cluster
Aucun bloc CIDR de pod d'un autre cluster

Connectivité entre le cluster cloud et le centre de données local

Lorsque vous connectez un cluster à un centre de données local (IDC), les adresses des pods ne doivent pas chevaucher les blocs CIDR du VPC acheminés vers l'IDC. Si l'IDC nécessite un accès direct aux adresses des pods, configurez les routes dans le routeur de bordure virtuelle (VBR) côté IDC.

Planification du plug-in CNI

ACK prend en charge deux plug-ins CNI : Terway et Flannel. Il est impossible de modifier le plug-in après la création du cluster ; celui-ci détermine les fonctionnalités réseau disponibles et la configuration des CIDR.

Choisir un plug-in CNI

Sélectionnez le plug-in adapté à vos besoins :

	Terway	Flannel
Idéal pour	Charges de travail nécessitant NetworkPolicy, des IPs de pod fixes, des adresses IP élastiques (EIP) liées aux pods ou un accès inter-clusters	Configurations plus simples où ces fonctionnalités ne sont pas requises
Source des IPs de pod	IPs attribuées depuis les vSwitch du VPC	IPs attribuées depuis un bloc CIDR virtuel
Taille du pool d'IPs	Limitée par la taille du bloc CIDR du vSwitch	Jusqu'à 65 536 IPs de pod avec un bloc CIDR de conteneur /16
IPv6	Pris en charge	Non pris en charge

Comparaison des fonctionnalités

Fonctionnalité	Terway	Flannel
NetworkPolicy	Pris en charge	Non pris en charge
Double pile IPv4/IPv6	Pris en charge	Non pris en charge
IP de pod fixe	Pris en charge	Non pris en charge
EIP lié au pod	Pris en charge	Non pris en charge
Accès inter-clusters	Pris en charge (lorsque les groupes de sécurité autorisent les ports requis)	Non pris en charge

ACK utilise un plug-in Flannel modifié et optimisé pour Alibaba Cloud ; il ne suit pas les mises à jour amont. Consultez l'historique des mises à jour pour Flannel .

Consultez la rubrique Plug-ins de réseau de conteneurs Terway vs. Flannel.

Planification des blocs CIDR

Mode réseau Terway

En mode Terway, les pods obtiennent leurs IPs depuis des vSwitch de pod dédiés. Dimensionnez les blocs CIDR des vSwitch de pod pour accueillir tous les pods répartis sur les nœuds et les zones, en prévoyant une marge pour les mises à niveau progressives.

terway

Configuration examples

Zone unique :

Bloc CIDR du VPC	Bloc CIDR du vSwitch	Bloc CIDR du vSwitch de pod	Bloc CIDR de service	Nombre maximal d'IPs de pod assignables
192.168.0.0/16	Zone I : 192.168.0.0/19	192.168.32.0/19	172.21.0.0/20	8 192

Multi-zones :

Bloc CIDR du VPC	Bloc CIDR du vSwitch	Bloc CIDR du vSwitch de pod	Bloc CIDR de service	Nombre maximal d'IPs de pod assignables
192.168.0.0/16	Zone I : 192.168.0.0/19	192.168.32.0/19	172.21.0.0/20	8 192
192.168.0.0/16	Zone J : 192.168.64.0/19	192.168.96.0/19	172.21.0.0/20	8 192

VPC

Utilisez l'un des blocs CIDR privés standard RFC suivants — ou un sous-réseau — comme bloc CIDR IPv4 principal de votre VPC : 192.168.0.0/16, 172.16.0.0/12 ou 10.0.0.0/8. Les longueurs de masque valides vont de /8 à /28 (varie selon le bloc). Exemple : 192.168.0.0/16.

Pour les déploiements multi-VPC ou cloud hybride, utilisez des sous-réseaux avec un masque /16 ou plus court. Assurez-vous qu'il n'y a aucun chevauchement entre les VPC ou avec les centres de données locaux.

Les VPC attribuent automatiquement des blocs CIDR IPv6 lorsque vous activez l'IPv6. Pour utiliser l'IPv6 pour les conteneurs, choisissez Terway.

Pour utiliser une plage d'IPs publiques comme bloc CIDR de votre VPC, demandez le quota ack.white_list/supportVPCWithPublicIPRanges dans le Centre de quotas .

vSwitch

Les vSwitch hébergent les instances ECS et gèrent le trafic entre nœuds. Le bloc CIDR du vSwitch doit être un sous-ensemble du bloc CIDR du VPC.

Les instances ECS obtiennent leurs IPs depuis ce bloc CIDR. Dimensionnez-le pour l'ensemble des nœuds.
Plusieurs vSwitch au sein d'un même VPC ne doivent pas avoir de blocs CIDR qui se chevauchent.
Chaque vSwitch de pod doit se trouver dans la même zone que son vSwitch de nœud correspondant.

vSwitch de pod

Le vSwitch de pod attribue des IPs aux pods et gère leur trafic. Son bloc CIDR doit être un sous-ensemble du bloc CIDR du VPC.

Dimensionnez-le pour le nombre maximal attendu de pods, en ajoutant une marge pour les mises à niveau.
Le bloc CIDR du vSwitch de pod ne doit pas chevaucher le bloc CIDR de service.

Bloc CIDR de service

Important

Le bloc CIDR de service ne peut pas être modifié après la création du cluster.

Le bloc CIDR de service définit la plage d'IPs pour les services ClusterIP. Chaque service reçoit une IP.

Les IPs de service ne sont accessibles qu'au sein du cluster, pas depuis l'extérieur.
Le bloc CIDR de service ne doit pas chevaucher le bloc CIDR du vSwitch ni le bloc CIDR du vSwitch de pod.

Bloc CIDR de service IPv6 (lorsque la double pile IPv6 est activée)

Utilisez une adresse locale unique (ULA) dans la plage fc00::/7. La longueur du préfixe doit être comprise entre /112 et /120.
Faites correspondre le nombre d'adresses utilisables dans le bloc CIDR de service.

Mode réseau Flannel

En mode Flannel, les IPs des pods proviennent d'un bloc CIDR de conteneur virtuel, non lié à un vSwitch spécifique. Les paquets des pods transitent par le VPC, et ACK ajoute automatiquement les routes vers chaque bloc CIDR de pod dans la table de routage du VPC.

Flannel network diagram

Configuration example

Bloc CIDR du VPC	Bloc CIDR du vSwitch	Bloc CIDR de conteneur	Bloc CIDR de service	Nombre maximal d'IPs de pod assignables
192.168.0.0/16	192.168.0.0/24	172.20.0.0/16	172.21.0.0/20	65 536

VPC

Utilisez l'un des blocs CIDR privés standard RFC suivants — ou un sous-réseau — comme bloc CIDR IPv4 principal de votre VPC : 192.168.0.0/16, 172.16.0.0/12 ou 10.0.0.0/8. Les longueurs de masque valides vont de /8 à /28 (varie selon le bloc). Pour les déploiements multi-VPC ou cloud hybride, utilisez un masque /16 ou plus court, sans chevauchement entre les VPC ou avec les centres de données locaux.

Pour utiliser une plage d'IPs publiques comme bloc CIDR de votre VPC, demandez le quota ack.white_list/supportVPCWithPublicIPRanges dans le Centre de quotas .

vSwitch

Les instances ECS obtiennent leurs IPs depuis ce bloc CIDR. Dimensionnez-le pour l'ensemble des nœuds.
Plusieurs vSwitch au sein d'un même VPC ne doivent pas avoir de blocs CIDR qui se chevauchent.

Bloc CIDR de conteneur

Important

Le bloc CIDR de conteneur ne peut pas être modifié après la création du cluster.

Ce bloc CIDR virtuel attribue les IPs des pods à l'échelle du cluster.

Il n'est lié à aucun vSwitch.
Il ne doit pas chevaucher le bloc CIDR du vSwitch ni le bloc CIDR de service.

Par exemple, si votre bloc CIDR de VPC est 172.16.0.0/12, n'utilisez pas 172.16.0.0/16 ni 172.17.0.0/16 pour le bloc CIDR de conteneur, car tous deux tombent dans la plage 172.16.0.0/12.

Bloc CIDR de service

Important

Le bloc CIDR de service ne peut pas être modifié après la création du cluster.

Le bloc CIDR de service définit la plage d'IPs pour les services ClusterIP.

Les IPs de service ne sont accessibles qu'au sein du cluster.
Le bloc CIDR de service ne doit pas chevaucher le bloc CIDR du vSwitch ni le bloc CIDR de conteneur.

Étapes suivantes

Utiliser les blocs CIDR secondaires du VPC : Configurez le SNAT sur une passerelle NAT et mettez à jour les règles du groupe de sécurité lors de l'extension avec des blocs CIDR secondaires ou de nouvelles zones.
Planification des comptes : Planifiez la structure des comptes pour isoler les autorisations et les charges de travail à mesure que votre activité se développe.
Planification des capacités de sécurité : Planifiez les contrôles de sécurité en fonction de votre topologie de connectivité réseau et de vos exigences de sécurité.
Planification des capacités de reprise après sinistre : Planifiez la reprise après sinistre en fonction de votre architecture métier pour protéger les données et garantir la continuité.
Accéder au serveur API depuis Internet : Exposez le serveur API de votre cluster sur Internet à l'aide d'une adresse IP élastique (EIP).
Activer l'accès sortant à Internet pour le cluster : Configurez le SNAT pour l'accès sortant aux ressources publiques, telles que les registres d'images ou les bibliothèques de dépendances.
FAQ sur la gestion du réseau : Problèmes réseau courants avec les clusters gérés ACK.