podman-kube-play(1) General Commands Manual podman-kube-play(1)

podman-kube-play - ایجاد کانتینرها، پادها و حجم‌ها بر پایه YAML کوبرنتیز

podman kube play [گزینه‌ها] file.yml|-|https://website.io/file.yml

دستور podman kube play یک فایل ساختاریافته از YAML کوبرنتیز را می‌خواند. این دستور کانتینرها، پادها یا حجم‌های توصیف‌شده در YAML را مجدداً ایجاد می‌کند. سپس کانتینرهای درون یک پاد راه‌اندازی می‌شوند و شناسه (ID) پاد جدید یا نام حجم جدید در خروجی نمایش داده می‌شود. اگر فایل YAML به‌صورت «-» مشخص شود، podman kube play فایل YAML را از ورودی استاندارد (stdin) می‌خواند. ورودی می‌تواند همچنین یک URL باشد که به یک فایل YAML اشاره دارد، مانند https://podman.io/demo.yml. دستور podman kube play فایل YAML را از نشانی URL خوانده و از روی آن پادها و کانتینرها را ایجاد می‌کند.

با استفاده از گزینه خط فرمان --down، این دستور همچنین قادر است پادهای ایجادشده توسط اجرای قبلی podman kube play را متوقف و حذف کند (از کار بیندازد).

با استفاده از گزینه خط فرمان --replace، این دستور پادهای ایجادشده توسط اجرای قبلی podman kube play (در صورت وجود) را متوقف و حذف کرده و پادها را مجدداً با فایل YAML کوبرنتیز از نو می‌سازد.

در حالت ایده‌آل، فایل ورودی توسط دستور پادمن ایجاد می‌شود (به podman-kube-generate(1) مراجعه کنید). این کار واردسازی بدون مشکل و نتایج مورد انتظار را تضمین می‌کند.

در حال حاضر، انواع (kinds) پشتیبانی‌شده در کوبرنتیز عبارتند از:

  • Pod
  • Deployment
  • PersistentVolumeClaim
  • ConfigMap
  • Secret
  • DaemonSet
  • Job

پادها یا استقرارهای کوبرنتیز (Kubernetes Pods or Deployments)

تنها پنج نوع حجم توسط kube play پشتیبانی می‌شوند: انواع حجم hostPath، emptyDir، configMap، persistentVolumeClaim و image.

  • هنگام استفاده از نوع حجم hostPath، تنها زیرنوع‌های default (empty)، DirectoryOrCreate، Directory، FileOrCreate، File، Socket، CharDevice و BlockDevice پشتیبانی می‌شوند. پادمن مقدار path در hostPath را زمانی که حداقل شامل یک اسلش مایل به جلو (/) باشد به عنوان مسیر فایل تفسیر می‌کند؛ در غیر این صورت، پادمن آن مقدار را به عنوان نام یک حجم نام‌دار (named volume) در نظر می‌گیرد.
  • هنگام استفاده از persistentVolumeClaim، مقدار claimName به عنوان نام حجم نام‌دار پادمن خواهد بود.
  • هنگام استفاده از یک حجم emptyDir، پادمن یک حجم ناشناس ایجاد می‌کند که به کانتینرهای در حال اجرا درون پاد متصل می‌شود و پس از حذف پاد، این حجم نیز پاک می‌گردد.
  • هنگام استفاده از یک حجم configMap، پادمن یک حجم ناشناس ایجاد می‌کند که به کانتینرهای در حال اجرا درون پاد متصل شده و پس از حذف پاد پاک می‌شود.
  • هنگام استفاده از نوع حجم image، پادمن یک حجم ایمیج فقط‌خواندنی با زیرمسیر خالی ایجاد می‌کند (کل ایمیج متصل می‌شود). این ایمیج باید از قبل به‌صورت محلی وجود داشته باشد. این قابلیت فقط در حالت دارای ریشه (rootful) پشتیبانی می‌شود.

نکته: سیاست بازنشانی پیش‌فرض برای کانتینرها always است. می‌توانید مقدار پیش‌فرض را با تنظیم فیلد restartPolicy در مشخصات (spec) تغییر دهید.

نکته: هنگام اجرای فایل YAML کوبرنتیز حاوی کانتینرهای راه‌انداز (init containers)، کانتینر راه‌انداز با نوع راه‌اندازی once ایجاد می‌شود. برای تغییر نوع پیش‌فرض، از حاشیه‌نویسی io.podman.annotations.init.container.type برای تنظیم نوع به always استفاده کنید.

نکته: انواع حجم hostPath ایجادشده توسط kube play یک برچسب مشترک SELinux به صورت (z) دریافت می‌کنند؛ اتصالات بایند (bind mounts) مجدداً برچسب‌گذاری نمی‌شوند (از chcon -t container_file_t -R <directory> استفاده کنید).

نکته: برای تنظیم فضای نام کاربری (userns) یک پاد، از حاشیه‌نویسی io.podman.annotations.userns در تعریف pod/deployment استفاده کنید. برای مثال، حاشیه‌نویسی io.podman.annotations.userns=keep-id به پادمن دستور می‌دهد یک فضای نام کاربری ایجاد کند که در آن شناسه کاربری و گروهی (UID:GID) کاربر بدون ریشه فعلی به همان مقادیر درون کانتینر نگاشت شوند. این مقدار را می‌توان با پرچم --userns بازنویسی کرد.

نکته: از حاشیه‌نویسی io.podman.annotations.volumes-from برای اتصال حجم‌های یک کانتینر به کانتینر دیگر استفاده کنید. می‌توانید حجم‌ها را از چندین کانتینر مبدأ بر روی یک کانتینر مقصد سوار کنید. کانتینرهای مبدأ که متعلق به همان پاد هستند باید قبل از کانتینر مقصد در فایل YAML کوبرنتیز تعریف شوند. قالب این حاشیه‌نویسی به صورت io.podman.annotations.volumes-from/targetContainer: "sourceContainer1:mountOpts1;sourceContainer2:mountOpts2" است.

