Kubernetes Headless Service: А если Pod исчез?17.06.2021 17:16

Мы столкнулись с достаточно занятным поведением при работе с Headless-сервисом в Kubernetes. В нашем случае проблема возникла с mongos, но она актуальна для любого Headless-сервиса. Приглашаю вас почитать нашу историю и самим попробовать поиграться с этой проблемой локально.

На одном из проектов мы используем MongoDB и Kubernetes. У MongoDB есть компонент: mongos. Через него выполняются запросы в шардированном MongoDB кластере (можно считать, что это просто хитрый proxy). До переезда в Kubernetes сервисы mongos устанавливались непосредственно на каждый хост.

При переезде сервисов в Kubernetes мы поселили пул mongos в Headless-сервис с автоматическим масштабированием Deployment через HPA (Horizontal Pod Autoscaler).

Через некоторое время выяснилось, что приложению при уменьшении количества Pod с mongos становится не очень хорошо.

0f15c85e7588153b7c834d170942cb15.png

Путем отладки выяснилось, что приложение подвисает именно при попытке установить подключение с mongos (net.Dial в терминах Go) и по времени совпадает с остановкой какого-либо Pod.

Для начала надо уточнить, что такое Headless-сервис: это сервис, который не использует отдельный IP-адрес для маршрутизации запросов (ClusterIP: None). В этом случае под DNS-именем сервиса видны IP всех Pod, которые в этот сервис входят.

Headless-сервисы полезны, когда приложение само должно управлять тем, к какому Pod подключаться, например:

  • mongodb-клиент использует IP сервера, с которым он работает, для того, чтобы запросы для одного курсора шли на один хост (курсор «живёт» на mongos). В случае использования ClusterIP могут «теряться» курсоры даже для коротких запросов.

  • gRPC-клиенты держат по одному соединению с сервисами и сами управляют запросами, мультиплексируя запросы к одному серверу. В случае использования ClusterIP клиент может создать одно подключение и нагружать ровно один Pod сервера.

Так как клиент сам управляет, к каким Pod он подключается, возможна ситуация, когда клиент помнит IP-адрес уже удалённого Pod. Причины этого просты:

  • список Pod передаётся через DNS, а DNS кэшируется;

  • клиент сам по себе кэширует ответы от DNS и список сервисов.

Что же происходит в случае, если клиент пытается подключиться к уже несуществующему Pod?

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

При этом, в случае если Pod еще не поднялся или был отстрелен по Out of Memory, но еще не был удалён, то при попытке подключиться клиент получает ошибку «connection refused» практически сразу. И это гораздо более гуманное решение, чем ждать у моря погоды пока не пробьём таймаут.

Когда стала понятна причина, решить проблему было делом техники.

  • Мы добавили ожидание сигнала SIGTERM в Pod с mongos. При получении этого сигнала мы продолжали работать еще 45 секунд до времени инвалидации DNS (чтобы адреса новых Pod доехали до клиента). После этой паузы завершали mongos и делали еще одну паузу в 15 секунд (чтобы переподключение по старому IP отшивалось по ошибке «connection refused», а не таймауту).

  • Мы выставили terminationGracePeriodSeconds в две минуты, чтобы Pod принудительно не отстрелили до его завершения.

Небольшая ремарка по поводу minReadySeconds

Проблема с остановкой Pod наиболее ярко проявляет себя при перевыкатке сервисов.

Изначально первопричиной казалось то, что выкатка успевает завершиться быстрее, чем обновляются кэши IP-адресов сервиса в клиентском приложении (клиент пытается идти на старые Pod которых нет, а про новые он еще не знает).

Для исправления мы просто замедлили выкатку с помощью параметра minReadySeconds. Это сделало проблему менее острой, но не решило её: остались таймауты при подключении к IP для уже не существующего Pod.

Тем не менее параметр minReadySeconds полезен из-за того, что выкатка не ждёт завершения удаления Pod после перехода его в состояние Terminating. В результате при раскатке сервиса мы можем на время добавленных пауз получить x2 Pod.

К тому же, если на клиенте не возникает нежелательных эффектов от недоступности части IP-адресов сервиса, то задержку для инвалидации DNS можно переместить в minReadySeconds.

