Container Service for Kubernetes:Recommended HA configurations for ACK clusters

Conseils relatifs à cette rubrique

Cette rubrique s'adresse aux développeurs et administrateurs de clusters Container Service for Kubernetes. Elle fournit des recommandations générales pour la planification et la création de clusters à haute disponibilité. Les configurations réelles varient en fonction de votre environnement de cluster et de vos exigences métier. Cette rubrique couvre les configurations de haute disponibilité pour le plan de contrôle et le plan de données du cluster.

Exemple d'architecture de cluster

Un cluster ACK se compose de deux parties principales : le plan de contrôle et les nœuds réguliers ou virtuels.

• Le plan de contrôle gère le cluster, y compris la planification des charges de travail et le maintien de l'état. Prenons l'exemple d'un cluster ACK managé. Un cluster ACK managé utilise une architecture Kubernetes-on-Kubernetes pour héberger les composants du plan de contrôle tels que Kube API Server, etcd et Kube Scheduler.

• Nœuds réguliers ou virtuels : les clusters ACK prennent en charge les nœuds réguliers (instances ECS) et les nœuds virtuels. Les nœuds exécutent les charges de travail et fournissent des ressources pour les conteneurs.

Les clusters ACK offrent par défaut un déploiement haute disponibilité multi-zones de disponibilité (multi-AZ). La figure suivante illustre l'architecture d'un cluster ACK managé.

Haute disponibilité de l'architecture du plan de contrôle

Pour les clusters ACK managés, tels que les clusters ACK managés (édition Pro et édition Basic), les clusters ACK Serverless (édition Pro et édition Basic), les clusters ACK Edge et les clusters LINGJUN, ACK gère leurs plans de contrôle et des composants tels que kube-apiserver, etcd et kube-scheduler.

• Régions multi-zones : tous les composants managés utilisent un déploiement équilibré multi-réplicas et multi-AZ, garantissant la continuité du service en cas de défaillance d'une seule zone ou d'un seul nœud.

• Régions mono-zone : tous les composants managés utilisent un déploiement multi-réplicas et multi-nœuds, garantissant la continuité du service en cas de défaillance d'un seul nœud.

Plus précisément, etcd dispose d'au moins trois réplicas et kube-apiserver d'au moins deux. Tous les réplicas kube-apiserver se connectent au VPC du cluster via des interfaces réseau élastiques (ENI). Le kubelet et Kube Proxy se connectent à kube-apiserver via l'équilibreur de charge classique (CLB) d'API Server ou une ENI.

Tous les composants managés principaux évoluent de manière élastique en fonction de l'utilisation des ressources telles que le CPU et la mémoire, répondant dynamiquement aux exigences d'API Server avec des garanties stables en matière de contrat de niveau de service (SLA).

Au-delà de la haute disponibilité multi-zones par défaut du plan de contrôle, configurez la haute disponibilité du plan de données : Configurations de haute disponibilité pour les pools de nœuds et les nœuds virtuels, Configurations de haute disponibilité pour les charges de travail, Configurations de haute disponibilité pour l'équilibrage de charge et Configurations recommandées pour les composants.

Configurations de haute disponibilité des pools de nœuds et des nœuds virtuels

Les clusters ACK prennent en charge les nœuds réguliers (instances ECS) et les nœuds virtuels, gérés via des pools de nœuds pour des opérations telles que les mises à niveau, la mise à l'échelle et l'exploitation et la maintenance. Utilisez des instances ECS pour un trafic stable ou prévisible, et des nœuds virtuels pour le trafic en rafale afin de réduire les coûts. Consultez la Présentation des pools de nœuds managés.

Configurations de haute disponibilité des pools de nœuds

Combinez la mise à l'échelle automatique des nœuds, les ensembles de déploiement, les déploiements multi-zones et les contraintes de distribution topologique Kubernetes pour isoler les services dans les domaines de défaillance et réduire les points de défaillance uniques.

Configurer la mise à l'échelle automatique des nœuds

Chaque pool de nœuds est soutenu par un groupe Auto Scaling (ESS), prenant en charge la mise à l'échelle manuelle et automatique au niveau de la planification de la charge ou des ressources du cluster. Consultez la Mise à l'échelle automatique et Activer la mise à l'échelle automatique des nœuds.

