[Перевод] PuppetConf 2016. Kubernetes для сисадминов. Часть 3

PuppetConf 2016. Kubernetes для сисадминов. Часть 1
PuppetConf 2016. Kubernetes для сисадминов. Часть 2

Мы берем приложение Lobsters и создаем новый образ с новыми требованиями. Сначала вводим команду развертывания $ kubectl apply –f deployments/lobsters.yaml и посылаем приложение в кластер, который должен выполнить обновление rolling update для каждого из имеющихся экземпляров приложения в соответствии с политикой обновлений. Сначала система убеждается в работоспособности каждого экземпляра, а затем уничтожает их в следующем наборе контейнеров.

xgblxesodan5f7msgrj_d3qc0x4.jpeg

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

0ytur3i7hpga4pd8blgqpltetpk.jpeg

Как сисадмин, вы можете сказать: «Здесь же нет HTTPS, такие сайты легко взломать, это же опасно!». Как же можно решить эту проблему? Я думаю, в ее решении Kubernetes может выступать как фреймворк, который позволяет системному администратору реализовать творческий подход к работе. Было бы хорошо, если я мог бы декларативно сказать: «Я хочу получить для этого сайта сертификат Let’s Encrypt, но при этом не хочу повторно развертывать данный контейнер». Я хочу сделать это в рамках своих возможностей, не обращаясь за помощью к команде разработчиков приложения. Kubernetes позволяет подобное, так как поддерживает пользовательские расширения.

Я говорил про kubectl, поды, развертывания, services, но у нас есть еще и custom types — пользовательские типы ресурсов, которые можно получить в Puppet. В Puppet мы можем дать определение новым типам, так что мы можем использовать эту систему для нашей работы.
Посмотрим, как это выглядит в Kubernetes. В первую очередь нам нужно расширение для сертификатов, вот как оно выглядит. Здесь у нас имеется свое собственное пространство имен hightower.com, в котором расположен сертифицируемый объект.

rrma5rckamyozcp6nnmpbtgyl7c.jpeg

Мы создаем в Kubernetes новое расширение с помощью команды $ kubectl create –f extensions/certificate.yaml, при этом в бэкенде автоматически создается хранилище и осуществляется управление данным состоянием.

f6ead2a5oznwql3lmm4x1vfdroq.jpeg

Появление этого нового объекта требует от меня нового инструмента, отслеживающего изменения и совершающего действия в отношении объекта certificate. То есть этот инструмент в фоновом режиме должен взаимодействовать с Let’s Encrypt и получить действующий сертификат. Для этого я использую secret — покажу очень быстро, как это делается.

Итак, нам нужен новый под, и я покажу, в чем разница по сравнению с предыдущим кодом. Я добавляю в существующий под контейнер nginx, так что нам не нужно обращаться к команде разработчиков. Мы продолжаем использовать HTTPS, просто разместив контейнер в самом верху существующего пода.

g70386ln3tvhoqjmebrbvryzpzq.jpeg

Этот контейнер принимает HTTPS-трафик, и ему нужен файл конфигурации для взаимодействия с бэкендом. Мне также нужны некоторые сертификаты, которые nginx загружает из файловой системы, поэтому переменные окружения здесь не работают. Я не писал nginx, так что не могу заставить его это делать.

_acl2isasvxctjkvufkrugqnk8k.jpeg

Поэтому я просто добавляю этот контейнер прямо внутрь пода и обращаюсь к двум secrets.

yciveqwa-pq7_cck1gf60hfjqn8.jpeg

Первый и самый главный secret — это TLS-сертификат, который должен поступить с Let’s Encrypt. Я не собираюсь сообщать о Let’s Encrypt своему приложению, я сообщаю о нем своей системе. Я хочу распоряжаться этой абстракцией. Поэтому сейчас я должен создать config-файл для nginx. Это основной файл конфигурации, который выглядит таким образом.

Здесь указан порт 443 и включен SSL, который ищет в файловой системе эти 2 файла, захватывает трафик и отправляет его локальному хосту 127.0.0.1:3000.

-2kd5yagcajoerql82qqk13j7x8.jpeg

Это именно то, что «слушает» мое приложение. Сейчас я создам configmap — карту конфигурации nginx, используя следующую команду.

9co7cwksmacc2wupjily8lafopw.jpeg

Теперь с помощью команды $ kubectl get configmaps я размещаю configmap «nginx» в системе с таким же именем, что и у диска.

xdragjavd0y5qozvclnjhgarhoo.jpeg

Далее необходимо создать secret, напомню вам еще раз — я хочу, чтобы все было автоматизированным, и не хочу вмешиваться в процесс получения сертификатов. Для этого я развертываю инструмент под названием «kube-cert-manager», и вот что получается в результате.

2qalnfsodexfhlnz6wrmdczbhuk.jpeg

Мы пытаемся получить действительный сертификат Let«s Encrypt, которому будет доверять мой браузер, и вставляем его в бэкенд как secret. Поэтому для моего пода не будет никакой разницы в том, что мы дополнили его содержимое. Если помните, все это сделано благодаря созданию custom type в Puppet.

Возможно, это плохая идея, но сейчас я постараюсь запустить контроллер, который будет работать в бэкграунде. Мы не делаем никакой компиляции, не создаем провайдеров, этот деймон просто работает в фоне и наблюдает за изменениями. Как только появляется объект сертификата, он получает его с Let«s Encrypt и вставляет в систему в режиме реального времени без всяких задержек. Итак, я использую следующую команду.

