Problemen met extensies voor Kubernetes-clusters met Azure Arc oplossen
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 voerenkubectl 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 flux 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 container
uitvoer 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 ENDPOINTS
osm-controller
voor 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-IP
zijn.
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:
Sleutel | 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 bookbuyer
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 naamruimte bookbuyer
weergeven:
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
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
- Meer informatie over clusterextensies.
- Bekijk algemene tips voor probleemoplossing voor Kubernetes-clusters met Arc.