Книга «Kubernetes для DevOps»
Привет, Хаброжители! Kubernetes — один из ключевых элементов современной облачной экосистемы. Эта технология обеспечивает надежность, масштабируемость и устойчивость контейнерной виртуализации. Джон Арундел и Джастин Домингус рассказывают об экосистеме Kubernetes и знакомят с проверенными решениями повседневных проблем. Шаг за шагом вы построите собственное облачно-ориентированное приложение и создадите инфраструктуру для его поддержки, настроите среду разработки и конвейер непрерывного развертывания, который пригодится вам при работе над следующими приложениями.
• Начнете работу с контейнерами и Kubernetes с азов: никакого специального опыта для изучения темы не требуется. • Запустите собственные кластеры или выберете управляемый сервис Kubernetes от Amazon, Google и др. • Примените Kubernetes для управления жизненным циклом контейнера и расхода ресурсов. • Оптимизируете кластеры по показателям стоимости, производительности, устойчивости, мощности и масштабируемости. • Изучите наилучшие инструменты для разработки, тестирования и развертывания ваших приложений. • Воспользуетесь актуальными отраслевыми практиками для обеспечения безопасности и контроля. • Внедрите в компании принципы DevOps, чтобы команды разработчиков стали действовать более гибко, быстро и эффективно.
Для кого предназначена книга
Книга наиболее актуальна для сотрудников отделов администрирования, ответственных за серверы, приложения и сервисы, а также для разработчиков, занимающихся либо построением новых облачных сервисов, либо миграцией существующих приложений в Kubernetes и облако. Не волнуйтесь, уметь работать с Kubernetes и контейнерами не требуется — мы всему научим.
Опытные пользователи Kubernetes также найдут для себя много ценного: здесь углубленно рассматриваются такие темы, как RBAC, непрерывное развертывание, управление конфиденциальными данными и наблюдаемость. Надеемся, что на страницах книги обязательно окажется что-нибудь интересное и для вас, независимо от ваших навыков и опыта.
На какие вопросы отвечает книга
Во время планирования и написания книги мы обсуждали облачные технологии и Kubernetes с сотнями людей, разговаривали как с лидерами и экспертами в данной отрасли, так и с абсолютными новичками. Ниже приведены отдельные вопросы, ответы на которые им хотелось бы увидеть в этом издании.
- «Меня интересует, почему следует тратить время на эту технологию. Какие проблемы она поможет решить мне и моей команде?»
- «Kubernetes кажется интересной, но имеет довольно высокий порог вхождения. Подготовить простой пример не составляет труда, но дальнейшие администрирование и отладка пугают. Мы бы хотели получить надежные советы о том, как люди управляют кластерами Kubernetes в реальных условиях и с какими проблемами мы, скорее всего, столкнемся».
- «Был бы полезен субъективный совет. Экосистема Kubernetes предлагает начинающим командам слишком много вариантов на выбор. Когда одно и то же можно сделать несколькими способами, как понять, какой из них лучше? Как сделать выбор?»
И, наверное, наиболее важный из всех вопросов:
- «Как использовать Kubernetes, не нарушая работу моей компании?»
Отрывок. Конфигурация и объекты Secret
Возможность отделить логику приложения Kubernetes от его конфигурации (то есть от любых значений или настроек, которые со временем могут поменяться) очень полезна. К конфигурационным значениям обычно относят параметры, предназначенные для определенной среды, DNS-адреса сторонних сервисов и учетные данные для аутентификации.
Конечно, все это можно поместить непосредственно в код, но такой подход недостаточно гибок. Например, для изменения конфигурационного значения тогда придется заново собирать и развертывать ваш код. Намного лучшим решением было бы отделить конфигурацию от кода и считывать ее из файла или переменных среды.
Kubernetes предоставляет несколько разных способов управления конфигурацией. Во-первых, вы можете передавать значения в приложение через переменные среды, указанные в спецификации pod-оболочки (см. подраздел «Переменные среды» на с. 192). Во-вторых, конфигурационные данные можно хранить непосредственно в Kubernetes, используя объекты ConfigMap и Secret.
В данной главе мы подробно исследуем эти объекты и рассмотрим некоторые практические подходы к управлению конфигурацией и конфиденциальными данными на примере демонстрационного приложения.
Обновление pod-оболочек при изменении конфигурацииt
Представьте, что в вашем кластере есть развертывание и вы хотите поменять некоторые значения в его ConfigMap. Если вы используете чарт Helm (см. раздел «Helm: диспетчер пакетов для Kubernetes» на с. 102), обнаружить изменение конфигурации и перезагрузить ваши pod-оболочки можно автоматически с помощью одного изящного приема. Добавьте следующую аннотацию в спецификацию своего развертывания:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}
Теперь шаблон развертывания содержит контрольную сумму конфигурационных параметров: при изменении параметров сумма обновится. Если выполнить команду helm upgrade, Helm обнаружит, что спецификация развертывания изменилась, и перезапустит все pod-оболочки.
Конфиденциальные данные в Kubernetes
Мы уже знаем, что объект ConfigMap предоставляет гибкий механизм хранения и доступа к конфигурационным данным в кластере. Однако у большинства приложений есть информация, которая является секретной и конфиденциальной: например, пароли или API-ключи. Ее можно хранить и в ConfigMap, но такое решение неидеально.
Вместо этого Kubernetes предлагает объект специального типа, предназначенный для хранения конфиденциальных данных: Secret. Далее рассмотрим на примере, как данный объект можно применить в нашем демонстрационном приложении.
Для начала взгляните на манифест Kubernetes для объекта Secret (см. hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
В этом примере закрытый ключ magicWord имеет значение xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Слово xyzzy вообще очень полезное в мире компьютеров. По аналогии с ConfigMap в объекте Secret можно размещать множество ключей и значений. Здесь для простоты мы используем лишь одну пару «ключ — значение».
Использование объектов Secret в качестве переменных среды
Как и ConfigMap, объект Secret можно сделать доступным в контейнере в виде переменных среды или файла на его диске. В следующем примере мы присвоим переменной среды значение из Secret:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWord
Выполните следующую команду в репозитории demo, чтобы применить манифесты:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created
Как и раньше, перенаправьте локальный порт к развертыванию, чтобы увидеть результат в своем браузере:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888
При открытии адреса localhost:9999/ вы должны увидеть следующее:
The magic word is "xyzzy"
Запись объектов Secret в файлы
В этом примере мы подключим объект Secret к контейнеру в виде файла. Код находится в папке hello-secret-file репозитория demo.
Чтобы подключить Secret в виде файла, воспользуемся следующим развертыванием:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-file
ports:
- containerPort: 8888
volumeMounts:
- name: demo-secret-volume
mountPath: "/secrets/"
readOnly: true
volumes:
- name: demo-secret-volume
secret:
secretName: demo-secret
Как и в подразделе «Создание конфигурационных файлов из объектов ConfigMap» на с. 240, мы создаем том (в данном случае это demo-secret-volume) и подключаем его к контейнеру в разделе спецификации volumeMounts. В поле mountPath указано /secrets, поэтому Kubernetes создаст в этой папке по одному файлу для каждой пары «ключ — значение», определенной в объекте Secret.
В нашем примере мы определили только одну пару «ключ — значение» с именем magicWord, поэтому манифест создаст в контейнере один файл /secrets/magicWord с конфиденциальными данными, доступный исключительно для чтения.
Если применить этот манифест таким же образом, как и в предыдущем примере, должен получиться тот же результат:
The magic word is "xyzzy"
Чтение объектов Secret
В предыдущем разделе мы использовали команду kubectl describe для вывода содержимого ConfigMap. Можно ли то же самое сделать с Secret?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels:
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytes
Обратите внимание на то, что сами данные не отображаются. Объекты Secret в Kubernetes имеют тип Opaque: это означает, что их содержимое не показывается в выводе kubectl describe, журнальных записях и терминале, благодаря чему невозможно случайно раскрыть конфиденциальную информацию.
Чтобы просмотреть закодированную версию конфиденциальных данных в формате YAML, воспользуйтесь командой kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque
base64
Что за eHl6enk=, совсем не похожий на наше исходное значение? На самом деле это объект Secret, представленный в кодировке base64. Base64 — это схема кодирования произвольных двоичных данных в виде строки символов.
Поскольку конфиденциальная информация может быть двоичной и недоступной для вывода (как, например, в случае с ключом шифрования TLS), объекты Secret всегда хранятся в формате base64.
Текст beHl6enk= является версией нашего секретного слова xyzzy, закодированной в base64. В этом можно убедиться, если выполнить в терминале команду base64 --decode:
echo "eHl6enk=" | base64 --decode
xyzzy
Таким образом, несмотря на то, что Kubernetes защищает вас от случайного вывода конфиденциальных данных в терминале или журнальных файлах, при наличии прав на чтение объектов Secret в определенном пространстве имен эти данные можно получить в формате base64 и впоследствии их раскодировать.
Если вам нужно закодировать в base64 какой-нибудь текст (например, чтобы поместить его в Secret), используйте команду base64 без аргументов:
echo xyzzy | base64
eHl6enkK
Доступ к объектам Secret
Кто может читать и редактировать объекты Secret? Это определяется RBAC — механизмом контроля доступа (подробно его обсудим в подразделе «Введение в управление доступом на основе ролей» на с. 258). Если вы используете кластер, в котором система RBAC отсутствует или не включена, все ваши объекты Secret доступны любым пользователям и контейнерам (позже мы объясним, что у вас не должно быть ни одного промышленного кластера без RBAC).
Пассивное шифрование данных
А что насчет тех, кто имеет доступ к базе данных etcd, в которой Kubernetes хранит всю свою информацию? Могут ли они прочитать конфиденциальные данные, не имея прав на чтение объектов Secret через API?
Начиная с версии 1.7, Kubernetes поддерживает пассивное шифрование данных. Это означает, что конфиденциальная информация внутри etcd хранится на диске в зашифрованном виде и не может быть прочитана даже тем, кто имеет прямой доступ к базе данных. Для ее расшифровки нужен ключ, который есть только у сервера API Kubernetes. В правильно сконфигурированном кластере пассивное шифрование должно быть включено.
Проверить, работает ли пассивное шифрование в вашем кластере, можно таким образом:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...
Если вы не видите флага experimental-encryption-provider-config, пассивное шифрование не включено. При использовании Google Kubernetes Engine или других сервисов по управлению Kubernetes ваши данные шифруются с помощью иного механизма, поэтому флаг будет отсутствовать. Узнайте у своего поставщика Kubernetes, шифруется ли содержимое etcd.
Хранение конфиденциальных данных
Есть такие ресурсы Kubernetes, которые никогда не следует удалять из кластера: например, особо важные объекты Secret. Вы можете уберечь ресурс от удаления с помощью аннотации, предоставляемой диспетчером Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keep
Стратегии управления объектами Secret
В примере из предыдущего раздела конфиденциальные данные защищались от несанкционированного доступа сразу после сохранения в кластере. Но в файлах манифестов они хранились в виде обычного текста.
Вы никогда не должны размещать конфиденциальную информацию в файлах, которые находятся в системе контроля версий. Как же безопасно администрировать и хранить такую информацию до того, как применить ее к кластеру Kubernetes?
Вы можете выбрать любые инструменты или стратегии для работы с конфиденциальными данными в своих приложениях, но все равно вам понадобится ответить как минимум на следующие вопросы.
- Где хранить конфиденциальные данные, чтобы они были высокодоступными?
- Как сделать конфиденциальные данные доступными для ваших активных приложений?
- Что должно происходить с вашими приложениями, когда вы заменяете или редактируете конфиденциальные данные?
Об авторах
Джон Арундел является консультантом с 30-летним опытом работы в компьютерной индустрии. Он написал несколько книг и работает со многими компаниями из разных стран, консультируя их в вопросах облачно-ориентированной инфраструктуры и Kubernetes. В свободное время увлекается серфингом, неплохо стреляет из пистолета и любительски играет на пианино. Живет в сказочном коттедже в Корнуолле, Англия.
Джастин Домингус — инженер системного администрирования, работающий в среде DevOps с Kubernetes и облачными технологиями. Ему нравится проводить время на свежем воздухе, пить кофе, ловить крабов и сидеть за компьютером. Живет в Сиэтле, штат Вашингтон, вместе с замечательным котом и еще более замечательной женой и по совместительству лучшим другом Эдриэнн.
» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Kubernetes
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
