توجه داشته باشید ترجمه: این ترجمه یک پس از مرگ عمومی از وبلاگ مهندسی این شرکت است . این یک مشکل با conntrack در یک خوشه Kubernetes را توصیف می کند که منجر به از کار افتادن جزئی برخی از خدمات تولید شده است.
این مقاله ممکن است برای کسانی مفید باشد که می خواهند کمی بیشتر در مورد پس از مرگ بیاموزند یا از برخی مشکلات احتمالی DNS در آینده جلوگیری کنند.
این DNS نیست
نمی تواند DNS باشد
DNS بود
کمی در مورد پس از مرگ و فرآیندها در Preply
پس از مرگ یک نقص یا رویدادی در تولید را توصیف می کند. پس از مرگ شامل جدول زمانی رویدادها، تأثیر کاربر، علت اصلی، اقدامات انجام شده و درس های آموخته شده است.
در جلسات هفتگی با پیتزا، در میان تیم فنی، اطلاعات مختلفی را به اشتراک می گذاریم. یکی از مهم‌ترین بخش‌های این جلسات، پس از مرگ است که اغلب با ارائه اسلاید و تحلیل عمیق‌تر حادثه همراه است. حتی با وجود اینکه ما بعد از مرگ کف نمی زنیم، اما سعی می کنیم فرهنگ "بدون سرزنش" را توسعه دهیم (). ما معتقدیم که نوشتن و ارائه پس از مرگ می تواند به ما (و دیگران) کمک کند تا از حوادث مشابه در آینده جلوگیری کنیم، به همین دلیل است که آنها را به اشتراک می گذاریم.
افراد درگیر در یک حادثه باید احساس کنند که می توانند بدون ترس از مجازات یا تلافی با جزئیات صحبت کنند. بدون سرزنش! نوشتن پس از مرگ یک مجازات نیست، بلکه یک فرصت یادگیری برای کل شرکت است.
مشکلات DNS در Kubernetes. پس از مرگ
تاریخ: 28.02.2020
نویسنده: آمت یو.، آندری اس.، ایگور ک.، الکسی پی.
وضعیت: تمام شده
به طور خلاصه: در دسترس نبودن جزئی DNS (26 دقیقه) برای برخی از خدمات در خوشه Kubernetes
نظر: 15000 رویداد برای سرویس های A، B و C از دست رفت
علت ریشه ای: Kube-proxy نتوانست به درستی یک ورودی قدیمی را از جدول conntrack حذف کند، بنابراین برخی از سرویس‌ها همچنان سعی می‌کردند به غلاف‌های موجود متصل شوند.
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...ماشه: به دلیل بار کم در داخل خوشه Kubernetes، CoreDNS-autoscaler تعداد پادها در استقرار را از سه به دو کاهش داد.
راه حل: استقرار بعدی برنامه شروع به ایجاد گره های جدید کرد، CoreDNS-autoscaler غلاف های بیشتری را برای سرویس دهی به خوشه اضافه کرد، که باعث بازنویسی جدول conntrack شد.
تشخیص: نظارت پرومتئوس تعداد زیادی خطای 5xx را برای سرویس های A، B و C شناسایی کرد و با مهندسان وظیفه تماس گرفت.
خطاهای 5xx در کیبانا
فعالیت
اثر
نوع
مسئول
کار
Autoscaler را برای CoreDNS غیرفعال کنید
جلوگیری کرد
آمت یو.
DEVOPS-695
یک سرور DNS کش راه اندازی کنید
نزول کردن
مکس وی.
DEVOPS-665
مانیتورینگ contrack را تنظیم کنید
جلوگیری کرد
آمت یو.
DEVOPS-674
درس های آموخته شده
چه خوب شد:
- نظارت خوب کار کرد. پاسخ سریع و منظم بود
- ما هیچ محدودیتی در گره ها نگرفتیم
چه اشکالی داشت:
- هنوز علت اصلی ناشناخته واقعی، مشابه در کنتراک
- همه اقدامات فقط پیامدها را اصلاح می کنند، نه علت اصلی (اشکال)
- می دانستیم که دیر یا زود ممکن است با DNS مشکل داشته باشیم، اما وظایف را اولویت بندی نکردیم
جایی که ما شانس آوردیم:
- استقرار بعدی توسط CoreDNS-autoscaler راه اندازی شد که جدول conntrack را بازنویسی کرد.
- این اشکال فقط برخی از سرویس ها را تحت تاثیر قرار داده است
جدول زمانی (EET)
زمان
اثر
22:13
CoreDNS-autoscaler تعداد پادها را از سه به دو کاهش داد
22:18
مهندسان وظیفه شروع به دریافت تماس از سیستم نظارت کردند
22:21
مهندسان وظیفه شروع به کشف علت اشتباهات کردند.
22:39
مهندسان وظیفه شروع به بازگرداندن یکی از آخرین خدمات به نسخه قبلی کردند
22:40
خطاهای 5xx ظاهر نشدند، وضعیت تثبیت شده است
- زمان تشخیص: دقیقه 4
- زمان قبل از اقدام: دقیقه 21
- زمان اصلاح: دقیقه 1
اطلاعات اضافی
- لاگ های CoreDNS:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - پیوندهای کیبانا (برش)، گرافانا (برش)
برای به حداقل رساندن استفاده از CPU، هسته لینوکس از چیزی به نام conntrack استفاده می کند. به طور خلاصه، این ابزاری است که حاوی لیستی از رکوردهای NAT است که در یک جدول خاص ذخیره می شوند. هنگامی که بسته بعدی از همان غلاف به همان غلاف قبلی رسید، آدرس IP نهایی مجدداً محاسبه نمی شود، بلکه از جدول conntrack گرفته می شود.
Contrack چگونه کار می کند
نمایش نتایج: از
این نمونه ای از یکی از پس از مرگ ما با چند پیوند مفید بود. به طور خاص در این مقاله، اطلاعاتی را به اشتراک می گذاریم که ممکن است برای شرکت های دیگر مفید باشد. به همین دلیل است که ما از اشتباه کردن نمی ترسیم و به همین دلیل است که یکی از پس از مرگ خود را عمومی می کنیم. در اینجا چند پس از مرگ عمومی جالب تر وجود دارد:
- GitLab:
- Dropbox:
- Spotify:
- بسیاری دیگر از و مخزن
- همچنین پس از مرگ عمومی با کتاب SRE
منبع: www.habr.com