<p>kubeadm должен сделать доступной параметр --node-ip</p>

В настоящее время у меня возникают проблемы с настройкой кластера Kubernetes в DigitalOcean из-за этого. По умолчанию kubelet будет связывать и раскрывать / транслировать IP-адрес шлюза по умолчанию, который в этих случаях является общедоступным IP-адресом, обращающимся к Интернет-трафику. Затем, когда доходит до настройки надстройки сети для модулей (например, Weave), весь ад вырывается наружу, потому что рекламный IP-адрес мастера является IP-адресом внутренней сети, но рабочие узлы пытаются раскрыть общедоступный: /

Решение состоит в том, чтобы обновить файл модуля, расположенный под /etc/systemd/system/kubelet.service.d/10-kubeadm.conf чтобы добавить --node-ip=<private_worker_ip> , перезагрузить модули и перезапустить kubelet, чтобы он заработал.

Если kubeadm может сделать это по умолчанию, передав параметр вроде @nkratzke, это было бы здорово!

Я просто хотел подтвердить, что добавление опции --node-ip=<private-worker-ip> к настройкам в файле /etc/systemd/system/kubelet.service.d/10-kubeadm.conf не решит эту проблему для настройки, о которой я говорил ранее. Несмотря на то, что узлы прослушивают этот интерфейс, Kubernetes продолжает использовать шлюз по умолчанию для связи между узлами, который в данном случае является общедоступным IP-адресом.

У меня такая же проблема. Я попробовал ваш метод, и у меня он тоже не сработал. Удалось ли вам заставить его работать?

@agsergi Я пытался настроить кластер k8s в DigitalOcean с включенной опцией Private Networking , что привело меня к этой проблеме. Отключение этой функции помогло мне, но я не уверен, что вы в одной лодке.

Я предполагаю, что эта проблема будет по-прежнему присутствовать, если к машине подключено более двух сетевых адаптеров.

Ребята,
У меня есть два интерфейса на моей виртуальной машине: один для NAT, а второй - для hostonly-adapter. По умолчанию kubeadmin использовал IP-адрес интерфейса по умолчанию (в моем случае NAT), если вы хотите использовать другой интерфейс, используйте:
$ sudo kubeadm init --apiserver-Advertise-address =

И у меня это сработало.

@luxas Почему это помечено как

@evocage нет --apiserver-Advertise-address =

огромное спасибо.

Я столкнулся с той же проблемой на Scaleway.

Когда я инициализировал мастер, я передал --apiserver-advertise-address=<private_net_IP> но когда я хочу добавить узел ( kubeadm join --toke=<token> <master_private_IP>:6443 ), модули kube-proxy и weave-net не запускаются (модуль синхронизации ошибки)

Но когда я подключаю общедоступный IP-адрес к своему узлу и перезагружаюсь, все идет хорошо: думаю:

Любая идея?

Та же проблема при попытке настроить Kubernetes на хосте виртуальной машины с одним IP, где только некоторые порты могут быть перенаправлены на виртуальные машины. Есть ли способ заставить его работать?

Просто хотел +1. Я пытаюсь запустить набор виртуальных машин Digitalocean с частным IP-адресом на всех из них, но общедоступный адрес каким-то образом продолжает свой путь в кластер.

Мне удалось заставить работать частные IP-адреса, запустив это на главном сервере:

kubeadm init --apiserver-advertise-address=<private-master-ip> init

Добавление --node-ip=<private-node-ip> в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf , перезагрузка демона, перезапуск kubelet, затем запуск:

kubeadm join --token <token> <private-master-ip>:6443 --discovery-token-ca-cert-hash sha256:<hash>

@mongrelion Какой тип связи между главным узлом <-> все еще использует общедоступные интерфейсы? Мне не удалось воспроизвести это, поэтому мне было бы интересно узнать, ведет ли себя кубернет неожиданно.

Вот и все! Комбинация --apiserver-advertise-address обеспечивающая запуск мастера в нужном месте, и --node-ip в конфигурации kubelet были волшебной комбинацией.

