Configuración del complemento de malla de servicios basado en Istio para Azure Kubernetes Service

Artículo
08/28/2024

Istio de código abierto usa MeshConfig para definir la configuración de toda la malla para la malla de servicios de Istio. El complemento de malla de servicios basado en Istio para AKS se basa en MeshConfig y clasifica las distintas propiedades admitidas, permitidas y bloqueadas.

En este artículo se explica cómo configurar el complemento de malla de servicios basado en Istio para Azure Kubernetes Service y la directiva de soporte técnico aplicable a dicha configuración.

Requisitos previos

En esta guía, se da por supuesto que ha seguido la documentación para habilitar el complemento de Istio en un clúster de AKS.

Configuración en el clúster

Averigüe qué revisión de Istio se implementa en el clúster:

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

Salida:

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

Cree un objeto ConfigMap con el nombre istio-shared-configmap-<asm-revision> en el espacio de nombres aks-istio-system. Por ejemplo, si el clúster ejecuta la revisión asm-1-18 de la malla, ConfigMap debe llamarse istio-shared-configmap-asm-1-18. La configuración de malla debe proporcionarse dentro de la sección de datos bajo la malla.

Ejemplo:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-shared-configmap-asm-1-18
  namespace: aks-istio-system
data:
  mesh: |-
    accessLogFile: /dev/stdout
    defaultConfig:
      holdApplicationUntilProxyStarts: true
