Мы используем k8s 1.9.3, управляемый через kops 1.9.3 в AWS с DNS на основе Gossip, используя сетевой плагин weave cni.
Я выполнял непрерывное обновление основных IG, чтобы включить некоторые дополнительные контроллеры доступа. (PodNodeSelector и PodTolerationRestriction) Я сделал это в двух других кластерах без проблем. Когда кластер перешел к работе с третьим мастером (мы запускаем наш кластер в конфигурации с тремя мастерами), он отключил экземпляр и попытался запустить новый мастер-экземпляр, но новый мастер-экземпляр не смог присоединиться к кластеру. После дальнейших исследований и последующих попыток свернуть третий мастер, чтобы ввести его в кластер, я обнаружил, что третий, не сумев присоединиться к мастеру, продолжает пытаться присоединиться к кластеру в качестве 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 на доступных мастер-экземплярах etcd, все они показывают неработоспособный идентификатор участника как f90faf39a4c5d077, но когда я смотрю журналы etcd-events, я вижу, что он видит неработоспособный идентификатор участника как 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-адреса?
