- PVSM.RU - https://www.pvsm.ru -
Сотни контейнеров. Миллионы внешних запросов. Миллиарды внутренних транзакций. Мониторинг и нотификации проблем. Простое масштабирование. 99% up time. Деплои и откатывание релизов.
Kubernetes как решение всех проблем! «Быть или не быть?» — вот в чем вопрос!
Не смотря на публичность данной статьи, скорее всего, я пишу это в первую очередь для себя, как разговор с резиновой уточкой [1]. После более чем двухгодового плавания с «хипстерскими» технологиями, я должен сделать шаг в сторону и адекватно оценить насколько это было обоснованно и будет адекватно для моего любого следующего проекта.
Тем не менее, я очень надеюсь, что эта публикация найдет своего читателя и поможет многим подготовлено подойти к выбору или отказу от Kubernetes.
Я попытаюсь описать весь опыт, полученный нами в `Lazada Express Logistics`, компании являющейся частью `Lazada Group` [2], которая в свою очередь — часть `Alibaba Group` [3]. Мы разрабатываем и осуществляем поддержку систем автоматизирующих по-максимуму весь операционный цикл доставки и фулфилмента в 6 крупнейших странах Юго-восточной Азии.
Однажды представитель компании, продающей облачные решения по всему миру, спросил у меня: «А что для Вас 'облако'?». Помешкав пару секунд (и подумав:«Хммм… наш диалог явно не о взвешенных в атмосфере конденсациях водяного пара...»), я ответил, что, мол, это как будто один сверх-надежный компьютер с неограниченными ресурсами и практически не имеющий накладных расходов на передачу потоков данных(cеть, диск, память, т.д.). Словно это мой лэптоп работающий для всего мира и способный держать такую нагрузку, а я в одиночку способен им управлять.
Собственно зачем нам это облачное чудо? Все в общем-то очень просто! Мы стремимся облегчить жизнь разработчиков, системных администраторов, devops-ов, тех-менеджеров. А такая вещь, как правильно приготовленное облако, многократно облегчает жизнь всем. Да и помимо всего прочего, мономорфные системы работающие на бизнес всегда дешевле и порождают меньше рисков.
Мы задались целью найти простую, удобную и надежную платформу приватного облака для всех наших приложений и для всех типов ролей в команде перечисленных выше. Провели небольшое исследование: Docker, Puppet, Swarm, Mesos, Openshift + Kubernetes, Kubernetes — Openshift… остановились на последнем — Kubernetes безо всяких аддонов.
Функционал описанный на самой первой странице [4] отлично вписывался и годился для всего нашего предприятия. Подробное изучение документации, болтовня с коллегами и небольшой опыт быстрой пробы. Все это дало уверенность, что авторы продукта не врут, и мы сможем получить наше великолепное облако!
Засучили рукава. И понеслось…
Все идет с основ. Для того чтобы создать систему, способную хорошо жить в кластере Kubernetes, вам придется продумать архитектуру и процессы разработки, настроить кучу механизмов и средств доставки, научиться мириться с ограничениями/концепциями мира Docker и изолированных процессов.
Как итог: мы приходим к выводу, что идеология микро-сервисной и сервисно-ориентированной архитектуры как не кстати годится для наших задач. Если вы читали статью Мартина Фаулера [5](перевод [6]) на эту тему, то более-менее должны представлять какой титанический труд должен быть проделан, прежде чем первый сервис оживет.
Мой чек-лист [7] разделяет инфраструктуру на три слоя, а затем примерно описывает то, о чем на каждом из уровней нужно помнить при создании подобных систем. Три слоя о которых идет речь:
Вообще идея 3-х слойной архитектуры и задач связанных с ней — это тема отдельной статьи. Но в свет она выйдет не раньше, чем этот самый чек-лист будет безукоризненно полон. Это может и не случиться никогда :)
Насколько тема приватных облаков актуальна и интересна все больше и больше среднему и крупному бизнесу, настолько же актуален вопрос о квалифицированных архитекторах, devops-ах, разработчиках, администраторах баз данных способных с этим работать.
Причина тому — новые технологии, которые, поступая на рынок, не успевают обрастать нужным объемом документации, обучающих статей и ответов на `Stack Overflow`. Однако, не смотря на это, такие технологии, как в нашем случае, Kubernetes — становятся очень популярными и создают дефицит кадров.
Решение простое — нужно взращивать специалистов внутри компании! Благо, в нашем случае, мы уже знали что такое Docker и как его готовить — остальное пришлось нагонять.
Не смотря на всю прелесть технологии «умного облачного кластера», нам были необходимы средства общения и установки объектов внутрь Kubernetes. Пройдя дорогу от самописного bash скрипта и сотен ветвей логики, мы закончили вполне понятными и читаемыми рецептами для Ansible. Для полноценного превращения Docker файлов в живые объекты нам понадобилось:
По мимо всего прочего мы изучали вопрос о Kubernetes Helm [13]. Но тем не менее, не смогли найти той самой killer-feature, которая могла бы заставить нас отказаться или заменить Ansible шаблонизацию на Helm чарты. Других полезных способностей этого решения мы не смогли найти.
Например, как делать проверку того, что один из объектов успешно установлен и можно продолжить выкатку других? Или как делать более тонкие настройки и установки контейнеров, которые уже работают, и нужно просто выполнить пару команд внутри их?
Эти и многие другие вопросы обязывают относиться к Helm как к простому шаблонизатору. Но зачем это?.. если Jinja2 [14], входящая в состав Ansible, даст фору любому не профильному решению.
Как полноценное решение для любого типа сервисов, включая statefull(имеющие состояние), Kubernetes поставляется с набором драйверов для работы с сетевыми блочными устройствами [15]. В случае с AWS, единственный приемлемый вариант — EBS [16].
Как вы можете убедится, треккер k8s пестрит кучей багов связанных с EBS [17], и решаются они довольно медленно. На сегодня, мы не страдаем от каких-то серьезных проблем, помимо того, что, иногда, для создания объекта с персистентным хранилищем требуется до 20 минут. Интеграция EBS-k8s очень, очень, очень сомнительного качества.
Однако, даже если вы используете другие решения для хранилищ и не испытываете особых проблем, то, все равно, будете нуждаться в качественных решениях для всего, что может хранить данные. Мы потратили уйму времени, чтобы заполнить пробелы и предоставить качественные решения для каждого из случаев:
Помимо всего прочего, Kubernetes, да и Docker мир, в принципе, обязывает, иногда, к множеству хитростей и тонкостей, которые очевидны на первый взгляд, но требуют дополнительного решения.
Небольшой пример.
Собирать логи внутри запущенного Docker контейнера нельзя. НО очень много систем и фреймворков не готовы к стримингу в `STDOUT`. Нужно заниматься `патчингом` и осознанной разработкой на системном уровне: писать в пайпы, заботиться о процессах и т.д. Немного времени и у нас есть Monolog Handler [24] для `php`, который способен выдавать логи так, как их поймет Docker/k8s
Как часть любой микро-сервисной и сервисно-ориентированной архитектуры, вам, скорее всего, понадобится некий шлюз. Но это для архитектуры, здесь же хочу заострить внимание почему это особо важно для кластера и вложенных в него сервисов.
Все довольно просто — нужна единая точка отказа доступа ко всем вашим сервисам.
Есть ряд задач которые мы решали в разрезе Kubernetes кластера:
Искушенный пользователь Kubernetes поспешит спросить о Kubernetes Ingress Resource [27], который предназначен именно для решения подобных задач. Все верно! Но мы требовали немного больше `фич`, как вы могли заметить, для нашего API Gateway чем есть в Ingress. Тем более, это всего лишь обертка для Nginx, с которым мы и так умеем работать.
Несмотря на мириады нюансов и проблем связанных с установкой, использованием и поддержкой представленного выше решения, будучи достаточно упорными, вы скорее всего, придете к успеху и получите, примерно, то, что на сегодняшний день имеем мы.
Что же из себя представляет платформа в текущем состоянии — немного сухих фактов:
Список отражает множество фактов, но опущенными остаются явные преимущества и приятные особенности Kubernetes как системы управления Docker процессами. Подробнее с этими вещами можно ознакомится на оффициальном сайте Kubernetes [31], в статьях на том же Хабре [32] или Medium [33].
Длинный список наших пожеланий, которые находятся на стадии прототипов или пока еще покрывают небольшую часть системы, тоже очень большой:
Опытный читатель, скорее всего, уже догадался, что статья врядли даст однозначный ответ на такой, казалось бы, простой короткий вопрос. Множество деталей и мелочей могут сделают вашу систему безумно крутой и производительной. Или другое множество багов и кривых имплементаций превратят вашу жизнь в ад.
Решать вам! Но мое мнение по поводу всего этого: «БЫТЬ!.. но очень аккуратно»
Автор: Dmitriy Paunin
Источник [38]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/259825
Ссылки в тексте:
[1] разговор с резиновой уточкой: https://en.wikipedia.org/wiki/Rubber_duck_debugging
[2] `Lazada Group`: https://www.lazada.com/
[3] `Alibaba Group`: https://www.alibaba.com/
[4] самой первой странице: https://kubernetes.io/
[5] статью Мартина Фаулера: https://martinfowler.com/articles/microservices.html
[6] перевод: https://habrahabr.ru/post/249183/
[7] чек-лист: https://github.com/paunin/soa-checklist
[8] Team City: https://www.jetbrains.com/teamcity/
[9] Ansible: https://www.ansible.com/
[10] Docker Registry: https://docs.docker.com/registry/
[11] images-builder: https://github.com/paunin/images-builder
[12] Ansible Kubernetes Module: https://github.com/paunin/ansible-kubernetes-module
[13] Kubernetes Helm: https://github.com/kubernetes/helm
[14] Jinja2: http://jinja.pocoo.org/
[15] сетевыми блочными устройствами: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
[16] EBS: https://aws.amazon.com/ebs
[17] кучей багов связанных с EBS: https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20EBS
[18] PostgreSQL кластер: https://github.com/paunin/postgres-docker-cluster
[19] статья на Хабре: https://habrahabr.ru/post/301370/
[20] статья на Medium: https://hackernoon.com/postgresql-cluster-into-kubernetes-cluster-f353cde212de
[21] RabbitMQ кластер: https://github.com/relaxart/k8s-rabbitmq
[22] Redis кластер: https://github.com/relaxart/k8s-redis
[23] Скрипт для бэкапов PostgreSQL : https://github.com/paunin/pg-backupper
[24] Monolog Handler: https://github.com/relaxart/monolog-docker-handler
[25] небольшой LUA скрипт: https://github.com/smacker/gateway-limit
[26] AWS Load Balancer: https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer
[27] Kubernetes Ingress Resource: https://kubernetes.io/docs/concepts/services-networking/ingress/
[28] minikube: https://github.com/kubernetes/minikube
[29] Elastic Search внутри Kubernetes кластера: https://kubernetes.io/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/
[30] Prometheus: https://prometheus.io/docs/operating/configuration/#%3Ckubernetes_sd_config%3E
[31] оффициальном сайте Kubernetes: https://kubernetes.io
[32] Хабре: https://habrahabr.ru/search/?q=kubernetes
[33] Medium: https://medium.com/search?q=kubernetes
[34] zipkin: http://zipkin.io/
[35] машинно обучаемые алгоритмы: https://google.com/search?q=anomaly+detection
[36] интересный пример: https://cobe.io/
[37] Federation mode: https://kubernetes.io/docs/concepts/cluster-administration/federation/
[38] Источник: https://habrahabr.ru/post/332108/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.