Главная » Хабрахабр » 10 причин [не] использовать k8s

10 причин [не] использовать k8s

Сегодня мы поговорим про Kubernetes, про грабли, которые можно собрать при его практическом использовании, и про наработки, которые помогли автору и которые должны помочь и вам. Постараемся доказать, что без k8s в современном мире никуда. Противникам k8s также предоставим отличные причины, почему не стоит на него переходить. То есть в рассказе мы будем не только защищать Kubernetes, но и ругать его. Отсюда в названии появилось это [не].

Последние два места работы Ивана так или иначе были связаны с Kubernetes: и в Postmates, и в Machine Zone он работал в инфракомандах, и Kubernetes они затрагивают очень плотно. Эта статья основана на докладе Ивана Глушкова на конференции DevOops 2017. Дальнейшее изложение будет вестись от лица Ивана. Плюс, Иван ведет подкаст DevZen.

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

Например, там будут примеры с конфигами. В этой статье все слайды вставлены как картинки, но иногда хочется что-нибудь скопировать. Слайды в PDF можно скачать по ссылке.

Есть и плюсы, и минусы, поэтому, если вы пришли искать минусы, вы их найдете. Я не буду строго всем говорить: обязательно используйте Kubernetes. Плюсы мне будет помогать показывать Simon Cat, и черная кошка будет перебегать дорогу, когда есть минус. Перед вами выбор, смотреть только на плюсы, только на минусы или в целом смотреть на все вместе.

Kubernetes — это точно такая же система, и существует их гораздо больше, чем одна штука. Итак, почему вообще произошел этот хайп, почему технология Х лучше, чем Y. Мой любимый SSH помогает мне сейчас, зачем мне переходить куда-то. Есть Puppet, Chef, Ansible, Bash+SSH, Terraform. Я считаю, что критериев много, но я выделил самые важные.

Автоматизация сборки, автоматизация всего pipeline — это очень хорошая вещь, нельзя её перехвалить, она на самом деле помогает. Время от коммита до релиза — очень хорошая оценка, и ребята из Express 42 — большие эксперты в этом. И, конечно же, сколько усилий вы потратите на то, чтобы все сделать. Continuous Integration, Continuous Deployment. Все можно написать на Ассемблере, как я говорю, систему деплоймента тоже, но удобства это не добавит.

Я немного коснусь этих областей дальше. Короткую вводную в Kubernetes я рассказывать не буду, вы знаете, что это такое.

Для них важна повторяемость, то есть если они написали какое-то приложение, запустили тест, оно будет работать и у вас, и у соседа, и в продакшне. Почему всё это так важно для разработчиков?

Упрощение процедуры тестирования и Continuous Integration — это не прямое следствие использования Kubernetes, но всё равно это упрощает задачу, поэтому всё становится удобнее. Второе — стандартизированное окружение: если вы изучили Kubernetes и пойдете соседнюю компанию, где есть Kubernetes, там будет всё то же самое.

Во-первых, это иммутабельная инфраструктура. Для релиз-разработчиков гораздо больше плюсов.

В-третьих, идемпотентность, возможность добавить релиз одной кнопкой. Во-вторых, инфраструктура как код, который где-то хранится. Конечно, все это можно сделать и в вашей системе, написанной на коленке, но вы не всегда можете это сделать правильно, а в Kubernetes это уже реализовано. Откаты релизов происходят достаточно быстро, и интроспекция системы достаточно удобная.

Есть много заблуждений на этот счет. Чем Kubernetes не является, и что он не позволяет делать? Kubernetes работает поверх них. Начнем с контейнеров. Их легко объяснить с помощью этого понятия, но на самом деле это неправильно. Контейнеры — не легковесные виртуальные машины, а совсем другая сущность. Он не делает его автоматически скалируемым. Концепция совершенно другая, её надо понять и принять.
Во-вторых, Kubernetes не делает приложение более защищенным.

Будет больно. Нужно сильно постараться, чтобы запустить Kubernetes, не будет так, что «нажал кнопку, и все автоматически заработало».

