Integrar cargas de trabalho do Kubernetes

Observação :este guia só oferece suporte ao Cloud Service Mesh com APIs do Istio e que não são compatíveis com as APIs do Google Cloud. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Nesta página, mostramos como integrar cargas de trabalho do Kubernetes com do Cloud Service Mesh.

Implantar serviços do Kubernetes

Para implantar serviços do Kubernetes em clusters com o Cloud Service Mesh, você precisa faça o seguinte:

• Criar serviços do Kubernetes para todos os contêineres. Todos Implantações deve ter um serviço do Kubernetes anexado.

• Nomeie as portas de serviço. Embora o GKE permita definir valores sem nome portas de serviço, o Cloud Service Mesh exige que você forneça uma nome da porta que corresponde ao protocolo.

• Rotule suas implantações. Isso permite que você use o tráfego do Cloud Service Mesh recursos de gerenciamento, como a divisão do tráfego entre as versões do mesmo serviço.

O exemplo de implantação e serviço a seguir ilustra esses 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 implantar seus serviços em um cluster com o Cloud Service Mesh, injetar proxies sidecar.

Exemplo: implantar a amostra "Online Boutique"

O aplicativo de exemplo The Online Boutique na anthos-service-mesh-packages é modificado a partir do conjunto original de manifestos no microservices-demo repositório de dados. Seguindo as práticas recomendadas, cada serviço é implantado em um a uma conta de serviço exclusiva.

1. Crie os namespaces do aplicativo:

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

   Saída esperada:

   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. Ativar os namespaces para injeção. As etapas dependem da implementação do plano de controle.

   Gerenciado (TD)

   Aplique o rótulo de injeção padrão ao namespace:

   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;
   

   Gerenciado (Istiod)

   Recomendado:execute o seguinte comando para aplicar o rótulo de injeção padrão ao namespace:

     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 você for um usuário com o plano de controle Managed Istiod: Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão suporte. Siga estas instruções:

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

      kubectl -n istio-system get controlplanerevision
      

      O resultado será assim:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Observação :se duas revisões do plano de controle aparecerem na lista anterior, remova uma delas. Não é possível ter vários canais de plano de controle no cluster.

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

   2. Aplique o rótulo de revisão ao namespace:

      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 o rótulo de injeção padrão ao namespace:

     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 você use a injeção padrão, mas a injeção baseada em revisão é compatível: Siga estas instruções:

   1. Use o seguinte comando para localizar o rótulo 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 o rótulo de revisão ao namespace. No comando a seguir, REVISION_LABEL é o valor do rótulo de revisão istiod que você anotou na etapa 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. Implante o aplicativo de amostra no cluster.

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

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

      Saída esperada:

      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
      

      Saída esperada:

      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
      

      Saída esperada:

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

Nomear portas de serviço

Para serem incluídas no Cloud Service Mesh, as portas de serviço precisam ser nomeadas, e o nome precisa ser inclua 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 do serviço pode incluir um sufixo na seguinte sintaxe: name: protocol[-suffix], em que os colchetes indicam um sufixo opcional que precisa 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 exibidas no Console do Google Cloud, as portas de serviço precisam ser nomeadas com um dos seguintes protocolos: http, http2 ou grpc. As portas de serviço nomeadas com o protocolo https são tratadas como tcp e as métricas não são exibidas para esses serviços.

Injetar proxies sidecar

Esta seção mostra como configurar a injeção do proxy sidecar com o Cloud Service Mesh para melhorar a segurança de rede, a confiabilidade e observabilidade. Essas funções são abstraídas do ambiente contêiner principal e implementado em um proxy comum fora do processo (o arquivo secundário), entregues como um contêiner separado no mesmo pod. Você pode usar Recursos do Cloud Service Mesh sem redesenho seus aplicativos de produção para uma malha de serviço.

A injeção automática de proxy sidecar (injeção automática) ocorre quando O Cloud Service Mesh detecta um rótulo de namespace que você configura para a carga de trabalho do pod. O proxy intercepta todo o tráfego de entrada e saída para as cargas de trabalho e se comunica com o Cloud Service Mesh.

Permissões necessárias para as tarefas

Para executar as tarefas descritas nesta página, você precisa ter o papel roles/container.clusterAdmin ou um superior a esse. Consulte Papéis do Google Kubernetes Engine para ver detalhes sobre as permissões incluídas nesse papel.

Como ativar a injeção automática de sidecar

1. Ativar o namespace para injeção. As etapas dependem da implementação do plano de controle.

   Gerenciado (TD)

   1. Aplique o rótulo de injeção padrão ao namespace:

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

   Gerenciado (Istiod)

   Recomendado:execute o seguinte comando para aplicar o rótulo de injeção padrão ao namespace:

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

   Se você for um usuário com o plano de controle Managed Istiod: Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão suporte. Siga estas instruções:

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

      kubectl -n istio-system get controlplanerevision
      

      O resultado será assim:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      OBSERVAÇÃO: se duas revisões do plano de controle aparecerem na lista acima, remova uma. Não é possível ter vários canais de plano de controle no cluster.

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

   2. Aplique o rótulo de revisão ao namespace:

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

   No cluster

   Recomendado:execute o seguinte comando para aplicar o rótulo de injeção padrão ao namespace:

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

   Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível: Siga estas instruções:

   1. Use o seguinte comando para localizar o rótulo 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 o rótulo de revisão ao namespace. No comando a seguir, REVISION_LABEL é o valor do rótulo de revisão istiod que você anotou na etapa anterior.

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

2. Reinicie os pods afetados usando as etapas da próxima seção.

3. Anote o namespace demo da seguinte maneira:

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

Reinicie os pods para atualizar proxies sidecar

Alerta: a menos que você tenha um balanceador de carga ou roteador configurado para implantações azul-verde (em inglês), teste a reinicialização de pods em um ambiente de preparo para verificar se os serviços conseguem processar qualquer possível interrupção do tráfego.

Com a injeção automática de sidecar, é possível reiniciar os pods para atualizar os sidecars deles:

A maneira como você reinicia os pods depende se eles foram criados como parte de uma Implantação.

1. Se você usou uma implantação, reinicie-a. Isso reinicia todos os pods com sidecars:

   kubectl rollout restart deployment -n NAMESPACE

   Se você não usou uma implantação, exclua os pods. Eles serão recriados automaticamente com os sidecars:

   kubectl delete pod -n NAMESPACE --all

2. Confira se todos os pods no namespace têm sidecars injetados:

   kubectl get pod -n NAMESPACE

   Neste exemplo de saída do comando anterior, observe que a coluna READY indica que há dois contêineres para cada uma das cargas de trabalho: o principal e o contêiner do proxy sidecar.

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