‏EKS حالا اجازه می‌ده ترافیک خروجی کنترل‌پلین از VPC خودت رد بشه

آمازون قابلیت جدیدی به اسم customer-routed control plane egress رو برای EKS اعلام کرده: می‌تونی ترافیک خروجی کنترل‌پلین کوبرنتیز رو از VPC خودت عبور بدی. این شامل تماس‌های برگشتی وبهوک‌های admission، واکشی سند discovery مربوط به OIDC و درخواست‌های پراکسی‌شده به aggregate API serverهاست.

پیش از این، ترافیک API Server از دل کنترل‌پلین مدیریت‌شدهٔ EKS بیرون می‌رفت. مشتری‌های صنایع تحت‌ نظارت خواسته بودن بتونن کنترل‌های خروجیِ VPC خودشون رو روی همین مسیر هم اعمال کنن تا همون سیاست‌هایی که بر ورک‌لودها حکومت می‌کنه، بر ترافیکی که خود API Server آغاز می‌کنه هم حاکم باشه.

مکانیزم کار اینه که EKS هنگام فعال بودن این قابلیت، API Server رو روی هر اینستنس کنترل‌پلین ایزوله می‌کنه و خروجیِ تحت‌کنترل مشتری رو به یه ENI تو سابنت‌های تو گره می‌زنه. از اون‌جا به بعد، ترافیک از روت‌ها، سکیوریتی‌گروپ‌ها و اندپوینت‌هایی که خودت مدیریت می‌کنی می‌گذره. ترافیک مدیریت‌شدهٔ خود EKS همچنان مسیر قبلی رو می‌ره و دست نمی‌خوره.

مهم‌ترین برد عملی، وبهوک‌های خصوصیه. خیلی تیم‌ها می‌خوان سرویس validating/mutating کاملاً داخل شبکه‌شون و پشت یه اندپوینت بدون آدرس عمومی بمونه، ولی رو یه کلاستر مدیریت‌شدهٔ استاندارد این سخت بود چون تماس خروجی API Server اصلاً به آدرس فقط-خصوصی نمی‌رسید. حالا تماس وبهوک از ENI داخل VPC می‌ره بیرون و می‌تونه وبهوکی رو که پشت یه لودبالانسر داخلی و با DNS خصوصی نشسته، پیدا کنه.

سناریوی دوم، ارائه‌دهندهٔ هویت OIDC خصوصیه. کنترل‌پلین باید دو بار به issuer برسه: موقع association برای گرفتن سند discovery و JWKS، و موقع اعتبارسنجی امضای توکن. حالا این دو واکشی هم از ENI مشتری رد می‌شن و issuer داخل VPC قابل استفاده می‌شه. یه نکتهٔ ظریف هم هست: کنترل‌پلین فقط گواهی‌هایی رو قبول می‌کنه که به یه CA عمومی زنجیر بشن و جایی برای CA bundle سفارشی وجود نداره — پس گواهی self-signed یا AWS Private CA کار نمی‌کنه. راه‌حل اینه که گواهی از یه CA عمومی مثل ACM بگیری و حریم خصوصی رو از لودبالانسر داخلی با آدرس خصوصی بگیری.

فعال‌سازی با ست کردن controlPlaneEgressMode روی CUSTOMER_ROUTED تو کانفیگ VPC کلاستر انجام می‌شه، چه موقع ساخت کلاستر و چه روی یه کلاستر موجود:

aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config controlPlaneEgressMode=CUSTOMER_ROUTED

ولی حواست باشه این تنظیم دائمیه: بعد از رفتن روی CUSTOMER_ROUTED دیگه نمی‌تونی به AWS_MANAGED برگردی. از اون به بعد هم رسیدن ترافیک به مقصد، مسئولیت خودته — اگه اندپوینت وبهوک یا OIDC از سابنت‌های کلاستر در دسترس نباشه، اون تماس‌ها شکست می‌خورن. DNS هم به VPC تو منتقل می‌شه، برای همین رول IAM کلاستر باید مجوزهای ec2:DescribeVpcs و ec2:DescribeDhcpOptions رو داشته باشه.

همهٔ ترافیک هم پوشش داده نمی‌شه: قابلیت‌های EKS مثل ArgoCD و ACK و KRO روی زیرساخت جدای مدیریت‌شدهٔ AWS اجرا می‌شن و تماس‌های STS از سمت IAM Authenticator هم همچنان مسیر EKS رو می‌رن. برای رصد مسیر هم می‌شه از VPC Flow Logs روی سابنت‌های کلاستر استفاده کرد. این قابلیت تو همهٔ ریجن‌های پشتیبانی‌شدهٔ EKS در دسترسه و هزینهٔ اضافه‌ای نداره — فقط هزینه‌های معمول NAT و VPC endpoint سر جاشونن.

نکات کلیدی:

• تماس‌های وبهوک، OIDC و aggregate API از ENI داخل VPC خودت خارج می‌شن
• وبهوک و issuer فقط-خصوصی بالاخره برای کلاسترهای مدیریت‌شده کار می‌کنن
• فعال‌سازی با controlPlaneEgressMode=CUSTOMER_ROUTED و غیرقابل بازگشته
• issuer خصوصی حتماً به گواهی از CA عمومی نیاز داره؛ self-signed قبول نیست
• ترافیک EKS Capabilities و STS همچنان از مسیر مدیریت‌شدهٔ AWS می‌ره