Intégrer des charges de travail Kubernetes

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Istio et non avec les API Google Cloud. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh.

Cette page vous 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 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 à son protocole.

• Ajouter des libellés à 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 du même service.

Les exemples de déploiement et de service suivants illustrent ces exigences:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

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 Online Boutique

L'exemple d'application Online Boutique du dépôt anthos-service-mesh-packages a été 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 espace de noms distinct avec un compte de service unique.

1. 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
   

2. Activez l'injection side-car automatique (injection automatique). Cette commande est différente selon que vous utilisez le maillage de services Cloud géré ou le maillage de services Cloud au sein du cluster. Si vous utilisez Cloud Service Mesh géré, utilisez des libellés d'injection par défaut (par exemple, istio-injection=enabled). Si vous utilisez Cloud Service Mesh dans le cluster, utilisez le même libellé de révision que celui que vous avez utilisé pour annoter l'espace de noms de la passerelle d'entrée. Notez que les clients existants migrés du plan de contrôle géré peuvent également utiliser leurs libellés de révision existants en plus du libellé 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;
   

   Remarque :Vous pouvez ignorer les erreurs liées au libellé "Istio.io/rev" introuvables.

   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
   

3. Déployez l'exemple d'application sur le cluster.

   1. 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
      

   2. 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
      

   3. 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 ce nom doit 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 pour améliorer la sécurité, la fiabilité et l'observabilité du réseau. Ces fonctions sont extraites du conteneur principal de l'application et implémentées dans un proxy commun hors processus (le side-car), fourni en tant que 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 qu'elles participent à 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.

Autorisations requises pour ces tâches

Pour effectuer les tâches décrites sur cette page, vous devez disposer du rôle roles/container.clusterAdmin ou d'un rôle supérieur. Consultez la section Rôles dans Google Kubernetes Engine pour en savoir plus sur les autorisations incluses dans ce rôle.

Activer l'injection side-car automatique

1. Activez l'espace de noms pour l'injection : La procédure dépend de la mise en œuvre de votre plan de contrôle.

   Géré (TD)

   1. Appliquez le libellé 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 le libellé d'injection par défaut à l'espace de noms:

     kubectl label namespace NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   Si vous utilisez déjà le 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 acceptée. Pour ce faire, procédez comme suit:

   1. 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 apparaissent 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 sous la colonne NAME correspond au libellé de révision qui correspond à la version disponible pour la version de Cloud Service Mesh.

   2. 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

   1. 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"}'
      

   2. Appliquez le libellé de révision à l'espace de noms. Dans la commande suivante, REVISION_LABEL correspond à la valeur du libellé de révision istiod que vous avez notée à l'étape précédente.

      kubectl label namespace NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

2. Redémarrez les pods concernés en suivant la procédure décrite dans la section suivante.

3. 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

Avertissement :À moins que vous n'ayez configuré un équilibreur de charge ou un routeur pour les déploiements bleu-vert, veillez à tester le redémarrage des pods dans un environnement de préproduction pour vérifier que vos services peuvent gérer toute interruption de trafic potentielle.

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 dans le cadre d'un déploiement ou non.

1. 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

2. 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
   ...