Como ativar recursos opcionais no plano de controle no cluster

Nesta página, descrevemos como ativar recursos opcionais em um plano de controle no cluster. Para informações sobre o plano de controle gerenciado, consulte Configurar o Anthos Service Mesh gerenciado.

Quando você instala o Anthos Service Mesh, os recursos que são ativados por padrão diferem por plataforma. Para ativar os recursos opcionais, inclua um arquivo de sobreposição ao instalar (ou fazer upgrade) do Anthos Service Mesh. Um arquivo de sobreposição é um arquivo YAML que contém um recurso personalizado (CR, na sigla em inglês) IstioOperator usado para configurar o plano de controle. É possível substituir a configuração padrão e ativar um recurso opcional ou desativar um recurso padrão em um arquivo de sobreposição. Especifique um recurso por arquivo de sobreposição. É possível usar mais camadas, e cada arquivo de sobreposição substitui a configuração nas camadas anteriores.

Cuidado: o uso de asmcli install substitui a configuração do plano de controle atual. Ao ativar recursos opcionais em uma instalação existente, especifique todos os arquivos que você quer manter na configuração original e os arquivos de sobreposição dos recursos que você quer ativar. É recomendável armazenar os arquivos de sobreposição que você usa para instalação no controle de origem para ser possível aplicar as mesmas configurações ao plano de controle com upgrades ou ao ativar outros recursos opcionais.

.

Sobre os arquivos de sobreposição

Os arquivos de sobreposição nesta página estão no pacote anthos-service-mesh (em inglês) no GitHub. Esses arquivos contêm personalizações comuns da configuração padrão. É possível usar esses arquivos como estão ou fazer outras alterações neles conforme necessário.

Ao instalar o Anthos Service Mesh usando o script asmcli fornecido pelo Google, é possível especificar um ou mais arquivos de sobreposição com as opções --option ou --custom_overlay. Caso você não precise fazer mudanças nos arquivos no repositório anthos-service-mesh, use --option, e o script busca o arquivo no GitHub para você. Caso contrário, faça alterações no arquivo de sobreposição e use a opção --custom_overlay para transmiti-lo para o asmcli.

Importante :não especifique mais de uma resposta automática IstioOperator em um arquivo de sobreposição, porque istioctl install só aplica a primeira resposta automática encontrada no arquivo.

Não inclua várias respostas automáticas em um arquivo de sobreposição	Crie arquivos de sobreposição separados para cada resposta automática

Como ativar recursos opcionais

Os exemplos a seguir são simplificados para mostrar apenas o uso de sobreposições personalizadas para ativar recursos opcionais. Substitua OTHER_FLAGS pelas outras opções de linha de comando.

Importante: a ordem dos arquivos na linha de comando é considerada. Primeiro, especifique a configuração necessária para os recursos padrão e, depois, os arquivos de sobreposição.

O comando asmcli install oferece duas maneiras de ativar um recurso opcional. O método usado depende se você precisa fazer alterações no arquivo de sobreposição.

• Use --option quando não precisar fazer alterações no arquivo de sobreposição. Com --option, asmcli busca o arquivo do repositório do GitHub para você. Portanto, é necessário ter uma conexão com a Internet.

  ./asmcli install \
    OTHER_FLAGS \
    --option OPTION_NAME
  

  Substitua OPTION_NAME pela opção que você quer ativar. Para ver uma lista de opções, consulte o pacote anthos-service-mesh.

• Use --custom_overlay quando precisar personalizar o arquivo de sobreposição.

  ./asmcli install \
    OTHER_FLAGS \
    --custom_overlay PATH_TO_FILE
  

  Substitua PATH_TO_FILE pelo caminho para o arquivo de sobreposição que você quer usar.

YAML para recursos opcionais

As seções a seguir fornecem o YAML para ativar recursos opcionais e compatíveis.

Modo mTLS STRICT

A configuração global.mtls.enabled foi removida da resposta automática IstioOperator para evitar problemas com upgrades e fornecer uma instalação mais flexível. Para ativar o mTLS STRICT, configure uma política de autenticação de peering.

Imagem de proxy distroless

Como prática recomendada, restrinja o conteúdo de um ambiente de execução do contêiner apenas aos pacotes necessários. Essa abordagem melhora a segurança e a proporção de sinal para ruído dos verificadores de vulnerabilidades e exposições comuns (CVEs, na sigla em inglês). O Istio fornece imagens de proxy com base em imagens de base distroless.

