Kubernetes: объединение кластера Kops с локальным кластером Kubeadm

В настоящее время у нас есть 2 кластера Kubernetes:

  • Одна установка с Kops, работающей на AWS

  • Одна установка с Kubeadm, работающим на нашем собственном оборудовании

Мы хотим объединить их, чтобы иметь возможность управлять только одним кластером.

Мастер может оказаться на AWS или на наших серверах, и то, и другое в порядке.

Мы не можем найти способ добавить узлы, настроенные для одного кластера, в другой.

Этот вопрос вызывает тот же вопрос, но остался без ответа: https://github.com/kubernetes/kops/issues/5024


person MasterScrat    schedule 19.07.2018    source источник


Ответы (1)


Вы можете присоединиться к узлам вручную, но это действительно не рекомендуемый способ.

Если вы используете kubeadm, у вас, вероятно, уже установлены все соответствующие компоненты на воркерах, чтобы они могли правильно подключиться. Я бы сказал, что следующий процесс:

запустить kubeadm reset в рассматриваемой локальной среде

войдите в узел kops и изучите конфигурацию kubelet:

systemctl cat kubelet

Здесь вы увидите, что конфигурация kubelet указана в /etc/sysconfig/kubelet. Вам нужно будет скопировать этот файл и убедиться, что локальный узел имеет его в своей конфигурации запуска systemd.

Скопируйте соответствующую конфигурацию на локальный узел. Вам нужно будет удалить все ссылки на материалы облачного провайдера AWS, а также убедиться, что имя хоста является действительным. Вот пример конфигурации, которую я скопировал с узла kops и изменил:

DAEMON_ARGS="--allow-privileged=true --cgroup-root=/ --cluster-dns=100.64.0.10 --cluster-domain=cluster.local --enable-debugging-handlers=true - --feature-gates=ExperimentalCriticalPodAnnotation=true --hostname-override=<my_dns_name> --kubeconfig=/var/lib/kubelet/kubeconfig --network-plugin=cni --node-labels=kops.k8s.io/instancegroup=onpremnodes,kubernetes.io/role=node,node-role.kubernetes.io/node= --non-masquerade-cidr=100.64.0.0/10 --pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0 --pod-manifest-path=/etc/kubernetes/manifests --register-schedulable=true --v=2 --cni-bin-dir=/opt/cni/bin/ --cni-conf-dir=/etc/cni/net.d/"
HOME="/root"

Также проверьте конфигурацию kubelet kubeconfig (она должна быть /var/lib/kubelet/kubeconfig). Это конфигурация, которая сообщает kubelet, на каком сервере API регистрироваться. Убедитесь, что он существует на локальном узле

Это должно заставить ваш узел присоединиться к API. Возможно, вам придется выполнить некоторую отладку во время этого процесса.

Я действительно не рекомендую это делать по следующим причинам:

  • Если вы не используете метки узлов разумным образом, у вас возникнут проблемы с подготовкой облачных элементов. Кубелет будет регулярно взаимодействовать с API AWS, поэтому, если вы попытаетесь использовать службу типа LoadBalancer или какие-либо облачные тома, вам нужно будет привязать рабочие нагрузки к определенным узлам. Вам придется активно использовать порчи и допуски.
  • Рабочие Kubernetes не предназначены для подключения по WAN. Вероятно, в какой-то момент вы столкнетесь с проблемой с задержкой в ​​сети и т. Д.
  • Если вы все же решите пойти по этому маршруту, вам необходимо убедиться, что у вас настроен TLS в обоих направлениях для связи API ‹-> kubelet или VPN.
person jaxxstorm    schedule 19.07.2018
comment
Спасибо за молниеносный ответ! - person MasterScrat; 21.07.2018
comment
Вы должны понимать, что делать это - плохая идея. Я видел этот ответ несколько месяцев назад и не знал, сколько у меня будет проблем. Главный: cloud-provider = aws. Вам необходимо отредактировать статические манифесты на главных узлах и удалить облачного провайдера aws, чтобы предотвратить удаление ваших локальных узлов из кластера kops AWS, но если вы это сделаете ... вы потеряете интеграцию с AWS (например, создание томов EBS, балансировщика нагрузки для сервисов и т. Д. .). Это изменение невозможно сделать из kops, поэтому после обновления / масштабирования / изменения кластера вам придется снова и снова редактировать манифесты ... - person Mariusz Dalewski; 16.04.2019