Маршрутизация внутреннего трафика в Кубернетес?

Question

В настоящее время у нас есть настройка, при которой приложения в нашем кластере mesos/marathon хотят обращаться к сервисам, которые могут находиться или не находиться в нашем кластере mesos/marathon. Вход для внешнего трафика в кластер осуществляется через Amazon ELB, расположенный перед кластером экземпляров Traefik, который затем выбирает соответствующий набор экземпляров контейнера для балансировки нагрузки через входящий заголовок HTTP-хоста по сравнению с, по существу, множеством - одна связь настроенных заголовков хоста с конкретным экземпляром контейнера. Внутренний и внутренний трафик фактически обрабатывается тем же маршрутом, так как запись DNS, связанная с данной службой, сопоставляется с тем же ELB как внутренним, так и внешним по отношению к нашему кластеру mesos/marathon. Мы также даем возможность иметь несколько записей DNS, указывающих на один и тот же набор контейнеров.

Эта настройка работает, но вызывает, по-видимому, ненужный сетевой трафик и нагрузку на наши ELB, а также на наш кластер Traefik, как если бы приложения в контейнерах или другом компоненте могли самостоятельно определять, что службы, к которым они хотели бы обратиться, находились в пределах к конкретному кластеру mesos/marathon, в котором они находились, и сделать соответствующий вызов либо внутри кластера, находящемуся перед набором контейнеров, либо непосредственно в конкретный контейнер.

Из того, что я понимаю о Kubernetes, Kubernetes предоставляет концепцию сервисов, которые, по сути, могут выступать в качестве фронта для набора модулей, основанных на конфигурации, для которой модули должны соответствовать. Однако я не совсем уверен в механизме, с помощью которого мы можем прозрачно знать, как приложения в кластере Kubernetes перенаправляют сетевой трафик на сервисные IP-адреса. Я думаю, что этому можно помочь, если использовать прокси-трафик Envoy, например, для <application-name>.<cluster-name>.company.com к имени службы, но если у нас есть CNAME, которая сопоставляется с этой предыдущей записью DNS (скажем, <application-name>.company.com), Я не совсем уверен, как мы можем избежать выхода из кластера.

Есть ли хороший способ решить в обоих случаях? Мы стараемся избегать того, чтобы логика наших приложений понимала, что они находятся в определенном кластере, и предпочла бы, чтобы компонент вне приложений выполнял маршрутизацию надлежащим образом.

Если я в корне неправильно понимаю какой-то конкретный компонент, я бы с удовольствием оценил исправление!

Answer 1

Когда вы используете межсетевое взаимодействие внутри кластера, вы используете Service абстракция, которая является чем-то вроде статической точки, которая будет направлять движение к нужным стручкам.

Конечная точка службы доступна только внутри кластера по ее IP-адресу или внутреннему DNS-имени, предоставленному внутренним DNS-сервером Kubernetes. Таким образом, для общения внутри кластера, вы можете использовать DNS-имена, такие как <servicename>.<namespace>.svc.cluster.local,

Но, что более важно, у Сервиса есть статический IP-адрес.

Итак, теперь вы можете добавить этот статический IP как hosts записать в модули внутри кластера, чтобы убедиться, что они будут общаться друг с другом внутри кластера.

Для этого вы можете использовать функцию HostAlias. Вот пример конфигурации:

apiVersion: v1
kind: Pod
metadata:
  name: hostaliases-pod
spec:
  restartPolicy: Never
  hostAliases:
  - ip: "10.0.1.23"
    hostnames:
    - "my.first.internal.service.example.com"
  - ip: "10.1.2.3"
    hostnames:
    - "my.second.internal.service.example.com"
  containers:
  - name: cat-hosts
    image: busybox
    command:
    - cat
    args:
    - "/etc/hosts"

Таким образом, если вы будете использовать свой внутренний IP-адрес службы в сочетании с общедоступным полным доменным именем службы, весь трафик из вашего модуля будет на 100% внутри кластера, поскольку приложение будет использовать внутренний IP-адрес.

Также вы можете использовать вышестоящий DNS- сервер, который будет содержать те же псевдонимы, но идея будет такой же. При использовании Upstream DNS для отдельной зоны разрешение будет работать так:

С новой версией Kubernetes, которая использует Core DSN для предоставления услуг DNS и имеет больше возможностей, это будет немного проще.