🥇Урок за Kubernetes, част 1: Приложения, микроуслуги и контейнери

По наша молба Habr създаде хъб Kubernetes и имаме удоволствието да поместим първата публикация в него. Абонирай се!

Kubernetes е лесен. Защо банките ми плащат много пари, за да работя в тази област, докато всеки може да овладее тази технология само за няколко часа?

Ако се съмнявате, че Kubernetes може да се научи толкова бързо, предлагам ви да опитате да го направите сами. А именно, след като усвоите този материал, ще можете да стартирате приложение, базирано на микроуслуги в клъстер на Kubernetes. Мога да гарантирам това, защото по същата методология, която използвам тук, обучавам нашите клиенти как да работят с Kubernetes. Какво прави това ръководство различно от другите? Всъщност, много неща. И така, повечето от тези материали започват с обяснение на прости неща - концепциите на Kubernetes и характеристиките на командата kubectl. Авторите на тези статии предполагат, че техният читател е запознат с разработката на приложения, микроуслугите и Docker контейнерите. Ще тръгнем по другия път. Първо, нека поговорим за това как да стартирате приложение, базирано на микроуслуги на компютър. След това ще разгледаме изграждането на изображения на контейнери за всяка микроуслуга. И след това ще се запознаем с Kubernetes и ще анализираме внедряването на приложение, базирано на микроуслуги в клъстер, управляван от Kubernetes.

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

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

Експериментално приложение

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

Ето как изглежда основният прозорец на това приложение.

Уеб приложение за анализ на настроението

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

SA-Frontend е уеб сървър на Nginx, който обслужва статични файлове на React.
SA-WebApp е уеб приложение, написано на Java, което обработва заявки от интерфейса.
SA-Logic е приложение на Python, което извършва анализ на настроението на текста.

Важно е да се отбележи, че микроуслугите не съществуват изолирано. Те прилагат идеята за "разделяне на задълженията", но в същото време трябва да взаимодействат помежду си.

Потоци от данни в приложението

В диаграмата по-горе можете да видите номерираните етапи на системата, илюстриращи потоците от данни в приложението. Нека ги разделим:

Браузърът изисква файл от сървъра index.html (което от своя страна зарежда пакета на приложението React).
Потребителят взаимодейства с приложението, което води до извикване на уеб приложение, базирано на Spring.
Уеб приложението препраща заявката за анализиране на текста към приложението Python.
Приложението Python анализира настроението на текста и връща резултата като отговор на заявката.
Приложението Spring изпраща отговор на приложението React (което от своя страна показва резултата от анализирания текст на потребителя).

Кодът за всички тези приложения може да бъде намерен тук. Препоръчвам ви да копирате това хранилище при себе си точно сега, тъй като ни предстоят много интересни експерименти с него.

Стартиране на приложение, базирано на микроуслуги на локалната машина

За да работи приложението, трябва да стартираме и трите микроуслуги. Нека започнем с най-красивото от тях - приложението отпред.

▍Настройване на React за локално развитие

За да стартирате React приложение, трябва да инсталирате рамката Node.js и NPM на вашия компютър. След като инсталирате всичко това, отидете с помощта на терминала в папката на проекта sa-frontend и изпълнете следната команда:

npm install

Чрез изпълнение на тази команда в папката node_modules ще се заредят зависимостите на приложението React, чиито записи са във файла package.json. След като изтеглите зависимостите в същата папка, изпълнете следната команда:

npm start

Това е всичко. Приложението React вече работи и може да бъде достъпно чрез навигиране до адреса на браузъра localhost:3000. Можете да промените нещо в неговия код. Веднага ще видите ефекта от тези промени в браузъра. Това е възможно благодарение на така наречената "гореща" подмяна на модулите. Благодарение на това, front-end разработката се превръща в просто и приятно изживяване.

▍Подготовка на React приложение за производство

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

За да създадете приложението React, отново с помощта на терминала, отидете до папката sa-frontend и изпълнете следната команда:

npm run build

Това ще създаде директория в папката на проекта build. Той ще съдържа всички статични файлове, необходими за работата на приложението React.

▍Обслужване на статични файлове с Nginx

Първо трябва да инсталирате и стартирате уеб сървъра Nginx. Тук можете да го изтеглите и да намерите инструкции за инсталирането и стартирането му. След това трябва да копирате съдържанието на папката sa-frontend/build към папката [your_nginx_installation_dir]/html.

С този подход файлът, генериран по време на асемблирането на приложението React index.html ще бъде на разположение на [your_nginx_installation_dir]/html/index.html. Това е файлът, който по подразбиране сървърът на Nginx издава при достъп до него. Сървърът е конфигуриран да слуша на порт 80, но можете да го персонализирате както искате, като редактирате файла [your_nginx_installation_dir]/conf/nginx.conf.

Сега отворете браузъра си и отидете на localhost:80. Ще видите страницата на приложението React.

Приложение React, обслужвано от Nginx сървър

Ако сега въведете нещо в полето Type your sentence и натиснете бутона Send - нищо няма да се случи. Но ако погледнете конзолата, можете да видите съобщения за грешка там. За да разберем къде точно възникват тези грешки, нека анализираме кода на приложението.

▍Анализ на кода на front-end приложението

Разглеждане на кода на файла App.js, можем да видим това, като щракнем върху бутона Send извиква метод analyzeSentence(). Кодът за този метод е показан по-долу. В същото време обърнете внимание на факта, че за всеки ред, към който има коментар на формуляра # Номер, под кода има обяснение. По същия начин ще анализираме други фрагменти от код.

analyzeSentence() {
    fetch('http://localhost:8080/sentiment', {  // #1
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({
                       sentence: this.textField.getValue()})// #2
    })
        .then(response => response.json())
        .then(data => this.setState(data));  // #3
}

1. URL адресът, към който се прави POST заявката. Предполага се, че този адрес е приложение, чакащо такива заявки.

2.Тялото на заявката, изпратено до приложението. Ето примерен текст на заявка:

{
    sentence: "I like yogobella!"
}

3.Когато се получи отговор на заявка, състоянието на компонента се актуализира. Това води до повторно изобразяване на компонента. Ако получим данни (т.е. JSON обект, съдържащ въведените данни и изчислената текстова оценка), ще изведем компонента Polarityстига да са изпълнени условията. Ето как описваме компонента:

const polarityComponent = this.state.polarity !== undefined ?
    <Polarity sentence={this.state.sentence} 
              polarity={this.state.polarity}/> :
    null;

Кодът изглежда работи доста добре. Какво не е наред тук, все пак? Ако приемете, че на адреса, на който приложението се опитва да изпрати POST заявка, все още няма нищо, което да приеме и обработи тази заявка, тогава ще бъдете напълно прави. А именно да обработва заявки, постъпващи на адреса http://localhost:8080/sentiment, трябва да стартираме уеб приложение, базирано на Spring.

Имаме нужда от Spring приложение, което може да приеме POST заявка

▍Настройване на уеб приложение, базирано на Spring

За да внедрите Spring приложение, имате нужда от JDK8 и Maven и правилно конфигурирани променливи на средата. След като инсталирате всичко това, можете да продължите да работите по нашия проект.

▍Пакетиране на приложението в jar файл

Отидете с помощта на терминала до папката sa-webapp и въведете следната команда:

mvn install

След изпълнение на тази команда в папката sa-webapp ще бъде създадена директория target. Това е мястото, където ще бъде разположено Java приложението, пакетирано в jar файл, представен от файла sentiment-analysis-web-0.0.1-SNAPSHOT.jar.

▍Стартиране на Java приложение

Отидете в папката target и стартирайте приложението със следната команда:

java -jar sentiment-analysis-web-0.0.1-SNAPSHOT.jar

Ще възникне грешка при изпълнение на тази команда. За да започнем да го коригираме, можем да анализираме детайлите на изключението в данните за проследяване на стека:

