Книга „Kubernetes за DevOps“

Здравейте жители на Хабро! Kubernetes е един от ключовите елементи на съвременната облачна екосистема. Тази технология осигурява надеждност, мащабируемост и устойчивост на виртуализация на контейнери. Джон Аръндел и Джъстин Домингъс говорят за екосистемата Kubernetes и представят доказани решения на ежедневните проблеми. Стъпка по стъпка ще изградите свое собствено облачно приложение и ще създадете инфраструктурата, която да го поддържа, ще настроите среда за разработка и конвейер за непрекъснато внедряване, който ще ви помогне, докато работите върху следващите си приложения.

• Започнете с контейнерите и Kubernetes от основите: не е необходим специален опит, за да научите темата. • Стартирайте свои собствени клъстери или изберете управлявана услуга Kubernetes от Amazon, Google и др. • Използвайте Kubernetes за управление на жизнения цикъл на контейнера и потреблението на ресурси. • Оптимизирайте клъстерите въз основа на цена, производителност, устойчивост, мощност и мащабируемост. • Научете най-добрите инструменти за разработване, тестване и внедряване на вашите приложения. • Използвайте настоящите индустриални практики, за да гарантирате сигурност и контрол. • Приложете принципите на DevOps във вашата компания, така че екипите за разработка да могат да действат по-гъвкаво, бързо и ефективно.

За кого е книгата?

Книгата е най-подходяща за служители на административни отдели, отговорни за сървъри, приложения и услуги, както и за разработчици, участващи или в изграждането на нови облачни услуги, или в мигрирането на съществуващи приложения към Kubernetes и облака. Не се притеснявайте, не е нужно да знаете как да работите с Kubernetes или контейнери - ние ще ви научим на всичко.

Опитните потребители на Kubernetes също ще открият много стойност, със задълбочено покритие на теми като RBAC, непрекъснато внедряване, управление на чувствителни данни и възможност за наблюдение. Надяваме се, че страниците на книгата ще съдържат нещо интересно за вас, независимо от вашите умения и опит.

На какви въпроси отговаря книгата?

Докато планирахме и пишехме книгата, обсъждахме облачните технологии и Kubernetes със стотици хора, говорейки с лидери и експерти в индустрията, както и с напълно начинаещи. По-долу са избрани въпроси, на които биха искали да видят отговор в тази публикация.

• „Интересувам се защо трябва да отделяте време за тази технология. Какви проблеми ще помогне на мен и моя екип да разрешим?“
• „Kubernetes изглежда интересен, но има доста висока бариера за навлизане. Подготвянето на прост пример не е трудно, но по-нататъшното администриране и отстраняване на грешки е плашещо. Бихме искали да получим надеждни съвети за това как хората управляват клъстерите на Kubernetes в реалния свят и какви проблеми е вероятно да срещнем."
• „Субективният съвет би бил полезен. Екосистемата на Kubernetes дава на новите екипи твърде много възможности за избор. Когато има няколко начина да направите едно и също нещо, как да разберете кой е най-добрият? Как да направим избор?

И може би най-важният от всички въпроси:

• „Как мога да използвам Kubernetes, без да наруша компанията си?“

Извадка. Конфигурация и секретни обекти

Възможността за отделяне на логиката на Kubernetes приложение от неговата конфигурация (т.е. от всякакви стойности или настройки, които могат да се променят с времето) е много полезна. Конфигурационните стойности обикновено включват специфични за средата настройки, DNS адреси на услуги на трети страни и идентификационни данни за удостоверяване.

Разбира се, всичко това може да се постави директно в кода, но този подход не е достатъчно гъвкав. Например, промяната на конфигурационна стойност ще изисква от вас да изградите и внедрите кода си отново. Много по-добро решение би било да се отдели конфигурацията от кода и да се прочете от файл или променливи на средата.

Kubernetes предоставя няколко различни начина за управление на конфигурацията. Първо, можете да предавате стойности на приложението чрез променливи на средата, посочени в спецификацията на обвивката на pod (вижте „Променливи на средата“ на страница 192). Второ, конфигурационните данни могат да се съхраняват директно в Kubernetes с помощта на ConfigMap и Secret обекти.

В тази глава ние изследваме подробно тези обекти и разглеждаме някои практически подходи за управление на конфигурация и чувствителни данни с помощта на демонстрационно приложение.

Актуализиране на обвивки на под при промяна на конфигурацията

Представете си, че имате внедряване във вашия клъстер и искате да промените някои стойности в неговата ConfigMap. Ако използвате диаграмата на Helm (вижте „Helm: Мениджър на пакети за Kubernetes“ на страница 102), можете автоматично да откриете промяна в конфигурацията и да презаредите обвивките на pod с един чист трик. Добавете следната анотация към вашата спецификация за внедряване:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

Шаблонът за внедряване вече съдържа контролна сума на конфигурационни параметри: ако параметрите се променят, сумата ще се актуализира. Ако стартирате надграждане на Helm, 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 обект. Тук за простота използваме само една двойка ключ-стойност.

