Перемикання трафіку TCP
Це завдання показує, як перенести TCP-трафік з одної версії мікросервісу на іншу.
Поширений випадок використання — це поступове перенесення TCP трафіку зі старої версії мікросервісу на нову. В Istio ви досягаєте цієї мети, конфігуруючи послідовність правил маршрутизації, які перенаправляють відсоток TCP трафіку з одного призначення на інше.
У цьому завданні ви направите 100% TCP трафіку до tcp-echo:v1
. Потім ви направите 20% TCP трафіку до tcp-echo:v2
, використовуючи функцію маршрутизації за коефіцієнтами в Istio.
Перш ніж почати
Налаштуйте Istio, дотримуючись інструкцій у керівництві з встановлення.
Ознайомтеся з документацією Управління трафіком.
Налаштування тестового середовища
Щоб почати, створіть простір імен для тестування перемикання TCP трафіку.
$ kubectl create namespace istio-io-tcp-traffic-shifting
Розгорніть демонстраційний застосунок curl, який буде використовуватися як джерело тестових запитів.
$ kubectl apply -f @samples/curl/curl.yaml@ -n istio-io-tcp-traffic-shifting
Розгорніть версії
v1
іv2
мікросервісуtcp-echo
.$ kubectl apply -f @samples/tcp-echo/tcp-echo-services.yaml@ -n istio-io-tcp-traffic-shifting
Застосування маршрутизації TCP на основі коефіцієнтів
- Направте весь TCP трафік до версії
v1
мікросервісуtcp-echo
.
$ kubectl apply -f @samples/tcp-echo/tcp-echo-all-v1.yaml@ -n istio-io-tcp-traffic-shifting
$ kubectl apply -f @samples/tcp-echo/gateway-api/tcp-echo-all-v1.yaml@ -n istio-io-tcp-traffic-shifting
- Визначте ingress IP та port:
TCP_INGRESS_PORT
та INGRESS_HOST
.Використовуйте наступні команди для встановлення змінних оточення SECURE_INGRESS_PORT
та INGRESS_HOST
:
$ kubectl wait --for=condition=programmed gtw tcp-echo-gateway -n istio-io-tcp-traffic-shifting
$ export INGRESS_HOST=$(kubectl get gtw tcp-echo-gateway -n istio-io-tcp-traffic-shifting -o jsonpath='{.status.addresses[0].value}')
$ export TCP_INGRESS_PORT=$(kubectl get gtw tcp-echo-gateway -n istio-io-tcp-traffic-shifting -o jsonpath='{.spec.listeners[?(@.name=="tcp-31400")].port}')
Переконайтеся, що служба
tcp-echo
працює, надіславши до неї деякий TCP-трафік.$ export CURL=$(kubectl get pod -l app=curl -n istio-io-tcp-traffic-shifting -o jsonpath={.items..metadata.name}) $ for i in {1..20}; do \ kubectl exec "$CURL" -c curl -n istio-io-tcp-traffic-shifting -- sh -c "(date; curl 1) | nc $INGRESS_HOST $TCP_INGRESS_PORT"; \ done one Mon Nov 12 23:24:57 UTC 2022 one Mon Nov 12 23:25:00 UTC 2022 one Mon Nov 12 23:25:02 UTC 2022 one Mon Nov 12 23:25:05 UTC 2022 one Mon Nov 12 23:25:07 UTC 2022 one Mon Nov 12 23:25:10 UTC 2022 one Mon Nov 12 23:25:12 UTC 2022 one Mon Nov 12 23:25:15 UTC 2022 one Mon Nov 12 23:25:17 UTC 2022 one Mon Nov 12 23:25:19 UTC 2022 ...
Зверніть увагу, що всі мітки часу мають префікс one, що означає, що весь трафік було перенаправлено на
v1
версію сервісуtcp-echo
.Передайте 20% трафіку з
tcp-echo:v1
наtcp-echo:v2
за допомогою наступної команди:
$ kubectl apply -f @samples/tcp-echo/tcp-echo-20-v2.yaml@ -n istio-io-tcp-traffic-shifting
$ kubectl apply -f @samples/tcp-echo/gateway-api/tcp-echo-20-v2.yaml@ -n istio-io-tcp-traffic-shifting
- Зачекайте кілька секунд, поки нові правила поширяться, а потім підтвердіть, що правило було замінено:
$ kubectl get virtualservice tcp-echo -o yaml -n istio-io-tcp-traffic-shifting
apiVersion: networking.istio.io/v1
kind: VirtualService
...
spec:
...
tcp:
- match:
- port: 31400
route:
- destination:
host: tcp-echo
port:
number: 9000
subset: v1
weight: 80
- destination:
host: tcp-echo
port:
number: 9000
subset: v2
weight: 20
$ kubectl get tcproute tcp-echo -o yaml -n istio-io-tcp-traffic-shifting
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
...
spec:
parentRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: tcp-echo-gateway
sectionName: tcp-31400
rules:
- backendRefs:
- group: ""
kind: Service
name: tcp-echo-v1
port: 9000
weight: 80
- group: ""
kind: Service
name: tcp-echo-v2
port: 9000
weight: 20
...
Надішліть ще трохи TCP-трафіку до мікросервісу
tcp-echo
.$ export CURL=$(kubectl get pod -l app=curl -n istio-io-tcp-traffic-shifting -o jsonpath={.items..metadata.name}) $ for i in {1..20}; do \ kubectl exec "$CURL" -c curl -n istio-io-tcp-traffic-shifting -- sh -c "(date; curl 1) | nc $INGRESS_HOST $TCP_INGRESS_PORT"; \ done one Mon Nov 12 23:38:45 UTC 2022 two Mon Nov 12 23:38:47 UTC 2022 one Mon Nov 12 23:38:50 UTC 2022 one Mon Nov 12 23:38:52 UTC 2022 one Mon Nov 12 23:38:55 UTC 2022 two Mon Nov 12 23:38:57 UTC 2022 one Mon Nov 12 23:39:00 UTC 2022 one Mon Nov 12 23:39:02 UTC 2022 one Mon Nov 12 23:39:05 UTC 2022 one Mon Nov 12 23:39:07 UTC 2022 ...
Тепер ви повинні помітити, що близько 20% міток часу мають префікс two, що означає, що 80% TCP-трафіку було перенаправлено на
v1
версію службиtcp-echo
, а 20% — наv2
.
Розуміння того, що відбулося
У цьому завданні ви частково мігрували TCP трафік зі старої версії на нову версію
сервісу tcp-echo
, використовуючи функцію маршрутизації за коефіцієнтами Istio. Зверніть увагу, що це дуже відрізняється від міграції версій за допомогою функцій розгортання платформ оркестрування контейнерів, які використовують масштабування екземплярів для управління трафіком.
За допомогою Istio ви можете дозволити двом версіям сервісу tcp-echo
масштабуватися вгору і вниз незалежно одна від одної, не впливаючи на розподіл трафіку між ними.
Для отримання додаткової інформації про маршрутизацію версій з автомасштабуванням, ознайомтеся зі статтею в блозі Canary Deployment з використанням Istio.
Очищення
- Видаліть правила маршрутизації:
$ kubectl delete -f @samples/tcp-echo/tcp-echo-all-v1.yaml@ -n istio-io-tcp-traffic-shifting
$ kubectl delete -f @samples/tcp-echo/gateway-api/tcp-echo-all-v1.yaml@ -n istio-io-tcp-traffic-shifting
Видаліть демонстраційний застосунок
curl
, застосунокtcp-echo
і тестовий простір імен:$ kubectl delete -f @samples/curl/curl.yaml@ -n istio-io-tcp-traffic-shifting $ kubectl delete -f @samples/tcp-echo/tcp-echo-services.yaml@ -n istio-io-tcp-traffic-shifting $ kubectl delete namespace istio-io-tcp-traffic-shifting