Activer les ensembles de déploiement

Un ensemble de déploiement disperse les instances ECS sur différents serveurs physiques pour éviter les pannes co-localisées. Spécifiez un ensemble de déploiement pour un pool de nœuds afin que les instances ajoutées lors de la mise à l'échelle soient placées sur des machines physiques distinctes, améliorant ainsi la reprise après sinistre et la disponibilité. Consultez les Bonnes pratiques pour les ensembles de déploiement de pools de nœuds.

Configurer la distribution multi-AZ

ACK prend en charge les pools de nœuds multi-zones. Sélectionnez plusieurs vSwitch de différentes zones lors de la création d'un pool de nœuds et définissez la Scaling Policy sur Distribution Balancing pour distribuer uniformément les instances ECS entre les zones. Si un déséquilibre des ressources se produit en raison d'une rupture de stock, effectuez une opération de rééquilibrage. Consultez Activer la mise à l'échelle automatique des nœuds.

Activer les contraintes de distribution topologique

La mise à l'échelle automatique des nœuds, les ensembles de déploiement et la distribution multi-zones, combinés aux contraintes de distribution topologique Kubernetes, permettent d'atteindre différents niveaux d'isolation des domaines de défaillance. Les nœuds des pools de nœuds ACK reçoivent automatiquement des étiquettes de topologie telles que kubernetes.io/hostname, topology.kubernetes.io/zone et topology.kubernetes.io/region. Utilisez ces contraintes pour contrôler la distribution des pods entre les domaines de défaillance et améliorer la tolérance aux pannes d'infrastructure.

Les clusters ACK prennent en charge la planification consciente de la topologie, par exemple en réessayant les pods dans les domaines de topologie ou en planifiant les pods sur des instances ECS dans le même ensemble de déploiement à faible latence.

Configurations de haute disponibilité des nœuds virtuels

Les nœuds virtuels ACK planifient les pods sur Elastic Container Instance (ECI) sans gérer les serveurs ECS sous-jacents. Les instances ECI sont créées à la demande avec une facturation à l'utilisation à la seconde.

Une mise à l'échelle horizontale rapide ou le lancement de travaux par lots peut épuiser l'inventaire des instances ou les adresses IP des vSwitch dans une zone, provoquant des échecs de création d'ECI. La fonctionnalité multi-zones des clusters ACK Serverless améliore les taux de réussite de création d'ECI.

Configurez le profil ECI pour les nœuds virtuels et spécifiez des vSwitch dans différentes zones pour un déploiement multi-zones.

• ECI distribue les demandes de création de pods sur tous les vSwitch.

• Si un vSwitch manque d'inventaire, ECI essaie automatiquement le vSwitch suivant.

Modifiez le champ vSwitchIds dans le ConfigMap kube-system/eci-profile. Ajoutez les ID de vSwitch, séparés par des virgules (,). Les modifications prennent effet immédiatement. Consultez Créer des pods ECI multi-zones.

kubectl -n kube-system edit cm eci-profile

apiVersion: v1
data:
  kube-proxy: "true"
  privatezone: "true"
  quota-cpu: "192000"
  quota-memory: 640Ti
  quota-pods: "4000"
  regionId: cn-hangzhou
  resourcegroup: ""
  securitygroupId: sg-xxx
  vpcId: vpc-xxx
  vSwitchIds: vsw-xxx,vsw-yyy,vsw-zzz
kind: ConfigMap

Configurations de haute disponibilité des charges de travail

Assurez-vous que les pods restent en cours d'exécution ou récupèrent rapidement après des pannes en configurant des contraintes de distribution topologique, une anti-affinité de pod, des budgets de perturbation de pod (PDB) et des vérifications d'intégrité avec auto-guérison.

Configurer les contraintes de distribution topologique

Les contraintes de distribution topologique distribuent uniformément les pods sur les nœuds et les zones pour améliorer la disponibilité des applications. Cela s'applique aux types de charges de travail tels que Deployment, StatefulSet, DaemonSet, Job et CronJob.

