В предыдущем блоге на , у вас должно быть понимание Kubernetes. В этом блоге о сетях Kubernetes я в первую очередь сосредоточусь на сетевых концепциях, используемых в Kubernetes.
В этом блоге о сети Kubernetes вы разберетесь в следующих темах:
Что такое Kubernetes?
Вы можете определить Kubernetes как инструмент оркестрации контейнеров с открытым исходным кодом, который предоставляет переносимую платформу для автоматизации развертывания контейнерных приложений.
Теперь любой, кто работает с Kubernetes, должен иметь четкое представление о Kubernetes Cluster, так как это поможет вам в понимании сети Kubernetes.
Кластер Kubernetes
Платформа Kubernetes предлагает управление желаемым состоянием, которое позволяет запускать кластерные службы, а также загружать конфигурацию в инфраструктуру. Разрешите пояснить на примере.
Рассмотрим файл YAML, содержащий всю информацию о конфигурации, которую необходимо передать в службы кластера. Итак, этот файл передается в API служб кластера, а затем службы кластера должны выяснить, как планировать поды в среде. Итак, предположим, что есть два образа контейнера для модуля 1 с тремя репликами и один образ контейнера для модуля 2 с двумя репликами. Распределение этих пар «модуль-реплика» рабочим будет зависеть от служб кластера.
Рубин на рельсах рынок труда
См. Диаграмму выше. Теперь, как вы можете видеть, службы кластера выделили первому рабочему объекту две пары реплик модуля, второму рабочему элементу - одну пару реплик модуля, а третьему рабочему элементу - две пары реплик модуля. Теперь именно процесс Kubelet отвечает за взаимодействие служб кластера с рабочими.
Итак, вся эта настройка кластерных сервисов и сами рабочие составляют это Кластер Kubernetes !!
Как вы думаете, как эти индивидуально выделенные поды общаются друг с другом?
Ответ кроется в сети Kubernetes!
Подпишитесь на наш канал на YouTube, чтобы получать новости ..!
В основном необходимо решить 4 проблемы с сетевыми концепциями.
- Связь между контейнером
- От модуля к модулю Связь
- Под для служебной связи
- Внешняя связь с сервисом
Теперь позвольте мне рассказать вам, как вышеупомянутые проблемы решаются с помощью Kubernetes Networking.
Сеть Kubernetes
Связь между модулями, сервисами и внешними сервисами в кластере привносит понятие сети Kubernetes.
Итак, для вашего лучшего понимания позвольте мне разделить концепции на следующие.
- Модули и контейнерные коммуникации
- Сервисы
- Подключение внешнего к службам через входящую сеть
Модули и контейнерные коммуникации
Прежде чем я расскажу, как взаимодействуют стручки, позвольте мне представить вам, что такое стручки?
Стручки
Поды - это базовые единицы приложений Kubernetes, которые состоят из одного или нескольких контейнеров, размещенных на одном хосте для совместного использования сетевого стека и других ресурсов. Таким образом, это означает, что все контейнеры в модуле могут подключаться к другим контейнерам на локальном хосте.
Теперь позвольте мне рассказать вам, как эти стручки взаимодействуют между собой?
Есть 2 типа общения. В межузловая связь и внутриузловая связь.
Итак, давайте начнем с внутриузловой связи, но перед этим позвольте мне представить вам компоненты сети модулей.
Внутриузловой под сетью
Внутриузловая сеть контейнеров - это, по сути, связь между двумя разными узлами в одном контейнере. Позвольте мне объяснить вам на примере.
Предположим, пакет идет от модуля 1 к модулю 2.
- Пакет покидает сеть Pod 1 на eth0 и попадает в корневую сеть на veth0.
- Затем пакет переходит на мост Linux (cbr0), который обнаруживает пункт назначения с помощью запроса ARP.
- Итак, если у veth1 есть IP-адрес, мост теперь знает, куда пересылать пакет.
Теперь аналогичным образом позвольте мне рассказать вам о межузловом взаимодействии модулей.
Заинтересованы в изучении Kubernetes?Межузловой в сети
Рассмотрим два узла с различными сетевыми пространствами имен, сетевыми интерфейсами и мостом Linux.
Теперь предположим, что пакет перемещается от pod1 к pod4, который находится на другом узле.
- Пакет покидает сеть pod 1 и попадает в корневую сеть на veth0.
- Затем пакет переходит к мосту Linux (cbr0), который отвечает за отправку ARP-запроса для поиска пункта назначения.
- После того, как мост понимает, что этот модуль не имеет адреса назначения, пакет возвращается к основному сетевому интерфейсу eth0.
- Теперь пакет покидает узел 1, чтобы найти его место назначения на другом узле, и входит в таблицу маршрутизации, которая направляет пакет на узел, чей блок CIDR содержит pod4.
- Итак, теперь пакет достигает узла 2, а затем мост принимает пакет, который делает запрос ARP, чтобы узнать, что IP принадлежит veth0.
- Наконец, пакет пересекает пару каналов и достигает pod4.
Итак, вот как поды общаются друг с другом. Теперь давайте продолжим и посмотрим, как сервисы помогают в взаимодействии модулей.
Итак, что вы думаете об услугах?
Сервисы
По сути, сервисы - это тип ресурса, который настраивает прокси-сервер для пересылки запросов в набор модулей, которые будут получать трафик и определяются селектором. После создания службы ей назначается IP-адрес, который будет принимать запросы на порт.
Теперь существуют различные типы сервисов, которые дают вам возможность предоставлять сервис за пределами IP-адреса вашего кластера.
Виды услуг
В основном существует 4 вида услуг.
ClusterIP: Это тип службы по умолчанию, который предоставляет службу на внутреннем IP-адресе кластера, делая службу доступной только в пределах кластера.
NodePort: Это предоставляет услугу на IP-адресе каждого узла на статическом порту. Поскольку ClusterIP Сервис, к которому будет маршрутизироваться сервис NodePort, создается автоматически. Мы можем связаться с сервисом NodePort вне кластера.
LoadBalancer: Это тип сервиса, который предоставляет сервис извне с помощью балансировщика нагрузки облачного провайдера. Таким образом, автоматически создаются службы NodePort и ClusterIP, к которым будет выполнять маршрутизацию внешний балансировщик нагрузки.
ExternalName : Этот тип службы сопоставляет службу содержимому externalName поле, возвращая CNAME запись со своим значением.
Итак, ребята, это все об услугах. Теперь вам может быть интересно, как внешние службы правильно подключаются к этим сетям?
Ну, это никто иной, как Сеть Ingress .
Сеть Ingress
Что ж, сеть Ingress - это самый мощный способ раскрытия сервисов, поскольку это набор правил, разрешающих входящие соединения, которые можно настроить для предоставления сервисов извне через доступные URL-адреса. Таким образом, он в основном действует как точка входа в кластер Kubernetes, который управляет внешним доступом к службам в кластере.
Теперь позвольте мне объяснить вам работу Ingress Network на примере.
У нас есть 2 узла, имеющие пространство имен pod и root сети с мостом Linux. В дополнение к этому, у нас также есть новое виртуальное устройство Ethernet под названием flannel0 (сетевой плагин), добавленное в корневую сеть.
Теперь мы хотим, чтобы пакет перешел от модуля 1 к модулю 4.
- Итак, пакет покидает сеть pod1 на eth0 и попадает в корневую сеть на veth0.
- Затем он передается на cbr0, который делает запрос ARP для поиска пункта назначения, после чего обнаруживает, что ни у кого на этом узле нет IP-адреса назначения.
- Итак, мост отправляет пакет на flannel0, так как таблица маршрутов узла настроена с помощью flannel0.
- Теперь демон flannel обращается к API-серверу Kubernetes, чтобы узнать все IP-адреса модулей и их соответствующие узлы, чтобы создать сопоставления IP-адресов модулей с IP-адресами узлов.
- Сетевой плагин оборачивает этот пакет в UDP-пакет с дополнительными заголовками, меняя IP-адреса источника и назначения на соответствующие узлы, и отправляет этот пакет через eth0.
- Теперь, поскольку таблица маршрутов уже знает, как маршрутизировать трафик между узлами, она отправляет пакет на узел назначения2.
- Пакет прибывает в eth0 узла 2 и возвращается на flannel0 для декапсуляции и отправляет его обратно в пространство имен корневой сети.
- Опять же, пакет пересылается на мост Linux, чтобы сделать запрос ARP для определения IP, принадлежащего veth1.
- Наконец, пакет пересекает корневую сеть и достигает Pod4 назначения.
Итак, вот как внешние сервисы подключаются с помощью входящей сети. Теперь, когда я говорил о сетевых плагинах, позвольте мне представить вам список популярных доступных сетевых плагинов.
Теперь, когда я так много рассказал вам о сети Kubernetes, позвольте мне показать вам пример из реальной жизни.
Пример использования: Wealth Wizard с использованием сети Kubernetes
Wealth Wizards - это онлайн-платформа финансового планирования, которая сочетает в себе финансовое планирование и интеллектуальные программные технологии для предоставления экспертных консультаций по доступной цене.
Вызовы
Теперь для компании было чрезвычайно важно быстро обнаружить и устранить уязвимости кода с полной видимостью своей облачной среды, но она хотела контролировать трафик с помощью ограничений доступа.
Таким образом, они использовали инфраструктуру Kubernetes для управления подготовкой и развертыванием кластеров с помощью инструментов для управления развертыванием и настройкой микросервисов в кластерах Kube.
Они также использовали функцию сетевой политики Kubernetes, чтобы позволить им контролировать трафик с помощью ограничений доступа.
Проблема заключалась в том, что эти политики ориентированы на приложения и могут развиваться только вместе с приложениями, но не было компонента, обеспечивающего соблюдение этих политик.
Таким образом, единственным решением, которое компания смогла найти для этого, было использование сетевого плагина, и поэтому они начали использовать Weave Net.
Решение
Этот сетевой плагин создает виртуальную сеть с контроллером сетевой политики для управления и обеспечения соблюдения правил в Kubernetes. Не только это, он также связывает контейнеры Docker на нескольких хостах и обеспечивает их автоматическое обнаружение.
Итак, предположим, что у вас есть рабочая нагрузка в кластере, и вы хотите, чтобы любая другая рабочая нагрузка в кластере не взаимодействовала с ней. Вы можете добиться этого, создав сетевую политику, которая ограничивает доступ и разрешает вход только через входной контроллер на определенном порту.
Теперь, с его развертыванием на каждом узле Kubernetes, плагин управляет маршрутизацией между модулями и имеет доступ для управления правилами IPtables. Проще говоря, каждая политика преобразуется в набор правил IPtables, которые координируются и настраиваются на каждом компьютере для преобразования тегов Kubernetes.
Хорошо, теперь, когда вы изучили столько теории о Kubernetes Networking, позвольте мне показать вам, как это делается на практике.
Руки вверх
Итак, предполагая, что все вы установили Kubernetes в свои системы, у меня есть сценарий, который я хочу продемонстрировать.
Предположим, вы хотите сохранить название продукта и идентификатор продукта, для этого вам понадобится веб-приложение. По сути, вам нужен один контейнер для веб-приложения, и вам нужен еще один контейнер в качестве MySQL для серверной части, и этот контейнер MySQL должен быть связан с контейнером веб-приложения.
Как насчет того, чтобы выполнить вышеприведенный пример практически.
Давайте начнем!
Шаг 1: Создайте папку в желаемом каталоге и измените путь рабочего каталога на эту папку.
mkdir HandsOn cd HandsOn /
Шаг 2: Теперь создайте файлы YAML развертывания для веб-приложения и базы данных MySQL.
Шаг 3: После создания файлов развертывания разверните оба приложения.
kubectl apply -f webapp.yml kubectl apply -f mysql.yml
Шаг 3.1: Проверьте оба развертывания.
kubectl получить развертывание
Шаг 4: Теперь вам нужно создать службы для обоих приложений.
kubectl apply -f webservice.yml kubectl apply -f sqlservice.yml
Шаг 4.1: После создания служб разверните службы.
Шаг 4.2: Проверьте, созданы ли сервисы или нет.
kubectl получить сервис
Шаг 5: Теперь проверьте конфигурацию запущенных модулей.
kubectl получить стручки
Шаг 6: Войдите в контейнер внутри модуля webapp.
kubectl exec -it идентификатор_контейнера bash nano var / www / html / index.php
Шаг 6.1 : Теперь измените $ servername от localhost до имени службы SQL « webapp-sql1 ”В этом случае и $ пароль от до ' Edureka ». Кроме того, заполните все необходимые данные базы данных и сохраните файл index.php с помощью сочетания клавиш. Ctrl + x и после этого нажмите Y сохранить и нажать войти .
Шаг 7: Теперь перейдите в контейнер MySQL, присутствующий в модуле..
kubectl exec it container_id bash
Шаг 7.1: Получите доступ к использованию контейнера MySQL.
mysql -u корень -p edureka
Где -u представляет пользователя, а -p - пароль вашей машины.
Шаг 7.2: Создайте базу данных в MySQL, которая будет использоваться для получения данных из веб-приложения.
СОЗДАТЬ БАЗУ ДАННЫХ
Шаг 7.3: Воспользуйтесь созданной базой данных.
ИСПОЛЬЗУЙТЕ детали продукта
Шаг 7.4: Создайте таблицу в этой базе данных в MySQL, которая будет использоваться для получения данных из веб-приложения.
СОЗДАТЬ ТАБЛИЦУ продукты (имя_продукта VARCHAR (10), идентификатор_продукта VARCHAR (11))
Шаг 7.5: Теперь выйдите из контейнера MySQL, используя команду выход .
Шаг 8: Проверьте номер порта, на котором работает ваше веб-приложение.
kubectl получить услуги
Шаг 8.1: Теперь откройте веб-приложение на выделенном ему номере порта.
Шаг 9: Как только вы нажмете на Отправить запрос , перейдите к узлу, на котором работает ваша служба MySQL, а затем войдите в контейнер.
Это покажет вам вывод всех продуктов списка, о которых вы заполнили детали.
Заинтересованы в изучении Kubernetes?Если вы нашли этот блог Kubernetes Networking актуальным, ознакомьтесь с от Edureka, надежной компании по онлайн-обучению с сетью из более чем 250 000 довольных учащихся по всему миру.