Problemen met extensies voor Kubernetes-clusters met Azure Arc oplossen

  • Artikel

Dit document bevat tips voor probleemoplossing voor veelvoorkomende problemen met betrekking tot clusterextensies, zoals GitOps (Flux v2) en Open Service Mesh.

Zie Problemen met Kubernetes met Azure Arc oplossen voor hulp bij het oplossen van algemene problemen met Kubernetes met Azure Arc.

GitOps (Flux v2)

Notitie

De Flux v2-extensie kan worden gebruikt in Kubernetes-clusters met Azure Arc of AKS-clusters (Azure Kubernetes Service). Deze tips voor probleemoplossing zijn over het algemeen van toepassing, ongeacht het clustertype.

Voer deze Azure CLI-opdrachten uit met de --debug opgegeven parameter voor algemene hulp bij het oplossen van problemen met fluxConfigurations resources:

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

Webhook-/drooguitvoeringsfouten

Als u ziet dat Flux niet kan worden afgestemd op een fout zoalsdry-run failed, error: admission webhook "<webhook>" does not support dry run, kunt u het probleem oplossen door het probleem te vinden of door MutatingWebhookConfiguration het ValidatingWebhookConfiguration in te stellen sideEffects op None ofNoneOnDryRun:

Zie Hoe kan ik fouten oplossen webhook does not support dry run voor meer informatie?

Fouten bij het installeren van de microsoft.flux extensie

Met microsoft.flux de extensie worden de Flux-controllers en Azure GitOps-agents geïnstalleerd in uw Azure Arc-clusters met Kubernetes of Azure Kubernetes Service (AKS). Als de extensie nog niet is geïnstalleerd in een cluster en u een GitOps-configuratieresource voor dat cluster maakt, wordt de extensie automatisch geïnstalleerd.

Als er een fout optreedt tijdens de installatie of als de extensie de status Mislukt heeft, moet u ervoor zorgen dat het cluster geen beleid heeft dat het maken van de flux-system naamruimte of resources in die naamruimte beperkt.

Zorg ervoor dat voor een AKS-cluster de Microsoft.ContainerService/AKS-ExtensionManager functievlag is ingeschakeld voor het abonnement.

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

Voer daarna deze opdracht uit om te bepalen of er andere problemen zijn. Stel de parameter clustertype (-t) in op connectedClusters voor een cluster met Arc of managedClusters voor een AKS-cluster. De naam van de microsoft.flux extensie is 'flux' als de extensie automatisch is geïnstalleerd tijdens het maken van een GitOps-configuratie. Zoek in het object statuses naar informatie.

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

Met de weergegeven resultaten kunt u bepalen wat er fout is gegaan en hoe u dit kunt oplossen. Mogelijke herstelacties zijn:

  • De extensie forceren door de extensie uit te voeren az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>
  • Verwijder de Helm-release door uit te voeren helm uninstall flux -n flux-system
  • Verwijder de flux-system naamruimte uit het cluster door deze uit te voeren kubectl delete namespaces flux-system

Daarna kunt u een fluxconfiguratie opnieuw maken, waarmee de microsoft.flux extensie automatisch wordt geïnstalleerd, of u kunt de flux-extensie handmatig opnieuw installeren.

Fouten bij het installeren van de microsoft.flux extensie in een cluster waarvoor Microsoft Entra Pod Identity is ingeschakeld

Als u de Flux-extensie wilt installeren in een cluster waarvoor Microsoft Entra Pod Identity is ingeschakeld, kan er een fout optreden in de extensie-agentpod:

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

De extensiestatus wordt ook geretourneerd als 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}}\"}]}}",

In dit geval probeert de extensieagent-pod het token op te halen uit IMDS op het cluster. maar de tokenaanvraag wordt onderschept door de pod-identiteit). U kunt dit probleem oplossen door een upgrade uit te voeren naar de nieuwste versie van de microsoft.flux extensie.

Problemen met kubelet-identiteit bij het installeren van de microsoft.flux extensie in een AKS-cluster

Met AKs-clusters is een van de verificatieopties kubelet-identiteit met behulp van een door de gebruiker toegewezen beheerde identiteit. Het gebruik van kubelet-identiteit kan de operationele overhead verminderen en de beveiliging verhogen bij het maken van verbinding met Azure-resources, zoals Azure Container Registry.

Als u Flux kubelet-identiteit wilt laten gebruiken, voegt u de parameter --config useKubeletIdentity=true toe bij het installeren van de Flux-extensie.

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

Ervoor zorgen dat aan de geheugen- en CPU-vereisten voor microsoft.flux de installatie van extensies wordt voldaan

De controllers die zijn geïnstalleerd in uw Kubernetes-cluster met de microsoft.flux extensie, vereisen CPU- en geheugenbronnen om goed te plannen op Kubernetes-clusterknooppunten. Zorg ervoor dat uw cluster kan voldoen aan het minimumgeheugen en de CPU-resources die kunnen worden aangevraagd. Houd ook rekening met de maximale limieten voor de vereisten voor cpu- en geheugenresources die hier worden weergegeven.

