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

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

مستندات

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

1.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

1.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

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

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

2 - مرجع

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

مرجع 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هایی هستند که توسط پروژه کوبرنتیز تعریف شده‌اند، اما توسط پروژه اصلی پیاده‌سازی نشده‌اند:

اسناد طراحی

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

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

2.1 - واژه‌نامه

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

.

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

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

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

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

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

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

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

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