Согласно этому запросу, наличие этой опции --node-ip непосредственно в kubeadm чтобы файлы конфигурации были инициализированы правильно, было бы полезно для невежественных новичков, таких как я, пытающихся раскрутить кластеры :)

Спасибо @jamiehannaford за это резюме. Считаем ли мы, что нам следует задокументировать это более наглядно?

@luxas Да, я думаю, было бы полезно явно задокументировать этот вариант использования.

@jamiehannaford Если вы хотите добавить это также в перестановку документов для v1.9, пришлите мне абзац для добавления на https://github.com/kubernetes/website/pull/6103

@fabriziopandini Конечно! Сделанный

Привет,

Я также хочу дать обратную связь. Я пытаюсь использовать kubeadm для создания безопасного кластера с одним узлом.
Я бы хотел, чтобы все службы Kubernetes были привязаны к localhost, но это не работает.

Я использую эту команду, и кластер создается:
kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=127.0.0.1 \ --apiserver-cert-extra-sans=127.0.0.1,staging.my-server.net
Однако /etc/kubernetes/admin.conf и друзья содержат публичный IP-адрес мастера.
server: https://75.xx.yy.zz:6443

Я попробую использовать подход --node, но был бы признателен, если бы вы помогли мне найти решение для этого.

Мой вариант использования:

У меня есть мощная машина, которую я хочу использовать в качестве промежуточной среды и, возможно, в качестве производственной среды для небольших проектов, где меня не волнует HA. Я могу использовать SSH и kubectl для управления кластером.

Спасибо,

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

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

Что происходит, так это то, что kubelet установленный kubeadm смотрит на интерфейсы и решает добавить в микс свою собственную частную подсеть, независимо от назначенных IP-адресов или доступных интерфейсов, и хочет сделать это дальше. тот же, который он считает "основным" (первый? WAN? Я не знаю). Это не видно через ifconfig но легко через ip addr , и маршрут также настроен, но нет никаких шансов, что он пролетит через сеть DO, которая соединяет узлы eth0 .

РЕДАКТИРОВАТЬ: Благодаря @klausenbusk кажется, что kubelet выбирает IP-адрес привязки в предположении, что он может быть полезен, когда это не так. Подробности см. Ниже.

Решение действительно состоит в том, чтобы указать kubelet, какой IP-адрес использовать. Это может быть общедоступная или частная, если вы используете дополнительную частную сеть.

Вот как я использовал --node-ip . Будьте осторожны, это предполагает, что KUBELET_EXTRA_ARGS еще не было установлено в файле модуля.

$ DROPLET_IP_ADDRESS=$(ip addr show dev eth0 | awk 'match($0,/inet (([0-9]|\.)+).* scope global eth0$/,a) { print a[1]; exit }')
$ echo $DROPLET_IP_ADDRESS  # check this, jus tin case
$ echo "Environment=\"KUBELET_EXTRA_ARGS=--node-ip=$DROPLET_IP_ADDRESS\"" >> /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
$ systemctl daemon-reload
$ systemctl restart kubelet

@lloeki Спасибо за https://github.com/kubernetes/website/blob/master/docs/setup/independent/troubleshooting-kubeadm.md

Таким образом, он выбирает один WAN (eth0), видит (или игнорирует) общедоступный IP-адрес и решает добавить вторую частную подсеть (например, 10.19.0.0/255 в моем случае), вероятно, полагая, что все узлы eth0 являются по той же ссылке.

Вы уверены, что? Это может быть просто IP-адрес привязки (сравните с curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address )

@klausenbusk, вы абсолютно правы, это были --node-ip .

Так что, кажется, kubelet выбирает его, исходя из предположения, что он может быть полезен, когда это не так?

$ curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
10.19.0.39
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet yyy.yyy.yyy.yyy/20 brd yyy.yyy.yyy.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.19.0.39/16 brd 10.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Не могли бы вы обновить документы

@jamiehannaford Похоже, я могу это сделать :)

/ назначить @liztio

