Rozwiązywanie problemów z rozszerzeniem dla klastrów Kubernetes z obsługą usługi Azure Arc

Artykuł
01/09/2025

W tym artykule opisano porady dotyczące rozwiązywania typowych problemów związanych z rozszerzeniami klastra , takimi jak GitOps (Flux v2) na platformie Azure lub Open Service Mesh (OSM).

Aby uzyskać pomoc dotyczącą rozwiązywania problemów z platformą Kubernetes z włączoną usługą Azure Arc, zobacz Rozwiązywanie problemów z platformą Kubernetes z obsługą usługi Azure Arc.

GitOps (Flux v2)

Uwaga

Można użyć rozszerzenia Flux v2 w klastrze Kubernetes z włączoną usługą Azure Arc lub w klastrze usługi Azure Kubernetes Service (AKS). Te porady dotyczące rozwiązywania problemów mają zwykle zastosowanie do wszystkich typów klastrów.

Aby uzyskać ogólną pomoc dotyczącą rozwiązywania problemów podczas korzystania z fluxConfigurations zasobów, uruchom następujące polecenia interfejsu wiersza polecenia platformy Azure przy użyciu parametru --debug :

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug

Błędy uruchamiania suchego elementu webhook

Strumień może zakończyć się niepowodzeniem i wyświetlić błąd podobny do dry-run failed, error: admission webhook "<webhook>" does not support dry run. Aby rozwiązać ten problem, przejdź do ValidatingWebhookConfiguration lub MutatingWebhookConfiguration. W konfiguracji ustaw wartość dla sideEffects wartości na None lub NoneOnDryRun.

Aby uzyskać więcej informacji, zobacz Jak mogę rozwiązać problemy z błędami "element webhook nie obsługuje suchego uruchomienia"?

Błędy podczas instalowania rozszerzenia microsoft.flux

Rozszerzenie microsoft.flux instaluje kontrolery Flux i agentów usługi Azure GitOps w klastrze Kubernetes z włączoną usługą Azure Arc lub w klastrze usługi Azure Kubernetes Service (AKS). Jeśli rozszerzenie nie jest jeszcze zainstalowane w klastrze i tworzysz zasób konfiguracji GitOps dla klastra, rozszerzenie jest instalowane automatycznie.

Jeśli podczas instalacji wystąpi błąd lub jeśli rozszerzenie wyświetla Failed stan, upewnij się, że klaster nie ma żadnych zasad, które ograniczają tworzenie flux-system przestrzeni nazw ani żadnych zasobów w tej przestrzeni nazw.

W przypadku klastra usługi AKS upewnij się, że flaga Microsoft.ContainerService/AKS-ExtensionManager funkcji jest włączona w subskrypcji platformy Azure:

az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager

Następnie uruchom następujące polecenie, aby ustalić, czy występują inne problemy. Ustaw parametr typu klastra (-t) na connectedClusters dla klastra z obsługą usługi Azure Arc lub managedClusters dla klastra usługi AKS. Jeśli rozszerzenie zostało zainstalowane automatycznie podczas tworzenia konfiguracji usługi GitOps, nazwa microsoft.flux rozszerzenia to flux.

az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>

Dane wyjściowe mogą pomóc w zidentyfikowaniu problemu i jego rozwiązaniu. Możliwe akcje korygowania obejmują:

Wymuś usunięcie rozszerzenia, uruchamiając polecenie az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>.
Odinstaluj wydanie programu Helm, uruchamiając polecenie helm uninstall flux -n flux-system.
flux-system Usuń przestrzeń nazw z klastra, uruchamiając polecenie kubectl delete namespaces flux-system.

Następnie możesz utworzyć nową konfigurację platformy Flux, która automatycznie instaluje microsoft.flux rozszerzenie, lub zainstalować rozszerzenie Flux ręcznie.

Błędy podczas instalowania rozszerzenia microsoft.flux w klastrze z tożsamością zarządzaną przez pod firmy Microsoft

Jeśli spróbujesz zainstalować rozszerzenie Flux w klastrze z tożsamością zarządzaną zasobnika firmy Microsoft, w zasobniku extension-agent może wystąpić błąd. Dane wyjściowe wyglądają podobnie do tego przykładu:

{"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"}

Stan rozszerzenia jest zwracany 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}}\"}]}}",

