Зрозумійте свою Mesh мережу за допомогою Istioctl Describe
В Istio 1.3 ми включили команду istioctl experimental describe
. Ця команда CLI надає інформацію, необхідну для розуміння конфігурації, що впливає на pod. Цей посібник показує, як використовувати цю експериментальну команду, щоб перевірити, чи є pod у mesh і перевірити його конфігурацію.
Основне використання команди виглядає наступним чином:
$ istioctl experimental describe pod <pod-name>[.<namespace>]
Додавання простору імен до імені podʼа має такий же ефект, як і використання опції -n
в istioctl
для вказівки не стандартного простору імен.
Цей посібник передбачає, що ви розгорнули демонстраційний застосунок Bookinfo у вашій mesh. Якщо ви цього ще не зробили, запустіть сервіси застосунку і визначте IP і порт ingress перед продовженням.
Перевірте, чи є pod у mesh
Команда istioctl describe
повертає попередження, якщо Envoy проксі не присутній у podʼі або якщо проксі не запущено. Крім того, команда попереджає, якщо деякі з вимог Istio для podʼів не виконані.
Наприклад, наступна команда видає попередження, що pod kube-dns
не є частиною сервісної мережі, оскільки він не має sidecar:
$ export KUBE_POD=$(kubectl -n kube-system get pod -l k8s-app=kube-dns -o jsonpath='{.items[0].metadata.name}')
$ istioctl x describe pod -n kube-system $KUBE_POD
Pod: coredns-f9fd979d6-2zsxk
Pod Ports: 53/UDP (coredns), 53 (coredns), 9153 (coredns)
WARNING: coredns-f9fd979d6-2zsxk is not part of mesh; no Istio sidecar
--------------------
2021-01-22T16:10:14.080091Z error klog an error occurred forwarding 42785 -> 15000: error forwarding port 15000 to pod 692362a4fe313005439a873a1019a62f52ecd02c3de9a0957cd0af8f947866e5, uid : failed to execute portforward in network namespace "/var/run/netns/cni-3c000d0a-fb1c-d9df-8af8-1403e6803c22": failed to dial 15000: dial tcp4 127.0.0.1:15000: connect: connection refused[]
Error: failed to execute command on sidecar: failure running port forward process: Get "http://localhost:42785/config_dump": EOF
Команда не видасть такого попередження для podʼа, який є частиною mesh, наприклад, для сервісу Bookinfo ratings
, але натомість виведе конфігурацію Istio, застосовану до podʼа:
$ export RATINGS_POD=$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')
$ istioctl experimental describe pod $RATINGS_POD
Pod: ratings-v1-7dc98c7588-8jsbw
Pod Ports: 9080 (ratings), 15090 (istio-proxy)
--------------------
Service: ratings
Port: http 9080/HTTP targets pod port 9080
Виведення показує наступну інформацію:
- Порти контейнера сервіса в podʼі,
9080
для контейнераratings
у цьому прикладі. - Порти контейнера
istio-proxy
в podʼі,15090
у цьому прикладі. - Протокол, що використовується службою в podʼі,
HTTP
через порт9080
у цьому прикладі.
Перевірте конфігурації правил призначення
Ви можете використовувати istioctl describe
, щоб побачити, які
правила призначення застосовуються до запитів до podʼа. Наприклад, застосуйте правила призначення для Bookinfo з взаємним TLS:
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
Тепер опишіть pod ratings
знову:
$ istioctl x describe pod $RATINGS_POD
Pod: ratings-v1-f745cf57b-qrxl2
Pod Ports: 9080 (ratings), 15090 (istio-proxy)
--------------------
Service: ratings
Port: http 9080/HTTP
DestinationRule: ratings for "ratings"
Matching subsets: v1
(Non-matching subsets v2,v2-mysql,v2-mysql-vm)
Traffic Policy TLS Mode: ISTIO_MUTUAL
Команда тепер показує додаткове виведення:
- Правило призначення
ratings
застосовується до запитів до сервісівratings
. - Підмножина правила призначення
ratings
, що відповідає podʼу,v1
у цьому прикладі. - Інші підмножини, визначені правилом призначення.
- Pod приймає або HTTP, або взаємні TLS запити, але клієнти використовують взаємний TLS.
Перевірте конфігурації віртуальних сервісів
Коли віртуальні сервіси конфігурують маршрути до podʼа, istioctl describe
також включатиме маршрути у своєму виведенні. Наприклад, застосуйте віртуальні сервіси Bookinfo, які маршрутизують всі запити до podʼів v1
:
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
Потім опишіть pod, що реалізує v1
сервіси reviews
:
$ export REVIEWS_V1_POD=$(kubectl get pod -l app=reviews,version=v1 -o jsonpath='{.items[0].metadata.name}')
$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
1 HTTP route(s)
Виведення містить подібну інформацію до тієї, що була показана раніше для podʼа ratings
, але також включає маршрути віртуального сервісу до podʼа.
Команда istioctl describe
не просто показує віртуальні сервіси, що впливають на pod. Якщо віртуальний сервіс конфігурує хост служби podʼа, але жоден трафік не досягає його, виведення команди міститиме попередження. Цей випадок може виникнути, якщо віртуальний сервіс
фактично блокує трафік, ніколи не маршрутизуючи трафік до підмножини podʼа. Наприклад:
$ export REVIEWS_V2_POD=$(kubectl get pod -l app=reviews,version=v2 -o jsonpath='{.items[0].metadata.name}')
$ istioctl x describe pod $REVIEWS_V2_POD
...
VirtualService: reviews
WARNING: No destinations match pod subsets (checked 1 HTTP routes)
Route to non-matching subset v1 for (everything)
Попередження включає причину проблеми, скільки маршрутів було перевірено, і навіть надає інформацію про інші маршрути, що існують. У цьому прикладі жоден трафік не досягає podʼа v2
, оскільки маршрут у віртуальному сервісі спрямовує весь трафік до підмножини v1
.
Якщо ви зараз видалите правила призначення Bookinfo:
$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
Ви зможете побачити ще одну корисну функцію istioctl describe
:
$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
WARNING: No destinations match pod subsets (checked 1 HTTP routes)
Warning: Route to subset v1 but NO DESTINATION RULE defining subsets!
Виведення показує, що ви видалили правило призначення, але не віртуальний сервіс, що залежить від нього. Віртуальний сервіс маршрутизує трафік до підмножини v1
, але немає правила призначення, що визначає підмножину v1
. Таким чином, трафік, призначений для версії v1
, не може дійти до podʼа.
Якщо ви оновите оглядач, щоб надіслати новий запит до Bookinfo в цей момент, ви побачите таке повідомлення: Error fetching product reviews
. Щоб виправити проблему, знову застосуйте правило призначення:
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
Оновлення оглядача показує, що застосунок знову працює, і виконання istioctl experimental describe pod $REVIEWS_V1_POD
більше не видає попереджень.
Перевірка маршрутів трафіку
Команда istioctl describe
також показує ваги розподілу трафіку. Наприклад, виконайте наступну команду, щоб маршрутизувати 90% трафіку до підмножини v1
і 10% до підмножини v2
сервісу reviews
:
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-90-10.yaml@
Тепер опишіть pod reviews v1
:
$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
Weight 90%
Виведення показує, що віртуальний сервіс reviews
має вагу 90% для
підмножини v1
.
Ця функція також корисна для інших типів маршрутизації. Наприклад, ви можете розгорнути маршрутизацію на основі заголовків:
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@
Потім опишіть pod знову:
$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
WARNING: No destinations match pod subsets (checked 2 HTTP routes)
Route to non-matching subset v2 for (when headers are end-user=jason)
Route to non-matching subset v3 for (everything)
Виведення видає попередження, оскільки ви описуєте pod у підмножині v1
. Однак конфігурація віртуального сервісу, яку ви застосували, маршрутизує трафік до підмножини v2
, якщо заголовок містить end-user=jason
, і до підмножини v3
у всіх інших випадках.
Перевірка строгого взаємного TLS
Слідуйте інструкціям міграції взаємного TLS, щоб увімкнути строгий взаємний TLS для сервісу ratings
:
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: ratings-strict
spec:
selector:
matchLabels:
app: ratings
mtls:
mode: STRICT
EOF
Виконайте наступну команду, щоб описати pod ratings
:
$ istioctl x describe pod $RATINGS_POD
Pilot reports that pod enforces mTLS and clients speak mTLS
У виводі повідомляється, що запити до пакета ratings
тепер зафіксовано і захищено.
Однак іноді розгортання може зламатися при переході на строгий взаємний TLS. Ймовірною причиною є те, що правило призначення не відповідало новій конфігурації. Наприклад, якщо ви конфігуруєте клієнтів Bookinfo, щоб не використовувати взаємний TLS, використовуючи прості правила призначення HTTP:
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
Якщо ви відкриєте Bookinfo в оглядачі, ви побачите повідомлення Ratings service is currently unavailable
. Щоб дізнатися чому, виконайте наступну команду:
$ istioctl x describe pod $RATINGS_POD
...
WARNING Pilot predicts TLS Conflict on ratings-v1-f745cf57b-qrxl2 port 9080 (pod enforces mTLS, clients speak HTTP)
Check DestinationRule ratings/default and AuthenticationPolicy ratings-strict/default
Виведення містить попередження, яке описує конфлікт між правилом призначення та політикою автентифікації.
Ви можете відновити правильну роботу, застосувавши правило призначення, яке використовує взаємний TLS:
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
Висновок та очищення
Наша мета з командою istioctl x describe
— допомогти вам зрозуміти конфігурації трафіку та безпеки у вашій Mesh Istio.
Ми будемо раді почути ваші ідеї щодо покращення! Приєднуйтесь до нас на https://discuss.istio.io.
Щоб видалити podʼи та конфігурації Bookinfo, використані в цьому посібнику, виконайте наступні команди:
$ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo.yaml@
$ kubectl delete -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@