نکته: در صورت استفاده از برچسب :latest، پادمن تلاش می‌کند تا ایمیج را از رجیستری دریافت کند. اگر ایمیج به‌صورت محلی با پادمن یا Buildah ساخته شده باشد، دارای دامنه localhost است که در این حالت، پادمن حتی در صورت وجود تگ :latest از ایمیج موجود در مخزن محلی استفاده می‌کند.

نکته: دستور podman play kube نام مستعاری برای podman kube play بوده و عملکرد یکسانی دارد.

نکته: از دستور podman kube down می‌توان برای متوقف کردن و حذف پادها یا کانتینرها بر اساس همان فایل YAML کوبرنتیز که توسط podman kube play برای ایجاد آن‌ها استفاده شده، بهره برد.

نکته: برای سفارشی‌سازی نام کانتینر زیرساخت (infra container) ایجادشده در حین podman kube play، از حاشیه‌نویسی io.podman.annotations.infra.name در تعریف پاد استفاده کنید. این حاشیه‌نویسی هنگام تولید یک yaml کوبرنتیز از پادی که با تنظیم پرچم --infra-name ایجاد شده باشد، به‌طور خودکار تنظیم می‌گردد.

نکته: از حاشیه‌نویسی io.podman.annotations.pids-limit/$ctrname برای پیکربندی محدودیت تعداد شناسه‌های فرایند (pids limit) در پاد استفاده کنید.

نکته: از حاشیه‌نویسی io.podman.annotations.cpuset/$ctrname برای محدود کردن اجرای یک کانتینر به مجموعه‌ای خاص از هسته‌های پردازنده (CPU) استفاده کنید. این معادل گزینه --cpuset-cpus=number در podman-run(1) است.

نکته: از حاشیه‌نویسی io.podman.annotations.memory-nodes/$ctrname برای محدود کردن تخصیص‌های حافظه کانتینر به مجموعه‌ای خاص از گره‌های حافظه در سیستم‌های NUMA استفاده کنید. این معادل گزینه --cpuset-mems=nodes در podman-run(1) است.

ادعاهای حجم دائمی کوبرنتیز (Kubernetes PersistentVolumeClaims)

یک PersistentVolumeClaim در کوبرنتیز نمایانگر یک حجم نام‌دار پادمن است. پادمن برای ایجاد حجم تنها به نام PersistentVolumeClaim نیاز دارد. می‌توان از حاشیه‌نویسی‌های کوبرنتیز برای بهره‌گیری از گزینه‌های موجود حجم‌های پادمن استفاده کرد.

  • volume.podman.io/driver
  • volume.podman.io/device
  • volume.podman.io/type
  • volume.podman.io/uid
  • volume.podman.io/gid
  • volume.podman.io/mount-options
  • volume.podman.io/import-source
  • volume.podman.io/image

از volume.podman.io/import-source برای وارد کردن محتویات فایل فشرده تار (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz, .tar.zst) مشخص‌شده در مقدار حاشیه‌نویسی به درون حجم ایجادشده در پادمن استفاده کنید.

دستور kube play در صورت وجود چیدمان مناسب دایرکتوری و فایل‌های Containerfile، توانایی ساخت آنی ایمیج‌ها را دارد. این گزینه هنوز برای کلاینت‌های راه دور، از جمله ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نیست. بخش زیر از یک فایل YAML را در نظر بگیرید:

apiVersion: v1
kind: Pod
metadata:
...
spec:
  containers:
  - name: container
    image: foobar
...

اگر دایرکتوری به نام foobar در دایرکتوری کاری فعلی با فایلی به نام Containerfile یا Dockerfile وجود داشته باشد، Podman kube play آن ایمیج را ساخته و نام آن را foobar می‌گذارد. ساختار دایرکتوری نمونه برای این مثال به شکل زیر است:

|- mykubefiles
    |- myplayfile.yaml
    |- foobar
         |- Containerfile

فرایند ساخت، دایرکتوری foobar را به عنوان دایرکتوری بافت (context directory) ساخت در نظر می‌گیرد. اگر ایمیجی به نام foobar در حافظه ذخیره‌سازی محلی وجود داشته باشد، ایمیج ساخته نمی‌شود مگر اینکه از پرچم --build استفاده شود. از --build=false برای غیرفعال کردن کامل ساخت ایمیج استفاده کنید.

دستور Kube play از انتخاب‌کننده‌های دستگاه CDI (رابط دستگاه کانتینر) برای اشتراک‌گذاری دستگاه‌های میزبان (مانند پردازنده‌های گرافیکی یا GPUها) با کانتینرها پشتیبانی می‌کند. ساختار پیکربندی از مدیریت منابع توسعه‌یافته کوبرنتیز پیروی می‌کند:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: container
    resources:
      limits:
        nvidia.com/gpu=all: 1

برای فعال‌سازی اشتراک‌گذاری دستگاه‌های میزبان، مشابه با استفاده از پرچم --device، پادمن کیوب از یک انتخاب‌کننده سفارشی CDI پشتیبانی می‌کند: podman.io/device=<host device path>.

کانفیگ‌مپ کوبرنتیز (Kubernetes ConfigMap)

کانفیگ‌مپ کوبرنتیز می‌تواند به عنوان یک منبع متغیرهای محیطی یا حجم‌ها در پادها یا استقرارها ارجاع داده شود. کانفیگ‌مپ‌ها یک شیء مستقل در پادمن نیستند؛ در عوض، هنگامی که کانتینری از یک ConfigMap استفاده می‌کند، پادمن بر حسب نیاز متغیرهای محیطی یا حجم‌ها را ایجاد می‌نماید.

