Intégrer des charges de travail Kubernetes
Cette page explique comment intégrer des charges de travail Kubernetes avec Cloud Service Mesh.
Déployer des services Kubernetes
Pour déployer des services Kubernetes sur des clusters avec Cloud Service Mesh, procédez comme suit:
Créer des services Kubernetes pour tous les conteneurs Tous les déploiements doivent être associés à un service Kubernetes.
Nommez les ports de service. Bien que GKE vous permette de définir des ports de service sans nom, Cloud Service Mesh nécessite que vous fournissiez un nom pour un port qui correspond au protocole du port.
Ajoutez des étiquettes à vos déploiements. Cela vous permet d'utiliser les fonctionnalités de gestion du trafic de Cloud Service Mesh, telles que la répartition du trafic entre les versions d'un même service.
Les exemples de déploiement et de service suivants illustrent ces exigences:
Après avoir déployé vos services sur un cluster avec Cloud Service Mesh, veillez à injecter des proxys side-car.
Exemple: Déployer l'exemple Boutique en ligne
L'exemple d'application Online Boutique du dépôt anthos-service-mesh-packages
est modifié à partir de l'ensemble de fichiers manifestes d'origine du dépôt microservices-demo
. Conformément aux bonnes pratiques, chaque service est déployé dans un espace de noms distinct avec un compte de service unique.
Créez les espaces de noms pour l'application :
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces
Résultat attendu :
namespace/ad created namespace/cart created namespace/checkout created namespace/currency created namespace/email created namespace/frontend created namespace/loadgenerator created namespace/payment created namespace/product-catalog created namespace/recommendation created namespace/shipping created
Activez l'injection side-car automatique (injection automatique). Cette commande est différente selon que vous utilisez Cloud Service Mesh géré ou dans le cluster Cloud Service Mesh au sein du cluster. Si vous utilisez le service Cloud Service Mesh géré, utilisez les étiquettes d'injection par défaut (par exemple,
istio-injection=enabled
). Si vous utilisez Cloud Service Mesh dans le cluster, utilisez la même étiquette de révision que celle que vous avez utilisée pour annoter l'espace de noms de la passerelle d'entrée. Notez que les clients existants du plan de contrôle géré qui ont été migrés peuvent également utiliser leurs libellés de révision existants en plus de l'étiquette d'injection par défaut.Libellés d'injection par défaut
Appliquez les libellés d'injection par défaut à l'espace de noms. Dans la commande suivante, GATEWAY_NAMESPACE est la même valeur que celle que vous avez utilisée pour annoter l'espace de noms de la passerelle d'entrée.
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns istio-injection=enabled istio.io/rev- done;
Résultat attendu :
namespace/ad labeled namespace/cart labeled namespace/checkout labeled namespace/currency labeled namespace/email labeled namespace/frontend labeled namespace/loadgenerator labeled namespace/payment labeled namespace/product-catalog labeled namespace/recommendation labeled namespace/shipping labeled
Libellé de révision
Appliquez le libellé de révision aux espaces de noms de l'application. Dans la commande suivante, REVISION est la même valeur que celle que vous avez utilisée pour annoter l'espace de noms de la passerelle d'entrée.
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns istio.io/rev=REVISION --overwrite done;
Résultat attendu :
namespace/ad labeled namespace/cart labeled namespace/checkout labeled namespace/currency labeled namespace/email labeled namespace/frontend labeled namespace/loadgenerator labeled namespace/payment labeled namespace/product-catalog labeled namespace/recommendation labeled namespace/shipping labeled
Déployez l'exemple d'application sur le cluster.
Créez les comptes de service et les déploiements :
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments
Résultat attendu :
serviceaccount/ad created deployment.apps/adservice created serviceaccount/cart created deployment.apps/cartservice created serviceaccount/checkout created deployment.apps/checkoutservice created serviceaccount/currency created deployment.apps/currencyservice created serviceaccount/email created deployment.apps/emailservice created serviceaccount/frontend created deployment.apps/frontend created serviceaccount/loadgenerator created deployment.apps/loadgenerator created serviceaccount/payment created deployment.apps/paymentservice created serviceaccount/product-catalog created deployment.apps/productcatalogservice created serviceaccount/recommendation created deployment.apps/recommendationservice created serviceaccount/shipping created deployment.apps/shippingservice created
Créez les services :
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/services
Résultat attendu :
service/adservice created service/cartservice created service/checkoutservice created service/currencyservice created service/emailservice created service/frontend created service/frontend-external created service/paymentservice created service/productcatalogservice created service/recommendationservice created service/shippingservice created
Créez les entrées de service :
kubectl apply -f \ DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml
Résultat attendu :
serviceentry.networking.istio.io/allow-egress-googleapis created serviceentry.networking.istio.io/allow-egress-google-metadata created
Nommer les ports de service
Pour être inclus dans Cloud Service Mesh, les ports de service doivent être nommés et inclure le protocole du port, par exemple:
apiVersion: v1 kind: Service metadata: name: ratings labels: app: ratings service: ratings spec: ports: - port: 9080 name: http
Le nom du port de service peut inclure un suffixe dans la syntaxe suivante : name: protocol[-suffix]
, où les crochets indiquent un suffixe facultatif qui doit commencer par un tiret, par exemple :
kind: Service metadata: name: myservice spec: ports: - number: 3306 name: mysql - number: 80 name: http-web
Pour que les métriques soient affichées dans la console Google Cloud, les ports de service doivent être nommés avec l'un des protocoles suivants: http
, http2
ou grpc
.
Les ports de service nommés avec le protocole https
sont traités comme tcp
, et les métriques ne sont pas affichées pour ces services.
Injecter des proxys side-car
Cette section explique comment configurer l'injection du proxy side-car avec Cloud Service Mesh afin d'améliorer la sécurité, la fiabilité et l'observabilité du réseau. Ces fonctions sont extraites du conteneur principal de l'application et mises en œuvre dans un proxy commun hors processus (le side-car), distribué sous la forme d'un conteneur distinct dans le même pod. Vous pouvez utiliser les fonctionnalités de Cloud Service Mesh sans avoir à repenser vos applications de production pour participer à un maillage de services.
L'injection automatique du proxy side-car (injection automatique) se produit lorsque Cloud Service Mesh détecte une étiquette d'espace de noms que vous configurez pour le pod de la charge de travail. Le proxy intercepte tout le trafic entrant et sortant vers les charges de travail et communique avec Cloud Service Mesh.
Activer l'injection side-car automatique
Activez l'espace de noms pour l'injection : Les étapes dépendent de la mise en œuvre du plan de contrôle.
Géré (TD)
- Appliquez l'étiquette d'injection par défaut à l'espace de noms:
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
Géré (Istiod)
Recommandé:Exécutez la commande suivante pour appliquer l'étiquette d'injection par défaut à l'espace de noms:
kubectl label namespace NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Si vous êtes un utilisateur existant disposant du plan de contrôle Istiod géré:nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est compatible. Pour ce faire, procédez comme suit:
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-rapid 6d7h
REMARQUE: Si deux révisions du plan de contrôle figurent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans le cluster.
Dans le résultat, la valeur figurant dans la colonne
NAME
correspond au libellé de révision qui correspond à la version disponible disponible pour la version de Cloud Service Mesh.Appliquez le libellé de révision à l'espace de noms.
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Dans le cluster
Recommandé:Exécutez la commande suivante pour appliquer l'étiquette d'injection par défaut à l'espace de noms:
kubectl label namespace NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est compatible: Suivez les instructions ci-dessous:
Exécutez la commande suivante pour localiser le libellé de révision sur
istiod
:kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
Appliquez le libellé de révision à l'espace de noms. Dans la commande suivante,
REVISION_LABEL
correspond à la valeur du libellé de révisionistiod
que vous avez notée à l'étape précédente.kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Redémarrez les pods concernés en suivant la procédure décrite dans la section suivante.
Annotez l'espace de noms
demo
comme suit:kubectl annotate --overwrite namespace NAMESPACE \ mesh.cloud.google.com/proxy='{"managed":"true"}'
Redémarrer les pods pour mettre à jour les proxys side-car
Avec l'injection automatique de side-car, vous pouvez mettre à jour les side-cars pour les pods existants avec un redémarrage du pod :
Le redémarrage des pods varie selon qu'ils ont ou non été créés dans le cadre d'un déploiement.
Si vous avez utilisé un déploiement, redémarrez le déploiement pour redémarrer tous les pods avec des side-cars :
kubectl rollout restart deployment -n NAMESPACE
Si vous n'avez pas utilisé de déploiement, supprimez les pods. Ils sont automatiquement recréés avec les side-cars :
kubectl delete pod -n NAMESPACE --all
Vérifiez que tous les pods de l'espace de noms disposent de side-cars injectés :
kubectl get pod -n NAMESPACE
Dans l'exemple de résultat suivant de la commande précédente, la colonne
READY
indique qu'il existe deux conteneurs pour chacune de vos charges de travail : le conteneur principal et le conteneur du proxy side-car.NAME READY STATUS RESTARTS AGE WORKLOAD 2/2 Running 0 20s ...