В IPv4 клиент без DHCP не знает ничего: ни адреса, ни шлюза, ни DNS. В IPv6 — наоборот: адрес и шлюз машина получает от роутера по Neighbor Discovery без всякого сервера, и это описано в частях 14 и 15 сетевой серии. Сам протокол DHCPv6 — сообщения Solicit, Advertise, Request, Reply, идентификаторы DUID, многоадресная рассылка ff02::1:2 — разобран в части 16. Здесь — о том, какое место остаётся для DHCPv6 рядом с SLAAC, как это место занимает сервер Windows, и чем IPv6-область отличается от IPv4-области из прошлой части.
Короткая версия для тех, кто решает, нужна ли эта часть: в домене из Windows-машин с одним роутером DHCPv6 можно не поднимать вовсе. Длинная версия — почему, и когда всё-таки нужно.
В первой части кластер выглядел как набор контроллеров, которые через kube-apiserver читают желаемое состояние и приводят к нему мир. Теперь разберём его по деталям: какие процессы работают на мастере и на узлах, что делает каждый, кто к кому подключается и по каким портам, как control plane запускает сам себя и что происходит за те несколько секунд, пока kubectl run превращается в работающий контейнер. Ставить кластер будем в части 4, а здесь, в разделе «Смотрим руками», — как всё это выглядит на уже готовом учебном кластере: мастер k8s-master-1 (192.168.10.17) и рабочие узлы k8s-node-1 (192.168.10.20) и k8s-node-2 (192.168.10.21).
Kubernetes — система, которая запускает контейнеры на группе машин и следит, чтобы запущено было ровно то, что описано. Звучит просто, но за этой фразой стоит смена способа думать о серверах: вместо «зайти на машину и запустить процесс» администратор пишет, каким должно быть состояние, а дальше десятки независимых циклов в кластере сами приводят мир к этому описанию и держат его таким. Эта часть — о том, откуда взялась такая модель, как устроен цикл согласования, чем декларативное управление отличается от императивного и чего Kubernetes не делает, хотя от него часто этого ждут. Команд здесь немного: учебный кластер мы поставим в части 4, а в конце этой части посмотрим, как описанное выглядит на нём.
Серия рассчитана на читателя, который знает Linux и сети. Сетевые протоколы, на которые опирается кластер, разобраны в серии «Сети для самых маленьких» — например, VXLAN, которым сетевой плагин соединяет узлы, описан в её части 18, — и там, где они понадобятся, будут ссылки на неё. Отказоустойчивый control plane на трёх мастерах с BGP — тема отдельной серии «Отказоустойчивый Kubernetes на BGP»; здесь кластер проще — один мастер и два рабочих узла, — зато каждый его компонент разобран подробно.
Протокол DHCP для IPv4 — четыре сообщения Discover, Offer, Request, Ack, формат опций, продление аренды и ретрансляция — разобран в части 11 сетевой серии. Здесь речь о серверной стороне в домене: как роль DHCP Server устроена в Windows, чем сервер в домене отличается от сервера в роутере, как два сервера делят одну область без конфликтов и как они регистрируют имена клиентов в DNS, не ломая безопасные обновления из прошлой части.
DHCP в домене традиционно ставят на контроллеры: это две службы, которым нужна одинаковая доступность и которые вместе занимают несколько десятков мегабайт памяти. Для лаборатории сделаем так же: сейчас на dc1, во второй половине части — на dc2, когда он появится в части 10. Если в организации есть отдельные серверы инфраструктуры, DHCP ставят туда, и всё написанное ниже не меняется, кроме одного пункта про группу DnsUpdateProxy.
Как устроен сам протокол DNS — дерево имён, рекурсивные и авторитативные серверы, типы записей, TTL — разобрано в части 12 сетевой серии, и здесь мы это не повторяем. Эта часть о том, что делает с DNS Active Directory: как зона превращается в объекты каталога, кто и как регистрирует в ней записи, куда сервер отправляет запросы о чужих именах, и какие настройки отличают DNS контроллера от DNS, поднятого на Linux.
Напомним, почему контроллер почти всегда ещё и DNS-сервер. Клиент находит контроллеры по SRV-записям (часть 3), а контроллеры регистрируют эти записи сами и обновляют каждый час. DNS-сервер, который принимает такие обновления, проверяет, кто их прислал, и реплицирует зону вместе с каталогом, не требуя ни зонных передач, ни отдельной настройки, — это DNS-сервер Windows с зоной в Active Directory. Можно держать зону домена на BIND, это поддерживается, но тогда динамические обновления, права на записи и репликацию придётся настраивать руками.
Поисковик узнаёт о новой странице сайта двумя способами: находит её по ссылкам при обходе или читает sitemap.xml. Оба способа работают «по расписанию» поисковика: он сам решает, когда заглянуть на сайт в следующий раз. Для небольшого блога это дни, а иногда недели. Новая статья уже опубликована, а в поиске её нет.
IndexNow переворачивает схему: не поисковик спрашивает сайт, а сайт сообщает поисковику. Протокол придумали в Microsoft (Bing) и Яндексе в 2021 году, сейчас его поддерживают Bing, Яндекс, Naver, Seznam и ещё несколько поисковиков. Google в протоколе не участвует и по-прежнему узнаёт о страницах из sitemap.
Один сервер PostgreSQL хорош ровно до того дня, когда гипервизор под ним перезагружается под обновления, а вместе с ним встают все приложения, которые держат на этом сервере свои базы. Эта статья — о том, как из трёх машин собрать кластер PostgreSQL, который переживает потерю любой из них сам, без администратора у консоли: что в нём за части, как они ставятся на Ubuntu, что происходит при отказе, как это проверить, как бэкапить и как потом обслуживать. Отдельно — о граблях, на которые я наступил, пока собирал такой кластер: некоторые из них отнимают часы, если не знать, куда смотреть.
Все имена и адреса в статье условные: домен example.com, узлы db1, db2, db3 с адресами 192.0.2.11–192.0.2.13, плавающий адрес 192.0.2.10. Операционная система — Ubuntu 26.04 LTS, в репозитории которой лежит PostgreSQL 18, Patroni 4.1 и etcd 3.5; все команды из статьи выполняются от root или через sudo.
Kerberos придумали в MIT в 1980-х для проекта Athena: тысячи рабочих станций, десятки серверов, и ни одному из них нельзя доверять пароль пользователя. Решение — доверенная третья сторона, которая знает ключи всех участников и выдаёт им билеты: зашифрованные удостоверения с ограниченным сроком, которые можно предъявить службе вместо пароля. Версия 5 протокола описана в RFC 4120, Microsoft взяла её в Windows 2000 как основную аутентификацию домена и добавила к ней свои расширения, описанные в MS-KILE и MS-PAC. С тех пор каждый вход в домен, каждое открытие сетевой папки и каждый запрос к контроллеру по LDAP начинаются с Kerberos.
В прошлой части мы видели в Wireshark, как LDAP-соединение после SASL-привязки стало нечитаемым. Сегодня разберём, что именно там произошло: по сообщениям, по полям и по ключам.
Всё, что читает или меняет каталог — оснастка Active Directory Users and Computers, модуль PowerShell, Exchange, sssd на Linux, система заявок, которая «интегрирована с AD», — говорит с контроллером по LDAP. Active Directory и есть LDAP-сервер: версии 3, по RFC 4510–4519, с расширениями Microsoft, описанными в открытой спецификации MS-ADTS. Оснастки показывают каталог отредактированным и переведённым; LDAP показывает его как есть. В этой части мы будем смотреть именно так, и это единственная часть серии, где графические инструменты — ldp.exe и ADSI Edit — не упоминание, а предмет: они показывают сырой каталог, и рядом с каждым их действием мы будем ставить ту же операцию в PowerShell.
Вторая половина части — о том, что в каталоге ломается при неосторожной правке и не восстанавливается откатом. Каталог хранит и данные, и собственную конфигурацию, и конфигурация защищена от администратора не сильнее, чем данные.
В прошлой части мы разобрали, что такое лес, домен, разделы каталога и глобальный каталог. Сегодня всё это появится на диске сервера dc1, который мы подготовили в части 1. Повышение сервера до контроллера — операция на десять минут и одну команду, но за эти десять минут меняется почти всё: исчезает локальная база учётных записей, появляются база каталога, DNS-зоны, общие папки и шесть новых служб. Пройдём по шагам и посмотрим на каждый.