Error creating bean with name 'sentimentController': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'sa.logic.api.url' in value "${sa.logic.api.url}"

За нас най-важното тук е споменаването на невъзможността за изясняване на смисъла sa.logic.api.url. Нека анализираме кода, където възниква грешката.

▍Анализ на кода на Java приложение

Ето кодовия фрагмент, където възниква грешката.

@CrossOrigin(origins = "*")
@RestController
public class SentimentController {
    @Value("${sa.logic.api.url}")    // #1
    private String saLogicApiUrl;
    @PostMapping("/sentiment")
    public SentimentDto sentimentAnalysis(
        @RequestBody SentenceDto sentenceDto) 
    {
        RestTemplate restTemplate = new RestTemplate();
        return restTemplate.postForEntity(
                saLogicApiUrl + "/analyse/sentiment",    // #2
                sentenceDto, SentimentDto.class)
                .getBody();
    }
}

В СentimentController има поле saLogicApiUrl. Стойността му се определя от имота sa.logic.api.url.
ред saLogicApiUrl свързва със стойността /analyse/sentiment. Заедно те образуват адрес за осъществяване на повикване към микроуслугата, която извършва анализ на текст.

▍Задаване на стойност на свойството

През пролетта източникът по подразбиране на стойностите на свойствата е файл application.properties, който можете да намерите на sa-webapp/src/main/resources. Но използването му не е единственият начин за задаване на стойности на свойства. Можете също да направите това със следната команда:

java -jar sentiment-analysis-web-0.0.1-SNAPSHOT.jar --sa.logic.api.url=WHAT.IS.THE.SA.LOGIC.API.URL

Стойността на това свойство трябва да сочи към адреса на нашето Python приложение.

Като го конфигурираме, казваме на уеб приложението Spring къде трябва да отиде, за да направи заявки за анализ на текст.

За да не си усложняваме живота, ще решим приложението Python да бъде достъпно на localhost:5000 и се опитайте да не го забравяте. В резултат на това командата за стартиране на приложението Spring ще изглежда така:

java -jar sentiment-analysis-web-0.0.1-SNAPSHOT.jar --sa.logic.api.url=http://localhost:5000

В нашата система липсва приложение на Python

Сега просто трябва да стартираме приложението Python и системата ще работи според очакванията.

▍Настройване на приложение на Python

За да стартирате приложение на Python, трябва да имате инсталирани Python 3 и Pip и трябва да имате правилно зададени съответните променливи на средата.

▍Инсталирайте зависимости

Отидете в папката на проекта sa-logic/sa и изпълнете следните команди:

python -m pip install -r requirements.txt
python -m textblob.download_corpora

▍Стартиране на приложението

С инсталираните зависимости сме готови да стартираме приложението:

python sentiment_analysis.py

След като изпълним тази команда, ще ни бъде казано следното:

* Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

Това означава, че приложението работи и чака заявки на localhost:5000/

▍Проучване на код

Нека да разгледаме кода на приложението на Python, за да разберем как отговаря на заявки:

from textblob import TextBlob
from flask import Flask, request, jsonify
app = Flask(__name__)                                   #1
@app.route("/analyse/sentiment", methods=['POST'])      #2
def analyse_sentiment():
    sentence = request.get_json()['sentence']           #3
    polarity = TextBlob(sentence).sentences[0].polarity #4
    return jsonify(                                     #5
        sentence=sentence,
        polarity=polarity
    )
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)                #6

Инициализация на обект Flask.
Посочване на адреса за изпращане на POST заявки към него.
Извличане на собственост sentence от тялото на заявката.
Инициализация на анонимен обект TextBlob и получаване на стойността polarity за първото предложение, получено в тялото на заявката (в нашия случай това е единственото предложение, изпратено за анализ).
Връщане на отговор, чието тяло съдържа текста на офертата и изчисления за нея показател polarity.
Стартиране на приложението Flask, което ще бъде достъпно на 0.0.0.0:5000 (можете също да получите достъп до него, като използвате конструкция на формуляра localhost:5000).

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

Всички микроуслуги, които съставляват приложението, се привеждат в здравословно състояние

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

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

Докер контейнери

Kubernetes е система за автоматизиране на внедряването, мащабирането и управлението на контейнерни приложения. Нарича се още "контейнер оркестратор". Ако Kubernetes работи с контейнери, тогава преди да използваме тази система, първо трябва да придобием тези контейнери. Но първо, нека поговорим какво представляват контейнерите. Може би най-добрият отговор на въпроса какво е това може да се намери в документация към Docker:

Изображението на контейнера е лек, самостоятелен, изпълним пакет, който съдържа приложение, което включва всичко необходимо за стартирането му: код на приложението, среда за изпълнение, системни инструменти и библиотеки, настройки. Контейнерните програми могат да се използват както в среди на Linux, така и в Windows и винаги ще работят по същия начин, независимо от инфраструктурата.

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

За да проучим функциите на контейнерите и да ги сравним с други начини за стартиране на приложения, нека да разгледаме примера за обслужване на React приложение с помощта на виртуална машина и контейнер.

▍Обслужване на статични файлове на React приложение с помощта на виртуална машина

Опитвайки се да организираме поддръжката на статични файлове с помощта на виртуални машини, ще се сблъскаме със следните недостатъци:

Неефективно използване на ресурсите, тъй като всяка виртуална машина е цялостна операционна система.
Зависимост от платформа. Това, което работи на някой локален компютър, може да не работи на производствен сървър.
Бавно и изискващо ресурси мащабиране на решение за виртуална машина.

Nginx уеб сървър, обслужващ статични файлове, работещи във виртуална машина

Ако контейнерите се използват за решаване на подобен проблем, тогава в сравнение с виртуалните машини могат да се отбележат следните силни страни:

Ефективно използване на ресурсите: работа с операционната система с помощта на Docker.
Независимост на платформата. Контейнер, който разработчикът може да стартира на собствения си компютър, ще работи навсякъде.
Леко внедряване чрез използване на слоеве на изображения.

Nginx уеб сървър, обслужващ статични файлове, работещи в контейнер

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

▍Изграждане на изображение на контейнер за React приложение

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

Преди да започнем работа с файла Dockerfile, спомнете си какво направихме, за да подготвим файловете на приложението React за качване на сървъра на Nginx:

Изграждане на пакет от приложения React (npm run build).
Стартиране на сървъра Nginx.
Копиране на съдържанието на директория build от папката на проекта sa-frontend към папката на сървъра nginx/html.

По-долу можете да видите паралелите между създаването на контейнер и горните действия, извършени на локалния компютър.

▍Подготовка на Dockerfile за SA-Frontend приложението

Инструкции, които трябва да бъдат включени в Dockerfile за кандидатстване SA-Frontend, се състои само от два отбора. Факт е, че екипът за разработка на Nginx е подготвил основен изображение за Nginx, който ще използваме за изграждане на нашия имидж. Ето двете стъпки, които трябва да опишем:

Трябва да направите изображението на Nginx основа на изображението.
Съдържание на папката sa-frontend/build трябва да копирате в папката с изображения nginx/html.

Ако преминем от това описание към файла Dockerfile, тогава ще изглежда така:

FROM nginx
COPY build /usr/share/nginx/html

Както можете да видите, всичко тук е много просто, докато съдържанието на файла дори се оказва доста четливо и разбираемо. Този файл казва на системата да вземе изображението nginx с всичко, което вече има, и копирайте съдържанието на директорията build към директорията nginx/html.

Тук може да имате въпрос относно това как знам къде точно да копирам файловете от папката build, т.е. откъде е тръгнал пътят /usr/share/nginx/html. Всъщност и тук няма нищо сложно. Факт е, че съответната информация може да бъде намерена в описание изображение.

