понедельник, 14 мая 2018 г.

Kubernetes(K8s) + Docker

      Я долгое время вынашивал идею доклада который бы обобщил накопленный мною и моими коллегами опыт. К сожалению с докладом не срослось в силу разных причин, поэтому напишу хотя бы небольшую заметку. 
       Сейчас про 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. Не буду говорить о том хорошо это или плохо. Вообще про балансировку можно отдельно рассказать.