Встановлення Sidecar

Виконання інʼєкції

Для того, щоб скористатися всіма можливостями Istio, podʼи в mesh повинні мати sidecar проксі Istio.

У наступних розділах описані два способи впровадження sidecar проксі Istio в pod: увімкнення автоматичної інʼєкції sidecar проксі Istio у просторі імен podʼа або вручну за допомогою команди istioctl⁵.

Коли автоматична інʼєкція увімкнена у просторі імен podʼа, конфігурація проксі додається під час створення podʼа з використанням контролера допуску.

Вручну конфігурація проксі додається безпосередньо до конфігурації, наприклад, до deployment.

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

Автоматична інʼєкція sidecar проксі

Sidecar проксі можна автоматично додавати до відповідних podʼів Kubernetes за допомогою контролера допуску з модифікацією вебхука⁶, який надається Istio.

Коли ви встановлюєте мітку istio-injection=enabled в простір імен і вебхук для інʼєкції увімкнено, будь-які нові podʼи, створені в цьому просторі імен, автоматично матимуть доданий sidecar.

Зверніть увагу, що на відміну від ручної інʼєкції, автоматична інʼєкція відбувається на рівні podʼа. Ви не побачите жодних змін у самому розгортанні. Замість цього, вам потрібно буде перевірити окремі podʼи (за допомогою kubectl describe), щоб побачити доданий проксі.

Розгортання застосунку

Розгорніть застосунок curl. Переконайтесь, що як deployment, так і pod мають один контейнер.

$ kubectl apply -f samples/curl/curl.yaml7
$ kubectl get deployment -o wide
NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                    SELECTOR
curl    1/1     1            1           12s   curl         curlimages/curl           app=curl

$ kubectl get pod
NAME                    READY   STATUS    RESTARTS   AGE
curl-8f795f47d-hdcgs    1/1     Running   0          42s

Позначте простір імен default міткою istio-injection=enabled.

$ kubectl label namespace default istio-injection=enabled --overwrite
$ kubectl get namespace -L istio-injection
NAME                 STATUS   AGE     ISTIO-INJECTION
default              Active   5m9s    enabled
...

Інʼєкція відбувається під час створення podʼа. Вбийте запущений pod і переконайтесь, що новий pod створено з впровадженим sidecar проксі. Початковий pod має 1/1 READY, а контейнер з доданим sidecar проксі має 2/2 READY.

$ kubectl delete pod -l app=curl
$ kubectl get pod -l app=curl
pod "curl-776b7bcdcd-7hpnk" deleted
NAME                     READY     STATUS        RESTARTS   AGE
curl-776b7bcdcd-7hpnk    1/1       Terminating   0          1m
curl-776b7bcdcd-bhn9m    2/2       Running       0          7s

Перегляньте детальний стан podʼа з інʼєкцією. Ви повинні побачити доданий контейнер istio-proxy та відповідні томи.

$ kubectl describe pod -l app=curl
...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  ...
  Normal  Created    11s   kubelet            Created container istio-init
  Normal  Started    11s   kubelet            Started container istio-init
  ...
  Normal  Created    10s   kubelet            Created container curl
  Normal  Started    10s   kubelet            Started container curl
  ...
  Normal  Created    9s    kubelet            Created container istio-proxy
  Normal  Started    8s    kubelet            Started container istio-proxy

Вимкніть інʼєкцію для простору імен default і переконайтесь, що нові podʼи створюються без sidecar проксі.

$ kubectl label namespace default istio-injection-
$ kubectl delete pod -l app=curl
$ kubectl get pod
namespace/default labeled
pod "curl-776b7bcdcd-bhn9m" deleted
NAME                     READY     STATUS        RESTARTS   AGE
curl-776b7bcdcd-bhn9m    2/2       Terminating   0          2m
curl-776b7bcdcd-gmvnr    1/1       Running       0          2s

Контроль політики інʼєкції

У наведених вище прикладах ви включали та відключали інʼєкцію на рівні простору імен. Інʼєкцію також можна контролювати на рівні кожного окремого podʼа, налаштовуючи мітку sidecar.istio.io/inject:

Якщо ви використовуєте ревізії панелі управління⁸, замість цього використовуються мітки, специфічні для ревізії, за допомогою відповідної мітки istio.io/rev. Наприклад, для ревізії з назвою canary:

Якщо мітки istio-injection та istio.io/rev присутні одночасно на одному просторі імен, пріоритет матиме мітка istio-injection.

Інжектор налаштований на виконання такої логіки:

1. Якщо будь-яка з міток (istio-injection або sidecar.istio.io/inject) вимкнена, інʼєкція в pod не відбувається.
2. Якщо будь-яка з міток (istio-injection, sidecar.istio.io/inject або istio.io/rev) включена, відбувається інʼєкція в pod.
3. Якщо жодна з міток не встановлена, відбувається інʼєкція в pod, якщо увімкнено .values.sidecarInjectorWebhook.enableNamespacesByDefault. Стандартно ця опція вимкнена, тому загалом це означає, що інʼєкція в pod не відбувається..

