Solución de problemas de extensión para clústeres de Kubernetes habilitados para Azure Arc

Artículo
01/09/2025

En este artículo se describen sugerencias para solucionar problemas comunes relacionados con extensiones de clúster como GitOps (Flux v2) en Azure u Open Service Mesh (OSM).

A fin de obtener ayuda para solucionar problemas generales con Kubernetes habilitado para Azure Arc, vea Solución de problemas de Kubernetes habilitado para Azure Arc.

GitOps (Flux v2)

Nota:

Puede usar la extensión Flux v2 en un clúster de Kubernetes habilitado para Azure Arc, o bien en un clúster de Azure Kubernetes Service (AKS). Estas sugerencias de solución de problemas se aplican generalmente a todos los tipos de clúster.

A fin de obtener ayuda general para solucionar problemas relacionados con el uso de recursos fluxConfigurations, ejecute estos comandos de la CLI de Azure con el parámetro --debug:

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug

Errores de simulación de webhook

Es posible que se produzca un error en Flux y se muestre un error similar a dry-run failed, error: admission webhook "<webhook>" does not support dry run. Para resolver el problema, vaya a ValidatingWebhookConfiguration o MutatingWebhookConfiguration. En la configuración, establezca el valor de sideEffects en None o NoneOnDryRun.

Para más información,vea Procedimiento para resolver errores de "webhook no admite la simulación".

Errores al instalar la extensión microsoft.flux

La extensión microsoft.flux instala los controladores de Flux y los agentes de Azure GitOps en el clúster de Kubernetes habilitado para Azure Arc o en el clúster de Azure Kubernetes Service (AKS). Si la extensión aún no está instalada en un clúster y crea un recurso de configuración de GitOps para ese clúster, la extensión se instala automáticamente.

Si experimenta un error durante la instalación, o bien si la extensión muestra un estado Failed, asegúrese de que el clúster no tiene ninguna directiva que restrinja la creación del espacio de nombres flux-system o de cualquiera de los recursos en ese espacio de nombres.

En cuanto a un clúster de AKS, asegúrese de que la marca de característica Microsoft.ContainerService/AKS-ExtensionManager esté habilitada en la suscripción de Azure:

az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager

A continuación, ejecute el comando siguiente para determinar si hay otros problemas. Establezca el parámetro de tipo de clúster (-t) en connectedClusters para un clúster habilitado para Azure Arc o en managedClusters para un clúster de AKS. Si la extensión se ha instalado automáticamente al crear la configuración de GitOps, el nombre de la extensión microsoft.flux es flux.

az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>

La salida puede ayudarle a identificar el problema y a corregirlo. Entre las posibles acciones de corrección se incluyen las siguientes:

Ejecute az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters> para forzar la eliminación de la extensión.
Ejecute helm uninstall flux -n flux-system para desinstalar la versión de Helm.
Ejecute kubectl delete namespaces flux-system para eliminar el espacio de nombres flux-system del clúster.

Después puede crear una configuración de Flux, lo que instala la extensión microsoft.flux automáticamente, o bien puede instalar la extensión Flux manualmente.

Errores al instalar la extensión microsoft.flux en un clúster que tiene una identidad administrada por pod de Microsoft Entra

Si intenta instalar la extensión Flux en un clúster que tiene una identidad administrada pod de Microsoft Entra, se puede producir un error en el pod extension-agent. La salida es similar a este ejemplo:

{"Message":"2021/12/02 10:24:56 Error: in getting auth header : error {adal: Refresh request failed. Status Code = '404'. Response body: no azure identity found for request clientID <REDACTED>\n}","LogType":"ConfigAgentTrace","LogLevel":"Information","Environment":"prod","Role":"ClusterConfigAgent","Location":"westeurope","ArmId":"/subscriptions/<REDACTED>/resourceGroups/<REDACTED>/providers/Microsoft.Kubernetes/managedclusters/<REDACTED>","CorrelationId":"","AgentName":"FluxConfigAgent","AgentVersion":"0.4.2","AgentTimestamp":"2021/12/02 10:24:56"}

