Rozwiązywanie problemów z rozszerzeniem dla klastrów Kubernetes z obsługą usługi Azure Arc
Ten dokument zawiera porady dotyczące rozwiązywania typowych problemów związanych z rozszerzeniami klastra, takimi jak GitOps (Flux v2) i Open Service Mesh.
Aby uzyskać pomoc dotyczącą rozwiązywania ogólnych 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
Rozszerzenie Flux v2 może być używane w klastrach Kubernetes z włączoną usługą Azure Arc lub w klastrach usługi Azure Kubernetes Service (AKS). Te porady dotyczące rozwiązywania problemów są zwykle stosowane niezależnie od typu klastra.
Aby uzyskać ogólną pomoc dotyczącą rozwiązywania problemów z fluxConfigurations zasobami, uruchom następujące polecenia interfejsu wiersza polecenia platformy Azure z określonym parametrem --debug :
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug
Błędy uruchamiania elementu webhook/suchego
Jeśli widzisz błąd Flux nie można uzgodnić z błędem, na przykład dry-run failed, error: admission webhook "<webhook>" does not support dry run, możesz rozwiązać ten problem, wyszukując element lub i ustawiając ValidatingWebhookConfiguration wartość sideEffects None na lub :NoneOnDryRunMutatingWebhookConfiguration
Aby uzyskać więcej informacji, zobacz Jak mogę usunąć webhook does not support dry run błędy?
Błędy podczas instalowania microsoft.flux rozszerzenia
Rozszerzenie microsoft.flux instaluje kontrolery Flux i agentów usługi Azure GitOps w klastrach Kubernetes z włączoną usługą Azure Arc lub Azure Kubernetes Service (AKS). Jeśli rozszerzenie nie jest jeszcze zainstalowane w klastrze i tworzysz zasób konfiguracji GitOps dla tego klastra, rozszerzenie jest instalowane automatycznie.
Jeśli podczas instalacji wystąpi błąd lub jeśli rozszerzenie jest w stanie niepowodzenia, upewnij się, że klaster nie ma żadnych zasad, które ograniczają tworzenie flux-system przestrzeni nazw lub zasobów w tej przestrzeni nazw.
W przypadku klastra usługi AKS upewnij się, że subskrypcja ma włączoną flagę Microsoft.ContainerService/AKS-ExtensionManager funkcji.
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
Następnie uruchom to polecenie, aby ustalić, czy występują inne problemy. Ustaw parametr typu klastra (-t) na connectedClusters dla klastra z obsługą usługi Arc lub managedClusters dla klastra usługi AKS. Nazwa microsoft.flux rozszerzenia to "flux", jeśli rozszerzenie zostało zainstalowane automatycznie podczas tworzenia konfiguracji gitOps. Informacji należy szukać w obiekcie statuses.
az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>
Wyświetlone wyniki mogą pomóc w ustaleniu, co poszło nie tak i jak go naprawić. 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-systemUsuń przestrzeń nazw z klastra, uruchamiając poleceniekubectl delete namespaces flux-system
Następnie można ponownie utworzyć konfigurację strumienia, która automatycznie instaluje microsoft.flux rozszerzenie, lub ponownie zainstalować rozszerzenie flux ręcznie.
Błędy podczas microsoft.flux instalowania rozszerzenia w klastrze z włączoną tożsamością pod firmy Microsoft
Jeśli spróbujesz zainstalować rozszerzenie Flux w klastrze z włączoną tożsamością zasobnika Microsoft Entra, może wystąpić błąd w zasobniku extension-agent:
{"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 również 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 zasobnik extension-agent próbuje pobrać token z usługi IMDS w klastrze. ale żądanie tokenu jest przechwytywane przez tożsamość zasobnika). Aby rozwiązać ten problem, przeprowadź uaktualnienie do najnowszej microsoft.flux wersji rozszerzenia.
Problemy z tożsamością kubelet podczas instalowania microsoft.flux rozszerzenia w klastrze usługi AKS
W przypadku klastrów AKs jedną z opcji uwierzytelniania jest tożsamość kubelet przy użyciu tożsamości zarządzanej przypisanej przez użytkownika. Użycie tożsamości kubelet może zmniejszyć nakład pracy operacyjnej i zwiększyć bezpieczeństwo podczas nawiązywania połączenia z zasobami platformy Azure, takimi jak usługa Azure Container Registry.
Aby umożliwić platformie Flux używanie tożsamości kubelet, dodaj parametr --config useKubeletIdentity=true podczas instalowania rozszerzenia 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
Zapewnianie spełnienia wymagań dotyczących pamięci i procesora CPU na potrzeby microsoft.flux instalacji rozszerzenia
Kontrolery zainstalowane w klastrze Kubernetes z microsoft.flux rozszerzeniem wymagają, aby zasoby procesora CPU i pamięci były prawidłowo zaplanowane na węzłach klastra Kubernetes. Upewnij się, że klaster jest w stanie spełnić wymagania dotyczące minimalnej ilości pamięci i zasobów procesora CPU, które mogą być wymagane. Należy również pamiętać o maksymalnych limitach dla potencjalnych wymagań dotyczących zasobów procesora CPU i pamięci przedstawionych tutaj.
| 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 |
| kontroler powiadomień | 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 Gatekeeper, które ograniczają zasoby dla kontenerów w klastrach Kubernetes, takich jak Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits, upewnij się, że limity zasobów w zasadach są większe niż limity pokazane w tym miejscu lub że flux-system przestrzeń nazw jest częścią excludedNamespaces parametru w przypisaniu zasad.
Strumień v1
Uwaga
Zalecamy jak najszybsze przeprowadzenie migracji do wersji Flux v2 . Obsługa zasobów konfiguracji klastra opartych na platformie Flux w wersji 1 utworzonych przed 1 stycznia 2024 r. zakoń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 w środowisku Flux v1, uruchom następujące polecenia interfejsu sourceControlConfigurations wiersza polecenia platformy Azure z określonym parametrem --debug :
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug
Azure Monitor Container Insights
Ta sekcja zawiera pomoc w rozwiązywaniu problemów z usługą Azure Monitor Container Insights dla klastrów Kubernetes z obsługą usługi Azure Arc.
Włączanie trybu uprzywilejowanego dla klastra Canonical Charmed Kubernetes
Usługa Azure Monitor Container Insights wymaga, aby element DaemonSet 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ć agenta usługi Azure Monitor (AMA) w systemie Oracle Linux 9.x
Podczas próby zainstalowania agenta usługi Azure Monitor (AMA) w klastrze Oracle Linux (RHEL) 9.x Kubernetes zasobniki AMA i zasobnik AMA-RS mogą nie działać prawidłowo z powodu kontenera addon-token-adapter w zasobniku. W przypadku tego błędu podczas sprawdzania dzienników ama-logs-rs zasobnika addon-token-adapter containersą wyświetlane dane wyjściowe podobne do następujących:
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 przy użyciu modprobe 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
Ta sekcja zawiera 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, zobaczysz dane wyjściowe podobne do:
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 został eksmitowany w pewnym momencie, jest inny, który jest READY 1/1 i Running z 0 ponownym uruchomieniem. Jeśli kolumna READY jest inna niż 1/1, siatka usługi jest w stanie przerwania. Kolumna READY z 0/1 wskazuje, że 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
Kolumna READY o liczbie wyższej niż 1 po / tym, jak wskazuje, że są zainstalowane przyczepki. Kontroler OSM zwykle nie działa prawidłowo z przyczepkami dołączonymi.
Sprawdzanie usługi kontrolera OSM
kubectl get service -n arc-osm-system osm-controller
Jeśli kontroler OSM jest w dobrej kondycji, zobaczysz następujące dane wyjściowe:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-controller ClusterIP 10.0.31.254 <none> 15128/TCP,9092/TCP 67m
Uwaga
CLUSTER-IP Będzie inaczej. Usługa NAME powinna PORT(S) być zgodna z tym, co pokazano tutaj.
Sprawdzanie punktów końcowych kontrolera OSM
kubectl get endpoints -n arc-osm-system osm-controller
Jeśli kontroler OSM jest w dobrej kondycji, zobaczysz dane wyjściowe podobne do:
NAME ENDPOINTS AGE
osm-controller 10.240.1.115:9092,10.240.1.115:15128 69m
Jeśli klaster nie ENDPOINTS ma dla osm-controllerprogramu , 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, zobaczysz dane wyjściowe podobne do:
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, zobaczysz dane wyjściowe podobne do:
NAME READY STATUS RESTARTS AGE
osm-injector-5986c57765-vlsdk 1/1 Running 0 73m
Kolumna 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, zobaczysz dane wyjściowe podobne do:
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. Nie powinno być żadnych EXTERNAL-IP.
Sprawdzanie punktów końcowych iniektora OSM
kubectl get endpoints -n arc-osm-system osm-injector
Jeśli wstrzykiwacz OSM jest w dobrej kondycji, zobaczysz dane wyjściowe podobne do:
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 będzie się różnić, ale port 9090 musi być taki sam.
Sprawdzanie sprawdzania poprawności elementów webhook i mutowania
kubectl get ValidatingWebhookConfiguration --selector app=osm-controller
Jeśli element webhook sprawdzania poprawności jest w dobrej kondycji , zobaczysz dane wyjściowe podobne do następujących:
NAME WEBHOOKS AGE
osm-validator-mesh-osm 1 81m
kubectl get MutatingWebhookConfiguration --selector app=osm-injector
Jeśli element webhook Mutating jest w dobrej kondycji , zobaczysz dane wyjściowe podobne do:
NAME WEBHOOKS AGE
arc-osm-webhook-osm 1 102m
Sprawdź usługę i 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 skonfigurowana konfiguracja sprawdzania poprawności elementu webhook będzie miała dane wyjściowe podobne do następujących:
{
"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 skonfigurowana konfiguracja mutowania elementu webhook będzie mieć dane wyjściowe podobne do następujących:
{
"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:
1845
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ź zawartość pliku OSM MeshConfig:
kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml
Powinny zostać wyświetlone dane wyjściowe podobne do poniższych:
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 wartości zasobów:
| Klucz | Typ | Wartość domyślna | 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
Przestrzeń nazw arc-osm-system nigdy nie będzie uczestniczyć w siatce usługi i nigdy nie zostanie oznaczona etykietą ani adnotacją z podanymi tutaj kluczami/wartościami.
Używamy osm namespace add polecenia do łączenia przestrzeni nazw z daną siatką usług. Gdy przestrzeń nazw kubernetes jest częścią siatki, wykonaj następujące kroki, aby potwierdzić spełnienie wymagań.
Wyświetl adnotacje przestrzeni nazw bookbuyer:
kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'
Musi istnieć następująca adnotacja:
{
"openservicemesh.io/sidecar-injection": "enabled"
}
Wyświetl etykiety przestrzeni nazw bookbuyer:
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 osm interfejsu wiersza polecenia, możesz również ręcznie dodać te adnotacje do przestrzeni nazw. Jeśli przestrzeń nazw nie jest oznaczona adnotacją z elementem "openservicemesh.io/sidecar-injection": "enabled"lub nie jest oznaczona etykietą "openservicemesh.io/monitored-by": "osm", wstrzykiwacz OSM nie doda przyczepek Envoy.
Uwaga
Po osm namespace add wywołaniu zostanie wstrzymywane tylko nowe zasobniki z przyczepki Envoy. Istniejące zasobniki należy ponownie uruchomić za kubectl rollout restart deployment pomocą polecenia .
Weryfikowanie identyfikatorów CRD usługi SMI
Sprawdź, czy klaster ma wymagane niestandardowe definicje zasobów (CRD), używając następującego polecenia:
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, odwiedź stronę obsługiwanych wersji usługi SMI i wybierz wersję z listy rozwijanej Wydania .
Pobierz wersje zainstalowanych identyfikatorów CRD za pomocą 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 wersja 1.1.0 będzie 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ć zmiany CRD między wydaniami, zapoznaj się z informacjami o wersji OSM.
Rozwiązywanie problemów z zarządzaniem certyfikatami
Aby uzyskać informacje na temat problemów z osm i zarządzania certyfikatami serwerów proxy usługi Envoy uruchomionych na zasobnikach aplikacji, zobacz witrynę dokumentacji OSM.
Uaktualnianie wysłana
Po utworzeniu nowego zasobnika w przestrzeni nazw monitorowanej przez dodatek osm wprowadza w tym zasobniku przyczepkę serwera proxy usługi Envoy. Jeśli należy zaktualizować wersję aplikacji Envoy, wykonaj kroki opisane w przewodniku uaktualniania w witrynie dokumentacji OSM.
Następne kroki
- 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.