Delen via


Problemen met extensies voor Kubernetes-clusters met Azure Arc oplossen

In dit artikel worden tips voor probleemoplossing beschreven voor veelvoorkomende problemen met betrekking tot clusterextensies , zoals GitOps (Flux v2) in Azure of Open Service Mesh (OSM).

Zie Problemen met Kubernetes met Azure Arc oplossen voor hulp bij het oplossen van Kubernetes-problemen met Azure Arc in het algemeen.

GitOps (Flux v2)

Notitie

U kunt de Flux v2-extensie gebruiken in een Kubernetes-cluster met Azure Arc of in een AKS-cluster (Azure Kubernetes Service). Deze tips voor probleemoplossing zijn over het algemeen van toepassing op alle clustertypen.

Voor algemene hulp bij het oplossen van problemen bij het gebruik fluxConfigurations van resources voert u deze Azure CLI-opdrachten uit met de --debug parameter:

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

Fouten bij droge uitvoering van webhook

Flux kan mislukken en een fout weergeven die vergelijkbaar is met dry-run failed, error: admission webhook "<webhook>" does not support dry run. Ga naar of MutatingWebhookConfigurationom het probleem op te ValidatingWebhookConfiguration lossen. Stel in de configuratie de waarde in voor sideEffects of None NoneOnDryRun.

Zie Hoe kan ik 'webhook biedt geen ondersteuning voor dry run'-fouten? oplossen voor meer informatie.

Fouten bij het installeren van de extensie microsoft.flux

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

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

Voor een AKS-cluster moet u ervoor zorgen dat de Microsoft.ContainerService/AKS-ExtensionManager functievlag is ingeschakeld in het Azure-abonnement:

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

Voer vervolgens de volgende opdracht uit om te bepalen of er andere problemen zijn. Stel de parameter van het clustertype (-t) connectedClusters in op Voor een Cluster met Azure Arc of op managedClusters voor een AKS-cluster. Als de extensie automatisch is geïnstalleerd toen u uw GitOps-configuratie maakte, is fluxde naam van de microsoft.flux extensie.

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

De uitvoer kan u helpen bij het identificeren van het probleem en hoe u dit kunt oplossen. Mogelijke herstelacties zijn:

  • Verwijder de extensie geforceerd door 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 uit te voeren kubectl delete namespaces flux-system.

Vervolgens kunt u een nieuwe Flux-configuratie maken, waarmee de microsoft.flux extensie automatisch wordt geïnstalleerd of u kunt de Flux-extensie handmatig installeren.

Fouten bij het installeren van de extensie microsoft.flux in een cluster met een door Microsoft Entra beheerde identiteit

Als u de Flux-extensie probeert te installeren in een cluster met een door Microsoft Entra beheerde identiteit, kan er een fout optreden in de extension-agent pod. De uitvoer ziet er ongeveer als volgt uit:

{"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 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 extension-agent pod het token op te halen van Azure Instance Metadata Service op het cluster, maar de tokenaanvraag wordt onderschept door de pod-identiteit. Voer een upgrade uit naar de nieuwste versie van de microsoft.flux extensie om dit probleem op te lossen.

Vereisten voor geheugen- en CPU-resources voor het installeren van de extensie microsoft.flux

De controllers die zijn geïnstalleerd in uw Kubernetes-cluster wanneer u de microsoft.flux extensie installeert, moeten voldoende CPU- en geheugenbronnen hebben om goed te plannen op een Kubernetes-clusterknooppunt. Zorg ervoor dat uw cluster voldoet aan de minimale geheugen- en CPU-resourcevereisten.

De volgende tabel bevat de minimum- en maximumlimieten voor de vereisten voor cpu- en geheugenresources voor dit scenario:

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

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

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.

Als u problemen met de sourceControlConfigurations resource in Flux v1 wilt oplossen, voert u deze Azure CLI-opdrachten uit, waaronder de --debug parameter:

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

Azure Monitor Container Insights

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

Bevoorrechte modus inschakelen voor een Canonical Charmed Kubernetes-cluster

Azure Monitor Container Insights vereist dat de Kubernetes 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 AMA-pods niet installeren in Oracle Linux 9.x

Als u Azure Monitor Agent (AMA) probeert te installeren op een Oracle Linux-cluster (Red Hat Enterprise Linux (RHEL)) 9.x Kubernetes-cluster, werken de AMA-pods en de AMA-RS-pod mogelijk niet correct vanwege de addon-token-adapter container in de pod. Wanneer u de logboeken van de ama-logs-rs pod controleert, addon-token-adapter containerziet u uitvoer die vergelijkbaar is met het volgende voorbeeld:

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 op elk knooppunt in het cluster te laden. Gebruik 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

In deze sectie ziet u opdrachten die u kunt gebruiken om de implementatie van Open Service Mesh-extensieonderdelen (OSM) in uw cluster te valideren en op te lossen.

De osm-controllerimplementatie 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, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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 een status heeft van Evicted op het ene punt, heeft een andere controller de READY status 1/1 en Running met 0 opnieuw opstarten. Als de READY status iets anders is dan 1/1, heeft de service-mesh een verbroken status. Als READY dat het is 0/1, loopt de container van het besturingsvlak vast.

Gebruik de volgende opdracht om controllerlogboeken te inspecteren:

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

Als de READY status een getal groter is dan 1 na de slash (/), worden sidecars geïnstalleerd. De OSM-controller werkt over het algemeen niet goed wanneer sidecars zijn gekoppeld.

Controleer de OSM-controllerservice

Voer deze opdracht uit om de OSM-controllerservice te controleren:

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

Als de OSM-controller in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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

Notitie

De werkelijke waarde voor CLUSTER-IP deze waarde verschilt van dit voorbeeld. De waarden voor NAME en PORT(S) moeten overeenkomen met wat in dit voorbeeld wordt weergegeven.

OsM-controllereindpunten controleren

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

Als de OSM-controller in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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

Als het cluster geen ENDPOINTS waarde osm-controllerheeft, is het besturingsvlak beschadigd. Deze beschadigde status betekent dat de controllerpod is vastgelopen of dat deze nooit correct is geïmplementeerd.

De OSM-injectorimplementatie controleren

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

Als de OSM-injector in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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

Controleer de OSM injector pod

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

Als de OSM-injector in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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

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

Controleer de OSM-injectorservice

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

Als de OSM-injector in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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 waarde worden vermeld voor EXTERNAL-IP.

OSM injector-eindpunten controleren

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

Als de OSM-injector in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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 poortwaarde 9090 moet hetzelfde zijn.

Webhooks controleren: Valideren en dempen

Controleer de webhook valideren door de volgende opdracht uit te voeren:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Als de validatiewebhook in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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

Controleer de webhook dempen door de volgende opdracht uit te voeren:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Als de mutatiewebhook in orde is, wordt uitvoer weergegeven die lijkt op het volgende voorbeeld:

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

Controleer op de service en de certificeringsinstantiebundel (CA-bundel) van de webhook valideren met behulp van deze opdracht:

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

Een goed geconfigureerde validatiewebhook heeft uitvoer die lijkt op dit voorbeeld:

{
  "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 mutatiewebhook heeft uitvoer die lijkt op dit voorbeeld:

{
  "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 Dempen) 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, 0 of een getal onder 1000 is, is de CA-bundel niet correct ingericht. Zonder een juiste CA-bundel genereert ValidatingWebhook u een fout.

osm-mesh-config De resource controleren

Controleer of de resource bestaat:

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

Controleer de waarde van de OSM-instelling meshconfig :

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

Zoek naar uitvoer die lijkt op dit voorbeeld:

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

De volgende tabel bevat osm-mesh-config resourcewaarden:

Sleutel Type Default value 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 arc-osm-system naamruimte neemt nooit deel aan een service-mesh en wordt nooit gelabeld of geannoteerd met de sleutel-/waardeparen die hier worden weergegeven.

U kunt de osm namespace add opdracht gebruiken om naamruimten toe te voegen aan een specifieke service-mesh. Wanneer een Kubernetes-naamruimte deel uitmaakt van de mesh, voert u de volgende stappen uit om te controleren of aan de vereisten wordt voldaan.

De aantekeningen van de bookbuyer naamruimte weergeven:

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

De volgende aantekening moet aanwezig zijn:

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

De labels van de bookbuyer naamruimte weergeven:

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

Het volgende label moet aanwezig zijn:

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

Als u de osm CLI niet gebruikt, kunt u deze aantekeningen handmatig toevoegen aan uw naamruimten. Als een naamruimte niet is voorzien van aantekeningen of "openservicemesh.io/sidecar-injection": "enabled"als deze 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 behulp van de kubectl rollout restart deployment opdracht.

De SMI-CRD's controleren

Controleer voor de OSM Service Mesh Interface (SMI) of het cluster de vereiste aangepaste resourcedefinities (CRD's) heeft:

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, raadpleegt u ondersteunde SMI-versies en selecteert u uw versie in het menu Releases .

Haal de versies van de geïnstalleerde CRD's op met behulp van 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 de versie in deze opdrachten indien nodig (in plaats van v1.1.0 kunt u bijvoorbeeld release-v1.1.1 gebruiken).

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

Zie de releaseopmerkingen van OSM om te zien hoe CRD-versies veranderen tussen releases.

Problemen met certificaatbeheer oplossen

Zie de OSM-documentatie voor informatie over hoe OSM certificaten voor Envoy-proxy's beheert 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 in de OSM-documentatie.