RODC — контроллер для филиала: он выдаёт билеты Kerberos, отвечает на LDAP и работает DNS-сервером, но записи отсылает на записываемый контроллер и сам ничего не реплицирует. Хешей паролей он по умолчанию не хранит: кешируются только учётные записи из разрешённого списка политики репликации паролей (PRP), остальных проверяет контроллер в офисе. TGT он шифрует ключом собственной учётной записи krbtgt_, поэтому украденный RODC не открывает ни других сайтов, ни чужих привилегий.
На трёх машинах Ubuntu 26.04 выключаем swap, включаем net.ipv4.ip_forward, ставим containerd с SystemdCgroup = true и пакеты kubeadm, kubelet и kubectl версии 1.36. На мастере kubeadm init --config kubeadm-config.yaml за минуту выпускает сертификаты, пишет kubeconfig и манифесты статических подов, затем ставим Calico через оператор Tigera, а рабочие узлы подключаем kubeadm join. Самое важное решение — отдельное имя API k8s-api.example.com в controlPlaneEndpoint: без него кластер потом не превратить в отказоустойчивый.
В прошлой статье мы подняли сервер Xray с VLESS, XTLS Vision и REALITY и настроили клиент v2rayN на Windows. Здесь — то же для Android. Телефон чаще остальных устройств ходит по чужим сетям: мобильный интернет, Wi-Fi в кафе, роуминг, — и именно на нём прокси нужнее всего.
В статье: как устроен VPN в Android и почему он в системе один; что находится внутри приложения v2rayNG; как установить его с проверкой подписи; как выдать телефону отдельный ключ и ввести его QR-кодом; какие настройки стоит поменять и почему — IPv6, routeOnly, DNS, обход локальной сети; как устроена маршрутизация и что делать с правилами, подписанными по-китайски; как проверить результат по журналу сервера и какие подводные камни ждут при переключении между VPN и между сетями.
Сервер и протоколы здесь заново не разбираются: они описаны в предыдущей статье, а про DNS, TCP, UDP и TLS есть части серии «Сети для самых маленьких». Нужное для понимания повторяется в одну-две фразы.
Каждый контроллер принимает изменения сам и передаёт партнёрам только изменившиеся атрибуты: изменение помечено USN и invocationID контроллера, где оно родилось, а вектор актуальности не даёт получить одно изменение дважды. Конфликт решает версия атрибута, затем метка времени. Соединения между контроллерами строит KCC; внутри сайта репликация идёт по уведомлению через 15 секунд, между сайтами — по расписанию связи сайтов, а проверяют её repadmin /replsummary и /showrepl.
Каждый объект — документ с полями apiVersion, kind, metadata, spec и status; kube-apiserver хранит его в etcd и отдаёт по пути вида /apis/apps/v1/namespaces/default/deployments/web. Запрос проходит аутентификацию, авторизацию, admission и проверку схемы, а запись сверяет resourceVersion и при расхождении отвечает 409 Conflict, чтобы клиенты не затирали чужие правки. Контроллеры не опрашивают API, а подписываются на изменения через watch, удаление идёт через финализаторы, а server-side apply ведёт учёт, кто каким полем владеет.
На сервере Windows создаётся область для префикса /64 (Add-DhcpServerv6Scope) с опциями DNS; адреса сервер выдаёт случайно из всего префикса, а резервирует по DUID и IAID вместо MAC. Клиенты придут к нему, только если роутер поднял в Router Advertisement флаг M или O, а шлюз всё равно приходит от роутера: DHCPv6 лишь дополняет RA. Failover для IPv6 нет — два сервера просто держат одинаковую область.
Кластер состоит из control plane и рабочих узлов. На мастере работают kube-apiserver, etcd, kube-scheduler и kube-controller-manager, на каждом узле — kubelet, containerd, kube-proxy и Calico. Главное правило: с etcd говорит только kube-apiserver, а все остальные компоненты — его клиенты: они подписываются на изменения через watch на порту 6443, делают свой шаг и записывают результат обратно в API, напрямую друг к другу не обращаясь. Сам control plane kubelet запускает статическими подами из манифестов в /etc/kubernetes/manifests.
Kubernetes запускает контейнеры на группе машин и следит, чтобы работало ровно то, что описано. Администратор не отдаёт команду «запусти контейнер на узле 1», а сохраняет в кластере желаемое состояние — например, Deployment с replicas: 3, — а контроллеры в цикле согласования сравнивают его с реальностью и устраняют разницу: пересоздают упавшие поды, переносят их с пропавшего узла, обновляют приложение без простоя. Он не собирает образы, не хранит данные приложений и не реализует сеть сам — это делают CI, внешнее хранилище и CNI-плагин.
Роль DHCP Server начинает раздавать адреса только после авторизации сервера в каталоге (Add-DhcpServerInDC), затем создаются область, опции и резервирования, причём опция 6 должна указывать на контроллеры. Чтобы записи DNS, которые сервер регистрирует за клиентов, мог обновлять и второй сервер, обновления идут от отдельной учётной записи svc-dhcp-dns из группы DnsUpdateProxy. Отказоустойчивость даёт failover: два сервера делят одну область в режиме Load Balance или Hot Standby.
Зона домена хранится не в файле, а в каталоге: каждое имя — объект dnsNode в разделе DomainDnsZones или ForestDnsZones, и зона реплицируется вместе с Active Directory, без зонных передач. Записи регистрируют сами машины динамическими обновлениями, подписанными Kerberos (GSS-TSIG), и у записи появляется владелец — тот, чьим билетом подписан запрос. Чужие имена сервер ищет через форвардеры, условные форвардеры или stub-зоны, а устаревшие динамические записи убирает очистка.