Интегрировать локально выполняемый сервис (миникуб) в кластер Kubernetes - PullRequest
Новая
       59

Интегрировать локально выполняемый сервис (миникуб) в кластер Kubernetes

0 голосов
/ 06 апреля 2020

В настоящее время я нахожусь в процессе проектирования кластера Kubernetes для существующей установки, которая включает в себя около десяти служб. Ранее я разрабатывал и тестировал эти сервисы локально с помощью Minikube, а позже я опубликовал их самостоятельно размещенный экземпляр Kubernetes на другой физической машине (назовем это промежуточной системой). Некоторые из этих развернутых сервисов должны иметь доступ к ресурсам на других машинах в той же сети. Это означает, что моей среде разработки (minikube) также необходим доступ к этим внешним ресурсам. Вот краткий «макет» одного процесса в этом кластере. 

+-----------+
| External  |
| Service X |
+-----------+
    ^
    |
+-----------+       +-----------+
| Service A |  <--  | Service B |
+-----------+       +-----------+

Из-за некоторых сетевых изменений я больше не могу получить доступ к этим удаленным ресурсам, это означает, что Внешняя служба X больше не является достижимо с моей локальной машины. Я знаю вопрос, можно ли каким-то образом разместить Службу B на моей локальной машине, но «подключить» ее к моему удаленному кластеру. Можно ли каким-то образом использовать миникуб в качестве простого узла для существующего экземпляра Kubernetes? Я сильно полагаюсь на обнаружение сервисов с CoreDNS, что означает, что я хотел бы найти решение на уровне инфраструктуры вместо подхода на уровне приложений. Было бы идеально, если бы промежуточная система даже не знала, что моя Служба B не размещена локально. Прошу прощения, если это, может быть, глупый вопрос, но мне кажется, что я немного разбираюсь в Куберне на данный момент.

1 Ответ

0 голосов
/ 10 апреля 2020

Если у вас есть два отдельных кластера kubernetes например, локальный экземпляр Minikube и некоторый другой удаленный кластер kubernetes , и вы хотите, чтобы они могли взаимодействовать с одним другой, вы можете использовать для этой цели так называемые службы без селекторов .

Вы можете рассматривать удаленный kubernetes кластер как любой другой внешний ресурс (например, сервер базы данных, работающий на отдельная машина / VM), и вы можете представить его внутри вашего кластера. Обычно мы открываем что-то, что выполняется на нашем k8s кластере извне, но в этом случае мы хотим предоставить внешний ресурс внутри нашего кластера, как если бы он был еще одним внутренним ресурсом. С точки зрения Pods он фактически выглядит как внутренний ресурс, который доступен в локальном кластерном домене, точно так же, как внутренние ресурсы, предоставляемые простой службой ClusterIP.

Давайте кратко рассмотрим как этого добиться. Это очень хорошо объяснено в этом разделе официальных документов kubernetes:

Службы, чаще всего абстрактные для доступа к бобам Kubernetes, но они также могут абстрагировать другие типы бэкэндов. Например:

  • Вы хотите иметь кластер внешней базы данных в рабочем состоянии, но в своей тестовой среде вы используете свои собственные базы данных.
  • Вы хотите, чтобы ваша служба указывала на службу в другое пространство имен или другой кластер.
  • Вы переносите рабочую нагрузку в Kubernetes. Оценивая подход, вы запускаете только часть своих бэкэндов в Kubernetes.

В любом из этих сценариев ios вы можете определить Сервис без селектора Pod. Например: 

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Поскольку эта служба не имеет селектора, соответствующий объект конечной точки не создается автоматически. Вы можете вручную сопоставить Службу с сетевым адресом и портом, где она работает, добавив объект Endpoint вручную: 

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

Если между упомянутыми dev существует только сетевое подключение и промежуточные среды, в которых вы можете использовать Services без селекторов . Если вам нужен кластер Minikube для подключения к чему-либо, выставленному на 192.0.2.42:9376 с помощью вашего промежуточного кластера, вам просто нужно использовать этот IP в ваших Конечных точках определение объекта. Служба определена для прослушивания по порту 80, поэтому она будет в конечном итоге предоставлена ​​вам Minikube Pods через этот стандартный порт.

Самое большое преимущество такого решения заключается в том, что такое Service делает указанный c внешний ресурс внутренне доступным для приложений, работающих в Pods в локальном k8s кластере , и они могут ссылаться на него, используя его DNS-имя , т.е. service-name в пределах тот же namespace или по полному доменному имени <my-service-name>.<namespace>.svc.cluster.local из любого namespace, для всего кластера.

Если ваш внешний ресурс доступен под доменным именем , вы может также рассмотреть возможность использования ExternalName , который является специальным типом службы без селектора , и в этом случае вам не нужно настраивать вручную любые объекты Endpoints. Его определение может выглядеть так: 

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com
...