A configuração a seguir ativa imagens distroless para todo o Anthos Service Mesh. Uma alteração no tipo de imagem requer que cada pod seja reiniciado e seja reinjetado para entrar em vigor.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      image:
        imageType: distroless

A imagem distroless não contém binários além do proxy. Portanto, não é possível aplicar exec a um shell ou usar curl, ping ou outros utilitários de depuração no contêiner. Se você tentar executar um shell, verá o seguinte erro.

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "<container-id>"
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown

Se você precisar de acesso a essas ferramentas para pods específicos, modifique o imageType usando a anotação de pod a seguir.

sidecar.istio.io/proxyImageType: debug

Após alterar o tipo de imagem de uma implantação pela anotação, a implantação precisa ser reiniciada.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Para a maioria dos tipos de depuração de proxy, o istioctl proxy-cmd precisa ser usado, o que não exige uma imagem base de depuração.

Usar uma sobreposição personalizada para o registro personalizado

Use uma sobreposição personalizada para registros personalizados, por exemplo, se você precisar instalar o Anthos Service Mesh a partir de um registro de contêiner personalizado. Exemplo:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  hub: {private_registry_url}

Veja a seguir uma lista de imagens do Anthos Service Mesh que você precisa espelhar no registro de contêineres personalizado:

• Instalação-CNI: gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
• Plano de dados gerenciado: gcr.io/gke-release/asm/mdp:1.13.9-asm.10
• PILOTOgcr.io/gke-release/asm/pilot:1.13.9-asm.10
• PROXY_V2 gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10

Observação: se você usar um serviço canônico, você também precisa espelhar os registros de contêiner personalizados gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 e gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16.

Adicionar imagens a um registro particular

Para enviar imagens do Anthos Service Mesh para um registro particular, siga as etapas a seguir.

Observação: use um cliente que possa ser acessado de gcr.io e enviado para o registro particular.

1. Extraia as imagens do Anthos Service Mesh:

   docker pull gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
   docker pull gcr.io/gke-release/asm/mdp:1.13.9-asm.10
   docker pull gcr.io/gke-release/asm/pilot:1.13.9-asm.10
   docker pull gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10
   docker pull gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
   

2. Crie uma variável para o URL do registro particular:

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   Substitua PRIVATE_REGISTRY_URL pelo URL do registro particular.
3. Marque com tag as imagens com o URL do registro particular:

   docker tag gcr.io/gke-release/asm/install-cni:1.13.9-asm.10 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
   docker tag gcr.io/gke-release/asm/mdp:1.13.9-asm.10 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.13.9-asm.10
   docker tag gcr.io/gke-release/asm/pilot:1.13.9-asm.10 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.13.9-asm.10
   docker tag gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10
   docker tag gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10 \
    ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
   

4. Envie as imagens marcadas com tag para o registro particular:

   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.13.9-asm.10
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.13.9-asm.10
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
   

5. (Opcional) Se você usar um serviço canônico, adicione as imagens de serviço canônicos ao registro particular.
   1. Extraia as imagens de serviço canônico do Anthos Service Mesh:

              docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0
              docker pull gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              

   2. Marque com tag as imagens com o URL do registro particular:

              docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0
              docker tag gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              

   3. Envie as imagens marcadas com tag para o registro particular:

              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/kube-rbac-proxy:v0.5.0
              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              

Se for possível extrair as imagens marcadas com tag do registro particular, o procedimento foi bem-sucedido.

Envoy direto para stdout

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Para mais informações, consulte Ativar a geração de registros de acesso do Envoy.

Cloud Trace

O Cloud Trace está disponível com instalações do Anthos Service Mesh nas seguintes plataformas:

• GKE no Google Cloud
• Clusters do GKE Enterprise no local se você instalar com a autoridade de certificação do Anthos Service Mesh (CA da malha)

Para informações detalhadas de preço do Cloud Trace, consulte esta página.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

A taxa de amostragem padrão é de 1%, mas é possível substituir o padrão especificando um valor tracing.sampling. O valor precisa estar no intervalo de 0,0 a 100,0 com uma precisão de 0,01. Por exemplo, para gerar traces de cinco solicitações de cada 10.000, use 0,05.

O exemplo a seguir mostra uma taxa de amostragem de 100%, que é o que você faria apenas para fins de demonstração ou solução de problemas.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
  values:
    global:
      proxy:
        tracer: stackdriver

Atualmente, a configuração do rastreador faz parte da configuração de inicialização do proxy. Por isso, o pod precisa ser reiniciado e reinjetado para coletar a atualização do rastreador. Por exemplo, é possível usar o comando a seguir para reiniciar os pods de uma implantação:

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Propagação do contexto de trace