El estado de la extensión se devuelve como Failed:

"{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"ExtensionCreationFailed\",\"message\":\" error: Unable to get the status from the local CRD with the error : {Error : Retry for given duration didn't get any results with err {status not populated}}\"}]}}",

En este caso, el pod extension-agent intenta obtener su token de Azure Instance Metadata Service en el clúster, pero la solicitud de token la intercepta la identidad de pod. Para corregir este problema, actualice a la versión más reciente de la microsoft.flux extensión.

Requisitos de recursos de memoria y CPU para instalar la extensión microsoft.flux

Los controladores que se instalen en el clúster de Kubernetes al instalar la extensión microsoft.flux deben tener suficientes recursos de CPU y memoria para la programación correcta en un nodo del clúster de Kubernetes. Asegúrese de que el clúster cumple los requisitos mínimos de recursos de memoria y CPU.

En la tabla siguiente se enumeran los límites mínimos y máximos para los posibles requisitos de recursos de CPU y memoria para este escenario:

Nombre del contenedor	CPU mínima	Memoria mínima	CPU máxima	Memoria máxima
`fluxconfig-agent`	5 m	30 Mi	50 m	150 Mi
`fluxconfig-controller`	5 m	30 Mi	100 m	150 Mi
`fluent-bit`	5 m	30 Mi	20 m	150 Mi
`helm-controller`	100 m	64 Mi	1.000 m	1 Gi
`source-controller`	50 m	64 Mi	1.000 m	1 Gi
`kustomize-controller`	100 m	64 Mi	1.000 m	1 Gi
`notification-controller`	100 m	64 Mi	1.000 m	1 Gi
`image-automation-controller`	100 m	64 Mi	1.000 m	1 Gi
`image-reflector-controller`	100 m	64 Mi	1.000 m	1 Gi

Si ha habilitado una directiva Gatekeeper de Azure Policy personalizada o integrada que limita los recursos de los contenedores en clústeres de Kubernetes, asegúrese de que los límites de recursos de la directiva sean mayores que los límites mostrados en la tabla anterior, o bien que el espacio de nombres flux-system forma parte del parámetro excludedNamespaces en la asignación de la directiva. Un ejemplo de una directiva en este escenario es Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits.

Flux v1

Nota:

Se recomienda que realice la migración a Flux v2 lo antes posible. La compatibilidad con los recursos de configuración de clúster basados en Flux v1 creados antes del 1 de enero de 2024 finaliza el 24 de mayo de 2025. A partir del 1 de enero de 2024, no podrá crear nuevos recursos de configuración de clúster basados en Flux v1.

Para solucionar problemas relacionados con el recurso sourceControlConfigurations en Flux v1, ejecute estos comandos de la CLI de Azure incluido el parámetro --debug:

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug

Container Insights de Azure Monitor

En esta sección se proporciona ayuda para solucionar problemas con Container Insights de Azure Monitor para clústeres de Kubernetes habilitados para Azure Arc.

Habilitación del modo con privilegios para el clúster de Kubernetes Canonical Charmed

Container Insights de Azure Monitor requiere que su DaemonSet de Kubernetes se ejecute en modo con privilegios. Para configurar correctamente un clúster de Canonical Charmed Kubernetes para la supervisión, ejecute el siguiente comando:

juju config kubernetes-worker allow-privileged=true

No se pueden instalar pods de AMA en Oracle Linux 9.x

Si intenta instalar el agente de Azure Monitor (AMA) en un clúster de Kubernetes de Oracle Linux [Red Hat Enterprise Linux (RHEL)] 9.x, es posible que los pods AMA y el pod AMA-RS no funcionen correctamente debido al contenedor addon-token-adapter del pod. Al comprobar los registros del pod ama-logs-rs, en addon-token-adapter container, verá un resultado similar al ejemplo siguiente:

Command: kubectl -n kube-system logs ama-logs-rs-xxxxxxxxxx-xxxxx -c addon-token-adapter
 
