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

Artículo
10/16/2024

En este documento se proporcionan sugerencias para solucionar problemas comunes relacionados con las extensiones de clúster, como GitOps (Flux v2) y Open Service Mesh.

Para obtener ayuda para solucionar problemas generales con Kubernetes habilitado para Azure Arc, consulte Solución de problemas de Kubernetes habilitados para Azure Arc.

GitOps (Flux v2)

Nota:

La extensión Flux v2 se puede usar en clústeres de Kubernetes habilitados para Azure Arc o en clústeres de Azure Kubernetes Service (AKS). Estas sugerencias de solución de problemas se aplican generalmente independientemente del tipo de clúster.

Para solucionar problemas relacionados con el recurso fluxConfigurations (Flux v2), ejecute estos comandos de la CLI de Azure con el parámetro --debug especificado:

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

Webhook y errores de simulacro

Si observa que Flux no se concilia y muestra un error como dry-run failed, error: admission webhook "<webhook>" does not support dry run, puede resolver el problema buscando los elementos ValidatingWebhookConfiguration o MutatingWebhookConfiguration y estableciendo sideEffects en None o NoneOnDryRun:

Para más información, consulte ¿Cómo se resuelven los errores webhook does not support dry run?

Errores al instalar la `microsoft.flux` extensión

La extensión microsoft.flux instala los controladores de Flux y los agentes de Azure GitOps en los clústeres de Kubernetes habilitado para Azure Arc o Azure Kubernetes Service (AKS). Si la extensión aún no está instalada en un clúster y se 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 si la extensión está en estado de error, asegúrese de que el clúster no tiene ninguna directiva que restrinja la creación del flux-system espacio de nombres o los recursos en ese espacio de nombres.

En cuanto a los clústeres de AKS, asegúrese de que la suscripción tenga habilitada la marca de Microsoft.ContainerService/AKS-ExtensionManagercaracterística.

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

Después, ejecute este comando para determinar si hay otros problemas. Establezca el parámetro de tipo de clúster (-t) en connectedClusters para un clúster habilitado para Arc o managedClusters para un clúster de AKS. El nombre de la microsoft.fluxextensión es "flux" si la extensión se instaló automáticamente durante la creación de la configuración de una instancia de GitOps. Busque información en el objeto statuses.

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

Los resultados mostrados pueden ayudarle a determinar qué salió mal y cómo corregirlo. Entre las posibles acciones de corrección se incluyen las siguientes:

Forzar la eliminación de la extensión mediante la ejecución de az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>
Desinstalación de la versión de Helm mediante la ejecución helm uninstall flux -n flux-system
Elimine el flux-system espacio de nombres del clúster mediante la ejecución de kubectl delete namespaces flux-system

Después de eso, puede volver a crear una configuraciónde flujo, que instala la microsoft.flux extensión automáticamente o puede volver a instalar la extensión de flujo manualmente.

Errores al instalar la `microsoft.flux` en un clúster con la identidad de Pod de Microsoft Entra habilitada

Si intenta instalar la extensión de Flux en un clúster que tenga habilitada la identidad de pod de Microsoft Entra, puede producirse un error en el pod del agente de extensión:

