🥇Knjiga „Kubernetes za DevOps“

Pozdrav, Habržitelji! Kubernetes je jedan od ključnih elemenata savremene cloud ekosistema. Ova tehnologija obezbeđuje pouzdanost, skalabilnost i otpornost kontejnerske virtualizacije. Džon Arundel i Džastin Domingus pričaju o ekosistemu Kubernetes-a i upoznavaju sa proverenim rešenjima svakodnevnih problema. Korak po korak, izgradićete vlastitu cloud-orijentisanu aplikaciju i stvoriti infrastrukturu za njeno podržavanje, podesiti razvojno okruženje i kontinuiranu isporuku koje će vam koristiti prilikom rada na budućim aplikacijama.

• Započnite rad sa kontejnerima i Kubernetes-om od osnova: nije potrebno nikakvo specijalno iskustvo za učenje ove teme. • Pokrenite vlastite klastere ili izaberite upravljanu Kubernetes uslugu od Amazona, Google-a i drugih. • Primijenite Kubernetes za upravljanje životnim ciklusom kontejnera i korišćenjem resursa. • Optimizujte klastere prema troškovima, performansama, otpornosti, snazi i skalabilnosti. • Istražite najbolje alate za razvoj, testiranje i implementaciju vaših aplikacija. • Iskoristite aktuelne industrijske prakse za obezbeđivanje sigurnosti i kontrole. • Uvedite u kompaniju principe DevOps-a, tako da timovi programera mogu raditi fleksibilnije, brže i efikasnije.

Za koga je knjiga namenjena

Knjiga je najrelevantnija za zaposlenike administrativnih odeljenja koji su odgovorni za servere, aplikacije i usluge, kao i za programere koji se bave ili izgradnjom novih cloud usluga ili migracijom postojećih aplikacija u Kubernetes i cloud. Ne brinite, nije potrebno imati iskustva sa radom u Kubernetes-u i kontejnerima — naučićemo vas svemu.

Iskusni korisnici Kubernetes-a takođe će pronaći mnogo vrednih informacija: ovde se detaljno razmatraju teme poput RBAC, kontinuirane isporuke, upravljanja poverljivim podacima i posmatranja. Nadamo se da će se na stranicama knjige obavezno naći nešto interesantno i za vas, bez obzira na vaše veštine i iskustvo.

Na koja pitanja knjiga odgovara

Med načrtovanjem in pisanjem knjige smo z več sto ljudmi razpravljali o oblačnih tehnologijah in Kubernetesu, se pogovarjali tako z voditelji in strokovnjaki v industriji kot z absolutnimi novinci. Spodaj so navedena vprašanja, na katera bi želeli videti odgovore v tej izdaji.

«Zanima me, zakaj bi moral izgubljati čas s to tehnologijo. Katere težave bo rešila meni in moji ekipi?»
«Kubernetes se zdi zanimiv, a ima precej visok vhodni prag. Pripraviti enostaven primer ni težko, vendar me straši nadaljnje upravljanje in odpravljanje napak. Radi bi dobili zanesljive nasvete o tem, kako ljudje upravljajo s Kubernetes klasterji v realnih pogojih in s katerimi problemi se najverjetneje srečamo.»
«Bilo bi koristno subjektivno mnenje. Ekosistem Kubernetes novim ekipam ponuja preveč možnosti. Ko je isto mogoče doseči na več načinov, kako razumeti, katera je najboljša? Kako se odločiti?»

In verjetno najpomembnejše od vseh vprašanj:

«Kako uporabiti Kubernetes, ne da bi motil delovanje moje podjetja?»

Odsek. Konfiguracija in objekti Secret

Možnost ločevanja logike aplikacije Kubernetes od njene konfiguracije (tj. od vseh vrednosti ali nastavitev, ki se lahko s časom spremenijo) je zelo koristna. Konfiguracijske vrednosti običajno vključujejo parametre, namenjene določeni okoljski nastavitvi, DNS-naslove zunanjih storitev in poverilnice za avtentikacijo.

Seveda vse to lahko vključite neposredno v kodo, vendar tak pristop ni dovolj fleksibilen. Na primer, za spremembo konfiguracijske vrednosti boste morali znova sestaviti in implementirati vašo kodo. Mnogo boljša rešitev bi bila ločiti konfiguracijo od kode in jo brati iz datoteke ali okolijskih spremenljivk.

Kubernetes ponuja več različnih načinov za upravljanje konfiguracije. Prvič, vrednosti lahko prenesete v aplikacijo prek okolijskih spremenljivk, določenih v specifikaciji pod-lučke (glej razdelek 'Okoljske spremenljivke' na str. 192). Drugič, konfiguracijski podatki se lahko shranijo neposredno v Kubernetes z uporabo objektov ConfigMap in Secret.

