Один кластер / экземпляр Kubernetes/OpenShift в разных центрах обработки данных?
При том понимании, что Ubernetes предназначен для полного решения этой проблемы, возможно ли в настоящее время (не обязательно рекомендуется) охватить один кластер K8/OpenShift между несколькими внутренними корпоративными центрами обработки данных?
Кроме того, предполагая, что задержка между центрами обработки данных является относительно низкой, а инфраструктура в корпоративных центрах обработки данных - относительно непротиворечивой.
Пример: с учетом 3 корпоративных контроллеров домена разверните мастера 1.. * в каждом центре обработки данных (как один кластер) и на каждом контроллере 1... * узлов с pods / rc's / services /..., развернутыми на всех 3 контроллерах домена.
Кто-то реализовал что-то вроде этого как решение для ограничения пробелов до того, как Ubernetes уйдет, и если да, то как это работает и какие соображения следует учитывать при работе таким образом?
1 ответ
в настоящее время возможно (не обязательно рекомендуется) охватить один кластер K8/OpenShift по нескольким внутренним корпоративным центрам обработки данных?
Да, в настоящее время это возможно. Узлам присваивается адрес сервера и учетные данные клиента, а затем они регистрируются в кластере. Узлы не знают (или не заботятся) о том, является ли сервер apiserver локальным или удаленным, и этот сервер позволяет любому узлу регистрироваться, если он имеет действительные учетные данные, независимо от того, где этот узел существует в сети.
Кроме того, предполагая, что задержка между центрами обработки данных является относительно низкой, а инфраструктура в корпоративных центрах обработки данных - относительно непротиворечивой.
Это важно, так как многие параметры в Kubernetes предполагают (неявно или явно) широкополосную сеть с низкой задержкой между сервером и узлами.
Пример: с учетом 3 корпоративных контроллеров домена разверните мастера 1.. * в каждом центре обработки данных (как один кластер) и на каждом контроллере 1... * узлов с pods / rc's / services /..., развернутыми на всех 3 контроллерах домена.
Недостатком этого подхода является то, что если у вас есть один глобальный кластер, у вас есть одна глобальная точка отказа. Даже если вы реплицировали главные компоненты HA, повреждение данных может перевести весь кластер в автономный режим. А неправильная конфигурация, распространяемая на все модули в контроллере репликации, может отключить всю службу. Плохой толчок изображения узла может перевести все ваши узлы в автономный режим. И так далее. Это одна из причин, по которой мы рекомендуем людям использовать кластер на домен сбоя, а не один глобальный кластер.