Мы хотим, чтобы вы и все остальные ничего не ломали.
Наш опыт. Для этого нужно больше смотреть по сторонам — и вот наша сторона.

Когда вы строите структуру, которая будет полностью управлять релизами и деплоями, вы должны понимать, что Kubernetes — один кубик, а таких кубиков должно быть 100. Во-первых, Kubernetes не ходит в одиночку. Новички, которые будут приходить в вашу систему, тоже будут изучать этот стек, огромный объем информации. Чтобы все это построить, нужно все это сильно изучить.

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

Система сложная, нужно много о чем заботиться. Из-за этого Kubernetes'у минус.

Если человек изучил Kubernetes в одной компании, в другой у него не встанут волосы дыбом из-за системы релизов. Но есть и плюсы. И за это — плюс. С течением времени, когда Kubernetes захватит большее пространство, переход людей и обучение будет более простым.

Это система, которая строится поверх Kubernetes, напоминает пакетный менеджер. Мы используем Helm. Можно устанавливать и в Kubernetes. Вы можете нажать кнопку, сказать, что хотите установить *Wine* в свою систему. Он позволяет работать с плагинами, клиент-серверная архитектура. Оно работает, автоматически скачает, запустит, и все будет работать. Это изолирует namespace друг от друга, и поломка одного не приведет к поломке другого. Если вы будете с ним работать, рекомендуем запускать один Tiller на namespace.

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

Скорее всего, у вас тоже есть какие-то конфиги, если вы запускаете в продакшне вашу систему. Давайте сравним конфиги. Я не знаю, почему мы ее так назвали. У нас есть своя система, которая называется BOOMer. Она состоит из Puppet, Chef, Ansible, Terraform и всего остального, там большой флакон.

Вот пример реальной конфигурации, которая сейчас работает в продакшне. Давайте посмотрим, как оно работает. Что мы здесь видим?

В одном флаконе уже смешаны концепции. Во-первых, мы видим, где запускать приложение, во-вторых, что надо запускать, и, в-третьих, как это надо подготовить к запуску.

Плюс, мы добавляем настройку сетей, прав доступа, планирование нагрузки. Если мы посмотрим дальше, из-за того, что мы добавили наследование, чтобы сделать более сложные конфиги, мы должны посмотреть на то, что находится в конфиге common, на который ссылаемся. Все это в одном конфиге, который нам нужен для того, чтобы запустить реальное приложение в продакшне, мы смешиваем кучу концепций в одном месте.

Настройка сети была выполнена при установке Kubernetes, настройка всего provisioning решается с помощью докера — у вас произошла инкапсуляция, все проблемы каким-то образом разделились, и в данном случае в конфиге есть только ваше приложение, и за это плюс. Это очень сложно, это очень неправильно, и в этом огромный плюс Kubernetes, потому что в нем вы просто определяете, что запустить.

Здесь у нас есть только одно приложение. Давайте посмотрим внимательнее. Во-первых, нужно определить сервисы. Чтобы заработал деплоймент, нужно, чтобы работала еще куча всего. Каким образом к нам поступают секреты, ConfigMap, доступ к Load Balancer.

Есть Stage/Prod/Dev. Не стоит забывать, что у вас есть несколько окружений. За это минус. Это все вместе составляет не маленький кусочек, который я показал, а огромный набор конфигов, что на самом деле сложно.

Он полностью повторяет шаблоны Kubernetes, если есть какой-то файл в Kubernetes с определением деплоймента, то же самое будет в Helm. Helm-шаблон для сравнения. Вместо конкретных значений для окружения у вас есть шаблоны, которые подставляются из values.
У вас есть отдельно шаблон, отдельно значения, которые должны подставиться в этот шаблон.

Это все очень непросто, за что минус. Конечно, нужно дополнительно определить различную инфраструктуру самого Helm, притом что у вас в Kubernetes масса конфигурационных файлов, которые нужно перетащить в Helm.

Для меня это явный минус. Система, которая должна упрощать, на самом деле усложняет. Либо нужно надстраивать что-то еще, либо не использовать

Давайте пойдем поглубже, мы недостаточно глубоко.

Я прочитал статью Гугла «Borg, Omega и Kubernetes», в ней очень сильно защищают концепцию, что нужно иметь один большой кластер. Во-первых, как мы работаем с кластерами. В результате наших споров, используем четыре разных кластера. Я тоже был за эту идею, но, в конце концов, мы от неё ушли.

Второй, конечно же, prod и stage. Первый кластер e2e, для тестирования самого Kubernetes и тестирования скриптов, разворачивающих окружение, плагины и так далее. В-третьих, это admin, в котором сгрузилось все остальное — в частности, у нас там CI, и, похоже, из-за него этот кластер будет самым большим всегда. Это стандартные концепции.

Тестирований очень много: по коммиту, по merge, все делают кучу коммитов, поэтому кластеры просто громадные.

У них внутри TF или CloudFormation, и то и другое очень плохо позволяет понимать, что находится внутри state. Мы пытались посмотреть на CoreOS, но не стали ее использовать. Когда вы хотите обновить настройки вашего Kubernetes, к примеру, его версию, можно столкнуться с тем, что обновление происходит не таким образом, не в той последовательности. Из-за этого возникают проблемы при обновлении. Это минус. Это большая проблема стабильности.

Это может быть внутренний источник, репозиторий, или внешний. Во-вторых, когда вы используете Kubernetes, нужно откуда-то скачивать образы. Я рекомендую использовать Docker Distribution, потому что она стабильная, её сделал Docker. Если внутренний, есть свои проблемы. Чтобы она работала, нужно сделать ее отказоустойчивой, потому что это единственное место, откуда ваши приложения получают данные для работы. Но цена поддержки все равно высокая.

Вы должны сделать его отказоустойчивым, причем от всех возможных проблем, которые только могут быть. Представьте, что в самый ответственный момент, когда вы нашли баг на продакшне, у вас репозиторий упал — приложение обновить вы не сможете.

Можно убить свой Docker Distribution. Во-вторых, если масса команд, у каждой свой образ, их накапливается очень много и очень быстро. Нужно делать чистку, удалять образы, выносить информацию для пользователей, когда и что вы будете чистить.

Представьте, что нужно зарелизить на 30 нод. В-третьих, при больших образах, скажем, если у вас есть монолит, размер образа будет очень большим. Хотелось бы, чтобы нажал кнопку, и тут же зарелизилось. 2 гигабайта на 30 нод — посчитайте, какой поток, как быстро он скачается на все ноды. Надо как-то ускорять эту закачку, а все это работает с одной точки. Но нет, нужно сначала дождаться, пока закачается.

Мы используем Quay. При внешних репозиториях есть те же проблемы с garbage collector, но чаще всего это делается автоматически. Чтобы не было публичных образов, нужно обеспечивать доступ. В случае с внешними репозиториями — это сторонние сервисы, в которых большинство образов публичные. Конечно, это можно автоматизировать, но в случае локального запуска Куба на своей системе вам все равно его придется настраивать. Нужны секреты, права доступа к образам, все это специально настраивать.

Это очень хорошая система, мы ранние пользователи с тех времен, когда они еще в блоге не писали. Для установки Kubernetes мы используем kops. Отличная система! Она не до конца поддерживает CoreOS, хорошо работает с Debian, умеет автоматически конфигурировать мастер-ноды Kubernetes, работает с аддонами, есть способность делать нулевое время простоя во время обновления Kubernetes.
Все эти возможности из коробки, за что большой и жирный плюс.

Их реально много, у всех свои достоинства и недостатки. По ссылкам можно найти много вариантов для настройки сети в Kubernetes. Можно, конечно, донастроить, чтобы работал через CNI, но лучше использовать самые популярные и стандартные. Kops поддерживает только часть из этих вариантов. Они тестируются сообществом, и, скорее всего, стабильны.

Он заработал хорошо с нуля, без большого количества проблем, использует BGP, быстрее инкапсуляции, поддерживает IP-in-IP, позволяет работать с мультиклаудами, для нас это большой плюс.
Хорошая интеграция с Kubernetes, с помощью меток разграничивает трафик. Мы решили использовать Calico. За это — плюс.

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

Сидим на etcd v2, из-за бага не обновлялись на v3. High Availability, как я говорил, мы делаем через kops, можно использовать 5-7-9 нод, мы используем три. Я не знаю, сомневаюсь. Теоретически, это позволит ускорить какие-то процессы.

Мы считаем, что у нас есть защита от совершенно неправильных действий, но для каких-то специальных и сложных релизов мы на всякий случаем делаем снапшоты всех дисков, мы не делаем бэкапов каждый день. Хитрый момент, у нас есть специальный кластер для экспериментов со скриптами, автоматическая накатка через CI.

Мы в Kubernetes используем RBAC — доступ, основанный на ролях. Авторизация — вечный вопрос. Посмотрите на конфиги — удивитесь.
Мы используем Dex, провайдер OpenID, который из какого-то источника данных выкачивает всю информацию.
А для того, чтобы залогиниться в Kubernetes, есть два пути. Он намного лучше ABAC, и если вы его настраивали, то понимаете, о чем я. Нужно этот конфиг как-то получить. Нужно как-то прописать в .kube/config, куда идти и что он может делать. Это не очень удобно. Либо пользователь идет в UI, где он логинится, получает конфиги, копипастит их в /config и работает. Так гораздо удобнее, мы решили действовать таким образом. Мы постепенно перешли к тому, что человек заходит в консоль, нажимает на кнопку, логинится, у него автоматически генерируются конфиги и складываются в нужное место.

Kubernetes позволяет через всю структуру авторизации протащить информацию о группе, которая транслируется в namespace и роли. В качестве источника данных мы используем Active Directory. Таким образом сразу разграничиваем, куда человек может заходить, куда не имеет права заходить и что он может релизить.

Если у вас нет Kubernetes, есть машина с запущенным приложением. Чаще всего людям нужен доступ к AWS. Это удобно, когда человек может зайти на свою машину и посмотреть, как работает приложение. Казалось бы, все что нужно — получать логи, смотри их и все. Есть команда `kubectl exec` — залезть в контейнер в приложение и посмотреть, что там происходит. С точки зрения Kubernetes все работает в контейнерах. Мы запретили доступ для всех, кроме инфракоманды. Поэтому на AWS-инстансы нет необходимости ходить.

Если есть возможность использовать роль админа — я админ. Более того, мы запретили долгоиграющие админские ключи, вход через роли. Это удобно конфигурировать через команду awsudo, это проект на гитхабе, очень рекомендую, позволяет работать, как с sudo-командой. Плюс мы добавили ротацию ключей.

Очень хорошая штука в Kubernetes, работает прямо из коробки. Квоты. Я считаю, что это важно и полезно всем. Вы ограничиваете какие-то namespace, скажем, по количеству объектов, памяти или CPU, которое можете потреблять. Мы пока не дошли до памяти и CPU, используем только по количеству объектов, но это все добавим.

Большой и жирный плюс, позволяет сделать много хитрых вещей.

Нельзя смешивать масштабирование внутри Kubernetes и снаружи Kubernetes. Масштабирование. Он может увеличивать pod'ы автоматически, когда идет большая нагрузка. Внутри Kubernetes делает масштабирование сам.

Это можно делать с помощью AWS Autoscaler, это проект на гитхабе. Здесь я говорю про масштабирование самих инстансов Kubernetes. Позволяет работать на Spot-инстансах, мы пока это не добавляли, но будем, позволяет сильно экономить. Когда вы добавляете новый pod и он не может стартовать, потому что ему не хватает ресурсов на всех инстансах, AWS Autoscaler автоматически может добавить ноды.

Обычно это телеметрия, логи, какие-то красивые графики. Когда у вас очень много пользователей и приложений у пользователей, нужно как-то за ними следить.

Нужен было более метрикоориентированный проект. У нас по историческим причинам был Sensu, он не очень подошел для Kubernetes. Хороший UI, SQL-подобный язык, но не хватило немножко фич. Мы посмотрели на весь TICK стек, особенно InfluxDB. Мы перешли на Prometheus.

Хороший язык запросов, хорошие алерты, и все из коробки. Он хорош.

Это наш собственный проект, написанный на Rust. Чтобы посылать телеметрию, мы использовали Cernan. У него есть несколько концепций: есть концепция источника данных, вы конфигурируете несколько источников. Это единственный проект на Rust, который уже год работает в нашем продакшне. У нас есть конфигурация фильтров, то есть перетекающие данные можно каким-то образом перерабатывать. Вы конфигурируете, куда данные будете сливать. Вы можете преобразовывать логи в метрики, метрики в логи, все, что хотите.
При том, что у вас несколько входов, несколько выводов, и вы показываете, что куда идет, там что-то вроде большой системы графов, получается довольно удобно.

Теоретически, Prometheus хочет сам забирать данные из приложений, поэтому во все приложения нужно добавлять endpoint, из которого он будет забирать метрики. Мы сейчас плавно переходим с текущего стека Statsd/Cernan/Wavefront на Kubernetes. Тут две возможности: запускать на каждом инстансе Kubernetes, можно с помощью Sidecar-концепции, когда в вашем поле данных работает еще один контейнер, который посылает данные. Cernan является передаточным звеном, должен работать везде. Мы делаем и так, и так.

Все приложения рассчитаны на это, поэтому одно из критических требований, чтобы мы не уходили от этой системы.
У нас прямо сейчас все логи шлются в stdout/stderr. Это очень хорошая система, рекомендую. Cernan посылает данные в ElasticSearch, события всей системы Kubernetes посылают туда же с помощью Heapster.

Мы используем Kibana. После этого все логи вы можете посмотреть в одном месте, к примеру, в консоли. Он позволяет смотреть, раскрашивает в разные цвета разные поды, умеет видеть, когда один под умер, а другой рестартовал. Есть замечательный продукт Stern, как раз для логов. Идеальный проект, очень его рекомендую, это жирный плюс Kubernetes, здесь все хорошо. Автоматически подхватывает все логи.

Мы используем S3 и KMS. Секреты. Они были в 1. Думаем о переходе на Vault или секреты в самом Kubernetes. 7 в состоянии альфы, но что-то делать с этим надо.

Разработка в Kubernetes вообще мало рассматривается. Мы добрались до интересного. В основном говорится: «Kubernetes — идеальная система, в ней все хорошо, давайте, переходите».
Но на самом деле бесплатный сыр только в мышеловке, а для разработчиков в Kubernetes — ад.

Я разработку в Kubernetes сравниваю с функциональным программированием: пока ты его не коснулся, ты думаешь в своем императивном стиле, все хорошо. Не с той точки зрения, что все плохо, а с той, что надо немножко по-другому взглянуть на вещи. Для того, чтобы разрабатывать в функциональщине, надо немножко повернуть голову другим боком — здесь то же самое.

Во-первых, разобраться с концепцией Docker Way. Разрабатывать можно, можно хорошо, но нужно смотреть на это иначе. Большинство разработчиков привыкло, что они заходят на свою локальную, удаленную или виртуальную машину по SSH, говорят: «Давай я тут кое-что подправлю, подшаманю». Это не то чтобы сложно, но до конца ее понять довольно проблематично.

Когда ты хочешь обновить приложение, пожалуйста, сделай новый образ, который будет работать, а старый, пожалуйста, не трогай, он просто умрет. Ты говоришь ему, что в Kubernetes так не будет, потому что у тебя read only инфраструра. Я лично работал над внедрением Kubernetes в разные команды и вижу ужас в глазах людей, когда они понимают, что все старые привычки придется полностью отбросить, придумать новые, новую систему какую-то, а это очень сложно.

Монтировать каким-то образом папку, заходить туда, обновлять систему, хотя бы компилировать. Плюс придется много делать выборов: скажем, когда делаешь какие-то изменения, если разработка локальная, нужно как-то коммитить в репозиторий, затем репозиторий по pipeline прогоняет тесты, а потом говорит: «Ой, тут опечатка в одном слове», нужно все делать локально. Эти выборы достаточно сложные. Если тесты запускать локально неудобно, то может коммитить в CI хотя бы, чтобы проверять какие-то локальные действия, а затем уже отправлять их в CI на проверку.

Нужно либо эмулировать окружение, либо как-то запускать локально. Особенно сложно, когда у вас развесистое приложение, состоящее из ста сервисов, а чтобы работал один из них, нужно обеспечить работу всех остальных рядышком. Из-за этого возникает негативное отношение к Kubernetes. Весь этот выбор нетривиальный, разработчику об этом нужно сильно думать. Он, конечно, хорош — но он плох, потому что нужно много думать и изменять свои привычки.
Поэтому здесь три жирных кошки перебежали через дорогу.

В частности, есть такая вещь, как Deis, наверняка вы все про нее слышали. Когда мы смотрели на Kubernetes, старались понять, может, есть какие-то удобные системы для разработки. Но проблема в том, что более сложные проекты могут на Deis не перейти. Она очень проста в использовании, и мы проверили, на самом деле, все простые проекты очень легко переходят на Deis.

Но единственная проблема, которую мы сейчас видим — нужно очень много хорошей документации. Как я уже рассказал, мы перешли на Helm Charts. Это тоже важно понимать заранее, и нужно это все делать. Нужны какие-то How-to, какие-то FAQ, чтобы человеку быстро стартовать, скопировать текущие конфиги, вставить свои, поменять названия для того, чтобы все было правильно. У меня здесь перечислены общие наборы инструментов для разработки, всего этого не коснусь, кроме миникуба.

Она позволяет запускать Kubernetes локально, позволяет видеть все на вашем лэптопе, не надо никуда ходить по SSH и так далее.
Minikube — очень хорошая система, в том смысле, что хорошо, что она есть, но плохо, что в таком виде.

Это сделать никак нельзя. Я работаю на MacOS, у меня Mac, соответственно, чтобы запускать локальный апп, мне нужно запускать локально докер. Обе вещи, фактически, эмуляции поверх моей операционной системы. В итоге нужно либо запускать virtualbox, либо xhyve. Мы используем xhyve, но рекомендуем использовать VirtualBox, поскольку очень много багов, их приходится обходить.

В целом, хорошо, что он как-то работает, но лучше бы его еще доделали. Но сама идея, что есть виртуализации, а внутри виртуализации запускается еще один уровень абстракции для виртуализации, какая-то нелепая, бредовая.

Мы использовали Concourse для CI, очень богатая функциональность, можно строить страшные графы, что, откуда, как запускается, от чего зависит. CI не относится напрямую к Kubernetes, но это очень важная система, особенно, если у вас есть Kubernetes, если ее интегрировать, можно получать очень хорошие результаты. Скажем, при переходе от одной версии на другую они поломали обратную совместимость и большинство плагинов не переписали. Но разработчики Concourse очень странно относятся к своему продукту. Более того, документацию не дописали, и, когда мы попытались что-то сделать, вообще ничего не заработало.

Перешли на Drone.io — он маленький, очень легкий, юркий, функциональности намного меньше, но чаще всего ее хватает. Документации мало вообще во всех CI, приходится читать код, и, в общем, мы отказались от Concourse. Тоже мало документации, читаем код, но это ок. Да, большие и увесистые графы зависимости — было бы удобно иметь, но и на маленьких тоже можно работать.

Если есть приложение, которое работает на реальной машине, для того, чтобы добавить в CI, используете докер-контейнер, а после него перейти в Kubernetes проще простого.
У нас настроен автоматический релиз admin/stage-кластера, в продакшн-кластер пока боимся добавлять настройку. Каждая стадия pipeline работает в своем докер-контейнере, это позволяет сильно упростить переход на Kubernetes. Плюс есть система плагинов.

Взято из готовой рабочей системы, в данном случае есть пять шагов в pipeline, каждый шаг что-то делает: собирает, тестирует и так далее. Это пример простого Drone-конфига. При том наборе фич, что есть в Drone, я считаю, что это хорошая штука.

Когда мы пришли к идее с несколькими кластерами, начали дальше работать в этом направлении, создали какие-то скрипты, понаставили кучу других кубиков к нашему Kubernetes. Мы много спорили о том, сколько иметь кластеров: один или несколько. После этого пришли к Google и попросили консультации, все ли сделали так, может, нужно что-то исправить.

Есть много недоделок, в частности, работа с геолокациями. Google согласился, что идея одного кластера неприменима в Kubernetes. Возможно, попозже. Получается, что идея верна, но говорить о ней пока рано. Пока может помочь Service Mesh.

Это продукт, похожий на тот, что делаем мы. В целом, если хотите посмотреть, как работает наша система, обратите внимание на Geodesic. Мы думаем о том, чтобы объединиться и, возможно, использовать их. Он с открытыми исходниками, очень похожий выбор концепции дизайна.

Да, в нашей практике работы с Kubernetes тоже есть проблемы.

Есть проблема с загрузками больших образов и их работой, возможно, связанная с файловой системой, мы туда еще не копали. Есть боль с локальными именами, с сертификатами. Мы меньше года работаем над этим проектом, и у нас уже три разных способа, годовые кольца растут. Есть уже три разных способа устанавливать расширения Kubernetes.

Давайте подобьем все минусы.

Это как новый язык выучить: в принципе, несложно, но сложно немного повернуть голову всем пользователям. Итак, я считаю, что один из главных минусов — большой объем информации на изучение, причем не только новых технологий, но и новых концепций и привычек. Если раньше не работали с подобными концепциями — перейти на Kubernetes тяжело.

Все думают, что установят Kubernetes, и всё сразу заработает. Kubernetes будет лишь небольшой частью вашей системы. Нет, это маленький кубик, и таких кубиков будет много.

Также очень тяжелые и большие конфигурационные файлы, и в концепциях поверх Kubernetes они ещё сложнее. Некоторые приложения в принципе сложно запускать на Kubernetes — и лучше не запускать. Все текущие решения — сырые.

Все эти минусы, конечно, отвратительные.

Мы не смогли сильно побороть, есть люди, которые ненавидят все это движение, не хотят и не понимают его плюсы.
Для того, чтобы запустить Minikube, вашу систему, чтобы все работало, придется сильно постараться. Компромиссы и сложный переход создают негативный образ Kubernetes, и как с этим бороться — я не знаю. Если не хотите слышать про плюсы — закройте глаза и уши, потому что дальше пойдут они. Как вы видите, минусов немало, и те, кто не хочет работать с Kubernetes имеют свои причины.

Часто бывает так, что, придя в систему, новичок начинает вырывать все волосы, потому что первые 1-2 месяца он пытается разобраться, как это все зарелизить, если система большая и живет долго, наросло много годовых колец. Первый плюс — с течением времени придется все меньше учить новичков. В Kubernetes все будет проще.

Коммит создал CI, CI создал образ, автоматически подкачался, ты нажал кнопку, и все ушло в продакшн. Во-вторых, Kubernetes не сам делает, но позволяет сделать, короткий цикл релиза. Это сильно сокращает время релиза.

Наша система и большинство ваших систем в одном месте собирают конфиги разных уровней, то есть у вас инфраструктурный код, бизнес код, все логики смешаны в одном месте. Следующее — разделение кода. Большинство из того, о чем я упоминал, за последние два года стало настолько стабильным, что их можно выпускать в продакшн. В Kubernetes такого не будет из коробки, выбор правильной концепции помогает этого избежать заранее.
Большое и очень активное сообщество, а значит, большое количество изменений. Возможно, часть из них появилась пораньше, но была не очень стабильной.

И нет доступа на ноды. Я считаю большим плюсом, что в одном месте можно видеть как логи приложения, так и логи работы Kubernetes с вашим приложением, что неоценимо. Когда мы убрали у пользователей доступы на ноды, это сразу срезало большой класс проблем.

Большая часть сообщества Kubernetes видят технологическую часть. Вторая часть плюсов немного более концептуальна. После того, как вы перейдете на Kubernetes, и если это все правильно настроить, инфракоманда (или бэкенд — я не знаю, как у вас это называется правильно) больше не нужна для того, чтобы релизить приложения. Но мы увидели концептуальную менеджмент-часть.

Инфракоманда не нужна для того, чтобы расследовать проблемы. Пользователь хочет зарелизить приложение, он не придет с просьбой об этом, а просто запустит новый pod, есть команда для этого. Да, иногда нужна поддержка, если проблема в Kubernetes, в инстансах, но чаще всего проблема с приложениями. Достаточно посмотреть логи, у нас набор конструкций не такой большой, есть список, по которому найти проблему очень легко.

Это следующая концепция: у каждой команды есть статистика, сколько происходит проблем в продакшне. Мы добавили Error Budget. Это хорошо тем, что команда будет серьезно следить, чтобы их релизы были очень стабильными. Если проблем происходит слишком много, команде режут релизы, пока не пройдет какое-то время. Хотите релизить в два часа ночи — пожалуйста. Нужна новая функциональность — пожалуйста, релизьте. Однако, если ситуация хуже, скорее всего, мы не разрешим релизить ничего, кроме фиксов. Если после релизов у вас в SLA одни «девятки» — делайте, что хотите, все стабильно, можете делать что угодно.

Мы перестаем быть «Полицией Нравов», не давая релизить поздно вечером. Это удобная вещь как для стабильности системы, так и для настроя внутри команды. Это сильно сокращает напряжение внутри компании. Делайте, что хотите, пока у вас хороший бюджет ошибок.

Для связи со мной можно использовать почту или написать в Твиттере: @gliush.

И в конце для вас куча ссылок, можете сами всё скачать и посмотреть:

  1. Container-Native Networking — Comparison
  2. Continuous Delivery by Jez Humble, David Farley.  
  3. Containers are not VMs 
  4. Docker Distribution (image registry) 
  5.  Quay — Image Registry as a Service 
  6. etcd-operator — Manager of etcd cluster atop Kubernetes 
  7. Dex - OpenID Connect Identity (OIDC) and OAuth 2.0 Provider with Pluggable Connectors 
  8. awsudo - sudo-like utility to manage AWS credentials 
  9. Autoscaling-related components for Kubernetes 
  10.  Simon’s cat 
  11. Helm: Kubernetes package manager 
  12. Geodesic: framework to create your own cloud platform 
  13. Calico: Configuring IP-in-IP 
  14. Sensu: Open-core monitoring system 
  15. InfluxDB: Scalable datastore for metrics, events, and real-time analytics 
  16. Cernan: Telemetry and logging aggregation server 
  17. Prometheus: Open Source monitoring solution 
  18. Heapster: Compute Resource Usage Analysis and Monitoring of Container Clusters 
  19. Stern: Multi pod and container log tailing for Kubernetes 
  20. Minikube: tool to run Kubernetes locally 
  21. Docker machine driver fox xhyve native OS X Hypervisor 
  22. Drone: Continuous Delivery platform built on Docker, written in Go 
  23. Borg, Omega and Kubernetes 
  24. Container-Native Networking — Comparison 
  25. Bug in minikube when working with xhyve driver.  

Если вам понравился этот доклад с конференции DevOops — обратите внимание, что 14 октября в Санкт-Петербурге пройдет новый DevOops 2018, в его программе тоже будет много интересного. Минутка рекламы. На сайте уже есть первые спикеры и доклады.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Создатели ботнета Mirai теперь сражаются с преступностью на стороне ФБР

Три подзащитных студента, стоявшие за ботнетом Mirai – онлайн-инструментом, учинившим разрушения по всему интернету осенью 2016 при помощи мощнейших распределённых атак на отказ от обслуживания – в четверг предстанут перед судом на Аляске и попросят судью вынести новый приговор: они ...

[Из песочницы] RESS — Новая архитектура для мобильных приложений

Вопреки провокационному заголовку, это никакая не новая архитектура, а попытка перевода простых и проверенных временем практик на новояз, на котором говорит современное Android-комьюнити Введение В последнее время стало больно смотреть на то, что творится в мире разработки под мобильные платформы. ...