За зголемената популарност на Кубернетес

Еј Хабр!

На крајот на летото сакаме да ве потсетиме дека продолжуваме да работиме на темата Кубернети и одлучи да објави напис од Stackoverflow во кој се демонстрира состојбата во овој проект на почетокот на јуни.

Уживајте во читањето!

Во моментот на пишување на овој напис, возраста на Кубернетес е приближно. шест години, а во текот на изминатите две години нејзината популарност порасна толку многу што постојано се рангира меѓу нив најомилен платформи. Кубернетес е на третото место оваа година. Да повториме: Kubernetes е платформа дизајнирана за водење и оркестрирање на оптоварувања со контејнери.

Контејнерите започнаа како посебен дизајн за изолирање на процесите во Linux; контејнерите се вклучени од 2007 година групите, а од 2002 година – именски простори. Контејнерите беа дизајнирани уште подобро до 2008 година, кога станаа достапни LXC, и Google разви свој внатрешен корпоративен механизам наречен Борг, каде што „целата работа се врши во контејнери“. Оттука брзо напредуваме до 2013 година, кога се случи првото издание на Docker, а контејнерите конечно станаа популарно масовно решение. Во тоа време, главната алатка за контејнерска оркестрација беше Месос, иако тој не беше многу популарен. Kubernetes првпат беше објавен во 2015 година, по што оваа алатка стана де факто стандард во областа на оркестрација на контејнери.

За да се обидеме да разбереме зошто Кубернетес е толку популарен, ајде да се обидеме да одговориме на неколку прашања. Кога последен пат програмерите можеа да се договорат за тоа како да распоредат апликации во производство? Колку програмери познавате кои ги користат алатките бидејќи тие се обезбедени надвор од кутијата? Колку администратори на облак има денес кои не разбираат како функционираат апликациите? Одговорите на овие прашања ќе ги разгледаме во оваа статија.

Инфраструктура како 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 складишта, за да можете да следите кога точно е направена промена, кој ја направил и што точно се променило. Ова ја зголемува транспарентноста на операциите низ целата организација и ја подобрува оперативната ефикасност со елиминирање на нејаснотијата, особено каде што вработените треба да ги бараат ресурсите што им се потребни. Во исто време, станува полесно автоматски да се прават промени во ресурсите на Кубернетес со едноставно спојување на барање за повлекување.
• Приспособливост. Кога ресурсите се дефинираат како 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 дозволува кој било кластер да се интегрира со провајдерот на облак на кој работи. На пример, ако корисникот работи апликација во Kubernetes на AWS и сака да ја изложи таа апликација преку услуга, давателот на облак помага автоматски да се создаде услугата 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 би се дефинирал приближно така. Со него, можете да инсталирате кластер на Кафка на врвот на 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.

Новите способности ви овозможуваат пофлексибилно да ги групирате операциите низ различни оптоварувања. Покрај тоа, програмерите уживаат поголема контрола при распоредување на апликации директно во производството.

Заедница

Друг главен аспект на популарноста на Кубернетес е силата на неговата заедница. Во 2015 година, по достигнувањето на верзијата 1.0, Kubernetes беше спонзориран од Фондација за Cloud Native Computing.

Постојат и различни заедници ГРУ (Специјални интересни групи) се фокусираа на работа на различни области на Кубернетес како што се развива проектот. Овие групи постојано додаваат нови функции, што ја прави работата со Kubernetes поудобна и поудобна.

Фондацијата Cloud Native, исто така, е домаќин на CloudNativeCon/KubeCon, која, во моментот на пишувањето, е најголемата конференција со отворен код во светот. Обично се одржува три пати годишно, собира илјадници професионалци кои сакаат да го подобрат Kubernetes и неговиот екосистем, како и да научат нови функции што се појавуваат на секои три месеци.

Покрај тоа, Cloud Native Foundation има Одбор за технички надзор, кој заедно со SIG ги разгледува новите и постоечките Проекти средства фокусирани на облак екосистемот. Повеќето од овие проекти помагаат да се подобрат силните страни на Kubernetes.

Конечно, верувам дека Kubernetes не би бил толку успешен како што е без свесните напори на целата заедница, каде што луѓето се држат заедно, но во исто време ги пречекуваат новодојденците во јатото.

Иднината

Еден од главните предизвици со кои ќе треба да се справат програмерите во иднина е можноста да се фокусираат на деталите на самиот код, а не на инфраструктурата во која работи. Ги исполнува овие трендови архитектонска парадигма без сервери, која е една од водечките денес. Напредните рамки веќе постојат, на пр. Ноктивен и OpenFaas, кои користат Kubernetes за апстракција на инфраструктурата од развивачот.

Во оваа статија, ја изгребавме само површината на моменталната состојба на Кубернетес - всушност, тоа е само врвот на ледениот брег. Корисниците на Kubernetes имаат на располагање многу други ресурси, можности и конфигурации.

Извор: www.habr.com