Hej Habr!
Krajem ljeta želimo vas podsjetiti da nastavljamo raditi na ovoj temi te je početkom lipnja odlučio objaviti članak sa Stackoverflowa koji pokazuje stanje stvari u ovom projektu.
Uživajte u čitanju!
U vrijeme pisanja ovog članka, starost Kubernetesa je cca. , a tijekom posljednje dvije godine popularnost mu je toliko porasla da je stalno rangiran među platforme. Kubernetes je ove godine na trećem mjestu. Da rezimiramo: Kubernetes je platforma dizajnirana za pokretanje i upravljanje kontejnerskim radnim opterećenjem.
Spremnici su započeli kao poseban dizajn za izolaciju procesa u Linuxu; kontejneri uključeni od 2007 , a od 2002. – imenski prostori. Kontejneri su još bolje dizajnirani do 2008. godine, kada su postali dostupni , a Google je razvio vlastiti interni korporativni mehanizam tzv , gdje se "sav posao obavlja u kontejnerima." Odavde se vraćamo u 2013., kada je objavljeno prvo Dockerovo izdanje, a kontejneri su konačno postali popularno masovno rješenje. U to je vrijeme glavni alat za orkestraciju kontejnera bio , iako nije bio pretjerano popularan. Kubernetes je prvi put objavljen 2015., nakon čega je ovaj alat postao de facto standard u području orkestracije kontejnera.
Kako bismo razumjeli zašto je Kubernetes toliko popularan, pokušajmo odgovoriti na nekoliko pitanja. Kada su se zadnji put programeri uspjeli dogovoriti o tome kako implementirati aplikacije u proizvodnju? Koliko programera poznajete koji koriste alate koji su isporučeni odmah po isporuci? Koliko danas ima cloud administratora koji ne razumiju kako funkcioniraju aplikacije? Odgovore na ta pitanja pogledat ćemo u ovom članku.
Infrastruktura kao YAML
U svijetu koji je prešao put od Puppet and Chef do Kubernetesa, jedna od najvećih promjena bio je prijelaz s "infrastrukture kao koda" na "infrastrukturu kao podatke" — konkretno, poput YAML-a. Svi resursi u Kubernetesu, koji uključuju podove, konfiguracije, postavljene instance, volumene itd., mogu se jednostavno opisati u YAML datoteci. Na primjer:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Ovaj pogled olakšava stručnjacima za DevOps ili SRE da u potpunosti izraze svoja radna opterećenja bez potrebe za pisanjem koda na jezicima kao što su Python ili Javascript.
Ostale prednosti organizacije infrastrukture kao podataka uključuju:
- Kontrola verzije GitOps ili Git Operations. Ovaj pristup vam omogućuje da zadržite sve Kubernetes YAML datoteke u git spremištima, tako da možete pratiti kada je točno promjena napravljena, tko ju je napravio i što se točno promijenilo. Time se povećava transparentnost operacija u cijeloj organizaciji i poboljšava operativna učinkovitost eliminacijom dvosmislenosti, posebno u mjestima gdje zaposlenici trebaju tražiti resurse koji su im potrebni. U isto vrijeme, postaje lakše automatski napraviti promjene u Kubernetes resursima jednostavnim spajanjem zahtjeva za povlačenje.
- Skalabilnost. Kada su resursi definirani kao YAML, operaterima klastera postaje iznimno lako promijeniti jedan ili dva broja u Kubernetes resursu, čime se mijenja način na koji se skalira. Kubernetes pruža mehanizam za horizontalno automatsko skaliranje podova, koji se može koristiti za prikladno određivanje minimalnog i maksimalnog broja podova potrebnih u određenoj konfiguraciji implementacije za rukovanje niskim i visokim razinama prometa. Na primjer, ako ste postavili konfiguraciju koja zahtijeva dodatni kapacitet zbog iznenadnog porasta prometa, tada se maxReplicas može promijeniti s 10 na 20:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-deployment
minReplicas: 1
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50- Sigurnost i upravljanje. YAML je izvrstan za procjenu kako su stvari raspoređene u Kubernetesu. Na primjer, velika sigurnosna zabrinutost tiče se izvode li se vaša radna opterećenja kao korisnik koji nije administrator. U ovom slučaju, možda će nam trebati alati kao što su , YAML/JSON validator, plus , validator politike koji osigurava da kontekst vaša radna opterećenja ne dopuštaju rad spremnika s administratorskim ovlastima. Ako je to potrebno, korisnici mogu primijeniti jednostavnu politiku , kao ovo:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Mogućnosti integracije s pružateljem usluga u oblaku. Jedan od najznačajnijih trendova u današnjoj visokoj tehnologiji je pokretanje radnih opterećenja na pružateljima javnih oblaka. Korištenje komponente Kubernetes omogućuje bilo kojem klasteru integraciju s pružateljem usluga oblaka na kojem radi. Na primjer, ako korisnik pokrene aplikaciju u Kubernetesu na AWS-u i želi izložiti tu aplikaciju putem usluge, pružatelj usluga u oblaku pomaže u automatskom kreiranju usluge
LoadBalancerkoji će automatski osigurati balanser opterećenja za preusmjeravanje prometa na module aplikacija.
Proširivost
Kubernetes je vrlo proširiv i programeri ga vole. Postoji skup dostupnih resursa kao što su podovi, implementacije, StatefulSets, tajne, ConfigMapsitd. Istina, korisnici i programeri mogu dodati druge resurse u obrazac .
Na primjer, ako želimo definirati resurs CronTab, tada biste mogli učiniti nešto poput ovoga:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.my.org
spec:
group: my.org
versions:
- name: v1
served: true
storage: true
Schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
Kasnije možemo stvoriti CronTab resurs otprilike ovako:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Druga opcija za proširivost u Kubernetesu je da programer može napisati vlastite izjave. je poseban proces u Kubernetes klasteru koji radi prema "" Uz pomoć operatera, korisnik može automatizirati upravljanje CRD-ovima (prilagođenim definicijama resursa) razmjenom informacija s Kubernetes API-jem.
Postoji nekoliko alata u zajednici koji programerima olakšavaju stvaranje vlastitih operatora. Među njima - i . Ovaj SDK pruža temelj iz kojeg programer može brzo početi stvarati operator. Recimo da možete pokrenuti iz naredbenog retka nešto poput ovoga:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorOvo stvara sav šablonski kod za vašeg operatera, uključujući YAML datoteke i Golang kod:
.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.goZatim možete dodati potrebne API-je i kontroler, ovako:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceZatim, konačno, sastavite operator i pošaljite ga u registar vašeg spremnika:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Ako razvojni programer želi još veću kontrolu, standardni kod u Go datotekama može se promijeniti. Na primjer, da biste izmijenili specifičnosti kontrolera, možete unijeti izmjene u datoteku controller.go.
Još jedan projekt , omogućuje vam stvaranje izjava koristeći samo deklarativne YAML datoteke. Na primjer, operator za Apache Kafka bio bi približno definiran . Pomoću njega možete instalirati Kafka klaster na vrh Kubernetesa sa samo nekoliko naredbi:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaZatim ga konfigurirajte drugom naredbom:
$ kubectl kudo install kafka --instance=my-kafka-name
-p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181
-p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m
-p BROKER_COUNT=5 -p BROKER_MEM=4096m
-p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3
-p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20
inovacije
Tijekom proteklih nekoliko godina velika izdanja Kubernetesa izlazila su svakih nekoliko mjeseci - to jest, tri do četiri velika izdanja godišnje. Broj novih značajki uvedenih u svakom od njih ne smanjuje se. Štoviše, nema znakova usporavanja ni u ovim teškim vremenima - pogledajte kakva je situacija sada .
Nove mogućnosti omogućuju vam fleksibilnije grupiranje operacija u različitim radnim opterećenjima. Osim toga, programeri uživaju veću kontrolu kada postavljaju aplikacije izravno u proizvodnju.
Zajednica
Još jedan važan aspekt popularnosti Kubernetesa je snaga njegove zajednice. Godine 2015., nakon dostizanja verzije 1.0, Kubernetes je sponzorirao .
Postoje i razne zajednice (Grupe s posebnim interesima) usredotočene na rad na različitim područjima Kubernetesa kako se projekt razvija. Ove grupe neprestano dodaju nove značajke, čineći rad s Kubernetesom praktičnijim i praktičnijim.
Cloud Native Foundation također ugošćuje CloudNativeCon/KubeCon, koji je u vrijeme pisanja ovog teksta najveća konferencija otvorenog koda na svijetu. Obično se održava tri puta godišnje, a okuplja tisuće profesionalaca koji žele poboljšati Kubernetes i njegov ekosustav, kao i naučiti nove značajke koje se pojavljuju svaka tri mjeseca.
Štoviše, Cloud Native Foundation ima , koji zajedno sa SIG-ovima revidira nove i postojeće sredstva usmjerena na ekosustav oblaka. Većina ovih projekata pomaže u poboljšanju prednosti Kubernetesa.
Konačno, vjerujem da Kubernetes ne bi bio tako uspješan bez svjesnih napora cijele zajednice, gdje se ljudi drže zajedno, ali u isto vrijeme pozdravljaju pridošlice u okrilju.
Budućnost
Jedan od glavnih izazova s kojima će se programeri morati nositi u budućnosti je sposobnost da se usredotoče na detalje samog koda, a ne na infrastrukturu u kojoj se izvodi. Udovoljava ovim trendovima , koji je danas jedan od vodećih. Napredni okviri već postoje, npr. и , koji koriste Kubernetes za apstrahiranje infrastrukture od programera.
U ovom smo članku samo zagrebali po površini trenutnog stanja Kubernetesa—zapravo, to je samo vrh ledenog brijega. Korisnici Kubernetesa imaju na raspolaganju mnoge druge resurse, mogućnosti i konfiguracije.
Izvor: www.habr.com