Разработчики Kubernetes отвечают на вопросы пользователей Reddit

10 апреля на Reddit состоялась ^[1] акция AMA (Ask My Anything), в рамках которой 9 разработчиков Kubernetes со всего мира отвечали на вопросы интернет-пользователей. Всего было собрано 326 комментариев, и мы представляем перевод некоторых из них — содержащих ответы на наиболее интересные (на наш взгляд) вопросы.

Вопросы и ответы для удобства разбиты на условные категории. Итак:

Общие технические вопросы

Вопрос: Есть ли планы по добавлению сетевых лимитов к существующим ограничениям на CPU и RAM? Можем ли мы также ожидать автомасштабирование на основе сетевых ресурсов и без применения пользовательских метрик?

Ответ №1: На данный момент работы в планировщике по пропускной способности сети не ожидаются. Учитывая опыт Borg, я сомневаюсь, что такие ограничения будут работать, как того хотят пользователи. Более предпочтительный, на мой взгляд, путь — добавить что-то вроде диапазонов QoS, в которых трафик с большим приоритетом будет предпочтителен, но такая реализация ещё не спроектирована и в ней потребуется учитывать особенности большого числа плагинов, поддерживаемых в Kubernetes.

Уточнение: «Пропускная способность сети» не относится к числу других скалярных ресурсов. Вы не можете просто сказать: «У пода должна быть пропускная способность XX», — потому что доступная пропускная способность является свойством конкретного сетевого пути, а не единственной конечной точки. Таким образом, её необходимо описывать как свойство для пары («У этого пода должна быть пропускная способность XX до другого пода»), что быстро перестаёт подлежать описанию в случаях, выходящих за пределы нескольких подов, и требует глубокой сетевой интеграции для реализации. TL;DR: Нам нужно более творчески думать о пропускной способности сети.

Ответ №2: На самом деле, существуют ограничивающие пропускную способность аннотации (kubernetes.io/ingress-bandwidth и kubernetes.io/egress-bandwidth), применимые к подам, но сможет ли используемый сетевой плагин воспользоваться ими, зависит от индивидуального случая (например, встроенный плагин kubenet и плагин OpenShift SDN смогут, а насчёт остальных я не уверен).

Автомасштабирование без пользовательских метрик вряд ли возможно. Мы стараемся поддерживать в API получение непользовательских метрик (non-custom-metrics) ограниченным ресурсами, которые можно выразить лимитами и запросами, чтобы API не разрасталось и по массе других причин. Однако мы также надеемся лучше стабилизировать наименование некоторых метрик, экспортируемых сейчас kubelet, чтобы масштабирование сети с использованием возможностей пользовательских метрик стало проще.

Вопрос: Что вы думаете по поводу использования полностью отдельных кластеров для dev- и production-окружений вместо применения пространств имён для такого разделения? Что вы обычно встречаете в реальной жизни?

Ответ №1: Kubernetes создан под вдохновением от Borg, который имеет относительно небольшое количество кластеров на большом количестве машин. Такому направлению мне бы и хотелось следовать. При этом в жизни я встречаю обе эти модели (и их всевозможные промежуточные версии), и для них обычно есть хорошие обоснования. Upstream-ядра не идеальны в изоляции (приветствуется помощь). Команды по безопасности могут быть дотошны. Мультиарендность (multi-tenancy) в Kubernetes находится в ранней стадии развития. И так далее… Несмотря на всё это, думаю, что преимущества больших кластеров в конечном счёте перевесят все затраты.

Ответ №2: Это замечательный вопрос. Мне его задают практически каждую неделю. К сожалению, кластеры очень редко идентичны — слишком уж много переменных задействовано. Поэтому, внедряя очередной кластер, вы добавляете новые риски. Управлять кластером Kubernetes само по себе не так просто, а управление множеством конфликтующих кластеров — ещё более сложная задача.

Говоря же о том, что я вижу в реальных инсталляциях, думаю, множество кластеров для test/staging/dev — достаточно распространённый паттерн. В конечном счёте я согласна с тем, что не стоит запускать разрабатываемый код в том же месте, где и production. Пространства имён замечательны — вы удивитесь тому, насколько активнее их используют крупные облачные провайдеры, чем можно подумать.

Вопрос: Какие факторы влияют на максимально поддерживаемое количество подов на узел (сейчас это 100)?

Ответ: Масштабируемость Docker, настройки ядра, тестирование, пользовательские потребности.

Дополнение: Размер приложения, сложность приложения и насколько приложение требовательно к различным подсистемам. Я видел работающий production с 300-400 подов на узел, которые запускали на средних машинах (по 16-32 ядра) для небольших приложений.

Долгое время узким горлом была исполняемая среда контейнера (container runtime) — теперь же им обычно являются сеть и iptables, а ещё проблемным может быть хранилище.