Os proxies secundários podem enviar períodos de trace automaticamente, mas eles precisam de algumas dicas para unir todo o trace. Os aplicativos precisam propagar os cabeçalhos HTTP apropriados para que, quando os proxies enviarem informações de período, os períodos possam ser correlacionados corretamente em um único trace.

Para fazer isso, um aplicativo precisa coletar e propagar os cabeçalhos apropriados da solicitação de entrada para qualquer solicitação de saída: A configuração de rastreamento do Anthos Service Mesh Stackdriver aceitará qualquer um dos seguintes formatos de cabeçalho e propagará todos os seguintes formatos:

• B3 (x-b3-traceid, x-b3-spanid, x-b3parentspanid, x-b3-sampled, x-b3-flags)
• W3C TraceContext (traceparent)
• Google Cloud Trace (x-cloud-trace-context)
• gRPC TraceBin (grpc-trace-bin)

Isso significa que os aplicativos podem usar qualquer um desses formatos para propagar o contexto de rastreamento, e os traces serão gerados e definidos adequadamente para o Stackdriver.

Exemplo

Veja um exemplo de solicitação HTTP-Get com um cabeçalho traceparent na solicitação original. Observe os cabeçalhos adicionais de contexto de trace adicionados pelo proxy.

$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
*   Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
  "args": {
    "freeform": ""
  },
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
    "Host": "httpbin:8000",
    "Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
    "User-Agent": "curl/7.80.0-DEV",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "a0c798646d74cef0",
    "X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
    "X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
    "X-Envoy-Attempt-Count": "1",
    "X-Forwarded-Client-Cert": "<REDACTED>"
  },
  "json": null,
  "method": "GET",
  "origin": "127.0.0.6",
  "url": "http://httpbin:8000/anything?freeform="
}

No conjunto retornado de cabeçalhos de solicitação, o conjunto completo de cabeçalhos de contexto de trace está presente.

Para mais exemplos de propagação dos cabeçalhos, consulte Rastrear a propagação de contexto.

Criar um trace do cliente com um ID personalizado.

Para criar um trace de um cliente com um ID personalizado, use o comando curl para criar uma solicitação com um cliente externo e forçá-lo a mostrar um trace. Exemplo:

curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"

Para mais informações sobre x-client-trace-id, consulte a documentação do Envoy (em inglês).

Observação: se você estiver testando os contêineres secundários do Anthos Service Mesh que enviam dados do Cloud Trace usando a demonstração de microsserviços do Google, desative a funcionalidade integrada do Cloud Trace. A microservices-demo consegue enviar dados do Cloud Trace sem o Istio. Não desativar essa funcionalidade resultará em rastreamentos duplicados, porque o contêiner do aplicativo e o secundário enviarão rastros. Há várias variáveis DISABLE_TRACING para configurar no arquivo de versão de demonstração de microsserviços.

Saída por meio de gateways

Recomendamos que você instale um gateway injetado, conforme descrito em Instalar e fazer upgrade de gateways.

Interface de rede de contêiner do Istio

A forma como você ativa a interface de rede de contêiner do Istio (CNI, na sigla em inglês) depende do ambiente em que o Anthos Service Mesh está instalado.

1. Ative uma política de rede.

2. Escolha o arquivo de sobreposição que corresponde à plataforma.

Ativar a CNI no GKE

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /home/kubernetes/bin
      excludeNamespaces:
        - istio-system
        - kube-system

Ativar CNI no local

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /opt/cni/bin
      excludeNamespaces:
        - istio-system
        - kube-system
        - gke-system

Ativar a observabilidade do Google Cloud para fora do Google Cloud

A instalação do Anthos Service Mesh com o Istio CA fora do Google Cloud informa as métricas ao Prometheus por padrão. Use essa opção para ativar as métricas de relatórios para a observabilidade do Google Cloud ou para o Prometheus e o Stackdriver, a fim de usar os painéis do Anthos Service Mesh.

Somente Stackdriver

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: false
        stackdriver:
          enabled: true

Stackdriver e Prometheus

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
        stackdriver:
          enabled: true

Ativar um balanceador de carga interno

Recomendamos que você instale um gateway injetado conforme descrito em Instalar e atualizar gateways para configurar um balanceador de carga interno no GKE. Ao configurar o serviço de gateway, inclua a anotação: networking.gke.io/load-balancer-type: "Internal"

Gerenciamento de certificados externos no gateway de entrada

Para informações sobre como ativar o gerenciamento de certificados externos no gateway de entrada usando o Envoy SDS, consulte Gateways seguros.