Configurer des services multiclusters

Cette page vous explique comment activer et utiliser des services multiclusters (MCS). Pour en savoir plus sur le fonctionnement de MCS et ses avantages, consultez la page Services multiclusters.

La fonctionnalité MCS de Google Kubernetes Engine (GKE) étend la portée du service Kubernetes au-delà de la limite du cluster et vous permet de détecter et d'appeler des services sur plusieurs clusters GKE. Vous pouvez exporter un sous-ensemble de services existants ou des nouveaux services.

Lorsque vous exportez un service avec MCS, celui-ci devient disponible sur tous les clusters de votre parc.

Ressources Google Cloud gérées par MCS

MCS gère les composants suivants de Google Cloud :

  • Cloud DNS : MCS configure les zones et les enregistrements Cloud DNS pour chaque service exporté dans vos clusters Fleet. Cela vous permet de vous connecter aux services qui s'exécutent dans d'autres clusters. Ces zones et enregistrements sont créés, lus, mis à jour et supprimés en fonction des services que vous choisissez d'exporter sur les clusters.

  • Règles de pare-feu : MCS configure les règles de pare-feu qui permettent aux pods de communiquer entre eux sur les clusters de votre Fleet. Les règles de pare-feu sont créées, lues, mises à jour et supprimées en fonction des clusters que vous ajoutez à votre Fleet. Ces règles sont semblables à celles créées par GKE pour activer la communication entre les pods d'un cluster GKE.

  • Traffic Director : MCS utilise Traffic Director comme plan de contrôle pour effectuer le suivi des points de terminaison et de leur état sur l'ensemble des clusters.

Exigences

MCS présente les exigences suivantes :

  • MCS n'accepte que l'exportation de services à partir de clusters GKE de VPC natif sur Google Cloud. Pour en savoir plus, consultez la page Créer un cluster de VPC natif. Vous ne pouvez pas utiliser de clusters GKE Standard non VPC natifs.

  • La connectivité entre les clusters dépend des clusters exécutés au sein du même réseau VPC, au sein de réseaux VPC appairés ou partagés. Sinon, les appels aux services externes ne pourront pas dépasser la limite du réseau.

  • Bien qu'un parc puisse couvrir plusieurs projets Google Cloud et réseaux VPC, un seul service multicluster doit être exporté à partir d'un seul projet et d'un seul réseau VPC.

  • MCS n'est pas compatible avec les règles de réseau.

  • Le module complémentaire HttpLoadBalancing doit être activé sur les clusters. Assurez-vous que le module complémentaire HttpLoadBalancing est activé. Le module complémentaire HttpLoadBalancing est activé par défaut et ne doit pas être désactivé.

Tarification

Les services multiclusters sont inclus dans les frais de gestion des clusters GKE et n'entraînent aucun coût supplémentaire. Vous devez activer l'API Traffic Director, mais MCS n'entraîne aucuns frais pour les points de terminaison Traffic Director. L'utilisation de licences GKE Enterprise n'est pas obligatoire pour utiliser MCS.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  1. Installez le SDK Google Cloud.

  2. Activez l'API Google Kubernetes Engine :

    Activer l'API Google Kubernetes Engine

  3. Activez les API MCS, Fleet (hub), Resource Manager, Traffic Director et Cloud DNS :

    gcloud services enable \
    multiclusterservicediscovery.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    trafficdirector.googleapis.com \
    dns.googleapis.com \
    --project=PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet dans lequel vous prévoyez d'enregistrer vos clusters dans une Fleet.

Activer MCS dans votre projet

MCS exige que les clusters GKE participants soient enregistrés dans le même parc. Une fois la fonctionnalité MCS activée pour un parc, tous les clusters peuvent exporter des services entre les clusters du parc.

Bien que MCS nécessite l'enregistrement des clusters dans un parc, l'activation de la plate-forme GKE Enterprise n'est pas nécessaire.

GKE Enterprise

