kind делает каждый узел контейнером Docker или Podman с systemd и kubelet внутри и ставит Kubernetes тем же kubeadm, а локальный образ попадает в кластер через kind load без реестра. k3s — один бинарь с control plane в горутинах процесса k3s server, состоянием в SQLite через kine и встроенными Flannel, Traefik и ServiceLB. minikube поднимает узел ВМ или контейнером по выбору драйвера и включает компоненты через addons. API у всех тот же, а расходится то, что ниже: LoadBalancer, тома и сеть ведут себя не так, как на настоящем кластере.
Источником правды о кластере становится репозиторий Git, а изменения забирает Argo CD по deploy key только на чтение: контроллер рендерит манифесты через Kustomize или Helm, сравнивает с живыми объектами и сам сводит разницу. Приложение описывает Application с syncPolicy.automated, prune и selfHeal, и ручная правка откатывается за секунды; порядок применения задают волны и хуки, а сами Application порождают App of Apps и ApplicationSet. AppProject ограничивает, откуда и куда можно доставлять, а секреты в Git не кладут.
Под получает доменную личность через gMSA — учётную запись, пароль которой вычисляет и меняет сам Active Directory и отдаёт только разрешённым хостам. В манифесте указывают лишь имя GMSACredentialSpec в gmsaCredentialSpecName; вебхук подставляет JSON спецификации и проверяет право use у ServiceAccount пода, а на узле CCG забирает пароль gMSA у контроллера и передаёт контейнеру. Узел для этого вводят в домен и добавляют в группу, которой разрешено читать пароль, а приложение должно работать от Network Service или Local System.
10 ноября 2026 года вышел .NET 11. Это релиз со стандартным сроком поддержки (STS): Microsoft обещает обновления до 14 ноября 2028 года, то есть ровно до того же дня, что и у LTS-версии .NET 10. Вместе с платформой вышел C# 15 — для проектов с net11.0 он включён по умолчанию, ничего в .csproj дописывать не нужно.
В статье разобраны все новинки языка: union-типы, закрытые иерархии классов, аргументы в выражениях коллекций, индексаторы-расширения, break и continue с меткой, статические члены интерфейсов на старых средах выполнения и предварительная версия новых правил безопасности памяти. Последний раздел посвящён runtime async: это не синтаксис, а новый способ компиляции async-методов, тоже пока предварительный. Все примеры собраны и запущены на SDK 11.0.100, вывод — настоящий, с русской локалью (поэтому дробная часть отделяется запятой). Ошибки компилятора приведены с кодами, как их выдаёт dotnet build.
hello собирается под windows/amd64 на nanoserver без инструкции RUN, и docker buildx кладёт Windows-вариант в общий тег с полем os.version, по которому containerd выбирает манифест своей сборки. На Windows нет cgroups и OOM killer: лимиты становятся свойствами job object, requests в ядро не попадают, а процесс сверх лимита памяти получает отказ VirtualAlloc и падает сам, поэтому limits задают всем Windows-подам. Тома даёт csi-driver-smb, логи собирает Alloy в HostProcess-поде в Loki тестового кластера, метрики — windows-exporter, а узел обновляют ежемесячно через drain, перезагрузку и uncordon после того, как Calico пересоздал сеть.
Тестовый кластер собирается на kubeadm из Linux-мастера, двух Linux-воркеров и воркера на Windows Server 2025. Calico 3.33 ставится сразу в VXLAN без BGP, со strictAffinity, windowsDataplane: HNS и прямым адресом API в ConfigMap kubernetes-services-endpoint. На Windows-узле скрипты sig-windows-tools ставят containerd и kubelet службами, kubeadm join с JoinConfiguration сразу вешает taint os=windows:NoSchedule и maxPods: 60, Calico и kube-proxy приходят HostProcess-подами, а Windows-поды на основе Nano Server направляет на узел RuntimeClass windows-2025.
Сеть Windows-узла строит служба HNS, а исполняет VFP — расширение коммутатора Hyper-V: вместо veth у пода vNIC в сетевом отсеке, вместо маршрутов и nftables — политики HNS, которые CNI-плагин, kube-proxy в режиме kernelspace и Felix описывают через её API. Из плагинов на Windows работают Flannel, Calico и Antrea, Cilium — нет. Выбираем Calico в VXLAN Always с выключенным BGP и strictAffinity: CrossSubnet на Windows не работает, а учебный кластер с BGP такой узел не примет — для него собирается отдельный тестовый кластер.
С точки зрения API Windows-узел — такой же узел: kubelet подключается к kube-apiserver, продлевает Lease и получает поды, а планировщик и контроллеры работают с ним без изменений. Различия ниже уровня API: kubelet и containerd работают службами Windows, контейнер создаёт служба HCS как server silo на основе job object вместо namespaces и cgroups, а системные компоненты, которым нужен доступ к самому узлу, запускаются в HostProcess-контейнерах — привилегированных на Windows нет. Kubernetes поддерживает только изоляцию процессов, поэтому сборка ОС в образе должна совпадать со сборкой хоста, а поды разводят по узлам taint os=windows:NoSchedule и RuntimeClass.
Сначала control plane, потом узлы по одному: на мастере переключают репозиторий на новую минорную версию, ставят kubeadm, смотрят kubeadm upgrade plan и выполняют kubeadm upgrade apply, который по очереди заменяет static pods и продлевает сертификаты на год; затем на каждом воркере kubectl drain, kubeadm upgrade node, новый kubelet и uncordon. Минорные версии нельзя перепрыгивать, а kubelet не может быть новее apiserver. Перед началом — снапшот etcd, копия /etc/kubernetes/pki и проверка совместимости Calico и других компонентов.
etcd — хранилище «ключ — значение» с историей версий: kube-apiserver кладёт каждый объект под ключ вида /registry/<ресурс>/<неймспейс>/<имя>, а resourceVersion — это ревизия etcd. Запись считается выполненной, когда её подтвердило большинство членов по протоколу Raft, поэтому членов делают нечётное число, а потеря кворума останавливает API. Каждая запись ждёт fdatasync журнала WAL, так что etcd нужен локальный SSD. Резервная копия — etcdctl snapshot save по расписанию, зашифрованная и выгруженная вне кластера.