Řešení potíží s rozšířením pro clustery Kubernetes s podporou Služby Azure Arc
Tento dokument obsahuje tipy pro řešení běžných problémů souvisejících s rozšířeními clusteru, jako jsou GitOps (Flux v2) a Open Service Mesh.
Nápovědu k řešení obecných problémů s 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 je možné použít buď v clusterech Kubernetes s podporou Azure Arc, nebo v clusterech Azure Kubernetes Service (AKS). Tyto tipy pro řešení potíží obecně platí bez ohledu na typ clusteru.
Pokud potřebujete obecnou pomoc s řešením problémů s fluxConfigurations prostředky, spusťte tyto příkazy Azure CLI se zadaným parametrem --debug :
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug
Chyby spuštění webhooku nebo suchého spuštění
Pokud se zobrazí chyba Flux selhává s chybou, jako dry-run failed, error: admission webhook "<webhook>" does not support dry runje , můžete problém vyřešit vyhledáním ValidatingWebhookConfiguration nebo MutatingWebhookConfiguration nastavením sideEffects na None hodnotu nebo NoneOnDryRun:
Další informace najdete v tématu Návody řešení webhook does not support dry run chyb?
Chyby při microsoft.flux instalaci rozšíření
Rozšíření microsoft.flux nainstaluje kontrolery Flux a agenty Azure GitOps do clusterů Kubernetes nebo Azure Kubernetes Service (AKS) s podporou Služby Azure Arc. Pokud rozšíření ještě není nainstalované v clusteru a vytvoříte pro tento cluster konfigurační prostředek GitOps, rozšíření se nainstaluje automaticky.
Pokud během instalace dojde k chybě nebo pokud je rozšíření ve stavu selhání, ujistěte se, že cluster nemá žádné zásady, které omezují vytváření flux-system oboru názvů nebo prostředků v daném oboru názvů.
V případě clusteru AKS se ujistěte, že je v předplatném Microsoft.ContainerService/AKS-ExtensionManager povolený příznak funkce.
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
Potom spusťte tento příkaz, abyste zjistili, jestli dochází k jiným problémům. Nastavte parametr typu clusteru na-tconnectedClusters cluster s podporou arc nebo managedClusters pro cluster AKS. Název microsoft.flux rozšíření je "flux", pokud se rozšíření nainstalovalo automaticky při vytváření konfigurace GitOps. Vyhledejte informace v objektu statuses.
az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>
Zobrazené výsledky vám můžou pomoct určit, co se nepovedlo a jak ho opravit. Mezi možné nápravné akce patří:
- Vynucení odstranění rozšíření spuštěním příkazu
az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters> - Odinstalace verze Helm spuštěním příkazu
helm uninstall flux -n flux-system flux-systemOdstranění oboru názvů z clusteru spuštěním příkazukubectl delete namespaces flux-system
Potom můžete buď znovu vytvořit konfiguraci fluxu, která rozšíření nainstaluje microsoft.flux automaticky, nebo můžete rozšíření flux přeinstalovat ručně.
Chyby při microsoft.flux instalaci rozšíření v clusteru s povolenou identitou podu Microsoft Entra
Pokud se pokusíte nainstalovat rozšíření Flux do clusteru s povolenou identitou podu Microsoft Entra, může dojít k chybě v podu agenta rozšíření:
{"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 také vrátí jako 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ě se pod agenta rozšíření pokusí získat token z IMDS v clusteru. požadavek na token je však zachycen identitou podu). Pokud chcete tento problém vyřešit, upgradujte na nejnovější verzimicrosoft.flux rozšíření.
Problémy s identitou kubeletu při instalaci microsoft.flux rozšíření v clusteru AKS
U clusterů AKs je jednou z možností ověřování kubelet identita pomocí spravované identity přiřazené uživatelem. Použití identity kubelet může snížit provozní režii a zvýšit zabezpečení při připojování k prostředkům Azure, jako je Azure Container Registry.
Pokud chcete, aby flux používal identitu kubeletu, přidejte parametr --config useKubeletIdentity=true při instalaci rozšíření Flux.
az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config useKubeletIdentity=true
Zajištění splnění požadavků na paměť a procesor pro microsoft.flux instalaci rozšíření
Kontrolery nainstalované v clusteru Kubernetes s rozšířením microsoft.flux vyžadují správné plánování prostředků procesoru a paměti na uzlech clusteru Kubernetes. Ujistěte se, že váš cluster dokáže splnit minimální paměť a prostředky procesoru, které se můžou požadovat. Všimněte si také maximálních limitů potenciálních požadavků na prostředky procesoru a paměti, které jsou zde uvedeny.
| 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 | 1000 m | 1 Gi |
| zdrojový kontroler | 50 m | 64 Mi | 1000 m | 1 Gi |
| Kustomize-controller | 100 m | 64 Mi | 1000 m | 1 Gi |
| kontroler oznámení | 100 m | 64 Mi | 1000 m | 1 Gi |
| image-automation-controller | 100 m | 64 Mi | 1000 m | 1 Gi |
| kontroler reflektoru obrázku | 100 m | 64 Mi | 1000 m | 1 Gi |
Pokud jste povolili vlastní nebo předdefinované zásady Azure Gatekeeperu, které omezují prostředky pro kontejnery v clusterech Kubernetes, jako Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limitsje například , zajistěte, aby limity prostředků pro zásady byly větší než zde uvedené limity, nebo že flux-system obor názvů je součástí excludedNamespaces parametru v přiřazení zásad.
Flux v1
Poznámka:
Doporučujeme migrovat na Flux v2 co nejdříve. Podpora prostředků konfigurace clusteru založených na flux v1 vytvořených před 1. lednem 2024 skončí 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 potíží s prostředkem sourceControlConfigurations v flux v1, spusťte tyto příkazy Azure CLI se zadaným parametrem --debug :
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration create <parameters> --debug
Přehledy kontejneru služby Azure Monitor
Tato část obsahuje pomoc s řešením potíží s kontejnerem služby Azure Monitor Přehledy 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 Přehledy vyžaduje, aby se proces démon spustil 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
Nejde nainstalovat agenta Azure Monitoru (AMA) v Oracle Linuxu 9.x
Při pokusu o instalaci agenta služby Azure Monitor (AMA) v clusteru Kubernetes (Oracle Linux) 9.x nemusí pody AMA a pod AMA-RS fungovat správně kvůli kontejneru addon-token-adapter v podu. Při této chybě se při kontrole protokolů podu ama-logs-rsaddon-token-adapter containerzobrazí výstup podobný následujícímu:
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.
Pokud chcete tento problém vyřešit, musíte modul explicitně načíst iptables_nat na každý uzel v clusteru pomocí modprobe příkazu 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 obsahuje 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:
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ž byl v určitém okamžiku vyřazen jeden kontroler, je tu další, který je READY 1/1 a Running s restartováním 0 . Pokud je sloupec jiný než 1/1, READY síť služeb je v nefunkčním stavu. Sloupec READY s 0/1 indikuje, že 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
Sloupec READY s číslem vyšším než 1 po / značce, že jsou nainstalovány sajdkáře. Ovladač OSM obecně nebude správně fungovat s připojenými sajdkárnami.
Kontrola služby kontroleru OSM
kubectl get service -n arc-osm-system osm-controller
Pokud je kontroler OSM v pořádku, zobrazí se následující výstup:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-controller ClusterIP 10.0.31.254 <none> 15128/TCP,9092/TCP 67m
Poznámka:
Bude CLUSTER-IP se lišit. Služba NAME by PORT(S) se měla shodovat se zobrazenými informacemi.
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:
NAME ENDPOINTS AGE
osm-controller 10.240.1.115:9092,10.240.1.115:15128 69m
Pokud cluster nemá žádnou ENDPOINTS možnost 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:
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:
NAME READY STATUS RESTARTS AGE
osm-injector-5986c57765-vlsdk 1/1 Running 0 73m
Sloupec 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:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-injector ClusterIP 10.0.39.54 <none> 9090/TCP 75m
Ujistěte se, že ip adresa uvedená pro osm-injector službu je 9090. Nemělo by existovat žádné 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:
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 bude lišit, ale port 9090 musí být stejný.
Kontrola ověřování a ztlumení webhooků
kubectl get ValidatingWebhookConfiguration --selector app=osm-controller
Pokud je ověřování webhooku v pořádku, zobrazí se výstup podobný následujícímu:
NAME WEBHOOKS AGE
osm-validator-mesh-osm 1 81m
kubectl get MutatingWebhookConfiguration --selector app=osm-injector
Pokud je ztlumený webhook v pořádku, zobrazí se výstup podobný následujícímu:
NAME WEBHOOKS AGE
arc-osm-webhook-osm 1 102m
Pomocí tohoto příkazu zkontrolujte službu a sadu certifikační autority ověřovacího webhooku:
kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'
Dobře nakonfigurovaná konfigurace webhooku bude mít výstup podobný následujícímu:
{
"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á konfigurace ztlumení webhooku bude mít výstup podobný následujícímu:
{
"name": "osm-injector",
"namespace": "arc-osm-system",
"path": "/mutate-pod-creation",
"port": 9090
}
Pomocí následujícího příkazu zkontrolujte, jestli řadič OSM udělil webhooku ověřování (nebo mutování) sadu ca Bundle:
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 ca. Pokud je výstup prázdný, 0 nebo číslo pod 1 000, sada ca není správně zřízená. Bez správné sady certifikační autority dojde k ValidatingWebhook chybě.
osm-mesh-config Kontrola prostředku
Zkontrolujte existenci prostředku:
kubectl get meshconfig osm-mesh-config -n arc-osm-system
Zkontrolujte obsah osm MeshConfig:
kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml
Zobrazený výstup by měl vypadat přibližně takto:
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 hodnoty prostředků:
| Key | Type | Výchozí hodnota | Příklady příkazů opravy Kubectl |
|---|---|---|---|
| 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 názvů arc-osm-system se nikdy nebude účastnit sítě služeb a nebude nikdy označen nebo opatřen poznámkami klíč/hodnoty, které jsou zde uvedeny.
Pomocí osm namespace add příkazu připojíme obory názvů k dané síti služby. Pokud je obor názvů Kubernetes součástí sítě, postupujte podle těchto kroků a ověřte splnění požadavků.
Zobrazení poznámek oboru názvů bookbuyer:
kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'
Musí existovat následující poznámka:
{
"openservicemesh.io/sidecar-injection": "enabled"
}
Zobrazení popisků oboru názvů bookbuyer:
kubectl get namespace bookbuyer -o json | jq '.metadata.labels'
Musí existovat následující popisek:
{
"openservicemesh.io/monitored-by": "osm"
}
Pokud nepoužíváte osm rozhraní příkazového řádku, můžete tyto poznámky také 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 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
Pomocí následujícího příkazu 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í, přejděte na stránku podporovaných verzí SMI a v rozevíracím seznamu 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 v těchto příkazech (například verze 1.1.0 by byla 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
Pokud chcete zobrazit změny CRD mezi verzemi, projděte si poznámky 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 na webu dokumentace OSM.
Upgrade Envoy
Při vytvoření nového podu v oboru názvů monitorovaném doplňkem osm vloží do daného podu sajdkáře proxy serveru Envoy. Pokud je potřeba aktualizovat verzi envoy, postupujte podle pokynů v průvodci upgradem na webu dokumentace OSM.
Další kroky
- 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.