пытаюсь проникнуть в istio на kubernetes, но мне кажется, что мне не хватает каких-то основ, или я делаю вещи задом наперед. Я достаточно опытен в kubernetes, но istio и его виртуальный сервис меня немного смущают.
Я создал 2 развертывания (helloworld-v1 / helloworld-v2). Оба имеют одно и то же изображение, единственное, что отличается, - это переменные окружения, которые выводят либо версию: «v1», либо версию: «v2». Я использую небольшой тестконтейнер, который я написал, который в основном возвращает заголовки, которые я получил в приложение. Служба kubernetes с именем "helloworld" может достигать обоих.
Я создал Виртуальный сервис и Правило назначения
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld
spec:
hosts:
- helloworld
http:
- route:
- destination:
host: helloworld
subset: v1
weight: 90
- destination:
host: helloworld
subset: v2
weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: helloworld
spec:
host: helloworld
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Согласно документам, не упоминающим ни один шлюз, следует использовать внутренний "меш".
Контейнеры с коляской успешно прикреплены:
kubectl -n demo get all
NAME READY STATUS RESTARTS AGE
pod/curl-6657486bc6-w9x7d 2/2 Running 0 3h
pod/helloworld-v1-d4dbb89bd-mjw64 2/2 Running 0 6h
pod/helloworld-v2-6c86dfd5b6-ggkfk 2/2 Running 0 6h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/helloworld ClusterIP 10.43.184.153 <none> 80/TCP 6h
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/curl 1 1 1 1 3h
deployment.apps/helloworld-v1 1 1 1 1 6h
deployment.apps/helloworld-v2 1 1 1 1 6h
NAME DESIRED CURRENT READY AGE
replicaset.apps/curl-6657486bc6 1 1 1 3h
replicaset.apps/helloworld-v1-d4dbb89bd 1 1 1 6h
replicaset.apps/helloworld-v2-6c86dfd5b6 1 1 1 6h
Все работает довольно хорошо, когда я получаю доступ к приложению "извне" (istio-ingressgateway), v2 вызывается один раз, v1 9 девять раз:
curl --silent -H 'host: helloworld' http://localhost
{"host":"helloworld","user-agent":"curl/7.47.0","accept":"*/*","x-forwarded-for":"10.42.0.0","x-forwarded-proto":"http","x-envoy-internal":"true","x-request-id":"a6a2d903-360f-91a0-b96e-6458d9b00c28","x-envoy-decorator-operation":"helloworld:80/*","x-b3-traceid":"e36ef1ba2229177e","x-b3-spanid":"e36ef1ba2229177e","x-b3-sampled":"1","x-istio-attributes":"Cj0KF2Rlc3RpbmF0aW9uLnNlcnZpY2UudWlkEiISIGlzdGlvOi8vZGVtby9zZXJ2aWNlcy9oZWxsb3dvcmxkCj8KGGRlc3RpbmF0aW9uLnNlcnZpY2UuaG9zdBIjEiFoZWxsb3dvcmxkLmRlbW8uc3ZjLmNsdXN0ZXIubG9jYWwKJwodZGVzdGluYXRpb24uc2VydmljZS5uYW1lc3BhY2USBhIEZGVtbwooChhkZXN0aW5hdGlvbi5zZXJ2aWNlLm5hbWUSDBIKaGVsbG93b3JsZAo6ChNkZXN0aW5hdGlvbi5zZXJ2aWNlEiMSIWhlbGxvd29ybGQuZGVtby5zdmMuY2x1c3Rlci5sb2NhbApPCgpzb3VyY2UudWlkEkESP2t1YmVybmV0ZXM6Ly9pc3Rpby1pbmdyZXNzZ2F0ZXdheS01Y2NiODc3NmRjLXRyeDhsLmlzdGlvLXN5c3RlbQ==","content-length":"0","version":"v1"}
"version": "v1",
"version": "v1",
"version": "v2",
"version": "v1",
"version": "v1",
"version": "v1",
"version": "v1",
"version": "v1",
"version": "v1",
Но как только я делаю скручивание изнутри стручка (в данном случае просто byrnedo / alpine-curl) против сервиса, вещи начинают сбиваться с толку:
curl --silent -H 'host: helloworld' http://helloworld.demo.svc.cluster.local
{"host":"helloworld","user-agent":"curl/7.61.0","accept":"*/*","version":"v1"}
"version":"v2"
"version":"v2"
"version":"v1"
"version":"v1"
"version":"v2"
"version":"v2"
"version":"v1"
"version":"v2“
"version":"v1"
Мало того, что мне не хватает всех атрибутов istio (которые я понимаю в связи между сервисами и сервисами, потому что, насколько я понимаю, они устанавливаются, когда запрос впервые входит в сетку через шлюз), но баланс для меня выглядит как значение по умолчанию 50:50 баланс услуги кубернетес.
Что мне нужно сделать, чтобы достичь такого же баланса 1: 9 при межсервисной связи? Должен ли я создать второй, «внутренний» шлюз, чтобы использовать вместо него службу fqdn? Я пропустил определение? Должен ли вызов службы fqdn из модуля относиться к маршрутизации виртуальной службы?
используемая версия istio - 1.0.1, используемая версия kubernetes v1.11.1.
UPDATE
развернул спальный модуль, как было предложено (на этот раз не полагаясь на автоинжекцию демонстрационного пространства имен), но вручную, как описано в образце сна
kubectl -n demo get deployment sleep -o wide
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
sleep 1 1 1 1 2m
sleep,istio-proxy tutum/curl,docker.io/istio/proxyv2:1.0.1 app=sleep
Также изменил Virtualservice на 0/100, чтобы увидеть, работает ли он на первый взгляд. К сожалению, это не сильно изменилось:
export SLEEP_POD=$(kubectl get -n demo pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl -n demo exec -it $SLEEP_POD -c sleep curl http://helloworld
{"user- agent":"curl/7.35.0","host":"helloworld","accept":"*/*","version":"v2"}
kubectl -n demo exec -it $SLEEP_POD -c sleep curl http://helloworld
{"user-agent":"curl/7.35.0","host":"helloworld","accept":"*/*","version":"v1"}
kubectl -n demo exec -it $SLEEP_POD -c sleep curl http://helloworld
{"user-agent":"curl/7.35.0","host":"helloworld","accept":"*/*","version":"v2"}
kubectl -n demo exec -it $SLEEP_POD -c sleep curl http://helloworld
{"user-agent":"curl/7.35.0","host":"helloworld","accept":"*/*","version":"v1"}
kubectl -n demo exec -it $SLEEP_POD -c sleep curl http://helloworld
{"user-agent":"curl/7.35.0","host":"helloworld","accept":"*/*","version":"v2"