За нарастващата популярност на Kubernetes

Хей Хабр!

В края на лятото искаме да ви напомним, че продължаваме да работим по темата Kubernetes и реши да публикува статия от Stackoverflow, демонстрираща състоянието на нещата в този проект в началото на юни.

Насладете се на четенето

Към момента на писане на тази статия възрастта на Kubernetes е приблизително. шест годишен, а през последните две години популярността му нарасна толкова много, че неизменно се класира сред най-любимият платформи. Kubernetes се нарежда на трето място тази година. За да обобщим: Kubernetes е платформа, предназначена за изпълнение и оркестриране на контейнеризирани работни натоварвания.

Контейнерите започнаха като специален дизайн за изолиране на процеси в Linux; контейнери са включени от 2007 г c групи, а от 2002 г. – пространства от имена. Контейнерите бяха проектирани още по-добре до 2008 г., когато станаха достъпни LXC, а Google разработи свой собствен вътрешен корпоративен механизъм, наречен Борг, където „цялата работа се извършва в контейнери“. Оттук бързаме напред към 2013 г., когато се състоя първото издание на Docker и контейнерите най-накрая станаха популярно масово решение. По това време основният инструмент за оркестрация на контейнери беше Месос, въпреки че не беше особено популярен. Kubernetes беше пуснат за първи път през 2015 г., след което този инструмент стана де факто стандарт в областта на оркестрацията на контейнери.

За да се опитаме да разберем защо Kubernetes е толкова популярен, нека се опитаме да отговорим на няколко въпроса. Кога за последен път разработчиците успяха да се споразумеят как да разположат приложенията в производствената среда? Колко разработчици познавате, които използват инструментите, тъй като те са предоставени от кутията? Колко облачни администратори има днес, които не разбират как работят приложенията? Ще разгледаме отговорите на тези въпроси в тази статия.

Инфраструктура като YAML

В света, преминал от Puppet и Chef към Kubernetes, една от най-големите промени беше преминаването от „инфраструктура като код“ към „инфраструктура като данни“ – по-специално като 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. Този подход ви позволява да съхранявате всички YAML файлове на Kubernetes в 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 позволява на всеки клъстер да се интегрира с облачния доставчик, на който работи. Например, ако потребител стартира приложение в 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 ще бъде дефиниран приблизително така. С него можете да инсталирате клъстер 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 беше спонсориран от Фондация за облачни компютри в облака.

Има и различни общности SIG (Групи със специални интереси), фокусирани върху работата върху различни области на Kubernetes, докато проектът се развива. Тези групи непрекъснато добавят нови функции, което прави работата с Kubernetes по-удобна и удобна.

Cloud Native Foundation също е домакин на CloudNativeCon/KubeCon, който към момента на писане е най-голямата конференция с отворен код в света. Обикновено се провежда три пъти годишно и събира хиляди професионалисти, които искат да подобрят Kubernetes и неговата екосистема, както и да научат нови функции, които се появяват на всеки три месеца.

Освен това Cloud Native Foundation има Комисия за технически надзор, който заедно със SIG преглежда нови и съществуващи Проекти средства, фокусирани върху облачната екосистема. Повечето от тези проекти помагат за подобряване на силните страни на Kubernetes.

И накрая, вярвам, че Kubernetes не би бил толкова успешен, колкото е, без съзнателните усилия на цялата общност, където хората се държат заедно, но в същото време приветстват новодошлите в кошарата.

Бъдещето

Едно от основните предизвикателства, с които разработчиците ще трябва да се справят в бъдеще, е способността да се фокусират върху детайлите на самия код, а не върху инфраструктурата, в която той работи. Отговаря на тези тенденции безсървърна архитектурна парадигма, който днес е един от водещите. Вече съществуват разширени рамки, напр. кнатив и OpenFaas, които използват Kubernetes, за да абстрахират инфраструктурата от разработчика.

В тази статия ние само надраскахме повърхността на текущото състояние на Kubernetes – всъщност това е само върхът на айсберга. Потребителите на Kubernetes имат много други ресурси, възможности и конфигурации на свое разположение.

Източник: www.habr.com