Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Options de configuration des pods Google Kubernetes Engine avec injection Envoy automatique

Ce guide fournit des informations sur les options et les tâches supplémentaires associées à l'injecteur side-car Envoy automatique.

Ajouter des proxys side-car aux charges de travail existantes

Une fois que vous avez installé l'injecteur side-car sur vos clusters, les proxys side-car sont automatiquement injectés dans des pods créés dans les espaces de noms activés. Si des charges de travail sont déjà en cours d'exécution avant l'activation de l'injecteur side-car, vous devez les redémarrer pour que l'injection aboutisse.

Pour les pods gérés par un objet Deployment, DaemonSet ou StatefulSet, vous pouvez exécuter la commande suivante :

# Deployment
kubectl rollout restart deployment/DEPLOYMENT_NAME --namespace NAMESPACE

# DaemonSet
kubectl rollout restart daemonset/DAEMONSET_NAME --namespace NAMESPACE

# StatefulSet
kubectl rollout restart statefulset/STATEFULSET_NAME --namespace NAMESPACE

Si vous n'avez utilisé aucun des contrôleurs ci-dessus pour déployer vos pods, vous devez les supprimer individuellement. Ils sont ensuite automatiquement recréés avec de nouveaux proxys side-car.

kubectl delete pod POD_NAME -n NAMESPACE

Vérifiez qu'un conteneur de proxy side-car a été injecté dans chacun de vos pods :

kubectl get pods -n NAMESPACE

Par exemple, avec le client Busybox créé ci-dessus, vous devriez voir 2/2 pods en cours d'exécution, un pour l'application Busybox elle-même et un pour le proxy side-car Envoy injecté :

NAME                      READY   STATUS    RESTARTS   AGE
busybox-c54f578c9-c9fk4   2/2     Running   183        7d15h

Remplacement d'injection

Par défaut, l'activation d'un espace de noms active l'injection du proxy side-car pour tous les pods résidents. L'injection peut également être configurée de manière sélective pour différents champs d'application afin de répondre à des besoins spécifiques. Par exemple, des valeurs de remplacement doivent être utilisées pour éviter l'injection de proxy side-car pour les services gRPC sans proxy.

Notez que les remplacements d'injection ne s'appliquent que lorsque l'espace de noms est activé et qu'ils prennent effet selon la priorité suivante : Annotations de pod > NeverInjectSelector > AlwaysInjectSelector > Règle par défaut

Activer/Désactiver l'injection pour des pods individuels spécifiques

Utilisez l'annotation de pod suivante pour activer ou désactiver l'injection d'un pod spécifique dans un espace de noms activé :

...
metadata:
  annotations:
    sidecar.istio.io/inject: "true" / "false"

Activer/Désactiver l'injection de groupes de pods spécifiques

L'injecteur side-car peut être configuré pour toujours ou ne jamais injecter des pods dans les espaces de noms activés en fonction d'un tableau de sélecteurs de libellés Kubernetes. Par exemple, utilisez les commandes suivantes pour configurer l'injecteur side-car pour ne pas injecter de proxy side-car si le pod possède le libellé "run=client" :

kubectl edit configmap -n istio-control istio-sidecar-injector

...
config: |-
  policy: enabled
  alwaysInjectSelector:
    []

  neverInjectSelector:
    - matchLabels:
        run: client
...

Les déploiements d'injecteurs side-car existants doivent être redémarrés pour que cette configuration prenne effet.

Personnaliser le comportement d'interception du trafic

Par défaut, tout le trafic sortant de votre application est intercepté et redirigé vers le proxy side-car Envoy. Le proxy Envoy peut ensuite gérer le trafic en suivant les instructions reçues de Cloud Service Mesh. Dans certains cas, vous pouvez modifier ce comportement pour contourner le proxy side-car.

Utilisez les annotations de pod suivantes pour exclure le trafic de l'interception et de la redirection.

Exclure de l'interception par plage d'adresses IP sortantes

Vous pouvez exclure le trafic de toute interception par plage d'adresses IP.

...
metadata:
  annotations:
    cloud.google.com/excludeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"

L'annotation de pod cloud.google.com/excludeOutboundCIDRs est une liste de plages d'adresses IP sortantes au format CIDR séparées par une virgule. Le trafic de sortie destiné à ces plages d'adresses IP n'est pas redirigé vers le side-car Envoy.

Notez que vous devez répertorier 169.254.169.254/32 dans l'annotation de pod pour vous assurer que les applications peuvent communiquer avec le serveur de métadonnées. Si vous ne spécifiez pas l'annotation de pod cloud.google.com/excludeOutboundCIDRs, l'interception du trafic est configurée pour exclure la plage CIDR sortante "169.254.169.254/32".

