Конечный пункт услуг Kubernetes - PullRequest
Новая
       14

Конечный пункт услуг Kubernetes

0 голосов
/ 29 января 2020

Я создал сервис Kubernetes, чьи внутренние узлы не являются частью Кластера, а представляют собой фиксированный набор узлов (имеющих фиксированные IP-адреса), поэтому я также создал ресурс Endpoints с тем же именем: 

apiVersion: v1
kind: Service
metadata:
  name: elk-svc
spec:
  ports:
    - port: 9200
      targetPort: 9200
      protocol: TCP
---
kind: Endpoints
apiVersion: v1
metadata:
  name: elk-svc
subsets:
  -
    addresses:
      - { ip: 172.21.0.40 }
      - { ip: 172.21.0.41 }
      - { ip: 172.21.0.42 }

    ports:
      - port: 9200

Описание службы и конечных точек: 

$ kubectl describe svc elk-svc
Name:           elk-svc
Namespace:      default
Labels:         <none>
Annotations:        kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"elk-svc","namespace":"default"},"spec":{"ports":[{"port":9200,"protocol":"TCP"...
Selector:       <none>
Type:           ClusterIP
IP:         10.233.17.18
Port:           <unset> 9200/TCP
Endpoints:      172.21.0.40:9200,172.21.0.41:9200,172.21.0.42:9200
Session Affinity:   None
Events:         <none>

$ kubectl describe ep elk-svc
Name:       elk-svc
Namespace:  default
Labels:     <none>
Annotations:    kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Endpoints","metadata":{"annotations":{},"name":"elk-svc","namespace":"default"},"subsets":[{"addresses":[{"ip":"172.21.0.40"...
Subsets:
  Addresses:        172.21.0.40,172.21.0.41,172.21.0.42
  NotReadyAddresses:    <none>
  Ports:
    Name    Port    Protocol
    ----    ----    --------
    <unset> 9200    TCP

Events: <none>

Мои модули могут обмениваться данными с ElasticSearch, используя внутренний IP-адрес кластера 10.233.17.18. Все идет хорошо!

У меня вопрос о том, есть ли какой-нибудь механизм механизма HealthCheck для той службы, которую я создал, поэтому, если один из моих узлов ElasticSearch выходит из строя, ie: 172.21.0.40, тогда Служба знает об этом и больше не будет направлять трафик c на этот узел, а на другие. Это возможно?

Спасибо.

Ответы [ 2 ]

1 голос
/ 29 января 2020

Это не поддерживается в k8s.
Для получения дополнительной информации обратитесь к этой проблеме, поднятой по вашему требованию: * https://github.com/kubernetes/kubernetes/issues/77738#issuecomment -491560980
Для этого варианта использования рекомендуется использовать loadbalancer, как haproxy

0 голосов
/ 30 января 2020

Мое предложение будет иметь обратный прокси, такой как nginx или haproxy перед узлами elasti c, который будет проверять работоспособность этих узлов.

...