Activer des fonctionnalités facultatives sur le plan de contrôle au sein du cluster
Cette page explique comment activer des fonctionnalités facultatives dans un plan de contrôle au sein du cluster. Pour plus d'informations sur le plan de contrôle géré, consultez Configurez le maillage de services Cloud Service géré géré.
Lorsque vous installez Cloud Service Mesh dans le cluster,
les fonctionnalités activées par défaut diffèrent selon la plate-forme.
Vous pouvez ignorer la configuration par défaut et activer une fonctionnalité facultative en incluant un fichier de superposition lorsque vous installez (ou mettez à niveau) Cloud Service Mesh. Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator
que vous utilisez pour configurer le plan de contrôle. Spécifiez une fonctionnalité par fichier de superposition. Vous pouvez superposer davantage de superpositions. Chaque fichier de superposition remplace la configuration des calques précédents.
À propos des fichiers de superposition
Les fichiers de superposition de cette page sont
anthos-service-mesh
dans GitHub. Ces fichiers contiennent des personnalisations courantes de la configuration par défaut. Vous pouvez utiliser ces fichiers tels quels ou vous pouvez apporter des modifications supplémentaires si nécessaire.
Lorsque vous installez Cloud Service Mesh à l'aide du service
asmcli
, vous
vous pouvez spécifier un ou plusieurs fichiers de superposition à l'aide des propriétés --option
ou
--custom_overlay
options. Si vous n'avez pas besoin de modifier les fichiers du dépôt anthos-service-mesh
, vous pouvez utiliser --option
. Le script récupère alors le fichier de GitHub à votre place. Sinon, vous pouvez apporter des modifications au fichier de superposition, puis utiliser l'option --custom_overlay
pour le transmettre au script asmcli
.
N'incluez pas plusieurs ressources personnalisées dans un même fichier de superposition. | Créer des fichiers de superposition distincts pour chaque ressource personnalisée |
---|---|
![]() |
![]() |
Activer les fonctionnalités facultatives
Les exemples suivants sont simplifiés pour montrer uniquement l'utilisation des superpositions personnalisées pour activer les fonctionnalités facultatives. Remplacez OTHER_FLAGS
par le
options d'installation requises.
La commande asmcli install
propose deux méthodes pour activer une fonctionnalité facultative. La méthode à utiliser dépend de la nécessité ou non de modifier le fichier de superposition.
Utilisez
--option
lorsque vous n'avez pas besoin de modifier le fichier de superposition. Avec--option
,asmcli
extrait automatiquement le fichier du dépôt GitHub. Vous devez donc disposer d'une connexion Internet../asmcli install \ OTHER_FLAGS \ --option OPTION_NAME
Remplacez
OPTION_NAME
par l'option que vous souhaitez activer. Veillez à omettre l'extension .yaml et à n'inclure que le nom de la superposition. tel queiap-operator
etattached-cluster
. Pour obtenir la liste des options disponibles, consultez laanthos-service-mesh
d'un package.Utilisez
--custom_overlay
lorsque vous devez personnaliser le fichier de superposition../asmcli install \ OTHER_FLAGS \ --custom_overlay PATH_TO_FILE
Remplacez
PATH_TO_FILE
par le chemin d'accès au fichier de superposition que vous souhaitez utiliser.
Format YAML pour les fonctionnalités facultatives
Les sections suivantes fournissent le code YAML permettant d'activer les fonctionnalités facultatives compatibles.
Mode mTLS STRICT
La configuration global.mtls.enabled
a été supprimée de la ressource personnalisée IstioOperator
pour éviter les problèmes liés aux mises à niveau et fournir une installation plus flexible.
Pour activer le mode TLS STRICT
, configurez une règle d'authentification des pairs à la place.
Image de proxy Distroless
Il est recommandé de limiter le contenu d'un environnement d'exécution de conteneur aux packages nécessaires. Cette approche améliore la sécurité et le rapport signal sur bruit des outils d'analyse des failles CVE (Common Vulnerabilities and Exposures). Istio fournit des images de proxy basées sur des images de base distroless.
La configuration suivante active le partage des images pour l'ensemble du maillage de services Cloud Service. Pour modifier un type d'image, vous devez redémarrer tous les pods et les réinjecter pour qu'ils prennent effet.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
defaultConfig:
image:
imageType: distroless
L'image distroless ne contient pas de fichiers binaires autres que le proxy. Par conséquent, il n'est pas possible d'exécuter une interface système (exec
), ni d'utiliser curl
, ping
ou d'autres utilitaires de débogage dans le conteneur. Si vous tentez d'exécuter une interface système, l'erreur suivante s'affiche.
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "<container-id>"
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown
Si vous avez besoin d'accéder à ces outils pour des pods spécifiques, vous pouvez remplacer imageType
à l'aide de l'annotation de pod suivante.
sidecar.istio.io/proxyImageType: debug
Une fois que vous avez modifié le type d'image d'un déploiement via l'annotation, le déploiement doit être redémarré.
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
Pour la plupart des types de débogage de proxy, istioctl proxy-cmd
doit être utilisé, ce qui ne nécessite pas d'image de base de débogage.
Utiliser une superposition personnalisée pour le registre personnalisé
Vous pouvez utiliser une superposition personnalisée pour les registres personnalisés, par exemple si vous devez installer Cloud Service Mesh à partir d'un registre de conteneurs personnalisé. Exemple :
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
hub: {private_registry_url}
Voici une liste d'images pour Cloud Service Mesh que vous devez dupliquer sur le registre de conteneurs personnalisés:
- Install-cni :
gke.gcr.io/asm/install-cni:1.15.7-asm.23
- Managed Data Plane :
gke.gcr.io/asm/mdp:1.15.7-asm.23
- Pilot :
gke.gcr.io/asm/pilot:1.15.7-asm.23
- Proxyv2 :
gke.gcr.io/asm/proxyv2:1.15.7-asm.23
Ajouter des images à un registre privé
Pour transférer des images Cloud Service Mesh vers un registre privé, procédez comme suit : étapes.
-
Extrayez les images Cloud Service Mesh:
docker pull gke.gcr.io/asm/install-cni:1.15.7-asm.23 docker pull gke.gcr.io/asm/mdp:1.15.7-asm.23 docker pull gke.gcr.io/asm/pilot:1.15.7-asm.23 docker pull gke.gcr.io/asm/proxyv2:1.15.7-asm.23
-
Créez une variable pour l'URL de votre registre privé :
Remplacezexport PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
PRIVATE_REGISTRY_URL
par votre registre privé. URL. -
Ajoutez un tag aux images avec l'URL de votre registre privé :
docker tag gke.gcr.io/asm/install-cni:1.15.7-asm.23 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.15.7-asm.23 docker tag gke.gcr.io/asm/mdp:1.15.7-asm.23 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.15.7-asm.23 docker tag gke.gcr.io/asm/pilot:1.15.7-asm.23 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.15.7-asm.23 docker tag gke.gcr.io/asm/proxyv2:1.15.7-asm.23 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.15.7-asm.23
- Transférez les images taguées vers votre registre privé :
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.15.7-asm.23 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.15.7-asm.23 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.15.7-asm.23 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.15.7-asm.23
- (Facultatif) Si vous utilisez un
service canonique, puis ajoutez
des images de service canoniques à votre registre privé.
- Extrayez les images du service canonique de Cloud Service Mesh:
docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 docker pull gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
- Ajoutez un tag aux images avec l'URL de votre registre privé :
docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 \ ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 docker tag gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
- Transférez les images taguées vers votre registre privé :
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/kube-rbac-proxy:v0.13.1 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
- Extrayez les images du service canonique de Cloud Service Mesh:
Si vous pouvez extraire les images taguées de votre registre privé, la procédure a été correctement effectuée.
Augmenter la durée du drainage de terminaison
Par défaut, Envoy attend cinq secondes (5s
) que les connexions existantes se terminent lorsqu'un pod est en cours d'arrêt.
La valeur du pod terminationGracePeriodSeconds
doit être supérieure à la valeur terminationDrainDuration
.
Pour en savoir plus, consultez Options globales du réseau maillé.
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
defaultConfig:
terminationDrainDuration: 30s
Activer les journaux d'accès
Pour en savoir plus, consultez la page Activer la journalisation des accès Envoy.
Cloud Trace
Cloud Trace est disponible avec les installations Cloud Service Mesh sur les plates-formes suivantes : plates-formes:
- GKE sur Google Cloud
- des clusters GKE Enterprise sur site si vous l'installez avec Autorité de certification Cloud Service Mesh
Pour en savoir plus, consultez Accéder aux traces.
Sortie via des passerelles de sortie
Nous vous recommandons d'installer une passerelle injectée comme décrit dans la section Installer et mettre à niveau des passerelles.
Container Network Interface d'Istio
La façon dont vous activez l'interface CNI (Container Network Interface) d'Istio dépend de la manière l'environnement sur lequel Cloud Service Mesh est installé.
Choisissez le fichier de superposition qui correspond à votre plate-forme.
Activer CNI sur GKE
Activer CNI sur site
Activer les journaux de trafic hors de Google Cloud
Installer Cloud Service Mesh avec l'autorité de certification Istio en dehors des rapports Google Cloud vers Prometheus par défaut. Utilisez cette option pour activer la création de rapports sur le trafic. les journaux, ou les deux. Vous pouvez donc utiliser Tableaux de bord Cloud Service Mesh
Stackdriver exclusivement
Stackdriver et Prometheus
Activer un équilibreur de charge interne
Nous vous recommandons d'installer une passerelle injectée comme décrit dans la section Installer et mettre à niveau des passerelles pour configurer un équilibreur de charge interne sur GKE. Lors de la configuration du service de passerelle, incluez l'annotation networking.gke.io/load-balancer-type: "Internal"
.
Gestion des certificats externes sur la passerelle d'entrée
Pour plus d'informations sur l'activation de la gestion des certificats externes sur la passerelle d'entrée à l'aide d'Envoy SDS, consultez la page Passerelles sécurisées.