#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-соединений.
- Вместо этого вы должны закодировать свое приложение так, чтобы оно могло извлекать и балансировать потоки на стороне клиента.