Containernaam Minimale CPU Minimumgeheugen Maximale CPU Maximumgeheugen
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
broncontroller 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

Als u een aangepast of ingebouwd Azure Gatekeeper-beleid hebt ingeschakeld waarmee de resources voor containers in Kubernetes-clusters worden beperkt, zoals Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits, moet u ervoor zorgen dat de resourcelimieten voor het beleid groter zijn dan de hier weergegeven limieten, of dat de flux-system naamruimte deel uitmaakt van de excludedNamespaces parameter in de beleidstoewijzing.

Flux v1

Notitie

U wordt aangeraden zo snel mogelijk naar Flux v2 te migreren. Ondersteuning voor op Flux v1 gebaseerde clusterconfiguratiebronnen die vóór 1 januari 2024 zijn gemaakt, eindigt op 24 mei 2025. Vanaf 1 januari 2024 kunt u geen nieuwe op Flux v1 gebaseerde clusterconfiguratiebronnen maken.

Voer deze Azure CLI-opdrachten uit met --debug de opgegeven parameter om problemen met de sourceControlConfigurations resource in Flux v1 op te lossen:

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

Azure Monitor Container Insights

Deze sectie biedt hulp bij het oplossen van problemen met Azure Monitor Container Insights voor Kubernetes-clusters met Azure Arc.

Bevoegde modus inschakelen voor Canonical Charmed Kubernetes-cluster

Azure Monitor Container Insights vereist dat de DaemonSet wordt uitgevoerd in de bevoegde modus. Voer de volgende opdracht uit om een Canonical Charmed Kubernetes-cluster in te stellen voor bewaking:

juju config kubernetes-worker allow-privileged=true

Kan Azure Monitor Agent (AMA) niet installeren in Oracle Linux 9.x

Wanneer u de Azure Monitor Agent (AMA) probeert te installeren op een Kubernetes-cluster van Oracle Linux (RHEL) 9.x, werken de AMA-pods en de AMA-RS-pod mogelijk niet goed vanwege de addon-token-adapter container in de pod. Met deze fout ziet u bij het controleren van de logboeken van de ama-logs-rs pod addon-token-adapter containeruitvoer die er ongeveer als volgt uitziet:

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.

Deze fout treedt op omdat voor het installeren van de extensie de iptable_nat module is vereist, maar deze module wordt niet automatisch geladen in Distributies van Oracle Linux (RHEL) 9.x.

U kunt dit probleem oplossen door de iptables_nat module expliciet te laden op elk knooppunt in het cluster met behulp van de modprobe opdracht sudo modprobe iptables_nat. Nadat u zich bij elk knooppunt hebt aangemeld en de iptable_nat module handmatig hebt toegevoegd, voert u de AMA-installatie opnieuw uit.

Notitie

Als u deze stap uitvoert, blijft de iptables_nat module niet persistent.

Open Service Mesh met Azure Arc

Deze sectie bevat opdrachten die u kunt gebruiken voor het valideren en oplossen van problemen met de implementatie van de Open Service Mesh-extensieonderdelen (OSM) in uw cluster.

Implementatie van OSM-controller controleren

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

Als de OSM-controller in orde is, ziet u uitvoer die vergelijkbaar is met:

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

OSM-controllerpods controleren

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

Als de OSM-controller in orde is, ziet u uitvoer die vergelijkbaar is met:

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

Hoewel de ene controller op een bepaald moment is verwijderd , is er een andere die is READY 1/1 en Running met 0 opnieuw opstarten. Als de kolom READY iets anders is dan 1/1, heeft de service-mesh een verbroken status. Kolom READY met 0/1 geeft aan dat de container van het besturingsvlak vastloopt.

Gebruik de volgende opdracht om controllerlogboeken te inspecteren:

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

Kolom READY met een getal hoger dan 1 na de / geeft aan dat er sidecars zijn geïnstalleerd. OSM Controller werkt over het algemeen niet goed met sidecars gekoppeld.

Controleer de OSM-controllerservice

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

Als de OSM-controller in orde is, ziet u de volgende uitvoer:

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

Notitie

De CLUSTER-IP zal anders zijn. De service NAME en PORT(S) moet overeenkomen met wat hier wordt weergegeven.

OsM-controllereindpunten controleren

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

Als de OSM-controller in orde is, ziet u uitvoer die vergelijkbaar is met:

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

Als het cluster geen ENDPOINTSosm-controllervoor heeft, is het besturingsvlak niet in orde. Deze beschadigde status betekent dat de controllerpod is vastgelopen of dat deze nooit correct is geïmplementeerd.

Implementatie van OSM-injector controleren

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

Als de OSM-injector in orde is, ziet u uitvoer die vergelijkbaar is met:

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

OSM injector pod controleren

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

Als de OSM-injector in orde is, ziet u uitvoer die vergelijkbaar is met:

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

De READY kolom moet zijn 1/1. Elke andere waarde geeft een beschadigde OSM injector pod aan.

OsM-injectorservice controleren

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