V tem poglavju bomo podrobno raziskali te objekte in pregledali nekatere praktične pristope k upravljanju s konfiguracijo ter zaupnimi podatki na primeru demostrativne aplikacije.

Posodabljanje pod-ovalk ob spreminjanju konfiguracije

Predstavljajte si, da imate v svojem klasterju razmestitev in želite spremeniti nekatere vrednosti v njegovem ConfigMap-u. Če uporabljate Helm graf (glejte razdelek 'Helm: upravljalec paketov za Kubernetes' na str. 102), lahko spremembo konfiguracije zaznate in avtomatsko ponovno zaženete svoje pod-ovalk, s pomočjo enega elegantnega trika. Vspecifikacijo svoje razmestitve dodajte naslednjo oznako:

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

Sedaj predloga razmestitve vsebuje kontrolno vsoto konfiguracijskih parametrov: ob spremembi parametrov se vsota posodobi. Če izvedete ukaz helm upgrade, bo Helm zaznal, da je specifikacija razmestitve spremenjena, in ponovno zažene vse pod-ovalk.

Zaupni podatki v Kubernetesu

Že vemo, da objekt ConfigMap ponuja prilagodljiv mehanizem za shranjevanje in dostop do konfiguracijskih podatkov v klasterju. Vendar pa ima večina aplikacij informacije, ki so tajne in zaupne: na primer, gesla ali API ključi. Te lahko shranimo tudi v ConfigMap, toda to ni idealna rešitev.

Namesto tega Kubernetes ponuja objekt posebne vrste, namenjen shranjevanju zaupnih podatkov: Secret. V nadaljevanju bomo na primeru prikazali, kako ta objekt uporabiti v naši demostratvni aplikaciji.