Error displayed: error modifying iptable rules: error adding rules to custom chain: running [/sbin/iptables -t nat -N aad-metadata --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory

iptables v1.8.9 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)

Perhaps iptables or your kernel needs to be upgraded.

Este error se produce porque la instalación de la extensión requiere el iptable_nat módulo, pero este módulo no se carga automáticamente en distribuciones de Oracle Linux (RHEL) 9.x.

Para corregir este problema, debe cargar explícitamente el módulo iptables_nat en cada nodo del clúster. Use el comando modprobe de sudo modprobe iptables_nat. Una vez que haya iniciado sesión en cada nodo y agregado eliptable_nat módulo manualmente, vuelva a intentar la instalación de AMA.

Nota:

La realización de este paso no hace que el iptables_nat módulo sea persistente.

Open Service Mesh habilitado para Azure Arc

En esta sección se muestran comandos que puede usar para validar y solucionar problemas de la implementación de los componentes de la extensión Open Service Mesh (OSM) en el clúster.

Comprobación de la implementación del controlador OSM

kubectl get deployment -n arc-osm-system --selector app=osm-controller

Si el controlador de OSM es correcto, verá una salida similar a la siguiente:

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
osm-controller   1/1     1            1           59m

Comprobación de pods del controlador de OSM

kubectl get pods -n arc-osm-system --selector app=osm-controller

Si el controlador OSM es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME                            READY   STATUS    RESTARTS   AGE
osm-controller-b5bd66db-wglzl   0/1     Evicted   0          61m
osm-controller-b5bd66db-wvl9w   1/1     Running   0          31m

Aunque un controlador tiene un estado de Evicted en un momento, otro controlador tiene el estado READY de 1/1 y Running con reinicios de 0. Si el estado READY es distinto de 1/1, la malla del servicio está en un estado interrumpido. Si READY es 0/1, el contenedor del plano de control está bloqueado.

Use el siguiente comando para inspeccionar los registros del controlador:

kubectl logs -n arc-osm-system -l app=osm-controller

Si el estado READY es un número mayor que 1 después de la barra diagonal (/), se instalan sidecars. Por lo general, el controlador OSM no funciona correctamente cuando se adjuntan sidecars.

Comprobación del servicio del controlador OSM

Para comprobar el servicio del controlador OSM, ejecute este comando:

kubectl get service -n arc-osm-system osm-controller

Si el controlador OSM es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME             TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)              AGE
osm-controller   ClusterIP   10.0.31.254   <none>        15128/TCP,9092/TCP   67m

Nota:

El valor real de CLUSTER-IP será diferente al de este ejemplo. Los valores de NAME y PORT(S) deben coincidir con lo que se muestra en este ejemplo.

Comprobación de los puntos de conexión del controlador de OSM

kubectl get endpoints -n arc-osm-system osm-controller

Si el controlador OSM es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME             ENDPOINTS                              AGE
osm-controller   10.240.1.115:9092,10.240.1.115:15128   69m

Si el clúster no tiene una instancia de ENDPOINTS que tenga el valor osm-controller, el plano de control es incorrecto. Este estado incorrecto significa que el pod del controlador se bloqueó o que nunca se implementó correctamente.

Comprobación de la implementación del inyector de OSM

kubectl get deployments -n arc-osm-system osm-injector

Si el inyector de OSM es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
osm-injector   1/1     1            1           73m

Comprobación del pod del inyector de OSM

kubectl get pod -n arc-osm-system --selector app=osm-injector

Si el inyector de OSM es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME                            READY   STATUS    RESTARTS   AGE
osm-injector-5986c57765-vlsdk   1/1     Running   0          73m

El estado READY debe ser 1/1. Cualquier otro valor indica un pod de inyector de OSM incorrecto.

Comprobación del servicio del inyector de OSM

kubectl get service -n arc-osm-system osm-injector

Si el inyector de OSM es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
osm-injector   ClusterIP   10.0.39.54   <none>        9090/TCP   75m

