د کوبرنیټس لپاره چلونکي: د دولتي غوښتنلیکونو چلولو څرنګوالی

په Kubernetes کې د دولتي غوښتنلیکونو ستونزه

د غوښتنلیکونو او خدماتو ترتیب کول، پیل کول او نور پیمانه کول اسانه دي کله چې د بې ریاسته په توګه طبقه بندي شوي قضیو ته راځي، د بیلګې په توګه. پرته د معلوماتو خوندي کول. د دې معیاري APIs په کارولو سره په Kubernetes کې دا ډول خدمات پرمخ وړل اسانه دي ، ځکه چې هرڅه د بکس څخه بهر پیښیږي: د معیاري تشکیلاتو سره سم ، پرته له کوم مشخصاتو یا جادو څخه.

په ساده ډول ، د کانټینرونو په کلستر کې په PHP/Ruby/Python کې د بیک انډ پنځه نورې کاپي پیلولو لپاره ، تاسو اړتیا لرئ یوازې 5 ځله نوی سرور تنظیم کړئ او سرچینې کاپي کړئ. څرنګه چې د سرچینې کوډ او init سکریپټ دواړه په عکس کې دي، نو د بې ریاست غوښتنلیک اندازه کول په بشپړ ډول ابتدايي کیږي. لکه څنګه چې د کانټینرونو مینه وال او د مایکرو سرویس جوړښت ښه پوهیږي، مشکل له سره پیل کیږي دولتي اطلاقات، i.e. د ډیټا دوام سره لکه ډیټابیسونه او کیچونه (MySQL، PostgreSQL، Redis، ElasticSearch، Cassandra...). دا په دواړو سافټویرونو باندې تطبیق کیږي چې په خپلواکه توګه د کورم کلستر پلي کوي (د مثال په توګه، Percona XtraDB او Cassandra)، او هغه سافټویر چې جلا مدیریت اسانتیاوو ته اړتیا لري (لکه Redis، MySQL، PostgreSQL...).

ستونزې رامینځته کیږي ځکه چې د سرچینې کوډ او د خدماتو پیل کول نور کافي ندي - تاسو اړتیا لرئ یو څه نور ګامونه ترسره کړئ. لږترلږه، ډاټا کاپي کړئ او/یا په کلستر کې شامل شئ. په دقیق ډول، دا خدمتونه د دې پوهیدلو ته اړتیا لري چې څنګه د معلوماتو له لاسه ورکولو یا لنډمهاله شتون پرته په سمه توګه اندازه کول، تازه کول او بیا تنظیم کول. د دې اړتیاوو په پام کې نیولو سره "عملي پوهه" بلل کیږي.

د CoreOS آپریټرونه

د "پروګرام" عملیاتي پوهې لپاره، د تیر کال په وروستیو کې د CoreOS پروژه معرفي شوی د کوبرنیټس پلیټ فارم لپاره "د سافټویر نوې ټولګي" - آپریټرونه (د انګلیسي "عملیات" څخه، د بیلګې په توګه "عملیات").

آپریټرونه د Kubernetes اصلي وړتیاوې کاروي او پراخوي (په شمول. StatefulSets، لاندې توپیر وګورئ) د DevOps متخصصینو ته اجازه ورکړئ چې د غوښتنلیک کوډ کې عملیاتي پوهه اضافه کړي.

د آپریټر موخه - کارونکي ته یو API چمتو کړئ چې تاسو ته اجازه درکوي د کوبرنیټس کلستر کې ډیری دولتي غوښتنلیک ادارې اداره کړئ ، پرته له دې چې فکر وکړئ چې د هوډ لاندې څه دي (کوم ډیټا او څه باید ورسره وشي ، د کلسټر ساتلو لپاره کوم حکمونه لاهم اجرا کولو ته اړتیا لري) ). په حقیقت کې ، آپریټر ډیزاین شوی ترڅو د امکان تر حده په کلستر کې د غوښتنلیک سره کار ساده کړي ، د عملیاتي دندو اجرا کول اتومات کوي چې دمخه باید په لاسي ډول حل شوي وي.

څنګه چلونکي کار کوي

ReplicaSets Kubernetes تاسو ته اجازه درکوي د چلولو پوډونو مطلوب شمیر مشخص کړئ، او کنټرولر ډاډ ترلاسه کوي چې د دوی شمیر ساتل کیږي (د پوډونو په جوړولو او حذف کولو سره). یو آپریټر په ورته ډول کار کوي، د معیاري Kubernetes سرچینې او کنټرولر ته د عملیاتي پوهې سیټ اضافه کوي چې تاسو ته اجازه درکوي د اړتیا وړ شمیر غوښتنلیکونو مالتړ لپاره اضافي کړنې ترسره کړئ.

