Устранение неполадок с расширением для кластеров Kubernetes с поддержкой Azure Arc
В этом документе приводятся советы по устранению распространенных проблем, связанных с расширениями кластера, такими как GitOps (Flux версии 2) и Сетка Open Service.
Сведения об устранении общих проблем с Kubernetes с поддержкой Azure Arc см. в статье "Устранение неполадок с Kubernetes с поддержкой Azure Arc".
GitOps (Flux версии 2)
Примечание.
Расширение Flux версии 2 можно использовать в кластерах Kubernetes с поддержкой Azure Arc или в кластерах Служба Azure Kubernetes (AKS). Эти советы по устранению неполадок обычно применяются независимо от типа кластера.
Чтобы устранить неполадки с fluxConfigurations ресурсами, выполните следующие команды Azure CLI с указанным параметром --debug :
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug
Ошибки веб-перехватчика или сухого запуска
Если вы видите, что Flux не удалось выполнить согласование с ошибкой, напримерdry-run failed, error: admission webhook "<webhook>" does not support dry run, можно устранить проблему, найдя ValidatingWebhookConfiguration или MutatingWebhookConfiguration установив значение NonesideEffects илиNoneOnDryRun:
Дополнительные сведения см. в Разделы справки устранении webhook does not support dry run ошибок?
Ошибки при установке microsoft.flux расширения
Расширение microsoft.flux устанавливает контроллеры Flux и агенты Azure GitOps в кластеры Kubernetes с поддержкой Azure Arc или Служба Azure Kubernetes (AKS). Если расширение еще не установлено в кластере и вы создаете ресурс конфигурации GitOps для этого кластера, расширение устанавливается автоматически.
Если во время установки возникает ошибка или если расширение находится в состоянии сбоя, убедитесь, что в кластере нет политик, ограничивающих создание flux-system пространства имен или ресурсов в этом пространстве имен.
Для кластера AKS убедитесь, что подписка включена Microsoft.ContainerService/AKS-ExtensionManager .
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
После этого выполните следующую команду, чтобы определить, существуют ли другие проблемы. Задайте параметр connectedClusters типа кластера (-t) для кластера с поддержкой Arc или managedClusters кластера AKS. Имя microsoft.flux расширения — "flux", если расширение было установлено автоматически во время создания конфигурации GitOps. Соответствующие сведения можно найти в объекте statuses.
az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>
Отображаемые результаты помогут определить, что произошло неправильно и как исправить его. Возможные действия по исправлению:
- Принудительное удаление расширения путем выполнения
az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters> - Удалите выпуск Helm, выполнив команду
helm uninstall flux -n flux-system flux-systemУдаление пространства имен из кластера путем выполненияkubectl delete namespaces flux-system
После этого можно повторно создать конфигурацию flux, которая автоматически устанавливает microsoft.flux расширение или переустановить расширение flux вручную.
Ошибки при установке microsoft.flux расширения в кластере с включенным удостоверением Microsoft Entra Pod
Если вы пытаетесь установить расширение Flux в кластере с включенным удостоверением pod Microsoft Entra, в модуле pod агента расширения может возникнуть ошибка:
{"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"}
Состояние расширения также возвращается как 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}}\"}]}}",
В этом случае модуль pod extension-agent пытается получить его токен из IMDS в кластере. но запрос маркера перехватывается удостоверением pod. Чтобы устранить эту проблему, выполните обновление до последней microsoft.flux версии расширения.
Проблемы с удостоверением kubelet при установке microsoft.flux расширения в кластере AKS
При использовании кластеров AKs одним из вариантов проверки подлинности является удостоверение kubelet с помощью управляемого удостоверения, назначаемого пользователем. Использование удостоверения kubelet может снизить операционные издержки и повысить безопасность при подключении к ресурсам Azure, таким как Реестр контейнеров Azure.
Чтобы разрешить Flux использовать удостоверение kubelet, добавьте параметр --config useKubeletIdentity=true при установке расширения 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
Обеспечение соблюдения требований к памяти и ЦП для microsoft.flux установки расширения
Контроллеры, установленные в кластере Kubernetes с microsoft.flux расширением, требуют правильного планирования ресурсов ЦП и памяти на узлах кластера Kubernetes. Убедитесь, что кластер может соответствовать минимальным ресурсам памяти и ЦП, которые могут быть запрошены. Обратите внимание также на максимальные ограничения для потенциальных требований к ресурсам ЦП и памяти, показанных здесь.
| Имя контейнера | Минимальный ЦП | Минимальный объем памяти | Максимальное количество ЦП | Максимальный объем памяти |
|---|---|---|---|---|
| fluxconfig-agent | 5 м | 30 Mi | 50 м | 150 Mi |
| fluxconfig-controller | 5 м | 30 Mi | 100 м | 150 Mi |
| fluent-bit | 5 м | 30 Mi | 20 м | 150 Mi |
| helm-controller | 100 м | 64 Mi | 1000 м | 1 Ги |
| source-controller | 50 м | 64 Mi | 1000 м | 1 Ги |
| kustomize-controller | 100 м | 64 Mi | 1000 м | 1 Ги |
| контроллер уведомлений | 100 м | 64 Mi | 1000 м | 1 Ги |
| image-automation-controller | 100 м | 64 Mi | 1000 м | 1 Ги |
| контроллер изображения-отражателя | 100 м | 64 Mi | 1000 м | 1 Ги |
Если вы включили пользовательскую или встроенную политику Azure Gatekeeper, которая ограничивает ресурсы для контейнеров в кластерах Kubernetes, например Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits, убедитесь, что ограничения ресурсов политики больше, чем ограничения, указанные здесь, или flux-system пространство имен является частью excludedNamespaces параметра в назначении политики.
Flux версии 1
Примечание.
Мы рекомендуем перейти на Flux версии 2 как можно скорее. Поддержка ресурсов конфигурации кластера flux версии 1, созданных до 1 января 2024 г., завершится 24 мая 2025 г. Начиная с 1 января 2024 г. вы не сможете создавать новые ресурсы конфигурации кластера Flux версии 1.
Чтобы устранить неполадки с ресурсом sourceControlConfigurations в Flux версии 1, выполните следующие команды Azure CLI с --debug указанным параметром:
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration create <parameters> --debug
Аналитика контейнера Azure Monitor
В этом разделе содержатся сведения об устранении неполадок с Аналитика контейнера Azure Monitor для кластеров Kubernetes с поддержкой Azure Arc.
Включение привилегированного режима для канонического кластера Kubernetes
Контейнер Azure Monitor Аналитика требует запуска daemonSet в привилегированном режиме. Чтобы успешно настроить мониторинг для кластера Canonical Charmed Kubernetes, выполните следующую команду:
juju config kubernetes-worker allow-privileged=true
Не удалось установить агент Azure Monitor (AMA) на Oracle Linux 9.x
При попытке установить агент Azure Monitor (AMA) в кластере Oracle Linux (RHEL) 9.x Kubernetes, модули pod AMA и pod AMA-RS могут работать неправильно из-за addon-token-adapter контейнера в модуле pod. При использовании этой ошибки при проверка журналов ama-logs-rs pod addon-token-adapter containerвы увидите выходные данные, аналогичные следующим:
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.
Эта ошибка возникает, так как для установки расширения требуется iptable_nat модуль, но этот модуль не загружается автоматически в дистрибутивы Oracle Linux (RHEL) 9.x.
Чтобы устранить эту проблему, необходимо явно загрузить iptables_nat модуль на каждом узле в кластере modprobe с помощью команды sudo modprobe iptables_nat. После входа в каждый узел и вручную добавьте iptable_nat модуль, повторите установку AMA.
Примечание.
Выполнение этого шага не делает iptables_nat модуль постоянным.
Open Service Mesh с поддержкой Azure Arc
В этом разделе содержатся команды, которые можно использовать для проверки и устранения неполадок развертывания компонентов расширения Open Service Mesh (OSM) в кластере.
Проверка развертывания контроллера OSM
kubectl get deployment -n arc-osm-system --selector app=osm-controller
Если контроллер OSM работоспособен, вы увидите следующие выходные данные:
NAME READY UP-TO-DATE AVAILABLE AGE
osm-controller 1/1 1 1 59m
Проверка модулей pod контроллера OSM
kubectl get pods -n arc-osm-system --selector app=osm-controller
Если контроллер OSM работоспособен, вы увидите следующие выходные данные:
NAME READY STATUS RESTARTS AGE
osm-controller-b5bd66db-wglzl 0/1 Evicted 0 61m
osm-controller-b5bd66db-wvl9w 1/1 Running 0 31m
Несмотря на то, что один контроллер был вытеснен в какой-то момент, есть другой, который READY 1/1 и Running с 0 перезапусками. Если столбец READY отличается от 1/1другого, сетка службы находится в неисправном состоянии. Столбец READY с 0/1 указанием сбоя контейнера плоскости управления.
Используйте следующую команду для проверки журналов контроллера:
kubectl logs -n arc-osm-system -l app=osm-controller
Столбец READY с числом выше, чем 1 после / того, как указано, что установлены боковики. Как правило, контроллер OSM не работает должным образом с подключенными боковиками.
Проверка службы контроллера OSM
kubectl get service -n arc-osm-system osm-controller
Если контроллер OSM работоспособен, вы увидите следующие выходные данные:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-controller ClusterIP 10.0.31.254 <none> 15128/TCP,9092/TCP 67m
Примечание.
Это CLUSTER-IP будет по-другому. Служба NAME и PORT(S) должна соответствовать показанной здесь службе.
Проверка конечных точек контроллера OSM
kubectl get endpoints -n arc-osm-system osm-controller
Если контроллер OSM работоспособен, вы увидите следующие выходные данные:
NAME ENDPOINTS AGE
osm-controller 10.240.1.115:9092,10.240.1.115:15128 69m
Если кластер не ENDPOINTSosm-controllerимеет, уровень управления неработоспособен. Это неработоспособное состояние означает, что модуль pod контроллера произошел сбой или что он никогда не был развернут правильно.
Проверка развертывания инектора OSM
kubectl get deployments -n arc-osm-system osm-injector
Если инектор OSM работоспособен, вы увидите выходные данные, аналогичные следующим:
NAME READY UP-TO-DATE AVAILABLE AGE
osm-injector 1/1 1 1 73m
Проверка модуля pod внедрения OSM
kubectl get pod -n arc-osm-system --selector app=osm-injector
Если инектор OSM работоспособен, вы увидите выходные данные, аналогичные следующим:
NAME READY STATUS RESTARTS AGE
osm-injector-5986c57765-vlsdk 1/1 Running 0 73m
В столбце READY должно быть значение 1/1. Любое другое значение указывает на неработоспособный модуль модуля внедрения OSM.
Проверка службы внедрения OSM
kubectl get service -n arc-osm-system osm-injector
Если инектор OSM работоспособен, вы увидите выходные данные, аналогичные следующим:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-injector ClusterIP 10.0.39.54 <none> 9090/TCP 75m
Убедитесь, что для службы osm-injector указан IP-адрес 9090. Здесь не должно быть строки EXTERNAL-IP.
Проверка конечных точек инектора OSM
kubectl get endpoints -n arc-osm-system osm-injector
Если инектор OSM работоспособен, вы увидите выходные данные, аналогичные следующим:
NAME ENDPOINTS AGE
osm-injector 10.240.1.172:9090 75m
Чтобы OSM работал нормально, требуется хотя бы одна конечная точка для osm-injector. IP-адрес конечных точек внедрения OSM будет отличаться, но порт 9090 должен совпадать.
Проверка проверки и изменение веб-перехватчиков
kubectl get ValidatingWebhookConfiguration --selector app=osm-controller
Если проверка веб-перехватчика работоспособна, вы увидите следующие выходные данные:
NAME WEBHOOKS AGE
osm-validator-mesh-osm 1 81m
kubectl get MutatingWebhookConfiguration --selector app=osm-injector
Если мутирующий веб-перехватчик работоспособен, вы увидите выходные данные, аналогичные следующим:
NAME WEBHOOKS AGE
arc-osm-webhook-osm 1 102m
Проверьте наличие службы и пакета ЦС проверяющего веб-перехватчика с помощью следующей команды:
kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'
Хорошо настроенная конфигурация проверки веб-перехватчика будет иметь выходные данные, аналогичные следующим:
{
"name": "osm-config-validator",
"namespace": "arc-osm-system",
"path": "/validate",
"port": 9093
}
Проверьте наличие службы и пакета ЦС для мутировающего веб-перехватчика с помощью следующей команды:
kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'
Хорошо настроенная конфигурация веб-перехватчика будет иметь выходные данные, аналогичные следующим:
{
"name": "osm-injector",
"namespace": "arc-osm-system",
"path": "/mutate-pod-creation",
"port": 9090
}
Проверьте, предоставил ли контроллер OSM проверку (или изменение) веб-перехватчика пакет ЦС с помощью следующей команды:
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
Пример результата:
1845
Число здесь обозначает размер пакета (количество байтов) центра сертификации. Если выходные данные пусты, 0 или число менее 1000, пакет ЦС не подготовлен правильно. Без правильного пакета ValidatingWebhook ЦС возникает ошибка.
Проверка ресурса osm-mesh-config
Проверьте наличие ресурса:
kubectl get meshconfig osm-mesh-config -n arc-osm-system
Проверьте содержимое OSM MeshConfig:
kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml
Должен отобразиться примерно такой результат:
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:
| Ключ. | Тип | Значение по умолчанию | Примеры команд для установки исправления 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 | array | [] |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge |
| spec.traffic.outboundIPRangeExclusionList | array | [] |
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 | array | [] |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge |
| spec.certificate.serviceCertValidityDuration | строка | "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 | строка | "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 | строка | "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 |
Проверка пространств имен
Примечание.
Пространство имен arc-osm-system никогда не будет участвовать в сетке служб и никогда не будет помечено или заносится с помощью клавиши или значений, показанных здесь.
Для присоединения пространства имен к определенной сервисной сетке используется команда osm namespace add. Если пространство имен Kubernetes входит в сетку, выполните следующие действия, чтобы подтвердить выполнение требований.
Проверка аннотации для пространства имен bookbuyer:
kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'
Должны присутствовать следующие заметки:
{
"openservicemesh.io/sidecar-injection": "enabled"
}
Проверка меток для пространства имен bookbuyer:
kubectl get namespace bookbuyer -o json | jq '.metadata.labels'
Должны присутствовать следующие метки:
{
"openservicemesh.io/monitored-by": "osm"
}
Если вы не используете osm ИНТЕРФЕЙС командной строки, вы также можете вручную добавить эти заметки в пространства имен. Если пространство имен не отмечено "openservicemesh.io/sidecar-injection": "enabled"или не помечено с "openservicemesh.io/monitored-by": "osm"меткой, средство внедрения OSM не добавит боковики Envoy.
Примечание.
После вызова osm namespace add с помощью расширения Envoy будут внедряться только новые объекты pod. Существующие модули pod необходимо перезапустить с помощью kubectl rollout restart deployment команды.
Проверка идентификаторов SMI
Проверьте, имеет ли кластер необходимые пользовательские определения ресурсов (CRD) с помощью следующей команды:
kubectl get crds
Убедитесь, что CRD соответствуют версиям, доступным в ветви выпуска. Чтобы убедиться, какие версии CRD используются, перейдите на страницу поддерживаемых версий SMI и выберите свою версию в раскрывающемся списке "Выпуски ".
Получите версии установленных 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
Если определений настраиваемых ресурсов нет, используйте следующие команды для их установки в кластере: Замените версию в этих командах по мере необходимости (например, версия 1.1.0 будет 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
Чтобы просмотреть изменения CRD между выпусками, обратитесь к заметкам о выпуске OSM.
Устранение неполадок управления сертификатами
Сведения о проблемах OSM и управлении сертификатами для прокси-серверов Envoy, работающих в модулях pod приложений, см. на сайте документации OSM.
Обновление Envoy
При создании нового модуля pod в пространстве имен, отслеживаемом надстройкой, OSM внедряет прокси-контейнер Envoy в этот модуль pod. Если необходимо обновить версию Envoy, выполните действия, описанные в руководстве по обновлению на сайте документации OSM.
Следующие шаги
- Дополнительные сведения о расширениях кластера.
- Ознакомьтесь с общими советами по устранению неполадок кластеров Kubernetes с поддержкой Arc.