Я посмотрел на это, и я думаю, что консенсус, даже если пользователи запрашивают добавление аргумента --node-ip в kubeadm, заключается в том, что изменение конфигурации kubelet и использование параметров, таких как @jamiehannaford, предлагает вот рекомендуемый подход:
https://github.com/kubernetes/kubeadm/issues/203#issuecomment -335416377

(или, возможно, добавление в $ KUBELET_EXTRA_ARGS перед перезапуском кублета).

учитывая решение отказаться от добавления дополнительных аргументов cmd в kubeadm, я думаю, что было бы безопасно закрыть эту проблему .... если нет планов включить это с помощью параметров kubeadm MasterConfig (как-то ?? ... поскольку мы полагаемся на пользователь, редактирующий конфиг kubelet и опирающийся на изменения вручную).

edit: или, возможно, с динамической конфигурацией kubelet, если это возможно?

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

@timstclair @liztio

Я согласен закрыть это.

Просто обратите внимание, что в Kubernetes 1.11 настройка KUBELET_EXTRA_ARGS в /etc/systemd/system/kubelet.service.d/20-custom.conf больше не работает: ее нужно установить в / etc / sysconfig / kubelet (немного другой синтаксис этих файлов).

@stepin Я только что настроил кластер 1.11 с помощью kubeadm и получил его потом cat: /etc/sysconfig/kubelet: No such file or directory

/etc/systemd/system/kubelet.service.d/20-custom.conf тоже не существует, поэтому я не уверен, что вы там делали.

Если то, что вы сказали, было правдой, похоже, игра в конфиг хот-картофель продолжается.

Мне удалось найти еще одно место для конфигурации kubelet здесь: /etc/default/kubelet

Для будущих путешественников (по крайней мере, на следующей неделе) это, похоже, сработает:

PRIVATE_IP=10.99.0.0
echo "KUBELET_EXTRA_ARGS=--node-ip=$PRIVATE_IP" > /etc/default/kubelet
systemctl daemon-reload
systemctl restart kubelet

Очевидно, вам нужно будет изменить IP-адрес на тот, который у вас есть на этом конкретном узле.

Отказ от ответственности: я просто проверяю Kubernetes, поэтому не гарантирую, что это не приведет к чему-то ужасному. Хотя, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf действительно указывает на /etc/default/kubelet , так что я думаю, что это правильно.

@jazoom - Спасибо за ваш комментарий, это, наконец, побудило меня более внимательно прочитать файл модуля systemd. Я думал, что схожу с ума, так как могу вызвать ту же конфигурацию в 1.10, и все сработало ... вывести конфигурацию в 1.11, а пользовательский --node-ip я установил, вообще не применялся. Переключение на добавление дополнительных аргументов в /etc/default/kubelet устранило проблему для меня.

@geerlingguy Пожалуйста .

По крайней мере, это не был случай, когда «он работает каждый второй раз, когда я поднимаю кластер 1.11». Эти невоспроизводимые проблемы действительно сведут вас с ума.

Только что столкнулся с этим в «Кубеадм 1.13». Исправлено с помощью следующего:

1) Добавьте "--node-ip" в '/var/lib/kubelet/kubeadm-flags.env':

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

2) Перезапускаем Кубелет:

systemctl daemon-reload && systemctl restart kubelet

^ Если кто-то знает, как заставить это работать с плавающими IP-адресами, которые не отображаются на сетевом адаптере, сообщите мне. В противном случае успешно.

Привет,

Пожалуйста, попробуйте это https://wiki.hetzner.de/index.php/Cloud_floating_IP_persistent/en .
Это работает для Hetzner, но я думаю, что это универсальный вариант.
Евгений

Это сработало отлично. Спасибо.

Только что столкнулся с этой проблемой в "Kubeadm 1.13". Проблема устранена следующими способами:

1. Добавьте "--node-ip" в "/var/lib/kubelet/kubeadm-flags.env":

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

1. Перезапускаем Кубелет:

systemctl daemon-reload && systemctl restart kubelet

большое спасибо, переезд