دا څنګه توپیر لري StatefulSets، د غوښتنلیکونو لپاره ډیزاین شوی چې کلستر ته اړتیا لري ترڅو دوی ته دولتي سرچینې چمتو کړي لکه د ډیټا ذخیره یا جامد IPs؟ د داسې غوښتنلیکونو لپاره، آپریټر کولی شي کار واخلي StatefulSets (پرځای یې ReplicaSets) د بنسټ په توګه، وړاندیز اضافي اتومات: د حادثې په صورت کې اړین عملونه ترسره کړئ، بیک اپ جوړ کړئ، ترتیب تازه کړئ، او داسې نور.

او همداسې، دا ټول څنګه کار کوي؟ آپریټر یو مدیر ډیمون دی چې:

1. په Kubernetes کې د پیښې API کې ګډون کوي؛
2. له دې څخه د سیسټم په اړه معلومات ترلاسه کوي (د هغې په اړه ReplicaSets, د ريبلو, خدمتونه او همداسی پسی.)؛
3. په اړه معلومات ترلاسه کوي د دریمې ډلې سرچینې (لاندې مثالونه وګورئ)؛
4. ظاهري/بدلون ته غبرګون ښيي د دریمې ډلې سرچینې (د مثال په توګه، د اندازې بدلولو لپاره، نسخه بدل کړئ، او داسې نور)؛
5. د سیسټم په حالت کې بدلونونو ته غبرګون ښیې (د هغې په اړه ReplicaSets, د ريبلو, خدمتونه او همداسی پسی.)؛
6. تر ټولو مهم:
   1. په Kubernetes API باندې غږ کوي ترڅو هرڅه چې ورته اړتیا لري رامینځته کړي (بیا ، خپل ReplicaSets, د ريبلو, خدمتونه...) ،
   2. یو څه جادو ترسره کوي (د ساده کولو لپاره، تاسو فکر کولی شئ چې آپریټر پخپله پوډونو ته ځي او کمانډونه زنګ وهي، د بیلګې په توګه، د کلستر سره یوځای کول یا د نسخې تازه کولو پر مهال د ډیټا بڼه لوړول).

په حقیقت کې، لکه څنګه چې د انځور څخه لیدل کیدی شي، یو جلا غوښتنلیک په ساده ډول په Kubernetes کې اضافه شوی (یو منظم تعین کول с ReplicaSet)، کوم چې د آپریټر په نوم یادیږي. دا په یو عادي پوډ کې ژوند کوي (معمولا یوازې یو) او د یوې قاعدې په توګه، یوازې د هغې لپاره مسؤل دی نوم نوم. دا آپریټر غوښتنلیک خپل API پلي کوي - که څه هم مستقیم نه ، مګر له لارې د دریمې ډلې سرچینې په Kubernetes کې.

په دې توګه، وروسته له دې چې موږ جوړ شو نوم نوم آپریټر، موږ کولی شو دا اضافه کړو د دریمې ډلې سرچینې.

د 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 د انجینرانو لخوا ترلاسه شوي اصلي نمونې رامینځته کړي پداسې حال کې چې په آپریټرونو کار کوي. د دې حقیقت سره سره چې ټول آپریټرونه انفرادي دي (د خپلو ځانګړتیاو او اړتیاو سره د ځانګړي غوښتنلیک لپاره رامینځته شوي) ، د دوی رامینځته کول باید د یو ډول چوکاټ پراساس وي چې لاندې اړتیاوې پلي کوي:

1. نصب باید د یو واحد له لارې ترسره شي تعین کول: kubectl جوړ -f SOME_OPERATOR_URL/deployment.yaml - او اضافي کړنو ته اړتیا نلري.
2. کله چې په کوبرنیټس کې آپریټر نصب کړئ ، نو د دریمې ډلې نوی ډول باید رامینځته شي (د دریمې ډلې سرچینې). د اپلیکیشن مثالونو (کلستر مثالونه) پیل کولو او د دوی نور اداره کولو لپاره (د نسخو تازه کول ، بیا تنظیم کول ، او نور) ، کارونکي به دا ډول وکاروي.
3. هرکله چې امکان ولري ، تاسو باید په کوبرنیټس کې جوړ شوي لومړني توکي وکاروئ ، لکه خدمتونه и ReplicaSetsد ښه ازمول شوي او د پوهیدو وړ کوډ کارولو لپاره.
4. د آپریټرانو شاته مطابقت او د کارونکي لخوا رامینځته شوي سرچینو زړو نسخو ملاتړ ته اړتیا لري.
5. که چیرې آپریټر لیرې شي ، نو غوښتنلیک پخپله باید پرته له بدلونونو فعالیت ته دوام ورکړي.
6. کاروونکي باید وړتیا ولري چې د مطلوب غوښتنلیک نسخه تعریف کړي او د غوښتنلیک نسخه تازه معلومات تنظیم کړي. د سافټویر تازه معلوماتو نشتوالی د عملیاتي او امنیتي ستونزو یوه عامه سرچینه ده، نو چلونکي باید پدې مسله کې د کاروونکو سره مرسته وکړي.
7. آپریټرونه باید د چاوس بندر په څیر د یوې وسیلې سره ازموینه وشي، کوم چې په پوډونو، ترتیبونو، او شبکې کې احتمالي ناکامۍ پیژني.

