Considérations et politiques de mise à jour des ressources CCM pour la configuration de l'équilibrage de charge des services - Container Service for Kubernetes

Lorsqu'un service est défini avec le type LoadBalancer, le Cloud Controller Manager (CCM) d'ACK crée ou configure un équilibreur de charge (Classic Load Balancer ou Network Load Balancer), y compris l'instance, les écouteurs et les groupes de serveurs backend. Cette rubrique détaille les points à prendre en compte pour configurer l'équilibrage de charge des services ainsi que les politiques de mise à jour des ressources par le CCM.

Considérations

Quelles instances SLB peuvent être réutilisées ?

Seules les instances créées dans la console Server Load Balancer (SLB) sont réutilisables. Les instances SLB créées automatiquement par cloud-controller-manager ou gérées par ACK (comme l'instance API Server) ne peuvent pas être réutilisées.
Pour réutiliser une instance SLB privée, celle-ci doit se trouver dans le même Virtual Private Cloud (VPC) que le cluster. La réutilisation inter-VPC s'applique uniquement aux instances NLB.
Le type d'adresse de l'instance SLB réutilisée doit correspondre au type d'accès du service. Si le service est configuré pour un Public Access (à l'aide de l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"), la IP Version de l'instance SLB doit être Public. Si le service est configuré pour un accès interne (à l'aide de l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"), la IP Version de l'instance SLB doit être Private.
Plusieurs services ne peuvent pas utiliser le même port d'écouteur sur une même instance SLB.
Lors de la réutilisation d'une instance SLB entre plusieurs clusters, assurez-vous que la combinaison namespace et nom du service est unique dans chaque cluster.

Considérations relatives aux instances SLB gérées par le CCM

Le CCM configure l'équilibrage de charge uniquement pour les services dont le type est Type=LoadBalancer.

Important

Si vous changez le type d'un service Type=LoadBalancer vers un autre type, le CCM supprime les configurations SLB. Le service devient alors inaccessible via l'instance SLB.

Le CCM utilise une API déclarative et peut actualiser la configuration SLB en fonction des modifications apportées au service. Les modifications manuelles effectuées dans la console SLB risquent d'être écrasées.

Important

Ne modifiez pas les configurations des instances SLB gérées par ACK directement dans la console SLB. Vos modifications pourraient être perdues et le service devenir inaccessible.

Ne supprimez ni ne modifiez le finaliseur service.k8s.alibaba/resources ou service.k8s.alibaba/nlb. Cela pourrait empêcher la récupération correcte des ressources CLB ou NLB.
Pour Cloud Controller Manager version 2.5.0 ou ultérieure, la spécification d'une instance CLB lors de la création d'un service nécessite une autorisation préalable. Soumettez une demande via le Quota Center.

Considérations pour l'accès à l'IP externe d'un service LoadBalancer depuis l'intérieur du cluster

Lorsque vous accédez à l'adresse IP SLB d'un service LoadBalancer depuis l'intérieur du cluster, le réseau du cluster peut intercepter le trafic et le transférer directement vers le point de terminaison du service backend, selon le type de plug-in réseau, sa version et la version du cluster.

Ce comportement contourne l'instance SLB externe, ce qui entraîne l'échec des configurations qui en dépendent. Les principaux scénarios affectés incluent :

La politique externalTrafficPolicy est définie sur Local : l'accès peut échouer si le trafic est acheminé vers un nœud ne disposant pas de pods backend.
Le protocole Proxy est activé : le service backend ne peut pas obtenir l'en-tête Proxy Protocol depuis l'instance SLB, provoquant un échec de handshake.
Écouteur HTTP/HTTPS : les opérations dépendantes de SLB, telles que la terminaison TLS ou l'ajout d'en-têtes comme X-Forwarded-For, ne prennent pas effet.

Par conséquent, pour accéder à un service LoadBalancer depuis l'intérieur du cluster :

Utilisez l'adresse intra-cluster du service (ClusterIP ou nom DNS tel que <service-name>.<namespace>.svc.cluster.local) pour une communication inter-services stable.
Pour accéder via le point d'entrée SLB, ajoutez l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname et utilisez le nom de domaine configuré au lieu de l'adresse IP. Consultez la section Définir un nom d'hôte pour un service.

Important
Lors de l'utilisation de cette fonctionnalité, évitez de planifier le pod client et le pod serveur sur le même nœud. Un routage asymétrique pourrait entraîner des échecs d'accès.

