Pozdravljeni, Habr!
Ob koncu poletja vas želimo spomniti, da nadaljujemo z delom na tej temi in se v začetku junija odločili objaviti članek iz Stackoverflowa, ki prikazuje stanje v tem projektu.
Uživajte v branju!
V času pisanja tega članka je starost Kubernetesa pribl. , v zadnjih dveh letih pa je njegova priljubljenost tako narasla, da se nenehno uvršča med platforme. Kubernetes je letos na tretjem mestu. Če povzamemo: Kubernetes je platforma, zasnovana za izvajanje in usmerjanje kontejnerskih delovnih obremenitev.
Vsebniki so se začeli kot posebna zasnova za izolacijo procesov v Linuxu; zabojniki so vključeni od leta 2007 , od leta 2002 pa – imenski prostori. Kontejnerji so bili do leta 2008, ko so bili na voljo, oblikovani še bolje , Google pa je razvil lasten interni korporativni mehanizem, imenovan , kjer "vse delo poteka v zabojnikih." Od tu naprej hitro naprej v leto 2013, ko je izšla prva izdaja Dockerja in so kontejnerji končno postali priljubljena množična rešitev. Takrat je bilo glavno orodje za orkestracijo kontejnerjev , čeprav ni bil tako priljubljen. Kubernetes je bil prvič izdan leta 2015, potem pa je to orodje postalo de facto standard na področju orkestracije vsebnikov.
Da bi poskušali razumeti, zakaj je Kubernetes tako priljubljen, poskušajmo odgovoriti na nekaj vprašanj. Kdaj se je nazadnje razvijalcem uspelo dogovoriti, kako uvesti aplikacije v produkcijo? Koliko razvijalcev poznate, ki uporabljajo orodja, kot so na voljo takoj po izdelavi? Koliko skrbnikov v oblaku je danes, ki ne razumejo delovanja aplikacij? Odgovore na ta vprašanja si bomo ogledali v tem članku.
Infrastruktura kot YAML
V svetu, ki je šel od Puppet in Chef do Kubernetesa, je bila ena največjih sprememb prehod od »infrastrukture kot kode« k »infrastrukturi kot podatku« – natančneje, kot je YAML. Vse vire v Kubernetesu, ki vključujejo pode, konfiguracije, nameščene instance, nosilce itd., je mogoče enostavno opisati v datoteki YAML. Na primer:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Ta pogled strokovnjakom za DevOps ali SRE olajša popolno izražanje svojih delovnih obremenitev, ne da bi morali pisati kodo v jezikih, kot sta Python ali Javascript.
Druge prednosti organizacije infrastrukture kot podatkov vključujejo:
- Nadzor različic GitOps ali Git Operations. Ta pristop vam omogoča, da vse datoteke Kubernetes YAML obdržite v repozitorijih git, tako da lahko natančno spremljate, kdaj je bila sprememba narejena, kdo jo je naredil in kaj točno se je spremenilo. To poveča preglednost delovanja v celotni organizaciji in izboljša operativno učinkovitost z odpravo dvoumnosti, zlasti tam, kjer naj zaposleni iščejo vire, ki jih potrebujejo. Hkrati postane lažje samodejno spreminjanje virov Kubernetes s preprosto združitvijo zahteve za vlečenje.
- Razširljivost. Ko so viri definirani kot YAML, postane operaterjem gruč izjemno enostavno spremeniti eno ali dve številki v viru Kubernetes in s tem spremeniti njegovo skaliranje. Kubernetes ponuja mehanizem za vodoravno samodejno skaliranje podov, ki ga je mogoče uporabiti za priročno določanje najmanjšega in največjega števila podov, potrebnih v določeni konfiguraciji uvajanja za obvladovanje nizkih in visokih ravni prometa. Na primer, če ste uvedli konfiguracijo, ki zahteva dodatno zmogljivost zaradi nenadnega skoka v prometu, potem lahko maxReplicas spremenite z 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- Varnost in upravljanje. YAML je odličen za ocenjevanje, kako so stvari nameščene v Kubernetesu. Na primer, glavni varnostni pomislek se nanaša na to, ali se vaše delovne obremenitve izvajajo kot neskrbniški uporabnik. V tem primeru bomo morda potrebovali orodja, kot je npr , validator YAML/JSON, plus , validator pravilnika, ki zagotavlja, da kontekst vaše delovne obremenitve ne dovoljujejo izvajanja vsebnika s skrbniškimi pravicami. Če je to potrebno, lahko uporabniki uporabijo preprost pravilnik , Všečkaj to:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Možnosti integracije s ponudnikom v oblaku. Eden najbolj opaznih trendov v današnji visoki tehnologiji je izvajanje delovnih obremenitev pri ponudnikih javnega oblaka. Uporaba komponente Kubernetes omogoča integracijo katere koli gruče s ponudnikom oblaka, na katerem deluje. Na primer, če uporabnik zažene aplikacijo v Kubernetesu na AWS in želi to aplikacijo izpostaviti prek storitve, ponudnik oblaka pomaga samodejno ustvariti storitev
LoadBalancerki bo samodejno zagotovil izravnavo obremenitve za preusmeritev prometa na sklope aplikacij.
Razširljivost
Kubernetes je zelo razširljiv in razvijalcem je všeč. Obstaja nabor razpoložljivih virov, kot so sklopi, uvajanja, StatefulSets, skrivnosti, ConfigMapsitd. Res je, uporabniki in razvijalci lahko v obrazec dodajo druge vire .
Na primer, če želimo definirati vir CronTab, potem bi lahko naredil nekaj takega:
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
Kasneje lahko ustvarimo vir CronTab nekaj takega:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Druga možnost za razširljivost v Kubernetesu je, da lahko razvijalec napiše lastne izjave. je poseben proces v gruči Kubernetes, ki deluje v skladu z" S pomočjo operaterja lahko uporabnik avtomatizira upravljanje CRD-jev (definicij virov po meri) z izmenjavo informacij z API-jem Kubernetes.
V skupnosti je na voljo več orodij, ki razvijalcem olajšajo ustvarjanje lastnih operaterjev. Med njimi - in . Ta SDK zagotavlja osnovo, iz katere lahko razvijalec hitro začne ustvarjati operater. Recimo, da lahko začnete z ukazno vrstico nekaj takega:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorS tem se ustvari vsa okvirna koda za vašega operaterja, vključno z datotekami YAML in kodo Golang:
.
|____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.goNato lahko dodate zahtevane API-je in krmilnik, kot je ta:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceNato končno sestavite operaterja in ga pošljite v register vašega vsebnika:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Če razvijalec želi še več nadzora, je mogoče spremeniti okvirno kodo v datotekah Go. Če želite na primer spremeniti posebnosti krmilnika, lahko spremenite datoteko controller.go.
Še en projekt , omogoča ustvarjanje stavkov z uporabo samo deklarativnih datotek YAML. Na primer, operator za Apache Kafka bi bil definiran približno . Z njim lahko namestite gručo Kafka na Kubernetes s samo nekaj ukazi:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaNato ga konfigurirajte z drugim ukazom:
$ 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
V zadnjih nekaj letih so večje izdaje Kubernetes izhajale vsakih nekaj mesecev – to je tri do štiri večje izdaje na leto. Število novosti, uvedenih v vsakem od njih, se ne zmanjšuje. Še več, tudi v teh težkih časih ni znakov upočasnjevanja – poglejte, kakšno je stanje zdaj .
Nove zmogljivosti vam omogočajo bolj prilagodljivo združevanje operacij v gruče med različnimi delovnimi obremenitvami. Poleg tega imajo programerji večji nadzor pri uvajanju aplikacij neposredno v proizvodnjo.
Skupnost
Drug pomemben vidik priljubljenosti Kubernetesa je moč njegove skupnosti. Leta 2015, ko je dosegel različico 1.0, je Kubernetes sponzoriral .
Obstajajo tudi različne skupnosti (Posebne interesne skupine) se je osredotočilo na delo na različnih področjih Kubernetesa, ko se projekt razvija. Te skupine nenehno dodajajo nove funkcije, zaradi česar je delo s Kubernetesom priročnejše in priročnejše.
Cloud Native Foundation gosti tudi CloudNativeCon/KubeCon, ki je v času pisanja največja odprtokodna konferenca na svetu. Običajno poteka trikrat letno in združuje na tisoče strokovnjakov, ki želijo izboljšati Kubernetes in njegov ekosistem ter se naučiti novih funkcij, ki se pojavijo vsake tri mesece.
Poleg tega ima Cloud Native Foundation , ki skupaj s SIG pregleduje nove in obstoječe sredstva, osredotočena na ekosistem v oblaku. Večina teh projektov pomaga izboljšati prednosti Kubernetesa.
Nenazadnje verjamem, da Kubernetes ne bi bil tako uspešen, kot je, brez zavestnega truda celotne skupnosti, kjer ljudje držijo skupaj, a hkrati pozdravljajo novince.
Prihodnost
Eden glavnih izzivov, s katerimi se bodo razvijalci morali soočiti v prihodnosti, je sposobnost osredotočanja na podrobnosti same kode in ne na infrastrukturo, v kateri se izvaja. Ustreza tem trendom , ki je danes ena vodilnih. Napredni okviri že obstajajo, npr. и , ki uporabljajo Kubernetes za abstrahiranje infrastrukture od razvijalca.
V tem članku smo le opraskali trenutno stanje Kubernetesa – pravzaprav je to le vrh ledene gore. Uporabniki Kubernetesa imajo na voljo številne druge vire, zmogljivosti in konfiguracije.
Vir: www.habr.com