Встановлення 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.yaml@
$ 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
:
Ресурс | Мітка | Значення “Включено” | Значення “Вимкнено” |
---|---|---|---|
Namespace | istio-injection | enabled | disabled |
Pod | sidecar.istio.io/inject | "true" | "false" |
Якщо ви використовуєте ревізії панелі управління, замість цього використовуються мітки, специфічні для ревізії, за допомогою відповідної мітки istio.io/rev
. Наприклад, для ревізії з назвою canary
:
Ресурс | Мітка “Включено” | Мітка “Вимкнено” |
---|---|---|
Namespace | istio.io/rev=canary | istio-injection=disabled |
Pod | istio.io/rev=canary | sidecar.istio.io/inject="false" |
Якщо мітки istio-injection
та istio.io/rev
присутні одночасно на одному просторі імен, пріоритет матиме мітка istio-injection
.
Інжектор налаштований на виконання такої логіки:
- Якщо будь-яка з міток (
istio-injection
абоsidecar.istio.io/inject
) вимкнена, інʼєкція в pod не відбувається. - Якщо будь-яка з міток (
istio-injection
,sidecar.istio.io/inject
абоistio.io/rev
) включена, відбувається інʼєкція в pod. - Якщо жодна з міток не встановлена, відбувається інʼєкція в pod, якщо увімкнено
.values.sidecarInjectorWebhook.enableNamespacesByDefault
. Стандартно ця опція вимкнена, тому загалом це означає, що інʼєкція в pod не відбувається..
Ручна інʼєкція sidecar
Для ручної інʼєкції в deployment використовуйте команду istioctl kube-inject
:
$ istioctl kube-inject -f @samples/curl/curl.yaml@ | 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.yaml@ \
| 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.