Kubernetes-ի աճող ժողովրդականության մասին

Հե՜յ Հաբր։

Ամառվա վերջում ուզում ենք հիշեցնել, որ շարունակում ենք աշխատել թեմայի շուրջ Կուբերնետես և որոշեց հրապարակել հոդված Stackoverflow-ից, որը ցույց է տալիս այս նախագծի իրերի վիճակը հունիսի սկզբին:

Վայելեք ընթերցանությունը:

Այս հոդվածը գրելու պահին Kubernetes-ի տարիքը մոտ. վեց տարեկան, և վերջին երկու տարիների ընթացքում նրա ժողովրդականությունն այնքան է աճել, որ այն հետևողականորեն դասվում է ամենասիրված հարթակներ. Kubernetes-ն այս տարի զբաղեցնում է երրորդ տեղը։ Հիշեցնենք, որ Kubernetes-ը հարթակ է, որը նախատեսված է բեռնարկղային ծանրաբեռնվածություն գործարկելու և կազմակերպելու համար:

Կոնտեյներները սկսվեցին որպես Linux-ում պրոցեսների մեկուսացման հատուկ դիզայն; բեռնարկղերը ներառված են 2007թ խմբեր, իսկ 2002 թվականից՝ անվանատարածքներ։ Կոնտեյներներն ավելի լավ էին նախագծվել մինչև 2008 թվականը, երբ այն հասանելի դարձավ LXC, և Google-ը մշակել է իր ներքին կորպորատիվ մեխանիզմը, որը կոչվում է Բորգ, որտեղ «բոլոր աշխատանքները կատարվում են տարաներով»։ Այստեղից մենք շտապում ենք մինչև 2013 թվականը, երբ տեղի ունեցավ Docker-ի առաջին թողարկումը, և բեռնարկղերը վերջապես դարձան հանրաճանաչ զանգվածային լուծում: Այն ժամանակ կոնտեյներային նվագախմբի հիմնական գործիքն էր Մեսոս, թեև նա մեծ ժողովրդականություն չէր վայելում։ Kubernetes-ն առաջին անգամ թողարկվել է 2015 թվականին, որից հետո այս գործիքը դարձել է դե ֆակտո ստանդարտ կոնտեյներային նվագախմբավորման ոլորտում։

Փորձելու համար հասկանալ, թե ինչու է Kubernetes-ը այդքան հայտնի, փորձենք պատասխանել մի քանի հարցի։ Ե՞րբ է վերջին անգամ ծրագրավորողները կարողացել պայմանավորվել, թե ինչպես տեղակայել հավելվածները արտադրության մեջ: Քանի՞ մշակողի գիտեք, ովքեր օգտագործում են գործիքները, քանի որ դրանք տրամադրվում են առանց տուփի: Քանի՞ ամպային ադմինիստրատորներ կան այսօր, ովքեր չեն հասկանում, թե ինչպես են աշխատում հավելվածները: Այս հարցերի պատասխանները մենք կանդրադառնանք այս հոդվածում:

Ենթակառուցվածքը որպես YAML

Աշխարհում, որը տիկնիկայինից և խոհարարից հասավ Կուբերնետես, ամենամեծ փոփոխություններից մեկը «ենթակառուցվածքից որպես կոդ» «ենթակառուցվածքից որպես տվյալ» տեղափոխությունն էր, մասնավորապես, ինչպես YAML-ը: Kubernetes-ի բոլոր ռեսուրսները, որոնք ներառում են պատյաններ, կոնֆիգուրացիաներ, տեղակայված օրինակներ, ծավալներ և այլն, հեշտությամբ կարելի է նկարագրել YAML ֆայլում: Օրինակ:

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

Այս տեսակետը հեշտացնում է DevOps-ի կամ SRE-ի մասնագետներին ամբողջությամբ արտահայտել իրենց աշխատանքային բեռները՝ առանց Python-ի կամ Javascript-ի նման լեզուներով կոդ գրելու:

Ենթակառուցվածքները որպես տվյալներ կազմակերպելու այլ առավելությունները ներառում են.

• GitOps կամ Git Operations Version Control: Այս մոտեցումը թույլ է տալիս Ձեզ պահել բոլոր Kubernetes YAML ֆայլերը git պահոցներում, որպեսզի կարողանաք հետևել, թե երբ է կատարվել փոփոխությունը, ով է կատարել այն և ինչ է փոխվել: Սա մեծացնում է գործառնությունների թափանցիկությունը ամբողջ կազմակերպությունում և բարելավում գործառնական արդյունավետությունը՝ վերացնելով երկիմաստությունը, հատկապես, որտեղ աշխատակիցները պետք է փնտրեն իրենց անհրաժեշտ ռեսուրսները: Միևնույն ժամանակ, ավելի հեշտ է դառնում ավտոմատ կերպով փոփոխություններ կատարել Kubernetes-ի ռեսուրսներում՝ պարզապես միաձուլելով ձգման հարցումը:
• Մասշտաբայնություն. Երբ ռեսուրսները սահմանվում են որպես YAML, կլաստերի օպերատորների համար չափազանց հեշտ է դառնում փոխել մեկ կամ երկու թվեր Kubernetes-ի ռեսուրսում՝ դրանով իսկ փոխելով դրա մասշտաբը: Kubernetes-ը տրամադրում է պատիճների հորիզոնական ավտոմատ մասշտաբավորման մեխանիզմ, որը կարող է օգտագործվել՝ հարմար կերպով որոշելու համար, թե կոնկրետ տեղակայման կոնֆիգուրացիաներում ինչ նվազագույն և առավելագույն քանակ է պահանջվում երթևեկության ցածր և բարձր մակարդակները կարգավորելու համար: Օրինակ, եթե դուք տեղադրել եք այնպիսի կոնֆիգուրացիա, որը պահանջում է լրացուցիչ հզորություն՝ երթևեկության հանկարծակի աճի պատճառով, ապա maxReplicas-ը կարող է փոխվել 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

