چه زمانی معماری پلتفرم نیاز به توجه دارد
- کلاسترهای راه‌اندازی‌شده بدون استاندارد پلتفرم
- مالکیت نامشخص بین تیم کاربرد و پلتفرم
- شکاف امنیت در RBAC، سیاست شبکه و زنجیره تأمین
- ارتقاهای دردناک و drift پیکربندی
- مشاهده‌پذیری که پاسخ به حادثه را پشتیبانی نکند
چگونه روی این پلتفرم کار می‌کنیم
- معماری هدف AKS و EKS و GKE
- مهندسی پلتفرم و طراحی پلتفرم توسعه‌دهنده داخلی
- GitOps و CI/CD برای تحویل کلاستر و کاربرد
- تصمیم‌گیری سیاست شبکه، ingress و service mesh
- مشاهده‌پذیری با پشته‌های سازگار Prometheus/Grafana
- مهاجرت از VM یا PaaS به کانتینر
معماری در بستر تصمیم
معماری مفهومی برای مرزهای تصمیم؛ محیط مشتری را نشان نمی‌دهد.
سرویس مدیریت‌شده را از دارایی انتخاب کنید
AKS و EKS و GKE واسط Kubernetes مشترک دارند اما در ادغام هویت، پیش‌فرض شبکه، افزونه‌ها و تجربه ارتقا متفاوتند. بر اساس دارایی اصلی ابر، مدل هویت، مهارت تیم و سرویس‌های مجاور انتخاب کنید—نه چک‌لیست ویژگی مجزا.
کیفیت مهندسی پلتفرم معمولاً مهم‌تر از تفاوت‌های جزئی سرویس مدیریت‌شده است. صفحه عملیات پلتفرم نحوه ماندن پس از طراحی کلاستر است.
آنچه فرض نمی‌کنیم
Kubernetes برای هر برنامه نوسازی لازم نیست. برخی بارکاری‌ها روی PaaS، serverless یا VM خوب مدیریت‌شده بهترند. معماری باید از بارکاری پیروی کند.
میز خدمت روزمره و فناوری اطلاعات محیط کار عملیات پلتفرم Kubernetes نیست. آن‌ها با Podium Catchers است.
تصمیم‌های فناوری در بستر
- Kubernetes
- AKS
- EKS
- GKE
- Helm
- GitOps
- Terraform
- Istio / service mesh patterns
آنچه این کار قرار است ممکن کند
- مدل عملیاتی کلاستر و پلتفرم قابل پشتیبانی
- مرزهای روشن‌تر خودخدمتی توسعه‌دهنده
- کاهش drift پیکربندی از طریق GitOps
- بهبود آمادگی امنیت و ارتقا
انتخاب پلتفرم انتخاب عملیاتی است
پیش از پیاده‌سازی معیار پذیرش بارکاری، مالکیت دسترسی، شیوه تغییر و مسئولیت‌های بازیابی را توافق می‌کنیم. سرویس‌های ارائه‌دهنده جای آزمون کاربرد، پاسخگویی هزینه و تیم بهره‌برداری را نمی‌گیرد.
پرسش‌ها و پاسخ‌ها
تفاوت AKS و EKS و GKE چیست؟
AKS و EKS و GKE سرویس‌های Kubernetes مدیریت‌شده در Azure و AWS و Google Cloud هستند. مفاهیم Kubernetes مشترک دارند اما در ادغام هویت، پیش‌فرض شبکه، افزونه‌ها، ابزار ارتقا و سرویس‌های اطراف متفاوتند.
#آیا برای هر برنامه نوسازی به Kubernetes نیاز داریم؟
خیر. Kubernetes وقتی ارزش دارد که orchestration کانتینر قابل انتقال و اهرم پلتفرم لازم باشد. برخی بارکاری‌ها روی PaaS، serverless یا VM خوب مدیریت‌شده بهترند. معماری باید از ویژگی بارکاری پیروی کند، نه مد روز.
#چه کسی پس از راه‌اندازی کلاستر را اداره می‌کند؟
می‌توانیم پلتفرمی که طراحی می‌کنیم بهره‌برداری کنیم. آن عملیات landing zone و کلاستر است، نه managed IT.
#تصمیم‌های service mesh کجا باید باشد؟
در همین صفحه به‌عنوان انتخاب معماری، و در مقاله منتشرشده درگاه در برابر service mesh. mesh جایگزین landing zone نیست.
#