Saluton, loĝantoj de Khabro! Kubernetes estas unu el la ŝlosilaj elementoj de la moderna nuba ekosistemo. Ĉi tiu teknologio disponigas fidindecon, skaleblon kaj fortikecon al kontenervirtualigo. John Arundel kaj Justin Domingus parolas pri la ekosistemo Kubernetes kaj prezentas pruvitajn solvojn al ĉiutagaj problemoj. Paŝo post paŝo, vi konstruos vian propran nub-denaskan aplikaĵon kaj kreos la infrastrukturon por subteni ĝin, starigos disvolvan medion kaj kontinuan disfaldan dukton, kiu helpos vin dum vi laboros pri viaj sekvaj aplikoj.
• Komencu kun ujoj kaj Kubernetes de la bazoj: neniu speciala sperto estas bezonata por lerni la temon. • Kuru viajn proprajn aretojn aŭ elektu administritan Kubernetes-servon de Amazon, Google, ktp. • Uzu Kubernetes por administri kontenan vivociklon kaj konsumon de rimedoj. • Optimumigu aretojn bazitajn sur kosto, rendimento, fortikeco, potenco kaj skaleblo. • Lernu la plej bonajn ilojn por disvolvi, testi kaj disfaldi viajn aplikaĵojn. • Utiligi aktualajn industriajn praktikojn por certigi sekurecon kaj kontrolon. • Efektivigu DevOps-principojn tra via kompanio por ke evoluigaj teamoj povu agi pli flekseble, rapide kaj efike.
Por kiu estas la libro?
La libro estas plej grava por dungitoj de administraj fakoj respondecaj pri serviloj, aplikoj kaj servoj, same kiel por programistoj implikitaj en aŭ konstruado de novaj nubaj servoj aŭ migrado de ekzistantaj aplikoj al Kubernetes kaj la nubo. Ne maltrankviliĝu, vi ne bezonas scii kiel labori kun Kubernetes aŭ ujoj - ni instruos al vi ĉion.
Spertaj uzantoj de Kubernetes ankaŭ trovos multan valoron, kun profunda priraportado de temoj kiel ekzemple RBAC, kontinua disfaldo, sentema administrado de datumoj kaj observeblo. Ni esperas, ke la paĝoj de la libro certe enhavos ion interesan por vi, sendepende de viaj kapabloj kaj sperto.
Kiajn demandojn respondas la libro?
Dum planado kaj skribado de la libro, ni diskutis nuban teknologion kaj Kubernetes kun centoj da homoj, parolante kun industriaj gvidantoj kaj spertuloj kaj kun kompletaj novuloj. Malsupre estas elektitaj demandoj, kiujn ili ŝatus vidi responditaj en ĉi tiu eldonaĵo.
- “Mi interesiĝas pri kial vi devus pasigi tempon por ĉi tiu teknologio. Kiajn problemojn ĝi helpos al mi kaj al mia teamo solvi?"
- “Kubernetes ŝajnas interesa, sed havas sufiĉe altan barieron al eniro. Prepari simplan ekzemplon ne estas malfacila, sed plua administrado kaj sencimigado estas timiga. Ni ŝatus ricevi fidindajn konsilojn pri kiel homoj administras Kubernetes-grupojn en la reala mondo kaj kiajn problemojn ni verŝajne renkontos."
- “Subjektiva konsilo estus helpema. La ekosistemo de Kubernetes donas al novaj teamoj tro multajn eblojn por elekti. Kiam estas pluraj manieroj fari la saman aferon, kiel vi scias, kiu estas la plej bona? Kiel fari elekton?
Kaj eble la plej grava el ĉiuj demandoj:
- "Kiel mi povas uzi Kubernetes sen interrompi mian kompanion?"
Eltiraĵo. Agordo kaj Sekretaj objektoj
La kapablo apartigi la logikon de Kubernetes-apliko de ĝia agordo (tio estas, de iuj valoroj aŭ agordoj, kiuj povas ŝanĝiĝi kun la tempo) estas tre utila. Agordaj valoroj kutime inkluzivas medio-specifajn agordojn, triajn servaj DNS-adresoj kaj aŭtentigaj akreditaĵoj.
Kompreneble, ĉio ĉi povas esti metita rekte en la kodon, sed ĉi tiu aliro ne estas sufiĉe fleksebla. Ekzemple, ŝanĝi agordan valoron tiam postulus, ke vi rekonstruu kaj disfaldi vian kodon. Multe pli bona solvo estus apartigi la agordon de la kodo kaj legi ĝin el dosiero aŭ mediovariabloj.
Kubernetes provizas plurajn malsamajn manierojn administri agordon. Unue, vi povas transdoni valorojn al la aplikaĵo per medio-variabloj specifitaj en la specifo de pod-envolvaĵo (vidu "Mediaj Variabloj" sur paĝo 192). Due, agordaj datumoj povas esti stokitaj rekte en Kubernetes uzante ConfigMap kaj Sekretajn objektojn.
En ĉi tiu ĉapitro, ni esploras ĉi tiujn objektojn detale kaj rigardas kelkajn praktikajn alirojn al administrado de agordo kaj sentemaj datumoj uzante demo-aplikaĵon.
Ĝisdatigante podŝelojn kiam agordo ŝanĝiĝas
Imagu, ke vi havas deplojon en via areto kaj vi volas ŝanĝi iujn valorojn en ĝia ConfigMap. Se vi uzas la Helm-diagramon (vidu "Helm: Pakaĵadministrilo por Kubernetes" sur paĝo 102), vi povas aŭtomate detekti agordan ŝanĝon kaj reŝargi viajn podŝelojn per unu bona lertaĵo. Aldonu la sekvan komentarion al via deploja specifo:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}La deploja ŝablono nun enhavas ĉeksumon de agordaj parametroj: se la parametroj estas ŝanĝitaj, la sumo estos ĝisdatigita. Se vi ruligas helm-ĝisdatigon, Helm detektos, ke la deploja specifo ŝanĝiĝis kaj rekomencos ĉiujn podŝelojn.
Sentemaj datumoj en Kubernetes
Ni jam scias, ke la objekto ConfigMap provizas flekseblan mekanismon por stoki kaj aliri agordajn datumojn en areto. Tamen, plej multaj aplikoj havas informojn, kiuj estas sentemaj kaj sentemaj, kiel pasvortoj aŭ API-ŝlosiloj. Ĝi ankaŭ povas esti konservita en ConfigMap, sed ĉi tiu solvo ne estas ideala.
Anstataŭe, Kubernetes ofertas specialan specon de objekto desegnita por stoki sentemajn datumojn: Sekreta. Poste, ni rigardu ekzemplon pri kiel ĉi tiu objekto povas esti uzata en nia demo-aplikaĵo.
Por komenci, rigardu la manifeston de Kubernetes por la Sekreta objekto (vidu hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
En ĉi tiu ekzemplo, la privata ŝlosilo magicWord estas xyzzy (en.wikipedia.org/wiki/Xyzzy_(komputado)). La vorto xyzzy estas ĝenerale tre utila en la mondo de komputiloj. Simile al ConfigMap, vi povas stoki plurajn ŝlosilojn kaj valorojn en Sekreta objekto. Ĉi tie, por simpleco, ni uzas nur unu ŝlosil-valoran paron.
Uzante Sekretajn Objektojn kiel Medivariablojn
Kiel ConfigMap, la Sekreta objekto povas esti disponebla en la ujo kiel mediovariabloj aŭ kiel dosiero sur sia disko. En la sekva ekzemplo, ni asignos mediovariablon al la valoro de Sekreto:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordRulu la sekvan komandon en la pruva deponejo por apliki la manifestojn:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" createdKiel antaŭe, plusendu la lokan havenon al la deplojo por vidi la rezulton en via retumilo:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888Kiam oni malfermas adreson :9999/ vi devus vidi la jenon:
The magic word is "xyzzy"
Skribante Sekretajn Objektojn al Dosieroj
En ĉi tiu ekzemplo, ni aldonos la Sekretan objekton al la ujo kiel dosiero. La kodo troviĝas en la dosierujo hello-secret-dosierujo de la pruv-deponejo.
Por konekti Sekreton kiel dosieron, ni uzos la jenan deplojon:
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-secretKiel en la subsekcio “Kreante agordajn dosierojn el ConfigMap-objektoj” sur p. 240, ni kreas volumon (ĉi-kaze demo-sekreta-volumeno) kaj muntas ĝin al la ujo en la sekcio de volumeMounts de la specifo. La kampo mountPath estas /secrets, do Kubernetes kreos unu dosieron en ĉi tiu dosierujo por ĉiu ŝlosilo/valora paro difinita en la Sekreta objekto.
En nia ekzemplo, ni difinis nur unu ŝlosil-valoran paron nomitan magicWord, do la manifesto kreos ununuran nurlegeblan dosieron /secrets/magicWord kun sentemaj datumoj en la ujo.
Se vi aplikas ĉi tiun manifeston en la sama maniero kiel la antaŭa ekzemplo, vi devus ricevi la saman rezulton:
The magic word is "xyzzy"
Legante Sekretajn Objektojn
En la antaŭa sekcio, ni uzis la kubectl describe komandon por montri la enhavon de ConfigMap. Ĉu oni povas fari la samon kun Secret?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesBonvolu noti, ke la datumoj mem ne estas montrataj. Sekretaj objektoj en Kubernetes estas de tipo Opaque, kio signifas, ke ilia enhavo ne estas montrita en kubectl priskribi eligo, protokolaj enskriboj aŭ la terminalo, kio malebligas hazarde malkaŝi sentemajn informojn.
Por vidi koditan YAML-version de sentemaj datumoj, uzu la komandon kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebazo64
Kio estas eHl6enk=, tute malsama de nia origina valoro? Ĉi tio estas fakte Sekreta objekto, reprezentita en baz64-kodigo. Base64 estas skemo por kodi arbitrajn binarajn datenojn kiel ĉenon de signoj.
Ĉar sentemaj informoj povas esti binaraj kaj ne eligitaj (kiel estas la kazo kun TLS-ĉifrada ŝlosilo), Sekretaj objektoj ĉiam estas stokitaj en base64-formato.
La teksto beHl6enk= estas la bazo64 kodita versio de nia sekreta vorto xyzzy. Vi povas kontroli ĉi tion rulante la komandon base64 —decode en la terminalo:
echo "eHl6enk=" | base64 --decode
xyzzyDo, dum Kubernetes protektas vin kontraŭ hazarde eligo de sentemaj datumoj en la terminalo aŭ protokolaj dosieroj, se vi legis permesojn pri Sekretaj objektoj en specifa nomspaco, tiuj datumoj povas esti bazitaj kaj poste malkoditaj.
Se vi bezonas baz64-kodi iun tekston (ekzemple, por meti ĝin en Sekreton), uzu la base64-komandon sen argumentoj:
echo xyzzy | base64
eHl6enkKAliro al Sekretaj Objektoj
Kiu povas legi kaj redakti Sekretajn objektojn? Ĉi tio estas determinita de RBAC, mekanismo de alirkontrolo (ni priparolos ĝin detale en la subsekcio "Enkonduko al Rolbazita Alirkontrolo" sur paĝo 258). Se vi prizorgas areton kiu ne havas RBAC aŭ ne estas ebligita, ĉiuj viaj Sekretaj objektoj estas haveblaj al iuj uzantoj kaj ujoj (ni klarigos poste, ke vi ne havu iujn ajn produktadgrupojn sen RBAC).
Pasiva datuma ĉifrado
Kio pri tiuj, kiuj havas aliron al la etcd-datumbazo, kie Kubernetes konservas ĉiujn ĝiajn informojn? Ĉu ili povas legi sentemajn datumojn sen havi permeson legi Sekretajn objektojn per la API?
Ekde versio 1.7, Kubernetes subtenas pasivan datuman ĉifradon. Ĉi tio signifas, ke sentemaj informoj ene de etcd estas stokita ĉifrite sur disko kaj ne povas esti legita eĉ de tiuj kun rekta aliro al la datumbazo. Por deĉifri ĝin, vi bezonas ŝlosilon, kiun nur la Kubernetes API-servilo havas. En taŭge agordita areto, pasiva ĉifrado devus esti ebligita.
Vi povas kontroli ĉu pasiva ĉifrado funkcias en via areto jene:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Se vi ne vidas la flagon experimental-encryption-provider-config, pasiva ĉifrado ne estas ebligita. Kiam vi uzas Google Kubernetes Engine aŭ aliajn Kubernetes-administrajn servojn, viaj datumoj estas ĉifritaj per malsama mekanismo, do la flago ne ĉeestos. Kontrolu kun via Kubernetes-vendisto por vidi ĉu etcd-enhavo estas ĉifrita.
Stokado de konfidencaj datumoj
Estas kelkaj Kubernetes-resursoj, kiuj neniam devus esti forigitaj de la areto, kiel ekzemple tre sentemaj Sekretaj objektoj. Vi povas protekti rimedon kontraŭ forigo per komentario donita de la administranto de Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepSekretaj Objektaj Administradaj Strategioj
En la ekzemplo de la antaŭa sekcio, sentemaj datumoj estis protektitaj kontraŭ neaŭtorizita aliro tuj post esti konservitaj en la areto. Sed en manifestdosieroj ili estis konservitaj kiel simpla teksto.
Vi neniam devas meti konfidencajn informojn en dosierojn, kiuj estas en versio-kontrolo. Kiel vi povas sekure administri kaj konservi ĉi tiujn informojn antaŭ ol apliki ĝin al via Kubernetes-areo?
Vi povas elekti iujn ajn ilojn aŭ strategiojn por trakti sentemajn datumojn en viaj aplikoj, sed vi ankoraŭ devos respondi almenaŭ la sekvajn demandojn.
- Kie oni konservu sentemajn datumojn por ke ĝi estu tre alirebla?
- Kiel fari sentemajn datumojn alireblaj por viaj aktivaj aplikoj?
- Kio devus okazi al viaj aplikaĵoj kiam vi anstataŭigas aŭ redaktas sentemajn datumojn?
Pri aŭtoroj
Johano Arundel estas konsultisto kun 30-jara sperto en la komputila industrio. Li skribis plurajn librojn kaj laboras kun multaj kompanioj de malsamaj landoj, konsilante ilin pri nub-indiĝena infrastrukturo kaj Kubernetes. En sia libera tempo, li ĝuas surfadon, estas bona pistolpafisto, kaj ludas pianon kiel amatoro. Loĝas en fabeldometo en Cornwall, Anglio.
Justino Domingus - inĝeniero pri administrado de sistemoj laboranta en medio DevOps kun Kubernetes kaj nubaj teknologioj. Li ĝuas pasigi tempon ekstere, trinki kafon, krabi kaj sidi ĉe la komputilo. Loĝas en Seatlo, Vaŝingtono, kun mirinda kato kaj eĉ pli mirinda edzino kaj plej bona amiko, Adrienne.
» Pliaj detaloj pri la libro troveblas ĉe
»
»
Por Khabrozhiteley 25% rabato uzante kuponon - Kubernetoj
Post pago de la papera versio de la libro, elektronika libro estos sendita retpoŝte.
fonto: www.habr.com