etcd آپریټر

د آپریټر د تطبیق بیلګه - etcd آپریټر، چمتو شوی د دې مفهوم د اعلان په ورځ. د etcd کلستر ترتیب کول د کورم ساتلو اړتیا له امله پیچلي کیدی شي، د کلستر غړیتوب بیا تنظیم کولو اړتیا، بیک اپ رامینځته کول، او نور. د مثال په توګه ، په لاسي ډول د etcd کلستر اندازه کول پدې معنی دي چې تاسو اړتیا لرئ د نوي کلستر غړي لپاره د DNS نوم رامینځته کړئ ، یو نوی etcd اداره پیل کړئ ، او کلسټر ته د نوي غړي په اړه خبرداری ورکړئ (etcdctl غړی اضافه کړئ). د آپریټر په حالت کې، کاروونکي به یوازې د کلستر اندازه بدلولو ته اړتیا ولري - نور هرڅه به په اوتومات ډول پیښ شي.

او له هغه وخته چې etcd هم په CoreOS کې رامینځته شوی و ، نو دا خورا منطقي و چې د دې آپریټر لومړی څرګند شي. هغه څنګه کار کوي؟ د چلونکي منطق وغيره د دریو برخو لخوا ټاکل کیږي:

1. مشاهده. آپریټر د Kubernetes API په کارولو سره د کلستر حالت څارنه کوي.
2. تحلیل. د اوسني حالت او مطلوب (د کارونکي ترتیب لخوا تعریف شوي) ترمنځ توپیرونه ومومئ.
3. عمل. د etcd او/یا Kubernetes خدماتو APIs په کارولو سره کشف شوي توپیرونه حل کوي.

د دې منطق پلي کولو لپاره، په آپریټر کې دندې چمتو شوي جوړ / ویجاړ کړئ (د etcd کلستر غړو جوړول او حذف کول) او بیاکتنه (د کلستر د غړو په شمیر کې بدلون). د دې عملیاتو درستیت د Netflix څخه د Chaos Monkey په څیر رامینځته شوي یوټیلټي په کارولو سره چیک شوی ، یعنی په تصادفي ډول د etcd پوډونه وژل.

د 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 آپریټر اوسنی حالت د بیټا نسخه ده، چې د چلولو لپاره Kubernetes 1.5.3+ او etcd 3.0+ ته اړتیا لري. د سرچینې کوډ او اسناد (د کارولو لپاره لارښوونې په شمول) شتون لري GitHub.

د CoreOS څخه بل مثال پلي کول رامینځته شوي - د پرومیتیوس آپریټر، مګر دا لاهم په الفا نسخه کې دی (ټول پلان شوي ځانګړتیاوې ندي پلي شوي).

وضعیت او امکانات

د کوبرنیټس آپریټرانو له اعلان څخه 5 میاشتې تیرې شوې. په رسمي CoreOS ذخیره کې لاهم یوازې دوه پلي کول شتون لري (د etcd او Prometheus لپاره). دواړه لاهم خپلو باثباته نسخو ته ندي رسیدلي ، مګر ژمنې هره ورځ لیدل کیږي.

پراختیا کونکي "یو داسې راتلونکي ته تصور کوي چې په کې کاروونکي پوسټګریس آپریټرونه ، کاسندرا آپریټرونه یا ریډیس آپریټرونه په خپلو کوبرنیټس کلسترونو کې نصبوي او د دې غوښتنلیکونو د توزیع وړ ادارو سره په اسانۍ سره کار کوي لکه څنګه چې نن ورځ د بې ریاست ویب غوښتنلیکونو عکس العمل پلي کول دي." لومړی د دریمې ډلې پراختیا کونکو څخه چلونکي واقعیا څرګندیدل پیل کړل:

• Elasticsearch Operator د UPMC شرکتونو څخه؛
• PostgreSQL آپریټر د کرنچي ډیټا څخه (د مارچ 2017 په وروستیو کې اعلان شوی)؛
• روک آپریټر د سیف پر بنسټ د توزیع شوي ډیټا ذخیره کولو سیسټم لیکوالانو څخه (روک په الفا حالت کې دی)؛
• Openstack Operators د SAP CCloud څخه.

په لوی اروپایی وړیا سافټویر کنفرانس کې FOSDEM، چې په بروکسل کې د 2017 په فبروري کې ترسره شو، د CoreOS څخه جوش ووډ په کې آپریټرانو اعلان وکړ. راپور (یو ویډیو په لینک کې شتون لري!)، کوم چې باید د خلاصې سرچینې په پراخه ټولنه کې د دې مفکورې د شهرت وده کې مرسته وکړي.

PS په مقاله کې ستاسو د علاقې لپاره مننه! زموږ مرکز کې ګډون وکړئ، ترڅو په DevOps او GNU/Linux سیسټم اداره کې نوي توکي او ترکیبونه له لاسه ورنکړي - موږ به یې په منظم ډول خپاره کړو!

سرچینه: www.habr.com