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

Artículo
04/18/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 de Istio está habilitado. Sin embargo, este objeto ConfigMap predeterminado se reconcilia con el complemento administrado de 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-systemantes 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

Los campos de MeshConfig se clasifican en tres categorías:

Bloqueados: los campos no permitidos se bloquean a través de webhooks de admisión administrada de complementos. El servidor de API publica inmediatamente el mensaje de error al usuario indicando que no se permite el campo.
Admitidos: los campos admitidos (por ejemplo, los campos relacionados con el registro de acceso) reciben soporte del soporte técnico de Azure.
Permitidos: se permiten estos campos (como proxyListenPort o proxyInboundListenPort), pero no están cubiertos por el soporte técnico de Azure.

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

Campo	Compatible	Notas
proxyListenPort	false	-
proxyInboundListenPort	false	-
proxyHttpPort	false	-
connectTimeout	false	Se puede configurar en DestinationRule
tcpKeepAlive	false	Se puede configurar en DestinationRule
defaultConfig	true	Se usa para configurar ProxyConfig
outboundTrafficPolicy	true	También se puede configurar en Sidecar CR
extensionProviders	false	-
defaultProviders	false	-
accessLogFile	true	-
accessLogFormat	true	-
accessLogEncoding	true	-
enableTracing	true	-
enableEnvoyAccessLogService	true	-
disableEnvoyListenerLog	true	-
trustDomain	false	-
trustDomainAliases	false	-
caCertificates	false	Se puede configurar en DestinationRule
defaultServiceExportTo	false	Se puede configurar en ServiceEntry
defaultVirtualServiceExportTo	false	Se puede configurar en VirtualService
defaultDestinationRuleExportTo	false	Se puede configurar en DestinationRule
localityLbSetting	false	Se puede configurar en DestinationRule
dnsRefreshRate	false	-
h2UpgradePolicy	false	Se puede configurar en DestinationRule
enablePrometheusMerge	true	-
discoverySelectors	true	-
pathNormalization	false	-
defaultHttpRetryPolicy	false	Se puede configurar en VirtualService
serviceSettings	false	-
meshMTLS	false	-
tlsDefaults	false	-

ProxyConfig (meshConfig.defaultConfig)

Campo	Compatible
tracingServiceName	true
drainDuration	true
statsUdpAddress	false
proxyAdminPort	false
tracing	true
simultaneidad	true
envoyAccessLogService	true
envoyMetricsService	true
proxyMetadata	false
statusPort	false
extraStatTags	false
proxyStatsMatcher	false
terminationDrainDuration	true
meshId	false
holdApplicationUntilProxyStarts	true
caCertificatesPem	false
privateKeyProvider	false

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

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. Sin embargo, 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