محیط عملیاتی
ایجاد یک کلاستر کوبرنتیز با کیفیت عملیاتی
یک کلاستر کوبرنتیز با کیفیت عملیاتی به برنامه‌ریزی و آمادگی نیاز دارد.
اگر کلاستر کوبرنتیز شما قرار است بارهای کاری حیاتی را اجرا کند، باید طوری پیکربندی شود که تاب‌آور باشد.
این صفحه گام‌هایی را توضیح می‌دهد که می‌توانید برای راه‌اندازی یک کلاستر آماده عملیات،
یا برای ارتقای یک کلاستر موجود به استفاده عملیاتی، بردارید.
اگر از قبل با راه‌اندازی عملیاتی آشنا هستید و فقط پیوندها را می‌خواهید، به
گام‌های بعدی بروید.
ملاحظات عملیاتی
معمولاً یک محیط کلاستر کوبرنتیز عملیاتی نسبت به محیط یادگیری شخصی، توسعه یا آزمون، الزامات بیشتری دارد.
یک محیط عملیاتی ممکن است به دسترسی امن برای کاربران متعدد، در دسترس بودن پایدار،
و منابعی برای سازگاری با تقاضاهای متغیر نیاز داشته باشد.
وقتی تصمیم می‌گیرید محیط عملیاتی کوبرنتیز شما کجا قرار بگیرد
(درون‌سازمانی یا در فضای ابری) و چه مقدار از مدیریت را خودتان بر عهده بگیرید
یا به دیگران بسپارید، در نظر بگیرید که الزامات کلاستر کوبرنتیز شما
تحت تأثیر این مسائل چگونه شکل می‌گیرد:
در دسترس بودن: یک محیط یادگیری کوبرنتیز روی یک ماشین
یک نقطه شکست واحد (Single Point of Failure) دارد. ایجاد یک کلاستر با دسترسی بالا یعنی در نظر گرفتن این موارد:
- جدا کردن control plane از گره‌های worker.
- تکثیر اجزای control plane روی چند گره.
- توزیع بار ترافیک به سرور API کلاستر.
- داشتن تعداد کافی گره worker در دسترس، یا گره‌هایی که بتوانند به‌سرعت در دسترس قرار بگیرند، متناسب با تغییر بارهای کاری.
مقیاس: اگر انتظار دارید محیط عملیاتی کوبرنتیز شما حجم پایداری از
تقاضا دریافت کند، ممکن است بتوانید ظرفیت مورد نیاز را تنظیم کنید و کار را تمام‌شده بدانید. با این حال،
اگر انتظار دارید تقاضا در طول زمان رشد کند یا بر اساس چیزهایی مانند
فصل یا رویدادهای خاص به‌شدت تغییر کند، باید برنامه‌ریزی کنید که چگونه مقیاس را افزایش دهید تا فشار بیشتر
درخواست‌ها روی control plane و گره‌های worker کاهش یابد، یا مقیاس را کم کنید تا منابع بلااستفاده کاهش پیدا کند.
امنیت و مدیریت دسترسی: روی کلاستر یادگیری کوبرنتیز خودتان
دسترسی کامل مدیر دارید. اما کلاسترهای مشترک با بارهای کاری مهم، و
بیش از یک یا دو کاربر، به رویکرد دقیق‌تری نیاز دارند درباره اینکه چه کسی و چه چیزی می‌تواند
به منابع کلاستر دسترسی داشته باشد. می‌توانید از کنترل دسترسی مبتنی بر نقش
(RBAC) و سازوکارهای امنیتی دیگر استفاده کنید
تا مطمئن شوید کاربران و بارهای کاری به منابع مورد نیازشان دسترسی دارند،
در حالی که بارهای کاری و خود کلاستر امن می‌مانند.
می‌توانید با مدیریت سیاست‌ها و
منابع کانتینر
برای منابعی که کاربران و بارهای کاری به آن‌ها دسترسی دارند محدودیت تعیین کنید.
پیش از آنکه خودتان یک محیط عملیاتی کوبرنتیز بسازید، در نظر بگیرید
بخشی یا همه این کار را به ارائه‌دهندگان
راهکارهای ابری آماده
یا دیگر شرکای کوبرنتیز بسپارید.
گزینه‌ها عبارت‌اند از:
- بدون سرور (Serverless): فقط بارهای کاری را روی تجهیزات شخص ثالث اجرا کنید، بدون آنکه
اصلاً یک کلاستر را مدیریت کنید. برای چیزهایی مانند مصرف CPU، حافظه و
درخواست‌های دیسک هزینه پرداخت می‌کنید.
- control plane مدیریت‌شده: اجازه دهید ارائه‌دهنده مقیاس و در دسترس بودن
control plane کلاستر را مدیریت کند و وصله‌ها و ارتقاها را هم انجام دهد.
- گره‌های worker مدیریت‌شده: استخرهای گره را مطابق نیاز خود پیکربندی کنید،
سپس ارائه‌دهنده مطمئن می‌شود آن گره‌ها در دسترس‌اند و در صورت نیاز آماده
اعمال ارتقا هستند.
- یکپارچه‌سازی: ارائه‌دهندگانی وجود دارند که کوبرنتیز را با سرویس‌های دیگری که ممکن است نیاز داشته باشید یکپارچه می‌کنند،
مانند ذخیره‌سازی، رجیستری‌های کانتینر، روش‌های احراز هویت
و ابزارهای توسعه.
چه خودتان یک کلاستر عملیاتی کوبرنتیز بسازید و چه با
شرکا کار کنید، بخش‌های زیر را مرور کنید تا نیازهای خود را در ارتباط با
control plane، گره‌های worker، دسترسی کاربر و
منابع بار کاری کلاستر ارزیابی کنید.
راه‌اندازی کلاستر عملیاتی
در یک کلاستر کوبرنتیز با کیفیت عملیاتی، control plane کلاستر را
از طریق سرویس‌هایی مدیریت می‌کند که می‌توانند به شکل‌های مختلف روی چند رایانه پخش شوند.
هر گره worker، با این حال، یک موجودیت واحد است که
برای اجرای پادهای کوبرنتیز پیکربندی شده است.
control plane عملیاتی
ساده‌ترین کلاستر کوبرنتیز تمام سرویس‌های control plane و گره worker را
روی یک ماشین اجرا می‌کند. می‌توانید آن محیط را با افزودن
گره‌های worker گسترش دهید، همان‌طور که در نمودار
اجزای کوبرنتیز نشان داده شده است.
اگر قرار است کلاستر برای مدت کوتاهی در دسترس باشد، یا در صورت بروز مشکل جدی
بتوان آن را کنار گذاشت، این چیدمان ممکن است نیاز شما را برآورده کند.
اما اگر به یک کلاستر پایدارتر و با دسترسی بالا نیاز دارید، باید
راه‌های گسترش control plane را در نظر بگیرید. طبق طراحی، سرویس‌های control plane
که روی یک ماشین اجرا می‌شوند دسترسی بالا ندارند.
اگر روشن و در حال اجرا ماندن کلاستر
و اطمینان از امکان تعمیر آن در صورت بروز مشکل مهم است،
این گام‌ها را در نظر بگیرید:
- انتخاب ابزارهای استقرار: می‌توانید یک control plane را با ابزارهایی مانند
kubeadm، kops و kubespray مستقر کنید. برای نکته‌های استقرار با کیفیت عملیاتی با هر یک از این روش‌ها،
نصب کوبرنتیز با ابزارهای استقرار
را ببینید. مجری‌های کانتینر مختلفی
برای استفاده همراه با استقرار شما در دسترس‌اند.
- مدیریت گواهینامه‌ها: ارتباطات امن بین سرویس‌های control plane
با گواهینامه پیاده‌سازی می‌شود. گواهینامه‌ها هنگام استقرار به‌طور خودکار تولید می‌شوند،
یا می‌توانید آن‌ها را با مرجع صدور گواهی خودتان تولید کنید.
برای جزئیات، گواهینامه‌ها و الزامات PKI را ببینید.
- پیکربندی متعادل‌کننده بار برای apiserver: یک متعادل‌کننده بار پیکربندی کنید
تا درخواست‌های API بیرونی را بین نمونه‌های سرویس apiserver که روی گره‌های مختلف اجرا می‌شوند توزیع کند. برای جزئیات،
ایجاد یک متعادل‌کننده بار بیرونی
را ببینید.
- جداسازی و پشتیبان‌گیری از سرویس etcd: سرویس‌های etcd می‌توانند روی همان ماشین‌هایی که
دیگر سرویس‌های control plane اجرا می‌شوند کار کنند، یا برای امنیت و در دسترس بودن بیشتر روی ماشین‌های جداگانه اجرا شوند.
چون etcd داده‌های پیکربندی کلاستر را ذخیره می‌کند،
پشتیبان‌گیری از پایگاه‌داده etcd باید به‌طور منظم انجام شود تا در صورت نیاز بتوانید
آن پایگاه‌داده را تعمیر کنید.
برای جزئیات پیکربندی و استفاده از etcd، پرسش‌های متداول etcd را ببینید.
برای جزئیات،
مدیریت کلاسترهای etcd برای کوبرنتیز
و راه‌اندازی یک کلاستر etcd با دسترسی بالا با kubeadm
را ببینید.
- ایجاد چند سامانه control plane: برای دسترسی بالا،
control plane نباید به یک ماشین محدود شود. اگر سرویس‌های control plane
توسط یک سرویس init (مانند systemd) اجرا می‌شوند، هر سرویس باید روی
دست‌کم سه ماشین اجرا شود. با این حال، اجرای سرویس‌های control plane به‌صورت پاد در
کوبرنتیز تضمین می‌کند که تعداد رپلیکاهایی که از سرویس‌ها درخواست می‌کنید
همیشه در دسترس باشد.
زمان‌بند باید در برابر خطا مقاوم باشد،
اما لازم نیست دسترسی بالا داشته باشد. برخی ابزارهای استقرار الگوریتم اجماع Raft
را برای انتخاب رهبر سرویس‌های کوبرنتیز تنظیم می‌کنند. اگر
نمونه اصلی از دسترس خارج شود، سرویس دیگری خود را انتخاب می‌کند و کار را بر عهده می‌گیرد.
- گسترش در چند ناحیه: اگر در دسترس ماندن کلاستر در همه زمان‌ها
حیاتی است، ایجاد کلاستری را در نظر بگیرید که در چند مرکز داده اجرا شود؛
در محیط‌های ابری به این مراکز داده ناحیه (zone) گفته می‌شود. گروه‌هایی از ناحیه‌ها منطقه (region) نامیده می‌شوند.
با پخش کردن یک کلاستر در
چند ناحیه همان منطقه، احتمال ادامه کار کلاستر
حتی اگر یک ناحیه از دسترس خارج شود بیشتر می‌شود.
برای جزئیات، اجرا در چندین ناحیه (zones) را ببینید.
- مدیریت قابلیت‌های جاری: اگر قصد دارید کلاستر را در طول زمان نگه دارید،
کارهایی هست که باید برای حفظ سلامت و امنیت آن انجام دهید. برای مثال،
اگر با kubeadm نصب کرده‌اید، دستورالعمل‌هایی برای
مدیریت گواهینامه
و ارتقای کلاسترهای kubeadm وجود دارد.
برای فهرست بلندتری از کارهای مدیریتی کوبرنتیز،
مدیریت یک کلاستر
را ببینید.
برای آشنایی با گزینه‌های موجود هنگام اجرای سرویس‌های control plane، صفحه‌های اجزای
kube-apiserver،
kube-controller-manager
و kube-scheduler
را ببینید. برای نمونه‌های control plane با دسترسی بالا،
گزینه‌های توپولوژی با دسترسی بالا،
ایجاد کلاسترهای با دسترسی بالا با kubeadm
و مدیریت کلاسترهای etcd برای کوبرنتیز را ببینید.
برای اطلاعات درباره تهیه برنامه پشتیبان etcd،
پشتیبان‌گیری از یک کلاستر etcd
را ببینید.
گره‌های worker عملیاتی
بارهای کاری با کیفیت عملیاتی باید تاب‌آور باشند و هر چیزی که به آن وابسته‌اند
نیز باید تاب‌آور باشد (مانند CoreDNS). چه control plane را خودتان مدیریت کنید
و چه یک ارائه‌دهنده ابری این کار را برای شما انجام دهد، همچنان باید در نظر بگیرید
که می‌خواهید گره‌های worker خود را چگونه مدیریت کنید (که به آن‌ها به‌سادگی گره هم گفته می‌شود).
- پیکربندی گره‌ها: گره‌ها می‌توانند ماشین فیزیکی یا مجازی باشند. اگر می‌خواهید
گره‌های خودتان را بسازید و مدیریت کنید، می‌توانید یک سیستم‌عامل پشتیبانی‌شده نصب کنید،
سپس سرویس‌های گره مناسب را اضافه و اجرا کنید. در نظر بگیرید:
- تقاضاهای بارهای کاری هنگام راه‌اندازی گره‌ها، با در دسترس بودن حافظه، CPU و سرعت دیسک و ظرفیت ذخیره‌سازی مناسب.
- اینکه سامانه‌های رایانه‌ای عمومی کافی هستند یا بارهای کاری‌ای دارید که به پردازنده GPU، گره‌های ویندوز یا جداسازی VM نیاز دارند.
- اعتبارسنجی گره‌ها: برای اطلاعات درباره اطمینان از اینکه یک گره الزامات پیوستن
به یک کلاستر کوبرنتیز را برآورده می‌کند، تنظیمات معتبر گره را ببینید.
- افزودن گره‌ها به کلاستر: اگر کلاستر را خودتان مدیریت می‌کنید، می‌توانید
با راه‌اندازی ماشین‌های خودتان و افزودن دستی آن‌ها، یا با ثبت خودکار آن‌ها در apiserver کلاستر، گره اضافه کنید.
برای اطلاعات درباره نحوه پیکربندی کوبرنتیز برای افزودن گره به این شکل‌ها، بخش
گره‌ها را ببینید.
- مقیاس‌دهی گره‌ها: برای ظرفیتی که کلاستر در نهایت به آن نیاز خواهد داشت برنامه‌ای داشته باشید.
برای کمک به تعیین تعداد گره‌های مورد نیاز بر اساس تعداد پادها و
کانتینرهایی که باید اجرا کنید، ملاحظات مربوط به کلاسترهای بزرگ را ببینید.
اگر گره‌ها را خودتان مدیریت می‌کنید، این کار می‌تواند به معنای
خرید و نصب تجهیزات فیزیکی خودتان باشد.
- مقیاس‌دهی خودکار گره‌ها: مقیاس‌دهی خودکار گره را بخوانید تا با
ابزارهای موجود برای مدیریت خودکار گره‌ها و ظرفیتی که
فراهم می‌کنند آشنا شوید.
- راه‌اندازی بررسی سلامت گره: برای بارهای کاری مهم، می‌خواهید مطمئن شوید
گره‌ها و پادهای در حال اجرا روی آن گره‌ها سالم‌اند. با استفاده از
دیمون Node Problem Detector
می‌توانید از سلامت گره‌ها مطمئن شوید.
مدیریت کاربر در محیط عملیاتی
در محیط عملیاتی، ممکن است از مدلی که در آن شما یا گروه کوچکی از
افراد به کلاستر دسترسی دارند، به جایی برسید که ده‌ها یا
صدها نفر بالقوه دسترسی داشته باشند. در یک محیط یادگیری یا نمونه اولیه پلتفرم، ممکن است برای همه کارها یک
حساب مدیریتی واحد داشته باشید. در محیط عملیاتی، حساب‌های بیشتری با سطح‌های دسترسی متفاوت به namespaceهای مختلف می‌خواهید.
پذیرفتن یک کلاستر با کیفیت عملیاتی یعنی تصمیم بگیرید چگونه
می‌خواهید به‌صورت گزینشی به کاربران دیگر اجازه دسترسی بدهید. به‌طور خاص، باید
راهبردهایی برای تأیید هویت کسانی که می‌خواهند به کلاستر شما دسترسی پیدا کنند
(احراز هویت) و تصمیم‌گیری درباره اینکه آیا اجازه انجام کاری را که درخواست می‌کنند دارند
(مجوزدهی) انتخاب کنید:
- احراز هویت: apiserver می‌تواند کاربران را با گواهینامه‌های کلاینت،
توکن‌های bearer، یک پروکسی احراز هویت، یا احراز هویت پایه HTTP شناسایی کند.
می‌توانید انتخاب کنید کدام روش‌های احراز هویت را می‌خواهید استفاده کنید.
با استفاده از افزونه‌ها، apiserver می‌تواند از روش‌های احراز هویت موجود سازمان شما،
مانند LDAP یا Kerberos، بهره ببرد. برای شرح این روش‌های مختلف احراز هویت کاربران کوبرنتیز،
احراز هویت
را ببینید.
- مجوزدهی: وقتی می‌خواهید کاربران عادی را مجاز کنید، احتمالاً بین
مجوزدهی RBAC و ABAC یکی را انتخاب می‌کنید. برای مرور حالت‌های مختلف مجوزدهی حساب‌های کاربری
(و همچنین دسترسی حساب سرویس به کلاستر)،
نمای کلی مجوزدهی را ببینید:
- کنترل دسترسی مبتنی بر نقش (RBAC): به شما امکان می‌دهد
با دادن مجموعه‌های مشخصی از مجوزها به کاربران احراز هویت‌شده، دسترسی به کلاستر را اختصاص دهید.
مجوزها را می‌توان برای یک namespace مشخص (Role) یا در سراسر کلاستر
(ClusterRole) اختصاص داد. سپس با RoleBinding و ClusterRoleBinding، آن مجوزها را می‌توان به
کاربران مشخص متصل کرد.
- کنترل دسترسی مبتنی بر ویژگی (ABAC): به شما امکان می‌دهد
بر اساس ویژگی‌های منبع در کلاستر سیاست بسازید و بر اساس همان ویژگی‌ها دسترسی را مجاز یا رد کنید.
هر خط از یک فایل سیاست، ویژگی‌های نسخه‌بندی (apiVersion
و kind) و نگاشتی از ویژگی‌های spec را مشخص می‌کند تا با فاعل (کاربر یا گروه)، ویژگی منبع،
ویژگی غیرمنبع (/version یا /apis) و readonly مطابقت داده شود. برای جزئیات،
نمونه‌ها را ببینید.
به‌عنوان کسی که احراز هویت و مجوزدهی را روی کلاستر عملیاتی کوبرنتیز تنظیم می‌کند، این موارد را در نظر بگیرید:
- تنظیم حالت مجوزدهی: وقتی سرور API کوبرنتیز
(kube-apiserver)
راه‌اندازی می‌شود، حالت‌های مجوزدهی پشتیبانی‌شده باید با یک فایل --authorization-config یا پرچم --authorization-mode
تنظیم شوند. برای مثال، آن پرچم در فایل kube-adminserver.yaml (در /etc/kubernetes/manifests)
می‌تواند روی Node,RBAC تنظیم شود. این کار مجوزدهی Node و RBAC را برای درخواست‌های احراز هویت‌شده مجاز می‌کند.
- ایجاد گواهینامه‌های کاربر و اتصال نقش (RBAC): اگر از مجوزدهی RBAC
استفاده می‌کنید، کاربران می‌توانند یک CertificateSigningRequest (CSR) بسازند که
مرجع صدور گواهی کلاستر آن را امضا کند. سپس می‌توانید Roleها و ClusterRoleها را به هر کاربر متصل کنید.
برای جزئیات، درخواست‌های امضای گواهینامه
را ببینید.
- ایجاد سیاست‌هایی که ویژگی‌ها را ترکیب می‌کنند (ABAC): اگر از مجوزدهی ABAC
استفاده می‌کنید، می‌توانید ترکیب‌هایی از ویژگی‌ها را به‌صورت سیاست اختصاص دهید تا
کاربران یا گروه‌های انتخاب‌شده برای دسترسی به منابع خاص (مانند یک
پاد)، namespace یا apiGroup مجاز شوند. برای اطلاعات بیشتر،
نمونه‌ها را ببینید.
- در نظر گرفتن کنترل‌کننده‌های پذیرش: شکل‌های دیگری از مجوزدهی برای
درخواست‌هایی که از طریق سرور API وارد می‌شوند شامل
احراز هویت توکن با Webhook
است.
Webhookها و دیگر انواع ویژه مجوزدهی باید با افزودن
کنترل‌کننده‌های پذیرش
به سرور API فعال شوند.
تعیین محدودیت برای منابع بار کاری
تقاضاهای بارهای کاری عملیاتی می‌توانند هم درون و هم بیرون
control plane کوبرنتیز فشار ایجاد کنند. هنگام آماده‌سازی برای
نیازهای بارهای کاری کلاستر، این موارد را در نظر بگیرید:
- تعیین محدودیت‌های namespace: سهمیه‌های هر namespace را برای چیزهایی مانند حافظه و CPU تنظیم کنید. برای جزئیات،
مدیریت منابع حافظه، CPU و API
را ببینید.
- آمادگی برای تقاضای DNS: اگر انتظار دارید بارهای کاری به‌شدت مقیاس بگیرند،
سرویس DNS شما هم باید آماده مقیاس‌گیری باشد.
مقیاس‌دهی خودکار سرویس DNS در یک کلاستر را ببینید.
- ایجاد حساب‌های سرویس بیشتر: حساب‌های کاربری تعیین می‌کنند کاربران روی یک کلاستر چه کاری می‌توانند
انجام دهند، در حالی که یک حساب سرویس دسترسی پاد را درون یک
namespace مشخص تعریف می‌کند. به‌طور پیش‌فرض، یک پاد حساب سرویس پیش‌فرض namespace خود را برمی‌گیرد.
برای اطلاعات درباره ایجاد یک حساب سرویس جدید،
مدیریت حساب‌های سرویس
را ببینید. برای مثال، ممکن است بخواهید:
گام‌های بعدی