Considérations pour la gestion de l'équilibrage de charge à grande échelle dans un seul cluster avec le CCM

Dans les clusters de grande taille, le CCM peut traiter lentement les événements liés aux services. Les scénarios suivants peuvent retarder des opérations telles que la création ou la suppression d'instances SLB et la mise à jour des points de terminaison des groupes de serveurs :

Création ou suppression simultanée de nombreux services LoadBalancer.
Mise à jour simultanée de nombreux points de terminaison de service.
Ajout ou suppression de nœuds par lots lorsque de nombreux services LoadBalancer existent.

Suivez ces bonnes pratiques :

Avant d'effectuer des modifications à grande échelle, évaluez la capacité et effectuez des tests de charge. Prévoyez une marge de traitement suffisante pour éviter les interruptions.
Utilisez des configurations telles que readinessGates et les hooks preStop pour prévenir les interruptions de trafic lors des changements. Consultez la section Implémenter des déploiements progressifs sans temps d'arrêt.
Lorsque vous utilisez de nombreux services LoadBalancer, surveillez attentivement les limites de quota pour CLB et NLB.
Mettez à niveau le cluster et le CCM vers les dernières versions pour bénéficier des optimisations dédiées aux scénarios à grande échelle.

Remplacer l'instance SLB d'un service

Vous ne pouvez pas remplacer directement l'instance SLB d'un service LoadBalancer existant. Supprimez et recréez le service à la place.

Accès externe et chemin du trafic réseau

Lorsque vous exposez des applications en externe via un service LoadBalancer, comprendre le chemin du trafic vous aide à dimensionner correctement la bande passante et à localiser les données de surveillance.

Chemin du trafic

Le trajet de la requête est le suivant : Client → Internet → Équilibreur de charge (CLB/NLB) → Réseau interne Alibaba Cloud → Conteneurs/nœuds backend. Le trafic entre l'équilibreur de charge et les nœuds backend transite par le réseau interne d'Alibaba Cloud, et non par la bande passante publique des nœuds du cluster.

Idée reçue courante sur la bande passante

Augmenter la bande passante publique des nœuds ACK ne résout pas les problèmes de forte concurrence ou de pics de trafic pour les services exposés en externe, car le trafic métier ne passe pas par la sortie réseau publique du nœud. La consommation de bande passante publique ne se produit qu'entre le client et l'équilibreur de charge. Pour résoudre les goulets d'étranglement liés aux performances d'accès externe, ajustez la spécification de bande passante de l'équilibreur de charge plutôt que la bande passante publique du nœud.

Surveillance du trafic amont et aval

Pour afficher le trafic amont et aval d'un service, connectez-vous à la console CLB ou NLB et consultez les données de surveillance sur la page de monitoring de l'instance correspondante. La surveillance au niveau des nœuds ne reflète pas le débit réel du trafic des services exposés en externe.

Méthodes d'accès et restrictions depuis l'extérieur du cluster

Restrictions d'accès ClusterIP

Les instances ECS ou autres ressources situées hors du cluster mais dans le même VPC ne peuvent pas accéder directement au ClusterIP d'un service. ClusterIP est une adresse IP virtuelle accessible uniquement depuis le réseau du cluster. Toute tentative d'accès au ClusterIP depuis une instance ECS externe échouera.

Méthode d'accès recommandée : LoadBalancer privé

Pour accéder aux applications du cluster depuis d'autres instances ECS dans le même VPC, créez un service de type LoadBalancer avec un type d'adresse intranet en ajoutant l'annotation suivante :

service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet

Cela crée une instance SLB privée accessible depuis l'intérieur du VPC. Utilisez l'adresse IP SLB privée générée pour accéder au service depuis des instances ECS externes.

Instabilité des adresses IP des pods

Les adresses IP des pods sont attribuées dynamiquement et changent lorsqu'un pod redémarre, ce qui les rend inadaptées en tant que points d'accès fixes. Utilisez un LoadBalancer privé ou un service NodePort pour fournir un point d'accès stable et persistant aux applications du cluster.

Limites de quota

VPC

Chaque nœud du cluster utilise une entrée de table de routage VPC. La limite par défaut est de 200 entrées. Si votre cluster dépasse 200 nœuds, connectez-vous à la console Quota Center et soumettez une demande.
Consultez la section Limites et quotas VPC.

Pour interroger les quotas VPC, consultez la section Gestion des quotas VPC.

Server Load Balancer

Le CCM crée une instance SLB pour chaque service de type Type=LoadBalancer. Le quota par défaut est de 60 instances CLB et 60 instances NLB. Pour augmenter ce quota, connectez-vous à la console Quota Center et soumettez une demande.
Le CCM attache des instances ECS ou des interfaces réseau élastiques (ENI) au groupe de serveurs backend SLB en fonction de la configuration du service, créant un groupe de serveurs distinct par targetPort. Limites de quota :
- Nombre de serveurs backend : une instance CLB prend en charge jusqu'à 200 serveurs backend ; une instance NLB prend en charge jusqu'à 400 serveurs basés sur ECS, ENI ou IP. Formule de quota : serveurs backend × targetPorts. Pour augmenter le quota, connectez-vous à la console Quota Center et soumettez une demande à l'avance.
- Attachements de groupes de serveurs par instance : une instance ECS ou une ENI peut être attachée à jusqu'à 50 groupes de serveurs backend CLB et 200 groupes de serveurs backend NLB. Pour augmenter cette limite, connectez-vous à la console Quota Center et soumettez une demande.
- Quota supplémentaire lors des mises à jour progressives : de nouveaux pods sont créés avant la destruction des anciens pods, consommant un quota supplémentaire qui peut dépasser les attentes. Prévoyez un quota suffisant à l'avance.
Le CCM crée des écouteurs en fonction des ports du service. La limite par défaut est de 50 écouteurs par instance CLB ou NLB. Pour en ajouter davantage, connectez-vous à la console Quota Center et soumettez une demande.
Consultez les sections Limites CLB et Limites NLB.

Interrogez les quotas SLB dans la section Gestion des quotas Server Load Balancer.

Politiques de mise à jour des instances SLB

Vous pouvez spécifier une instance SLB existante ou laisser le CCM en créer une. Les politiques de mise à jour diffèrent selon ces deux méthodes.

Objet ressource	Spécifier une instance SLB existante	Instance SLB gérée par le CCM
Server Load Balancer	Définissez l'annotation : `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id`. Le CCM utilise cette instance comme équilibreur de charge du service, la configure en fonction des autres annotations et crée des groupes de serveurs virtuels. Lorsque le service est supprimé, le CCM conserve l'instance SLB spécifiée.	Le CCM crée et configure les ressources telles que l'instance SLB, les écouteurs et les groupes de serveurs virtuels en fonction de la configuration du service. Lorsque le service est supprimé, le CCM supprime l'instance SLB créée automatiquement.
Écouteur	Définissez l'annotation : `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners` : Si défini sur `"false"`, le CCM ne gère aucune configuration d'écouteur pour l'instance SLB. Si défini sur `"true"`, le CCM gère les écouteurs en fonction de la configuration du service. Si un écouteur existe déjà, le CCM l'écrase.	Le CCM crée et configure la politique de l'écouteur en fonction de la configuration du service.
Groupe de serveurs backend	Lorsque les points de terminaison backend du service ou les nœuds du cluster changent, le CCM met à jour les groupes de serveurs virtuels backend. Terway : par défaut, le CCM attache les adresses IP des pods au backend SLB, au lieu des nœuds ECS. Flannel : la politique de mise à jour du groupe de serveurs backend varie selon le mode du service. Mode Cluster (`spec.externalTrafficPolicy = Cluster`) : par défaut, le CCM attache tous les nœuds au backend SLB, sauf si le backend est configuré avec BackendLabel. Important Chaque instance ECS possède des limites quant au nombre d'instances SLB qu'elle peut utiliser. Le mode Cluster consomme rapidement ce quota. Une fois épuisé, les services ne peuvent plus se réconcilier. Utilisez le mode Local pour résoudre ce problème. Mode Local (`spec.externalTrafficPolicy = Local`) : le CCM ajoute uniquement au backend SLB les nœuds exécutant les pods du service. Cela réduit la consommation de quota SLB et préserve les adresses IP source de couche 4. Flannel : le CCM n'ajoute jamais les nœuds master au backend SLB. Flannel : par défaut, le CCM ne retire pas du backend SLB les nœuds vidés (`kubectl drain`) ou non planifiables (`kubectl cordon`). Pour les retirer, définissez `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend` sur `on`.

Activer la protection contre la suppression pour un service

La protection contre la suppression empêche la suppression accidentelle de services impliquant des opérations métier critiques ou des données sensibles. Les ressources protégées ne peuvent être supprimées qu'après avoir désactivé manuellement la protection. Consultez la section Activer la protection contre la suppression pour un service.