Inclure dans l'interception par la plage d'adresses IP sortantes

Vous pouvez inclure le trafic dans l'interception par plage d'adresses IP.

...
metadata:
  annotations:
    cloud.google.com/includeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"

L'annotation de pod cloud.google.com/includeOutboundCIDRs est une liste de plages d'adresses IP sortantes au format CIDR séparées par une virgule. Le trafic de sortie destiné à ces plages d'adresses IP sont redirigées vers le side-car Envoy.

Le caractère générique * peut être utilisé pour rediriger tout le trafic sortant. Une zone vide désactive tout le trafic sortant. La valeur par défaut de l'annotation est *.

Exclure de l'interception par numéro de port sortant

Vous pouvez exclure le trafic de l'interception et de la redirection par numéro de port sortant.

...
metadata:
  annotations:
    cloud.google.com/excludeOutboundPorts: "10001, 10002"

L'annotation de pod cloud.google.com/excludeOutboundPorts est une liste de ports sortants séparés par une virgule. Le trafic de sortie destiné à ces ports est exclu de l'interception et de la redirection vers le side-car Envoy.

Si vous ne spécifiez pas l'annotation cloud.google.com/excludeOutboundPorts, le trafic sortant destiné à n'importe quel port est intercepté et redirigé vers le side-car Envoy. Cela équivaut à transmettre l'annotation cloud.google.com/excludeOutboundPorts avec une liste vide ("").

Inclure dans l’interception par le numéro de port entrant

Vous pouvez inclure le trafic dans l'interception par numéro de port entrant.

...
metadata:
  annotations:
    cloud.google.com/includeInboundPorts: "10001, 10002"

L'annotation de pod cloud.google.com/includeInboundPorts est une liste de ports entrants séparés par une virgule pour lesquels le trafic doit être redirigé vers le sidecar Envoy. Le caractère générique * peut être utilisé pour configurer la redirection pour tous les ports. Une valeur vide désactive toutes les redirections entrantes. La valeur par défaut est une chaîne vide ("").

Exclure de l'interception par numéro de port entrant

Vous pouvez exclure le trafic de l'interception par numéro de port entrant.

...
metadata:
  annotations:
    cloud.google.com/excludeInboundPorts: "10001, 10002"

L'annotation de pod cloud.google.com/excludeInboundPorts est une liste de ports entrants séparés par une virgule à exclure de la redirection vers le sidecar Envoy. La ne s'applique que lorsque tout le trafic entrant (*) est redirigé. La valeur par défaut est une chaîne vide ("").

Activer les certificats gérés

Vous pouvez activer les certificats de charge de travail gérée.

...
metadata:
  annotations:
    cloud.google.com/enableManagedCerts: "true"

Lorsque l'annotation cloud.google.com/enableManagedCerts du pod est définie sur true, les certificats de charge de travail gérés par GKE signés par le service d'autorité de certification sont insérés et installés sur le conteneur sidecar. La valeur de l'annotation est définie par défaut sur false.

Configurer les métadonnées du proxy side-car

Pour prendre en charge d'autres fonctionnalités de Cloud Service Mesh, les proxys side-car peuvent hériter des métadonnées spécifiques à partir de leurs pods d'encapsulation. Pour ce faire, vous disposez de deux méthodes. Les deux options permettent d'ajouter des métadonnées et de les partager avec Cloud Service Mesh lorsque le proxy side-car se connecte à Cloud Service Mesh. Les options s'excluent mutuellement.

La première option vous permet de spécifier des paires clé/valeur de métadonnées individuelles. Par exemple, incluez l'annotation suivante dans la spécification de votre modèle de pod pour appliquer le libellé "version": "dev" à ses proxys side-car injectés.

...
metadata:
  annotations:
    cloud.google.com/proxyMetadata: '{"version": "dev"}'

La deuxième option ajoute tous les libellés du pod au proxy side-car injecté du pod.

...
metadata:
  annotations:
    cloud.google.com/forwardPodLabels: "true"

Si vous ne spécifiez pas l'annotation cloud.google.com/forwardPodLabels, les libellés de pod ne sont pas ajoutés au proxy side-car. Notez que les annotations cloud.google.com/proxyMetadata et cloud.google.com/forwardPodLabels s'excluent mutuellement. Si vous définissez les deux, cloud.google.com/forwardPodLabels est prioritaire et cloud.google.com/proxyMetadata est ignoré.

Le filtrage des configurations permet ensuite à Cloud Service Mesh de partager un sous-ensemble de configurations seulement avec les proxys spécifiques correspondant à ce libellé "version": "dev".

Pour que cette configuration prenne effet, vous devez redémarrer les déploiements existants.

Annotations de pod compatibles

Cloud Service Mesh accepte les annotations de pod suivantes pour l'injection side-car. Bien que d'autres annotations d'injecteur side-car puissent fonctionner, la liste suivante décrit les annotations compatibles avec Cloud Service Mesh. Pour éviter les risques de faille ou d'instabilité, ne créez pas de dépendances sur d'autres annotations dans votre déploiement en production.

Nom de l'annotation	Value	Description
sidecar.istio.io/inject	Valeur booléenne, représentée sous forme de chaîne. Exemple : "`true`"	Indique si un side-car Envoy doit être automatiquement injecté dans la charge de travail.
cloud.google.com/proxyMetadata	Carte JSON des paires clé/valeur. Exemple : "`'{"version": "dev"}'`"	Spécifie les paires clé/valeur dans une carte JSON à ajouter aux métadonnées Envoy.
cloud.google.com/forwardPodLabels	"true" ou "false"	Si la valeur est "true", tous les libellés de pod sont ajoutés aux métadonnées Envoy, et l'annotation "cloud.google.com/proxyMetadata" est ignorée. La valeur par défaut est "false".
cloud.google.com/excludeOutboundPorts	Liste de ports sortants séparés par une virgule	Le trafic de sortie qui indique que l'un de ces ports de destination est exclu de l'interception/de la redirection vers le side-car Envoy. Ce trafic va contournent le proxy Envoy et ne sont pas traités conformément à Cloud Service Mesh configuration. La valeur par défaut est une chaîne vide (par exemple "").
cloud.google.com/includeInboundPorts	Liste de ports entrants séparés par une virgule	Liste de ports entrants séparés par une virgule pour lesquels le trafic est redirigé vers le side-car Envoy. Utilisez le caractère générique "*" pour configurer la redirection pour tous les ports. Une valeur vide désactive tout redirection entrante. La valeur par défaut est une chaîne vide ("").
cloud.google.com/excludeInboundPorts	Liste de ports entrants séparés par une virgule	Liste de ports entrants séparés par une virgule pour lesquels le trafic n'est pas redirigé vers le side-car Envoy. L'annotation ne s'applique que lorsque tout le trafic entrant (*) est redirigé. La valeur par défaut en une chaîne vide ("").
cloud.google.com/excludeOutboundCIDRs	Liste des plages d'adresses IP sortantes, séparées par une virgule, au format CIDR	Le trafic de sortie indiquant que l'une de ces adresses IP de destination est exclue de l'interception/de la redirection vers le side-car Envoy. Ce trafic va contournent le proxy Envoy et ne sont pas traités conformément à Cloud Service Mesh configuration. La valeur par défaut est "169.254.169.254/32", qui correspond à la plage requise pour communiquer avec le serveur de métadonnées. Notez que cette plage est obligatoire. Par conséquent, si vous spécifiez l'annotation "excludeOutboundCIDRs", veillez à inclure également "169.254.169.254/32" en plus des autres CIDR. Vérifiez que la liste ne contient pas d'espaces.
cloud.google.com/includeOutboundCIDRs	Liste des plages d'adresses IP sortantes, séparées par une virgule, au format CIDR	Le trafic de sortie indiquant que l'une de ces adresses IP de destination est incluse en cas d'interception ou de redirection vers le side-car Envoy. Ce trafic est est dirigée vers le proxy Envoy et est gérée par Cloud Service Mesh configuration. La valeur par défaut est "169.254.169.254/32", qui correspond à la plage requise pour communiquer avec le serveur de métadonnées. Notez que cette plage est obligatoire. si vous spécifiez l'annotation "includeMissingCIDRs", assurez-vous également inclure "169.254.169.254/32" en plus de tout autre CIDR. Vérifiez que la liste ne contient pas d'espaces.
cloud.google.com/enableManagedCerts	Valeur booléenne, représentée sous forme de chaîne. Exemple : "`true`"	Lorsque la valeur est "`true`", les certificats de charge de travail gérée GKE signés par Certificate Authority Service sont insérés et installés sur le conteneur sidecar. La valeur par défaut est "`false`".

Désinstaller l'injecteur side-car

Désinstallez l'injecteur side-car à l'aide des commandes suivantes :

kubectl delete -f specs/
kubectl label namespace default istio-injection-