🪄 CoreDNS и systemd-resolved
Ух, пришлось сегодня изрядно помучиться и поломать голову насчет DNS.
В чем проблема?
Проблема в том, что центральный сервер 1С выдает клиенту адрес рабочего процесса в формате хост:порт. Чтобы начать работу в информационной базе, клиент должен установить TCP соединение с этим рабочим процессом. Я относительно легко смог сделать так, чтобы клиент, находящийся снаружи кластера Kubernetes, мог зарезолвить имя рабочего сервера в IP-адрес балансировщика.
Для этого я сделал 3 вещи:
1️⃣ прикинул, что в реестре кластера 1С все серверы должны быть зарегистрированы по имени службы, а не по имени хоста, иначе снаружи Kubernetes до них будет не достучаться
2️⃣ ночью чуть-чуть изменил гравитационное поле Земли добавил плагин k8s_external для CoreDNS в своем кластере Kubernetes, выставил сам CoreDNS наружу
3️⃣ настроил systemd-resolved на хосте так, чтобы запросы к зоне cluster.local шли на CoreDNS.
Изи 🤓
Загвоздка тут в том, что серверы кластера 1С будут общаться друг с другом через этот же внешний IP-адрес балансировщика.
Что в этом плохого? Ну, во-первых, скорее всего будут лишние "хопы", соответственно, увеличатся задержки. Во-вторых, некоторые облачные провайдеры тарифицируют балансировщики не только по времени, но и по трафику.
Я думал, призывал на помощь ИИ и экспериментировал, но сделать так называемый Split-DNS в Kubernetes у меня пока не получилось. Split-DNS - это когда одно имя резволвится в один адрес при обращении к нему из одной сети, и в другой адрес при обращении из другой сети.
Однако, я обновил лабу 03-kind-hello-world-1c разделом с настройкой DNS как оно есть сейчас, а задачу по настройке Split-DNS отправил в бэклог.
Как же в тему сейчас этот стикер 👇
Ух, пришлось сегодня изрядно помучиться и поломать голову насчет DNS.
В чем проблема?
Проблема в том, что центральный сервер 1С выдает клиенту адрес рабочего процесса в формате хост:порт. Чтобы начать работу в информационной базе, клиент должен установить TCP соединение с этим рабочим процессом. Я относительно легко смог сделать так, чтобы клиент, находящийся снаружи кластера Kubernetes, мог зарезолвить имя рабочего сервера в IP-адрес балансировщика.
Для этого я сделал 3 вещи:
1️⃣ прикинул, что в реестре кластера 1С все серверы должны быть зарегистрированы по имени службы, а не по имени хоста, иначе снаружи Kubernetes до них будет не достучаться
2️⃣ ночью чуть-чуть изменил гравитационное поле Земли добавил плагин k8s_external для CoreDNS в своем кластере Kubernetes, выставил сам CoreDNS наружу
3️⃣ настроил systemd-resolved на хосте так, чтобы запросы к зоне cluster.local шли на CoreDNS.
Изи 🤓
Загвоздка тут в том, что серверы кластера 1С будут общаться друг с другом через этот же внешний IP-адрес балансировщика.
Что в этом плохого? Ну, во-первых, скорее всего будут лишние "хопы", соответственно, увеличатся задержки. Во-вторых, некоторые облачные провайдеры тарифицируют балансировщики не только по времени, но и по трафику.
Я думал, призывал на помощь ИИ и экспериментировал, но сделать так называемый Split-DNS в Kubernetes у меня пока не получилось. Split-DNS - это когда одно имя резволвится в один адрес при обращении к нему из одной сети, и в другой адрес при обращении из другой сети.
Однако, я обновил лабу 03-kind-hello-world-1c разделом с настройкой DNS как оно есть сейчас, а задачу по настройке Split-DNS отправил в бэклог.
Как же в тему сейчас этот стикер 👇