istio.io/index.md at 315487e71035a9ad8045f05ec314b5c9cf061a35

15 KiB

Raw Blame History

title

description

force_inline_toc

weight

aliases

owner

test

Проблеми з інʼєкцією Sidecar

Вирішення загальних проблем із використанням вебхуків Kubernetes для автоматичної інʼєкції sidecar у Istio.

true

/uk/docs/ops/troubleshooting/injection

istio/wg-user-experience-maintainers

n/a

Результат інʼєкції sidecar не відповідає очікуванням

Це включає випадки, коли виконано інʼєкцію sidecar тоді, коли це не очікувалося, і відсутність інʼєкції sidecar, коли це було потрібно.

Переконайтеся, що ваш pod не знаходиться в просторі імен kube-system або kube-public. Автоматична інʼєкція sidecar буде проігнорована для podʼів у цих просторах імен.
Переконайтеся, що ваш pod не має hostNetwork: true у своїй специфікації. Автоматична інʼєкція sidecar буде проігнорована для podʼів, які знаходяться в мережі хосту.

Модель sidecar передбачає, що зміни iptables, необхідні для перехоплення трафіку Envoy, відбуваються всередині podʼа. Для podʼів в мережі хосту це припущення порушується, що може призвести до збоїв маршрутизації на рівні хосту.
Перевірте namespaceSelector вебхука, щоб визначити, чи вебхук має область застосування "opt-in" чи "opt-out" для цільового простору імен.

namespaceSelector для opt-in виглядає так:

{{< text bash yaml >}} $ kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml | grep "namespaceSelector:" -A5 namespaceSelector: matchLabels: istio-injection: enabled rules:
- apiGroups:
  - "" {{< /text >}}
Вебхук інʼєкції буде викликано для podʼів, створених у просторах імен з міткою istio-injection=enabled.

{{< text bash >}} $ kubectl get namespace -L istio-injection NAME STATUS AGE ISTIO-INJECTION default Active 18d enabled istio-system Active 3d kube-public Active 18d kube-system Active 18d {{< /text >}}

namespaceSelector для opt-out виглядає так:

{{< text bash >}} $ kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml | grep "namespaceSelector:" -A5 namespaceSelector: matchExpressions: - key: istio-injection operator: NotIn values: - disabled rules:
- apiGroups:
  - "" {{< /text >}}
Вебхук інʼєкції буде викликано для podʼів, створених у просторах імен без мітки istio-injection=disabled.

{{< text bash >}} $ kubectl get namespace -L istio-injection NAME STATUS AGE ISTIO-INJECTION default Active 18d istio-system Active 3d disabled kube-public Active 18d disabled kube-system Active 18d disabled {{< /text >}}

Переконайтеся, що простір імен вашого застосунку правильно позначений і (пере)поставте мітки відповідно, наприклад:

{{< text bash >}} $ kubectl label namespace istio-system istio-injection=disabled --overwrite {{< /text >}}

(повторіть для всіх просторів імен, у яких вебхук інʼєкції має бути викликаний для нових podʼів)

{{< text bash >}} $ kubectl label namespace default istio-injection=enabled --overwrite {{< /text >}}
Перевірте стандартну політику

Перевірте стандартну політику інʼєкції у configmap istio-sidecar-injector.

{{< text bash yaml >}} $ kubectl -n istio-system get configmap istio-sidecar-injector -o jsonpath='{.data.config}' | grep policy: policy: enabled {{< /text >}}

Дозволені значення політики — disabled та enabled. Стандартна політика застосовується лише в разі відповідності namespaceSelector вебхука до цільового простору імен. Невідомі політики повністю вимикають інʼєкцію.
Перевірте переважну анотацію для podʼа

Стандартну політику можна перевизначити за допомогою мітки sidecar.istio.io/inject у метаданих шаблону podʼа. Метадані розгортання ігноруються. Значення мітки true виконує примусову інʼєкцію sidecar, тоді як значення false не виконує примусової інʼєкції sidecar.

Наступна мітка перевизначає будь-яку стандартну політику і виконує примусову інʼєкцію sidecar:

{{< text bash yaml >}} $ kubectl get deployment curl -o yaml | grep "sidecar.istio.io/inject:" -B4 template: metadata: labels: app: curl sidecar.istio.io/inject: "true" {{< /text >}}

Поди не можуть бути створені взагалі

Виконайте команду kubectl describe -n namespace deployment name для розгортання невдалого podʼа. Невдача виклику вебхука інʼєкції зазвичай буде зафіксована в журналі подій.

{{< text plain >}} Warning FailedCreate 3m (x17 over 8m) replicaset-controller Error creating: Internal error occurred:
failed calling admission webhook "sidecar-injector.istio.io": Post https://istiod.istio-system.svc:443/inject:
x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying
to verify candidate authority certificate "Kubernetes.cluster.local") {{< /text >}}

Помилки x509: certificate signed by unknown authority зазвичай викликані порожнім caBundle у конфігурації вебхука.

Перевірте, щоб caBundle у mutatingwebhookconfiguration відповідало кореневому сертифікату, змонтованому в podʼі istiod.

{{< text bash >}} $ kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml -o jsonpath='{.webhooks[0].clientConfig.caBundle}' | md5sum 4b95d2ba22ce8971c7c92084da31faf0 - $ kubectl -n istio-system get configmap istio-ca-root-cert -o jsonpath='{.data.root-cert.pem}' | base64 -w 0 | md5sum 4b95d2ba22ce8971c7c92084da31faf0 - {{< /text >}}

