Book "Kubernetes for DevOps"

Salve, Khabro habitant! Kubernetes unum e elementis elementorum nubis modernae ecosystematis. Haec technicae artis constantiam, scalability et mollitiam virtualizationis continentis praebet. Ioannes Arundel et Iustinus Domingus de Kubernetes oecosystematis loquuntur et probatas solutiones ad problemata quotidiana introducunt. Gradatim, tuam applicationem nubem-nativam aedificabis et infrastructuram ad sustentandam creabis, ambitus evolutionis et continuum organum fistularum quae te adiuvabit ut in proximis applicationibus laboras.

• Incipias a vasis et Kubernetibus a fundamentis: nulla experientia specialis requiritur ad thema discendum. • Tuis racemis curre vel eligere servitium Kubernetes ab Amazone, Google etc. • Optimise botri secundum sumptus, effectus, mollitiam, potentiam et scalam. • Disce optima instrumenta evolvendi, experiendi, applicationes tuas explica. • Leverage industriae currentis exercitia ad securitatem et imperium obtinendum. • DevOps deducendi principia per totam societatem tuam ut iugis evolutionis mollius, velocius et efficacius agere possit.

Quis liber est?

Liber maxime pertinet ad ministrorum administrationis departments responsabiles servitores, applicationes et officia, ac etiam pro electronicis quae implicantur in vel novas nubeculas operas aedificandas vel applicationes ad Kubernetes et nubem migrantium existentes. Nolite solliciti esse, non opus est scire quomodo cum Kubernetibus vel vasis laborare — nos omnia te docebimus.

Utentes periti Kubernetes etiam multum valent, cum in profundis coverage locorum, ut RBAC, continua instruere, sensitivarum notitiarum administratione, et observabilitatem. Speramus paginas libri certissime continentes aliquid interesting pro te, cuiuscumque artes et experientiae tuae.

Quibus quaestionibus liber respondet?

Dum librum pararet et scriberet, technologiam technologiam et Kubernetes cum centenis hominibus tractavimus, loquendo cum industria ducum et peritorum necnon novitiorum completorum. Infra sunt quaestiones selectae quae in hac publicatione videre viderentur.

• "Im 'interested cur in hac technologia tempus terere debeas. Quae problemata adiuvabit me et meos equos solve?"
• “Kubernetes interesting videtur, sed satis altum impedimentum ad ingressum habet. Simplex exemplum parans non difficile est, at administratio et debuggatio ulterior constringit. Certum consilium accipere volumus quomodo homines Kubernetes ligaturas in mundo reali curent et quas difficultates occurrant verisimile est".
• "Subjective consilium utile esset. Kubernetes ecosystematis novas iunctiones nimis multas optiones eligendi dat. Cum pluribus modis idem facias, unde scis uter sit optimus? Quomodo eligendi?

Et fortasse potissima omnium quaestionum;

• "Quomodo uti possum Kubernetes sine comitatu meo perturbare?"

EXCERPTA. Configurationis et secreta obiecti

Facultas logicam applicationis Kubernetes separandi a sua configuratione (id est, ab aliquibus valoribus vel uncinis qui temporis mutationem possunt) valde utile est. Configurationis valores typice includunt ambitus speciales ordines, tertia pars muneris DNS inscriptiones et documentorum authenticas.

Utique haec omnia in codice directe poni possunt, sed accessus non satis flexibilis. Exempli causa, mutata configurationis valorem, te requiret ut codicem tuum denuo aedifices ac explicaveris. Multo melius solutio esset configurationem e codice separare et ex fasciculi vel ambitus variabilium legere.

Kubernetes pluribus modis ad configurationem administrandam praebet. Primum, valores transire potes in applicatione per variabilium variabilium in legumine specifationis folliculorum specificatarum (vide "Environment Variabiles" pag. 192). Secundo, notitia conformationis in Kubernetes directe condi potest utentibus Mando et obiectis secretis.

In hoc capite singula haec obiecta exploramus ac inspicimus aliquos accessus practicos ad configurationem administrandam ac sensitivas notitias adhibitis demo applicationis.

Conchis vasculum adaequationis cum configuratione mutationes

Finge te in botro tuo instruere et vis aliquos valores in Mando mutare. Si chartula Helm uteris (vide "Helm: Sarcina Procurator Kubernetes" in pagina 102), automatice figuram mutationem deprehendere potes et vasculum conchas in uno stropha nitida repone. Hanc annotationem adde tuam specificationem instruere:

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

Formulae instruere nunc checksum parametri configurationis continet: si moduli mutentur, summa renovabitur. Si galeam upgrade curris, Helm deprehendet speciem instruere mutatam esse et omnes conchas vasculi sileo.

Sensitiva data in Kubernetes

Iam scimus rem Mificam obiecto flexibilem mechanismum praebere ad condenda et accessurae figurae notitias in botro. Maxime autem applicationes informationes habent sensitivas et sensitivas, sicut passwords vel clavium API. ConfigMap etiam condi potest, sed haec solutio non est idealis.

Instead, Kubernetes specialem obiecti speciem praebet ad notitias sensitivas reponendas: Secret. Deinde inspiciamus exemplum quomodo hoc obiectum in applicatione nostra demoli possit adhiberi.

Ut incipias, inspice Kubernetes manifesto ob obiectum secreti (vide salve-secretum-env/k8s/secret.yaml);

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

In hoc exemplo, magicaeWord clavis privatae xyzzy est (en.wikipedia.org/wiki/Xyzzy_ (computatio)). Verbum xyzzy in mundo computatoriorum plerumque perutile est. Similes ConfigMap, plures claves et valores in obiecto Secreto reponere potes. Hic, ad simplicitatem, una tantum par pretii clavis utimur.

Usura secreta obiecta Opera Variabiles

Sicut ConfigMap, Obiectum Secretum praesto esse potest in vase sicut variabiles ambitus vel fasciculus in disco. In hoc exemplo, ambitum variabilem valori ex Secretis ponemus:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

Praeceptum sequens currite in promptuario demo ad manifestationes applicandas;

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created

Ut ante, portum localem ad instruere eventum in navigatro tuo videre:

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

Cum agemus electronica localhost: 9999 / debes videre quae sequuntur:

The magic word is "xyzzy"

Scribo occulta obiecta tabularia

Hoc exemplo obiecto Secretum tanquam fasciculum continenti apponemus. Codex in repositorio secretorum fasciculi folder democratis collocatur.

Secretum coniungere ut fasciculum, sequenti instruere utemur:

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

Ut in ordine "configurationem imaginum creans objecta MapMap" pag. 240, volumen (in hoc casu demo-secreto-volumen) creamus et eum ad continens in sectione specificationis voluminis conscendimus. Agro MontisPath secreta est, ergo Kubernetes unum fasciculum creabit in hoc folder pro singulis clavis/pretii par in objecto Secreto definito.

In exemplo nostro definivimus solum unum par valoris, qui magicWord vocatus est, ut manifestum creabit unum solum lecturum fasciculum /secreta/magicWord cum sensitiva notitia in continente.

Hoc si eodem modo quo exemplo praecedens manifestam applicaveris, eundem eventum habere debeas;

The magic word is "xyzzy"

Lectio secreta obiecta

In sectione superiore, mandatum kubectl describentes usi sumus ut contenta in ConfigMap proponeret. Idemne fieri potest cum Secretis?

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

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

Data
====
magicWord: 5   bytes

Lorem ipsum data non ostenditur. Occulta secreta in Kubernetes speciei Opacae sunt, quae significat eorum contenta in kubectl descripto output, log viscusrum, vel terminales, non demonstrant, quod impossibile est ut notitias sensitivas accidentaliter revelare.

Ad inspiciendam versionem notatam sensitivam YAML encoded, uti mandatum kubectl obtine;

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

base64

Quid est eHl6enk=, prorsus diversum ab originali nostro valore? Hoc est actu Secretum obiectum, quod in basi64 descriptam repraesentat. Base64 est schema delatam arbitrariam datam binariam sicut filum characterum.

Quia notitia sensitiva potest esse binaria et non formata (sicut fit cum clavis encryptionis TLS), secreta obiecta semper in forma base 64 reponuntur.

