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. 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:
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.
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 a injeção automática de arquivo secundário (injeção automática). Esse comando é diferente dependendo de você estar usando o Cloud Service Mesh gerenciado ou no cluster. Se você estiver usando o Cloud Service Mesh gerenciado, use rótulos de injeção padrão Por exemplo,
istio-injection=enabled
. Se você estiver usando o Cloud Service Mesh no cluster, usar o mesmo marcador de revisão que você usou para anotar o namespace do gateway de entrada. Observe que os clientes migrados do plano de controle gerenciado também pode usar os rótulos de revisão atuais além do rótulo de injeção padrão.Rótulos de injeção padrão
Aplique os rótulos de injeção padrão ao namespace. No comando a seguir, GATEWAY_NAMESPACE é o mesmo valor usado para anotar o namespace de gateway de entrada.
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;
Saída esperada:
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
Rótulo de revisão
Aplique o rótulo de revisão aos namespaces do aplicativo. No comando a seguir, REVISION é o mesmo valor usado para anotar o namespace de gateway de entrada.
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;
Saída esperada:
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
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 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.
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ê 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:
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 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:
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 ...