O rastúcej popularite Kubernetes

Čau Habr!

Na konci leta vám chceme pripomenúť, že téme naďalej pracujeme Kubernetes a rozhodla sa začiatkom júna zverejniť článok zo Stackoverflow demonštrujúci stav vecí v tomto projekte.

Užite si čítanie!

V čase písania tohto článku je vek Kubernetes cca. šesť rokov, a za posledné dva roky sa jeho popularita natoľko rozrástla, že sa medzi nimi neustále umiestňuje najobľúbenejšie platformy. Kubernetes je tento rok na treťom mieste. Aby sme to zhrnuli: Kubernetes je platforma navrhnutá na spúšťanie a organizovanie kontajnerových úloh.

Kontajnery začali ako špeciálny dizajn na izoláciu procesov v Linuxe; kontajnery zahŕňajú od roku 2007 skupinya od roku 2002 – menné priestory. Kontajnery boli navrhnuté ešte lepšie do roku 2008, keď boli dostupné LXCa Google vyvinul vlastný interný firemný mechanizmus tzv Borg, kde sa „všetka práca vykonáva v kontajneroch“. Odtiaľ sa rýchlo posunieme do roku 2013, kedy sa uskutočnilo prvé vydanie Dockera a kontajnery sa konečne stali obľúbeným masovým riešením. V tom čase bol hlavným nástrojom kontajnerovej orchestrácie Mesos, hoci nebol veľmi populárny. Kubernetes bol prvýkrát vydaný v roku 2015, po ktorom sa tento nástroj stal de facto štandardom v oblasti orchestrácie kontajnerov.

Aby sme sa pokúsili pochopiť, prečo je Kubernetes taký populárny, skúsme odpovedať na niekoľko otázok. Kedy sa naposledy vývojári dokázali dohodnúť na spôsobe nasadenia aplikácií do produkcie? Koľko vývojárov poznáte, ktorí používajú nástroje tak, ako sú poskytované hneď po vybalení? Koľko je dnes cloudových správcov, ktorí nerozumejú fungovaniu aplikácií? Na odpovede na tieto otázky sa pozrieme v tomto článku.

Infraštruktúra ako YAML

Vo svete, ktorý prešiel z Puppet and Chef do Kubernetes, bol jednou z najväčších zmien prechod z „infraštruktúry ako kódu“ na „infraštruktúru ako dáta“ – konkrétne ako YAML. Všetky zdroje v Kubernetes, ktoré zahŕňajú moduly, konfigurácie, nasadené inštancie, zväzky atď., možno jednoducho popísať v súbore YAML. Napríklad:

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

Toto zobrazenie uľahčuje profesionálom DevOps alebo SRE plne vyjadriť svoje pracovné zaťaženie bez toho, aby museli písať kód v jazykoch ako Python alebo Javascript.

Medzi ďalšie výhody organizácie infraštruktúry ako údajov patria:

• GitOps alebo Git Operations Version Control. Tento prístup vám umožňuje uchovávať všetky súbory Kubernetes YAML v úložiskách git, takže môžete presne sledovať, kedy bola zmena vykonaná, kto ju urobil a čo presne sa zmenilo. To zvyšuje transparentnosť operácií v celej organizácii a zlepšuje prevádzkovú efektivitu odstránením nejednoznačnosti, najmä tam, kde by zamestnanci mali hľadať zdroje, ktoré potrebujú. Zároveň je jednoduchšie automaticky vykonávať zmeny v zdrojoch Kubernetes jednoduchým zlúčením žiadosti o stiahnutie.
• Škálovateľnosť. Keď sú prostriedky definované ako YAML, pre operátorov klastra je mimoriadne jednoduché zmeniť jedno alebo dve čísla v zdroji Kubernetes, čím sa zmení jeho škálovanie. Kubernetes poskytuje mechanizmus pre horizontálne automatické škálovanie modulov, ktorý možno použiť na pohodlné určenie, aký minimálny a maximálny počet modulov je potrebný v konkrétnej konfigurácii nasadenia na zvládnutie nízkej a vysokej úrovne prevádzky. Ak ste napríklad nasadili konfiguráciu, ktorá si vyžaduje dodatočnú kapacitu z dôvodu náhleho nárastu návštevnosti, maxReplicas možno zmeniť z 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

• Bezpečnosť a riadenie. YAML je skvelý na vyhodnotenie toho, ako sú veci nasadené v Kubernetes. Napríklad hlavná obava o bezpečnosť sa týka toho, či vaše pracovné zaťaženia bežia ako používateľ bez správcu. V tomto prípade môžeme potrebovať nástroje ako napr súperiť, validátor YAML/JSON a navyše Otvorte Policy Agent, validátor politiky, aby sa zabezpečilo, že kontext SecurityContext vaše pracovné zaťaženia nedovoľujú, aby sa kontajner spúšťal s oprávneniami správcu. Ak je to potrebné, používatelia môžu použiť jednoduchú politiku modlím sa, Páči sa ti to:

package main

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