Примером, для которого достаточно только minReadySeconds являются gRPC-сервисы: там клиент держит по одному подключению к каждому серверу и раскидывает запросы между уже имеющимся подключениями, а не подключается к сервису при создании клиентской сессии.

Как поиграться с этой проблемой локально?

Эту ситуацию можно легко воспроизвести в MiniKube на примере nginx.

Для этого надо понадобится headless Service (service.yml): 

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  clusterIP: None
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

И тестовая утилита (dialer.go): 

package main

import (
	"fmt"
	"net"
	"os"
	"time"
)

const timeFormat = "15:04:05.999"

func main() {
	address := os.Args[1]
	last := ""
	ticker := time.NewTicker(time.Millisecond * 100)
	t := time.Now()
	fmt.Printf("%s: === %s\n", t.Format(timeFormat), address)
	for {
		conn, err := net.DialTimeout("tcp", address, time.Millisecond*100)
		var msg string
		if conn != nil {
			msg = fmt.Sprintf("connected (%s)", conn.RemoteAddr())
			_ = conn.Close()
		}
		if err != nil {
			msg = err.Error()
		}
		if last != msg {
			now := time.Now()
			if last != "" {
				fmt.Printf("%s: --- %s: %v\n", now.Format(timeFormat), last, now.Sub(t))
			}
			last = msg
			fmt.Printf("%s: +++ %s\n", now.Format(timeFormat), last)
			t = now
		}
		<-ticker.C
	}
}

Запустим тестовую утилиту для подключения к сервису nginx по 80-му порту. Она будет выводить результат попытки подключиться к сервису (пока не успешный, так как сервис смотрит вникуда): 

#!/bin/bash
echo "
tee dialer.go << EEOF
$(cat dialer.go)
EEOF

go run dialer.go nginx:80
" | kubectl --context=minikube run -i --rm "debug-$(date +'%s')" \
            --image=golang:1.16 --restart=Never --

Вывести она должна что-то вида: 

16:57:19.986: === nginx:80
16:57:19.988: +++ dial tcp: lookup nginx on 10.96.0.10:53: server misbehaving

Пока оставим окно с утилитой и потом будем в него посматривать.

Простой Deployment без задержек

Добавим в сервис Deployment (nginx.yml): 

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80

Параметр replicas для эксперимента равен единице, чтобы не скакать между IP-адресами.

На боевом Deployment должны быть так же livenessProbe и readinessProbe. Но в данном эксперименте они будут только мешать.

И сделаем «обновление» Deployment: 

#!/bin/bash
kubectl --context minikube rollout restart deployment/nginx

От этой команды произойдёт перевыкатка Deployment. При этом важно отметить, что схема выкатки по умолчанию: поднять новый Pod и только затем погасить старый Pod. То есть всегда будет запущен как минимум один Pod.

В выводе тестовой утилиты мы увидим примерно следующее (комментарии добавлены отдельно): 

# Здесь мы подключились к созданному Deployment и до обновления попытки
# подключения были успешны
17:04:08.288: +++ connected (172.17.0.10:80)
17:07:32.187: --- connected (172.17.0.10:80): 3m23.899438044s
# Здесь завершился nginx при остановке Pod, но клиент еще идет по старому
# кэшированному IP.
# Так как Pod существует, мы быстро получаем ошибку "connection refused"
17:07:32.187: +++ dial tcp 172.17.0.10:80: connect: connection refused
17:07:32.488: --- dial tcp 172.17.0.10:80: connect: connection refused: 301.155902ms
# Старый Pod уже удалён, но клиент всё еще идет по старому кэшированному IP.
# Так как по IP-адресу уже никто не отвечает, мы пробиваем таймаут.
17:07:32.488: +++ dial tcp 172.17.0.10:80: i/o timeout
17:07:38.448: --- dial tcp 172.17.0.10:80: i/o timeout: 5.960150161s
# Старый IP покинул кэш и мы подключились к новому Pod.
17:07:38.448: +++ connected (172.17.0.7:80)

Добавляем задержку перед удалением Pod

Добавим в Deployment паузу после завершения сервиса, чтобы вместо долгого таймаута получать быстрый «connection refused»: 