به عنوان مثال، سند YAML زیر یک ConfigMap را تعریف کرده و سپس در یک پاد از آن بهره می‌برد:

apiVersion: v1
kind: ConfigMap
metadata:
  name: foo
data:
    FOO: bar
---
apiVersion: v1
kind: Pod
metadata:
  name: foobar
spec:
  containers:
  - name: container-1
    image: foobar
    envFrom:
    - configMapRef:
        name: foo
        optional: false

و در نتیجه متغیر محیطی FOO برای کانتینر container-1 برابر با bar تنظیم می‌شود.

سکرت کوبرنتیز (Kubernetes Secret)

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

به عنوان مثال، سند YAML زیر یک Secret را تعریف کرده و سپس در یک پاد از آن استفاده می‌کند:

kind: Secret
apiVersion: v1
metadata:
  name: foo
data:
  foo: YmFy # base64 for bar
---
apiVersion: v1
kind: Pod
metadata:
  name: foobar
spec:
  containers:
  - name: container-1
    image: foobar
    env:
    - name: FOO
      valueFrom:
        secretKeyRef:
          name: foo
          key: foo

و در نتیجه متغیر محیطی FOO برای کانتینر container-1 برابر با bar تنظیم می‌شود.

سوار کردن خودکار حجم‌ها (منسوخ‌شده) (Automounting Volumes (deprecated))

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

اگر حاشیه‌نویسی io.podman.annotations.kube.image.automount/$ctrname مشخص شده باشد، یک ایمیج می‌تواند به‌طور خودکار درون کانتینر سوار شود. قواعد زیر اعمال می‌گردند:

  • ایمیج باید از قبل به‌صورت محلی وجود داشته باشد.
  • ایمیج باید حداقل دارای ۱ دستورالعمل حجم (volume directive) باشد.
  • مسیری که با دستورالعمل حجم مشخص شده است از درون ایمیج بر روی کانتینر متصل می‌شود. به عنوان مثال، ایمیجی با یک حجم در مسیر /test/test_dir، دایرکتوری /test/test_dir ایمیج را به /test/test_dir در کانتینر متصل می‌کند.
  • امکان تعیین چندین ایمیج وجود دارد. اگر چندین ایمیج در یک مسیر مشخص دارای حجم باشند، آخرین ایمیج مشخص‌شده اولویت خواهد داشت.
  • ایمیج‌ها همواره به‌صورت فقط‌خواندنی سوار می‌شوند.
  • ایمیج‌ها برای سوار شدن در حاشیه‌نویسی "io.podman.annotations.kube.image.automount/$ctrname" به صورت فهرستی جداشده با نقطه ویرگول (;) تعریف می‌شوند. آنها در یک کانتینر منفرد در پاد سوار می‌شوند، نه در کل پاد. در صورت نیاز به اتصالات بیشتر، می‌توان این حاشیه‌نویسی را برای کانتینرهای اضافی نیز مشخص نمود.

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

نکته: برای podman kube play، پرچم --annotation حاشیه‌نویسی‌های مختص پادمن را به کانتینرها و پادهای ایجادشده توسط پادمن اضافه می‌کند، نه به خود فایل YAML کوبرنتیز. از این حاشیه‌نویسی‌ها می‌توان برای پیکربندی قابلیت‌های مختص پادمن مانند فضاهای نام کاربری (io.podman.annotations.userns)، حجم‌های مشترک (io.podman.annotations.volumes-from) و سایر رفتارهای کانتینر بهره برد.

مسیر فایل احراز هویت. پیش‌فرض در لینوکس ${XDG_RUNTIME_DIR}/containers/auth.json و در ویندوز/مک‌او‌اس $HOME/.config/containers/auth.json است. این فایل توسط دستور podman login ایجاد می‌شود. اگر وضعیت احراز هویت در آنجا پیدا نشود، مسیر $HOME/.docker/config.json که با استفاده از docker login تنظیم می‌شود مورد بررسی قرار می‌گیرد.

نکته: این امکان نیز وجود دارد که مسیر پیش‌فرض فایل احراز هویت با تنظیم متغیر محیطی REGISTRY_AUTH_FILE بازنویسی شود. این کار با دستور export REGISTRY_AUTH_FILE=path انجام می‌پذیرد.

ساخت ایمیج‌ها حتی در صورتی که در حافظه ذخیره‌سازی محلی یافت شوند. برای غیرفعال کردن کامل ساخت ایمیج از --build=false استفاده کنید. (این گزینه با کلاینت راه دور پادمن در دسترس نیست)

نکته: شما همچنین می‌توانید نوع جداسازی پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_ISOLATION بازنویسی کنید: export BUILDAH_ISOLATION=oci. برای اطلاعات بیشتر به podman-build.1.md مراجعه فرمایید.

استفاده از گواهی‌های موجود در مسیر path (شامل *.crt, *.cert, *.key) برای برقراری ارتباط با رجیستری (پیش‌فرض: /etc/containers/certs.d). برای جزئیات به containers-certs.d(5) مراجعه کنید. (این گزینه در کلاینت راه دور پادمن، از جمله ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نمی‌باشد)

استفاده از YAML کانفیگ‌مپ کوبرنتیز در مسیر path جهت تامین مقادیر متغیرهای محیطی درون کانتینرهای پاد. (این گزینه در کلاینت راه دور پادمن در دسترس نیست)

نکته: گزینه --configmap را می‌توان چندین بار به کار برد، یا فهرستی جداشده با کاما از مسیرها را جهت ارسال چندین YAML کانفیگ‌مپ کوبرنتیز استفاده کرد. فایل YAML می‌تواند در قالب چندسندی (multi-doc) باشد؛ اما باید تنها شامل ConfigMapها باشد.