Définissez maxSkew.topologyKey pour contrôler la distribution des pods dans les domaines de topologie, par exemple pour distribuer uniformément les charges de travail entre les zones. Voici un exemple.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-zone
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-zone
  template:
    metadata:
      labels:
        app: app-run-per-zone
    spec:
      containers:
        - name: app-container
          image: app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: app-run-per-zone

Configurer l'anti-affinité de pod

L'anti-affinité de pod empêche les pods d'être planifiés sur le même nœud, améliorant ainsi l'isolation des pannes. Voici un exemple.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-node
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-node
  template:
    metadata:
      labels:
        app: app-run-per-node
    spec:
      containers:
        - name: app-container
          image: app-image
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - app-run-per-node
              topologyKey: "kubernetes.io/hostname"

Les contraintes de distribution topologique peuvent également limiter les pods à un par nœud. Avec topologyKey: "kubernetes.io/hostname", chaque nœud agit comme un domaine de topologie.

L'exemple suivant définit maxSkew sur 1, topologyKey sur "kubernetes.io/hostname" et whenUnsatisfiable sur DoNotSchedule, limitant la différence de nombre de pods entre les nœuds à un maximum d'un pour une distribution uniforme.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: my-app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: my-app

Configurer le budget de perturbation de pod

Un budget de perturbation de pod (PDB) définit le nombre minimum de réplicas disponibles pendant la maintenance ou la panne d'un nœud, empêchant trop de réplicas d'être terminés simultanément. Voici un exemple.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-pdb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-with-pdb
  template:
    metadata:
      labels:
        app: app-with-pdb
    spec:
      containers:
        - name: app-container
          image: app-container-image
          ports:
            - containerPort: 80
--- 
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-for-app
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: app-with-pdb

Configurer les vérifications d'intégrité des pods et l'auto-guérison

Configurez des sondes de vivacité, de préparation et de démarrage avec des politiques de redémarrage pour surveiller l'intégrité des conteneurs et permettre l'auto-guérison. Voici un exemple.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-probe
spec:
  containers:
    - name: app-container
      image: app-image
      livenessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 5
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/ready
        initialDelaySeconds: 20
        periodSeconds: 15
  restartPolicy: Always

Configurations de haute disponibilité de l'équilibrage de charge

Améliorez la stabilité du service et l'isolation des pannes en spécifiant des zones principales et secondaires pour les instances Server Load Balancer (SLB) et en activant les indications conscientes de la topologie.

Spécifier des zones principales et secondaires pour les instances CLB

CLB se déploie sur plusieurs zones dans la plupart des régions pour la reprise après sinistre inter-centres de données. Spécifiez des zones principales et secondaires pour les instances CLB à l'aide d'annotations de service pour correspondre aux zones des instances ECS du pool de nœuds, réduisant ainsi le transfert de données inter-zones. Consultez les Régions et zones qui prennent en charge CLB et Spécifier des zones principales et secondaires lors de la création d'une instance CLB.

Voici un exemple.

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "cn-hangzhou-b"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "cn-hangzhou-i"
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

Activer les indications conscientes de la topologie

Kubernetes 1.23 a introduit le routage conscient de la topologie (indications conscientes de la topologie) pour réduire le trafic inter-zones et améliorer les performances réseau.

Activez cette fonctionnalité dans le service. Lorsque suffisamment de points de terminaison sont disponibles dans la zone, le contrôleur EndpointSlice donne la priorité au routage du trafic vers les points de terminaison plus proches de l'origine de la demande en fonction des indications de topologie, maintenant le trafic dans la même zone pour réduire les coûts. Consultez Routage conscient de la topologie.

Configurations recommandées pour les modules complémentaires

ACK fournit divers composants pour étendre la fonctionnalité du cluster. Consultez la Présentation des composants et notes de version et Gérer les composants.

Références

• Utilisez des types d'instance ECS plus grands pour les nœuds de calcul. Consultez les Configurations recommandées pour les types d'instance ECS.

• Pour les déploiements de grande envergure de l'édition Pro des clusters ACK managés (généralement plus de 500 nœuds ou 10 000 pods), consultez les Recommandations d'utilisation pour les clusters à grande échelle.

• Consultez les Bonnes pratiques pour les nœuds et les pools de nœuds.

• Consultez les Bonnes pratiques pour la mise à l'échelle automatique.