Ручна інʼєкція sidecar

Для ручної інʼєкції в deployment використовуйте команду istioctl kube-inject:

$ istioctl kube-inject -f samples/curl/curl.yaml7 | kubectl apply -f -
serviceaccount/curl created
service/curl created
deployment.apps/curl created

Стандартно буде використовуватися конфігурація в кластері. Альтернативно інʼєкція може бути виконана з використанням локальних копій конфігурації.

$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.values}' > inject-values.yaml
$ kubectl -n istio-system get configmap istio -o=jsonpath='{.data.mesh}' > mesh-config.yaml

Запустіть kube-inject для вхідного файлу та розгорніть.

$ istioctl kube-inject \
    --injectConfigFile inject-config.yaml \
    --meshConfigFile mesh-config.yaml \
    --valuesFile inject-values.yaml \
    --filename samples/curl/curl.yaml7 \
    | kubectl apply -f -
serviceaccount/curl created
service/curl created
deployment.apps/curl created

Перевірте, що sidecar було додано в pod curl зі значенням 2/2 у колонці READY.

$ kubectl get pod -l app=curl
NAME                     READY   STATUS    RESTARTS   AGE
curl-64c6f57bc8-f5n4x    2/2     Running   0          24s

Налаштування інʼєкції

Загалом інʼєкція podʼів відбувається на основі шаблону інʼєкції sidecar, налаштованого в configmap istio-sidecar-injector. Налаштування окремих podʼів доступне для перевизначення цих опцій на індивідуальних podʼах. Це робиться шляхом додавання контейнера istio-proxy до вашого podʼу. Інʼєкція sidecar розглядатиме будь-яку конфігурацію, визначену тут, як перевизначення стандартного шаблону інʼєкції.

Слід бути обережним при налаштуванні цих параметрів, оскільки це дозволяє повністю налаштувати отриманий Pod, включаючи внесення змін, які можуть спричинити некоректну роботу контейнера sidecar.

Наприклад, наступна конфігурація налаштовує різні параметри, зокрема знижує запити на ЦП, додає монтування тому і додає хук preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "100m"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["curl", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

Загалом можна налаштувати будь-яке поле в podʼі. Однак потрібно бути обережним з певними полями:

• Kubernetes вимагає, щоб поле image було встановлено до запуску інʼєкції. Хоча ви можете встановити конкретний образ для перевизначення стандартного, рекомендується встановити image на auto, що дозволить інжектору sidecar автоматично вибирати образ для використання.
• Деякі поля в Pod залежать від повʼязаних налаштувань. Наприклад, запит на ЦП має бути меншим за обмеження ЦП. Якщо обидва поля не налаштовані разом, pod може не запуститися.
• Поля securityContext.RunAsUser і securityContext.RunAsGroup можуть не бути прийняті в деяких випадках, наприклад, коли використовується режим TPROXY, оскільки він вимагає запуску sidecar від імені користувача 0. Неправильне перевизначення цих полів може призвести до втрати трафіку, і повинно виконуватися з особливою обережністю.

Крім того, деякі поля налаштовуються за допомогою анотацій⁹ на podʼі, хоча рекомендується використовувати наведений вище підхід до налаштування параметрів. Додатково потрібно бути обережним з деякими анотаціями:

• Якщо встановлено sidecar.istio.io/proxyCPU, обовʼязково встановіть sidecar.istio.io/proxyCPULimit. Інакше обмеження на cpu для sidecar буде встановлено як необмежене.
• Якщо встановлено sidecar.istio.io/proxyMemory, обовʼязково встановіть sidecar.istio.io/proxyMemoryLimit. Інакше обмеження на memory для sidecar буде встановлено як необмежене.

Наприклад, дивіться наведену нижче конфігурацію неповних анотацій ресурсів і відповідні налаштування введених ресурсів:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyMemoryLimit: "5Gi"

spec:
  containers:
  - name: istio-proxy
    resources:
      limits:
        memory: 5Gi
      requests:
        cpu: 200m
        memory: 5Gi
      securityContext:
        allowPrivilegeEscalation: false

Власні шаблони (експериментально)

Повністю власні шаблони також можна визначити під час встановлення. Наприклад, щоб визначити власний шаблон, який інжектує змінну середовища GREETING у контейнер istio-proxy:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio
spec:
  values:
    sidecarInjectorWebhook:
      templates:
        custom: |
          spec:
            containers:
            - name: istio-proxy
              env:
              - name: GREETING
                value: hello-world

Podʼи стандартно використовуватимуть шаблон інʼєкції sidecar, який створюється автоматично. Це можна перевизначити за допомогою анотації inject.istio.io/templates. Наприклад, щоб застосувати стандартний шаблон і наше налаштування, можна встановити inject.istio.io/templates=sidecar,custom.

Крім шаблона sidecar, стандартно надається шаблон gateway для підтримки інʼєкції проксі у розгортання Gateway.