اجزای اصلی معماری Kubernetes چیست و هر کدام مسئول چه هستند؟

یک خوشه Kubernetes از یک صفحه کنترل به اضافه مجموعه ای از ماشین های کارگر به نام گره تشکیل شده است که برنامه های کانتینری را در Pods اجرا می کنند. هر خوشه حداقل به یک گره کارگر برای اجرای Pods نیاز دارد.

از لحاظ مفهومی، Kubernetes اعلامی است: شما حالت مورد نظر را به سرور API ارسال می کنید (ذخیره شده در etcd)، و کنترل کننده ها حلقه های آشتی پیوسته ای را اجرا می کنند که تفاوت ها را مشاهده می کنند و برای هدایت وضعیت واقعی به سمت حالت مطلوب عمل می کنند.

اجزای هواپیما را کنترل کنید

صفحه کنترل تصمیمات کلی در مورد خوشه می گیرد (مانند زمان بندی) و به رویدادهای خوشه پاسخ می دهد. در تولید معمولاً در چندین ماشین برای در دسترس بودن بالا اجرا می شود.

• kube-apiserver - مؤلفه اصلی که API HTTP Kubernetes را آشکار می کند. این انتهای جلویی صفحه کنترل و تنها نقطه تماس است: تمام احراز هویت، مجوز، اعتبارسنجی درخواست، و خواندن/نوشتن جریان حالت خوشه از طریق آن انجام می شود. به صورت افقی مقیاس می شود. در استقرارهای معمولی، تنها مؤلفه Kubernetes است که حالت خوشه را مستقیماً در etcd می خواند و می نویسد. همه اجزای دیگر از طریق سرور API با حالت تعامل دارند.
• etcd - یک فروشگاه ارزش کلیدی سازگار و بسیار در دسترس که به عنوان ذخیره پشتیبان Kubernetes برای همه داده های خوشه ای استفاده می شود: پیکربندی، وضعیت و ابرداده. etcd اجباری است و تنها منبع حقیقت است - از دست دادن آن به معنای از دست دادن تمام حالت خوشه است، بنابراین باید با حد نصاب اجرا شود (تعداد فرد اعضا) و به طور منظم پشتیبان گیری شود.
• kube-scheduler - پادهایی را که هنوز به یک گره متصل نشده اند را تماشا می کند و هر Pod را با در نظر گرفتن منابع، محدودیت ها و سیاست ها به یک گره مناسب اختصاص می دهد.
• kube-controller-manager - کنترل‌کننده‌هایی را اجرا می‌کند که رفتار API Kubernetes را پیاده‌سازی می‌کنند (به عنوان مثال، Node controller، Job controller، EndpointSlice controller). هر کنترل کننده وضعیت مورد نظر را تماشا می کند و وضعیت واقعی را با آن تطبیق می دهد.
• cloud-controller-manager (اختیاری) - با ارائه دهنده ابر زیربنایی ادغام می شود و منطق خاص ابر را از اجزای اصلی Kubernetes جدا می کند.

اجزای گره

اینها روی هر گره اجرا می شوند، Pods را در حال اجرا نگه می دارند و محیط زمان اجرا را فراهم می کنند.

• kubelet - عاملی که از کارکرد Pods، از جمله ظروف آنها اطمینان می دهد. سرور API را برای تکالیف Pod تماشا می‌کند، کانتینرها را از طریق زمان اجرا راه‌اندازی می‌کند، حجم‌ها را نصب می‌کند، کاوشگرهای زنده‌گی/آمادگی را اجرا می‌کند و وضعیت گره را گزارش می‌دهد.
• kube-proxy - شبکه‌سازی سرویس را با برنامه‌نویسی iptables یا قوانین IPVS روی گره‌ها پیاده‌سازی می‌کند تا ترافیک به یک سرویس به IPهای Pod صحیح ارسال شود. این گزینه اختیاری است زیرا برخی از پلاگین های CNI (به عنوان مثال، Cilium در حالت eBPF) وظیفه آن را بر عهده می گیرند، اما در یک کلاستر استاندارد لازم است.
• Container Runtime - نرم افزاری که مسئول اجرای کانتینرها (کانتینر، CRI-O و غیره از طریق رابط CRI) است.

افزونه ها

افزونه ها عملکرد خوشه را گسترش می دهند: DNS خوشه (به طور پیش فرض CoreDNS)، رابط کاربری وب داشبورد، نظارت بر منابع کانتینر، و ثبت گزارش در سطح خوشه.

پیگیری مشترک: تمام ارتباطات از طریق سرور API جریان می‌یابد - زمان‌بندی، کنترل‌کننده‌ها و کوبلت‌ها به سادگی آن را تماشا می‌کنند و واکنش نشان می‌دهند - که سرور API را به مرکز مهم خوشه تبدیل می‌کند.