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

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

آموزش‌ها

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

مبانی

مدیریت کلاستر

1 - سلام Minikube

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

اهداف

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

پیش از شروع

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

توجه:

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

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

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

minikube start

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

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

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

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

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

توجه:

دستور dashboard افزونه داشبورد را فعال می‌کند و یک پراکسی باز کرده و داشبورد را در مرورگر پیش‌فرض شما نمایش می‌دهد. در داشبورد می‌توانید منابعی مثل Deployment و Service ایجاد کنید.

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

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

برای متوقف کردن پراکسی، کلید Ctrl+C را بزنید. پس از خروج، داشبورد همچنان روی کلاستر اجرا می‌شود و فقط پراکسی قطع می‌شود. در صورت نیاز می‌توانید دوباره دستور dashboard را اجرا کنید.

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

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

# یک ترمینال جدید راه‌اندازی کنید و این را در حال اجرا رها کنید..
minikube dashboard --url

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

ساخت Deployment

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

  1. از دستور kubectl create برای ایجاد یک Deployment که یک پاد را مدیریت می‌کند، استفاده کنید. پاد یک کانتینر را بر اساس Docker image ارائه شده اجرا می‌کند.:

    # یک image آزمایشی که شامل یک وب سرور است را اجرا کنید
    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 get pods دریافت کرده‌اید، جایگزین کنید.):

    توجه:

    نام hello-node-5f76cf6ccf-br9b5 را با خروجی دستور kubectl get pods جایگزین کنید.
    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
    

توجه:

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

ساخت Service

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

هشدار:

کانتینر agnhost یک اندپوینت /shell دارد که برای اشکال‌زدایی(debuggin) مفید است، اما expose کردن آن در اینترنت عمومی خطرناک است. این را روی یک کلاستر متصل به اینترنت یا یک کلاستر عملیاتی اجرا نکنید.
  1. با استفاده از دستور kubectl expose، پاد را در اینترنت عمومی expose کنید:

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

--type=LoadBalancer نشان می‌دهد که شما می‌خواهید سرویس خود را در خارج از کلاستر expose کنید.

کد برنامه درون image آزمایشی فقط به پورت TCP 8080 گوش می‌دهد. اگر از kubectl expose برای expose کردن پورت دیگری استفاده می‌کردید، کلاینت‌ها نمی‌توانستند به آن پورت دیگر متصل شوند.

  1. مشاهده 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
    

در ارائه‌دهندگان ابری که از متعادل‌کننده‌های بار(Load Balancers) پشتیبانی می‌کنند، یک آدرس IP خارجی برای دسترسی به سرویس فراهم می‌شود. در minikube، نوع LoadBalancer سرویس را از طریق دستور minikube service قابل دسترسی می‌کند.

  1. دستور زیر را اجرا کنید:

    minikube service hello-node
    

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

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

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

  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-server را بررسی کنید:

    kubectl top pods
    

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

    error: Metrics API not available
    
  5. غیرفعال کردن metrics-server:

    minikube addons disable metrics-server
    

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

    metrics-server was successfully disabled

پاکسازی

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

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

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

minikube stop

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

# Optional
minikube delete

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

نتیجه‌گیری

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

گام‌های بعدی

2 - مدیریت کلاستر

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

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

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

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

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

اهداف

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

احتیاط:

پیکربندی kubelet که برای این آموزش استفاده شده است، از نظر طراحی ناامن است و نباید در محیط عملیاتی استفاده شود

پیش از شروع

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

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

پیکربندی Swap

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

توجه:

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

اگر حافظه 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

توجه:

از آنجا که شما در حال راه‌اندازی یک کلاستر عملیاتی نیستید، از HTTP ساده (readOnlyPort: 10255) برای کوئری‌های احراز هویت نشده به API kubelet استفاده می‌کنید

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

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

نصب:

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 برای پیکربندی کانتینرها در یک پاد ایستا استفاده کنید.

گام‌های بعدی

2.2 - راهنمای namespace

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

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

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

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

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

پیش از شروع

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

برای بررسی نسخه، وارد کنید kubectl version.

پیش‌نیازها

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

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

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

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

با فرض اینکه یک کلاستر جدید دارید، می‌توانید با انجام موارد زیر، namespace موجود را بررسی کنید:

kubectl get namespaces
NAME      STATUS    AGE
default   Active    13m

ایجاد namespace جدید

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

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

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

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

یکی از الگوهایی که این سازمان می‌تواند دنبال کند، تقسیم‌بندی کلاستر کوبرنتیز به دو namespace است: «توسعه» و «تولید».

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

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

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    name: development

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

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

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

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    name: production

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

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

برای اطمینان از درست بودن همه چیز، بیایید تمام namespace موجود در کلاستر خود را فهرست کنیم.

kubectl get namespaces --show-labels
NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production

ایجاد پادها در هر namespace

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

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

برای نشان دادن این موضوع، بیایید یک استقرار و پادهای ساده را در namespace 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 است تا در هر namespace کار کند. مقدار فیلدهای "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ها را مشاهده کنید و بسته به namespaceی که می‌خواهید با آن کار کنید، متناوب با دو 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

بیایید به namespace «development» تغییر دهیم.

kubectl config use-context dev

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

kubectl config current-context
dev

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

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

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

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

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

kubectl config use-context prod

namespace 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

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

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