Сервисная архитектура Kubernetes

Question

В одном и том же кластере kubernetes,

(1) Могу ли я иметь несколько StatefulSets, подключенных к одному безголовому сервису, или каждый StatefulSet должен иметь свой собственный безголовый сервис?Каковы плюсы и минусы этого?

(2) Можно ли смешивать стандартные и автономные сервисы в одном кластере?В частности, я хотел бы использовать сервис LoadBalancer для балансировки нагрузки безголовых сервисов.Могу ли я определить службу типа LoadBalancer и подключить к ней безголовые службы (ClusterIP = None)?Если да, как я могу достичь этого?

Вот моя предполагаемая архитектура:

Load Balancer Service
  - Headless Service (Database-service)
    -  MySql
    - BlazeGraph
  - Headless Service (Web / Tomcat)
    - Web Service (RESTful / GraphQL)

Любой совет и понимание приветствуются.Спасибо!

Answer 1

@ Prafull Ladha, вот мои настройки.У моей службы и связанных с ней наборов состояний есть разные службы базы данных label.app: приложение = база данных mysqlset: приложение = mysql

khteh@khteh-T580:~ 2007 $ k get pods -l app=mysql -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP         NODE         NOMINATED NODE
mysql-0   1/1     Running   1          18h   10.1.1.4   khteh-t580   <none>

khteh@khteh-T580:~ 2008 $ k get pods -l app=blazegraph -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP           NODE         NOMINATED NODE
blazegraph-0   1/1     Running   1          18h   10.1.1.254   khteh-t580   <none>

khteh@khteh-T580:~ 2009 $ k describe service database-service
Name:              database-service
Namespace:         default
Labels:            app=database
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                 {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"database"},"name":"database-service","namespace":"defaul...
Selector:          app=database,tier=database
Type:              ClusterIP
IP:                None
Port:              mysql  3306/TCP
TargetPort:        3306/TCP
Endpoints:         <none>
Port:              blazegraph  9999/TCP
TargetPort:        9999/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

Обратите внимание, что конечные точки службы есть.Я не уверен, что это правильная установка.

Answer 2

Безголовый сервис, который вы должны использовать в любом случае, когда вы хотите автоматически обнаруживать все модули в сервисе, а не в обычном сервисе, где вместо этого вы получаете ClusterIP.В качестве иллюстрации из вышеупомянутого примера здесь приведена разница между записями DNS для Service (с ClusterIP) и Headless Service (без ClusterIP):

• Стандартный сервис, вы получите значение clusterIP:

  kubectl exec zookeeper-0 -- nslookup zookeeper
  Server:        10.0.0.10
  Address:    10.0.0.10#53
  
  Name:    zookeeper.default.svc.cluster.local
  Address: 10.0.0.213
  

• Безголовый сервис вы получите IP каждого пакета

  kubectl exec zookeeper-0 -- nslookup zookeeper
  Server:        10.0.0.10
  Address:    10.0.0.10#53
  
  Name:    zookeeper.default.svc.cluster.local
  Address: 172.17.0.6
  Name:    zookeeper.default.svc.cluster.local
  Address: 172.17.0.7
  Name:    zookeeper.default.svc.cluster.local
  Address: 172.17.0.8
  

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

Безголовый сервис позволяет разработчику уменьшить связь с системой kubernetes, позволяя им выполнять обнаружение по-своему.Для таких сервисов clusterIP не выделяется, kube-proxy не обрабатывает эти сервисы, и для них не выполняется балансировка нагрузки и прокси, выполняемые платформой для них.Таким образом, если вы определите clusterIP: None в своем сервисе, балансировка нагрузки не будет выполняться со стороны kubernetes.

Надеюсь, это поможет.

РЕДАКТИРОВАТЬ:

Iпровел небольшой эксперимент, чтобы ответить на ваши запросы, создал два набора состояний базы данных mysql с именами mysql и mysql2, по 1 реплике для каждого набора состояний.У них есть свои PV, PVC, но они связаны только одним безголовым сервисом.

[root@ip-10-0-1-235 centos]# kubectl get pods -l app=mysql -o wide
NAME       READY     STATUS    RESTARTS   AGE       IP              NODE
mysql-0    1/1       Running   0          4m        192.168.13.21   ip-10-0-1-235.ec2.internal
mysql2-0   1/1       Running   0          3m        192.168.13.22   ip-10-0-1-235.ec2.internal

Теперь вы можете увидеть один безголовый сервис, подключенный к обоим пакетам

[root@ip-10-0-1-235 centos]# kubectl describe svc mysql
Name:              mysql
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=mysql
Type:              ClusterIP
IP:                None
Port:              <unset>  3306/TCP
TargetPort:        3306/TCP
Endpoints:         192.168.13.21:3306,192.168.13.22:3306
Session Affinity:  None
Events:            <none>

Теперь, когда вы ищетеслужба из какого-то другого модуля, она возвращает IP-адрес обоих модулей:

[root@rtp-worker-0 /]# nslookup mysql
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   mysql.default.svc.cluster.local
Address: 192.168.13.21
Name:   mysql.default.svc.cluster.local
Address: 192.168.13.22

Теперь невозможно определить, какой адрес (модуль) имеет какой набор состояний.Теперь я попытался идентифицировать набор состояний с помощью имени метаданных, но не смог

[root@rtp-worker-0 /]# nslookup mysql2.mysql.default.svc.cluster.local
Server:     10.96.0.10
Address:    10.96.0.10#53

** server can't find mysql2.mysql.default.svc.cluster.local: NXDOMAIN

Надеюсь, это прояснится.