Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

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

Рынок должен начать смотреть на Kubernetes как на Linux Kernel. Что я имею в виду? В трезвом уме сисадмин маленькой или средней компании вряд ли станет говорить на работе, что не нужно использовать дистрибутив Linux — мол, сейчас он возьмет ядро и соберет свой дистрибутив. Так просто не принято: все понимают, что надо выбирать готовый дистрибутив, подходящий под конкретный набор задач. Да, есть и универсальные дистрибутивы, которые более-менее успешно могут использоваться под разные задачи, однако помимо дистрибутивов общего пользования (generic purpose), есть и куча специфических дистрибутивов вроде того же Talos Linux, Kali Linux, VyOS, DSL, SLAX, которые заточены под конкретные виды задач.
. . .
Многие ли инженеры четко и полноценно понимают, что там скрыто в недрах Linux Kernel, какие крутилки ядра применены в том или ином дистрибутиве Linux? А все потому, что рынок принял дистрибутив как некий эталон юнита с минимальной единицей бизнес-ценности, дробить эту абстракцию до уровня ядра или отдельных компонентов ядра просто нет смысла. Конечно, крупные компании собирают свои дистрибутивы — например, тот же Microsoft уже в новой технологической истории сделал Azure Linux. Однако большинству компаний это не нужно.

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

- Рабочие группы CNCF (TAG App Delivery, Technical Oversight Committee, а также мейнтейнеры и главные спонсоры Kubernetes) должны запустить дискуссии по этой теме. Обсудить перспективы и угрозы, в итоге выработав некую продуктовую стратегию. Потому что в итоге Kubernetes как продукт должен претерпеть достаточно серьезные изменения — одно дело, когда разрабатывается полноценное ПО и совсем другое, когда разрабатывается компонент, пусть и центральный. 

- TAG App Delivery, Technical Oversight Committee должны начать говорить с рынком и транслировать в него послание о том, что необходимо много платформ, чтобы были альтернативы. А также создать документы и технические условия (или инициировать формирование новой рабочей группы), позволяющие максимально упростить процесс создания платформы (собственно, Kubernetes как продукт должен сфокусироваться именно на том, что он становится центральным компонентом сторонней платформы).

- Талантливые и предприимчивые инженеры, а также часть тех компаний, которые разрабатывали свои внутренние платформы, должны переключиться на разработку публичных платформ (свободных или проприетарных — это уже вопрос второй, главное, чтобы были альтернативы). 

- Крупные игроки различных рынков должны начать объединяться вокруг различных платформ или создавать новые, которые максимально соответствуют требованиям конкретного рынка и заточены под него.

- CNCF и другие open source-организации должны брать такие проекты под свое крыло и помогать им развиваться, а также выделять под продвижение такого подхода временные слоты на ключевых конференциях, которые они организуют (речь, например, о Kubecon).

The ROM doesn’t handle DNS, it just has a command to ask the mobile phone to lookup a domain for it and send an IP address back.

Сегодня официально выпустили новую версию Kubernetes — 1.32. Среди главных нововведений — возможность задавать ресурсы на уровне пода, асинхронное вытеснение подов планировщиком, нулевое ожидание (sleep) для PreStop-хуков, новые эндпоинты /statusz и /flagz для ключевых компонентов K8s, более гранулярная авторизация для API kubelet’а, внешнее управление ключами сервисных учётных записей и специальная функция, с помощью которой плагины смогут подсказывать планировщику, когда стоит повторить попытку планирования.

В России полностью решена проблема с импортозамещением мощных вычислительных ресурсов, заявил глава "Ростелекома" Михаил Осеевский, выступая в Совете Федерации.

"Хочу доложить, что сегодня страна чувствует себя достаточно уверенно. У нас полностью решена проблема импортозамещения мощных вычислительных ресурсов, серверов, систем хранения [данных]", - сказал топ-менеджер.

Защита конечных точек: стратегия новой реальности

Расскажем о будущем пользовательских устройств, переходе на open-source ОС на базе Linux, выстроенных процессах безопасности и особенностях архитектуры нового решения

Мы размышляли, как управлять всем этим парком. Первое, что пришло в голову, — стандартные решения, такие как Ansible, Puppet, SaltStack, Chef. Вариантов много, и каждый из них по своему хорош, но сначала нужно определиться с нашими требованиями.

Мы старались сформулировать требования по аналогии с другими большими устоявшимися MDM-системами: SCCM, Jamf, Intune. Нам нужны:

1. Декларированный подход к управлению конфигурациями. Хотим видеть конечное решение конфигураций нашей системы, а не просто последовательное выполнение команд без финального результата.

2. Масштабируемость и отказоустойчивость — эти параметры обязательны.

3. Возможность сбора различных фактов о системе, потому что мы хотим вести статистику по всему парку, собирать информацию об установленных программах и другую интересную нам информацию.

4. Возможность задавать конкретные политики безопасности и обеспечивать их выполнение на всех управляемых нами устройствах, что критически важно в большой и сложной инфраструктуре.

5. Большое сообщество, которое следит за обновлениями и безопасностью.
Это плюс для любой системы: быстрый выпуск фиксов багов, много разных модулей для удобства управления.

6. И нужно выбирать то, что нравится, потому что потом самим же с этим работать.

Выбор пал на Puppet, потому что он использует pull-модель и у него свой центр сертификации. Масштабируемость инфраструктуры может быть как горизонтальная, так и вертикальная, что очень удобно. А если рядом установить Foreman, получится полноценная система управления с графическим интерфейсом, и все это в последствии можно кастомизировать под себя.