Ative funcionalidades opcionais num plano de controlo no cluster

Esta página descreve como ativar funcionalidades opcionais na Cloud Service Mesh com um plano de controlo no cluster.

Quando instala o Cloud Service Mesh no cluster, as funcionalidades ativadas por predefinição variam consoante a plataforma. Pode substituir a configuração predefinida e ativar uma funcionalidade opcional incluindo um ficheiro de sobreposição quando instala (ou atualiza) o Cloud Service Mesh. Um ficheiro de sobreposição é um ficheiro YAML que contém um recurso personalizado (CR) IstioOperatorque usa para configurar o plano de controlo. Especifique um elemento por ficheiro de sobreposição. Pode aplicar mais sobreposições, e cada ficheiro de sobreposição substitui a configuração nas camadas anteriores.

Aviso: a utilização de asmcli install substitui a configuração do plano de controlo existente. Quando ativa funcionalidades opcionais numa instalação existente, certifique-se de que especifica todos os ficheiros que quer manter na configuração original, bem como os ficheiros de sobreposição das funcionalidades que quer ativar. Recomendamos que armazene os ficheiros de sobreposição que usa para a instalação no controlo de origem, para que possa aplicar as mesmas configurações ao seu plano de controlo com atualizações ou quando ativar funcionalidades opcionais adicionais. Isto garante que não há tempo de inatividade quando ativa funcionalidades opcionais.

Acerca dos ficheiros de sobreposição

Os ficheiros de sobreposição nesta página estão no pacote anthos-service-mesh no GitHub. Estes ficheiros contêm personalizações comuns à configuração predefinida. Pode usar estes ficheiros tal como estão ou fazer alterações adicionais conforme necessário.

Quando instala o Cloud Service Mesh através do script asmcli, pode especificar um ou mais ficheiros de sobreposição com as opções --option ou --custom_overlay. Se não precisar de fazer alterações aos ficheiros no repositório anthos-service-mesh, pode usar o comando --option, e o script obtém o ficheiro do GitHub por si. Caso contrário, pode fazer alterações ao ficheiro de sobreposição e, em seguida, usar a opção --custom_overlay para o passar para o asmcli.

Importante: não especifique mais do que um IstioOperator CR num ficheiro de sobreposição, porque istioctl install só aplica o primeiro CR que encontrar no ficheiro.

Não inclua vários CRs num ficheiro de sobreposição	Crie ficheiros de sobreposição separados para cada CR

Como ativar funcionalidades opcionais

Os exemplos seguintes foram simplificados para mostrar apenas a utilização das sobreposições personalizadas para ativar funcionalidades opcionais. Substitua OTHER_FLAGS pelos indicadores de instalação necessários.

Importante: a ordem dos ficheiros na linha de comandos é importante. Certifique-se de que especifica primeiro a configuração necessária para as funcionalidades predefinidas e, em seguida, os ficheiros de sobreposição.

O comando asmcli install oferece duas formas de ativar uma funcionalidade opcional. O método que usa depende de precisar de fazer alterações ao ficheiro de sobreposição.

• Use --option quando não precisar de fazer alterações ao ficheiro de sobreposição. Com --option, asmcli obtém o ficheiro do repositório do GitHub por si, pelo que tem de ter uma ligação à Internet.

  ./asmcli install \
    OTHER_FLAGS \
    --option OPTION_NAME
  

  Substitua OPTION_NAME pela opção que quer ativar. Certifique-se de que omite a extensão .yaml e inclui apenas o nome do ficheiro de sobreposição, como iap-operator e attached-cluster. Para ver uma lista de opções, consulte o pacote anthos-service-mesh.

• Use --custom_overlay quando precisa de personalizar o ficheiro de sobreposição.

  ./asmcli install \
    OTHER_FLAGS \
    --custom_overlay PATH_TO_FILE
  

  Substitua PATH_TO_FILE pelo caminho para o ficheiro de sobreposição que quer usar.

YAML para funcionalidades opcionais

As secções seguintes fornecem o YAML para ativar funcionalidades opcionais e suportadas.

Modo STRICT mTLS

A configuração global.mtls.enabled foi removida do IstioOperator CR para evitar problemas com as atualizações e oferecer uma instalação mais flexível. Para ativar o STRICT mTLS, configure uma política de autenticação de pares.

Imagem de proxy sem distribuição

Como prática recomendada, deve restringir o conteúdo de um tempo de execução do contentor apenas aos pacotes necessários. Esta abordagem melhora a segurança e a relação sinal/ruído dos scanners de vulnerabilidades e exposições comuns (CVE). O Istio fornece imagens de proxy baseadas em imagens de base sem distribuição.

A seguinte configuração ativa as imagens sem distribuição para toda a malha de serviços na nuvem. Uma alteração do tipo de imagem requer que cada pod seja reiniciado e reinjetado para entrar em vigor.

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

A imagem sem distribuição não contém binários além do proxy. Por conseguinte, não é possível exec um shell nem usar curl, ping ou outras utilidades de depuração no contentor.