#!/bin/bash
kubectl --context minikube patch deployment nginx --output yaml --patch '
---
spec:
  template:
    spec:
      containers:
        - name: nginx
          command: [ "sh" ]
          # Добавляем паузу после завершения nginx
          args:
            - "-c"
            - "nginx -g \"daemon off;\" && sleep 60"
          # К сожалению, sh не пробрасывает SIGTERM в дочерний процесс
          lifecycle:
            preStop:
              exec:
                command: ["sh", "-c", "nginx -s stop"]
      # Увеличиваем время, которое отводится на остановку Pod-а перед
      # его безусловным завершением
      terminationGracePeriodSeconds: 180
'

Эта пауза нужна только при корректном завершении Pod (в этом случае процесс получает SIGTERM). Если процесс завершается, к примеру, по Out Of Memory или Segmentation fault, то её быть не должно.

И еще раз сделаем «обновление» Deployment: 

#!/bin/bash
kubectl --context minikube rollout restart deployment/nginx

В выводе тестовой утилиты мы увидим примерно следующее (комментарии добавлены отдельно): 

# Здесь мы подключились к созданному Deployment и до обновления попытки
# подключения были успешны
17:58:10.389: +++ connected (172.17.0.7:80)
18:00:53.687: --- connected (172.17.0.7:80): 2m43.29763747s
# Здесь завершился nginx при остановке Pod, но клиент еще идет по старому
# кэшированному IP.
# Так как Pod существует, мы быстро получаем ошибку "connection refused".
# Существовать Pod будет до тех пор пока не завершится sleep после nginx.
18:00:53.687: +++ dial tcp 172.17.0.7:80: connect: connection refused
18:01:10.491: --- dial tcp 172.17.0.7:80: connect: connection refused: 16.804114254s
# Старый IP покинул кэш и мы подключились к новому Pod.
18:01:10.491: +++ connected (172.17.0.10:80)

Добавляем задержку перед остановкой Pod

Добавим в Deployment паузу перед завершением сервиса, чтобы сервис отвечал, пока адрес Pod не покинет кэш на клиенте: 

#!/bin/bash
kubectl --context minikube patch deployment nginx --output yaml --patch '
---
spec:
  template:
    spec:
      containers:
        - name: nginx
          # Добавляем задержку перед остановкой nginx
          lifecycle:
            preStop:
              exec:
                command: ["sh", "-c", "sleep 60 && nginx -s stop"]
      # Увеличиваем время, которое отводится на остановку Pod перед
      # его безусловным завершением
      terminationGracePeriodSeconds: 180
'

И еще раз сделаем «обновление» Deployment: 

#!/bin/bash
kubectl --context minikube rollout restart deployment/nginx

В выводе тестовой утилиты мы увидим примерно следующее (комментарии добавлены отдельно): 

# Здесь мы подключились к созданному Deployment и до обновления попытки
# подключения были успешны
18:05:10.589: +++ connected (172.17.0.7:80)
18:07:10.689: --- connected (172.17.0.7:80): 2m0.099149168s
# Старый IP покинул кэш и мы подключились к новому Pod.
# Старый Pod еще отвечает и из-за этого переключение прошло гладко.
18:07:10.689: +++ connected (172.17.0.10:80)

Какие нужны задержки?

Итого: для гладкого переключения необходимо две задержки.

  • Между SIGTERM и остановкой приложения — чтобы на момент отключения клиента он не мог получить из DNS-кэша ровно тот же Pod и пойти на него.

    Эта задержка должна быть не меньше, чем время жизни записи в DNS-кэше.

    Делать эту паузу больше, чем сумма времени жизни записи в DNS-кэше и времени жизни записи в кэше приложения не имеет особого смысла.

    Если на клиенте не возникает нежелательных эффектов от недоступности части IP-адресов сервиса, то вместо паузы после SIGTERM можно использовать minReadySeconds.

  • Между остановкой приложения и завершением Pod, чтобы при попытке клиента подключиться/переподключиться к этому Pod мы получали быстрый «connection refused», а не ждали всё время таймаута.

    Эта задержка должна быть подобрана так, чтобы с момента получения SIGTERM и до завершения Pod прошло время не меньше суммы времени жизни записи в DNS кэше и времени жизни записи в кэше приложения.

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

Конкретные длительности задержек надо подбирать индивидуально.

© Habrahabr.ru