Sdílet prostřednictvím


Ř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-systempříkazu .
  • flux-system Odstraňte obor názvů z clusteru spuštěním kubectl delete namespaces flux-systempří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 containerse 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.