Asegúrese de que la dirección IP que aparece para el servicio osm-injector es 9090. No debe aparecer ningún valor para EXTERNAL-IP.

Comprobación de los puntos de conexión del inyector de OSM

kubectl get endpoints -n arc-osm-system osm-injector

Si el inyector de OSM es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Para que OSM funcione, debe haber al menos un punto de conexión para osm-injector. La dirección IP de los puntos de conexión del inyector de OSM varía, pero el valor del puerto 9090 debe ser el mismo.

Comprobación de webhooks: validación y mutación

Ejecute el siguiente comando para comprobar el webhook de validación:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Si el webhook de validación es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME                     WEBHOOKS   AGE
osm-validator-mesh-osm   1          81m

Ejecute el siguiente comando para comprobar el webhook de mutación:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Si el webhook de mutación es correcto, aparece una salida similar a la del ejemplo siguiente:

NAME                  WEBHOOKS   AGE
arc-osm-webhook-osm   1          102m

Compruebe el servicio y la agrupación de entidad de certificación (agrupación de CA) del webhook de validación mediante este comando:

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'

Un webhook de validación bien configurado tiene una salida similar a la de este ejemplo:

{
  "name": "osm-config-validator",
  "namespace": "arc-osm-system",
  "path": "/validate",
  "port": 9093
}

Compruebe el servicio y el paquete de CA del webhook de mutación mediante la ejecución del siguiente comando:

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'

Un webhook de mutación bien configurado tiene una salida similar a la de este ejemplo:

{
  "name": "osm-injector",
  "namespace": "arc-osm-system",
  "path": "/mutate-pod-creation",
  "port": 9090
}

Compruebe si el controlador OSM ha proporcionado al webhook de validación (o de mutación) una agrupación de CA mediante el comando siguiente:

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c

Ejemplo:

El número de la salida indica el número de bytes o el tamaño de la agrupación de CA. Si la salida está vacía, es 0 o un número inferior a 1.000, la agrupación de CA no se aprovisiona correctamente. Sin una agrupación de CA correcta, se produce un error en ValidatingWebhook.

Comprobación del recurso `osm-mesh-config`

Compruebe que el recurso exista:

kubectl get meshconfig osm-mesh-config -n arc-osm-system

Compruebe el valor del ajuste meshconfig de OSM:

kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml

Busque una salida similar a la de este ejemplo:

apiVersion: config.openservicemesh.io/v1alpha1
kind: MeshConfig
metadata:
  creationTimestamp: "0000-00-00A00:00:00A"
  generation: 1
  name: osm-mesh-config
  namespace: arc-osm-system
  resourceVersion: "2494"
  uid: 6c4d67f3-c241-4aeb-bf4f-b029b08faa31
spec:
  certificate:
    certKeyBitSize: 2048
    serviceCertValidityDuration: 24h
  featureFlags:
    enableAsyncProxyServiceMapping: false
    enableEgressPolicy: true
    enableEnvoyActiveHealthChecks: false
    enableIngressBackendPolicy: true
    enableMulticlusterMode: false
    enableRetryPolicy: false
    enableSnapshotCacheMode: false
    enableWASMStats: true
  observability:
    enableDebugServer: false
    osmLogLevel: info
    tracing:
      enable: false
  sidecar:
    configResyncInterval: 0s
    enablePrivilegedInitContainer: false
    logLevel: error
    resources: {}
  traffic:
    enableEgress: false
    enablePermissiveTrafficPolicyMode: true
    inboundExternalAuthorization:
      enable: false
      failureModeAllow: false
      statPrefix: inboundExtAuthz
      timeout: 1s
    inboundPortExclusionList: []
    outboundIPRangeExclusionList: []
    outboundPortExclusionList: []
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

En la tabla siguiente se enumeran los valores del recurso osm-mesh-config:

Clave	Tipo	Valor predeterminado	Ejemplos de comandos de revisión de Kubectl
`spec.traffic.enableEgress`	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enableEgress":false}}}' --type=merge`
`spec.traffic.enablePermissiveTrafficPolicyMode`	bool	`true`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enablePermissiveTrafficPolicyMode":true}}}' --type=merge`
`spec.traffic.outboundPortExclusionList`	array	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge`
`spec.traffic.outboundIPRangeExclusionList`	array	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundIPRangeExclusionList":["10.0.0.0/32","1.1.1.1/24"]}}}' --type=merge`
`spec.traffic.inboundPortExclusionList`	array	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge`
`spec.certificate.serviceCertValidityDuration`	string	`"24h"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"certificate":{"serviceCertValidityDuration":"24h"}}}' --type=merge`
`spec.observability.enableDebugServer`	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"enableDebugServer":false}}}' --type=merge`
`spec.observability.osmLogLevel`	string	`"info"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"osmLogLevel": "info"}}}}' --type=merge`
`spec.observability.tracing.enable`	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"enable":true}}}}' --type=merge`
`spec.sidecar.enablePrivilegedInitContainer`	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"enablePrivilegedInitContainer":true}}}' --type=merge`
`spec.sidecar.logLevel`	string	`"error"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"logLevel":"error"}}}' --type=merge`
`spec.featureFlags.enableWASMStats`	bool	`"true"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableWASMStats":"true"}}}' --type=merge`
`spec.featureFlags.enableEgressPolicy`	bool	`"true"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEgressPolicy":"true"}}}' --type=merge`
`spec.featureFlags.enableMulticlusterMode`	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableMulticlusterMode":"false"}}}' --type=merge`
`spec.featureFlags.enableSnapshotCacheMode`	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableSnapshotCacheMode":"false"}}}' --type=merge`
`spec.featureFlags.enableAsyncProxyServiceMapping`	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableAsyncProxyServiceMapping":"false"}}}' --type=merge`
`spec.featureFlags.enableIngressBackendPolicy`	bool	`"true"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableIngressBackendPolicy":"true"}}}' --type=merge`
`spec.featureFlags.enableEnvoyActiveHealthChecks`	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEnvoyActiveHealthChecks":"false"}}}' --type=merge`

Comprobación de espacios de nombres

Nota:

El espacio de nombres arc-osm-system nunca participa en una malla de servicios y nunca se etiqueta ni anota con los pares clave/valor que se muestran aquí.

Puede usar el comando osm namespace add para unir espacios de nombres a una malla de servicios determinada. Cuando un espacio de nombres de Kubernetes forma parte de la malla, siga estos pasos para confirmar que se cumplen los requisitos.

Vea las anotaciones del espacio de nombres bookbuyer:

kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'

Las siguientes anotaciones deben estar presentes:

{
  "openservicemesh.io/sidecar-injection": "enabled"
}

Vea las etiquetas del espacio de nombres bookbuyer:

kubectl get namespace bookbuyer -o json | jq '.metadata.labels'

La siguiente etiqueta debe estar presente:

{
  "openservicemesh.io/monitored-by": "osm"
}

Si no usa la CLI de osm, puede agregar manualmente estas anotaciones a los espacios de nombres. Si un espacio de nombres no está anotado con "openservicemesh.io/sidecar-injection": "enabled", o no está etiquetado con "openservicemesh.io/monitored-by": "osm", el inyector de OSM no agrega sidecars de Envoy.

Nota:

Después osm namespace add se llama, solo las nuevos pods se inyectan con un sidecar Envoy. Los pods existentes deben reiniciarse mediante el comando kubectl rollout restart deployment.

Comprobación de las CRD de SMI

Para la interfaz de malla de servicios (SMI) de OSM, compruebe si el clúster tiene las definiciones de recursos personalizadas (CRD) necesarias:

kubectl get crds

Asegúrese de que las CRD se corresponden a las versiones disponibles en la rama de versión. Para confirmar qué versiones CRD están en uso, vea Versiones compatibles con SMI y seleccione la versión en el menú Versiones.

Obtenga las versiones de las CRD instaladas con el siguiente comando:

for x in $(kubectl get crds --no-headers | awk '{print $1}' | grep 'smi-spec.io'); do
    kubectl get crd $x -o json | jq -r '(.metadata.name, "----" , .spec.versions[].name, "\n")'
done

Si faltan las CRD, use los siguientes comandos para instalarlas en el clúster. Reemplace la versión de estos comandos según sea necesario (por ejemplo, en lugar de v1.1.0, podría usar release-v1.1).

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_http_route_group.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_tcp_route.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_access.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_split.yaml

Para ver cómo cambian las versiones de CRD entre versiones, vea las notas de la versión de OSM.

Solución de problemas de administración de certificados

Para obtener información sobre cómo OSM emite y administra certificados para servidores proxy de Envoy que se ejecutan en pods de aplicación, vea la documentación de OSM.

Actualización de Envoy

Cuando se crea un pod en un espacio de nombres supervisado por el complemento, OSM inyecta un sidecar de proxy de Envoy en ese pod. Si es necesario actualizar la versión de Envoy, siga los pasos de la Guía de actualización en la documentación de OSM.

Obtenga más información sobre las extensiones de clúster.
Vea sugerencias generalesde solución de problemas para clústeres de Kubernetes habilitados para Arc.

Compartir a través de

Solución de problemas de extensión para clústeres de Kubernetes habilitados para Azure Arc

GitOps (Flux v2)

Errores de simulación de webhook

Errores al instalar la extensión microsoft.flux

Errores al instalar la extensión microsoft.flux en un clúster que tiene una identidad administrada por pod de Microsoft Entra

Requisitos de recursos de memoria y CPU para instalar la extensión microsoft.flux

Flux v1

Container Insights de Azure Monitor

Habilitación del modo con privilegios para el clúster de Kubernetes Canonical Charmed

No se pueden instalar pods de AMA en Oracle Linux 9.x

Open Service Mesh habilitado para Azure Arc

Comprobación de la implementación del controlador OSM

Comprobación de pods del controlador de OSM

Comprobación del servicio del controlador OSM

Comprobación de los puntos de conexión del controlador de OSM

Comprobación de la implementación del inyector de OSM

Comprobación del pod del inyector de OSM

Comprobación del servicio del inyector de OSM

Comprobación de los puntos de conexión del inyector de OSM

Comprobación de webhooks: validación y mutación

Comprobación del recurso `osm-mesh-config`

Comprobación de espacios de nombres

Comprobación de las CRD de SMI

Solución de problemas de administración de certificados

Actualización de Envoy

Comentarios

Recursos adicionales

Compartir a través de

Solución de problemas de extensión para clústeres de Kubernetes habilitados para Azure Arc

GitOps (Flux v2)

Errores de simulación de webhook

Errores al instalar la extensión microsoft.flux

Errores al instalar la extensión microsoft.flux en un clúster que tiene una identidad administrada por pod de Microsoft Entra

Requisitos de recursos de memoria y CPU para instalar la extensión microsoft.flux

Flux v1

Container Insights de Azure Monitor

Habilitación del modo con privilegios para el clúster de Kubernetes Canonical Charmed

No se pueden instalar pods de AMA en Oracle Linux 9.x

Open Service Mesh habilitado para Azure Arc

Comprobación de la implementación del controlador OSM

Comprobación de pods del controlador de OSM

Comprobación del servicio del controlador OSM

Comprobación de los puntos de conexión del controlador de OSM

Comprobación de la implementación del inyector de OSM

Comprobación del pod del inyector de OSM

Comprobación del servicio del inyector de OSM

Comprobación de los puntos de conexión del inyector de OSM

Comprobación de webhooks: validación y mutación

Comprobación del recurso osm-mesh-config

Comprobación de espacios de nombres

Comprobación de las CRD de SMI

Solución de problemas de administración de certificados

Actualización de Envoy

Contenido relacionado

Comentarios

Recursos adicionales

Comprobación del recurso `osm-mesh-config`