Si l'API GKE Enterprise est activée dans votre projet hôte de parc comme condition préalable pour l'utilisation d'autres composants GKE Enterprise, tous les clusters enregistrés dans le parc du projet sont facturés selon les tarifs de GKE Enterprise. Ce modèle de tarification vous permet d'utiliser toutes les fonctionnalités de GKE Enterprise sur des clusters enregistrés avec des frais uniques par processeur virtuel. Vous pouvez vérifier si l'API GKE Enterprise est activée à l'aide de la commande suivante:

gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com

Si le résultat ressemble à ce qui suit, la plate-forme GKE Enterprise complète est activée et tous les clusters enregistrés dans le parc entraînent des frais GKE Enterprise:

anthos.googleapis.com                        Anthos API

Si ce n'est pas le cas, contactez l'administrateur de votre projet.

Un résultat vide indique que GKE Enterprise n'est pas activé.

Activer MCS sur votre cluster GKE

  1. Activez la fonctionnalité MCS pour le parc de votre projet :

    gcloud container fleet multi-cluster-services enable \
    --project PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet dans lequel vous prévoyez d'enregistrer vos clusters dans une Fleet. Il s'agit de votre projet hôte du parc.

  2. Enregistrez vos clusters GKE dans un parc. Nous vous recommandons vivement d'enregistrer votre cluster avec la fédération d'identité de charge de travail pour GKE activée. Si vous n'activez pas la fédération d'identité de charge de travail pour GKE, vous devez enregistrer le cluster avec un compte de service Google Cloud pour l'authentification et effectuer les étapes supplémentaires décrites dans la section Authentifier les comptes de service.

    Pour enregistrer votre cluster avec la fédération d'identité de charge de travail pour GKE, exécutez la commande suivante :

    gcloud container fleet memberships register MEMBERSHIP_NAME \
   --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \
   --enable-workload-identity \
   --project PROJECT_ID

    Remplacez les éléments suivants :

    • MEMBERSHIP_NAME : nom de l'abonnement que vous choisissez pour représenter de manière unique le cluster dans le parc. Généralement, le nom d'appartenance au parc d'un cluster est le nom du cluster, mais vous devrez peut-être en spécifier un nouveau si un autre cluster portant le nom d'origine existe déjà dans le parc.
    • CLUSTER_LOCATION : zone ou région dans laquelle se trouve le cluster.
    • CLUSTER_NAME : nom du cluster.

  3. Accordez les autorisations IAM requises pour l'outil d'importation MCS :

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \
    --role "roles/compute.networkViewer"

    Remplacez PROJECT_ID par l'ID du projet hôte du parc.

  4. Assurez-vous que chaque cluster de la Fleet possède un espace de noms dans lequel partager les services. Si nécessaire, créez un espace de noms à l'aide de la commande suivante :

    kubectl create ns NAMESPACE

    Remplacez NAMESPACE par le nom de l'espace de noms.

  5. Pour vérifier que MCS est activé, exécutez la commande suivante :

    gcloud container fleet multi-cluster-services describe \
    --project PROJECT_ID

    Le résultat ressemble à ce qui suit :

    createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
  projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
    state:
      code: OK
      description: Firewall successfully updated
      updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
  state: ACTIVE
spec: {}

    Si la valeur de state n'est pas ACTIVE, consultez la section Dépannage.

Authentifier les comptes de service

Si vous avez enregistré vos clusters GKE dans une Fleet utilisant un compte de service, vous devez prendre des mesures supplémentaires pour authentifier ce compte de service. MCS déploie un composant appelé gke-mcs-importer. Ce composant reçoit les mises à jour des points de terminaison de Traffic Director. Pour activer MCS, vous devez donc accorder à votre compte de service l'autorisation de lire les informations de Traffic Director.

Lorsque vous utilisez un compte de service, vous pouvez utiliser le compte de service Compute Engine par défaut ou votre propre compte de service de nœud :

