PuppetConf 2016. Kubernetes для сисадминов. Часть 1
PuppetConf 2016. Kubernetes для сисадминов. Часть 2
Мы берем приложение Lobsters и создаем новый образ с новыми требованиями. Сначала вводим команду развертывания $ kubectl apply –f deployments/lobsters.yaml и посылаем приложение в кластер, который должен выполнить обновление rolling update для каждого из имеющихся экземпляров приложения в соответствии с политикой обновлений. Сначала система убеждается в работоспособности каждого экземпляра, а затем уничтожает их в следующем наборе контейнеров.
Посмотрим, как это сработало. Для этого перезагружаем сайт, и теперь отсутствие белых мест сделает нашего маркетолога счастливым.
Как сисадмин, вы можете сказать: «Здесь же нет HTTPS, такие сайты легко взломать, это же опасно!». Как же можно решить эту проблему? Я думаю, в ее решении Kubernetes может выступать как фреймворк, который позволяет системному администратору реализовать творческий подход к работе. Было бы хорошо, если я мог бы декларативно сказать: «Я хочу получить для этого сайта сертификат Let's Encrypt, но при этом не хочу повторно развертывать данный контейнер». Я хочу сделать это в рамках своих возможностей, не обращаясь за помощью к команде разработчиков приложения. Kubernetes позволяет подобное, так как поддерживает пользовательские расширения.
Я говорил про kubectl, поды, развертывания, services, но у нас есть еще и custom types — пользовательские типы ресурсов, которые можно получить в Puppet. В Puppet мы можем дать определение новым типам, так что мы можем использовать эту систему для нашей работы.
Посмотрим, как это выглядит в Kubernetes. В первую очередь нам нужно расширение для сертификатов, вот как оно выглядит. Здесь у нас имеется свое собственное пространство имен hightower.com, в котором расположен сертифицируемый объект.
Мы создаем в Kubernetes новое расширение с помощью команды $ kubectl create –f extensions/certificate.yaml, при этом в бэкенде автоматически создается хранилище и осуществляется управление данным состоянием.
Появление этого нового объекта требует от меня нового инструмента, отслеживающего изменения и совершающего действия в отношении объекта certificate. То есть этот инструмент в фоновом режиме должен взаимодействовать с Let's Encrypt и получить действующий сертификат. Для этого я использую secret – покажу очень быстро, как это делается.
Итак, нам нужен новый под, и я покажу, в чем разница по сравнению с предыдущим кодом. Я добавляю в существующий под контейнер nginx, так что нам не нужно обращаться к команде разработчиков. Мы продолжаем использовать HTTPS, просто разместив контейнер в самом верху существующего пода.
Этот контейнер принимает HTTPS-трафик, и ему нужен файл конфигурации для взаимодействия с бэкендом. Мне также нужны некоторые сертификаты, которые nginx загружает из файловой системы, поэтому переменные окружения здесь не работают. Я не писал nginx, так что не могу заставить его это делать.
Поэтому я просто добавляю этот контейнер прямо внутрь пода и обращаюсь к двум secrets.
Первый и самый главный secret – это TLS-сертификат, который должен поступить с Let's Encrypt. Я не собираюсь сообщать о Let's Encrypt своему приложению, я сообщаю о нем своей системе. Я хочу распоряжаться этой абстракцией. Поэтому сейчас я должен создать config-файл для nginx. Это основной файл конфигурации, который выглядит таким образом.
Здесь указан порт 443 и включен SSL, который ищет в файловой системе эти 2 файла, захватывает трафик и отправляет его локальному хосту 127.0.0.1:3000.
Это именно то, что «слушает» мое приложение. Сейчас я создам configmap — карту конфигурации nginx, используя следующую команду.
Теперь с помощью команды $ kubectl get configmaps я размещаю configmap «nginx» в системе с таким же именем, что и у диска.
Далее необходимо создать secret, напомню вам еще раз – я хочу, чтобы все было автоматизированным, и не хочу вмешиваться в процесс получения сертификатов. Для этого я развертываю инструмент под названием «kube-cert-manager», и вот что получается в результате.
Мы пытаемся получить действительный сертификат Let’s Encrypt, которому будет доверять мой браузер, и вставляем его в бэкенд как secret. Поэтому для моего пода не будет никакой разницы в том, что мы дополнили его содержимое. Если помните, все это сделано благодаря созданию custom type в Puppet.
Возможно, это плохая идея, но сейчас я постараюсь запустить контроллер, который будет работать в бэкграунде. Мы не делаем никакой компиляции, не создаем провайдеров, этот деймон просто работает в фоне и наблюдает за изменениями. Как только появляется объект сертификата, он получает его с Let’s Encrypt и вставляет в систему в режиме реального времени без всяких задержек. Итак, я использую следующую команду.
У этой штуки тоже есть хранилище, так что мы можем сохранить все что нужно. Требуется несколько секунд, чтобы менеджер сертификации kube-cert-manager начал работать.
Следующее, что нам нужно сделать, — это создать объект сертификата. Это то, что я определяю сам, это моя собственная схема. Я создаю новую вещь, которую Kubernetes не встречал до этого момента, в которой говорится, что я могу получить сертификат для домена lobsters.com.
Здесь имеется адрес электронной почты и другая информация, которая необходима для того, чтобы Let’s Encrypt выдал мне действительный сертификат. Let’s Encrypt пришлет мне обменный токен, чтобы увидеть, действительно ли я являюсь владельцем этого домена, и мне нужно будет применить этот токен к моему DNS в Google Cloud. Если проверка пройдет, то они выдадут мне настоящий сертификат, который я вставлю в свою файловую систему. Посмотрим, как это работает, введя команду $ kubectl get pods.
Как видите, менеджер сертификатов все еще работает. Посмотрим подробную информацию об этом процессе с помощью команды $ kubectl describe pods kube-cert-manager, вставив название контейнера из первой строки кода.
Вы видите, что выполняется работа по расписанию. В данный момент на сервере создается том, который после проверки и форматирования будет смонтирован на этом сервере. Пока идет этот процесс, можно пойти дальше и закончить нашу работу.
Я ввожу команду kubectl create –f certificates/lobsters.yaml и получаю следующий результат.
Далее я использую команду, которая позволяет просмотреть логи нескольких контейнеров. Я выделю тот, что касается моего объекта.
Сейчас происходит создание записи DNS внутри моего облачного DNS-сервера. Если я обновлю изображенную здесь страницу, то увижу новый обменный токен с расширением .txt.
Итак, я получил токен от Let’s Encrypt и теперь проверяю, что эта запись DNS распространилась по всем авторизированным серверам, прежде чем я скажу Let’s Encrypt, чтобы они проверили эту текстовую запись в моем домене.
Если это сработает, они пришлют мне обратно действующий сертификат. Демонстрация работы DNS в режиме реального времени – плохая идея. Ага, мы наконец получаем сертификат. Let’s Encrypt заметил, что сертификат исчез из Kubernetes, и вставил его туда. Это отлично, потому сейчас у меня уже имеется интерфейс запроса сертификатов для всего, что выполняется в среде Kubernetes.
Чтобы убедится, что все работает правильно, я ввожу команду $ kubectl get secrets, и мы видим один secret для сайта lobsters.hightowerlabs.com.
Теперь я использую команду $ 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.
Перейдя на вкладку Google Cloud, видно, что этот адрес совпадает с адресом, соответствующим доменному имени lobsters.hightowerlabs.com. Теперь, если набрать в адресной строке браузера lobsters.hightowerlabs.com, можно увидеть, что у нас имеется действующий сертификат.
Благодарю вас, это все, что я хотел рассказать в докладе «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 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Автор: ua-hosting.company
