این حالت نمایش چند صفحه ای قابل پرینت این قسمت می‌باشد. برای پرینت کلیک کنید..

بازگشت به حالت نمایش عادی این قسمت.

مستندات

1 - سلام Minikube

این آموزش به شما نشان می‌دهد چگونه یک برنامه نمونه را روی کوبرنتیز با استفاده از minikube اجرا کنید. این آموزش یک ایمیج کانتینری ارائه می‌دهد که از NGINX برای بازگرداندن تمامی درخواست‌ها استفاده می‌کند.

Objectives

  • استقرار یک برنامه نمونه روی minikube
  • اجرای برنامه
  • مشاهده لاگ‌های برنامه

Before you begin

این آموزش فرض می‌کند که شما قبلا minikube را راه‌اندازی کرده‌اید. برای دستورالعمل نصب، مرحله ۱ در صفحه minikube start را ببینید.

همچنین باید kubectl را نصب کنید. برای دستورالعمل نصب، صفحه Install tools را ببینید.

ساخت یک کلاستر minikube

minikube start

باز کردن داشبورد

داشبورد کوبرنتیز را باز کنید. دو روش برای انجام این کار وجود دارد:

یک ترمینال جدید باز کنید و دستور زیر را اجرا کنید:

# Start a new terminal, and leave this running.
minikube dashboard

اکنون به ترمینالی که minikube start را اجرا کرده بودید برگردید.

اگر نمی‌خواهید minikube مرورگر را باز کند، زیر دستور dashboard از فلگ --url استفاده کنید. minikube یک آدرس URL نمایش می‌دهد که شما می‌توانید در مرورگر دلخواه باز کنید.

یک ترمینال جدید باز کنید و اجرا کنید:

# Start a new terminal, and leave this running.
minikube dashboard --url

حالا می‌توانید از این URL استفاده کنید و به ترمینالی که minikube start را اجرا کرده بودید برگردید.

ساخت Deployment

یک Pod گروهی از یک یا چند کانتینر است که برای مدیریت و شبکه‌سازی به هم مرتبط هستند. پاد این آموزش فقط یک کانتینر دارد. Deployment وضعیت سلامت پاد را بررسی کرده و اگر خراب شود، آن را مجدداً اجرا می‌کند. Deployment روش پیشنهادی برای ساخت و مقیاس‌دهی پادهاست.

  1. ایجاد Deployment:

    # Run a test container image that includes a webserver
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080

  2. مشاهده Deployment:

    kubectl get deployments

    خروجی مشابه موارد زیر است:

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
hello-node   1/1     1            1           1m

    (ممکن است کمی زمان ببرد تا پاد آماده شود. اگر 0/1 دیدید، چند ثانیه بعد دوباره امتحان کنید.)

  3. مشاهده Pod:

    kubectl get pods

    خروجی مشابه موارد زیر است:

    NAME                          READY     STATUS    RESTARTS   AGE
hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m

  4. مشاهده رویدادهای کلاستر:

    kubectl get events

  5. مشاهده کانفیگ kubectl:

    kubectl config view

  6. مشاهده لاگ کانتینر داخل پاد (نام پاد را جایگزین کنید):

    kubectl logs hello-node-5f76cf6ccf-br9b5

    خروجی مشابه موارد زیر است:

    I0911 09:19:26.677397       1 log.go:195] Started HTTP server on port 8080
I0911 09:19:26.677586       1 log.go:195] Started UDP server on port  8081

ساخت Service

به طور پیش‌فرض پاد فقط از داخل شبکه داخلی کوبرنتیز قابل دسترسی است. برای اینکه کانتینر hello-node از بیرون قابل دسترسی باشد، باید آن را به‌عنوان یک Service اکسپوز کنید.

  1. اکسپوز کردن پاد:

    kubectl expose deployment hello-node --type=LoadBalancer --port=8080

  2. مشاهده Service:

    kubectl get services

    خروجی مشابه موارد زیر است:

    NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m

  3. اجرای سرویس:

    minikube service hello-node

    این دستور مرورگر را باز می‌کند و پاسخ برنامه را نمایش می‌دهد.

فعال‌سازی افزونه‌ها

minikube شامل مجموعه‌ای از addons داخلی است.

  1. فهرست افزونه‌ها:

    minikube addons list

    خروجی مشابه موارد زیر است:

     addon-manager: enabled
 dashboard: enabled
 default-storageclass: enabled
 efk: disabled
 freshpod: disabled
 gvisor: disabled
 helm-tiller: disabled
 ingress: disabled
 ingress-dns: disabled
 logviewer: disabled
 metrics-server: disabled
 nvidia-driver-installer: disabled
 nvidia-gpu-device-plugin: disabled
 registry: disabled
 registry-creds: disabled
 storage-provisioner: enabled
 storage-provisioner-gluster: disabled

  2. فعال‌سازی افزونه metrics-server:

    minikube addons enable metrics-server

    خروجی مشابه موارد زیر است:

    The 'metrics-server' addon is enabled

  3. مشاهده پادها و سرویس‌ها:

    kubectl get pod,svc -n kube-system

    خروجی مشابه موارد زیر است:

    NAME                                        READY     STATUS    RESTARTS   AGE
pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
pod/metrics-server-67fb648c5                1/1       Running   0          26s
pod/etcd-minikube                           1/1       Running   0          34m
pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
pod/kube-addon-manager-minikube             1/1       Running   0          34m
pod/kube-apiserver-minikube                 1/1       Running   0          34m
pod/kube-controller-manager-minikube        1/1       Running   0          34m
pod/kube-proxy-rnlps                        1/1       Running   0          34m
pod/kube-scheduler-minikube                 1/1       Running   0          34m
pod/storage-provisioner                     1/1       Running   0          34m

NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s

  4. بررسی خروجی metrics:

    kubectl top pods

    اگر دیدید:

    error: Metrics API not available

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

  5. غیرفعال کردن افزونه:

    minikube addons disable metrics-server

پاکسازی

اکنون می‌توانید منابعی را که در کلاستر خود ایجاد کرده‌اید، پاک کنید:

kubectl delete service hello-node
kubectl delete deployment hello-node

توقف کلاستر minikube:

minikube stop

در صورت تمایل، ماشین مجازی Minikube را حذف کنید:

# Optional
minikube delete

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

نتیجه‌گیری

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

What's next

  • آموزش استقرار اولین برنامه روی کوبرنتیز با kubectl
  • یادگیری بیشتر درباره Deployment
  • یادگیری بیشتر درباره اجرای برنامه‌ها
  • یادگیری بیشتر درباره Service

2 - مستندات کوبرنتیز

کوبرنتیز یک موتور orchestration کانتینر متن‌باز برای خودکارسازی استقرار، مقیاس‌پذیری و مدیریت برنامه‌های کانتینری است. این پروژه متن‌باز توسط Cloud Native Computing Foundation میزبانی می‌شود.

2.1 - مستندات نسخه‌های موجود

این وبگاه(website) شامل مستندات نسخه فعلی کوبرنتیز و چهار نسخه قبلی آن است.

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

3 - شروع کنید

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

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

چندین مؤلفه کوبرنتیز مانند kube-apiserver یا kube-proxy نیز می‌توانند به‌صورت ایمیج کانتینر در داخل خوشه مستقر شوند.

توصیه می‌شود هرجا امکان‌پذیر است، مؤلفه‌های کوبرنتیز را به‌شکل ایمیج‌های کانتینری اجرا کرده و مدیریت آن‌ها را به خود کوبرنتیز بسپارید.
مؤلفه‌هایی که کانتینرها را اجرا می‌کنند—به‌ویژه kubelet—در این دسته قرار نمی‌گیرند.

اگر نمی‌خواهید خودتان یک خوشه کوبرنتیز را مدیریت کنید، می‌توانید یک سرویس مدیریت‌شده، از جمله بسترهای تأییدشده را انتخاب کنید.
همچنین راهکارهای استاندارد و سفارشی دیگری در طیف گسترده‌ای از محیط‌های ابری و سرورهای فیزیکی (bare metal) وجود دارد.

محیط یادگیری

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

محیط عملیاتی

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

برای خوشه‌ای که خودتان مدیریت می‌کنید، ابزار رسمیِ پشتیبانی‌شده برای استقرار کوبرنتیز، kubeadm است.

What's next

کوبرنتیز طوری طراحی شده است که Control Plane آن روی لینوکس اجرا شود. درون خوشه خود می‌توانید برنامه‌ها را روی لینوکس یا سیستم عامل های دیگر، از جمله ویندوز، اجرا کنید.

3.1 - نصب kubeadm

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

This راهنمای نصب is for Kubernetes v1.33. If you want to use a different Kubernetes version, please refer to the following pages instead:

Before you begin

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

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

  • پروژه kubeadm از هسته‌های LTS پشتیبانی می‌کند. برای مشاهده به لیست هسته‌(kernel)های LTS مراجعه کنید.
  • شما می‌توانید با استفاده از دستور uname -r نسخه هسته(kernel) را دریافت کنید.

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

  • پروژه kubeadm از نسخه‌های اخیر هسته(kernel) پشتیبانی می‌کند. برای مشاهده فهرستی از هسته(kernel) های اخیر، به اطلاعات انتشار ویندوز سرور مراجعه کنید.
  • شما می‌توانید نسخه هسته(kernel) (که به آن نسخه سیستم عامل نیز گفته می‌شود) را با استفاده از دستور systeminfo مشاهده کنید.

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

یک خوشه کوبرنتیز که توسط 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 container runtimes
Runtime Path to Unix domain socket
containerd unix:///var/run/containerd/containerd.sock
CRI-O unix:///var/run/crio/crio.sock
Docker Engine (using cri-dockerd) unix:///var/run/cri-dockerd.sock

Windows container runtimes
Runtime Path to Windows named pipe
containerd npipe:////./pipe/containerd-containerd
Docker Engine (using cri-dockerd) npipe:////./pipe/cri-dockerd

نصب kubeadm، kubelet و kubectl

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

  • kubeadm: دستور راه اندازی خوشه.

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

  • kubectl: ابزار خط فرمان برای ارتباط با خوشه شما.

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

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

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

این دستورالعمل‌ها برای کوبرنتیز v1.33 هستند.

  1. فهرست بسته‌های apt را به‌روزرسانی کنید و بسته‌های مورد نیاز برای استفاده از مخزن کوبرنتیز apt را نصب کنید:

    sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

  2. کلید امضای عمومی مخازن بسته کوبرنتیز را دانلود کنید. کلید امضای یکسانی برای همه مخازن استفاده می‌شود، بنابراین می‌توانید نسخه موجود در URL را نادیده بگیرید:

    # اگر پوشه(folder) `/etc/apt/keyrings` وجود ندارد، باید قبل از دستور curl ایجاد شود، نکته زیر را بخوانید.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

  1. مخزن کوبرنتیز apt مناسب را اضافه کنید. لطفاً توجه داشته باشید که این مخزن فقط بسته‌هایی برای کوبرنتیز 1.33 دارد؛ برای سایر نسخه‌های فرعی کوبرنتیز، باید نسخه فرعی کوبرنتیز را در URL تغییر دهید تا با نسخه فرعی مورد نظر شما مطابقت داشته باشد. (همچنین باید بررسی کنید که مستندات مربوط به نسخه کوبرنتیز که قصد نصب آن را دارید، مطالعه می‌کنید.)

    # This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

  2. فهرست بسته‌های apt را به‌روزرسانی کنید، kubelet، kubeadm و kubectl را نصب کنید و نسخه آنها را پین کنید:

    sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

  3. (اختیاری) سرویس kubelet را قبل از اجرای kubeadm فعال کنید:

    sudo systemctl enable --now kubelet

  1. SELinux را روی حالت «مجاز» تنظیم کنید:

    این دستورالعمل‌ها برای کوبرنتیز 1.33 هستند.

    # Set SELinux in permissive mode (effectively disabling it)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

  1. مخزن کوبرنتیز yum را اضافه کنید. پارامتر exclude در تعریف مخزن تضمین می‌کند که بسته‌های مربوط به کوبرنتیز با اجرای yum update ارتقا پیدا نکنند، زیرا برای ارتقاء کوبرنتیز باید رویه خاصی دنبال شود. لطفاً توجه داشته باشید که این مخزن فقط بسته‌هایی برای کوبرنتیز دارد 1.33؛ برای سایر نسخه‌های فرعی کوبرنتیز، باید نسخه فرعی کوبرنتیز را در URL تغییر دهید تا با نسخه فرعی مورد نظر شما مطابقت داشته باشد (همچنین باید بررسی کنید که مستندات مربوط به نسخه کوبرنتیز که قصد نصب آن را دارید، مطالعه می‌کنید).

    # This overwrites any existing configuration in /etc/yum.repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.33/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.33/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF

  2. kubelet، kubeadm و kubectl را نصب کنید:

    sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

  3. (اختیاری) سرویس kubelet را قبل از اجرای kubeadm فعال کنید:

    sudo systemctl enable --now kubelet

افزونه‌های CNI را نصب کنید (برای اکثر شبکه‌های پاد مورد نیاز است):

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

پوشه را برای دانلود پرونده‌‌های دستور(command) ایجاد کنید:

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

در صورت تمایل، crictl را نصب کنید (برای تعامل با رابط مجری کانتینر (CRI) مورد نیاز است، و برای kubeadm اختیاری است):

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

kubeadm، kubelet را نصب کنید و یک سرویس systemd kubelet اضافه کنید:

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

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

در صورت تمایل، قبل از اجرای kubeadm، سرویس kubelet را فعال کنید:

sudo systemctl enable --now kubelet

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

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

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

عیب‌یابی

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

What's next

3.2 - عیب‌یابی kubeadm

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

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

  • اگر فکر می‌کنید مشکل شما یک باگ در 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 شروع به کار نمی‌کنند. برای حل این مشکل، می‌توانید یکی از گزینه‌های زیر را امتحان کنید:

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

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

3.3 - راه‌اندازی خوشه etcd با قابلیت دسترسی بالا با kubeadm

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

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

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

Before you begin

  • سه میزبان که می‌توانند از طریق پورت‌های 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 ابتدا ایجاد شده است، شما باید با ایجاد یک پرونده واحد جدید که اولویت بالاتری نسبت به پرونده واحد 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 میزبانی که در حال آزمایش آن هستید، قرار دهید.

What's next

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

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

FEATURE STATE: Kubernetes v1.11 [stable]

چرخه حیات ابزار رابط خط فرمان 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 که با نسخه‌های کوبرنتیز ارائه می‌شوند عبارتند از:

Package name Description
kubeadm ابزار خط فرمان /usr/bin/kubeadm و پرونده نصبی kubelet را برای kubelet نصب می‌کند.
kubelet (باینری)پرونده(فایل) دودویی /usr/bin/kubelet را نصب می‌کند.
kubectl (باینری)پرونده(فایل) دودویی /usr/bin/kubectl را نصب می‌کند.
cri-tools (باینری)پرونده(فایل) دودویی /usr/bin/crictl را از مخزن گیت cri-tools نصب می‌کند.
kubernetes-cni (باینری)پرونده‌(فایل)های دودویی /opt/cni/bin را از مخزن plugins git نصب می‌کند.

4 - (cluster)مدیریت خوشه

4.1 - اجرای kubelet در حالت مستقل

این آموزش به شما نشان می‌دهد که چگونه یک نمونه مستقل از kubelet را اجرا کنید

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

پس از دنبال کردن این آموزش، می‌توانید از خوشه ای که دارای control plane برای مدیریت پادها و گره‌ها و انواع دیگر اشیاء است، استفاده کنید. به عنوان مثال، Hello, minikube

همچنین می‌توانید kubelet را در حالت مستقل اجرا کنید تا برای موارد استفاده در محیط عملیاتی مناسب باشد، مانند اجرای control plane برای یک خوشه (cluster) با قابلیت دسترسی بالا و استقرار انعطاف‌پذیر. این آموزش جزئیات مورد نیاز برای اجرای یک control plane انعطاف‌پذیر را پوشش نمی‌دهد

Objectives

  • cri-o و kubelet را روی یک سیستم لینوکس نصب کنید و آنها را به عنوان سرویس‌های systemd اجرا کنید.
  • یک پاد (Pod) با اجرای nginx راه‌اندازی کنید که به درخواست‌های روی پورت TCP 80 روی نشانی IP پاد گوش دهد.
  • یاد بگیرید که چگونه اجزای مختلف راه‌حل با یکدیگر تعامل دارند.

Before you begin

  • دسترسی ادمین (root) به یک سیستم لینوکس که از systemd و iptables (یا nftables با شبیه‌سازی iptables) استفاده می‌کند
  • دسترسی به اینترنت برای دانلود اجزای مورد نیاز برای آموزش، مانند: دسترسی به اینترنت برای دانلود اجزای مورد نیاز برای آموزش، مانند:

سیستم را آماده کنید

پیکربندی Swap

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

اگر حافظه swap را فعال کرده‌اید، آن را غیرفعال کنید یا عبارت failSwapOn: false را به پرونده پیکربندی kubelet اضافه کنید برای بررسی فعال بودن swap:

sudo swapon --show

اگر هیچ خروجی از دستور وجود نداشته باشد، حافظه swap از قبل غیرفعال شده است

برای غیرفعال کردن موقت swap:

sudo swapoff -a

برای اینکه این تغییر در طول راه‌اندازی‌های مجدد پایدار بماند:

مطمئن شوید که swap بسته به نحوه پیکربندی آن در سیستم شما، در /etc/fstab یا systemd.swap غیرفعال باشد

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

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

cat /proc/sys/net/ipv4/ip_forward

اگر خروجی «۱» باشد، از قبل فعال شده است. اگر خروجی «۰» باشد، مراحل بعدی را دنبال کنید

برای فعال کردن ارسال بسته IPv4، یک پرونده پیکربندی ایجاد کنید که پارامتر net.ipv4.ip_forward را روی 1 تنظیم کند:

sudo tee /etc/sysctl.d/k8s.conf <<EOF
net.ipv4.ip_forward = 1
EOF

اعمال تغییرات در سیستم:

sudo sysctl --system

خروجی مشابه این است:

...
* Applying /etc/sysctl.d/k8s.conf ...
net.ipv4.ip_forward = 1
* Applying /etc/sysctl.conf ...

دانلود، نصب و پیکربندی مولفه ها

یک مجری کانتینر اجرا نصب کنید

آخرین نسخه‌های موجود از بسته‌های مورد نیاز را دانلود کنید (توصیه می‌شود).

این آموزش نصب CRI-O container runtime (لینک خارجی) را پیشنهاد می‌کند

بسته به توزیع لینوکس خاص شما، چندین [روش] برای نصب [https://github.com/cri o/cri o/blob/main/install.md] کانتینر CRI O در زمان اجرا وجود دارد. اگرچه CRI O استفاده از بسته‌های deb یا rpm را توصیه می‌کند، اما این آموزش از اسکریپت _static binary bundle_ پروژه CRI O Packaging (https://github.com/crio/packaging/blob/main/README.md) استفاده می‌کند، که هم برای ساده‌سازی فرآیند کلی و هم برای عدم وابستگی به توزیع مورد نظر است

این اسکریپت نرم‌افزارهای مورد نیاز اضافی، مانند cni-plugins برای شبکه‌سازی کانتینر، و crun و runc برای اجرای کانتینرها را نصب و پیکربندی می‌کند

این اسکریپت به طور خودکار معماری پردازنده سیستم شما (amd64 یا arm64) را تشخیص داده و آخرین نسخه‌های بسته‌های نرم‌افزاری را انتخاب و نصب می‌کند

CRI-O تنظیم

از صفحه نسخه‌ها (پیوند خارجی) دیدن کنید

اسکریپت بسته دودویی استاتیک را دانلود کنید:

curl https://raw.githubusercontent.com/cri-o/packaging/main/get > crio-install

اسکریپت نصب را اجرا کنید:

sudo bash crio-install

فعال کردن و شروع سرویس crio:

sudo systemctl daemon-reload
sudo systemctl enable --now crio.service

تست سریع:

sudo systemctl is-active crio.service

خروجی مشابه این است:

active

بررسی دقیق سرویس:

sudo journalctl -f -u crio.service

نصب افزونه های شبکه

نصب‌کننده‌ی cri-o بسته‌ی cni-plugins را نصب و پیکربندی می‌کند. می‌توانید با اجرای دستور زیر، نصب را تأیید کنید:

/opt/cni/bin/bridge --version

خروجی مشابه این است:

CNI bridge plugin v1.5.1
CNI protocol versions supported: 0.1.0, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 1.0.0

برای بررسی پیکربندی پیش‌فرض:

cat /etc/cni/net.d/11-crio-ipv4-bridge.conflist

خروجی مشابه این است:

{
  "cniVersion": "1.0.0",
  "name": "crio",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipMasq": true,
      "hairpinMode": true,
      "ipam": {
        "type": "host-local",
        "routes": [
            { "dst": "0.0.0.0/0" }
        ],
        "ranges": [
            [{ "subnet": "10.85.0.0/16" }]
        ]
      }
    }
  ]
}

دانلود و نصب kubelet

آخرین نسخه پایدار آخرین نسخه از kubelet را دریافت کنید


curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubelet"



curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubelet"

پیکربندی:

sudo mkdir -p /etc/kubernetes/manifests

sudo tee /etc/kubernetes/kubelet.yaml <<EOF
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  webhook:
    enabled: false # Do NOT use in production clusters!
authorization:
  mode: AlwaysAllow # Do NOT use in production clusters!
enableServer: false
logging:
  format: text
address: 127.0.0.1 # Restrict access to localhost
readOnlyPort: 10255 # Do NOT use in production clusters!
staticPodPath: /etc/kubernetes/manifests
containerRuntimeEndpoint: unix:///var/run/crio/crio.sock
EOF

نصب:

chmod +x kubelet
sudo cp kubelet /usr/bin/

یک پرونده واحد سرویس systemd ایجاد کنید:

sudo tee /etc/systemd/system/kubelet.service <<EOF
[Unit]
Description=Kubelet

[Service]
ExecStart=/usr/bin/kubelet \
 --config=/etc/kubernetes/kubelet.yaml
Restart=always

[Install]
WantedBy=multi-user.target
EOF

پارامتر خط فرمان --kubeconfig عمداً در پرونده پیکربندی سرویس حذف شده است. این پارامتر مسیر پرونده [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) را تعیین می‌کند که نحوه اتصال به سرور API را مشخص می‌کند و حالت سرور API را فعال می‌کند. حذف آن، حالت مستقل را فعال می‌کند.

سرویس kubelet را فعال و شروع کنید:

sudo systemctl daemon-reload
sudo systemctl enable --now kubelet.service

آزمایش سریع:

sudo systemctl is-active kubelet.service

خروجی مشابه زیر است:

active

بررسی دقیق سرویس:

sudo journalctl -u kubelet.service

نقطه پایانی API /healthz مربوط به kubelet را بررسی کنید:

curl http://localhost:10255/healthz?verbose

خروجی مشابه زیر است:

[+]ping ok
[+]log ok
[+]syncloop ok
healthz check passed

از نقطه پایانی API /pods مربوط به kubelet کوئری بگیرید:

curl http://localhost:10255/pods | jq '.'

خروجی مشابه زیر است:

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {},
  "items": null
}

یک پاد را در kubelet اجرا کنید

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

ایجاد یک تنظیمات برای یک Pod:

cat <<EOF > static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
EOF

پرونده تنظیمات static-web.yaml را در پوشه /etc/kubernetes/manifests رونوشت کنید.

sudo cp static-web.yaml /etc/kubernetes/manifests/

اطلاعاتی در مورد کوبلت و پاد پیدا کنید

افزونه شبکه Pod یک پل شبکه (cni0) و یک جفت رابط veth برای هر Pod ایجاد می‌کند (یکی از این جفت‌ها درون Pod تازه ساخته شده و دیگری در سطح میزبان است).

نقطه پایانی API مربوط به kubelet را در نشانی http://localhost:10255/pods جستجو کنید:

curl http://localhost:10255/pods | jq '.'

برای به دست آوردن نشانی IP مربوط به پاد static-web:

curl http://localhost:10255/pods | jq '.items[].status.podIP'

خروجی مشابه زیر است:

"10.85.0.4"

به پاد سرور nginx روی http://<IP>:<Port> (پورت پیش‌فرض ۸۰ است) متصل شوید، در این مورد:

curl http://10.85.0.4

خروجی مشابه زیر است:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

جزئیات بیشتر را کجا جستجو کنیم

اگر نیاز به تشخیص مشکلی در اجرای این آموزش دارید، می‌توانید برای نظارت و عیب‌یابی به پوشه‌های زیر مراجعه کنید:

/var/lib/cni
/var/lib/containers
/var/lib/kubelet

/var/log/containers
/var/log/pods

پاک کردن

kubelet

sudo systemctl disable --now kubelet.service
sudo systemctl daemon-reload
sudo rm /etc/systemd/system/kubelet.service
sudo rm /usr/bin/kubelet
sudo rm -rf /etc/kubernetes
sudo rm -rf /var/lib/kubelet
sudo rm -rf /var/log/containers
sudo rm -rf /var/log/pods

مجری کانتینر

sudo systemctl disable --now crio.service
sudo systemctl daemon-reload
sudo rm -rf /usr/local/bin
sudo rm -rf /usr/local/lib
sudo rm -rf /usr/local/share
sudo rm -rf /usr/libexec/crio
sudo rm -rf /etc/crio
sudo rm -rf /etc/containers

افزونه های شبکه

sudo rm -rf /opt/cni
sudo rm -rf /etc/cni
sudo rm -rf /var/lib/cni

نتیجه‌گیری

این صفحه جنبه‌های اساسی استقرار یک kubelet در حالت مستقل را پوشش داد. اکنون آماده استقرار پادها و آزمایش قابلیت‌های اضافی هستید.

توجه داشته باشید که در حالت مستقل، kubelet از دریافت پیکربندی‌های پاد از control plane پشتیبانی نمی‌کند (زیرا هیچ اتصالی به control plane وجود ندارد).

همچنین نمی‌توانید از ConfigMap یا Secret برای پیکربندی کانتینرها در یک پاد استاتیک استفاده کنید.

What's next

4.2 - راهنمای فضاهای نام

کوبرنتیز فضاهای نام به پروژه‌ها، تیم‌ها یا مشتریان مختلف کمک کنید تا خوشه (cluster) کوبرنتیز را به اشتراک بگذارند.

این کار را با ارائه موارد زیر انجام می‌دهد:

  1. یک محدوده برای نام‌ها.
  2. (cluster)سازوکاری برای ضمیمه کردن مجوز و سیاست به یک زیربخش از خوشه.

استفاده از چندین فضای نام اختیاری است.

این مثال نحوه استفاده از فضاهای نام کوبرنتیز برای تقسیم‌بندی خوشه (cluster) شما را نشان می‌دهد.

Before you begin

شما باید یک خوشه(Cluster) کوبرنتیز داشته باشید و ابزار خطِّ فرمان kubectl نیز برای برقراری ارتباط با خوشه شما پیکربندی شده باشد. توصیه می‌شود این آموزش را روی خوشه‌ای با دست‌کم دو گره(Node) که به‌عنوان میزبان‌های control plane عمل نمی‌کنند اجرا کنید.
اگر هنوز خوشه ندارید، می‌توانید با استفاده از minikube یکی بسازید یا از یکی از محیط‌های آزمایشی کوبرنتیز زیر بهره ببرید:

To check the version, enter kubectl version.

پیش‌نیازها

این مثال موارد زیر را فرض می‌کند:

  1. شما یک خوشه کوبرنتیز موجود دارید.
  2. شما درک اولیه‌ای از کوبرنتیز پادهای، سرویس ها، و استقرارها دارید.

آشنایی با فضای نام پیش‌فرض

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

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

kubectl get namespaces

NAME      STATUS    AGE
default   Active    13m

ایجاد فضاهای نام جدید

برای این تمرین، دو فضای نام کوبرنتیز اضافی برای نگهداری محتوای خودایجاد خواهیم کرد.

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

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

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

یکی از الگوهایی که این سازمان می‌تواند دنبال کند، تقسیم‌بندی خوشه (cluster) کوبرنتیز به دو فضای نام است: «توسعه» و «تولید».

بیایید دو فضای نام جدید برای نگهداری کارمان ایجاد کنیم.

از پرونده namespace-dev.yaml که یک فضای نام development را توصیف می‌کند، استفاده کنید:

admin/namespace-dev.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    name: development

فضای نام «توسعه» را با استفاده از kubectl ایجاد کنید.

kubectl create -f https://k8s.io/examples/admin/namespace-dev.yaml

محتویات زیر را در پرونده namespace-prod.yaml که یک فضای نام production را توصیف می‌کند، ذخیره کنید:

admin/namespace-prod.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    name: production

و سپس بیایید فضای نام production را با استفاده از kubectl ایجاد کنیم.

kubectl create -f https://k8s.io/examples/admin/namespace-prod.yaml

برای اطمینان از درست بودن همه چیز، بیایید تمام فضاهای نام موجود در خوشه (cluster) خود را فهرست کنیم.

kubectl get namespaces --show-labels

NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production

ایجاد پادها در هر فضای نام

فضای نام کوبرنتیز، محدوده‌ی پادها، سرویس‌هاواستقرارها را در خوشه (cluster) فراهم می‌کند.

کاربرانی که با یک فضای نام تعامل دارند، محتوای فضای نام دیگر را نمی‌بینند.

برای نشان دادن این موضوع، بیایید یک استقرار و پادهای ساده را در فضای نام development اجرا کنیم. ابتدا بررسی می‌کنیم که محتوا فعلی چیست:

kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.122.180
  name: lithe-cocoa-92103_kubernetes
contexts:
- context:
    cluster: lithe-cocoa-92103_kubernetes
    user: lithe-cocoa-92103_kubernetes
  name: lithe-cocoa-92103_kubernetes
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
  user:
    password: h5M0FtUUIflBSdI7
    username: admin

kubectl config current-context

lithe-cocoa-92103_kubernetes

مرحله بعدی تعریف یک context برای کلاینت kubectl است تا در هر فضای نام کار کند. مقدار فیلدهای "cluster" و "user" از context فعلی رونوشت می‌شود.

kubectl config set-context dev --namespace=development \
  --cluster=lithe-cocoa-92103_kubernetes \
  --user=lithe-cocoa-92103_kubernetes

kubectl config set-context prod --namespace=production \
  --cluster=lithe-cocoa-92103_kubernetes \
  --user=lithe-cocoa-92103_kubernetes

به‌طور پیش‌فرض، دستورات بالا دو context را اضافه می‌کنند که در پرونده «.kube/config» ذخیره می‌شوند. اکنون می‌توانید contextها را مشاهده کنید و بسته به فضای نامی که می‌خواهید با آن کار کنید، متناوب با دو context درخواستی جدید جایگزین کنید.

برای مشاهده‌ی context‌های جدید:

kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.122.180
  name: lithe-cocoa-92103_kubernetes
contexts:
- context:
    cluster: lithe-cocoa-92103_kubernetes
    user: lithe-cocoa-92103_kubernetes
  name: lithe-cocoa-92103_kubernetes
- context:
    cluster: lithe-cocoa-92103_kubernetes
    namespace: development
    user: lithe-cocoa-92103_kubernetes
  name: dev
- context:
    cluster: lithe-cocoa-92103_kubernetes
    namespace: production
    user: lithe-cocoa-92103_kubernetes
  name: prod
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
  user:
    password: h5M0FtUUIflBSdI7
    username: admin

بیایید به فضای نام «development» تغییر دهیم.

kubectl config use-context dev

شما می‌توانید با انجام موارد زیر، context فعلی خود را تأیید کنید:

kubectl config current-context

dev

در این مرحله، تمام درخواست‌هایی که از خط فرمان به خوشه (cluster) کوبرنتیز ارسال می‌کنیم، در فضای نام development قرار می‌گیرند.

بیایید چند محتوا ایجاد کنیم.

admin/snowflake-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: snowflake
  name: snowflake
spec:
  replicas: 2
  selector:
    matchLabels:
      app: snowflake
  template:
    metadata:
      labels:
        app: snowflake
    spec:
      containers:
      - image: registry.k8s.io/serve_hostname
        imagePullPolicy: Always
        name: snowflake

تغییرات را برای ایجاد یک استقرار اعمال کنید

kubectl apply -f https://k8s.io/examples/admin/snowflake-deployment.yaml

ما یک استقرار با اندازه رونوشت ۲ عدد پاد ایجاد کرده‌ایم که پادی به نام snowflake را با یک کانتینر پایه که نام میزبان را ارائه می‌دهد، اجرا می‌کند.

kubectl get deployment

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
snowflake    2/2     2            2           2m

kubectl get pods -l app=snowflake

NAME                         READY     STATUS    RESTARTS   AGE
snowflake-3968820950-9dgr8   1/1       Running   0          2m
snowflake-3968820950-vgc4n   1/1       Running   0          2m

و این عالی است، توسعه‌دهندگان می‌توانند هر کاری که می‌خواهند انجام دهند و لازم نیست نگران تأثیرگذاری بر محتوا در فضای نام «تولید» باشند.

بیایید به فضای نام production برویم و نشان دهیم که چگونه منابع موجود در یک فضای نام از فضای نام دیگر پنهان می‌شوند.

kubectl config use-context prod

فضای نام production باید خالی باشد و دستورات زیر نباید چیزی را برگردانند.

kubectl get deployment
kubectl get pods

بخش تولید دوست دارد گاوها را اداره کند، پس بیایید چند گاوداری ایجاد کنیم.

kubectl create deployment cattle --image=registry.k8s.io/serve_hostname --replicas=5

kubectl get deployment

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
cattle       5/5     5            5           10s

kubectl get pods -l app=cattle

NAME                      READY     STATUS    RESTARTS   AGE
cattle-2263376956-41xy6   1/1       Running   0          34s
cattle-2263376956-kw466   1/1       Running   0          34s
cattle-2263376956-n4v97   1/1       Running   0          34s
cattle-2263376956-p5p3i   1/1       Running   0          34s
cattle-2263376956-sxpth   1/1       Running   0          34s

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

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

5 - مرجع

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

مرجع API

کتابخانه‌های client با پشتیبانی رسمی

برای فراخوانی API کوبرنتیز از یک زبان برنامه‌نویسی، می‌توانید از کتابخانه‌ها استفاده کنید.
کتابخانه‌هایی که به‌طور رسمی پشتیبانی می‌شوند:

خط فرمان

  • kubectl - ابزار خط فرمان اصلی برای اجرای دستورها و مدیریت خوشه‌های کوبرنتیز.
  • kubeadm - ابزار خط فرمانی برای راه‌اندازی آسان یک خوشه ایمن کوبرنتیز.

اجزا

  • kubelet - عامل اصلی‌ای که روی هر گره اجرا می‌شود. kubelet مجموعه‌ای از PodSpecها را می‌گیرد و اطمینان حاصل می‌کند کانتینرهای توصیف‌شده در حال اجرا و سالم هستند.

  • kube-apiserver - یک REST API که داده‌های اشیای API مانند پادها، سرویس‌ها و replication controllerها را اعتبارسنجی و پیکربندی می‌کند.

  • kube-controller-manager - یک Daemon ای که حلقه‌های کنترل اصلی همراه کوبرنتیز را در خود جای داده است.

  • kube-proxy - می‌تواند ارسال ساده جریان TCP/UDP یا ارسال TCP/UDP به‌صورت round-robin را بین مجموعه‌ای از بک‌اندها انجام دهد.

  • kube-scheduler - زمان‌بندی‌کننده‌ای که دسترس‌پذیری، عملکرد و ظرفیت را مدیریت می‌کند.

  • فهرست ports and protocols که باید روی گره‌های Control Plain و Worker باز باشند

پیکربندی APIها

این بخش میزبان مستندات APIهای «منتشر نشده» است که برای پیکربندی اجزا یا ابزارهای کوبرنتیز استفاده می‌شوند. اکثر این APIها توسط سرور API به روش RESTful در معرض نمایش قرار نمی‌گیرند، اگرچه برای کاربر یا اپراتور جهت استفاده یا مدیریت یک خوشه ضروری هستند.

پیکربندی API برای kubeadm

API های خارجی

اینها APIهایی هستند که توسط پروژه کوبرنتیز تعریف شده‌اند، اما توسط پروژه اصلی پیاده‌سازی نشده‌اند:

اسناد طراحی

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

معماری کوبرنتیز و مرور کلی طراحی کوبرنتیز.

5.1 - واژه‌نامه

6 - مشارکت در کوبرنتیز

.

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

با وجود این همه روش برای تأثیرگذاری بر پروژه، ما – کوبرنتیز – یک تارنما اختصاصی ساخته‌ایم: https://k8s.dev. می‌توانید به آنجا بروید تا بیشتر درباره مشارکت در کوبرنتیز بدانید.

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

همچنین می‌توانید صفحه مشارکت‌کنندگان CNCF درباره مشارکت در کوبرنتیز را مطالعه کنید.

6.1 - مشارکت در مستندات کوبرنتیز

این وبسایت توسط SIG Docs کوبرنتیز نگه‌داری می‌شود.
پروژه کوبرنتیز از کمک همه مشارکت‌کنندگان، چه تازه‌کار و چه باتجربه، استقبال می‌کند!

مشارکت‌کنندگان مستندات کوبرنتیز:

  • بهبود محتوای موجود
  • ایجاد محتوای جدید
  • ترجمه مستندات
  • مدیریت و انتشار بخش‌های مستندات در چرخه انتشار کوبرنتیز

تیم وب نوشت، که بخشی از SIG Docs است، به مدیریت وب نوشت‌های رسمی کمک می‌کند. برای کسب اطلاعات بیشتر،
مشارکت در وب نوشت‌های کوبرنتیز را بخوانید.

شروع کنید

هر کسی می‌تواند برای مستندات یک issue باز کند یا تغییری را با یک PR به مخزن GitHub kubernetes/website ارائه کند.
برای کار مؤثر در جامعه کوبرنتیز لازم است با git و GitHub آشنایی کافی داشته باشید.

برای مشارکت در مستندات:

  1. توافق‌نامه مجوز مشارکت‌کنندگان (CLA) CNCF را امضا کنید:
    Contributor License Agreement.
  2. با مخزن مستندات و مولد سایت ایستای این وبسایت آشنا شوید.
  3. اطمینان حاصل کنید که فرایندهای پایه برای باز کردن یک PR و بازبینی تغییرات را می‌دانید.
flowchart TB subgraph third[باز کردن PR] direction TB U[ ] -.- Q[بهبود محتوا] --- N[ایجاد محتوا] N --- O[ترجمه مستندات] O --- P[مدیریت و انتشار بخش های مستندات
در چرخه انتشار کوبرنتیز] end subgraph second[بازبینی] direction TB T[ ] -.- D[مرور مخزن
kubernetes/website] --- E[بررسی مولد سایت
ایستای Hugo] E --- F[درک دستورات پایه
GitHub] F --- G[بازبینی PRهای باز
و فرایندهای بازبینی تغییرات] end subgraph first[ثبت نام] direction TB S[ ] -.- B[توافق نامه مجوز مشارکت کنندگان CNCF را امضا کنید] --- C[به کانال Slack sig-docs بپیوندید] C --- V[به فهرست پستی kubernetes-sig-docs بپیوندید] V --- M[در تماس های هفتگی sig-docs یا جلسات Slack شرکت کنید] end A([fa:fa-user مشارکت کننده
جدید]) --> first A --> second A --> third A --> H[سوال بپرسید!!!] classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey class S,T,U spacewhite class first,second,third white

شکل ۱. شروع به کار برای یک مشارکت‌کننده جدید.

قدم ۱ یک نقشه راه برای مشارکت‌کنندگان تازه‌وارد ترسیم می‌کند. می‌توانید برخی یا همه مراحل «ثبت‌نام» (Sign up) و «بازبینی» (Review) را دنبال کنید. اکنون آماده‌اید تا PRهایی را باز کنید که اهداف مشارکت شما را برآورده سازند؛ برخی از این اهداف در بخش «ایجاد PR» (Open PR) فهرست شده‌اند. باز هم، سوالات همیشه مورد استقبال هستند!

برخی کارها به اعتماد و دسترسی بیشتری در سازمان کوبرنتیز نیاز دارند. برای جزئیات بیشتر درباره نقش‌ها و سطح دسترسی، مشارکت در SIG Docs را ببینید.

اولین مشارکت شما

شما می‌توانید با مرور چندین مرحله از قبل، برای اولین مشارکت خود آماده شوید.

شکل ۲ مراحل و جزئیات بعدی را شرح می‌دهد.

flowchart LR subgraph second[اولین مشارکت] direction TB S[ ] -.- G[بازبینی PRهای اعضای
دیگر K8s] --> A[بررسی فهرست Issues در
kubernetes/website برای PRهای
good first] --> B[باز کردن یک PR!!] end subgraph first[آماده سازی پیشنهادی] direction TB T[ ] -.- D[مرور نمای کلی مشارکت] -->E[خواندن راهنماهای
محتوا و سبک K8s] E --> F[یادگیری انواع محتوای صفحه در Hugo
و شورت کدها] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,D,E,F,G grey class S,T spacewhite class first,second white

گام ۲. آماده‌سازی برای نخستین مشارکت شما.

هنگام مشارکت کمک بگیرید

ارائه نخستین مشارکت می‌تواند دلهره‌آور باشد.
سفیران مشارکت‌کنندگان جدید
برای همراهی شما در انجام چند مشارکت اول حضور دارند. می‌توانید از طریق
Slack کوبرنتیز و ترجیحاً در کانال #sig-docs با آن‌ها ارتباط بگیرید.
همچنین تماس برای آشنایی و خوشامدگویی به مشارکت‌کنندگان جدید
در اولین سه‌شنبه هر ماه برگزار می‌شود. در آنجا می‌توانید با سفیران مشارکت‌کنندگان جدید تعامل کرده
و پرسش‌های خود را مطرح کنید.

گام‌های بعدی

با SIG Docs همراه شوید

SIG Docs گروهی از مشارکت‌کنندگان است که مستندات کوبرنتیز و وبسایت آن را منتشر و نگه‌داری می‌کنند. مشارکت با SIG Docs راهی عالی برای مشارکت‌کنندگان کوبرنتیز (چه توسعه‌دهندگان قابلیت‌ها و چه سایر افراد) است تا تأثیر بزرگی بر پروژه کوبرنتیز بگذارند.

SIG Docs با روش‌های مختلفی ارتباط برقرار می‌کند:

  • به کانال #sig-docs در Slack کوبرنتیز بپیوندید. حتماً خودتان را معرفی کنید!
  • به لیست‌پستی kubernetes-sig-docs ملحق شوید؛ مباحث گسترده‌تر در اینجا انجام می‌شود و تصمیم‌های رسمی ثبت می‌شوند.
  • در جلسه ویدئویی SIG Docs که هر دو هفته یک‌بار برگزار می‌شود شرکت کنید. این جلسات همیشه در #sig-docs اعلام شده و به تقویم جلسات جامعه کوبرنتیز افزوده می‌شوند. لازم است کلاینت Zoom را نصب کنید یا از طریق تلفن وارد شوید.
  • در هفته‌هایی که جلسه حضوری Zoom برگزار نمی‌شود، در استندآپ غیرهمزمان (Async Stand-up) SIG Docs در Slack شرکت کنید. این جلسات نیز همیشه در #sig-docs اعلام می‌شوند. تا ۲۴ ساعت پس از اعلام جلسه می‌توانید در یکی از رشته‌ها مشارکت کنید.

راه‌های دیگر برای مشارکت کردن

6.2 - مشارکت در وب نوشت‌های کوبرنتیز

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

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

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

وب نوشت‌های رسمی کوبرنتیز

وب نوشت اصلی

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

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

وب نوشت مشارکت‌کنندگان

وب نوشت مشارکت‌کنندگان کوبرنتیز برای مخاطبانی است که بیشتر بر روی کوبرنتیز کار می‌کنند تا افرادی که با کوبرنتیز کار می‌کنند.
پروژه کوبرنتیز عمداً برخی مقالات را در هر دو وبلاگ منتشر می‌کند.

هر کسی می‌تواند یک مطلب وب نوشتی بنویسد و آن را برای بازبینی ارسال کند.

به‌روزرسانی و نگهداری مقاله

پروژه کوبرنتیز مقالات قدیمی وب نوشت‌های خود را نگه‌داری نمی‌کند. این بدان معناست که هر مقاله منتشرشده‌ای که بیش از یک سال از انتشارش گذشته باشد، معمولاً برای دریافت مسئله یا درخواست ادغام جهت اعمال تغییرات واجد شرایط نیست. برای جلوگیری از ایجاد رویه، حتی درخواست ادغام‌های فنی و درست هم به احتمال زیاد رد می‌شوند.

بااین‌حال، استثناهایی وجود دارند؛ مانند:

  • (به‌روزرسانی‌های) مقالاتی که به‌عنوان همیشه‌سبز علامت خورده‌اند
  • حذف یا اصلاح مقالاتی که اکنون توصیه‌های نادرست و خطرناک ارائه می‌دهند
  • رفع خطاها برای اطمینان از این‌که یک مقاله موجود هنوز به‌درستی نمایش داده می‌شود

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

مقالات همیشه سبز

می‌توانید با قرار دادن evergreen: true در مقدمه، یک مقاله را به‌عنوان همیشه‌سبز علامت‌گذاری کنید.

ما فقط زمانی مقالات وب نوشت را به‌عنوان نگه‌داری‌شده (evergreen: true در مقدمه) علامت می‌زنیم که پروژه کوبرنتیز بتواند متعهد شود آن‌ها را برای همیشه نگه‌داری کند. برخی مقالات وب نوشت بدون تردید شایسته این هستند؛ برای نمونه، تیم ارتباطات انتشار همواره اعلان‌های رسمی را به‌عنوان همیشه‌سبز علامت می‌زند.

What's next

6.3 - بازبینی تغییرات

این بخش توضیح می‌دهد چگونه محتوا را بازبینی کنید.

6.3.1 - بازبینی (review) Pull Requestها

هرکسی می‌تواند یک Pull Request مربوط به مستندات را بازبینی (review) کند. برای دیدن Pull Requestهای باز، به بخش pull requests در مخزن وب‌سایت کوبرنتیز بروید.

بازبینی Pull Requestهای مستندات راه بسیار خوبی برای معرفی خود به جامعه کوبرنتیز است؛ به شما کمک می‌کند با پایگاه کد آشنا شوید و اعتماد سایر مشارکت‌کنندگان را جلب کنید.

پیش از بازبینی، بهتر است:

پیش از شروع

پیش از آن‌که بازبینی را آغاز کنید:

  • آیین‌نامه/قواعد رفتاری CNCF را بخوانید و در همه زمان‌ها به آن پایبند باشید.
  • مؤدب، ملاحظه‌کار و یاری‌رسان باشید.
  • علاوه بر تغییرات، بر جنبه‌های مثبت PRها نیز نظر بگذارید.
  • همدل باشید و در نظر داشته باشید بازبینی شما چگونه دریافت می‌شود.
  • نیت خوب را فرض کنید و پرسش‌های روشن‌کننده بپرسید.
  • مشارکت‌کنندگان باتجربه، با مشارکت‌کنندگان تازه‌ای که کارشان نیاز به تغییرات گسترده دارد جفت شوید.

فرایند بازبینی

