Sveiki, Habr!
Vasaros pabaigoje norime priminti, kad temą tęsiame ir nusprendė birželio pradžioje paskelbti Stackoverflow straipsnį, kuriame demonstruojama šio projekto padėtis.
Mėgaukitės skaitymu!
Šio straipsnio rašymo metu Kubernetes amžius yra maždaug. , o per pastaruosius dvejus metus jo populiarumas išaugo tiek, kad jis nuolat patenka tarp platformos „Kubernetes“ šiemet užima trečią vietą. Apibendrinant: „Kubernetes“ yra platforma, skirta paleisti ir organizuoti konteinerinius darbo krūvius.
Konteineriai buvo sukurti kaip specialus procesų izoliavimo Linux sistemoje dizainas; konteineriai įtraukiami nuo 2007 m , o nuo 2002 m. – vardų erdves. Konteineriai buvo sukurti dar geriau iki 2008 m., kai jie tapo prieinami , o „Google“ sukūrė savo vidinį įmonės mechanizmą, vadinamą , kur „visas darbas atliekamas konteineriuose“. Nuo čia greitai pereiname į 2013 m., kai įvyko pirmasis „Docker“ išleidimas, o konteineriai pagaliau tapo populiariu masiniu sprendimu. Tuo metu pagrindinis konteinerių orkestravimo įrankis buvo , nors jis nebuvo beprotiškai populiarus. Kubernetes pirmą kartą buvo išleistas 2015 m., Po to šis įrankis tapo de facto standartu konteinerių orkestravimo srityje.
Norėdami suprasti, kodėl Kubernetes yra toks populiarus, pabandykime atsakyti į keletą klausimų. Kada paskutinį kartą kūrėjams pavyko susitarti, kaip įdiegti programas gamyboje? Kiek žinote kūrėjų, kurie naudoja įrankius, nes jie pateikiami iš karto? Kiek šiandien yra debesų administratorių, kurie nesupranta, kaip veikia programos? Šiame straipsnyje pažvelgsime į atsakymus į šiuos klausimus.
Infrastruktūra kaip YAML
Pasaulyje, kuris nuo „Puppet and Chef“ tapo „Kubernetes“, vienas didžiausių pokyčių buvo perėjimas nuo „infrastruktūros kaip kodo“ prie „infrastruktūros kaip duomenų“ – konkrečiai, kaip YAML. Visi „Kubernetes“ ištekliai, įskaitant paketus, konfigūracijas, įdiegtus egzempliorius, tomus ir kt., gali būti lengvai aprašyti YAML faile. Pavyzdžiui:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Šis rodinys palengvina „DevOps“ ar SRE specialistams visapusiškai išreikšti savo darbo krūvius, nereikia rašyti kodo tokiomis kalbomis kaip Python ar Javascript.
Kiti infrastruktūros, kaip duomenų, organizavimo pranašumai:
- „GitOps“ arba „Git Operations“ versijos valdymas. Šis metodas leidžia laikyti visus Kubernetes YAML failus git saugyklose, kad galėtumėte tiksliai sekti, kada buvo atliktas pakeitimas, kas jį atliko ir kas tiksliai pasikeitė. Tai padidina veiklos skaidrumą visoje organizacijoje ir pagerina veiklos efektyvumą pašalinant dviprasmybes, ypač ten, kur darbuotojai turėtų ieškoti jiems reikalingų išteklių. Tuo pačiu metu tampa lengviau automatiškai atlikti Kubernetes išteklių pakeitimus tiesiog sujungiant ištraukimo užklausą.
- Mastelio keitimas. Kai ištekliai apibrėžiami kaip YAML, klasterių operatoriams tampa labai lengva pakeisti vieną ar du skaičius Kubernetes išteklyje ir taip pakeisti jo mastelį. „Kubernetes“ suteikia horizontalaus automatinio modulių skalės nustatymo mechanizmą, kurį galima naudoti norint patogiai nustatyti, koks minimalus ir didžiausias priedų skaičius yra reikalingas tam tikroje diegimo konfigūracijoje, kad būtų galima valdyti mažą ir didelį srautą. Pavyzdžiui, jei įdiegėte konfigūraciją, kuriai reikia papildomos talpos dėl staigaus srauto padidėjimo, tada maxReplicas galima pakeisti iš 10 į 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- Saugumas ir valdymas. YAML puikiai tinka įvertinti, kaip viskas yra įdiegta Kubernetes. Pavyzdžiui, pagrindinis saugumo susirūpinimas yra susijęs su tuo, ar jūsų darbo krūviai vykdomi kaip ne administratorius. Tokiu atveju mums gali prireikti tokių įrankių kaip , YAML / JSON tikrintuvas ir plius , politikos patvirtinimo priemonė, užtikrinanti, kad kontekstas jūsų darbo krūviai neleidžia konteineriui paleisti su administratoriaus teisėmis. Jei to reikia, vartotojai gali taikyti paprastą politiką , kaip šitas:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Integravimo su debesų paslaugų teikėju parinktys. Viena ryškiausių šiuolaikinių aukštųjų technologijų tendencijų yra viešųjų debesijos paslaugų teikėjų darbo krūvis. Komponento naudojimas „Kubernetes“ leidžia bet kuriai klasteriui integruotis su debesies paslaugų teikėju, kuriame jis veikia. Pavyzdžiui, jei vartotojas paleidžia programą Kubernetes sistemoje AWS ir nori atskleisti tą programą naudodamas paslaugą, debesies paslaugų teikėjas padeda automatiškai sukurti paslaugą.
LoadBalancer, kuris automatiškai pateiks apkrovos balansavimo priemonę nukreipti srautą į programų rinkinius.
Išplečiamumas
„Kubernetes“ yra labai išplečiama ir kūrėjams tai patinka. Yra keletas galimų išteklių, pvz., paketų, diegimų, StatefulSets, paslaptys, ConfigMapsir kt. Tiesa, vartotojai ir kūrėjai formoje gali pridėti kitų išteklių .
Pavyzdžiui, jei norime apibrėžti išteklius CronTab, tada galite padaryti kažką panašaus:
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
Vėliau galime sukurti CronTab šaltinį, panašų į šį:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Kitas „Kubernetes“ išplėtimo variantas yra tai, kad kūrėjas gali parašyti savo pareiškimus. yra specialus procesas Kubernetes klasteryje, kuris veikia pagal „“ Operatoriaus pagalba vartotojas gali automatizuoti CRD (pasirinktinių išteklių apibrėžimų) valdymą, keisdamasis informacija su Kubernetes API.
Bendruomenėje yra keletas įrankių, leidžiančių kūrėjams lengvai sukurti savo operatorius. Tarp jų - ir . Šis SDK suteikia pagrindą, kuriuo remdamasis kūrėjas gali greitai pradėti kurti operatorių. Tarkime, galite pradėti nuo komandinės eilutės maždaug taip:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorTai sukuria visą jūsų operatoriaus pagrindinį kodą, įskaitant YAML failus ir 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.goTada galite pridėti reikiamas API ir valdiklį, pavyzdžiui:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceTada galiausiai surinkite operatorių ir nusiųskite jį į savo konteinerio registrą:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Jei kūrėjas nori dar daugiau kontrolės, Go failų pagrindinį kodą galima pakeisti. Pavyzdžiui, norėdami pakeisti valdiklio specifiką, galite pakeisti failą controller.go.
Kitas projektas , leidžia kurti teiginius naudojant tik deklaratyvius YAML failus. Pavyzdžiui, Apache Kafka operatorius būtų apibrėžtas apytiksliai . Su juo galite įdiegti Kafka klasterį Kubernetes viršuje naudodami tik keletą komandų:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaTada sukonfigūruokite jį kita komanda:
$ 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
Naujovės
Per pastaruosius kelerius metus pagrindiniai „Kubernetes“ leidimai buvo išleidžiami kas kelis mėnesius – tai yra, trys ar keturi pagrindiniai leidimai per metus. Kiekvienoje iš jų pristatomų naujų funkcijų skaičius nemažėja. Be to, net šiais sunkiais laikais nematyti jokių lėtėjimo ženklų – pažiūrėkite, kokia padėtis dabar .
Naujos galimybės leidžia lanksčiau sugrupuoti operacijas įvairiais darbo krūviais. Be to, programuotojai naudojasi didesne kontrole, kai programas diegia tiesiai į gamybą.
Bendruomenė
Kitas svarbus Kubernetes populiarumo aspektas yra jos bendruomenės stiprumas. 2015 m., pasiekus 1.0 versiją, Kubernetes rėmė .
Taip pat yra įvairių bendruomenių (Specialiųjų interesų grupės) projektui vystantis daugiausia dėmesio skyrė darbui įvairiose Kubernetes srityse. Šios grupės nuolat prideda naujų funkcijų, todėl darbas su Kubernetes tampa patogesnis ir patogesnis.
„Cloud Native Foundation“ taip pat rengia „CloudNativeCon“ / „KubeCon“, kuri tuo metu, kai buvo rašoma, yra didžiausia atvirojo kodo konferencija pasaulyje. Paprastai jis vyksta tris kartus per metus, jame susirenka tūkstančiai profesionalų, norinčių patobulinti „Kubernetes“ ir jos ekosistemą, taip pat išmokti naujų funkcijų, kurios pasirodo kas tris mėnesius.
Be to, „Cloud Native Foundation“ turi , kuri kartu su SIG peržiūri naujus ir esamus lėšų, skirtų debesų ekosistemai. Dauguma šių projektų padeda pagerinti Kubernetes pranašumus.
Galiausiai, manau, kad „Kubernetes“ nebūtų tokia sėkminga, kaip yra be sąmoningų visos bendruomenės pastangų, kur žmonės laikosi kartu, bet kartu priima naujokus į būrį.
Ateitis
Vienas iš pagrindinių iššūkių, kurį kūrėjai turės spręsti ateityje, yra galimybė sutelkti dėmesį į paties kodo detales, o ne į infrastruktūrą, kurioje jis veikia. Jis atitinka šias tendencijas , kuri šiandien yra viena iš pirmaujančių. Jau yra pažangių karkasų, pvz. и , kurie naudoja „Kubernetes“, kad atitrauktų infrastruktūrą iš kūrėjo.
Šiame straipsnyje mes tik subraižome dabartinės Kubernetes būklės paviršių – iš tikrųjų tai tik ledkalnio viršūnė. Kubernetes vartotojai turi daug kitų išteklių, galimybių ir konfigūracijų.
Šaltinis: www.habr.com