نوټ. ژباړه: ډیلی موشن د نړۍ یو له لویو ویډیو کوربه توب خدماتو څخه دی او له همدې امله د پام وړ Kubernetes کارن دی. پدې موادو کې ، د سیسټم معمار ډیویډ ډونچیز د K8s پراساس د شرکت تولید پلیټ فارم رامینځته کولو پایلې شریکوي ، کوم چې په GKE کې د بادل نصب سره پیل شوی او د هایبرډ حل په توګه پای ته رسیدلی ، کوم چې د غوره غبرګون وخت او د زیربنا لګښتونو سپمولو ته اجازه ورکوي.
د اصلي API بیا جوړولو پریکړه کول درې کاله وړاندې، موږ غوښتل چې د غوښتنلیکونو کوربه کولو او اسانه کولو لپاره یوه اغیزمنه لاره جوړه کړو . د دې هدف لپاره ، موږ پریکړه وکړه چې د کانټینر آرکیسټریشن پلیټ فارم وکاروو او په طبیعي ډول کبرنیټس غوره کړو.
ولې د Kubernetes پراساس خپل پلیټ فارم جوړول ارزښت لري؟
د ګوګل کلاوډ کارولو په وخت کې د تولید کچې API
د 2016 اوړي
درې کاله دمخه ، سمدلاسه وروسته له هغه چې Dailymotion د لخوا پیرودل شو ، زموږ د انجینرۍ ټیمونه په یو نړیوال هدف متمرکز دي: د بشپړ نوي ډیلی موشن محصول رامینځته کول.
زموږ د کانټینرونو تحلیلونو، د آرکیسټریشن حلونو او زموږ د تیرو تجربو پراساس، موږ باوري یو چې کوبرنیټس سم انتخاب دی. ځینې پراختیا کونکي دمخه د لومړني مفاهیمو په اړه پوهه درلوده او پوهیدل چې څنګه یې کارول کیږي، کوم چې د زیربنا بدلون لپاره لویه ګټه وه.
د زیربنا له نظره، یو پیاوړی او انعطاف منونکی سیسټم ته اړتیا وه چې د کلاوډ اصلي غوښتنلیکونو نوي ډولونه کوربه کړي. موږ د خپل سفر په پیل کې په بادل کې پاتې کیدل غوره کړل نو موږ وکولی شو د ذهن د سولې سره د امکان تر ټولو قوي آنلاین پلیټ فارم جوړ کړو. موږ پریکړه وکړه چې خپل غوښتنلیکونه د ګوګل Kubernetes Engine په کارولو سره ځای په ځای کړو، که څه هم موږ پوهیږو چې ژر یا وروسته به موږ خپلو ډیټا مرکزونو ته لاړ شو او د هایبرډ ستراتیژي پلي کړو.
تاسو ولې GKE غوره کړ؟
موږ دا انتخاب په عمده توګه د تخنیکي دلایلو لپاره کړی. سربیره پردې، دا اړینه وه چې ژر تر ژره زیربنا چمتو کړي چې د شرکت سوداګریز اړتیاوې پوره کړي. موږ د کوربه کولو غوښتنلیکونو لپاره ځینې اړتیاوې درلودې، لکه جغرافیایي ویش، د توزیع وړتیا او د غلطۍ زغم.
په Dailymotion کې د GKE کلسترونه
څرنګه چې ډیلی موشن یو ویډیو پلیټ فارم دی چې په ټوله نړۍ کې شتون لري، موږ واقعیا غوښتل چې د انتظار وخت کمولو سره د خدماتو کیفیت ښه کړو ځنډ... پخوا یوازې په پاریس کې شتون درلود، کوم چې suboptimal و. ما غوښتل چې نه یوازې په اروپا کې ، بلکه په آسیا او متحده ایالاتو کې هم د غوښتنلیکونو کوربه توب وکړم.
ځنډ ته دا حساسیت پدې معنی دی چې جدي کار باید د پلیټ فارم شبکې جوړښت کې ترسره شي. پداسې حال کې چې ډیری کلاوډ خدمتونه تاسو دې ته اړ باسي چې په هره سیمه کې خپله شبکه جوړه کړئ او بیا یې د VPN یا یو ډول مدیریت شوي خدماتو له لارې وصل کړئ ، ګوګل کلاوډ تاسو ته اجازه درکوي چې د ګوګل ټولې سیمې پوښي په بشپړ ډول د روټ وړ واحد شبکه رامینځته کړئ. دا د سیسټم د عملیاتو او موثریت په برخه کې یو لوی پلس دی.
سربیره پردې ، د ګوګل کلاوډ څخه د شبکې خدمتونه او د بار بیلانسونه عالي دنده ترسره کوي. دوی په ساده ډول تاسو ته اجازه درکوي چې د هرې سیمې څخه خپل سري عامه IP پتې وکاروئ، او د BGP په زړه پورې پروتوکول د پاتې برخې پاملرنه کوي (د بیلګې په توګه د کاروونکو نږدې کلستر ته لیږدول). په ښکاره ډول، د ناکامۍ په صورت کې، ټرافيک به په اتوماتيک ډول د انساني مداخلې پرته بلې سيمې ته ځي.
د ګوګل د بار توازن څارنه
زموږ پلیټ فارم د GPUs درانه کارول هم کوي. ګوګل کلاوډ تاسو ته اجازه درکوي چې دا په مستقیم ډول د کوبرنیټس کلسترونو کې وکاروئ.
په هغه وخت کې، د زیربنا ټیم په ابتدايي توګه د میراث سټیک باندې تمرکز درلود چې په فزیکي سرورونو کې ځای پرځای شوي. له همدې امله د مدیریت شوي خدمت کارولو (د کوبرنیټس ماسټرانو په شمول) زموږ اړتیاوې پوره کړې او موږ ته اجازه راکړه چې ټیمونه وروزو ترڅو د ځایی کلسترونو سره کار وکړي.
د پایلې په توګه، موږ وکولی شو د کار له پیل څخه یوازې 6 میاشتې وروسته د ګوګل کلاوډ زیربنا کې د تولید ترافیک ترلاسه کول پیل کړو.
په هرصورت، د یو شمیر ګټو سره سره، د بادل چمتو کونکي سره کار کول د ځینې لګښتونو سره تړاو لري، کوم چې د بار پورې اړه لري. له همدې امله موږ هر هغه اداره شوي خدمتونه په دقت سره تحلیل کړل چې موږ یې کاروو، هیله مند یو چې په راتلونکي کې یې په ساحه کې پلي کړو. په حقیقت کې، د محلي کلسترونو تطبیق د 2016 په پای کې پیل شو او د هایبرډ ستراتیژي په ورته وخت کې پیل شوه.
د محلي کانټینر آرکیسټریشن پلیټ فارم ډیلی موشن پیل کول
د ۲۰۱۶ کال مني
په شرایطو کې کله چې ټول سټیک د تولید لپاره چمتو و، او په API کې کار وکړئ دا وخت دی چې په سیمه ایزو کلسترونو تمرکز وکړي.
په هغه وخت کې، کاروونکو هره میاشت له 3 ملیارد څخه ډیر ویډیوګانې لیدلې. البته، موږ د ډیرو کلونو لپاره زموږ د منځپانګې رسولو پراخه شبکه درلوده. موږ غوښتل له دې حالت څخه ګټه واخلو او د کوبرنیټس کلسترونه په موجوده ډیټا مرکزونو کې ځای په ځای کړو.
د ډیلی موشن زیربنا په شپږو ډیټا مرکزونو کې له 2,5 زرو څخه ډیر سرورونه لري. دا ټول د سالټسټیک په کارولو سره تنظیم شوي. موږ د ماسټر او کارګر نوډونو او همدارنګه د etcd کلستر جوړولو لپاره ټول اړین ترکیبونه چمتو کول پیل کړل.
د شبکې برخه
زموږ شبکه په بشپړه توګه راوتلې ده. هر سرور خپل IP په شبکه کې د Exabgp په کارولو سره اعلانوي. موږ د شبکې ډیری پلگ انونه پرتله کړل او یوازینی یو چې ټولې اړتیاوې یې پوره کړې (د L3 کارولو له امله) . دا د موجوده شبکې زیربنا ماډل کې په بشپړ ډول فټ کوي.
له هغه ځایه چې موږ غوښتل ټول موجود زیربنا عناصر وکاروو، لومړی شی چې موږ یې باید ترسره کړو هغه دا و چې زموږ د کور جوړ شوي شبکې کارونې (په ټولو سرورونو کې کارول کیږي): دا د کوبرنیټس نوډونو سره په شبکه کې د IP پتې سلسلې اعلانولو لپاره وکاروئ. موږ کالیکو ته اجازه ورکړه چې پوډونو ته IP پتې وټاکي، مګر دا یې ونه کړه او لاهم یې د شبکې تجهیزاتو کې د BGP غونډو لپاره نه کاروي. په حقیقت کې، روټینګ د Exabgp لخوا اداره کیږي، کوم چې د کیلیکو لخوا کارول شوي فرعي نیټ اعلانوي. دا موږ ته اجازه راکوي چې د داخلي شبکې څخه هر پوډ ته ورسیږو (او په ځانګړي توګه د بار بیلنسرز څخه).
موږ څنګه د ننوتلو ترافیک اداره کوو
غوښتل شوي خدمت ته د راتلونکو غوښتنو د لیږلو لپاره، دا پریکړه وشوه چې د انګریس کنټرولر څخه کار واخلئ ځکه چې د کوبرنیټس انګریس سرچینو سره یوځای کول.
درې کاله دمخه، nginx-ingress-controller تر ټولو بالغ کنټرولر و: Nginx د اوږدې مودې لپاره شاوخوا و او د خپل ثبات او فعالیت لپاره پیژندل شوی و.
زموږ په سیسټم کې ، موږ پریکړه وکړه چې کنټرولرونه په وقف شوي 10-ګیګابایټ بلیډ سرورونو کې ځای په ځای کړو. هر کنټرولر د اړوند کلستر د کیوب - اپیسرور پای نقطې سره وصل و. دا سرورونه د عامه یا شخصي IP پتې اعلانولو لپاره Exabgp هم کاروي. زموږ د شبکې ټوپولوژي موږ ته اجازه راکوي چې د دې کنټرولرونو څخه BGP وکاروو ترڅو ټول ټرافیک مستقیم پوډونو ته واستوو پرته لدې چې د نوډ پورټ په څیر خدمت کارولو څخه. دا طریقه د نوډونو تر مینځ د افقی ترافیک څخه مخنیوي کې مرسته کوي او موثریت ته وده ورکوي.
د انټرنیټ څخه پوډونو ته د ترافیک حرکت
اوس چې موږ خپل هایبرډ پلیټ فارم پوهیږو، موږ کولی شو پخپله د ټرافيکي مهاجرت پروسې ته ژوره ورسوو.
د ګوګل کلاوډ څخه ډیلی موشن زیربنا ته د ترافیک مهاجرت
د ۲۰۱۶ کال مني
د شاوخوا دوه کلونو جوړولو ، ازموینې ، او ټونینګ وروسته ، موږ په پای کې د یو څه ټرافیک منلو لپاره د کوبرنیټس بشپړ سټیک لرو.
د روټینګ اوسنۍ تګلاره خورا ساده ده، مګر د اړتیاوو پوره کولو لپاره کافي ده. د عامه IPs سربیره (په ګوګل کلاوډ او ډیلی موشن کې) ، د AWS روټ 53 د پالیسیو تنظیم کولو او کاروونکي زموږ د خوښې کلستر ته لیږلو لپاره کارول کیږي.
د روټ 53 په کارولو سره د روټینګ پالیسۍ مثال
د ګوګل کلاوډ سره دا اسانه ده ځکه چې موږ په ټولو کلسترونو کې یو واحد IP شریکوو او کاروونکي نږدې GKE کلستر ته لیږل کیږي. زموږ د کلسترونو لپاره ټیکنالوژي توپیر لري، ځکه چې د دوی IPs مختلف دي.
د مهاجرت په جریان کې، موږ هڅه وکړه چې سیمه ایزې غوښتنې مناسبو کلسترونو ته واړوو او د دې طریقې ګټې یې ارزولې.
ځکه چې زموږ د GKE کلسترونه د ګمرک میټریکونو په کارولو سره د آټو سکیل لپاره تنظیم شوي ، دوی د راتلونکي ترافیک پراساس اندازه پورته/ ښکته کوي.
په نورمال حالت کې، ټول سیمه ایز ترافیک محلي کلستر ته لیږدول کیږي، او GKE د ستونزو په صورت کې د ریزرو په توګه کار کوي (روغتیا معاینه د روټ 53 لخوا ترسره کیږي).
...
په راتلونکي کې، موږ غواړو چې د روټینګ تګلارې په بشپړه توګه اتومات کړو ترڅو یو خپلواکه هایبرډ ستراتیژي ترلاسه کړو چې په دوامداره توګه د کاروونکو لپاره لاسرسی ښه کوي. په پلس اړخ کې، د بادل لګښتونه د پام وړ کم شوي او د API غبرګون وختونه حتی کم شوي. موږ د نتیجې کلاوډ پلیټ فارم باور لرو او چمتو یو چې د اړتیا په صورت کې دې ته نور ټرافيکي لارښود کړو.
PS د ژباړونکي څخه
تاسو ممکن د Kubernetes په اړه بل وروستي Dailymotion پوسټ کې هم علاقه ولرئ. دا په ډیری کبرنیټ کلسترونو کې د هیلم سره د غوښتنلیکونو پلي کولو ته وقف شوی او شاوخوا یوه میاشت مخکې.
زموږ په بلاګ کې هم ولولئ:
- «".
- «»
- «»
- «»
- «»
- «»
- «»
- «»
- «»
- «»
- «".
سرچینه: www.habr.com