به‌طور کلی، Pull Requestها را از نظر محتوا و سبک به زبان انگلیسی بازبینی کنید. شکل ۱ گام‌های فرایند بازبینی را نشان می‌دهد؛ جزئیات هر گام در ادامه آمده است.

flowchart LR subgraph fourth[Start review] direction TB S[ ] -.- M[add comments] --> N[review changes] N --> O[new contributors should
choose Comment] end subgraph third[Select PR] direction TB T[ ] -.- J[read description
and comments]--> K[preview changes in
Netlify preview build] end A[Review open PR list]--> B[Filter open PRs
by label] B --> third --> fourth classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,J,K,M,N,O grey class S,T spacewhite class third,fourth white

شکل ۱. گام‌های فرایند بازبینی.

  1. به نشانی https://github.com/kubernetes/website/pulls بروید. فهرستی از همه Pull Requestهای باز برای وب‌سایت و مستندات کوبرنتیز را می‌بینید.

  2. Pull Requestهای باز را با استفاده از یک یا همه برچسب‌های زیر فیلتر کنید:

    • cncf-cla: yes (پیشنهاد می‌شود): PRهایی که نویسنده آن‌ها CLA را امضا نکرده است نمی‌توانند ادغام شوند. برای اطلاعات بیش‌تر بخش، CLA امضا را ببینید.
    • language/en (پیشنهاد می‌شود): فقط PRهای زبان انگلیسی را فیلتر می‌کند.
    • size/<size>: PRها را بر اساس اندازه فیلتر می‌کند. اگر تازه‌کار هستید، با PRهای کوچک‌تر شروع کنید.

    همچنین مطمئن شوید PR با برچسب work in progress علامت‌گذاری نشده باشد؛ چنین PRهایی هنوز آماده بازبینی نیستند.

  3. پس از انتخاب یک PR برای بازبینی، تغییرات را با انجام کارهای زیر درک کنید:

    • توضیحات PR را بخوانید تا تغییرات انجام‌شده را بفهمید و هر Issue پیوند‌شده را بررسی کنید.
    • نظرهای سایر بازبین‌ها را بخوانید.
    • روی تب Files changed کلیک کنید تا فایل (پرونده)‌ها و خطوط تغییر‌یافته را ببینید.
    • پیش‌نمایش تغییرات را در ساخت پیش‌نمایش Netlify مشاهده کنید. برای این کار، در تب Conversation به بخش بررسی ساخت Netlify که در پایین صفحه قرار دارد بروید.
      (این تصویر مربوط به نسخه دسکتاپ GitHub است؛ اگر در تبلت یا تلفن همراه بازبینی می‌کنید، رابط کاربری GitHub کمی متفاوت است):
      GitHub pull request details including link to Netlify preview
      برای باز کردن پیش‌نمایش، روی پیوند Details در خط deploy/netlify در فهرست بررسی‌ها کلیک کنید.

  4. به تب Files changed بروید تا بازبینی را آغاز کنید.

    1. روی نماد + کنار خطی که می‌خواهید نظر بدهید کلیک کنید.
    2. نظر خود را درباره آن خط بنویسید و روی Add single comment (اگر تنها یک نظر دارید) یا Start a review (اگر چند نظر دارید) کلیک کنید.
    3. پس از پایان، در بالای صفحه روی Review changes کلیک کنید. اینجا می‌توانید خلاصه‌ای از بازبینی خود (و چند نظر مثبت برای مشارکت‌کننده!) بنویسید. لطفاً همیشه از دکمه "Comment" استفاده کنید.

    • هنگام پایان بازبینی، از کلیک روی دکمه "Request changes" پرهیز کنید.
      اگر می‌خواهید پیش از اعمال تغییرات بیشتر مانع ادغام PR شوید، می‌توانید کامنت /hold بگذارید. دلیل hold را ذکر کنید و در صورت تمایل شرایط برداشتن آن را مشخص کنید.

    • هنگام پایان بازبینی، از کلیک روی دکمه "Approve" پرهیز کنید. بیشتر مواقع گذاشتن کامنت /approve توصیه می‌شود.

چک‌لیست بازبینی

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

زبان و دستور زبان

  • ‌آیا خطاهای آشکاری در زبان یا دستور زبان وجود دارد؟ آیا راه بهتری برای بیان یک جمله هست؟
    • روی زبان و دستور زبان بخش‌هایی از صفحه که نویسنده تغییر داده تمرکز کنید. مگر این‌که نویسنده آشکارا قصد به‌روزرسانی کل صفحه را داشته باشد، او الزام ندارد همه اشکالات صفحه را برطرف کند.
    • وقتی یک PR صفحه‌ای موجود را به‌روزرسانی می‌کند، روی بخش‌های تغییر یافته صفحه بازبینی کنید. آن محتوا باید از نظر فنی و ویرایشی درست باشد. اگر خطاهایی پیدا کردید که مستقیماً به هدف نویسنده مرتبط نیست، آن را در یک Issue جداگانه مطرح کنید (البته ابتدا مطمئن شوید Issue مشابهی وجود ندارد).
    • مراقب Pull Requestهایی باشید که محتوا را جابه‌جا می‌کنند. اگر نویسنده صفحه‌ای را تغییر نام می‌دهد یا دو صفحه را ادغام می‌کند، ما (SIG Docs کوبرنتیز) معمولاً از او نمی‌خواهیم همه ایرادهای املایی یا دستور زبانی موجود در محتوای جابه‌جا شده را برطرف کند.
  • آیا واژه‌های پیچیده یا کهنه‌ای هست که بتوان آن‌ها را با واژه‌ای ساده‌تر جایگزین کرد؟
  • آیا واژه، اصطلاح یا عبارتی هست که بتوان آن را با جایگزینی غیرتبعیض‌آمیز عوض کرد؟
  • آیا انتخاب واژه و حروف بزرگ/کوچک کردن آن با راهنمای سبک هماهنگ است؟
  • آیا جمله‌های طولانی وجود دارد که می‌تواند کوتاه‌تر یا ساده‌تر شود؟
  • آیا پاراگراف‌های طولانی وجود دارد که شاید به‌صورت فهرست یا جدول بهتر باشند؟

محتوا

  • آیا محتوای مشابهی در جای دیگری از سایت کوبرنتیز وجود دارد؟
  • آیا محتوا بیش از حد به مستندات خارج از وب‌سایت، مستندات متعلق به یک فروشنده ی خاص یا مستندات غیرمتن‌باز پیوند می‌دهد؟

مستندات

چند بررسی که باید در نظر گرفت:

  • آیا این PR عنوان، slug/alias یا پیوند لنگری (anchor link) صفحه‌ای را تغییر داده یا حذف کرده است؟ اگر بله، آیا در نتیجه این PR پیوند‌های شکسته‌ای ایجاد شده است؟ آیا گزینه دیگری مثل تغییر عنوان صفحه بدون تغییر slug وجود دارد؟

  • آیا PR صفحه‌ای جدید اضافه می‌کند؟ اگر بله:

    • آیا صفحه از نوع محتوای صفحه مناسب و شورتکدهای مرتبط Hugo استفاده می‌کند؟
    • آیا صفحه در ناوبری جانبی آن بخش به‌درستی نمایش داده می‌شود (یا اصلاً نمایش داده می‌شود)؟
    • آیا باید صفحه در فهرست صفحه اصلی اسناد ظاهر شود؟

  • آیا تغییرات در پیش‌نمایش Netlify نمایش داده می‌شوند؟ درباره فهرست‌ها، بلاک‌های کد، جدول‌ها، نکته‌ها و تصاویر دقیق باشید.

وب‌نوشت (blog)

بازخورد زودهنگام درباره پست‌های وب‌نوشت (blog) از طریق Google Doc یا HackMD استقبال می‌شود. لطفاً درخواست خود را از کانال Slack #sig-docs-blog زودتر ارسال کنید.

پیش از بازبینی PRهای وب‌نوشت (blog)، با راهنمای وب‌نوشت (blog) و ارسال پست وب‌نوشت (blog) و مطالعات موردی آشنا باشید.

همچنین درباره مقالات evergreen و نحوه تصمیم‌گیری درباره evergreen بودن مقاله اطلاعات داشته باشید.

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

به‌عنوان پروژه، فقط زمانی مقالات وب‌نوشت (blog) را با برچسب نگه‌داری (evergreen: true در front matter) علامت می‌کنیم که پروژه Kubernetes متعهد باشد آن‌ها را به‌طور نامحدود نگه‌داری کند. برخی مقالات قطعاً ارزش این کار را دارند و ما همیشه اطلاعیه‌های انتشار را evergreen علامت می‌کنیم. اگر درباره نحوه بازبینی این مورد مطمئن نیستید، با سایر مشارکت‌کنندگان مشورت کنید.

راهنمای محتوا بدون قید و شرط بر مقالات وب‌نوشت (blog) و PRهایی که آن‌ها را اضافه می‌کنند اعمال می‌شود. به یاد داشته باشید برخی محدودیت‌ها فقط به مستندات مربوط‌اند و برای مقالات وب‌نوشت (blog) صدق نمی‌کنند.

بررسی کنید که منبع Markdown از نوع مناسب محتوای صفحه و / یا layout مناسب استفاده می‌کند.

سایر

مراقب ویرایش‌های جزئی (Trivial Edits) باشید؛ اگر تغییری را ویرایش جزئی تشخیص می‌دهید، این سیاست را یادآور شوید (اگر واقعاً بهبود است، قبول تغییر اشکالی ندارد).

نویسندگانی را که در حال انجام اصلاحات مربوط به فاصله‌گذاری (whitespace) هستند تشویق کنید که این کار را در اولین commit PR خود انجام دهند و سپس تغییرات دیگر را روی آن اضافه کنند. این کار هم ادغام (merge) و هم بازبینی‌ها را ساده‌تر می‌کند. به‌ویژه مراقب تغییرات جزئی باشید که همراه با مقدار زیادی اصلاح فاصله‌گذاری در یک commit واحد انجام شده‌اند (و اگر چنین موردی دیدید، نویسنده را تشویق کنید تا آن را اصلاح کند).

به‌عنوان بازبین، اگر مسائل کوچکی در PR یافتید که برای معنا حیاتی نیستند، مثل غلط‌های املایی یا فاصله نادرست، نظر خود را با پیشوند nit: بنویسید. این به نویسنده نشان می‌دهد این بخش از بازخورد شما غیر بحرانی است.

اگر در حال بررسی تأیید یک Pull Request هستید و تمام بازخوردهای باقی‌مانده با nit علامت‌گذاری شده‌اند، می‌توانید PR را ادغام کنید. در این حالت، توصیه می‌شود برای موارد nit باقی‌مانده یک issue جدید باز کنید. همچنین در نظر بگیرید که آیا می‌توانید آن issue جدید را به‌عنوان Good First Issue علامت‌گذاری کنید یا خیر؛ اگر امکان‌پذیر باشد، این ها منابع خوبی (برای مشارکت‌کنندگان تازه‌وارد) خواهند بود.

6.3.2 - بازبینی برای تأییدکنندگان و بازبین‌ها

بازبین‌ها (Reviewers) و تأییدکنندگان (Approvers) در SIG Docs هنگام بازبینی یک تغییر چند کار اضافه نیز انجام می‌دهند.

هر هفته یکی از تأییدکنندگان مستندات (docs approver) داوطلب می‌شود تا Pull Requestها را تریاژ (triage) و بازبینی کند. این فرد در آن هفته "PR Wrangler" است. برای اطلاعات بیشتر، به زمان‌بندی PR Wrangler مراجعه کنید. برای تبدیل شدن به PR Wrangler، در نشست هفتگی SIG Docs شرکت کنید و داوطلب شوید. حتی اگر در برنامهٔ همین هفته نام شما نیست، هنوز هم می‌توانید Pull Requestهایی (PRها) را که در حال حاضر تحت بازبینی فعال نیستند، بررسی کنید.

علاوه بر چرخشی بودن، یک بات بازبین‌ها و تأییدکنندگان PR را بر اساس مالکیت فایل (پرونده)‌های تحت تأثیر تعیین می‌کند.

بازبینی یک PR

مستندات کوبرنتیز از فرآیند بازبینی کد کوبرنتیز پیروی می‌کند.

هر آنچه در بازبینی یک Pull Request آمده است صدق می‌کند، اما بازبین‌ها و تأییدکنندگان باید کارهای زیر را نیز انجام دهند:

  • استفاده از دستور Prow /assign برای اختصاص دادن یک بازبین مشخص به یک Pull Request در صورت نیاز. این کار به‌ویژه زمانی اهمیت بیشتری دارد که نیاز به درخواست بازبینی فنی از مشارکت‌کنندگان کد باشد.

  • اطمینان از اینکه PR مطابق با راهنمای محتوا و راهنمای سبک است؛ اگر این‌طور نیست، نویسنده را به بخش مربوطه در راهنما(ها) ارجاع دهید.

  • استفاده از گزینه Request Changes در GitHub در صورت لزوم برای پیشنهاد تغییر به نویسنده PR.

  • تغییر وضعیت بازبینی خود در GitHub با استفاده از دستورات Prow /approve یا /lgtm
    اگر پیشنهادهای شما اعمال شده‌اند.

commit در PR شخص دیگر

گذاشتن نظر در PR مفید است، اما گاهی ممکن است لازم باشد در Pull Request شخص دیگری commit کنید.

هرگز کار شخص دیگری را «به‌دست نگیرید» مگر اینکه خود او صراحتاً درخواست کرده باشد یا قصد داشته باشید یک PR قدیمی و رهاشده را احیا کنید. گرچه این کار ممکن است در کوتاه‌مدت سریع‌تر باشد، اما فرصت مشارکت را از آن فرد می‌گیرد.

روش کار بستگی دارد به اینکه آیا نیاز دارید فایلی (پرونده‌ای) را ویرایش کنید که در دامنهٔ PR است یا فایلی (پرونده‌ای) را که هنوز در آن PR تغییری نکرده است.

شما نمی‌توانید در PR شخص دیگر commit کنید اگر یکی از شرایط زیر برقرار باشد:

  • اگر نویسنده PR شاخه (branch) خود را مستقیماً به مخزن https://github.com/kubernetes/website/ پوش کرده باشد. تنها بازبینی‌کننده‌ای با دسترسی push می‌تواند در PR کاربر دیگر commit کند.

  • نویسنده PR به‌صراحت ویرایش توسط تأییدکنندگان را غیرفعال کرده باشد.

دستورات Prow برای بازبینی

Prow سیستم CI/CD مبتنی بر کوبرنتیز است که روی Pull Requestها اجرا می‌شود.
Prow امکان استفاده از دستورات شبیه به چت‌بات را فراهم می‌کند تا کارهای GitHub مانند افزودن یا حذف برچسب‌ها، بستن Issueها و تعیین تاییدکنندگان را مدیریت کند.
دستورات Prow به‌صورت کامنت در GitHub و با فرمت /<command-name> نوشته می‌شوند.

رایج‌ترین دستورات Prow برای بازبین‌ها و تأییدکنندگان عبارتند از:

دستورات Prow برای بازبینی
دستور Prow محدودیت نقش توضیحات
/lgtm اعضای سازمان نشان می‌دهد بازبینی شما تمام شده و از تغییرات راضی هستید.
/approve تایید کنندگان PR را برای ادغام تأیید می‌کند.
/assign همه شخصی را برای بازبینی یا تأیید PR تعیین می‌کند.
/close اعضای سازمان یک Issue یا PR را می‌بندد.
/hold همه برچسب do-not-merge/hold را اضافه می‌کند و مانع ادغام خودکار PR می‌شود.
/hold cancel همه برچسب do-not-merge/hold را حذف می‌کند.

برای دیدن لیست کامل دستورات قابل استفاده در PR، به Prow مرجع دستورات مراجعه کنید.

دسته‌بندی و اولویت‌بندی Issueها

به‌طور کلی، SIG Docs از فرآیند تریاژ Issueها در کوبرنتیز پیروی می‌کند و از همان برچسب‌ها استفاده می‌کند.

این فیلتر در GitHub، فهرستی از issueها را پیدا می‌کند که ممکن است به تریاژ نیاز داشته باشند.

Triage یک Issue

  1. اعتبارسنجی Issue

    • مطمئن شوید که Issue مربوط به مستندات وب‌سایت است. برخی Issueها با پاسخ سریع یا ارجاع بسته می‌شوند.
      (به بخش درخواست‌های پشتیبانی یا گزارش باگ کد مراجعه کنید.)
    • بررسی کنید که Issue ارزش پیگیری دارد یا نه.
    • اگر Issue جزئیات کافی ندارد یا قالب به‌درستی پر نشده، برچسب triage/needs-information اضافه کنید.
    • اگر Issue هم lifecycle/stale و هم triage/needs-information دارد، آن را ببندید.

  2. افزودن برچسب اولویت (برای جزئیات کامل به دستورالعمل‌های تریاژ Issue‌ها مراجعه کنید)

برچسب‌های Issue
برچسب توضیحات
priority/critical-urgent همین حالا انجام دهید.
priority/important-soon ظرف ۳ ماه انجام دهید.
priority/important-longterm ظرف ۶ ماه انجام دهید.
priority/backlog قابل تعویق نامحدود؛ هر زمان منابع در دسترس بود انجام دهید.
priority/awaiting-more-evidence نگه‌دارنده یک Issue بالقوه خوب تا گم نشود.
help یا good first issue مناسب برای کسی با تجربه بسیار کم در کوبرنتیز یا SIG Docs. برای اطلاعات بیش‌تر، Help Wanted و Good First Issue را ببینید.

در صورت صلاحدید، مالکیت یک Issue را بر عهده بگیرید و برای آن PR ارسال کنید (به‌ویژه اگر سریع انجام می‌شود یا مرتبط با کاری است که همین حالا انجام می‌دهید).

اگر درباره تریاژ یک Issue پرسشی داشتید، در کانال #sig-docs در Slack یا لیست ایمیل kubernetes-sig-docs بپرسید.

افزودن و حذف برچسب های Issue

برای افزودن برچسب، یکی از قالب‌های زیر را در کامنت بگذارید:

  • /<label-to-add> (مثال: /good-first-issue)
  • /<label-category> <label-to-add> (مثال: /triage needs-information یا /language ja)

برای حذف برچسب:

  • /remove-<label-to-remove> (مثال: /remove-help)
  • /remove-<label-category> <label-to-remove> (مثال: /remove-triage needs-information)

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

لیست همه برچسب‌ها در بخش برچسب‌های مخزن وب‌سایت موجود است. همه برچسب‌ها توسط SIG Docs استفاده نمی‌شوند.

برچسب‌های چرخه عمر Issue

Issueها معمولاً به‌سرعت باز و بسته می‌شوند. بااین‌حال، گاهی یک Issue پس از باز شدن غیرفعال می‌شود و گاهی لازم است بیش از ۹۰ روز باز بماند.

برچسب‌های چرخه عمر Issue
برچسب توضیحات
lifecycle/stale پس از ۹۰ روز بدون فعالیت، Issue به‌طور خودکار با این برچسب علامت‌گذاری می‌شود. اگر چرخه عمر به‌صورت دستی با فرمان /remove-lifecycle stale برگردانده نشود، Issue خودکار بسته خواهد شد.
lifecycle/frozen Issue دارای این برچسب پس از ۹۰ روز غیرفعال شدن منقضی نمی‌شود. کاربر این برچسب را دستی برای Issueهایی اضافه می‌کند که باید مدت‌زمان بسیار طولانی‌تری باز بمانند، مانند آن‌هایی که برچسب priority/important-longterm دارند.

مدیریت انواع خاص Issueها

SIG Docs به‌اندازه‌ای با انواع زیر از Issue مواجه می‌شود که لازم است شیوه رسیدگی به آن‌ها مستند شود.

Issueهای تکراری

اگر یک مشکل واحد بیش از یک Issue باز دارد، آن‌ها را در یک Issue ادغام کنید. تصمیم بگیرید کدام Issue باز بماند (یا یک Issue جدید باز کنید)، سپس تمام اطلاعات مرتبط را منتقل کرده و Issueهای مرتبط را پیوند کنید. در نهایت، به همه Issueهای دیگر که همان مشکل را توصیف می‌کنند برچسب triage/duplicate بزنید و آن‌ها را ببندید. داشتن یک Issue منفرد، سردرگمی را کاهش می‌دهد و از دوباره‌کاری جلوگیری می‌کند.

Issueهای مربوط به پیوند‌های خراب

اگر Issue پیوند مرده در مستندات API یا kubectl است، تا زمانی که مشکل کاملاً درک شود به آن برچسب /priority critical-urgent بدهید.
به تمام Issueهای پیوند مرده دیگر برچسب /priority important-longterm بدهید، چون باید به‌صورت دستی رفع شوند.

Issueهای وب‌نوشت (blog)

انتظار می‌رود مطالب وب‌نوشت (blog) کوبرنتیز با گذر زمان قدیمی شوند؛ بنابراین فقط مطالب کمتر از یک‌سال را نگه‌داری می‌کنیم.
اگر Issue مربوط به مطلبی قدیمی‌تر از یک سال است، معمولاً باید Issue را بدون رفع ببندید.

می‌توانید هنگام بستن PR، پیوندی به به‌روزرسانی و نگه‌داری مقاله بفرستید.

در صورت وجود توجیه مناسب، ایجاد استثنا اشکالی ندارد.

درخواست های پشتیبانی یا گزارش باگ کد

برخی از Issueهای مربوط به مستندات در واقع به کد اصلی مربوط می‌شوند یا درخواست کمک هستند، برای مثال زمانی که یک آموزش (tutorial) درست کار نمی‌کند. برای Issueهایی که به مستندات مربوط نیستند، آن‌ها را با برچسب kind/support ببندید و در یک کامنت، درخواست‌کننده را به کانال‌های پشتیبانی دیگر (مانند Slack یا Stack Overflow) راهنمایی کنید. اگر Issue مربوط به باگ در یک قابلیت باشد، درخواست‌کننده را به مخزن مرتبط هدایت کنید (مخزن kubernetes/kubernetes نقطهٔ شروع مناسبی است).

نمونه پاسخ به درخواست پشتیبانی:

This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.

You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.

If this is a documentation issue, please re-open this issue.

نمونه پاسخ به گزارش باگ کد:

This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.

If this is a documentation issue, please re-open this issue.

squash کردن (Squashing)

به‌عنوان یک تأییدکننده، هنگام بازبینی Pull Requestها (PRها) ممکن است در شرایط مختلف یکی از کارهای زیر را انجام دهید:

  • به مشارکت‌کننده توصیه کنید commit‌هایش را squash کند.
  • commit‌ها را به‌جای مشارکت‌کننده squash کنید.
  • به مشارکت‌کننده توصیه کنید هنوز squash نکند.
  • مانع از squash شدن شوید.

توصیه به مشارکت‌کنندگان برای squash: یک مشارکت‌کننده تازه‌وارد ممکن است نداند که باید commit‌هایش را در PR squash کند. در این صورت، او را راهنمایی کنید، پیوندهای مفید در اختیارش بگذارید و در صورت نیاز پیشنهاد کمک بدهید. چند پیوند مفید:

squash commit برای مشارکت‌کنندگان: اگر مشارکت‌کننده ممکن است در squash کردن مشکل داشته باشد یا فشار زمانی برای ادغام PR وجود دارد، می‌توانید squash را برای او انجام دهید:

  • مخزن kubernetes/website برای اجازه squash هنگام ادغام PR پیکربندی شده است. کافی است دکمه Squash commits را بزنید.

  • در یک PR، اگر مشارکت‌کننده اجازهٔ مدیریت PR را به نگه‌دارندگان (maintainers) بدهد، می‌توانید commit‌های او را squash کنید و fork او را با نتیجهٔ نهایی به‌روزرسانی نمایید. پیش از انجام squash، به او توصیه کنید آخرین تغییرات خود را ذخیره کرده و به PR پوش کند. پس از squash نیز به او بگویید commit squash‌ شده را به کلون محلی خود pull کند.

  • همچنین می‌توانید با استفاده از یک برچسب (label) کاری کنید که GitHub commit‌ها را squash کند، به‌طوری که Tide / GitHub این کار را انجام دهند؛ یا هنگام ادغام PR روی دکمهٔ Squash commits کلیک کنید.

توصیه برای پرهیز از squash

  • اگر یک commit تغییرات خراب‌کننده یا نادرستی انجام داده باشد و commit آخر برای بازگرداندن (revert) آن خطا باشد، در این حالت commit‌ها را squash نکنید. حتی اگر در تب "Files changed" در PR در GitHub و در پیش‌نمایش Netlify همه‌چیز درست به‌نظر برسد، ادغام چنین PRی می‌تواند برای دیگر مشارکت‌کنندگان باعث ایجاد conflict در rebase یا merge شود. در چنین شرایطی، متناسب با صلاح‌دید خود مداخله کنید تا از ایجاد مشکل برای دیگر مشارکت‌کنندگان جلوگیری شود.

هرگز squash نکنید

اگر در حال راه‌اندازی یک بومی‌سازی (localization) یا انتشار مستندات برای یک نسخهٔ جدید هستید، در این حالت شاخه‌ای را ادغام می‌کنید که از fork یک کاربر نیست؛ در چنین شرایطی هرگز commit‌ها را squash نکنید. عدم squash در اینجا ضروری است زیرا باید تاریخچهٔ کامل commit‌ها برای آن فایل (پرونده)‌ها حفظ شود.

6.4 - بومی‌سازی مستندات کوبرنتیز

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

کمک به محلی سازی موجود

شما می‌توانید به افزودن یا بهبود محتوای یک محلی‌سازی موجود کمک کنید. در کانال Kubernetes در Slack، می‌توانید برای هر محلی‌سازی یک کانال پیدا کنید. همچنین یک کانال عمومی در Slack تحت عنوان SIG Docs Localizations وجود دارد که می‌توانید در آن سلام کنید.

کد دو حرفی زبان خود را پیدا کنید

ابتدا، برای یافتن کد دو حرفی زبان محلی‌سازی خود، به استاندارد ISO 639-1 مراجعه کنید. برای مثال، کد دو حرفی زبان کره‌ای «ko» است.

برخی از زبان‌ها از نسخه کوچک کد کشور که توسط ISO-3166 تعریف شده است، همراه با کدهای زبان خود استفاده می‌کنند. برای مثال، کد زبان پرتغالی برزیلی «pt-br» است.

مخزن را Fork و Clone کنید

ابتدا، شاخه‌ی خودتان را ایجاد کنید از مخزن kubernetes/website.

سپس، fork خود را clone کنید و تغییر پوشه دهید:

git clone https://github.com/<username>/website
cd website

پوشه محتوای تارنما شامل زیرپوشه هایی برای هر زبان است. محلی‌سازی که می‌خواهید به آن کمک کنید، درون content/<two-letter-code> قرار دارد.

پیشنهاد تغییرات

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

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

تغییرات در یک درخواست ادغام را به یک محلی‌سازی واحد محدود کنید. بررسی درخواست‌های ادغام که محتوا را در چندین محلی‌سازی تغییر می‌دهند، مشکل‌ساز است.

برای پیشنهاد تغییرات در آن بومی‌سازی، از پیشنهاد بهبود محتوا پیروی کنید. این فرآیند مشابه پیشنهاد تغییرات در محتوای بالادستی (انگلیسی) است.

شروع یک محلی‌سازی جدید

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

از آنجا که مشارکت‌کنندگان نمی‌توانند درخواست‌های ادغام خود را تأیید کنند، برای شروع بومی‌سازی حداقل به دو مشارکت‌کننده نیاز دارید.

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

شما باید کد دو حرفی زبان خود را بدانید. برای یافتن کد دو حرفی زبان محلی خود، به استاندارد ISO 639-1 مراجعه کنید. برای مثال، کد دو حرفی زبان کره‌ای «ko» است.

اگر زبانی که می‌خواهید بومی‌سازی آن را شروع کنید، در مکان‌های مختلفی صحبت می‌شود و تفاوت‌های قابل توجهی بین گونه‌های مختلف آن وجود دارد، ممکن است منطقی باشد که کد کشور ISO-3166 با حروف کوچک را با کد دو حرفی آن زبان ترکیب کنید. به عنوان مثال، پرتغالی برزیلی به صورت «pt-br» بومی‌سازی شده است.

وقتی محلی‌سازی جدیدی را شروع می‌کنید، باید قبل از اینکه پروژه کوبرنتیز بتواند تغییرات شما را در تارنما زنده منتشر کند، تمام حداقل محتوای مورد نیاز را محلی‌سازی کنید.

اسناد SIG می‌توانند به شما کمک کنند تا روی یک شاخه جداگانه کار کنید تا بتوانید به تدریج به سمت آن هدف حرکت کنید.

پیدا کردن جامعه

به کوبرنتیز SIG اسناد اطلاع دهید که به ایجاد محلی‌سازی علاقه‌مند هستید! به کانال SIG Docs در Slack و کانال SIG Docs Localizations در Slack بپیوندید. سایر تیم‌های محلی‌سازی خوشحال می‌شوند که در شروع کار به شما کمک کنند و به سوالات شما پاسخ دهند.

لطفاً شرکت در جلسه زیرگروه محلی‌سازی اسناد SIG را نیز در نظر بگیرید. ماموریت زیرگروه محلی‌سازی اسناد SIG، همکاری در تیم‌های محلی‌سازی اسناد SIG برای همکاری در تعریف و مستندسازی فرآیندهای ایجاد راهنماهای مشارکتی محلی‌سازی شده است. علاوه بر این، زیرگروه محلی‌سازی اسناد SIG به دنبال فرصت‌هایی برای ایجاد و اشتراک‌گذاری ابزارهای مشترک در بین تیم‌های محلی‌سازی و شناسایی الزامات جدید برای تیم رهبری اسناد SIG است. اگر در مورد این جلسه سؤالی دارید، لطفاً در کانال محلی‌سازی اسناد SIG سوال کنید.

همچنین می‌توانید یک کانال Slack برای محلی‌سازی خود در مخزن kubernetes/community ایجاد کنید. برای مثالی از اضافه کردن یک کانال Slack،به درخواست ادغام مربوط به اضافه کردن یک کانال برای زبان فارسی مراجعه کنید.

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

وقتی یک درخواست ادغام محلی‌سازی باز کردید، می‌توانید عضو سازمان گیت هاب کوبرنتیز شوید. هر فرد در تیم باید درخواست عضویت سازمان خود را (https://github.com/kubernetes/org/issues/new/choose) در مخزن kubernetes/org ایجاد کند.

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

در مرحله بعد، تیم محلی‌سازی کوبرنتیز خود را به sig-docs/teams.yaml اضافه کنید. برای مثالی از اضافه کردن یک تیم محلی‌سازی، به درخواست ادغام برای اضافه کردن تیم محلی‌سازی اسپانیایی مراجعه کنید.

اعضای «@kubernetes/sig-docs--owners» می‌توانند درخواست ادغام هایی را تأیید کنند که محتوا را در پوشه محلی‌سازی شما (و فقط در داخل) تغییر می‌دهد: «/content//». برای هر محلی‌سازی، تیم @Kubernetes/sig-docs-**-reviews تکالیف بررسی درخواست های ادغام جدید را خودکار می‌کند. اعضای @kubernetes/website-maintainers می‌توانند شاخه‌های محلی‌سازی جدیدی برای هماهنگی تلاش‌های ترجمه ایجاد کنند. اعضای @kubernetes/website-milestone-maintainers می‌توانند از /milestone دستور Prow برای اختصاص یک نقطه عطف به مسائل یا درخواست های ادغام استفاده کنند.

پیکربندی گردش کار

در مرحله بعد، یک برچسب GitHub برای محلی‌سازی خود در مخزن kubernetes/test-infra اضافه کنید. یک برچسب به شما امکان می‌دهد مشکلات را فیلتر کرده و درخواست‌ها را برای زبان خاص خود دریافت کنید.

برای مثالی از افزودن برچسب، به درخواست ادغام مربوط به افزودن برچسب زبان ایتالیایی مراجعه کنید (https://github.com/kubernetes/test-infra/pull/11316).

تغییر پیکربندی تارنما

تارنمای کوبرنتیز از Hugo به عنوان قالب وب خود استفاده می‌کند. پیکربندی Hugo این تارنما در پرونده hugo.toml قرار دارد. برای پشتیبانی از محلی‌سازی جدید، باید hugo.toml را تغییر دهید.

یک بلوک پیکربندی برای زبان جدید به hugo.toml زیر بلوک [languages] موجود اضافه کنید. برای مثال، بلوک زبان آلمانی به شکل زیر خواهد بود:

[languages.de]
title = "Kubernetes"
languageName = "Deutsch (German)"
weight = 5
contentDir = "content/de"
languagedirection = "ltr"

[languages.de.params]
time_format_blog = "02.01.2006"
language_alternatives = ["en"]
description = "Produktionsreife Container-Orchestrierung"
languageNameLatinScript = "Deutsch"

نوار انتخاب زبان، مقدار مربوط به languageName را فهرست می‌کند. "نام زبان به خط بومی و زبان (نام زبان انگلیسی به خط لاتین)" را به languageName اختصاص دهید. برای مثال، languageName = "한국어 (کره‌ای)" یا languageName = "Deutsch (آلمانی)".

می‌توان از languageNameLatinScript برای دسترسی به نام زبان به خط لاتین و استفاده از آن در قالب استفاده کرد. "نام زبان به خط لاتین" را به languageNameLatinScript اختصاص دهید. برای مثال، languageNameLatinScript ="Korean" یا languageNameLatinScript ="Deutsch".

پارامتر «وزن» ترتیب زبان‌ها را در نوار انتخاب زبان تعیین می‌کند. وزن کمتر اولویت دارد و در نتیجه زبان اول ظاهر می‌شود. هنگام اختصاص پارامتر «وزن»، بررسی بلوک زبان‌های موجود و تنظیم وزن آنها برای اطمینان از اینکه نسبت به همه زبان‌ها، از جمله هر زبان جدید اضافه شده، به ترتیب مرتب شده‌اند، مهم است.

برای اطلاعات بیشتر در مورد پشتیبانی چند زبانه Hugo، به "حالت چند زبانه" مراجعه کنید.

یک پوشه محلی‌سازی جدید اضافه کنید

یک زیرشاخه مختص به زبان مورد نظر را به پوشه content در مخزن اضافه کنید. برای مثال، کد دو حرفی برای زبان آلمانی de است:

mkdir content/de

شما همچنین باید یک پوشه در داخل «i18n» برای ایجاد کنید رشته های محلی شده; برای مثال به محلی سازی های موجود نگاه کنید.

برای مثال، برای زبان آلمانی، رشته‌ها در i18n/de/de.toml قرار دارند.

بومی‌سازی ضوابط رفتاری جامعه

برای اضافه کردن اصول اخلاقی به زبان خودتان، یک درخواست ادغام در مخزن cncf/foundation باز کنید.

پرونده‌های مالکان را تنظیم کنید

برای تنظیم نقش‌های هر کاربر که در بومی‌سازی مشارکت دارند، یک پرونده OWNERS در زیرشاخه‌ی زبان مربوطه با کد زیر ایجاد کنید:

  • بازبین‌ها: فهرستی از تیم‌های کوبرنتیز با نقش‌های بازبین، در این مورد،
  • تیم sig-docs-**-reviews که در افزودن تیم محلی‌سازی خود در گیت‌هاب ایجاد شده است.
  • تأییدکنندگان: فهرستی از تیم‌های کوبرنتیز با نقش‌های تأییدکننده، در این مورد،
  • تیم sig-docs-**-owners که در افزودن تیم محلی‌سازی خود در گیت‌هاب ایجاد شده است.
  • برچسب‌ها: فهرستی از برچسب‌های گیت‌هاب که به‌طور خودکار به یک درخواست ادغام اعمال می‌شوند، در این مورد، برچسب زبانی که در Configure the workflow ایجاد شده است.

اطلاعات بیشتر در مورد پرونده OWNERS را می‌توانید در go.k8s.io/owners بیابید.

پرونده OWNERS اسپانیایی با کد زبان es، به این شکل است:

# برای مشاهده اسناد مربوط به مالکین به نشانی https://go.k8s.io/owners مراجعه کنید.

# این پروژه محلی‌سازی زبان اسپانیایی است.
# تیم‌ها و اعضا در نشانی https://github.com/orgs/kubernetes/teams قابل مشاهده هستند.

reviewers:
- sig-docs-es-reviews

approvers:
- sig-docs-es-owners

labels:
- area/localization
- language/es

پس از افزودن پرونده OWNERS مختص زبان، پرونده rootOWNERS_ALIASES را با تیم‌های جدید کوبرنتیز برای محلی‌سازی، sig-docs-**-owners و sig-docs-**-reviews به‌روزرسانی کنید.

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

--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -48,6 +48,14 @@ aliases:
     - stewart-yu
     - xiangpengzhao
     - zhangxiaoyu-zidif
+  sig-docs-es-owners: # Admins for Spanish content
+    - alexbrand
+    - raelga
+  sig-docs-es-reviews: # PR reviews for Spanish content
+    - alexbrand
+    - electrocucaracha
+    - glo-pena
+    - raelga
   sig-docs-fr-owners: # Admins for French content
     - perriea
     - remyleone

درخواست ادغام را باز کنید

در مرحله بعد، یک درخواست ادغام را باز کنید (درخواست ادغام) برای افزودن محلی سازی به مخزن «kubernetes/website». درخواست ادغام قبل از تأیید باید شامل همه حداقل محتوای مورد نیاز باشد.

برای مثالی از افزودن یک محلی‌سازی جدید، به درخواست ادغام برای فعال‌سازی مستندات به زبان فرانسوی مراجعه کنید.

یک پرونده README محلی اضافه کنید

برای راهنمایی سایر مشارکت‌کنندگان محلی‌سازی، یک پرونده جدید README-**.md به بالاترین سطح kubernetes/website اضافه کنید، که در آن ** کد دو حرفی زبان است. برای مثال، یک پرونده README آلمانی به صورت README-de.md خواهد بود.

مشارکت کنندگان بومی سازی را در پرونده «README-**.md» بومی سازی شده راهنمایی کنید. همان اطلاعات موجود در «README.md» و همچنین شامل موارد زیر باشد:

  • نقطه تماس برای پروژه بومی‌سازی
  • هرگونه اطلاعات خاص مربوط به محلی‌سازی

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

محلی‌سازی جدید خود را راه‌اندازی کنید

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

بومی‌سازی محتوا

بومی‌سازی تمام مستندات کوبرنتیز کار بسیار بزرگی است. اشکالی ندارد که از مقیاس کوچک شروع کنید و به مرور زمان آن را گسترش دهید.

حداقل محتوای مورد نیاز

حداقل، تمام بومی‌سازی‌ها باید شامل موارد زیر باشند:

توضیحات نشانی‌های اینترنتی
خانه همه نشانی‌های اینترنتی (URL) عنوان و زیرعنوان
نصب همه نشانی‌های اینترنتی (URL) عنوان و زیرعنوان
آموزش‌ها مبانی کوبرنتیز, سلام Minikube
رشته‌های سایت تمام رشته‌های تارنما در یک پرونده TOML جدید و بومی‌سازی‌شده
انتشارات همه نشانی‌های اینترنتی (URL) عنوان و زیرعنوان

اسناد ترجمه شده باید در زیرشاخه content/**/ خود قرار گیرند، اما در غیر این صورت، همان مسیر URL منبع انگلیسی را دنبال کنند. به عنوان مثال، برای تهیه آموزش Kubernetes Basics برای ترجمه به آلمانی، یک زیرشاخه در زیر شاخه content/de/ ایجاد کنید و منبع یا پوشه انگلیسی را رونوشت کنید:

mkdir -p content/de/docs/tutorials
cp -ra content/en/docs/tutorials/kubernetes-basics/ content/de/docs/tutorials/

ابزارهای ترجمه می‌توانند فرآیند ترجمه را سرعت بخشند. برای مثال، برخی از ویراستاران افزونه‌هایی را برای ترجمه سریع متن ارائه می‌دهند.

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

بومی سازی تصاویر SVG

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

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

  1. شناسایی متن قابل ترجمه: با شناسایی عناصر متنی درون تصویر SVG که نیاز به ترجمه دارند، شروع کنید. این عناصر معمولاً شامل برچسب‌ها، زیرنویس‌ها، حاشیه‌نویسی‌ها یا هر متنی هستند که اطلاعات را منتقل می‌کند.

  2. ویرایش پرونده‌های SVG: پرونده های SVG مبتنی بر XML هستند، به این معنی که می‌توان آن‌ها را با استفاده از یک ویرایشگر متن ویرایش کرد. با این حال، توجه به این نکته مهم است که اکثر تصاویر مستندات در کوبرنتیز از قبل متن را به منحنی تبدیل می‌کنند تا از مشکلات سازگاری فونت جلوگیری شود. در چنین مواردی، توصیه می‌شود از نرم‌افزارهای تخصصی ویرایش SVG مانند Inkscape برای ویرایش استفاده کنید، پرونده SVG را باز کنید و عناصر متنی را که نیاز به ترجمه دارند، پیدا کنید.

  3. ترجمه متن: متن اصلی را با نسخه ترجمه شده به زبان مورد نظر جایگزین کنید. مطمئن شوید که متن ترجمه شده به طور دقیق معنای مورد نظر را منتقل می‌کند و در فضای موجود در تصویر جای می‌گیرد. هنگام کار با زبان‌هایی که از الفبای لاتین استفاده می‌کنند، باید از خانواده فونت Open Sans استفاده شود. می‌توانید فونت Open Sans را از اینجا دریافت کنید: فونت Open Sans.

  4. تبدیل متن به منحنی: همانطور که قبلاً ذکر شد، برای رفع مشکلات سازگاری فونت، توصیه می‌شود متن ترجمه شده را به منحنی یا مسیر تبدیل کنید. تبدیل متن به منحنی تضمین می‌کند که تصویر نهایی متن ترجمه شده را به درستی نمایش می‌دهد، حتی اگر سیستم کاربر فونت دقیق استفاده شده در SVG اصلی را نداشته باشد.

  5. بررسی و آزمایش: پس از انجام ترجمه‌های لازم و تبدیل متن به منحنی، تصویر SVG به‌روزرسانی‌شده را ذخیره و بررسی کنید تا از نمایش و ترازبندی صحیح متن اطمینان حاصل شود. پیش‌نمایش تغییرات محلی را بررسی کنید.

پرونده های منبع

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

برای یافتن پرونده های منبع برای نسخه هدف خود:

  1. به مخزن تارنمای کوبرنتیز در نشانی https://github.com/kubernetes/website بروید.

  2. یک شاخه برای نسخه هدف خود از جدول زیر انتخاب کنید:

نسخه هدف شاخه
آخرین نسخه main
نسخه قبلی release-1.32
نسخه بعدی dev-1.34

شاخه‌ی «اصلی» محتوای نسخه فعلی v1.33 را در خود جای داده است. تیم انتشار، قبل از انتشار نسخه بعدی، یک شاخه release-1.33 ایجاد می‌کند: v1.34.

رشته‌های سایت در i18n

محلی‌سازی‌ها باید شامل محتویات ‎i18n/en/en.toml‎ در یک پرونده جدید مختص زبان باشند. به عنوان مثال، از زبان آلمانی استفاده می‌کنیم: i18n/de/de.toml.

یک پوشه و پرونده محلی‌سازی جدید به i18n/ اضافه کنید. برای مثال، با زبان آلمانی (de):

mkdir -p i18n/de
cp i18n/en/en.toml i18n/de/de.toml

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

[ui_search]
other = "Suchen"

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

راهنمای محلی‌سازی مختص زبان

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

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

  • آهنگ سرعت و انتشار
  • راهبرد شاخه
  • گردش کار درخواست ادغام
  • راهنمای شیوه
  • واژه‌نامه اصطلاحات بومی‌سازی‌شده و غیربومی‌سازی‌شده
  • قراردادهای نشانه‌گذاری
  • اصطلاحات شیء کوبرنتیز API

جلسات زوم مخصوص زبان‌های مختلف

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

طبق سیاست CNCF، تیم‌های محلی‌سازی باید جلسات خود را در لیست پخش یوتیوب SIG اسناد بارگذاری کنند. یکی از روسای مشترک یا سرپرست فنی SIG اسناد می‌تواند تا زمان خودکارسازی این فرآیند توسط SIG اسناد به آنها کمک کند.

راهبرد شاخه

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

برای همکاری در یک شاخه محلی‌سازی:

  1. یکی از اعضای تیم @kubernetes/website-maintainers یک شاخه محلی‌سازی از شاخه منبع در https://github.com/kubernetes/website باز می‌کند.

    تأییدکنندگان تیم شما زمانی به تیم @kubernetes/website-maintainers پیوستند که شما تیم محلی‌سازی خود را به مخزن kubernetes/org اضافه کردید.

    ما طرح نامگذاری شاخه زیر را توصیه می‌کنیم:

    dev-<source version>-<language code>.<team milestone>

    برای مثال، یک تأییدکننده در یک تیم محلی‌سازی آلمانی، شاخه محلی‌سازی dev-1.12-de.1 را مستقیماً در مخزن kubernetes/website، بر اساس شاخه منبع برای کوبرنتیز نسخه ۱.۱۲، باز می‌کند.

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

    برای مثال، یک مشارکت‌کننده آلمانی یک درخواست ادغام با تغییرات در kubernetes:dev-1.12-de.1 از username:local-branch-name باز می‌کند.

  3. تأییدکنندگان، شاخه‌های ویژگی را بررسی و در شاخه محلی‌سازی ادغام می‌کنند.

  4. به صورت دوره‌ای، یک تأییدکننده با باز کردن و تأیید یک درخواست ادغام جدید، شاخه محلی‌سازی را با شاخه منبع خود ادغام می‌کند. قبل از تأیید درخواست ادغام، حتماً commitها را squash کنید. مراحل ۱ تا ۴ را در صورت نیاز تا زمان تکمیل بومی‌سازی تکرار کنید. برای مثال، شاخه‌های بومی‌سازی بعدی آلمانی عبارتند از: dev-1.12-de.2، dev-1.12-de.3 و غیره.

تیم‌ها باید محتوای بومی‌سازی‌شده را در همان شاخه‌ای که محتوا از آن تهیه شده است، ادغام کنند. برای مثال:

  • یک شاخه محلی‌سازی که از شاخه اصلی منبع‌گیری شده است، باید در شاخه اصلی ادغام شود.
  • یک شاخه محلی‌سازی که از release-1.32 منبع‌گیری شده است، باید در release-1.32 ادغام شود.

در ابتدای هر مرحله از مراحل پیشرفت تیم، باز کردن یک مسئله برای مقایسه تغییرات بالادستی بین شاخه محلی‌سازی قبلی و شاخه محلی‌سازی فعلی مفید است. دو اسکریپت برای مقایسه تغییرات بالادستی وجود دارد.

  • upstream_changes.py برای بررسی تغییرات اعمال شده در یک پرونده خاص مفید است. و
  • diff_l10n_branches.py برای ایجاد لیستی از پرونده ‌های منسوخ شده برای یک شاخه محلی‌سازی خاص مفید است.

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

برای اطلاعات بیشتر در مورد کار از طریق Fork‌ها یا مستقیماً از مخزن، به "مخزن را fork و clone کنید" مراجعه کنید.

مشارکت‌های بالادستی

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