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 MutatingWebhookConfiguration
om 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 flux
de 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 voerenkubectl 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 container
ziet 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-controller
heeft, 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.
Gerelateerde inhoud
- Meer informatie over clusterextensies.
- Bekijk algemene tips voor probleemoplossing voor Kubernetes-clusters met Arc.