• Možnosti integrácie s poskytovateľom cloudu. Jedným z najpozoruhodnejších trendov v dnešnej špičkovej technológii je spúšťanie úloh na verejných poskytovateľoch cloudu. Použitie komponentu cloud-poskytovateľ Kubernetes umožňuje integráciu akéhokoľvek klastra s poskytovateľom cloudu, na ktorom beží. Ak napríklad používateľ spustí aplikáciu v Kubernetes na AWS a chce túto aplikáciu sprístupniť prostredníctvom služby, poskytovateľ cloudu mu pomôže službu automaticky vytvoriť. LoadBalancerktorý automaticky zabezpečí vyvažovanie záťaže Amazon Elastic Load Balancerna presmerovanie prevádzky do aplikačných modulov.

Rozšíriteľnosť

Kubernetes je veľmi rozšíriteľný a vývojári ho milujú. Existuje súbor dostupných zdrojov, ako sú moduly, nasadenia, StatefulSets, tajomstvá, ConfigMaps, atď. Je pravda, že používatelia a vývojári môžu do formulára pridať ďalšie zdroje vlastné definície zdrojov.

Napríklad, ak chceme definovať zdroj CronTab, potom by ste mohli urobiť niečo takéto:

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

Neskôr môžeme vytvoriť zdroj CronTab niečo ako toto:

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

Ďalšou možnosťou rozšírenia v Kubernetes je, že vývojár môže písať svoje vlastné vyhlásenia. operátor je špeciálny proces v klastri Kubernetes, ktorý funguje podľa „riadiaci obvod" S pomocou operátora môže používateľ automatizovať správu CRD (vlastné definície zdrojov) výmenou informácií s Kubernetes API.

V komunite existuje niekoľko nástrojov, ktoré vývojárom uľahčujú vytváranie vlastných operátorov. Medzi nimi - Operačný rámec a SDK operátora. Táto súprava SDK poskytuje základ, z ktorého môže vývojár rýchlo začať vytvárať operátora. Povedzme, že môžete začať z príkazového riadku takto:

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

Tým sa vytvorí všetok štandardný kód pre vášho operátora vrátane súborov YAML a kódu 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

Potom môžete pridať požadované rozhrania API a ovládač takto:

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

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

Potom nakoniec zostavte operátora a odošlite ho do registra vášho kontajnera:

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

Ak chce vývojár ešte väčšiu kontrolu, štandardný kód v súboroch Go možno zmeniť. Ak chcete napríklad upraviť špecifiká ovládača, môžete vykonať zmeny v súbore controller.go.

Ďalší projekt VŠADE, umožňuje vytvárať výpisy iba pomocou deklaratívnych súborov YAML. Napríklad operátor pre Apache Kafka by bol definovaný približne tak. S ním môžete nainštalovať klaster Kafka na Kubernetes pomocou niekoľkých príkazov:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

A potom ho nakonfigurujte pomocou iného príkazu:

$ 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ácie

Počas niekoľkých posledných rokov hlavné vydania Kubernetes vychádzali každých pár mesiacov – to znamená tri až štyri hlavné vydania za rok. Počet noviniek predstavených v každom z nich sa neznižuje. Navyše ani v týchto ťažkých časoch nie sú žiadne známky spomalenia – pozrite sa, aká je situácia teraz Projektová aktivita Kubernetes na Github.

Nové možnosti vám umožňujú flexibilnejšie zoskupovať operácie v rámci rôznych pracovných zaťažení. Programátori si navyše užívajú väčšiu kontrolu pri nasadzovaní aplikácií priamo do produkcie.

Spoločenstva

Ďalším hlavným aspektom popularity Kubernetes je sila jeho komunity. V roku 2015, po dosiahnutí verzie 1.0, bol Kubernetes sponzorovaný Cloud Native Computing Foundation.

Existujú aj rôzne komunity SIG (Special Interest Groups) sa počas vývoja projektu zamerali na prácu v rôznych oblastiach Kubernetes. Tieto skupiny neustále pridávajú nové funkcie, vďaka čomu je práca s Kubernetes pohodlnejšia a pohodlnejšia.

Cloud Native Foundation tiež hostí CloudNativeCon/KubeCon, čo je v čase písania tohto článku najväčšia open source konferencia na svete. Zvyčajne sa koná trikrát do roka a spája tisíce profesionálov, ktorí chcú zlepšiť Kubernetes a jeho ekosystém, ako aj naučiť sa nové funkcie, ktoré sa objavujú každé tri mesiace.

Okrem toho má Cloud Native Foundation Výbor pre technický dozor, ktorá spolu so SIGmi recenzuje nové aj existujúce Projekty prostriedky zamerané na cloudový ekosystém. Väčšina z týchto projektov pomáha zlepšovať silné stránky Kubernetes.

Nakoniec verím, že Kubernetes by nebol taký úspešný ako je bez vedomého úsilia celej komunity, kde ľudia držia spolu, ale zároveň vítajú nováčikov v skupine.

budúcnosť

Jednou z hlavných výziev, s ktorými sa budú musieť vývojári v budúcnosti popasovať, je schopnosť sústrediť sa na detaily samotného kódu, a nie na infraštruktúru, v ktorej beží. Spĺňa tieto trendy architektonická paradigma bez serverov, ktorá je dnes jednou z popredných. Pokročilé rámce už existujú, napr. Nožom и OpenFaas, ktoré používajú Kubernetes na abstrahovanie infraštruktúry od vývojára.

V tomto článku sme len načrtli povrch súčasného stavu Kubernetes – v skutočnosti je to len špička ľadovca. Používatelia Kubernetes majú k dispozícii mnoho ďalších zdrojov, možností a konfigurácií.

Zdroj: hab.com