a499zou6q5d0mmb-dudvreekhyg.jpeg

У этой штуки тоже есть хранилище, так что мы можем сохранить все что нужно. Требуется несколько секунд, чтобы менеджер сертификации kube-cert-manager начал работать.

p46igctf-yljcjod5tgweyo9pnq.jpeg

Следующее, что нам нужно сделать, — это создать объект сертификата. Это то, что я определяю сам, это моя собственная схема. Я создаю новую вещь, которую Kubernetes не встречал до этого момента, в которой говорится, что я могу получить сертификат для домена lobsters.com.

hqylkdbzfn7vdps0b5drmv8jbpm.jpeg

Здесь имеется адрес электронной почты и другая информация, которая необходима для того, чтобы Let«s Encrypt выдал мне действительный сертификат. Let«s Encrypt пришлет мне обменный токен, чтобы увидеть, действительно ли я являюсь владельцем этого домена, и мне нужно будет применить этот токен к моему DNS в Google Cloud. Если проверка пройдет, то они выдадут мне настоящий сертификат, который я вставлю в свою файловую систему. Посмотрим, как это работает, введя команду $ kubectl get pods.

pb6uzapiyin51rbygpmlorvu3pw.jpeg

Как видите, менеджер сертификатов все еще работает. Посмотрим подробную информацию об этом процессе с помощью команды $ kubectl describe pods kube-cert-manager, вставив название контейнера из первой строки кода.

wglyxeqwjbcurcrse2hshtjw_ji.jpeg

Вы видите, что выполняется работа по расписанию. В данный момент на сервере создается том, который после проверки и форматирования будет смонтирован на этом сервере. Пока идет этот процесс, можно пойти дальше и закончить нашу работу.

Я ввожу команду kubectl create –f certificates/lobsters.yaml и получаю следующий результат.

z5hpgphmdzfu4rtwj1dq0bntpwg.jpeg

Далее я использую команду, которая позволяет просмотреть логи нескольких контейнеров. Я выделю тот, что касается моего объекта.

szwxef5zwbj9zy-r4simoyc8nji.jpeg

Сейчас происходит создание записи DNS внутри моего облачного DNS-сервера. Если я обновлю изображенную здесь страницу, то увижу новый обменный токен с расширением .txt.

n_z4rfe1bpsde1qtie1km2dwxhs.jpeg

Итак, я получил токен от Let«s Encrypt и теперь проверяю, что эта запись DNS распространилась по всем авторизированным серверам, прежде чем я скажу Let«s Encrypt, чтобы они проверили эту текстовую запись в моем домене.

mbmaprqr4ddkxyuytws68cgj-u8.jpeg

Если это сработает, они пришлют мне обратно действующий сертификат. Демонстрация работы DNS в режиме реального времени — плохая идея. Ага, мы наконец получаем сертификат. Let«s Encrypt заметил, что сертификат исчез из Kubernetes, и вставил его туда. Это отлично, потому сейчас у меня уже имеется интерфейс запроса сертификатов для всего, что выполняется в среде Kubernetes.

Чтобы убедится, что все работает правильно, я ввожу команду $ kubectl get secrets, и мы видим один secret для сайта lobsters.hightowerlabs.com.

b7ffj1jembzr8j1htlpxkrxkcoa.jpeg

Теперь я использую команду $ kubectl delete secrets lobsters.hightowerlabs.com, потому что это декларативная система, мы не удаляем объект сертификата, а избавляемся от связанного с ним secret, расположенного внутри Kubernetes. В результате мы должны убедиться в том, что при удалении этого элемента система вернет на место сам сертификат Let«s Encrypt. Это очень похоже на то, что мы делаем в Puppet, только здесь это происходит в режиме онлайн.

Убедившись, что все работает, мы осуществляем новое развертывание нашего приложения nginx под названием «lobsters-secure», которое обеспечит безопасность нового домена. Его образ похож на предыдущий вариант, но разница состоит в том, что мы поместили сюда nginx. Nginx забирает по ссылке secrets, затем Kubernetes вставляет его в файловую систему, в результате чего я получаю действующий сертификат для конкретного домена.

Для этого я ввожу команду $ kubectl apply –f deployments/lobsters-secure.yaml, используя то же самое имя, так что эта команда перепишет существующее состояние. Далее используется команда $ kubectl get pods, которая показывает, что сейчас здесь происходит скользящее обновление rolling update, поскольку у нас поменялись определения definition.

После завершения обновления видно, что для данного приложения используются новые definition. Я хочу убедиться в действительности сертификата для нашего DNS-имени, для чего ввожу команду $ kubectl get svc и копирую IP-адрес сайта lobsters.

bftvi4mtuaqz29b5eelp25eqets.jpeg

Перейдя на вкладку Google Cloud, видно, что этот адрес совпадает с адресом, соответствующим доменному имени lobsters.hightowerlabs.com. Теперь, если набрать в адресной строке браузера lobsters.hightowerlabs.com, можно увидеть, что у нас имеется действующий сертификат.

zxsez5z5vhqg3e3cxkuqzs7jc84.jpeg

Благодарю вас, это все, что я хотел рассказать в докладе «Kubernetes для системных администраторов».


Немного рекламы :)


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5–2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5–2697v3 2.6GHz 14C 64GB DDR4 4×960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5–2430 2.2Ghz 6C 128GB DDR3 2×960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5–2650 v4 стоимостью 9000 евро за копейки?

© Habrahabr.ru