Knjiga “Kubernetes za DevOps”

Knjiga “Kubernetes za DevOps” Pozdrav, stanovnici Khabra! Kubernetes je jedan od ključnih elemenata modernog ekosustava oblaka. Ova tehnologija pruža pouzdanost, skalabilnost i otpornost na virtualizaciju spremnika. John Arundel i Justin Domingus govore o ekosustavu Kubernetes i predstavljaju provjerena rješenja za svakodnevne probleme. Korak po korak izgradit ćete svoju vlastitu aplikaciju izvornu u oblaku i stvoriti infrastrukturu koja će je podržavati, postaviti razvojno okruženje i kontinuirani cjevovod za implementaciju koji će vam pomoći u radu na vašim sljedećim aplikacijama.

• Započnite s kontejnerima i Kubernetesom od osnova: nije potrebno posebno iskustvo za učenje teme. • Pokrenite vlastite klastere ili odaberite upravljanu uslugu Kubernetes od Amazona, Googlea itd. • Koristite Kubernetes za upravljanje životnim ciklusom spremnika i potrošnjom resursa. • Optimizirajte klastere na temelju cijene, performansi, otpornosti, snage i skalabilnosti. • Naučite najbolje alate za razvoj, testiranje i implementaciju svojih aplikacija. • Iskoristite trenutnu praksu u industriji kako biste osigurali sigurnost i kontrolu. • Implementirajte DevOps principe u cijeloj tvrtki kako bi razvojni timovi mogli djelovati fleksibilnije, brže i učinkovitije.

Kome je knjiga namijenjena?

Knjiga je najrelevantnija za djelatnike administrativnih odjela odgovornih za poslužitelje, aplikacije i usluge, kao i za programere koji se bave izgradnjom novih usluga u oblaku ili migracijom postojećih aplikacija na Kubernetes i oblak. Ne brinite, ne morate znati raditi s Kubernetesom ili kontejnerima – mi ćemo vas svemu naučiti.

Iskusni korisnici Kubernetesa također će pronaći mnogo vrijednosti, s detaljnim pokrivanjem tema kao što su RBAC, kontinuirana implementacija, upravljanje osjetljivim podacima i mogućnost promatranja. Nadamo se da će se na stranicama knjige sigurno naći nešto zanimljivo za vas, bez obzira na vaše vještine i iskustvo.

Na koja pitanja knjiga odgovara?

Dok smo planirali i pisali knjigu, razgovarali smo o tehnologiji oblaka i Kubernetesu sa stotinama ljudi, razgovarajući s vodećima u industriji i stručnjacima, kao i s potpunim početnicima. Ispod su odabrana pitanja na koja bi željeli vidjeti odgovore u ovoj publikaciji.

  • “Zanima me zašto biste trebali trošiti vrijeme na ovu tehnologiju. Koje će probleme pomoći riješiti meni i mom timu?"
  • “Kubernetes se čini zanimljivim, ali ima prilično visoku prepreku za ulazak. Priprema jednostavnog primjera nije teška, ali daljnja administracija i otklanjanje pogrešaka je zastrašujuće. Željeli bismo dobiti pouzdan savjet o tome kako ljudi upravljaju Kubernetes klasterima u stvarnom svijetu i na koje ćemo probleme vjerojatno naići."
  • “Subjektivni savjeti bili bi od pomoći. Ekosustav Kubernetes daje novim timovima previše opcija za odabir. Kada postoji nekoliko načina da učinite istu stvar, kako znati koji je najbolji? Kako napraviti izbor?

I možda najvažnije od svih pitanja:

  • "Kako mogu koristiti Kubernetes bez ometanja svoje tvrtke?"

Izvod. Konfiguracija i tajni objekti

Mogućnost odvajanja logike Kubernetes aplikacije od njezine konfiguracije (to jest, od svih vrijednosti ili postavki koje se mogu promijeniti tijekom vremena) vrlo je korisna. Vrijednosti konfiguracije obično uključuju postavke specifične za okruženje, DNS adrese usluga trećih strana i vjerodajnice za provjeru autentičnosti.

Naravno, sve se to može staviti izravno u kod, ali ovaj pristup nije dovoljno fleksibilan. Na primjer, promjena konfiguracijske vrijednosti zahtijevala bi da ponovno izgradite i implementirate svoj kod. Mnogo bolje rješenje bilo bi odvojiti konfiguraciju od koda i pročitati je iz datoteke ili varijabli okoline.

Kubernetes nudi nekoliko različitih načina upravljanja konfiguracijom. Prvo, možete proslijediti vrijednosti aplikaciji putem varijabli okruženja navedenih u specifikaciji omotača kapsule (pogledajte “Varijable okruženja” na stranici 192). Drugo, konfiguracijski podaci mogu se pohraniti izravno u Kubernetes pomoću ConfigMap i Secret objekata.

