Эй Хабр!
Жайдын аягында биз теманын үстүндө иштөөнү уланта турганыбызды эскертебиз жана июнь айынын башында бул долбоордогу иштердин абалын көрсөткөн Stackoverflow макаласын жарыялоону чечти.
Happy окуу!
Бул макаланы жазып жаткан учурда, Кубернетестин жашы болжол менен. , жана акыркы эки жылдын ичинде анын популярдуулугу ушунчалык өскөндүктөн, ал ырааттуу түрдө рейтингде турат платформалар. Кубернетес быйыл үчүнчү орунда турат. Эскерте кетсек: Kubernetes - бул контейнердик жүктөрдү иштетүү жана уюштуруу үчүн иштелип чыккан платформа.
Контейнерлер Linux процесстерин изоляциялоо үчүн атайын долбоор катары башталган; контейнерлер 2007-жылдан бери киргизилген , ал эми 2002-жылдан бери – аттар мейкиндиги. Контейнерлер 2008-жылы жеткиликтүү болгондон да жакшыраак иштелип чыккан , жана Google аттуу өзүнүн ички корпоративдик механизмин иштеп чыккан , мында "бардык иш контейнерлерде жасалат". Бул жерден биз 2013-жылга чейин тездик менен алга карайбыз, ал кезде Dockerдин биринчи релизи болуп, контейнерлер акыры популярдуу массалык чечимге айланган. Ал кезде контейнердик оркестрдин негизги куралы болгон , ал абдан популярдуу болгон эмес. Kubernetes биринчи жолу 2015-жылы чыгарылган, андан кийин бул курал контейнер оркестри жаатында иш жүзүндө стандарт болуп калды.
Kubernetes эмне үчүн мынчалык популярдуу экенин түшүнүү үчүн, келгиле, бир нече суроолорго жооп берүүгө аракет кылалы. Качан акыркы жолу иштеп чыгуучулар тиркемелерди өндүрүшкө кантип жайылтуу боюнча макулдаша алышкан? Куралдарды колдонуучу канча иштеп чыгуучуларды билесиз, анткени алар кутудан чыгарылган? Бүгүнкү күндө тиркемелер кантип иштээрин түшүнбөгөн канча булут администраторлору бар? Бул суроолорго жоопту ушул макалада карап чыгабыз.
YAML катары инфраструктура
Куурчак жана ашпозчудан Кубернетеске өткөн дүйнөдө эң чоң өзгөрүүлөрдүн бири "код катары инфраструктурадан" "маалымат катары инфраструктурага", тагыраак айтканда, YAML сыяктуу. Кубернетестеги бардык ресурстарды, анын ичинде подъезддерди, конфигурацияларды, жайгаштырылган инстанцияларды, томдорду ж.б., 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 нерселердин Кубернетеде кантип орнотулгандыгын баалоо үчүн сонун. Мисалы, негизги коопсуздук маселеси сиздин иш жүктөөлөрүңүз администратор эмес колдонуучу катары иштеп жатканына байланыштуу. Мындай учурда бизге куралдар керек болушу мүмкүн , 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, ал автоматтык түрдө жүк балансын камсыз кылат трафикти тиркеме подколоруна багыттоо үчүн.
Кеңейтүү
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 кластериндеги өзгөчө процесс." Оператордун жардамы менен колдонуучу Kubernetes API менен маалымат алмашуу аркылуу CRDлерди башкарууну автоматташтыра алат.
Коомчулукта иштеп чыгуучуларга өз операторлорун түзүүнү жеңилдеткен бир нече куралдар бар. Алардын арасында - жана . Бул SDK иштеп чыгуучу операторду түзө баштай турган негизди камсыз кылат. Келгиле, сиз буйрук сабынан төмөнкүдөй нерсени баштасаңыз болот дейли:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorБул YAML файлдарын жана Голанг кодун кошо алганда, операторуңуз үчүн бардык кодун түзөт:
.
|____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тин негизги релиздери бир нече ай сайын чыгып турат, башкача айтканда, жылына үч-төрт негизги релиз. Алардын ар биринде киргизилген жаңы функциялардын саны азайбайт. Анын үстүнө азыркы кыйын мезгилде да жайлоонун белгилери байкалбайт – азыр абал кандай экенин караңыз .
Жаңы мүмкүнчүлүктөр ар кандай иш жүктөмдөрүндө кластердик операцияларды ийкемдүү кылууга мүмкүндүк берет. Мындан тышкары, программисттер тиркемелерди түздөн-түз өндүрүшкө жайылтууда көбүрөөк көзөмөлгө ээ.
коомчулук
Кубернетестин популярдуулугунун дагы бир негизги аспектиси - анын жамаатынын күчү. 2015-жылы, 1.0 версиясына жеткенде, Kubernetes демөөрчү болгон .
Ошондой эле ар кандай жамааттар бар (Атайын Кызыкчылык топтору) долбоор өнүккөн сайын Kubernetesтин ар кандай аймактарында иштөөгө багытталган. Бул топтор дайыма жаңы функцияларды кошуп, Kubernetes менен иштөөнү ыңгайлуураак жана ыңгайлуу кылып жатышат.
Cloud Native Foundation ошондой эле CloudNativeCon/KubeCon өткөрөт, ал жазуу учурунда дүйнөдөгү эң чоң ачык булак конференциясы болуп саналат. Адатта жылына үч жолу өткөрүлөт, ал Kubernetes жана анын экосистемасын жакшыртууну, ошондой эле үч айда бир пайда болгон жаңы функцияларды үйрөнүүнү каалаган миңдеген адистерди бириктирет.
Мындан тышкары, Cloud Native Foundation бар , алар SIGs менен бирге жаңы жана иштеп жаткандарды карап чыгат булут экосистемасына багытталган каражаттар. Бул долбоорлордун көбү Kubernetes күчтүү жактарын жакшыртууга жардам берет.
Акыр-аягы, мен Кубернетес бүтүндөй коомчулуктун аң-сезимдүү аракеттерисиз ийгиликтүү болбойт деп ишенем, анда адамдар биригип, ошол эле учурда жаңы келгендерди тосуп алышат.
болочок
Келечекте иштеп чыгуучулар чече турган негизги көйгөйлөрдүн бири - ал иштеп жаткан инфраструктурага эмес, коддун деталдарына көңүл буруу мүмкүнчүлүгү. Бул тенденцияларга жооп берет , бул бүгүнкү күндө алдыңкылардын бири. Өркүндөтүлгөн алкактар мурунтан эле бар, мис. и иштеп чыгуучудан инфраструктураны абстракциялоо үчүн Kubernetes колдонушат.
Бул макалада биз Кубернетестин учурдагы абалын сызып чыктык — чындыгында, бул айсбергдин чети гана. Kubernetes колдонуучуларынын карамагында көптөгөн башка ресурстар, мүмкүнчүлүктөр жана конфигурациялар бар.
Source: www.habr.com