راپور په کبرنیټس کې د آپریټر رامینځته کولو عملي مسلو ته وقف شوی ، د دې جوړښت ډیزاین کول او لومړني عملیاتي اصول.
د راپور په لومړۍ برخه کې به موږ په پام کې ونیسو:
- په Kubernetes کې چلونکی څه شی دی او ولې ورته اړتیا ده؛
- څنګه په سمه توګه آپریټر د پیچلو سیسټمونو مدیریت ساده کوي؛
- چلونکی څه کولی شي او څه نشي کولی.
بیا، راځئ چې د آپریټر داخلي جوړښت په اړه بحث وکړو. راځئ چې ګام په ګام د آپریټر جوړښت او عملیات وګورو. راځئ چې په تفصیل سره یې وګورو:
- د آپریټر او Kubernetes ترمنځ تعامل؛
- کوم کارونه چې آپریټر ترسره کوي او کوم کارونه چې دا Kubernetes ته سپاري.
راځئ چې په Kubernetes کې د شارډونو او ډیټابیس نقلونو اداره کولو ته وګورو.
بیا، موږ به د معلوماتو ذخیره کولو مسلو په اړه بحث وکړو:
- د آپریټر له نظره د دوامداره ذخیره کولو سره څنګه کار کول؛
- د محلي ذخیرې کارولو زیانونه.
د راپور په وروستۍ برخه کې، موږ به د غوښتنلیک عملي مثالونه په پام کې ونیسو د ایمیزون یا ګوګل کلاوډ خدمت سره. راپور د ClickHouse لپاره د آپریټر د پراختیا او عملیاتي تجربې مثال پراساس دی.
ویډیو:
زما نوم ولادیسلاو کلیمینکو دی. نن ما غوښتل د یو آپریټر په جوړولو او چلولو کې زموږ د تجربې په اړه وغږیږم، او دا د ډیټابیس کلسترونو اداره کولو لپاره یو ځانګړی آپریټر دی. د مثال په ډول د ClickHouse کلستر اداره کولو لپاره.
ولې موږ د آپریټر او ClickHouse په اړه د خبرو کولو فرصت لرو؟
- موږ د ClickHouse ملاتړ او پراختیا کوو.
- په اوس وخت کې، موږ هڅه کوو چې ورو ورو د ClickHouse په پراختیا کې خپله ونډه ترسره کړو. او موږ په ClickHouse کې د بدلونونو حجم له مخې له Yandex وروسته دوهم یو.
- موږ هڅه کوو چې د ClickHouse ایکوسیستم لپاره اضافي پروژې رامینځته کړو.
زه غواړم تاسو ته د دې پروژو څخه د یوې په اړه ووایم. دا د Kubernetes لپاره د ClickHouse-operator په اړه دی.
زما په راپور کې غواړم دوه موضوعاتو ته اشاره وکړم:
- لومړۍ موضوع دا ده چې څنګه زموږ د ClickHouse ډیټابیس مدیریت آپریټر په Kubernetes کې کار کوي.
- دویمه موضوع دا ده چې کوم آپریټر څنګه کار کوي، د بیلګې په توګه دا څنګه د کوبرنیټس سره اړیکه لري.
په هرصورت، دا دوه پوښتنې به زما د راپور په اوږدو کې سره یو ځای شي.
څوک به د هغه څه اوریدلو سره علاقه ولري چې زه یې ویل غواړم؟
- دا به د هغو کسانو لپاره خورا ګټور وي چې چلونکي چلوي.
- یا د هغو کسانو لپاره چې غواړي خپل ځان جوړ کړي ترڅو پوه شي چې دا څنګه په داخلي توګه کار کوي، آپریټر څنګه د کوبرنیټس سره تعامل کوي، او کوم زیانونه لیدل کیدی شي.
د ښه پوهیدو لپاره چې موږ به نن ورځ بحث وکړو، دا یو ښه نظر دی چې پوه شئ چې کبرنیټس څنګه کار کوي او یو څه لومړني بادل روزنه لري.
ClickHouse څه شی دی؟ دا یو کالم ډیټابیس دی چې د تحلیلي پوښتنو آنلاین پروسس کولو لپاره ځانګړي ځانګړتیاوې لري. او دا په بشپړه توګه خلاص سرچینه ده.
او دا زموږ لپاره مهمه ده چې یوازې دوه شیان پوه شو. تاسو اړتیا لرئ پوه شئ چې دا یو ډیټابیس دی، نو هغه څه چې زه به تاسو ته ووایم د نږدې هر ډیټابیس لپاره به پلي شي. او دا حقیقت چې د ClickHouse DBMS خورا ښه اندازه کوي، تقریبا خطي توزیع ورکوي. او له همدې امله، د کلستر حالت د ClickHouse لپاره طبیعي حالت دی. او موږ په دې بحث کولو کې خورا علاقه لرو چې څنګه په کوبرنیټس کې د کلیک هاؤس کلستر ته خدمت وکړو.
ولې هغه هلته اړتیا لري؟ ولې موږ نشو کولی خپل کار ته دوام ورکړو؟ او ځوابونه یو څه تخنیکي او یو څه تنظیمي دي.
- په عمل کې، موږ په زیاتیدونکي توګه د داسې وضعیت سره مخ یو چې په لویو شرکتونو کې نږدې ټولې برخې لا دمخه په کوبرنیټس کې دي. ډیټابیسونه بهر پاتې دي.
- او پوښتنه په زیاتیدونکي ډول پوښتل کیږي: "ایا دا دننه کیدی شي؟" له همدې امله ، لوی شرکتونه هڅه کوي د مدیریت اعظمي یووالي ترلاسه کړي ترڅو ژر تر ژره وکولی شي د دوی ډیټا ګودامونه اداره کړي.
- او دا په ځانګړي توګه مرسته کوي که تاسو په نوي ځای کې ورته شی تکرار کولو اعظمي فرصت ته اړتیا لرئ ، د بیلګې په توګه اعظمي پورټ وړتیا.
څومره اسانه او څومره ستونزمن دی؟ دا، البته، د لاس په واسطه ترسره کیدی شي. مګر دا دومره ساده نده ، ځکه چې موږ پخپله د کوبرنیټس اداره کولو کې اضافه پیچلتیا لرو ، مګر په ورته وخت کې د کلیک هاؤس مشخصات خورا لوړ دي. او دا ډول مجموعه نتیجه ورکوي.
او دا ټول په ګډه د ټیکنالوژیو خورا لوی سیټ ورکوي، چې اداره کول یې خورا ستونزمن کیږي، ځکه چې کوبرنیټس خپل ورځني مسایل عملیات ته راوړي، او کلیک هاوس خپل مسایل ورځني عملیاتو ته راوړي. په ځانګړي توګه که موږ ډیری کلیک هاوسونه لرو، او موږ باید په دوامداره توګه د دوی سره یو څه وکړو.
د متحرک ترتیب سره، ClickHouse په کافي اندازه لوی شمیر مسلې لري چې په DevOps کې دوامداره بار رامینځته کوي:
- کله چې موږ غواړو په ClickHouse کې یو څه بدل کړو، د بیلګې په توګه، یو نقل یا شارډ اضافه کړئ، نو موږ اړتیا لرو چې ترتیب تنظیم کړو.
- بیا د ډاټا سکیما بدل کړئ، ځکه چې ClickHouse یو ځانګړی شارډینګ طریقه لري. هلته تاسو اړتیا لرئ د ډیټا ډیاګرام ترتیب کړئ ، تشکیلات تنظیم کړئ.
- تاسو اړتیا لرئ چې نظارت تنظیم کړئ.
- د نوو شارډونو لپاره د لاګونو راټولول، د نوي نقلونو لپاره.
- د بیا رغونې پاملرنه وکړئ.
- او بیا پیل کړئ.
دا معمول کارونه دي چې زه واقعیا غواړم د کارولو لپاره اسانه کړم.
Kubernetes پخپله په عملیاتو کې ښه مرسته کوي، مګر د بنسټیز سیسټم شیانو کې.
Kubernetes د شیانو په اسانولو او اتومات کولو کې ښه دی لکه:
- رغول.
- بیا روښانه کول.
- د ذخیره کولو سیسټم مدیریت.
دا ښه ده، دا سمه لار ده، مګر هغه د ډیټابیس کلستر د چلولو په اړه په بشپړه توګه ناپوه دی.
موږ نور غواړو، موږ غواړو چې ټول ډیټابیس په Kubernetes کې کار وکړي.
زه غواړم د یو لوی جادو سور تڼۍ په څیر یو څه ترلاسه کړم چې تاسو یې فشار کوئ او د ورځني کارونو سره یو کلستر چې حل کولو ته اړتیا لري د خپل ټول ژوند دوره کې ځای په ځای شوي او ساتل کیږي. په کوبرنیټس کې د کلیک هاوس کلستر.
او موږ هڅه وکړه چې داسې حل پیدا کړو چې د کار په اسانه کولو کې مرسته وکړي. دا د Altinity څخه Kubernetes لپاره د ClickHouse چلونکی دی.
یو آپریټر یو پروګرام دی چې اصلي دنده یې د نورو پروګرامونو اداره کول دي، د بیلګې په توګه دا یو مدیر دی.
او دا د چلند نمونې لري. تاسو کولی شئ دا کوډ شوي پوهه د موضوع ساحې په اړه ووایاست.
او د هغه اصلي دنده د DevOps ژوند اسانه کول او د مایکرو مدیریت کمول دي ، ترڅو هغه (DevOps) دمخه د لوړې کچې شرایطو کې فکر کوي ، د بیلګې په توګه ، ترڅو هغه (DevOps) په مایکرو مدیریت کې ښکیل نه وي ، ترڅو هغه تنظیم نه کړي. ټول توضیحات په لاسي ډول.
او یوازې آپریټر یو روبوټیک معاون دی چې د مایکروټاسکونو سره معامله کوي او د DevOps سره مرسته کوي.
تاسو ولې یو آپریټر ته اړتیا لرئ؟ هغه په دوه برخو کې په ځانګړې توګه ښه فعالیت کوي:
- کله چې متخصص چې د ClickHouse سره معامله کوي کافي تجربه نلري، مګر دمخه د ClickHouse چلولو ته اړتیا لري، آپریټر عملیات اسانه کوي او تاسو ته اجازه درکوي د کلک هاوس کلستر د پیچلي ترتیب سره پرمخ بوځي، پرته له دې چې دا ټول څنګه کار کوي په اړه ډیر تفصیل ته لاړ نشي. دننه تاسو یوازې هغه ته د لوړې کچې دندې ورکړئ، او دا کار کوي.
- او دویمه دنده په کوم کې چې دا غوره ترسره کوي هغه وخت دی چې اړتیا وي د لوی شمیر عادي کارونو اتومات کول. د سیسټم مدیرانو څخه مایکروټاسکونه لرې کوي.
دا یا د هغه چا لخوا خورا اړین دی چې یوازې خپل سفر پیل کوي ، یا د هغه چا لخوا چې ډیری اتومات کولو ته اړتیا لري.
د آپریټر پر بنسټ چلند څنګه د نورو سیسټمونو څخه توپیر لري؟ هیلم شته. دا د ClickHouse په نصبولو کې هم مرسته کوي؛ تاسو کولی شئ د هیلم چارټونه رسم کړئ، کوم چې حتی د کلک هاوس بشپړ کلستر به نصب کړي. بیا د چلونکي او ورته تر مینځ توپیر څه دی، د بیلګې په توګه، هیلم؟
اصلي بنسټیز توپیر دا دی چې هیلم د بسته بندۍ مدیریت دی او آپریټر یو ګام نور هم ځي. دا د ټول ژوند دوره لپاره ملاتړ دی. دا یوازې نصب نه دی، دا ورځني کارونه دي چې په کې اندازه کول، شارډینګ کول شامل دي، د بیلګې په توګه هر هغه څه چې د ژوند دوره کې باید ترسره شي (که اړتیا وي، بیا حذف کول هم) - دا ټول د آپریټر لخوا پریکړه کیږي. دا د ټول سافټویر ژوند دورې اتومات کولو او ساتلو هڅه کوي. دا د نورو حلونو څخه بنسټیز توپیر دی چې وړاندې کیږي.
دا د تعارف برخه وه، راځئ چې پرمخ لاړ شو.
موږ څنګه خپل آپریټر جوړوو؟ موږ هڅه کوو چې د یوې سرچینې په توګه د ClickHouse کلستر اداره کولو لپاره مسلې ته ورسیږو.
دلته موږ د انځور په ښي خوا کې د معلوماتو ډاټا لرو. دا د کلستر مشخصاتو سره YAML دی، کوم چې په کلاسیک ډول د kubectl له لارې Kubernetes ته لیږدول کیږي. هلته زموږ آپریټر دا پورته کوي او خپل جادو کوي. او په محصول کې موږ لاندې سکیم ترلاسه کوو. دا په Kubernetes کې د ClickHouse تطبیق دی.
او بیا به موږ ورو ورو وګورو چې په سمه توګه آپریټر څنګه کار کوي، کوم ځانګړي دندې حل کیدی شي. موږ به یوازې عادي دندې په پام کې ونیسو ځکه چې موږ محدود وخت لرو. او هر هغه څه چې آپریټر یې پریکړه کولی شي بحث نه کیږي.
راځئ چې له تمرین څخه پیل وکړو. زموږ پروژه په بشپړ ډول خلاص سرچینه ده ، نو تاسو کولی شئ وګورئ چې دا په GitHub کې څنګه کار کوي. او تاسو کولی شئ د دې نظرونو څخه پرمخ لاړ شئ چې که تاسو یوازې دا پیل کول غواړئ ، نو تاسو کولی شئ د ګړندي پیل لارښود سره پیل کړئ.
که تاسو غواړئ په تفصیل سره پوه شئ، نو موږ هڅه کوو چې اسناد په لږ یا لږ ښه بڼه وساتو.
راځئ چې د یوې عملي ستونزې سره پیل وکړو. لومړی کار، چیرې چې موږ ټول غواړو پیل کړو، دا ده چې لومړی مثال په یو ډول پرمخ بوځو. زه څنګه کولی شم د آپریټر په کارولو سره ClickHouse پیل کړم، حتی که زه واقعیا نه پوهیږم چې دا څنګه کار کوي؟ موږ یو منشور لیکو، ځکه چې ... د k8s سره ټولې اړیکې د منشور له لارې اړیکه ده.
دا دومره پیچلي منشور دی. هغه څه چې موږ په سور کې روښانه کړي هغه څه دي چې موږ ورته اړتیا لرو تمرکز وکړو. موږ له آپریټر څخه غوښتنه کوو چې د ډیمو په نوم کلستر جوړ کړي.
دا د اوس لپاره اساسي مثالونه دي. ذخیره لا تر اوسه نه ده بیان شوې، مګر موږ به یو څه وروسته ذخیره ته راستانه شو. د اوس لپاره، موږ به د کلستر د پراختیا متحرکات وګورو.
موږ دا منشور جوړ کړ. موږ دا زموږ آپریټر ته تغذیه کوو. هغه کار وکړ، هغه جادو جوړ کړ.
موږ کنسول ته ګورو. درې برخې په زړه پورې دي: یو پوډ، دوه خدمتونه، او یو سټیټ سیټ.
آپریټر کار کړی، او موږ کولی شو وګورو چې هغه څه شی جوړ کړی.
هغه داسې یو څه جوړوي. موږ د هر نقل لپاره StatefulSet، Pod، ConfigMap لرو، د ټول کلستر لپاره ConfigMap. خدمتونه کلستر ته د ننوتلو نقطو په توګه اړین دي.
خدمتونه د مرکزي بار بیلانس خدمت دي او د هر نقل لپاره هم کارول کیدی شي ، د هر شارډ لپاره.
زموږ بنسټیز کلستر داسې ښکاري. دا د یو واحد نوډ څخه دی.
راځئ نور لاړ شو او شیان پیچلي کړو. موږ اړتیا لرو چې کلستر ټوټه کړو.
زموږ دندې وده کوي، متحرکات پیل کیږي. موږ غواړو یو شارډ اضافه کړو. موږ پرمختګ تعقیبوو. موږ خپل مشخصات بدلوو. موږ اشاره کوو چې موږ دوه ټوټې غواړو.
دا ورته فایل دی چې په متحرک ډول د سیسټم وده سره وده کوي. د ذخیره کولو شمیره، ذخیره به نوره هم بحث وکړي، دا جلا موضوع ده.
موږ د YAML آپریټر تغذیه کوو او ګورو چې څه پیښیږي.
چلونکي فکر وکړ او لاندې ادارې یې جوړې کړې. موږ دمخه دوه پوډونه لرو، درې خدمتونه او ناڅاپه، 2 StatefulSets. ولې 2 StatefulSets؟
په ډیاګرام کې دا داسې وه - دا زموږ لومړنی حالت دی، کله چې موږ یو پوډ درلود.
دا داسې شوه. تر اوسه هر څه ساده دي، دا نقل شوي دي.
او ولې دوه دولتي سیټونه شول؟ دلته موږ اړتیا لرو د دې پوښتنې په اړه بحث او بحث وکړو چې پوډونه څنګه په کوبرنیټس کې اداره کیږي.
د StatefulSet په نوم یو څیز شتون لري چې تاسو ته اجازه درکوي د ټیمپلیټ څخه د پوډونو سیټ رامینځته کړئ. دلته کلیدي فکتور ټیمپلیټ دی. او تاسو کولی شئ په یوه StatefulSet کې د یوې ټیمپلیټ په کارولو سره ډیری پوډونه لانچ کړئ. او دلته کلیدي جمله "د یوې ټیمپلیټ لپاره ډیری پوډونه" دي.
او د ټول کلستر د جوړولو لپاره یو لوی لالچ شتون درلود، دا په یو سټیټفل سیټ کې بسته کول. دا به کار وکړي، هیڅ ستونزه نشته. مګر یو احتیاط شتون لري. که موږ غواړو یو متضاد کلستر راټول کړو، دا د ClickHouse له څو نسخو څخه دی، نو بیا پوښتنې راپورته کیږي. هو، StatefulSet کولی شي یو رولینګ تازه کړي، او هلته تاسو کولی شئ نوې نسخه راوباسئ، تشریح کړئ چې تاسو اړتیا لرئ په ورته وخت کې د ډیری نوډونو څخه زیات هڅه مه کوئ.
مګر که موږ دا دنده وسپارو او ووایو چې موږ غواړو په بشپړ ډول متضاد کلستر جوړ کړو او موږ نه غواړو چې د رولینګ تازه کولو په کارولو سره له زاړه نسخې څخه نوي ته بدل کړو ، مګر موږ په ساده ډول غواړو په دواړو شرایطو کې متفاوت کلستر جوړ کړو. د ClickHouse مختلف نسخې او د مختلف ذخیره کولو شرایطو کې. موږ غواړو، د بیلګې په توګه، په جلا ډیسکونو کې ځینې نقلونه جوړ کړو، په سستو کې، په عموم کې، په بشپړه توګه یو متضاد کلستر جوړ کړو. او د دې حقیقت له امله چې StatefulSet د یوې ټیمپلیټ څخه معیاري حل کوي، د دې کولو لپاره هیڅ لاره نشته.
د یو څه فکر کولو وروسته، پریکړه وشوه چې موږ به دا کار وکړو. موږ هر یو نقل په خپل StatefulSet کې لرو. د دې حل لپاره ځینې نیمګړتیاوې شتون لري، مګر په عمل کې دا ټول په بشپړه توګه د آپریټر لخوا پوښل شوي. او ډیرې ګټې لري. موږ کولی شو دقیق کلستر جوړ کړو چې موږ یې غواړو، د بیلګې په توګه، یو بالکل متضاد. له همدې امله، په یوه کلستر کې چې موږ د یو نقل سره دوه شارډونه لرو، موږ به په سمه توګه 2 StatefulSets او 2 Pods ولرو ځکه چې موږ دا طریقه د پورته ذکر شوي دلیلونو لپاره غوره کړې ترڅو د متفاوت کلستر جوړولو وړتیا ولري.
راځو عملی ستونزو ته. زموږ په کلستر کې موږ اړتیا لرو چې کاروونکي تنظیم کړو، د بیلګې په توګه. تاسو اړتیا لرئ چې په Kubernetes کې د ClickHouse ځینې ترتیبات ترسره کړئ. آپریټر د دې لپاره ټول امکانات چمتو کوي.
موږ کولی شو هغه څه ولیکئ چې موږ یې په مستقیم ډول په YAML کې غواړو. د ترتیب کولو ټول اختیارونه په مستقیم ډول د دې YAML څخه د ClickHouse تشکیلاتو کې نقشه شوي، کوم چې بیا په ټول کلستر کې ویشل شوي.
تاسو کولی شئ دا په دې ډول ولیکئ. دا د مثال په توګه دی. پټنوم کوډ کیدی شي. په بشپړ ډول د کلک هاوس ترتیب کولو ټول اختیارونه ملاتړ کیږي. دلته یوازې یو مثال دی.
د کلستر ترتیب د ConfigMap په توګه ویشل شوی. په عمل کې، د ConfigMap تازه کول سمدلاسه نه پیښیږي، نو که کلستر لوی وي، نو بیا د ترتیب کولو بهیر یو څه وخت نیسي. مګر دا ټول د کارولو لپاره خورا اسانه دي.
راځئ چې دنده پیچلې کړو. کلستر وده کوي. موږ غواړو چې ډاټا نقل کړو. دا دی، موږ دمخه دوه شارډونه لرو، هر یو یو نقل، او کاروونکي ترتیب شوي. موږ وده کوو او غواړو چې نقل وکړو.
موږ د نقل لپاره څه ته اړتیا لرو؟
موږ ZooKeeper ته اړتیا لرو. په ClickHouse کې، نقل د ZooKeeper په کارولو سره جوړ شوی. ZooKeeper ته اړتیا ده ترڅو د ClickHouse مختلف نقلونه د دې په اړه توافق ولري چې کوم ډیټا بلاکونه په کوم کلیک هاوس کې دي.
ZooKeeper د هر چا لخوا کارول کیدی شي. که چیرې تصدۍ یو بهرنی زوکیپر ولري، نو دا کارول کیدی شي. که نه، تاسو کولی شئ دا زموږ د ذخیره کولو څخه نصب کړئ. یو انسټالر شتون لري چې دا ټول شیان اسانه کوي.
او د ټول سیسټم د متقابل عمل ډیاګرام داسې ښکاري. موږ Kubernetes د یو پلیټ فارم په توګه لرو. دا د ClickHouse آپریټر اجرا کوي. ما دلته د زوکیپر عکس اخیستی. او آپریټر د ClickHouse او ZooKeeper دواړو سره اړیکه لري. دا د متقابل عمل پایله ده.
او دا ټول د ClickHouse لپاره اړین دي چې په بریالیتوب سره په k8s کې ډاټا نقل کړي.
راځئ چې اوس پخپله دنده وګورو، د نقل لپاره منشور به څه ډول ښکاري.
موږ په خپل منشور کې دوه برخې اضافه کوو. لومړی هغه ځای دی چې زوکیپر ترلاسه کړئ ، کوم چې یا د کوبرنیټس دننه یا بهر کیدی شي. دا یوازې یو توضیح دی. او موږ د نقلونو امر کوو. هغوی. موږ دوه نقلونه غواړو. په مجموع کې، موږ باید په تولید کې 4 پوډونه ولرو. موږ د ذخیره کولو په اړه یادونه کوو، دا به یو څه وروسته بیرته راشي. ذخیره یوه جلا کیسه ده.
دا داسې وه.
دا داسې کیږي. نقلونه اضافه کیږي. څلورم یو مناسب نه و، موږ باور لرو چې د دوی ډیری شتون شتون لري. او زوکیپر اړخ ته اضافه کیږي. سکیمونه ډیر پیچلي کیږي.
او دا وخت دی چې راتلونکی دنده اضافه کړئ. موږ به دوامداره ذخیره اضافه کړو.
د دوامداره ذخیره کولو لپاره موږ مختلف انتخابونه لرو.
که موږ د بادل چمتو کونکي کې روان یو ، د مثال په توګه ، د ایمیزون ، ګوګل کارول ، نو د کلاوډ ذخیره کارولو لپاره عالي لیوالتیا شتون لري. دا خورا اسانه دی، دا ښه دی.
او دوهم اختیار شتون لري. دا د محلي ذخیره کولو لپاره دی، کله چې موږ په هر نوډ کې محلي ډیسکونه لرو. دا اختیار د پلي کولو لپاره خورا ستونزمن دی، مګر په ورته وخت کې دا ډیر ګټور دی.
راځئ وګورو چې موږ د بادل ذخیره کولو په اړه څه لرو.
ګټې شتون لري. دا تنظیم کول خورا اسانه دي. موږ په ساده ډول د بادل چمتو کونکي څخه امر کوو چې مهرباني وکړئ موږ ته د داسې او داسې ظرفیت ، داسې او داسې ټولګي ذخیره راکړئ. ټولګي په خپلواکه توګه د چمتو کونکو لخوا ټاکل کیږي.
او یو نیمګړتیا شتون لري. د ځینو لپاره، دا یو غیر جدي نیمګړتیا ده. البته، د فعالیت ځینې مسلې به وي. دا د کارولو لپاره خورا اسانه او د باور وړ دی ، مګر د فعالیت ځینې احتمالي نیمګړتیاوې شتون لري.
او ځکه کلیک هاؤس په ځانګړي ډول په تولید تمرکز کوي، یو څوک ممکن حتی ووایي چې دا هرڅه چې کولی شي له مینځه یوسي، له همدې امله ډیری پیرودونکي هڅه کوي د اعظمي تولید کچه راټیټوي.
او د دې څخه ډیری ترلاسه کولو لپاره، موږ محلي ذخیره ته اړتیا لرو.
Kubernetes په Kubernetes کې د محلي ذخیره کارولو لپاره درې خلاصې وړاندې کوي. دا:
- خالي ډایر
- HostPath.
- د محلي
راځئ وګورو چې دوی څنګه توپیر لري او څنګه ورته ورته دي.
لومړی، په ټولو دریو لارو کې موږ ذخیره لرو - دا محلي ډیسکونه دي چې په ورته فزیکي k8s نوډ کې موقعیت لري. مګر دوی ځینې توپیرونه لري.
راځئ چې تر ټولو ساده سره پیل وکړو، د بیلګې په توګه emptyDir. دا په عمل کې څه شی دی؟ زموږ په توضیحاتو کې ، موږ د کانټینر کولو سیسټم (اکثره ډاکر) څخه غوښتنه کوو چې موږ ته په محلي ډیسک کې فولډر ته لاسرسی چمتو کړي.
په عمل کې ، ډاکر د خپلو لارو په اوږدو کې یو لنډمهاله فولډر رامینځته کوي او ورته اوږد هش وايي. او دې ته د لاسرسي لپاره انٹرفیس چمتو کوي.
دا به څنګه د فعالیت له مخې کار وکړي؟ دا به د محلي ډیسک سرعت سره کار وکړي، i.e. دا ستاسو سکرو ته بشپړ لاسرسی دی.
مګر دا قضیه خپل نیمګړتیاوې لري. دوام په دې مسله کې خورا شکمن دی. لومړی ځل چې ډاکر د کانټینرونو سره حرکت کوي، دوام ورک شوی. که Kubernetes غواړي دا پوډ د کوم دلیل لپاره بل ډیسک ته انتقال کړي، ډاټا به ورک شي.
دا طریقه د ازموینو لپاره ښه ده، ځکه چې دا دمخه نورمال سرعت ښیې، مګر د یو څه جدي لپاره دا اختیار مناسب نه دی.
له همدې امله، دویمه طریقه شتون لري. دا hostPath دی. که تاسو مخکینی سلایډ او دا یو وګورئ، تاسو یوازې یو توپیر لیدلی شئ. زموږ فولډر د ډاکر څخه مستقیم د کبرنیټس نوډ ته لیږدول شوی. دلته یو څه ساده دی. موږ په مستقیم ډول په محلي فایل سیسټم کې لاره مشخص کوو چیرې چې موږ غواړو خپل معلومات ذخیره کړو.
دا طریقه ګټې لري. دا دمخه یو ریښتینی دوام دی ، او پدې کې یو کلاسیک دی. موږ به په ډیسک کې په یو پته کې ثبت شوي معلومات ولرو.
نیمګړتیاوې هم شتون لري. دا د مدیریت پیچلتیا ده. زموږ کوبرنیټس ممکن وغواړي پوډ بل فزیکي نوډ ته واړوي. او دا هغه ځای دی چې DevOps لوبې ته راځي. هغه باید په سمه توګه ټول سیسټم ته تشریح کړي چې دا پوډونه یوازې هغه نوډونو ته لیږدول کیدی شي چې تاسو په دې لارو کې یو څه ایښودل شوي وي، او په یو وخت کې له یو څخه زیات نوډ نه وي. دا خورا ستونزمن دی.
په ځانګړې توګه د دې موخو لپاره، موږ د دې ټولو پیچلتیا پټولو لپاره زموږ په آپریټر کې ټیمپلیټونه جوړ کړل. او تاسو کولی شئ په ساده ډول ووایاست: "زه غواړم د هر فزیکي نوډ لپاره د کلیک هاؤس یوه بیلګه ولرم او د دې ډول لارې په اوږدو کې."
مګر موږ یوازینی هغه نه یو چې دې اړتیا ته اړتیا لري، نو پخپله د کوبرنیټس حضرات هم پوهیږي چې خلک غواړي فزیکي ډیسکونو ته لاسرسی ولري، نو دوی دریم پرت چمتو کوي.
دا محلي بلل کیږي. په عملي توګه د تیر سلایډ څخه هیڅ توپیر شتون نلري. یوازې مخکې لدې چې دا په لاسي ډول تایید کولو ته اړتیا وه چې موږ نشو کولی دا پوډونه له نوډ څخه نوډ ته انتقال کړو ، ځکه چې دوی باید د ځایی فزیکي ډیسک سره یو څه لاره سره وصل وي ، مګر اوس دا ټول پوهه پخپله په کوبرنیټس کې پوښل شوې. او دا معلومه شوه چې تنظیم کول خورا اسانه دي.
راځم خپلې عملي ستونزې ته. راځئ چې د YAML ټیمپلیټ ته راستون شو. دلته موږ اصلي ذخیره لرو. موږ بیرته په هغه کې یو. موږ د k8s په څیر کلاسیک VolumeClaim ټیمپلیټ تنظیم کړ. او موږ تشریح کوو چې کوم ډول ذخیره غواړو.
له دې وروسته، k8s به د ذخیره کولو غوښتنه وکړي. دا به موږ ته په StatefulSet کې تخصیص کړي. او په پای کې به دا د ClickHouse په اختیار کې وي.
موږ دا سکیم درلود. زموږ دوامداره ذخیره سور وه، کوم چې داسې ښکاري چې دا باید ترسره شي.
او شنه کیږي. اوس د K8s کلستر سکیم کې د کلیک هاوس په بشپړ ډول نهایی شوی. موږ شارډونه، نقلونه، زوکیپر لرو، موږ یو ریښتینی دوام لرو، کوم چې په یو ډول یا بل ډول پلي کیږي. دا سکیم لا دمخه په بشپړ ډول فعال دی.
موږ ژوند ته دوام ورکوو. زموږ کلستر وده کوي. او الیکسي هڅه کوي، او د کلک هاؤس نوې نسخه خپره کړي.
یو عملي کار رامینځته کیږي - زموږ په کلستر کې د ClickHouse نوې نسخه ازموینه کول. او، په طبیعي توګه، تاسو نه غواړئ دا ټول راوباسئ؛ تاسو غواړئ یوه نوې نسخه په لرې کونج کې په یوه نقل کې واچوئ، او شاید یوه نوې نسخه نه وي، مګر په یوځل کې دوه، ځکه چې دوی ډیری وختونه راځي.
موږ په دې اړه څه ویلای شو؟
دلته موږ یوازې یو فرصت لرو. دا د پوډ ټیمپلیټونه دي. تاسو کولی شئ ولیکئ چې زموږ آپریټر په بشپړ ډول تاسو ته اجازه درکوي چې یو متضاد کلستر جوړ کړئ. هغوی. ترتیب کړئ، په یو ګروپ کې د ټولو نقلونو څخه پیل کول، د هر شخصي نقل سره پای ته رسیږي، کوم نسخه چې موږ کلیک هاوس غواړو، کوم نسخه موږ ذخیره غواړو. موږ کولی شو په بشپړ ډول د هغه ترتیب سره کلستر تنظیم کړو چې موږ ورته اړتیا لرو.
راځئ چې لږ ژور دننه لاړ شو. مخکې له دې، موږ په دې اړه خبرې وکړې چې څنګه د ClickHouse-operator د ClickHouse ځانګړتیاوو په اړه کار کوي.
اوس زه غواړم پدې اړه یو څو ټکي ووایم چې کوم آپریټر په عموم کې کار کوي ، او همدارنګه دا څنګه د K8s سره تعامل کوي.
راځئ چې لومړی د K8s سره متقابل عمل وګورو. څه پیښیږي کله چې موږ د کیوبیکل غوښتنه کوو؟ زموږ توکي د API له لارې په etcd کې ښکاري.
د مثال په توګه، د Kubernetes بنسټیز توکي: پوډ، StatefulSet، خدمت، او داسې نور د لیست لاندې.
په ورته وخت کې، هیڅ فزیکي نه پیښیږي. دا توکي باید په کلستر کې مادي شي.
د دې هدف لپاره، یو کنټرولر ښکاري. کنټرولر یو ځانګړی k8s برخه ده چې کولی شي دا توضیحات مادي کړي. هغه پوهیږي چې څنګه او څه باید په فزیکي توګه وکړي. هغه پوهیږي چې څنګه کانټینرونه چلوي، د سرور د کار کولو لپاره هلته څه تنظیم کولو ته اړتیا لري.
او دا زموږ توکي په K8s کې مادي کوي.
مګر موږ غواړو نه یوازې د پوډونو او سټیټفل سیټونو سره کار وکړو ، موږ غواړو د کلک هاوس نصب کول رامینځته کړو ، د بیلګې په توګه د کلیک هاوس ډوله یو څیز ، ترڅو د دې سره په بشپړ ډول کار وکړو. تر اوسه داسې کوم امکان نشته.
مګر K8s لاندې ښه شیان لري. موږ غواړو چې موږ د دې پیچلي ادارې په څیر یو ځای ولرو په کوم کې چې زموږ کلستر د پوډونو او سټیټفیل سیټ څخه راټول شي.
او د دې لپاره څه کول پکار دي؟ لومړی، د ګمرک سرچینې تعریف په انځور کې راځي. دا څه شی دی؟ دا د K8s لپاره توضیحات دي ، چې تاسو به یو بل ډیټا ډول ولرئ ، چې موږ غواړو په پوډ کې دودیز سرچینې اضافه کړو ، StatefulSet ، کوم چې دننه به پیچلي وي. دا د معلوماتو جوړښت تشریح دی.
موږ دا د kubectl Apply له لارې هم هلته لیږو. Kubernetes په خوښۍ سره دا واخیست.
او اوس زموږ په ذخیره کې، په etcd کې اعتراض د ClickHouseInstallation په نوم د دودیز سرچینې ثبتولو فرصت لري.
خو د اوس لپاره نور څه نه کیږي. دا دی ، که موږ اوس د YAML فایل رامینځته کړو چې موږ د شارډونو او نقلونو تشریح کولو ته ګورو او ووایو "کوبکټل پلي کیږي" ، نو کوبرنیټس به دا ومني ، په etcd کې یې واچوي او ووایی: "ښه ، مګر زه نه پوهیږم څه وکړم. ورسره زه نه پوهیږم چې څنګه د ClickHouseInstallation وساتي.
په دې اساس، موږ یو چا ته اړتیا لرو چې د کوبرنیټس سره د نوي ډیټا ډول خدمت کولو کې مرسته وکړي. په ښي خوا کې موږ د کوبرنیټس اصلي کنټرولر لرو چې د اصلي ډیټا ډولونو سره کار کوي. او په ښي خوا کې موږ باید یو دودیز کنټرولر ولرو چې کولی شي د دودیز ډیټا ډولونو سره کار وکړي.
او په بل ډول دا د چلونکي په نوم یادیږي. ما دا په ځانګړې توګه دلته د Kubernetes په توګه شامل کړل، ځکه چې دا د K8s څخه بهر هم اعدام کیدی شي. ډیری وختونه، البته، ټول آپریټرونه په کوبرنیټس کې اعدام شوي، مګر هیڅ شی دا د بهر ودریدو مخه نه نیسي، نو دلته دا په ځانګړې توګه بهر ته لیږدول کیږي.
او په بدل کې، دودیز کنټرولر، چې د آپریټر په نوم هم پیژندل کیږي، د API له لارې د Kubernetes سره اړیکه لري. دا دمخه پوهیږي چې څنګه د API سره تعامل وکړي. او هغه لا دمخه پوهیږي چې څنګه پیچلي سرکټ مادي کړي چې موږ یې د دودیز سرچینې څخه جوړول غواړو. دا په حقیقت کې هغه څه دي چې آپریټر یې کوي.
آپریټر څنګه کار کوي؟ راځئ چې ښي خوا ته وګورو چې هغه څنګه دا کوي. راځئ چې معلومه کړو چې آپریټر دا ټول څنګه عملي کوي او د K8s سره نور تعامل څنګه واقع کیږي.
یو آپریټر یو پروګرام دی. هغه د پیښو پر بنسټ والړ دی. آپریټر د Kubernetes API په کارولو سره پیښو کې ګډون کوي. د Kubernetes API د ننوتلو نقطې لري چیرې چې تاسو کولی شئ پیښو ته ګډون وکړئ. او که چیرې په K8s کې یو څه بدل شي، نو بیا Kubernetes هرچا ته پیښې لیږي، د بیلګې په توګه. هر هغه څوک چې د دې API ټکي کې ګډون کړی وي نو خبرتیاوې به ترلاسه کړي.
آپریټر پیښو ته ګډون کوي او باید یو ډول غبرګون وکړي. د دې دنده دا ده چې راڅرګندېدونکو پیښو ته ځواب ووایی.
پیښې د ځینې تازه معلوماتو لخوا رامینځته کیږي. زموږ د YAML فایل د ClickHouseInstallation توضیحاتو سره راځي. هغه د kubectl apply له لارې etcd ته لاړ. هلته یوه پیښه رامینځته شوه، او په پایله کې دا پیښه د ClickHouse-operator ته راغله. آپریټر دا توضیحات ترلاسه کړل. او هغه باید یو څه وکړي. که چیرې د ClickHouseInstallation څیز لپاره تازه معلومات راشي، نو تاسو اړتیا لرئ چې کلستر تازه کړئ. او د آپریټر دنده د کلستر تازه کول دي.
هغه څه کوي؟ لومړی ، موږ اړتیا لرو د دې تازه کولو سره د څه لپاره د عمل پلان جوړ کړو. تازه معلومات خورا کوچني کیدی شي، i.e. د YAML اجرا کولو کې کوچنی، مګر کولی شي په کلستر کې خورا لوی بدلونونه راولي. له همدې امله، آپریټر یو پلان رامینځته کوي، او بیا یې هغه ته ځي.
د دې پلان له مخې ، هغه د دې جوړښت دننه پخول پیل کوي ترڅو پوزې ، خدمات ، د بیلګې په توګه مادي کړي. هغه څه وکړئ چې اصلي دنده یې ده. دا په کبرنیټس کې د کلیک هاوس کلستر جوړولو څرنګوالی دی.
اوس راځئ چې داسې یو په زړه پورې شی ته ورسوو. دا د Kubernetes او آپریټر تر مینځ د مسؤلیت ویش دی، یعنی Kubernetes څه کوي، چلونکي څه کوي، او دوی څنګه یو له بل سره اړیکه لري.
Kubernetes د سیسټم شیانو لپاره مسؤل دی، د بیلګې په توګه. د شیانو د بنسټیز سیټ لپاره چې د سیسټم سکوپ په توګه تشریح کیدی شي. Kubernetes پوهیږي چې څنګه پوډونه پیل کړي، څنګه کانټینرونه بیا پیل کړي، څنګه حجم پورته کړي، څنګه د ConfigMap سره کار وکړي، د بیلګې په توګه. هرڅه چې د سیسټم په نوم یادیږي.
آپریټرونه په ډومینونو کې کار کوي. هر آپریټر د خپلې موضوع ساحې لپاره جوړ شوی. موږ دا د ClickHouse لپاره وکړل.
او آپریټر د موضوع ساحې په شرایطو کې دقیق تعامل کوي ، لکه د عکس اضافه کول ، ډیاګرام رامینځته کول ، د نظارت تنظیم کول. دا د ویش پایله ده.
راځئ چې یو عملي مثال وګورو چې د مسؤلیت دا ویش څنګه واقع کیږي کله چې موږ د عکس العمل اضافه کول ترسره کوو.
آپریټر یو دنده ترلاسه کوي - د نقل اضافه کولو لپاره. چلونکی څه کوي؟ آپریټر به محاسبه وکړي چې یو نوی StatefulSet رامینځته کولو ته اړتیا لري، په کوم کې چې دا ډول او داسې ټیمپلیټونه، د حجم ادعا باید بیان شي.
هغه دا ټول چمتو کړل او K8s ته یې وسپاره. هغه وايي چې هغه ConfigMap، StatefulSet، Volume ته اړتیا لري. Kubernetes کار کوي. هغه بنسټیز واحدونه مادي کوي چې ورسره یې کار کوي.
او بیا د ClickHouse-operator بیا لوبې ته راځي. هغه لا دمخه یو فزیکي پوډ لري په کوم کې چې هغه دمخه یو څه کولی شي. او ClickHouse-operator بیا د ډومین په شرایطو کې کار کوي. هغوی. په ځانګړې توګه ClickHouse، د دې لپاره چې په کلستر کې نقل شامل کړئ، تاسو باید لومړی، د ډیټا سکیما تنظیم کړئ چې پدې کلستر کې شتون لري. او، دوهم، دا نقل باید په نظارت کې شامل شي ترڅو دا په روښانه توګه تعقیب شي. آپریټر لا دمخه دا تنظیموي.
او یوازې له هغې وروسته کلیک هاوس پخپله لوبې ته راځي ، د بیلګې په توګه. بل لوړ رتبه اداره. دا لا دمخه یو ډیټابیس دی. دا خپله بیلګه لري، یو بل ترتیب شوی نقل چې د کلستر سره یوځای کیدو لپاره چمتو دی.
دا معلومه شوه چې د اجرا کولو سلسله او د مسؤلیت ویش کله چې د عکس اضافه کول خورا اوږد وي.
موږ خپلو عملي کارونو ته دوام ورکوو. که تاسو دمخه کلستر لرئ، تاسو کولی شئ تشکیلات مهاجرت کړئ.
موږ دا جوړ کړی ترڅو تاسو په موجوده xml کې سم پیسټ کړئ، کوم چې ClickHouse پوهیږي.
تاسو کولی شئ کلیک هاوس ښه تنظیم کړئ. یوازې د زون ځای پرځای کول هغه څه دي چې ما یې په اړه خبرې وکړې کله چې د hostPath ، ځایی ذخیره توضیح کول. دا څنګه د زون ځای پرځای کول په سمه توګه ترسره کیږي.
راتلونکی عملي دنده څارنه ده.
که زموږ کلستر بدل شي، نو موږ باید په دوره توګه څارنه ترتیب کړو.
راځئ چې انځور ته وګورو. موږ لا دمخه دلته شنه تیرونه لیدلي دي. اوس راځئ چې سور تیر ته وګورو. دا څنګه موږ غواړو زموږ د کلستر څارنه وکړو. څنګه د کلک هاؤس کلستر څخه میټریکونه پرومیټیوس ته رسیږي، او بیا ګرافانا ته.
د څارنې ستونزه څه ده؟ ولې دا د یو ډول لاسته راوړنې په توګه وړاندې کیږي؟ مشکل په متحرکاتو کې دی. کله چې موږ یو کلستر ولرو او دا جامد وي، نو بیا موږ کولی شو یو ځل نظارت تنظیم کړو او نور نه ځوروو.
مګر که موږ ډیری کلسترونه ولرو، یا یو څه په دوامداره توګه بدلون ومومي، نو پروسه متحرک ده. او په دوامداره توګه د نظارت تنظیم کول د سرچینو او وخت ضایع کول دي، د بیلګې په توګه. حتی یوازې سست. دا باید اتومات شي. مشکل د پروسې په متحرکاتو کې دی. او آپریټر دا خورا ښه اتومات کوي.
زموږ کلستر څنګه وده وکړه؟ په پیل کې هغه داسې و.
بیا هغه داسې وو.
په پای کې، هغه داسې شو.
او څارنه د آپریټر لخوا په اوتومات ډول ترسره کیږي. د ننوتلو واحد نقطه.
او یوازې په وتلو کې موږ د ګرافانا ډشبورډ ته ګورو ترڅو وګورو چې زموږ د کلستر ژوند څنګه دننه غوړیږي.
په هرصورت ، د ګرافانا ډشبورډ هم زموږ د آپریټر سره مستقیم د سرچینې کوډ کې توزیع شوی. تاسو کولی شئ وصل شئ او وکاروئ. زموږ DevOps ماته دا سکرین شاټ راکړ.
موږ به چیرته لاړ شو؟ دا:
- د ازموینې اتوماتیک پراختیا. اصلي دنده د نوي نسخو اتوماتیک ازموینه ده.
- موږ هم واقعیا غواړو د ZooKeeper سره ادغام اتومات کړو. او د ZooKeeper-operator سره د یوځای کولو پلانونه شتون لري. هغوی. د ZooKeeper لپاره یو آپریټر لیکل شوی او دا منطقي ده چې دوه آپریټران د یو ډیر اسانه حل رامینځته کولو لپاره ادغام پیل کړي.
- موږ غواړو ډیر پیچلي حیاتي نښې ترسره کړو.
- ما په شنه کې روښانه کړه چې موږ د ټیمپلیټونو میراث ته نږدې یو - DONE، د بیلګې په توګه د آپریټر راتلونکي خوشې کیدو سره موږ به دمخه د ټیمپلیټونو میراث ولرو. دا یو پیاوړی وسیله ده چې تاسو ته اجازه درکوي د ټوټو څخه پیچلي تشکیلات جوړ کړئ.
- او موږ د پیچلو کارونو اتومات غواړو. اصلي یو یې بیا شریکول دي.
راځئ چې ځینې منځنۍ پایلې واخلو.
په پایله کې موږ څه ترلاسه کوو؟ او ایا دا د کار کولو وړ دی که نه؟ ایا دا حتی اړینه ده چې هڅه وکړئ ډیټابیس په کوبرنیټس کې راوباسئ او په عموم کې آپریټر وکاروئ او په ځانګړي توګه د Alitnity آپریټر وکاروئ؟
په محصول کې موږ ترلاسه کوو:
- د پام وړ ساده کول او د تشکیلاتو، ځای پرځای کولو، او ساتنې اتومات کول.
- په سمدستي توګه جوړ شوی څارنه.
- او د پیچلو حاالتو لپاره د کارولو لپاره چمتو شوي کوډ شوي ټیمپلیټونه. یو عمل لکه د نقل اضافه کول اړتیا نلري په لاسي ډول ترسره شي. چلونکی دا کار کوي.
یوازې یوه وروستۍ پوښتنه پاتې ده. موږ دمخه په Kubernetes کې ډیټابیس لرو، مجازی کول. د داسې حل د فعالیت په اړه څه، په ځانګړې توګه له هغه وخته چې ClickHouse د فعالیت لپاره مطلوب دی؟
ځواب دا دی چې هرڅه سم دي! زه به په تفصیل نه لاړ شم؛ دا د جلا راپور موضوع ده.
مګر د TSBS په څیر داسې پروژه شتون لري. اصلي دنده یې څه ده؟ دا د ډیټابیس فعالیت ازموینه ده. دا یوه هڅه ده چې ګرم له ګرم سره پرتله کړئ، نرم له نرم سره.
هغه څنګه کار کوي؟ یو ډیټا سیټ تولید شوی. بیا د ډیټا دا سیټ د ورته ازموینې په کارولو سره په مختلف ډیټابیسونو کې پرمخ وړل کیږي. او هر ډیټابیس یوه ستونزه په هغه طریقه حل کوي چې پوهیږي څنګه. او بیا تاسو کولی شئ پایلې پرتله کړئ.
دا دمخه د ډیټابیسونو لوی ګروپ ملاتړ کوي. ما درې اصلي پیژندلي دي. دا:
- TimescaleDB.
- InfluxDB.
- کلیک هاوس.
یو پرتله کول د بل ورته حل سره هم ترسره شوي. د RedShift سره پرتله کول. پرتله کول په ایمیزون کې ترسره شوي. کلیک هاؤس هم پدې مسله کې د هرچا څخه ښه دی.
د هغه څه څخه چې ما وویل کومې پایلې ترلاسه کیدی شي؟
- په Kubernetes کې DB امکان لري. شاید هر یو ممکن وي، مګر په ټولیز ډول داسې ښکاري چې دا ممکن وي. په Kubernetes کې ClickHouse یقینا زموږ د آپریټر په مرسته ممکن دی.
- آپریټر د پروسې اتومات کولو کې مرسته کوي او واقعیا ژوند اسانه کوي.
- فعالیت نورمال دی.
- او موږ ته داسې ښکاري چې دا کیدی شي او باید وکارول شي.
خلاص سرچینه - موږ سره یوځای شئ!
لکه څنګه چې ما مخکې وویل، آپریټر په بشپړه توګه د خلاصې سرچینې محصول دی، نو دا به خورا ښه وي که چیرې د ډیرو خلکو شمیر یې وکاروي. مونږ سره یو ځای شه! موږ تاسو ټولو ته انتظار یو!
د ټولو څخه مننه!
پوښتنې
د راپور لپاره مننه! زما نوم انتون دی. زه د SEMrush څخه یم. زه حیران یم چې د ننوتلو سره څه شی دی. موږ د څارنې په اړه اورو، مګر د ننوتلو په اړه هیڅ نه، که موږ د ټول کلستر په اړه خبرې وکړو. د مثال په توګه، موږ په هارډویر کې کلستر پورته کړی. او موږ مرکزي شوي لوګینګ کاروو، د معیاري وسیلو په کارولو سره یې په عام ډنډ کې راټولوو. او بیا له هغه ځایه موږ هغه معلومات ترلاسه کوو چې زموږ سره علاقه لري.
ښه پوښتنه، د بیلګې په توګه د ترسره کولو لیست کې ننوتل. زموږ آپریټر تر اوسه دا اتومات نه کوي. دا لاهم وده کوي، پروژه لاهم ځوانه ده. موږ د ننوتلو اړتیا پوهیږو. دا هم ډېره مهمه موضوع ده. او دا شاید د څارنې څخه لږ مهم نه وي. مګر د پلي کولو لپاره په لیست کې لومړی څارنه وه. هلته به ننوځي. په طبیعي توګه، موږ هڅه کوو چې د کلستر د ژوند ټول اړخونه اتومات کړو. له همدې امله، ځواب دا دی چې اوس مهال آپریټر، له بده مرغه، نه پوهیږي چې دا څنګه وکړي، مګر دا په پلانونو کې دی، موږ به یې وکړو. که تاسو غواړئ یوځای شئ، نو مهرباني وکړئ غوښتنه وکړئ.
سلام! د راپور لپاره مننه! زه د دوامدار حجم پورې اړوند معیاري پوښتنه لرم. کله چې موږ د دې آپریټر سره یو ترتیب جوړ کړو، نو آپریټر څنګه معلوموي چې په کوم نوډ کې موږ یو ځانګړی ډیسک یا فولډر تړلی یو؟ موږ باید لومړی هغه ته تشریح کړو چې مهرباني وکړئ زموږ کلیک هاوس په دې نوډونو کې ځای په ځای کړئ چې ډیسک لري؟
تر هغه ځایه چې زه پوهیږم ، دا پوښتنه د ځایی ذخیره کولو دوام دی ، په ځانګړي توګه د دې کوربه پاټ برخه. دا د ټول سیسټم تشریح کولو په څیر دی چې پوډ باید په داسې او داسې نوډ کې پیل شي، کوم چې موږ په فزیکي توګه تړلی ډیسک لرو، کوم چې د داسې او داسې لارې په اوږدو کې نصب شوی. دا یوه بشپړه برخه ده چې ما په خورا سطحي ډول لمس کړې ځکه چې ځواب خورا لوی دی.
په لنډه توګه دا داسې ښکاري. په طبیعي توګه، موږ باید دا حجمونه چمتو کړو. دا مهال ، په ځایی ذخیره کې هیڅ متحرک شرایط شتون نلري ، نو DevOps باید پخپله ډیسکونه پرې کړي ، دا حجمونه. او دوی باید Kubernetes تشریح کړي چې تاسو به د داسې او داسې ټولګي دوامداره حجمونه ولرئ، کوم چې په داسې او داسې نوډونو کې موقعیت لري. بیا تاسو اړتیا لرئ Kubernetes ته تشریح کړئ چې پوډونه چې ورته او داسې محلي ذخیره کولو ټولګي ته اړتیا لري باید یوازې د لیبلونو په کارولو سره ورته او ورته نوډونو ته لارښود شي. د دې موخو لپاره، آپریټر د دې وړتیا لري چې یو ډول لیبل او یو د کوربه مثال په توګه وټاکي. او دا معلومه شوه چې پوډونه به د Kubernetes لخوا ودرول شي ترڅو یوازې په نوډونو کې چلیږي چې اړتیاوې پوره کوي، لیبلونه، په ساده شرایطو کې. مدیران په لاسي ډول لیبلونه او ډیسک چمتو کوي. او بیا دا ترازو.
او دا دریم اختیار دی، ځایی، چې دا یو څه اسانه کولو کې مرسته کوي. لکه څنګه چې ما مخکې ټینګار کړی، دا د ټونینګ په اړه دردناک کار دی، کوم چې په نهایت کې د اعظمي فعالیت ترلاسه کولو کې مرسته کوي.
زه په دې اړه دویمه پوښتنه لرم. کوبرنیټس په داسې ډول ډیزاین شوی و چې دا زموږ لپاره مهمه نده چې ایا موږ نوډ له لاسه ورکړو یا نه. په دې حالت کې باید څه وکړو که چیرې موږ هغه نوډ له لاسه ورکړو چیرې چې زموږ شارډ ځړول کیږي؟
هو، Kubernetes په پیل کې موقعیت درلود چې زموږ د پوډونو سره زموږ اړیکه د غواګانو په څیر ده، مګر دلته زموږ سره هر ډیسک د پالتو په څیر یو څه کیږي. دلته داسې ستونزه ده چې موږ نشو کولی یوازې هغه لرې کړو. او د کبرنیټس پرمختګ په هغه لور روان دی چې په بشپړ ډول د فلسفې سره درملنه ناممکنه ده، لکه څنګه چې دا په بشپړه توګه رد شوې سرچینه وي.
اوس د عملي پوښتنې لپاره. څه وکړئ که تاسو هغه نوډ له لاسه ورکړو چې ډیسک پکې و؟ دلته ستونزه په لوړه کچه حل کیږي. د ClickHouse په قضیه کې، موږ نقلونه لرو چې په لوړه کچه کار کوي، د بیلګې په توګه. د ClickHouse په کچه.
نتیجه اخستنه څه ده؟ DevOps د دې ډاډ ترلاسه کولو مسؤلیت لري چې ډاټا له لاسه نه ورکوي. هغه باید نقل په سمه توګه تنظیم کړي او باید ډاډ ترلاسه کړي چې نقل روان دی. د ClickHouse په کچه نقل باید نقل شوي ډاټا ولري. دا هغه دنده نه ده چې آپریټر یې حل کوي. او هغه ستونزه نه ده چې کوبرنیټس پخپله حل کوي. دا د ClickHouse په کچه دی.
څه وکړئ که ستاسو د اوسپنې نوډ له مینځه ویسي؟ او دا معلومه شوه چې تاسو به اړتیا ولرئ دویم نصب کړئ، په سمه توګه په دې کې ډیسک چمتو کړئ، او لیبلونه پلي کړئ. او له هغې وروسته ، دا به هغه اړتیاوې پوره کړي چې کوبرنیټس کولی شي پدې کې د مثال پوډ پیل کړي. Kubernetes به دا پیل کړي. ستاسو د پوډونو شمیر د ټاکل شوې شمیرې پوره کولو لپاره کافي ندي. دا به د هغه دورې څخه تیریږي چې ما ښودلې. او په لوړه کچه، ClickHouse به پوه شي چې موږ یو نقل ته داخل شوي یو، دا لاهم خالي دی او موږ باید دې ته د معلوماتو لیږدول پیل کړو. هغوی. دا پروسه لا تر اوسه ښه اتومات نه ده.
د راپور لپاره مننه! کله چې هر ډول ناوړه شیان پیښ شي، آپریټر خرابیږي او بیا پیل کیږي، او پدې وخت کې پیښې راځي، ایا تاسو دا په یو ډول اداره کوئ؟
څه پیښیږي که چیرې آپریټر خراب شي او بیا پیل شي، سمه ده؟
هو. او په دې وخت کې پیښې راورسیدې.
پدې قضیه کې د څه کولو دنده په جزوي ډول د آپریټر او کوبرنیټس ترمینځ شریکه شوې. کبرنیټس د دې وړتیا لري چې یوه پیښه تکرار کړي چې پیښ شوي. هغه بیا غږوي. او د آپریټر دنده دا ده چې ډاډ ترلاسه کړي چې کله د پیښې لاګ په هغه باندې بیا پلی کیږي ، دا پیښې غیر فعال دي. او د دې لپاره چې د ورته پیښې تکرار زموږ سیسټم مات نه کړي. او زموږ آپریټر د دې دندې سره مقابله کوي.
سلام! د راپور لپاره مننه! دیمتري زاویلوف، شرکت سمیدووا ایا داسې پلانونه شتون لري چې آپریټر ته د هاپروکسي سره تنظیم کولو وړتیا اضافه کړي؟ زه به د معیاري سربیره یو بل بیلانسر سره علاقه ولرم ، ترڅو دا سمارټ وي او پوه شي چې کلیک هاوس واقعیا شتون لري.
ایا تاسو د انګریس په اړه خبرې کوئ؟
هو، د هاپروکسي سره Ingress ځای په ځای کړئ. په هاپروکسي کې تاسو کولی شئ د کلستر ټوپولوژي مشخص کړئ چیرې چې دا نقلونه لري.
موږ تر اوسه په دې اړه فکر نه دی کړی. که تاسو ورته اړتیا لرئ او تشریح کولی شئ چې ولې ورته اړتیا ده، نو دا به ممکن وي چې پلي یې کړئ، په ځانګړې توګه که تاسو غواړئ ګډون وکړئ. موږ به خوښ یو چې اختیار په پام کې ونیسو. لنډ ځواب نه دی، موږ اوس مهال دا ډول فعالیت نه لرو. د لارښوونې لپاره مننه، موږ به دا مسله وګورو. او که تاسو د کارونې قضیه هم تشریح کړئ او ولې په عمل کې ورته اړتیا ده ، د مثال په توګه ، په GitHub کې مسلې رامینځته کړئ ، نو دا به عالي وي.
مخکې لري.
ښه. موږ هر ډول وړاندیزونو ته خلاص یو. او هاپروکسي د تودو لیست کې اضافه کیږي. د کار لیست مخ په ډیریدو دی، تر اوسه کم شوی نه دی. مګر دا ښه دی، دا پدې مانا ده چې محصول په تقاضا کې دی.
سرچینه: www.habr.com