Ръководство за Kubernetes, част 1: приложения, микросервизи и контейнери

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стартиране на приложение, основано на микросервизи, на локален компютър

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

▍Настройка на React за локална разработка

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

npm install

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

npm start

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

▍ Подготовка на 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 — нищо няма да се случи. Но ако погледнете конзолата, можете да видите съобщения за грешки. За да разберем къде точно се случват тези грешки, ще разгледаме кода на приложението.

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

Като погледнем кода на файла 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 обект, съдържащ входящите данни и изчислената оценка на текста), ще изведем компонента Полярност, тъй като ще бъдат спазени съответните условия. Ето как описваме компонента:

const polarityComponent = this.state.polarity !== undefined ?
     :
    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

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

Грешка при създаването на bean с име 'sentimentController': Инжектирането на зависимости не успя; вложено изключение е java.lang.IllegalArgumentException: Не можа да се разреши заместителят 'sa.logic.api.url' в стойността "${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();
    }
}

1. В SentimentController има поле saLogicApiUrl. Неговата стойност се задава чрез свойството sa.logic.api.url.
2. Редът saLogicApiUrl конкатенирова се със стойността /analyse/sentiment. Заедно те формират адрес за извършване на обаждане към микросервиза, който изпълнява анализ на текста.

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

В Spring стандартният източник на стойности на свойства е файлът 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

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

* Работи на http://0.0.0.0:5000/ (Натиснете CTRL+C, за да прекратите)

Това означава, че приложението е стартирано и очаква заявки на адрес 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

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

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

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

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

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

Контейнери Docker

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

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

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

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

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

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

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

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

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

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

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

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

▍Създаване на образ на контейнер за React-приложение

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

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

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

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

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

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

1. Както основа на образа трябва да направим образ на Nginx.
2. Съдържанието на папката 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. На този етап на работа трябва да направите следното:

1. Инсталиране Docker.
2. Регистрирайте се на сайта на Docker Hub.
3. Влезте в акаунта си, изпълнявайки в терминала следната команда:

   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 виртуална машина, чийто адрес ще изглежда като :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.

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

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

1. Нека стартираме контейнера на приложението sa-logic и да го настроим да слуша на порта 5050:

   docker run -d -p 5050:5000 $DOCKER_USER_ID/sentiment-analysis-logic

2. Нека стартираме контейнера на приложението sa-webapp и да го настроим да слуша на порта 8080. Освен това, трябва да настроим порта, на който Python-приложението ще чака заявки от Java-приложението, преназначавайки променливата на средата SA_LOGIC_API_URL:

   $ docker run -d -p 8080:8080 -e SA_LOGIC_API_URL='http://:5000' $DOCKER_USER_ID/sentiment-analysis-web-app

За да разберете как да откриете IP адреса на контейнера или виртуалната машина Docker — вижте файла README.

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

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

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

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

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

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

Изводи: защо ни е нужен кластер Kubernetes?

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

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