U ovom poglavlju detaljno istražujemo te objekte i razmatramo neke praktične pristupe upravljanju konfiguracijom i osjetljivim podacima pomoću demo aplikacije.

Ažuriranje ljuski mahune kada se promijeni konfiguracija

Zamislite da imate implementaciju u svom klasteru i želite promijeniti neke vrijednosti u njegovoj ConfigMap. Ako koristite Helm grafikon (pogledajte “Helm: Upravitelj paketa za Kubernetes” na stranici 102), možete automatski detektirati promjenu konfiguracije i ponovno učitati svoje pod ljuske jednim zgodnim trikom. Dodajte sljedeću napomenu svojoj specifikaciji implementacije:

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

Predložak za implementaciju sada sadrži kontrolni zbroj konfiguracijskih parametara: ako se parametri promijene, zbroj će se ažurirati. Ako pokrenete helm nadogradnju, Helm će otkriti da se specifikacija postavljanja promijenila i ponovno će pokrenuti sve pod ljuske.

Osjetljivi podaci u Kubernetesu

Već znamo da objekt ConfigMap pruža fleksibilan mehanizam za pohranu i pristup konfiguracijskim podacima u klasteru. Međutim, većina aplikacija ima informacije koje su osjetljive i osjetljive, poput lozinki ili API ključeva. Također se može pohraniti u ConfigMap, ali ovo rješenje nije idealno.

Umjesto toga, Kubernetes nudi posebnu vrstu objekta dizajniranu za pohranu osjetljivih podataka: Secret. Zatim, pogledajmo primjer kako se ovaj objekt može koristiti u našoj demo aplikaciji.

Za početak pogledajte manifest Kubernetesa za tajni objekt (pogledajte hello-secret-env/k8s/secret.yaml):

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

U ovom primjeru, privatni ključ magicWorda je xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Riječ xyzzy općenito je vrlo korisna u svijetu računala. Slično ConfigMap-u, možete pohraniti više ključeva i vrijednosti u tajni objekt. Ovdje, radi jednostavnosti, koristimo samo jedan par ključ-vrijednost.

Korištenje tajnih objekata kao varijabli okruženja

Kao i ConfigMap, tajni objekt može biti dostupan u spremniku kao varijable okruženja ili kao datoteka na njegovom disku. U sljedećem primjeru dodijelit ćemo varijablu okruženja vrijednosti 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

Pokrenite sljedeću naredbu u demo repozitoriju da biste primijenili manifeste:

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

Kao i prije, proslijedite lokalni priključak implementaciji da vidite rezultat u svom pregledniku:

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

Prilikom otvaranja adrese localhost:9999/ trebali biste vidjeti sljedeće:

The magic word is "xyzzy"

Zapisivanje tajnih objekata u datoteke

U ovom ćemo primjeru tajni objekt priložiti spremniku kao datoteku. Kod se nalazi u mapi hello-secret-file demo repozitorija.

Da bismo povezali Secret kao datoteku, koristit ćemo sljedeću implementaciju:

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

Kao u pododjeljku “Stvaranje konfiguracijskih datoteka iz ConfigMap objekata” na str. 240, stvaramo volumen (u ovom slučaju demo-secret-volume) i montiramo ga na spremnik u odjeljku volumeMounts specifikacije. Polje mountPath je /secrets, tako da će Kubernetes stvoriti jednu datoteku u ovoj mapi za svaki par ključ/vrijednost definiran u Secret objektu.

U našem smo primjeru definirali samo jedan par ključ-vrijednost pod nazivom magicWord, tako da će manifest stvoriti jednu datoteku samo za čitanje /secrets/magicWord s osjetljivim podacima u spremniku.

Ako ovaj manifest primijenite na isti način kao prethodni primjer, trebali biste dobiti isti rezultat:

The magic word is "xyzzy"

Čitanje tajnih objekata

U prethodnom odjeljku koristili smo naredbu kubectl describe za prikaz sadržaja ConfigMapa. Može li se isto učiniti s Secretom?

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

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

Data
====
magicWord: 5   bytes

Imajte na umu da se sami podaci ne prikazuju. Tajni objekti u Kubernetesu su tipa Opaque, što znači da se njihov sadržaj ne prikazuje u kubectl describe izlazu, unosima dnevnika ili terminalu, što onemogućuje slučajno otkrivanje osjetljivih informacija.

Za pregled kodirane YAML verzije osjetljivih podataka upotrijebite naredbu kubectl get:

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

base64

Što je eHl6enk=, potpuno različito od naše izvorne vrijednosti? Ovo je zapravo tajni objekt, predstavljen u base64 kodiranju. Base64 je shema za kodiranje proizvoljnih binarnih podataka kao niza znakova.

Budući da osjetljive informacije mogu biti binarne i ne izlaze (kao što je slučaj s TLS ključem za šifriranje), tajni objekti uvijek se pohranjuju u base64 formatu.

