Полгода назад мы закончили миграцию всех наших stateless сервисов в kubernetes. На первый взгляд задача достаточно простая: нужно развернуть кластер, написать спецификации приложений и вперед. Из-за одержимости в вопросе обеспечения стабильности в работе нашего сервиса пришлось сразу начать разбираться с тем, как работает k8s и тестировать различные сценарии отказов. Больше всего вопросов у меня возникало ко всему, что касается сети. Один из таких "скользких" моментов — работа сервисов (Services) в kubernetes.
В документации нам говорят:
- выкатите приложение
- задайте liveness/readiness пробы
- создайте сервис
- дальше все будет работать: балансировка нагрузки, обработка отказов итд.
Но на практике все несколько сложнее. Давайте посмотрим, как оно работает на самом деле.
Немного теории
Далее я подразумеваю, что читатель уже знаком с устройством kubernetes и его терминологией, вспомним лишь, что такое сервис.
Сервис — сущность k8s, которая описывает совокупность подов и методов доступа к ним.
Например, мы запустили наше приложение:
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
selector:
matchLabels:
app: webapp
replicas: 2
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: defaultxz/webapp
command: ["/webapp", "0.0.0.0:80"]
ports:
- containerPort: 80
readinessProbe:
httpGet: {path: /, port: 80}
initialDelaySeconds: 1
periodSeconds: 1
$ kubectl get pods -l app=webapp
NAME READY STATUS RESTARTS AGE
webapp-5d5d96f786-b2jxb 1/1 Running 0 3h
webapp-5d5d96f786-rt6j7 1/1 Running 0 3hТеперь чтобы обратиться к нему, мы должны создать сервис, в котором определяем к каким именно подам мы хотим иметь доступ (selector) и по каким портам:
kind: Service
apiVersion: v1
metadata:
name: webapp
spec:
selector:
app: webapp
ports:
- protocol: TCP
port: 80
targetPort: 80$ kubectl get svc webapp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
webapp ClusterIP 10.97.149.77 <none> 80/TCP 1dТеперь мы с любой машины кластера можем обратиться к нашему сервису:
curl -i http://10.97.149.77
HTTP/1.1 200 OK
Date: Mon, 24 Sep 2018 11:55:14 GMT
Content-Length: 2
Content-Type: text/plain; charset=utf-8Как это все работает
Очень упрощенно:
- вы сделали kubectl apply спецификации Deployment
- происходит магия, детали которой не важны в данном контексте
- в результате на каких-то нодах оказались работающие поды приложения
- раз в интервал kubelet (агент k8s на каждой ноде) выполняет liveness/readiness пробы всех запущенных на его ноде подов, результаты он отправляет в apiserver (интерфейс к мозгам k8s)
- kube-proxy на каждой ноде получает уведомления от apiserver о всех изменениях сервисов и подов, которые участвуют в сервисах
- kube-proxy все изменения отражает в конфигурации нижележащих подсистем (iptables, ipvs)
Для простоты рассмотрим дефолтный способ проксирования — iptables. В iptables у нас для нашего виртуального ip 10.97.149.77:
-A KUBE-SERVICES -d 10.97.149.77/32 -p tcp -m comment --comment "default/webapp: cluster IP" -m tcp --dport 80 -j KUBE-SVC-BL7FHTIPVYJBLWZNтрафик уходит в цепочку KUBE-SVC-BL7FHTIPVYJBLWZN, в которой распределяется между 2 другими цепочками
-A KUBE-SVC-BL7FHTIPVYJBLWZN -m comment --comment "default/webapp:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-UPKHDYQWGW4MVMBS
-A KUBE-SVC-BL7FHTIPVYJBLWZN -m comment --comment "default/webapp:" -j KUBE-SEP-FFCBJRUPEN3YPZQTэто уже наши поды:
-A KUBE-SEP-UPKHDYQWGW4MVMBS -p tcp -m comment --comment "default/webapp:" -m tcp -j DNAT --to-destination 10.244.0.10:80
-A KUBE-SEP-FFCBJRUPEN3YPZQT -p tcp -m comment --comment "default/webapp:" -m tcp -j DNAT --to-destination 10.244.0.11:80Тестируем отказ одного из подов
Мое тестовое приложение webapp умеет переключаться в режим "сыпь ошибками", для этого нужно сделать дернуть урл "/err".
Результаты ab -c 50 -n 20000 в середине теста дернули "/err" на одном из подов:
Complete requests: 20000
Failed requests: 3719Дело тут не в конкретном количестве ошибок (их количество будет меняться в зависимости от нагрузки), а в том, что они есть. В целом мы выкинули "плохой" под из балансировки, но в момент переключения клиент сервиса получал ошибки. Причину ошибок достаточно легко объяснить: readiness пробы выполняются kubelet раз в секунду + еще небольшое время на распространение информации о том, что под не ответил на пробу.
Поможет ли IPVS бэкенд для kube-proxy (experimental)?
На самом деле нет! Он решает задачу оптимизации проксирования, предлагает настраиваемый алгоритм балансировки, но никак не решит проблему обработки отказов.
Как быть
Данную проблему может решить только балансировщик, который умеет повторные попытки (retries). Другими словами, для http нам нужен L7 балансировщик. Такие балансировщики для kubernetes уже во всю используются либо в виде ingress (подразумевался как точка в хода в кластер, но по большому счету делает ровно то, что нужно), либо как реализацию отдельного слоя — service mesh, например istio.
У себя в production мы не стали пока использовать ни ingress, ни service mesh из-за дополнительной сложности. Подобные абстракции, на мой взгляд, помогают в тех случаях, когда нужно часто конфигурировать большое количество сервисов. Но при этом вы "платите" управляемостью и простой инфраструктуры. Вы будете тратить дополнительное время, чтобы понять, как настроить рертаи, таймауты для конкретного сервиса.
Как делаем мы
Мы используем headless сервисы k8s. У таких сервисов нет виртуального ip и соответственно в их работе kube-proxy и iptables не участвует. Для каждого такого сервиса можно получить список живых подов либо через DNS, либо через API.
Для приложений, которые взаимодействуют с другими сервисами мы делаем sidecar контейнер с envoy. Evoy периодически получает актуальных список подов для всех нужных сервисов через DNS, и самое главное умеет делать повторные попытки запросов на другие поды в случае ошибки. Можно запустить его в виде DaemonSet на каждой ноде, но тогда при отказе этого инстанса, перестали бы работать все приложения, которые его используют. Так как потребление ресурсов этим прокси достаточно небольшое, мы решили использовать его именно в варианте sidecar контейнера.
Это по сути ровно то, что делает istio, но в нашем случае баланс сместился в сторону простоты (не нужно изучать istio, нарываться на его баги). Возможно этот баланс изменится, и мы начнем использовать что-нибудь типа istio.
У нас в okmeter.io kubernetes определенно прижился, и мы верим в его дальнейшее распространение. Поддержка мониторинга k8s в нашем сервисе на подходе, следите за новостями!
Автор: NikolaySivko
