Integre cargas de trabalho do Kubernetes

Nota: este guia só suporta a Cloud Service Mesh com APIs Istio e não suporta Google Cloud APIs. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

Esta página mostra como integrar cargas de trabalho do Kubernetes com a Cloud Service Mesh.

Implemente serviços do Kubernetes

Para implementar serviços Kubernetes em clusters com o Cloud Service Mesh, tem de fazer o seguinte:

• Crie serviços Kubernetes para todos os contentores. Todas as implementações devem ter um serviço Kubernetes anexado.

• Atribua um nome às portas de serviço. Embora o GKE lhe permita definir portas de serviço sem nome, o Cloud Service Mesh requer que forneça um nome para uma porta que corresponda ao protocolo da porta.

• Etiquete as suas implementações. Isto permite-lhe usar funcionalidades de gestão de tráfego do Cloud Service Mesh, como dividir o tráfego entre versões do mesmo serviço.

A implementação e o serviço de exemplo seguintes ilustram estes requisitos:

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

Depois de implementar os seus serviços num cluster com a Cloud Service Mesh, certifique-se de que injeta proxies sidecar.

Exemplo: implemente o exemplo da loja online

A aplicação de exemplo Online Boutique no repositório anthos-service-mesh-packages é modificada a partir do conjunto original de manifestos no repositório microservices-demo. Seguindo as práticas recomendadas, cada serviço é implementado num espaço de nomes separado com uma conta de serviço exclusiva.

1. Crie os espaços de nomes para a aplicação:

   kubectl apply -f \
     DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces
   

   Resultado esperado:

   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. Ative os espaços de nomes para a injeção. Os passos dependem da sua implementação do plano de controlo.

   Gerido (TD)

   Aplique a etiqueta de injeção predefinida ao espaço de nomes:

   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;
   

   Gerido (Istiod)

   Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

     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;
   

   Se for um utilizador existente com o plano de controlo do Istiod gerido: recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada. Siga as instruções abaixo:

   1. Execute o seguinte comando para localizar os canais de lançamento disponíveis:

      kubectl -n istio-system get controlplanerevision
      

      O resultado é semelhante ao seguinte:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Nota: se aparecerem duas revisões do plano de controlo na lista anterior, remova uma delas. Ter vários canais do plano de controlo no cluster não é suportado.

      Na saída, o valor na coluna NAME é a etiqueta de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

   2. Aplique a etiqueta de revisão ao espaço de nomes:

      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;
      

   No cluster

   Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

     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;
   

   Recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada: siga estas instruções:

   1. Use o seguinte comando para localizar a etiqueta de revisão em istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Aplique a etiqueta de revisão ao espaço de nomes. No comando seguinte, REVISION_LABEL é o valor da etiqueta de revisão istiod que anotou no passo anterior.

      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;
      

3. Implemente a aplicação de exemplo no cluster.

   1. Crie as contas de serviço e as implementações:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments
      

      Resultado esperado:

      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. Crie os serviços:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/kubernetes-manifests/services
      

      Resultado esperado:

      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. Crie as entradas de serviço:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml
      

      Resultado esperado:

      serviceentry.networking.istio.io/allow-egress-googleapis created
      serviceentry.networking.istio.io/allow-egress-google-metadata created
      

Nomeie as portas de serviço

Para serem incluídas na Cloud Service Mesh, as portas de serviço têm de ter um nome, e o nome tem de incluir o protocolo da porta, por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

O nome da porta de serviço pode incluir um sufixo na seguinte sintaxe: name: protocol[-suffix] em que os parênteses retos indicam um sufixo opcional que tem de começar com um traço, por exemplo:

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

Para que as métricas sejam apresentadas na Google Cloud consola, as portas de serviço têm de ter um dos seguintes protocolos: http, http2 ou grpc. As portas de serviço com o protocolo https são tratadas comotcp e as métricas não são apresentadas para esses serviços.

Injete proxies complementares

Esta secção aborda a configuração da injeção de proxy sidecar com o Cloud Service Mesh para melhorar a segurança, a fiabilidade e a observabilidade da rede. Estas funções são abstraídas do contentor principal da aplicação e implementadas num proxy fora do processo comum (o sidecar), fornecido como um contentor separado no mesmo pod. Pode usar as funcionalidades do Cloud Service Mesh sem reestruturar as suas aplicações de produção para participar numa malha de serviços.

A injeção automática de proxy sidecar ocorre quando o Cloud Service Mesh deteta uma etiqueta de espaço de nomes que configura para o pod da carga de trabalho. O proxy interceta todo o tráfego de entrada e saída para as cargas de trabalho e comunica com a malha de serviços na nuvem.

Autorizações necessárias para estas tarefas

Para realizar as tarefas nesta página, tem de ter a função de roles/container.clusterAdmin ou superior. Consulte as funções do Google Kubernetes Engine para ver detalhes sobre as autorizações incluídas nesta função.

Ativar a injeção automática de sidecar

1. Ative o espaço de nomes para injeção. Os passos dependem da sua implementação do plano de controlo.

   Gerido (TD)

   1. Aplique a etiqueta de injeção predefinida ao espaço de nomes:

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

   Gerido (Istiod)

   Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

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

   Se for um utilizador existente com o plano de controlo do Istiod gerido: recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada. Siga as instruções abaixo:

   1. Execute o seguinte comando para localizar os canais de lançamento disponíveis:

      kubectl -n istio-system get controlplanerevision
      

      O resultado é semelhante ao seguinte:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      NOTA: se aparecerem duas revisões do plano de controlo na lista acima, remova uma delas. Ter vários canais do plano de controlo no cluster não é suportado.

      Na saída, o valor na coluna NAME é a etiqueta de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

   2. Aplique a etiqueta de revisão ao espaço de nomes:

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

   No cluster

   Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

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

   Recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada: siga estas instruções:

   1. Use o seguinte comando para localizar a etiqueta de revisão em istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Aplique a etiqueta de revisão ao espaço de nomes. No comando seguinte, REVISION_LABEL é o valor da etiqueta de revisão istiod que anotou no passo anterior.

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

2. Reinicie os pods afetados através dos passos na secção seguinte.

3. Anote o espaço de nomes demo da seguinte forma:

   kubectl annotate --overwrite namespace NAMESPACE \
   mesh.cloud.google.com/proxy='{"managed":"true"}'
   

Reinicie os pods para atualizar os proxies sidecar

Aviso: a menos que tenha um balanceador de carga ou um router configurado para implementações azul-verde, certifique-se de que testa o reinício dos pods num ambiente de preparação para verificar se os seus serviços conseguem processar qualquer potencial interrupção do tráfego.

Com a injeção automática de sidecars, pode atualizar os sidecars para os pods existentes com um reinício do pod:

A forma como reinicia os pods depende de terem sido criados como parte de uma implementação.

1. Se usou uma implementação, reinicie-a, o que reinicia todos os pods com sidecars:

   kubectl rollout restart deployment -n NAMESPACE

   Se não usou uma implementação, elimine os pods. Estes são recriados automaticamente com os sidecars:

   kubectl delete pod -n NAMESPACE --all

2. Verifique se todos os pods no espaço de nomes têm sidecars injetados:

   kubectl get pod -n NAMESPACE

   No exemplo de saída seguinte do comando anterior, repare que a coluna READY indica que existem dois contentores para cada uma das suas cargas de trabalho: o contentor principal e o contentor para o proxy sidecar.

   NAME                    READY   STATUS    RESTARTS   AGE
   WORKLOAD           2/2     Running   0          20s
   ...