```
Los valores bajo defaultConfig son la configuración de todo la malla aplicada para el proxy sidecar de Envoy.

Precaución

Se crea un objeto ConfigMap predeterminado (por ejemplo, istio-asm-1-18 para la revisión asm-1-18) en el espacio de nombres aks-istio-system del clúster cuando el complemento Istio está habilitado. Pero este objeto ConfigMap predeterminado se reconcilia con el complemento administrado Istio y, por tanto, los usuarios NO deben editar directamente este objeto ConfigMap. En su lugar, los usuarios deben crear un objeto ConfigMap compartido de Istio específico de la revisión (por ejemplo istio-shared-configmap-asm-1-18, para la revisión asm-1-18) en el espacio de nombres aks-istio-system y, a continuación, el plano de control de Istio combinará esto con el objeto ConfigMap predeterminado, con la configuración predeterminada teniendo prioridad.

Configuración y actualizaciones de malla

Al realizar la actualización de valor controlado para Istio, debe crear un objeto ConfigMap independiente para la nueva revisión en el espacio de nombres aks-istio-system antes de iniciar la actualización de valor controlado. De este modo, la configuración está disponible cuando se implementa el plano de control de la nueva revisión en el clúster. Por ejemplo, si va a actualizar la malla de asm-1-18 a asm-1-19, debe copiar los cambios de istio-shared-configmap-asm-1-18 para crear un objeto ConfigMap nuevo denominado istio-shared-configmap-asm-1-19 en el espacio de nombres aks-istio-system.

Una vez completada o revertida la actualización, puede eliminar el objeto ConfigMap de la revisión que se quitó del clúster.

Valores permitidos, admitidos y bloqueados de MeshConfig

Los campos de MeshConfig se clasifican como allowed, supported o blocked. Para obtener más información sobre estas categorías, consulte la directiva de soporte para las características y opciones de configuración de los complementos de Istio.

La configuración de malla y la lista de campos permitidos o admitidos son específicas de la revisión para tener en cuenta los campos que se agregan o quitan en las revisiones. La lista completa de campos permitidos y de admitidos o no admitidos dentro de la lista de permitidos se proporciona en la tabla siguiente. Cuando se pone a disposición una nueva revisión de malla, los cambios en la clasificación de permitidos y admitidos de los campos se indican en esta tabla.

MeshConfig

Los campos presentes en la documentación de referencia de MeshConfig de código abierto que no se describen en la tabla siguiente están bloqueados. Por ejemplo, configSources está bloqueado.

Campo	Admitidos o permitidos	Notas
proxyListenPort	Permitidas	-
proxyInboundListenPort	Permitidas	-
proxyHttpPort	Permitidas	-
connectTimeout	Permitidas	Se puede configurar en DestinationRule
tcpKeepAlive	Permitidas	Se puede configurar en DestinationRule
defaultConfig	Compatible	Se usa para configurar ProxyConfig
outboundTrafficPolicy	Compatible	También se puede configurar en Sidecar CR
extensionProviders	Permitidas	-
defaultProviders	Permitidas	-
accessLogFile	Compatible	Este campo aborda la generación de registros de acceso. Para obtener una experiencia administrada sobre la recopilación y consulta de registros, vea Azure Monitor Container Insights en AKS. Se recomienda configurar el registro de acceso a través de la API de telemetría.
accessLogFormat	Compatible	Este campo aborda la generación de registros de acceso. Para obtener una experiencia administrada sobre la recopilación y consulta de registros, vea Azure Monitor Container Insights en AKS
accessLogEncoding	Compatible	Este campo aborda la generación de registros de acceso. Para obtener una experiencia administrada sobre la recopilación y consulta de registros, vea Azure Monitor Container Insights en AKS
enableTracing	Permitidas	Se recomienda configurar el seguimiento a través de la API de telemetría.
enableEnvoyAccessLogService	Compatible	Este campo aborda la generación de registros de acceso. Para obtener una experiencia administrada sobre la recopilación y consulta de registros, vea Azure Monitor Container Insights en AKS
disableEnvoyListenerLog	Compatible	Este campo aborda la generación de registros de acceso. Para obtener una experiencia administrada sobre la recopilación y consulta de registros, vea Azure Monitor Container Insights en AKS
trustDomain	Permitidas	-
trustDomainAliases	Permitidas	-
caCertificates	Permitidas	Se puede configurar en DestinationRule
defaultServiceExportTo	Permitidas	Se puede configurar en ServiceEntry
defaultVirtualServiceExportTo	Permitidas	Se puede configurar en VirtualService
defaultDestinationRuleExportTo	Permitidas	Se puede configurar en DestinationRule
localityLbSetting	Permitidas	Se puede configurar en DestinationRule
dnsRefreshRate	Permitidas	-
h2UpgradePolicy	Permitidas	Se puede configurar en DestinationRule
enablePrometheusMerge	Permitidas	-
discoverySelectors	Compatible	-
pathNormalization	Permitidas	-
defaultHttpRetryPolicy	Permitidas	Se puede configurar en VirtualService
serviceSettings	Permitidas	-
meshMTLS	Permitidas	-
tlsDefaults	Permitidas	-
ingressService	Permitidas	Nombre del servicio Kubernetes usado para el controlador de entrada istio.
ingressSelector	Permitidas	Define qué implementación de puerta de enlace se va a usar como controlador de entrada. Este campo corresponde al campo Gateway.selector y se establecerá como istio: INGRESS_SELECTOR.

ProxyConfig (meshConfig.defaultConfig)

Los campos presentes en la documentación de referencia de MeshConfig de código abierto que no se describen en la tabla siguiente están bloqueados.

Campo	Admitidos o permitidos	Notas
tracingServiceName	Permitidas	Se recomienda configurar el seguimiento a través de la API de telemetría.
drainDuration	Compatible	-
statsUdpAddress	Permitidas	-
proxyAdminPort	Permitidas	-
tracing	Permitidas	Se recomienda configurar el seguimiento a través de la API de telemetría.
simultaneidad	Compatible	-
envoyAccessLogService	Permitidas	Se recomienda configurar el seguimiento a través de la API de telemetría.
envoyMetricsService	Permitidas	Se recomienda configurar la recopilación de métricas a través de la API de telemetría.
proxyMetadata	Permitidas	-
statusPort	Permitidas	-
extraStatTags	Permitidas	-
proxyStatsMatcher	Permitidas	-
terminationDrainDuration	Compatible	-
meshId	Permitidas	-
holdApplicationUntilProxyStarts	Compatible	-
caCertificatesPem	Permitidas	-
privateKeyProvider	Permitidas	-

Precaución

Ámbito de compatibilidad de las configuraciones: la configuración de malla permite configurar proveedores de extensiones como instancias autoadministradas de Zipkin o Apache Skywalking con el complemento de Istio. Pero estos proveedores de extensiones están fuera del ámbito de compatibilidad del complemento de Istio. Los problemas asociados con las herramientas de extensión están fuera del límite de compatibilidad del complemento de Istio.

Sugerencias comunes sobre errores y solución de problemas

Asegúrese de que MeshConfig tiene sangría aplicada con espacios en lugar de pestañas.
Asegúrese de que solo está editando el objeto ConfigMap compartido específico de la revisión (por ejemplo, istio-shared-configmap-asm-1-18) y no intenta editar el objeto ConfigMap predeterminado (por ejemplo, istio-asm-1-18).
ConfigMap debe seguir el nombre istio-shared-configmap-<asm-revision> y estar en el espacio de nombres aks-istio-system.
Asegúrese de que todos los campos de MeshConfig estén escritos correctamente. Si no se reconocen o no forman parte de la lista de permitidos, el control de admisión deniega dichas configuraciones.
Al realizar actualizaciones de valor controlado, compruebe los objetos ConfigMaps específicos de la revisión para asegurarse de que existen configuraciones para las revisiones implementadas en el clúster.
Algunas opciones MeshConfig como accessLogging pueden aumentar el consumo de recursos de Envoy, y deshabilitar algunas de estas opciones de configuración puede mitigar el uso de recursos del plano de datos de Istio. También es aconsejable usar el campo discoverySelectors en MeshConfig para ayudar a aliviar el consumo de memoria para Istio y Envoy.
Si el campo concurrency de MeshConfig está mal configurado y se establece en cero, esto provoca que Envoy use todos los núcleos de CPU. En su lugar, si este campo no está establecido, el número de subprocesos de trabajo que se ejecutarán se determina automáticamente en función de las solicitudes o límites de CPU.
Condiciones de carrera de pod y sidecar en las que se inicia la aplicación antes de que Envoy se pueda mitigar mediante el campo holdApplicationUntilProxyStarts en MeshConfig.

Compartir a través de