Hallo Khabro inwoners! Kubernetes is een van die sleutelelemente van die moderne wolkekosisteem. Hierdie tegnologie bied betroubaarheid, skaalbaarheid en veerkragtigheid aan houervirtualisering. John Arundel en Justin Domingus praat oor die Kubernetes-ekosisteem en stel bewese oplossings vir alledaagse probleme bekend. Stap vir stap sal jy jou eie wolk-inheemse toepassing bou en die infrastruktuur skep om dit te ondersteun, 'n ontwikkelingsomgewing en 'n deurlopende ontplooiingspyplyn opstel wat jou sal help terwyl jy aan jou volgende toepassings werk.
• Begin met houers en Kubernetes uit die basiese beginsels: geen spesiale ondervinding word vereis om die onderwerp te leer nie. • Bestuur jou eie groepe of kies 'n bestuurde Kubernetes-diens van Amazon, Google, ens. • Gebruik Kubernetes om houerlewensiklus en hulpbronverbruik te bestuur. • Optimaliseer clusters gebaseer op koste, werkverrigting, veerkragtigheid, krag en skaalbaarheid. • Leer die beste gereedskap om jou toepassings te ontwikkel, toets en ontplooi. • Gebruik huidige bedryfspraktyke om sekuriteit en beheer te verseker. • Implementeer DevOps-beginsels regdeur jou maatskappy sodat ontwikkelingspanne meer buigsaam, vinnig en doeltreffend kan optree.
Vir wie is die boek?
Die boek is die mees relevant vir werknemers van administrasiedepartemente wat verantwoordelik is vir bedieners, toepassings en dienste, sowel as vir ontwikkelaars wat betrokke is by óf die bou van nuwe wolkdienste óf die migreer van bestaande toepassings na Kubernetes en die wolk. Moenie bekommerd wees nie, jy hoef nie te weet hoe om met Kubernetes of houers te werk nie - ons sal jou alles leer.
Ervare Kubernetes-gebruikers sal ook baie waarde vind, met in-diepte dekking van onderwerpe soos RBAC, deurlopende ontplooiing, sensitiewe databestuur en waarneembaarheid. Ons hoop dat die bladsye van die boek beslis iets interessants vir jou sal bevat, ongeag jou vaardighede en ervaring.
Watter vrae beantwoord die boek?
Terwyl ons die boek beplan en geskryf het, het ons wolktegnologie en Kubernetes met honderde mense bespreek en met bedryfsleiers en kundiges sowel as volledige beginners gepraat. Hieronder is geselekteerde vrae wat hulle graag in hierdie publikasie beantwoord wil sien.
- “Ek stel belang in hoekom jy tyd aan hierdie tegnologie moet spandeer. Watter probleme sal dit my en my span help om op te los?”
- “Kubernetes lyk interessant, maar het 'n redelik hoë toegangsgrens. Om 'n eenvoudige voorbeeld voor te berei is nie moeilik nie, maar verdere administrasie en ontfouting is skrikwekkend. Ons wil graag betroubare raad kry oor hoe mense Kubernetes-klusters in die regte wêreld bestuur en watter probleme ons waarskynlik sal teëkom.”
- “Subjektiewe advies sal nuttig wees. Die Kubernetes-ekosisteem gee nuwe spanne te veel opsies om van te kies. As daar verskeie maniere is om dieselfde ding te doen, hoe weet jy watter een die beste is? Hoe om 'n keuse te maak?
En miskien die belangrikste van alle vrae:
- "Hoe kan ek Kubernetes gebruik sonder om my maatskappy te ontwrig?"
Uittreksel. Konfigurasie en geheime voorwerpe
Die vermoë om die logika van 'n Kubernetes-toepassing van sy konfigurasie te skei (dit wil sê van enige waardes of instellings wat mettertyd kan verander) is baie nuttig. Konfigurasiewaardes sluit tipies omgewingspesifieke instellings, derdepartydiens-DNS-adresse en stawingbewyse in.
Dit alles kan natuurlik direk in die kode geplaas word, maar hierdie benadering is nie buigsaam genoeg nie. Byvoorbeeld, die verandering van 'n konfigurasiewaarde sal dan vereis dat jy jou kode weer moet bou en ontplooi. 'n Baie beter oplossing sou wees om die konfigurasie van die kode te skei en dit van 'n lêer of omgewingsveranderlikes te lees.
Kubernetes bied verskeie maniere om konfigurasie te bestuur. Eerstens kan u waardes aan die toepassing deurgee deur omgewingsveranderlikes wat in die peulomhulsel-spesifikasie gespesifiseer word (sien “Omgewingsveranderlikes” op bladsy 192). Tweedens kan konfigurasiedata direk in Kubernetes gestoor word deur gebruik te maak van ConfigMap en Secret voorwerpe.
In hierdie hoofstuk verken ons hierdie voorwerpe in detail en kyk na 'n paar praktiese benaderings tot die bestuur van konfigurasie en sensitiewe data met behulp van 'n demo-toepassing.
Dateer peuldoppe op wanneer konfigurasie verander
Stel jou voor dat jy 'n ontplooiing in jou groepering het en jy wil 'n paar waardes in die ConfigMap daarvan verander. As jy die Helm-kaart gebruik (sien "Helm: Pakketbestuurder vir Kubernetes" op bladsy 102), kan jy outomaties 'n konfigurasieverandering opspoor en jou peuldoppe herlaai in een netjiese truuk. Voeg die volgende aantekening by jou ontplooiingspesifikasie:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Die ontplooiingssjabloon bevat nou 'n kontrolesom van konfigurasieparameters: as die parameters verander word, sal die som opgedateer word. As jy stuurwielopgradering uitvoer, sal Helm bespeur dat die ontplooiingspesifikasie verander het en sal alle peuldoppe herbegin.
Sensitiewe data in Kubernetes
Ons weet reeds dat die ConfigMap-objek 'n buigsame meganisme bied vir die stoor en toegang tot konfigurasiedata in 'n groepering. Die meeste toepassings het egter inligting wat sensitief en sensitief is, soos wagwoorde of API-sleutels. Dit kan ook in ConfigMap gestoor word, maar hierdie oplossing is nie ideaal nie.
In plaas daarvan bied Kubernetes 'n spesiale tipe voorwerp wat ontwerp is om sensitiewe data te stoor: Geheim. Kom ons kyk vervolgens na 'n voorbeeld van hoe hierdie voorwerp in ons demo-toepassing gebruik kan word.
Om te begin, kyk na die Kubernetes-manifes vir die Geheime voorwerp (sien hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
In hierdie voorbeeld is die magicWord private sleutel xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Die woord xyzzy is oor die algemeen baie nuttig in die wêreld van rekenaars. Soortgelyk aan ConfigMap, kan jy verskeie sleutels en waardes in 'n geheime voorwerp stoor. Hier gebruik ons vir eenvoud slegs een sleutel-waarde-paar.
Gebruik geheime voorwerpe as omgewingsveranderlikes
Soos ConfigMap, kan die Geheime voorwerp in die houer beskikbaar gestel word as omgewingsveranderlikes of as 'n lêer op sy skyf. In die volgende voorbeeld sal ons 'n omgewingsveranderlike toewys aan die waarde van Secret:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordVoer die volgende opdrag in die demo-bewaarplek uit om die manifeste toe te pas:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" createdSoos voorheen, stuur die plaaslike poort aan na die ontplooiing om die resultaat in jou blaaier te sien:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888Wanneer 'n adres oopgemaak word :9999/ jy behoort die volgende te sien:
The magic word is "xyzzy"
Skryf van geheime voorwerpe na lêers
In hierdie voorbeeld sal ons die Geheime voorwerp as 'n lêer aan die houer heg. Die kode is geleë in die hello-secret-file-lêergids van die demo-bewaarplek.
Om Secret as 'n lêer te koppel, sal ons die volgende ontplooiing gebruik:
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-secretSoos in die onderafdeling "Skep konfigurasielêers vanaf ConfigMap-voorwerpe" op bl. 240, skep ons 'n volume (in hierdie geval demo-geheim-volume) en monteer dit op die houer in die volumeMounts-afdeling van die spesifikasie. Die mountPath-veld is /secrets, so Kubernetes sal een lêer in hierdie vouer skep vir elke sleutel/waarde-paar wat in die Geheime voorwerp gedefinieer is.
In ons voorbeeld het ons slegs een sleutel-waarde-paar genaamd magicWord gedefinieer, so die manifes sal 'n enkele leesalleen-lêer /secrets/magicWord met sensitiewe data in die houer skep.
As jy hierdie manifes op dieselfde manier as die vorige voorbeeld toepas, behoort jy dieselfde resultaat te kry:
The magic word is "xyzzy"
Lees Geheime Voorwerpe
In die vorige afdeling het ons die kubectl describe-opdrag gebruik om die inhoud van 'n ConfigMap te vertoon. Kan dieselfde gedoen word met Secret?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesNeem asseblief kennis dat die data self nie vertoon word nie. Geheime voorwerpe in Kubernetes is van die tipe Ondeursigtig, wat beteken dat hul inhoud nie gewys word in kubectl beskrywing van uitvoer, loginskrywings of die terminaal nie, wat dit onmoontlik maak om per ongeluk sensitiewe inligting te openbaar.
Om 'n geënkodeerde YAML-weergawe van sensitiewe data te sien, gebruik die kubectl get-opdrag:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebasis64
Wat is eHl6enk=, heeltemal anders as ons oorspronklike waarde? Dit is eintlik 'n geheime voorwerp, verteenwoordig in base64-kodering. Base64 is 'n skema vir die enkodering van arbitrêre binêre data as 'n string karakters.
Omdat sensitiewe inligting binêr kan wees en nie uitvoer nie (soos die geval is met 'n TLS-enkripsiesleutel), word Geheime voorwerpe altyd in base64-formaat gestoor.
Die teks beHl6enk= is die basis64-gekodeerde weergawe van ons geheime woord xyzzy. U kan dit verifieer deur die base64 —decode-opdrag in die terminaal uit te voer:
echo "eHl6enk=" | base64 --decode
xyzzyDus, terwyl Kubernetes jou beskerm teen die per ongeluk afvoer van sensitiewe data in die terminaal of loglêers, as jy leestoestemmings op Geheime voorwerpe in 'n spesifieke naamruimte het, kan daardie data gebaseer word en daarna gedekodeer word.
As jy 'n teks met base64 moet enkodeer (byvoorbeeld om dit in 'n geheim te plaas), gebruik die base64-opdrag sonder argumente:
echo xyzzy | base64
eHl6enkKToegang tot geheime voorwerpe
Wie kan geheime voorwerpe lees en redigeer? Dit word bepaal deur RBAC, 'n toegangsbeheermeganisme (ons sal dit in detail bespreek in die onderafdeling "Inleiding tot Rolgebaseerde Toegangsbeheer" op bladsy 258). As jy 'n kluster bestuur wat nie RBAC het nie of nie geaktiveer is nie, is al jou Geheime voorwerpe beskikbaar vir enige gebruikers en houers (ons sal later verduidelik dat jy geen produksieklusters sonder RBAC moet hê nie).
Passiewe data-enkripsie
Wat van diegene wat toegang het tot die etcd-databasis waar Kubernetes al sy inligting stoor? Kan hulle sensitiewe data lees sonder om toestemming te hê om Geheime voorwerpe via die API te lees?
Sedert weergawe 1.7 ondersteun Kubernetes passiewe data-enkripsie. Dit beteken dat sensitiewe inligting binne ensd geënkripteer op skyf gestoor word en nie eers deur diegene met direkte toegang tot die databasis gelees kan word nie. Om dit te dekripteer, benodig jy 'n sleutel wat net die Kubernetes API-bediener het. In 'n behoorlik gekonfigureerde groepering moet passiewe enkripsie geaktiveer word.
U kan op hierdie manier kyk of passiewe enkripsie in u groepering werk:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...As jy nie die eksperimentele-encryption-provider-config-vlag sien nie, is passiewe enkripsie nie geaktiveer nie. Wanneer u Google Kubernetes Engine of ander Kubernetes-bestuursdienste gebruik, word u data met 'n ander meganisme geïnkripteer, dus sal die vlag nie teenwoordig wees nie. Gaan met jou Kubernetes-verskaffer om te sien of ens-inhoud geïnkripteer is.
Berging van vertroulike data
Daar is 'n paar Kubernetes-hulpbronne wat nooit uit die groep verwyder moet word nie, soos hoogs sensitiewe Geheime voorwerpe. Jy kan 'n hulpbron beskerm teen uitgevee deur 'n aantekening wat deur die Helm-bestuurder verskaf word:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepGeheime voorwerpbestuurstrategieë
In die voorbeeld van die vorige afdeling is sensitiewe data teen ongemagtigde toegang beskerm onmiddellik nadat dit in die groep gestoor is. Maar in manifeslêers is hulle as gewone teks gestoor.
Jy moet nooit vertroulike inligting plaas in lêers wat in weergawebeheer is nie. Hoe kan jy hierdie inligting veilig bestuur en berg voordat jy dit op jou Kubernetes-kluster toepas?
Jy kan enige gereedskap of strategieë kies om sensitiewe data in jou toepassings te hanteer, maar jy sal steeds ten minste die volgende vrae moet beantwoord.
- Waar moet sensitiewe data gestoor word sodat dit hoogs toeganklik is?
- Hoe om sensitiewe data toeganklik te maak vir jou aktiewe toepassings?
- Wat moet met jou toepassings gebeur wanneer jy sensitiewe data vervang of wysig?
Oor die skrywers
John Arundel is 'n konsultant met 30 jaar ondervinding in die rekenaarbedryf. Hy het verskeie boeke geskryf en werk saam met baie maatskappye van verskillende lande en adviseer hulle oor wolk-infrastruktuur en Kubernetes. In sy vrye tyd geniet hy branderplankry, is 'n goeie pistoolskut en speel klavier as 'n amateur. Woon in 'n sprokieskothuis in Cornwall, Engeland.
Justin Domingus — stelseladministrasie-ingenieur wat in 'n DevOps-omgewing werk met Kubernetes en wolktegnologieë. Hy geniet dit om tyd in die buitelug deur te bring, koffie te drink, te krap en by die rekenaar te sit. Woon in Seattle, Washington, met 'n wonderlike kat en 'n nog wonderliker vrou en beste vriendin, Adrienne.
» Vir meer inligting oor die boek, besoek asseblief
»
»
Vir Khabrozhiteli 25% afslag op die koepon - Kubernetes
By betaling van die papierweergawe van die boek word 'n e-boek na die e-pos gestuur.
Bron: will.com