Integrar cargas de trabalho do Kubernetes
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. Tudo Implantações deve ter um serviço do Kubernetes anexado.
Nomeie as 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 as 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:
Depois de implantar seus serviços em um cluster com o Cloud Service Mesh, injetar proxies sidecar.
Exemplo: implantar o exemplo da loja on-line
O aplicativo de exemplo 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
a 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 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ê já for usuário do plano de controle do Istiod gerenciado: recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível. Siga estas instruções:
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
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 tem suporte: Siga estas 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ãoistiod
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 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 aborda 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 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. É 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.
Como ativar a injeção automática de sidecar
Ativar o namespace 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:
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ê já for usuário do plano de controle do Istiod gerenciado: recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível. Siga estas instruções:
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.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 tem suporte: Siga estas 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ãoistiod
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 maneira: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 ...