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. Не буду говорить о том хорошо это или плохо. Вообще про балансировку можно отдельно рассказать. 

Docker

  К сожаленю двинуть Docker дальше чем дев окружение у меня не получается, но ребята из Badoo преуспели в этом: http://www.slideshare.net/banuchka/meetup-29102014

Docker

     I've been playing with Docker for quite long time - since version 0.5 or so. Now Docker became spread a lot, so its hard to find person who don't know about Docker.  Docker used by Yandex and Google, Docker became default container engine for RHEL 7.  And still there are some things I was not aware about,  For example about nsenter util.
    I regret that I have not read that article 6 months ago - https://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/ 
    Another article I find useful for myself - http://blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part 

Docker and tools

       В продолжении темы Docker, пока разворачивал прототип деплоя следующего тысячелетия накопал еще несколько инструментов облегчающих работу с Docker. Не факт что они окажутся полезными, но чтобы уж самому не потерять их:
1. Fig - своего рода менеджер Docker контейнеров. Ты ему скармливаешь "карту сервера" а он сам поднимает все описанные там контейнеры и вместе с необходимыми --link и volume. Замысел очень хороший, эта та функциональность которой действительно очень не хватает докеру. Плюс к тому проект очень активно развивается, последний коммит был всего пару дней назад. Но: это на самом деле дублирование функционала менеджеров конфигурации: Puppet, Salt stack, Ansible. Они пытаются сделать то же самое - но заточенное исключительно под Docker. Плюс в настоящее время он работает только на одном хосте... В общем пока решил его не использовать.
2. Ansible Docker в последних версиях Ansible появилась поддержка Docker. Это конечо радует но по факту толку от нее не много. Пока можно только создавать контейнеры/образы, и получать информацию по ним. Для реального использования этого явно не достаточно. Плюс все это сделано очень не очевидно. Я пробовал сначала писать прототип на Ansible, но пришел к выводу что пока я буду с этим синтаксисом разбираться - я потрачу столько же времени как на fabric. В общем простота fabric всех победила.
3.  Confd - демон который слушает поток событий от etcd и перегенерирует конфиги при изменении информации в etcd. Также может заставить тот или иной процесс перечитать конфиги после перегенерации. Вот пример использования вместе с Docker - http://brianketelsen.com/2014/02/25/using-nginx-confd-and-docker-for-zero-downtime-web-updates/ 
4.  Серия из 10 постов одного из маинтейнеров lxc(основы Docker'a): https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/ Особенно понравился 6 и 7 пост - про безопасность lxc контейнеров и запуск контейнеров от не привелигированного пользователя. Если в кратце - в настоящее время lxc контейнеры не безопасны, так как root контейнера эквивалентен root хоста, соответсвенно если пользователь сумеет выйти за пределы контейнера - пиши пропало. Хорошая новость - в следующей убунте контейнеры можно будет запускать от не привелигированного пользователя, в результате если даже пользователь выйдет за пределы контейнера - он перестанет быть root. Надеюсь Docker быстро сделает поддержку для подобных контейнеров.
5. Dron.io -  Continuous Integration платформа, построенная на основе Docker и go. Вот пример использования: http://jipiboily.com/2014/from-zero-to-fully-working-ci-server-in-less-than-10-minutes-with-drone-docker. Еще у них на github лежат Go библиотеки для работы с github и bitbucket.com

Docker

   Последние 2 недели играюсь с Docker. Охеренная штука оказалась... не без изъянов конечно.  Итак если в кратце, плюсы Docker:
1. Docker реально очень быстрый. Виртуальные машины просто на порядок медленнее.
2. Docker простой - если почитать документацию то все в принципе логично и понятно.
3. Docker очень быстро развивается
Из недостатков:
1. Есть некоторые косяки. Lxc сам по себе не верх стабильности, а тут еще и Docker своих багов добавляет. Хотя они честно пишут об этих багах и даже в документации есть ссылки на тикеты с багами.
2. Средства связывания находятся в состоянии зародыша. Контайнеры нельзя линковать друг к другу динамически, шары(volume) нельзя изменять динамически. Получается ситуация - да, ты можешь реально быстро распихать компоненты по контейнерам, запускать их на любой машине - но задача связывания этих компонентов не решена совсем. Ведь для построения работающей системы нужно чтобы эти компоненты знали друг о друге. Вот у тебя есть компонент - база данных, а куда к ней коннектится ? IP адреса-то динамические ?? Если бы они внутри Docker реализовали discovery сервис - цены бы ему не было. Но сейчас мы имеем ровно 2 варианта:
1. Если  оба контейнера находятся внутри одного  физического сервера, то ты можешь связать их при помощи опции link. Но опять же - ее нельзя задать для уже запущенного контейнера. И этот способ не работает когдя нужно связать компоненты, находящиеся на разных физических серверах.
2. Использовать сторонние discovery сервисы:
 - SkyDNS
 - Discoverd
 - Etcd
 - Serf
В общем для рельной работы с Docker нужно использовать один из этих сервисов. Все эти link - выглядят как костыли. Строить свое live окружение на костылях - себе дороже будет.