Als de OSM-injector in orde is, ziet u uitvoer die vergelijkbaar is met:

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

Zorg ervoor dat het IP-adres dat voor osm-injector de service wordt vermeld, is 9090. Er mag geen EXTERNAL-IPzijn.

OSM injector-eindpunten controleren

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

Als de OSM-injector in orde is, ziet u uitvoer die vergelijkbaar is met:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Om OSM te laten functioneren, moet er ten minste één eindpunt zijn voor osm-injector. Het IP-adres van uw OSM injector-eindpunten varieert, maar de poort 9090 moet hetzelfde zijn.

Webhooks valideren en dempen controleren

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Als de validatiewebhook in orde is, ziet u uitvoer die vergelijkbaar is met:

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

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Als de mutatiewebhook in orde is, ziet u uitvoer die vergelijkbaar is met:

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

Controleer met deze opdracht op de service en de CA-bundel van de webhook valideren :

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

Een goed geconfigureerde webhookconfiguratie valideren heeft uitvoer die vergelijkbaar is met:

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

Controleer op de service en de CA-bundel van de mutating webhook met behulp van de volgende opdracht:

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

Een goed geconfigureerde webhookconfiguratie voor het dempen van een webhook heeft uitvoer die vergelijkbaar is met:

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

Controleer met de volgende opdracht of de OSM-controller de webhook valideren (of de mutatie) van een CA-bundel heeft gegeven:

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

Voorbeelduitvoer:

1845

Het getal in de uitvoer geeft het aantal bytes of de grootte van de CA-bundel aan. Als de uitvoer leeg is, 0 of een getal onder 1000, is de CA-bundel niet correct ingericht. Zonder een juiste CA-bundel treedt er ValidatingWebhook een fout op.

osm-mesh-config De resource controleren

Controleer of de resource bestaat:

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

Controleer de inhoud van OSM MeshConfig:

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

De uitvoer moet er ongeveer zo uitzien:

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

osm-mesh-config resourcewaarden:

Key Type Standaardwaarde Voorbeelden van kubectl-patchopdrachten
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 matrix [] kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge
spec.traffic.outboundIPRangeExclusionList matrix [] 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 matrix [] kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge
spec.certificate.serviceCertValidityDuration tekenreeks "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 tekenreeks "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 tekenreeks "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

Naamruimten controleren

Notitie

De naamruimte arc-osm-system neemt nooit deel aan een service-mesh en wordt nooit gelabeld of geannoteerd met de sleutel/waarden die hier worden weergegeven.

We gebruiken de osm namespace add opdracht om naamruimten toe te voegen aan een bepaalde service-mesh. Wanneer een Kubernetes-naamruimte deel uitmaakt van de mesh, volgt u deze stappen om te bevestigen dat aan de vereisten wordt voldaan.

De aantekeningen van de naamruimte bookbuyerweergeven:

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

De volgende aantekening moet aanwezig zijn:

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

De labels van de naamruimte bookbuyerweergeven:

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

Het volgende label moet aanwezig zijn:

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

Als u geen CLI gebruikt osm , kunt u deze aantekeningen ook handmatig toevoegen aan uw naamruimten. Als een naamruimte niet is geannoteerd met "openservicemesh.io/sidecar-injection": "enabled"of niet is gelabeld met "openservicemesh.io/monitored-by": "osm", voegt de OSM-injector geen Envoy-sidecars toe.

Notitie

Nadat osm namespace add deze is aangeroepen, worden alleen nieuwe pods geïnjecteerd met een Envoy sidecar. Bestaande pods moeten opnieuw worden opgestart met de kubectl rollout restart deployment opdracht.

De SMI-CRD's controleren

Controleer of het cluster de vereiste aangepaste resourcedefinities (CRD's) heeft met behulp van de volgende opdracht:

kubectl get crds

Zorg ervoor dat de CRD's overeenkomen met de versies die beschikbaar zijn in de releasebranch. Als u wilt controleren welke CRD-versies worden gebruikt, gaat u naar de pagina ondersteunde SMI-versies en selecteert u uw versie in de vervolgkeuzelijst Releases .

Haal de versies van de geïnstalleerde CRD's op met de volgende opdracht:

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

Als CRD's ontbreken, gebruikt u de volgende opdrachten om ze op het cluster te installeren. Vervang indien nodig de versie in deze opdrachten (bijvoorbeeld v1.1.0 is 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

Raadpleeg de releaseopmerkingen van OSM om CRD-wijzigingen tussen releases te bekijken.

Problemen met certificaatbeheer oplossen

Zie de site van OSM-documenten voor informatie over hoe OSM certificaten beheert voor Envoy-proxy's die worden uitgevoerd op toepassingspods.

Envoy upgraden

Wanneer een nieuwe pod wordt gemaakt in een naamruimte die wordt bewaakt door de invoegtoepassing, injecteert OSM een Envoy-proxy-sidecar in die pod. Als de Envoy-versie moet worden bijgewerkt, volgt u de stappen in de upgradehandleiding op de site van OSM-documenten.

Volgende stappen