Под капотом: Kubernetes версии 1.6 здесь
Kubernetes — одно из самых быстрорастущих программных решений с открытым исходным кодом. Kubernetes, изначально поддерживаемый более чем 15-летним опытом исследований и разработок Google, стал стандартом для управления контейнерами в масштабе. И вот вышла новая версия. Версия 1.6 уникальна в том смысле, что впервые вся команда по выпуску состоит в основном из людей, не являющихся сотрудниками Google. Тот факт, что этот выпуск можно отнести к таким компаниям, как CoreOS, Microsoft, Red Hat, Heptio, Mirantis и Google, свидетельствует о том, насколько далеко и широко выросло сообщество Kubernetes.
Стабильность
Основное внимание в версии 1.6 уделяется стабильности. Апарна Синха, менеджер проекта Google по Kubernetes, заявила на недавнем KubeCon в Берлине, что это решение было принято всем сообществом Kubernetes, и оно отразится и на будущих выпусках. Решение состоит в том, чтобы сосредоточиться на перемещении существующих функций более низкого уровня из альфа-версии в бета-версию и в стабильную версию, а не вводить новые функции. В версии 1.6 более 20 функций были переведены из альфа-версии в стабильную версию с более чем 32 изменениями функций.
Большие кластеры
Масштабируемость Kubernetes сравнивается с довольно строгими SLO (целями уровня обслуживания), 99 процентов всех вызовов API возвращаются в течение одной секунды, а 99 процентов модулей и их контейнеров запускаются в течение пяти секунд. Этот SLO теперь поддерживает кластеры на 5000 узлов (150 000 pod). Это 150-процентное увеличение общего размера кластера и хорошая новость для крупных предприятий, которые ищут подтверждение концепции. Для непосвященных кластер — это набор узлов (физических или виртуальных машин), на которых запущены агенты Kubernetes.
и т. д. 3.0
Etcd — это облегченное распределенное хранилище ключей и значений, которое может быть распределено по нескольким узлам, а увеличение размера кластера связано с переходом на etcd 3.0. Kubernetes использует etcd, разработанный командой CoreOs для хранения данных конфигурации, которые могут использоваться каждым узлом в кластере. Etcd заботится о хранении и репликации данных, используемых Kubernetes, во всем кластере, а также может восстанавливаться после сбоя оборудования и сетевых разделов. Etcd 3.0 — это первый стабильный выпуск модели данных и API etcd3, а также контроллер по умолчанию, включенный в Kubernetes 1.6. Версия 3.0 была самостоятельно разработана CoreOS для облегчения масштабирования до 5000 узлов.
Версия 1.6 также содержит ряд обновлений, связанных с автоматизацией хранения. Предоставление динамического хранилища используется для автоматизации и управления жизненным циклом хранилища и особенно полезно для использования приложений с отслеживанием состояния, когда вы хотите убедиться, что хранилище всегда доступно. В версии 1.6 пользователи теперь могут пользоваться преимуществами динамического выделения ресурсов хранения без необходимости выполнять какую-либо настройку вручную.
Федерация и мультиоблако
Да, 5000 узлов — это много, и, похоже, сообщество единодушно считает, что обслуживание пользователей там, где они есть, с малой задержкой — это приоритет, а не дальнейшее увеличение. Используйте мультиоблако, которое не только снижает затраты на инфраструктуру, но и повышает доступность, производительность, безопасность и управление аварийными ситуациями. Для пользователей, которым необходимо масштабирование до более чем 5000 узлов, федерация позволяет объединять несколько кластеров и обращаться к ним с помощью одного API. Среди обновлений федерации в версии 1.6 — утилита командной строки kubefed и каскадное удаление федеративных ресурсов. Утилита командной строки kubefed, которая только что вышла в бета-версию, теперь может автоматически настраивать kube-dns при присоединении к кластерам. Каскадное удаление означает, что когда вы удаляете ресурс из федерации, соответствующие ресурсы во всех кластерах также удаляются.
RBAC
Еще одним нововведением стало то, что RBAC (управление доступом на основе ролей) теперь перешло в бета-версию, что означает, что пользователям могут быть предоставлены определенные разрешения в отношении доступа к различным частям вашего кластера. Еще одна особенность — детальный контроль над тем, что люди могут делать в кластере. Без RBAC каждый модуль в кластере имеет примерно такой же уровень авторизации, как и любой другой модуль, поэтому трудно различать рабочие нагрузки. Переход на RBAC настолько важен, что команда разработчиков сравнивает его с переходом от DOS к UNIX, когда у всех был равный доступ в DOS, но UNIX вышла с разрешениями, специфичными для пользователя.
Нет блокировки контейнера
Вы не можете думать о Kubernetes и не иметь в голове образы Docker — кажется, что эти две вещи почти неразделимы. Но версия 1.6 призвана изменить это. Все предыдущие версии Kubernetes были привязаны к среде выполнения контейнеров Docker, но особенность версии 1.6 заключается в том, что среды выполнения контейнеров теперь подключаемые и могут быть заменены по желанию.
Теперь клиенты могут использовать среды выполнения контейнеров, отличные от Docker, например rkt или CRI-O. Это долгожданное изменение для сообщества открытого исходного кода, которое ненавидит привязку к поставщику. Это также отличная новость для тех, кто не использует Docker.
Привязка к узлам, антипривязка и индивидуальное планирование
Многие мощные инструменты планирования также перешли в бета-версию с этим выпуском, и node-affinity — один из них. Node-affinity позволяет вам определить для каждого модуля, какой тип узла вы хотите запланировать для каждого модуля. Примером может служить планирование модулей только на узлах с твердотельными накопителями или узлами с GPUS или узлами в определенном географическом местоположении. Вторая часть этого инструмента называется анти-аффинити, и эта функция позволяет планировать модули относительно других модулей, чтобы их можно было запрограммировать либо отталкивать, либо притягивать друг друга на основе пользовательских определений. Примером антиаффинности может быть, если вы хотите разделить модули или избежать совместного планирования антагонистических сервисов в одном модуле.
Еще одна функция, которая переходит в бета-версию, называется «загрязнения и допуски» и позволяет исключать модули из определенных узлов. Например, модуль, которому не требуется доступ к графическому процессору, будет исключен из всех модулей с графическим процессором. И последнее, но не менее важное: несколько планировщиков также перешли в бета-версию в этом выпуске. Это позволяет не только создавать собственные расписания, но и заменять планировщик на свой собственный.
Объявления CoreOS
Наряду с Kubernetes, инструменты, построенные вокруг него, также растут, и команда CoreOS, разработавшая etcd3 для этого релиза, а также фактически возглавившая этот релиз, сидит в VIP-ложе Kubernetes. Наряду с версией 1.6 CoreOS объявила, что ее решение Tectonic для Kubernetes теперь поддерживает «голое железо», AWS и предварительную поддержку как для Azure, так и для OpenStack. Еще одно обновление — расширение реестра образов контейнеров Quay для управления и поддержки полных приложений Kubernetes.
В свете всех недавних объявлений Kubernetes, не только от CoreO, Google или Docker, но и от Red Hat, SUSE, IBM, HPE и многих других, наше внимание привлекает то, что все предприятие заинтересовано в оркестровке контейнеров в большой путь. Имея доказательства того, что DevOps и микросервисная архитектура снижают риски и улучшают качество, это всего лишь вопрос времени, когда компании будут вынуждены адаптироваться или устареют. Интернет полон тематических исследований от стартапов в Штатах до компаний из списка Fortune 500 в Китае и банков в Англии, и, вероятно, со времен Linux не было такого большого программного обеспечения с открытым исходным кодом, как Kubernetes.
Как и Linux, Kubernetes завоевал беспрецедентную популярность и поддержку не только со стороны сообщества разработчиков открытого исходного кода, но и со стороны крупных компаний. Дэн Гиллеспи из CoreOS возглавил команду по выпуску версии 1.6, и заслуга Google в том, что она позволила добиться такой прозрачности. Передача бразды правления кому-то другому, чтобы возглавить и управлять выпуском, соответствует истинному духу программного обеспечения с открытым исходным кодом и способствует еще большему доверию среди пользователей. Благодаря повышенной масштабируемости, снижению затрат и поддержке многооблачных сред вскоре люди начнут задаваться вопросом, почему они еще не перешли на новый уровень.