Устранение неполадок с расширением для кластеров Kubernetes с поддержкой Azure Arc
В этой статье описываются советы по устранению распространенных проблем, связанных с расширениями кластера, такими как GitOps (Flux версии 2) в Azure или Open Service Mesh (OSM).
Сведения об устранении неполадок с 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
. В конфигурации задайте значение для sideEffects
None
или NoneOnDryRun
.
Дополнительные сведения см. в разделе Разделы справки устранение ошибок веб-перехватчика не поддерживает ошибки сухого запуска?.
Ошибки при установке расширения microsoft.flux
Расширение microsoft.flux
устанавливает контроллеры Flux и агенты Azure GitOps в кластере Kubernetes с поддержкой Azure Arc или кластере Служба Azure Kubernetes (AKS). Если расширение еще не установлено в кластере и вы создаете ресурс конфигурации GitOps для кластера, расширение устанавливается автоматически.
Если во время установки возникает ошибка или если расширение отображает Failed
состояние, убедитесь, что в кластере нет политик, ограничивающих создание flux-system
пространства имен или любого из ресурсов в этом пространстве имен.
Для кластера AKS убедитесь, что Microsoft.ContainerService/AKS-ExtensionManager
флаг функции включен в подписке Azure:
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
Затем выполните следующую команду, чтобы определить, существуют ли другие проблемы. Задайте параметр типа кластера (-t
) connectedClusters
для кластера с поддержкой Azure Arc или managedClusters
для кластера AKS. Если расширение было установлено автоматически при создании конфигурации microsoft.flux
GitOps, имя расширения — flux
.
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 в кластере с управляемым модулем Microsoft Entra pod, в pod может возникнуть 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"}
Состояние расширения возвращается следующим образом 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}}\"}]}}",
В этом случае extension-agent
модуль pod пытается получить его маркер из службы метаданных экземпляра Azure в кластере, но запрос токена перехватывается удостоверением pod. Чтобы устранить эту проблему, выполните обновление до последней microsoft.flux
версии расширения.
Требования к ресурсам памяти и ЦП для установки расширения 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 Ги |
notification-controller |
100 м | 64 Mi | 1000 м | 1 Ги |
image-automation-controller |
100 м | 64 Mi | 1000 м | 1 Ги |
image-reflector-controller |
100 м | 64 Mi | 1000 м | 1 Ги |
Если вы включили настраиваемую или встроенную политику Политика Azure Gatekeeper, которая ограничивает ресурсы для контейнеров в кластерах Kubernetes, убедитесь, что ограничения ресурсов политики больше ограничений, отображаемых в предыдущей таблице, или flux-system
пространство имен является частью excludedNamespaces
параметра в назначении политики. Примером политики в этом сценарии является Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits
.
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 flux create <parameters> --debug
Аналитика контейнеров Azure Monitor
В этом разделе приводятся сведения об устранении неполадок с аналитикой контейнеров в Azure Monitor для кластеров Kubernetes с поддержкой Azure Arc.
Включение привилегированного режима для канонического кластера Kubernetes
Azure Monitor Container Insights требует выполнения Kubernetes DaemonSet в привилегированном режиме. Чтобы успешно настроить мониторинг для кластера Canonical Charmed Kubernetes, выполните следующую команду:
juju config kubernetes-worker allow-privileged=true
Не удается установить модули pod AMA в Oracle Linux 9.x
Если вы попытаетесь установить агент Azure Monitor (AMA) в кластере Oracle Linux (Red Hat Enterprise 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
состояние Evicted
1/1
и Running
с 0
перезапусками. READY
Если состояние отличается от 1/1
состояния, сетка службы находится в неисправном состоянии. Если READY
это 0/1
так, контейнер плоскости управления завершается сбоем.
Используйте следующую команду для проверки журналов контроллера:
kubectl logs -n arc-osm-system -l app=osm-controller
READY
Если состояние больше, чем 1
после боковой косой черты (/
), устанавливаются боковики. Контроллер OSM обычно не работает правильно при присоединении боководов.
Проверка службы контроллера 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
Если кластер не ENDPOINTS
имеет значения osm-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
Проверка модуля внедрения 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
Убедитесь, что IP-адрес, указанный для osm-injector
службы 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
значения ресурсов:
Ключ | Тип | Default value | Примеры команд исправлений 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
вызова только новые модули pod внедряются с помощью бокового автомобиля Envoy. Существующие модули pod необходимо перезапустить с помощью kubectl rollout restart deployment
команды.
Проверка идентификаторов SMI
Для интерфейса сетки службы OSM (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. Если необходимо обновить версию Envoy, выполните действия, описанные в руководстве по обновлению в документации ПО OSM.
Связанный контент
- Дополнительные сведения о расширениях кластера.
- Ознакомьтесь с общими советами по устранению неполадок кластеров Kubernetes с поддержкой Arc.