Configurar o complemento de malha de serviço baseado em Istio para o Serviço Kubernetes do Azure

Artigo
04/16/2024

O Istio de código aberto usa MeshConfig para definir configurações de malha para a malha de serviço do Istio. O complemento de malha de serviço baseado em Istio para AKS se baseia no MeshConfig e classifica diferentes propriedades como suportadas, permitidas e bloqueadas.

Este artigo explica como configurar o complemento de malha de serviço baseado em Istio para o Serviço Kubernetes do Azure e a política de suporte aplicável a essa configuração.

Pré-requisitos

Este guia pressupõe que você seguiu a documentação para habilitar o complemento Istio em um cluster AKS.

Configurar a configuração no cluster

Descubra qual revisão do Istio é implantada no cluster:

az aks show --name $CLUSTER --resource-group $RESOURCE_GROUP --query 'serviceMeshProfile'

Resultado:

{
  "istio": {
      "certificateAuthority": null,
      "components": {
      "egressGateways": null,
      "ingressGateways": null
      },
      "revisions": [
      "asm-1-18"
      ]
  },
  "mode": "Istio"
}

Crie um ConfigMap com o nome istio-shared-configmap-<asm-revision> no aks-istio-system namespace. Por exemplo, se o cluster estiver executando a revisão asm-1-18 da malha, o ConfigMap precisará ser nomeado como istio-shared-configmap-asm-1-18. A configuração de malha deve ser fornecida dentro da seção de dados em malha.

Exemplo:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-shared-configmap-asm-1-18
  namespace: aks-istio-system
data:
  mesh: |-
    accessLogFile: /dev/stdout
    defaultConfig:
      holdApplicationUntilProxyStarts: true