W takim przypadku extension-agent zasobnik próbuje pobrać token z usługi Azure Instance Metadata Service w klastrze, ale żądanie tokenu jest przechwytywane przez tożsamość zasobnika. Aby rozwiązać ten problem, przeprowadź uaktualnienie do najnowszej microsoft.flux wersji rozszerzenia.

Wymagania dotyczące zasobów pamięci i procesora CPU dotyczące instalowania rozszerzenia microsoft.flux

Kontrolery zainstalowane w klastrze Kubernetes podczas instalowania microsoft.flux rozszerzenia muszą mieć wystarczającą ilość zasobów procesora CPU i pamięci, aby prawidłowo zaplanować w węźle klastra Kubernetes. Upewnij się, że klaster spełnia minimalne wymagania dotyczące pamięci i zasobów procesora CPU.

W poniższej tabeli wymieniono minimalne i maksymalne limity dla potencjalnych wymagań dotyczących zasobów procesora CPU i pamięci w tym scenariuszu:

Nazwa kontenera	Minimalna liczba procesorów	Minimalna ilość pamięci	Maksymalna liczba procesorów	Maksymalna ilość pamięci
`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

Jeśli włączono niestandardowe lub wbudowane zasady usługi Azure Policy Gatekeeper, które ograniczają zasoby dla kontenerów w klastrach Kubernetes, upewnij się, że limity zasobów w zasadach są większe niż limity pokazane w poprzedniej tabeli lub że flux-system przestrzeń nazw jest częścią excludedNamespaces parametru w przypisaniu zasad. Przykładem zasad w tym scenariuszu jest Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits.

Strumień v1

Uwaga

Zalecamy przeprowadzenie migracji do środowiska Flux v2 tak szybko, jak to możliwe. Obsługa zasobów konfiguracji klastra opartego na platformie Flux w wersji 1, które zostały utworzone przed 1 stycznia 2024 r., kończy się 24 maja 2025 r. Od 1 stycznia 2024 r. nie będzie można utworzyć nowych zasobów konfiguracji klastra opartego na platformie Flux w wersji 1.

Aby ułatwić rozwiązywanie problemów z zasobem sourceControlConfigurations w środowisku Flux v1, uruchom następujące polecenia interfejsu wiersza polecenia platformy Azure, w tym parametr:--debug

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug

Azure Monitor Container Insights

Ta sekcja zawiera pomoc dotyczącą rozwiązywania problemów z usługą Container Insights w usłudze Azure Monitor dla klastrów Kubernetes z obsługą usługi Azure Arc.

Włączanie trybu uprzywilejowanego dla klastra Kubernetes oczarowanego canonical

Usługa Azure Monitor Container Insights wymaga, aby zestaw DaemonSet platformy Kubernetes działał w trybie uprzywilejowanym. Aby pomyślnie skonfigurować klaster Kubernetes oczarowany canonical do monitorowania, uruchom następujące polecenie:

juju config kubernetes-worker allow-privileged=true

Nie można zainstalować zasobników AMA w systemie Oracle Linux 9.x

Jeśli spróbujesz zainstalować agenta usługi Azure Monitor (AMA) w klastrze Platformy Kubernetes w systemie Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x, zasobniki AMA i zasobnik AMA-RS mogą nie działać prawidłowo z powodu kontenera addon-token-adapter w zasobniku. Po sprawdzeniu dzienników ama-logs-rs zasobnika w addon-token-adapter containerpliku zobaczysz dane wyjściowe podobne do następującego przykładu:

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.

Ten błąd występuje, ponieważ zainstalowanie rozszerzenia wymaga modułu iptable_nat , ale ten moduł nie jest automatycznie ładowany w dystrybucjach oracle Linux (RHEL) 9.x.

Aby rozwiązać ten problem, należy jawnie załadować iptables_nat moduł w każdym węźle w klastrze. modprobe Użyj polecenia sudo modprobe iptables_nat. Po zalogowaniu się do każdego węzła i ręcznym dodaniu modułu iptable_nat ponów próbę instalacji usługi AMA.

Uwaga

Wykonanie tego kroku nie powoduje trwałego modułu iptables_nat .

Usługa Open Service Mesh z obsługą usługi Azure Arc

W tej sekcji przedstawiono polecenia, których można użyć do weryfikowania i rozwiązywania problemów z wdrażaniem składników rozszerzenia Open Service Mesh (OSM) w klastrze.

Sprawdzanie wdrożenia kontrolera OSM

kubectl get deployment -n arc-osm-system --selector app=osm-controller

Jeśli kontroler OSM jest w dobrej kondycji, zobaczysz dane wyjściowe podobne do:

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
osm-controller   1/1     1            1           59m

Sprawdzanie zasobników kontrolera OSM

kubectl get pods -n arc-osm-system --selector app=osm-controller

Jeśli kontroler OSM jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME                            READY   STATUS    RESTARTS   AGE
osm-controller-b5bd66db-wglzl   0/1     Evicted   0          61m
osm-controller-b5bd66db-wvl9w   1/1     Running   0          31m

Mimo że jeden kontroler ma stan Evicted w jednym momencie, inny kontroler ma READY stan 1/1 i Running z 0 ponownym uruchomieniem. READY Jeśli stan jest inny niż 1/1, siatka usługi jest w stanie przerwania. Jeśli READY parametr ma 0/1wartość , kontener płaszczyzny sterowania ulega awarii.

Użyj następującego polecenia, aby sprawdzić dzienniki kontrolera:

kubectl logs -n arc-osm-system -l app=osm-controller

READY Jeśli stan jest liczbą większą niż 1 po ukośniku do przodu (/), przyczepki są zainstalowane. Kontroler OSM zwykle nie działa poprawnie, gdy przyczepki są dołączone.

Sprawdzanie usługi kontrolera OSM

Aby sprawdzić usługę kontrolera OSM, uruchom następujące polecenie:

kubectl get service -n arc-osm-system osm-controller

Jeśli kontroler OSM jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME             TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)              AGE
osm-controller   ClusterIP   10.0.31.254   <none>        15128/TCP,9092/TCP   67m

Uwaga

Rzeczywista wartość parametru CLUSTER-IP będzie inna niż w tym przykładzie. Wartości i NAME PORT(S) powinny być zgodne z tym, co pokazano w tym przykładzie.

Sprawdzanie punktów końcowych kontrolera OSM

kubectl get endpoints -n arc-osm-system osm-controller

Jeśli kontroler OSM jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME             ENDPOINTS                              AGE
osm-controller   10.240.1.115:9092,10.240.1.115:15128   69m

Jeśli klaster nie ENDPOINTS ma wartości osm-controller, płaszczyzna sterowania jest w złej kondycji. Ten stan złej kondycji oznacza, że zasobnik kontrolera uległ awarii lub że nigdy nie został prawidłowo wdrożony.

Sprawdzanie wdrożenia iniektora OSM

kubectl get deployments -n arc-osm-system osm-injector

Jeśli wstrzykiwacz OSM jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
osm-injector   1/1     1            1           73m

Sprawdzanie zasobnika iniektora OSM

kubectl get pod -n arc-osm-system --selector app=osm-injector

Jeśli wstrzykiwacz OSM jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME                            READY   STATUS    RESTARTS   AGE
osm-injector-5986c57765-vlsdk   1/1     Running   0          73m

Stan READY musi mieć wartość 1/1. Każda inna wartość wskazuje w złej kondycji zasobnik iniektora OSM.

Sprawdzanie usługi iniektora OSM

kubectl get service -n arc-osm-system osm-injector

Jeśli wstrzykiwacz OSM jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
osm-injector   ClusterIP   10.0.39.54   <none>        9090/TCP   75m

Upewnij się, że adres IP wymieniony dla osm-injector usługi to 9090. Dla elementu nie powinna być wyświetlana EXTERNAL-IPżadna wartość .

Sprawdzanie punktów końcowych iniektora OSM

kubectl get endpoints -n arc-osm-system osm-injector

Jeśli wstrzykiwacz OSM jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Aby osm działał, musi istnieć co najmniej jeden punkt końcowy dla elementu osm-injector. Adres IP punktów końcowych iniektora OSM różni się, ale wartość 9090 portu musi być taka sama.

Sprawdzanie elementów webhook: weryfikowanie i wyciszanie

Sprawdź sprawdzanie poprawności elementu webhook, uruchamiając następujące polecenie:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Jeśli element webhook sprawdzania poprawności jest w dobrej kondycji, dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME                     WEBHOOKS   AGE
osm-validator-mesh-osm   1          81m

Sprawdź element webhook Mutating , uruchamiając następujące polecenie:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Jeśli element webhook Mutating jest w dobrej kondycji , dane wyjściowe wyglądające podobnie jak w poniższym przykładzie:

NAME                  WEBHOOKS   AGE
arc-osm-webhook-osm   1          102m

Sprawdź usługę i pakiet urzędu certyfikacji (pakiet urzędu certyfikacji) elementu webhook sprawdzania poprawności przy użyciu tego polecenia:

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'

Dobrze skonfigurowany element webhook sprawdzania poprawności zawiera dane wyjściowe podobne do tego przykładu:

{
  "name": "osm-config-validator",
  "namespace": "arc-osm-system",
  "path": "/validate",
  "port": 9093
}

Sprawdź usługę i pakiet urzędu certyfikacji elementu webhook Mutating przy użyciu następującego polecenia:

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'

Dobrze skonfigurowany element webhook zmutowaniem zawiera dane wyjściowe podobne do tego przykładu:

{
  "name": "osm-injector",
  "namespace": "arc-osm-system",
  "path": "/mutate-pod-creation",
  "port": 9090
}

Sprawdź, czy kontroler OSM udzielił elementu webhook sprawdzania poprawności (lub Mutating) pakietu urzędu certyfikacji przy użyciu następującego polecenia:

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

Przykładowe wyjście:

Liczba w danych wyjściowych wskazuje liczbę bajtów lub rozmiar pakietu urzędu certyfikacji. Jeśli dane wyjściowe są puste, 0 lub liczba poniżej 1000, pakiet urzędu certyfikacji nie jest poprawnie aprowizowany. Bez poprawnego pakietu ValidatingWebhook urzędu certyfikacji zgłasza błąd.

`osm-mesh-config` Sprawdzanie zasobu

Sprawdź istnienie zasobu:

kubectl get meshconfig osm-mesh-config -n arc-osm-system

Sprawdź wartość ustawienia OSM meshconfig :

kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml

Wyszukaj dane wyjściowe podobne do tego przykładu:

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: ""

W poniższej tabeli wymieniono osm-mesh-config wartości zasobów:

Klucz	Typ	Domyślna wartość	Przykłady poleceń narzędzia 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`	tablica	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge`
`spec.traffic.outboundIPRangeExclusionList`	tablica	`[]`	`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`	tablica	`[]`	`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`

Sprawdzanie przestrzeni nazw

Uwaga

arc-osm-system Przestrzeń nazw nigdy nie uczestniczy w siatce usługi i nigdy nie jest oznaczona etykietą lub adnotacją z parami klucz/wartość pokazanymi tutaj.

Możesz użyć osm namespace add polecenia , aby połączyć przestrzenie nazw z określoną siatką usług. Gdy przestrzeń nazw kubernetes jest częścią siatki, wykonaj następujące kroki, aby potwierdzić, że wymagania zostały spełnione.

Wyświetl adnotacje bookbuyer przestrzeni nazw:

kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'

Musi istnieć następująca adnotacja:

{
  "openservicemesh.io/sidecar-injection": "enabled"
}

Wyświetl etykiety bookbuyer przestrzeni nazw:

kubectl get namespace bookbuyer -o json | jq '.metadata.labels'

Musi być obecna następująca etykieta:

{
  "openservicemesh.io/monitored-by": "osm"
}

Jeśli nie używasz interfejsu osm wiersza polecenia, możesz ręcznie dodać te adnotacje do przestrzeni nazw. Jeśli przestrzeń nazw nie jest oznaczona adnotacją z elementem "openservicemesh.io/sidecar-injection": "enabled"lub jeśli nie jest oznaczona etykietą , "openservicemesh.io/monitored-by": "osm"iniektor OSM nie dodaje przyczepek Envoy.

Uwaga

Po osm namespace add wywołaniu, tylko nowe zasobniki są wstrzykiwane z przyczepki Envoy. Istniejące zasobniki należy ponownie uruchomić przy użyciu kubectl rollout restart deployment polecenia .

Weryfikowanie identyfikatorów CRD usługi SMI

W przypadku interfejsu usługi OSM Service Mesh (SMI) sprawdź, czy klaster ma wymagane niestandardowe definicje zasobów (CRD):

kubectl get crds

Upewnij się, że identyfikatory CRD odpowiadają wersjom dostępnym w gałęzi wydania. Aby sprawdzić, które wersje CRD są używane, zobacz Wersje obsługiwane przez usługę SMI i wybierz wersję w menu Wydania .

Pobierz wersje zainstalowanych identyfikatorów CRD przy użyciu następującego polecenia:

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

Jeśli brakuje identyfikatorów CRD, użyj następujących poleceń, aby zainstalować je w klastrze. Zastąp wersję tych poleceń zgodnie z potrzebami (na przykład zamiast wersji 1.1.0 możesz użyć wersji 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

Aby zobaczyć, jak wersje CRD zmieniają się między wydaniami, zobacz informacje o wersji OSM.

Rozwiązywanie problemów z zarządzaniem certyfikatami

Aby uzyskać informacje na temat rozwiązywania problemów z osm i zarządzania certyfikatami dla serwerów proxy usługi Envoy uruchomionych na zasobnikach aplikacji, zobacz dokumentację OSM.

Uaktualnianie wysłana

Gdy nowy zasobnik zostanie utworzony w przestrzeni nazw monitorowanej przez dodatek, OSM wprowadza w tym zasobniku moduł boczny serwera proxy usługi Envoy. Jeśli należy zaktualizować wersję aplikacji Envoy, wykonaj kroki opisane w przewodniku uaktualniania w dokumentacji OSM.

Dowiedz się więcej o rozszerzeniach klastra.
Zapoznaj się z ogólnymi wskazówkami dotyczącymi rozwiązywania problemów z klastrami Kubernetes z obsługą usługi Arc.

Udostępnij za pośrednictwem

Rozwiązywanie problemów z rozszerzeniem dla klastrów Kubernetes z obsługą usługi Azure Arc

GitOps (Flux v2)

Błędy uruchamiania suchego elementu webhook

Błędy podczas instalowania rozszerzenia microsoft.flux

Błędy podczas instalowania rozszerzenia microsoft.flux w klastrze z tożsamością zarządzaną przez pod firmy Microsoft

Wymagania dotyczące zasobów pamięci i procesora CPU dotyczące instalowania rozszerzenia microsoft.flux

Strumień v1

Azure Monitor Container Insights

Włączanie trybu uprzywilejowanego dla klastra Kubernetes oczarowanego canonical

Nie można zainstalować zasobników AMA w systemie Oracle Linux 9.x

Usługa Open Service Mesh z obsługą usługi Azure Arc

Sprawdzanie wdrożenia kontrolera OSM

Sprawdzanie zasobników kontrolera OSM

Sprawdzanie usługi kontrolera OSM

Sprawdzanie punktów końcowych kontrolera OSM

Sprawdzanie wdrożenia iniektora OSM

Sprawdzanie zasobnika iniektora OSM

Sprawdzanie usługi iniektora OSM

Sprawdzanie punktów końcowych iniektora OSM

Sprawdzanie elementów webhook: weryfikowanie i wyciszanie

`osm-mesh-config` Sprawdzanie zasobu

Sprawdzanie przestrzeni nazw

Weryfikowanie identyfikatorów CRD usługi SMI

Rozwiązywanie problemów z zarządzaniem certyfikatami

Uaktualnianie wysłana

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Rozwiązywanie problemów z rozszerzeniem dla klastrów Kubernetes z obsługą usługi Azure Arc

GitOps (Flux v2)

Błędy uruchamiania suchego elementu webhook

Błędy podczas instalowania rozszerzenia microsoft.flux

Błędy podczas instalowania rozszerzenia microsoft.flux w klastrze z tożsamością zarządzaną przez pod firmy Microsoft

Wymagania dotyczące zasobów pamięci i procesora CPU dotyczące instalowania rozszerzenia microsoft.flux

Strumień v1

Azure Monitor Container Insights

Włączanie trybu uprzywilejowanego dla klastra Kubernetes oczarowanego canonical

Nie można zainstalować zasobników AMA w systemie Oracle Linux 9.x

Usługa Open Service Mesh z obsługą usługi Azure Arc

Sprawdzanie wdrożenia kontrolera OSM

Sprawdzanie zasobników kontrolera OSM

Sprawdzanie usługi kontrolera OSM

Sprawdzanie punktów końcowych kontrolera OSM

Sprawdzanie wdrożenia iniektora OSM

Sprawdzanie zasobnika iniektora OSM

Sprawdzanie usługi iniektora OSM

Sprawdzanie punktów końcowych iniektora OSM

Sprawdzanie elementów webhook: weryfikowanie i wyciszanie

osm-mesh-config Sprawdzanie zasobu

Sprawdzanie przestrzeni nazw

Weryfikowanie identyfikatorów CRD usługi SMI

Rozwiązywanie problemów z zarządzaniem certyfikatami

Uaktualnianie wysłana

Powiązana zawartość

Opinia

Dodatkowe zasoby

`osm-mesh-config` Sprawdzanie zasobu