Книга "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 виявить, що специфікація розгортання змінилася, і перезапустить всі оболонки.

Конфіденційні дані в 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

При відкритті адреси локальний: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:             <none>
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% купона Кубернетес

За фактом оплати паперової версії книги на e-mail надсилається електронна книга.

Джерело: habr.com