Kube-прокси в режиме IPVS не поддерживает соединение

#kubernetes #kube-proxy #ipvs

#kubernetes #kube-прокси #ipvs

Вопрос:

У меня есть кластер k8s с ipvs режимом kube-proxy и кластер баз данных за пределами k8s.

Чтобы получить доступ к кластеру БД, я создал ресурсы служб и конечных точек:

 ---
apiVersion: v1
kind: Service
metadata:
  name: database
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 3306
    targetPort: 3306

---
apiVersion: v1
kind: Endpoints
metadata:
  name: database
subsets:
- addresses:
  - ip: 192.168.255.9
  - ip: 192.168.189.76
  ports:
  - port: 3306
    protocol: TCP
 

Затем я запускаю модуль с клиентом MySQL и пытаюсь подключиться к этой службе:

 mysql -u root -p password -h database
 

В сетевом дампе я вижу успешное подтверждение TCP и успешное подключение к MySQL. На узле, на котором запущен модуль (далее — рабочий узел) Я вижу следующее установленное соединение:

 sudo netstat-nat -n | grep 3306
tcp   10.0.198.178:52642             192.168.189.76:3306            ESTABLISHED
 

Затем я отправляю несколько тестовых запросов из модуля в открытом сеансе MySQL. Все они отправляются на один и тот же узел. Это ожидаемое поведение.

Затем я отслеживаю установленные соединения на рабочем узле. Примерно через 5 минут установленное соединение с узлом базы данных будет пропущено.

Но в сетевом дампе я вижу, что пакеты завершения TCP не отправляются с рабочего узла на узел базы данных. В результате я получаю утечку соединения на узле базы данных.

Как ipvs решает удалить установленное соединение? Если ipvs соединение прерывается, почему оно не завершает TCP-соединение должным образом? Это ошибка или я что-то неправильно понимаю с ipvs режимом в kube-proxy?

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

1. Есть ли какие-либо соответствующие журналы?

Ответ №1:

Kube-proxy и Kubernetes не помогают сбалансировать постоянные соединения.

Вся концепция долговременных соединений в Kubernetes хорошо описана в этой статье:

Kubernetes не балансирует нагрузку на долговременные соединения, и некоторые модули могут получать больше запросов, чем другие. Если вы используете HTTP / 2, gRPC, RSockets, AMQP или любое другое долговременное соединение, такое как соединение с базой данных, вам может потребоваться рассмотреть балансировку нагрузки на стороне клиента.

Я рекомендую пройти через все это, но в целом это можно резюмировать следующим образом:

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