Я могу установить единую главную среду k8s (1.17.3) и теперь планирую развернуть MultiMaster, выполнив следующие действия. ссылка на сайт с kubeadm (составная плоскость управления и узлы etcd)
Требуется предоставить --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT".
почему kubeadm требует информацию о балансировщике нагрузки? так как
Я хочу, чтобы информация о балансировщике нагрузки не входила в кластер, чтобы я мог свободно менять IP-адрес балансировщика нагрузки в любое время, не мешая кластеру, поскольку каждый мастер прослушивает
- 10.10.10.1:6443
- 10.10.10.2:6443
- 10.10.10.3:6443
Если какой-либо компонент в кластере хочет передать его, используя преобразователь конечных точек, если я прав?
Предоставляя конечную точку уровня управления, наша информация LB тесно связана с конфигурацией кластера. Могу ли я получить несколько мастеров без указания точки управления?
Обновление1:
В ответ на @mdaniel. Если мы предоставим IP одного из Мастеров в --control-plane-endpoint, он станет Единственной точкой отказа для добавления новой плоскости управления.
Предположим, я поставил 10.10.10.1:6443 как конечную точку плоскости управления, и после этого этот мастер не работает, и я хочу добавить еще одну плоскость управления, это не будет успешным, я попытался выполнить
kubeadm join 10.10.10.2:6443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane --certificate-key ...
это дает следующую ошибку
[preflight] Running pre-flight checks
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
error execution phase preflight: unable to fetch the kubeadm-config ConfigMap: failed to get config map: Get https://10.10.10.1:6443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout=10s: dial tcp 10.10.10.1:6443: connect: connection refused
Дело в том, что если я явно упомянул другой CP, он должен учитывать это, а не все еще выбирать CM из старого CP.
Да, я могу обойтись, изменив записи в
PS: Я знал, что предполагаю использовать LB, но у меня есть конкретный сценарий, когда я представлю LB позже в своем центре обработки данных.
почему kubeadm требует информацию о балансировщике нагрузки?
Потому что вам не нужно обновлять каждый kubeconfig во вселенной, когда ваш главный IP-адрес обновляется. Вы можете использовать записи CNAME, запись A с несколькими ответами, запутанную систему общего IP или любое решение высокой доступности, соответствующее вашим потребностям и опыту, но в 99,99% случаев наличие балансировщика нагрузки перед серверами api является решение, которое вызывает наименьшую возможную головную боль.
Это, очевидно, неверно в 100% случаев, так как у меня были ненулевые случаи, когда проверки работоспособности балансировщика нагрузки не выполнялись, изолируя серверы api от остальной части кластера, что превращало небольшой пожар в бушующий ядерный, но В основном это наименее болезненно.
Для ясности, остальная часть вашего вопроса о --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" это просто набор слов из справочного текста, и он не требуется. Вы можете подключить 10.10.10.1:6443 к этому аргументу (или любому из них, на самом деле), если машина работает kubeadm может связаться с этим IP-адресом на этом порту, и что IP-адреса ваших серверов api указаны в списке SAN для своих сертификатов.