Перевірка справності сервісів Istio

Протоколи перевірки справності Kubernetes описують кілька способів налаштування перевірок справності та готовності:

  1. Команда
  2. HTTP запит
  3. TCP перевірка
  4. gRPC перевірка

Метод з командою працює без змін, але HTTP запити, TCP перевірки та gRPC перевірки потребують внесення змін до конфігурації podʼа.

Запити перевірки справності до сервісу liveness-http надсилаються Kubelet. Це стає проблемою, коли увімкнено взаємний TLS, оскільки Kubelet не має сертифіката, виданого Istio. Тому запити перевірки справності зазнають невдачі.

Перевірки TCP потребують спеціальної обробки, оскільки Istio перенаправляє весь вхідний трафік у sidecar, і всі TCP порти виглядають відкритими. Kubelet просто перевіряє, чи є процес, який слухає на вказаному порту, тому перевірка завжди буде успішною, поки sidecar працює.

Istio розвʼязує обидві ці проблеми, переписуючи перевірку готовності/справності застосунку PodSpec, щоб запит перевірки надсилався до агента sidecar.

Приклад переписування перевірки справності

Щоб продемонструвати, як переписується перевірка готовності/справності на рівні PodSpec застосунку, скористаємося зразком liveness-http-same-port.

Спочатку створіть і позначте простір імен для прикладу:

$ kubectl create namespace istio-io-health-rewrite
$ kubectl label namespace istio-io-health-rewrite istio-injection=enabled

І розгорніть демонстраційний застосунок:

$ kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: liveness-http
  namespace: istio-io-health-rewrite
spec:
  selector:
    matchLabels:
      app: liveness-http
      version: v1
  template:
    metadata:
      labels:
        app: liveness-http
        version: v1
    spec:
      containers:
      - name: liveness-http
        image: docker.io/istio/health:example
        ports:
        - containerPort: 8001
        livenessProbe:
          httpGet:
            path: /foo
            port: 8001
          initialDelaySeconds: 5
          periodSeconds: 5
EOF

Після розгортання ви можете перевірити контейнер застосунку podʼа, щоб побачити змінений шлях:

$ kubectl get pod "$LIVENESS_POD" -n istio-io-health-rewrite -o json | jq '.spec.containers[0].livenessProbe.httpGet'
{
  "path": "/app-health/liveness-http/livez",
  "port": 15020,
  "scheme": "HTTP"
}

Оригінальний шлях livenessProbe тепер зіставлено на новий шлях у змінній середовища контейнера sidecar ISTIO_KUBE_APP_PROBERS:

$ kubectl get pod "$LIVENESS_POD" -n istio-io-health-rewrite -o=jsonpath="{.spec.containers[1].env[?(@.name=='ISTIO_KUBE_APP_PROBERS')]}"
{
  "name":"ISTIO_KUBE_APP_PROBERS",
  "value":"{\"/app-health/liveness-http/livez\":{\"httpGet\":{\"path\":\"/foo\",\"port\":8001,\"scheme\":\"HTTP\"},\"timeoutSeconds\":1}}"
}

Для HTTP та gRPC запитів агент sidecar перенаправляє запит до застосунку і видаляє тіло відповіді, повертаючи тільки код відповіді. Для перевірок TCP агент sidecar потім виконає перевірку порту, уникаючи перенаправлення трафіку.

Переписування проблемних перевірок стандартно увімкнено у всіх стандартних профілях конфігурації Istio конфігураційних профілях, але його можна вимкнути, як описано нижче.

Перевірки справності та готовності за допомогою команди

Istio надає демонстраційний застосунок для перевірки справності, який реалізує цей підхід. Щоб продемонструвати його роботу з увімкненим взаємним TLS, спочатку створіть простір імен для прикладу:

$ kubectl create ns istio-io-health

Щоб налаштувати строгий взаємний TLS, виконайте:

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "istio-io-health"
spec:
  mtls:
    mode: STRICT
EOF

Далі перейдіть до кореневої теки установки Istio і виконайте наступну команду для розгортання демонстраційного сервісу:

Zip
$ kubectl -n istio-io-health apply -f <(istioctl kube-inject -f @samples/health-check/liveness-command.yaml@)

Щоб підтвердити, що перевірки справності працюють, перевірте статус демонстраційного podʼа, щоб упевнитися, що він працює.

$ kubectl -n istio-io-health get pod
NAME                             READY     STATUS    RESTARTS   AGE
liveness-6857c8775f-zdv9r        2/2       Running   0           4m

Перевірки справності та готовності за допомогою HTTP, TCP і gRPC

Як зазначалося раніше, Istio стандартно використовує переписування перевірок для реалізації HTTP, TCP і gRPC перевірок. Ви можете вимкнути цю функцію або для конкретних podʼів, або глобально.

Вимкнення переписування перевірок для podʼа

Ви можете додати анотацію sidecar.istio.io/rewriteAppHTTPProbers: "false" до podʼа, щоб вимкнути опцію переписування перевірок. Переконайтеся, що ви додали анотацію до ресурсу pod, оскільки вона буде ігноруватися в будь-якому іншому місці (наприклад, на ресурсі deployment, який містить pod).

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: liveness-http
spec:
  selector:
    matchLabels:
      app: liveness-http
      version: v1
  template:
    metadata:
      labels:
        app: liveness-http
        version: v1
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "false"
    spec:
      containers:
      - name: liveness-http
        image: docker.io/istio/health:example
        ports:
        - containerPort: 8001
        livenessProbe:
          httpGet:
            path: /foo
            port: 8001
          initialDelaySeconds: 5
          periodSeconds: 5
EOF

Цей підхід дозволяє вам поступово вимикати переписування перевірок справності на окремих deployments, без перевстановлення Istio.

Вимкнення переписування перевірок глобально

Встановіть Istio з параметром --set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=false, щоб вимкнути переписування перевірок глобально. Альтернативно, оновіть config map для інжектора sidecar Istio:

$ kubectl get cm istio-sidecar-injector -n istio-system -o yaml | sed -e 's/"rewriteAppHTTPProbe": true/"rewriteAppHTTPProbe": false/' | kubectl apply -f -

Очищення

Видаліть простори імен, використані для прикладів:

$ kubectl delete ns istio-io-health istio-io-health-rewrite
Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!