Kubernetes дахь төлөвтэй програмуудтай холбоотой асуудал
Харьяалалгүй гэж ангилагдсан тохиолдлуудын хувьд програм, үйлчилгээг тохируулах, эхлүүлэх, цаашдын цар хүрээг нэмэгдүүлэх нь хялбар байдаг. өгөгдөл хадгалахгүйгээр. Kubernetes-д ийм үйлчилгээг стандарт API-уудыг ашиглан ажиллуулах нь тохиромжтой, учир нь бүх зүйл "хайрцагнаас гадуур" тохиолддог: стандарт тохиргооны дагуу, ямар ч онцлог, ид шидийн оролцоогүйгээр.
Энгийнээр хэлэхэд, PHP/Ruby/Python-д дахин таван хуулбарыг контейнерийн кластерт ажиллуулахын тулд та ердөө 5 удаа шинэ сервер суулгаж, эх сурвалжуудыг хуулах хэрэгтэй. Эх код болон init скрипт хоёулаа зураг дээр байгаа тул харьяалалгүй програмыг масштаблах нь бүрэн энгийн зүйл болж хувирдаг. Контейнер болон микро үйлчилгээний архитектурын шүтэн бишрэгчид сайн мэддэг тул бэрхшээл нь үүнээс эхэлдэг төлөвтэй програмууд, өөрөөр хэлбэл Өгөгдлийн сан, кэш (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...) зэрэг өгөгдлийн тогтвортой байдал. Энэ нь чуулгын кластерийг бие даан хэрэгжүүлдэг програм хангамж (жишээ нь, Percona XtraDB болон Cassandra) болон тусдаа удирдлагын хэрэгслүүд (Redis, MySQL, PostgreSQL... гэх мэт) шаарддаг программ хангамжид хоёуланд нь хамаарна.
Эх код болон үйлчилгээг эхлүүлэх нь хангалтгүй болсон тул хүндрэлүүд гарч ирдэг - та хэд хэдэн алхам хийх хэрэгтэй. Хамгийн багадаа өгөгдлийг хуулж,/эсвэл кластерт нэгдээрэй. Нарийвчлан хэлэхэд, эдгээр үйлчилгээ нь өгөгдөл алдагдуулах, түр зуур ашиглах боломжгүй болгохгүйгээр тэдгээрийг хэрхэн зөв масштаблах, шинэчлэх, дахин тохируулах талаар ойлголттой байхыг шаарддаг. Эдгээр хэрэгцээг харгалзан үзэхийг "үйл ажиллагааны мэдлэг" гэж нэрлэдэг.
CoreOS операторууд
Үйл ажиллагааны мэдлэгийг "програмчлах" зорилгоор өнгөрсөн оны сүүлээр CoreOS төсөл Kubernetes платформын "шинэ ангиллын програм хангамж" - Операторууд (Англи хэлнээс "үйл ажиллагаа", өөрөөр хэлбэл "үйл ажиллагаа").
Kubernetes-ийн үндсэн чадавхийг ашиглаж, өргөтгөж буй операторууд (үүнд орно. Stateful Sets, доорх ялгааг харна уу) DevOps мэргэжилтнүүдэд програмын кодонд үйлдлийн мэдлэг нэмэх боломжийг олгоно.
Операторын зорилго — хэрэглэгчдэд Kubernetes кластерт байгаа хэд хэдэн төлөвтэй програмын нэгжүүдийг удирдах боломжийг олгодог API-ээр хангах, бүрээсийн доор юу байгааг (ямар өгөгдөл, үүнтэй юу хийх, кластерыг хадгалахын тулд ямар тушаалуудыг гүйцэтгэх шаардлагатай) талаар бодохгүйгээр. ). Үнэн хэрэгтээ Оператор нь кластер доторх програмтай ажиллах ажлыг аль болох хялбарчилж, өмнө нь гараар шийдэх ёстой байсан үйлдлийн даалгавруудыг автоматжуулах зорилготой юм.
Операторууд хэрхэн ажилладаг
ReplicaSets Kubernetes нь танд хүссэн тооны ажиллаж байгаа pods-ыг зааж өгөх боломжийг олгодог бөгөөд хянагч нь тэдгээрийн тоог хадгалах (подыг үүсгэх, устгах замаар) баталгаажуулдаг. Оператор нь ижил төстэй аргаар ажилладаг бөгөөд стандарт Kubernetes нөөц ба хянагч дээр үйлдлийн мэдлэгийг нэмж өгдөг бөгөөд энэ нь танд шаардлагатай тооны хэрэглээний нэгжийг дэмжих нэмэлт үйлдлүүдийг хийх боломжийг олгодог.
Энэ юугаараа ялгаатай вэ Stateful Sets, кластер нь өгөгдөл хадгалах эсвэл статик IP гэх мэт төлөв байдлын нөөцөөр хангахыг шаарддаг програмуудад зориулагдсан уу? Ийм програмуудын хувьд Операторууд ашиглаж болно Stateful Sets (оронд нь ReplicaSets) үндэс болгон, санал болгох нэмэлт автоматжуулалт: гэмтэл гарсан тохиолдолд шаардлагатай үйлдлүүдийг хийх, нөөцлөлт хийх, тохиргоог шинэчлэх гэх мэт.
Тэгэхээр энэ бүхэн яаж ажилладаг вэ? Оператор нь менежерийн демон юм:
- Kubernetes дахь үйл явдлын API-г захиалсан;
- түүнээс системийн талаарх мэдээллийг хүлээн авдаг (түүний тухай ReplicaSets, занга, үйлчилгээ гэх мэт.);
- тухай мэдээлэл хүлээн авдаг Гуравдагч этгээдийн нөөц (доорх жишээг үзнэ үү);
- гадаад төрх/өөрчлөлтөд хариу үйлдэл үзүүлдэг Гуравдагч этгээдийн нөөц (жишээлбэл, хэмжээг өөрчлөх, хувилбарыг өөрчлөх гэх мэт);
- системийн төлөв байдлын өөрчлөлтөд хариу үйлдэл үзүүлдэг (түүний тухай ReplicaSets, занга, үйлчилгээ гэх мэт.);
- Хамгийн гол:
- Kubernetes API-г дуудаж өөрт хэрэгтэй бүх зүйлээ (дахин өөрийн гэсэн ReplicaSets, занга, үйлчилгээ...),
- зарим ид шидийг гүйцэтгэдэг (хялбаршуулахын тулд та Оператор өөрөө pods руу орж командуудыг дууддаг гэж бодож болно, жишээлбэл, кластерт нэгдэх эсвэл хувилбарыг шинэчлэх үед өгөгдлийн форматыг шинэчлэх).
Үнэн хэрэгтээ, зургаас харахад Kubernetes-д тусдаа програмыг нэмж оруулсан болно (ердийн байрлуулалт с ReplicaSet), үүнийг Оператор гэж нэрлэдэг. Энэ нь ердийн хонхорцог (ихэвчлэн нэг) амьдардаг бөгөөд дүрмээр бол зөвхөн түүний төлөө хариуцлага хүлээдэг Нэрийн талбар. Энэхүү оператор програм нь өөрийн API-г шууд биш, харин дамжуулан хэрэгжүүлдэг Гуравдагч этгээдийн нөөц Кубернетес хотод.
Тиймээс бид бүтээсний дараа Нэрийн талбар Оператор, бид үүнийг нэмж болно Гуравдагч этгээдийн нөөц.
Жишээ нь etcd (дэлгэрэнгүйг доороос үзнэ үү):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Elasticsearch-ийн жишээ:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Операторуудад тавигдах шаардлага
CoreOS нь Оператор дээр ажиллаж байхдаа инженерүүдийн олж авсан үндсэн загваруудыг томъёолсон. Бүх операторууд нь хувь хүн байдаг (өөрийн онцлог, хэрэгцээтэй тусгай хэрэглээнд зориулж бүтээгдсэн) хэдий ч тэдгээрийг бий болгох нь дараахь шаардлагыг тавьдаг нэг төрлийн тогтолцоонд суурилсан байх ёстой.
- Суурилуулалтыг дангаар нь хийх ёстой байрлуулалт: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - нэмэлт үйлдэл хийх шаардлагагүй.
- Kubernetes-д оператор суулгах үед гуравдагч талын шинэ төрлийг үүсгэх шаардлагатай (ThirdPartyResource). Хэрэглээний тохиолдлуудыг (кластерийн тохиолдлууд) ажиллуулж, цаашид удирдахын тулд (хувилбаруудыг шинэчлэх, хэмжээг өөрчлөх гэх мэт) хэрэглэгч энэ төрлийг ашиглана.
- Боломжтой бол та Kubernetes-д суулгасан командуудыг ашиглах хэрэгтэй үйлчилгээ и ReplicaSetsсайн шалгагдсан, ойлгомжтой код ашиглах.
- Операторуудын хоцрогдсон нийцтэй байдал, хэрэглэгчийн үүсгэсэн нөөцийн хуучин хувилбаруудад дэмжлэг үзүүлэх шаардлагатай.
- Хэрэв Операторыг устгасан бол програм өөрөө үргэлжлүүлэн ажиллах ёстой.
- Хэрэглэгчид хүссэн програмын хувилбарыг тодорхойлж, програмын хувилбарын шинэчлэлтийг зохицуулах боломжтой байх ёстой. Програм хангамжийн шинэчлэлт байхгүй байгаа нь үйл ажиллагааны болон аюулгүй байдлын асуудлын нийтлэг эх үүсвэр болдог тул операторууд энэ асуудалд хэрэглэгчдэд туслах ёстой.
- Операторуудыг Chaos Monkey гэх мэт хэрэгслээр турших хэрэгтэй бөгөөд энэ нь хонхорцог, тохиргоо болон сүлжээнд гарч болзошгүй алдааг тодорхойлдог.
etcd оператор
Операторын хэрэгжилтийн жишээ - etcd оператор, энэ үзэл баримтлалыг зарласан өдөр. etcd кластерын тохиргоо нь чуулга хадгалах, кластерийн гишүүнчлэлийг дахин тохируулах, нөөцлөлт үүсгэх гэх мэт шаардлагаас шалтгаалж төвөгтэй байж болно. Жишээлбэл, etcd кластерыг гараар масштаблах нь та шинэ кластерийн гишүүнд DNS нэр үүсгэх, шинэ etcd нэгж эхлүүлэх, кластерт шинэ гишүүний талаар сэрэмжлүүлэх шаардлагатай гэсэн үг юм (etcdctl гишүүн нэмнэ). Операторын хувьд хэрэглэгч зөвхөн кластерын хэмжээг өөрчлөх шаардлагатай болно - бусад бүх зүйл автоматаар хийгдэх болно.
Мөн etcd нь CoreOS дээр бүтээгдсэн тул түүний Оператор эхлээд гарч ирэх нь үнэхээр логик байсан. Тэр яаж ажилладаг вэ? Операторын логик гэх мэт Гурван бүрэлдэхүүнээр тодорхойлогддог.
- Ажиглах. Оператор нь Kubernetes API ашиглан кластерийн төлөвийг хянадаг.
- Шинжилгээ. Одоогийн байдал болон хүссэн (хэрэглэгчийн тохиргоогоор тодорхойлогддог) хоорондын ялгааг олно.
- Үйлдэл. etcd болон/эсвэл Kubernetes үйлчилгээний API-г ашиглан илрүүлсэн ялгааг шийддэг.
Энэ логикийг хэрэгжүүлэхийн тулд Оператор дээр функцуудыг бэлтгэсэн Үүсгэх/устгах ( etcd кластерийн гишүүдийг үүсгэх, устгах) болон хэмжээг (кластерийн гишүүдийн тооны өөрчлөлт). Түүний үйл ажиллагааны зөв эсэхийг Netflix-ийн Chaos Monkey-тэй төстэй байдлаар бүтээсэн хэрэглүүрийг ашиглан шалгасан. etcd хонхорцог санамсаргүй байдлаар устгах.
etcd-г бүрэн ажиллуулахын тулд Оператор нэмэлт боломжуудыг хангадаг: Нөөцлөх (Хэрэглэгчдэд автоматаар, үл үзэгдэх нөөц хуулбар үүсгэх - тохиргоонд тэдгээрийг хэр олон удаа хийх, хичнээн хадгалахыг тодорхойлоход хангалттай - мөн тэдгээрээс өгөгдлийг дараа нь сэргээх) ба шинэчлэх (сууралгүйгээр гэх мэт суулгацуудыг шинэчлэх).
Оператортой ажиллах нь ямар харагддаг вэ?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
etcd Operator-ийн одоогийн байдал нь бета хувилбар бөгөөд ажиллахын тулд Kubernetes 1.5.3+ болон etcd 3.0+ шаардлагатай. Эх код болон баримт бичиг (ашиглах зааврыг оруулаад) эндээс авах боломжтой .
CoreOS-ээс хэрэгжүүлэлтийн өөр нэг жишээ бий болсон - , гэхдээ альфа хувилбарт хэвээр байна (төлөвлөсөн бүх функцууд хэрэгжээгүй).
Байдал ба хэтийн төлөв
Kubernetes Operators зарласнаас хойш 5 сар өнгөрчээ. Албан ёсны CoreOS репозиторид (etcd болон Prometheus-д зориулсан) хоёрхон хувилбар байсаар байна. Хоёулаа тогтвортой хувилбартаа хараахан хүрээгүй байгаа ч үйлдлүүд нь өдөр бүр ажиглагддаг.
Хөгжүүлэгчид "хэрэглэгчид Postgres Operators, Cassandra Operators эсвэл Redis Operators-ийг өөрсдийн Kubernetes кластер дээрээ суулгаж, эдгээр програмуудын өргөтгөх боломжтой нэгжүүдтэй өнөөдөр харъяалалгүй вэб програмын хуулбарыг байршуулахтай адил хялбархан ажиллах ирээдүй" гэж төсөөлж байна. Эхлээд Гуравдагч талын хөгжүүлэгчдийн операторууд үнэхээр гарч эхэлсэн:
- UPMC Enterprises-аас;
- Crunchy Data-аас (2017 оны XNUMX-р сарын сүүлээр зарласан);
- Ceph дээр суурилсан тархсан өгөгдөл хадгалах системийн зохиогчдоос (Рүүк альфа статустай);
- SAP CCloud-аас.
2017 оны XNUMX-р сард Брюссельд болсон Европын хамгийн том чөлөөт програм хангамжийн бага хурал болох FOSDEM дээр CoreOS-ийн Жош Вүүд операторуудыг зарлав. (Видео бичлэгийг холбоос дээр үзэх боломжтой!), Энэ нь Нээлттэй эх сурвалжийн өргөн хүрээний нийгэмлэгт энэ үзэл баримтлалыг алдаршуулахад хувь нэмэр оруулах ёстой.
PS Нийтлэлийг сонирхож байгаад баярлалаа! Манай төвд бүртгүүлнэ үү, DevOps болон GNU/Linux системийн удирдлагын талаархи шинэ материал, жорыг алдахгүйн тулд бид тэдгээрийг тогтмол нийтлэх болно!
Эх сурвалж: www.habr.com