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 en savoir plus sur le plan de contrôle géré, consultez la page Configurer la plate-forme Anthos Service Mesh gérée.

Lorsque vous installez Anthos Service Mesh, les fonctionnalités activées par défaut diffèrent selon la plate-forme. Vous activez les fonctionnalités facultatives en incluant un fichier overlay lorsque vous installez (ou mettez à niveau) Anthos Service Mesh. Un fichier de superposition est un fichier YAML contenant une ressource personnalisée (RP) IstioOperator que vous utilisez pour configurer le plan de contrôle. Vous pouvez ignorer la configuration par défaut et activer une fonctionnalité facultative, ou désactiver une fonctionnalité par défaut dans un fichier de superposition. Spécifiez une fonctionnalité par fichier de superposition. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes.

Attention : L'utilisation de asmcli install écrase la configuration existante du plan de contrôle. Lorsque vous activez les fonctionnalités facultatives pour une installation existante, veillez à spécifier tous les fichiers que vous souhaitez conserver dans la configuration d'origine, ainsi que les fichiers de superposition pour les fonctionnalités que vous souhaitez activer. Nous vous recommandons de stocker les fichiers de superposition que vous utilisez pour l'installation dans le dépôt source afin de pouvoir appliquer les mêmes configurations à votre plan de contrôle avec des mises à niveau ou lors de l'activation de fonctionnalités facultatives supplémentaires.

À propos des fichiers de superposition

Les fichiers de superposition utilisés sur cette page se trouvent dans le package anthos-service-mesh sur 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 Anthos Service Mesh à l'aide du script asmcli fourni par Google, vous pouvez spécifier un ou plusieurs fichiers de superposition avec les options --option ou --custom_overlay. 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.

Important :Ne spécifiez pas plus d'une RS IstioOperator dans un fichier de superposition, car istioctl install n'applique que la première RS qu'il trouve dans le fichier.

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 les autres options de ligne de commande.

Important : L'ordre des fichiers sur la ligne de commande est important. Veillez à spécifier d'abord la configuration requise pour les fonctionnalités par défaut, puis les fichiers de superposition par la suite.

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. Pour obtenir la liste des options, consultez le package anthos-service-mesh.

• 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 les images distroless pour Anthos Service Mesh. 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 Anthos Service Mesh à partir d'un registre de conteneurs personnalisé. Exemple :

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  hub: {private_registry_url}

Vous trouverez ci-dessous la liste des images d'Anthos Service Mesh que vous devez mettre en miroir dans le registre de conteneurs personnalisé :

• Install-cni : gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
• Managed Data Plane : gcr.io/gke-release/asm/mdp:1.14.6-asm.16
• Pilot : gcr.io/gke-release/asm/pilot:1.14.6-asm.16
• Proxyv2 : gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16

Remarque :Si vous utilisez un service canonique, vous devez également mettre en miroir les registres de conteneurs personnalisés gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 et gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16.

Ajouter des images à un registre privé

Pour transférer des images Anthos Service Mesh vers un registre privé, procédez comme suit.

Remarque : Utilisez un client à partir duquel vous pouvez extraire la valeur gcr.io et la transférer vers votre registre privé.

1. Extrayez les images Anthos Service Mesh :

   docker pull gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
   docker pull gcr.io/gke-release/asm/mdp:1.14.6-asm.16
   docker pull gcr.io/gke-release/asm/pilot:1.14.6-asm.16
   docker pull gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
   

2. Créez une variable pour l'URL de votre registre privé :

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   Remplacez PRIVATE_REGISTRY_URL par l'URL de votre registre privé.
3. Ajoutez un tag aux images avec l'URL de votre registre privé :

   docker tag gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
   docker tag gcr.io/gke-release/asm/mdp:1.14.6-asm.16 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16
   docker tag gcr.io/gke-release/asm/pilot:1.14.6-asm.16 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16
   docker tag gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
   

4. Transférez les images taguées vers votre registre privé :

   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
   

5. (Facultatif) Si vous utilisez un service canonique, ajoutez les images canoniques de ce service à votre registre privé.
   1. Extrayez les images du service canonique Anthos Service Mesh:

              docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0
              docker pull gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              

   2. Ajoutez un tag aux images avec l'URL de votre registre privé :

              docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0
              docker tag gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              

   3. Transférez les images taguées vers votre registre privé :

              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/kube-rbac-proxy:v0.5.0
              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              

Si vous pouvez extraire les images taguées de votre registre privé, la procédure a été correctement effectuée.

Diriger Envoy vers stdout

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Pour en savoir plus, consultez la page Activer la journalisation des accès Envoy.

Cloud Trace

Cloud Trace est disponible avec les installations Anthos Service Mesh sur les plates-formes suivantes :

• GKE sur Google Cloud
• Clusters GKE Enterprise sur site si vous les installez avec l'autorité de certification Anthos Service Mesh (Mesh CA)

Pour en savoir plus sur la tarification, consultez la page des tarifs de Cloud Trace.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