Tekst beHl6enk= je base64 kodirana verzija naše tajne riječi xyzzy. To možete provjeriti pokretanjem naredbe base64 —decode u terminalu:

echo "eHl6enk=" | base64 --decode
xyzzy

Dakle, iako vas Kubernetes štiti od slučajnog ispisivanja osjetljivih podataka u terminalu ili datotekama dnevnika, ako imate dopuštenja za čitanje tajnih objekata u određenom prostoru imena, ti se podaci mogu bazirati na bazi 64 i naknadno dekodirati.

Ako trebate base64 kodirati neki tekst (na primjer, staviti ga u Secret), koristite base64 naredbu bez argumenata:

echo xyzzy | base64
eHl6enkK

Pristup tajnim objektima

Tko može čitati i uređivati ​​tajne objekte? To određuje RBAC, mehanizam kontrole pristupa (o tome ćemo detaljno govoriti u pododjeljku “Uvod u kontrolu pristupa temeljenu na ulogama” na stranici 258). Ako pokrećete klaster koji nema RBAC ili nije omogućen, svi vaši tajni objekti dostupni su svim korisnicima i spremnicima (kasnije ćemo objasniti da ne biste trebali imati proizvodne klastere bez RBAC-a).

Pasivna enkripcija podataka

Što je s onima koji imaju pristup etcd bazi podataka gdje Kubernetes pohranjuje sve svoje podatke? Mogu li čitati osjetljive podatke bez dopuštenja za čitanje tajnih objekata putem API-ja?

Od verzije 1.7, Kubernetes podržava pasivnu enkripciju podataka. To znači da su osjetljive informacije unutar etcd-a pohranjene šifrirane na disku i ne mogu ih pročitati čak ni oni s izravnim pristupom bazi podataka. Da biste ga dešifrirali, potreban vam je ključ koji ima samo Kubernetes API poslužitelj. U pravilno konfiguriranom klasteru, pasivna enkripcija bi trebala biti omogućena.

Na ovaj način možete provjeriti radi li pasivna enkripcija u vašem klasteru:

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

Ako ne vidite eksperimentalnu-encryption-provider-config oznaku, pasivna enkripcija nije omogućena. Kada koristite Google Kubernetes Engine ili druge Kubernetes usluge upravljanja, vaši su podaci šifrirani pomoću drugog mehanizma, tako da oznaka neće biti prisutna. Provjerite sa svojim dobavljačem Kubernetesa je li etcd sadržaj šifriran.

Pohranjivanje povjerljivih podataka

Postoje neki Kubernetes resursi koji se nikad ne bi trebali uklanjati iz klastera, poput vrlo osjetljivih tajnih objekata. Možete zaštititi resurs od brisanja korištenjem primjedbe koju daje Helm manager:

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

Tajne strategije upravljanja objektima

U primjeru iz prethodnog odjeljka osjetljivi podaci zaštićeni su od neovlaštenog pristupa odmah nakon pohranjivanja u klaster. Ali u datotekama manifesta bili su pohranjeni kao običan tekst.

Nikada ne biste trebali stavljati povjerljive informacije u datoteke koje su u kontroli verzija. Kako možete sigurno upravljati ovim informacijama i pohraniti ih prije nego što ih primijenite na svoj Kubernetes klaster?

Možete odabrati bilo koje alate ili strategije za rukovanje osjetljivim podacima u svojim aplikacijama, ali svejedno ćete morati odgovoriti barem na sljedeća pitanja.

  • Gdje bi trebali biti pohranjeni osjetljivi podaci kako bi bili visoko dostupni?
  • Kako učiniti osjetljive podatke dostupnima vašim aktivnim aplikacijama?
  • Što bi se trebalo dogoditi s vašim aplikacijama kada zamijenite ili uredite osjetljive podatke?

O autorima

John Arundel je konzultant s 30 godina iskustva u računalnoj industriji. Napisao je nekoliko knjiga i radi s mnogim tvrtkama iz različitih zemalja, savjetujući ih o infrastrukturi izvornoj u oblaku i Kubernetesu. U slobodno vrijeme bavi se surfanjem, dobar je pucač iz pištolja, a amaterski svira klavir. Živi u kućici iz bajke u Cornwallu u Engleskoj.

Justin Domingus — inženjer sistemske administracije koji radi u DevOps okruženju s Kubernetes i cloud tehnologijama. Voli provoditi vrijeme na otvorenom, piti kavu, loviti rakove i sjediti za računalom. Živi u Seattleu, Washington, s divnom mačkom i još divnijom ženom i najboljom prijateljicom, Adrienne.

» Više detalja o knjizi možete pronaći na web stranica izdavača
» pregled sadržaja
» Izvod

Za Khabrozhiteley 25% popusta korištenjem kupona - Kubernetes

Po uplati papirnate verzije knjige, elektronička knjiga bit će poslana e-mailom.

Izvor: www.habr.com

Dodajte komentar