Post🧩 Kubernetes Design Patterns

🧩 Kubernetes Design Patterns که باید بشناسید وقتی با Kubernetes کار می‌کنیم، فقط Deployment و Service مهم نیستند. Kubernetes یک‌سری Pattern دارد که برای حل مسائل رایج در معماری و اجرای Applicationها استفاده می‌شوند. در این پست چند Pattern مهم را با مثال مرور می‌کنیم 👇 1️⃣ Sidecar Pattern در این الگو یک Container جانبی کنار Container اصلی و در همان Pod اجرا می‌شود. Pod ┌──────────────────────────┐ │ │ │ Application │ │ │ │ │ ▼ │ │ Sidecar │ │ │ └──────────────────────────┘ مثال Application لاگ تولید می‌کند و Sidecar مسئول ارسال آن به Loki است: App │ │ logs ▼ Shared Volume │ ▼ Fluent Bit │ ▼ Loki کاربردها: Log Collection Proxy Service Mesh Monitoring Security Agent 📌 نکته: Sidecar یک Deployment Pattern است؛ یعنی می‌گوید Container جانبی کجا قرار گرفته است. 2️⃣ Adapter Pattern Adapter برای تبدیل Interface یا Format استفاده می‌شود. فرض کنید Application متریک‌ها را با فرمت اختصاصی خودش تولید می‌کند: requests=100 errors=5 ولی Monitoring شما Prometheus Format می‌خواهد. Application │ ▼ Adapter │ ▼ Prometheus Format │ ▼ Prometheus Application را تغییر نمی‌دهیم؛ Adapter خروجی آن را به چیزی که سیستم مقصد انتظار دارد تبدیل می‌کند. کاربردها: تبدیل Metrics تبدیل Logs تبدیل Protocol تبدیل API Format 📌 Adapter می‌تواند خودش به‌صورت یک Sidecar Container پیاده‌سازی شود. 3️⃣ Ambassador Pattern Ambassador به نمایندگی از Application با یک سرویس خارجی ارتباط برقرار می‌کند. مثلاً Application باید به Redis خارج از Kubernetes وصل شود: Pod ┌──────────────────────────┐ │ │ │ Application │ │ │ │ │ ▼ │ │ Ambassador │ │ │ └──────┼───────────────────┘ │ ▼ External Redis Application فقط می‌داند: localhost:6379 ولی Ambassador می‌داند Redis واقعی کجاست: 10.10.20.30:6379 Ambassador می‌تواند مسئول مواردی مثل: TLS Authentication Retry Connection Pooling Routing باشد. 📌 تفاوت با Adapter: Adapter → تبدیل Interface Ambassador → ارتباط با سرویس خارجی 4️⃣ Init Container Pattern گاهی قبل از اجرای Application باید کاری انجام شود. در اینجا از Init Container استفاده می‌کنیم: Init Container ↓ Main Container مثلاً: Migration ↓ Django یا: Download Config ↓ Application Init Container باید با موفقیت تمام شود تا Container اصلی اجرا شود. 5️⃣ Leader Election Pattern گاهی چند Replica داریم ولی فقط یکی باید Leader باشد. مثلاً: Pod-1 Pod-2 Pod-3 ولی فقط: Pod-2 = Leader کار اصلی را انجام می‌دهد. Leader Election │ ┌──────┼──────┐ ▼ ▼ ▼ Pod-1 Pod-2 Pod-3 ★ Leader اگر Pod-2 از بین برود: Pod-1 Pod-3 یکی از آن‌ها Leader می‌شود. کاربرد: Celery Beat Scheduler Controllerها Workerهای Singleton Jobs حساس به Duplicate Execution 6️⃣ Singleton Pattern گاهی از یک Application فقط باید یک Instance فعال داشته باشیم. مثلاً: Celery Beat نمی‌خواهیم: Beat-1 Beat-2 Beat-3 همزمان Taskها را Schedule کنند. می‌توانیم: Replica = 1 قرار دهیم. اما ⚠️ این به‌تنهایی HA واقعی نیست. اگر Pod بمیرد، Kubernetes آن را دوباره می‌سازد؛ ولی برای جلوگیری از اجرای همزمان چند Instance، در سیستم‌های حساس معمولاً Leader Election یا Distributed Lock راه مطمئن‌تری است. 7️⃣ Stateful Pattern برای Applicationهایی که Identity پایدار یا Storage مخصوص هر Instance دارند، از StatefulSet استفاده می‌کنیم. مثلاً: postgres-0 postgres-1 postgres-2 برخلاف Deployment، این Podها Identity پایدار دارند. همراه با: Headless Service می‌توانیم DNS پایدار داشته باشیم: postgres-0.postgres postgres-1.postgres postgres-2.postgres کاربرد: PostgreSQL Kafka ZooKeeper Elasticsearch بعضی سیستم‌های Distributed ⚠️ StatefulSet به‌تنهایی به معنی Database HA نیست. 8️⃣ Service Discovery Pattern #k8s @code_crafters