Прывітанне, Хаброжыцелі! 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Пры адкрыцці адраса :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: Opaquebase64
Што за 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 дасылаецца электронная кніга.
Крыніца: habr.com