Kubernetes برای کسانی که باید آن را اجرا کنند

آموزش‌های Kubernetes به شما یاد می‌دهند چگونه یک pod را배포 کنید. هیچکس به شما نمی‌آموزد وقتی یک node به طور خاموش از Ready state خارج شود در ساعت ۳ شب و تلفن on-call شما نه‌تنها زنگ می‌زند، باید چه کار کنید. این درباره قسمت دوم است.

Resource requests و limits اختیاری نیستند

اگر resources.requests و resources.limits را روی containerهایتان حذف کنید، scheduler داشته باشد حدس می‌زند، و kubelet هیچ ایده‌ای ندارد وقتی node کم حافظه دارد ابتدا چه چیزی را evict کند. requests را برابر آنچه container در شرایط بار عادی واقعاً استفاده می‌کند تنظیم کنید، نه آنچه امیدوار هستید استفاده کند. memory limits را نزدیک به requests تنظیم کنید زیرا OOM-killed pods به صورت تمیز restart می‌شوند، اما CPU limits باید عموماً سست‌تر یا غیر موجود باشد مگر اینکه با noisy neighbors درگیری داشته باشید، زیرا CPU throttling در یک hard limit باعث latency spikes می‌شود که debugging آن فاجعه‌بار است. به طور منظم kubectl top pods -n your-namespace را اجرا کنید و آن را با آنچه اعلام کرده‌اید مقایسه کنید. عدم تطابق‌ها در clusterهایی با بیش از چند سرویس سریع جمع می‌شوند.

etcd کل cluster است، آن را به این صورت رفتار کنید

هر چیزی که Kubernetes می‌داند در etcd زندگی می‌کند. آن را از دست دهید و cluster state خود را از دست می‌دهید، نه فقط برخی metadata. etcdctl snapshot save /backup/etcd-snapshot.db را به صورت scheduled اجرا کنید، و واقعاً restoration آن را روی یک scratch cluster حداقل یک بار test کنید. من تیم‌هایی را دیده‌ام که backup شبانه داشتند اما معلوم شد برای سه ماه corrupt هستند چون هیچکس آن‌ها را verify نکرده بود. اگر روی یک managed control plane هستید (EKS, GKE, AKS)، etcd را مستقیماً مدیریت نمی‌کنید، اما باید داستان backup و restore پروایدر خود را پیش از اینکه به آن نیاز دارید بشناسید، نه حین یک incident.

Liveness و readiness probes گاهی باید با یکدیگر مخالفت کنند

یک اشتباه معمول استفاده از همان endpoint برای هر دو liveness و readiness probes است. Liveness باید پاسخ دهد