Kubernetes Networking - изчерпателно ръководство за мрежовите концепции в Kubernetes

В предишния блог на , трябва да сте разбрали за Kubernetes. В този блог за Kubernetes мрежи ще се фокусирам предимно върху мрежовите концепции, включени в Kubernetes.

В този блог за Kubernetes Networking ще разберете следните теми:

• Какво представлява Kubernetes?
• Работа в мрежа в Kubernetes
• Случай за използване на съветника за богатство
• Практически

Какво е Kubernetes?

Можете да определите Kubernetes като инструмент за оркестрация на контейнери с отворен код, който осигурява преносима платформа за автоматизиране на внедряването на контейнеризирани приложения.

Сега всеки, който работи с Kubernetes, трябва да има ясно разбиране за Kubernetes Cluster, тъй като това ще ви помогне да разберете Kubernetes Networking.

Клъстер Kubernetes

Платформата Kubernetes предлага желано управление на състоянието, което позволява на клъстерните услуги да работят, захранваната конфигурация в инфраструктурата. Нека да обясня с пример.

Помислете за YAML файл, който съдържа цялата информация за конфигурацията, която трябва да бъде подадена в услугите на клъстера. И така, този файл се подава към приложния програмен интерфейс (API) на клъстерни услуги и след това клъстерните услуги ще определят как да планират подси в околната среда. И така, да предположим, че има две изображения на контейнери за pod 1 с три реплики и едно изображение на контейнер за pod 2 с две реплики, зависи от услугите на клъстера, за да разпределят тези двойки под-реплики на работниците.

пример за краставица java селен webdriver

Обърнете се към горната схема. Сега, както можете да видите, че клъстерните услуги са разпределили първия работник с две двойки реплики на шушулки, втория работник с двойка двойка реплика на шушулка и третия работник с две двойки реплики на шушулки. Сега процесът Kubelet е отговорен за комуникацията на клъстерните услуги с работниците.

И така, цялата тази настройка на клъстерни услуги и самите работници съставят това Клъстер Kubernetes !!

Как мислите, че тези индивидуално разпределени шушулки комуникират помежду си?

Отговорът се крие в Kubernetes Networking!

Абонирайте се за нашия канал в YouTube, за да получавате нови актуализации ..!

Има основно 4 проблема за решаване с мрежовите концепции.

• Контейнер към контейнерна комуникация
• Под комуникация от под до под
• Под за обслужваща комуникация
• Външни за услугата Комуникация

Сега, нека ви кажа как се решават горните проблеми с Kubernetes Networking.

Kubernetes Networking

Комуникацията между шушулките, услугите и външните услуги към тези в клъстера включва концепцията за Kubernetes мрежа.

Така че, за ваше по-добро разбиране, позволете ми да разделя понятията на следните.

• Комуникация на шушулки и контейнери
• Услуги
• Свързване на външни към услуги чрез Ingress Network

Комуникация на шушулки и контейнери

Преди да ви кажа как комуникират шушулките, позволете ми да ви представя какво представляват шушулките?

Подс

Pods са основните единици на Kubernetes приложения, които се състоят от един или повече контейнери, разпределени на един и същ хост за споделяне на мрежов стек и други ресурси. Това означава, че всички контейнери в подсистемата могат да достигнат до други на локален хост.

А сега, нека ви запозная с това как комуникират тези шушулки?

Има 2 вида комуникация. The междувъзлова комуникация и вътрешновъзлова комуникация.

И така, нека започнем с вътрешновъзлова комуникация, но преди това нека ви запозная с компонентите на подмрежата.

Intra-node Pod Network

Вътрешно-възловата подмрежа е основно комуникацията между два различни възла в един и същ под. Позволете ми да ви обясня с пример.

Да приемем, че пакетът преминава от pod1 към pod2.