Използване на секретни обекти като променливи на средата

Подобно на 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

Изпълнете следната команда в демо хранилището, за да приложите манифестите:

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 обекта към контейнера като файл. Кодът се намира в папката hello-secret-file на демонстрационното хранилище.

За да свържем 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"

Четене на секретни обекти

В предишния раздел използвахме командата kubectl describe, за да покажем съдържанието на ConfigMap. Може ли да се направи същото с Secret?

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             <none>
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

Моля, обърнете внимание, че самите данни не се показват. Тайните обекти в 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= е base64 кодирана версия на нашата тайна дума xyzzy. Можете да проверите това, като изпълните командата base64 —decode в терминала:

echo "eHl6enk=" | base64 --decode
xyzzy

И така, докато Kubernetes ви предпазва от случайно извеждане на чувствителни данни в терминала или регистрационни файлове, ако имате разрешения за четене на секретни обекти в конкретно пространство от имена, тези данни могат да бъдат базирани на база 64 и впоследствие декодирани.

Ако трябва да кодирате base64 някакъв текст (например, за да го поставите в Secret), използвайте командата base64 без аргументи:

echo xyzzy | base64
eHl6enkK

Достъп до секретни обекти

Кой може да чете и редактира секретни обекти? Това се определя от RBAC, механизъм за контрол на достъпа (ще го обсъдим подробно в подраздела „Въведение в ролевия контрол на достъпа“ на страница 258). Ако работите с клъстер, който няма RBAC или не е активиран, всички ваши Secret обекти са достъпни за всички потребители и контейнери (ще обясним по-късно, че не трябва да имате производствени клъстери без RBAC).

Пасивно криптиране на данни

Какво ще кажете за тези, които имат достъп до базата данни etcd, където Kubernetes съхранява цялата си информация? Могат ли да четат чувствителни данни, без да имат разрешение да четат Secret обекти чрез API?

От версия 1.7 Kubernetes поддържа пасивно криптиране на данни. Това означава, че чувствителната информация в etcd се съхранява криптирана на диск и не може да бъде прочетена дори от тези с директен достъп до базата данни. За да го дешифрирате, имате нужда от ключ, който има само Kubernetes API сървърът. В правилно конфигуриран клъстер пасивното криптиране трябва да бъде активирано.

Можете да проверите дали пасивното криптиране работи във вашия клъстер по следния начин:

kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
        --experimental-encryption-provider-config=...

Ако не виждате флага за конфигурация на експериментален доставчик на шифроване, пасивното шифроване не е активирано. Когато използвате Google Kubernetes Engine или други услуги за управление на Kubernetes, вашите данни се криптират с помощта на различен механизъм, така че флагът няма да присъства. Проверете при вашия доставчик на Kubernetes дали etcd съдържанието е шифровано.

Съхраняване на поверителни данни

Има някои ресурси на Kubernetes, които никога не трябва да се премахват от клъстера, като например силно чувствителни секретни обекти. Можете да защитите ресурс от изтриване, като използвате анотация, предоставена от мениджъра на Helm:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

Стратегии за управление на тайни обекти

В примера от предишния раздел чувствителните данни бяха защитени от неоторизиран достъп веднага след като бяха съхранени в клъстера. Но във файловете на манифеста те се съхраняват като обикновен текст.

Никога не трябва да поставяте поверителна информация във файлове, които са в контрола на версиите. Как можете безопасно да управлявате и съхранявате тази информация, преди да я приложите към вашия клъстер Kubernetes?

Можете да изберете всякакви инструменти или стратегии за обработка на чувствителни данни във вашите приложения, но все пак ще трябва да отговорите поне на следните въпроси.

• Къде трябва да се съхраняват чувствителни данни, така че да са много достъпни?
• Как да направите чувствителни данни достъпни за вашите активни приложения?
• Какво трябва да се случи с вашите приложения, когато замените или редактирате чувствителни данни?

За авторите

Джон Аръндел е консултант с 30 години опит в компютърната индустрия. Той е написал няколко книги и работи с много компании от различни страни, като ги съветва относно облачната инфраструктура и Kubernetes. В свободното си време обича да кара сърф, стреля добре с пистолет и свири любителски на пиано. Живее в приказна вила в Корнуол, Англия.

Джъстин Домингъс — инженер по системна администрация, работещ в DevOps среда с Kubernetes и облачни технологии. Той обича да прекарва времето си на открито, да пие кафе, да лови раци и да седи пред компютъра. Живее в Сиатъл, Вашингтон, с прекрасна котка и още по-прекрасна съпруга и най-добра приятелка Адриен.

» За повече информация относно книгата, моля посетете уебсайт на издателя
» Таблица на съдържанието
» Откъс

За Khabrozhiteli 25% отстъпка от купона - Kubernetes

При заплащане на хартиената версия на книгата, на електронната поща се изпраща електронна книга.

Източник: www.habr.com