همانطور که Kubernetes همچنان به انقلابی در نحوه مدیریت و استقرار برنامه ها ادامه می دهد، درک پیچیدگی های آن برای توسعه دهندگان و تیم های عملیاتی به طور یکسان ضروری می شود. اگر یک تیم اختصاصی DevOps ندارید، احتمالاً نباید با Kubernetes کار کنید. با وجود این، در برخی موارد ممکن است مهندس DevOps در دسترس نباشد در حالی که ما در حال رفع اشکال هستیم. برای این موقعیت ها و برای آشنایی کلی، ما هنوز باید خود را با مسائل رایج Kubernetes آشنا کنیم تا شکاف بین توسعه و عملیات را پر کنیم. فکر می‌کنم این مهارت مهمی را نیز فراهم می‌کند که به ما کمک می‌کند کار DevOps را بهتر درک کنیم، با این درک میتوانیم به عنوان یک تیم منسجم پیشرفت کنیم. این راهنما خطاهای رایج Kubernetes را بررسی می‌کند و نکات عیب‌یابی را برای کمک به توسعه‌دهندگان در جهت حرکت در چشم‌انداز پیچیده هماهنگ‌سازی کانتینر ارائه می‌دهد.
https://www.youtube.com/watch?v=Q3cy8i4tsyQ
به عنوان یک یادداشت جانبی، اگر محتوای این پست و سایر پست‌های این مجموعه را دوست دارید، کتاب Debugging من را که پوشش می‌دهد، ببینید. تیموضوع او اگر دوستانی دارید که در حال یادگیری کدنویسی هستند، ممنون می شوم به کتاب مبانی جاوا من مراجعه کنید. اگر می خواهید پس از مدتی به جاوا بازگردید، کتاب جاوا 8 تا 21 من را بررسی کنید.
شناسایی مشکلات پیکربندی
هنگامی که با مشکلات پیکربندی در Kubernetes مواجه می شوید، اولین جایی که باید بررسی کنید ستون وضعیت با استفاده از kubectl get pods فرمان خطاهای رایج در اینجا ظاهر می شوند و نیاز به بازرسی بیشتر دارند kubectl describe pod.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-first-pod-id-xxxx 1/1 Running 0 13s
my-second-pod-id-xxxx 1/1 Running 0 13s
علل و راه حل های رایج
منابع ناکافی: توجه داشته باشید که این به معنای منابع برای خود POD است و نه منابع داخل کانتینر. این بدان معنی است که سخت افزار یا VM اطراف به یک حد رسیده است.
علامت: پادها به دلیل محدودیت منابع برنامه ریزی نمی شوند.
راه حل: با افزودن گره های بیشتر برای تطبیق با منابع مورد نیاز، خوشه را بزرگ کنید.
خرابی در نصب ولوم:
علامت: پادها نمی توانند حجم ها را به درستی نصب کنند.
راه حل: مطمئن شوید که ذخیره سازی به طور دقیق در مشخصات غلاف تعریف شده است و کلاس ذخیره سازی و پیکربندی های حجم پایدار (PV) را بررسی کنید.
مراحل بررسی دقیق
ما میتوانیم استفاده کنیم kubectl describe pod: این دستور شرح مفصلی از pod شامل رویدادهایی که رخ داده است را ارائه می دهد. با بررسی این رویدادها می‌توان به علت دقیق این موضوع پی برد.
مرحله مهم دیگر تجزیه و تحلیل سهمیه منابع است. گاهی اوقات، محدودیت منابع به دلیل سهمیه منابع در سطح فضای نام است. استفاده کنید kubectl get resourcequotas برای بررسی اینکه آیا سهمیه ها ایجاد غلاف را محدود می کنند یا خیر.
مقابله با خطاهای کشش تصویر
خطاهایی مانند ErrImagePull یا ImagePullBackOff مشکلات مربوط به واکشی تصاویر ظرف را نشان دهد. این خطاها معمولاً مربوط به در دسترس بودن تصویر یا مجوزهای دسترسی است.
مراحل عیب یابی
اولین مرحله بررسی نام تصویر است که می توانیم با دستور زیر انجام دهیم:
docker pull
سپس باید نام تصویر را برای اشتباهات تایپی یا نویسه‌های نامعتبر تأیید کنیم. من دستور را از طریق grep وارد می کنم تا مطمئن شوم که نام 100٪ یکسان است، برخی از اشتباهات تایپی بسیار دشوار است.
اعتبارنامه نیز می تواند یک دام بزرگ باشد. به عنوان مثال نقص مجوز هنگام کشیدن تصاویر از مخازن خصوصی.
ما باید اطمینان حاصل کنیم که اعتبار رجیستری Docker به درستی در Secrets Kubernetes پیکربندی شده است.
پیکربندی شبکه نیز باید بررسی شود. اطمینان حاصل کنید که گره های Kubernetes به رجیستری Docker دسترسی شبکه دارند. خط‌مشی‌های شبکه یا قوانین فایروال ممکن است دسترسی را مسدود کنند.
چندین مشکل اضافی مانند مشکلات برچسب های تصویر وجود دارد. مطمئن شوید که از تگ های تصویر درست استفاده می کنید. آخرین برچسب ها ممکن است همیشه به نسخه تصویر مورد انتظار اشاره نکنند.
اگر از یک رجیستری خصوصی استفاده می کنید، ممکن است با مشکلات دسترسی مواجه شوید. اطمینان حاصل کنید که اعتبار شما به روز است و رجیستری از همه گره ها در همه مناطق قابل دسترسی است.
رسیدگی به مسائل گره
خطاهای مربوط به گره اغلب به مشکلات فیزیکی یا ماشین مجازی اشاره دارد. این مسائل می تواند عملکرد عادی خوشه Kubernetes را مختل کند و نیاز به توجه فوری دارد.
برای بررسی وضعیت گره از دستور زیر استفاده کنید:
kubectl get nodes
سپس میتوانیم گره‌های مشکل‌ساز در خروجی حاصل را شناسایی کنیم.
این یک کلیشه است اما گاهی اوقات راه اندازی مجدد گره ها بهترین راه حل برای برخی مشکلات است. ما می توانیم ماشین یا ماشین مجازی آسیب دیده را راه اندازی مجدد کنیم. Kubernetes باید تلاش کند تا “خودشفا” و در عرض چند دقیقه بهبود یابد.
برای بررسی شرایط گره می توانیم از دستور استفاده کنیم:
kubectl describe node
باید به دنبال شرایطی مانند MemoryPressure، DiskPressure، یا NetworkUnavailable. این شرایط سرنخ هایی را در مورد موضوع اساسی که باید در گره به آن بپردازیم ارائه می دهد.
اقدامات پیشگیرانه
نظارت بر گره باید با ابزارهایی مانند Prometheus، Grafana برای مراقبت از سلامت و عملکرد گره مورد استفاده قرار گیرد. اینها برای مسائل مربوط به Kubernetes سطح پایین عالی کار می کنند، ما همچنین می توانیم از آنها برای مسائل برنامه های سطح بالا استفاده کنیم.
برخی از ابزارهای درمانی خودکار مانند Kubernetes Cluster Autoscaler وجود دارد که میتوانیم از آنها برای مدیریت خودکار تعداد گره‌ها در خوشه شما بر اساس نیازهای حجم کار استفاده کنیم. من شخصاً طرفدار زیادی نیستم زیرا از شکست آبشاری که باعث مصرف منابع اضافی شود می ترسم.
مدیریت کلیدها یا اسرار پیکربندی گمشده
از دست دادن کلیدهای پیکربندی یا اسرار مسائل رایجی است که استقرار Kubernetes را مختل می کند. مدیریت صحیح این عناصر برای عملکرد روان بسیار مهم است.
ما باید از ConfigMaps و Secrets استفاده کنیم. اینها به ما اجازه می دهند مقادیر پیکربندی و اطلاعات حساس را به صورت ایمن ذخیره کنیم. برای جلوگیری از آن، باید اطمینان حاصل کنیم که ConfigMaps و Secrets به درستی در مشخصات غلاف شما ارجاع شده اند.
توضیحات غلاف را با استفاده از دستور بررسی کنید:
kubectl describe pod
خروجی را مرور کنید و به دنبال جزئیات پیکربندی گم شده باشید. هرگونه پیکربندی نادرست را اصلاح کنید.
ConfigMap و ایجاد مخفی را می توان با استفاده از دستور تأیید کرد:
kubectl get configmaps
و:
kubectl get secrets
اطمینان حاصل کنید که ConfigMaps و Secrets مورد نیاز در فضای نام وجود دارد و حاوی داده های مورد انتظار است.
بهتر است بخش‌های غیر حساس ConfigMaps را در کنترل نسخه نگه دارید و در عین حال Secrets برای امنیت را حذف کنید. علاوه بر این، شما باید از ConfigMaps و Secrets مختلف برای محیط های مختلف (توسعه، مرحله بندی، تولید) استفاده کنید تا از نشت پیکربندی جلوگیری کنید.
استفاده از Buildg برای اشکال زدایی تعاملی
Buildg یک ابزار نسبتاً جدید است که فرآیند اشکال‌زدایی پیکربندی‌های Docker را با امکان اشکال‌زدایی تعاملی بهبود می‌بخشد.
اشکال زدایی تعاملی را برای مسائل پیکربندی به روشی شبیه به اشکال زدایی استاندارد ارائه می دهد. این به ما اجازه می دهد تا از طریق آن گام برداریم Dockerfile مراحل و تعیین نقاط شکست. Buildg با VSCode و سایر IDE ها از طریق پروتکل Debug Adapter Protocol (DAP) سازگار است.
Buildg به ما امکان می‌دهد وضعیت کانتینر را در هر مرحله از فرآیند ساخت بررسی کنیم تا مشکلات را زودتر شناسایی کنیم.
برای نصب buildg دستورالعمل های صفحه Buildg GitHub را دنبال کنید.
نتیجه
اشکال زدایی Kubernetes می تواند چالش برانگیز باشد، اما با دانش و ابزار مناسب، توسعه دهندگان می توانند به طور موثر مشکلات رایج را شناسایی و حل کنند. با درک مشکلات پیکربندی، خطاهای کشش تصویر، مشکلات گره ها و اهمیت ConfigMaps و Secrets، توسعه دهندگان می توانند به استقرارهای قوی تر و قابل اعتماد Kubernetes کمک کنند. ابزارهایی مانند Buildg پیشرفت‌های امیدوارکننده‌ای را در اشکال‌زدایی تعاملی ارائه می‌کنند و شکاف بین توسعه و عملیات را بیشتر می‌کنند.
همانطور که Kubernetes به تکامل خود ادامه می دهد، آگاه بودن در مورد ابزارهای جدید و بهترین شیوه ها برای مدیریت و استقرار موفق برنامه ضروری است. با پرداختن پیشگیرانه به این مسائل رایج، توسعه دهندگان می توانند از عملکرد نرم تر و کارآمدتر Kubernetes اطمینان حاصل کنند که در نهایت منجر به برنامه های کاربردی انعطاف پذیرتر و مقیاس پذیرتر می شود.
