А никто не сталкивался с такой проблемой. Мне etcd pod'ы, которые

создает etcd-operator cilium'а
Спамят 50-60 раз в секунду такую ошибку

2020-12-11 16:52:36.002166 I | embed: rejected connection from "10.245.4.173:32988" (error "tls: \"10.245.4.173\" does not match any of DNSNames [\"*.cilium-etcd.kube-system.svc\" \"*.cilium-etcd.kube-system.svc.cluster.local\"]", ServerName "cilium-etcd-c2m6jflr96.cilium-etcd.kube-system.svc", IPAddresses [], DNSNames ["*.cilium-etcd.kube-system.svc" "*.cilium-etcd.kube-system.svc.cluster.local"])

Нашел issue https://github.com/cilium/cilium-etcd-operator/issues/37
Мол включите реверсивный резолв в CoreDNS. Он у меня конечно включен. PTR записи есть. (https://github.com/cilium/cilium/blob/aa22314462750c67a18a18ba6b5d4a16f3a99c4d/Documentation/gettingstarted/k8s-install-etcd-operator-steps.rst)
В качестве проверки дают пример такого DNS запроса:

```
host 10.60.20.86
86.20.60.10.in-addr.arpa domain name pointer cilium-etcd-972nprv9dp.cilium-etcd.kube-system.svc.cluster.local.
```

Но вот беда, у меня etcd оператор создает две службы cilium-etcd, cilium-etcd-client, и coredns по всей видимости рандомно возвращает результат.
Здесь 10.245.4.173 - адрес pod'а etcd, который фигурирует в ошибке другого pod'а (ошибку смотрите выше). 10.245.4.75 - адрес CoreDNS pod'а
Вот несколько одинаковых DNS запросов, которые возвращают разные результаты:

```
$ dig -x 10.245.4.173 @10.245.4.75 +short
10-245-4-173.cilium-etcd-client.kube-system.svc.cluster.local.

$ dig -x 10.245.4.173 @10.245.4.75 +short
10-245-4-173.cilium-etcd-client.kube-system.svc.cluster.local.

$ dig -x 10.245.4.173 @10.245.4.75 +short
cilium-etcd-54glklt9sp.cilium-etcd.kube-system.svc.cluster.local.

$ dig -x 10.245.4.173 @10.245.4.75 +short
cilium-etcd-54glklt9sp.cilium-etcd.kube-system.svc.cluster.local.
```

И видимо etcd такого никак не ожидает.

Видно что тут два первых запроса вернули PTR для службы cilium-etcd-client, а два последних для cilium-etcd.
Служба cilium-etcd - headles. Оператор использует чтобы собрать кластер etcd. А вот cilium-etcd-client обычная, используется для подключения к ней cilium агентов и cilium оператора.

Чет какая-то боль с этим managed etcd в cilium. В 1.9.1 он вообще кластер не может собрать, так как нет еще сети, а cilium агенты не могут подняться так как нет работающего etcd кластера.
Походу etcd оператор в cilium не продакшн реди. Либо я его как-то не так готовлю?

Пиши в слак им

Перегенири серты

Сказали что будут открываться от etcd-оператора

а он сам их генерит. Для этого достаточно дропнуть секреты с ними, потом дропнуть etcdcluster и pod cilium-etcd-operator'а. Я это пробовал, пробовал и переставлять весь cilium с полной очисткой его перед этим. Он странно как-то сделан. cilium-etcd-operator деплоет etcd-operator, который деплоет etcd кластер. Затем cilium-etcd-operator ждет, и если etcd кластер не собрался, то он его дропает и дропает etcd-operator и так по гр кругу. И у него получается успешно собрать кластер очень часто не с первого раза =)

о пасиб. У них же slack есть

а это в слеке написали? Или где-то анонсировали про это в блоге?

В слаке как-то написали, когда я у них про etcd-operator стал расспрашивать

Да вообще оригинальный etcd-operator давно дропнули :(

В смысле тот на котором основан cilium-etcd-operator

да там не то чтобы он основан. Он зачем-то поднимает etcd-operator, который уже поднимает кластер. В итоге получаем cilium-etcd-operator + etcd-operator - так странно

Дело в том, что etcd-operator обычно подразумевает персистент-кластер, но во многих кейсах хилить его не умеет, в случае с цилиумом, который использует etcd тупо для кэша проще убить и создать новый кластер, если что-то пошло не так

Он прям самого оператора спавнит или CR для него?

да, вот только странно что что-то идет не так. А потом он внезапно таки собирает кластер. Бывает такое, что он поднимает первый pod, потом второй не может поднять, с ошибкой (не удалось получить member list) и все. Так и висит пока cilium-etcd-operator снова не передеплоет etcd-operator, который будет передеплоивать etcd кластер. > Он прям самого оператора спавнит или CR для него? Прям оператора и похоже CRD тоже. В managedFields crd вижу и еtcd-operator и cilium-etcd-operator в менеджерах. Забавно что если etcd-operator не справляется. Он прям его дропает, а не только кластер =)

Там есть возможная проблема курицы и яйца, у тебя controller-manager или cilium выдаёт podCIDRs на ноды?

Да вроде проблем с выдачей ип подам нет. Поды успешно создаются и начинают пробовать собрать кластер. А вообще я настраивал чтобы controller-manager выдовал. Если я правильно это сделал. В helm чарте опции: config.ipam=kubernetes, global.k8s.requireIPv4PodCIDR=true Это для весрии 1.8.5, Для >= 1.9.0 они там поменяли чарт сильно. Но я щас про 1.8.5. В 1.9.1 etcd вообще не заводится без костылей

Тогда не знаю (

Кстати да, я спрашивал почему они от umbrella-chart отказались в итоге