Leer en inglés

Compartir a través de


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

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

  1. 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"
    }
    
  2. 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.