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émentaireHttpLoadBalancing
est activé. Le module complémentaireHttpLoadBalancing
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 :
Installez le SDK Google Cloud.
Activez l'API Google Kubernetes Engine :
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
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.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.
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.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.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 pasACTIVE
, 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 :
Si vous utilisez un compte de service Compute Engine par défaut, activez les champs d'application suivants :
https://www.googleapis.com/auth/compute.readonly
https://www.googleapis.com/auth/cloud-platform
Pour en savoir plus sur l'activation des champs d'application, consultez la section Modifier le compte de service et les champs d'application d'accès d'une instance.
Si vous utilisez votre propre compte de service de nœud, attribuez-lui le rôle
roles/compute.networkViewer
.
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 :
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'objetServiceExport
. 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.
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
etNAMESPACE
: valeurs que vous définissez dans votre objetServiceExport
.
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'annotationnet.gke.io/derived-service
sur l'objetServiceImport
.NAMESPACE
: espace de noms de l'objetServiceExport
.
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
etNAMESPACE
: valeurs que vous définissez dans votre objetServiceExport
.MEMBERSHIP_NAME
: identifiant unique du parc pour le cluster dans lequel se trouve le podLOCATION
: emplacement de l'abonnement. Les abonnements sont soitglobal
, soit leur emplacement correspond à l'une des régions ou zones où se trouve le pod, par exempleus-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 :
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'objetServiceExport
.
Vérifiez que
ServiceExport
disparaît de la liste au bout de 30 minutes.Annulez l'enregistrement de vos clusters dans la Fleet s'ils n'ont pas besoin d'être enregistrés à d'autres fins.
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.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 codeOK
ne sont pas concernés par l'appartenanceFAILED
. 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 codeOK
ne sont pas concernés par l'appartenanceERROR
. 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 estOK
.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 estWARNING
. 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 estERROR
. 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 estFAILED
. 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
ougkehub
nécessitent des autorisations supplémentaires dans le projet du membre.Les comptes de service
mcsd
etgkehub
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
etgkehub
.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 estOK
. 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 estOK
. 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 estFAILED
.
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
- En savoir plus sur les services
- Découvrez comment exposer des applications avec des services.
- Implémentez un exemple de Services multiclusters de base.