ProHoster > Blogs > Administrācija > Par Kubernetes pieaugoŔo popularitāti

Par Kubernetes pieaugoŔo popularitāti

Sveiki, Habr!

Vasaras beigās vēlējamies atgādināt, ka turpinām strādāt pie tēmas Kubernetes un esam nolēmuÅ”i publicēt rakstu no Stackoverflow, kas atspoguļo situāciju Å”ajā projektā jÅ«nija sākumā.

Par Kubernetes pieaugoŔo popularitāti

Patīkamu lasīŔanu!

Raksta sagatavoÅ”anas brÄ«dÄ« Kubernetes vecums ir aptuveni seÅ”i gadi, un pēdējo divu gadu laikā tā popularitāte ir pieaugusi lÄ«dz tādam lÄ«menim, ka tā stabilākā ir starp visiem iecienÄ«tākajiem platformām. Å ajā gadā Kubernetes ieņem treÅ”o vietu. Atgādinām: Kubernetes ir platforma, kas paredzēta konteineru darba slodžu palaiÅ”anai un orÄ·estrācijai.

Konteineri radās kā Ä«paÅ”a konstrukcija procesu izolācijai Linux; konteineros kopÅ” 2007. gada ietilpst cgroups, bet kopÅ” 2002. gada ā€“ nosaukumu telpas. Konteineri attÄ«stÄ«jās vēl labāk lÄ«dz 2008. gadam, kad kļuva pieejama LXC, un Google izstrādāja savu iekŔējo mehānismu, kas saucas Borg, kur ā€žvisa darbÄ«ba notiek konteinerosā€. Pāriesim uz 2013. gadu, kad notika pirmais Docker izlaidums, un konteineri beidzot kļuva par populārām masveida risinājumiem. Tajā brÄ«dÄ« galvenais instruments konteineru orÄ·estrācijai bija Mesos, kaut gan tam nebija liela popularitāte. Pirmais Kubernetes izlaidums notika 2015. gadā, pēc kura Å”is rÄ«ks faktiski kļuva par standartu konteineru orÄ·estrācijā.

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ējoreiz izstrādātājiem izdevās vienoties par to, kā izvietot lietotnes ražoÅ”anā? Cik jÅ«s pazÄ«stat izstrādātāju, kuri izmanto rÄ«kus tādā veidā, kā tie tiek piegādāti ā€žno kārbasā€? Cik Å”odien ir tādu mākoņu administratoru, kuri nesaprot, kā darbojas lietotnes? Atbildes uz Å”iem jautājumiem mēs apskatÄ«sim Å”ajā rakstā.

Infrastruktūra kā YAML

Pasaulē, kas no Puppet un Chef pārgāja uz Kubernetes, viena no lielākajām pārmaiņām bija pāreja no ā€žinfrastruktÅ«ras kā kodsā€ uz ā€žinfrastruktÅ«ras kā datiā€ ā€” konkrēti, kā YAML. Visus resursus Kubernetes, kas ietver pods, konfigurācijas, izvietotie instanču, apjomi u.c., 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

Ar Ŕādu pieeju DevOps vai SRE speciālistiem ir ērtāk pilnÄ«bā izteikt savas darba slodzes, nepārkāpjot programmÄ“Å”anas valodu kā Python vai Javascript rakstÄ«Å”anu.

Citi datu infrastruktÅ«ras organizÄ“Å”anas ieguvumi ir Ŕādi:

  • GitOps vai Git Operations Version versiju kontrole. Šāda pieeja ļauj turēt visus Kubernetes YAML failus git repozitorijās, tādējādi jÅ«s precÄ«zi varat izsekot, kad tika veiktas izmaiņas, kurÅ” tās veica un kas tieÅ”i tika mainÄ«ts. Tas uzlabo organizācijas darÄ«jumu caurredzamÄ«bu, palielina efektivitāti novērÅ”ot neskaidrÄ«bas, kur darbiniekiem jāmeklē nepiecieÅ”amie resursi. Tajā paŔā laikā kļūst vieglāk automātiski veikt izmaiņas Kubernetes resursos ā€“ izmantojot parasto pieprasÄ«jumu apvienoÅ”anu.
  • MērogojamÄ«ba. Kad resursi ir definēti YAML formātā, klastera operatoriem kļūst ārkārtÄ«gi viegli mainÄ«t vienu vai divus skaitļus Kubernetes resursā, tādējādi mainot tā mērogoÅ”anas principus. Kubernetes ir paredzēta mehānika horizontālai automātiskai mērogoÅ”anai, kas ļauj ērti noteikt minimālo un maksimālo podu skaitu, kas nepiecieÅ”ams konkrētajai izvērsto konfigurācijai, lai tiktu galā ar zemu un augstu trafika lÄ«meni. Piemēram, ja esat izveidojis konfigurāciju, kurai nepiecieÅ”ama papildu jauda sakarā ar strauju trafika pieaugumu, jÅ«s varat mainÄ«t maxReplicas rādÄ«tāju 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 pārvaldÄ«ba. YAML ir lieliski piemērots, lai novērtētu, kā tiek izvērsti dažādi elementi Kubernetes. Piemēram, nopietna problēma, kas saistÄ«ta ar droŔības nodroÅ”ināŔanu, ir tā, vai jÅ«su darba slodzes tiek palaistas no lietotāja bez administratora tiesÄ«bām. Å ajā gadÄ«jumā mums var noderēt tādi rÄ«ki kā conftest, YAML/JSON validētājs, plus Open Policy Agent, politikas validētājs, kas ļauj pārliecināties, ka konteksts SecurityContext jÅ«su darba noslodzi neļauj konteineram darboties ar administratora privilēģijām. Ja tas nepiecieÅ”ams, lietotāji var ieviest vienkārÅ”u politiku rego, tāpat:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Konteinera nedrīkst darboties kā root"
}

  • Iespējas integrēties ar mākoņu pakalpojumu sniedzēju. Viens no acÄ«mredzamākajiem mÅ«sdienu augsto tehnoloÄ£iju virzieniem ir strādāt ar slodzēm publisko mākoņu pakalpojumu sniedzēju jaudā. Ar komponenta palÄ«dzÄ«bu cloud-provider Kubernetes ļauj ikvienam klasterim integrēties ar to mākoņu pakalpojumu sniedzēju, uz kura tas darbojas. Piemēram, ja lietotājs ir palaidis lietojumprogrammu Kubernetes uz AWS un vēlas atvērt piekļuvi Å”ai lietojumprogrammai, mākoņu pakalpojumu sniedzējs palÄ«dz automātiski izveidot pakalpojumu LoadBalancer, kas automātiski nodroÅ”inās slodzes balansētāju Amazon Elastic Load Balancer, lai novirzÄ«tu trafiku uz lietojumprogrammu podiem.

PaplaŔināmība

Kubernetes ļoti labi paplaÅ”inās, un tas patÄ«k izstrādātājiem. Pastāv komplekts esoÅ”o resursu, piemēram, podi, izvietojumi, StatefulSets, slepenie, ConfigMaps, utt. PatiesÄ«bā lietotāji un izstrādātāji var pievienot arÄ« citus resursus veidā pielāgoti resursu definÄ«cijas.

Piemēram, ja mēs vēlamies definēt resursu CronTab, mēs varētu darīt kaut ko līdzīgu:

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 aptuveni Ŕādā veidā:

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

Vēl viena paplaÅ”ināmÄ«bas iespēja Kubernetes ir izstrādātājs var rakstÄ«t savus operatorus. Operators ā€“ tas ir Ä«paÅ”s process Kubernetes klasterÄ«, kas darbojas pēc ā€žkontroles kontÅ«raā€œ parauga. Pateicoties operatoram, lietotājs var automatizēt CRD (pielāgoto resursu definÄ«ciju) pārvaldÄ«bu, apmainoties ar informāciju ar Kubernetes API.

Kopienā ir vairākas rÄ«ku, kas izstrādātājiem atvieglo savu operatoru izstrādi. Starp tiem ir Operator Framework un tā Operator SDK. Å is SDK nodroÅ”ina bāzi, no kuras izstrādātājs var ļoti ātri sākt veidot operatoru. Piemēram, to var sākt ar komandai no tās

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

Tādā veidā tiek izveidots viss raksturlielumu kods jūsu operatoram, tostarp YAML faili un kods 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.go

Pēc tam var pievienot nepiecieÅ”amos API un kontrolieri, Ŕādi:

$ 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 visfinally, salikt operatoru un augÅ”upielādēt to savā konteinera reÄ£istrā:

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

Ja izstrādātājam nepiecieÅ”ama vēl lielāka kontrole, tad var mainÄ«t raksturlielumu kodu failos, kas uzrakstÄ«ti Go valodā. Piemēram, lai izmainÄ«tu kontroliera specifiku, var veikt izmaiņas failā controller.go.

Vēl viens projekts, KUDO, ļauj veidot operatorus, izmantojot tikai deklaratÄ«vus YAML failus. Piemēram, operators Apache Kafka tiks definēts apmēram Ŕādi tā. Ar to var Ä«stenot tikai dažu komandu palÄ«dzÄ«bu, lai uzstādÄ«tu Kafka klasteri virs Kubernetes:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Un pēc tam to konfigurēt ar vēl vienu 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

Jaunumi

Pēdējo pāris gadu laikā lieli Kubernetes laidieni notiek ik pēc dažiem mēneÅ”iem ā€“ proti, trÄ«s vai četri lielie laidieni gadā. Jauno funkciju skaits, kas tiek iekļautas katrā no tiem, nemazinās. Turklāt pat mÅ«sdienās nav pazÄ«mju par palēnināŔanos ā€“ aplÅ«kojiet, kāda ir paÅ”reizējā Kubernetes projekta aktivitāte GitHub.

Jaunas iespējas ļauj elastÄ«gāk klasterizēt operācijas, ja ir dažādas darba slodzes. Turklāt programmētājiem patÄ«k pilnÄ«gāka kontrole, izvietojot lietojumprogrammas tieÅ”i ražoÅ”anā.

Kopiena

Vēl viens būtisks Kubernetes popularitātes aspekts ir tā kopienas spēks. 2015. gadā, kad tika sasniegta versija 1.0, Kubernetes tika sponsorēts Cloud Native Computing Foundation.

Tāpat pastāv dažādas kopienas SIG (speciālās intereÅ”u grupas), kuru mērÄ·is ir izstrādāt dažādas Kubernetes jomas, kamēr projekts attÄ«stās. Å Ä«s grupas pastāvÄ«gi pievieno jaunas iespējas, tādējādi padarot darbu ar Kubernetes ērtāku.

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

Turklāt Cloud Native Foundation ir Tehniskā uzraudzÄ«bas komiteja, kas kopā ar SIG vērtē jaunus un esoÅ”us projektus fondā, kas ir orientēti uz mākoņu ekosistēmu. Lielākā daļa no Å”iem projektiem palÄ«dz uzlabot Kubernetes stiprās puses.

Visbeidzot, es ticu, ka Kubernetes nebūtu guvis tādu panākumu bez apzinātiem visas kopienas centieniem, kur cilvēki atbalsta viens otru, bet vienlaikus ar prieku uzņem jaunpienācējus.

Nākotne

Viens no galvenajiem izaicinājumiem, ar kuriem nākotnē saskarsies izstrādātāji, ir spēja koncentrēties uz koda detaļām, nevis uz infrastruktÅ«ru, kurā tas darbojas. Å Ä«m tendencēm atbilst serverless arhitektÅ«ras paradigmas, kas Å”odien ir viena no vadoÅ”ajām. Jau pastāv attÄ«stÄ«tas ietvarstruktÅ«ras, piemēram, Knative un OpenFaas, kas izmanto Kubernetes, lai abstrahētu infrastruktÅ«ru no izstrādātāja.

Å ajā rakstā mēs tikai vispārÄ«gi apskatÄ«jām paÅ”reizējo Kubernetes stāvokli ā€“ patiesÄ«bā tas ir tikai aisberga virsotne. Lietotājiem Kubernetes ir pieejami arÄ« daudzi citi resursi, iespējas un konfigurācijas.

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster