Comments 93
А что вместо? Вот, допустим, у меня есть небольшая (в плане ресурсов) VPS, на которой мне нужно запустить 5 приложений (например): API сайта, SSR сайта, обработчики очередей, сервис email-рассылок и сервис с грабберами какими-нибудь. Как это правильно развернуть на VPS? Сейчас сам сервер настраиваю через Ansible (установка PostgreSQL, Docker, Docker-compose, конфиги и т.п.), а мои приложения в контейнерах запускаются через docker-compose. Деплой сделан через GitlabCI: сборка образа, доставка его на сервер и рестарт docker-compose. Но выглядит, если честно, костыльненько, и есть мысль k3s попробовать.
Но выглядит, если честно, костыльненько
https://www.youtube.com/watch?v=LeVULLqWwcg
Не существует "правильного" способа, об этом и есть первый пункт. Если у вас всё работает, не возникает никаких проблем, то какая разница как это выглядит?
Выглядит нормально. В чём костыли?
Ну, например, если я захочу сделать какой-нибудь rollingUpdate, то эта схема уже становится не особо рабочей, т.к. для этого нужен хотя бы Docker Swarm. Если заказчик захочет, например, SSR-сервис вынести на более производительный отдельный VPS, то это опять-таки боль. Понятное дело, что глупо пытаться всё заранее предусмотреть, но с задачей вынести что-то на отдельный VPS сталкивался не раз.
Swarm не советую. Слишком…простой для нескольких серверов.
Используйте rke + rancher. Настраивается просто, можно даже на одной машине. Работает стабильно. Умеет обновлять версию k8s. Даже если сломаете все, восстановить с нуля - пара команд и пол часа времени.
Чёт я попробовал ранчер на арм машине и оно не завелось. В веб интерфейсе не появились данные для подключения узлов. Видимо оно нормально работает только на х64 железе.
Если у вас появился веб-интерфейс, скорее всего, все заработало. Данные для подключения узлов вы сами добавляете (ну или через тот же ранчер создаете кластер, но это так себе вендор-лок вариант).
т.е. чтобы там что-то было, у вас уже должен быть кластер, в идеале.
Дык в том-то и дело, что кластер я создал, а подключить в него рабочий узел не вышло. Через морду. Лезть руками тикеты извлекать - а зачем тогда ранчер... Сразу уж тогда его нахрен и делать всё руками.
Стоп. Что значит "подключить рабочий узел"? Добавить ноду? Так это не забота ранчера, он не для этого.
Если создавали кластер через rke, то добавьте ноду в конфиг и сделайте rke up
Если создавали чем-то другим, то уже в этом "чем-то другом"
Я смотрел на ранчер по этой статье: https://habr.com/ru/post/418691/
И вот на шаге "Чтобы добавить воркер, перейдите в редактирование кластера в web интерфейсе Rancher, увидите то же меню, которое генерирует команду подключения", я увидел фигу, пустой веб интерфейс.
В статье кластер создавали силами самого ранчера. В таком случае и ноды добавляются оттуда же.
В принципе, рабочий вариант, но он получается зависим от этой панели. Я думаю можно как-то вытащить и kubeconfig, но я когда пробовал - не понравилось.
Ранчер лучше использовать просто как веб-интерфейс к кластеру. Лучше него пока не нашел.
Лучше отдельный systemd-сервис на каждое приложение. Podman (из RH операционок) умеет командой такие делать. Для Docker нужно будет самому написать. Пример из Podman:
$ cat container-sites.service
# container-sites.service
# autogenerated by Podman 2.0.5
# Fri Feb 19 05:50:30 UTC 2021
[Unit]
Description=Podman container-sites.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStartPre=/bin/rm -f %t/container-sites.pid %t/container-sites.ctr-id
ExecStart=/usr/bin/podman run --conmon-pidfile %t/container-sites.pid --cidfile %t/container-sites.ctr-id --cgroups=no-conmon --replace -d --name sites --network=cni-podman1 -p 80:80 -p 443:443 -p 127.0.0.1:2019:2019 -v /data/Caddyfile:/etc/caddy/Caddyfile -v /data/sites:/sites -v /data/sites-data:/data -v /data/sites-config:/config myaccount/site:v1.0.0s-dev
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-sites.ctr-id -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-sites.ctr-id
PIDFile=%t/container-sites.pid
KillMode=none
Type=forking
[Install]
WantedBy=multi-user.target default.target
Для вашего случая подойдёт nomad.
Костыльненько конечно.
Nomad полегче, но его тоже курить надо, да и тулинга меньше к нему.
Хотя ресурсы он и правда почти не ест.
Берите k3s или microk8s (второй вообще из коробки с собой всё имеет) и не парьтесь. Чарты для куба есть уже для постгреса, кролика и прочего, есть ингрес, серт-менеджер...
в номаде ничего этого нет.
Придётся использовать traefik, то ещё удовольствие.
Хотя у меня есть пет проджект на номаде, год работает, есть пить не просит.
Но там специфика проекта, в контейнерах не запустить.
Так то с удовольствием бы уехал в куб )
у меня такой же вопрос про альтернативы. Да k8s имеет много недостатков. Но вот у меня есть docker-compose с вязанкой сервисов созданный разработчиками. Мне надо его переместить в рабочее окружение. Т.е. сделать чтобы у меня было несколько экземпляров нужных мне сервисов, правильно сконфигурированных.
Что использовать? K8S это конечно кошмар. Но какие альтернативы? Какой-то конвертер в ansible? Swarm?
Я без ехидства, мне реально нужно.
Почему минусуют за nomad? Вопрос же у человека: какая может быть замена docker-compose.
Выглядит интересно. Вопрос в том не является ли это заменой одного зла на другое?
K8S хотя бы используется широко и его много кто знает.
nomad делает так же компания что и terraform, packer, consul, vault.
У nomad есть rolling update https://learn.hashicorp.com/tutorials/nomad/job-rolling-update - а у docker-compose rolling update нет.
Да понятно, что с docker compose в прод идти нельзя. Это даже не вопрос. Вопрос в том как сконвертить docker compose используемый разработчиками во что-то простое и пригодное для прода.
К сожалению nomad не использую. Спросите в чате https://t.me/ru_hashicorp
почему нельзя?
Ну тут есть два момента
Я знаю проект где уже который год прод на compose и это в общем норм
В доке compose написано, что в прод не берите и для большинства задкачиков предлагать что-то что противоречит тому что написано в доке - плохая идея.
Спасибо.
https://docs.docker.com/compose/production/
Вроде ничего не пишут.
Есть ещё такая статья: Возможно, вам не нужен Kubernetes
Они там как раз для своего случая используют Nomad.
Nomad как и k8s имеет деклатаривное описание и стремится к состоянию, тот же swarm это задеплоил, а как раздеплоить при удалении сервиса из yaml файла хз...
Попробуйте, там всё настраивается за 5 минут. И документация хорошая)
Kubernetes разработан для компаний типа FAANG
возможно, десяток приложений для развертывания,
для развертывания всего одного или двух приложений
На счет FAANG - неправда. Куча других компаний использует kubernetes. Если 10 приложений - то использование оправдано.
Это не значит, что Kubernetes никогда не будет полезен для небольших развертываний
Небольших развертываний это примерно сколько там приложений?
Но архитектура Kubernetes не очень-то помогает вам отслеживать рабочие нагрузки и обеспечивать их оптимальную производительность.
При увеличении нагрузки HPA или KEDA увеличивают кол-во реплик, а при уменьшении нагрузки уменьшают кол-во реплик.
Многие люди видят не баг, а фичу в архитектурном принципе Kubernetes «всё есть код»
Сейчас это называется GitOps.
На счет FAANG — неправда. Куча других компаний использует kubernetes.
В оригинале web-scale companies. Netflix (который не FAANG) автор ниже прямо упоминает.
Если 10 приложений — то использование оправдано.
Небольших развертываний это примерно сколько там приложений?
Автор предлагает усомниться в этом массовом предрассудке.
Не все приложения stateless и вообще бесплатно контейнеризуемы.
(Кстати, я в курсе про StatefulSet)
При увеличении нагрузки HPA или KEDA увеличивают кол-во реплик, а при уменьшении нагрузки уменьшают кол-во реплик.
Это ещё одна пара сущностей, которым нужен менеджмент.
И кстати когда они появились? Статье больше года… и только с менеджментом в экосистеме куба в целом не полегчало.
OpenShift vs. Tanzu vs. 100500…
Сейчас это называется GitOps.
Мне лично тоже по вкусу этот свиной хрящик. Но я бы воздержался от хайпа и тотального навязывания своего вкуса..
OpenShift используют компании с обычной инфраструктурой, потому что OpenShift интегрируется с Active Directory из коробки. Но OpenShift и стоит денег.
Tanzu не видел чтобы кто то использовал.
Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler. You can add custom metrics for the Horizontal Pod Autoscaler to use in the autoscaling/v2beta2 API. Kubernetes then queries the new custom metrics API to fetch the values of the appropriate custom metrics.
OpenShift используют компании с обычной инфраструктурой, потому что OpenShift интегрируется с Active Directory из коробки. Но OpenShift и стоит денег.
Tanzu не видел чтобы кто то использовал.
Второе, очевидно, используют компании c инфраструктурой vSphere 7+.
Кстати, инфра Vmware интегрирована с AD целую вечность (с тех пор как они лицензировали Likewise.)
И то, и другое — opinionated управлялки. "Соборы", вместо экосистематичного "базара".
Автор толкует о том в частности, что "базар" кубера злокачественней линуксового "базара".
Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler
Угу, принято. И про Netflix тоже.
OpenShift без поддержки называется OKD (и он бесплатен).
Tanzu не стоит дополнительных денег, если уже оплачивается VMWare. Такие компании ее и используют.
Про OKD знаем. У заказчика стоит Openshift 3.11 - возможно это OKD. Мы там права юзера имеем. Почему не обновляет до новых версий - не знаю.
Новые версии OKD очень требовательны по ресурсам:
One host is required with at least 8 CPU cores, 32.00 GiB of RAM, and 120 GB of filesystem storage.
Или для dev/локального запуска:
4 physical CPU cores
9 GB of free memory
35 GB of storage space
Непонятно откуда требования, выделенные жирным. Вот документация (там 4/16/100 для мастера и 2/8/100 для worker): https://docs.openshift.com/container-platform/4.9/installing/installing_bare_metal/installing-bare-metal.html#minimum-resource-requirements_installing-bare-metal . При этом на практике я бы не делал ноды меньше 8/32. И, понятно, число нод должно быть таким, чтобы ресурсы на 3 мастера на их фоне выглядели как ничто.
Про dev (CodeReady Containers) -- это именно OpenShift (с ui и прочим). Если достаточно чистого Kubernetes, то его в Docker можно включить.
Tanzu тожу недавно обзавелись "коммунальной" редакцией.
А что такое N в FAANG?
Facebook, Amazon, Apple, Netflix и Google (FAANG) https://ru.wikipedia.org/wiki/Facebook,_Apple,_Amazon,_Netflix_и_Google
В оригинале web-scale companies. Netflix (который не FAANG) автор ниже прямо упоминает.
Я извиняюсь, но Netflix это N в FAANG.
Ну не знаю. Использую k8s (rke, rancher, helm) в собственном проекте на VDS + железный сервер. Начинали с двух машин. Сейчас их десяток где-то.
Очень удобно, никаких претензий. Лишь один раз helm заклинило и он мне снес весь чарт проекта. Ну восстановил за пол часа где-то, бывает.
По мне так k8s можно использовать и на маленьких проектах. Разве что минимальные требования к серверам не такие уж и маленькие: мастер сжирает ресурсы довольно прилично даже для пары воркеров.
Скажите, пожалуйста, а сколько нужно, если совсем по-минимальному? И второй вопрос: правильно ли я понял, что VDS должно быть минимум 2 штуки: 1- мастер-нода, 2 - воркер?
Совсем по минимальному хватит одной VDS на 2-4 ядра и 8-12 ОЗУ. Этого хватит чтобы запустить мастер и на нем же что-то рабочее. Фактически k8s без разницы где и что запускать, можно все фигачить на одной машине.
Желательно конечно мастер вынести, чтобы не машал нагрузкой. Для рабочей ноды минимальных особо нет, хватит и одного ядра/гига, все зависит от того, что вы там запускаете.
Россказни про "нужно минимум три мастера" - просто россказни. Если вы не гугл, то одного мастера вполне хватит. Даже если упадет - все продолжить работать, просто без контроля запуска, этого хватит на "переподнять мастер". Но фактически падать там нечему.
Rancher тоже можно запустить на этой же ноде, правда это не удобно (потребуется переносить 443 на другой порт, а браузеры этого не любят, особенно на самоподписанном сертификате-IP). У меня под него тоже отдельная чуть ли не сама дешевая VDS.
Понял, спасибо Вам большое - ценная информация.
Непонятно как вы собираетесь переподнимать 1 мастер. Если 1 мастер и он упал, то нужно переставлять весь кластер (при этом да, приложения продолжают работать, если не используют k8s api -- cron, скейлинг и тп). Переставить кластер вполне может быть приемлемым, не каждый год оно падает, а простой может быть дешевым.
При этом, если есть хотя бы 3 ноды, то нет особых причин не запустить 3 мастера. На мастерах можно запускать обычные поды (настройка). Оверхед 2х дополнительных etcd не такой уж большой, зато кластер не нужно будет переставлять.
Был опыт работы с K8s на мелких виртуалках в Digital Ocean. И сам с нуля поднимал, и подключал воркер в их сервис. В итоге, оно нестабильно работает -- через пару месяцев само ломается. А вот с docker из systemd проблем нет. Для ультрамелких деплоев пока что так делаю.
Возможно мы о разных падениях. Если он у вас накрылся, не запускается и вам надо его полностью переделать - то да, это переделка кластера. Но такое бывает...да хз, никогда почти.
Если мастер просто перезагрузился (например VDS дернули) - он просто запустится и кластер продолжит работу как ни в чем ни бывало. У меня такое было пару раз - все хорошо закончилось.
Оверхед от мастера довольно чувствительный. Возможно причина в запуске через rke, не знаю. Но учитывая стоимость VDS мне проще выделить для него отдельные ядра и память и не заморачиваться. К тому же рабочие ноды я иногда перезапускаю/обновляю. Сломать ноду "лучше", чем сломать мастер-ноду.
Не знаю на счет DO. Возможно причина в их реализации. Я работал с GKE - это вообще идеал. Работал с Selectel на старте - это прям беда, у них все слетало. Потом плюнул и запустил кластер на обычных железках: работает уже третий год.
Мастеров может быть 1, 3+. Мастер может быть и воркером (т.е. запускать обычную нагрузку). OpenShift 4 поддерживает только 2 сценария: 1 (при этом нельзя добавить воркеров) или 3 мастера.
Воркеров может быть 0+.
Важно дать памяти достаточно, т.к. swap в K8s отключен. Для стабильной работы должен быть запас по свободной памяти.
Если совсем по минимальному, то я бы не использовал K8s, т.к. будут все связанные сложности, а развернуть кучу удобных сервисов ресурсов не будет.
Kubernetes -- это основа Private Cloud. Из этого 2 следствия:
Cloud, хоть и Private, сложно масштабировать вниз.
Cloud, хоть и Private, состоит из десятков (а то и сотен) сервисов. И да, их нужно ставить, настраивать и обслуживать. И далеко не все из них есть в готовых дистрибьютивах типа OpenShift. Тут Kubernetes можно рассматривать как Linux (ядро), по отношению к дистрибьютивам.
Есть варианты малых кластеров, но они для удаленных офисов (Edge) или разработки/тестирования.
Исходя из этого, все претензии изначальной статьи выглядят странно. Кроме разве проблем масштабирования вниз. Об этом нужно знать и использовать другие решения: K8s в публичном облаке или более классические решения (Anisble).
Его ещё называют кластерной операционной системой
Cloud, хоть и Private, сложно масштабировать вниз.
Cloud, хоть и Private, состоит из десятков (а то и сотен) сервисов.
По аналогии с дооблачными временами:
при ограниченном бюджете я бы вычеркнул высокую доступность и вообще впариваемую автоматизацию. Автоматизировать следует только то, что реально задолбался уже самостоятельно делать руками.
Например, девелоперам нужно воспроизводимое окружение для разработки и для запуска CI пайплайна — и тут как раз кубер может выручить.
Если не отвлекаться на фишки, которые уже пару десятилетий продают организациям, которым автоматизация это экономия на зарплате (админов/опсов).
Сейчас актуален всё тот же FUD, что и раньше — "увольте админа, купите чудо-продукт" — но уже в виде дериватива: "админ не справится скейлить 100500 сервисов, используйте оркестратор" (вариант "откажитесь от своего железа, покупайте немножечко нашего мейнфрейма облака").
Плохо вестись на такое — и подписываться на внедрение и обслуживание очередной чудо-автоматизации или чудо-оркестрации. Ну или покупать вместо этого managed кубер время гиперквалифицированных чудо-SRE.
Статья размытая, не несущая конкретики толком.
Альтернативы никакой нет. При этом говорятся очевидные вещи, вроде того, что это не палочка выручалочка.
Ну да, нет ничего идеального в этом мире.
Но кубер очевидно лучше чем docker compose. Его легко поднять локально через minikube (супер удобная штука, single click run k8s). Конфигурации на нем писать одно удовольствие - он поддерживает не через жо пятую точку все что нужно приложениям и их интеграции.
Наверное, если у вас статический сайт-визитка, вам кубер не нужен, так это вроде очевидно 🤷🏻♂️
Но кубер очевидно лучше чем docker compose.
Вовсе неочевидна необходимость в том, чтобы всё подряд контейнеризовать. Тем более, что это занятие далеко не бесплатно.
Мне кажется, что автор за "собор" и против "базара"; однако последний он готов признать неизбежным злом. Конкретно недоволен он фрагментацией экосистемы кубера, более злокачественной по его мнению, чем фрагментация дистрибутивов Линукса.
Все подряд и не нужно, использование кубера не подразумевает, что надо все запихнуть в контейнеры же. Его крутость в том, что это кластерная о/с, ты же свои деплойменты можешь синтегрировать с любым сервисом из bare metal. Особенно используя helm + ansible.
Естественно, бд в контейнере нет, естественно не все проекты сразу перейдут в кубер, а кто-то и не перейдет вовсе, и это будет работать какие-то годы возможно параллельно.
Конкретно недоволен он фрагментацией экосистемы кубера
Ну, в этом, конечно есть правда. Но и время жизни линукса не сравнить с к8с. Время покажет, как обычно, кто вымрет, кто выживет.
Может быть, его архитектура ещё упростится.
Это вы еще Опенстек не видели. Кубер просто мана небесная по сравнению с ним.
Я понимаю, что отвечаю в пустоту, но
Kubernetes разработан для компаний типа FAANG
Это архитектурная проблема? Кмк, это большой плюс - компании типа FAANG могут дизайнить платформенные продукты вроде k8s с хорошим пониманием разного рода нагрузок и сценарием. Когда этим занимается небольшой стартап, получаем инструмент навроде swarm - слабо расширяемый и ограниченно масштабируемый.
Рынок Kubernetes раздроблен
Ровно наоборот. Любой вендор может сколь угодно перепиливать ванильный k8s и обмазывать его своими плагинами, clusterapi и прочими свистоперделками, но покуда он совместим с требованиями CNCF - кто угодно может запускать на нем что угодно.
В Kubernetes слишком много частей
"Kubernetes - это всего 5 бинарей!" (с). На самом деле частей много, потому что уровней абстракции много - и большинство порождены не k8s, а инфраструктурой. Да, это сложно, но сложно не потому, что k8s, а потому, что виртуализация и оркестрация - в целом сложная тема. K8s упрощает ее достаточно сильно не настолько, чтобы она стала простой.
Управлять Kubernetes вручную сложно
Здесь возразить нечего, это действительно так. Как и управлять кластером БД, или кластером Kafka сложно. Поэтому имеет смысл использовать managed k8s, покуда вам не станет выгоднее держать свой штат девопсов, чем платить облаку. (здесь могла быть нативочка, но ее не будет)
У Kubernetes есть проблемы с мониторингом и оптимизацией производительности
И снова все ровно наоборот. K8s (точнее, Metrics API) предоставляет единый и единообразный мониторинг всего и вся в k8s. Мониторинг же бизнесовых показателей ничем не меняется по сравнению с запуском в другом окружении.
Что касается производительности - и снова нет. K8s наоборот позволяет более полно утилизировать ресурсы за счет шедулера + гибких правил (taints, affinity, вот это все). В итоге простоя ресурсов меньше, чек меньше (если нагрузки вообще есть, конечно. Сам кластер тоже что-то ест).
Kubernetes всё сводит к коду
Да, и это прекрасно. IaC кажется сложным, но решает очень большую проблему - единообразность окружений, а также аудит, возможность отката при неудачном изменении инфры и тиражирование при необходимости. Не буду рекламировать IaC тут, но это благословение, а не наказание.
Kubernetes хочет всё полностью контролировать
Кмк, так говорить - некорректно. K8s хочет контролировать все, что внутри кластера - это логично. При этом интеграция с ресурсами вне кластера очень даже работает - посмотрите у любого облачного провайдера. Для особых энтузиастов есть инструменты вроде Cilium, с которыми эти интеграции еще сильнее упрощаются (ценой дополнительных уровней абстракции, конечно).
Тем, кто не FAANG и не собирается в их клуб — зачем "облачная ОС" именно того чужого надчеловеческого масштаба?
Зачем например хаять rancher, как это делают слёрмовцы?
Да нет там никакого надчеловеческого масштаба. K8s - это не облачная ОС, а платформа виртуализации, по сути, только с человеческим лицом в виде манифестов вместо каких-то сложных api и инструментов вроде vmomi.
Зачем хаять k3s - я не знаю, но k3s - это проект для "игрушечного" запуска куба - локально, в dev окружении или еще где. Он не прод-реди, его задача другая, вот и все, в остальном ничего плохого то нет.
Тем, кто не собирается в клуб - берите managed куб и забудте раз и навсегда про "нечеловеческий масштаб". Нюансы работы знать нужно, но вот нюансы обслуживания (а их реально много) - нет.
"не прод-реди" это такой FUD.
Аналогичным образом продавцы железных рейдов когда-то хаяли ZFS. Которыя, будучи по сути SDS, работала и на их железках — но предпочитала чтобы ненужные надмозги контроллеров были "отшиблены" перепрошивкой, ради прямого доступа к носителям.
У всех свои запросы. Знаю компании, у которых прод. нагрузка бежит на виртуалке с компоузом, знаю компании, где аналогичные нагрузки бегут просто на докере, а им управляет самописное cli приложение.
Вопрос в том, какие требования к инфраструктуре. Если требования "запустить один контейнер", то k8s тут явно лишний, да и k3s - тоже.
У k3s есть четкое и понятное назначение - это локальные окружения и "тесные" условия - эдж, всякие малинки и прочее. Кроме того, k3s идет на большое количество упрощений (как то использование однонодовой неотказоустойчивой ДБ вместо распределенной etcd и вообще минимальная отказоустойчивость. В "отказоустойчивом" варианте k3s мало чем отличается от k8s).
Подходит ли это для ваших нужд - вопрос только к вам. В плане долгосрочного использования k3s сильно проигрывает k8s как по возможностям обслуживания, так по масштабированию, отказоустойчивасти и прочим характеристикам прод. среды. Но возможно, время это исправит, тем более, что появляются интересные проекты вроде Talos - нацеленные на простоту и "изкоробочность".
У всех свои запросы.
То есть, вы уже согласились с автором в первом пункте (см. статью выше)
локальные окружения и "тесные" условия
То есть, по сути мы с вами согласны, а разногласие лишь в определении тесноты.
(Утрирую.) Моя позиция в том, что у 88% организаций условия "тесные" — настолько, что им не по карману перераспределять бюджеты ради приобретения облачных подписок.
Мы могли бы уже "заключить перемирие", на том, чтобы вы окучивали оставшиеся 12% "небомжей".
Но вы зачем-то продолжаете продавать доступ к мейнфреймам облакам всем остальным. Предлагая им принять участие в финансировании ненужных им чужого железа и чужого управляльного софта.
Моя позиция в том, что у 88% организаций условия "тесные" — настолько, что им не по карману перераспределять бюджеты ради приобретения облачных подписок.
У меня нет такой статистики. Если у вас есть - поделитесь.
То есть, вы уже согласились с автором в первом пункте
Нет, не согласился. Для компаний уровня FAANG k8s как раз не очень подходит из-за одной особенности - он слишком "общий". Именно поэтому гугл использует borg, а не k8s - borg умеет работать только с одной OC, только с одним набором библиотек и только с определенным железом. За счет этого достигается большая эффективность.
Куб же хорош там, где нужно запускать гетерогенные нагрузки/разные технологии (привет, микросервисы), при этом хочется уметь хорошо масштабироваться горизонтально, управлять всем из единого места и иметь единый мониторинг.
Под это подходят средние и крупные компании, не подходят мелкие (стартапы) и очень крупные (мегакорпорации).
Но вы зачем-то продолжаете продавать доступ
Кто «вы-то»?! (с)
Я ничего не продаю. А если говорить про публичные облака, то обычно предлагают разные варианты с различным количеством operations - обычно это VM, K8s, какие-нибудь контейнеры, и какие-нибудь функции. Например, у GCP это Compute Engine, GKE, App Runner и Cloud Functions соответственно. При этом уровень operations снижается, а цена повышается (потому что цена operations входит в цену услуги).
Наверное понятно, что если бы k8s подходил для всех, то других услуг не было бы. Вопрос в том, чтобы понять, кому что подходит.
У меня нет такой статистики. Если у вас есть — поделитесь.
Ни у кого нет и не может быть статистики, когда речь идёт о самоощущении организации. "Да, мы бомжи и у нас условия тесные". (И да, я полагаю что 88 процентов таких оценка ещё заниженная).
И тут к ним приходите вы с рекламой аутсорса отказа от собственной наземной инфраструктуры и регулярной ренты в карманы хозяевам мейнфреймов облаков. То есть — с рекламой такого потребления, которое им "не по сеньке шапка".
Если вам удастся разбудить в принимающем решения лице статусного потребителя — вы выиграли, и своё на той организации заработали.
Попробуйте теперь статистикой или как-то иначе доказать, что это ситуация win-win, а не наоборот.
Да кто "вы" то? Я никому ничего не продаю. И убеждать никого ни в чем не собираюсь. Пожалуйста поберегите подмену тезисов для другого случая.
Аргументы мои выше. Серьезных контраргументов (кроме необъяснимых "88%") я не увидел.
Что же касается облаков - то тут я тоже не понимаю, в чем вопрос. Облака - это не только k8s, но еще очень много всего, так что каждый найдет себе подходящее. А кто не найдет (любители on-prem), среди того же k8s - есть и Tanzu, и Rancher, и Openstack, если хочется большего удобства, чем ванильный k8s.
К большому сожалению, я не увидел у вас аргументов, а увидел коврово-бомбометательную рекламу.
Убей мамку и отдай квартиру вон тому дяде откажись от своей наземной инфраструктуры и регулярно заноси облачным провайдерам.
Но в принципе мы с КО согласны, что богатым и здоровым быть лучше, чем бедным и больным.
Облака — это не только k8s, но еще очень много всего, так что каждый найдет себе подходящее. А кто не найдет (любители on-prem), среди того же k8s — есть и Tanzu, и Rancher, и Openstack, если хочется большего удобства, чем ванильный k8s.
Ну то есть, вы именно фрагментацию экосистемы продаёте как её примущество. Отлично понимая, что офигевшим клиентам на этом "базаре" прямая дорога под крыло управляемых сервисов.
А сами вы отлично понимаете, что это совет вредный. Чуть выше здесь вы рекомендовали начинающим "небомжам" избавиться от стесняющих их железок и целиком отдаться управляемым сервисам. И это логичная рекомендация (если принять вашу, сомнительную, аксиоматику).
Ну и надо понимать, что "k8s не для бомжей" - это однозначно инструмент для тех, кто выигрывает что-то от его использования, потому что и сам кластер потребляет немало ресурсов, и его обслуживание и настройка чего-то стоят.
Если нагрузки вида "три контейнера, Postgres и API Gateway" - лучше посмотреть в сторону Heroku или GCP App Runner вкупе с managed DB.
Kubernetes разработан для компаний типа FAANG
удобно пользоваться и в небольших проектах, даже как "песочницей" для запуска POC контейнеров, а не судорожно метаться в поисках подходящего функционала в облаке.
Рынок Kubernetes раздроблен
как минимум kubectl apply доступен у всех облачных провайдеров
В Kubernetes слишком много частей
из коробки идет минимум необходимого функционала. в результате отпадает необходимость постоянно тянуть в кластер базовые фичи.
Kubernetes не гарантирует высокую доступность автоматически
есть механизмы, позволяющие разработчику распределять нагрузку. ждем ИИ, который по нагрузке научится сам балансировать поды по нодам )
Управлять Kubernetes вручную сложно.
прямая дорога к косякам в виде человеческого фактора. инфраструктура-как-код отлично подходит для автоматизации
У Kubernetes есть проблемы с мониторингом и оптимизацией производительности
возможно этого нет в ванильной поставке, но в облаке уже прикручены продвинутые инструменты для мониторинга и алертинга
Kubernetes всё сводит к коду
за что ему огромная благодарность. воспроизводимость результата - отсутствие проблем с поднятием однотипных конфигураций
Kubernetes хочет всё полностью контролировать
странное утверждение. контейнеры кастомные, как настроишь - так и будут работать
ждем ИИ, который по нагрузке научится сам балансировать поды по нодам )
А разве скедулер куба сейчас этого не умеет? Не знал…
Vmware DRS успешен полтора десятилетия.
Внезапно, тут в комментах пронаблюдался фанбой-феномен.
Несколько человек выразили возмущение недостаточно восторженными речами автора и ринулись его опровергать.
Как вообще можно опровергнуть чьи-то оценочные суждения, при ценностном расхождении (т.е. разнице в аксиоматике) с их автором?
Я старался предотвратить этот сценарий изначально, дав внизу ссылки на три "хардкорные" статьи.
Не вышло...
Вам в недочеты указывают, при том бесплатно, а вы "фанбой-феномен" -ом оправдываете.
У мнения - к8с сложно/дорого, есть право на жизнь в ограниченом количестве случаев, но вы же позиционируете мнение как общее утверждение.. а это не так.
Компьютерная наука относиться к естественным наукам, тут для выводов нужны исходные данные и аргументация. А если вы пришли со своим мнением за лайками, возможно вы ошиблись разделом или ресурсом.
Вам в недочеты указывают
Зачем мне — переводчику статьи — указывать её недочёты? Странная инициатива.
Но раз уж вы взялись их указывать, и именно мне, почему удивляетесь "ответочке" — тому, что и я взялся оценивать вашу собственную позицию?
Компьютерная наука относиться к естественным наукам
Наука, может, и относится, фанбойство нет.
Но я понимаю, что лично вы все свои "яйца" сложили в определённую "корзину"… к которой автор статьи отнёсся недостаточно бережно.
Оттого не смогли пройти мимо столь болезненной для вас чьей-то в интернете неправоты.
Сидим на ранчере уже как года 3, в целом очень даже неплохо, почти все можно делать через UI
8 проблем в архитектуре Kubernetes