Прывітанне, Хабр!
У канцы лета мы хочам нагадаць, што працягваем прапрацоўку тэмы. і вырашылі апублікаваць артыкул са Stackoverflow, якая дэманструе стан спраў у гэтым праекце на пачатак чэрвеня.
Прыемнага чытання!
На момант напісання гэтага артыкула ўзрост Kubernetes складае каля , і за апошнія два гады яго папулярнасць настолькі вырасла, што ён стабільна ўваходзіць у лік платформ. У гэтым годзе Kubernetes займае трэцяе месца. Нагадаем: Kubernetes - гэта платформа, прызначаная для запуску і аркестрацыі кантэйнерных працоўных нагрузак.
Кантэйнеры зарадзіліся як спецыяльная канструкцыя для ізаляцыі працэсаў у Linux; у склад кантэйнераў з 2007 уваходзяць , а з 2002 - прасторы імёнаў. Кантэйнеры аформіліся яшчэ лепш да 2008 году, калі стала даступная , а ў 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 Version. Такі падыход дазваляе трымаць усе YAML-файлы Kubernetes у рэпазітарах git, дзякуючы чаму вы ў дакладнасці можаце адсачыць, калі была занесеная змена, хто яго занёс, і што менавіта змянілася. Дзякуючы гэтаму павялічваецца празрыстасць аперацый у межах усёй арганізацыі, павялічваецца эфектыўнасць працы ў сілу ўхілення неадназначнасці, у прыватнасці, у тым, дзе супрацоўнікі павінны шукаць патрэбныя ім рэсурсы. У той жа час, становіцца прасцей аўтаматычна ўносіць змены ў рэсурсы Kubernetes - шляхам звычайнага зліцця pull-запыту.
- Маштабаванасць. Калі рэсурсы вызначаны ў выглядзе 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, які аўтаматычна падасць балансавальнік нагрузкі , Каб перанакіраваць трафік у поды прыкладанняў.
Пашыральнасць
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 дае аснову, адштурхваючыся ад якой, распрацоўшчык можа вельмі хутка прыступіць да стварэння аператара. Скажам, можна пачаць з каманднага радка прыкладна такім чынам:
$ 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 заключаецца ў сіле яго супольнасці. У 2015 годзе, па дасягненні версіі 1.0, Kubernetes спансаваўся .
Таксама існуюць разнастайныя супольнасці (спецыяльныя групы па інтарэсах), накіраваныя на прапрацоўку розных абласцей Kubernetes па меры таго, як гэты праект развіваецца. Гэтыя гурты ўвесь час дадаюць усё новыя магчымасці, дзякуючы чаму працаваць з Kubernetes становіцца зручней і зручней.
Фонд Cloud Native Foundation таксама праводзіць CloudNativeCon/KubeCon, якая, на момант напісання гэтага тэксту, з'яўляецца найбуйнейшай апенсорснай канферэнцыяй у свеце. Як правіла, яна праводзіцца тры разы на год і збірае тысячы прафесіяналаў, якія жадаюць палепшыць Kubernetes і яго экасістэму, а таксама асвоіць новыя магчымасці, якія з'яўляюцца кожныя тры месяцы.
Больш за тое, у Cloud Native Foundation ёсць , які, сумесна з SIGs разглядае новыя і наяўныя фонду, арыентаваныя на хмарную экасістэму. Большасць з гэтых праектаў дапамагаюць палепшыць моцныя бакі Kubernetes.
Нарэшце, я веру, што Kubernetes не меў бы такога поспеху без усвядомленых намаганняў усёй супольнасці, дзе людзі трымаюцца сябар за сябра, але, у той жа час, з радасцю прымаюць у свае шэрагі пачаткоўцаў.
будучыню
Адзін з асноўных выклікаў, з якімі распрацоўшчыкам давядзецца мець справу ў будучыні, з'яўляецца ўменне засяроджвацца на дэталях самага кода, а не на той інфраструктуры, у якой ён працуе. Менавіта гэтым тэндэнцыям адказвае , якая з'яўляецца сёння адной з кіроўных. Ужо існуюць прасунутыя фрэймворкі, напрыклад, и , якія выкарыстоўваюць Kubernetes для абстрагавання інфраструктуры ад распрацоўніка.
У гэтым артыкуле мы толькі ў агульных рысах разгледзелі цяперашні стан Kubernetes насамрэч, гэта толькі верхавіна айсберга. У распараджэнні ў карыстачоў Kubernetes ёсць і мноства іншых рэсурсаў, магчымасцяў і канфігурацый.
Крыніца: habr.com