ProHoster > Blog > Administrim > Për popullaritetin në rritje të Kubernetes

Për popullaritetin në rritje të Kubernetes

Përshëndetje, Habr!

Në fund të verës, dëshirojmë të kujtojmë se po vazhdojmë me punën e temës Kubernetes dhe vendosëm të publikojmë një artikull nga Stackoverflow që tregon gjendjen e projektit në fillim të qershorit.

Për popullaritetin në rritje të Kubernetes

Lexim të këndshëm!

Në momentin e shkruarjes së këtij artikulli, mosha e Kubernetes është rreth gjashtë vjet, dhe në dy vitet e fundit popullariteti i tij është rritur aq shumë sa që ai vazhdimisht është në mesin e platformave më të dashura. Këtë vit, Kubernetes zë vendin e tretë. Kujtojmë: Kubernetes është një platformë e destinuar për të drejtuar dhe orkestruar ngarkesat pune në konteiner.

Konteinerët kanë lindur si një strukturë e veçantë për izolimin e proceseve në Linux; që nga viti 2007 ata përmbajnë cgroups, dhe që nga viti 2002 - hapësirat emërtuese. Konteinerët u formuan edhe më mirë në vitin 2008, kur u bë e disponueshme LXC, dhe në Google zhvilluan një mekanizëm të brendshëm të quajtur Borg, ku "të gjithë punët bëhen në konteinerë". Nga aty do të kalojmë në vitin 2013, kur u publikua versioni i parë i Docker, dhe konteinerët kaluan përfundimisht në kategorinë e zgjidhjeve popullore masive. Në atë kohë, mjeti kryesor për orkestrimin e konteinerëve ishte Mesos, megjithatë ai nuk gëzonte popullaritet të madh. Publikimi i parë i Kubernetes ndodhi në vitin 2015, pas të cilit ky mjet në fakt u bë standard në fushën e orkestrimit të konteinerëve.

PĂ«r tĂ« pĂ«rpiquar tĂ« kuptojmĂ« se pĂ«rse Kubernetes Ă«shtĂ« kaq i populllar, le tĂ« pĂ«rpiqemi tĂ« pĂ«rgjigjemi nĂ« disa pyetje. Kur ishte hera e fundit qĂ« zhvilluesit arritĂ«n tĂ« binin dakord pĂ«r mĂ«nyrĂ«n e shpĂ«rndarjes sĂ« aplikacioneve nĂ« prodhim? Sa zhvillues njohni qĂ« pĂ«rdorin mjetet nĂ« formĂ«n siç ofrohen "nga kuti"? Sa administratorĂ« cloud keni sot qĂ« nuk e kuptojnĂ« se si funksionojnĂ« aplikacionet? PĂ«rshtypjet pĂ«r kĂ«to pyetje do t’i shqyrtojmĂ« nĂ« kĂ«tĂ« artikull.

Infrastruktura si YAML

NĂ« njĂ« botĂ« qĂ« kaloi nga Puppet dhe Chef pĂ«r nĂ« Kubernetes, njĂ« nga ndryshimet mĂ« tĂ« mĂ«dha ishte kalimi nga "infrastruktura si kod" nĂ« "infrastruktura si tĂ« dhĂ«na" — konkretisht, si YAML. TĂ« gjitha burimet nĂ« Kubernetes, qĂ« pĂ«rfshijnĂ« pod-et, konfigurimet, instancat e shpĂ«rndara, vjetĂ«t dhe tĂ« tjera, mund tĂ« pĂ«rshkruhen lehtĂ«sisht nĂ« njĂ« skedĂ« YAML. PĂ«r shembull:

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

Me një prezantim të tillë, specialistëve të DevOps ose SRE u lehtësohet të shprehin plotësisht ngarkesat e punës së tyre, pa pasur nevojë të shkruajnë kod programimi në gjuhë si Python ose Javascript.

Avantazhet e tjera të organizimit të infrastrukturës së të dhënave, veçanërisht, janë si më poshtë:

  • GitOps ose versionimi i operacioneve Git. Ky qasje lejon mbajtjen e tĂ« gjithĂ« skedarĂ«ve YAML tĂ« Kubernetes nĂ« depo git, duke mundĂ«suar tĂ« gjurmohet saktĂ«sisht se kur Ă«shtĂ« bĂ«rĂ« njĂ« ndryshim, kush e bĂ«ri atĂ« dhe çfarĂ« ka ndryshuar. KĂ«tu rritet transparenca e operacioneve brenda tĂ«rĂ« organizatĂ«s, dhe rritet efikasiteti nĂ«pĂ«rmjet eliminimit tĂ« paqartĂ«sive, veçanĂ«risht nĂ« lidhje me vendndodhjen e burimeve qĂ« kĂ«rkojnĂ« punonjĂ«sit. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, bĂ«het mĂ« e lehtĂ« qĂ« tĂ« bĂ«hen ndryshime automatike nĂ« burimet e Kubernetes - pĂ«rmes bashkimit tĂ« zakonshĂ«m tĂ« kĂ«rkesave pĂ«r tĂ«rheqje.
  • ShkallĂ«zueshmĂ«ria. Kur burimet janĂ« tĂ« definuara nĂ« formĂ« YAML, operatorĂ«ve tĂ« grumbullit u bĂ«het jashtĂ«zakonisht e lehtĂ« tĂ« ndryshojnĂ« njĂ« ose dy numra nĂ« burimin Kubernetes, duke ndryshuar kĂ«shtu parimet e shkallĂ«zimit tĂ« tij. Kubernetes ka njĂ« mekanizĂ«m pĂ«r automatik shkallĂ«zimin horizontal tĂ« pod-eve, me anĂ« tĂ« tĂ« cilit pĂ«rcaktohet lehtĂ«sisht se cili Ă«shtĂ« numri minimal dhe maksimal i pod-eve qĂ« nevojiten nĂ« njĂ« konfigurim tĂ« caktuar tĂ« implementuar, pĂ«r tĂ« pĂ«rballuar nivele tĂ« ulĂ«ta dhe tĂ« larta tĂ« trafikut. PĂ«r shembull, nĂ«se keni implementuar njĂ« konfigurim pĂ«r tĂ« cilin kĂ«rkohen kapacitete shtesĂ« pĂ«r shkak tĂ« njĂ« shpĂ«rthimi tĂ« papritur tĂ« trafikut, atĂ«herĂ« treguesi maxReplicas mund tĂ« ndryshohet nga 10 nĂ« 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

  • Siguria dhe menaxhimi. YAML Ă«shtĂ« njĂ« format i shkĂ«lqyer pĂ«r tĂ« vlerĂ«suar se si implementohen gjĂ«rat nĂ« Kubernetes. PĂ«r shembull, njĂ« problem serioz i sigurisĂ« lidhet me faktin nĂ«se ngarkesat tuaja tĂ« punĂ«s ekzekutohen nga njĂ« pĂ«rdorues pa privilegje administratorĂ«sh. NĂ« kĂ«tĂ« rast, mjetet si conftest, validues i YAML/JSON, pĂ«rveç Open Policy Agent, validues politikash, qĂ« siguron se konteksti SecurityContext ngarkat e punĂ«s suaj nuk i lejojnĂ« kontejnerit tĂ« punojĂ« me privilegje administratori. NĂ«se kjo kĂ«rkohet, pĂ«rdoruesit mund tĂ« zbatojnĂ« njĂ« politikĂ« tĂ« thjeshtĂ« rego, ndryshe kĂ«shtu:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Kontejnerët nuk duhet të punojnë si root"
}

  • Opsionet e integrimit me ofruesin e cloud. NjĂ« nga tendencat mĂ« tĂ« dukshme nĂ« teknologjitĂ« moderne Ă«shtĂ« tĂ« запусĐșаш ngarkesat e punĂ«s nĂ« kapacitetet e ofruesve publikĂ« tĂ« cloud. Me ndihmĂ«n e komponentit cloud-provider Kubernetes lejon çdo klaster tĂ« integrohet me ofruesin e cloud me tĂ« cilin punon. PĂ«r shembull, nĂ«se njĂ« pĂ«rdorues ka nisur njĂ« aplikacion nĂ« Kubernetes nĂ« AWS dhe dĂ«shiron tĂ« hapĂ« qasje nĂ« kĂ«tĂ« aplikacion pĂ«rmes njĂ« shĂ«rbimi, ofruesi i cloud ndihmon automatikisht nĂ« krijimin e njĂ« shĂ«rbimi LoadBalancer, i cili do tĂ« ofrojĂ« automatikisht njĂ« balancues ngarkese Amazon Elastic Load Balancer, pĂ«r tĂ« shpĂ«rndarĂ« trafikun nĂ« podet e aplikacioneve.

Zgjerueshmëria

Kubernetes është shumë i zgjerueshëm, dhe kjo pëlqehet nga zhvilluesit. Ekziston një grup burimesh të disponueshme, si podet, deploymet, StatefulSets, sekretet, ConfigMaps, etj. E vërtetë, përdoruesit dhe zhvilluesit mund të shtojnë burime të tjera në formën e kategorive të definuara nga përdoruesi.

Për shembull, nëse duam të definim një burim CronTab, mund të bëjmë diçka të tillë:

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

Më vonë, mund të krijojmë një burim CronTab në mënyrë të ngjashme:

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

NjĂ« mundĂ«si tjetĂ«r zgjerueshmĂ«rie nĂ« Kubernetes Ă«shtĂ« se zhvilluesi mund tĂ« shkruajĂ« operatorĂ« tĂ« tij. Operatori – Ă«shtĂ« njĂ« proces i veçantĂ« nĂ« klasterin Kubernetes, qĂ« punon sipas modelit "konturi i menaxhimit". Me ndihmĂ«n e operatorit, pĂ«rdoruesi mund tĂ« automatizojĂ« menaxhimin e CRD (definimeve tĂ« burimeve tĂ« personalizuara), duke shkĂ«mbyer informacion me Kubernetes API.

Në komunitet ka disa mjete, me anë të të cilave zhvilluesit mund ta krijojnë lehtë operatorin e tyre. Ndër to janë Operator Framework dhe degëve të tij Operator SDK. Ky SDK ofron një bazë, nga e cila zhvilluesi mund të fillojë shpejt të krijojë një operator. Për shembull, mund të filloni nga komanda e linjës kështu:

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

Kështu krijohet e gjithë kodi stereotipik për operatorin tuaj, duke përfshirë, skedarët YAML dhe kodin në 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

Pastaj, mund të shtoni API-të dhe kontrolluesin e nevojshëm, kështu:

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

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

Pas kësaj, përfundimisht, ndërtoni operatorin dhe dërgojeni në regjistrin e kontejnerit tuaj:

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

Nëse zhvilluesi kërkon më shumë kontroll, mund të modifikojë kodin stereotipik në skedarët Go. Për shembull, për të ndryshuar specifikën e kontrolluesit, mund të bëni ndryshime në skedarin controller.go.

Një projekt tjetër, KUDO, lejon krijimin e operatorëve duke përdorur vetëm skedarë deklarativë YAML. Për shembull, një operator për Apache Kafka do të përcaktohej më ose më pak ashtu. Me të mund të instaloni një kluster Kafka mbi Kubernetes me vetëm disa komanda:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Dhe pastaj ta konfiguronit me një komandë tjetër:

$ 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

Inovacionet

GjatĂ« disa viteve tĂ« fundit, lĂ«shimet e mĂ«dha tĂ« Kubernetes dalin çdo disa muaj – dmth, tre-katĂ«r lĂ«shime tĂ« mĂ«dha nĂ« vit. Numri i karakteristikave tĂ« reja tĂ« implementuara nĂ« secilin prej tyre nuk po zvogĂ«lohet. PĂ«r mĂ« tepĂ«r, nuk ka shenja ngadalĂ«simi edhe nĂ« kĂ«to kohĂ« tĂ« komplikuara – shikoni se sa Ă«shtĂ« aktualisht aktiviteti i projektit Kubernetes nĂ« Github.

Mundësitë e reja lejojnë një klasterizim më fleksibël të operacioneve kur ka ngarkesa të ndryshme pune. Për më tepër, programuesve u pëlqen një kontroll më i plotë gjatë implementimit të aplikacioneve direkt në prodhim.

Komuniteti

Një aspekt tjetër serioz i popullaritetit të Kubernetes është forca e komunitetit të tij. Në vitin 2015, me arritjen e versionit 1.0, Kubernetes u sponzorua Cloud Native Computing Foundation.

Gjithashtu ekzistojnë komunitete të ndryshme SIG (grupet speciale të interesit), të fokusuar në zhvillimin e fushave të ndryshme të Kubernetes ndërsa ky projekt evoluon. Këto grupe vazhdimisht shtojnë mundësi të reja, duke e bërë përdorimin e Kubernetes më të lehtë dhe më të ndjerë.

Fondacioni Cloud Native gjithashtu organizon CloudNativeCon/KubeCon, e cila, në momentin e shkrimit të këtij teksti, është konferenca më e madhe open source në botë. Si rregull, ajo zhvillohet tri herë në vit dhe mbledh mijëra profesionistë që dëshirojnë të përmirësojnë Kubernetes dhe ekosistemin e tij, si dhe të mësojnë mundësitë e reja që shfaqen çdo tre muaj.

Më tej, në Fondacionin Cloud Native ka Komitetin për Nadzor Teknik, i cili, së bashku me SIG-të shqyrton projektet e reja dhe ato ekzistuese projektet të fondit, të fokusuara në ekosistemin cloud. Shumica e këtyre projekteve ndihmojnë në përmirësimin e pikave të forta të Kubernetes.

Së fundmi, unë besoj se Kubernetes nuk do të kishte arritur suksesin e tij pa përpjekjet e vetëdijshme të tërë komunitetit, ku njerëzit mbështesin njëri-tjetrin, por si njëkohësisht mirëpresin me kënaqësi të rinjtë në radhët e tyre.

E ardhmja

Një nga sfidat kryesore që zhvilluesit do të kenë përballë në të ardhmen është aftësia për t'u përqendruar në detajet e kodit të vet, dhe jo në infrastrukturën në të cilën ai operon. Këto tendenca janë në përgjigje të paradigmës së arkitekturës pa server, e cila sot është një nga më të njohurat. Tashmë ekzistojnë korniza të avancuara, për shembull, Knative dhe OpenFaas, që përdorin Kubernetes për të abstruar infrastrukturën nga zhvilluesi.

NĂ« kĂ«tĂ« artikull ne vetĂ«m pĂ«rmbledhim gjendjen aktuale tĂ« Kubernetes – nĂ« tĂ« vĂ«rtetĂ«, kjo Ă«shtĂ« vetĂ«m maja e ajsbergut. PĂ«rdoruesit e Kubernetes kanĂ« gjithashtu shumĂ« burime, mundĂ«si dhe konfiguracione tĂ« tjera nĂ« dispozicion.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster