اطمینان از عملکرد صحیح کلاستر کوبرنتیز یکی از موضوعات مهم در نگهداری و مدیریت زیرساخت های کانتینری محسوب می شود. از این رو، جهت اطمینان از پایداری کلاستر کوبرنتیز، از معماری High availability در سطح نودهای مستر یا اصطلاحا Control plane استفاده می کنیم. بنابراین، لازم است یک کلاستر مالتی مستر بر اساس توپولوژی های اشاره شده در سایت کوبرنتیز (مدل Stacked-ETCD یا External ETCD) راه اندازی کنیم که به نحوه نصب و راه اندازی کلاستر پایدار در مقاله دیگری خواهم پرداخت.
در این مقاله، صرفا هدف آشنایی با روش رفع یکی از مشکلاتی است که بصورت اتفاقی با آن برخورد داشتیم و خطا مربوط به زمانی است که دسترسی به کلاستر کوبرنتیز با fail شدن یکی از نودهای مستر صورت می گیرد. بهتر است برای درک بهتر موضوع یکبار سناریو را مرور کنیم. البته اجرای این سناریو توصیه نمی شود و در مقاله دیگری نحوه صحیح راه اندازی یک کلاستر پایدار را آموزش خواهم داد.
سناریو: یک کلاستر مالتی مستر با داشتن سه نود master و دو نود worker از طریق kubeadm راه اندازی کرده ایم. (بدون لود بالانسر)
هنگامی که یکی از نودهای کلاستر (مستر 2 یا 3) را down می کنید، کلاستر با داشتن دو نود مستر دیگر بصورت صحیح و پایدار کار می کند و نود master1 از وضعیت فعلی و داون شدن یکی از مسترنودها بلافاصله آگاه می شود. در این حالت، مشکل خاصی نیست و مدیریت کلاستر برقرار بوده و با استفاده از فرامین kubectl می توان کلاستر و سرویس های اجرایی را مدیریت کرد.
اما مشکل دقیقا زمانی رخ می دهد که نود master1 را down کنید!! بعد از خاموشی مستر1، بلافاصله دسترسی به کلاستر از بین رفته و در عملکرد کلاستر کوبرنتیز اختلال ایجاد می شود و به هیچ عنوان امکان اجرای دستور در نودهای مستر دیگر master 2, 3 وجود ندارد.
با توجه به اینکه سه نود مستر در یک کلاستر با هم sync هستند و چنین مشکلی رخ می دهد، داستان کمی عجیب بنظرمی رسید. بعد از بررسی های مختلف روی کامپوننت های کلاستر، متوجه شدیم مشکل اصلی مربوط به رفتار کامپوننت های کلاستر کوبرنتیز و down شدن نود master1 می باشد. از آنجا که master1 صرفا نقش leader را در این کلاستر بر عهده دارد و پس از down شدن این نود، سایر نودها امکان switch کردن را ندارند. خطای زیر در خروجی ترمینال مشاهده شده که حاکی از قطع شدن ارتباط بین نودهای دیگر با kube-apiserver اصلی که روی مستر نود1 واقع شده، می باشد
The connection to the server 192.168.90.120:6443 was refused – did you specify the right host or port?
Unable to connect to the server: dial tcp 192.168.90.120:6443: connect: no route to host
رفع مشکل: برای رفع خطای مذکور، بایستی بصورت دستی تنظیمات کلاستر را بگونه ای پیکربندی کرد که کامپوننت kube-apiserver در سطح کلاستر برای سایر نودهای مستر قابل رویت و دستیابی باشد تا امکان ارسال درخواست ها و دستورات kubectl به kube-apiserver فراهم گردد.
برای درک این موضوع و اطلاع از وضعیت پیکربندی فعلی کلاسترتان، کافیست روی نودهای مستر قطع ارتباط شده، دستور kubectl config view را اجرا کنید! امیدوارم متوجه شده باشید که علت عدم اجرای دستورات چیست؟!
با کمی دقت در خروجی، متوجه می شوید که تمام نودهای این کلاستر، kube-apieserver را در آدرس تعیین شده در server: https://192.168.90.120:6443 جستجو می کنند که الان این نود داون شده است! پس لازم هست، تنظمیات کلاستر به آدرس جدیدی اشاره کند که باید یکی دیگر از نودهای مستر ( master2 یا master3) باشد.
برای انجام این پیکربندی و رفع مشکل کلاستر کوبرنتیز کافیست آدرس سرور kube-apiserver جدیدمان را بصورت دستی در فایل کانفیگ با دستور زیر تغییر بدهیم. (تمام نودها)
Kubectl config set clusters.kubernetes.server https://<second_master_node>:6443
اکنون کلاستر شما بصورت صحیح پیکربندی شده است و کافی است سایر نودها، با آدرس جدید kube-apiserver ارتباط برقرار نمایند.
پس از انجام پیکربندی فوق، امکان ارسال دستور به kube-apiserver جدید میسر می شود ولی متاسفانه وضعیت همه نودها به حالت Not Ready نمایش داده می شود.
عجیب نیست زیرا دلیل این موضوع به خاطر عدم امکان شناسایی apiserver جدید توسط اجنت Kubelet می باشد و kubelet سیستم ها همچنان به اشتباه با kube-apiserver قدیمی در حال برقراری ارتباط هستند.
برای رفع این مشکل بایستی مطلع باشید که kubelet در حقیقیت یک agent بوده که وظیفه برقراری ارتباط و تعامل با kube-apiserver را بر عهده می گیرد و برای اینکار تنظیمات لازم را از یک فایل پیکربندی در مسیر /etc/kubernetes/kubelet.conf فراخوانی می کند. پس براحتی می توانید فایل پیکربندی آنرا بصورت دستی ویرایش کنید و kube-apiserver جدیدتان را در این فایل معرفی کنید.
پس از انجام تغییرات، یکبار آقای kubelet را با دستور systemctl restart kubelet راه اندازی مجدد کنید تا از تغییرات صورت گرفته در فایل پیکربندی خودش آگاه شود.
حال می بینید مشکل حل شده و دستورات شما قابل اجرا هستند و دسترسی به کلاستر کوبرنتیز برقرار گردید.
