2016-11-14 2 views
1

У меня есть кластер Kubernetes v1.4, работающий в AWS с узлами автоматического масштабирования. У меня также есть кластер Монго копия Установить с SSL-соединениями только (с общим именем FQDN) и записей публичных DNS:Создайте запись записи A в Kubernetes local DNS

  • node1.mongo.example.com -> 1.1.1.1
  • node2.mongo. example.com -> 1.1.1.2
  • node3.mongo.example.com -> 1.1.1.3

узлы Kubernetes являются частью группы безопасности, которая позволяет получить доступ к Монго кластера, но только через их частных IP-адресов.

Есть ли способ создания записей A в Kubernetes DNS с частными IP-адресами при запросе публичного FQDN?

Первая вещь, которую я попробовал, был сценарий & ConfigMap комбинация для обновления/и т.д./хостов при запуске (см. Is it a way to add arbitrary record to kube-dns?), но это проблематично, так как другие Kubernetes услуги могут также обновить файл хостов в разное время.

Я также попытался услуги конфигурации & Enpoints:

--- 
apiVersion: v1 
kind: Service 
metadata: 
    name: node1.mongo.example.com 
spec: 
    ports: 
    - protocol: TCP 
     port: 27017 
     targetPort: 27017 
--- 
apiVersion: v1 
kind: Endpoints 
metadata: 
    name: node1.mongo.example.com 
subsets: 
    - addresses: 
     - ip: 192.168.0.1 
    ports: 
     - port: 27017 

Но это не удается, как имя службы не может быть полное доменное имя ...

+0

Вы думаете об использовании экземпляра mongo AWS public DNS (общедоступное имя хоста)? Он перенаправляет на частный IP при вызове из экземпляра ec2: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#vpc-public-ip-addresses –

ответ

5

Хотя не так очевидно, во-первых, решение довольно просто , Изображение kube-dns в последних версиях включает в себя dnsmasq как один из его компонентов. Если вы заглянете в его страницу руководства, вы увидите несколько полезных вариантов. После этой лекции вы можете выбрать путь, подобный этому:

Создать ConfigMap для хранения Dns отображения:

apiVersion: v1 
kind: ConfigMap 
metadata: 
    name: kube-dns 
    namespace: kube-system 
data: 
    myhosts: | 
    10.0.0.1 foo.bar.baz 

Имея, что ConfigMap применяется в кластере, теперь вы можете внести некоторые изменения в kube-dns-vXX развертывания вы используете в ваших кубернетах.

Определить объем, который будет разоблачать ваш CM к dnsmasq

volumes: 
    - name: hosts 
    configMap: 
     name: kube-dns 

и крепление в вашем dnsmasq контейнере шаблона kube-dns развертывания/гс

volumeMounts: 
    - name: hosts 
     mountPath: /etc/hosts.d 

и, наконец, добавить небольшой флаг конфигурации к вашему dnsmasq:

args: 
    - --hostsdir=/etc/hosts.d 

теперь, когда вы применяете эти изменения к развертыванию kube-dns-vXX в своем кластере, он смонтирует конфигурационную карту и использует файлы, установленные в /etc/hosts.d/ (с типичным файлом в формате хоста) в качестве источника знаний для dnsmasq. Следовательно, если вы сейчас запрашиваете foo.bar.baz в своих контейнерах, они будут решать соответствующий IP-адрес. Эти записи имеют приоритет над публичным DNS, поэтому он должен идеально соответствовать вашему делу.

Учтите, что dnsmasq не следит за изменениями в ConfigMap, поэтому его необходимо перезапустить вручную, если он изменится.

Протестировано и подтверждено это на живом кластере всего несколько минут назад.

Смежные вопросы