Общие сведения о сети GKE VPC-Native Cluster Pod
Давайте воспользуемся некоторыми инструментами linux и kubectl, чтобы нарисовать базовый поток связи модулей GKE.
Прежде чем создавать кластер GKE, вам необходимо создать подсеть под данным VPC в облачной консоли Google.
Я дал диапазон подсети как 10.120.20.0/24 (основной диапазон), и этот основной диапазон будет назначен всем рабочим узлам, которые мы добавляем в кластер.
После создания кластера вы можете заметить, что в подсеть будут добавлены два вторичных диапазона IP-адресов.
Обычно эти вторичные диапазоны используются для модулей и сервисов.
В нашем кластере вторичный диапазон 10.12.0.0/14 будет использоваться для модулей и
Вторичный диапазон 10.204.0.0/20 будет использоваться для конечных точек служб.
Предположим, что есть кластер GKE с описанными выше деталями, и давайте разберемся со связью модуля.
у меня тоже есть администратор кластера привилегированный экземпляр, в котором я установил kubectl, и позволяет собрать некоторые детали, используя экземпляр
- Найдите узлы
kubectl получить узлы -o широкий | awk ‘{напечатать $1 «\t» $2 «\t» $6}’
Итак, у нас есть три узла
Node3 = gke-cluster-standard-clus-default-pool-0e999ebf-rs5w
Node2 = gke-cluster-standard-clus-default-pool-17b978bb-wpm6
Node1 = gke-cluster-standard-clus-default-pool-7cf8a05e-ksb0
Давайте создадим развертывание с репликацией 6. создадим следующий файл
развертывание.yaml
kubectl get po -o широкий | grep nginx-развертывание | awk ‘{print $1 «\t» $2 «\t» $3 «\t» $6 «\t» $7}’
Таким образом, каждый рабочий узел запускает два модуля внутри него.
Узел 1=nginx-развертывание-76bf4969df-vl6jk (Sub1), nginx-развертывание-76bf4969df-vzs4r (Под2)
Узел2=nginx-развертывание-76bf4969df-89qkh (Под3), nginx-развертывание-76bf4969df-fk2m6 (Sub4)
узел 3=nginx-развертывание-76bf4969df-2kpxz (Под5), nginx-развертывание-76bf4969df-95bxn (Под6)
Давайте рассмотрим модули, работающие под Узел 1. Итак, мы теперь знаем оба Sub1 а также Под2 имеют IP-адреса 10.12.2.57 и 10.12.2.56 по порядку.
Давайте подробно проверим сетевые интерфейсы этих модулей с помощью следующих команд.
kubectl exec -it nginx-deployment-76bf4969df-vl6jk IP
kubectl exec -it nginx-deployment-76bf4969df-vzs4r IP
eth0@if60 указывает на то, что Sub1 интерфейс Ethernet связан с виртуальным сетевым интерфейсом с номером строки 60 хоста Узел 1.
Сходным образом eth0@if59 указывает на то, что Под2 интерфейс Ethernet связан с виртуальным сетевым интерфейсом с номером строки 59 хоста Узел 1.
Отлично! Теперь отправляемся в терминал Узел 1 и выполните следующую команду, чтобы найти, к чему относятся эти номера строк 59 и 60.
IP а
Теперь очень ясно, что Sub1 а также Под2 интерфейсы Ethernet соединены с хост-узлом (Узел 1) виртуальный интерфейс Ethernet (Veth).
Также ниже команда покажет вам эти интерфейсы veth veth6758a8b4 а также veth3d227386 соединены с мостом cbr0 с IP-адресом 10.12.2.1/24.
brctl-шоу
Примечание: вы можете установить бридж-утилиты при необходимости проверить
На основе приведенных выше идентификаций диаграмма связи модуля Worker будет выглядеть следующим образом.
Подобным образом я могу нарисовать диаграмму для Узел2 как показано ниже
Вы знаете, что рабочие узлы кластера GKE являются экземплярами Compute Engine VPC, поэтому эти экземпляры автоматически взаимодействуют друг с другом, используя основную подсеть VPC.
Но если Sub1 из Узел 1 нужно общаться с Под3 из Узел2то в кластере должна быть включена маршрутизация.
Но при создании кластера GKE рекомендуется создать кластер с опцией ** Native VPC — IP Aliasing**.
Google говорит, что преимущество IP-псевдонимов в Native VPC
«IP-адреса Pod изначально маршрутизируются в сети GCP (в том числе через сетевой пиринг VPC) и больше не используют квоту маршрутизации».
Пожалуйста, обратитесь к эта ссылка
Pod Ranges используют то, что называется Псевдонимы IP-адресов которые изначально маршрутизируются. Это означает, что логика их маршрутизации встроена в сетевой уровень. И нет необходимости настраивать какие-то дополнительные маршруты. В режиме возможно масштабирование до 1000 узлов с помощью VPC Native.
Псевдонимы IP-адресов поддерживают VPC, а маршрутизация обеспечивается VPC.. При использовании IP-псевдонимов маршрутизация модулей выполняется самим VPC, и нет необходимости добавлять ручные маршруты для доступа к IP-адресам модулей. (Ссылаться на эта ссылка )
Попробуем пропинговать с Sub1 к Под3
kubectl exec -it nginx-deployment-76bf4969df-vl6jk ping 10.12.0.32
Следующая диаграмма иллюстрирует наш кластер
Итак, в моем следующем посте я объясню всю оверлейную сеть кластера Kubernetes, созданного с нуля.