CA сертифікат повинен збігатися. Якщо вони не збігаються, перезапустіть podʼи istiod.

{{< text bash >}} $ kubectl -n istio-system patch deployment istiod
-p "{"spec":{"template":{"metadata":{"labels":{"date":"date +'%s'"}}}}}" deployment.extensions "istiod" patched {{< /text >}}

Помилки в статусі розгортання

Коли автоматична інʼєкція sidecar увімкнена для podʼа, і інʼєкція за будь-якої причини не вдається, створення podʼа також зазнає невдачі. У таких випадках ви можете перевірити статус розгортання podʼа, щоб визначити помилку. Помилки також зʼявляться в подіях простору імен, повʼязаного з розгортанням.

Наприклад, якщо pod контролера istiod не працював, коли ви намагалися розгорнути ваш pod, події покажуть таку помилку:

{{< text bash >}} $ kubectl get events -n curl ... 23m Normal SuccessfulCreate replicaset/curl-9454cc476 Created pod: curl-9454cc476-khp45 22m Warning FailedCreate replicaset/curl-9454cc476 Error creating: Internal error occurred: failed calling webhook "namespace.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": dial tcp 10.96.44.51:443: connect: connection refused {{< /text >}}

{{< text bash >}} $ kubectl -n istio-system get pod -lapp=istiod NAME READY STATUS RESTARTS AGE istiod-7d46d8d9db-jz2mh 1/1 Running 0 2d {{< /text >}}

{{< text bash >}} $ kubectl -n istio-system get endpoints istiod NAME ENDPOINTS AGE istiod 10.244.2.8:15012,10.244.2.8:15010,10.244.2.8:15017 + 1 more... 3h18m {{< /text >}}

Якщо pod або точки доступу istiod не готові, перевірте журнали podʼа та статус для будь-яких ознак того, чому вебхук podʼа не запускається і не обслуговує трафік.

{{< text bash >}} for pod in(kubectl -n istio-system get pod -lapp=istiod -o jsonpath='{.items[*].metadata.name}'); do
kubectl -n istio-system logs ${pod}
done

for pod in(kubectl -n istio-system get pod -l app=istiod -o name); do
kubectl -n istio-system describe ${pod};
done $ {{< /text >}}

Автоматична інʼєкція sidecar не працює, якщо у сервера API Kubernetes є налаштування проксі

Коли сервер API Kubernetes має налаштування проксі, такі як:

{{< text yaml >}} env:

name: http_proxy value: http://proxy-wsa.esl.foo.com:80
name: https_proxy value: http://proxy-wsa.esl.foo.com:80
name: no_proxy value: 127.0.0.1,localhost,dockerhub.foo.com,devhub-docker.foo.com,10.84.100.125,10.84.100.126,10.84.100.127 {{< /text >}}

З такими налаштуваннями інʼєкція sidecar зазнає невдачі. Єдиний повʼязаний запис можна знайти в журналі kube-apiserver:

{{< text plain >}} W0227 21:51:03.156818 1 admission.go:257] Failed calling webhook, failing open sidecar-injector.istio.io: failed calling admission webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-system.svc:443/inject: Service Unavailable {{< /text >}}

Переконайтеся, що CIDR podʼів і сервісів не оброблені відповідно до змінних *_proxy. Перевірте файли та журнали kube-apiserver, щоб перевірити конфігурацію та чи оброблялись якісь запити.

Одним зі способів вирішення є видалення налаштувань проксі з маніфесту kube-apiserver, іншим — включення istio-sidecar-injector.istio-system.svc або .svc у значення no_proxy. Переконайтеся, що kube-apiserver перезапущено після кожного способу розвʼязання.

Була сповіщено про проблему у Kubernetes, повʼязану з цим, і згодом вона була закрита. https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443

Обмеження при використанні Tcpdump у podʼах

Tcpdump не працює у sidecar podʼі — контейнер не запускається з правами root. Проте будь-який інший контейнер у тому ж podʼі побачить усі пакети, оскільки мережевий простір імен спільний. iptables також побачить конфігурацію на рівні podʼа.

Комунікація між Envoy та застосунком відбувається на 127.0.0.1 і не є зашифрованою.

Кластер не масштабується автоматично

Через те, що контейнер sidecar монтує локальний том для зберігання, автомастабувач вузлів не може видалити вузли з podʼами, до яких було виконано інʼєкції. Це є відомою проблемою. Вирішенням є додавання анотації podʼа "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" до podʼів з інʼєкіями.

Pod або контейнери запускаються з мережевими проблемами, якщо istio-proxy не готовий

Багато застосунків виконують команди або перевірки під час запуску, які потребують зʼєднання з мережею. Це може призвести до зависання або перезавантаження контейнерів застосунку, якщо контейнер sidecar istio-proxy не готовий.

Щоб уникнути цього, встановіть holdApplicationUntilProxyStarts на true. Це призведе до інʼєкції sidecar на початку списку контейнерів podʼа та налаштує його так, щоб блокувати запуск усіх інших контейнерів до тих пір, поки проксі не буде готовий.

Це можна додати як глобальну опцію конфігурації:

{{< text yaml >}} values.global.proxy.holdApplicationUntilProxyStarts: true {{< /text >}}

або як анотацію podʼа:

{{< text yaml >}} proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }' {{< /text >}}

15 KiB Raw Blame History Unescape Escape