Najprej si oglejmo manifest Kubernetes za objekt Secret (glejte hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

V tem primeru ima skriti ključ magicWord vrednost xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Beseda xyzzy je v svetu računalnikov zelo koristna. Tako kot v ConfigMap lahko v objektu Secret shranjujemo več ključev in vrednosti. Tukaj za poenostavitev uporabljamo le en par 'ključ - vrednost'.

Uporaba objektov Secret kot okolijskih spremenljivk

Tako kot ConfigMap je mogoče objekt Secret narediti dostopen v kontejnerju v obliki okolijskih spremenljivk ali datoteke na njegovem disku. V naslednjem primeru bomo spremenljivki okolja dodelili vrednost iz 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/
department.extensions "demo" настроен
секрет "demo-secret" создан

Как и прежде, перенаправьте локальный порт на развертывание, чтобы увидеть результат в вашем браузере:

kubectl port-forward deploy/demo 9999:8888
Перенаправление с 127.0.0.1:9999 -> 8888
Перенаправление с [::1]:9999 -> 8888

При открытии адреса localhost:9999/ вы должны увидеть следующее:

Загадочное слово — "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», мы создаем том (в данном случае это demo-secret-volume) и подключаем его к контейнеру в разделе спецификации volumeMounts. В поле mountPath указано /secrets, поэтому Kubernetes создаст в этой папке по одному файлу для каждой пары «ключ — значение», определенной в объекте Secret.

В нашем примере мы определили только одну пару «ключ — значение» с именем magicWord, поэтому манифест создаст в контейнере один файл /secrets/magicWord с конфиденциальными данными, доступный исключительно для чтения.

Если применить этот манифест так же, как и в предыдущем примере, должен получиться тот же результат:

Загадочное слово — "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, журнальных записях и терминале, благодаря чему невозможно случайно раскрыть конфиденциальную информацию.

Za ogled kodirane verzije zaupnih podatkov v formatu YAML uporabite ukaz kubectl get:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

base64

Kaj je eHl6enk=, ki se sploh ne podobna naši izvorni vrednosti? V resnici je to objekt Secret, predstavljen v base64 kodiranju. Base64 je shema kodiranja poljubnih binarnih podatkov v obliki niza znakov.

Ker so zaupni podatki lahko binarni in ne dostopni za izpis (kot v primeru TLS šifrirnega ključa), se objekti Secret vedno shranjujejo v formatu base64.

Besedilo beHl6enk= je različica našega skrivnega besede xyzzy, kodirana v base64. To lahko preverite tako, da v terminal vnesete ukaz base64 --decode:

echo "eHl6enk=" | base64 --decode
xyzzy

Tako, čeprav Kubernetes zaščiti pred slučajnim izpisom zaupnih podatkov v terminalu ali dnevniških datotekah, je ob pravicah za branje objektov Secret v določenem imenskem prostoru te podatke mogoče pridobiti v formatu base64 in jih kasneje dekodirati.

Če morate kodirati kakšen besedilo v base64 (na primer, da ga vključite v Secret), uporabite ukaz base64 brez argumentov:

echo xyzzy | base64
eHl6enkK

Dostop do objektov Secret

Kdo lahko bere in ureja objekte Secret? To določa RBAC — mehanizem nadzora dostopa (podrobneje bomo obravnavali v podpoglavju 'Uvod v upravljanje dostopa na podlagi vlog' na str. 258). Če uporabljate grozd, v katerem RBAC sistemi ni, ali ni omogočen, so vsi vaši objekti Secret na voljo vsem uporabnikom in rezinicam (kasneje bomo razložili, da ne bi smeli imeti nobenega industrijskega grozda brez RBAC).

Pasivno šifriranje podatkov

Kaj pa tisti, ki imajo dostop do baze podatkov etcd, kjer Kubernetes shranjuje vse svoje informacije? Ali lahko preberejo zaupne podatke, ne da bi imeli pravice za branje objektov Secret prek API?

Od različice 1.7 naprej Kubernetes podpira pasivno šifriranje podatkov. To pomeni, da se občutljive informacije znotraj etcd shranjujejo na disku v šifrirani obliki in jih ne morejo prebrati niti tisti, ki imajo neposreden dostop do baze podatkov. Za njihovo dešifriranje potrebujemo ključ, ki ga ima le API strežnik Kubernetes. V pravilno konfiguriranem klastru mora biti pasivno šifriranje omogočeno.

Pasivno šifriranje v vašem klastru lahko preverite na naslednji način:

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

Če ne vidite zastavice experimental-encryption-provider-config, pasivno šifriranje ni omogočeno. Pri uporabi Google Kubernetes Engine ali drugih storitev za upravljanje Kubernetes se vaši podatki šifrirajo z drugačnim mehanizmom, zato zastavice ne bo. Povprašajte svojega ponudnika Kubernetes, ali se vsebina etcd šifrira.

Shranjevanje občutljivih podatkov

Obstajajo nekateri viri Kubernetes, ki jih nikoli ne smete izbrisati iz klastru: na primer, pomembni objekti Secret. Vir lahko zaščitite pred brisanjem s pomočjo označbe, ki jo zagotavlja Helm upravljalec:

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

Strategije upravljanja objektov Secret

V prejšnjem razdelku so bili občutljivi podatki zaščiteni pred nepooblaščenim dostopom takoj po shranjevanju v klaster. V datotekah manifestov so bili shranjeni v navadnem besedilu.

Nikoli ne smete shranjevati občutljivih informacij v datotekah, ki so v sistemu za nadzor različic. Kako torej varno upravljati in hraniti te informacije, preden jih uporabite v klastru Kubernetes?

Lahko izberete katera koli orodja ali strategije za delo z občutljivimi podatki v svojih aplikacijah, a boste še vedno morali odgovoriti na vsaj naslednja vprašanja.

Kje shraniti občutljive podatke, da bodo visoko dostopni?
Kako narediti občutljive podatke dostopne za vaše aktivne aplikacije?
Kaj se mora zgoditi z vašimi aplikacijami, ko zamenjate ali uredite občutljive podatke?

O avtorjih

John Arundel je svetovalec z 30-letnimi izkušnjami na področju računalniške industrije. Napisal je več knjig in sodeluje z mnogimi podjetji iz različnih držav, jim svetuje glede oblačne infrastrukture in Kubernetes. V prostem času se ukvarja s surfanjem, dobro strelja s pištolo in ljubiteljsko igra na klavir. Živi v pravljični hiši v Cornwallu v Angliji.

Justin Domingus je inženir sistemskega administriranja, ki dela v okolju DevOps s Kubernetes in oblačnimi tehnologijami. Rad preživlja čas na svežem zraku, pije kavo, lovi rake in sedi za računalnikom. Živi v Seattlu, v zvezni državi Washington, skupaj z čudovitim mačkom in še bolj čudovito ženo ter najboljšim prijateljem Adriennom.

» Podrobneje si lahko ogledate knjigo na spletni strani založnika
» Taula de continguts
» Odrezek

Za Habr uporabnike popust 25% s kodo — Kubernetes

Ob plačilu papirne različice knjige se na e-mail pošlje elektronska knjiga.

Izvor: habr.com