شروع کنید

• 1: ملاحظات مربوط به کلاستر‌های بزرگ
• 2: نصب kubeadm
• 3: عیب‌یابی kubeadm
• 4: اعتبارسنجی تنظیمات گره(Node)
• 5: اجرای استانداردهای امنیتی pod
• 6: راه‌اندازی خوشه etcd با قابلیت دسترسی بالا با kubeadm
• 7: پیکربندی هر kubelet در خوشه(cluster) شما با استفاده از kubeadm

1 - ملاحظات مربوط به کلاستر‌های بزرگ

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

کوبرنتیز v1.33 از کلاستر‌هایی با حداکثر ۵,۰۰۰ گره(Node) پشتیبانی می‌کند. به طور خاص‌تر، کوبرنتیز به گونه‌ای طراحی شده است که پیکربندی‌هایی را که همه معیارهای زیر را برآورده می‌کنند، در خود جای دهد:

• حداکثر ۱۱۰ پاد در هر گره
• حداکثر ۵,۰۰۰ گره
• حداکثر ۱۵۰,۰۰۰ پاد در کل
• حداکثر ۳۰۰,۰۰۰ کانتینر در کل

شما می‌توانید با اضافه کردن یا حذف گره‌ها، کلاستر خود را مقیاس‌بندی کنید. روش انجام این کار به نحوه‌ی استقرار کلاستر شما بستگی دارد.

سهمیه منابع ارائه دهنده ابر

برای جلوگیری از مواجهه با مشکلات سهمیه ارائه دهنده ابر، هنگام ایجاد یک کلاستر با گره‌های زیاد، موارد زیر را در نظر بگیرید:

• درخواست افزایش سهمیه برای منابع ابری مانند:
  • نمونه‌های رایانه‌ای
  • پردازنده‌ها
  • حجم‌های ذخیره‌سازی
  • آدرس‌های IP در حال استفاده
  • مجموعه قوانین فیلتر بسته
  • تعداد متعادل‌کننده‌های بار
  • زیرشبکه‌های شبکه
  • جریان‌های گزارش
• محدود کردن اقدامات مقیاس‌بندی کلاستر برای ایجاد گره‌های جدید در دسته‌ها، با یک مکث بین دسته‌ها، زیرا برخی از ارائه دهندگان ابر، ایجاد نمونه‌های جدید را محدود می‌کنند.

اجزای Control plane

برای یک کلاستر بزرگ، به یک control plane با منابع محاسباتی و سایر منابع کافی نیاز دارید.

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

شما باید حداقل یک نمونه را در هر منطقه خرابی اجرا کنید تا تحمل خطا فراهم شود. گره‌های Kubernetes به طور خودکار ترافیک را به سمت نقاط انتهایی control plane که در همان منطقه خرابی هستند هدایت نمی‌کنند. با این حال، ارائه دهنده ابر شما ممکن است مکانیسم‌های خاص خود را برای انجام این کار داشته باشد.

به عنوان مثال، با استفاده از یک متعادل کننده بار مدیریت شده، متعادل کننده بار را طوری پیکربندی می‌کنید که ترافیکی را که از kubelet و Pods در منطقه خرابی A سرچشمه می‌گیرد، ارسال کند و آن ترافیک را فقط به میزبان‌های control plane که در منطقه A نیز هستند، هدایت کند. اگر یک میزبان control plane یا منطقه خرابی نقطه انتهایی A آفلاین شود، به این معنی است که تمام ترافیک control plane برای گره‌های موجود در منطقه A اکنون بین مناطق ارسال می‌شود. اجرای چندین میزبان control plane در هر منطقه، احتمال وقوع چنین نتیجه‌ای را کاهش می‌دهد.

مخزن etcd

برای بهبود عملکرد کلاستر‌های بزرگ، می‌توانید اشیاء رویداد را در یک نمونه etcd اختصاصی جداگانه ذخیره کنید.

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

• شروع و پیکربندی نمونه etcd اضافی
• پیکربندی API server برای استفاده از آن برای ذخیره رویدادها

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

منابع افزونه

کوبرنتیز محدودیت منابع به حداقل رساندن تأثیر نشت حافظه و سایر روش‌هایی که podها و containerها می‌توانند بر سایر اجزا تأثیر بگذارند، کمک می‌کند. این محدودیت‌های منابع، همانطور که برای بارهای کاری برنامه اعمال می‌شوند، برای منابع افزونه نیز اعمال می‌شوند.

