پس از کانتینریزاسیون موفقیت آمیز و تنظیم CI/CD برای برنامه نمایش تلویزیونی من (همانطور که در پست قبلی من به تفصیل شرح داده شده است ، “از CosmosDB تا DynamoDB: مهاجرت و کانتینر کردن یک برنامه FastAPI + React”) ، گام منطقی بعدی در ماجراجویی “یادگیری ابر” من برای پذیرش یک بستر ارکستراسیون قوی تر و مقیاس پذیر تر: آمازون edastic kubernetes (eks) بود. برای مدیریت این لایه جدید زیرساخت ها به عنوان کد (IAC) ، به Terraform روی آوردم. این پست تجربه را شرح می دهد ، موانع هنگام تنظیم EKS با Terraform و راه حل هایی که راه را هموار کرده است.
چرا eks؟ فشار برای ارکستراسیون
در حالی که در حال اجرا ظروف Docker در یک نمونه EC2 واحد با آهنگسازی Docker برای مرحله اولیه کار می کرد ، هدف همیشه کشف شیوه های واقعی ابر است. Kubernetes (و EKS به عنوان ارائه AWS مدیریت شده خود) قول داده است:
- مقیاس پذیری: بر اساس تقاضا ، به راحتی غلاف برنامه های من را به بالا یا پایین می رساند.
- انعطاف پذیری: بازیابی خودکار غلاف ها و تحمل بهتر گسل.
- کشف خدمات و تعادل بار: مکانیسم های یکپارچه برای ارتباطات بین خدمات و افشای برنامه ها.
- پیکربندی اعلامی: تعریف وضعیت کاربرد مورد نظر من با تجلی Kubernetes.
Terraform: ابزار کار
با کلیک دستی از طریق کنسول AWS برای تنظیم یک خوشه EKS ، VPC ، گروه های گره و کلیه نقش ها و گروه های امنیتی مرتبط با آن پیچیده و مستعد خطا است. Terraform با رویکرد اعلامیه IAC ، انتخاب روشنی برای خودکارسازی این تأمین ، اطمینان از تکرارپذیری و کنترل نسخه برای زیرساخت های من بود. من تصمیم گرفتم از مقام رسمی استفاده کنم terraform-aws-modules/eks/aws ماژول ، که به طور قابل توجهی تنظیم EKS را ساده می کند.
چالش 1: تسلط بر حالت پس زمینه از راه دور Terraform
قبل از شروع کار EKS ، بهترین روش ها دیکته می کند که یک پس زمینه از راه دور برای ایالت Terraform تنظیم می کند. این برای همکاری و جلوگیری از از دست دادن دولت بسیار مهم است. من برای قفل کردن S3 را با DynamoDB انتخاب کردم.
- Stumble: من به یک مسئله واقعاً عجیب رسیدم. اشتباه اولیه من شامل تعاریف منابع برای سطل S3 و جدول DynamoDB در همان پیکربندی Terraform بود که همچنین خوشه EKS را تعریف می کرد و از آن سطل S3 به عنوان پس زمینه خود استفاده می کرد.
- علائم: وقتی دویدم
terraform applyبرای خوشه EKS من ، به نظر می رسید که میز خیلی سطل S3 و میز دینامودب را که حالت Terraform من را نگه داشته است ، از بین می برد! Terraform شروع به ایجاد منابع EKS می کند ، سپس سعی می کند سطل S3 را که به طور فعال از آن استفاده می کرد ، “مدیریت” (و از بین ببرد). این امر باعث شد که این درخواست از میانی در میانی استفاده کند ، زیرا Terraform نمی تواند وضعیت خود را در سطل ای که به تازگی حذف کرده بود نجات دهد ، یا قفل را از یک جدول DynamoDB که دیگر وجود ندارد ، رها کند. خطاها واضح بود:NoSuchBucketوتResourceNotFoundExceptionبرای جدول قفل همانطور که می توانید تصور کنید ، این باعث ایجاد آشفتگی ، از دست دادن وضعیت Terraform من و منجر به مشکلات مربوط به قفل های Terraform شد.
راه حل (قسمت اولیه): کلید جدایی دقیق بود.
- یک پیکربندی کاملاً جداگانه ایجاد کنید (به عنوان مثال ، در a از راه دور Subdirectory) که تنها هدف آنها تعریف و ایجاد سطل S3 (با نسخه و رمزگذاری) و جدول DynamoDB برای قفل حالت است. این پیکربندی از باکد محلی پیش فرض استفاده می کند.
- Terraform را اجرا کنید ، یک بار برای تهیه این منابع ، فقط در این پیکربندی فقط با زمینه استفاده کنید.
- سپس ، در پیکربندی اصلی EKS Terraform ، من فقط موارد را درج کردم
backend "s3" {}در بلوک کردنproviders.tf، با اشاره به سطل و میز از قبل موجود. پیکربندی EKS به خودی خود حاوی هیچ استresourceبلوک برای اجزای باطن.
یک شبح طولانی (راه حل کامل): حتی بعد از جدا کردن کد ، وقتی دویدم terraform plan از eks-cluster دایرکتوری ، من متوجه شدم که هنوز هم قصد دارد 4 منبع را از بین ببرد ، که می دانستم منابع دولتی من هستند! مسئله این بود که یک درخواست قبلی (ناموفق) آن منابع باطن را در پرونده حالت پیکربندی EKS ثبت کرده است. وقتی دویدم terraform state list، 4 منبع در معرض نمایش در واقع منابع دولت بودند. Terraform کد فعلی من (بدون منابع با پس زمینه تعریف شده) را با پرونده دولت (منابع با پس زمینه ثبت نشده است) مقایسه کرد و نتیجه گرفت که از آنجا که کد دیگر آنها را تعریف نکرده است ، باید طبق پرونده دولتی که مدیریت می کرد ، نابود شوند. رفع صریحاً با اجرای این منابع از پرونده دولت خوشه EKS حذف شد terraform state rm برای هر یک از چهار منبع باطن. بعد از انجام این کار ، terraform plan به درستی 0 را برای نابودی نشان داد ، تصدیق کرد که آنها در جای دیگر اداره می شوند.
چالش 2: پیکربندی VPC – برای ایجاد یا استفاده؟
ماژول EKS می تواند یک VPC جدید ایجاد کند یا از یک موجود موجود استفاده کند.
-
رویکرد اولیه: من به ماژول اجازه می دهم یک VPC جدید ایجاد کند. این رویکرد اغلب تمیزتر است و تضمین می کند که تمام الزامات برچسب زدن EKS به طور خودکار برآورده می شوند.
-
دیوار “vpclimitexted”: در طی یک
terraform apply، من باVpcLimitExceededخطا حساب AWS من به حد پیش فرض 5 VPC در هر منطقه رسیده بود. این امر به این دلیل بود که Terraform برخی از منابع ، از جمله VPC را در طول شکست من ایجاد کردterraform applyبشر
راه حل ها و ملاحظات:
VPC های بلااستفاده را حذف کنید: سریعترین راه حل ورود به کنسول AWS و حذف VPC های قدیمی و بلااستفاده بود.
چالش 3: “منبع در حال حاضر وجود دارد” – تمیز کردن پس از اجرای ناموفق
ایجاد خوشه EKS یک فرآیند طولانی است. اگر درخواست کردن در اواسط راه نمی افتد ، برخی از منابع ممکن است ایجاد شوند در حالی که دیگران نیستند ، و ممکن است Terraform در صورت خراب شدن قبل از صرفه جویی ، ایجاد خود را در پرونده ایالتی ثبت نکرده باشد ، دقیقاً مانند آنچه با VPC ها اتفاق افتاد.
-
مشکل: متعاقب
terraform applyتلاش ، من مانند خطاهایی مانندAlreadyExistsExceptionبرای یک kms alias (alias/eks/ltc-eks-cluster) و یک گروه ورود به سیستم CloudWatch (/aws/eks/ltc-eks-cluster/cluster). Terraform در تلاش بود تا این موارد را ایجاد کند ، اما آنها قبلاً از یک اجرای جزئی قبلی وجود داشته اند.
راه حل:
حذف دستی (با احتیاط استفاده کنید): برای نام مستعار KMS ، از آنجا که من مطمئن بودم که این یک بقایای و استفاده نشده است ، من قبل از اجرای مجدد آن را از طریق کنسول AWS حذف کردم apply گزینه ای بود که من گرفتم اگر از منشأ منبع مطمئن نیستید ، این خطرناک تر است.
در حالت ایده آل ، ماژول های Terraform بی پروا هستند ، اما گاهی اوقات با خلاقیت های پیچیده و چند مرحله ای مانند EKS ، خرابی های جزئی می توانند چیزهایی را در وضعیتی قرار دهند که نیاز به مداخله دستی دارد.
موفقیت شیرین: یک خوشه در حال اجرا EKS
پس از پیمایش این موانع ، terraform apply سرانجام به پایان رسید ، و outputs.tf دستور پیکربندی را فراهم کرد kubectlبشر دید kubectl get nodes بازگشت گره های کارگر از خوشه جدید EKS من یک لحظه بسیار رضایت بخش بود!
یادگیری های کلیدی از EKS & Terraform:
- حالت پس زمینه مقدس است: با تنظیم آن با دقت رفتار کنید و آن را جدا نگه دارید. درک کنید که چگونه ناسازگاری های دولت می تواند به برنامه های غیر منتظره منجر شود.
- پیش فرض و الزامات ماژول را درک کنید: ماژول EKS قدرتمند است اما انتظارات دارد (مانند برچسب زدن زیر شبکه VPC برای تعادل بار).
- محدودیت خدمات AWS واقعی است: از آنها آگاه باشید ، به خصوص برای منابعی مانند VPC.
- اعمال ناموفق نیاز به پاکسازی/واردات دارد: فقط اجرا را دوباره اجرا نکنید. در مورد خطاهای “در حال حاضر وجود دارد” تحقیق کنید و یا منبع را وارد کنید یا در صورت بقایای یتیم با خیال راحت آن را حذف کنید.
- صبر: تهیه خوشه EKS به زمان نیاز دارد.
می توانید مخزن را در اینجا پیدا کنید.
مراحل بعدی: استقرار برنامه
با خوشه EKS ارائه شده توسط Terraform و خط لوله CI/CD من که تصاویر را به ECR سوق می دهد ، مرحله بعدی نوشتن مانیفست های Kubernetes YAML (استقرار ، خدمات ، پیکربندی ها ، اسرار) برای استقرار من در جلوی واکنش من و Backend Fastapi بر روی خوشه است. این شامل پیکربندی Ingress برای دسترسی خارجی و IRSA برای دسترسی به سرویس ایمن AWS از غلافهای من است. سفر به یک برنامه کاملاً ارکستر ادامه دارد!
