O Anthos Service Mesh 1.9 chegou ao fim da vida útil e não é mais compatível. Consulte Como fazer upgrade de versões anteriores.

Veja uma mais recente ou selecione outra versão disponível:

Versões disponíveis

1.20 (mais recente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Como instalar o Anthos Service Mesh no local com um HSM e o Vault

Neste guia, explicamos como instalar o Anthos Service Mesh no GKE no VMware e usar o Thales Luna HSM 7+ e o Hashicorp Vault para gerar com segurança a chave de assinatura de CA do Istio e proteger essa chave.

Se você tiver uma versão anterior do Anthos Service Mesh instalada, consulte Como fazer upgrade do Anthos Service Mesh no GKE no VMware. Esta instalação ativa os recursos compatíveis no seu cluster.

Antes de começar

Confira os requisitos a seguir antes de iniciar a configuração.

Requisitos

Você precisa ter uma assinatura do Anthos. Como alternativa, uma opção de pagamento por utilização está disponível para o GKE Enterprise apenas no Google Cloud. Para mais informações, consulte o Guia de preços do GKE Enterprise.
Entre em contato com a equipe de suporte para conceder a você as permissões para acessar as imagens. A equipe de suporte também fornecerá assistência adicional.
Verifique se o cluster em que você instala o Anthos Service Mesh tem pelo menos quatro vCPUs, 15 GB de memória e quatro nós.
Você precisa nomear as portas de serviço usando a sintaxe a seguir: name: protocol[-suffix], em que os colchetes indicam um sufixo opcional que precisa começar com um traço. Saiba mais em Como nomear portas de serviço.
Verifique se a versão do cluster está listada em Ambientes compatíveis. Para verificar a versão do cluster, use a ferramenta de linha de comando gkectl. Se você não tiver a gkectl instalada, consulte Downloads do GKE On-Prem.
```
gkectl version
```
É preciso ter o Thales Luna HSM 7+ na infraestrutura. O HSM precisa ter o serviço de rede configurado e acessível a partir do cluster do Anthos Service Mesh.
Você precisa ter servidores Hashicorp Vault na sua infraestrutura para armazenar as credenciais que acessam o HSM. Os servidores do Vault precisam ser acessados pelo cluster do Anthos Service Mesh por meio da rede.

Configurar o ambiente

Instale as ferramentas a seguir na máquina que você controla o processo de instalação do Anthos Service Mesh.

Ferramenta de linha de comando curl
A Google Cloud CLI.

Após instalar as ferramentas de pré-requisito, execute as seguintes etapas:

Faça a autenticação com a Google Cloud CLI:
```
gcloud auth login
```
Atualize os componentes:
```
gcloud components update
```
Instale kubectl:
```
gcloud components install kubectl
```
Para implantar e testar a instalação com o aplicativo de amostra Online Online (em inglês), instale kpt:
```
gcloud components install kpt
```
Alterne o contexto para o cluster de usuário (se necessário):
```
kubectl config use-context CLUSTER_NAME
```
Conceda permissões de administrador de cluster à sua conta de usuário (seu endereço de e-mail de login do Google Cloud). Você precisa dessas permissões para criar as regras necessárias de controle de acesso baseado em papéis (RBAC, na sigla em inglês) para o Anthos Service Mesh:
```
kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user=USER_ACCOUNT
```

Implantar dependências

Implante o Thales Luna HSM 7+ na infraestrutura para gerenciar com segurança as chaves de assinatura de CA do Istio. Verifique se o HSM tem serviço de rede e conectividade com o cluster do Anthos Service Mesh.
Implante os servidores Hashicorp Vault na sua infraestrutura para armazenar as credenciais para acessar o HSM. Verifique se os servidores do Vault têm conectividade de rede com o cluster do Anthos Service Mesh.
Ter uma estação de trabalho com acesso ao servidor do Vault, ao HSM e ao cluster do Kubernetes em que você instala o Anthos Service Mesh.

Configurar o módulo de segurança de hardware (HSM)

Esta seção lista as etapas para configurar o módulo de segurança de hardware (HSM) e gerar chaves de criptografia.

Provisione as credenciais e o slot do HSM

Siga o guia de instalação de HSM para executar as etapas a seguir.

Configure o HSM como um HSM de rede.
Provisione arquivos PEM para conexões mTLS com o HSM, incluindo o arquivo de chave do cliente, o arquivo de certificado do cliente e o arquivo de certificado do servidor.
Provisione um slot do HSM para o Anthos Service Mesh e registre o rótulo e o PIN do slot.

Gerar uma chave de criptografia de chaves (KEK) do HSM

Na máquina com acesso ao HSM, faça o download da ferramenta HSM (disponível apenas para Linux amd-64).
```
gsutil cp gs://artifacts.thalescpl-io-k8s-kms-plugin.appspot.com/binary/k8s-kms-plugin .
```

Defina variáveis de ambiente antes de executar a ferramenta HSM como um servidor local, que se conecta ao HSM e é veiculado no Unix Domain Socket (UDS).

export P11_TOKEN=HSM slot label
export ChrystokiConfigurationPath=path to the Thales HSM Chrystoki configuration file
export P11_LIB=path to the libCryptoki2.so file for accessing the Thales HSM
export P11_PIN_FILE=path to the file that stores the HSM slot PIN
export SOCKET=/tmp/.hsm-sock
./k8s-kms-plugin serve &

A saída será semelhante a esta:

The token has been initialized and is reassigned to slot 412789065
INFO Loaded P11 PIN from file: /home/hsm/hsm-credential/pin  line="cmd/serve.go:93"
INFO KMS Plugin Listening on : /var/.hsm-sock  line="cmd/serve.go:119"
INFO Serving on socket: /tmp/.hsm-sock  line="cmd/serve.go:198"

Se você não tiver uma chave de criptografia de chaves (KEK, na sigla em inglês) no HSM, siga estas etapas para gerar uma. Use k8s-kms-plugin como um cliente para se comunicar com o servidor da ferramenta HSM. Se você quiser especificar explicitamente um ID KEK, transmita a sinalização --kek-id no comando. Caso contrário, um código KEK aleatório será gerado automaticamente.
```
./k8s-kms-plugin generate-kek --kek-id KEK ID
```
Registre o código da KEK. Ele será usado nas etapas a seguir.
O HSM usa o certificado raiz importado para verificar o certificado CA assinado do Istio. Você pode seguir este passo para importar o certificado raiz para o HSM. Use k8s-kms-plugin como um cliente para se comunicar com o servidor da ferramenta HSM. Importe o certificado raiz usando o comando a seguir.
```
./k8s-kms-plugin import-ca -f root cert PEM file
```

Configurar a autenticação do Kubernetes para o Vault

No cluster do Kubernetes, crie uma conta de serviço dedicada e uma política de RBAC para que o Vault chame a API TokenReview. Crie um namespace dedicado para essa finalidade.
Crie a conta de serviço padrão no namespace vault, defina as permissões e extraia o JSON Web Token (JWT) associado para o servidor do Vault chamar a API TokenReview do Kubernetes. Observação: você poderá usar qualquer conta de serviço e namespace do Kubernetes se tiver permissão suficiente.
Configure o sufixo do cluster que você quer configurar. Use um diretório dedicado para a configuração.
```
export CLUSTER_SUFFIX="c1"
mkdir ${CLUSTER_SUFFIX}
cd ${CLUSTER_SUFFIX}
```
Alterne para o cluster que você quer gerenciar e crie o namespace vault. kubectl cria a conta de serviço padrão automaticamente.
```
kubectl create ns vault
```

Para conceder permissões, vincule a conta de serviço default.vault ao papel auth-delegator.

kubectl apply -f -<< EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: role-tokenreview-binding
 namespace: vault
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
 - kind: ServiceAccount
   name: default
   namespace: vault
EOF

Crie um secret para armazenar a credencial do token.

VAULT_SA_SECRET=default-token
kubectl apply -n vault -f - << EOF
apiVersion: v1
kind: Secret
metadata:
 name: "${VAULT_SA_SECRET}"
 annotations:
   kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

Receba o JWT para a conta de serviço default.vault.

VAULT_SA_JWT_TOKEN=$(kubectl get -n vault secret $VAULT_SA_SECRET -o jsonpath="{.data.token}" | base64 --decode)
echo $VAULT_SA_JWT_TOKEN > ${CLUSTER_SUFFIX}-tokenreview_jwt
cat ${CLUSTER_SUFFIX}-tokenreview_jwt

Recupere o endereço e o certificado de CA do servidor da API Kubernetes. Depois, configure o servidor do Vault para chamar o servidor da API Kubernetes.

Receber os valores públicos de IP:Port do Kubernetes.

K8S_ADDR=$(kubectl config  view -o jsonpath="{.clusters[?(@.name == '$(kubectl config current-context)')].cluster.server}")
echo $K8S_ADDR > ${CLUSTER_SUFFIX}-k8s_addr
cat ${CLUSTER_SUFFIX}-k8s_addr

Receber o certificado para autenticar o servidor da API Kubernetes.

VAULT_SA_CA_CRT=$(kubectl get -n vault secret $VAULT_SA_SECRET -o jsonpath="{.data['ca\.crt']}" | base64 --decode)
echo $VAULT_SA_CA_CRT > "${CLUSTER_SUFFIX}-k8s_cert"
cat "${CLUSTER_SUFFIX}-k8s_cert"

Converta o arquivo de certificado no formato de arquivo PEM e valide-o.

sed -i 's/ CERTIFICATE/CERTIFICATE/g' ${CLUSTER_SUFFIX}-k8s_cert
sed -i 's/ /\n/g' ${CLUSTER_SUFFIX}-k8s_cert
sed -i 's/CERTIFICATE/ CERTIFICATE/g' ${CLUSTER_SUFFIX}-k8s_cert

Verifique se o certificado é válido.

openssl x509 -in ${CLUSTER_SUFFIX}-k8s_cert -noout -text

Volte para o diretório anterior.
```
cd ..
```

Agora use os três arquivos no diretório do cluster para configurar o Vault na próxima etapa.

Configurar o Vault para armazenar credenciais do HSM

Quando o servidor do Vault estiver disponibilizando tráfego TLS com um certificado válido, configure o PKI do Vault e configure a autenticação do Kubernetes. Veja a seguir um exemplo de configuração de uma única CA raiz e CAs intermediárias por cluster.

Faça login no Vault como raiz.
```
vault login
```

Armazene o secret do HSM.

SECRET_PATH=asm-$CLUSTER_SUFFIX
vault secrets enable -path=$SECRET_PATH  kv
vault secrets tune -max-lease-ttl=87600h $SECRET_PATH
export HSM_SECRET_PATH="$SECRET_PATH/hsm"
vault kv put ${HSM_SECRET_PATH} clientcert=HSM_CLIENT_CERT clientkey=HSM_CLIENT_KEY servercert=HSM_SERVER_CERT PIN=HSM_PIN
vault kv get ${HSM_SECRET_PATH}

Crie uma política com permissões para o caminho de ICP.

vault policy write asm-$CLUSTER_SUFFIX-hsm-policy -<< EOF
path "${HSM_SECRET_PATH}" {
capabilities = ["read"]
}
EOF

Adicione a autenticação do Kubernetes para o cluster.

vault auth enable --path="${HSM_SECRET_PATH}"  kubernetes

Defina o JWT do Kubernetes, o endereço do Kubernetes e o certificado de CA do Kubernetes no caminho de autenticação do Vault.

vault write auth/${HSM_SECRET_PATH}/config \
token_reviewer_jwt=cat "${CLUSTER_SUFFIX}"-tokenreview_jwt \
kubernetes_host=cat "${CLUSTER_SUFFIX}"-k8s_addr \
kubernetes_ca_cert=@"${CLUSTER_SUFFIX}"-k8s_cert

Permitir que istiod-service-account.istio-system autentique como papel demo e usar a política criada.

vault write auth/${HSM_SECRET_PATH}/role/istiod \
bound_service_account_names=istiod-service-account \
bound_service_account_namespaces=istio-system \
policies=asm-$CLUSTER_SUFFIX-hsm-policy \
ttl=768h

Volte para a pasta pai.
```
cd ..
```

Fazer o download do arquivo de instalação

Linux

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz
```

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig istio-1.9.8-asm.6-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:
```
 tar xzf istio-1.9.8-asm.6-linux-amd64.tar.gz
```
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:
- Exemplos de aplicativos no diretório samples.
- A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
- Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.
Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.
```
cd istio-1.9.8-asm.6
```

macOS

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz
```

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.9.8-asm.6-osx.tar.gz.1.sig istio-1.9.8-asm.6-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:
```
tar xzf istio-1.9.8-asm.6-osx.tar.gz
```
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:
- Exemplos de aplicativos no diretório samples.
- A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
- Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.
Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.
```
cd istio-1.9.8-asm.6
```

Windows

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip
```

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip.1.sig
openssl dgst -verify - -signature istio-1.9.8-asm.6-win.zip.1.sig istio-1.9.8-asm.6-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:
```
tar xzf istio-1.9.8-asm.6-win.zip
```
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:
- Exemplos de aplicativos no diretório samples.
- A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
- Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.
Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.
```
cd istio-1.9.8-asm.6
```

Configurar o recurso no plano de controle

Defina as variáveis de ambiente.

export CLUSTER_SUFFIX="c1"
export VAULT_ADDR="https://VAULT_IP:PORT"

Copie o arquivo que contém o certificado para autenticar o Vault em um arquivo chamado cert. Por exemplo, o certificado TLS do servidor do Vault, ${VAULT_CACERT}.

Observação: o cliente Vault usa este certificado para autenticar o servidor do Vault. Esse certificado é diferente do usado pelo Vault para autenticar o servidor da API Kubernetes.
```
cp ${VAULT_CACERT} ./cert
```

Crie um ConfigMap a partir do arquivo no namespace istio-system.

kubectl create ns istio-system
kubectl delete configmap vault-tls-cert -n istio-system
kubectl create configmap vault-tls-cert -n istio-system --from-file=./cert

Configurar o webhook de validação

Ao instalar o Anthos Service Mesh, você define um rótulo de revisão em istiod. Você precisa definir a mesma revisão no webhook de validação.

Copie o seguinte YAML para um arquivo chamado istiod-service.yaml.

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-198-6
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-198-6

Instale o Anthos Service Mesh

Configure as variáveis de ambiente para configurar o ASM para interagir com o Vault e o HSM. O comando a seguir reduz o tempo de espera para 10 segundos porque o Istio não estará totalmente pronto devido à operação de importação pendente pelo operador.

export HSM_SLOT_LABEL=the HSM slot label
export VAULT_ADDR=address of the vault server
export HSM_SECRET_PATH=the path to the HSM secret on Vault
export KEK_ID=the HSM slot KEK ID
export HSM_PLUGIN_IMAGE=gcr.io/thalescpl-io-k8s-kms-plugin/hsm-plugin:asm-1.7-1
export VAULT_CLIENT_IMAGE=gcr.io/gke-release/asm/vaultclient:latest
export WAIT_FOR_RESOURCES_TIMEOUT=10s

Execute o seguinte comando para instalar o Anthos Service Mesh com o perfil asm-multicloud. Se você quiser ativar um recurso opcional compatível, inclua -f e o nome de arquivo YAML na linha de comando a seguir. Para mais informações, consulte Como ativar recursos opcionais.

istioctl install --set profile=asm-multicloud \
   --set revision=asm-198-6 \
   --set values.hsm.enabled=true \
   --set values.hsm.hsmKEKID=${KEK_ID} \
   --set values.hsm.hsmPluginImage=${HSM_PLUGIN_IMAGE} \
   --set values.hsm.hsmSlotLabel=${HSM_SLOT_LABEL} \
   --set values.hsm.vaultClientImage=${VAULT_CLIENT_IMAGE} \
   --set values.hsm.vaultAddr=${VAULT_ADDR} \
   --set values.hsm.vaultAuthPath=auth/${HSM_SECRET_PATH}/login \
   --set values.hsm.vaultAuthRole=istiod \
   --set values.hsm.vaultAuthJwtPath="/var/run/secrets/kubernetes.io/serviceaccount/token" \
   --set values.hsm.vaultSecretPath=${HSM_SECRET_PATH} \
   --set values.global.jwtPolicy="first-party-jwt"

Configure o webhook de validação para que ele possa localizar o serviço istiod com o rótulo de revisão:
```
kubectl apply -f istiod-service.yaml
```
Esse comando cria uma entrada de serviço que permite ao webhook de validação verificar automaticamente as configurações antes de serem aplicadas.
Verifique se o Istio foi inicializado corretamente e está em espera.
```
kubectl get pod -l app=istiod -n istio-system
```
A saída será semelhante a esta:
```
NAME                      READY   STATUS    RESTARTS   AGE
istiod-66ff56d76c-f9p5l   2/3     Running   2          1m27s
```
Veja que o Istio não está totalmente pronto porque o contêiner discovery está bloqueado e aguardando o certificado.

Verifique o registro dos contêineres do Istio para garantir que eles estão no estado certo.

kubectl logs -c hsm-plugin -l app=istiod -n istio-system

A saída será semelhante a esta:

The token has been initialized and is reassigned to slot 412789065
INFO Loaded P11 PIN from file: /var/run/hsm-credential/pin  line="cmd/serve.go:93"
INFO KMS Plugin Listening on : /var/run/hsm-socket/.sock  line="cmd/serve.go:119"
INFO Serving on socket: /var/run/hsm-socket/.sock  line="cmd/serve.go:198"
KEK ID: 7651a4ea-eeb7-4c1f-927b-8c871c2127aa

kubectl logs -c discovery -l app=istiod -n istio-system

Espere a última linha de saída, como a seguinte:

...
2020-10-15T21:56:56.918931Z info    pkica   Wait until the CA certificate secret istio-system.istio-ca-cert can be loaded...

Assinar certificado para o Istio

Faça o download da CSR criptografada pelo secret do Kubernetes.

kubectl get secret istio-ca-cert-csr -n istio-system -o jsonpath={.data} > encrypted_csr.json

Descriptografe a CSR.

kubectl get secret istio-ca-cert-csr -n istio-system -o jsonpath={.data} > encrypted_csr.json
./k8s-kms-plugin decrypt-csr -f encrypted_csr.json -o csr.pem

O administrador de segurança precisa assinar o arquivo csr.pem usando a CA raiz.
Coloque a cadeia de certificados na raiz do arquivo chamado cert-chain.pem e execute o comando a seguir.
```
kubectl create secret generic istio-ca-cert --from-file=cert-chain.pem -n istio-system
```

Verifique no Istio se a Istio está carregando a nova cadeia de certificados.

kubectl logs ISTIOD_POD -c discovery -n istio-system | grep "CA cert\:" -A 60

A resposta será semelhante a esta:

2020-10-24T18:58:14.354254Z info pkica CA cert: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

certificados intermediários: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

certificado raiz: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

Verificar a instalação

Siga as etapas abaixo para verificar se a instalação do Anthos Service Mesh está funcionando corretamente.

Verificar os componentes do plano de controle

Verifique se os pods do plano de controle em istio-system estão em execução:

kubectl get pod -n istio-system

A saída esperada será assim:

NAME                                      READY   STATUS      RESTARTS   AGE
istio-ingressgateway-74cc894bfd-786rg     1/1     Running     0          7m19s
istiod-78cdbbbdb-d7tps                    3/3     Running     0          7m36s
promsd-576b8db4d6-lqf64                   2/2     Running     1          7m19s

Acione uma chamada TLS para um serviço do arquivo secundário e inspecione o certificado usado pelo serviço, usando bookinfo como exemplo.
```
kubectl exec POD -c istio-proxy -- openssl s_client -alpn istio -showcerts -connect details:9080
```
Inspecione os certificados na saída e espere ver a cadeia de certificados do lado do servidor na saída.

Injetar proxies de arquivo secundário

O Anthos Service Mesh usa proxies sidecar para aumentar a segurança, a confiabilidade e a observabilidade da rede. Com o Anthos Service Mesh, essas funções são abstraídas do contêiner principal do aplicativo e implementadas em um proxy comum fora do processo, entregue como um contêiner separado no mesmo pod.

A instalação não será concluída até que você ative a injeção automática de proxy de arquivo secundário (injeção automática) e reinicie os pods de todas as cargas de trabalho que estavam sendo executadas no cluster antes de instalar o Anthos Service Mesh.

Para ativar a injeção automática, rotule os namespaces com o rótulo de revisão que foi definido no istiod quando você instalou o Anthos Service Mesh. O rótulo de revisão é usado pelo webhook do injetor automático de arquivo secundário para associar os arquivos secundários injetados a uma revisão istiod específica. Depois de adicionar o rótulo, todos os pods existentes no namespace precisarão ser reiniciados para que os arquivos secundários sejam injetados.

Antes de implantar novas cargas de trabalho em um novo namespace, configure a injeção automática para que o Anthos Service Mesh possa monitorar e proteger o tráfego.

Para ativar a injeção automática:

Use o seguinte comando para localizar o rótulo de revisão em istiod:

kubectl -n istio-system get pods -l app=istiod --show-labels

A resposta será semelhante a:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-198-6-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586
istiod-asm-198-6-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586

Na saída, na coluna LABELS, observe o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-198-6.

Aplique o rótulo de revisão e remova o rótulo istio-injection, se ele existir. No comando a seguir, NAMESPACE é o nome do namespace em que você quer ativar a injeção automática, e REVISION é o rótulo de revisão que você anotou na etapa anterior.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente, que é esperado em novas instalações do Anthos Service Mesh ou em novas implantações. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection.
Se as cargas de trabalho estavam em execução no cluster antes de instalar o Anthos Service Mesh, reinicie os pods para acionar a nova injeção.

A maneira como você reinicia os pods depende do seu aplicativo e do ambiente em que o cluster está. Por exemplo, no seu ambiente de preparo, basta excluir todos os pods, o que faz com que eles sejam reiniciados. Mas no ambiente de produção, há um processo que implementa uma implantação azul-verde para que você possa reiniciar os pods com segurança para evitar a interrupção do tráfego.

É possível usar kubectl para executar uma reinicialização gradual:
```
kubectl rollout restart deployment -n NAMESPACE
```
Verifique se os pods estão configurados para apontar para a nova versão de istiod.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```

Configurar um endereço IP externo

A instalação padrão do Anthos Service Mesh presume que um endereço IP externo é alocado automaticamente para serviços LoadBalancer. Isso não é verdade no GKE no VMware. Por isso, é preciso alocar manualmente um endereço IP para o recurso de gateway de entrada do Anthos Service Mesh.

Para configurar um endereço IP externo, siga uma das seções abaixo, dependendo do modo de balanceamento de carga do cluster:

Configurar o modo de balanceamento de carga integrado

Abra a configuração do serviço istio-ingressgateway:
```
kubectl edit svc -n istio-system istio-ingressgateway
```
A configuração do serviço istio-ingressgateway é aberta no editor de texto padrão do shell.

No arquivo, adicione a seguinte linha no bloco de especificação (spec):

loadBalancerIP: <your static external IP address>

Exemplo:

spec:
 loadBalancerIP: 203.0.113.1

Salve o arquivo.

Configurar o modo de balanceamento de carga manual

Para expor um serviço do tipo NodePort com um endereço IP virtual (VIP) no seu balanceador de carga, consiga os valores nodePort primeiro:

Veja a configuração do serviço istio-ingressgateway no shell:

kubectl get svc -n istio-system istio-ingressgateway -o yaml

Cada uma das portas dos gateways do Anthos Service Mesh é exibida. A resposta ao comando será semelhante à seguinte:

 ...
 ports:
 - name: status-port
   nodePort: 30391
   port: 15020
   protocol: TCP
   targetPort: 15020
 - name: http2
   nodePort: 31380
   port: 80
   protocol: TCP
   targetPort: 80
 - name: https
   nodePort: 31390
   port: 443
   protocol: TCP
   targetPort: 443
 - name: tcp
   nodePort: 31400
   port: 31400
   protocol: TCP
   targetPort: 31400
 - name: https-kiali
   nodePort: 31073
   port: 15029
   protocol: TCP
   targetPort: 15029
 - name: https-prometheus
   nodePort: 30253
   port: 15030
   protocol: TCP
   targetPort: 15030
 - name: https-grafana
   nodePort: 30050
   port: 15031
   protocol: TCP
   targetPort: 15031
 - name: https-tracing
   nodePort: 31204
   port: 15032
   protocol: TCP
   targetPort: 15032
 - name: tls
   nodePort: 30158
   port: 15443
   protocol: TCP
   targetPort: 15443
 ...

Exponha essas portas pelo balanceador de carga.

Por exemplo, a porta de serviço chamada http2 tem port 80 e nodePort 31380. Suponha que os endereços de nó do cluster de usuário sejam 192.168.0.10, 192.168.0.11 e 192.168.0.12, e o VIP do balanceador de carga seja 203.0.113.1.

Configure o balanceador de carga para que o tráfego enviado para 203.0.113.1:80 seja encaminhado para 192.168.0.10:31380, 192.168.0.11:31380 ou 192.168.0.12:31380. É possível selecionar as portas de serviço que quer expor nesse VIP.

A seguir

Implantar o aplicativo de amostra Online Boutique