• Անվտանգություն և կառավարում. YAML-ը հիանալի է գնահատելու, թե ինչպես են իրերը տեղակայվում Kubernetes-ում: Օրինակ, անվտանգության հիմնական մտահոգությունը վերաբերում է, թե արդյոք ձեր աշխատանքային բեռները աշխատում են որպես ոչ ադմինիստրատորի օգտվող: Այս դեպքում մեզ կարող են անհրաժեշտ լինել այնպիսի գործիքներ, ինչպիսիք են մրցույթ, YAML/JSON վավերացուցիչ, գումարած Բաց քաղաքականության գործակալ, քաղաքականության վավերացնող՝ ապահովելու, որ համատեքստը Անվտանգության համատեքստ ձեր աշխատանքային ծանրաբեռնվածությունը թույլ չի տալիս, որ կոնտեյները աշխատի ադմինիստրատորի արտոնություններով: Եթե ​​դա պահանջվում է, օգտվողները կարող են կիրառել պարզ քաղաքականություն ռեգո, սրա նման:

package main

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

• Ամպային մատակարարի հետ ինտեգրվելու տարբերակներ: Այսօրվա բարձր տեխնոլոգիաների ամենաուշագրավ միտումներից մեկը հանրային ամպային մատակարարների վրա աշխատանքային ծանրաբեռնվածություն գործարկելն է: Օգտագործելով բաղադրիչը ամպային մատակարար Kubernetes-ը թույլ է տալիս ցանկացած կլաստերի ինտեգրվել ամպային մատակարարի հետ, որի վրա այն աշխատում է: Օրինակ, եթե օգտատերը AWS-ով գործարկում է հավելված Kubernetes-ում և ցանկանում է բացահայտել այդ հավելվածը ծառայության միջոցով, ամպային մատակարարն օգնում է ավտոմատ կերպով ստեղծել ծառայությունը: LoadBalancerորը ավտոմատ կերպով կտրամադրի բեռի հավասարակշռիչը Amazon Elastic Load Balancerերթևեկությունը վերահղելու դեպի հավելվածների պատյաններ:

Ընդարձակելիություն

Kubernetes-ը շատ ընդարձակելի է, և մշակողները սիրում են այն: Կա մի շարք մատչելի ռեսուրսներ, ինչպիսիք են պատյանները, տեղակայումները, StatefulSets, գաղտնիքներ, ConfigMapsև այլն։ Ճիշտ է, օգտվողներն ու մշակողները կարող են այլ ռեսուրսներ ավելացնել ձևի մեջ մաքսային ռեսուրսների սահմանումներ.

Օրինակ, եթե ուզում ենք ռեսուրս սահմանել CronTab, ապա դուք կարող եք նման բան անել.

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

Ավելի ուշ մենք կարող ենք ստեղծել CronTab ռեսուրս նման բան.

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

Kubernetes-ում ընդարձակելիության մեկ այլ տարբերակ այն է, որ մշակողը կարող է գրել իր սեփական հայտարարությունները: Օպերատոր հատուկ գործընթաց է Kubernetes կլաստերում, որն աշխատում է համաձայն «կառավարման միացում« Օպերատորի օգնությամբ օգտատերը կարող է ավտոմատացնել CRD-ների կառավարումը (մաքսային ռեսուրսների սահմանումներ)՝ տեղեկատվություն փոխանակելով Kubernetes API-ի հետ։

Համայնքում կան մի քանի գործիքներ, որոնք ծրագրավորողների համար հեշտացնում են սեփական օպերատորների ստեղծումը: Նրանց մեջ - Օպերատորի շրջանակ իսկ Օպերատոր SDK. Այս SDK-ն ապահովում է հիմք, որից ծրագրավորողը կարող է արագ սկսել օպերատոր ստեղծել: Ենթադրենք, դուք կարող եք սկսել հրամանի տողից նման բան.

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

Սա ստեղծում է ձեր օպերատորի համար կաթսայի բոլոր ծածկագիրը, ներառյալ YAML ֆայլերը և 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

Այնուհետև կարող եք ավելացնել անհրաժեշտ API-ները և վերահսկիչները, այսպես.

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

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

Այնուհետև, վերջապես, հավաքեք օպերատորը և ուղարկեք այն ձեր կոնտեյների գրանցամատյան.

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