▍Сглобяване на изображението и качването му в хранилището

Преди да можем да работим със завършено изображение, трябва да го изпратим в хранилището на изображения. За да направим това, ще използваме безплатната облачна платформа за хостинг на изображения Docker Hub. На този етап от работата трябва да направите следното:

установят докер.
Регистрирайте се на сайта на Docker Hub.
Влезте в акаунта си, като изпълните следната команда в терминала:
```
docker login -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD"
```

Сега трябва, като използвате терминала, отидете в директорията sa-frontend и изпълнете следната команда там:

docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend .

Тук и по-долу в подобни команди $DOCKER_USER_ID трябва да бъде заменено с вашето потребителско име в Docker Hub. Например, тази част от командата може да изглежда така: rinormaloku/sentiment-analysis-frontend.

В този случай тази команда може да бъде съкратена, като се премахне от нея -f Dockerfile, тъй като папката, в която изпълняваме тази команда, вече има този файл.

За да изпратим готовото изображение в хранилището, се нуждаем от следната команда:

docker push $DOCKER_USER_ID/sentiment-analysis-frontend

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

▍Стартиране на контейнер

Сега всеки може да изтегли и стартира изображението, известно като $DOCKER_USER_ID/sentiment-analysis-frontend. За да направите това, трябва да изпълните следната последователност от команди:

docker pull $DOCKER_USER_ID/sentiment-analysis-frontend
docker run -d -p 80:80 $DOCKER_USER_ID/sentiment-analysis-frontend

Сега контейнерът работи и можем да продължим да работим, като създадем други изображения, от които се нуждаем. Но преди да продължим, нека разберем дизайна 80:80, което се намира в командата за изпълнение на изображението и може да изглежда объркващо.

Първо число 80 е номерът на порта на хоста (т.е. локалния компютър).
Второ число 80 е портът на контейнера, към който трябва да бъде пренасочена заявката.

Разгледайте следната илюстрация.

Пренасочване на портове

Системата препраща заявки от порта <hostPort> до пристанището <containerPort>. Тоест достъп до порта 80 компютърът е пренасочен към порт 80 контейнер.

Тъй като пристанището 80 отворено на локалния компютър, можете да получите достъп до приложението от този компютър на адрес localhost:80. Ако вашата система не поддържа Docker, можете да стартирате приложението на виртуална машина Docker, чийто адрес ще изглежда така <docker-machine ip>:80. За да разберете IP адреса на виртуалната машина Docker, можете да използвате командата docker-machine ip.

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

▍.dockerignore файл

Изграждане на изображението на приложението SA-Frontend, можем да забележим, че този процес е изключително бавен. Това е така, защото контекстът за изграждане на изображение трябва да бъде изпратен до демона на Docker. Директорията, която представлява контекста на компилация, се дава като последен аргумент на командата docker build. В нашия случай в края на тази команда има точка. Това води до включването на следната структура в контекста на асемблирането:

sa-frontend:
|   .dockerignore
|   Dockerfile
|   package.json
|   README.md
+---build
+---node_modules
+---public
---src

Но от всички папки, присъстващи тук, имаме нужда само от папка build. Изтеглянето на нещо друго е загуба на време. Можете да ускорите изграждането, като кажете на Docker кои директории да игнорира. За да направим това, имаме нужда от файл .dockerignore. Вие, ако сте запознати с файла .gitignore, структурата на този файл вероятно ще изглежда позната. Той изброява директории, които системата за изграждане на изображение може да игнорира. В нашия случай съдържанието на този файл изглежда така:

node_modules
src
public

досие .dockerignore трябва да е в същата папка като файла Dockerfile. Сега сглобяването на изображението ще отнеме няколко секунди.

Нека сега да разгледаме изображението за Java приложение.

▍Изграждане на изображение на контейнер за Java приложение

Знаете какво и вече сте научили всичко необходимо за създаване на контейнерни изображения. Ето защо този раздел ще бъде много кратък.

