محیط عملیاتی

• 1: محیط‌های اجرای کانتینر
• 2: نصب کوبرنتیز با ابزارهای استقرار
• 2.1: راه‌اندازی کلاسترها با kubeadm
• 2.1.1: نصب kubeadm
• 2.1.2: عیب‌یابی kubeadm
• 2.1.3: راه‌اندازی کلاستر etcd با قابلیت دسترسی بالا با kubeadm
• 2.1.4: پیکربندی هر kubelet در کلاستر شما با استفاده از kubeadm

1 - محیط‌های اجرای کانتینر

باید روی هر گره (Node) کلاستر یک محیط اجرای کانتینر نصب کنید تا پادها بتوانند آنجا اجرا شوند. این صفحه شرح می‌دهد چه کارهایی لازم است و وظایف مرتبط با راه‌اندازی گره‌ها را توضیح می‌دهد.

کوبرنتیز 1.37 ایجاب می‌کند از یک محیط اجرای کانتینر استفاده کنید که با رابط محیط اجرای کانتینر (CRI) سازگار باشد.

برای اطلاعات بیشتر، پشتیبانی از نسخه CRI را ببینید.

این صفحه طرحی از نحوه استفاده از چند محیط اجرای کانتینر رایج همراه با کوبرنتیز ارائه می‌دهد.

• containerd
• CRI-O
• Docker Engine
• Mirantis Container Runtime

نصب و پیکربندی پیش‌نیازها

پیکربندی شبکه

به‌طور پیش‌فرض، هسته لینوکس اجازه نمی‌دهد بسته‌های IPv4 بین رابط‌ها مسیریابی شوند. بیشتر پیاده‌سازی‌های شبکه کلاستر کوبرنتیز این تنظیم را (در صورت نیاز) تغییر می‌دهند، اما برخی انتظار دارند مدیر این کار را برای آن‌ها انجام دهد. (برخی همچنین انتظار دارند پارامترهای sysctl دیگری تنظیم شود، ماژول‌های هسته بارگذاری شود و مانند آن؛ مستندات پیاده‌سازی شبکه خودتان را ببینید.)

فعال‌سازی هدایت بسته IPv4

برای فعال کردن دستی هدایت بسته IPv4:

# پارامترهای sysctl مورد نیاز راه‌اندازی؛ این پارامترها پس از راه‌اندازی مجدد باقی می‌مانند
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# اعمال پارامترهای sysctl بدون راه‌اندازی مجدد
sudo sysctl --system

بررسی کنید که net.ipv4.ip_forward روی 1 تنظیم شده باشد:

sysctl net.ipv4.ip_forward

درایورهای cgroup

در لینوکس، از گروه‌های کنترل برای محدود کردن منابعی که به فرایندها تخصیص می‌یابد استفاده می‌شود.

هم kubelet و هم محیط اجرای کانتینر زیرین باید با گروه‌های کنترل ارتباط برقرار کنند تا مدیریت منابع پادها و کانتینرها را اعمال کنند و منابعی مانند درخواست‌ها و محدودیت‌های cpu/حافظه را تنظیم کنند. برای ارتباط با گروه‌های کنترل، kubelet و محیط اجرای کانتینر باید از یک درایور cgroup استفاده کنند. بسیار مهم است که kubelet و محیط اجرای کانتینر از یک درایور cgroup یکسان استفاده کنند و به یک شکل پیکربندی شده باشند.

دو درایور cgroup در دسترس است:

• cgroupfs
• systemd

درایور cgroupfs

درایور cgroupfs درایور cgroup پیش‌فرض در kubelet است. وقتی از درایور cgroupfs استفاده می‌شود، kubelet و محیط اجرای کانتینر مستقیماً با سیستم‌فایل cgroup ارتباط برقرار می‌کنند تا cgroupها را پیکربندی کنند.

وقتی systemd سیستم init باشد، درایور cgroupfs توصیه نمی‌شود، چون systemd انتظار دارد یک مدیر cgroup واحد روی سامانه باشد. علاوه بر این، اگر از cgroup v2 استفاده می‌کنید، به‌جای cgroupfs از درایور cgroup systemd استفاده کنید.

درایور cgroup از نوع systemd

وقتی systemd به‌عنوان سیستم init یک توزیع لینوکس انتخاب می‌شود، فرایند init یک گروه کنترل ریشه (cgroup) می‌سازد و مصرف می‌کند و نقش مدیر cgroup را دارد.

systemd یکپارچگی تنگاتنگی با cgroupها دارد و برای هر واحد systemd یک cgroup تخصیص می‌دهد. در نتیجه، اگر systemd را به‌عنوان سیستم init همراه با درایور cgroupfs به کار ببرید، سامانه دو مدیر cgroup متفاوت خواهد داشت.

دو مدیر cgroup دو دیدگاه متفاوت از منابع موجود و در حال استفاده سامانه ایجاد می‌کنند. در برخی موارد، گره‌هایی که برای kubelet و محیط اجرای کانتینر روی cgroupfs پیکربندی شده‌اند اما بقیه فرایندها را با systemd اجرا می‌کنند، زیر فشار منابع ناپایدار می‌شوند.

راه کاهش این ناپایداری آن است که وقتی systemd سیستم init انتخاب‌شده است، systemd را به‌عنوان درایور cgroup برای kubelet و محیط اجرای کانتینر به کار ببرید.

برای تنظیم systemd به‌عنوان درایور cgroup، گزینه KubeletConfiguration به نام cgroupDriver را ویرایش کنید و آن را روی systemd بگذارید. برای مثال:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd

اگر systemd را به‌عنوان درایور cgroup برای kubelet پیکربندی کنید، باید systemd را به‌عنوان درایور cgroup محیط اجرای کانتینر هم پیکربندی کنید. برای دستورالعمل، به مستندات محیط اجرای کانتینر خودتان مراجعه کنید. برای مثال:

• containerd
• CRI-O

در کوبرنتیز 1.37، وقتی دروازه ویژگی KubeletCgroupDriverFromCRI فعال باشد و محیط اجرای کانتینر از RPC مربوط به RuntimeConfig در CRI پشتیبانی کند، kubelet درایور cgroup مناسب را به‌طور خودکار از محیط اجرا تشخیص می‌دهد و تنظیم cgroupDriver درون پیکربندی kubelet را نادیده می‌گیرد.

با این حال، نسخه‌های قدیمی‌تر محیط‌های اجرای کانتینر (به‌طور مشخص containerd نسخه 1.y و پایین‌تر) از RPC مربوط به RuntimeConfig در CRI پشتیبانی نمی‌کنند و ممکن است به این پرس‌وجو پاسخ درست ندهند؛ در این صورت Kubelet به مقدار پرچم --cgroup-driver خودش برمی‌گردد.

در کوبرنتیز ۱.۳۸ این رفتار بازگشت حذف می‌شود و نسخه‌های قدیمی‌تر containerd با kubeletهای جدیدتر با شکست مواجه می‌شوند.

پشتیبانی از نسخه CRI

محیط اجرای کانتینر شما باید از نسخه v1 رابط محیط اجرای کانتینر پشتیبانی کند.

کوبرنتیز از v1.26 به بعد فقط با نسخه v1 از API مربوط به CRI کار می‌کند. اگر یک محیط اجرای کانتینر از API نسخه v1 پشتیبانی نکند، kubelet به‌عنوان گره ثبت نمی‌شود.

محیط‌های اجرای کانتینر

containerd

این بخش گام‌های لازم برای استفاده از containerd به‌عنوان محیط اجرای CRI را شرح می‌دهد.

برای نصب containerd روی سامانه خود، دستورالعمل‌های شروع کار با containerd را دنبال کنید. پس از آنکه یک فایل پیکربندی معتبر config.toml ساختید، به این گام برگردید.

• Linux
• Windows

در لینوکس، سوکت پیش‌فرض CRI برای containerd برابر است با /run/containerd/containerd.sock. در ویندوز، نقطه پایانی پیش‌فرض CRI برابر است با npipe://./pipe/containerd-containerd.

پیکربندی درایور cgroup از نوع systemd

برای استفاده از درایور cgroup از نوع systemd در /etc/containerd/config.toml همراه با runc، پیکربندی زیر را بر اساس نسخه Containerd خود تنظیم کنید.

نسخه‌های 1.x از Containerd:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

نسخه‌های 2.x از Containerd:

[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
  ...
  [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
    SystemdCgroup = true

اگر از cgroup v2 استفاده می‌کنید، درایور cgroup از نوع systemd توصیه می‌شود.

اگر این تغییر را اعمال می‌کنید، حتماً containerd را دوباره راه‌اندازی کنید:

sudo systemctl restart containerd

در کوبرنتیز v1.28 می‌توانید تشخیص خودکار درایور cgroup را به‌عنوان یک قابلیت آلفا فعال کنید. برای جزئیات بیشتر، درایور cgroup از نوع systemd را ببینید.

جایگزینی ایمیج sandbox (pause)

در پیکربندی containerd می‌توانید ایمیج sandbox را با تنظیم پیکربندی زیر بازنویسی کنید:

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.10"

پس از به‌روزرسانی فایل پیکربندی، ممکن است لازم باشد containerd را هم دوباره راه‌اندازی کنید: systemctl restart containerd.

CRI-O

این بخش گام‌های لازم برای نصب CRI-O به‌عنوان محیط اجرای کانتینر را در بر دارد.

برای نصب CRI-O، دستورالعمل نصب CRI-O را دنبال کنید.

درایور cgroup

CRI-O به‌طور پیش‌فرض از درایور cgroup از نوع systemd استفاده می‌کند، که احتمالاً برای شما درست کار می‌کند. برای جابه‌جایی به درایور cgroup از نوع cgroupfs، یا /etc/crio/crio.conf را ویرایش کنید یا یک پیکربندی drop-in در /etc/crio/crio.conf.d/02-cgroup-manager.conf بگذارید، برای مثال:

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

باید به conmon_cgroup تغییر یافته هم توجه کنید؛ هنگام استفاده از CRI-O با cgroupfs باید روی مقدار pod تنظیم شود. به‌طور کلی لازم است پیکربندی درایور cgroup در kubelet (که معمولاً از راه kubeadm انجام می‌شود) و CRI-O هم‌گام بماند.

در کوبرنتیز v1.28 می‌توانید تشخیص خودکار درایور cgroup را به‌عنوان یک قابلیت آلفا فعال کنید. برای جزئیات بیشتر، درایور cgroup از نوع systemd را ببینید.

برای CRI-O، سوکت CRI به‌طور پیش‌فرض /var/run/crio/crio.sock است.

جایگزینی ایمیج sandbox (pause)

در پیکربندی CRI-O می‌توانید مقدار پیکربندی زیر را تنظیم کنید:

[crio.image]
pause_image="registry.k8s.io/pause:3.10"

این گزینه پیکربندی از بارگذاری زنده پیکربندی برای اعمال تغییر پشتیبانی می‌کند: systemctl reload crio، یا با فرستادن SIGHUP به فرایند crio.

Docker Engine

1. روی هر یک از گره‌ها، Docker را برای توزیع لینوکس خود مطابق نصب Docker Engine نصب کنید.

2. cri-dockerd را نصب کنید و دستورالعمل‌های بخش نصب مستندات را دنبال کنید.

برای cri-dockerd، سوکت CRI به‌طور پیش‌فرض /run/cri-dockerd.sock است.

Mirantis Container Runtime

Mirantis Container Runtime (MCR) یک محیط اجرای کانتینر تجاری است که پیش‌تر با نام Docker Enterprise Edition شناخته می‌شد.

می‌توانید Mirantis Container Runtime را با کوبرنتیز و با استفاده از مؤلفه متن‌باز cri-dockerd که همراه MCR است به کار ببرید.

برای آشنایی بیشتر با نحوه نصب Mirantis Container Runtime، به راهنمای استقرار MCR مراجعه کنید.

برای یافتن مسیر سوکت CRI، واحد systemd به نام cri-docker.socket را بررسی کنید.

جایگزینی ایمیج sandbox (pause)

آداپتور cri-dockerd یک آرگومان خط فرمان می‌پذیرد تا مشخص کند کدام ایمیج کانتینر به‌عنوان کانتینر زیرساخت پاد («ایمیج pause») استفاده شود. آرگومان خط فرمان مورد استفاده --pod-infra-container-image است.

گام‌های بعدی

علاوه بر یک محیط اجرای کانتینر، کلاستر شما به یک افزونه شبکه در حال کار نیاز دارد.

2 - نصب کوبرنتیز با ابزارهای استقرار

روش‌ها و ابزارهای زیادی برای راه‌اندازی کلاستر کوبرنتیز خودتان در محیط عملیاتی وجود دارد. برای مثال:

• kubeadm

• Cluster API: زیرپروژه‌ای از کوبرنتیز که بر ارائه APIهای اعلانی و ابزارهایی برای ساده‌سازی تهیه‌سازی، ارتقا و بهره‌برداری از چندین کلاستر کوبرنتیز تمرکز دارد.

• kops: ابزاری خودکار برای تهیه‌سازی کلاستر. برای آموزش‌ها، بهترین شیوه‌ها، گزینه‌های پیکربندی و اطلاعات مربوط به ارتباط با جامعه، جزئیات را در وب‌سایت kOps ببینید.

• kubespray: ترکیبی از playbookهای Ansible، فهرست (inventory)، ابزارهای تهیه‌سازی، و دانش تخصصی برای کارهای عمومی مدیریت پیکربندی سیستم‌عامل و کلاسترهای کوبرنتیز. می‌توانید از طریق کانال Slack #kubespray با جامعه در تماس باشید.

2.1 - راه‌اندازی کلاسترها با kubeadm

2.1.1 - نصب kubeadm

این صفحه نحوه نصب جعبه ابزار kubeadm را نشان می‌دهد. برای کسب اطلاعات در مورد نحوه ایجاد یک کلاستر با kubeadm پس از انجام این فرآیند نصب، به صفحه ایجاد یک کلاستر با kubeadm مراجعه کنید.

پیش از شروع

• یک میزبان لینوکس سازگار. پروژه کوبرنتیز دستورالعمل‌های عمومی برای توزیع‌های لینوکس مبتنی بر Debian و Red Hat و توزیع‌های بدون مدیر بسته ارائه می‌دهد.
• ۲ گیگابایت یا بیشتر رم برای هر دستگاه (هر چه کمتر باشد، فضای کمی برای برنامه‌های شما باقی می‌ماند).
• ۲ پردازنده مرکزی یا بیشتر برای ماشین‌های کنترلی.
• اتصال کامل شبکه بین تمام ماشین‌های موجود در کلاستر (شبکه عمومی یا خصوصی اشکالی ندارد).
• نام میزبان، نشانی(آدرس) MAC و شناسه محصول منحصر به فرد برای هر گره(node). برای جزئیات بیشتر به اینجا مراجعه کنید.
• پورت‌های خاصی روی دستگاه‌های شما باز هستند. برای جزئیات بیشتر به اینجا مراجعه کنید.

نسخه سیستم عامل خود را بررسی کنید

• Linux
• Windows

یک کلاستر کوبرنتیز که توسط kubeadm ایجاد می‌شود، به نرم‌افزاری بستگی دارد که از ویژگی‌های هسته(kernel) استفاده می‌کند. این نرم‌افزار شامل، اما نه محدود به container runtime، kubelet، و یک افزونه Container Network Interface می‌شود.

برای کمک به شما در جلوگیری از خطاهای غیرمنتظره ناشی از عدم پشتیبانی از نسخه هسته، kubeadm بررسی پیش از اجرای SystemVerification را اجرا می‌کند. اگر نسخه هسته(kernel) پشتیبانی نشود، این بررسی با شکست مواجه می‌شود.

اگر می‌دانید که هسته(kernel) شما ویژگی‌های مورد نیاز را ارائه می‌دهد، حتی اگر kubeadm از نسخه آن پشتیبانی نکند، می‌توانید از بررسی صرف نظر کنید.

بررسی کنید که نشانی(آدرس) MAC و product_uuid برای هر گره(node) منحصر به فرد باشند

• شما می‌توانید نشانی(آدرس) MAC رابط‌های شبکه را با استفاده از دستور ip link یا ifconfig -a دریافت کنید.
• شناسه محصول (product_uuid) را می‌توان با استفاده از دستور sudo cat /sys/class/dmi/id/product_uuid بررسی کرد.

بسیار محتمل است که دستگاه‌های سخت‌افزاری نشانی(آدرس) های منحصر به فردی داشته باشند، اگرچه برخی از ماشین‌های مجازی ممکن است مقادیر یکسانی داشته باشند. کوبرنتیز از این مقادیر برای شناسایی منحصر به فرد گره‌ها در کلاستر استفاده می‌کند. اگر این مقادیر برای هر گره(node) منحصر به فرد نباشند، فرآیند نصب ممکن است با شکست مواجه شود.

بررسی آداپتورهای شبکه

اگر بیش از یک adapters شبکه دارید و اجزای کوبرنتیز شما از طریق مسیر پیش‌فرض قابل دسترسی نیستند، توصیه می‌کنیم مسیر(های) IP را اضافه کنید تا نشانی(آدرس) های کلاستر کوبرنتیز از طریق adapters مناسب عبور کنند.

بررسی پورت‌های مورد نیاز

این پورت‌های مورد نیاز برای اینکه اجزای Kubernetes بتوانند با یکدیگر ارتباط برقرار کنند، باید باز باشند. می‌توانید از ابزارهایی مانند netcat برای بررسی باز بودن یک پورت استفاده کنید. به عنوان مثال:

nc 127.0.0.1 6443 -zv -w 2

افزونه شبکه پاد که استفاده می‌کنید ممکن است نیاز به باز بودن پورت‌های خاصی داشته باشد. از آنجایی که این موضوع در هر افزونه شبکه پاد متفاوت است، لطفاً برای اطلاع از پورت(های) مورد نیاز افزونه‌ها، به مستندات آنها مراجعه کنید.

پیکربندی Swap

رفتار پیش‌فرض یک kubelet این است که در صورت شناسایی حافظه swap در یک گره، شروع به کار نکند. این بدان معناست که swap باید یا غیرفعال شود یا توسط kubelet تحمل شود.

• برای تحمل swap، failSwapOn: false را به پیکربندی kubelet یا به عنوان یک آرگومان خط فرمان اضافه کنید. توجه: حتی اگر failSwapOn: false ارائه شود، بارهای کاری به طور پیش‌فرض به swap دسترسی نخواهند داشت. این را می‌توان با تنظیم swapBehavior، دوباره در فایل(فایل) پیکربندی kubelet، تغییر داد. برای استفاده از swap، swapBehavior را به غیر از تنظیم پیش‌فرض NoSwap تنظیم کنید. برای جزئیات بیشتر به مدیریت حافظه swap مراجعه کنید.
• برای غیرفعال کردن swap، می‌توان از دستور sudo swapoff -a برای غیرفعال کردن موقت swap استفاده کرد.

برای اینکه این تغییر در راه‌اندازی‌های مجدد پایدار بماند، مطمئن شوید که swap در فایل‌های پیکربندی مانند /etc/fstab، systemd.swap غیرفعال شده است، بسته به اینکه چگونه روی سیستم شما پیکربندی شده است.

نصب یک محیط اجرای کانتینر

برای اجرای کانتینرها در پادها، کوبرنتیز از یک container runtime استفاده می‌کند.

به طور پیش‌فرض، کوبرنتیز از Container Runtime Interface (CRI) برای ارتباط با محیط اجرای کانتینر انتخابی شما استفاده می‌کند.

اگر محیط اجرای کانتینر را مشخص نکنید، kubeadm به طور خودکار سعی می‌کند با اسکن لیستی از نقاط پایانی شناخته شده، محیط اجرای کانتینر نصب شده را تشخیص دهد. اگر چندین محیط اجرای کانتینر شناسایی شود یا هیچ محیط اجرای کانتینری شناسایی نشود، kubeadm خطایی ایجاد می‌کند و از شما می‌خواهد که مشخص کنید می‌خواهید از کدام یک استفاده کنید.

برای اطلاعات بیشتر به محیط های اجرای کانتینر مراجعه کنید.

جداول زیر شامل نقاط پایانی شناخته شده برای سیستم عامل‌های پشتیبانی شده است:

• Linux
• Windows

نصب kubeadm، kubelet و kubectl

شما این بسته‌ها را روی تمام دستگاه‌های خود نصب خواهید کرد:

• kubeadm: دستور راه اندازی کلاستر.

• kubelet: مؤلفه‌ای که روی تمام ماشین‌های موجود در کلاستر شما اجرا می‌شود و کارهایی مانند راه‌اندازی پادها و کانتینرها را انجام می‌دهد.

• kubectl: ابزار خط فرمان برای ارتباط با کلاستر شما.

‘kubelet’ , kubeadm یا kubectl را برای شما نصب یا مدیریت نخواهد کرد، بنابراین باید مطمئن شوید که آنها با نسخه control plane کوبرنتیز که می‌خواهید kubeadm برای شما نصب کند، مطابقت دارند. اگر این کار را نکنید، خطر بروز انحراف نسخه وجود دارد که می‌تواند منجر به رفتار غیرمنتظره و باگ‌دار شود. با این حال، انحراف یک نسخه جزئی بین kubelet و control plane پشتیبانی می‌شود، اما نسخه kubelet هرگز نمی‌تواند از نسخه سرور API فراتر رود. به عنوان مثال، kubelet که نسخه ۱.۷.۰ را اجرا می‌کند باید کاملاً با یک سرور API نسخه ۱.۸.۰ سازگار باشد، اما برعکس آن امکان‌پذیر نیست.

برای اطلاعات بیشتر در مورد نصب kubectl، به نصب و راه‌اندازی kubectl مراجعه کنید.

برای اطلاعات بیشتر در مورد انحراف نسخه، به موارد زیر مراجعه کنید:

• کوبرنتیز نسخه و سیاست انحراف نسخه
• ابزار Kubeadm-specific سیاست انحراف نسخه

• Debian-based distributions
• Red Hat-based distributions
• Without a package manager

CNI_PLUGINS_VERSION="v1.3.0"
ARCH="amd64"
DEST="/opt/cni/bin"
sudo mkdir -p "$DEST"
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz

DOWNLOAD_DIR="/usr/local/bin"
sudo mkdir -p "$DOWNLOAD_DIR"

CRICTL_VERSION="v1.31.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet}
sudo chmod +x {kubeadm,kubelet}

RELEASE_VERSION="v0.16.2"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubelet/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service
sudo mkdir -p /usr/lib/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

sudo systemctl enable --now kubelet

Kubelet حالا هر چند ثانیه یک بار ری‌استارت می‌شود، چون در یک حلقه‌ی توقف منتظر می‌ماند تا kubeadm به آن بگوید چه کاری انجام دهد.

پیکربندی درایور cgroup

پیکربندی درایور cgroup هم محیط اجرای کانتینر و هم kubelet دارای یک ویژگی به نام "cgroup driver" هستند که برای مدیریت cgroupها در دستگاه‌های لینوکس مهم است.

عیب‌یابی

اگر با kubeadm به مشکل برخوردید، لطفاً به مستندات عیب‌یابی ما مراجعه کنید.

گام‌های بعدی

• استفاده از kubeadm برای ایجاد یک کلاستر

2.1.2 - عیب‌یابی kubeadm

مانند هر برنامه دیگری، ممکن است در نصب یا اجرای kubeadm با خطایی مواجه شوید. این صفحه برخی از سناریوهای رایج خرابی را فهرست کرده و مراحلی را ارائه داده است که می‌تواند به شما در درک و رفع مشکل کمک کند.

اگر مشکل شما در لیست زیر نیست، لطفاً مراحل زیر را دنبال کنید:

• اگر فکر می‌کنید مشکل شما یک باگ در kubeadm است:

  • به github.com/kubernetes/kubeadm بروید و مشکلات موجود را جستجو کنید.
  • اگر مشکلی وجود ندارد، لطفاً یکی را باز کنید و الگوی مشکل را دنبال کنید.

• اگر در مورد نحوه‌ی کار kubeadm مطمئن نیستید، می‌توانید در Slack در #kubeadm سوال خود را بپرسید، یا در StackOverflow سوالی مطرح کنید. لطفاً برچسب‌های مرتبط مانند #kubernetes و #kubeadm را وارد کنید تا دیگران بتوانند به شما کمک کنند.

به دلیل عدم وجود RBAC، امکان اتصال یک گره(node) نسخه ۱.۱۸ به یک کلاستر نسخه ۱.۱۷ وجود ندارد.

در نسخه ۱.۱۸ kubeadm، در صورتی که گره‌ای با نام مشابه از قبل وجود داشته باشد، امکان جلوگیری از پیوستن آن به یک گره(node) در کلاستر اضافه شد. این امر مستلزم اضافه کردن RBAC برای کاربر bootstrap-token بود تا بتواند یک شیء گره(node) را دریافت کند.

با این حال، این مسئله باعث می‌شود که kubeadm join از نسخه ۱.۱۸ نتواند به کلاستر که توسط kubeadm نسخه ۱.۱۷ ایجاد شده است، بپیوندد.

برای حل مشکل، دو گزینه دارید:

دستور kubeadm init phase bootstrap-token را روی یک گره(node) control-plane با استفاده از kubeadm نسخه ۱.۱۸ اجرا کنید.

توجه داشته باشید که این دستور بقیه مجوزهای bootstrap-token را نیز فعال می‌کند.

یا

RBAC زیر را به صورت دستی با استفاده از kubectl apply -f ... اعمال کنید:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubeadm:get-nodes
rules:
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubeadm:get-nodes
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubeadm:get-nodes
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:bootstrappers:kubeadm:default-node-token

فایل اجرایی ebtables یا فایل اجرایی مشابه آن در حین نصب پیدا نشد.

اگر هنگام اجرای kubeadm init هشدارهای زیر را مشاهده کردید

[preflight] WARNING: ebtables not found in system path
[preflight] WARNING: ethtool not found in system path

پس ممکن است ebtables، ethtool یا یک فایل اجرایی مشابه را روی گره(node) خود نداشته باشید. می‌توانید آنها را با دستورات زیر نصب کنید:

• برای کاربران اوبونتو/دبیان، دستور apt install ebtables ethtool را اجرا کنید.
• برای کاربران CentOS/Fedora، دستور yum install ebtables ethtool را اجرا کنید.

kubeadm در هنگام نصب در انتظار control plane می‌ماند

اگر متوجه شدید که kubeadm init پس از چاپ خط زیر هنگ می‌کند:

[apiclient] Created API client, waiting for the control plane to become ready

این ممکن است ناشی از تعدادی از مشکلات باشد. رایج‌ترین آنها عبارتند از:

• مشکلات اتصال شبکه. قبل از ادامه، بررسی کنید که دستگاه شما اتصال کامل به شبکه دارد.
• درایور cgroup مربوط به مجری کانتینر با درایور kubelet متفاوت است. برای درک نحوه پیکربندی صحیح آن، به پیکربندی درایور cgroup مراجعه کنید.
• کانتینرهای control plane دچار crash loop یا هنگ شده‌اند. می‌توانید این مورد را با اجرای docker ps و بررسی هر کانتینر با اجرای docker logs بررسی کنید. برای سایر کانتینرهای زمان اجرا، به اشکال‌زدایی گره‌های Kubernetes با crictl مراجعه کنید.

kubeadm هنگام حذف کانتینرهای مدیریت‌شده، مسدود می‌شود

اگر مجری کانتینر متوقف شود و هیچ کانتینری که توسط کوبرنتیز مدیریت می‌شود را حذف نکند، موارد زیر ممکن است رخ دهد:

sudo kubeadm reset

[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
(block)

یک راه حل ممکن، راه اندازی مجدد مجری کانتینر و سپس اجرای مجدد kubeadm reset است. همچنین می‌توانید از crictl برای اشکال زدایی وضعیت مجری کانتینر استفاده کنید. به اشکال زدایی گره‌های کوبرنتیز با crictl مراجعه کنید.

پادها در وضعیت‌های RunContainerError، CrashLoopBackOff یا Error

درست پس از kubeadm init نباید هیچ پادی در این حالت‌ها وجود داشته باشد.

• اگر پادها درست بعد از kubeadm init در یکی از این حالت‌ها هستند، لطفاً یک مشکل را در مخزن kubeadm باز کنید. coredns (یا kube-dns) باید تا زمانی که افزونه شبکه را مستقر نکرده‌اید، در حالت Pending باشد.
• اگر پس از نصب افزونه شبکه، Pods را در حالت‌های RunContainerError، CrashLoopBackOff یا Error مشاهده کردید و هیچ اتفاقی برای coredns (یا kube-dns) نیفتاد، به احتمال زیاد افزونه Pod Network که نصب کرده‌اید به نحوی خراب است. ممکن است مجبور شوید امتیازات RBAC بیشتری به آن اعطا کنید یا از نسخه جدیدتری استفاده کنید. لطفاً مشکل را در ردیاب مشکلات ارائه دهندگان Pod Network ثبت کنید و مشکل را در آنجا بررسی کنید.

«coredns» در حالت Pending گیر کرده است

این انتظار می‌رود و بخشی از طراحی است. kubeadm مستقل از ارائه‌دهنده شبکه است، بنابراین مدیر باید افزونه شبکه pod را نصب کند. شما باید قبل از اینکه CoreDNS به طور کامل مستقر شود، یک افزونه Pod Network نصب کنید. از این رو، قبل از راه‌اندازی شبکه، در حالت «در انتظار» قرار دارد.

سرویس‌های HostPort کار نمی‌کنند

قابلیت‌های «HostPort» و «HostIP» بسته به ارائه‌دهنده‌ی شبکه‌ی پاد شما در دسترس هستند. لطفاً برای اطلاع از در دسترس بودن قابلیت‌های «HostPort» و «HostIP» با نویسنده‌ی افزونه‌ی Pod Network تماس بگیرید.

ارائه دهندگان CNI مربوط به Calico، Canal و Flannel تأیید شده‌اند که از HostPort پشتیبانی می‌کنند.

برای اطلاعات بیشتر، به مستندات نقشه پورت CNI مراجعه کنید.

اگر ارائه دهنده شبکه شما از افزونه portmap CNI پشتیبانی نمی‌کند، ممکن است لازم باشد از ویژگی NodePort سرویس‌ها استفاده کنید یا از HostNetwork=true استفاده کنید.

پادها از طریق سرویس IP خود قابل دسترسی نیستند

• بسیاری از افزونه‌های شبکه هنوز hairpin mode را فعال نمی‌کنند که به پادها اجازه می‌دهد از طریق Service IP خود به خودشان دسترسی داشته باشند. این مشکلی مربوط به CNI است. لطفاً برای دریافت آخرین وضعیت پشتیبانی از حالت hairpin با ارائه‌دهنده افزونه شبکه تماس بگیرید.

• اگر از VirtualBox (مستقیماً یا از طریق Vagrant) استفاده می‌کنید، باید مطمئن شوید که hostname -i یک نشانی(آدرس) IP قابل مسیریابی را برمی‌گرداند. به طور پیش‌فرض، اولین رابط به یک شبکه فقط میزبان غیرقابل مسیریابی متصل است. یک راه حل، تغییر /etc/hosts است، برای مثال به این Vagrantfile مراجعه کنید.

خطاهای گواهی TLS

خطای زیر نشان‌دهنده‌ی عدم تطابق احتمالی گواهی است.

# kubectl get pods
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

• تأیید کنید که فایل $HOME/.kube/config حاوی یک گواهی معتبر است و در صورت لزوم یک گواهی را بازسازی کنید. گواهی‌های موجود در فایل kubeconfig با کد base64 کدگذاری شده‌اند. دستور base64 --decode می‌تواند برای رمزگشایی گواهی و دستور openssl x509 -text -noout می‌تواند برای مشاهده اطلاعات گواهی استفاده شود.

• متغیر محیطی KUBECONFIG را با استفاده از دستور زیر غیرفعال کنید:

  unset KUBECONFIG
  

یا آن را روی مکان پیش‌فرض KUBECONFIG تنظیم کنید:

export KUBECONFIG=/etc/kubernetes/admin.conf

• یک راه حل دیگر، بازنویسی kubeconfig موجود برای کاربر "admin" است:

  mv $HOME/.kube $HOME/.kube.bak
  mkdir $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
  

عدم موفقیت در چرخش گواهی کلاینت Kubelet

به طور پیش‌فرض، kubeadm با استفاده از پیوند نمادین /var/lib/kubelet/pki/kubelet-client-current.pem که در /etc/kubernetes/kubelet.conf مشخص شده است، یک kubelet با چرخش خودکار گواهینامه‌های کلاینت پیکربندی می‌کند. اگر این فرآیند چرخش با شکست مواجه شود، ممکن است خطاهایی مانند x509: certificate has expired or is not yet valid در لاگ‌های kube-apiserver مشاهده کنید. برای رفع مشکل، باید این مراحل را دنبال کنید:

1. از فایل‌های /etc/kubernetes/kubelet.conf و /var/lib/kubelet/pki/kubelet-client* پشتیبان تهیه کرده و آنها را از گره‌ی خراب حذف کنید.

2. از یک گره control plane فعال در کلاستر ای که /etc/kubernetes/pki/ca.key دارد، دستور kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf را اجرا کنید. $NODE باید روی نام گره(node) خراب موجود در کلاستر تنظیم شود. kubelet.conf حاصل را به صورت دستی تغییر دهید تا نام کلاستر و نقطه پایانی سرور تنظیم شود، یا kubeconfig user --config را به آن بدهید (به ایجاد فایل‌های kubeconfig برای کاربران اضافی مراجعه کنید). اگر کلاستر شما ca.key را ندارد، باید گواهی‌های تعبیه شده در kubelet.conf را به صورت خارجی امضا کنید.

3. فایل kubelet.conf حاصل را در /etc/kubernetes/kubelet.conf روی گره‌ی خراب‌شده کپی کنید.

4. Kubelet (systemctl restart kubelet) را روی گره(node) خراب‌شده مجدداً راه‌اندازی کنید و منتظر بمانید تا /var/lib/kubelet/pki/kubelet-client-current.pem دوباره ایجاد شود.

5. فایل kubelet.conf را به صورت دستی ویرایش کنید تا به گواهی‌های کلاینت kubelet چرخانده شده اشاره کند، برای این کار client-certificate-data و client-key-data را با موارد زیر جایگزین کنید:

   client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
   client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
   

6. kubelet را مجدداً راه اندازی کنید.

7. مطمئن شوید که گره(node) به حالت «آماده» (Ready) درآمده است.

کارت شبکه پیش‌فرض هنگام استفاده از flannel به عنوان شبکه پاد در Vagrant

خطای زیر ممکن است نشان دهد که مشکلی در شبکه پاد وجود دارد:

Error from server (NotFound): the server could not find the requested resource

• اگر از flannel به عنوان شبکه pod در Vagrant استفاده می‌کنید، باید نام رابط پیش‌فرض flannel را مشخص کنید.

  Vagrant معمولاً دو رابط به همه ماشین‌های مجازی اختصاص می‌دهد. رابط اول که به همه میزبان‌ها نشانی IP 10.0.2.15 اختصاص داده شده است، برای ترافیک خارجی است که NAT می‌شود.

  این ممکن است منجر به مشکلاتی در flannel شود، که به طور پیش‌فرض روی اولین رابط روی یک میزبان قرار می‌گیرد.

  این امر باعث می‌شود همه میزبان‌ها فکر کنند که نشانی IP عمومی یکسانی دارند. برای جلوگیری از این، پرچم --face eth1 را به flannel ارسال کنید تا رابط دوم انتخاب شود.

IP غیر عمومی مورد استفاده برای کانتینرها

در برخی شرایط، دستورات kubectl logs و kubectl run ممکن است در یک کلاستر با عملکرد عادی، خطاهای زیر را نشان دهند:

Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host

• این ممکن است به دلیل استفاده کوبرنتیز از یک IP باشد که نمی‌تواند با IP های دیگر در زیرشبکه به ظاهر یکسان ارتباط برقرار کند، احتمالاً به دلیل سیاست ارائه دهنده دستگاه.

• DigitalOcean یک IP عمومی به eth0 و همچنین یک IP خصوصی برای استفاده داخلی به عنوان لنگر برای ویژگی IP شناور خود اختصاص می‌دهد، اما kubelet دومی را به جای IP عمومی به عنوان IP داخلی گره(node) انتخاب می‌کند.

  برای بررسی این سناریو به جای ifconfig از ip addr show استفاده کنید زیرا ifconfig نشانی(آدرس) IP مستعار متخلف را نمایش نمی‌دهد. به عنوان یک جایگزین، یک نقطه پایانی API مخصوص DigitalOcean امکان جستجوی IP لنگر را از سرور مجازی فراهم می‌کند:

  curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
  

راه حل این است که با استفاده از --node-ip به kubelet بگویید از کدام IP استفاده کند. هنگام استفاده از DigitalOcean، در صورت تمایل به استفاده از شبکه خصوصی اختیاری، می‌تواند IP عمومی (اختصاص داده شده به eth0) یا IP خصوصی (اختصاص داده شده به eth1) باشد. برای این کار می‌توان از بخش kubeletExtraArgs از ساختار kubeadmNodeRegistrationOptions استفاده کرد.

سپس kubelet را مجدداً راه اندازی کنید:

systemctl daemon-reload
systemctl restart kubelet

پادهای coredns دارای وضعیت CrashLoopBackOff یا Error هستند

اگر گره‌هایی دارید که SELinux را با نسخه قدیمی‌تر Docker اجرا می‌کنند، ممکن است با سناریویی مواجه شوید که در آن پادهای coredns شروع به کار نمی‌کنند. برای حل این مشکل، می‌توانید یکی از گزینه‌های زیر را امتحان کنید:

• به نسخه جدیدتر Docker ارتقا دهید.

• SELinux را غیرفعال کنید.

• فایل استقرار coredns را تغییر دهید تا allowPrivilegeEscalation بر روی true تنظیم شود:

kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -

یکی دیگر از دلایل بروز خطای «CrashLoopBackOff» در CoreDNS زمانی است که یک CoreDNS Pod مستقر در کوبرنتیز یک حلقه را تشخیص دهد. چندین راه حل برای جلوگیری از تلاش کوبرنتیز برای راه‌اندازی مجدد CoreDNS Pod هر بار که CoreDNS حلقه را تشخیص داده و خارج می‌شود، در دسترس هستند.

پادهای etcd مرتباً مجدداً راه‌اندازی می‌شوند

اگر با خطای زیر مواجه شدید:

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""

این مشکل در صورتی ظاهر می‌شود که CentOS 7 را با Docker 1.13.1.84 اجرا کنید. این نسخه از Docker می‌تواند از اجرای kubelet در کانتینر etcd جلوگیری کند.

برای حل مشکل، یکی از این گزینه‌ها را انتخاب کنید:

• بازگشت به نسخه قبلی داکر، مانند 1.13.1-75

  yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
  

• یکی از نسخه‌های پیشنهادی جدیدتر، مانند ۱۸.۰۶ را نصب کنید:

  sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
  yum install docker-ce-18.06.1.ce-3.el7.x86_64
  

ارسال لیستی از مقادیر جدا شده با ویرگول به مولفه های داخل پرچم --component-extra-args امکان‌پذیر نیست.

پرچم‌های kubeadm init مانند --component-extra-args به شما امکان می‌دهند مولفه‌های سفارشی را به یک جزء control plane مانند kube-apiserver ارسال کنید. با این حال، این مکانیسم به دلیل نوع داده‌ای که برای تجزیه مقادیر استفاده می‌شود (mapStringString) محدود است.

اگر تصمیم دارید مولفه ای را ارسال کنید که از چندین مقدار جدا شده با ویرگول مانند --apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists" پشتیبانی می‌کند، این پرچم با flag: malformed pair, expect string=string با شکست مواجه خواهد شد. این اتفاق می‌افتد زیرا لیست مولفه‌ها برای --apiserver-extra-args انتظار جفت‌های key=value را دارد و در این حالت NamespacesExists به عنوان کلیدی در نظر گرفته می‌شود که مقداری از آن کم است.

به عنوان یک روش جایگزین، می‌توانید جفت‌های key=value را به این صورت از هم جدا کنید: --apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists" اما این باعث می‌شود که کلید enable-admission-plugins فقط مقدار NamespaceExists را داشته باشد.

یک راه حل شناخته شده، استفاده از kubeadm فایل پیکربندی است.

kube-proxy قبل از مقداردهی اولیه گره(node) توسط cloud-controller-manager برنامه‌ریزی شده است

در سناریوهای ارائه دهنده ابر، kube-proxy می‌تواند قبل از اینکه cloud-controller-manager نشانی‌های گره(node) را مقداردهی اولیه کند، روی گره‌های کارگر جدید برنامه‌ریزی شود. این باعث می‌شود kube-proxy نتواند نشانی(آدرس) IP گره(node) را به درستی دریافت کند و تأثیرات جانبی بر عملکرد پروکسی که متعادل‌کننده‌های بار را مدیریت می‌کند، داشته باشد.

خطای زیر در kube-proxy Pods قابل مشاهده است:

server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP

یک راه حل شناخته شده، وصله کردن kube-proxy DaemonSet است تا امکان زمان‌بندی آن روی گره‌های control plane صرف نظر از شرایط آنها فراهم شود و تا زمانی که شرایط محافظت اولیه آنها کاهش یابد، از گره‌های دیگر دور نگه داشته شود:

kubectl -n kube-system patch ds kube-proxy -p='{
  "spec": {
    "template": {
      "spec": {
        "tolerations": [
          {
            "key": "CriticalAddonsOnly",
            "operator": "Exists"
          },
          {
            "effect": "NoSchedule",
            "key": "node-role.kubernetes.io/control-plane"
          }
        ]
      }
    }
  }
}'

موضوع ردیابی این مشکل اینجا است.

/usr روی گره‌ها فقط خواندنی نصب شده است

در توزیع‌های لینوکس مانند Fedora CoreOS یا Flatcar Container Linux، پوشه(folder) /usr به عنوان یک فایل سیستم فقط خواندنی نصب می‌شود. برای پشتیبانی از flex-volume، اجزای کوبرنتیز مانند kubelet و kube-controller-manager از مسیر پیش‌فرض /usr/libexec/kubernetes/kubelet-plugins/volume/exec/ استفاده می‌کنند، با این حال پوشه(folder) flex-volume باید قابل نوشتن باشد تا این ویژگی کار کند.

برای حل این مشکل، می‌توانید پوشه(folder) flex-volume را با استفاده از kubeadm پیکربندی کنید. فایل پیکربندی.

در گره(node) کنترل اصلی (که با استفاده از kubeadm init ایجاد شده است)، فایل زیر را با استفاده از --config ارسال کنید:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controllerManager:
  extraArgs:
  - name: "flex-volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

در مورد اتصال گره‌ها:

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

به عنوان یک روش جایگزین، می‌توانید /etc/fstab را تغییر دهید تا mount /usr قابل نوشتن شود، اما لطفاً توجه داشته باشید که این کار، یک اصل طراحی توزیع لینوکس را تغییر می‌دهد.

برنامه ارتقاء kubeadm پیام خطای « context deadline exceeded» را چاپ می‌کند.

این پیام خطا هنگام ارتقاء یک کلاستر کوبرنتیز با kubeadm در صورت اجرای یک etcd خارجی نشان داده می‌شود. این یک اشکال بحرانی نیست و به این دلیل اتفاق می‌افتد که نسخه‌های قدیمی‌تر kubeadm بررسی نسخه را روی کلاستر etcd خارجی انجام می‌دهند. می‌توانید با kubeadm upgrade apply ... ادامه دهید.

این مشکل از نسخه ۱.۱۹ برطرف شده است.

kubeadm reset «/var/lib/kubelet» را از حالت وصل خارج می‌کند

اگر /var/lib/kubelet در حالت متصل باشد، انجام kubeadm reset عملاً آن را از حالت متصل خارج می‌کند.

برای حل این مشکل، پس از انجام عملیات kubeadm reset، پوشه(folder) /var/lib/kubelet را دوباره متصل کنید.

این یک پسرفت است که در kubeadm نسخه ۱.۱۵ معرفی شد. این مشکل در نسخه ۱.۲۰ برطرف شده است.

نمی‌توان از سرور متریک به صورت امن در کلاستر kubeadm استفاده کرد.

در یک کلاستر kubeadm، می‌توان با ارسال --kubelet-insecure-tls به metrics-server به صورت ناامن از آن استفاده کرد. این روش برای کلاستر های عملیاتی توصیه نمی‌شود.

اگر می‌خواهید از TLS بین سرور metrics و kubelet استفاده کنید، مشکلی وجود دارد، زیرا kubeadm یک گواهی سرویس خودامضا برای kubelet مستقر می‌کند. این می‌تواند باعث خطاهای زیر در سمت سرور metrics شود:

x509: certificate signed by unknown authority
x509: certificate is valid for IP-foo not IP-bar

برای درک نحوه پیکربندی kubeletها در یک کلاستر kubeadm برای داشتن گواهی‌های سرویس‌دهی امضا شده، به فعال‌سازی گواهی‌های سرویس‌دهی امضا شده kubelet مراجعه کنید.

همچنین به نحوه اجرای امن سرور metrics مراجعه کنید.

به دلیل تغییر نکردن هش etcd، ارتقا با شکست مواجه می‌شود

فقط برای ارتقاء یک گره control plane با فایل باینری kubeadm نسخه ۱.۲۸.۳ یا بالاتر، که در حال حاضر توسط نسخه‌های kubeadm نسخه‌های ۱.۲۸.۰، ۱.۲۸.۱ یا ۱.۲۸.۲ مدیریت می‌شود، قابل اجرا است.

در اینجا پیام خطایی که ممکن است با آن مواجه شوید آمده است:

[upgrade/etcd] Failed to upgrade etcd: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
[upgrade/etcd] Waiting for previous etcd to become available
I0907 10:10:09.109104    3704 etcd.go:588] [etcd] attempting to see if all cluster endpoints ([https://172.17.0.6:2379/ https://172.17.0.4:2379/ https://172.17.0.3:2379/]) are available 1/10
[upgrade/etcd] Etcd was rolled back and is now available
static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.rollbackOldManifests
	cmd/kubeadm/app/phases/upgrade/staticpods.go:525
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.upgradeComponent
	cmd/kubeadm/app/phases/upgrade/staticpods.go:254
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.performEtcdStaticPodUpgrade
	cmd/kubeadm/app/phases/upgrade/staticpods.go:338
...

پیام خطایی که ممکن است با آن مواجه شوید این است: دلیل این خطا این است که نسخه‌های آسیب‌دیده یک فایل تنظیمات etcd با پیش‌فرض‌های ناخواسته در PodSpec تولید می‌کنند. این منجر به ایجاد تفاوت در مقایسه تنظیمات می‌شود و kubeadm انتظار تغییر در هش Pod را دارد، اما kubelet هرگز هش را به‌روزرسانی نمی‌کند.

اگر این مشکل را در کلاستر خود مشاهده کردید، دو راه برای حل آن وجود دارد:

• ارتقاء etcd را می‌توان با استفاده از دستور زیر بین نسخه‌های آسیب‌دیده و نسخه ۱.۲۸.۳ (یا بالاتر) نادیده گرفت:

  kubeadm upgrade {apply|node} [version] --etcd-upgrade=false
  

  این کار در صورتی که نسخه جدید etcd توسط نسخه بعدی وصله v1.28 معرفی شده باشد، توصیه نمی‌شود.

• قبل از ارتقا، تنظیمات مربوط به پاد ثابت etcd را وصله کنید تا ویژگی‌های پیش‌فرض مشکل‌ساز حذف شوند:

  diff --git a/etc/kubernetes/manifests/etcd_defaults.yaml b/etc/kubernetes/manifests/etcd_origin.yaml
  index d807ccbe0aa..46b35f00e15 100644
  --- a/etc/kubernetes/manifests/etcd_defaults.yaml
  +++ b/etc/kubernetes/manifests/etcd_origin.yaml
  @@ -43,7 +43,6 @@ spec:
          scheme: HTTP
        initialDelaySeconds: 10
        periodSeconds: 10
  -      successThreshold: 1
        timeoutSeconds: 15
      name: etcd
      resources:
  @@ -59,26 +58,18 @@ spec:
          scheme: HTTP
        initialDelaySeconds: 10
        periodSeconds: 10
  -      successThreshold: 1
        timeoutSeconds: 15
  -    terminationMessagePath: /dev/termination-log
  -    terminationMessagePolicy: File
      volumeMounts:
      - mountPath: /var/lib/etcd
        name: etcd-data
      - mountPath: /etc/kubernetes/pki/etcd
        name: etcd-certs
  -  dnsPolicy: ClusterFirst
  -  enableServiceLinks: true
    hostNetwork: true
    priority: 2000001000
    priorityClassName: system-node-critical
  -  restartPolicy: Always
  -  schedulerName: default-scheduler
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  -  terminationGracePeriodSeconds: 30
    volumes:
    - hostPath:
        path: /etc/kubernetes/pki/etcd
  

اطلاعات بیشتر در مورد این اشکال را می‌توانید در ردیابی مشکل بیابید.

2.1.3 - راه‌اندازی کلاستر etcd با قابلیت دسترسی بالا با kubeadm

به طور پیش‌فرض، kubeadm یک نمونه etcd محلی را روی هر گره(node) control plane اجرا می‌کند.

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

این وظیفه، فرآیند ایجاد یک کلاستر خارجی etcd با دسترسی بالا از سه عضو را بررسی می‌کند که می‌توانند توسط kubeadm در طول ایجاد کلاستر مورد استفاده قرار گیرند.

پیش از شروع

• سه میزبان که می‌توانند از طریق پورت‌های TCP 2379 و 2380 با یکدیگر ارتباط برقرار کنند. این سند این پورت‌های پیش‌فرض را در نظر گرفته است. با این حال، آنها از طریق فایل پیکربندی kubeadm قابل تنظیم هستند.
• هر میزبان باید systemd و یک پوسته سازگار با bash نصب شده داشته باشد.
• هر میزبان باید یک مجری کانتینر، kubelet و kubeadm نصب شده داشته باشد.
• هر میزبان باید به رجیستری container image کوبرنتیز (registry.k8s.io) دسترسی داشته باشد یا فایل image از etcd مورد نیاز را با استفاده از kubeadm config images list/pull فهرست/دریافت کند. این راهنما نمونه‌های etcd را به عنوان پاد‌های استاتیک که توسط یک kubelet مدیریت می‌شود، تنظیم می‌کند.
• برخی زیرساخت‌ها برای کپی کردن فایل‌ها بین میزبان‌ها. به عنوان مثال ssh و scp می‌توانند این نیاز را برآورده کنند.

راه‌اندازی کلاستر

رویکرد کلی این است که تمام گواهینامه‌ها روی یک گره(node) تولید شوند و فقط فایل‌های لازم بین گره‌های دیگر توزیع شوند.

1. kubelet را طوری پیکربندی کنید که به عنوان مدیر سرویس برای etcd عمل کند.

   توجه:

   شما باید این کار را روی هر میزبانی که etcd باید در آن اجرا شود، انجام دهید.
   از آنجایی که etcd ابتدا ایجاد شده است، شما باید با ایجاد یک فایل واحد جدید که اولویت بالاتری نسبت به فایل واحد kubelet ارائه شده توسط kubeadm دارد، اولویت سرویس را لغو کنید.

   cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf
   # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
   # Replace the value of "containerRuntimeEndpoint" for a different container runtime if needed.
   #
   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   authentication:
     anonymous:
       enabled: false
     webhook:
       enabled: false
   authorization:
     mode: AlwaysAllow
   cgroupDriver: systemd
   address: 127.0.0.1
   containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock
   staticPodPath: /etc/kubernetes/manifests
   EOF
   
   cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
   [Service]
   ExecStart=
   ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf
   Restart=always
   EOF
   
   systemctl daemon-reload
   systemctl restart kubelet
   

   وضعیت kubelet را بررسی کنید تا مطمئن شوید که در حال اجرا است.

   systemctl status kubelet
   

2. ایجاد فایل‌های پیکربندی برای kubeadm.

   با استفاده از اسکریپت زیر، یک فایل پیکربندی kubeadm برای هر میزبانی که قرار است یک عضو etcd روی آن اجرا شود، ایجاد کنید.

   # Update HOST0, HOST1 and HOST2 with the IPs of your hosts
   export HOST0=10.0.0.6
   export HOST1=10.0.0.7
   export HOST2=10.0.0.8
   
   # Update NAME0, NAME1 and NAME2 with the hostnames of your hosts
   export NAME0="infra0"
   export NAME1="infra1"
   export NAME2="infra2"
   
   # Create temp directories to store files that will end up on other hosts
   mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
   
   HOSTS=(${HOST0} ${HOST1} ${HOST2})
   NAMES=(${NAME0} ${NAME1} ${NAME2})
   
   for i in "${!HOSTS[@]}"; do
   HOST=${HOSTS[$i]}
   NAME=${NAMES[$i]}
   cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: InitConfiguration
   nodeRegistration:
       name: ${NAME}
   localAPIEndpoint:
       advertiseAddress: ${HOST}
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: ClusterConfiguration
   etcd:
       local:
           serverCertSANs:
           - "${HOST}"
           peerCertSANs:
           - "${HOST}"
           extraArgs:
           - name: initial-cluster
             value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
           - name: initial-cluster-state
             value: new
           - name: name
             value: ${NAME}
           - name: listen-peer-urls
             value: https://${HOST}:2380
           - name: listen-client-urls
             value: https://${HOST}:2379
           - name: advertise-client-urls
             value: https://${HOST}:2379
           - name: initial-advertise-peer-urls
             value: https://${HOST}:2380
   EOF
   done
   

3. مرجع صدور گواهی را ایجاد کنید.

   اگر از قبل یک CA دارید، تنها کاری که باید انجام دهید کپی کردن فایل‌های crt و key مربوط به CA در /etc/kubernetes/pki/etcd/ca.crt و /etc/kubernetes/pki/etcd/ca.key است. پس از کپی کردن این فایل‌ها، به مرحله بعدی، "ایجاد گواهینامه برای هر عضو" بروید.

   اگر از قبل CA ندارید، این دستور را روی $HOST0 (جایی که فایل‌های پیکربندی kubeadm را ایجاد کرده‌اید) اجرا کنید.

   kubeadm init phase certs etcd-ca
   

   این دو فایل را ایجاد می‌کند:

   • /etc/kubernetes/pki/etcd/ca.crt
   • /etc/kubernetes/pki/etcd/ca.key

4. ایجاد گواهی برای هر عضو

   kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST2}/
   # cleanup non-reusable certificates
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST1}/
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   # No need to move the certs because they are for HOST0
   
   # clean up certs that should not be copied off this host
   find /tmp/${HOST2} -name ca.key -type f -delete
   find /tmp/${HOST1} -name ca.key -type f -delete
   

5. کپی گواهینامه‌ها و پیکربندی‌های kubeadm.

   گواهینامه‌ها ایجاد شده‌اند و اکنون باید به میزبان‌های مربوطه منتقل شوند.

   USER=ubuntu
   HOST=${HOST1}
   scp -r /tmp/${HOST}/* ${USER}@${HOST}:
   ssh ${USER}@${HOST}
   USER@HOST $ sudo -Es
   root@HOST $ chown -R root:root pki
   root@HOST $ mv pki /etc/kubernetes/
   

6. اطمینان حاصل کنید که همه فایل‌های مورد انتظار وجود دارند.

   لیست کامل فایل‌های مورد نیاز در $HOST0 به شرح زیر است:

   /tmp/${HOST0}
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── ca.key
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   روی $HOST1:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   روی $HOST2:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

7. پاد استاتیک را ایجاد کنید.

   حالا که گواهینامه‌ها و پیکربندی‌ها آماده شده‌اند، وقت آن رسیده که تنظیمات را ایجاد کنیم. روی هر میزبان، دستور kubeadm را اجرا کنید تا یک تنظیمات ثابت برای etcd ایجاد شود.

   root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
   root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   

8. اختیاری: سلامت کلاستر را بررسی کنید.

   اگر etcdctl در دسترس نباشد، می‌توانید این ابزار را درون یک container image اجرا کنید. شما می‌توانید این کار را مستقیماً با مجری کانتینر خود با استفاده از ابزاری مانند crictl run انجام دهید و نه از طریق کوبرنتیز.

   ETCDCTL_API=3 etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://${HOST0}:2379 endpoint health
   ...
   https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
   https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
   https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
   

   • مقدار ${HOST0} را برابر با نشانی(آدرس) IP میزبانی که در حال آزمایش آن هستید، قرار دهید.

گام‌های بعدی

زمانی که یک کلاستر etcd با ۳ عضو فعال داشتید، می‌توانید با استفاده از روش etcd خارجی با kubeadm به راه‌اندازی یک control plane با دسترسی‌پذیری بالا ادامه دهید.

2.1.4 - پیکربندی هر kubelet در کلاستر شما با استفاده از kubeadm

چرخه حیات ابزار رابط خط فرمان kubeadm از kubelet که یک سرویس (daemon) است که روی هر گره(node) در کلاستر کوبرنتیز اجرا می‌شود، جدا شده است. ابزار رابط خط فرمان kubeadm هنگام راه‌اندازی یا ارتقاء کوبرنتیز توسط کاربر اجرا می‌شود، در حالی که kubelet همیشه در پس‌زمینه در حال اجرا است.

از آنجایی که kubelet یک سرویس (daemon) است، باید توسط نوعی سیستم init یا مدیر سرویس نگهداری شود. وقتی kubelet با استفاده از DEBها یا RPMها نصب می‌شود، systemd برای مدیریت kubelet پیکربندی می‌شود. می‌توانید به جای آن از یک مدیر سرویس متفاوت استفاده کنید، اما باید آن را به صورت دستی پیکربندی کنید.

برخی از جزئیات پیکربندی kubelet باید در تمام kubelet های موجود در کلاستر یکسان باشد، در حالی که سایر جنبه‌های پیکربندی باید بر اساس هر kubelet تنظیم شوند تا با ویژگی‌های مختلف یک ماشین خاص (مانند سیستم عامل، فضای ذخیره‌سازی و شبکه) سازگار شوند. شما می‌توانید پیکربندی kubelet های خود را به صورت دستی مدیریت کنید، اما kubeadm اکنون یک نوع API از نوع KubeletConfiguration را برای مدیریت پیکربندی‌های kubelet خود به صورت مرکزی ارائه می‌دهد.

الگوهای پیکربندی Kubelet

بخش‌های زیر الگوهایی را برای پیکربندی kubelet شرح می‌دهند که با استفاده از kubeadm ساده شده‌اند، نه اینکه پیکربندی kubelet را برای هر گره(node) به صورت دستی مدیریت کنند.

انتشار پیکربندی سطح کلاستر به هر kubelet

شما می‌توانید مقادیر پیش‌فرض را برای استفاده توسط دستورات kubeadm init و kubeadm join به kubelet ارائه دهید. مثال‌های جالب شامل استفاده از یک مجری کانتینر متفاوت یا تنظیم زیرشبکه پیش‌فرض مورد استفاده توسط سرویس‌ها است.

اگر می‌خواهید سرویس‌های شما از زیرشبکه 10.96.0.0/12 به عنوان پیش‌فرض برای سرویس‌ها استفاده کنند، می‌توانید پارامتر --service-cidr را به kubeadm ارسال کنید:

kubeadm init --service-cidr 10.96.0.0/12

اکنون IPهای مجازی برای سرویس‌ها از این زیرشبکه اختصاص داده می‌شوند. همچنین باید نشانی(آدرس) DNS مورد استفاده توسط kubelet را با استفاده از پرچم --cluster-dns تنظیم کنید. این تنظیم باید برای هر kubelet روی هر مدیر و گره(node) در کلاستر یکسان باشد. kubelet یک شیء API نسخه‌بندی شده و ساختار یافته ارائه می‌دهد که می‌تواند اکثر پارامترها را در kubelet پیکربندی کند و این پیکربندی را به هر kubelet در حال اجرا در کلاستر ارسال کند. این شیء KubeletConfiguration نامیده می‌شود. KubeletConfiguration به کاربر اجازه می‌دهد پرچم‌هایی مانند نشانی‌(آدرس)های IP DNS کلاستر را که به صورت لیستی از مقادیر با کلید camelCased بیان می‌شوند، مشخص کند، که با مثال زیر نشان داده شده است:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10

برای جزئیات بیشتر در مورد KubeletConfiguration، به این بخش نگاهی بیندازید.

ارائه جزئیات پیکربندی مختص به هر نمونه

برخی از میزبان‌ها به دلیل تفاوت در سخت‌افزار، سیستم عامل، شبکه یا سایر پارامترهای خاص میزبان، به پیکربندی‌های خاصی برای kubelet نیاز دارند. لیست زیر چند نمونه را ارائه می‌دهد.

• مسیر فایل DNS resolution، همانطور که توسط پرچم پیکربندی --resolv-conf در kubelet مشخص شده است، ممکن است در بین سیستم عامل‌ها یا بسته به اینکه آیا از systemd-resolved استفاده می‌کنید یا خیر، متفاوت باشد. اگر این مسیر اشتباه باشد، DNS resolution در گره‌ای که kubelet آن به طور نادرست پیکربندی شده است، با شکست مواجه خواهد شد.

• شیء گره(node) API با نام .metadata.name به طور پیش‌فرض روی نام میزبان دستگاه تنظیم شده است، مگر اینکه از یک ارائه‌دهنده ابری استفاده کنید. در صورت نیاز به تعیین نام گره‌ای متفاوت از نام میزبان دستگاه، می‌توانید از پرچم --hostname-override برای لغو رفتار پیش‌فرض استفاده کنید.

• در حال حاضر، kubelet نمی‌تواند به طور خودکار درایور cgroup مورد استفاده توسط مجری کانتینر را تشخیص دهد، اما مقدار --cgroup-driver باید با درایور cgroup مورد استفاده توسط مجری کانتینر مطابقت داشته باشد تا سلامت kubelet تضمین شود.

• برای مشخص کردن مجری کانتینر، باید نقطه پایانی آن را با پرچم --container-runtime-endpoint=<path> تنظیم کنید.

روش توصیه‌شده برای اعمال چنین پیکربندی مختص به نمونه، استفاده از KubeletConfiguration patches است.

پیکربندی kubelets با استفاده از kubeadm

می‌توان kubelet را طوری پیکربندی کرد که kubeadm آن را اجرا کند اگر یک شیء API سفارشی KubeletConfiguration با یک فایل پیکربندی مانند kubeadm ... --config some-config-file.yaml ارسال شود.

با فراخوانی kubeadm config print init-defaults --component-configs KubeletConfiguration می‌توانید تمام مقادیر پیش‌فرض این ساختار را مشاهده کنید.

همچنین می‌توان وصله‌های مخصوص هر نمونه را روی «KubeletConfiguration» پایه اعمال کرد. برای جزئیات بیشتر، نگاهی به سفارشی‌سازی kubelet بیندازید.

گردش کار هنگام استفاده از kubeadm init

وقتی kubeadm init را فراخوانی می‌کنید، پیکربندی kubelet در مسیر /var/lib/kubelet/config.yaml روی دیسک ذخیره می‌شود و همچنین در یک نقشه پیکربندی kubelet-config در فضای نام kube-system کلاستر آپلود می‌شود. یک فایل پیکربندی kubelet همچنین در مسیر /etc/kubernetes/kubelet.conf با پیکربندی پایه در سطح کلاستر برای همه kubelet های کلاستر نوشته می‌شود. این فایل پیکربندی به گواهی‌های کلاینت اشاره می‌کند که به kubelet اجازه می‌دهد با سرور API ارتباط برقرار کند. این امر نیاز به انتشار پیکربندی سطح کلاستر به هر kubelet را برطرف می‌کند.

برای پرداختن به الگوی دومِ ارائه جزئیات پیکربندی مختص به نمونه، kubeadm یک فایل محیطی را در /var/lib/kubelet/kubeadm-flags.env می‌نویسد که شامل فهرستی از پرچم‌هایی است که باید هنگام شروع به kubelet منتقل شوند. پرچم‌ها در فایل به این شکل ارائه می‌شوند:

KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."

علاوه بر پرچم‌های مورد استفاده هنگام شروع kubelet، این فایل همچنین شامل پارامترهای پویا مانند درایور cgroup و اینکه آیا از یک سوکت مجری کانتینر متفاوت (--cri-socket) استفاده شود یا خیر، می‌باشد.

پس از مرتب‌سازی این دو فایل روی دیسک، kubeadm تلاش می‌کند دو دستور زیر را اجرا کند، البته اگر از systemd استفاده می‌کنید:

systemctl daemon-reload && systemctl restart kubelet

اگر بارگذاری مجدد و راه‌اندازی مجدد موفقیت‌آمیز باشد، گردش کار عادی kubeadm init ادامه می‌یابد.

گردش کار هنگام استفاده از kubeadm join

وقتی kubeadm join را اجرا می‌کنید، kubeadm از اعتبارنامه‌ی Bootstrap Token برای انجام یک راه انداز TLS استفاده می‌کند که اعتبارنامه‌ی مورد نیاز برای دانلود نقشه‌ی پیکربندی kubelet-config را دریافت کرده و آن را در /var/lib/kubelet/config.yaml می‌نویسد. فایل محیط پویا دقیقاً به همان روشی که kubeadm init تولید می‌شود، تولید می‌شود.

در مرحله بعد، kubeadm دو دستور زیر را برای بارگذاری پیکربندی جدید در kubelet اجرا می‌کند:

systemctl daemon-reload && systemctl restart kubelet

پس از اینکه kubelet پیکربندی جدید را بارگذاری کرد، kubeadm فایل KubeConfig را می‌نویسد که شامل یک گواهی CA و راه انداز Token است. این فایل‌ها توسط kubelet برای انجام TLS راه انداز و دریافت یک اعتبارنامه منحصر به فرد استفاده می‌شوند که در /etc/kubernetes/kubelet.conf ذخیره می‌شود.

وقتی فایل /etc/kubernetes/kubelet.conf نوشته می‌شود، kubelet اجرای TLS راه انداز را به پایان رسانده است. Kubeadm پس از تکمیل TLS راه انداز ، فایل /etc/kubernetes/bootstrap-kubelet.conf را حذف می‌کند.

فایل نصبی kubelet برای systemd

kubeadm به همراه پیکربندی نحوه‌ی اجرای kubelet توسط systemd ارائه می‌شود. توجه داشته باشید که دستور kubeadm CLI هرگز به این فایل drop-in دست نمی‌زند.

این فایل پیکربندی که توسط بسته kubeadm نصب شده است، در مسیر /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf نوشته شده و توسط systemd استفاده می‌شود. این فایل، بسته اصلی kubelet.service را تکمیل می‌کند.

اگر می‌خواهید این مورد را بیشتر تغییر دهید، می‌توانید یک پوشه به نشانی(آدرس) /etc/systemd/system/kubelet.service.d/ (نه /usr/lib/systemd/system/kubelet.service.d/) ایجاد کنید و تنظیمات شخصی‌سازی خود را در یک فایل در آنجا قرار دهید. برای مثال، می‌توانید یک فایل محلی جدید به نشانی(آدرس) /etc/systemd/system/kubelet.service.d/local-overrides.conf اضافه کنید تا تنظیمات واحد پیکربندی شده توسط kubeadm را تغییر دهید.

این چیزی است که احتمالاً در /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf خواهید یافت:

[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
# the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

این فایل مکان‌های پیش‌فرض برای تمام فایل ‌های مدیریت‌شده توسط kubeadm در kubelet را مشخص می‌کند.

• فایل KubeConfig مورد استفاده برای TLS راه انداز، فایل /etc/kubernetes/bootstrap-kubelet.conf است، اما فقط در صورتی استفاده می‌شود که /etc/kubernetes/kubelet.conf وجود نداشته باشد.
• فایل KubeConfig با هویت منحصر به فرد kubelet در مسیر /etc/kubernetes/kubelet.conf قرار دارد.
• فایل حاوی ComponentConfig مربوط به kubelet در مسیر /var/lib/kubelet/config.yaml قرار دارد.
• فایل محیط پویا که شامل KUBELET_KUBEADM_ARGS است، از /var/lib/kubelet/kubeadm-flags.env گرفته شده است.
• فایل ای که می‌تواند شامل لغو پرچم‌های مشخص‌شده توسط کاربر با KUBELET_EXTRA_ARGS باشد، از /etc/default/kubelet (برای DEBها) یا /etc/sysconfig/kubelet (برای RPMها) گرفته شده است. KUBELET_EXTRA_ARGS

آخرین فایل در زنجیره پرچم‌ها است و در صورت وجود تنظیمات متناقض، بالاترین اولویت را دارد.

فایل های باینری و محتویات بسته‌های کوبرنتیز

بسته‌های DEB و RPM که با نسخه‌های کوبرنتیز ارائه می‌شوند عبارتند از: