🥇O rastućoj popularnosti Kubernetesa

Bok, Habr!

Na kraju ljeta želimo podsjetiti da nastavljamo raditi na temi Kubernetes i odlučili smo objaviti članak sa Stackoverflowa koji pokazuje stanje stvari u ovom projektu na početku lipnja.

Uživajte u čitanju!

U trenutku pisanja ovog članka, Kubernetes je star oko šest godina, a tijekom posljednje dvije godine njegova popularnost toliko je porasla da stabilno zauzima jedno od najomiljenijih platformi. Ove godine Kubernetes zauzima treće mjesto. Podsjetimo: Kubernetes je platforma namijenjena pokretanju i orkestraciji kontejnerskih radnih opterećenja.

Kontejneri su nastali kao posebna konstrukcija za izolaciju procesa u Linuxu; od 2007. uključuju cgroups, a od 2002. - prostore imena. Kontejneri su se bolje oblikovali do 2008. godine, kada je postao dostupan LXC, a u Googleu su razvili svoj interni mehanizam nazvan Borg, gdje se 'sav rad odvija u kontejnerima'. Odavde se vraćamo u 2013. godinu kada je objavljeno prvo izdanje Dockera i kontejneri su konačno prešli u kategoriju popularnih masovnih rješenja. U to vrijeme, glavni alat za orkestraciju kontejnera bio je Mesos, iako nije uživao veliku popularnost. Prvo izdanje Kubernetes-a dogodilo se 2015. godine, nakon čega je ovaj alat de facto postao standard u području orkestracije kontejnera.

Kako bismo pokušali razumjeti zašto je Kubernetes tako popularan, pokušajmo odgovoriti na nekoliko pitanja. Kada su se posljednji put programeri složili o tome kako implementirati aplikacije u produkciji? Koliko poznajete programera koji koriste alate onakvima kakvi se pružaju 'iz kutije'? Koliko danas takvih cloud administratora ne razumije kako aplikacije rade? Odgovore na ta pitanja razmotrit ćemo u ovom članku.

Infrastruktura kao YAML

U svijetu koji je od Puppeta i Chefa prešao na Kubernetes, jedna od najvećih promjena bila je prijelaz od 'infrastrukture kao koda' do 'infrastrukture kao podataka' - konkretno, kao YAML. Sve resurse u Kubernetes-u, koji uključuju podove, konfiguracije, implementirane instance, volumene itd. lako je opisati u YAML datoteci. Na primjer:

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

S ovakvim pristupom stručnjacima za DevOps ili SRE je lakše potpuno izraziti svoje radne opterećenje bez potrebe za pisanjem programskog koda na jezicima kao što su Python ili Javascript.

Druge prednosti organizacije infrastrukture kao podataka su sljedeće:

GitOps ili kontrola verzija Git Operations Version. Ovaj pristup omogućava da svi YAML datoteke Kubernetes budu u git repozitorijima, čime se precizno može pratiti kada je da izmjena izvršena, tko ju je izvršio i što je točno promijenjeno. Ovo povećava transparentnost operacija širom organizacije i poboljšava učinkovitost uklanjanjem nejasnoća, osobito u tome gdje zaposlenici trebaju tražiti potrebne resurse. U isto vrijeme, jednostavnije je automatski uvesti promjene u resurse Kubernetes - putem običnog spajanja pull zahtjeva.
Skalabilnost. Kada su resursi definirani u obliku YAML-a, operaterima klastera postaje izuzetno jednostavno promijeniti jedan ili dva broja u resursu Kubernetes, čime se mijenjaju principi njegove skalabilnosti. Kubernetes ima mehanizam za horizontalno automatsko skaliranje podova, koji omogućava jednostavno određivanje minimalnog i maksimalnog broja podova koji su potrebni u određenoj raspoređenoj konfiguraciji kako bi se nosili s niskim i visokim razinama prometa. Na primjer, ako ste rasporedili konfiguraciju kojoj su potrebni dodatni resursi zbog naglog porasta prometa, možete promijeniti maxReplicas s 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

Sigurnost i upravljanje. YAML je odličan za procjenu načina na koji su određene stvari raspoređene u Kubernetesu. Na primjer, ozbiljan problem vezan uz sigurnost je pokreću li se vaša radna opterećenja pod korisnikom koji nema administratorska prava. U ovom slučaju mogu nam pomoći alati poput conftest, validator YAML/JSON, plus Open Policy Agent, validator politika, koji omogućava da se osigura da kontekst SecurityContext Vašim radnim opterećenjima ne dopušta spremniku da radi s administratorskim privilegijama. Ako je to potrebno, korisnici mogu primijeniti jednostavnu politiku. rego, ovako:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Spremnici ne smiju raditi kao root"
}

Opcije integracije s pružateljem oblaka. Jedan od najočitijih trendova u modernim tehnologijama je pokretanje radnih opterećenja na resursima javnih pružatelja oblaka. Pomoću komponente cloud-provider Kubernetes omogućuje bilo kojem klasteru da se integrira s pružateljem oblaka na kojem radi. Na primjer, ako korisnik pokrene aplikaciju u Kubernetesu na AWS-u i želi omogućiti pristup toj aplikaciji putem usluge, pružatelj oblaka pomaže automatski stvoriti uslugu LoadBalancer, koja automatski osigurava ravnotežnu opremu Amazon Elastic Load Balancer, kako bi preusmjerio promet u podove aplikacija.

Ekstenzibilnost

Kubernetes se vrlo dobro proširuje i to se sviđa programerima. Postoji set postojećih resursa, kao što su podovi, rasporedi, StatefulSets, tajne, ConfigMaps, itd. Naravno, korisnici i programeri mogu dodati i druge resurse u obliku korisnički definiranih resursa.

Na primjer, ako želimo definirati resurs CronTab, mogli bismo učiniti nešto slično:

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

Kasnije možemo stvoriti resurs CronTab otprilike ovako:

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

Još jedna opcija ekstenzibilnosti u Kubernetesu je da programer može pisati vlastite operatore. Operator – to je poseban proces u klasteru Kubernetes koji radi po uzorku "konture upravljanja". Pomoću operatera korisnik može automatizirati upravljanje CRD (vlastitim definicijama resursa) razmjenjujući informacije s Kubernetes API-jem.

U zajednici postoji nekoliko alata koji programerima olakšavaju stvaranje vlastitih operatora. Među njima su Operator Framework i njegov Operator SDK. Ovaj SDK pruža osnovu na koju se programer može vrlo brzo primiti stvaranja operatora. Na primer, može se početi iz komandne linije otprilike ovako:

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

Tako se generiše sav stvoreni kod za vaš operator, uključujući YAML datoteke i kod na Golangu:

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

Nakon toga možete dodati potrebne API-je i kontroler, ovako:

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

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

Nakon toga, konačno, sastavite operator i pošaljite ga u registar vašeg kontejnera:

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

Ako programeru treba još veća kontrola, može promeniti generisani kod u datotekama na Go. Na primer, da bi se promenila specifičnost kontrolera, možete izmeniti datoteku controller.go.

Drugi projekt, KUDO, omogućava stvaranje operatora koristeći samo deklarativne YAML datoteke. Na primer, operator za Apache Kafka biće definisan otprilike tako. Pomoću njega možete sa samo par komandi instalirati Kafka klaster na Kubernetes:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

A zatim ga podesiti pomoću još jedne komande:

$ 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

Tokom nekoliko poslednjih godina veliki izdanja Kubernetes-a izlaze svaka nekoliko meseci – dakle, po tri-četiri velika izdanja godišnje. Broj novih funkcija koje se implementiraju u svakom od njih ne smanjuje se. Štaviše, ne primećuju se znaci usporavanja čak ni u našim teškim vremenima – pogledajte kolika je trenutno aktivnost projekta Kubernetes na Github-u.

Nove mogućnosti omogućuju fleksibilnije klasteriziranje operacija uz raznolikost radnih opterećenja. Osim toga, programerima se sviđa veća kontrola prilikom implementacije aplikacija izravno u produkciju.

Zajednica

Još jedan ozbiljan aspekt popularnosti Kubernetesa leži u snazi njegove zajednice. Godine 2015., postizanjem verzije 1.0, Kubernetes je postao sponzoriran Cloud Native Computing Foundation.

Također postoje razne zajednice SIG (specijalne interesne grupe), fokusirane na razradu različitih područja Kubernetesa dok se ovaj projekt razvija. Ove grupe kontinuirano dodaju nove mogućnosti, što čini rad s Kubernetesom sve lakšim i jednostavnijim.

Cloud Native Foundation također organizuje CloudNativeCon/KubeCon, koja, u vrijeme pisanja ovog teksta, predstavlja najveću open-source konferenciju na svijetu. Obično se održava tri puta godišnje i okuplja tisuće stručnjaka koji žele poboljšati Kubernetes i njegov ekosustav, kao i naučiti nove mogućnosti koje se javljaju svaka tri mjeseca.

Štoviše, u Cloud Native Foundation postoji Odbor za tehnički nadzor, koji zajedno s SIG-ovima razmatra nove i postojeće projekata projekte fonda, fokusirane na oblačni ekosustav. Većina ovih projekata pomaže u jačanju Kubernetesa.

Na kraju, vjerujem da Kubernetes ne bi imao toliku uspješnost bez svjesnih napora čitave zajednice, gdje se ljudi podržavaju, ali istovremeno s radošću prihvaćaju novake.

Budućnost

Jedan od glavnih izazova s kojima će se programeri suočiti u budućnosti je sposobnost usredotočavanja na detalje samog koda, a ne na infrastrukturu u kojoj se nalazi. Upravo tim tendencijama odgovara serverless arhitektonska paradigma, koja je danas jedna od vodećih. Već postoje napredni okviri, poput Knative i OpenFaas, koji koriste Kubernetes za apstraktizaciju infrastrukture od programera.

U ovom članku smo samo ukratko razmotrili trenutno stanje Kubernetesa – zapravo, to je samo vrh sante leda. Korisnicima Kubernetesa na raspolaganju su i mnogi drugi resursi, mogućnosti i konfiguracije.

Izvor: habr.com

O rastućoj popularnosti Kubernetes-a

Infrastruktura kao YAML

Ekstenzibilnost

Inovacije

Zajednica

Budućnost