Кажется, тема «зачем нужен Kubernetes», уже раздражает. Хочется сказать: «все кому надо — давно уже поняли», однако я разделил бы технических (и околотехнических) работников на тех, кто «понял и знает как использовать», и тех, кто «понял, но хочет знать, как сделать знания актуальными».
Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.
Почему я считаю важным уметь менять парадигму технологического мышления?
Самая сложная вещь для тех, кто давно работает в технологиях, — принять, что новый тренд стал постоянным. За 20 лет работы я видел, как приходили и уходили разные технологии, причем некоторые из них были «суперактуальны» целых несколько месяцев.
Я читал Джоэля Спольски про то, как Microsoft систематически придумывает новый стек для разработчиков для того, чтобы в целом не дать им возможность посмотреть на что-то иное. Как SRE, я вдвойне опасался каждой новой технологии: всё новое — сырое, всё сырое — нестабильное. Ну, а всё нестабильное приведёт к проблемам в продакшне, а стабильность продакшна — это главное.
Как программист и предприниматель, я хотел создавать продукт быстрее — всё новое надо изучать, изменять привычные подходы, а это значит — медленнее выкатывать фичи. Если какие-то новые технологии принимались быстро, то все связанное с микросервисно-ориентированной разработкой (давайте так назовем весь современный стек) нужно было учить. И с каждым годом учить все дольше; гораздо проще писать старым привычным методом и доставлять продукт быстрее.
Но факт остается фактом: иногда новые технологии остаются и меняют всю парадигму целиком. И тут возникает выбор: оставаться в старой парадигме или переходить в новую. Cobol-программисты до сих пор могут устроиться на работу, perl-разработчики помнят про booking, но альтернативных путей для этих людей становится всё меньше и меньше. И тогда «ретроградство» во имя стабильности становится ограничением. Со всем современным стеком, если вы не хотите себя ограничивать, время уже не то, что пришло, а мы уже отстаем. И, если мы не хотим застрять в «perl»-е, надо учиться. Это занимает продолжительное время. Попробую рассказать свой пошаговый опыт в обучении.
Поймите, как запускать приложения в докере. Прежде всего, ветеранам стоит понять, что способ «хранения» и «запуска» приложений изменился навсегда. Скорее всего, разработчик, который научился разработке в последние годы, вообще не представляет себе, как запускать приложение в продакшне без докера. В голове такого разработчика, вероятно, нет концепции «хранить файлы локально», кроме редких кейсов общего хранилища, но главное, что нужно понять «ветерану»: докер — это новый exe. У exe-формата, может быть, есть свои минусы, но никто уже об этом особо не думает.
Да, микросервисный подход стал стандартом. Как когда-то ООП появилось для того, чтобы большим командам стало проще писать большой софт; теперь таким же стандартом стали микросервисы. Их даже те же люди культивируют (см. Фаулера). Это разумно: при соблюдении версионности API приложения отдельным командам проще писать самостоятельные приложения, чем одно большое. Зачем и маленькие приложения писать микросервисно, можно поспорить, но и их в какой-то момент все стали писать в ООП-стиле— просто так привычно (см. выше про exe). Можно много рассуждать о том, что у межпроцессной коммуникации (особенно, построенной на TCP-стеке) существует миллион недостатков с точки зрения производительности (один сервис пойдет к другому по TCP вместо того, чтобы просто выполнить ассемблерный-call — вы представляете какая это разница в производительности?), но факт остается фактом — у микросервисов есть достоинства скорости разработки средних и больших проектов и они также стали стандартом. Поймите, как микросервисы между собой взаимодействуют (HTTP API, grpc, асинхронное взаимодействие через очередь — миллион способов), бонусом — поймите, что такое service mesh. (Минута гневного юмора: боже, ребята, они придумали разделить приложение, и оказалось, что коммуникация между разделенными приложениями — сложная шутка, поэтому они добавили еще один слой, чтобы облегчить межпроцессный ужас, за что это нам?)
Поймите, как управлять пачкой запущенных в докерах микросервисов. Итак, мы смирились, что приложения мы теперь запускаем в докере и что приложение мы разделяем на микросервисы. Теперь надо как-то управлять запущенными докерами. Можно делать это самому на выделенных серверах (и рулить, например Docker Swarm-ом, ну или собрать Kubernetes), а можно использовать сервисы, которые дают облака — контейнер-сервисы от AWS или Kubernetes. В использовании облаков есть одно очень большое преимущество. Вы, фактически, перестаете думать про слой, запущенный ниже менеджера контейнеров (SRE сейчас посмеются, но давайте признаемся — когда все стабильно, мы не лазим на ноды GKE руками в большинстве случаев). Таким образом, фактически, менеджер контейнеров, стандартом которого стал Kubernetes, превращается в операционную систему. В нём есть пакет-менеджеры, в него можно «ставить софт», в нём можно запускать «exe-шники» — докеры, в нём есть кронджобы. Kubernetes — это новая ОС.
Разберитесь, как докер-контейнеры надо будет доставлять. Выкладка простого сайта теперь занимает 5 минут, и люди считают это нормой. Надо собрать докер, протестировать, положить в registry и поместить в менеджер докеров (давайте будем говорить дальше Kubernetes). Это дикость (?), к которой все привыкли, это оптимизируется и это стандарт. CI/CD системы стали стандартом выкладки, и с ними надо разобраться. Также как и с GitOps.
Поймите, что on-premise хостинг для большинства приложений уйдет (на Западе — уже ушел) в прошлое. Когда-то давно нормой было купить серверы, собрать их, привезти в ДЦ, поставить в колокейшн и скоммутировать. Даже для небольшого проекта. Потом на смену пришли Dedicated-серверы. Какому количеству людей приходит сейчас в голову на небольших и средних проектах мучаться, покупать и собирать железо? На смену Dedicated — на Западе уже сейчас, а в РФ скоро — придут облака. Об этом говорят сто лет, я использую AWS с 2008 года, и у него есть проблемы, но когда мы говорим о сервисе, который берёт на себя менеджмент Kubernetes (EKS, GKE, Kubernetes от Яндекса или Селектела), мне становится непонятно, зачем менеджить сам Kubernetes и дедики, если это делают другие ребята? Я же не меняю кулеры в дедиках больше… Вопрос распространенности on-premise дистрибуций Kubernetes в РФ — это вопрос курса доллара, закона о персданных и «молодости» российского клауд-хостинга. Рано или поздно это решится и on-premise станет дикостью, которую хотят энтерпрайзы и большие нагруженные проекты. С базами то же самое. Если мы говорим о большинстве приложений, которым не требуется супервысокая нагрузка или супермощный тюнинг, то облачный PostreSQL/MongoDB/MySQL дает огромное количество преимуществ. Не надо думать про тюнинг, не надо думать про бэкапы. Создать дев-сервер из продакшн-сервера — пара команд в облачной консоли. Я понимаю, что вся эта идея может вызывать гнев у админа: ребята, я и сам админ, но для большинства нехайлоад задач менеджмент баз, правда, не нужен. Возможно, AWS и GKE стоят дорого и недоступны нам из-за закона о персданных, но это лишь дополнительное время для отставания: рано или поздно те же фичи будут у Яндекса или Селектела, и парадигма сменится.
Поймите, что инфраструктуру теперь пишут. Я не любил IaaC, когда он был Chef-ом и Puppet-ом, но на смену им, слава богу, пришли более адекватные Terraform и Pulumi для описания того, что вы хотите поднять в кластере, и Ansible для работы внутри. Зайти и что-то поставить в шелл — теперь абсолютная дикость. Да, это быстрее и удобнее, но в новой парадигме — это дикость: вспомните про exe.
Каким я вижу конкретный технический путь для того, чтобы понять, как работать с современным стеком?
1) Сделать триальный аккаунт на клауд-хостинге. Их предоставляют все хостинги. Я начинал с GKE, но можно, например, взять аккаунт на российских хостингах, если вы ожидаете, что работать будете, скорее всего, на этой территории.
Если Terraform/Pulumi поддерживают ваш клауд — описать инфраструктуру, которую вы хотите создать в них. Если у вас есть навыки программирования, я рекомендую Pulumi: вместо собственного SDL Terraform-а вы сможете писать на привычных языках и конструкциях.
2) Найти приложение и упаковать его в докер. Что тут упаковывать — выбор за вами. Я внезапно обнаружил для себя, насколько стал распространен NodeJS, и решил заняться глубоким изучением его эксплуатации, поэтому дальнейшую работу веду с нодой. Вот, например, бложик на NodeJS, который можно поднять, но вообще все на ваше усмотрение.
3) Разобраться с базовыми конструктами (под, деплоймент, сервис) K8S и задеплоить приложение руками в кластер K8S.
4) Разобраться с Helm-ом, написать Helm-чарт, задеплоить приложение Helm-ом.
Взять бесплатный план на CircleCI как CI-ке, которую не надо ставить, и конфигурировать: конфиги будут похожи на остальные системы.
5) Задеплоить приложение через CI-ку.
Разделить CI (то, что собирает приложение) и CD. Сделать CD по GitOps (см, например ArgoCD).
Где-то с этого момента вы, в принципе, будете в курсе основных базисов современного стэка.
Куда можно пойти копаться дальше?
А ещё я чуть более регулярно, чем блог здесь, веду свой телеграм-канал, подписывайтесь :-)
Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.
Почему я считаю важным уметь менять парадигму технологического мышления?
Самая сложная вещь для тех, кто давно работает в технологиях, — принять, что новый тренд стал постоянным. За 20 лет работы я видел, как приходили и уходили разные технологии, причем некоторые из них были «суперактуальны» целых несколько месяцев.
Я читал Джоэля Спольски про то, как Microsoft систематически придумывает новый стек для разработчиков для того, чтобы в целом не дать им возможность посмотреть на что-то иное. Как SRE, я вдвойне опасался каждой новой технологии: всё новое — сырое, всё сырое — нестабильное. Ну, а всё нестабильное приведёт к проблемам в продакшне, а стабильность продакшна — это главное.
Как программист и предприниматель, я хотел создавать продукт быстрее — всё новое надо изучать, изменять привычные подходы, а это значит — медленнее выкатывать фичи. Если какие-то новые технологии принимались быстро, то все связанное с микросервисно-ориентированной разработкой (давайте так назовем весь современный стек) нужно было учить. И с каждым годом учить все дольше; гораздо проще писать старым привычным методом и доставлять продукт быстрее.
Но факт остается фактом: иногда новые технологии остаются и меняют всю парадигму целиком. И тут возникает выбор: оставаться в старой парадигме или переходить в новую. Cobol-программисты до сих пор могут устроиться на работу, perl-разработчики помнят про booking, но альтернативных путей для этих людей становится всё меньше и меньше. И тогда «ретроградство» во имя стабильности становится ограничением. Со всем современным стеком, если вы не хотите себя ограничивать, время уже не то, что пришло, а мы уже отстаем. И, если мы не хотим застрять в «perl»-е, надо учиться. Это занимает продолжительное время. Попробую рассказать свой пошаговый опыт в обучении.
Направления глубокого погружения
Поймите, как запускать приложения в докере. Прежде всего, ветеранам стоит понять, что способ «хранения» и «запуска» приложений изменился навсегда. Скорее всего, разработчик, который научился разработке в последние годы, вообще не представляет себе, как запускать приложение в продакшне без докера. В голове такого разработчика, вероятно, нет концепции «хранить файлы локально», кроме редких кейсов общего хранилища, но главное, что нужно понять «ветерану»: докер — это новый exe. У exe-формата, может быть, есть свои минусы, но никто уже об этом особо не думает.
Да, микросервисный подход стал стандартом. Как когда-то ООП появилось для того, чтобы большим командам стало проще писать большой софт; теперь таким же стандартом стали микросервисы. Их даже те же люди культивируют (см. Фаулера). Это разумно: при соблюдении версионности API приложения отдельным командам проще писать самостоятельные приложения, чем одно большое. Зачем и маленькие приложения писать микросервисно, можно поспорить, но и их в какой-то момент все стали писать в ООП-стиле— просто так привычно (см. выше про exe). Можно много рассуждать о том, что у межпроцессной коммуникации (особенно, построенной на TCP-стеке) существует миллион недостатков с точки зрения производительности (один сервис пойдет к другому по TCP вместо того, чтобы просто выполнить ассемблерный-call — вы представляете какая это разница в производительности?), но факт остается фактом — у микросервисов есть достоинства скорости разработки средних и больших проектов и они также стали стандартом. Поймите, как микросервисы между собой взаимодействуют (HTTP API, grpc, асинхронное взаимодействие через очередь — миллион способов), бонусом — поймите, что такое service mesh. (Минута гневного юмора: боже, ребята, они придумали разделить приложение, и оказалось, что коммуникация между разделенными приложениями — сложная шутка, поэтому они добавили еще один слой, чтобы облегчить межпроцессный ужас, за что это нам?)
Поймите, как управлять пачкой запущенных в докерах микросервисов. Итак, мы смирились, что приложения мы теперь запускаем в докере и что приложение мы разделяем на микросервисы. Теперь надо как-то управлять запущенными докерами. Можно делать это самому на выделенных серверах (и рулить, например Docker Swarm-ом, ну или собрать Kubernetes), а можно использовать сервисы, которые дают облака — контейнер-сервисы от AWS или Kubernetes. В использовании облаков есть одно очень большое преимущество. Вы, фактически, перестаете думать про слой, запущенный ниже менеджера контейнеров (SRE сейчас посмеются, но давайте признаемся — когда все стабильно, мы не лазим на ноды GKE руками в большинстве случаев). Таким образом, фактически, менеджер контейнеров, стандартом которого стал Kubernetes, превращается в операционную систему. В нём есть пакет-менеджеры, в него можно «ставить софт», в нём можно запускать «exe-шники» — докеры, в нём есть кронджобы. Kubernetes — это новая ОС.
Разберитесь, как докер-контейнеры надо будет доставлять. Выкладка простого сайта теперь занимает 5 минут, и люди считают это нормой. Надо собрать докер, протестировать, положить в registry и поместить в менеджер докеров (давайте будем говорить дальше Kubernetes). Это дикость (?), к которой все привыкли, это оптимизируется и это стандарт. CI/CD системы стали стандартом выкладки, и с ними надо разобраться. Также как и с GitOps.
Поймите, что on-premise хостинг для большинства приложений уйдет (на Западе — уже ушел) в прошлое. Когда-то давно нормой было купить серверы, собрать их, привезти в ДЦ, поставить в колокейшн и скоммутировать. Даже для небольшого проекта. Потом на смену пришли Dedicated-серверы. Какому количеству людей приходит сейчас в голову на небольших и средних проектах мучаться, покупать и собирать железо? На смену Dedicated — на Западе уже сейчас, а в РФ скоро — придут облака. Об этом говорят сто лет, я использую AWS с 2008 года, и у него есть проблемы, но когда мы говорим о сервисе, который берёт на себя менеджмент Kubernetes (EKS, GKE, Kubernetes от Яндекса или Селектела), мне становится непонятно, зачем менеджить сам Kubernetes и дедики, если это делают другие ребята? Я же не меняю кулеры в дедиках больше… Вопрос распространенности on-premise дистрибуций Kubernetes в РФ — это вопрос курса доллара, закона о персданных и «молодости» российского клауд-хостинга. Рано или поздно это решится и on-premise станет дикостью, которую хотят энтерпрайзы и большие нагруженные проекты. С базами то же самое. Если мы говорим о большинстве приложений, которым не требуется супервысокая нагрузка или супермощный тюнинг, то облачный PostreSQL/MongoDB/MySQL дает огромное количество преимуществ. Не надо думать про тюнинг, не надо думать про бэкапы. Создать дев-сервер из продакшн-сервера — пара команд в облачной консоли. Я понимаю, что вся эта идея может вызывать гнев у админа: ребята, я и сам админ, но для большинства нехайлоад задач менеджмент баз, правда, не нужен. Возможно, AWS и GKE стоят дорого и недоступны нам из-за закона о персданных, но это лишь дополнительное время для отставания: рано или поздно те же фичи будут у Яндекса или Селектела, и парадигма сменится.
Поймите, что инфраструктуру теперь пишут. Я не любил IaaC, когда он был Chef-ом и Puppet-ом, но на смену им, слава богу, пришли более адекватные Terraform и Pulumi для описания того, что вы хотите поднять в кластере, и Ansible для работы внутри. Зайти и что-то поставить в шелл — теперь абсолютная дикость. Да, это быстрее и удобнее, но в новой парадигме — это дикость: вспомните про exe.
Курс глубокого погружения
Каким я вижу конкретный технический путь для того, чтобы понять, как работать с современным стеком?
1) Сделать триальный аккаунт на клауд-хостинге. Их предоставляют все хостинги. Я начинал с GKE, но можно, например, взять аккаунт на российских хостингах, если вы ожидаете, что работать будете, скорее всего, на этой территории.
Если Terraform/Pulumi поддерживают ваш клауд — описать инфраструктуру, которую вы хотите создать в них. Если у вас есть навыки программирования, я рекомендую Pulumi: вместо собственного SDL Terraform-а вы сможете писать на привычных языках и конструкциях.
2) Найти приложение и упаковать его в докер. Что тут упаковывать — выбор за вами. Я внезапно обнаружил для себя, насколько стал распространен NodeJS, и решил заняться глубоким изучением его эксплуатации, поэтому дальнейшую работу веду с нодой. Вот, например, бложик на NodeJS, который можно поднять, но вообще все на ваше усмотрение.
3) Разобраться с базовыми конструктами (под, деплоймент, сервис) K8S и задеплоить приложение руками в кластер K8S.
4) Разобраться с Helm-ом, написать Helm-чарт, задеплоить приложение Helm-ом.
Взять бесплатный план на CircleCI как CI-ке, которую не надо ставить, и конфигурировать: конфиги будут похожи на остальные системы.
5) Задеплоить приложение через CI-ку.
Разделить CI (то, что собирает приложение) и CD. Сделать CD по GitOps (см, например ArgoCD).
Что дальше
Где-то с этого момента вы, в принципе, будете в курсе основных базисов современного стэка.
Куда можно пойти копаться дальше?
- Если вы ищете работу/хотите работать на Западе, можно пойти в углубление знаний по клаудам: сдайте на Cloud Architect сертификат Google-а или аналогичный от AWS (мы в ITSumma недавно получили 3 таких сертификата). Это даст представление о фичах, которые дают клауды, и поможет в них ориентироваться. Хороший курс на linuxacademy.
- Сдайте на CKA: это уже сложная тема, но стоит того. Подготовка к экзамену даст огромный пакет знаний.
- Научитесь программировать, если не умеете. Я сейчас пошел изучать фронт и поражен тем, как всё изменилось. Мои знания закончились где-то в 2012-м или даже раньше, еще на JQuery, люди смеются. Фронт сейчас стал сложнее, чем бэкэнд, там огромное количество application-логики и при этом совершенно непривычные для меня парадигмы. Очень интересно!
А ещё я чуть более регулярно, чем блог здесь, веду свой телеграм-канал, подписывайтесь :-)
Gemorroj
Вот я из ретроградствующих. Как из статьи, так из собственных ощущений вижу что "Это дикость". Какие проблемы мы решаем всей этой кучей инструментов? Быстрая выкладка кода? Но не создаем ли мы больше проблем, чем решаем? Или тут следует выключить мозг и смириться с тем, что "так надо"?
dvserg
Думаю в первую очередь это масштабируемость. Если вдруг понадобится больше ресурсов — такое решение позволит его получать «по запросу».
Следующая задача — упрощение развертывания и обновления. Не нужно растаскивать на все используемые серверы, достаточно обновить образ и перезапустить все копии контейнеров.
eapotapov Автор
Тут хитрый вопрос.
Можно задать этот же вопрос про объектно-ориентированное програмирование, и ответ кстати будет примерно такой же. Зачем нужно ООП?
Чтобы большие команды могли проще создавать сложные многофункциональные приложения.
В 1990-е годы ожидалось что приложение будет выпускаться раз в несколько лет и монолитный ООП подходил, да и в целом — технологии не давали обновлять «части» приложения.
В 2010-е хочется обновлять приложение (оно теперь стоит на сервере) как можно быстрее. Если большая команда будет писать миллион фич в пределах одного приложения — это будет сложно, лучше приложение разделить. Поскольку люди имеют свойство делать глупости и ошибаться — лучше эти отдельные куски приложения сделать вообще отдельными приложениями, пусть каждый работает над своей частью. Эти приложения надо как-то менеджить — появился K8S. Для больших приложений (посмотрите на карту сервисов Netflix) это работает великолепно.
Почему так пишут даже маленькие приложения? Да фиг его поймет почему, можно по другому, но пишут. ООП тоже непонятно зачем для маленьких приложений было, но стало просто стандартом. Так и тут. Противно, в отличие от ООП (которое было до того как многие из нас стали айтишниками) произошло при нас, хочется брюзжать. На ООП, наверняка, также толпа справедливо брюзжала.
dvserg
Отличие 90х и 200х есть еще в одном моменте — это развитие глобальной сети, а вместе с ней и способов доставки приложений. В 90х монолитные приложения обновлялись копированием с носителей на компьютеры оффлайн, и это было нормально. Затем с развитием сетей появилось онлайн обновление, что потребовало разбивать приложение на модули для снижения трафика. Ну а в настоящий момент эта «естественная» идея вышла на новый уровень.
andreyverbin
Для этого нужно ABI, нужна система пакетов типа npm/maven/nuget, нужны библиотеки. ООП для этого не нужно.
andreyverbin
Не беспокойтесь, такое уже было и благополучно сдохло. Вспоминаю J2EE, который весь из себя был заточен для распределённых систем. Там было все, что сегодня есть в k8s и даже больше. Сдохло оно протому, что появился spring framework, который выкинул всю распределенщину и позволил делать «просто». Затем уже spring’у досталось от Ruby On Rails, который сделал ещё проще и который до сих пор его можно считать стандартом простоты и лаконичности.
А до J2EE была CORBA и DCOM, там было все то же самое. J2EE приходил к ним на смену, вроде как пытался их упростить :)
Продвинутый App server был распределённым, мог запускаться на нескольких хостах. Был auto scaling, когда новые инстансы сервисов поднимались по требованию. Облаков тогда не было, поэтому масштабирование было внутри app server.