A Kubernetes növekvő népszerűségéről

Szia Habr!

Nyár végén szeretnénk emlékeztetni, hogy továbbra is dolgozunk a témán Kubernetes és úgy döntött, hogy június elején közzétesz egy cikket a Stackoverflow-tól, amely bemutatja a projekt helyzetét.

Élvezd az olvasást!

A cikk írásakor Kubernetes életkora kb. hat éves, és az elmúlt két évben annyira megnőtt a népszerűsége, hogy folyamatosan a közé sorolják legkedveltebb platformok. A Kubernetes idén a harmadik helyen áll. Összefoglalva: A Kubernetes egy konténeres munkaterhelések futtatására és összehangolására tervezett platform.

A konténerek a Linux folyamatainak elkülönítésére szolgáló speciális tervezésként indultak; konténerek 2007 óta tartalmazzák csoportok, 2002 óta pedig – névterek. A konténereket 2008-ra még jobban tervezték, amikor elérhetővé vált évi LXC, a Google pedig kifejlesztette saját belső vállalati mechanizmusát, az úgynevezett Borg, ahol „minden munka konténerekben történik”. Innentől 2013-ig haladunk előre, amikor a Docker első kiadása megtörtént, és a konténerek végre népszerű tömegmegoldássá váltak. Abban az időben a konténerhangszerelés fő eszköze az volt Mesos, bár nem volt vadul népszerű. A Kubernetes először 2015-ben jelent meg, majd ez az eszköz de facto szabvány lett a konténerhangszerelés területén.

Hogy megértsük, miért olyan népszerű a Kubernetes, próbáljunk meg válaszolni néhány kérdésre. Mikor tudtak a fejlesztők utoljára megegyezni az alkalmazások éles üzembe helyezésének módjáról? Hány fejlesztőt ismer, aki használja az azonnali eszközöket? Hány felhőrendszergazda van ma, aki nem érti az alkalmazások működését? Ezekre a kérdésekre keressük a választ ebben a cikkben.

Az infrastruktúra YAML-ként

Abban a világban, amely a Puppet and Chef-től a Kubernetes-ig terjedt, az egyik legnagyobb változás az „infrastruktúra mint kód” helyett az „infrastruktúra mint adat” felé való elmozdulás volt – konkrétan, mint a YAML. A Kubernetes összes erőforrása, beleértve a podokat, konfigurációkat, telepített példányokat, köteteket stb., könnyen leírható egy YAML-fájlban. Például:

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

Ez a nézet megkönnyíti a DevOps vagy SRE szakemberek számára, hogy teljes mértékben kifejezzék munkaterhelésüket anélkül, hogy olyan nyelveken kellene kódot írniuk, mint a Python vagy a Javascript.

Az infrastruktúra adatként való megszervezésének további előnyei a következők:

• GitOps vagy Git Operations Version Control. Ez a megközelítés lehetővé teszi, hogy az összes Kubernetes YAML-fájlt git-tárolókban tartsa, így pontosan nyomon követheti, hogy mikor történt változtatás, ki hajtotta végre azt, és pontosan mi változott. Ez növeli a műveletek átláthatóságát a szervezet egészében, és javítja a működési hatékonyságot azáltal, hogy kiküszöböli a kétértelműséget, különösen ott, ahol az alkalmazottaknak meg kell keresniük a szükséges erőforrásokat. Ugyanakkor egyszerűbbé válik a Kubernetes-erőforrások automatikus módosítása egy lekérési kérelem egyszerű összevonásával.
• Méretezhetőség. Ha az erőforrásokat YAML-ként definiálják, a fürtoperátorok rendkívül könnyen módosíthatnak egy vagy két számot egy Kubernetes-erőforrásban, ezáltal megváltoztatva a skálázás módját. A Kubernetes egy mechanizmust biztosít a pod-ok vízszintes automatikus skálázásához, amellyel kényelmesen meghatározható, hogy egy adott telepítési konfigurációban mekkora minimális és maximális számú pod szükséges az alacsony és nagy forgalom kezelésére. Például, ha olyan konfigurációt telepített, amely a forgalom hirtelen megugrása miatt további kapacitást igényel, akkor a maxReplicas 10-ről 20-ra módosítható:

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

• Biztonság és menedzsment. A YAML kiválóan alkalmas arra, hogy kiértékelje a dolgok Kubernetesben történő telepítését. Például egy komoly biztonsági probléma az, hogy a munkaterhelései nem rendszergazdaként futnak-e. Ebben az esetben szükségünk lehet olyan eszközökre, mint pl vetélkedő, YAML/JSON érvényesítő, plusz Nyílt házirend-ügynök, egy irányelv érvényesítő, amely biztosítja, hogy a kontextus SecurityContext a munkaterhelések nem teszik lehetővé a tároló rendszergazdai jogosultságokkal való futtatását. Ha ez szükséges, a felhasználók egyszerű házirendet alkalmazhatnak imádkozom, mint ez:

package main

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

• A felhőszolgáltatóval való integráció lehetőségei. Napjaink csúcstechnológiájának egyik legfigyelemreméltóbb trendje a nyilvános felhőszolgáltatók terhelése. A komponens használata felhő-szolgáltató A Kubernetes lehetővé teszi, hogy bármely fürt integrálódjon azzal a felhőszolgáltatóval, amelyen fut. Például, ha a felhasználó egy alkalmazást futtat a Kubernetesben az AWS-en, és egy szolgáltatáson keresztül szeretné közzétenni az alkalmazást, a felhőszolgáltató segít automatikusan létrehozni a szolgáltatást. LoadBalanceramely automatikusan biztosítja a terheléselosztót Amazon rugalmas terheléselosztóa forgalom átirányítása az alkalmazásdobozokra.

Bővíthetőség

A Kubernetes nagyon bővíthető, és a fejlesztők szeretik. Van egy sor rendelkezésre álló erőforrás, például pod-ok, telepítések, StatefulSets, titkok, ConfigMapsstb. Igaz, a felhasználók és a fejlesztők más erőforrásokat is hozzáadhatnak az űrlaphoz egyéni erőforrás-definíciók.

Például, ha meg akarunk határozni egy erőforrást CronTab, akkor valami ilyesmit tehet:

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

Később létrehozhatunk egy CronTab erőforrást, valami ilyesmit:

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

A Kubernetes bővíthetőségének másik lehetősége az, hogy a fejlesztő saját nyilatkozatokat írhat. operátor egy speciális folyamat a Kubernetes klaszterben, amely a „vezérlő áramkör" Egy operátor segítségével a felhasználó automatizálhatja a CRD-k (egyéni erőforrás-definíciók) kezelését a Kubernetes API-val történő információcserével.

A közösségben számos eszköz található, amelyek megkönnyítik a fejlesztők számára saját operátorok létrehozását. Közöttük - Operátori keretrendszer és Operator SDK. Ez az SDK olyan alapot biztosít, amelyből a fejlesztő gyorsan hozzáláthat egy operátor létrehozásához. Tegyük fel, hogy elindíthatja a parancssorból, ilyesmi:

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

Ez létrehozza az összes alapkódot a kezelő számára, beleértve a YAML fájlokat és a Golang kódot:

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

Ezután hozzáadhatja a szükséges API-kat és vezérlőket, például:

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

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

Végül állítsa össze az operátort, és küldje el a konténer rendszerleíró adatbázisába:

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

Ha a fejlesztő még nagyobb irányítást szeretne, a Go-fájlok alapkódja módosítható. Például a vezérlő sajátosságainak módosításához módosíthatja a fájlt controller.go.

Egy másik projekt MINDENHOL, lehetővé teszi utasítások létrehozását csak deklaratív YAML-fájlok használatával. Például az Apache Kafka operátora hozzávetőlegesen lenne meghatározva így. Ezzel néhány paranccsal telepíthet egy Kafka-fürtöt a Kubernetes tetejére:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Ezután állítsa be egy másik paranccsal:

$ 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

újítások

Az elmúlt néhány évben néhány havonta jelentek meg a nagyobb Kubernetes-kiadások – vagyis évente három-négy nagyobb kiadás. Az egyikben bevezetett újdonságok száma nem csökken. Ráadásul még ezekben a nehéz időkben sem mutatkoznak a lassulás jelei – nézd meg, mi a helyzet most Kubernetes projekt tevékenység a Githubon.

Az új képességek lehetővé teszik a műveletek rugalmasabb fürtözését a különböző munkaterhelések között. Ezenkívül a programozók nagyobb irányítást élveznek, amikor az alkalmazásokat közvetlenül a termelésbe helyezik.

Közösség

A Kubernetes népszerűségének másik fő szempontja a közösség ereje. 2015-ben az 1.0-s verzió elérésekor a Kubernetes szponzorált Cloud Native Computing Foundation.

Különféle közösségek is léteznek SIG (Special Interest Groups) a Kubernetes különböző területein végzett munkára összpontosított a projekt fejlődése során. Ezek a csoportok folyamatosan új funkciókat adnak hozzá, kényelmesebbé és kényelmesebbé téve a Kubernetes-szel való munkát.

A Cloud Native Foundation ad otthont a CloudNativeCon/KubeConnak is, amely a cikk írásakor a legnagyobb nyílt forráskódú konferencia a világon. Általában évente háromszor rendezik meg, és több ezer szakembert hoz össze, akik szeretnék fejleszteni a Kuberneteset és ökoszisztémáját, valamint elsajátítani a háromhavonta megjelenő új funkciókat.

Ezenkívül a Cloud Native Foundation rendelkezik Műszaki Felügyelő Bizottság, amely a SIG-ekkel együtt felülvizsgálja az újakat és a meglévőket Projektek források a felhő ökoszisztémára összpontosítottak. A legtöbb ilyen projekt segít a Kubernetes erősségeinek javításában.

Végül úgy gondolom, hogy a Kubernetes nem lenne olyan sikeres, mint amilyen az egész közösség tudatos erőfeszítései nélkül, ahol az emberek összetartanak, de ugyanakkor szívesen látják az újonnan érkezőket is.

a jövőben

Az egyik fő kihívás, amellyel a fejlesztőknek meg kell küzdeniük a jövőben, az az, hogy magára a kódra kell összpontosítani, nem pedig az infrastruktúrára, amelyben fut. Ez megfelel ezeknek a trendeknek szerver nélküli építészeti paradigma, amely ma az egyik vezető. Fejlett keretrendszerek már léteznek, pl. Kíváló и OpenFaas, amelyek Kubernetes segítségével vonják el az infrastruktúrát a fejlesztőtől.

Ebben a cikkben csak a felszínét kapargattuk Kubernetes jelenlegi állapotának – valójában ez csak a jéghegy csúcsa. A Kubernetes-felhasználók számos egyéb erőforrással, képességgel és konfigurációval rendelkeznek.

Forrás: will.com