```
Os valores abaixo defaultConfig são configurações de malha aplicadas ao proxy do sidecar Envoy.

Atenção

Um ConfigMap padrão (por exemplo, istio-asm-1-18 para revisão asm-1-18) é criado no aks-istio-system namespace no cluster quando o addon Istio está habilitado. No entanto, este ConfigMap padrão é reconciliado pelo addon Istio gerenciado e, portanto, os usuários NÃO devem editar diretamente este ConfigMap. Em vez disso, os usuários devem criar um ConfigMap compartilhado Istio específico de revisão (por exemplo istio-shared-configmap-asm-1-18 , para revisão asm-1-18) no namespace aks-istio-system e, em seguida, o plano de controle Istio mesclará isso com o ConfigMap padrão, com as configurações padrão tendo precedência.

Configuração e upgrades de malha

Ao executar a atualização canary para o Istio, você precisa criar um ConfigMap separado para a nova revisão no aks-istio-system namespace antes de iniciar a atualização canary. Dessa forma, a configuração estará disponível quando o plano de controle da nova revisão for implantado no cluster. Por exemplo, se você estiver atualizando a malha de asm-1-18 para asm-1-19, precisará copiar as alterações de istio-shared-configmap-asm-1-18 para criar um novo ConfigMap chamado istio-shared-configmap-asm-1-19 no aks-istio-system namespace.

Depois que a atualização for concluída ou revertida, você poderá excluir o ConfigMap da revisão que foi removida do cluster.

Valores permitidos, suportados e bloqueados

Os campos em MeshConfig são classificados em três categorias:

Bloqueado: Os campos não permitidos são bloqueados através de webhooks de admissão gerenciados por addon. O servidor de API publica imediatamente a mensagem de erro para o usuário informando que o campo não é permitido.
Com suporte: os campos suportados (por exemplo, campos relacionados com o registo de acesso) recebem suporte do suporte do Azure.
Permitido: esses campos (como proxyListenPort ou proxyInboundListenPort) são permitidos, mas não são cobertos pelo suporte do Azure.

A configuração de malha e a lista de campos permitidos/suportados são revisões específicas para levar em conta os campos que estão sendo adicionados/removidos nas revisões. A lista completa de campos permitidos e os campos suportados/não suportados dentro da lista de permitidos é fornecida na tabela abaixo. Quando uma nova revisão de malha é disponibilizada, quaisquer alterações na classificação permitida e suportada dos campos são anotadas nesta tabela.

MeshConfig

Campo	Suportado	Notas
proxyListenPort	false	-
proxyInboundListenPort	false	-
proxyHttpPort	false	-
connectTimeout	false	Configurável em DestinationRule
tcpKeepAlive	false	Configurável em DestinationRule
defaultConfig	verdadeiro	Usado para configurar ProxyConfig
outboundTrafficPolicy	verdadeiro	Também configurável em Sidecar CR
extensionProviders	false	-
defaultProvedores	false	-
accessLogFile [en]	verdadeiro	-
accessLogFormat	verdadeiro	-
accessLogEncoding	verdadeiro	-
habilitarRastreamento	verdadeiro	-
enableEnvoyAccessLogService	verdadeiro	-
disableEnvoyListenerLog	verdadeiro	-
trustDomain	false	-
trustDomainAliases	false	-
caCertificados	false	Configurável em DestinationRule
defaultServiceExportTo	false	Configurável em ServiceEntry
defaultVirtualServiceExportTo	false	Configurável no VirtualService
defaultDestinationRuleExportTo	false	Configurável em DestinationRule
localidadeLbSetting	false	Configurável em DestinationRule
dnsRefreshRate	false	-
h2UpgradePolicy	false	Configurável em DestinationRule
habilitarPrometheusMerge	verdadeiro	-
discoverySelectores	verdadeiro	-
pathNormalização	false	-
defaultHttpRetryPolicy	false	Configurável no VirtualService
serviceSettings	false	-
malhaMTLS	false	-
tlsDefaults	false	-

ProxyConfig (meshConfig.defaultConfig)

Campo	Suportado
tracingServiceName	verdadeiro
drenagemDuração	verdadeiro
statsUdpAddress	false
proxyAdminPort	false
rastreio	verdadeiro
simultaneidade	verdadeiro
envoyAccessLogService	verdadeiro
envoyMetricsService	verdadeiro
proxyMetadados	false
statusPort	false
extraStatTags	false
proxyStatsMatcher	false
terminationDrainDuration	verdadeiro
meshId	false
holdApplicationUntilProxyStarts	verdadeiro
caCertificatesPem	false
privateKeyProvider	false

Os campos presentes na documentação de referência do MeshConfig de código aberto, mas não na tabela acima, são bloqueados. Por exemplo, configSources está bloqueado.

Atenção

Escopo de suporte de configurações: A configuração Mesh permite que provedores de extensão, como instâncias autogerenciadas do Zipkin ou Apache Skywalk, sejam configurados com o addon Istio. No entanto, esses provedores de extensão estão fora do escopo de suporte do Istio addon. Quaisquer problemas associados às ferramentas de extensão estão fora do limite de suporte do addon Istio.

Erros comuns e dicas de solução de problemas

Certifique-se de que o MeshConfig está recuado com espaços em vez de guias.
Certifique-se de que você está editando apenas o ConfigMap compartilhado específico da revisão (por exemplo istio-shared-configmap-asm-1-18) e não está tentando editar o ConfigMap padrão (por exemplo istio-asm-1-18).
O ConfigMap deve seguir o nome istio-shared-configmap-<asm-revision> e estar no aks-istio-system namespace.
Certifique-se de que todos os campos MeshConfig estão escritos corretamente. Se eles não forem reconhecidos ou se não fizerem parte da lista de permitidos, o controle de admissão negará tais configurações.
Ao executar atualizações canárias, verifique seus ConfigMaps específicos de revisão para garantir que as configurações existam para as revisões implantadas em seu cluster.
Certas MeshConfig opções, como accessLogging, podem aumentar o consumo de recursos do Envoy, e desativar algumas dessas configurações pode reduzir a utilização de recursos do plano de dados do Istio. Também é aconselhável usar o campo no MeshConfig para ajudar a aliviar o discoverySelectors consumo de memória para Istiod e Envoy.
Se o concurrency campo no MeshConfig estiver configurado incorretamente e definido como zero, isso fará com que o Envoy use todos os núcleos da CPU. Em vez disso, se esse campo estiver desdefinido, o número de threads de trabalho a serem executados será determinado automaticamente com base nas solicitações/limites da CPU.
Condições de corrida de pod e sidecar nas quais o aplicativo começa antes do Envoy podem ser atenuadas usando o holdApplicationUntilProxyStarts campo no MeshConfig.

Partilhar via