Um vaxandi vinsældir Kubernetes

Hæ Habr!

Í lok sumars viljum við minna á að við höldum áfram að vinna að efnið Kubernetes og ákvað að birta grein frá Stackoverflow sem sýnir stöðu mála í þessu verkefni í byrjun júní.

Gleðilegt lestur!

Þegar þessi grein er skrifuð er aldur Kubernetes u.þ.b. sex ára, og á undanförnum tveimur árum hafa vinsældir þess aukist svo mikið að það er stöðugt raðað á meðal mest uppáhalds pallar. Kubernetes er í þriðja sæti í ár. Til að rifja upp: Kubernetes er vettvangur hannaður til að keyra og skipuleggja gámavinnuálag.

Gámar byrjuðu sem sérstök hönnun til að einangra ferli í Linux; gámar hafa verið með síðan 2007 hópar, og síðan 2002 – nafnarými. Gámar voru hannaðir enn betur árið 2008, þegar þeir urðu fáanlegir LXC, og Google þróaði eigin innri fyrirtækjakerfi sem kallast Borg, þar sem „öll vinna fer fram í gámum“. Héðan höldum við áfram til ársins 2013, þegar fyrsta útgáfu Docker fór fram, og gámar urðu loksins vinsæl fjöldalausn. Á þeim tíma var helsta tækið til gámahljómsveitar Mesos, þó hann hafi ekki verið mjög vinsæll. Kubernetes kom fyrst út árið 2015, eftir það varð þetta tól í raun staðall á sviði gámahljómsveitar.

Til að reyna að skilja hvers vegna Kubernetes er svona vinsælt skulum við reyna að svara nokkrum spurningum. Hvenær gátu verktaki síðast komið sér saman um hvernig ætti að dreifa forritum í framleiðslu? Hversu marga forritara þekkir þú sem nota verkfærin þar sem þau eru úthlutað úr kassanum? Hversu margir skýjastjórnendur eru í dag sem skilja ekki hvernig forrit virka? Við munum skoða svörin við þessum spurningum í þessari grein.

Innviðir sem YAML

Í heiminum sem fór frá Puppet and Chef til Kubernetes, var ein stærsta breytingin að færa frá „innviði sem kóða“ yfir í „innviði sem gögn“ - nánar tiltekið eins og YAML. Auðvelt er að lýsa öllum tilföngum í Kubernetes, sem innihalda belg, stillingar, uppsett tilvik, bindi osfrv., í YAML skrá. Til dæmis:

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

Þessi skoðun auðveldar DevOps eða SRE fagfólki að tjá vinnuálag sitt að fullu án þess að þurfa að skrifa kóða á tungumálum eins og Python eða Javascript.

Aðrir kostir þess að skipuleggja innviði sem gögn eru:

• GitOps eða Git Operations Version Control. Þessi aðferð gerir þér kleift að geyma allar Kubernetes YAML skrár í git geymslum, svo þú getur fylgst nákvæmlega með hvenær breyting var gerð, hver gerði hana og hvað nákvæmlega breyttist. Þetta eykur gagnsæi starfseminnar um allt skipulag og bætir skilvirkni í rekstri með því að eyða tvíræðni, sérstaklega þar sem starfsmenn ættu að leita að þeim úrræðum sem þeir þurfa. Á sama tíma verður auðveldara að gera sjálfkrafa breytingar á Kubernetes auðlindum með því einfaldlega að sameina dráttarbeiðni.
• Skalanleiki. Þegar auðlindir eru skilgreindar sem YAML, verður það afar auðvelt fyrir klasafyrirtæki að breyta einni eða tveimur tölum í Kubernetes auðlind og breyta þannig hvernig hún skalast. Kubernetes býður upp á kerfi fyrir lárétta sjálfvirka mælingu á belgjum, sem hægt er að nota til að ákvarða á þægilegan hátt hvaða lágmarks- og hámarksfjöldi belgs þarf í tiltekinni uppsetningu til að takast á við litla og mikla umferð. Til dæmis, ef þú hefur sett upp stillingar sem krefst viðbótargetu vegna skyndilegrar aukningar í umferð, þá er hægt að breyta maxReplicas úr 10 í 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

• Öryggi og stjórnun. YAML er frábært til að meta hvernig hlutum er dreift í Kubernetes. Til dæmis, stórt öryggisvandamál snýst um hvort vinnuálag þitt sé í gangi sem notandi sem ekki er stjórnandi. Í þessu tilfelli gætum við þurft verkfæri eins og keppni, YAML/JSON staðfestingaraðili, auk Opna stefnumiðlara, stefnumatsaðili til að tryggja að samhengið Öryggissamhengi vinnuálagið þitt leyfir ekki ílátinu að keyra með stjórnandaréttindi. Ef þess er krafist geta notendur beitt einfaldri stefnu ég bið, svona:

package main

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

• Valkostir fyrir samþættingu við skýjaveitu. Ein athyglisverðasta þróunin í hátækni nútímans er að keyra vinnuálag á opinbera skýjaveitur. Að nota íhlutinn skýjaveita Kubernetes gerir öllum þyrpingum kleift að samþættast við skýjaveituna sem hann keyrir á. Til dæmis, ef notandi keyrir forrit í Kubernetes á AWS og vill afhjúpa það forrit í gegnum þjónustu, hjálpar skýjaveitan sjálfkrafa að búa til þjónustuna LoadBalancersem mun sjálfkrafa útvega álagsjafnara Amazon Elastic Load Balancertil að beina umferð yfir á forritapúða.

Stækkanleiki

Kubernetes er mjög stækkanlegt og forritarar elska það. Það er sett af tiltækum úrræðum eins og belg, dreifing, StatefulSets, leyndarmál, ConfigMaps, o.s.frv. Að vísu geta notendur og verktaki bætt við öðrum auðlindum í formi sérsniðnar auðlindaskilgreiningar.

Til dæmis ef við viljum skilgreina auðlind CronTab, þá gætirðu gert eitthvað á þessa leið:

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

Síðar getum við búið til CronTab auðlind eitthvað á þessa leið:

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

Annar valkostur fyrir stækkanleika í Kubernetes er að verktaki getur skrifað eigin yfirlýsingar. Flugrekandi er sérstakt ferli í Kubernetes klasanum sem vinnur samkvæmt „stjórnrás" Með hjálp rekstraraðila getur notandinn sjálfvirkt stjórnun CRDs (sérsniðnar auðlindaskilgreiningar) með því að skiptast á upplýsingum með Kubernetes API.

Það eru nokkur verkfæri í samfélaginu sem auðvelda forriturum að búa til sína eigin rekstraraðila. Meðal þeirra - Rekstrarrammi og SDK rekstraraðila. Þetta SDK veitir grunn sem verktaki getur fljótt byrjað að búa til rekstraraðila. Segjum að þú getir byrjað frá skipanalínunni eitthvað á þessa leið:

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

Þetta býr til allan ketilskóðann fyrir símafyrirtækið þitt, þar á meðal YAML skrár og Golang kóða:

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

Síðan geturðu bætt við nauðsynlegum API og stjórnanda, svona:

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

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

Settu síðan saman rekstraraðilann að lokum og sendu hann til skrásetningar gámsins þíns:

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

Ef verktaki vill enn meiri stjórn er hægt að breyta boilerplate kóðanum í Go skrám. Til dæmis, til að breyta sérstöðu stjórnandans, geturðu gert breytingar á skránni controller.go.

Annað verkefni alls staðar, gerir þér kleift að búa til yfirlýsingar með því að nota aðeins yfirlýsingar YAML skrár. Til dæmis væri rekstraraðili fyrir Apache Kafka skilgreindur um það bil svo. Með því geturðu sett upp Kafka þyrping ofan á Kubernetes með aðeins nokkrum skipunum:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Og stilltu það síðan með annarri skipun:

$ 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

Nýsköpun

Undanfarin ár hafa helstu Kubernetes útgáfur komið út á nokkurra mánaða fresti - það er þrjár til fjórar helstu útgáfur á ári. Fjöldi nýrra eiginleika sem kynntir eru í hverjum þeirra fækkar ekki. Þar að auki eru engin merki um að hægja á sér jafnvel á þessum erfiðu tímum - sjáið hvernig staðan er núna Kubernetes verkefnisvirkni á Github.

Nýir eiginleikar gera þér kleift að flokka starfsemi á sveigjanlegri hátt yfir fjölbreytt vinnuálag. Að auki njóta forritarar meiri stjórn þegar þeir setja forrit beint í framleiðslu.

Community

Annar stór þáttur í vinsældum Kubernetes er styrkur samfélagsins. Árið 2015, þegar útgáfa 1.0 var náð, var Kubernetes styrkt af Cloud Native Computing Foundation.

Það eru líka ýmis samfélög SIG (Special Interest Groups) lögðu áherslu á að vinna á mismunandi sviðum Kubernetes eftir því sem verkefnið þróast. Þessir hópar eru stöðugt að bæta við nýjum eiginleikum, sem gerir vinnu með Kubernetes þægilegri og þægilegri.

Cloud Native Foundation hýsir einnig CloudNativeCon/KubeCon, sem, þegar þetta er skrifað, er stærsta opinn uppspretta ráðstefna í heimi. Það er venjulega haldið þrisvar á ári og safnar saman þúsundum sérfræðinga sem vilja bæta Kubernetes og vistkerfi þess, auk þess að læra nýja eiginleika sem birtast á þriggja mánaða fresti.

Þar að auki hefur Cloud Native Foundation Tæknieftirlitsnefnd, sem, ásamt SIGs, fer yfir nýtt og núverandi Verkefni sjóðir sem einbeita sér að skýjavistkerfinu. Flest þessara verkefna hjálpa til við að bæta styrkleika Kubernetes.

Að lokum tel ég að Kubernetes myndi ekki ná eins árangri og raun ber vitni án meðvitaðs átaks alls samfélagsins, þar sem fólk stendur saman en býður um leið nýliða velkomna í hópinn.

Framtíðin

Ein helsta áskorunin sem þróunaraðilar munu þurfa að takast á við í framtíðinni er hæfileikinn til að einbeita sér að smáatriðum kóðans sjálfs, en ekki innviðina sem hann keyrir í. Það mætir þessum straumum netþjónalaus byggingarlistarfyrirmynd, sem er einn af þeim fremstu í dag. Háþróaðir rammar eru þegar til, t.d. Hnífa и OpenFaas, sem nota Kubernetes til að taka innviðina frá framkvæmdaraðilanum.

Í þessari grein höfum við aðeins klórað yfirborðið af núverandi ástandi Kubernetes - í raun er það bara toppurinn á ísjakanum. Kubernetes notendur hafa mörg önnur úrræði, getu og stillingar til umráða.

Heimild: www.habr.com