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 plano de controle gerenciado, consulte Configure o Cloud Service Mesh gerenciado.
Quando você instala o Cloud Service Mesh no cluster, a
os recursos ativados por padrão variam de acordo com a plataforma.
É possível modificar a configuração padrão e ativar um recurso opcional
incluindo um arquivo de sobreposição ao instalar (ou fazer upgrade) o Cloud 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. 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.
Sobre os arquivos de sobreposição
Os arquivos de sobreposição nesta página estão no
pacote anthos-service-mesh
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.
Quando você instala o Cloud Service Mesh usando o
asmcli
, você
você pode especificar um ou mais arquivos de sobreposição com --option
ou
Opções de --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
.
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
flags de instalação necessárias.
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. Lembre-se de omitir a extensão .yaml e incluir apenas o nome do arquivo de sobreposição, comoiap-operator
eattached-cluster
. Para conferir uma lista de opções, consulte o pacoteanthos-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 Cloud 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ê executar um comando curl, o seguinte erro será exibido:
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 você executar um comando de shell, o seguinte erro vai aparecer.
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 Cloud Service Mesh a partir de um registro de contêiner personalizado. Exemplo:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
hub: {private_registry_url}
Confira a seguir uma lista de imagens do Cloud Service Mesh que você precisa espelhar para o Container Registry personalizado:
- Instalação-CNI:
gke.gcr.io/asm/install-cni:1.23.2-asm.2
- Plano de dados gerenciado:
gke.gcr.io/asm/mdp:1.23.2-asm.2
- PILOTO
gke.gcr.io/asm/pilot:1.23.2-asm.2
- PROXY_V2
gke.gcr.io/asm/proxyv2:1.23.2-asm.2
Adicionar imagens a um registro particular
Para enviar imagens do Cloud Service Mesh a um registro particular, siga as etapas a seguir.
-
Extraia as imagens do Cloud Service Mesh:
docker pull gke.gcr.io/asm/install-cni:1.23.2-asm.2 docker pull gke.gcr.io/asm/mdp:1.23.2-asm.2 docker pull gke.gcr.io/asm/pilot:1.23.2-asm.2 docker pull gke.gcr.io/asm/proxyv2:1.23.2-asm.2
-
Crie uma variável para o URL do registro particular:
Substituaexport PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
PRIVATE_REGISTRY_URL
pelo URL do registro particular. -
Marque com tag as imagens com o URL do registro particular:
docker tag gke.gcr.io/asm/install-cni:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.2-asm.2 docker tag gke.gcr.io/asm/mdp:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.2-asm.2 docker tag gke.gcr.io/asm/pilot:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.2-asm.2 docker tag gke.gcr.io/asm/proxyv2:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.2-asm.2
- Envie as imagens marcadas com tag para o registro particular:
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.2-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.2-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.2-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.2-asm.2
- (Opcional) Se você usar um
serviço canônico, adicione as
imagens de serviço canônicos ao registro particular.
- Extraia as imagens de serviço canônicas 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
- Marque com tag as imagens com o URL do registro particular:
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
- Envie as imagens marcadas com tag para o registro particular:
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
- Extraia as imagens de serviço canônicas do Cloud Service Mesh:
Se for possível extrair as imagens marcadas com tag do registro particular, o procedimento foi bem-sucedido.
Aumentar a duração da drenagem do encerramento
Por padrão, o Envoy aguardará cinco segundos (5s
) para que as conexões existentes sejam concluídas quando um pod for encerrado.
O pod terminationGracePeriodSeconds
precisa ser maior que terminationDrainDuration
.
Para mais informações, consulte Opções globais de malha.
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
defaultConfig:
terminationDrainDuration: 30s
Ativar registros de acesso
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 Cloud Service Mesh nas seguintes plataformas:
- GKE no Google Cloud
- clusters do GKE Enterprise no local se você instalar com Autoridade de certificação do Cloud Service Mesh
Para mais informações, consulte Como acessar traces.
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 (CNI, na sigla em inglês) do Istio depende de: o ambiente em que o Cloud Service Mesh está instalado.
Escolha o arquivo de sobreposição que corresponde à plataforma.
Ativar a CNI no GKE
Ativar CNI no local
Ativar os registros de tráfego fora do Google Cloud
Como instalar o Cloud Service Mesh com o Istio CA fora dos relatórios do Google Cloud para o Prometheus por padrão. Use essa opção para ativar os relatórios de registro do tráfego ou do Prometheus e do Stackdriver. Assim, é possível usar os painéis do Cloud Service Mesh.
Somente Stackdriver
Stackdriver e Prometheus
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.