Եթե ​​մշակողը ցանկանում է ավելի շատ վերահսկողություն ունենալ, ապա Go ֆայլերում կաթսայի ծածկագիրը կարող է փոխվել: Օրինակ, կարգավորիչի առանձնահատկությունները փոփոխելու համար կարող եք փոփոխություններ կատարել ֆայլում controller.go.

Մեկ այլ նախագիծ ԱՄԵՆ ՈՒՐ, թույլ է տալիս ստեղծել հայտարարություններ՝ օգտագործելով միայն դեկլարատիվ YAML ֆայլեր: Օրինակ, Apache Kafka-ի օպերատորը կսահմանվի մոտավորապես այնքան. Դրա միջոցով դուք կարող եք տեղադրել Kafka կլաստեր Kubernetes-ի վերևում ընդամենը մի քանի հրամաններով.

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Եվ այնուհետև կարգավորեք այն մեկ այլ հրամանով.

$ 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

Նորարարություն

Վերջին մի քանի տարիների ընթացքում Kubernetes-ի հիմնական թողարկումները դուրս են գալիս մի քանի ամիսը մեկ, այսինքն՝ տարեկան երեքից չորս հիմնական թողարկում: Նրանցից յուրաքանչյուրում ներդրված նոր հնարավորությունների թիվը չի նվազում։ Ավելին, նույնիսկ այս դժվարին ժամանակներում դանդաղելու նշաններ չկան՝ տեսեք, թե ինչ վիճակ է հիմա Kubernetes նախագծի գործունեությունը Github-ում.

Նոր հնարավորությունները թույլ են տալիս ավելի ճկուն կերպով խմբավորել գործողությունները տարբեր ծանրաբեռնվածությամբ: Բացի այդ, ծրագրավորողներն ավելի մեծ վերահսկողություն են վայելում, երբ հավելվածներն ուղղակիորեն արտադրում են:

Համայնք

Kubernetes-ի հանրաճանաչության մեկ այլ կարևոր կողմը նրա համայնքի հզորությունն է: 2015 թվականին, 1.0 տարբերակին հասնելուց հետո, Kubernetes-ը հովանավորվեց Cloud բնիկների հաշվարկների հիմնադրամ.

Կան նաև տարբեր համայնքներ SIG (Հատուկ հետաքրքրությունների խմբեր) կենտրոնացել են Kubernetes-ի տարբեր ոլորտներում աշխատելու վրա, քանի որ նախագիծը զարգանում է: Այս խմբերն անընդհատ ավելացնում են նոր հնարավորություններ՝ ավելի հարմար և հարմարավետ դարձնելով Kubernetes-ի հետ աշխատանքը։

Cloud Native հիմնադրամը նաև հյուրընկալում է CloudNativeCon/KubeCon-ին, որը գրելու պահին աշխարհի ամենամեծ բաց կոդով համաժողովն է: Այն սովորաբար անցկացվում է տարին երեք անգամ և համախմբում է հազարավոր մասնագետների, ովքեր ցանկանում են բարելավել Kubernetes-ը և նրա էկոհամակարգը, ինչպես նաև սովորել նոր հնարավորություններ, որոնք հայտնվում են երեք ամիսը մեկ:

Ավելին, Cloud Native հիմնադրամն ունի Տեխնիկական վերահսկողության հանձնաժողով, որը SIG-ների հետ միասին վերանայում է նորը և գոյություն ունեցողը Ծրագրեր միջոցներ, որոնք ուղղված են ամպային էկոհամակարգին: Այս նախագծերի մեծ մասն օգնում է բարելավել Kubernetes-ի ուժեղ կողմերը:

Վերջապես, ես հավատում եմ, որ Kubernetes-ը չէր լինի այնքան հաջող, որքան դա առանց ողջ համայնքի գիտակցված ջանքերի, որտեղ մարդիկ մնում են միասին, բայց միևնույն ժամանակ ողջունում են նորեկներին:

Ապագան

Հիմնական մարտահրավերներից մեկը, որով ծրագրավորողները պետք է զբաղվեն ապագայում, հենց կոդի մանրամասների վրա կենտրոնանալու ունակությունն է, այլ ոչ թե այն ենթակառուցվածքի վրա, որտեղ այն աշխատում է: Այն համապատասխանում է այս միտումներին առանց սերվերի ճարտարապետական ​​պարադիգմ, որն այսօր առաջատարներից է։ Ընդլայնված շրջանակներ արդեն գոյություն ունեն, օրինակ. Տաբատ и OpenFaas, որոնք օգտագործում են Kubernetes-ը՝ մշակողից ենթակառուցվածքը վերացարկելու համար։

Այս հոդվածում մենք միայն քերծեցինք Կուբերնետեսի ներկայիս վիճակի մակերեսը, իրականում դա այսբերգի միայն ծայրն է: Kubernetes-ի օգտատերերն իրենց տրամադրության տակ ունեն բազմաթիվ այլ ռեսուրսներ, հնարավորություններ և կոնֆիգուրացիաներ:

Source: www.habr.com