Жизненный цикл типа конечных точек Kubernetes

#kubernetes

#kubernetes

Вопрос:

Вопрос

Я хотел узнать о жизненном цикле объекта типа endpoints и хотел бы знать, нормально ли, что конечные точки автоматически исчезают после уменьшения размера модуля до 0 экземпляров?

Структура сценария

Кластер Kubernetes версии v1.19 [1 главный 3 рабочих узла]

Конечная точка Glusterfs (привязана к пространству имен) [включает IP-адреса конфигурации устройств glusterfs]

Сервис [обычный сервис для модуля и хранилища]

Развертывание [включает соответствующую информацию о развертывании, например, переменные env]

Структура конвейера межсоединений

Конечная точка -> Служба -> Развертывание

Конечные точки yaml

 apiVersion: v1
kind: Endpoints
metadata:
name: gluster-test
namespace: "test"
subsets:
- addresses:
    - ip: "ip 1"
  ports:
    - port: 1
      protocol: TCP
- addresses:
    - ip: "ip 2"
  ports:
    - port: 1
      protocol: TCP
- addresses:
    - ip: "ip 3"
  ports:
    - port: 1
      protocol: TCP
- addresses:
    - ip: "ip 4"
  ports:
    - port: 1
      protocol: TCP
  

Служба Glusterfs yaml

 apiVersion: v1
kind: Service
metadata:
name: "gluster-test-sv"
namespace: "test"
spec:
ports:
  - port: 1
  

Объем сохранения yaml

 apiVersion: v1
kind: PersistentVolume
metadata:
name: "gluster-test2-pv"
namespace: test
spec:
capacity:
  storage: "5Gi"
accessModes:
  - ReadWriteMany
glusterfs:
  endpoints: gluster-test
  path: "/test2"
  readOnly: false
persistentVolumeReclaimPolicy: Retain
  

Требование сохранения объема

 apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: "gluster-test2-claim"
namespace: test
spec:
accessModes:
  - ReadWriteMany
resources:
  requests:
    storage: "5Gi"
  

Развертывание yaml

 kind: Deployment
apiVersion: apps/v1
metadata:
name: "test-de"
labels:
  app.kubernetes.io/name: "test"
namespace: kubernetes-dashboard
spec:
replicas: 1
selector:
  matchLabels:
    app.kubernetes.io/name: "test"
template:
  metadata:
    labels:
      app.kubernetes.io/name: "test"
  spec:
    containers:
      - name: "test"
        image: "test:latest"
        ports:
          - name: http
            containerPort: XXXX
            protocol: TCP
        volumeMounts:
          - mountPath: /XXX
            name: storage
            readOnly: false
    imagePullSecrets:
      - name: "test"
    volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: "gluster-test-claim"
    securityContext:
      fsGroup: XXX
  

Комментарии:

1. Можете ли вы обновить этот вопрос с помощью ваших файлов yaml?

2. @thomas Я обновляю основной пост и добавляю файлы yaml.

Ответ №1:

Endpoint это объектно-ориентированное представление конечной точки REST API, которое заполняется на сервере API K8s. Это означает, что в мире K8s это список адресов (IP и портов) конечных точек, которые реализуют Службу.

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

 apiVersion: v1
kind: Endpoints
metadata:
  name: glusterfs-cluster <--remember to match this with service name
subsets:
  - addresses:
      - ip: 10.10.10.10 
    ports:
      - port: 
  - addresses:
      - ip: 12.12.12.12 
    ports:
      - port: 
  

Примечание: в ваших примерах имя конечных точек не совпадает с именем службы.

Что именно происходит за кулисами, так это то, что kube-proxy следит за плоскостью управления Kubernetes на предмет добавления и удаления объектов служб и конечных точек. Затем для каждой службы он устанавливает правила iptables, которые собирают трафик для службы clusterIP port и перенаправляют этот трафик на один из поддерживаемых наборов Службы. Для каждого объекта конечной точки он устанавливает правила iptables, которые выбирают резервный модуль.

Комментарии:

1. Спасибо за этот подробный ответ, я думаю, что, изменив имя, проблема должна быть решена.