O Cloud Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Integrar cargas de trabalho do Kubernetes

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

Implantar serviços do Kubernetes

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

Criar serviços do Kubernetes para todos os contêineres. Todas as implantações precisam ter um serviço do Kubernetes anexado.
Nomeie suas portas de serviço. Embora o GKE permita definir portas de serviço sem nome, o Cloud Service Mesh exige que você forneça um nome para uma porta que corresponda ao protocolo dessa porta.
Rotule suas implantações. Isso permite usar os recursos de gerenciamento de tráfego do Cloud Service Mesh, como dividir tráfego entre 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 os serviços em um cluster com o Cloud Service Mesh, injete proxies sidecar.

Exemplo: implante a amostra do Online Boutique

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

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

Ative os namespaces para injeção. As etapas dependem da sua 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 comando a seguir 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ê já usa o plano de controle gerenciado do Istiod:recomendamos usar a injeção padrão, mas a injeção baseada em revisão é compatível. Siga estas instruções:

Execute o comando a seguir 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.

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 comando a seguir 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. Use as seguintes instruções:

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

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;

Implante o aplicativo de amostra no cluster.

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

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

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

Nesta seção, explicamos como configurar a injeção de proxy sidecar com o Cloud Service Mesh para melhorar a segurança, a confiabilidade e a observabilidade da rede. Essas funções são abstraídas do contêiner principal do aplicativo e implementadas em um proxy comum fora do processo (o sidecar), entregue como um contêiner separado no mesmo pod. É possível usar os recursos do Cloud Service Mesh sem reformular seus aplicativos de produção para participar de uma malha de serviço.

A injeção automática de proxy sidecar ocorre quando o Cloud Service Mesh detecta um rótulo de namespace que você configura para o pod da carga de trabalho. O proxy intercepta todo o tráfego de entrada e saída das 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

Ativar o namespace para injeção. As etapas dependem da sua 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 comando a seguir 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ê já usa o plano de controle gerenciado do Istiod:recomendamos usar a injeção padrão, mas a injeção baseada em revisão é compatível. Siga estas instruções:
1. Execute o comando a seguir 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 delas. Não é possível ter vários canais do 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 comando a seguir 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. Use as seguintes 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
Reinicie os pods afetados usando as etapas da próxima seção.

Anote o namespace demo da seguinte forma:

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

Reinicie os pods para atualizar proxies sidecar

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.

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