Řešení potíží s rozšířením pro clustery Kubernetes s podporou Služby Azure Arc
Tento článek popisuje tipy pro řešení běžných problémů souvisejících s rozšířeními clusteru, jako jsou GitOps (Flux v2) v Azure nebo Open Service Mesh (OSM).
Nápovědu k řešení obecných problémů Kubernetes s podporou Azure Arc najdete v tématu Řešení potíží s Kubernetes s podporou Azure Arc.
GitOps (Flux v2)
Poznámka:
Rozšíření Flux v2 můžete použít buď v clusteru Kubernetes s podporou Azure Arc, nebo v clusteru Azure Kubernetes Service (AKS). Tyto tipy pro řešení potíží obecně platí pro všechny typy clusterů.
Pokud potřebujete obecnou pomoc s řešením problémů při používání fluxConfigurations
prostředků, spusťte tyto příkazy Azure CLI s parametrem --debug
:
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug
Chyby suchého spuštění webhooku
Flux může selhat a zobrazit chybu podobnou dry-run failed, error: admission webhook "<webhook>" does not support dry run
. Pokud chcete tento problém vyřešit, přejděte na ValidatingWebhookConfiguration
nebo MutatingWebhookConfiguration
. V konfiguraci nastavte hodnotu na sideEffects
None
hodnotu nebo NoneOnDryRun
.
Další informace najdete v tématu Návody řešení chyb webhooku nepodporuje suché spuštění?.
Chyby při instalaci rozšíření microsoft.flux
Rozšíření microsoft.flux
nainstaluje kontrolery Flux a agenty Azure GitOps do clusteru Kubernetes s podporou Azure Arc nebo clusteru Azure Kubernetes Service (AKS). Pokud rozšíření ještě není nainstalované v clusteru a vy pro cluster vytvoříte konfigurační prostředek GitOps, rozšíření se nainstaluje automaticky.
Pokud během instalace dojde k chybě nebo pokud se v rozšíření zobrazí Failed
stav, ujistěte se, že cluster nemá žádné zásady, které omezují vytváření flux-system
oboru názvů nebo žádné prostředky v tomto oboru názvů.
V případě clusteru AKS se ujistěte, že Microsoft.ContainerService/AKS-ExtensionManager
je příznak funkce povolený v předplatném Azure:
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
Potom spusťte následující příkaz, abyste zjistili, jestli existují jiné problémy. Nastavte parametr typu clusteru (-t
) na connectedClusters
hodnotu Pro cluster s podporou Azure Arc nebo pro managedClusters
cluster AKS. Pokud se rozšíření nainstalovalo automaticky při vytváření konfigurace GitOps, název microsoft.flux
rozšíření je flux
.
az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>
Výstup vám může pomoct identifikovat problém a jak ho opravit. Mezi možné nápravné akce patří:
- Vynutit odstranění rozšíření spuštěním
az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>
příkazu . - Odinstalujte verzi Helm spuštěním
helm uninstall flux -n flux-system
příkazu . flux-system
Odstraňte obor názvů z clusteru spuštěnímkubectl delete namespaces flux-system
příkazu .
Pak můžete buď vytvořit novou konfiguraci fluxu, která rozšíření nainstaluje microsoft.flux
automaticky, nebo můžete rozšíření Flux nainstalovat ručně.
Chyby při instalaci rozšíření microsoft.flux v clusteru se spravovanou identitou podu Microsoft Entra
Pokud se pokusíte nainstalovat rozšíření Flux v clusteru, který má spravovanou identitu podu Microsoft Entra, může dojít k chybě v podu extension-agent
. Výstup vypadá podobně jako v tomto příkladu:
{"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"}
Stav rozšíření se vrátí takto 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}}\"}]}}",
V tomto případě extension-agent
se pod pokusí získat token ze služby Azure Instance Metadata Service v clusteru, ale požadavek na token se zachytí identitou podu. Pokud chcete tento problém vyřešit, upgradujte na nejnovější verzi microsoft.flux
rozšíření.
Požadavky na prostředky paměti a procesoru pro instalaci rozšíření microsoft.flux
Řadiče nainstalované v clusteru Kubernetes při instalaci microsoft.flux
rozšíření musí mít dostatek prostředků procesoru a paměti, aby bylo možné správně naplánovat uzel clusteru Kubernetes. Ujistěte se, že váš cluster splňuje minimální požadavky na paměť a prostředky procesoru.
Následující tabulka uvádí minimální a maximální limity pro potenciální požadavky na prostředky procesoru a paměti pro tento scénář:
Název kontejneru | Minimální využití procesoru | Minimální paměť | Maximální využití procesoru | Maximální paměť |
---|---|---|---|---|
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 | 1 000 m | 1 Gi |
source-controller |
50 m | 64 Mi | 1 000 m | 1 Gi |
kustomize-controller |
100 m | 64 Mi | 1 000 m | 1 Gi |
notification-controller |
100 m | 64 Mi | 1 000 m | 1 Gi |
image-automation-controller |
100 m | 64 Mi | 1 000 m | 1 Gi |
image-reflector-controller |
100 m | 64 Mi | 1 000 m | 1 Gi |
Pokud jste povolili vlastní nebo předdefinované zásady Gatekeeperu služby Azure Policy, které omezují prostředky pro kontejnery v clusterech Kubernetes, ujistěte se, že limity prostředků zásad jsou větší než limity uvedené v předchozí tabulce nebo že flux-system
obor názvů je součástí parametru excludedNamespaces
v přiřazení zásad. Příkladem zásady v tomto scénáři je Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits
.
Flux v1
Poznámka:
Doporučujeme migrovat na Flux v2 co nejdříve. Podpora prostředků konfigurace clusteru založených na flux v1, které byly vytvořeny před 1. lednem 2024, končí 24. května 2025. Od 1. ledna 2024 nebudete moct vytvářet nové prostředky konfigurace clusteru založené na fluxu v1.
Pokud chcete pomoct s řešením problémů s prostředkem sourceControlConfigurations
v flux v1, spusťte tyto příkazy Azure CLI, včetně parametru --debug
:
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug
Azure Monitor Container Insights
Tato část obsahuje nápovědu k řešení potíží s přehledy kontejnerů ve službě Azure Monitor pro clustery Kubernetes s podporou Služby Azure Arc.
Povolení privilegovaného režimu pro cluster Kubernetes s kanonickým ovládacím uzly
Azure Monitor Container Insights vyžaduje, aby se služba Kubernetes DaemonSet spouštěla v privilegovaném režimu. Pokud chcete úspěšně nastavit cluster Kubernetes canonical Charmed pro monitorování, spusťte následující příkaz:
juju config kubernetes-worker allow-privileged=true
Pody AMA nejde nainstalovat na Oracle Linux 9.x
Pokud se pokusíte nainstalovat agenta Azure Monitoru (AMA) na cluster Kubernetes 9.x Kubernetes (Red Hat Enterprise Linux) Oracle Linux (Red Hat Enterprise Linux) 9.x, nemusí pody AMA a pod AMA-RS fungovat správně kvůli addon-token-adapter
kontejneru v podu. Když zkontrolujete protokoly podu ama-logs-rs
, zobrazí addon-token-adapter container
se výstup podobný následujícímu příkladu:
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.
K této chybě dochází, protože instalace rozšíření vyžaduje iptable_nat
modul, ale tento modul se automaticky nenačte v distribucích Oracle Linux (RHEL) 9.x.
Chcete-li tento problém vyřešit, musíte modul explicitně načíst iptables_nat
na každý uzel v clusteru. modprobe
Použijte příkaz sudo modprobe iptables_nat
. Po přihlášení k jednotlivým uzlům a ručním přidání iptable_nat
modulu zkuste instalaci AMA zopakovat.
Poznámka:
Provedením tohoto kroku modul neukončíte iptables_nat
jako trvalý.
Open Service Mesh s podporou Služby Azure Arc
Tato část ukazuje příkazy, které můžete použít k ověření a řešení potíží s nasazením komponent rozšíření Open Service Mesh (OSM) ve vašem clusteru.
Kontrola nasazení kontroleru OSM
kubectl get deployment -n arc-osm-system --selector app=osm-controller
Pokud je kontroler OSM v pořádku, zobrazí se výstup podobný následujícímu:
NAME READY UP-TO-DATE AVAILABLE AGE
osm-controller 1/1 1 1 59m
Kontrola podů kontroleru OSM
kubectl get pods -n arc-osm-system --selector app=osm-controller
Pokud je kontroler OSM v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME READY STATUS RESTARTS AGE
osm-controller-b5bd66db-wglzl 0/1 Evicted 0 61m
osm-controller-b5bd66db-wvl9w 1/1 Running 0 31m
I když má jeden kontroler stav Evicted
v jednom okamžiku, druhý kontroler má READY
stav 1/1
a Running
s restartováním 0
. READY
Pokud je stav jiný než 1/1
, síť služeb je v nefunkčním stavu. Pokud READY
ano 0/1
, kontejner řídicí roviny se chybově ukončí.
Ke kontrole protokolů kontroleru použijte následující příkaz:
kubectl logs -n arc-osm-system -l app=osm-controller
READY
Pokud je stav číslo větší než 1
za lomítkem (/
), nainstalují se sajdkárna. Ovladač OSM obecně nefunguje správně při připevnění sajdkáru.
Kontrola služby kontroleru OSM
Pokud chcete zkontrolovat službu kontroleru OSM, spusťte tento příkaz:
kubectl get service -n arc-osm-system osm-controller
Pokud je kontroler OSM v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-controller ClusterIP 10.0.31.254 <none> 15128/TCP,9092/TCP 67m
Poznámka:
Skutečná hodnota pro CLUSTER-IP
bude jiná než v tomto příkladu. Hodnoty a NAME
PORT(S)
měly by odpovídat hodnotám zobrazeným v tomto příkladu.
Kontrola koncových bodů kontroleru OSM
kubectl get endpoints -n arc-osm-system osm-controller
Pokud je kontroler OSM v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME ENDPOINTS AGE
osm-controller 10.240.1.115:9092,10.240.1.115:15128 69m
Pokud cluster nemá žádnou ENDPOINTS
hodnotu osm-controller
, řídicí rovina není v pořádku. Tento stav není v pořádku, znamená to, že pod kontroleru selhal nebo že se nikdy nenasadil správně.
Kontrola nasazení injektoru OSM
kubectl get deployments -n arc-osm-system osm-injector
Pokud je injektor OSM v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME READY UP-TO-DATE AVAILABLE AGE
osm-injector 1/1 1 1 73m
Kontrola podu injektoru OSM
kubectl get pod -n arc-osm-system --selector app=osm-injector
Pokud je injektor OSM v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME READY STATUS RESTARTS AGE
osm-injector-5986c57765-vlsdk 1/1 Running 0 73m
Stav READY
musí být 1/1
. Jakákoli jiná hodnota označuje pod injektoru OSM, který není v pořádku.
Kontrola služby injektoru OSM
kubectl get service -n arc-osm-system osm-injector
Pokud je injektor OSM v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-injector ClusterIP 10.0.39.54 <none> 9090/TCP 75m
Ujistěte se, že JE IP adresa uvedená pro osm-injector
službu 9090
. Neměla by být uvedena žádná hodnota pro EXTERNAL-IP
.
Kontrola koncových bodů injektoru OSM
kubectl get endpoints -n arc-osm-system osm-injector
Pokud je injektor OSM v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME ENDPOINTS AGE
osm-injector 10.240.1.172:9090 75m
Aby osm fungovalo, musí existovat alespoň jeden koncový bod pro osm-injector
. IP adresa koncových bodů injektoru OSM se liší, ale hodnota 9090
portu musí být stejná.
Kontrola webhooků: Ověřování a mutování
Spuštěním následujícího příkazu zkontrolujte ověřování webhooku:
kubectl get ValidatingWebhookConfiguration --selector app=osm-controller
Pokud je ověření webhooku v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME WEBHOOKS AGE
osm-validator-mesh-osm 1 81m
Spuštěním následujícího příkazu zkontrolujte ztlumení webhooku:
kubectl get MutatingWebhookConfiguration --selector app=osm-injector
Pokud je mutační webhook v pořádku, zobrazí se výstup podobný následujícímu příkladu:
NAME WEBHOOKS AGE
arc-osm-webhook-osm 1 102m
Pomocí následujícího příkazu zkontrolujte službu a sadu certifikační autority (CA bundle) ověřovacího webhooku:
kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'
Dobře nakonfigurovaný webhook má výstup podobný tomuto příkladu:
{
"name": "osm-config-validator",
"namespace": "arc-osm-system",
"path": "/validate",
"port": 9093
}
Pomocí následujícího příkazu zkontrolujte službu a sadu certifikační autority webhooku Mutating :
kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'
Dobře nakonfigurovaný webhook ztlumení má výstup podobný tomuto příkladu:
{
"name": "osm-injector",
"namespace": "arc-osm-system",
"path": "/mutate-pod-creation",
"port": 9090
}
Pomocí následujícího příkazu zkontrolujte, jestli kontroler OSM udělil validaci (nebo mutování) webhooku sady certifikační autority:
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
Příklad výstupu:
1845
Číslo ve výstupu označuje počet bajtů nebo velikost sady certifikační autority. Pokud je výstup prázdný, 0 nebo číslo pod 1 000, sada certifikační autority není správně zřízená. Bez správné sady ValidatingWebhook
certifikační autority vyvolá chybu.
osm-mesh-config
Kontrola prostředku
Zkontrolujte existenci prostředku:
kubectl get meshconfig osm-mesh-config -n arc-osm-system
Zkontrolujte hodnotu nastavení OSM meshconfig
:
kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml
Vyhledejte výstup podobný tomuto příkladu:
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: ""
Následující tabulka uvádí osm-mesh-config
hodnoty prostředků:
Klíč | Type | Default value | Příklady příkazů kubectl patch |
---|---|---|---|
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 |
pole | [] |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge |
spec.traffic.outboundIPRangeExclusionList |
pole | [] |
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 |
pole | [] |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge |
spec.certificate.serviceCertValidityDuration |
string | "24h" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"certificate":{"serviceCertValidityDuration":"24h"}}}' --type=merge |
spec.observability.enableDebugServer |
bool | false |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"enableDebugServer":false}}}' --type=merge |
spec.observability.osmLogLevel |
string | "info" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"osmLogLevel": "info"}}}}' --type=merge |
spec.observability.tracing.enable |
bool | false |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"enable":true}}}}' --type=merge |
spec.sidecar.enablePrivilegedInitContainer |
bool | false |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"enablePrivilegedInitContainer":true}}}' --type=merge |
spec.sidecar.logLevel |
string | "error" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"logLevel":"error"}}}' --type=merge |
spec.featureFlags.enableWASMStats |
bool | "true" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableWASMStats":"true"}}}' --type=merge |
spec.featureFlags.enableEgressPolicy |
bool | "true" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEgressPolicy":"true"}}}' --type=merge |
spec.featureFlags.enableMulticlusterMode |
bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableMulticlusterMode":"false"}}}' --type=merge |
spec.featureFlags.enableSnapshotCacheMode |
bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableSnapshotCacheMode":"false"}}}' --type=merge |
spec.featureFlags.enableAsyncProxyServiceMapping |
bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableAsyncProxyServiceMapping":"false"}}}' --type=merge |
spec.featureFlags.enableIngressBackendPolicy |
bool | "true" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableIngressBackendPolicy":"true"}}}' --type=merge |
spec.featureFlags.enableEnvoyActiveHealthChecks |
bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEnvoyActiveHealthChecks":"false"}}}' --type=merge |
Kontrola oborů názvů
Poznámka:
Obor arc-osm-system
názvů se nikdy neúčastní sítě služeb a nikdy se neoznačí ani neoznačí dvojicemi klíč/hodnota, které jsou zde uvedené.
Pomocí příkazu můžete osm namespace add
připojit obory názvů ke konkrétní síti služeb. Pokud je obor názvů Kubernetes součástí sítě, proveďte následující kroky a ověřte splnění požadavků.
Zobrazení poznámek bookbuyer
oboru názvů:
kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'
Musí existovat následující poznámka:
{
"openservicemesh.io/sidecar-injection": "enabled"
}
Zobrazení popisků bookbuyer
oboru názvů:
kubectl get namespace bookbuyer -o json | jq '.metadata.labels'
Musí existovat následující popisek:
{
"openservicemesh.io/monitored-by": "osm"
}
Pokud rozhraní příkazového osm
řádku nepoužíváte, můžete tyto poznámky přidat do svých oborů názvů ručně. Pokud obor názvů není opatřen poznámkami "openservicemesh.io/sidecar-injection": "enabled"
nebo pokud není označený "openservicemesh.io/monitored-by": "osm"
, injektor OSM nepřidá sajdkáře Envoy.
Poznámka:
Po osm namespace add
zavolání se do sajdkáře envoy vloží pouze nové pody. Existující pody se musí restartovat pomocí kubectl rollout restart deployment
příkazu.
Ověření identifikátorů SMI CRD
V případě rozhraní SMI (OSM Service Mesh Interface) zkontrolujte, jestli má cluster požadované vlastní definice prostředků (CRD):
kubectl get crds
Ujistěte se, že identifikátory CRD odpovídají verzím dostupným ve větvi vydané verze. Pokud chcete ověřit, které verze CRD se používají, podívejte se na podporované verze SMI a v nabídce Vydané verze vyberte svou verzi.
Pomocí následujícího příkazu získejte verze nainstalovaných disků CRD:
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
Pokud chybí identifikátory CRD, nainstalujte je do clusteru pomocí následujících příkazů. Podle potřeby nahraďte verzi těchto příkazů (například místo verze 1.1.0 můžete použít 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
Informace o tom, jak se verze CRD mezi verzemi mění, najdete v poznámkách k verzi OSM.
Řešení potíží se správou certifikátů
Informace o tom, jak OSM problémy a spravuje certifikáty pro proxy servery envoy spuštěné na podech aplikací, najdete v dokumentaci OSM.
Upgrade Envoy
Při vytvoření nového podu v oboru názvů, který je monitorován doplňkem, osm vloží do podu envoy proxy sajdkár . Pokud je potřeba aktualizovat verzi envoy, postupujte podle pokynů v průvodci upgradem v dokumentaci OSM.
Související obsah
- Přečtěte si další informace o rozšířeních clusteru.
- Podívejte se na obecné tipy pro řešení potíží pro clustery Kubernetes s podporou Arc.