💎 Виртуализация — помогает управлять надёжностью, затратами и гибкостью инфраструктуры.

В ней есть основные функции, которые напрямую влияют на ключевые показатели:
SLA — фактическая доступность сервисов;
RTO/RPO — скорость восстановления и допустимые потери данных;
TCO — совокупная стоимость владения.

🧬 Разберем эти термины в виде краткого глоссария.

🟣 Live Migration (миграция на лету)

Перенос работающей ВМ между физическими серверами без остановки. Позволяет проводить плановое обслуживание и ребалансировку нагрузки без остановки сервисов.

*Снижается количество плановых простоев и соблюдается SLA.

🟣 High Availability (HA)

Автоматический перезапуск ВМ на другом узле при отказе. Сокращает простои из-за поломок оборудования.

*Предсказуемый RTO и выполнение SLA без ручных вмешательств.

🟣 Fault Tolerance (FT)

Параллельный «зеркальный» экземпляр ВМ с мгновенным переключением. Нужен там, где нельзя потерять ни секунды работы или транзакции.

*Исключаются простои для самых критичных систем, снижаются финансовые и репутационные риски.

🟣 Snapshot (снимок состояния)

Фиксация состояния ВМ в конкретный момент времени. Позволяет мгновенно создать "точку отката" перед рискованными операциями (обновления, изменение конфигураций) и быстро вернуться к ней в случае сбоя.

*Снижается время на восстановление после инцидентов (RTO) и риски при внесении изменений.

🟣 vSwitch и оверлеи (VXLAN/GENEVE)

Программные сети для связности и сегментации сервисов. Изменения выполняются политиками, без перестройки «железа».

*Быстрее запускаются новые среды и ограничивается влияние инцидентов.

🟣 Thin / Thick Provisioning

Способ выделять дисковое место: сразу целиком (thick) или по мере роста (thin). Thick — про стабильную производительность. Thin — про экономию ёмкости и плотность.

*Выбор нужного баланса цены и предсказуемости.

🟣 Scheduler / DRS

Автоматическое распределение и балансировка виртуальных машин между узлами кластера. Обеспечивает равномерное потребление ресурсов железа, предотвращая перегрузку отдельных серверов.

*Повышается общая эффективность использования инфраструктуры и снижается необходимость ручного вмешательства.

🟣 Ресурсные политики (Reservations / Limits / Shares)

Правила приоритета, гарантий и ограничений по CPU/памяти/IO. Критичные сервисы защищены от «соседей», фоновые — не мешают.

*Управление качеством сервисов и прозрачное планирование мощности.

🟣 NUMA и совместимость CPU (EVC)

Согласование ВМ с архитектурой процессоров и миграции между разными поколениями железа. Нагрузки свободно перемещаются по кластеру без привязки к конкретным узлам.

*Быстрее обновляется парк и получается избежать длительных простоев.

🟣 Storage QoS

Гарантии и лимиты по IOPS/пропускной способности для томов и ВМ. «Шумные» задачи не влияют на критичные сервисы.

*Стабильные задержки в пиковые часы и понятную связь уровня сервиса с затратами.

#полезное

💿 zVirt: «Диск в некорректном состоянии» после сбоя миграции

Во время плановой миграции диска ВМ между доменами хранения (HDD → SSD) произошёл сбой задачи миграции.

✅ Симптомы

В карточке ВМ появился снимок с пометкой «Диск в некорректном состоянии»; выключать/перезагружать ВМ рискованно из-за возможной потери данных.

✅ Что произошло

Система создала snapshot на исходном домене и delta на целевом; snapshot полностью скопировался, но ссылки в БД не переключились на новый слой — delta оказалась на целевом домене, а база продолжила указывать на старый.

✅ Как исправили

Так как snapshot уже был на целевом домене, обновили ссылки в БД на корректный снимок и принудительно активировали его; статус ВМ стал «Включено». После проверки работы удалили лишние тома на исходном домене.

👀 Вывод

В zVirt диск ВМ многослойный; при сбоях возможен разрыв ссылок между слоями. Сначала — диагностика по документации вендора, затем точечные правки.

#изПрактики