Вопрос: Есть ли какие-то планы по улучшению инфраструктуры логирования? Сейчас складывается ощущение, что это лишь какое-то временное решение…

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

Вопрос: Какие из разрабатываемых прямо сейчас фич K8s волнуют вас больше всего?

Ответ №1: Лично для меня: локальные тома (я считаю, что это полезная работа настолько же, насколько ненавижу саму потребность в них), идентификация (всевозможная), переделка Ingress, обобщение API machinery. Я также импровизирую над тем, как развивать Services — в них наблюдается беспорядок.

Ответ №2: Их множество! Смотрите backlog по фичам ^[2].

«Дочерние»/связанные проекты

Вопрос: Существуют ли хорошие GUI-фронтенды для управления контейнерами и их оркестровки?

Ответ №1: Kubernetes Dashboard web UI ^[3] замечательно управляется с примитивами Kubernetes. У него есть страница «Create», где вы можете быстро развернуть новые Deployments, лишь заполнив форму.

У некоторых дистрибутивов (например, OpenShift и Tectonic) есть свои веб-интерфейсы. Kubernetic ^[4] — desktop GUI для Kubernetes, который выглядит похоже на Kubernetes Dashboard. Есть даже мобильное приложение Cabin ^[5]! Если же вы ищете чего-то более высокоуровневого и ориентированного на приложения, существует Kubeapps ^[6], через который устанавливаются и управляются Helm-чарты.

Ответ №2: Видели ли вы Weave Scope ^[7]?

Интерфейс Weave Scope

Вопрос: Ожидаете ли вы, что kubeadm ^[8] станет стандартным способом для создания/обновления кластеров (вне hosted-инсталляций)?

Ответ №1: Kubeadm — широко признанный метод развёртывания кластеров Kubernetes с большим количеством доступных опций. Хотя сообщество Kubernetes одновременно поддерживает множество решений для деплоя кластеров (в основном по той причине, что нет единого лучшего решения, закрывающего все потребности), Kubeadm ^[9] — подходящее решение, которое мы обычно предлагаем для деплоя готовых к production кластеров Kubernetes. Но повторюсь, что существует множество других решений для деплоя и управления кластерами, и у каждого из них есть свои плюсы и минусы. Kubeadm — лишь одно из них.

Ответ №2: Ставлю на kubeadm. И я действительно делаю на него ставку каждый день. Мы работаем над тем, чтобы подготовить его к широкой аудитории (GA) как можно скорее, и будет по-настоящему здорово наконец-то увидеть некоторую стабильность в самой фрагментированной (на мой взгляд) части Kubernetes — инсталляции.

Вопрос: Есть ли хорошие руководства/утилиты, чтобы посмотреть на мои существующие кластеры и увидеть, какие access controls мне необходимы перед тем, как активировать RBAC?

Ответ: Взгляните на audit2rbac ^[10] — позволяет просканировать лог audit на наличие неавторизованных запросов к API и создать соответствующие роли в RBAC для них.

Дополнение: Эта презентация ^[11] по audit2rbac — хорошая отправная точка.

Вопрос: Какой разрабатываемый проект/интеграция вас радует больше всего?

Ответ №1: Istio ^[12].

Ответ №2: Istio.

Ответ №3: Cluster API ^[13]! Ого, он наконец-то доступен!

Проект, сообщество

Вопрос: Посоветуйте хорошие ресурсы для тех, кто хочет стать активным контрибьютором в проект(ы) Kubernetes.

Ответ №1: Я всегда говорю, что тем, кто хочет внести свой вклад, нужно выбрать один бинарник (kubelet, controller manager, apiserver и т.п.) и начать читать с main(). Если у вас получится так читать час, не находя ничего, что стоит исправить (или хотя бы просто переименовать что-нибудь для лучшей читаемости), вы смотрите недостаточно внимательно.

Ответ №2: Начинать с main() — это и мой предпочтительный способ изучать что угодно. Кодовая база Kubernetes может показаться запутанной и огромной новым пользователям, поэтому я всегда напоминаю, что нет ничего плохого в добавлении нескольких fmt.Printf() в код, его повторной компиляции и запуске. Кроме того, запуск некоторых частей Kubernetes может быть значительно сложнее других. Иногда вам просто необходимо проявлять изобретательность — все мы оставили безумные куски кода, работая над различными частями системы. Bash — ваш друг.

Ответ №3: Начинать свой вклад в Kubernetes лучше всего с недавно созданного руководства Kubernetes Contributor guide ^[14]. Оно подробно описывает практически все аспекты внесения изменений в проект Kubernetes и является источником №1 для тех, кто хочет стать активным контрибьютором проекта. Кроме того, мы регулярно проводим сеансы #meet-our-contributors ^[15] (в Slack — прим. перев.), где вы можете задавать свои вопросы, связанные с процессом внесения изменений в Kubernetes.

