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.
Attribuez un nom à vos 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 correspondant au protocole du port.
Ajoutez des étiquettes à vos déploiements. Cela vous permet d'utiliser le trafic Cloud Service Mesh de gestion centralisée, comme la répartition du trafic entre les versions d'une même Google Cloud.
L'exemple de déploiement et de service suivant illustre 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 de 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 dans le dépôt microservices-demo
. Conformément aux bonnes pratiques, chaque service est déployé dans un bucket
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 les espaces de noms pour l'injection : La procédure dépend de votre implémentation du plan de contrôle.
Géré (TD)
Appliquez l'étiquette d'injection par défaut à l'espace de noms:
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio.io/rev- istio-injection=enabled --overwrite done;
Géré (Istiod)
Recommandation : Exécutez la commande suivante pour appliquer le libellé d'injection par défaut à l'espace de noms :
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio.io/rev- istio-injection=enabled --overwrite done;
Si vous êtes déjà un utilisateur du plan de contrôle Istio géré : nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est prise en charge. Suivez les instructions suivantes :
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
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.
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;
Dans le cluster
Recommandation : Exécutez la commande suivante pour appliquer le libellé d'injection par défaut à l'espace de noms :
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio.io/rev- istio-injection=enabled --overwrite done;
Nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est prise en charge : suivez les instructions suivantes :
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.for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;
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 le nom doit incluez 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 pour améliorer la sécurité, la fiabilité et l'observabilité. Ces fonctions sont extraites de la couche conteneur principal et implémenté dans un proxy commun hors processus (le side-car), livré en tant que conteneur distinct dans le même pod. Vous pouvez utiliser les fonctionnalités de Cloud Service Mesh sans avoir à repenser votre modèle ; 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 un libellé 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 : La procédure dépend de votre implémentation 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)
Recommandation : Exécutez la commande suivante pour appliquer le libellé d'injection par défaut à l'espace de noms :
kubectl label namespace NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Si vous êtes déjà un utilisateur du plan de contrôle Istio géré : nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est prise en charge. Suivez les instructions suivantes :
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 de la colonne
NAME
est le libellé de révision qui correspond à la version 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
Recommandation : Exécutez la commande suivante pour appliquer le libellé 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 prise en charge : suivez les instructions suivantes :
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 été créés ou non 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 ...