Поделиться через


Устранение неполадок с расширением для кластеров 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.