استفاده از مسیر path به عنوان دایرکتوری بافت ساخت برای هر ایمیج. نیازمند آن است که گزینه --build روی true تنظیم شده باشد. (این گزینه در کلاینت راه دور پادمن در دسترس نیست)

نام کاربری و گذرواژه [username[:password]] جهت استفاده برای احراز هویت در رجیستری، در صورت نیاز. اگر یک یا هر دو مقدار ارائه نشوند، اعلانی در خط فرمان ظاهر شده و می‌توان مقدار را وارد کرد. گذرواژه بدون بازتاب (echo) دریافت می‌شود.

توجه داشته باشید که اطلاعات هویتی مشخص‌شده تنها برای احراز هویت در مقابل رجیستری‌های هدف به کار می‌روند. از آنها برای آینه‌ها (mirrors) یا زمان بازنویسی آدرس رجیستری استفاده نمی‌شود (به containers-registries.conf(5) مراجعه کنید)؛ برای احراز هویت در مقابل آنها، استفاده از یک فایل containers-auth.json(5) را مد نظر قرار دهید.

حذف و پاک‌سازی حجم‌های متصل به PersistentVolumeClaimها به عنوان بخشی از گزینه --down.

چاپ راهنمای دستور.

اختصاص یک آدرس IP ایستا به پاد. زمانی که kube play بیش از یک پاد ایجاد می‌کند، این گزینه را می‌توان چندین بار مشخص کرد. نکته: هنگام پیوستن به چندین شبکه از ساختار --network name:ip=<ip> استفاده نمایید.

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

گزینه‌های اختصاصی درایور لاگ‌گیری.

تنظیم پیکربندی لاگ‌گیری سفارشی. مقادیر *name* زیر پشتیبانی می‌شوند:

path: تعیین مسیر فایل گزارش
(مانند --log-opt path=/var/log/container/mycontainer.json)؛

max-size: تعیین حداکثر اندازه فایل گزارش
(مانند --log-opt max-size=10mb)؛

tag: تعیین یک برچسب (tag) گزارش سفارشی برای کانتینر
(مانند --log-opt tag=";{{.ImageName}}". این گزینه از همان کلیدهای podman inspect --format پشتیبانی می‌کند. این گزینه در حال حاضر تنها توسط درایور لاگ‌گیری journald پشتیبانی می‌شود.

label: تعیین یک لیبل گزارش سفارشی برای کانتینر
(مانند --log-opt label="CONTAINER_IMAGE={{.ImageName}}". این گزینه از همان کلیدهای podman inspect --format پشتیبانی می‌کند. این گزینه می‌تواند چندین بار تکرار شود. این گزینه در حال حاضر تنها توسط درایور لاگ‌گیری journald پشتیبانی می‌شود.

اختصاص یک آدرس MAC ایستا به پاد. هنگامی که kube play بیش از یک پاد ایجاد می‌کند، این گزینه را می‌توان چندین بار تعیین کرد. نکته: هنگام پیوستن به چندین شبکه از ساختار --network name:mac=<mac> استفاده کنید.

تنظیم حالت شبکه برای پاد.

مقادیر معتبر mode عبارتند از:

•
bridge[:OPTIONS,...]: ایجاد یک پشته شبکه روی پل (bridge) پیش‌فرض. این حالت پیش‌فرض برای کانتینرهای دارای ریشه (rootful) است. امکان تعیین گزینه‌های اضافی زیر وجود دارد:
  • alias=name: افزودن نام مستعار در حوزه شبکه برای کانتینر.
  • ip=IPv4: تعیین آدرس IPv4 ایستا برای این کانتینر.
  • ip6=IPv6: تعیین آدرس IPv6 ایستا برای این کانتینر.
  • mac=MAC: تعیین آدرس MAC ایستا برای این کانتینر.
  • interface_name=name: تعیین یک نام برای رابط شبکه ایجادشده در داخل کانتینر.
  • host_interface_name=name: تعیین یک نام برای رابط شبکه ایجادشده در خارج از کانتینر (روی میزبان).
هر گزینه دیگری بدون اعتبارسنجی به netavark ارسال خواهد شد. این موضوع می‌تواند برای ارسال آرگومان‌ها به پلاگین‌های netavark مفید باشد.

برای شبکه‌های پل بدون ریشه (rootless bridge)، هدایت پورت به‌طور پیش‌فرض از rootlessport استفاده می‌کند. تنظیم rootless_port_forwarder="pasta" در بخش [network] فایل containers.conf(5)، هدایت را به سازوکار سطح هسته pasta (از طریق pesto) تغییر می‌دهد که آدرس IP مبدأ کلاینت اصلی را درون کانتینر حفظ می‌کند. این گزینه آزمایشی بوده و رفتار آن ممکن است در آینده تغییر کند.

برای مثال، جهت تنظیم یک آدرس IPv4 ایستا و یک آدرس MAC ایستا، از دستور --network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99 استفاده نمایید.

  • <network name or ID>[:OPTIONS,...]: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این نام یا شناسه شبکه‌ای است که توسط podman network create ساخته شده است. امکان تعیین گزینه‌های مشابه شرح داده شده در بخش bridge بالا وجود دارد. برای مشخص کردن شبکه‌های بیشتر از گزینه --network به دفعات استفاده کنید.
    جهت سازگاری با گذشته، می‌توان شبکه‌های جداشده با کاما را نیز در اولین آرگومان --network مشخص کرد؛ هرچند این کار مانع از استفاده شما از گزینه‌های تشریح‌شده در بخش bridge بالا می‌شود.
  • none: ایجاد یک فضای نام شبکه برای کانتینر اما بدون پیکربندی رابط‌های شبکه برای آن؛ بنابراین کانتینر هیچ‌گونه اتصال شبکه‌ای نخواهد داشت.
  • container:id: استفاده مجدد از پشته شبکه یک کانتینر دیگر.
  • host: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام مجزا. هشدار: این کار دسترسی کامل به سوکت‌های انتزاعی دامنه یونیکس و سوکت‌های TCP/UDP مقید به localhost را به کانتینر می‌دهد. از آنجا که این سازوکارها اغلب برای جلوگیری از دسترسی به سرویس‌های حساس سیستم و جداسازی آنها از موجودیت‌های خارجی استفاده می‌شوند، استفاده از این گزینه ممکن است یک آسیب‌پذیری امنیتی تلقی گردد.
  • ns:path: مسیر فضای نام شبکه‌ای که کانتینر باید به آن ملحق شود.
  • private: ایجاد یک فضای نام جدید برای کانتینر. در کانتینرهای با ریشه (rootful) از حالت bridge و در کانتینرهای بدون ریشه (rootless) از pasta استفاده می‌شود.
  • pasta[:OPTIONS,...]: استفاده از pasta(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode).
    این حالت پیش‌فرض برای کانتینرهای بدون ریشه بوده و تنها در حالت rootless پشتیبانی می‌شود.
    به‌طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط پاد از میزبان کپی می‌شوند. هدایت پورت، آدرس IP مبدأ اولیه را حفظ می‌کند. گزینه‌های تشریح‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما مشخص نمود.
    از نظر گزینه‌های pasta(1)، گزینه --config-net به‌طور پیش‌فرض داده می‌شود تا در زمان راه‌اندازی کانتینر، شبکه پیکربندی شود؛ همچنین گزینه --no-map-gw نیز به‌طور پیش‌فرض اعمال می‌شود تا از دسترسی مستقیم از کانتینر به میزبان با استفاده از آدرس درگاه (gateway) جلوگیری گردد. مورد اخیر را می‌توان با ارسال --map-gw در گزینه‌های خاص pasta لغو کرد (اگرچه این یک گزینه واقعی در pasta(1) نیست).
    جهت یکپارچگی بهتر با مدیریت DNS، مقدار --dns-forward 169.254.1.1 به‌طور پیش‌فرض ارسال می‌شود و این نشانی به عنوان نخستین تحلیل‌گر به resolv.conf(5) اضافه می‌گردد. در صورتی که نیاز به استفاده از آدرس IP متفاوتی باشد، می‌توان --dns-forward را به‌طور صریح مشخص کرد.
    برای عملکرد صحیح مدخل host.containers.internal در /etc/hosts و اجازه برقراری ارتباط با میزبان، گزینه --map-guest-addr 169.254.1.2 به‌طور پیش‌فرض ارسال می‌شود. مجدداً می‌توان آن را به‌طور صریح برای انتخاب آدرس IP دیگر تنظیم کرد.
    همچنین در صورتی که هیچ هدایت پورت TCP یا UDP از میزبان به کانتینر پیکربندی نشده باشد (از طریق --publish پادمن یا ارسال مستقیم گزینه‌های -t/-u در pasta)، به ترتیب مقادیر -t none و -u none ارسال می‌شوند تا فوروارد خودکار پورت بر اساس پورت‌های مقید غیرفعال گردد. به طور مشابه، -T none و -U none برای غیرفعال کردن عملکرد مشابه از سمت کانتینر به میزبان ارسال می‌گردند.
    تمامی گزینه‌ها را می‌توان در containers.conf(5) نیز پیکربندی کرد؛ کلید pasta_options در زیر بخش network آن فایل را مشاهده کنید.
    چند مثال:
  • pasta:--map-gw: اجازه دسترسی مستقیم به میزبان با استفاده از آدرس درگاه (gateway).
  • pasta:--mtu,1500: تعیین MTU معادل ۱۵۰۰ بایت برای رابط tap درون کانتینر.
  • pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp: غیرفعال کردن IPv6، تخصیص 10.0.2.0/24 به رابط tap0 کانتینر، با درگاه 10.0.2.2، فعال کردن فورواردر DNS در دسترس روی 10.0.2.3، تنظیم MTU روی ۱۵۰۰ بایت، و غیرفعال‌سازی پشتیبانی از NDP، DHCPv6 و DHCP.
  • pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp: همانند مورد قبل، با حفظ مقدار MTU روی ۶۵۵۲۰ بایت.
  • pasta:-t,auto,-u,auto,-T,auto,-U,auto: فعال‌سازی هدایت خودکار پورت بر اساس پورت‌های متصل مشاهده‌شده از هر دو سوی میزبان و کانتینر.
  • pasta:-T,5201: فعال‌سازی هدایت پورت TCP شماره ۵۲۰۱ از کانتینر به میزبان با استفاده از رابط loopback به جای رابط tap به منظور بهبود عملکرد.

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

عدم ایجاد فایل /etc/hostname در کانتینرها.

به‌طور پیش‌فرض، پادمن فایل /etc/hostname را مدیریت کرده و نام میزبان خود کانتینر را درج می‌نماید. هنگامی که گزینه --no-hostname تنظیم شود، در صورت وجود فایل /etc/hostname در ایمیج، بدون تغییر حفظ خواهد شد.

عدم تغییر فایل /etc/hosts درون پاد.

پادمن به‌طور پیش‌فرض کنترل فایل /etc/hosts پاد را به عهده می‌گیرد و مدخل‌هایی برای نام کانتینر (به گزینه --name مراجعه کنید)، نام میزبان (به گزینه --hostname مراجعه کنید)، میزبان‌های داخلی host.containers.internal و host.docker.internal، و همچنین هر نام میزبانی که با گزینه --add-host اضافه شده باشد در آن قرار می‌دهد. برای جزئیات به گزینه --add-host رجوع کنید. ارسال گزینه --no-hosts این رفتار را غیرفعال می‌سازد تا فایل /etc/hosts ایمیج دست‌نخورده باقی بماند. همین نتیجه را می‌توان با تنظیم سراسری no_hosts=true در containers.conf حاصل کرد.

این گزینه با میزبان‌های اضافه شده در YAML کوبرنتیز ناسازگار است.

عدم افزودن نام پاد به عنوان پیشوند نام کانتینر.

تعریف یا بازنویسی تعریف پورت در فایل YAML.

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

تنظیم این گزینه روی true تمام پورت‌ها را روی میزبان منتشر (هدایت) می‌کند، حتی اگر تنها از طریق containerPort در YAML کوبرنتیز مشخص شده باشند. از دیدگاه اینکه کدام پورت منتشر خواهد شد، --publish اولویت بالاتری نسبت به hostPort دارد، و hostPort اولویت بالاتری نسبت به containerPort دارد.

اگر این گزینه روی false (مقدار پیش‌فرض) تنظیم شود، تنها پورت‌هایی که از طریق hostPort یا --publish تعریف شده باشند روی میزبان منتشر می‌گردند.

جلوگیری از چاپ اطلاعات خروجی هنگام دریافت ایمیج‌ها.

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

مسیر دایرکتوری برای نمایه‌های seccomp (پیش‌فرض: "/var/lib/kubelet/seccomp"). (این گزینه با کلاینت راه دور پادمن، از جمله ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نیست)

راه‌اندازی پاد پس از ایجاد آن؛ برای ایجاد صرف بدون راه‌اندازی، آن را روی false تنظیم کنید.

الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام ارتباط با رجیستری‌ها (پیش‌فرض: true). در صورت تنظیم صریح روی true، اعتبارسنجی TLS انجام می‌گیرد. اگر روی false تنظیم شود، اعتبارسنجی TLS انجام نخواهد شد. اگر مشخص نشود، اعتبارسنجی TLS اعمال می‌شود مگر آنکه رجیستری هدف در containers-registries.conf(5) به عنوان یک رجیستری ناامن ذکر شده باشد.

تنظیم حالت فضای نام کاربری (user namespace) برای کانتینر.

اگر --userns مشخص نشود، مقدار پیش‌فرض به شکل زیر تعیین می‌گردد: - اگر --pod تنظیم شده باشد، --userns نادیده گرفته شده و از فضای نام کاربری پاد استفاده می‌شود. - اگر متغیر محیطی PODMAN_USERNS تنظیم شده باشد، مقدار آن اعمال می‌گردد. - اگر userns در containers.conf تعیین شده باشد، آن مقدار استفاده می‌شود. - در غیر این صورت، --userns=host فرض خواهد شد.

مقدار --userns="" (یعنی یک رشته خالی) نام مستعاری برای --userns=host است.

این گزینه با گزینه‌های --gidmap، --uidmap، --subuidname و --subgidname ناسازگار است.

نگاشت‌های کلید (Key) در --userns برای کاربر بدون ریشه (rootless):

کلید (Key) کاربر میزبان (Host User) کاربر کانتینر (Container User)
auto $UID nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.)
host $UID 0 (حساب کاربری پیش‌فرض به کاربر root درون کانتینر نگاشت می‌شود.)
keep-id $UID $UID (نگاشت حساب کاربری به همان مقدار UID در درون کانتینر.)
keep-id:uid=200,gid=210 $UID 200:210 (نگاشت حساب کاربری به مقادیر UID و GID مشخص‌شده در کانتینر.)
nomap $UID nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.)

مقادیر معتبر mode عبارتند از:

auto[:OPTIONS,...]: ایجاد خودکار یک فضای نام کاربری منحصربه‌فرد.

  • حالت دارای ریشه (rootful mode): پرچم --userns=auto مستلزم آن است که نام کاربری containers در فایل‌های /etc/subuid و /etc/subgid با محدوده‌ای استفاده‌نشده از شناسه‌های کاربری فرعی (subordinate) که کانتینرهای پادمن مجاز به تخصیص آن‌ها هستند مشخص شده باشد. مثال: containers:2147483647:2147483648.
  • حالت بدون ریشه (rootless mode): محدوده کاربران از فایل‌های /etc/subuid و /etc/subgid استفاده خواهد شد. توجه داشته باشید که اجرای یک کانتینر منفرد بدون استفاده از --userns=auto از کل محدوده UIDها استفاده کرده و امکان تقسیم‌بندی بیشتر را نمی‌دهد. به subuid(5) مراجعه کنید.

پادمن محدوده‌های منحصربه‌فردی از UIDها و GIDها را از شناسه‌های کاربری فرعی containers تخصیص می‌دهد. اندازه این محدوده‌ها بر اساس تعداد UIDهای مورد نیاز در ایمیج تعیین می‌شود. تعداد UIDها و GIDها را می‌توان با گزینه size بازنویسی کرد.

گزینه --userns=keep-id از تمامی subuidها و subgidهای کاربر بهره می‌برد. گزینه --userns=nomap از تمامی subuidها و subgidهای کاربر به جز شناسه خود کاربر استفاده می‌کند. استفاده از --userns=auto هنگام راه‌اندازی کانتینرهای جدید تا زمانی که کانتینرهایی وجود داشته باشند که با --userns=nomap یا --userns=keep-id بدون محدود کردن اندازه فضای نام کاربری شروع به کار کرده‌اند، عمل نخواهد کرد.

