Installer et mettre à niveau des passerelles
Anthos Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé recevant des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé. Les passerelles sont principalement utilisées pour gérer le trafic entrant, mais vous pouvez également les configurer pour gérer d'autres types de trafic. Exemple :
Passerelles de sortie : une passerelle de sortie vous permet de configurer un nœud de sortie dédié au trafic quittant le maillage, ce qui vous permet de limiter les services qui peuvent ou doivent accéder aux réseaux externes ou d'activer le contrôle sécurisé du trafic de sortie à ajouter la sécurité de votre réseau maillé, par exemple.
Passerelles est-ouest : proxy pour le trafic est-ouest permettant aux charges de travail de service de communiquer au-delà des limites des clusters dans un réseau maillé principal sur différents réseaux. Par défaut, cette passerelle est publique sur Internet.
Cette page décrit les bonnes pratiques pour déployer et mettre à niveau les proxys de passerelle, ainsi que des exemples de configuration de vos propres proxys de passerelle istio-ingressgateway
et istio-egressgateway
.
Il est possible d'appliquer des configurations telles que la répartition du trafic, les redirections et la logique de nouvelle tentative en appliquant une configuration de passerelle aux proxys de passerelle. Ensuite, au lieu d'ajouter le routage du trafic de couche d'application (L7) à la même ressource API, vous associez un service virtuel à la passerelle. Cela vous permet de gérer le trafic de la passerelle comme n'importe quel autre trafic de plan de données dans le maillage de services.
Vous pouvez déployer les passerelles de différentes manières. Vous pouvez également choisir d'utiliser plusieurs topologies au sein du même cluster. Reportez-vous à la page Topologies de déploiement de passerelle dans la documentation d'Istio pour en savoir plus sur ces topologies.
Bonnes pratiques pour le déploiement de passerelles
Les bonnes pratiques de déploiement de passerelles varient selon que vous utilisez le plan de données géré ou le plan de données non géré.
Bonnes pratiques pour le plan de données géré
- Activez le plan de données géré.
- Ajoutez un libellé de révision géré à un espace de noms.
- Déployer et gérer le plan de contrôle et les passerelles séparément.
- Pour respecter nos bonnes pratiques de sécurité, nous vous recommandons de déployer les passerelles dans un espace de noms différent du plan de contrôle.
- Injectez de la configuration proxy pour les passerelles à l'aide de l'injection side-car automatique (injection automatique) comme vous l'utilisez pour injecter les proxys side-car pour vos services.
Ces bonnes pratiques :
- assurent que vos passerelles gérées sont automatiquement à jour avec les dernières améliorations et les dernières mises à jour de sécurité ;
- déchargent la gestion et la maintenance des instances de passerelle vers le plan de données géré par Anthos Service Mesh.
Bonnes pratiques pour le plan de données non géré
- Déployer et gérer le plan de contrôle et les passerelles séparément.
- Pour respecter nos bonnes pratiques de sécurité, nous vous recommandons de déployer les passerelles dans un espace de noms différent du plan de contrôle.
- Injectez de la configuration proxy pour les passerelles à l'aide de l'injection side-car automatique (injection automatique) comme vous l'utilisez pour injecter les proxys side-car pour vos services.
Ces bonnes pratiques :
- Laissez les administrateurs de vos espaces de noms gérer les passerelles sans avoir à élever les privilèges pour l'ensemble du cluster.
- Laissez vos administrateurs utiliser les mêmes outils ou mécanismes de déploiement que ceux utilisés pour gérer les applications Kubernetes afin de déployer et de gérer des passerelles.
- donnent aux administrateurs un contrôle total sur le déploiement de la passerelle et simplifiez les opérations. Lorsqu'une nouvelle mise à niveau est disponible ou qu'une configuration est modifiée, les administrateurs mettent à jour les pods de passerelle simplement en les redémarrant. Ainsi, l'opération de déploiement de passerelle est semblable à l'utilisation de proxys side-car pour vos services.
Déployer des passerelles
Pour prendre en charge les utilisateurs avec des outils de déploiement existants, Anthos Service Mesh accepte les mêmes méthodes pour déployer une passerelle que Istio : IstioOperator
, Helm et Kubernetes YAML. Chaque méthode produit le même résultat. Bien que vous puissiez choisir la méthode que vous connaissez le mieux, nous vous recommandons d'utiliser la méthode YAML de Kubernetes, car elle est plus facile à modifier et vous pouvez stocker des fichiers manifestes hydratés dans un contrôle de source.
Créez un espace de noms pour la passerelle si vous n'en possédez pas déjà un. Remplacez
GATEWAY_NAMESPACE
par le nom de votre espace de noms.kubectl create namespace GATEWAY_NAMESPACE
Pour activer l'injection automatique, vous devez ajouter un libellé à vos espaces de noms en utilisant les libellés d'injection par défaut, si le tag par défaut est configuré, ou bien le libellé de révision. Le libellé que vous ajoutez varie selon que vous avez déployé Anthos Service Mesh géré ou que vous avez installé le plan de contrôle intégré au cluster. Le libellé est utilisé par le webhook d'injecteur side-car pour associer les side-cars injectés à une révision spécifique du plan de contrôle.
Sélectionnez l'onglet ci-dessous en fonction de votre type d'installation (gérée ou dans le cluster).
Géré
Exécutez la commande suivante pour localiser les versions disponibles :
kubectl -n istio-system get controlplanerevision
Le résultat ressemble à ce qui suit :
NAME AGE asm-managed 6d7h asm-managed-rapid 6d7h
Dans le résultat, la valeur de la colonne
NAME
est le libellé de révision qui correspond à la version disponible pour la version d'Anthos Service Mesh.Dans le cluster
Pour les plans de contrôle au sein du cluster, le service et le déploiement
istiod
ont un libellé de révision semblable àistio.io/rev=asm-1139-10
, oùasm-1139-10
identifie la version d'Anthos Service Mesh. La révision fait partie du nom du serviceistiod
, par exemple,istiod-asm-1139-10.istio-system
.Utilisez la commande suivante pour localiser le libellé de révision sur
istiod
pour le plan de contrôle du cluster :kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
Activez l'espace de noms pour l'injection : Remplacez
REVISION
par la valeur du libellé de révision.kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
Si vous avez installé Anthos Service Mesh à l'aide de
asmcli
, accédez au répertoire que vous avez spécifié dans--output_dir
, puis àcd
dans le répertoiresamples
.Si vous n'avez pas installé l'outil à l'aide de
asmcli
, copiez les fichiers de configuration des passerelles à partir du dépôtanthos-service-mesh
.Vous pouvez déployer l'exemple de configuration de passerelle situé dans le répertoire
samples/gateways/
ou le modifier si nécessaire.Entrée
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
Sortie
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
Après avoir créé le déploiement, vérifiez que les nouveaux services fonctionnent correctement :
kubectl get pod,service -n GATEWAY_NAMESPACE
Le résultat ressemble à ce qui suit :
NAME READY STATUS RESTARTS AGE pod/istio-ingressgateway-856b7c77-bdb77 1/1 Running 0 3s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istio-ingressgateway LoadBalancer 10.24.5.129 34.82.157.6 80:31904/TCP 3s
Sélecteurs de passerelle
Vous appliquez une configuration Gateway aux proxys istio-ingressgateway
et istio-egressgateway
pour gérer le trafic entrant et sortant de votre maillage, ce qui vous permet de spécifier quel trafic peut entrer ou quitter le réseau maillé. Les libellés des pods d'un déploiement de passerelle sont utilisés par les ressources de configuration de passerelle. Il est donc important que le sélecteur de passerelle corresponde à ces libellés.
Par exemple, dans les déploiements ci-dessus, le libellé istio=ingressgateway
est défini sur les pods de la passerelle. Pour appliquer une configuration de passerelle à ces déploiements, vous devez sélectionner le même libellé :
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: gateway
spec:
selector:
istio: ingressgateway
...
Pour obtenir un exemple de configuration de passerelle et de service virtuel, consultez le fichier frontend.yaml dans l'exemple d'application Boutique en ligne.
Mettre à niveau les passerelles
Mises à niveau sur place
Dans la plupart des cas d'utilisation, vous devez mettre à niveau vos passerelles en suivant le modèle de mise à niveau sur place. Comme les passerelles utilisent l'injection de pods, les nouveaux pods de passerelle créés sont automatiquement injectés avec la dernière configuration, qui inclut la version.
Si vous souhaitez modifier la révision du plan de contrôle utilisée par la passerelle, vous pouvez définir le libellé istio.io/rev sur le déploiement de la passerelle, ce qui déclenchera également un redémarrage progressif.
Plan de contrôle géré
Étant donné que Google gère les mises à niveau du plan de contrôle pour le plan de contrôle géré, vous pouvez simplement redémarrer le déploiement de la passerelle pour que les nouveaux pods soient automatiquement injectés avec la dernière configuration et la dernière version.
kubectl rollout restart deployment istio-ingressgateway \
-n GATEWAY_NAMESPACE
Plan de contrôle dans le cluster
Pour appliquer le même schéma à vos passerelles lorsque vous disposez du plan de contrôle dans le cluster, vous devez modifier la révision du plan de contrôle utilisée par la passerelle.
Définissez le libellé istio.io/rev
sur le déploiement de passerelle afin de déclencher un redémarrage progressif.
- Mettez à jour le libellé de révision sur l'espace de noms ou sur le pod de la passerelle.
- Si vous avez attribué un libellé à l'espace de noms pour l'injection :
- Définissez le libellé istio.io/rev sur l'espace de noms sur la nouvelle valeur de révision.
kubectl label namespace GATEWAY_NAMESPACE \
istio-injection- istio.io/rev=REVISION \
--overwrite
OU
- Si vous avez activé l'injection uniquement pour le pod de la passerelle :
- Définissez le libellé istio.io/rev sur le déploiement sur la nouvelle valeur de révision.
- Kubernetes YAML
- Définissez le libellé istio.io/rev sur le déploiement sur la nouvelle valeur de révision.
cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: istio-ingressgateway
namespace: GATEWAY_NAMESPACE
spec:
selector:
matchLabels:
istio: ingressgateway
template:
metadata:
annotations:
# This is required to tell Anthos Service Mesh to inject the gateway with the
# required configuration.
inject.istio.io/templates: gateway
labels:
istio: ingressgateway
istio.io/rev: REVISION
spec:
containers:
- name: istio-proxy
image: auto # The image will automatically update each time the pod starts.
EOF
kubectl apply -f gateway-deployment.yaml
Mises à niveau Canary (avancé)
Si vous utilisez le plan de contrôle au sein du cluster et que vous souhaitez contrôler plus lentement le déploiement d'une nouvelle révision de plan de contrôle, vous pouvez suivre le modèle de mise à niveau Canary. Vous pouvez exécuter plusieurs versions d'un déploiement de passerelle et vous assurer que tout fonctionne comme prévu avec un sous-ensemble de votre trafic. Par exemple, si vous souhaitez déployer une nouvelle révision, Canary, créez une copie du déploiement de votre passerelle en définissant le libellé istio.io/rev=REVISION
sur la nouvelle révision et un nouveau nom, par exemple istio-ingressgateway-canary
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: istio-ingressgateway-canary
namespace: GATEWAY_NAMESPACE
spec:
selector:
matchLabels:
istio: ingressgateway
template:
metadata:
annotations:
inject.istio.io/templates: gateway
labels:
istio: ingressgateway
istio.io/rev: REVISION # Set to the control plane revision you want to deploy
spec:
containers:
- name: istio-proxy
image: auto
Lorsque ce déploiement est créé, vous disposez de deux versions de la passerelle, toutes deux sélectionnées par le même service :
kubectl get endpoints -o
"custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"
NAME PODS
istio-ingressgateway istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf
Si vous êtes certain que vos applications fonctionnent comme prévu, exécutez la commande suivante pour passer à la nouvelle version en supprimant le déploiement avec l'ancien ensemble de libellés istio.io/rev :
kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE
Si vous avez rencontré un problème lors du test de votre application avec la nouvelle version de la passerelle, exécutez cette commande pour revenir à l'ancienne version en supprimant le déploiement avec le nouvel ensemble de libellés istio.io/rev :
kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE
Résoudre les problèmes liés aux passerelles
Échec de la mise à jour de l'image de passerelle depuis auto
Lorsque vous déployez ou mettez à niveau une passerelle, Anthos Service Mesh insère auto
en tant qu'espace réservé dans le champ image
. Après l'appel de la mutation du webhook, Anthos Service Mesh remplace automatiquement cet espace réservé par l'image du proxy Anthos Service Mesh réelle. Si l'appel du webhook en mutation échoue, l'espace réservé auto
est conservé, et le conteneur est introuvable. Cela est généralement dû à un libellé d'espace de noms incorrect. Assurez-vous d'avoir configuré le bon espace de noms, puis déployez ou mettez à niveau la passerelle à nouveau.