10 апреля на Reddit состоялась акция 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 по фичам.
«Дочерние»/связанные проекты
Вопрос: Существуют ли хорошие GUI-фронтенды для управления контейнерами и их оркестровки?
Ответ №1: Kubernetes Dashboard web UI замечательно управляется с примитивами Kubernetes. У него есть страница «Create», где вы можете быстро развернуть новые Deployments, лишь заполнив форму.
У некоторых дистрибутивов (например, OpenShift и Tectonic) есть свои веб-интерфейсы. Kubernetic — desktop GUI для Kubernetes, который выглядит похоже на Kubernetes Dashboard. Есть даже мобильное приложение Cabin! Если же вы ищете чего-то более высокоуровневого и ориентированного на приложения, существует Kubeapps, через который устанавливаются и управляются Helm-чарты.
Ответ №2: Видели ли вы Weave Scope?
Интерфейс Weave Scope
Вопрос: Ожидаете ли вы, что kubeadm станет стандартным способом для создания/обновления кластеров (вне hosted-инсталляций)?
Ответ №1: Kubeadm — широко признанный метод развёртывания кластеров Kubernetes с большим количеством доступных опций. Хотя сообщество Kubernetes одновременно поддерживает множество решений для деплоя кластеров (в основном по той причине, что нет единого лучшего решения, закрывающего все потребности), Kubeadm — подходящее решение, которое мы обычно предлагаем для деплоя готовых к production кластеров Kubernetes. Но повторюсь, что существует множество других решений для деплоя и управления кластерами, и у каждого из них есть свои плюсы и минусы. Kubeadm — лишь одно из них.
Ответ №2: Ставлю на kubeadm. И я действительно делаю на него ставку каждый день. Мы работаем над тем, чтобы подготовить его к широкой аудитории (GA) как можно скорее, и будет по-настоящему здорово наконец-то увидеть некоторую стабильность в самой фрагментированной (на мой взгляд) части Kubernetes — инсталляции.
Вопрос: Есть ли хорошие руководства/утилиты, чтобы посмотреть на мои существующие кластеры и увидеть, какие access controls мне необходимы перед тем, как активировать RBAC?
Ответ: Взгляните на audit2rbac — позволяет просканировать лог audit на наличие неавторизованных запросов к API и создать соответствующие роли в RBAC для них.
Дополнение: Эта презентация по audit2rbac — хорошая отправная точка.
Вопрос: Какой разрабатываемый проект/интеграция вас радует больше всего?
Ответ №1: Istio.
Ответ №2: Istio.
Ответ №3: Cluster API! Ого, он наконец-то доступен!
Проект, сообщество
Вопрос: Посоветуйте хорошие ресурсы для тех, кто хочет стать активным контрибьютором в проект(ы) Kubernetes.
Ответ №1: Я всегда говорю, что тем, кто хочет внести свой вклад, нужно выбрать один бинарник (kubelet, controller manager, apiserver и т.п.) и начать читать с main(). Если у вас получится так читать час, не находя ничего, что стоит исправить (или хотя бы просто переименовать что-нибудь для лучшей читаемости), вы смотрите недостаточно внимательно.
Ответ №2: Начинать с main() — это и мой предпочтительный способ изучать что угодно. Кодовая база Kubernetes может показаться запутанной и огромной новым пользователям, поэтому я всегда напоминаю, что нет ничего плохого в добавлении нескольких fmt.Printf() в код, его повторной компиляции и запуске. Кроме того, запуск некоторых частей Kubernetes может быть значительно сложнее других. Иногда вам просто необходимо проявлять изобретательность — все мы оставили безумные куски кода, работая над различными частями системы. Bash — ваш друг.
Ответ №3: Начинать свой вклад в Kubernetes лучше всего с недавно созданного руководства Kubernetes Contributor guide. Оно подробно описывает практически все аспекты внесения изменений в проект Kubernetes и является источником №1 для тех, кто хочет стать активным контрибьютором проекта. Кроме того, мы регулярно проводим сеансы #meet-our-contributors (в 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 и OpenTracing великолепны. Ещё меня радует Envoy. Долгое время я работал с CNI, так что будет несправедливо не упомянуть и его.
Ответ №2: Envoy, Jaeger, Prometheus.
Ответ №3: Рад видеть, что Telepresence подал заявку на присоединение к проектам CNCF. В последнее время появилось множество отличных инструментов для разработки для Kubernetes (а также Draft, Skaffold, freshpod) — жду, что эта область будет расти!
Ответ №4: kubicorn.
Список проектов CNCF, находящихся в стадии Incubating (по состоянию на 17 апреля 2018 г.)
Вопрос: Каковы планы по OpenShift после приобретения CoreOS компанией Red Hat? Они будут объединены или поддерживаться отдельно?
Ответ: Мы ожидаем множество новостей по этому вопросу в скором времени. Цель — взять лучшее из Tectonic и соединить их с лучшим из OpenShift, а также обеспечить возможность использования всех этих частей напрямую с Kubernetes и упростить расширение Kubernetes с ними и создание приложений на этой базе.
И напоследок — наиболее запомнившийся ответ на вопрос о том, какие рекомендации разработчики могут дать средним и большим компаниям, мигрирующим на K8s: «Знайте, какие проблемы вы пытаетесь решить. Don't boil the ocean».
P.S. от переводчика
Читайте также в нашем блоге:
- «Kubernetes 1.10: обзор основных новшеств»;
- «Иллюстрированное руководство по устройству сети в Kubernetes»;
- «Что происходит в Kubernetes при запуске kubectl run?»: часть 1 и часть 2;
- «Как на самом деле работает планировщик Kubernetes?»;
- «Инфраструктура с Kubernetes как доступная услуга»;
- «Наш опыт с Kubernetes в небольших проектах» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes);
- «Истории успеха Kubernetes в production. Часть 8: Huawei»;
- «Путеводитель CNCF по решениям Open Source (и не только) для cloud native».
Автор: may-cat
