Windows и Linux живут вместе в кластере Kubernetes
Я смотрел на документация kubernetes, который, похоже, совместим с Windows, однако мне не совсем понятно, могут ли Linux и Windows жить вместе (я имею в виду, в разных виртуальных машинах, но в одном кластере).
Я хотел бы знать, есть ли поддержка этого сценария в gcloud, azure или aws. А также процедуру или пример, чтобы заставить его работать. Например, как создать модуль в правильной виртуальной машине (Windows или Linux) и как работают горизонтальные и кластерные автомасштаберы.
Вариант использования - это 2 API, один из которых работает в Windows (.NET Framework), а другой в Linux (python / C++), и я хочу иметь возможность перенаправлять их, иметь возможность вызывать друг друга, масштабировать их и так далее с помощью кубернетов. Отметим, что у приложения .NET Framework есть зависимости (в основном для математической оптимизации), которые нельзя передать в .NET Core, это означает, что я не могу преобразовать приложение в на базе Linux.
Альтернативным решением было бы развернуть среду выполнения .NET в контейнерах Linux (!), Работающих на платформе Kubernetes только для Linux. .NET отлично работает в Linux, и, если вы можете запускать свой код, используя этот вариант с открытым исходным кодом, вам стоит подумать об этом.
Спасибо за комментарии @DazWilkin. Фактически, я знаю, что возможно развертывание с .NET CORE из-за совместимости с несколькими ОС. Однако приложение имеет зависимости, основанные на .NET Framework, который поддерживается только Windows.
Понятно! Позвольте мне поспрашивать и дать вам более точный ответ о планах Kubernetes Engine.
А ваша зависимость .NET - это двоичная, запутанная библиотека DLL с закрытым исходным кодом? Если нет, то какой класс не переносится? Возможно, удастся починить его на переносной.
Я действительно хотел бы знать об общем случае, а не о конкретном. Потому что это код, который я не контролирую, это другой программист. Однако в нашем конкретном случае кажется, что одна из библиотек - крайняя оптимизация, но я не уверен, что она единственная.
Я предполагаю, что они не предоставляют переносимый .NET, потому что Windows TPM защищает их бизнес. Какие функции вам требуются для экстремальной оптимизации? Ваша основная платформа - Python или собственный Linux? Возможно, другие придумают альтернативы.
Я вызываю множество программ linux либо с подпроцессами bash, и так далее. Так что да, родной Linux.
Ответы 2
Да, это должно быть возможно.
Поскольку все развертывания находятся в контейнерах докеров, вы можете запускать любую ОС в Kubernetes (в контейнере докеров). Также Windows.
Запуск контейнеров Windows и Linux в одном кластере не должен вызвать у вас никаких проблем.
Спасибо @ bn4t. Однако я ищу более подробный ответ. Я хотел бы знать, как программно создавать узлы и поды, ориентированные на ОС контейнера изображений. Как использовать автомасштабирование HPA, автомасштабирование кластера и т. д.
Немного истории, поэтому контейнеры - это вещь Linux, поэтому контейнеров как таковых в Windows нет. Docker создал Docker для Windows, но, по сути, он запускает виртуальную машину Linux Hyper-V (ранее назывался VirtualBox), а внутри нее запускаются ваши контейнеры. В последней версии Docker Microsoft добавила возможности Hyper-V, позволяющие запускать эти контейнеры как бы изначально, что упрощает запуск .NET-приложения в контейнерах.
K8s реализован в Golang, поэтому в целом было проще переносить основные компоненты, такие как kubelet, kube-proxy, kubectl, в Windows с помощью кросс-компилятора Golang (или встроенного в Windows).
Сложная часть - это сеть, но похоже, что они выяснили это в документы
Что касается поддержки публичного облака от основных провайдеров:
AWS
- Гипервизор: модифицированный Xen или KVM. Нет поддержки вложенной виртуализации.
- ВМ: виртуальные машины Windows. Невозможно использовать Hyper-V с вложенной виртуализацией, но может запускать Docker для Windows.
- Чистый металл: (i3.metal на момент написания этой статьи). Запустите Hyper-V изначально и Docker для Windows.
Лазурь
- Гипервизор: Hyper-V. Поддерживает вложенную виртуализацию для некоторых типов экземпляров.
- Виртуальные машины: виртуальные машины Windows, могут использовать вложенную виртуализацию с Hyper-V и могут запускать Docker для Windows.
- ACS, AKS, ACE: должна иметь возможность использовать преимущества Hyper-V с вложенной виртуализацией и в некоторых случаях изначально.
GCP
- Гипервизор: KVM. Поддерживает вложенную виртуализацию для некоторых типов экземпляров.
- ВМ: виртуальные машины Windows. Может запускать Hyper-V с вложенной виртуализацией и может запускать Docker для Windows.
Кроме этого, я не знаю, что еще к этому нужно (кроме того, что в документы). Вопрос очень широкий. Просто установите Docker для Windows, настройте сеть, присоединитесь к своему кластеру с kubeadm и запланируйте рабочие нагрузки Windows, используя спецификацию nodeSelector в ваших модулях, и убедитесь, что вы пометили свои узлы Windows с помощью beta.kubernetes.io/os=windows.
Есть еще одно хорошее руководство по настройке Kubernetes с узлами Windows здесь
Это интересный ответ. Я знал, что Windows использует Hyper-V для виртуальной машины Linux, на которой работает докер, но я не знал, что для Windows он использует то же самое. Кроме того, я видел сетевой процесс в документации, однако я ничего не видел об автоматизации (может быть, у меня какой-то недостаток опыта?). Лейбл beta.kubernetes.io/os=windows я точно не знал. И, наконец, было бы неплохо узнать о совместимости с aws, azure и / или gcloud.
Добавлена дополнительная информация об основных облачных провайдерах.
Спасибо за дополнительную информацию, ваш ответ довольно полный, интересный и аккуратный. Я надеюсь, что ребята из gcloud, aws и azure постараются сделать это простым и понятным способом. Потому что, насколько я понимаю, решение подразумевает создание множества скриптов, которые будут управлять такими вещами, как масштабирование.
Вы не можете сделать это на [Google] Kubernetes Engine сегодня (gcloud). В настоящее время Kubernetes Engine поддерживает только виртуальные машины Linux. Я не знаю (это не означает, что их нет) каких-либо планов по поддержке одного кластера с несколькими ОС.