Le taux d'échantillonnage par défaut est de 1 %, mais vous pouvez remplacer la valeur par défaut en spécifiant une valeur tracing.sampling. La valeur doit être comprise entre 0 et 100 avec une précision de 0,01. Par exemple, pour tracer cinq requêtes sur 10 000, spécifiez 0,05.

L'exemple suivant montre un taux d'échantillonnage de 100 % (ce qui n'est destiné qu'à des fins de démonstration ou de dépannage).

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
  values:
    global:
      proxy:
        tracer: stackdriver

Notez qu'à l'heure actuelle, la configuration du traceur fait partie de la configuration d'amorçage du proxy. Par conséquent, le pod doit redémarrer et être réinjecté pour récupérer la mise à jour du traceur. Par exemple, vous pouvez utiliser la commande suivante pour redémarrer les pods faisant partie d'un déploiement :

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Propagation du contexte de trace

Même si les proxys side-car peuvent envoyer automatiquement des délais de trace, ils ont besoin d'indications pour relier l'intégralité de la trace. Les applications doivent propager les en-têtes HTTP appropriés de sorte que, lorsque les proxys envoient des informations de délais, ceux-ci soient correctement corrélés en une seule trace.

Pour ce faire, une application doit collecter et propager les en-têtes appropriés de la requête entrante vers les requêtes sortantes : La configuration de traçage Stackdriver d'Anthos Service Mesh accepte l'un des formats d'en-tête suivants et propage tous les formats suivants :

• B3 (x-b3-traceid, x-b3-spanid, x-b3parentspanid, x-b3-sampled, x-b3-flags)
• W3C TraceContext (traceparent)
• Google Cloud Trace (x-cloud-trace-context)
• gRPC TraceBin (grpc-trace-bin)

Cela signifie que vos applications peuvent utiliser n'importe lequel de ces formats pour propager le contexte de traçage, et les traces sont générées et définies de manière appropriée sur Stackdriver.

Exemple

Voici un exemple de requête HTTP-Get avec un en-tête traceparent dans la requête d'origine. Notez les en-têtes de contexte de trace supplémentaires ajoutés par le proxy.

$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
*   Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
  "args": {
    "freeform": ""
  },
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
    "Host": "httpbin:8000",
    "Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
    "User-Agent": "curl/7.80.0-DEV",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "a0c798646d74cef0",
    "X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
    "X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
    "X-Envoy-Attempt-Count": "1",
    "X-Forwarded-Client-Cert": "<REDACTED>"
  },
  "json": null,
  "method": "GET",
  "origin": "127.0.0.6",
  "url": "http://httpbin:8000/anything?freeform="
}

Notez que l'ensemble complet d'en-têtes de contexte de trace est présent dans l'ensemble d'en-têtes de requête renvoyé.

Pour obtenir davantage d'exemples de propagation des en-têtes, consultez la page Propagation du contexte de trace.

Créer une trace à partir d'un client avec un ID personnalisé

Pour créer une trace à partir d'un client avec un ID personnalisé, utilisez la commande curl pour créer une requête avec un client externe et l'obliger à afficher une trace. Exemple :

curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"

Pour plus d'informations sur x-client-trace-id, reportez-vous à la documentation d'Envoy.

Remarque : Si vous testez les conteneurs side-car d'Anthos Service Mesh qui envoient des données Cloud Trace à l'aide de la démonstration microservices-demo de Google, veillez à désactiver la fonctionnalité intégrée Cloud Trace. La démonstration microservices-demo est capable d'envoyer des données Cloud Trace sans Istio. Si vous ne désactivez pas cette fonctionnalité, des traces en double sont créées, car le conteneur d'application et le conteneur side-car envoient tous deux des traces. Vous devez configurer plusieurs variables DISABLE_TRACING dans le fichier de release microservices-demo.

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 procédure d'activation de l'interface CNI (Container Network Interface) d'Istio dépend de l'environnement sur lequel Anthos Service Mesh est installé.

1. Activer une règle de réseau

2. Choisissez le fichier de superposition qui correspond à votre plate-forme.

Activer CNI sur GKE

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /home/kubernetes/bin
      excludeNamespaces:
        - istio-system
        - kube-system

Activer CNI sur site

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /opt/cni/bin
      excludeNamespaces:
        - istio-system
        - kube-system
        - gke-system

Activer l'observabilité Google Cloud en dehors de Google Cloud

L'installation d'Anthos Service Mesh avec l'autorité de certification Istio en dehors de Google Cloud entraîne par défaut la transmission des métriques à Prometheus. Utilisez cette option pour activer la création de rapports sur les métriques pour l'observabilité Google Cloud, ou à la fois pour Prometheus et Stackdriver, afin de pouvoir utiliser les tableaux de bord Anthos Service Mesh.

Stackdriver exclusivement

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: false
        stackdriver:
          enabled: true

Stackdriver et Prometheus

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
        stackdriver:
          enabled: true

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.