Изучение контейнеризации за пределами Kubernetes
devops kubernetes docker containers devops-tools containerization containers-devops kubernetes-infrastructure

Изучение контейнеризации за пределами Kubernetes

13 апреля 2022 г.

За последние несколько лет слово «Контейнер» (и, возможно, даже «Докер») стало синонимом Kubernetes. Это было, конечно, непреднамеренно — Kubernetes достиг такой популярности, которой обладают очень немногие технологические тенденции в последнее время. Эта статья не предназначена для критики Kubernetes, который я считаю блестящей технологией. Вместо этого я хочу привести аргумент, что контейнеры могут делать гораздо больше даже без Kubernetes.


Почему Docker?


Давайте подумаем о проблемах, для решения которых был создан Docker:


(1) Удалите все кошмары зависимостей, из-за которых рабочие среды неизменно отличаются от сред разработки.



(2) Эффективность упаковки и развертывания — как с точки зрения размера, так и времени.


(3) Повышение производительности труда разработчиков — особенно внутреннего цикла «Правка» -> «Сборка» -> «Отладка».


Все отличные цели достигнуты, и в основном достигнуты.


Что пошло не так?


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


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


Как помогает облачная PaaS?


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


Некоторое время назад Google Cloud представила свой продукт Cloud Run, который представляет собой бессерверную контейнерную платформу, в первую очередь оптимизированную для рабочих процессов на основе контейнеров. Они сделали это, несмотря на то, что у них уже был продукт для бессерверных вычислений, управляемый событиями (Cloud Functions), но это было в основном для рабочих процессов на основе кода.


AWS долгое время старались, чтобы концепция PaaS (в их случае Lambda) отличалась от концепции контейнеров. Их управляемый сервис Kubernetes, очевидно, поддерживал контейнеры, но они долгое время сопротивлялись, добавив поддержку контейнеров в Lambda. Это изменилось в прошлом году, когда они наконец объявили, что Lambda будет поддерживать контейнеры в дополнение к коду.


В моем предыдущем обзоре на тему PaaS, я сделал упрощающее предположение, что бессерверные технологии — это всего лишь вариант PaaS. Как видите, я продолжаю придерживаться этого предположения и здесь.


Если мы объединим преимущества Docker, которые мы обсуждали ранее, с преимуществами полностью управляемой PaaS (как описано в статье, указанной выше), мы скоро поймем, что Docker и контейнеры могут на самом деле лучше подходить (для большинства разработчиков и вариантов использования). со средами PaaS, а не с Kubernetes.


Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE