ProHoster > Blogs > Administrācija > Par Kubernetes popularitātes pieaugumu

Par Kubernetes popularitātes pieaugumu

Čau Habr!

Vasaras beigās vēlamies atgādināt, ka turpinām darbu pie tēmas Kubernetes un nolēma jÅ«nija sākumā publicēt Stackoverflow rakstu, kurā parādÄ«ta Ŕī projekta situācija.

Par Kubernetes popularitātes pieaugumu

Baudiet lasīŔanu!

Å Ä« raksta tapÅ”anas brÄ«dÄ« Kubernetes vecums ir apm. seÅ”us gadus vecs, un pēdējo divu gadu laikā tā popularitāte ir tik ļoti augusi, ka tā pastāvÄ«gi tiek ierindota starp vismīļākā platformas. Kubernetes Å”ogad ieņem treÅ”o vietu. Rezumējot: Kubernetes ir platforma, kas paredzēta konteinerizētu darba slodžu vadÄ«Å”anai un vadÄ«Å”anai.

Konteineri sākās kā Ä«paÅ”s dizains procesu izolÄ“Å”anai operētājsistēmā Linux; konteineri ir iekļauti kopÅ” 2007. gada grupas, un kopÅ” 2002. gada ā€“ vārdu telpas. Konteineri tika izstrādāti vēl labāk lÄ«dz 2008. gadam, kad tie kļuva pieejami LXC, un Google izstrādāja savu iekŔējo korporatÄ«vo mehānismu, ko sauc Borg, kur ā€œviss darbs tiek veikts konteinerosā€. No Å”ejienes mēs ātri virzāmies uz 2013. gadu, kad notika pirmā Docker izlaiÅ”ana, un konteineri beidzot kļuva par populāru masu risinājumu. Tolaik galvenais konteineru orÄ·estrÄ“Å”anas instruments bija Mesos, lai gan viņŔ nebija mežonÄ«gi populārs. Kubernetes pirmo reizi tika izlaists 2015. gadā, pēc tam Å”is rÄ«ks kļuva par de facto standartu konteineru orÄ·estrÄ“Å”anas jomā.

Lai mēģinātu saprast, kāpēc Kubernetes ir tik populārs, mēģināsim atbildēt uz dažiem jautājumiem. Kad pēdējo reizi izstrādātāji varēja vienoties par lietojumprogrammu izvietoÅ”anu ražoÅ”anā? Cik daudz izstrādātāju jÅ«s zināt, kuri izmanto rÄ«kus, kas tiek nodroÅ”ināti jau sākotnēji? Cik Å”odien ir mākoņu administratoru, kuri nesaprot, kā darbojas lietojumprogrammas? Atbildes uz Å”iem jautājumiem aplÅ«kosim Å”ajā rakstā.

Infrastruktūra kā YAML

Pasaulē, kas no Leļļu un Å”efpavāra pārgāja uz Kubernetes, viena no lielākajām izmaiņām bija pāreja no ā€œinfrastruktÅ«ras kā kodaā€ uz ā€œinfrastruktÅ«ru kā datiemā€ ā€” konkrēti, piemēram, YAML. Visus Kubernetes resursus, tostarp aplikumus, konfigurācijas, izvietotos gadÄ«jumus, sējumus utt., var viegli aprakstÄ«t YAML failā. Piemēram:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

Šis skats atvieglo DevOps vai SRE profesionāļiem, lai pilnībā izteiktu savu darba slodzi, nerakstot kodu tādās valodās kā Python vai Javascript.

Citas priekÅ”rocÄ«bas, organizējot infrastruktÅ«ru kā datus, ir Ŕādas:

  • GitOps vai Git Operations versiju kontrole. Å Ä« pieeja ļauj saglabāt visus Kubernetes YAML failus git krātuvēs, lai jÅ«s varētu precÄ«zi izsekot, kad tika veiktas izmaiņas, kas tās veica un kas tieÅ”i mainÄ«jās. Tas palielina darbÄ«bu caurspÄ«dÄ«gumu visā organizācijā un uzlabo darbÄ«bas efektivitāti, novērÅ”ot neskaidrÄ«bas, jo Ä«paÅ”i gadÄ«jumos, kad darbiniekiem jāmeklē nepiecieÅ”amie resursi. Tajā paŔā laikā kļūst vieglāk automātiski veikt izmaiņas Kubernetes resursos, vienkārÅ”i apvienojot izvilkÅ”anas pieprasÄ«jumu.
  • MērogojamÄ«ba. Ja resursi ir definēti kā YAML, klasteru operatoriem kļūst ārkārtÄ«gi viegli mainÄ«t vienu vai divus skaitļus Kubernetes resursā, tādējādi mainot tā mērogoÅ”anu. Kubernetes nodroÅ”ina mehānismu horizontālai podziņu automātiskai mērogoÅ”anai, ko var izmantot, lai ērti noteiktu minimālo un maksimālo aplikumu skaitu, kas ir nepiecieÅ”ams konkrētā izvietoÅ”anas konfigurācijā, lai apstrādātu zemu un augstu trafika lÄ«meni. Piemēram, ja esat izvietojis konfigurāciju, kurai nepiecieÅ”ama papildu jauda pēkŔņa trafika pieauguma dēļ, tad maxReplicas var mainÄ«t no 10 uz 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

  • DroŔība un vadÄ«ba. YAML ir lieliski piemērots, lai novērtētu, kā lietas tiek izvietotas Kubernetes. Piemēram, lielas droŔības problēmas ir saistÄ«tas ar to, vai jÅ«su darba slodzes darbojas kā lietotājs, kas nav administrators. Å ajā gadÄ«jumā mums var bÅ«t nepiecieÅ”ami tādi rÄ«ki kā konkurss, YAML/JSON validators, plus Atvērts politikas aÄ£ents, politikas apstiprinātājs, lai nodroÅ”inātu kontekstu DroŔības konteksts jÅ«su darba slodze neļauj konteineram darboties ar administratora privilēģijām. Ja tas ir nepiecieÅ”ams, lietotāji var piemērot vienkārÅ”u politiku ES lÅ«dzos, kā Å”is:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

  • Iespējas integrācijai ar mākoņa pakalpojumu sniedzēju. Viena no ievērojamākajām tendencēm mÅ«sdienu augsto tehnoloÄ£iju jomā ir slodzes izpilde publiskajos mākoņpakalpojumos. Komponenta izmantoÅ”ana mākoņa pakalpojumu sniedzējs Kubernetes ļauj jebkuram klasterim integrēties ar mākoņa nodroÅ”inātāju, kurā tas darbojas. Piemēram, ja lietotājs palaiž lietojumprogrammu Kubernetes pakalpojumā AWS un vēlas atklāt Å”o lietojumprogrammu, izmantojot pakalpojumu, mākoņa pakalpojumu sniedzējs palÄ«dz automātiski izveidot pakalpojumu. LoadBalancerkas automātiski nodroÅ”inās slodzes balansētāju Amazon elastÄ«gais slodzes balansētājslai novirzÄ«tu trafiku uz lietojumprogrammu blokiem.

PaplaŔināmība

Kubernetes ir ļoti paplaÅ”ināma, un izstrādātājiem tas patÄ«k. Ir pieejami vairāki resursi, piemēram, podi, izvietojumi, StatefulSets, noslēpumi, ConfigMapsutt. Tiesa, lietotāji un izstrādātāji veidlapā var pievienot citus resursus pielāgotas resursu definÄ«cijas.

Piemēram, ja mēs vēlamies definēt resursu CronTab, tad jÅ«s varētu rÄ«koties Ŕādi: 

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ēlāk mēs varam izveidot CronTab resursu, kas lÄ«dzÄ«gs Å”im:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

Vēl viena Kubernetes paplaÅ”ināŔanas iespēja ir tāda, ka izstrādātājs var rakstÄ«t savus paziņojumus. Operators ir Ä«paÅ”s process Kubernetes klasterÄ«, kas darbojas saskaņā ar ā€œvadÄ«bas ķēde" Ar operatora palÄ«dzÄ«bu lietotājs var automatizēt CRD (pielāgotu resursu definÄ«ciju) pārvaldÄ«bu, apmainoties ar informāciju ar Kubernetes API.

Kopienā ir vairāki rÄ«ki, kas ļauj izstrādātājiem viegli izveidot savus operatorus. Starp viņiem - Operatora sistēma un Operatora SDK. Å is SDK nodroÅ”ina pamatu, no kura izstrādātājs var ātri sākt operatora izveidi. Pieņemsim, ka varat sākt no komandrindas, piemēram:

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

Tādējādi tiek izveidots viss jūsu operatora standarta kods, tostarp YAML faili un Golang kods:

.
|____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.go

Pēc tam varat pievienot nepiecieÅ”amos API un kontrolieri, piemēram:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

Pēc tam, visbeidzot, salieciet operatoru un nosūtiet to uz sava konteinera reģistru:

$ operator-sdk build your.container.registry/youruser/myapp-operator

Ja izstrādātājs vēlas vēl lielāku kontroli, Go failos esoÅ”o pamatkodu var mainÄ«t. Piemēram, lai mainÄ«tu kontroliera specifiku, failā varat veikt izmaiņas controller.go.

Vēl viens projekts visur, ļauj izveidot paziņojumus, izmantojot tikai deklaratīvos YAML failus. Piemēram, operators Apache Kafka būtu definēts aptuveni tā. Ar to jūs varat instalēt Kafka klasteru Kubernetes virspusē, veicot tikai dažas komandas:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Un pēc tam konfigurējiet to, izmantojot citu komandu:

$ 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

Inovācijas

Dažu pēdējo gadu laikā galvenie Kubernetes izlaidumi ir iznākuÅ”i ik pēc dažiem mēneÅ”iem ā€” tas ir, trÄ«s lÄ«dz četri galvenie laidieni gadā. Katrā no tām ieviesto jauno funkciju skaits nesamazinās. Turklāt pat Å”ajos grÅ«tajos laikos nekas neliecina par bremzÄ“Å”anu ā€“ paskatieties, kāda ir situācija Å”obrÄ«d Kubernetes projekta darbÄ«ba vietnē Github.

Jaunās iespējas ļauj elastÄ«gāk grupēt darbÄ«bas dažādās darba slodzēs. Turklāt programmētājiem ir lielāka kontrole, izvietojot lietojumprogrammas tieÅ”i ražoÅ”anā.

Kopiena

Vēl viens svarÄ«gs Kubernetes popularitātes aspekts ir tās kopienas spēks. 2015. gadā, sasniedzot versiju 1.0, Kubernetes sponsorēja Mākoņu vietējās skaitļoÅ”anas fonds.

Ir arÄ« dažādas kopienas SIG (ÄŖpaÅ”u intereÅ”u grupas) koncentrējās uz darbu pie dažādām Kubernetes jomām, projektam attÄ«stoties. Å Ä«s grupas pastāvÄ«gi pievieno jaunas funkcijas, padarot darbu ar Kubernetes ērtāku un ērtāku.

Cloud Native Foundation rÄ«ko arÄ« CloudNativeCon/KubeCon, kas rakstÄ«Å”anas laikā ir lielākā atvērtā koda konference pasaulē. Parasti tas notiek trÄ«s reizes gadā, un tajā pulcējas tÅ«kstoÅ”iem profesionāļu, kuri vēlas uzlabot Kubernetes un tās ekosistēmu, kā arÄ« apgÅ«t jaunas funkcijas, kas parādās ik pēc trim mēneÅ”iem.

Turklāt Cloud Native Foundation ir Tehniskās uzraudzÄ«bas komiteja, kas kopā ar SIG apskata jaunos un esoÅ”os Projekti fondi, kas vērsti uz mākoņu ekosistēmu. Lielākā daļa Å”o projektu palÄ«dz uzlabot Kubernetes stiprās puses.

Visbeidzot, es uzskatu, ka Kubernetes nebÅ«tu tik veiksmÄ«gs, kā tas ir bez visas kopienas apzinātiem centieniem, kur cilvēki turas kopā, bet tajā paŔā laikā uzņem jaunpienācējus.

Nākotne

Viens no galvenajiem izaicinājumiem, kas izstrādātājiem bÅ«s jārisina nākotnē, ir spēja koncentrēties uz paÅ”a koda detaļām, nevis uz infrastruktÅ«ru, kurā tas darbojas. Tas atbilst Ŕīm tendencēm arhitektÅ«ras paradigma bez serveriem, kas Å”odien ir viens no vadoÅ”ajiem. Uzlaboti ietvari jau pastāv, piem. IzveicÄ«gs Šø OpenFaas, kas izmanto Kubernetes, lai abstrahētu infrastruktÅ«ru no izstrādātāja.

Å ajā rakstā mēs esam tikai saskrāpējuÅ”i paÅ”reizējo Kubernetes stāvokli ā€” patiesÄ«bā tā ir tikai aisberga redzamā daļa. Kubernetes lietotāju rÄ«cÄ«bā ir daudz citu resursu, iespēju un konfigurāciju.

Avots: www.habr.com

Pievieno komentāru