Se executar um comando curl, é apresentado 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: unable to start container process: exec: "curl": executable file not found in $PATH: unknown

Se executar um comando de shell, é apresentado 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 precisar de aceder a estas ferramentas para pods específicos, pode substituir o imageType através da seguinte anotação de pod.

sidecar.istio.io/proxyImageType: debug

Após alterar o tipo de imagem de uma implementação através da anotação, a implementação deve ser reiniciada.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Para a maioria dos tipos de depuração de proxy, deve usar-se istioctl proxy-cmd, que não requer uma imagem base de depuração.

Use uma sobreposição personalizada para um registo personalizado

Pode usar uma sobreposição personalizada para registos personalizados, por exemplo, se precisar de instalar o Cloud Service Mesh a partir de um registo de contentores personalizado. Por exemplo:

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

Segue-se uma lista de imagens do Cloud Service Mesh que tem de duplicar para o registo de contentores personalizado:

• Install-cni - gke.gcr.io/asm/install-cni:1.23.6-asm.11
• Plano de dados gerido – gke.gcr.io/asm/mdp:1.23.6-asm.11
• Pilot - gke.gcr.io/asm/pilot:1.23.6-asm.11
• Proxyv2 – gke.gcr.io/asm/proxyv2:1.23.6-asm.11

Nota: se usar um serviço canónico, também tem de duplicar os registos de contentores personalizados gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 e gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16.

Adicione imagens a um registo privado

Para enviar imagens do Cloud Service Mesh para um registo privado, conclua os passos seguintes.

Nota: use um cliente a partir do qual possa extrair dados de gcr.io e enviá-los para o seu registo privado.

1. Extraia as imagens do Cloud Service Mesh:

   docker pull gke.gcr.io/asm/install-cni:1.23.6-asm.11
   docker pull gke.gcr.io/asm/mdp:1.23.6-asm.11
   docker pull gke.gcr.io/asm/pilot:1.23.6-asm.11
   docker pull gke.gcr.io/asm/proxyv2:1.23.6-asm.11
   

2. Crie uma variável para o URL do seu registo privado:

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   Substitua PRIVATE_REGISTRY_URL pelo URL do seu registo privado.
3. Etiquete as imagens com o URL do seu registo privado:

   docker tag gke.gcr.io/asm/install-cni:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.6-asm.11
   docker tag gke.gcr.io/asm/mdp:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.6-asm.11
   docker tag gke.gcr.io/asm/pilot:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.6-asm.11
   docker tag gke.gcr.io/asm/proxyv2:1.23.6-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.6-asm.11
   

4. Envie as imagens etiquetadas para o seu registo privado:

   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.6-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.6-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.6-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.6-asm.11
   

5. (Opcional) Se usar um serviço canónico, adicione as imagens do serviço canónico ao seu registo privado.
   1. Extraia as imagens do serviço canónico do Cloud Service Mesh:

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

   2. Etiquete as imagens com o URL do seu registo privado:

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

   3. Envie as imagens etiquetadas para o seu registo privado:

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

Se conseguir extrair as imagens etiquetadas do seu registo privado, o procedimento foi bem-sucedido.

Aumentar a duração da drenagem de encerramento

Por predefinição, o Envoy aguarda cinco segundos (5s) para que as ligações existentes sejam concluídas quando um pod está a terminar.

O valor de terminationGracePeriodSeconds tem de ser superior ao valor de terminationDrainDuration.

Para mais informações, consulte Opções de malha global.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      terminationDrainDuration: 30s

Ative os registos de acesso

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

Para mais informações, consulte o artigo Ative o registo de acesso do Envoy.

Cloud Trace

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

• GKE no Google Cloud
• Clusters do GKE Enterprise no local se instalar com a autoridade de certificação do Cloud Service Mesh

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

Para mais informações, consulte o artigo Aceder a rastreios.

Saída através de gateways de saída

Recomendamos que instale um gateway injetado, conforme descrito no artigo Instale e atualize gateways.

Interface de rede de contentores do Istio

A forma como ativa a interface de rede de contentores (CNI) do Istio depende do ambiente no qual o Cloud Service Mesh está instalado.

1. Ative uma política de rede.

2. Escolha o ficheiro de sobreposição adequado à sua plataforma.

Ative 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

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

Ative os registos de tráfego paraGoogle Cloud

A instalação do Cloud Service Mesh com a AC do Istio fora do Google Cloud comunica métricas ao Prometheus por predefinição. Use esta opção para ativar os relatórios de registos de tráfego ou o Prometheus e o Stackdriver, para poder usar os painéis de controlo do Cloud Service Mesh.

Apenas 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

Ative um balanceador de carga interno

Recomendamos que instale um gateway injetado, conforme descrito no artigo Instale e atualize gateways, para configurar um balanceador de carga interno no GKE. Quando configura o serviço de gateway, inclui a anotação: networking.gke.io/load-balancer-type: "Internal"

Gestão de certificados externos no gateway de entrada

Para obter informações sobre como ativar a gestão de certificados externos no gateway de entrada através do SDS do Envoy, consulte o artigo Gateways seguros.