Thank you for reading this post, don't forget to subscribe!

1: Раз­вер­ты­ва­ние при­ло­же­ния без Kustomize
2: Раз­вер­ты­ва­ние при­ло­же­ния с помо­щью Kustomize
3: Управ­ле­ние кон­фи­гу­ра­ци­я­ми при­ло­же­ния для раз­ных сред с помо­щью Kustomize

 

Kustomize – это откры­тый инстру­мент управ­ле­ния кон­фи­гу­ра­ци­ей, раз­ра­бо­тан­ный для устра­не­ния подоб­ных про­блем. Начи­ная с вер­сии Kubernetes 1.14, kubectl пол­но­стью под­дер­жи­ва­ет фай­лы Kustomize и kustomization.

1: Развертывание приложения без Kustomize

Преж­де все­го мы попро­бу­ем раз­вер­нуть при­ло­же­ние более тра­ди­ци­он­ным спо­со­бом – без Kustomize. В этом мануа­ле мы исполь­зу­ем раз­ра­ба­ты­ва­е­мую вер­сию my-app – услов­но­го ста­ти­че­ско­го веб-при­ло­же­ния, раз­ме­щен­но­го на Nginx. Хра­нить веб-кон­тент мы будем в виде дан­ных в ConfigMap, кото­рый мон­ти­ру­ет­ся в под внут­ри раз­вер­ты­ва­ния. Для каж­до­го из этих ком­по­нен­тов потре­бу­ет­ся отдель­ный файл YAML, кото­рый мы сей­час создадим.

Сна­ча­ла создай­те новый ката­лог для сво­е­го при­ло­же­ния и всех его кон­фи­гу­ра­ци­он­ных фай­лов. Здесь мы будем запус­кать все коман­ды это­го руководства.

Итак, в сво­ем домаш­нем ката­ло­ге создай­те новую пап­ку и перей­ди­те в нее:

mkdir ~/my-app && cd ~/my-app

Теперь исполь­зуй­те любой тек­сто­вый редак­тор, что­бы создать и открыть файл по име­ни configmap.yml:

nano configmap.yml

Добавь­те в него сле­ду­ю­щий код:

Эта спе­ци­фи­ка­ция создаст новый объ­ект ConfigMap. Мы назва­ли его my-app и сохра­ни­ли в нем неко­то­рый веб-кон­тент в фор­ма­те HTML (внут­ри data).

Сохра­ни­те и закрой­те файл.

Теперь создай­те и открой­те файл по име­ни deployment.yml:

nano deployment.yml

Вставь­те в него следующее:

Эта спе­ци­фи­ка­ция созда­ет новый объ­ект раз­вер­ты­ва­ния (Deployment). Здесь мы опре­де­ли­ли имя и мет­ку my-app, уста­но­ви­ли коли­че­ство реплик (1) и ука­за­ли образ кон­тей­не­ра Nginx вер­сии 1.17, кото­рый нуж­но исполь­зо­вать это­му объ­ек­ту. Кро­ме того, мы уста­но­ви­ли порт кон­тей­не­ра (80), опре­де­ли­ли запро­сы и огра­ни­че­ния для cpu и памя­ти, а так­же уро­вень логи­ро­ва­ния (DEBUG).

Сохра­ни­те и закрой­те файл.

Теперь раз­вер­ни­те эти два фай­ла в кла­сте­ре Kubernetes. Что­бы создать несколь­ко объ­ек­тов из stdin, пере­дай­те коман­ду cat в kubectl:

cat configmap.yml deployment.yml | kubectl apply -f -

Подо­жди­те несколь­ко секунд, а затем исполь­зуй­те kubectl, что­бы про­ве­рить ста­тус приложения:

kubectl get pods -l app=my-app

В резуль­та­те вы уви­ди­те один под с запу­щен­ным при­ло­же­ни­ем и зна­че­ни­ем 1/1 в столб­це READY (оно ука­зы­ва­ет, что у вас есть один кон­тей­нер, и он запущен):

Итак, наш под рабо­та­ет и под­дер­жи­ва­ет­ся раз­вер­ты­ва­ни­ем, но мы по-преж­не­му не можем полу­чить доступ к сво­е­му при­ло­же­нию. Преж­де все­го нуж­но доба­вить сервис.

Создай­те и открой­те тре­тий файл YAML, service.yml:

nano service.yml

Добавь­те в файл сле­ду­ю­щие строки:

Это новый объ­ект – сер­вис по име­ни my-app. Если вы уста­но­ви­те зна­че­ние LoadBalancer в стро­ке spec.type, боль­шин­ство облач­ных про­вай­де­ров выпол­нит оркест­ров­ку балан­си­ров­щи­ка нагруз­ки, что­бы сде­лать ваше при­ло­же­ние доступ­ным в Интер­не­те. Пара­метр spec.ports исполь­зу­ет TCP-порт 80 для любо­го пода с мет­кой my-app.

Сохра­ни­те и закрой­те файл.

Теперь раз­вер­ни­те сер­вис в сво­ем кла­сте­ре Kubernetes:

kubectl apply -f service.yml

Подо­жди­те несколь­ко секунд, а затем вве­ди­те коман­ду kubectl, что­бы про­ве­рить ста­тус приложения:

kubectl get services -w

В ито­ге пуб­лич­ный IP-адрес сер­ви­са появит­ся в столб­це EXTERNAL-IP (вме­сто your_external_ip будет уни­каль­ный IP-адрес):

Ско­пи­руй­те появив­ший­ся IP-адрес, вве­ди­те его в бра­у­зер, и вы уви­ди­те вер­сию DEVELOPMENT ваше­го приложения.

В тер­ми­на­ле нажми­те CTRL+C, что­бы оста­но­вить про­смотр сервисов.

На этом эта­пе мы раз­вер­ну­ли раз­ра­ба­ты­ва­е­мую вер­сию про­сто­го при­ло­же­ния my-app в Kubernetes. В раз­де­лах 2 и 3 мы попро­бу­ем повтор­но раз­вер­нуть эту вер­сию my-app с помо­щью Kustomize, а затем раз­вер­нем про­из­вод­ствен­ную вер­сию с немно­го дру­ги­ми кон­фи­гу­ра­ци­я­ми. Новый рабо­чий про­цесс про­де­мон­стри­ру­ет, насколь­ко хоро­шо Kustomize может управ­лять изме­не­ни­я­ми кон­фи­гу­ра­ции и насколь­ко силь­но он спо­со­бен упро­стить разработку.

2: Развертывание приложения с помощью Kustomize

Итак, сей­час мы раз­вер­нем то же самое при­ло­же­ние, но через Kustomize, а не в стан­дарт­ной мане­ре Kubernetes.

В насто­я­щее вре­мя фай­ло­вая систе­ма про­ек­та выгля­дит так:

Что­бы сде­лать это при­ло­же­ние доступ­ным для раз­вер­ты­ва­ния с помо­щью Kustomize, необ­хо­ди­мо доба­вить один файл, kustomization.yml. Давай­те созда­дим его:

nano kustomization.yml

Как мини­мум, этот файл дол­жен ука­зы­вать, каки­ми ресур­са­ми сле­ду­ет управ­лять при запус­ке коман­ды kubectl с пара­мет­ром –k (кото­рый и напра­вит kubectl на обра­бот­ку фай­ла kustomization).

Добавь­те в файл сле­ду­ю­щий блок конфигураций:

Сохра­ни­те и закрой­те файл.

Перед повтор­ным раз­вер­ты­ва­ни­ем, уда­ли­те суще­ству­ю­щие ресур­сы Kubernetes, кото­рые вы созда­ли в раз­де­ле 1:

kubectl delete deployment/my-app service/my-app configmap/my-app

А затем раз­вер­ни­те их сно­ва, но на этот раз с помо­щью Kustomize:

kubectl apply -k .

Вме­сто опции –f, кото­рая поз­во­ля­ет Kubernetes создать ресур­сы из фай­ла, мы вклю­ча­ем в коман­ду kubectl опцию –k и ката­лог (сим­вол точ­ки обо­зна­ча­ет теку­щий ката­лог). Такая коман­да обра­ща­ет­ся к Kustomize и про­ве­ря­ет файл kustomization.yml ука­зан­но­го каталога.

В резуль­та­те коман­да созда­ет все три ресур­са: ConfigMap, раз­вер­ты­ва­ние и сер­вис. Исполь­зуй­те коман­ду get pods, что­бы про­ве­рить свое развертывание:

kubectl get pods -l app=my-app

Вы сно­ва уви­ди­те один под с запу­щен­ным при­ло­же­ни­ем и 1/1 в столб­це READY (что зна­чит, что ваш един­ствен­ный кон­тей­нер успеш­но запущен).

Сно­ва запу­сти­те коман­ду get services. Вы опять уви­ди­те свой сер­вис и его пуб­лич­ный IP-адрес:

kubectl get services -l app=my-app

Итак, вы исполь­зо­ва­ли Kustomize для управ­ле­ния кон­фи­гу­ра­ци­я­ми Kubernetes, и все про­шло успеш­но. На сле­ду­ю­щем эта­пе мы раз­вер­нем тесто­вое при­ло­же­ние в про­из­вод­ствен­ной сре­де с немно­го дру­гой кон­фи­гу­ра­ци­ей. Затем мы попро­бу­ем исполь­зо­вать Kustomize для управ­ле­ния раз­ны­ми вер­си­я­ми конфигураций.

3: Управление конфигурациями приложения для разных сред с помощью Kustomize

Кон­фи­гу­ра­ци­он­ные фай­лы ресур­сов Kubernetes могут начать раз­рас­тать­ся, как толь­ко вы ста­не­те рабо­тать с несколь­ки­ми типа­ми ресур­сов (осо­бен­но когда меж­ду сре­да­ми раз­ра­бот­ки и про­из­вод­ства есть неболь­шие раз­ли­чия). К при­ме­ру, вме­сто одно­го фай­ла deployment.yml у вас могут появить­ся фай­лы deployment-development.yml и deployment-production.yml. Это может кос­нуть­ся и всех дру­гих ресурсов.

Пред­ставь­те, что может слу­чить­ся, когда вый­дет новая вер­сия Docker-обра­за Nginx и вы захо­ти­те исполь­зо­вать е в сво­ем про­ек­те. Допу­стим, вы про­те­сти­ро­ва­ли новую вер­сию в фай­ле deployment-development.yml и хоти­те внед­рить ее – но забы­ва­е­те обно­вить файл deployment-production.yml. И тогда в сре­де раз­ра­бот­ки и в сре­де про­из­вод­ства исполь­зу­ют­ся две раз­ные вер­сии Nginx. Подоб­ные недо­че­ты и неболь­шие ошиб­ки в кон­фи­гу­ра­ции могут быст­ро сло­мать приложение.

Kustomize может зна­чи­тель­но упро­стить вашу рабо­ту. Давай­те вспом­ним, как теперь выгля­дит фай­ло­вая систе­ма с кон­фи­гу­ра­ци­он­ны­ми фай­ла­ми Kubernetes и kustomization.yml:

Пред­по­ло­жим, теперь вы гото­вы раз­вер­нуть my-app в про­из­вод­ствен­ной сре­де, при­чем рабо­чая вер­сия при­ло­же­ния будет отли­чать­ся от вер­сии раз­ра­бот­ки сле­ду­ю­щим образом:

• Чис­ло реплик в пара­мет­ре replicas уве­ли­чит­ся с 1 до 3.
• Запро­сы (requests) ресур­сов кон­тей­не­ра уве­ли­чат­ся со 100m ЦП и 128М памя­ти до 250m и 256М соответственно.
• огра­ни­че­ния ресур­сов кон­тей­не­ра (limits) уве­ли­чат­ся со 100m ЦП и 256М памя­ти до 1 и 1 ГБ соответственно.
• пере­мен­ная сре­ды LOG_LEVEL будет иметь зна­че­ние не DEBUG, а INFO.
• Дан­ные ConfigMap изме­нят­ся, что­бы пока­зы­вать немно­го дру­гой контент.

Для нача­ла создай­те несколь­ко новых ката­ло­гов, что­бы упо­ря­до­чить все более при­выч­ным для Kustomize способом:

mkdir base

Этот ката­лог будет содер­жать вашу «базо­вую» кон­фи­гу­ра­цию, или base. В дан­ном при­ме­ре это будет раз­ра­ба­ты­ва­е­мая вер­сия my-app.

Теперь пере­ме­сти­те теку­щую кон­фи­гу­ра­цию из my-app/ в этот каталог:

mv configmap.yml deployment.yml service.yml kustomization.yml base/

Затем создай­те новый ката­лог для кон­фи­гу­ра­ции сре­ды про­из­вод­ства. Kustomize назы­ва­ет эти кон­фи­гу­ра­ции overlay. Вос­при­ни­мать overlay сле­ду­ет как слой поверх базо­вой кон­фи­гу­ра­ции – для функ­ци­о­ни­ро­ва­ния overlay все­гда тре­бу­ет­ся база.

mkdir -p overlays/production

Создай­те еще один файл kustomization.yml для опре­де­ле­ния овер­лея сре­ды производства:

nano overlays/production/kustomization.yml

Добавь­те сле­ду­ю­щие кон­фи­гу­ра­ции в файл:

В этом фай­ле будет ука­за­на база для наше­го буду­ще­го овер­лея и стра­те­гия, кото­рую Kubernetes будет исполь­зо­вать для изме­не­ния ресур­сов. В этом при­ме­ре для обнов­ле­ния ресур­сов ConfigMap и Deployment мы исполь­зу­ем патч типа StrategicMerge.

Сохра­ни­те и закрой­те файл.

А теперь добавь­те новые фай­лы deployment.yml и configmap.yml в ката­лог overlays/production/.

Сна­ча­ла создай­те новый файл deployment.yml:

nano overlays/production/deployment.yml

Добавь­те в свой файл сле­ду­ю­щее. Выде­лен­ные раз­де­лы опре­де­ля­ют изме­не­ния в кон­фи­гу­ра­ции разработки:

Обра­ти­те вни­ма­ние на содер­жи­мое это­го ново­го фай­ла deployment.yml. Он вклю­ча­ет толь­ко поля TypeMeta ресур­са, кото­рый изме­нил­ся (в дан­ном слу­чае это раз­вер­ты­ва­ние), и еще несколь­ко полей, что­бы перей­ти во вло­жен­ную струк­ту­ру и ука­зать новое зна­че­ние (напри­мер, для запро­са ресур­сов кон­тей­не­ра и лимитов).

Сохра­ни­те и закрой­те файл.

Теперь создай­те новый файл configmap.yml для ваше­го овер­лея сре­ды производства:

nano /overlays/production/configmap.yml

Добавь­те в файл сле­ду­ю­щий контент:

Здесь мы отра­жа­ем сре­ду PRODUCTION (а не DEVELOPMENT, как было рань­ше). Обра­ти­те вни­ма­ние, мы так­же изме­ни­ли цвет тек­ста с крас­но­го #f22 на синий #22f.

Итак, теперь струк­ту­ра ката­ло­гов выгля­дит так:

 

Все гото­во к раз­вер­ты­ва­нию базо­вой кон­фи­гу­ра­ции. Сна­ча­ла уда­ли­те суще­ству­ю­щие ресурсы:

kubectl delete deployment/my-app service/my-app configmap/my-app

Раз­вер­ни­те базо­вую кон­фи­гу­ра­цию в Kubernetes:

kubectl apply -k base/

Про­верь­те свое развертывание:

kubectl get pods,services -l app=my-app

Вы уви­ди­те свою базо­вую кон­фи­гу­ра­цию с вер­си­ей для раз­ра­бот­ки (как вид­но по EXTERNAL-IP сервиса):

Теперь раз­вер­ни­те кон­фи­гу­ра­цию производства:

kubectl apply -k overlays/production/

Про­верь­те и это развертывание:

kubectl get pods,services -l app=my-app

Вы уви­ди­те вашу кон­фи­гу­ра­цию про­из­вод­ства с соот­вет­ству­ю­щей вер­си­ей, как вид­но по EXTERNAL-IP сервиса:

Обра­ти­те вни­ма­ние, в про­из­вод­ствен­ной кон­фи­гу­ра­ции 3 пода, а не 1. Мож­но про­смот­реть ресурс раз­вер­ты­ва­ния, что­бы убе­дить­ся, что дру­гие, менее оче­вид­ные изме­не­ния так­же всту­пи­ли в силу:

kubectl get deployments -l app=my-app -o yaml

Посе­ти­те your_external_ip в бра­у­зе­ре, что­бы про­смот­реть рабо­чую вер­сию сайта.

Теперь вы зна­е­те, как исполь­зо­вать Kustomize для управ­ле­ния кон­фи­гу­ра­ци­я­ми при­ло­же­ний. Вер­нем­ся к при­ме­ру с новым обра­зом Nginx: если вы захо­ти­те изме­нить вер­сию Nginx в про­ек­те, теперь вам нуж­но будет изме­нить толь­ко deployment.yml в базо­вой кон­фи­гу­ра­ции – и овер­леи, исполь­зу­ю­щие эту базу, под­тя­нут это изме­не­ние через Kustomize. Это зна­чи­тель­но упро­ща­ет про­цесс раз­ра­бот­ки, улуч­ша­ет чита­е­мость кон­фи­гу­ра­ций и сни­жа­ет веро­ят­ность воз­ник­но­ве­ния ошибок.