«Домен» - это группа узлов хоста.
Не все так просто, было бы точнее, если бы вы сказали «Домен - это логическая группа ресурсов».
Чтобы понять это правильно, вы должны сначала понять большинство компонентов в отдельности. Я рекомендую эти чтения в первую очередь:
Тогда мы можем извлечь из этого несколько пунктов:
Узлы не являются виртуальными машинами, узлы работают поверх лазурных виртуальных машин.
Они часто имеют отображение 1: 1, но в некоторых случаях вы можете иметь отображение узла 5: 1 / ВМ , например, при установке локального кластера разработки.
Виртуальные машины Azure имеют домены обновления и домены сбоя, узлы сервисной фабрики имеют домены обновления и домены сбоя
Насколько они выглядят одинаково, у них есть свои различия:
Домены ошибок:
- Домены сбоя VM являются изолированными слотами для физического развертывания, что означает: источник питания, сеть, диски и т. Д. Они ограничены по регионам.
- SF Fault Domains - это логические слоты узлов для развертывания приложения, что означает, что когда SF развертывает приложение на узлах, оно будет распределяться по разным доменам сбоев, чтобы сделать их надежными, большую часть времени FD будет отображаться на VM Fault Domains, но в сложных сценариях это можно сопоставить с чем угодно, например, можно сопоставить весь регион с одним SF FD.
.
Обновление \ Обновление доменов:
- Домены обновлений виртуальной машины относятся к ОС \ исправлениям и обновлениям оборудования, отдельные домены обновлений будут обрабатываться изолированно и не обновляться одновременно, поэтому, когда требуется обновление ОС для сбоя вашей виртуальной машины, они обновят домен по домену. Меньшее количество доменов обновлений означает, что больше компьютеров будет отключено во время обновлений.
- В доменах обновления SF используется аналогичный подход доменов обновления виртуальных машин, но при этом основное внимание уделяется службам и самому обновлению кластера, сокращая UD на UD за раз и переходя к следующему, когда предыдущий UD завершается успешно.
- В обоих случаях вы настраиваете Update \ Upgrade на то, сколько экземпляров (%) ваших vm \ узлов \ сервисов может быть отключено во время обновлений. Так, например, если ваша служба имеет 100 экземпляров в кластере с 5 UD, SF будет обновлять 20 служб одновременно, если вы увеличите количество UD, например, до 10, количество уменьшенных экземпляров сократится до 10 экземпляров за раз, но время развертывания вашего приложения увеличится в той же пропорции.
Исходя из этого, вы можете рассматривать FD & UP как матрицу надежных слотов развертывания. Чем больше у вас будет, тем больше будет повышаться надежность (с компромиссами, такими как время обновления). Пример ниже взят из SF документов:
Service Fabric из коробки старается изо всех сил разместить экземпляры ваших служб на разных FD \ UD, это означает, что, если возможно, они будут на разных FD \ UD, в противном случае он найдет другой с наименьшим числом экземпляров развертываемая служба.
А про Кубернетес:
В Kubernetes эти функции не являются стандартными, k8 имеют концепцию зон , но, согласно документам, они ограничены регионами, они не могут распространяться на регионы.
Kubernetes автоматически распределит модули в контроллере или службе репликации по узлам в кластере с одной зоной (чтобы уменьшить влияние отказов). В кластерах с несколькими зонами это поведение распространения распространяется на зоны (чтобы уменьшить влияние отказов зон). Это достигается с помощью SelectorSpreadPriority.
Это размещение с максимальным усилием, и поэтому, если зоны в вашем кластере неоднородны (например, разное количество узлов, разные типы узлов или разные требования к ресурсам модуля), это может помешать равномерному распределению ваших модулей по зонам. , При желании вы можете использовать однородные зоны (одинаковое количество и типы узлов) для уменьшения вероятности неравномерного распространения.
Это не то же самое, что FD, но очень похожая концепция.
Для достижения результата, аналогичного SF, потребуется развернуть кластер по зонам или сопоставить узлы с VM FD \ UD, чтобы они вели себя как узлы на SF. Добавьте метки к узлам, чтобы идентифицировать эти домены. Вам также необходимо создать метки NodeType на узлах в разных FD, чтобы их можно было использовать для развертывания модулей на узлах с разделителями.
Например:
- Node01 : FD01: NodeType = FrontEnd
- Node02 : FD02: NodeType = FrontEnd
- Node03 : FD03: NodeType = FrontEnd
- Node04 : FD01: NodeType = BackEnd
- Node05 : FD02: NodeType = BackEnd
При развертывании приложения вы должны использовать функцию affinity , чтобы назначать POD узлу, и в этом случае ваша служба будет иметь:
- Требуется сходство с NodeType = FrontEnd
- Предпочитаемый AntiAfinity до ContainerName = [само по себе]
С этими настройками использование k8-файлов affinity и anti-affinity будет пытаться разместить реплики \ экземпляры вашего контейнера на отдельных узлах, и узлы будут уже разделены FD \ zone, разделенными метками NoteType, тогда k8s будут обрабатывать обновления обновления как SF.
Поскольку правила антиаффинности предпочтительнее, k8s постарается сбалансировать между этими узлами с максимальной эффективностью, если нет доступных действительных узлов, он начнет добавлять больше экземпляров на узел, который уже содержит экземпляры того же контейнера,
Заключение
Это немного дополнительная работа, но мало чем отличающаяся от того, что в настоящее время используется в других решениях.
Основной проблемой здесь будет настройка узлов на FD \ Zones, после того как вы разместите свои узлы на правильном FD, остальные будут работать бесперебойно.
В SF вам не нужно беспокоиться об этом при развертывании кластера в Azure, но если вы делаете это с нуля, это большая работа, даже больше, чем k8s.
ПРИМЕЧАНИЕ. Если вы используете AKS , он будет распределять узлы по наборам доступности (набор, который указывает домены сбоев ВМ и домены обновлений). В настоящее время, согласно этой записи , AKS не предоставляет вам распределение зон, поэтому вам придется делать это с нуля, если вам нужен такой уровень распределения.