Utiliser MCS

Les sections suivantes vous montrent comment utiliser MCS. MCS utilise l'API Multi-Cluster Services de Kubernetes.

Enregistrer un service pour l'exportation

Pour enregistrer un service pour l'exportation dans d'autres clusters de votre Fleet, procédez comme suit :

  1. Créez un objet ServiceExport nommé export.yaml :

    # export.yaml
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
 namespace: NAMESPACE
 name: SERVICE_EXPORT_NAME

    Remplacez les éléments suivants :

    • NAMESPACE : espace de noms de l'objet ServiceExport. Cet espace de noms doit correspondre à celui du service que vous exportez.
    • SERVICE_EXPORT_NAME : nom d'un service de votre cluster que vous souhaitez exporter vers d'autres clusters de votre parc.

  2. Créez la ressource ServiceExport en exécutant la commande suivante :

    kubectl apply -f export.yaml

L'exportation initiale de votre service prend environ cinq minutes pour être synchronisée avec les clusters enregistrés dans votre Fleet. Une fois qu'un service est exporté, les synchronisations de points de terminaison suivantes surviennent immédiatement.

Vous pouvez exporter le même service depuis plusieurs clusters pour créer un seul point de terminaison de service multicluster à disponibilité élevée avec la distribution du trafic entre les clusters. Avant d'exporter des services portant le même nom et le même espace de noms, assurez-vous de les regrouper de cette manière. Nous vous déconseillons d'exporter des services dans les espaces de noms default et kube-system, en raison de la probabilité élevée de conflits de noms inattendus et du regroupement involontaire des résultats. Si vous exportez plus de cinq services avec le même nom et le même espace de noms, la distribution du trafic sur les services importés peut être limitée à cinq services exportés.

Consommer des services interclusters

MCS n'est compatible qu'avec les services sans adresse IP de cluster et ClusterSetIP. Seuls les enregistrements DNS A sont disponibles.

Une fois que vous avez créé un objet ServiceExport, le nom de domaine suivant est associé au service exporté à partir de n'importe quel pod d'un cluster Fleet :

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Le résultat inclut les valeurs suivantes :

  • SERVICE_EXPORT_NAME et NAMESPACE : valeurs que vous définissez dans votre objet ServiceExport.

Pour les services ClusterSetIP, le domaine est associé à l'adresse ClusterSetIP. Vous pouvez trouver cette valeur en localisant l'objet ServiceImport dans un cluster de l'espace de noms dans lequel l'objet ServiceExport a été créé. L'objet ServiceImport est automatiquement créé.

Par exemple :

kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: external-svc-SERVICE-EXPORT-TARGET
status:
 ports:
 - name: https
   port: 443
   protocol: TCP
   targetPort: 443
 ips: CLUSTER_SET_IP

MCS crée un objet Endpoints dans le cadre de l'importation d'un Service dans un cluster. En examinant cet objet, vous pouvez surveiller la progression d'une importation de l'objet Service. Pour trouver le nom de l'objet Endpoints, recherchez la valeur de l'annotation net.gke.io/derived-service sur un objet ServiceImport correspondant à votre service importé. Par exemple :

kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: external-svc-SERVICE-EXPORT-TARGET

Ensuite, recherchez l'objet Endpoints pour vérifier si MCS a déjà propagé les points de terminaison au cluster d'importation. L'objet Endpoints est créé dans le même espace de noms que l'objet ServiceImport, sous le nom stocké dans l'annotation net.gke.io/derived-service. Par exemple :

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

Remplacez les éléments suivants :

  • DERIVED_SERVICE_NAME: valeur de l'annotation net.gke.io/derived-service sur l'objet ServiceImport.
  • NAMESPACE : espace de noms de l'objet ServiceExport.

Pour en savoir plus sur l'état de fonctionnement des points de terminaison, consultez le tableau de bord de Traffic Director dans la console Google Cloud.

Pour les services sans adresse IP de cluster, le domaine est associé à la liste des adresses IP des points de terminaison dans les clusters d'exportation. Chaque pod backend doté d'un nom d'hôte est également adressable indépendamment avec un nom de domaine qui se présente sous la forme suivante :

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Le résultat inclut les valeurs suivantes :

  • SERVICE_EXPORT_NAME et NAMESPACE : valeurs que vous définissez dans votre objet ServiceExport.
  • MEMBERSHIP_NAME : identifiant unique du parc pour le cluster dans lequel se trouve le pod
  • LOCATION : emplacement de l'abonnement. Les abonnements sont soit global, soit leur emplacement correspond à l'une des régions ou zones où se trouve le pod, par exemple us-central1.
  • HOSTNAME : nom d'hôte du pod.

Vous pouvez également adresser un pod backend avec un nom d'hôte exporté à partir d'un cluster enregistré auprès d'un membre global, en utilisant un nom de domaine au format suivant :

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Désactiver MCS

Pour désactiver MCS, procédez comme suit :

  1. Pour chaque cluster de votre Fleet, supprimez chaque objet ServiceExport que vous avez créé :

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

    Remplacez les éléments suivants :

    • SERVICE_EXPORT_NAME : nom de votre objet ServiceExport.
    • NAMESPACE : espace de noms de l'objet ServiceExport.

  2. Annulez l'enregistrement de vos clusters dans la Fleet s'ils n'ont pas besoin d'être enregistrés à d'autres fins.

  3. Désactivez la fonctionnalité multiclusterservicediscovery :

    gcloud container fleet multi-cluster-services disable \
    --project PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet dans lequel vous avez enregistré les clusters.

  4. Désactivez l'API pour MCS :

    gcloud services disable multiclusterservicediscovery.googleapis.com \
    --project PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet dans lequel vous avez enregistré les clusters.

Limites

Les limites suivantes ne sont pas appliquées et, dans certains cas, vous pouvez les dépasser en fonction de la charge de vos clusters ou de votre projet, ainsi que du taux d'abandon des points de terminaison. Toutefois, vous risquez de rencontrer des problèmes de performances lorsque ces limites sont dépassées.

  • Exportation de clusters : un seul service, identifié par un nom d'espace de noms, peut être exporté en toute sécurité depuis cinq clusters au maximum en même temps. Au-delà de cette limite, il est possible que seul un sous-ensemble de points de terminaison puisse être importé dans les clusters consommant des services. Vous pouvez exporter différents services à partir de différents sous-ensembles de clusters.

  • Le nombre de pods derrière un seul service : sans risques si vous conservez moins de 250 pods derrière un seul service. Il s'agit de la même limite que les services de cluster unique. Avec des charges de travail relativement statiques et un petit nombre de services multiclusters, il est possible de dépasser considérablement ce nombre en milliers de points de terminaison par service. Comme pour les services à cluster unique, tous les points de terminaison sont surveillés par kube-proxy sur chaque nœud. Au-delà de cette limite, en particulier lors de l'exportation simultanée à partir de plusieurs clusters, des nœuds plus importants peuvent être nécessaires.

  • Nombre de services multiclusters exportés simultanément : nous vous recommandons d'exporter simultanément au maximum 50 ports de service uniques, identifiés par le nom d'espace de noms et les ports déclarés d'un service. Par exemple, l'exportation d'un service qui expose les ports 80 et 443 serait comptabilisé comme 2 ports de la limite de 50 ports de service uniques. Les services ayant le même nom d'espace de noms exportés à partir de plusieurs clusters sont considérés comme un seul service unique. Le service à deux ports mentionné précédemment ne serait toujours comptabilisé que comme deux ports s'il était exporté depuis cinq clusters simultanément. Chaque service multicluster est comptabilisé dans votre quota de services de backend, et chaque cluster ou zone d'exportation crée un groupe de points de terminaison du réseau (NEG).

  • Types de service : MCS n'est compatible qu'avec les services ClusterSetIP et sans adresse IP de cluster. Les services NodePort et LoadBalancer ne sont pas compatibles et peuvent entraîner un comportement inattendu.

  • Utiliser l'agent IPmasq avec MCS: MCS fonctionne comme prévu lorsque vous utilisez une plage d'adresses IP de pod par défaut ou non masquée.

    Si vous utilisez une plage d'adresses IP de pod personnalisée ou un ConfigMap d'agent IPmasq personnalisé, le trafic MCS peut être masqué. Cela empêche MCS de fonctionner, car les règles de pare-feu n'autorisent que le trafic provenant des adresses IP des pods.

    Pour éviter ce problème, vous devez utiliser la plage d'adresses IP des pods par défaut ou spécifier toutes les plages d'adresses IP des pods dans le champ nonMasqueradeCIDRs du ConfigMap de l'agent IPmasq. Si vous utilisez Autopilot ou si vous devez utiliser une plage d'adresses IP de pod autre que celle par défaut et que vous ne pouvez pas spécifier toutes les plages d'adresses IP de pods dans le ConfigMap, vous devez utiliser la règle NAT de sortie pour configurer le masquage d'adresses IP.

MCS avec des clusters dans plusieurs projets

Vous ne pouvez pas exporter un service si ce service est déjà exporté par d'autres clusters d'un autre projet du parc portant le même nom et le même espace de noms. Vous pouvez accéder au service dans d'autres clusters du parc dans d'autres projets, mais ces clusters ne peuvent pas exporter le même service dans le même espace de noms.

Dépannage

Les sections suivantes vous présentent des conseils de dépannage pour MCS.

Afficher l'état de la fonctionnalité (featureState)

Afficher l'état de la fonctionnalité peut vous aider à confirmer si MCS a bien été configuré. Vous pouvez afficher l'état de la fonctionnalité MCS à l'aide de la commande suivante :

gcloud container fleet multi-cluster-services describe

Le résultat ressemble à ce qui suit :

createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
   state:
     code: OK
     description: Firewall successfully updated
     updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
 state: ACTIVE
spec: {}

Les champs les plus utiles pour le dépannage sont code et description.

Codes de featureState

Un code indique l'état général du membre en rapport à MCS. Vous pouvez trouver ces champs dans le champ state.code. Il existe trois codes possibles :

  • OK : l'appartenance a bien été ajoutée à MCS et est prête à être utilisée.

  • WARNING : MCS est en train de rapprocher la configuration de l'appartenance. Le champ de description peut fournir plus d'informations sur l'origine de ce code.

  • FAILED : l'appartenance n'a pas été ajoutée à MCS. Les autres membres de la Fleet avec un code OK ne sont pas concernés par l'appartenance FAILED. Le champ de description peut fournir plus d'informations sur l'origine de ce code.

  • ERROR : cette appartenance ne dispose pas de ressources. Les autres membres de la Fleet avec un code OK ne sont pas concernés par l'appartenance ERROR. Le champ de description peut fournir plus d'informations sur l'origine de ce code.

Descriptions de featureState

Une description fournit des informations supplémentaires sur l'état de l'appartenance dans MCS. Les descriptions suivantes sont disponibles dans le champ state.description :

  • Firewall successfully created : ce message indique que la règle de pare-feu du membre a bien été créée et/ou mise à jour. Le code de l'appartenance est OK.

  • Firewall creation pending : ce message indique que la règle de pare-feu du membre est en attente de création ou de mise à jour. Le code de l'appartenance est WARNING. Lorsque la règle de pare-feu est en attente, il peut y avoir des problèmes lors de la mise à jour et de la connexion aux nouveaux services multiclusters et appartenances ajoutés.

  • GKE Cluster missing : ce message indique que le cluster GKE enregistré n'est pas disponible ou n'est pas supprimé. Le code de l'appartenance est ERROR. Vous devez annuler l'enregistrement au parc pour cette appartenance manuellement après la suppression d'un cluster GKE.

  • Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required : ce message indique des erreurs StatusForbidden (état interdit) internes (403). Le code de l'appartenance est FAILED. Cette erreur se produit dans les scénarios suivants :

    • Vous n'avez pas activé les API nécessaires dans le projet du membre.

      Si le cluster du membre se trouve dans un projet distinct de la Fleet, consultez la section Configuration multiprojet pour vous assurer que vous avez effectué toutes les étapes nécessaires. Si vous avez effectué toutes les étapes, assurez-vous que ces API sont activées dans le projet d'enregistrement à l'aide des commandes suivantes :

      gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID
gcloud services enable dns.googleapis.com --project PROJECT_ID
gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID
gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID

      Remplacez PROJECT_ID par l'ID du projet dans lequel vous avez enregistré les clusters.

    • Les comptes de service mcsd ou gkehub nécessitent des autorisations supplémentaires dans le projet du membre.

      Les comptes de service mcsd et gkehub doivent avoir été créés automatiquement dans le projet hôte du parc avec toutes les autorisations requises. Pour vérifier que les comptes de service existent, exécutez les commandes suivantes :

      gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd
gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub

      Remplacez PROJECT_ID par l'ID du projet hôte du parc.

    Ces commandes doivent afficher le nom complet des comptes de service mcsd et gkehub.

  • Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity : ce message s'affiche lorsque les clusters hébergés dans différents VPC sont enregistrés dans la même Fleet. L'état de l'appartenance est OK. Le réseau VPC d'un cluster est défini par le réseau de NetworkConfig. Les services multiclusters nécessitent un réseau plat. Ces VPC doivent être activement appairés pour que les services multiclusters se connectent correctement les uns aux autres. Pour en savoir plus, consultez la section Exemple de configuration d'appairage de réseaux VPC.

  • Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed. : ce message vous rappelle que les clusters multiprojets requièrent des étapes de configuration supplémentaires. L'état de l'appartenance est OK. Les appartenances entre projets sont définies sous la forme de cluster d'un membre qui n'existe pas dans le même projet que le parc. Pour en savoir plus, consultez la section Configuration multiprojet.

  • Non-GKE clusters are currently not supported : ce message vous rappelle que MCS n'est compatible qu'avec les clusters GKE. Les clusters non-GKE ne peuvent pas être ajoutés à MCS. L'état de l'appartenance est FAILED.

Problèmes connus

Services MCS avec plusieurs ports

Il existe un problème connu avec les services multiclusters avec plusieurs ports TCP/UDP sur GKE Dataplane V2, où certains points de terminaison ne sont pas programmés dans le plan de données. Ce problème affecte les versions de GKE antérieures à 1.26.3-gke.400.

Pour contourner ce problème, lorsque vous utilisez GKE Dataplane V2, utilisez plusieurs MCS avec un seul port au lieu d'un MCS avec plusieurs ports.

MCS avec VPC partagé

Avec la mise en œuvre actuelle de MCS, si vous déployez plusieurs parcs dans le même VPC partagé, les métadonnées sont partagées entre les parcs. Lorsqu'un service est créé dans un parc, les métadonnées de service sont exportées ou importées dans toutes les autres flottes faisant partie du même VPC partagé et visibles par l'utilisateur.

Ce comportement sera résolu dans une prochaine version de MCS.

La vérification d'état utilise le port par défaut au lieu de containerPort

Lorsque vous déployez un service avec un champ targetPort faisant référence à un port nommé dans un déploiement, MCS configure le port par défaut pour la vérification d'état au lieu du port containerPort spécifié.

Pour éviter ce problème, utilisez des valeurs numériques dans le champ de service ports.targetPort et le champ de déploiement readinessProbe.httpGet.port au lieu de valeurs nommées.

Ce comportement sera résolu dans une prochaine version de MCS.

Étape suivante