نوټ. ژباړه: د نړۍ د مشهور ټینډر خدمت کارمندانو پدې وروستیو کې کوبرنیټس ته د دوی زیربنا د مهاجرت ځینې تخنیکي توضیحات شریک کړل. دې پروسې نږدې دوه کاله وخت ونیو او په پایله کې یې په K8s کې خورا لوی پلیټ فارم پیل کړ، چې په 200 زره کانټینرونو کې د 48 خدماتو کوربه توب درلود. د Tinder انجینران له کومو په زړه پورې ستونزو سره مخ شول او کومې پایلې ته ورسیدل؟ دا ژباړه ولولئ.
ولې؟
نږدې دوه کاله دمخه ، ټینډر پریکړه وکړه چې خپل پلیټ فارم کوبرنیټس ته واړوي. کوبرنیټس به د ټینډر ټیم ته اجازه ورکړي چې کانټینر شي او تولید ته د لږې هڅې سره د نه بدلیدونکي ګمارنې له لارې حرکت وکړي (نه بدلیدونکی ګمارنه). په دې حالت کې، د غوښتنلیکونو راټولول، د دوی ځای پرځای کول، او زیربنا به په ځانګړي ډول د کوډ لخوا تعریف شي.
موږ د توزیع او ثبات د ستونزې د حل په لټه کې یو. کله چې اندازه کول خورا مهم شول، موږ ډیری وختونه باید د نوي EC2 مثالونو لپاره څو دقیقې انتظار وکړو. د کانټینرونو په لاره اچولو او د دقیقو پرځای په ثانیو کې د ترافیک خدمت پیل کولو نظر موږ ته خورا زړه راښکونکی شو.
پروسه ستونزمنه وه. د 2019 په پیل کې زموږ د مهاجرت په جریان کې، د کوبرنیټس کلستر مهمې کچې ته ورسید او موږ د ترافیک حجم، کلستر اندازې، او DNS له امله د مختلفو ستونزو سره مخ شو. د لارې په اوږدو کې، موږ د 200 خدماتو مهاجرت او د 1000 نوډونو، 15000 پوډونو او 48000 روان کانټینرونو څخه مشتمل د Kubernetes کلستر ساتلو پورې اړوند ډیرې په زړه پورې ستونزې حل کړې.
څنګه؟
د 2018 کال د جنورۍ راهیسې، موږ د مهاجرت له مختلفو مرحلو څخه تیر شوي یو. موږ د خپلو ټولو خدماتو کانټینر کولو او د کوبرنیټس ټیسټ کلاوډ چاپیریالونو ته د ځای په ځای کولو سره پیل کړی. د اکتوبر په میاشت کې، موږ په طریقه سره د ټولو موجوده خدماتو کوبرنیټس ته لیږدول پیل کړل. د راتلونکي کال د مارچ په میاشت کې، موږ مهاجرت بشپړ کړ او اوس د Tinder پلیټ فارم په ځانګړي ډول په کوبرنیټس کې پرمخ ځي.
د Kubernetes لپاره د انځورونو جوړول
موږ د مایکرو خدماتو لپاره له 30 څخه ډیر د سرچینې کوډ ذخیره لرو چې د کوبرنیټس کلستر کې پرمخ ځي. په دې زیرمو کې کوډ په مختلفو ژبو لیکل شوی (د بیلګې په توګه، Node.js، Java، Scala، Go) د ورته ژبې لپاره د ډیری چلولو چاپیریال سره.
د جوړونې سیسټم د دې لپاره ډیزاین شوی چې د هر مایکرو خدماتو لپاره په بشپړ ډول دودیز کولو وړ "جوړولو شرایط" چمتو کړي. دا معمولا د Dockerfile او د شیل کمانډونو لیست لري. د دوی مینځپانګه په بشپړ ډول د تنظیم وړ ده ، او په ورته وخت کې ، دا ټول جوړ شوي شرایط د معیاري شکل سره سم لیکل شوي. د ساختماني شرایطو معیاري کول د یو واحد جوړونې سیسټم ته اجازه ورکوي چې ټول مایکرو خدمتونه اداره کړي.
شکل 1-1. د بلډر کانټینر له لارې د معیاري جوړونې پروسه
د منډو تر مینځ اعظمي ثبات ترلاسه کولو لپاره (د چلولو چاپیریال) ورته جوړونې پروسه د پراختیا او ازموینې پرمهال کارول کیږي. موږ د یوې خورا په زړه پوري ننګونې سره مخ یو: موږ باید یوه لاره رامینځته کړو ترڅو په ټول پلیټ فارم کې د جوړونې چاپیریال دوام تضمین کړو. د دې د ترلاسه کولو لپاره، د ټول مجلس پروسې په ځانګړي کانټینر کې ترسره کیږي. جوړونکی.
د هغه کانټینر پلي کول پرمختللي ډاکر تخنیکونو ته اړتیا لري. جوړونکی د ځایی کارن ID او رازونه (لکه د SSH کیلي، د AWS اسناد، او نور) په میراث ترلاسه کوي چې د خصوصي ټینډر ذخیره کولو ته اړتیا لري. دا سیمه ایز لارښودونه نصبوي چې سرچینې لري ترڅو په طبیعي ډول د ساختماني آثارو ذخیره کړي. دا طریقه فعالیت ته وده ورکوي ځکه چې دا د جوړونکي کانټینر او کوربه ترمینځ د ساختماني آثارو کاپي کولو اړتیا له مینځه وړي. زیرمه شوي ساختماني اثار پرته له اضافي ترتیب څخه کارول کیدی شي.
د ځینو خدماتو لپاره، موږ باید یو بل کانټینر جوړ کړو ترڅو د رن ټایم چاپیریال ته د تالیف چاپیریال نقشه کړو (د مثال په توګه، د Node.js bcrypt کتابتون د نصب کولو په وخت کې د پلیټ فارم ځانګړي بائنری آثار تولیدوي). د تالیف پروسې په جریان کې ، اړتیاوې ممکن د خدماتو ترمینځ توپیر ولري ، او وروستی ډاکر فایل په الوتنه کې تالیف شوی.
د کوبرنیټس کلستر جوړښت او مهاجرت
د کلستر اندازه مدیریت
موږ د کارولو پریکړه وکړه kube-aws د ایمیزون EC2 مثالونو کې د اتومات کلستر ګمارنې لپاره. په پیل کې، هرڅه د نوډونو په یو عام حوض کې کار کاوه. موږ ژر تر ژره د اندازې او مثال ډول سره د کاري بارونو جلا کولو اړتیا درک کړه ترڅو د سرچینو ډیر مؤثره کار واخیستل شي. منطق دا و چې د څو بار شوي څو-تریډ شوي پوډونو چلول د فعالیت له مخې د دوی د یو لوی شمیر واحد تار شوي پوډونو سره د دوی د هماهنګۍ په پرتله ډیر وړاندوینې وړ و.
په پای کې موږ په دې اړه پریکړه وکړه:
- m5.4x لوی - د څارنې لپاره (Prometheus)؛
- c5.4x لوی - د Node.js کاري بار لپاره (واحد تار شوي کاري بار)؛
- c5.2x لوی - د جاوا او ګو لپاره (د څو ټریډ شوي کاري بار)؛
- c5.4x لوی - د کنټرول پینل لپاره (3 نوډونه).
مهاجرت
د زاړه زیربنا څخه Kubernetes ته د مهاجرت لپاره یو له چمتووالي ګامونو څخه دا و چې د خدماتو تر مینځ موجوده مستقیم ارتباط نوي بار بیلنسرز (Elastic Load Balancers) (ELB) ته واستول شي. دوی د مجازی خصوصي کلاوډ (VPC) په ځانګړي فرعي نیټ کې رامینځته شوي. دا فرعي شبکه د Kubernetes VPC سره وصل وه. دې موږ ته اجازه راکړه چې ماډلونه په تدریجي ډول مهاجرت کړو، پرته له دې چې د خدماتو انحصار ځانګړي ترتیب ته پام وکړو.
دا پای ټکي د DNS ریکارډونو وزن لرونکي سیټونو په کارولو سره رامینځته شوي چې CNAMEs یې هر نوي ELB ته په ګوته کوي. د بدلولو لپاره، موږ د کوبرنیټس خدمت نوي ELB ته د 0 وزن سره یوه نوې داخله اضافه کړه. بیا مو د ننوتلو وخت (TTL) 0 ته ټاکلی و. له دې وروسته، زاړه او نوي وزنونه وو. ورو ورو تنظیم شوی، او بالاخره د بار 100٪ نوي سرور ته لیږل شوی. وروسته له دې چې سویچ بشپړ شو، د TTL ارزښت ډیر مناسب کچې ته راستون شو.
د جاوا ماډلونه چې موږ یې درلودل د ټیټ TTL DNS سره مقابله کولی شو، مګر د نوډ غوښتنلیکونه نشي کولی. یو انجینر د پیوستون حوض کوډ یوه برخه بیا لیکلې او په مدیر کې یې وتړله چې په هر 60 ثانیو کې حوضونه تازه کوي. غوره شوي چلند خورا ښه کار وکړ او پرته له کوم پام وړ فعالیت تخریب.
درسونه
د شبکې فابریک محدودیتونه
د 8 جنوري 2019 په سهار کې، د ټینډر پلیټ فارم په ناڅاپي ډول ټکر شو. د سهار په پیل کې د پلیټ فارم ځنډ کې غیر اړونده زیاتوالي په ځواب کې ، په کلستر کې د پوډونو او نوډونو شمیر ډیر شو. دا د دې لامل شوی چې د ARP کیچ زموږ په ټولو نوډونو کې ختم شي.
د ARP کیچ پورې اړوند درې لینکس اختیارونه شتون لري:
()
gc_thresh3 - دا یو سخت حد دی. په لاګ کې د "ګاونډي میز اوور فلو" ننوتلو څرګندیدل پدې معنی دي چې حتی د همغږي کثافاتو راټولولو (GC) وروسته ، د ARP زیرمه کې د ګاونډي ننوتلو ذخیره کولو لپاره کافي ځای شتون نلري. په دې حالت کې، دانه په ساده ډول پاکټ په بشپړه توګه رد کړ.
موږ یی استعمالوو په Kubernetes کې د شبکې پارچه په توګه. کڅوړې د VXLAN له لارې لیږدول کیږي. VXLAN یو L2 تونل دی چې د L3 شبکې په سر کې پورته شوی. دا ټیکنالوژي د MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation کاروي او د لیر 2 شبکې برخو پراخولو ته اجازه ورکوي. د فزیکي معلوماتو مرکز شبکه کې د ټرانسپورټ پروتوکول IP پلس UDP دی.
شکل 2-1. فلالین ډیاګرام ()
شکل 2-2. د VXLAN بسته ()
هر Kubernetes کارګر نوډ د لوی / 24 بلاک څخه د /9 ماسک سره د مجازی پته ځای تخصیص کوي. د هر نوډ لپاره دا دی یوه داخله په روټینګ جدول کې، یوه ننوتنه په ARP جدول کې (په فلانیل.1 انٹرفیس کې)، او یوه داخله د بدلولو میز (FDB) کې. دوی د لومړي ځل لپاره اضافه کیږي کله چې د کارګر نوډ پیل شي یا هر ځل چې نوی نوډ کشف شي.
سربیره پردې، نوډ پوډ (یا پوډ پوډ) اړیکه په پای کې د انٹرفیس له لارې تیریږي ایتکسینکس (لکه څنګه چې پورته فلالین ډیاګرام کې ښودل شوي). دا د هرې اړوندې سرچینې او منزل کوربه لپاره د ARP جدول کې اضافي ننوتلو پایله لري.
زموږ په چاپیریال کې، دا ډول ارتباط خورا عام دی. په Kubernetes کې د خدماتو شیانو لپاره، یو ELB جوړ شوی او Kubernetes هر نوډ د ELB سره راجستر کوي. ELB د پوډونو په اړه هیڅ نه پوهیږي او ټاکل شوي نوډ ممکن د کڅوړې وروستی منزل نه وي. ټکی دا دی چې کله یو نوډ د ELB څخه پاکټ ترلاسه کوي، دا د قواعدو په پام کې نیولو سره په پام کې نیسي iptables د یو ځانګړي خدمت لپاره او په تصادفي ډول په بل نوډ کې پوډ غوره کوي.
د ناکامۍ په وخت کې، په کلستر کې 605 نوډونه وو. د پورته ذکر شوي دلیلونو لپاره، دا د اهمیت د لرې کولو لپاره کافي و gc_thresh3، کوم چې ډیفالټ دی. کله چې دا پیښ شي، نه یوازې د کڅوړو غورځول پیل کیږي، مګر د /24 ماسک سره د فلالین بشپړ مجازی پته ځای د ARP میز څخه ورک کیږي. د نوډ پوډ ارتباط او د DNS پوښتنې مداخله کوي (DNS په کلستر کې کوربه شوی؛ د توضیحاتو لپاره پدې مقاله کې وروسته ولولئ).
د دې ستونزې د حل لپاره، تاسو اړتیا لرئ چې ارزښتونه زیات کړئ gc_thresh1, gc_thresh2 и gc_thresh3 او د ورک شوي شبکو د بیا راجستر کولو لپاره فلانیل بیا پیل کړئ.
غیر متوقع DNS اندازه کول
د مهاجرت پروسې په جریان کې، موږ په فعاله توګه د ټرافیک اداره کولو لپاره DNS کارولی او په تدریجي ډول د زاړه زیربنا څخه Kubernetes ته خدمتونه لیږدول. موږ په Route53 کې د اړوندو RecordSets لپاره نسبتا ټیټ TTL ارزښتونه ترتیب کړل. کله چې زوړ زیربنا د EC2 مثالونو کې روانه وه، زموږ د حل کولو ترتیب د ایمیزون DNS ته اشاره وکړه. موږ دا په پام کې نیولې او زموږ په خدماتو او ایمیزون خدماتو (لکه ډینامو ډی بی) باندې د ټیټ TTL اغیزې په پراخه کچه د پام وړ ندي.
لکه څنګه چې موږ Kubernetes ته خدمتونه لیږدول، موږ وموندله چې DNS په هره ثانیه کې 250 زره غوښتنې پروسس کوي. د پایلې په توګه، غوښتنلیکونه د DNS پوښتنو لپاره دوامداره او جدي وخت تجربه کول پیل کړل. دا د نه منلو وړ هڅو سره سره پیښ شوي چې د DNS چمتو کونکي غوره کولو او بدلولو لپاره CoreDNS (کوم چې په لوړ بار کې 1000 پوډونو ته رسیدلي چې په 120 کور کې روان دي).
پداسې حال کې چې د نورو ممکنه لاملونو او حلونو څیړنه، موږ وموندل د نسل شرایط تشریح کول چې د پاکټ فلټر کولو چوکاټ اغیزه کوي جال جوړونکی په لینکس کې. هغه مهال ویش چې موږ ولیدل، د مخ په زیاتیدونکي کاونټر سره یوځای insert_failed په فلانیل انٹرفیس کې د مقالې موندنو سره مطابقت درلود.
ستونزه د سرچینې او منزل شبکې پته ژباړې (SNAT او DNAT) او ورپسې جدول ته د ننوتلو په مرحله کې پیښیږي contrack. یو له کاري حلونو څخه چې په داخلي توګه بحث شوی او د ټولنې لخوا وړاندیز شوی دا و چې DNS پخپله د کارګر نوډ ته واړوي. په دې حالت کې:
- SNAT ته اړتیا نشته ځکه چې ترافیک د نوډ دننه پاتې کیږي. دا اړتیا نلري چې د انٹرفیس له لارې تیر شي ایتکسینکس.
- DNAT ته اړتیا نشته ځکه چې د منزل IP نوډ ته ځایی دی، او د مقرراتو سره سم په تصادفي ډول ټاکل شوی پوډ ندی iptables.
موږ پریکړه وکړه چې د دې طریقې سره ودریږو. CoreDNS په Kubernetes کې د ډیمون سیټ په توګه ګمارل شوی و او موږ په سیمه ایز نوډ DNS سرور پلي کړ حل کول هر پوډ د بیرغ په ترتیبولو سره --cluster-dns امرونه کبلیت . دا حل د DNS وخت پای ته رسیدو لپاره مؤثره ثابت شو.
په هرصورت، موږ لاهم د پیکټ ضایع او په کاونټر کې زیاتوالی لیدلی insert_failed په فلانیل انٹرفیس کې. دا وروسته له دې چې د کاري حل پلي کیدو ته دوام ورکړ ځکه چې موږ وکولی شو یوازې د DNS ترافیک لپاره SNAT او/یا DNAT له مینځه یوسو. د ریس شرایط د نورو ډولونو ترافیک لپاره ساتل شوي. خوشبختانه ، زموږ ډیری کڅوړې TCP دي ، او که کومه ستونزه رامینځته شي دوی په ساده ډول بیرته لیږدول کیږي. موږ لاهم هڅه کوو چې د هر ډول ترافیک لپاره مناسب حل ومومئ.
د غوره بار بیلانس لپاره د انوان کارول
لکه څنګه چې موږ Kubernetes ته د بیکینډ خدمتونه مهاجرت کړل، موږ د پوډونو تر منځ د غیر متوازن بار سره مخ شو. موږ وموندله چې HTTP Keepalive د دې لامل شوی چې د ELB اړیکې د هرې ګمارنې په لومړي چمتو پوډونو کې ځړول شي. په دې توګه، د ټرافیک لویه برخه د شته پوډونو کوچنۍ فیصده څخه تیریږي. لومړی حل چې موږ یې ازموینه کړې د بدترین حالت سناریوګانو لپاره په نوي ګمارلو کې 100٪ ته د MaxSurge تنظیم کول وو. اغیزه د لویو ګمارلو په شرایطو کې بې اهمیته او نا امیده وه.
یو بل حل چې موږ یې کارولی و په مصنوعي ډول د مهمو خدماتو لپاره د سرچینو غوښتنې زیاتول. په دې حالت کې، نږدې ځای پر ځای شوي پوزې به د نورو درنو پوډرو په پرتله د چلولو لپاره ډیر ځای ولري. دا به په اوږد مهال کې کار ونکړي ځکه چې دا به د سرچینو ضایع وي. برسېره پردې، زموږ د نوډ غوښتنلیکونه واحد تار شوي وو او په وینا یې، یوازې یو کور کارولی شي. یوازینۍ اصلي حل دا و چې د غوره بار توازن کارول وکاروئ.
موږ له ډیرې مودې راهیسې په بشپړ ډول تعریف کول غواړو . اوسني وضعیت موږ ته اجازه راکړه چې دا په خورا محدود ډول ځای په ځای کړو او سمدستي پایلې ترلاسه کړو. Envoy یو لوړ فعالیت، خلاص سرچینه، پراکسی - XNUMX پراکسي د لوی SOA غوښتنلیکونو لپاره ډیزاین شوی. دا کولی شي د بار بار توازن پرمختللي تخنیکونه پلي کړي ، پشمول د اتوماتیک بیاکتنې ، سرکټ ماتونکي ، او د نړیوال نرخ محدودیت. (نوټ. ژباړه: تاسو کولی شئ په دې اړه نور ولولئ د اسټیو په اړه، کوم چې د سفیر پر بنسټ والړ دی.)
موږ د لاندې تشکیلاتو سره راغلي یو: د هر پوډ او یوې لارې لپاره د انوای سایډ کار ولرئ، او کلستر په ځایی ډول د بندر له لارې کانټینر سره وصل کړئ. د احتمالي کاسکیډینګ کمولو او د یوې کوچنۍ هټ ریډیوس ساتلو لپاره ، موږ د هر خدمت لپاره د هر یو د موجودیت زون (AZ) لپاره د اینواو فرنټ پراکسي پوډونو بیړۍ کارولې. دوی زموږ د یو انجینر لخوا لیکل شوي د ساده خدماتو کشف انجن باندې تکیه وکړه چې په ساده ډول د ورکړل شوي خدمت لپاره په هر AZ کې د پوډونو لیست بیرته راستانه کړ.
د خدماتو مخکینۍ سفیرانو بیا د دې خدماتو کشف میکانیزم د یو اپ سټریم کلستر او لارې سره کارولی. موږ کافي وخت پای ته ورساوه، د سرکټ ماتونکي ټول ترتیبات یې زیات کړل، او د یوې ناکامۍ سره د مرستې لپاره د لږ تر لږه بیاکتنې ترتیبات اضافه کړل او د اسانه ځای پرځای کول ډاډمن کړل. موږ د دې هر یو خدمت مخکښ سفیر مخې ته TCP ELB کیښود. حتی که زموږ د اصلي پراکسي پرت څخه ساتل په ځینو انوی پوډونو کې ودرول شوي، دوی لاهم د دې توان درلود چې بار خورا ښه اداره کړي او په پس منظر کې د لږترلږه_request له لارې توازن لپاره تنظیم شوي.
د ګمارلو لپاره ، موږ د غوښتنلیک پوډونو او سایډ کار پوډونو دواړو کې د پری سټاپ هک کارولی. هک د سایډ کار کانټینر کې موقعیت لرونکي د اډمین پای پوائنټ حالت چیک کولو کې یوه تېروتنه رامینځته کړه او د یو څه وخت لپاره خوب ته لاړ ترڅو فعال ارتباطات پای ته ورسوي.
یو له هغو دلیلونو څخه چې موږ دومره ګړندي حرکت کولو توان درلود د تفصيلي میټریکونو له امله دی چې موږ وکولی شو په اسانۍ سره د پرومیټیوس نصب کولو کې مدغم شو. دې موږ ته اجازه راکړه چې دقیقا وګورو چې څه پیښیږي پداسې حال کې چې موږ د تنظیم کولو پیرامیټونه تنظیم کړل او ټرافيک یې بیا توزیع کړ.
پایلې سمدستي او څرګندې وې. موږ د خورا غیر متوازن خدماتو سره پیل کړی، او دا مهال دا په کلستر کې د 12 خورا مهم خدماتو په وړاندې کار کوي. سږکال موږ د لا پرمختللي خدماتو کشف ، سرکټ ماتولو ، بهر کشف ، د نرخ محدودیت او تعقیب سره بشپړ خدمت میش ته لیږد پلان کوو.
شکل 3-1. سفیر ته د لیږد پرمهال د یو خدمت CPU کنورژن
وروستۍ پایله
د دې تجربې او اضافي څیړنو له لارې، موږ د لویو Kubernetes کلسترونو ډیزاین کولو، ځای پر ځای کولو او چلولو کې د قوي مهارتونو سره یو پیاوړی زیربنا ټیم جوړ کړی دی. د ټینډر ټول انجنیران اوس پوهه او تجربه لري چې کانټینرونه بسته کړي او کوبرنیټس ته غوښتنلیکونه ځای په ځای کړي.
کله چې په زاړه زیربنا کې اضافي ظرفیت ته اړتیا رامینځته شوه ، موږ باید د نوي EC2 مثالونو پیل کولو لپاره څو دقیقې انتظار وکړو. اوس کانټینرونه چلول پیل کوي او د دقیقو پرځای په ثانیو کې د ترافیک پروسس پیل کوي. په یو واحد EC2 مثال کې د څو کانټینرونو مهالویش کول هم ښه افقی غلظت چمتو کوي. د پایلې په توګه، موږ د تیر کال په پرتله په 2019 کې د EC2 لګښتونو کې د پام وړ کمښت وړاندوینه کوو.
مهاجرت نږدې دوه کاله وخت ونیو، مګر موږ دا د 2019 په مارچ کې بشپړ کړ. اوس مهال، د Tinder پلیټ فارم په ځانګړې توګه د Kubernetes په کلستر کې چلیږي چې 200 خدمات، 1000 نوډونه، 15 پوډونه او 000 روان کانټینرونه لري. زیربنا نور د عملیاتي ټیمونو یوازینۍ ډومین نه دی. زموږ ټول انجینران دا مسؤلیت شریکوي او یوازې د کوډ په کارولو سره د دوی غوښتنلیکونو جوړولو او پلي کولو پروسه کنټرولوي.
PS د ژباړونکي څخه
زموږ په بلاګ کې د مقالو لړۍ هم ولولئ:
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
سرچینه: www.habr.com