{"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 tambié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 IMDS en el clúster. pero la identidad del pod intercepta la solicitud de token. Para corregir este problema, actualice a la versión más reciente de la microsoft.flux extensión.

Problemas con la identidad de kubelet al instalar la `microsoft.flux` extensión en un clúster de AKS

Con los clústeres de AKs, una de las opciones de autenticación es la identidad de kubelet mediante una identidad administrada asignada por el usuario. El uso de la identidad kubelet puede reducir la sobrecarga operativa y aumenta la seguridad al conectarse a recursos de Azure como Azure Container Registry.

Para permitir que Flux use la identidad de kubelet, agregue el parámetro --config useKubeletIdentity=true al instalar la extensión Flux.

az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config useKubeletIdentity=true

Asegurarse de que se cumplen los requisitos de memoria y del CPU para la `microsoft.flux` instalación de extensiones

Los controladores que se instalen en el clúster de Kubernetes mediante microsoft.flux la extensión requieren recursos de CPU y memoria para programar correctamente en los nodos del clúster de Kubernetes. Asegúrese de que el clúster puede satisfacer los recursos mínimos de memoria y del CPU que se pueden solicitar. Tenga en cuenta también los límites máximos para los posibles requisitos de recursos de CPU y memoria que se muestran aquí.

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	1000 m	1 Gi
source-controller	50 m	64 Mi	1000 m	1 Gi
kustomize-controller	100 m	64 Mi	1000 m	1 Gi
notification-controller	100 m	64 Mi	1000 m	1 Gi
image-automation-controller	100 m	64 Mi	1000 m	1 Gi
image-reflector-controller	100 m	64 Mi	1000 m	1 Gi

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

Flux v1

Nota:

Se recomienda migrar 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 finalizará 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 relacionadossourceControlConfigurations con el recurso (Flux v1), ejecute estos comandos de la CLI de Azure con el parámetro --debug especificado:

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.

Activación del modo privilegiado para el clúster Canonical Charmed Kubernetes

Azure Monitor Container Insights requiere que su DaemonSet se ejecute en modo privilegiado. 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 puede instalar el agente de Azure Monitor (AMA) en Oracle Linux 9.x

Al intentar instalar el agente de Azure Monitor (AMA) en un clúster de Kubernetes de Oracle Linux (RHEL) 9.x, es posible que los pods AMA y el pod AMA-RS no funcionen correctamente debido al addon-token-adapter contenedor del pod. Con este error, al comprobar los registros del ama-logs-rs pod, addon-token-adapter container, verá una salida similar a la 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 iptables_nat módulo en cada nodo del clúster, mediante el modprobe comando 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 proporcionan comandos que puede usar para validar y solucionar problemas de la implementación de los componentes de extensión Open Service Mesh (OSM) en el clúster.

Comprobación de la implementación del controlador de 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 de OSM es correcto, verá una salida similar a la 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 haya sido desalojado en algún momento, hay otro que lo está READY 1/1 y Running con 0 reinicios. Si el valor de la columna READY es distinto de 1/1, la malla del servicio está en un estado interrumpido. Una columna READY que tiene el valor 0/1 indica que el contenedor del plano de control se está bloqueado.

Use el siguiente comando para inspeccionar los registros del controlador:

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

La columna READY con un número mayor que 1 después de la / indica que hay sidecars instalados. Por lo general, el controlador OSM no funcionará correctamente con sidecars conectados.

Comprobación del servicio de controlador de OSM

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

Si el estado del controlador de OSM es correcto, se mostrará la siguiente salida:

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

Nota:

El CLUSTER-IP será diferente. El servicio NAME y PORT(S) debe coincidir con lo que se muestra aquí.

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

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

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

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

Si el clúster no tiene ENDPOINTS para 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, verá una salida similar a la 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, verá una salida similar a la siguiente:

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

La columna 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, verá una salida similar a la 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 debería ser una 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, verá una salida similar a la 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 variará, pero el puerto 9090 debe ser el mismo.

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

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Si el webhook de Validación es correcto, verá una salida similar a la siguiente:

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

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Si el mutar webhook es correcto, verá un resultado similar al siguiente:

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

Compruebe el servicio y el paquete de CA del webhook de Validación mediante este comando:

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

La configuración correcta de un webhook de Validación tendrá una salida similar a:

{
  "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'

La configuración correcta de un webhook de mutación tendrá una salida similar al:

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

Compruebe si el controlador de OSM ha otorgado un paquete de CA al webhook de validación (o de mutación) 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 del paquete de CA. Si la salida está vacía, 0 o un número inferior a 1000, la agrupación de CA no se aprovisiona correctamente. Sin una agrupación de CA correcta, el ValidatingWebhook produce un error.

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

Compruebe que el recurso exista:

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

Compruebe el contenido del recurso MeshConfig de OSM:

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

Debería mostrarse una salida similar a esta:

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: ""

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 participará en una malla de servicio ni se etiquetará o anotará con la clave o los valores que se muestran aquí.

Usamos el comando osm namespace add para unir espacios de nombres a una malla de servicio 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 osm CLI, también 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 agregará sidecars de Envoy.

Nota:

Después de que se llame a osm namespace add, solo se insertarán los pods con un sidecar de Envoy. Los pods existentes deben reiniciarse con el kubectl rollout restart deployment comando.

Comprobación de las CRD de SMI

Compruebe si el clúster tiene las definiciones de recursos personalizadas (CRD) necesarias mediante el siguiente comando:

kubectl get crds

Asegúrese de que las CRD corresponden a las versiones disponibles en la rama de versión. Para confirmar qué versiones CRD están en uso, visite la página versiones compatibles con SMI y seleccione la versión en la lista desplegable Versiones.

Obtenga las versiones de los CRD instalados 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, v1.1.0 sería la versión-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

Consulte las notas de la versión de OSM para ver los cambios que se producen entre las distintas versiones de CRD.

Solución de problemas de administración de certificados

Para obtener más información sobre cómo OSM emite y administra certificados en servidores proxy de Envoy que se ejecutan en pods de aplicación, consulte el sitio de documentación de OSM.

Actualización de Envoy

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

Pasos siguientes

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)

Webhook y errores de simulacro

Errores al instalar la `microsoft.flux` extensión

Errores al instalar la `microsoft.flux` en un clúster con la identidad de Pod de Microsoft Entra habilitada

Problemas con la identidad de kubelet al instalar la `microsoft.flux` extensión en un clúster de AKS

Asegurarse de que se cumplen los requisitos de memoria y del CPU para la `microsoft.flux` instalación de extensiones

Flux v1

Container Insights de Azure Monitor

Activación del modo privilegiado para el clúster Canonical Charmed Kubernetes

No se puede instalar el agente de Azure Monitor (AMA) en Oracle Linux 9.x

Open Service Mesh habilitado para Azure Arc

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

Comprobación de pods del controlador de OSM

Comprobación del servicio de controlador de 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 los webhooks de 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

Pasos siguientes

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)

Webhook y errores de simulacro

Errores al instalar la microsoft.flux extensión

Errores al instalar la microsoft.flux en un clúster con la identidad de Pod de Microsoft Entra habilitada

Problemas con la identidad de kubelet al instalar la microsoft.flux extensión en un clúster de AKS

Asegurarse de que se cumplen los requisitos de memoria y del CPU para la microsoft.flux instalación de extensiones

Flux v1

Container Insights de Azure Monitor

Activación del modo privilegiado para el clúster Canonical Charmed Kubernetes

No se puede instalar el agente de Azure Monitor (AMA) en Oracle Linux 9.x

Open Service Mesh habilitado para Azure Arc

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

Comprobación de pods del controlador de OSM

Comprobación del servicio de controlador de 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 los webhooks de 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

Pasos siguientes

Comentarios

Recursos adicionales

Errores al instalar la `microsoft.flux` extensión

Errores al instalar la `microsoft.flux` en un clúster con la identidad de Pod de Microsoft Entra habilitada

Problemas con la identidad de kubelet al instalar la `microsoft.flux` extensión en un clúster de AKS

Asegurarse de que se cumplen los requisitos de memoria y del CPU para la `microsoft.flux` instalación de extensiones

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