Отворете файла Dockerfile, който се намира в папката на проекта sa-webapp. Ако прочетете текста на този файл, тогава в него ще срещнете само две нови конструкции, които започват с ключови думи ENV и EXPOSE:

ENV SA_LOGIC_API_URL http://localhost:5000
…
EXPOSE 8080

Ключова дума ENV ви позволява да декларирате променливи на средата в Docker контейнери. По-специално, в нашия случай ви позволява да зададете URL за достъп до API на приложението, което извършва анализ на текст.

Ключова дума EXPOSE ви позволява да кажете на Docker да отвори порт. Ще използваме този порт, докато работим с приложението. Тук можете да видите това в Dockerfile за кандидатстване SA-Frontend няма такава команда. Това е само за целите на документацията, с други думи, тази конструкция е за читателя Dockerfile.

Изграждането на изображението и изпращането му в хранилището изглежда точно като предишния пример. Ако все още не сте много уверени в способностите си, съответните команди могат да бъдат намерени във файла README.md в папка sa-webapp.

▍Изграждане на изображение на контейнер за приложение на Python

Ако погледнете съдържанието на файла Dockerfile в папка sa-logicняма да намерите нищо ново там. Командите за изграждане на изображението и изпращането му в хранилището трябва вече да са ви познати, но, както в случая с другите ни приложения, те могат да бъдат намерени във файла README.md в папка sa-logic.

▍Тестване на контейнерни приложения

Можете ли да се доверите на нещо, което не сте тествали? И аз не мога. Нека тестваме нашите контейнери.

Нека стартираме контейнера за приложения sa-logic и го конфигурирайте да слуша на порт 5050:
```
docker run -d -p 5050:5000 $DOCKER_USER_ID/sentiment-analysis-logic
```
Нека стартираме контейнера за приложения sa-webapp и го конфигурирайте да слуша на порт 8080. Освен това трябва да зададем порта, на който приложението Python ще слуша за заявки от приложението Java, като преназначим променливата на средата SA_LOGIC_API_URL:
```
$ docker run -d -p 8080:8080 -e SA_LOGIC_API_URL='http://<container_ip or docker machine ip>:5000' $DOCKER_USER_ID/sentiment-analysis-web-app
```

За да научите как да откриете IP адреса на контейнер или Docker VM, вижте файла README.

Нека стартираме контейнера за приложения sa-frontend:

docker run -d -p 80:80 $DOCKER_USER_ID/sentiment-analysis-frontend

Сега всичко е готово за навигация в браузъра до адреса localhost:80 и тествайте приложението.

Моля, имайте предвид, че ако промените порта за sa-webapp, или ако използвате Docker VM, ще трябва да редактирате файла App.js от папка sa-frontendчрез промяна на IP адреса или номера на порта в метода analyzeSentence()чрез заместване на текуща информация вместо остарели данни. След това трябва да сглобите отново изображението и да го използвате.

Ето как изглежда нашата диаграма на приложението сега.

Микроуслугите работят в контейнери

Резюме: защо се нуждаем от Kubernetes клъстер?

Току-що прегледахме файловете Dockerfile, говори за това как да създавате изображения и да ги изпращате в хранилище на Docker. Освен това научихме как да ускорим сглобяването на изображения с помощта на файла .dockerignore. В резултат на това нашите микроуслуги вече работят в Docker контейнери. Тук може да имате напълно основателен въпрос защо имаме нужда от Kubernetes. Отговорът на този въпрос ще бъде посветен на втората част на този материал. Междувременно разгледайте следния въпрос:
Да приемем, че нашето уеб приложение за анализ на текст е станало популярно в световен мащаб. Всяка минута при него идват милиони заявки. Това означава, че микроуслугите sa-webapp и sa-logic ще бъде под огромен стрес. Как да мащабирате контейнери, които изпълняват микроуслуги?

Източник: www.habr.com

Урок за Kubernetes, част 1: Приложения, микроуслуги и контейнери