🕐 Live Migration: как переместить работающую ВМ между серверами без простоя

Есть задача: перенести работающую виртуальную машину с одного физического сервера на другой (чтобы обновить железо или перераспределить нагрузку). При этом пользователи не должны заметить перерыва в работе.

🗣Основные шаги Live Migration:

⏺ Подготовка

Проверяется совместимость хостов (CPU, память, устройства). На целевом хосте выделяются ресурсы. QEMU устанавливает соединение (TCP или RDMA для скорости). Если что-то несовместимо (например, разные CPU флаги), миграция не стартует.

⏺ Фаза предварительного копирования (Pre-copy)

Итеративно копируется память VM с источника на цель, пока VM продолжает работать. Сначала вся RAM, затем только "грязные" страницы (изменённые). Это повторяется, пока разница не станет минимальной (конвергенция).

⏺ Фаза остановки и переноса (Stop-and-copy)

VM приостанавливается на источнике (downtime начинается). Передаются оставшиеся страницы памяти, состояние CPU, устройств (диски, сетевые карты). Это быстрый шаг, чтобы минимизировать простой.

⏺ Фаза запуска на целевом хосте

VM запускается на целевом хосте. Трафик перенаправляется (если нужно, через ARP или SDN). Источник очищается.

⏺ Live Migration — это сложный оркестр синхронизации состояний, превращающий, казалось бы, невозможную задачу перемещения работающей системы в рутинную операцию для современных дата-центров.

#заметкиИнженера

🔄 KubeVirt

Фреймворк для управления виртуальными машинами прямо внутри Kubernetes.

Позволяет запускать ВМ как native-ресурсы кластера через Custom Resource Definitions (CRD).

⚙️ Основной функционал:

— Запуск и управление ВМ через Kubernetes API и kubectl
— Использование стандартных Kubernetes-сетей (CNI) и хранилищ (CSI)
— Live Migration ВМ между нодами кластера
— Поддержка cloud-init и автоматизированной настройки ВМ
— Интеграция с KVM/QEMU через специальные поды

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

#полезное
👉 Git

KVM + QEMU — виртуализация на Linux

KVM (Kernel-based Virtual Machine) — модуль ядра, обеспечивающий аппаратную виртуализацию.

QEMU — эмулятор, который с KVM превращается в полноценный гипервизор. Вместе они позволяют запускать VM быстро и эффективно, без overhead, как в VirtualBox или VMware.

Полезно для тестирования, разработки.

🟢 Пример 1

Создание VM одной командой (через QEMU)

qemu-system-x86_64 \
  -enable-kvm \
  -m 1G \
  -cpu host \
  -drive file=focal-server-cloudimg-amd64-disk-kvm.img,format=qcow2 \
  -netdev user,id=net0 \
  -device virtio-net-pci,netdev=net0 \
  -nographic

Где:
-enable-kvm — используем аппаратное ускорение
-m 1G — выделяем 1 ГБ памяти
-cpu host — пробрасываем CPU хоста без эмуляции
-nographic — запускаем без GUI (для серверов)

Преимущество
Максимально быстро и минималистично, но без персистентности — закрыли терминал = ВМ остановилась.

🟢 Пример 2

Создание управляемой ВМ одной командой (через libvirt)

virt-install \
  --name vm \
  --ram 2048 \
  --vcpu 2 \
  --disk my_disk.qcow2,size=8 \
  --cdrom ubuntu-24.04.3-live-server-amd64.iso

✅ Что это дает

— Автоматическая регистрация ВМ в libvirt
— Управление через virsh
— Сетевые мосты "из коробки"
— Персистентность конфигурации

Управление такими виртуальными машины происходит через утилиту virsh.

Основные команды:

virsh list --all           # список всех ВМ
virsh start vm             # запуск ВМ
virsh shutdown vm          # штатная остановка
virsh destroy vm           # принудительное завершение
virsh edit vm              # редактирование конфигурации
virsh undefine vm          # удаление ВМ (но не дисков)

📍 Первый пример с qemu-system-x86_64 — ваш выбор для быстрого тестирования образов и экспериментов, когда нужно запустить ВМ буквально одной командой.

📍 Второй подход через virt-install + virsh идеален, когда требуется полноценное управление виртуальными машинами — здесь на помощь приходит libvirt с его персистентностью и удобным CLI.

Оба способа отлично дополняют друг друга в арсенале инженера.

#линуксятина

🤓 Mastering KVM Virtualization

Практическое руководство по KVM, QEMU и libvirt

🔎 Рассматривается:
— архитектура и внутреннее устройство KVM/QEMU, работа libvirt;
— установка окружения и создание ВМ (virt-manager, virt-install, PXE);
— виртуальные сети и хранилища: Linux bridge, NAT/ routed/ isolated сети, MacVTap, iSCSI, LVM;
— управление жизненным циклом ВМ: консоли (VNC/SPICE), агенты гостя, live-миграция;
— шаблоны и снапшоты, форматы дисков, клонирование/тонкое развёртывание;
— Kimchi: веб-управление KVM/libvirt;
— SDN для KVM: Open vSwitch, туннели (VXLAN), OpenDaylight;
— интеграция с OpenStack и устранение неполадок виртуализации;
— производительность и best practices: VirtIO, CPU/memory/NUMA, I/O, тайм-кипинг;
— инструменты V2V/P2V (virt-v2v) и конвертация гостевых систем.

Авторы:
Humble Devassy Chirammal, Prasad Mukhedkar, Anil Vettathu.
Издательство:
Packt Publishing, 2016.

#книги

💎 Виртуализация vs Контейнеризация

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

➡️ Время запуска:

ВМ — минуты / контейнеры — секунды

➡️ Диск:

ВМ занимают больше / контейнеры легче

➡️ Портативность:

ВМ сложнее переносить / контейнеры проще

➡️ Эффективность:
у контейнеров выше

➡️ ОС и ядро:

ВМ используют собственную ОС / контейнеры — общее ядро

#полезное

⬆️ Кейс: Частное облако и российская виртуализация для энергокомпании

Запрет на использование иностранных ПАКов на объектах КИИ и растущие требования к отказоустойчивости заставляют критическую инфраструктуру искать быстрые и надёжные решения.

📞 Задача

Крупная энергокомпания — объект КИИ, обеспечивающий энергоснабжение в Сибири, обратилась с запросом:
— быстро нарастить ресурсы и повысить устойчивость ИТ-систем;
— перейти на российскую виртуализацию.

🖲️ Решение

Базой проекта стала платформа частного облака CORTEL с использованием отечественной системы виртуализации zVirt.

Инфраструктуру развернули прямо на площадке заказчика, что позволило:
— сохранить полный контроль над периметром,
— упростить интеграцию,
— сократить время запуска.

⭐️ Этапы внедрения

— Анализ требований КИИ и проектирование архитектуры.
— Развёртывание частного облака на базе zVirt в ЦОДе заказчика.
— Интеграция с существующей ИТ-инфраструктурой.
— Настройка политики доступа и мониторинга.
— Проверка производительности и переход в эксплуатацию.

🚩 Результат

— Развёртывание за 2 дня.
— SLA 99,95% (максимум ~4 часа недоступности в год).
— Соответствие требованиям КИИ.
— Отсутствие затрат на долгий цикл закупок оборудования.

«Подрядчик взял всё на себя — оборудование, мощности и отечественную виртуализацию. Мы получили удобный интерфейс, гарантии и специалистов на связи, отвечающих за работоспособность и администрирование кластера.»
— отметил ИТ-директор заказчика.

О нюансах проекта читайте здесь

Чем заменить VMware ➡️ здесь

#изПрактики

🛡 КИИ: Новости и материалы.

Если вы занялись вопросом недавно, вот памятка для ответственных и заинтересованных по теме КИИ, с ответами на основные вопросы.

Про актуальные изменения за первое полугодие 2025 года тут

Подробный план о том, как проводить категоризирование критической информационной инфраструктуры тут

Из последних новостей за второе полугодие:

Сроки миграции перенесли до 1 января 2028 и 1 декабря 2030.
Переход значимых объектов КИИ на российское ПО официально сдвинут.
Минцифры 19 сентября 2025 представило проект ПП о сроках и правилах перехода на отечественное ПО: предельная дата — 1 января 2028; при объективной невозможности и решении Президиума Правкомиссии срок может быть продлён, но не далее 1 декабря 2030.

Появился стандарт по ПАК для КИИ ПНСТ 1007-2025
В конце июня 2025 утверждён предварительный национальный стандарт, который классифицирует программно-аппаратные комплексы по назначению и задаёт основу для их признания «доверенными» для применения на объектах КИИ. Полный текст опубликован на портале Росстандарта.

Сформированы «Типовые отраслевые объекты КИИ»
ФСТЭК опубликовала проект постановления с перечнями типовых отраслевых объектов КИИ

#ИТиЗАКОН

👋 make-argocd-fly — генератор ArgoCD Applications.

Превращает шаблоны на базе Helm, Kustomize и Jinja2 в Kubernetes-манифесты, а также автоматически создает ресурсы Argo CD Application, адаптированные для разных окружений (например, dev, stage, prod).

Основной функционал:

✅Рендерит Helm-чарты и Kustomize-оверлеи в детерминированный YAML — видно, что именно будет применено в кластер.

✅Генерирует ресурсы Application для Argo CD на основе ваших шаблонов.

✅Поддерживает шаблоны на Jinja2 (переменные, логика, частичные шаблоны).

✅Работает с несколькими окружениями (dev/stage/prod) и раскладывает вывод по понятной структуре каталогов: output/<env>/<app>/…

✅Упрощает код-ревью: идентичные шаблоны всегда генерируют одинаковые манифесты, поэтому в Pull Request видно только смысловые изменения.

✅Установка:

pip install make-argocd-fly   # требуется Python ≥ 3.11

👉 Git
#полезное

Terraform — инструмент от HashiCorp для декларативного описания инфраструктуры через код (IaC).

Вы описываете желаемое состояние, а Terraform сам понимает, как его достичь.

⏰ Зачем

Упрощает управление инфраструктурой — нет ручных кликов в консолях. Обеспечивает повторяемость, аудит и коллаборацию. Идеально для DevOps: деплоите VPC, EC2 или K8s кластер одним apply.

⏰ Как используется

Пишем конфиг, запускаем terraform init (инициализация), terraform plan (превью изменений), terraform apply (применение). Для разрушения — terraform destroy. Поддерживает state-файлы для отслеживания изменений.

⏰ Модульность

Terraform поддерживает модули — переиспользуемые блоки кода.
Создайте модуль для VPC, и используйте его в разных проектах. Это как Lego: собирайте инфраструктуру из готовых частей, меняя переменные.

⏰ Универсальность языка HCL

HCL (HashiCorp Configuration Language) — декларативный язык Terraform.

Синтаксис одинаковый для всех облаков: ресурсы описываются блоками resource "aws_instance" {} или resource "google_compute_instance" {}. Разница только в провайдерах — плагинах для конкретных облаков (AWS, GCP). Один код — разные среды, легко мигрировать между провайдерами.

🔵 Terraform превращает ручное создание инфраструктуры в предсказуемый и повторяемый процесс. Один раз настроил — используешь везде.

#заметкиИнженера

💎 Terragrunt — тонкая обёртка над Terraform, которая устраняет повторяющийся код и упрощает управление сложной инфраструктурой.

🤔 Основной функционал

— Автоматическое управление зависимостями между модулями (dependencies)
— Поддержка нескольких окружений (dev/stage/prod) с общими настройками
— Интеграция с remote state для хранения состояния Terraform
— Hooks для выполнения скриптов до/после Terraform-операций
— Автоматизация команд Terraform (init, plan, apply) для всей инфраструктуры

🤔 Ключевые особенности

— Универсальность HCL: синтаксис Terraform (HCL) остаётся неизменным, Terragrunt добавляет надстройку для конфигураций
— Провайдер-независимость: работает с любыми облаками, отличия только в провайдерах, а код — единый
— Упрощение CI/CD: легко интегрируется в пайплайны для автоматизированного IaC

Terragrunt делает Terraform масштабируемым и удобным для команд, минимизируя повторения и ошибки.

👉 Git
#полезное

⚙️ Cloud-init — стандартная система инициализации для облачных экземпляров, которая выполняет начальную настройку при первом запуске ВМ. Поддерживается всеми major-облаками и гипервизорами.

✅ Как работает:

1. Образ ОС содержит cloud-init пакет
2. При старте ВМ cloud-init ищет данные конфигурации
3. Выполняет инструкции (пользователи, пакеты, скрипты)
4. Сохраняет логи в /var/log/cloud-init-output.log

✅ Основные возможности:
— Создание пользователей и настройка SSH-ключей
— Установка пакетов и обновление системы
— Настройка сетевых интерфейсов
— Выполнение custom-скриптов
— Монтирование дисков и настройка swap

🚪 Пример конфигурации:

#cloud-config
# Конфигурация пользователя 
users:
  - name: admin
    passwd: $6$rounds=4096$xyz$...  # хэш пароля
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash

# Обновление пакетов
package_update: true
package_upgrade: true

# Установка сurl, htop, git
packages:
  - curl
  - htop
  - git

🤓 Cистема изначально разрабатывалась для Ubuntu, но стала де-факто стандартом и теперь поддерживается всеми major-дистрибутивами, включая CentOS, Debian и даже FreeBSD.

Cloud-init превращает создание новых серверов из рутины в автоматизированный процесс — один раз настроил конфиг и получаешь готовые к работе ВМ в любом облаке.

#линуксятина

🦎 Terraform: инфраструктура на уровне кода. 3-е межд. изд.

Практическое руководство по проектированию, развёртыванию и сопровождению облачной инфраструктуры с помощью Terraform.

🔎 Рассматривается:

— основы Terraform: синтаксис HCL, state-файлы, провайдеры;
— создание модулей, их тестирование и версионирование;
— управление состоянием в команде, блокировки и бэкенды;
— шаблоны проектирования и лучшие практики для продакшна;
— CI/CD для инфраструктурного кода.

Полезно архитекторам, DevOps- и SRE-инженерам, а также разработчикам, которые хотят уверенно строить и сопровождать надёжные, масштабируемые и управляемые системы в облаках.

Автор:
Yevgeniy Brikman.
Издательство:
O’Reilly, 3-е межд. изд., 2022.

#книги

💊 Кейс: миграция фармацевтической торговой сети в Public Cloud

Цель — повысить доступность ИТ-систем и снизить стоимость владения.

📞 Задача

— Обеспечить непрерывность работы ИТ-систем и устранить периодические недоступности критичных сервисов.

— Масштабировать ресурсы без длительных внутренних проектов.

— Провести миграцию в облако с минимальным влиянием на бизнес.

⭐️ Этапы реализации

— Собрали совместную рабочую группу и план миграции.

— Провели тесты и подготовили план миграции.

— С учётом устаревших версий ПО стандартная миграция оказалась невозможна, поэтому придумали обходные сценарии.

— Перенос проводили в ночные окна для минимизации влияния на пользователей.

— Проверка работоспособности и ввод в эксплуатацию.

— Настройка поддержки и регламентов взаимодействия 24×7.
CORTEL

🚩 Результат

— ТСО ↓ в 12 раз в первый год обслуживания за счёт перехода в облако.

— ROI +32% за трёхлетний период по сравнению с владением своей инфраструктурой.

— SLA 99,95% на облачной инфраструктуре.

— Масштабирование «по запросу» (например, оперативное добавление ядер/диска); CAPEX трансформирован в OPEX.

— Круглосуточная поддержка и прямое взаимодействие инженерных команд

«Сервис позволил сократить операционные затраты и сосредоточиться на развитии бизнеса; миграция ночью прошла по плану с ожидаемым результатом», — Чингис Юндунов,
ИТ-директор «СИБИНТЕРФАРМ».

Подробнее о проекте читайте здесь

Все про Public Cloud — здесь

#изПрактики

🏓 Как добиться 100% SLA более чем на 90 дней

❕ Мы начали с метрик.
Зафиксировали SLI и SLO: аптайм, потери пакетов, конвергенция BGP, MTTR. На каждую метрику — пороги и автоматические действия. Если что-то уходит за границы — система реагирует раньше людей.

🔎 Сеть
Несколько независимых аплинков, приходящих на независимые взаиморезервируемые маршрутизаторы. BGP с community для инженерии трафика и blackhole. Мониторим префиксы, xFlow, задержки на магистралях. Роутинговые «что если» прогоняем заранее.

💻 Кластера
Только HA. Хранилища настроены под сценарий: синхронно для критичных RPO, асинхронно между площадками для DR. Регулярно проверяем репликацию и отработку аварий.

🛡 Прод
Любое изменение — через тестовые среды и поэтапный выпуск. Rate limiting и load shedding включаются до того, как пользователи заметят деградацию. Окна обслуживания — только в периоды минимальной активности и так, чтобы клиенты это "не почуствовали".

⚙️ Операции
Runbook’и подробные и точные: кто, что, за сколько минут. Проводим тестовые испытания: искусственные отказы, секундомер, разбор полётов. Ошибочный бюджет не «тратим» — предотвращаем инциденты раньше.

🗂 Прозрачность
Важные метрики — публичны.
За последние 90 дней:
0 инцидентов с влиянием на сервисы
0 минут простоя
100.000% аптайма.

Это видно здесь

Как говорит наш ДИТ:

«В нашем деле хорошо — это когда никто ничего не заметил. И вот уже 90 дней подряд мы ничем не удивляем.
100%. Ровно. Скучно. Красиво»

⚙️ Must-Have Cloud-Native утилиты

⚙️ K9s
— терминальный UI для управления Kubernetes кластерами с возможностью мониторинга ресурсов, диагностики и оперативного управления подами.

⚙️ Lens
— полнофункциональная IDE для Kubernetes с визуализацией кластера, встроенным терминалом и поддержкой расширений.

⚙️ Alertmanager
— компонент экосистемы Prometheus для обработки, группировки и маршрутизации оповещений с поддержкой различных каналов уведомлений.

⚙️ VictoriaMetrics
— высокопроизводительная и экономичная система мониторинга и хранения временных рядов, совместимая с Prometheus.

⚙️ Cert-manager
— автоматическое управление TLS-сертификатами в Kubernetes, включая выпуск, обновление и продление от Let's Encrypt и других CA.

#полезное

💻 Cloud Controller Manager в Kubernetes: интеграция с облаками

Компонент Kubernetes, который абстрагирует работу с API облачных провайдеров.

💬 Как работает

Изначально облачная логика была внутри kube-controller-manager. Начиная с Kubernetes 1.6, CCM выделен в отдельный процесс/Deployment и берёт на себя задачи, связанные с облаком: создание LoadBalancer, управление нодами, маршрутизация и пр.

💬 Из чего состоит

CCM включает контроллеры (node, route, service), которые отслеживают состояние кластера и вызывают облачные API для синхронизации. Например, при создании Service типа LoadBalancer CCM запрашивает у провайдера балансировщик. Это позволяет использовать Kubernetes в мультивендорных средах без «вшивания» логики конкретного облака в ядро.

💬 Что это даёт

✅ Абстракция от вендора. Кластер не привязан к одному облаку: меняете провайдера — меняете реализацию CCM.

✅ Динамическое управление ресурсами. Автоматическое создание и удаление объектов (LB, маршрутов, узлов) по мере необходимости.

✅ Гибкость и масштабирование. Поддержка частных облаков и on-prem через кастомные реализации CCM.

Примечание: для хранилищ сейчас обычно используются CSI-драйверы; исторически облачные диски интегрировались через провайдер в Kubernetes.

💬 Что может CCM

✅ LoadBalancer
Автоматически создаёт облачный балансировщик для Service.

✅ Node Management
Добавляет/удаляет ноды, выставляет providerID и метки (например, зона доступности).

✅ Маршруты/сети
Настраивает маршрутизацию между нодами, если это требуется конкретным провайдером.