گزینه‌های معتبر auto:

  • gidmapping=CONTAINER_GID:HOST_GID:SIZE: برای اجبار به وجود یک نگاشت GID در فضای نام کاربری.
  • size=SIZE: جهت تعیین اندازه صریح برای فضای نام کاربری خودکار، برای مثال --userns=auto:size=8192. اگر size مشخص نشود، auto اندازه‌ای را برای فضای نام کاربری تخمین می‌زند.
  • uidmapping=CONTAINER_UID:HOST_UID:SIZE: برای اجبار به وجود یک نگاشت UID در فضای نام کاربری.

شناسه کاربر و گروه (UID و GID) میزبان در gidmapping و uidmapping می‌توانند به صورت اختیاری با نماد @ پیشوندگذاری شوند. در این حالت، پادمن شناسه میانی متناظر با شناسه میزبان را جستجو کرده و شناسه میانی یافته‌شده را به شناسه کانتینر نگاشت می‌کند. برای جزئیات به --uidmap مراجعه کنید.

container:id: پیوستن به فضای نام کاربری کانتینر مشخص‌شده.

host یا "" (رشته خالی): اجرا در فضای نام کاربری فراخواننده. فرایندهای در حال اجرا درون کانتینر همان امتیازاتی را روی میزبان دارند که هر فرایند دیگری که توسط کاربر فراخواننده اجرا می‌شود داراست.

keep-id: یک فضای نام کاربری ایجاد می‌کند که در آن UID:GID کاربر فعلی به همان مقادیر درون کانتینر نگاشت می‌شوند. برای کانتینرهای ایجادشده توسط root، نگاشت فعلی در یک فضای نام کاربری جدید ایجاد می‌شود.

علاوه بر این، فرایند init در داخل کانتینر تحت شناسه کاربری (UID) کاربر فعلی اجرا خواهد شد. این رفتار دستور USER ایمیج را لغو می‌کند مگر آنکه گزینه --user را به‌طور صریح مشخص نمایید.

گزینه‌های معتبر keep-id:

  • uid=UID: بازنویسی UID درون کانتینر که کاربر فعلی به آن نگاشت می‌گردد.
  • gid=GID: بازنویسی GID درون کانتینر که کاربر فعلی به آن نگاشت می‌گردد.
  • size=SIZE: بازنویسی اندازه فضای نام کاربری پیکربندی‌شده. این گزینه برای پر نشدن تمامی شناسه‌های در دسترس مفید است. هنگام اجرا به عنوان کاربر root پشتیبانی نمی‌شود.

nomap: یک فضای نام کاربری ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه فعلی به درون کانتینر نگاشت نمی‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر root مجاز نیست.

ns:namespace: اجرای پاد در فضای نام کاربری موجودِ ارائه‌شده.

اجرای پادها و کانتینرها در پیش‌زمینه (foreground). مقدار پیش‌فرض false است.

در هر زمان می‌توانید دستور podman pod ps را در شل دیگری اجرا کنید تا فهرستی از پادها و کانتینرهای در حال اجرا را مشاهده نمایید.

هنگامی که در حالت tty متصل هستید، می‌توانید با فشردن کلیدهای ترکیبی Ctrl-C یا با دریافت هر سیگنال وقفه دیگری، پادها و کانتینرها را از بین ببرید.

تمامی پادها، کانتینرها و حجم‌های ایجادشده توسط podman kube play در هنگام خروج حذف می‌شوند.

ایجاد مجدد پاد و کانتینرهای شرح‌داده‌شده در فایل YAML مشخص‌شده روی میزبان:

$ podman kube play demo.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

ایجاد مجدد پاد و کانتینرهای مشخص‌شده در فایل YAML ارائه‌شده به stdin:

$ cat demo.yml | podman kube play -
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

متوقف کردن و حذف پاد و کانتینرها بر اساس توضیحات فایل YAML مشخص‌شده:

$  podman kube play --down demo.yml
Pods stopped:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6
Pods removed:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

ارائه چندین فایل کانفیگ‌مپ به عنوان منابع متغیرهای محیطی در پادها و کانتینرهای مشخص‌شده:

$ podman kube play demo.yml --configmap configmap-foo.yml,configmap-bar.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6
$ podman kube play demo.yml --configmap configmap-foo.yml --configmap configmap-bar.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

ایجاد پاد متصل به دو شبکه با اختصاص IP ایستا روی هر یک:

$ podman kube play demo.yml --network net1:ip=10.89.1.5 --network net2:ip=10.89.10.10
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

لطفاً توجه داشته باشید که شبکه‌ها باید ابتدا با استفاده از دستور podman-network-create(1) ایجاد شده باشند.

ایجاد و برچیدن از یک URL اشاره‌کننده به فایل YAML:

$ podman kube play https://podman.io/demo.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6
$ podman kube play --down https://podman.io/demo.yml
Pods stopped:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6
Pods removed:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

در صورتی که فایل YAML مورد اشاره توسط نشانی URL پس از ایجاد پادها و کانتینرها دچار تغییر یا دگرگونی شده باشد، دستور podman kube play --down با URL کار نخواهد کرد.

این سند فیلدهای YAML کوبرنتیز را که در حال حاضر توسط دستور podman kube play پشتیبانی می‌شوند مشخص می‌کند.

نکته: مقدار N/A به این معناست که این گزینه در یک محیط پادمن تک‌گره‌ای (single-node) قابل پشتیبانی نیست.

فیلد (Field) پشتیبانی (Support)
containers ✅
initContainers ✅
imagePullSecrets خیر
enableServiceLinks خیر
os.name خیر
volumes ✅
nodeSelector N/A
nodeName N/A
affinity.nodeAffinity N/A
affinity.podAffinity N/A
affinity.podAntiAffinity N/A
tolerations.key N/A
tolerations.operator N/A
tolerations.effect N/A
tolerations.tolerationSeconds N/A
schedulerName N/A
runtimeClassName خیر
priorityClassName خیر
priority خیر
topologySpreadConstraints.maxSkew N/A
topologySpreadConstraints.topologyKey N/A
topologySpreadConstraints.whenUnsatisfiable N/A
topologySpreadConstraints.labelSelector N/A
topologySpreadConstraints.minDomains N/A
restartPolicy ✅
terminationGracePeriodSeconds ✅
activeDeadlineSeconds خیر
readinessGates.conditionType خیر
hostname ✅
setHostnameAsFQDN خیر
subdomain خیر
hostAliases.hostnames ✅
hostAliases.ip ✅
dnsConfig.nameservers ✅
dnsConfig.options.name ✅
dnsConfig.options.value ✅
dnsConfig.searches ✅
dnsPolicy خیر
hostNetwork ✅
hostPID ✅
hostIPC ✅
shareProcessNamespace ✅
serviceAccountName خیر
automountServiceAccountToken خیر
securityContext.runAsUser ✅
securityContext.runAsNonRoot خیر
securityContext.runAsGroup ✅
securityContext.supplementalGroups ✅
securityContext.fsGroup خیر
securityContext.fsGroupChangePolicy خیر
securityContext.seccompProfile.type خیر
securityContext.seccompProfile.localhostProfile خیر
securityContext.seLinuxOptions.level ✅
securityContext.seLinuxOptions.role ✅
securityContext.seLinuxOptions.type ✅
securityContext.seLinuxOptions.user ✅
securityContext.sysctls.name ✅
securityContext.sysctls.value ✅
securityContext.windowsOptions.gmsaCredentialSpec خیر
securityContext.windowsOptions.hostProcess خیر
securityContext.windowsOptions.runAsUserName خیر

فیلد (Field) پشتیبانی (Support)
name ✅
image ✅
imagePullPolicy ✅
command ✅
args ✅
workingDir ✅
ports.containerPort ✅
ports.hostIP ✅
ports.hostPort ✅
ports.name ✅
ports.protocol ✅
env.name ✅
env.value ✅
env.valueFrom.configMapKeyRef.key ✅
env.valueFrom.configMapKeyRef.name ✅
env.valueFrom.configMapKeyRef.optional ✅
env.valueFrom.fieldRef ✅
env.valueFrom.resourceFieldRef ✅
env.valueFrom.secretKeyRef.key ✅
env.valueFrom.secretKeyRef.name ✅
env.valueFrom.secretKeyRef.optional ✅
envFrom.configMapRef.name ✅
envFrom.configMapRef.optional ✅
envFrom.prefix خیر
envFrom.secretRef.name ✅
envFrom.secretRef.optional ✅
volumeMounts.mountPath ✅
volumeMounts.name ✅
volumeMounts.mountPropagation خیر
volumeMounts.readOnly ✅
volumeMounts.subPath ✅
volumeMounts.subPathExpr خیر
volumeDevices.devicePath خیر
volumeDevices.name خیر
resources.limits ✅
resources.requests ✅
lifecycle.postStart خیر
lifecycle.preStop خیر
lifecycle.stopSignal ✅
terminationMessagePath خیر
terminationMessagePolicy خیر
livenessProbe ✅
readinessProbe خیر
startupProbe خیر
securityContext.runAsUser ✅
securityContext.runAsNonRoot خیر
securityContext.runAsGroup ✅
securityContext.readOnlyRootFilesystem ✅
securityContext.procMount ✅
securityContext.privileged ✅
securityContext.allowPrivilegeEscalation ✅
securityContext.capabilities.add ✅
securityContext.capabilities.drop ✅
securityContext.seccompProfile.type خیر
securityContext.seccompProfile.localhostProfile خیر
securityContext.seLinuxOptions.level ✅
securityContext.seLinuxOptions.role ✅
securityContext.seLinuxOptions.type ✅
securityContext.seLinuxOptions.user ✅
securityContext.windowsOptions.gmsaCredentialSpec خیر
securityContext.windowsOptions.hostProcess خیر
securityContext.windowsOptions.runAsUserName خیر
stdin خیر
stdinOnce خیر
tty خیر

فیلد (Field) پشتیبانی (Support)
volumeName خیر
storageClassName ✅
volumeMode خیر
accessModes ✅
selector خیر
resources.limits خیر
resources.requests ✅

فیلد (Field) پشتیبانی (Support)
binaryData ✅
data ✅
immutable خیر

فیلد (Field) پشتیبانی (Support)
replicas ✅ (تعداد واقعی رپلیکا نادیده گرفته شده و روی ۱ تنظیم می‌شود)
selector ✅
template ✅
minReadySeconds خیر
strategy.type خیر
strategy.rollingUpdate.maxSurge خیر
strategy.rollingUpdate.maxUnavailable خیر
revisionHistoryLimit خیر
progressDeadlineSeconds خیر
paused خیر

فیلد (Field) پشتیبانی (Support)
selector ✅
template ✅
minReadySeconds خیر
strategy.type خیر
strategy.rollingUpdate.maxSurge خیر
strategy.rollingUpdate.maxUnavailable خیر
revisionHistoryLimit خیر

فیلد (Field) پشتیبانی (Support)
activeDeadlineSeconds خیر
selector خیر (به‌طور خودکار توسط k8s تنظیم می‌شود)
template ✅
backoffLimit خیر
completionMode خیر
completions خیر (با kube generate روی ۱ تنظیم می‌شود)
manualSelector خیر
parallelism خیر (با kube generate روی ۱ تنظیم می‌شود)
podFailurePolicy خیر
suspend خیر
ttlSecondsAfterFinished خیر

podman(1), podman-kube(1), podman-kube-down(1), podman-network-create(1), podman-kube-generate(1), podman-build(1), containers-certs.d(5)