• Пакетът напуска мрежата на Pod 1 на eth0 и влиза в кореновата мрежа на veth0
• След това пакетът преминава към моста на Linux (cbr0), който открива дестинацията с помощта на ARP заявка
• Така че, ако veth1 има IP, мостът вече знае къде да препрати пакета.

Сега, по същия начин, нека ви разкажа за комуникацията на под-възела.

Inter-node pod network

Помислете за два възела с различни мрежови пространства от имена, мрежови интерфейси и Linux мост.

Сега, приемете, че пакетът пътува от pod1 до pod4, който е на различен възел.

• Пакетът напуска мрежата pod 1 и влиза в кореновата мрежа при veth0
• След това пакетът преминава към моста на Linux (cbr0), чиято отговорност е да направи ARP заявка за намиране на дестинацията.
• След като мостът осъзнае, че този модул няма адреса на местоназначение, пакетът се връща към основния мрежов интерфейс eth0.
• Сега пакетът напуска възела 1, за да намери дестинацията на другия възел, и влиза в таблицата с маршрути, който насочва пакета към възела, чийто CIDR блок съдържа pod4.
• И така, сега пакетът достига node2 и след това мостът взема пакета, който прави ARP заявка, за да установи, че IP принадлежи на veth0.
• Накрая пакетът пресича двойката тръби и достига pod4.

И така, шушулките комуникират помежду си. Сега нека да продължим напред и да видим как услугите помагат в комуникацията на шушулки.

И така, какви според вас са услугите?

Услуги

По принцип услугите са вид ресурс, който конфигурира прокси за препращане на заявките към набор от под, които ще получават трафик и се определя от селектора. След като услугата е създадена, тя има присвоен IP адрес, който ще приема заявки на порта.

Сега има различни видове услуги, които ви дават възможност за излагане на услуга извън вашия IP адрес на клъстера.

Видове услуги

Има основно 4 вида услуги.

IP клъстер: Това е типът услуга по подразбиране, който излага услугата на вътрешен IP адрес на клъстера, като прави услугата достъпна само в рамките на клъстера.

NodePort: Това излага услугата на IP на всеки възел на статичен порт. Тъй като, а Клъстер IP услуга, към която ще насочва услугата NodePort, се създава автоматично. Можем да се свържем с услугата NodePort извън клъстера.

LoadBalancer: Това е типът услуга, който излага услугата външно, използвайки балансиращия товар на доставчика на облак. Така че услугите NodePort и ClusterIP, към които ще се насочи външният балансиращ товар, се създават автоматично.

Външно име : Този тип услуга съпоставя услугата със съдържанието на externalName поле чрез връщане на a CNAME запис с неговата стойност.

Така че, момчета, това беше всичко за услугите. Сега може би се чудите как външните услуги се свързват с тези мрежи, нали?

Е, това е от никой друг Влизане мрежа .

Влизане мрежа

Е, мрежата Ingress е най-мощният начин за излагане на услуги, тъй като е колекция от правила, които позволяват входящи връзки, които могат да бъдат конфигурирани да предоставят услуги външно чрез достъпни URL адреси. И така, той по същество действа като входна точка към клъстера Kubernetes, който управлява външен достъп до услугите в клъстер.

Сега, нека ви обясня с пример работата на Ingress Network.

Разполагаме с 2 възла, имащи пространства от имена на под и коренна мрежа с Linux мост. В допълнение към това, ние също имаме ново виртуално Ethernet устройство, наречено flannel0 (мрежов плъгин), добавено към основната мрежа.

Сега искаме пакетът да преминава от pod1 към pod 4.

• И така, пакетът напуска мрежата на pod1 на eth0 и влиза в основната мрежа на veth0.
• След това се предава на cbr0, който прави ARP заявката за намиране на дестинацията и след това установява, че никой в ​​този възел няма IP адреса на дестинацията.
• И така, мостът изпраща пакета на flannel0, тъй като маршрутната таблица на възела е конфигурирана с flannel0.
• Сега фланеловият демон разговаря с API сървъра на Kubernetes, за да знае всички IP адреси на подсистемите и съответните им възли, за да създаде съпоставяне на IP адреси на подсистеми с IP адреси на възли.
• Мрежовият плъгин обвива този пакет в UDP пакет с допълнителни заглавки, променящи източника и местоназначението IP към съответните им възли и изпраща този пакет чрез eth0.
• Сега, тъй като таблицата с маршрути вече знае как да насочва трафика между възлите, тя изпраща пакета до целевия node2.
• Пакетът пристига в eth0 на node2 и се връща към flannel0, за да се декапсулира и го излъчва обратно в коренното пространство от имена.
• Отново пакетът се препраща към моста на Linux, за да се направи ARP заявка за откриване на IP, който принадлежи на veth1.
• Пакетът накрая пресича коренната мрежа и достига до дестинацията Pod4.

Така че, по този начин външните услуги са свързани с помощта на входяща мрежа. Сега, когато говорих за мрежови плъгини, позволете ми да ви запозная със списъка с популярни мрежови плъгини.

Сега, след като ви разказах толкова много за Kubernetes Networking, позволете ми да ви покажа казус от реалния живот.

Казус: Съветник за богатство, използващ Kubernetes Networking

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 се прилага -f webapp.yml kubectl се прилага -f mysql.yml

Стъпка 3.1: Проверете и двете разполагания.

kubectl получи разгръщане

Стъпка 4: Сега трябва да създадете услуги и за двете приложения.

kubectl се прилага -f webservice.yml kubectl се прилага -f sqlservice.yml

Стъпка 4.1: След като услугите са създадени, внедрете услугите.

Стъпка 4.2: Проверете дали услугите са създадени или не.

kubectl получи услуга

Стъпка 5: Сега проверете конфигурацията на работещите под.

kubectl вземи шушулки

Стъпка 6: Влезте в контейнера вътре в webapp шушулката.

kubectl exec -it container_id bash nano var / www / html / index.php

Стъпка 6.1 : Сега променете $ име на сървър от localhost до името на услугата SQL, което е „ webapp-sql1 ”В този случай и $ парола от до ' edureka ”. Освен това попълнете всички необходими данни за базата данни и запазете файла index.php, като използвате клавишната комбинация Ctrl + x и след това натиснете Y. за да запаметите и натиснете въведете .

Стъпка 7: Сега отидете в контейнера на MySQL, който се намира в шушулката.

kubectl го изпълнява container_id bash

Стъпка 7.1: Получете достъп за използване на контейнера MySQL.

mysql -u корен -p edureka

Където -u представлява потребителя, а -p е паролата на вашата машина.

Стъпка 7.2: Създайте база данни в MySQL, която ще се използва за получаване на данни от webapp.

СЪЗДАЙТЕ БАЗАТА ДАННИ ProductDetails

Стъпка 7.3: Използвайте създадената база данни.

ИЗПОЛЗВАЙТЕ Подробности за продукта

Стъпка 7.4: Създайте таблица в тази база данни в MySQL, която ще се използва за получаване на данни от webapp.

СЪЗДАВАНЕ НА ТАБЛИЦА продукти (име на продукт VARCHAR (10), product_id VARCHAR (11))

Стъпка 7.5: Сега излезте и от MySQL контейнера, като използвате командата изход .

Стъпка 8: Проверете номера на порта, на който работи вашето уеб приложение.

kubectl получи услуги

Стъпка 8.1: Сега отворете уеб приложението на разпределения номер на порт.

Стъпка 9: След като щракнете върху Изпратете заявка , отидете до възела, в който се изпълнява вашата услуга MySQL, и след това влезте в контейнера.

Това ще ви покаже резултатите от всички продукти от списъка, за които сте попълнили подробностите.

Ако намерите този блог за Kubernetes Networking за подходящ, разгледайте от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят.