Натан Йелин (Natan Yellin) из robusta.dev опросил участников Kubernetes-сообщества на Reddit, что больше всего их раздражает в Kubernetes. Тред собрал более 90 ответов и комментариев. Как выяснилось, CrashLoopBackOff — далеко не самый раздражающий фактор. Куда больше пользователям не нравится, например, сложность Kubernetes и необходимость его изучать.
Ниже — самые возмутительные особенности K8s по мнению пользователей Reddit и разработчиков «Фланта».
Топ-10 раздражителей
1. «Некоторые поля у вновь созданных ресурсов неизменны. И нет простого способа понять, какие именно». (+113 на момент этой публикации.)
2. «Никто не знает, что с ним [Kubernetes] не так [когда возникает какая-то проблема], и разработчики не хотят изучать его». (+71)
3. «Вы не можете использовать kubectl, просто чтобы перечислить ВСЕ ресурсы (независимо от типа) в пространстве имен. Если пространство имен “зависнет” при удалении, никто не скажет вам, ПОЧЕМУ». (+36)
В треде к этому вопросу предлагают варианты решения проблемы.
4. «Количество связанных [с K8s] проектов и их безумные (“crazy”) названия, в которых очень мало смысла». (+28)
«You mean Krazy naming?» — уточняет FiringSquad1080.
5. «На автомате использую команду kubectl get logs вместо правильной kubectl logs :/». (+22)
«Эта проблема должна быть на первом месте», — ответил автор треда.
6. «Бесконечная экосистема абстракции инструментов. Как только у вас есть что-то, что работает, появляются другие инструменты, которые делают почти то же самое, но, возможно, чуть больше». (+20)
7. «Набирать “Kubernetes” в телефоне». (+16)
8. «Для многих вещей нет разумных значений по умолчанию, и их невозможно добавить автоматически. Хотите, чтобы у всех созданных пространств имен был базовый PodSecurity по умолчанию? Admission controller! Хотите, чтобы у всех ролей были разумные разрешения по умолчанию? Admission controller! Хотите, чтобы у всех пространств имен была настроена NetworkPolicy по умолчанию? Механизм политик! Бррр».
9. «Всё с kubectl config. Приходится использовать сторонний инструмент kubectx». (+14)
Про kubectx мы рассказывали 4+ года назад, а про утилиту fubectl, упомянутую в комментариях к этому пункту, — в прошлом году.
10. «Замена аргумента get на describe». (+11)
А легендарный CrashLoopBackOff сдает позиции: в топе его не оказалось…
Что не нравится нашим инженерам
Вот что больше всего раздражает команду разработки Kubernetes-платформы Deckhouse.
Евгений Шевченко:
«Когда у тебя есть несколько логически связанных штук, приходится делать по несколько запросов, чтобы связать вместе информацию из разных углов.
Например, чтобы посмотреть IP узла, на котором находится конкретный Pod, требуется два действия: посмотреть в Pod, чтобы увидеть имя узла, а потом — в узел, чтобы увидеть его адрес. Но бывают цепочки и длиннее. Например, с cert-manager’ом.
Вот если бы kubectl умел делать
join… Oh shi-, у меня есть идея для Open Source-проекта».
Андрей Квапил:
«Есть различные недокументированные особенности. Например, podSpec в большинстве случаев иммутабельна (неизменна), но обновить
imageу запущенного Pod’а всё же можно. А в именовании Docker-образов типаregistry.io/image:tag@sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855нет никакого смысла, потому что тег при указании дайджеста всегда игнорируется. Но не сказать, что это меня сильно бесит».
Максим Набоких:
«Бесят:
1. fejta-bot, который проверяет "свежесть" issues;
А что больше всего бесит в Kubernetes вас?
Делитесь накипевшим в опросе и комментариях!
P.S.
Читайте также в нашем блоге:
Комментарии (25)
amarkevich
04.02.2022 12:26+2странный дизайн - грабли при траблшутинге: Kubernetes events will disappear after one hour
bm13kk
04.02.2022 15:12+1Вообще подход к траблшутингу. Инфу вроде и можно достать. Но надо бегать по куче разных запросов.
Дикая магия. Плагины к иде то работают, то нет. А почему - вообще не понятно.
Self_Perfection
04.02.2022 15:44+5Его делают люди, которые похоже не умеют в линуксы. Вот ставим например официальный deb пакет c kubectl. А там внезапно только один бинарник kubectl! man страниц нет, bash-completion нет. Они там с Луны свалились?
Inlore
04.02.2022 16:04Не думаю, что пакеты для дистров собирают разработчики кубера...
Self_Perfection
04.02.2022 16:20+2Пакет с их вебсайта https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-using-native-package-management
И при этом ниже на веб сайте пишут, что нужно сплясать вприсядку чтобы bash-completion получить. Вот видимо прямо те же люди, которые пакет собирают.
driusha
04.02.2022 15:49+4Очень сложно разобраться, почему Pod не может заскедулиться на ноду. В эвентах скедулер пишет про то, что на пятнадцати нодах не хватает CPU, хотя он бы на эти ноды и так не попал из-за nodeSelector.
Nikita_Danilov
04.02.2022 19:38+14Уважаемые, можете, пожалуйста, объяснить – как вообще инженерное сообщество могло принять в качестве стандарта подобный инструмент, обладающим таким количеством косяков и нелогичных моментов?
Регулярно вижу статьи о том, как сложно понять причины падения кубера, причины падения подов, причины неработоспособности скейлинга, причины чего бы то ни было.
Каковы прогнозы - оно будет когда-нибудь просто работать? Это наше будущее или надо ждать перерождения? 8 лет вроде уже проекту.
TimsTims
05.02.2022 00:51+5А вы думаете весь софт - это идеально написанный и вылизанный код? Сейчас "Эра MVP", всё что изобретается - лишь бы работало хоть как-нибудь. Добавляем сюда модный CICD, когда вчерашний админы вдруг начинают свою работу автоматизировать, и получаем тонну говнософта, который автоматизирует другой говнософт. Примерно тоже самое происзошло и с frontend-ом и его сборщиками. Вот руки у людей добрались и до кубера.
pepemon
05.02.2022 14:02когда вчерашний админы вдруг начинают свою работу автоматизировать
Почему вдруг? Считаете, что доставка приложения до окружений должна обязательно быть ручной?
TimsTims
05.02.2022 16:17-1"Вдруг" - потому что раньше обходились bash-скриптами, а потом резко (вдруг) все начали создавать целую кучу инструментов. Так и появился зоопарк для зоопарка систем и программ. Когда всё это видишь, то понимаешь, что всё это создавалось в спешке, очень разными людьми, для очень разных задач, и почему-то это всё как-то работает вместе.
ugenk
05.02.2022 01:44+3Come on, кубер сделали бесплатным для того, что бы вы помучались с ним, и пришли в гугл клауд, где "все тот же кубер, только не глючит"
KarmicDude
05.02.2022 04:30+3Ну предложите полновесную альтернативу кубу?)
Понимание как траблшутить куба придет с опытом. Сама по себе система большая и сложная, много нюансов, тонна доки, высокий порог вхождения. Как результат, не всегда глубокие и полноценные компетенции у тех, кто деплоит приложения не соблюдая хорошие практики, например, в ограничении ресурсов или что-то ломает не правильной конфигурацией; аналогично у тех, кто пытается это потом чинить могут быть недостаточный опыт и навыки в администрировании куба и с разбегу может ничего не получаться.
Кажется это нормально и куб в прод надо выбирать командам с четким пониманием зачем он и для чего, точно зная, что он им нужен и, разумеется, обладая компетенциями в его обслуживании или полагаясь на хорошие менедж решения и внешние команды, оказывающие помощь в администрировании куба.
Nikita_Danilov
05.02.2022 20:32Зависит от понимания "полновесной". Я признаюсь, у меня в основном опыт работы с .NET поверх on-premise серверов или виртуальных машин в облаках. Я не знаком с ситуацией когда есть простаивающие мощности и необходимо жонглировать контейнерами между серверами. Обычно наоборот, требуется выжать максимум из имеющихся серверов, для чего стараешься точно знать:
Сколько экземпляров сервисов обслуживает запросы пользователей, чтобы планировать допустимую нагрузку для системы целиком, ведь там позади могут быть полуживые внутренние системы плевавшие на твой автоскейлинг.
Характер потребления ресурсов сервисами, чтобы знать какие можно разместить на каких группах серверов рядом, а какие необходимо держать отдельно, ведь дело не в реакции на показатели, а понимании как себя ведёт именно этот кусок системы.
Для настройки серверов и раскатки сервисов использовались Configuration-as-a-Code, PS-скрипты и PS DSC, Bash скрипты, различные джобберы типа Jenkins/TeamCity/TFS ради визуализации. Хотя справедливости ради пользовал Octopus Deploy также, он тот ещё комбайн, но можно и без него. Главное, ты точно знаешь чем будет занят конкретный сервер или группа серверов, а уж инструменты были плюс-минус одинаковые судя по рассказам.
Если говорить про эффективное распределение ресурсов по дата-центру, с перемешиванием десятков-сотен экземпляров сервисов на десятках-сотнях серверов:
Разве встроенные AWS ECS и Azure App Service не дают необходимого функционала раскатки контейнеров? Они же созданы ради этого, имеют встроенный скейлинг, управление количеством экземпляров.
Grigor60
06.02.2022 08:29+1Вы абсолютно правы, большинство людей не должны деплоить в кубер. Есть милион более простых инструментов. С гораздо меньшим количеством функций. Но для 99% веб серверов или backed систем работающих по event bus это отличные решения.
Проблема кубера его пихают иногда куда не надо.
Например когда я говорю про без альтернативность кубера - я имею ввиду что мне нужно запустить 100 веб сервисом с 3мя разными подходами к autoscale.
А ещё я хочу запускать spark и flink и ml в одной платформе. Что бы тот же autoscale переимпользовать, но с нюансами.
А ещё я хочу иметь общий инструмент для security и network policy apply для все своих сервисом, compute engine, kafka и ml framework. Да да у нас отдельная команда secops, которая пишет opa security policy для 50 других команд.
А ещё я хочу общий инструмент что бы все выше перечисленые Тулы можно было запускать на spot. Или легко добавлять управление ebs/ssd в некоторые сервисом, но не во все.
А ещё я лично, люблю экзотические юзкейзы автоматизировать. Например у на 70 кластеров кафки в каждом не меньше 60 нод. И полностью автоматическая система rebalance/backup/ scale/alert/disk extension.
А ещё я забыл про service discovery. Есть милион альтернатив, но я хочу что бы оно с моими сетями интегрировалось, а не везде consul/zookeeper пихать. Что не так уж просто.
Вот и подумайте сколько всего мы раньше писали и костыли в том числе на terraform и chef/puppet/ansible/etc. И как потом сделать на этих технологиях сранный rolling upgrade сложной системе, что бы не больше 5 инстансов было в перезапуска.
А я не говорю про drain and shutdown, если hardvare/vm degradate случился.
Но и это не все, главное теперь есть чёткий протокол/api между developer которые пишут код и реализовуют gracefull shutdown, restart, exactly once guarantee, ha в своём коде и ops которые управляют сетями, дисками, load balancers, security permissions и прочее.
И да я не девопс, я разработчик и меня не раз бесило что я не могу нормально backup автоматический сделать или не знаю какой timeout на sigkill.
markowww
05.02.2022 04:32Рискну предположить, что примерно так же, как Chrome захватил рынок браузеров: огромные ресурсы на первоначальное продвижение. Клиенты хотят модный кубер, хотя они "винчестер от парабеллума" отличить не могут.
С другой стороны, на этом прям целая отрась выросла: где раньше нужна была пара админов, теперь целый отдел девопсов или managed решение от <выберите любого обачного провайдера>, все довольны :)
pepemon
05.02.2022 14:01+10Я деплоил и маленькие, и большие проекты при помощи и Capistrano, и голого Ansible, и Ansible+Docker, и
docker-compose, и Swarm был, и скрипты самописные были, и скриптовый клей для всего сразу был.Kubernetes сложно, сразу пирог из абстракций, много движущихся частей, но, несмотря на всю сложность, это лучшее из всего что я использовал для развертывания бизнес-приложений. Haters gonna hate, но даже если убрать весь хайп, данная система решает проблему развертываний в разные окружения + Day-2 operations элегантнее всего. Да, такая махина и элегантнее всего. Всё так уныло в мире автоматического развертывания. Альтернативой на проект из ~10 сервисов может быть большой отдел "админов", руками накликивающие в UI условных Tomcat/JBoss. Или же обслуживающих ещё более монструозную какую-нибудь закрытую "платформу развертывания".
С Kubernetes будет достаточно пары компетентных инженеров. Даже для суровых энтерпрайзных Java-приложений. Спасибо Red Hat.
mixir
05.02.2022 09:46Высокий порог входа k8s, отладка операторов, отладка сети внутри, отладка крэша подов. Ох, это должно было быть приключение на 20 минут, а не на 2 недели...
pepemon
05.02.2022 14:07Сколько лет индустрии, столько лет льются влажные мечты о деплое одной кнопкой и чтобы всё само работало. Не бывает так, Beanstalk был близко, но всё равно нет. И это managed решение при чём.
toxicdream
05.02.2022 11:20+1Инструмент который создаёт больше проблем чем решает должен или эволюционировать, или умереть
shurup
05.02.2022 11:41А как померить, что проблем больше, чем пользы? Растущее сообщество и количество внедрений разве не является доказательством большей пользы?
mIK_LH
05.02.2022 18:08+12 дня было убито на поиски причины. Один под который имел подключение к rabbitmq завис в состоянии terminating. Удалён был по команде "k delete pod -force". Под благополучно удалился. Через 2 дня мы заметили что из реббита куда-то начали пропадать сообщения. В реббите в списке подключенных клиентов был один ip адрес который не принадлежал ни одному поду, и вообще при попытках выяснить что это за айпишник кубернетис не показывал ни один ресурс который бы его использовал. Long story short - оказывается кубернетис сам под как ресурс прибил, а вот контейнер в сломаном состоянии остался висеть и кушать сообщения из канала(реббит был в самом кластере), но при этом к базе которая была ресурсом облака он соеденине потерял и не мог эти сообщения нормально запроцессить. Выяснить что за фигня происходит удалось только тогда когда я додумался зайти в шелл на всех нодах и выполнить docker ps где я и увидел этот контейнер.
ZaitsXL
05.02.2022 19:42+1CrashLoopBackOff? А NullPointerException и вообще любые сообщения об ошибках людей тоже раздражают?
Envek
Почему куб такой сложный? Потому что это по сути целая операционная система для деплоя приложений, которая пытается абстрагировать вообще все детали нижележащих облаков или железок: https://buttondown.email/nelhage/archive/two-reasons-kubernetes-is-so-complex/