Textus beHl6enk= est base64 inscripta versio verbi secreti nostri xyzzy. Hoc cognoscere potes per currendo base64 -decode imperium in termino:

echo "eHl6enk=" | base64 --decode
xyzzy

Itaque, dum Kubernetes te protegit ne sensitiva notitia in terminali vel stipes lima, si permissiones de obiectis secretis in speciali nomine spatii legisti, notitias fundari et postea decoctas esse possit.

Si opus est ut base64 aliquam textum encode (exempli gratia, illud in Secreto ponere), basis64 sine argumentis praecepto utere:

echo xyzzy | base64
eHl6enkK

Accessing secreta obiecta

Quis legere et obiecta secreta recensere potest? Hoc determinatur per RBAC, accessum ad mechanismum moderandum (de eo singillatim disseremus in ordine "Introductio ad Partem Ex Access Imperium" pag 258). Si curris botrum qui RBAC non habet vel non datur, omnia objecta Secretorum tuis usoribus et vasis praesto sunt (postea explicabimus quod racemi sine RBAC productione non debent).

Passivum encryption notitia

Quid de illis qui ad datorum etc. aditum habent, ubi Kubernetes omnem suam informationem reponit? Possuntne notitias sensitivas legere sine licentia legere secreta per API?

Cum versione 1.7, Kubernetes encryptionem passivam dat. Hoc significat sensitiva informationes intra etcd in disco encryptas conditas esse et etiam ab iis legi non posse cum accessu directo ad datorum aditum. Ad minuendum illud, clavis opus est ut solum Kubernetes API servo suo habeat. In botro rite figurato, encryption passivum praestari debet.

Potes reprehendo si encryption passivum operatur in botro tuo hoc modo:

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

Si vexillum experimentum-encryption-provisor-mando non vides, encryption passivum non para. Cum Engine utens Google Kubernetes vel alia officia administrationis Kubernetes, notitia tua diversis mechanism utens encryptatur, ergo vexillum praesens non erit. Reprehendo cum venditore Kubernetti tuo vide an contentum etcd encryptum sit.

Secretum repono notitia

Sunt nonnullae facultates Kubernetes quae numquam ab botro removendae sunt, sicut objecta secreta sensitiva. Subsidiam tueri potes ne deleta sit utens annotatione a procuratore Helm:

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

Secret Object Management Strategies

In exemplo ex sectione praecedente, notitia sensitiva ab accessu legitimo statim post in botro conservata est. Sed in manifestis scriniis reposita sunt ut patet in textu.

Numquam secretiores notitias in scriniis qui in versione potestate collocare debes. Quomodo tu secure dispones et haec informationes repone antequam eam applicando tuo Kubernetes botro?

Quaelibet instrumenta vel consilia eligere potes ad notitias sensitivas tractandas in tuis applicationibus, sed etiam sequentibus quaestionibus respondere debes.

• Ubinam notitia sensitiva debet recondi ut valde sit pervia?
• Quomodo sensitiva notitia accessibilis ad applicationes activas tuas?
• Quid accidat applicationibus tuis, cum sensitivas notitias repone vel recensere?

De auctoribus

Ioannes Arundell consultus est cum 30 annis experientiae in industria computatrum. Plures libros et opera conscripsit cum multis societatibus e diversis nationibus, eos in infrastructura nubis nativa et Kubernetes monens. Suo libero tempore, superficies fruitur, pistol surculus bonus est, et amateur ludit. Habitat in fairytale casale Cornubiae in Anglia.

Justin Domingus - systemata administrationis architecti operantis in ambitu DevOps cum Kubernetes et technologiae nubilo. Foris commoratus, potione capulus, crabro, ac sedente ad computatorium fruitur. Habitat in Seattle, Washington, cum fele mira et mirabiliore uxore et amicissimo Adrienne.

» Pro maiori de libro, quaeso, visita publisher's website
» mensam de contentis in eodem
» Excerpt

Nam Khabrozhiteli XXV% discount in coupon - Kubernetes

Post solutionem chartae versio libri, electronica mittitur ad electronicam.

Source: www.habr.com