Я долгое время вынашивал идею доклада который бы обобщил накопленный мною и моими коллегами опыт. К сожалению с докладом не срослось в силу разных причин, поэтому напишу хотя бы небольшую заметку.
Сейчас про Docker и Kubernetes не пишет разве что ленивый, но в большинстве своем это либо рекламные проспекты, либо статьи из разряда - как запустить сделать свой нахер никому не нужный блог безмерно масштабируемым. В этой статье не будет никаких сверхъестественных технологий и запатентованных магических технологий. Просто рецепт как МОЖНО эксплуатировать связку докер + кубернейтс в production среде. В действительно высоко нагруженной production среде, обрабатывающей десятки тысяч запросов в секунду, состоящей из нескольких сотен серверов. Обратите внимание на слово - МОЖНО. То есть я не претендую на истину в последней инстанции. Наверняка что-то можно было сделать и лучше. Но мы сделали так как написано и у нас это не плохо работало.
1. При эксплуатации докера очень много зависит от совместимости версии самого докера + версии ядра + версии кубера. Поэтому кратенько приведу то что мы использовали: Docker 1.13.1, Linux version 3.10.0-327.el7.x86_64, CentOS Linux release 7.2.1511, Kubernetes v1.5.5. Время идет и даже на момент публикации поста эта информация уже порядком устарела, но я все же оставлю ее здесь. Скорее всего вы будете использовать другие версии, но нужно подходить к этому очень осторожно. Docker печально известен своей нестабильностью, поэтому прежде чем деплоить новую комбинацию версий в продакшен - ей нужно дать "отстоятся" на паре-тройке серверов в течении 2-3х недель.
2. Сеть. Мы использовали стандартную сеть на основе linux bridge + BGP для маршрутизации трафика между серверами. То есть на каждый сервер выделялась /24 подсеть(к примеру 10.216.0.1/24), первый адрес подсети выделялся самому серверу(10.216.0.1) а остальные выделялись kubernetes подам запущенных на этой машине. Для всех подов 10.216.0.1 прописывался как default gateway.
Также на каждом хосте стояла quagga которая анонсировала 10.216.0.1/24 сеть по BGP протоколу.
3. Сторадж: STORAGE_DRIVER=overlay, файловая система xfs. Когда мы начинали свой поход в продакшен мы перепробовали много вариантов, но сейчас это уже стало стандартом de-facto.
4. Мониторинг - Prometheus + Grafana + telegraf для сбора метрик с хостов. Прометей стоял отдельно, без всяких новомодных Prometheus Operator.
5. Логгирование тоже было сделано крайне просто - на каждом хосте стоял rsyslog, который слушал unix domain сокет. Директория с этим сокетом пробрасывалась в каждый контейнер. Обращаю внимание что пробрасывался не сам сокет а только директория в которой он находился. Так сделано потому что контейнеры должны иметь возможность переоткрыть его если к примеру rsyslog перезапускали. Весь софт только и знал что писал в этот сокет. rsyslog вычитывал это, аггрегировал, при необходимости буфферизировал на диск и отправлял по сети на центральный лог сервер.
6. Load balancing + DNS - мы не использовали возможности предоставляемые кубером для балансировки нагрузки. У нас все было через ServiceDiscovery, поэтому компоненты сами друг сдругом общались. Peer to peer. Не буду говорить о том хорошо это или плохо. Вообще про балансировку можно отдельно рассказать.
Комментариев нет:
Отправить комментарий