✅ Автоскейлинг
CCM предоставляет интерфейс для Cluster Autoscaler, чтобы динамически добавлять/удалять ноды в облаке при изменении нагрузки. Без CCM автоскейлинг ограничен локальными кластерами; с ним — полноценно работает в облаке.

#полезное

☯️CCM: проблема «курица и яйцо» в Kubernetes

В официальном блоге Kubernetes есть статья о классической проблеме инициализации Cloud Controller Manager после выноса cloud-provider из ядра.

💬 Что не так с CCM?

— Зависимость от нод.
При старте kubelet с --cloud-provider=external получают запрещающую метку (taint)
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule.

CCM должен снять эту запрещающую метку и добавить облачные сведения (адреса, метки). Если CCM развёрнут как Deployment/DaemonSet без необходимых допусков (tolerations), он может не запуститься на таких нодах.

— Каскадный эффект. Неинициализированные узлы блокируют запуск CCM, тот — снятие запрещающей метки. Параллельно CNI может ждать IP от CCM, узлы получают node.kubernetes.io/not-ready, и система зацикливается.

— Задержки.
Новый процесс инициализации добавляет задержки по сравнению с прежним поведением, когда kubelet сразу заполнял данные узла.

💬 Как исправить?

— hostNetwork: true.

Чтобы CCM использовал сетевой стек хоста и имел доступ к конечным точкам (endpoints) и API провайдера.

— Deployment/DaemonSet + механизм leader-election.

Разворачивайте как управляемый ресурс и включайте --leader-elect=true при нескольких репликах, чтобы избежать гонок.

— Размещение на control plane.

Задайте nodeSelector: { node-role.kubernetes.io/control-plane: "" } и добавьте podAntiAffinity, чтобы реплики не оказывались на одном хосте.

— Явные допуски (tolerations).

🟢Для старта на неинициализированных узлах:
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule

🟢Для размещения на control plane:
node-role.kubernetes.io/control-plane:NoSchedule и/или node-role.kubernetes.io/master:NoSchedule

🟢Для устойчивости при инициализации:
node.kubernetes.io/not-ready:NoExecute и node.kubernetes.io/unreachable:NoExecute (иногда может потребоваться и NoSchedule).

Дополнение: автоскейлинг по размеру кластера для CCM не рекомендуется; несколько реплик нужны для отказоустойчивости, а не для ускорения работы.

💬 Если CCM работает вне управляемого им кластера (например, в hosted control plane), применимость советов зависит от конкретной топологии и ограничений среды. Это не «упрощённый» случай — проверяйте требования вашей архитектуры.

#заметкиИнженера

🖥 NFS (Network File System) — протокол для совместного доступа к файлам по сети, разработанный Sun Microsystems в 1984 году.

Позволяет монтировать удалённые директории как локальные, делая их доступными для нескольких хостов. Используется в кластерах, NAS и облаках для общего хранилища.

🟡 Как работает

— Архитектура «клиент-сервер»: сервер экспортирует каталоги, клиенты их монтируют
— RPC-протокол: для управления подключениями (порт 111)
— NFS-демоны: nfsd обрабатывает запросы, mountd управляет монтированием
— Версии протокола: NFSv3 (UDP/TCP), NFSv4 (TCP, встроенная аутентификация)

🟡 Базовая настройка на сервере

# Установка пакета
sudo apt install nfs-kernel-server

# Создаём экспортируемый каталог
sudo mkdir /srv/share
sudo chown nobody:nogroup /srv/share

Конфигурация /etc/exports:

/srv/share 192.168.1.0/24(rw,sync,no_subtree_check)

🟡 Ключевые атрибуты /etc/exports

— rw/ro — чтение-запись или только чтение
— sync/async — синхронная/асинхронная запись
— no_subtree_check — отключение проверки поддеревьев
— no_root_squash — доступ root без преобразования
— all_squash — всех пользователей отображать в nobody
— anonuid/anongid — явное указание UID/GID для анонимных пользователей

🟡 Настройка клиента

# Установка пакета
sudo apt install nfs-common

# Монтирование каталога
sudo mount -t nfs server-ip:/srv/share /local/mount

NFS — классика для общих файловых систем в Linux, идеально для кластеров или бэкапов

#линуксятина