Вопрос: Что является главной сложностью для Kubernetes в 2018 году?

Ответ №1: Готовность к enterprise. Это классическая проблема 80/20. Оставшаяся работа трудна, «грязна» и тяжела в хорошей оценке.

Вопрос-уточнение: Что это за 20%, которые так сложны?

Ответ-уточнение: Требования к безопасности. Интеграции с сетями. Длинный список возможностей, которые, как думают люди, им нужны. Интеграции с проведением аудита. Управление политиками. Соблюдение нормативных требований и регламенты. У каждого enterprise-заказчика накопленный годами «статус-кво» в окружении, с которым необходимо считаться, чтобы вас вообще начали всерьёз рассматривать.

Дополнение: Думаю, что частью проблемы готовности к enterprise является обучение людей, как эксплуатировать приложения в Kubernetes. То, как мы работаем с оркестрируемыми контейнерами, отличается от традиционных способов, используемых в enterprise сегодня. Обучение людей тому, что им нужно для успеха, — актуальное упущение.

Ответ №2: Люди. Управление проектом является судьбоносным: мы подошли к переломному моменту, в котором должны разобраться с тем, как масштабировать человеческий фактор. Над этим — управлением всеми людьми — нам и предстоит поработать.

Вопрос: Самый странный баг в K8s, который вы находили или исправляли?

Ответ №1: Возможно, что однократный сбор метрик определённого класса хранилища мог стать бесконечным, потому что используемый для этого способ забивал нижележащую прослойку хранения, что вызывало задержку в timestamps, что в свою очередь вызывало отсутствующие метрики в Heapster.

Ответ №2: Зависающий kube-proxy вызывал ошибки ICMP «no route to host», что привело нас в чертовское недоумение и к поискам проблемы по всему сетевому стеку кроме стороны получателя.

Другие проекты, экосистема

Вопрос: Какой бы совет вы дали команде Docker Swarm?

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

Дополнение: Docker Swarm — отличная технология, но, к сожалению, не всё в ней Open Source. Соглашусь, что своевременность и удача весьма значимы. Docker Swarm замечателен, и я хотел бы сделать совместный с Kubernetes проект, помогающий пользователям понять эти парадигмы в работе.

Вопрос: Какие другие проекты CNCF вас радуют больше всего? Есть ли другие существующие проекты, которые вы будете рады увидеть в их числе в скором времени?

Ответ №1: Так много вариантов. Думаю, Prometheus ^[16] и OpenTracing ^[17] великолепны. Ещё меня радует Envoy ^[18]. Долгое время я работал с CNI ^[19], так что будет несправедливо не упомянуть и его.

Ответ №2: Envoy, Jaeger ^[20], Prometheus.

Ответ №3: Рад видеть, что Telepresence ^[21] подал заявку ^[22] на присоединение к проектам CNCF. В последнее время появилось множество отличных инструментов для разработки для Kubernetes (а также Draft, Skaffold, freshpod) — жду, что эта область будет расти!

Ответ №4: kubicorn ^[23].

Список проектов CNCF, находящихся в стадии Incubating (по состоянию на 17 апреля 2018 г.)

Вопрос: Каковы планы по OpenShift после приобретения ^[24] CoreOS компанией Red Hat? Они будут объединены или поддерживаться отдельно?

Ответ: Мы ожидаем множество новостей по этому вопросу в скором времени. Цель — взять лучшее из Tectonic и соединить их с лучшим из OpenShift, а также обеспечить возможность использования всех этих частей напрямую с Kubernetes и упростить расширение Kubernetes с ними и создание приложений на этой базе.

И напоследок — наиболее запомнившийся ответ на вопрос о том, какие рекомендации разработчики могут дать средним и большим компаниям, мигрирующим на K8s: «Знайте, какие проблемы вы пытаетесь решить. Don't boil the ocean ^[25]».

P.S. от переводчика

Читайте также в нашем блоге:

• «Kubernetes 1.10: обзор основных новшеств ^[26]»;
• «Иллюстрированное руководство по устройству сети в Kubernetes ^[27]»;
• «Что происходит в Kubernetes при запуске kubectl run?»: часть 1 ^[28] и часть 2 ^[29];
• «Как на самом деле работает планировщик Kubernetes? ^[30]»;
• «Инфраструктура с Kubernetes как доступная услуга ^[31]»;
• «Наш опыт с Kubernetes в небольших проектах ^[32]» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes);
• «Истории успеха Kubernetes в production. Часть 8: Huawei ^[33]»;
• «Путеводитель CNCF по решениям Open Source (и не только) для cloud native ^[34]».

Автор: may-cat

Источник ^[35]