Мы используем k8s 1.9.3, управляемый через kops 1.9.3 в AWS с DNS на основе Gossip с использованием сетевого плагина weave cni.
Я выполнял непрерывное обновление основных IG, чтобы включить некоторые дополнительные контроллеры доступа. (PodNodeSelector и PodTolerationRestriction) Я сделал это в двух других кластерах без проблем. Когда кластер начал работу с третьим мастером (мы запускаем наш кластер в 3 основных настройках), он выключил экземпляр и попытался вызвать новый мастер-экземпляр, но новый мастер-экземпляр не смог присоединиться к кластеру. После дальнейших исследований и последующих попыток свернуть третий мастер, чтобы перенести его в кластер, я обнаружил, что третий, не присоединяясь к мастеру, продолжает пытаться присоединиться к кластеру как IP-адрес старых мастеров. Хотя это IP-адрес это что-то другое. Наблюдение за kubectl get nodes | grep master показывает, что кластер считает, что это старый IP-адрес, и он терпит неудачу, потому что это уже не тот IP-адрес. Похоже, что по какой-то причине DNS на основе сплетен в кластере не получает уведомление о IP-адресе нового мастера.
Это вызывает проблемы, потому что у kubernetes svc по-прежнему есть ip-адрес старого мастера, что приводит к сбою любых запросов API, направленных на этот несуществующий мастер-сервер. Это также вызывает проблемы для etcd, который продолжает пытаться связаться с ним по старому IP-адресу. Много журналов, как это:
018-10-29 22:25:43.326966 W | etcdserver: failed to reach the peerURL(http://etcd-events-f.internal.kops-prod.k8s.local:2381) of member 3b7c45b923efd852 (Get http://etcd-events-f.internal.kops-prod.k8s.local:2381/version: dial tcp 10.34.6.51:2381: i/o timeout)
2018-10-29 22:25:43.327088 W | etcdserver: cannot get the version of member 3b7c45b923efd852 (Get http://etcd-events-f.internal.kops-prod.k8s.local:2381/version: dial tcp 10.34.6.51:2381: i/o timeout)
Одна странность состоит в том, что если я запускаю etcdctl cluster-health на доступных экземплярах master и т. Д., То все они показывают идентификатор нездорового члена как f90faf39a4c5d077, но когда я просматриваю журналы событий etcd, я вижу, что он видит идентификатор участника нездоровья как 3b7c45b923efd852. Так что, кажется, есть некоторое несоответствие с etcd.
Поскольку мы работаем в мастер-настройке с тремя узлами и одним мастером, мы не хотим перезапускать другие мастера, чтобы попытаться исправить проблему, потому что боимся потерять кворум в кластере etcd.
Мы используем weave 2.3.0 в качестве нашего сетевого поставщика CNI.
На отказавшем мастере заметил, что weave cni config /etc/cni/net.d/10-weave.conf не создается, а файлы /etc/hosts на рабочих мастерах не обновляются должным образом с новым IP-адресом мастера. Похоже, kube-proxy по какой-то причине не получает обновление.
Запуск образа debian 8 (jessie) по умолчанию, который предоставляется с kops 1.9.
Как заставить мастер корректно обновить DNS с новым IP-адресом?