به عنوان مثال، می‌توانید محدودیت‌های CPU و حافظه را برای یک جزء ثبت وقایع تنظیم کنید:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

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

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

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

• بسیاری از افزونه‌ها به صورت افقی مقیاس‌پذیر هستند - شما با اجرای پادهای بیشتر ظرفیت را افزایش می‌دهید - اما با یک کلاستر بسیار بزرگ، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.

مقیاس پذیر خودکار عمودی می‌تواند در حالت recommender اجرا شود تا ارقام پیشنهادی برای درخواست‌ها و محدودیت‌ها را ارائه دهد.

• برخی افزونه‌ها به صورت یک رونوشت در هر گره اجرا می‌شوند که توسط DaemonSet کنترل می‌شوند: به عنوان مثال، یک تجمیع‌کننده لاگ در سطح گره. مشابه مورد افزونه‌های مقیاس‌پذیر افقی، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.

گام‌های بعدی

• VerticalPodAutoscaler یک منبع سفارشی است که می‌توانید در کلاستر خود مستقر کنید تا به شما در مدیریت درخواست‌های منابع و محدودیت‌های podها کمک کند. درباره مقیاس پذیر خودکار عمودی و نحوه استفاده از آن برای مقیاس‌بندی اجزای کلاستر، از جمله افزونه‌های حیاتی کلاستر، بیشتر بدانید.

• درباره مقیاس‌بندی خودکار گره بخوانید

• تغییر اندازه افزونه به شما کمک می‌کند تا با تغییر مقیاس کلاستر، اندازه افزونه‌ها را به طور خودکار تغییر دهید.

2 - نصب kubeadm

این صفحه نحوه نصب جعبه ابزار kubeadm را نشان می‌دهد. برای کسب اطلاعات در مورد نحوه ایجاد یک خوشه(cluster) با 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 برای ایجاد یک خوشه

3 - عیب‌یابی kubeadm

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

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

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

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

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

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

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

با این حال، این مسئله باعث می‌شود که kubeadm join از نسخه ۱.۱۸ نتواند به خوشه(cluster) که توسط 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 فعال در خوشه(cluster) ای که /etc/kubernetes/pki/ca.key دارد، دستور kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf را اجرا کنید. $NODE باید روی نام گره(node) خراب موجود در خوشه(cluster) تنظیم شود. kubelet.conf حاصل را به صورت دستی تغییر دهید تا نام خوشه(cluster) و نقطه پایانی سرور تنظیم شود، یا kubeconfig user --config را به آن بدهید (به ایجاد پرونده‌های kubeconfig برای کاربران اضافی مراجعه کنید). اگر خوشه(cluster) شما 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 ممکن است در یک خوشه(cluster) با عملکرد عادی، خطاهای زیر را نشان دهند:

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» را چاپ می‌کند.

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

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

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

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

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

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

نمی‌توان از سرور متریک به صورت امن در خوشه(cluster) kubeadm استفاده کرد.

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

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

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

برای درک نحوه پیکربندی kubeletها در یک خوشه(cluster) 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 هرگز هش را به‌روزرسانی نمی‌کند.

اگر این مشکل را در خوشه(cluster) خود مشاهده کردید، دو راه برای حل آن وجود دارد:

• ارتقاء 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
  

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

4 - اعتبارسنجی تنظیمات گره(Node)

تست انطباق گره

آزمون انطباق گره یک چارچوب آزمون کانتینری‌شده است که برای یک گره، راستی‌آزمایی سامانه و آزمون کارکرد فراهم می‌کند. این آزمون بررسی می‌کند آیا گره حداقل نیازمندی‌های کوبرنتیز را برآورده می‌کند یا نه؛ گره‌ای که این آزمون را با موفقیت پشت سر بگذارد، صلاحیت پیوستن به یک کلاستر کوبرنتیز را دارد.

پیش‌نیاز گره

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

• زمان‌های اجرای کانتینر سازگار با CRI مانند Docker، containerd و CRI-O
• kubelet

اجرای تست انطباق گره

برای اجرای آزمون انطباق گره، مراحل زیر را انجام دهید:

۱. مقدار گزینه --kubeconfig را برای kubelet تعیین کنید؛ برای مثال: --kubeconfig=/var/lib/kubelet/config.yaml. از آنجا که چارچوب آزمون برای بررسی kubelet یک کنترل‌پلین محلی راه‌اندازی می‌کند، از http://localhost:8080 به‌عنوان نشانی سرور API استفاده کنید. چند پارامتر خط فرمان دیگر برای kubelet وجود دارد که ممکن است بخواهید به کار ببرید:

• --cloud-provider: اگر از --cloud-provider=gce استفاده می‌کنید، این پرچم را برای اجرای آزمون حذف کنید.

۲. آزمون انطباق گره را با فرمان زیر اجرا کنید:

# $CONFIG_DIR is the pod manifest path of your kubelet.
# $LOG_DIR is the test output path.
sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  registry.k8s.io/node-test:0.2

اجرای تست انطباق گره برای سایر معماری‌ها

کوبرنتیز همچنین imageهای داکر تست انطباق گره را برای معماری‌های دیگر ارائه می‌دهد:

اجرای آزمون انتخاب شده

برای اجرای تست‌های خاص، متغیر محیطی FOCUS را با عبارت منظم تست‌هایی که می‌خواهید اجرا کنید، بازنویسی کنید.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Only run MirrorPod test
  registry.k8s.io/node-test:0.2

برای رد کردن تست‌های خاص، متغیر محیطی SKIP را با عبارت منظم تست‌هایی که می‌خواهید رد کنید، بازنویسی کنید.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test
  registry.k8s.io/node-test:0.2

آزمون انطباق گره نسخه کانتینری‌شده آزمون گره e2e است و به‌طور پیش‌فرض همه آزمون‌های انطباق را اجرا می‌کند.

از نظر تئوری، اگر کانتینر را به‌درستی پیکربندی کرده و حجم‌های موردنیاز را مناسب مانت کنید، می‌توانید هر آزمون e2e گره را اجرا کنید. اما به‌شدت توصیه می‌شود فقط آزمون انطباق را اجرا کنید، زیرا اجرای آزمون‌های غیرانطباق به پیکربندی بسیار پیچیده‌تری نیاز دارد.

هشدارها

• آزمون تعدادی image داکر را روی گره باقی می‌گذارد؛ از جمله image آزمون انطباق گره و image کانتینرهایی که در آزمون کارکرد استفاده شدند.
• آزمون چند کانتینر مرده را روی گره باقی می‌گذارد. این کانتینرها در طول آزمون کارکرد ایجاد می‌شوند.

5 - اجرای استانداردهای امنیتی pod

این صفحه مروری بر بهترین شیوه‌ها در مورد اجرای استانداردهای امنیتی پاد ارائه می‌دهد.

استفاده از کنترل‌کننده پذیرش امنیتی داخلی pod

کنترل‌کننده‌ی پذیرش امنیت پاد Pod Security Admission Controller قصد دارد جایگزین سیاست‌های امنیتی منسوخ‌شده‌ی پاد (PodSecurityPolicies) شود.

پیکربندی تمام Namespace های کلاستر

namespace یی که فاقد هرگونه پیکربندی هستند، باید به عنوان شکاف‌های قابل توجه در مدل امنیتی کلاستر شما در نظر گرفته شوند. توصیه می‌کنیم برای تجزیه و تحلیل انواع Workloads موجود در هر namespace، وقت بگذارید و با مراجعه به استانداردهای امنیتی پاد، سطح مناسبی را برای هر یک از آنها تعیین کنید. فضاهای نام بدون برچسب فقط باید نشان دهند که هنوز ارزیابی نشده‌اند.

در سناریویی که همه Workloads در همه namespace ها الزامات امنیتی یکسانی دارند، ما یک مثال ارائه می‌دهیم که نحوه اعمال برچسب‌های PodSecurity را به صورت انبوه نشان می‌دهد.

اصل حداقل امتیاز را بپذیرید

در یک دنیای ایده‌آل، هر پاد در هر فضای نامی الزامات سیاست محدود را برآورده می‌کند. با این حال، این امر نه ممکن است و نه عملی، زیرا برخی از Workloads به دلایل موجه به امتیازات بالاتری نیاز دارند.

• namespace هایی که به Workloads «ممتاز» اجازه می‌دهند، باید کنترل‌های دسترسی مناسبی را ایجاد و اجرا کنند.
• برای Workloads که در آن namespace های مجاز اجرا می‌شوند، مستندات مربوط به الزامات امنیتی منحصر به فرد آنها را نگهداری کنید. در صورت امکان، در نظر بگیرید که چگونه می‌توان این الزامات را بیشتر محدود کرد.

اتخاذ یک استراتژی چند حالته

حالت‌های audit و warn کنترل‌کننده پذیرش استانداردهای امنیتی پاد ، جمع‌آوری بینش‌های امنیتی مهم در مورد پادهای شما را بدون ایجاد اختلال در حجم کار موجود، آسان می‌کند.

فعال کردن این حالت‌ها برای همه namespace ها، و تنظیم آنها روی سطح و نسخه مورد نظر شما که در نهایت می‌خواهید enforce کنید، یک تمرین خوب است. هشدارها و حاشیه‌نویسی‌های حسابرسی ایجاد شده در این مرحله می‌توانند شما را به سمت آن وضعیت هدایت کنند. اگر انتظار دارید نویسندگان بار کاری تغییراتی را برای مطابقت با سطح مورد نظر ایجاد کنند، حالت warn را فعال کنید. اگر انتظار دارید از گزارش‌های حسابرسی برای نظارت/هدایت تغییرات برای مطابقت با سطح مورد نظر استفاده کنید، حالت audit را فعال کنید.

وقتی حالت enforce را روی مقدار دلخواه خود تنظیم کرده‌اید، این حالت‌ها همچنان می‌توانند به چند روش مختلف مفید باشند:

• با تنظیم warn در همان سطح enforce، کلاینت‌ها هنگام تلاش برای ایجاد Podها (یا منابعی که قالب‌های Pod دارند) که اعتبارسنجی را پشت سر نمی‌گذارند، هشدارهایی دریافت می‌کنند. این به آنها کمک می‌کند تا آن منابع را برای مطابقت به‌روزرسانی کنند.
• در namespaceهایی که enforce را به یک نسخه غیرجدید خاص پین می‌کنند، تنظیم حالت‌های audit و warn در همان سطح enforce، اما به نسخه latest، امکان مشاهده تنظیماتی را فراهم می‌کند که در نسخه‌های قبلی مجاز بودند اما طبق بهترین شیوه‌های فعلی مجاز نیستند.

جایگزین‌های شخص ثالث

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

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

تصمیم برای استفاده از یک راهکار داخلی (مثلاً کنترل‌کننده پذیرش PodSecurity) در مقابل یک ابزار شخص ثالث، کاملاً به شرایط شما بستگی دارد. هنگام ارزیابی هر راهکاری، اعتماد به زنجیره تأمین شما بسیار مهم است. در نهایت، استفاده از هر یک از رویکردهای فوق‌الذکر بهتر از انجام ندادن هیچ کاری خواهد بود.

6 - راه‌اندازی خوشه 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 با دسترسی‌پذیری بالا ادامه دهید.

7 - پیکربندی هر kubelet در خوشه(cluster) شما با استفاده از kubeadm

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

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

برخی از جزئیات پیکربندی kubelet باید در تمام kubelet های موجود در خوشه(cluster) یکسان باشد، در حالی که سایر جنبه‌های پیکربندی باید بر اساس هر 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) در خوشه(cluster) یکسان باشد. kubelet یک شیء API نسخه‌بندی شده و ساختار یافته ارائه می‌دهد که می‌تواند اکثر پارامترها را در kubelet پیکربندی کند و این پیکربندی را به هر kubelet در حال اجرا در خوشه(cluster) ارسال کند. این شیء KubeletConfiguration نامیده می‌شود. KubeletConfiguration به کاربر اجازه می‌دهد پرچم‌هایی مانند نشانی‌(آدرس)های IP DNS خوشه(cluster) را که به صورت لیستی از مقادیر با کلید 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 خوشه(cluster) آپلود می‌شود. یک پرونده(فایل) پیکربندی kubelet همچنین در مسیر /etc/kubernetes/kubelet.conf با پیکربندی پایه در سطح خوشه(cluster) برای همه kubelet های خوشه(cluster) نوشته می‌شود. این پرونده(فایل) پیکربندی به گواهی‌های کلاینت اشاره می‌کند که به kubelet اجازه می‌دهد با سرور API ارتباط برقرار کند. این امر نیاز به انتشار پیکربندی سطح خوشه(cluster) به هر 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 که با نسخه‌های کوبرنتیز ارائه می‌شوند عبارتند از: