'\" t .nh .TH podman-kube-play 1 .SH "نام (NAME)" podman-kube-play \- ایجاد کانتینرها، پادها و حجم‌ها بر پایه YAML کوبرنتیز .SH "خلاصه دستور (SYNOPSIS)" \fBpodman kube play\fP [\fIگزینه‌ها\fP] \fIfile.yml|-|https://website.io/file.yml\fP .SH "توضیحات (DESCRIPTION)" دستور \fBpodman kube play\fP یک فایل ساختاریافته از YAML کوبرنتیز را می‌خواند. این دستور کانتینرها، پادها یا حجم‌های توصیف‌شده در YAML را مجدداً ایجاد می‌کند. سپس کانتینرهای درون یک پاد راه‌اندازی می‌شوند و شناسه (ID) پاد جدید یا نام حجم جدید در خروجی نمایش داده می‌شود. اگر فایل YAML به‌صورت «-» مشخص شود، \fBpodman kube play\fR فایل YAML را از ورودی استاندارد (stdin) می‌خواند. ورودی می‌تواند همچنین یک URL باشد که به یک فایل YAML اشاره دارد، مانند https://podman.io/demo.yml. دستور \fBpodman kube play\fR فایل YAML را از نشانی URL خوانده و از روی آن پادها و کانتینرها را ایجاد می‌کند. .PP با استفاده از گزینه خط فرمان \fB--down\fR، این دستور همچنین قادر است پادهای ایجادشده توسط اجرای قبلی \fBpodman kube play\fR را متوقف و حذف کند (از کار بیندازد). .PP با استفاده از گزینه خط فرمان \fB--replace\fR، این دستور پادهای ایجادشده توسط اجرای قبلی \fBpodman kube play\fR (در صورت وجود) را متوقف و حذف کرده و پادها را مجدداً با فایل YAML کوبرنتیز از نو می‌سازد. .PP در حالت ایده‌آل، فایل ورودی توسط دستور پادمن ایجاد می‌شود (به podman-kube-generate(1) مراجعه کنید). این کار واردسازی بدون مشکل و نتایج مورد انتظار را تضمین می‌کند. .PP در حال حاضر، انواع (kinds) پشتیبانی‌شده در کوبرنتیز عبارتند از: .IP \(bu 2 Pod .IP \(bu 2 Deployment .IP \(bu 2 PersistentVolumeClaim .IP \(bu 2 ConfigMap .IP \(bu 2 Secret .IP \(bu 2 DaemonSet .IP \(bu 2 Job .PP \fBپادها یا استقرارهای کوبرنتیز (Kubernetes Pods or Deployments)\fR .PP تنها پنج نوع حجم توسط kube play پشتیبانی می‌شوند: انواع حجم \fIhostPath\fP، \fIemptyDir\fP، \fIconfigMap\fP، \fIpersistentVolumeClaim\fP و \fIimage\fP. .IP \(bu 2 هنگام استفاده از نوع حجم \fIhostPath\fP، تنها زیرنوع‌های \fIdefault (empty)\fP، \fIDirectoryOrCreate\fP، \fIDirectory\fP، \fIFileOrCreate\fP، \fIFile\fP، \fISocket\fP، \fICharDevice\fP و \fIBlockDevice\fP پشتیبانی می‌شوند. پادمن مقدار \fIpath\fP در \fIhostPath\fP را زمانی که حداقل شامل یک اسلش مایل به جلو (/) باشد به عنوان مسیر فایل تفسیر می‌کند؛ در غیر این صورت، پادمن آن مقدار را به عنوان نام یک حجم نام‌دار (named volume) در نظر می‌گیرد. .IP \(bu 2 هنگام استفاده از \fIpersistentVolumeClaim\fP، مقدار \fIclaimName\fP به عنوان نام حجم نام‌دار پادمن خواهد بود. .IP \(bu 2 هنگام استفاده از یک حجم \fIemptyDir\fP، پادمن یک حجم ناشناس ایجاد می‌کند که به کانتینرهای در حال اجرا درون پاد متصل می‌شود و پس از حذف پاد، این حجم نیز پاک می‌گردد. .IP \(bu 2 هنگام استفاده از یک حجم \fIconfigMap\fP، پادمن یک حجم ناشناس ایجاد می‌کند که به کانتینرهای در حال اجرا درون پاد متصل شده و پس از حذف پاد پاک می‌شود. .IP \(bu 2 هنگام استفاده از نوع حجم \fIimage\fP، پادمن یک حجم ایمیج فقط‌خواندنی با زیرمسیر خالی ایجاد می‌کند (کل ایمیج متصل می‌شود). این ایمیج باید از قبل به‌صورت محلی وجود داشته باشد. این قابلیت فقط در حالت دارای ریشه (rootful) پشتیبانی می‌شود. .PP نکته: سیاست بازنشانی پیش‌فرض برای کانتینرها \fBalways\fR است. می‌توانید مقدار پیش‌فرض را با تنظیم فیلد \fBrestartPolicy\fR در مشخصات (spec) تغییر دهید. .PP نکته: هنگام اجرای فایل YAML کوبرنتیز حاوی کانتینرهای راه‌انداز (init containers)، کانتینر راه‌انداز با نوع راه‌اندازی \fBonce\fR ایجاد می‌شود. برای تغییر نوع پیش‌فرض، از حاشیه‌نویسی \fBio.podman.annotations.init.container.type\fR برای تنظیم نوع به \fBalways\fR استفاده کنید. .PP نکته: انواع حجم \fIhostPath\fP ایجادشده توسط kube play یک برچسب مشترک SELinux به صورت (z) دریافت می‌کنند؛ اتصالات بایند (bind mounts) مجدداً برچسب‌گذاری نمی‌شوند (از \fBchcon -t container_file_t -R \fR استفاده کنید). .PP نکته: برای تنظیم فضای نام کاربری (userns) یک پاد، از حاشیه‌نویسی \fBio.podman.annotations.userns\fP در تعریف pod/deployment استفاده کنید. برای مثال، حاشیه‌نویسی \fBio.podman.annotations.userns=keep-id\fP به پادمن دستور می‌دهد یک فضای نام کاربری ایجاد کند که در آن شناسه کاربری و گروهی (UID:GID) کاربر بدون ریشه فعلی به همان مقادیر درون کانتینر نگاشت شوند. این مقدار را می‌توان با پرچم \fB--userns\fR بازنویسی کرد. .PP نکته: از حاشیه‌نویسی \fBio.podman.annotations.volumes-from\fP برای اتصال حجم‌های یک کانتینر به کانتینر دیگر استفاده کنید. می‌توانید حجم‌ها را از چندین کانتینر مبدأ بر روی یک کانتینر مقصد سوار کنید. کانتینرهای مبدأ که متعلق به همان پاد هستند باید قبل از کانتینر مقصد در فایل YAML کوبرنتیز تعریف شوند. قالب این حاشیه‌نویسی به صورت \fBio.podman.annotations.volumes-from/targetContainer: "sourceContainer1:mountOpts1;sourceContainer2:mountOpts2"\fR است. .PP نکته: در صورت استفاده از برچسب \fB:latest\fR، پادمن تلاش می‌کند تا ایمیج را از رجیستری دریافت کند. اگر ایمیج به‌صورت محلی با پادمن یا Buildah ساخته شده باشد، دارای دامنه \fBlocalhost\fR است که در این حالت، پادمن حتی در صورت وجود تگ \fB:latest\fR از ایمیج موجود در مخزن محلی استفاده می‌کند. .PP نکته: دستور \fBpodman play kube\fR نام مستعاری برای \fBpodman kube play\fR بوده و عملکرد یکسانی دارد. .PP نکته: از دستور \fBpodman kube down\fR می‌توان برای متوقف کردن و حذف پادها یا کانتینرها بر اساس همان فایل YAML کوبرنتیز که توسط \fBpodman kube play\fR برای ایجاد آن‌ها استفاده شده، بهره برد. .PP نکته: برای سفارشی‌سازی نام کانتینر زیرساخت (infra container) ایجادشده در حین \fBpodman kube play\fR، از حاشیه‌نویسی \fBio.podman.annotations.infra.name\fP در تعریف پاد استفاده کنید. این حاشیه‌نویسی هنگام تولید یک yaml کوبرنتیز از پادی که با تنظیم پرچم \fB--infra-name\fR ایجاد شده باشد، به‌طور خودکار تنظیم می‌گردد. .PP نکته: از حاشیه‌نویسی \fBio.podman.annotations.pids-limit/$ctrname\fP برای پیکربندی محدودیت تعداد شناسه‌های فرایند (pids limit) در پاد استفاده کنید. .PP نکته: از حاشیه‌نویسی \fBio.podman.annotations.cpuset/$ctrname\fP برای محدود کردن اجرای یک کانتینر به مجموعه‌ای خاص از هسته‌های پردازنده (CPU) استفاده کنید. این معادل گزینه \fB--cpuset-cpus=number\fR در podman-run(1) است. .PP نکته: از حاشیه‌نویسی \fBio.podman.annotations.memory-nodes/$ctrname\fP برای محدود کردن تخصیص‌های حافظه کانتینر به مجموعه‌ای خاص از گره‌های حافظه در سیستم‌های NUMA استفاده کنید. این معادل گزینه \fB--cpuset-mems=nodes\fR در podman-run(1) است. .PP \fBادعاهای حجم دائمی کوبرنتیز (Kubernetes PersistentVolumeClaims)\fR .PP یک PersistentVolumeClaim در کوبرنتیز نمایانگر یک حجم نام‌دار پادمن است. پادمن برای ایجاد حجم تنها به نام PersistentVolumeClaim نیاز دارد. می‌توان از حاشیه‌نویسی‌های کوبرنتیز برای بهره‌گیری از گزینه‌های موجود حجم‌های پادمن استفاده کرد. .IP \(bu 2 volume.podman.io/driver .IP \(bu 2 volume.podman.io/device .IP \(bu 2 volume.podman.io/type .IP \(bu 2 volume.podman.io/uid .IP \(bu 2 volume.podman.io/gid .IP \(bu 2 volume.podman.io/mount-options .IP \(bu 2 volume.podman.io/import-source .IP \(bu 2 volume.podman.io/image .PP از \fBvolume.podman.io/import-source\fR برای وارد کردن محتویات فایل فشرده تار (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz, .tar.zst) مشخص‌شده در مقدار حاشیه‌نویسی به درون حجم ایجادشده در پادمن استفاده کنید. .PP دستور kube play در صورت وجود چیدمان مناسب دایرکتوری و فایل‌های Containerfile، توانایی ساخت آنی ایمیج‌ها را دارد. این گزینه هنوز برای کلاینت‌های راه دور، از جمله ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نیست. بخش زیر از یک فایل YAML را در نظر بگیرید: .EX apiVersion: v1 kind: Pod metadata: \&... spec: containers: - name: container image: foobar \&... .EE .PP اگر دایرکتوری به نام \fBfoobar\fR در دایرکتوری کاری فعلی با فایلی به نام \fBContainerfile\fR یا \fBDockerfile\fR وجود داشته باشد، Podman kube play آن ایمیج را ساخته و نام آن را \fBfoobar\fR می‌گذارد. ساختار دایرکتوری نمونه برای این مثال به شکل زیر است: .EX |- mykubefiles |- myplayfile.yaml |- foobar |- Containerfile .EE .PP فرایند ساخت، دایرکتوری \fBfoobar\fR را به عنوان دایرکتوری بافت (context directory) ساخت در نظر می‌گیرد. اگر ایمیجی به نام \fBfoobar\fR در حافظه ذخیره‌سازی محلی وجود داشته باشد، ایمیج ساخته نمی‌شود مگر اینکه از پرچم \fB--build\fR استفاده شود. از \fB--build=false\fR برای غیرفعال کردن کامل ساخت ایمیج استفاده کنید. .PP دستور Kube play از انتخاب‌کننده‌های دستگاه CDI (رابط دستگاه کانتینر) برای اشتراک‌گذاری دستگاه‌های میزبان (مانند پردازنده‌های گرافیکی یا GPUها) با کانتینرها پشتیبانی می‌کند. ساختار پیکربندی از مدیریت منابع توسعه‌یافته کوبرنتیز پیروی می‌کند: .EX apiVersion: v1 kind: Pod spec: containers: - name: container resources: limits: nvidia.com/gpu=all: 1 .EE .PP برای فعال‌سازی اشتراک‌گذاری دستگاه‌های میزبان، مشابه با استفاده از پرچم \fB--device\fR، پادمن کیوب از یک انتخاب‌کننده سفارشی CDI پشتیبانی می‌کند: \fBpodman.io/device=\fR\&. .PP \fBکانفیگ‌مپ کوبرنتیز (Kubernetes ConfigMap)\fR .PP کانفیگ‌مپ کوبرنتیز می‌تواند به عنوان یک منبع متغیرهای محیطی یا حجم‌ها در پادها یا استقرارها ارجاع داده شود. کانفیگ‌مپ‌ها یک شیء مستقل در پادمن نیستند؛ در عوض، هنگامی که کانتینری از یک ConfigMap استفاده می‌کند، پادمن بر حسب نیاز متغیرهای محیطی یا حجم‌ها را ایجاد می‌نماید. .PP به عنوان مثال، سند YAML زیر یک ConfigMap را تعریف کرده و سپس در یک پاد از آن بهره می‌برد: .EX 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 .EE .PP و در نتیجه متغیر محیطی \fBFOO\fR برای کانتینر \fBcontainer-1\fR برابر با \fBbar\fR تنظیم می‌شود. .PP \fBسکرت کوبرنتیز (Kubernetes Secret)\fR .PP سکرت کوبرنتیز نمایانگر یک سکرت نام‌دار در پادمن است. سکرت کوبرنتیز به صورت یکپارچه ذخیره می‌شود و ممکن است به عنوان منبع متغیرهای محیطی یا حجم‌ها در پادها یا استقرارها مورد ارجاع قرار گیرد. .PP به عنوان مثال، سند YAML زیر یک Secret را تعریف کرده و سپس در یک پاد از آن استفاده می‌کند: .EX 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 .EE .PP و در نتیجه متغیر محیطی \fBFOO\fR برای کانتینر \fBcontainer-1\fR برابر با \fBbar\fR تنظیم می‌شود. .PP \fBسوار کردن خودکار حجم‌ها (منسوخ‌شده) (Automounting Volumes (deprecated))\fR .PP نکته: حاشیه‌نویسی اتصال خودکار حجم‌ها منسوخ شده است. کوبرنتیز دارای پشتیبانی بومی از حجم‌های ایمیج است و باید به جای این حاشیه‌نویسی مختص پادمن از آن استفاده شود. .PP اگر حاشیه‌نویسی \fBio.podman.annotations.kube.image.automount/$ctrname\fR مشخص شده باشد، یک ایمیج می‌تواند به‌طور خودکار درون کانتینر سوار شود. قواعد زیر اعمال می‌گردند: .IP \(bu 2 ایمیج باید از قبل به‌صورت محلی وجود داشته باشد. .IP \(bu 2 ایمیج باید حداقل دارای ۱ دستورالعمل حجم (volume directive) باشد. .IP \(bu 2 مسیری که با دستورالعمل حجم مشخص شده است از درون ایمیج بر روی کانتینر متصل می‌شود. به عنوان مثال، ایمیجی با یک حجم در مسیر \fB/test/test_dir\fR، دایرکتوری \fB/test/test_dir\fR ایمیج را به \fB/test/test_dir\fR در کانتینر متصل می‌کند. .IP \(bu 2 امکان تعیین چندین ایمیج وجود دارد. اگر چندین ایمیج در یک مسیر مشخص دارای حجم باشند، آخرین ایمیج مشخص‌شده اولویت خواهد داشت. .IP \(bu 2 ایمیج‌ها همواره به‌صورت فقط‌خواندنی سوار می‌شوند. .IP \(bu 2 ایمیج‌ها برای سوار شدن در حاشیه‌نویسی "io.podman.annotations.kube.image.automount/$ctrname" به صورت فهرستی جداشده با نقطه ویرگول (;) تعریف می‌شوند. آنها در یک کانتینر منفرد در پاد سوار می‌شوند، نه در کل پاد. در صورت نیاز به اتصالات بیشتر، می‌توان این حاشیه‌نویسی را برای کانتینرهای اضافی نیز مشخص نمود. .SH "گزینه‌ها (OPTIONS)" .SS \fB--annotation\fP=\fIkey=value\fP افزودن حاشیه‌نویسی به کانتینر یا پاد. این گزینه را می‌توان چندین بار تنظیم کرد. .PP نکته: برای \fBpodman kube play\fR، پرچم \fB--annotation\fR حاشیه‌نویسی‌های مختص پادمن را به کانتینرها و پادهای ایجادشده توسط پادمن اضافه می‌کند، نه به خود فایل YAML کوبرنتیز. از این حاشیه‌نویسی‌ها می‌توان برای پیکربندی قابلیت‌های مختص پادمن مانند فضاهای نام کاربری (\fBio.podman.annotations.userns\fR)، حجم‌های مشترک (\fBio.podman.annotations.volumes-from\fR) و سایر رفتارهای کانتینر بهره برد. .SS \fB--authfile\fP=\fIpath\fP مسیر فایل احراز هویت. پیش‌فرض در لینوکس \fB${XDG_RUNTIME_DIR}/containers/auth.json\fR و در ویندوز/مک‌او‌اس \fB$HOME/.config/containers/auth.json\fR است. این فایل توسط دستور \fBpodman login\fP ایجاد می‌شود. اگر وضعیت احراز هویت در آنجا پیدا نشود، مسیر \fB$HOME/.docker/config.json\fR که با استفاده از \fBdocker login\fP تنظیم می‌شود مورد بررسی قرار می‌گیرد. .PP نکته: این امکان نیز وجود دارد که مسیر پیش‌فرض فایل احراز هویت با تنظیم متغیر محیطی \fBREGISTRY_AUTH_FILE\fR بازنویسی شود. این کار با دستور \fBexport REGISTRY_AUTH_FILE=\fIpath\fP\fP انجام می‌پذیرد. .SS \fB--build\fP ساخت ایمیج‌ها حتی در صورتی که در حافظه ذخیره‌سازی محلی یافت شوند. برای غیرفعال کردن کامل ساخت ایمیج از \fB--build=false\fR استفاده کنید. (این گزینه با کلاینت راه دور پادمن در دسترس نیست) .PP نکته: شما همچنین می‌توانید نوع جداسازی پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_ISOLATION بازنویسی کنید: export BUILDAH_ISOLATION=oci. برای اطلاعات بیشتر به podman-build.1.md مراجعه فرمایید. .SS \fB--cert-dir\fP=\fIpath\fP استفاده از گواهی‌های موجود در مسیر \fIpath\fP (شامل *\&.crt, *\&.cert, *\&.key) برای برقراری ارتباط با رجیستری (پیش‌فرض: /etc/containers/certs.d). برای جزئیات به \fBcontainers-certs.d(5)\fP مراجعه کنید. (این گزینه در کلاینت راه دور پادمن، از جمله ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نمی‌باشد) .SS \fB--configmap\fP=\fIpath\fP استفاده از YAML کانفیگ‌مپ کوبرنتیز در مسیر \fIpath\fP جهت تامین مقادیر متغیرهای محیطی درون کانتینرهای پاد. (این گزینه در کلاینت راه دور پادمن در دسترس نیست) .PP نکته: گزینه \fB--configmap\fP را می‌توان چندین بار به کار برد، یا فهرستی جداشده با کاما از مسیرها را جهت ارسال چندین YAML کانفیگ‌مپ کوبرنتیز استفاده کرد. فایل YAML می‌تواند در قالب چندسندی (multi-doc) باشد؛ اما باید تنها شامل ConfigMapها باشد. .SS \fB--context-dir\fP=\fIpath\fP استفاده از مسیر \fIpath\fP به عنوان دایرکتوری بافت ساخت برای هر ایمیج. نیازمند آن است که گزینه --build روی true تنظیم شده باشد. (این گزینه در کلاینت راه دور پادمن در دسترس نیست) .SS \fB--creds\fP=\fI[username[:password]]\fP نام کاربری و گذرواژه [username[:password]] جهت استفاده برای احراز هویت در رجیستری، در صورت نیاز. اگر یک یا هر دو مقدار ارائه نشوند، اعلانی در خط فرمان ظاهر شده و می‌توان مقدار را وارد کرد. گذرواژه بدون بازتاب (echo) دریافت می‌شود. .PP توجه داشته باشید که اطلاعات هویتی مشخص‌شده تنها برای احراز هویت در مقابل رجیستری‌های هدف به کار می‌روند. از آنها برای آینه‌ها (mirrors) یا زمان بازنویسی آدرس رجیستری استفاده نمی‌شود (به \fBcontainers-registries.conf(5)\fR مراجعه کنید)؛ برای احراز هویت در مقابل آنها، استفاده از یک فایل \fBcontainers-auth.json(5)\fR را مد نظر قرار دهید. .SS \fB--force\fP حذف و پاک‌سازی حجم‌های متصل به PersistentVolumeClaimها به عنوان بخشی از گزینه --down. .SS \fB--help\fP, \fB-h\fP چاپ راهنمای دستور. .SS \fB--ip\fP=\fIIP address\fP اختصاص یک آدرس IP ایستا به پاد. زمانی که kube play بیش از یک پاد ایجاد می‌کند، این گزینه را می‌توان چندین بار مشخص کرد. نکته: هنگام پیوستن به چندین شبکه از ساختار \fB--network name:ip=\fP استفاده نمایید. .SS \fB--log-driver\fP=\fIdriver\fP تنظیم درایور لاگ‌گیری برای تمامی کانتینرهای ایجادشده. .SS \fB--log-opt\fP=\fIname=value\fP گزینه‌های اختصاصی درایور لاگ‌گیری. .PP تنظیم پیکربندی لاگ‌گیری سفارشی. مقادیر *name* زیر پشتیبانی می‌شوند: .PP \fBpath\fP: تعیین مسیر فایل گزارش (مانند \fB--log-opt path=/var/log/container/mycontainer.json\fP)؛ .PP \fBmax-size\fP: تعیین حداکثر اندازه فایل گزارش (مانند \fB--log-opt max-size=10mb\fP)؛ .PP \fBtag\fP: تعیین یک برچسب (tag) گزارش سفارشی برای کانتینر (مانند \fB--log-opt tag="{{.ImageName}}"\fP\&. این گزینه از همان کلیدهای \fBpodman inspect --format\fP پشتیبانی می‌کند. این گزینه در حال حاضر تنها توسط درایور لاگ‌گیری \fBjournald\fP پشتیبانی می‌شود. .PP \fBlabel\fP: تعیین یک لیبل گزارش سفارشی برای کانتینر (مانند \fB--log-opt label="CONTAINER_IMAGE={{.ImageName}}"\fP\&. این گزینه از همان کلیدهای \fBpodman inspect --format\fP پشتیبانی می‌کند. این گزینه می‌تواند چندین بار تکرار شود. این گزینه در حال حاضر تنها توسط درایور لاگ‌گیری \fBjournald\fP پشتیبانی می‌شود. .SS \fB--mac-address\fP=\fIMAC address\fP اختصاص یک آدرس MAC ایستا به پاد. هنگامی که kube play بیش از یک پاد ایجاد می‌کند، این گزینه را می‌توان چندین بار تعیین کرد. نکته: هنگام پیوستن به چندین شبکه از ساختار \fB--network name:mac=\fP استفاده کنید. .SS \fB--network\fP=\fImode\fP, \fB--net\fP تنظیم حالت شبکه برای پاد. .PP مقادیر معتبر \fImode\fP عبارتند از: .IP \(bu 2 \fBbridge[:OPTIONS,...]\fP: ایجاد یک پشته شبکه روی پل (bridge) پیش‌فرض. این حالت پیش‌فرض برای کانتینرهای دارای ریشه (rootful) است. امکان تعیین گزینه‌های اضافی زیر وجود دارد: .RS .IP \(bu 2 \fBalias=\fP\fIname\fP: افزودن نام مستعار در حوزه شبکه برای کانتینر. .IP \(bu 2 \fBip=\fP\fIIPv4\fP: تعیین آدرس IPv4 ایستا برای این کانتینر. .IP \(bu 2 \fBip6=\fP\fIIPv6\fP: تعیین آدرس IPv6 ایستا برای این کانتینر. .IP \(bu 2 \fBmac=\fP\fIMAC\fP: تعیین آدرس MAC ایستا برای این کانتینر. .IP \(bu 2 \fBinterface_name=\fP\fIname\fP: تعیین یک نام برای رابط شبکه ایجادشده در داخل کانتینر. .IP \(bu 2 \fBhost_interface_name=\fP\fIname\fP: تعیین یک نام برای رابط شبکه ایجادشده در خارج از کانتینر (روی میزبان). .RE .IP هر گزینه دیگری بدون اعتبارسنجی به netavark ارسال خواهد شد. این موضوع می‌تواند برای ارسال آرگومان‌ها به پلاگین‌های netavark مفید باشد. برای شبکه‌های پل بدون ریشه (rootless bridge)، هدایت پورت به‌طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR فایل \fBcontainers.conf(5)\fP، هدایت را به سازوکار سطح هسته pasta (از طریق \fBpesto\fR) تغییر می‌دهد که آدرس IP مبدأ کلاینت اصلی را درون کانتینر حفظ می‌کند. این گزینه آزمایشی بوده و رفتار آن ممکن است در آینده تغییر کند. برای مثال، جهت تنظیم یک آدرس IPv4 ایستا و یک آدرس MAC ایستا، از دستور \fB--network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99\fR استفاده نمایید. .IP \(bu 2 \fI\fP\fB[:OPTIONS,...]\fP: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این نام یا شناسه شبکه‌ای است که توسط \fBpodman network create\fP ساخته شده است. امکان تعیین گزینه‌های مشابه شرح داده شده در بخش bridge بالا وجود دارد. برای مشخص کردن شبکه‌های بیشتر از گزینه \fB--network\fP به دفعات استفاده کنید. .br جهت سازگاری با گذشته، می‌توان شبکه‌های جداشده با کاما را نیز در اولین آرگومان \fB--network\fP مشخص کرد؛ هرچند این کار مانع از استفاده شما از گزینه‌های تشریح‌شده در بخش bridge بالا می‌شود. .IP \(bu 2 \fBnone\fP: ایجاد یک فضای نام شبکه برای کانتینر اما بدون پیکربندی رابط‌های شبکه برای آن؛ بنابراین کانتینر هیچ‌گونه اتصال شبکه‌ای نخواهد داشت. .IP \(bu 2 \fBcontainer:\fP\fIid\fP: استفاده مجدد از پشته شبکه یک کانتینر دیگر. .IP \(bu 2 \fBhost\fP: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام مجزا. هشدار: این کار دسترسی کامل به سوکت‌های انتزاعی دامنه یونیکس و سوکت‌های TCP/UDP مقید به localhost را به کانتینر می‌دهد. از آنجا که این سازوکارها اغلب برای جلوگیری از دسترسی به سرویس‌های حساس سیستم و جداسازی آنها از موجودیت‌های خارجی استفاده می‌شوند، استفاده از این گزینه ممکن است یک آسیب‌پذیری امنیتی تلقی گردد. .IP \(bu 2 \fBns:\fP\fIpath\fP: مسیر فضای نام شبکه‌ای که کانتینر باید به آن ملحق شود. .IP \(bu 2 \fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر. در کانتینرهای با ریشه (rootful) از حالت \fBbridge\fP و در کانتینرهای بدون ریشه (rootless) از \fBpasta\fP استفاده می‌شود. .IP \(bu 2 \fBpasta[:OPTIONS,...]\fP: استفاده از \fBpasta\fP(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode). .br این حالت پیش‌فرض برای کانتینرهای بدون ریشه بوده و تنها در حالت rootless پشتیبانی می‌شود. .br به‌طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط پاد از میزبان کپی می‌شوند. هدایت پورت، آدرس IP مبدأ اولیه را حفظ می‌کند. گزینه‌های تشریح‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما مشخص نمود. .br از نظر گزینه‌های pasta(1)، گزینه \fB--config-net\fP به‌طور پیش‌فرض داده می‌شود تا در زمان راه‌اندازی کانتینر، شبکه پیکربندی شود؛ همچنین گزینه \fB--no-map-gw\fP نیز به‌طور پیش‌فرض اعمال می‌شود تا از دسترسی مستقیم از کانتینر به میزبان با استفاده از آدرس درگاه (gateway) جلوگیری گردد. مورد اخیر را می‌توان با ارسال \fB--map-gw\fP در گزینه‌های خاص pasta لغو کرد (اگرچه این یک گزینه واقعی در pasta(1) نیست). .br جهت یکپارچگی بهتر با مدیریت DNS، مقدار \fB--dns-forward 169.254.1.1\fP به‌طور پیش‌فرض ارسال می‌شود و این نشانی به عنوان نخستین تحلیل‌گر به resolv.conf(5) اضافه می‌گردد. در صورتی که نیاز به استفاده از آدرس IP متفاوتی باشد، می‌توان \fB--dns-forward\fP را به‌طور صریح مشخص کرد. .br برای عملکرد صحیح مدخل \fBhost.containers.internal\fR در /etc/hosts و اجازه برقراری ارتباط با میزبان، گزینه \fB--map-guest-addr 169.254.1.2\fP به‌طور پیش‌فرض ارسال می‌شود. مجدداً می‌توان آن را به‌طور صریح برای انتخاب آدرس IP دیگر تنظیم کرد. .br همچنین در صورتی که هیچ هدایت پورت TCP یا UDP از میزبان به کانتینر پیکربندی نشده باشد (از طریق \fB--publish\fP پادمن یا ارسال مستقیم گزینه‌های \fB-t\fP/\fB-u\fP در pasta)، به ترتیب مقادیر \fB-t none\fP و \fB-u none\fP ارسال می‌شوند تا فوروارد خودکار پورت بر اساس پورت‌های مقید غیرفعال گردد. به طور مشابه، \fB-T none\fP و \fB-U none\fP برای غیرفعال کردن عملکرد مشابه از سمت کانتینر به میزبان ارسال می‌گردند. .br تمامی گزینه‌ها را می‌توان در \fBcontainers.conf(5)\fP نیز پیکربندی کرد؛ کلید \fBpasta_options\fR در زیر بخش network آن فایل را مشاهده کنید. .br چند مثال: .RS .IP \(bu 2 \fBpasta:--map-gw\fP: اجازه دسترسی مستقیم به میزبان با استفاده از آدرس درگاه (gateway). .IP \(bu 2 \fBpasta:--mtu,1500\fP: تعیین MTU معادل ۱۵۰۰ بایت برای رابط \fItap\fP درون کانتینر. .IP \(bu 2 \fBpasta:--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\fP: غیرفعال کردن IPv6، تخصیص \fB10.0.2.0/24\fR به رابط \fBtap0\fR کانتینر، با درگاه \fB10.0.2.2\fR، فعال کردن فورواردر DNS در دسترس روی \fB10.0.2.3\fR، تنظیم MTU روی ۱۵۰۰ بایت، و غیرفعال‌سازی پشتیبانی از NDP، DHCPv6 و DHCP. .IP \(bu 2 \fBpasta:-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\fP: همانند مورد قبل، با حفظ مقدار MTU روی ۶۵۵۲۰ بایت. .IP \(bu 2 \fBpasta:-t,auto,-u,auto,-T,auto,-U,auto\fP: فعال‌سازی هدایت خودکار پورت بر اساس پورت‌های متصل مشاهده‌شده از هر دو سوی میزبان و کانتینر. .IP \(bu 2 \fBpasta:-T,5201\fP: فعال‌سازی هدایت پورت TCP شماره ۵۲۰۱ از کانتینر به میزبان با استفاده از رابط loopback به جای رابط tap به منظور بهبود عملکرد. .RE .PP هنگامی که هیچ گزینه شبکه‌ای مشخص نشده باشد و حالت شبکه \fIhost\fP در فایل YAML تعریف نشده باشد، یک پشته شبکه جدید ایجاد شده و پادها به آن متصل می‌شوند که برقراری ارتباط میان‌پادی (pod to pod) را میسر می‌سازد. .SS \fB--no-hostname\fP عدم ایجاد فایل \fI/etc/hostname\fP در کانتینرها. .PP به‌طور پیش‌فرض، پادمن فایل \fI/etc/hostname\fP را مدیریت کرده و نام میزبان خود کانتینر را درج می‌نماید. هنگامی که گزینه \fB--no-hostname\fP تنظیم شود، در صورت وجود فایل \fI/etc/hostname\fP در ایمیج، بدون تغییر حفظ خواهد شد. .SS \fB--no-hosts\fP عدم تغییر فایل \fB/etc/hosts\fR درون پاد. .PP پادمن به‌طور پیش‌فرض کنترل فایل \fB/etc/hosts\fR پاد را به عهده می‌گیرد و مدخل‌هایی برای نام کانتینر (به گزینه \fB--name\fP مراجعه کنید)، نام میزبان (به گزینه \fB--hostname\fP مراجعه کنید)، میزبان‌های داخلی \fBhost.containers.internal\fR و \fBhost.docker.internal\fR، و همچنین هر نام میزبانی که با گزینه \fB--add-host\fP اضافه شده باشد در آن قرار می‌دهد. برای جزئیات به گزینه \fB--add-host\fP رجوع کنید. ارسال گزینه \fB--no-hosts\fP این رفتار را غیرفعال می‌سازد تا فایل \fB/etc/hosts\fR ایمیج دست‌نخورده باقی بماند. همین نتیجه را می‌توان با تنظیم سراسری \fIno_hosts=true\fP در \fBcontainers.conf\fR حاصل کرد. .PP این گزینه با میزبان‌های اضافه شده در YAML کوبرنتیز ناسازگار است. .SS \fB--no-pod-prefix\fP عدم افزودن نام پاد به عنوان پیشوند نام کانتینر. .SS \fB--publish\fP=\fI[[ip:][hostPort]:]containerPort[/protocol]\fP تعریف یا بازنویسی تعریف پورت در فایل YAML. .PP فهرست پورت‌های موجود در فایل YAML و خط فرمان با یکدیگر ادغام می‌شوند. تطبیق با استفاده از فیلد \fBcontainerPort\fP صورت می‌گیرد. اگر \fBcontainerPort\fP هم در فایل YAML و هم در این گزینه قید شده باشد، مقدار این گزینه اولویت خواهد داشت. .SS \fB--publish-all\fP تنظیم این گزینه روی \fBtrue\fR تمام پورت‌ها را روی میزبان منتشر (هدایت) می‌کند، حتی اگر تنها از طریق \fBcontainerPort\fP در YAML کوبرنتیز مشخص شده باشند. از دیدگاه اینکه کدام پورت منتشر خواهد شد، \fB--publish\fP اولویت بالاتری نسبت به \fBhostPort\fP دارد، و \fBhostPort\fP اولویت بالاتری نسبت به \fBcontainerPort\fP دارد. .PP اگر این گزینه روی \fBfalse\fR (مقدار پیش‌فرض) تنظیم شود، تنها پورت‌هایی که از طریق \fBhostPort\fP یا \fB--publish\fP تعریف شده باشند روی میزبان منتشر می‌گردند. .SS \fB--quiet\fP, \fB-q\fP جلوگیری از چاپ اطلاعات خروجی هنگام دریافت ایمیج‌ها. .SS \fB--replace\fP متوقف کردن و حذف پادهای ایجادشده توسط اجرای پیشین \fBkube play\fR و ساخت مجدد آن‌ها. این گزینه جهت به‌روز نگه‌داشتن پادهای موجود بر اساس فایل YAML کوبرنتیز استفاده می‌شود. .SS \fB--seccomp-profile-root\fP=\fIpath\fP مسیر دایرکتوری برای نمایه‌های seccomp (پیش‌فرض: "/var/lib/kubelet/seccomp"). (این گزینه با کلاینت راه دور پادمن، از جمله ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نیست) .SS \fB--start\fP راه‌اندازی پاد پس از ایجاد آن؛ برای ایجاد صرف بدون راه‌اندازی، آن را روی false تنظیم کنید. .SS \fB--tls-verify\fP الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام ارتباط با رجیستری‌ها (پیش‌فرض: \fBtrue\fP). در صورت تنظیم صریح روی \fBtrue\fP، اعتبارسنجی TLS انجام می‌گیرد. اگر روی \fBfalse\fP تنظیم شود، اعتبارسنجی TLS انجام نخواهد شد. اگر مشخص نشود، اعتبارسنجی TLS اعمال می‌شود مگر آنکه رجیستری هدف در \fBcontainers-registries.conf(5)\fP به عنوان یک رجیستری ناامن ذکر شده باشد. .SS \fB--userns\fP=\fImode\fP تنظیم حالت فضای نام کاربری (user namespace) برای کانتینر. .PP اگر \fB--userns\fR مشخص نشود، مقدار پیش‌فرض به شکل زیر تعیین می‌گردد: - اگر \fB--pod\fR تنظیم شده باشد، \fB--userns\fR نادیده گرفته شده و از فضای نام کاربری پاد استفاده می‌شود. - اگر متغیر محیطی \fBPODMAN_USERNS\fP تنظیم شده باشد، مقدار آن اعمال می‌گردد. - اگر \fBuserns\fR در \fBcontainers.conf\fR تعیین شده باشد، آن مقدار استفاده می‌شود. - در غیر این صورت، \fB--userns=host\fR فرض خواهد شد. .PP مقدار \fB--userns=""\fR (یعنی یک رشته خالی) نام مستعاری برای \fB--userns=host\fR است. .PP این گزینه با گزینه‌های \fB--gidmap\fP، \fB--uidmap\fP، \fB--subuidname\fP و \fB--subgidname\fP ناسازگار است. .PP نگاشت‌های کلید (Key) در --userns برای کاربر بدون ریشه (rootless): .TS allbox; l l l l l l . \fBکلید (Key)\fP \fBکاربر میزبان (Host User)\fP \fBکاربر کانتینر (Container User)\fP auto $UID T{ nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.) T} host $UID T{ 0 (حساب کاربری پیش‌فرض به کاربر root درون کانتینر نگاشت می‌شود.) T} keep-id $UID T{ $UID (نگاشت حساب کاربری به همان مقدار UID در درون کانتینر.) T} keep-id:uid=200,gid=210 $UID T{ 200:210 (نگاشت حساب کاربری به مقادیر UID و GID مشخص‌شده در کانتینر.) T} nomap $UID T{ nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.) T} .TE .PP مقادیر معتبر \fImode\fP عبارتند از: .PP \fBauto\fP[:\fIOPTIONS,...\fP]: ایجاد خودکار یک فضای نام کاربری منحصربه‌فرد. .IP \(bu 2 \fBحالت دارای ریشه (rootful mode)\fR: پرچم \fB--userns=auto\fR مستلزم آن است که نام کاربری \fBcontainers\fP در فایل‌های /etc/subuid و /etc/subgid با محدوده‌ای استفاده‌نشده از شناسه‌های کاربری فرعی (subordinate) که کانتینرهای پادمن مجاز به تخصیص آن‌ها هستند مشخص شده باشد. مثال: \fBcontainers:2147483647:2147483648\fR\&. .IP \(bu 2 \fBحالت بدون ریشه (rootless mode)\fR: محدوده کاربران از فایل‌های /etc/subuid و /etc/subgid استفاده خواهد شد. توجه داشته باشید که اجرای یک کانتینر منفرد بدون استفاده از --userns=auto از کل محدوده UIDها استفاده کرده و امکان تقسیم‌بندی بیشتر را نمی‌دهد. به subuid(5) مراجعه کنید. .PP پادمن محدوده‌های منحصربه‌فردی از UIDها و GIDها را از شناسه‌های کاربری فرعی \fBcontainers\fR تخصیص می‌دهد. اندازه این محدوده‌ها بر اساس تعداد UIDهای مورد نیاز در ایمیج تعیین می‌شود. تعداد UIDها و GIDها را می‌توان با گزینه \fBsize\fR بازنویسی کرد. .PP گزینه \fB--userns=keep-id\fR از تمامی subuidها و subgidهای کاربر بهره می‌برد. گزینه \fB--userns=nomap\fR از تمامی subuidها و subgidهای کاربر به جز شناسه خود کاربر استفاده می‌کند. استفاده از \fB--userns=auto\fR هنگام راه‌اندازی کانتینرهای جدید تا زمانی که کانتینرهایی وجود داشته باشند که با \fB--userns=nomap\fR یا \fB--userns=keep-id\fR بدون محدود کردن اندازه فضای نام کاربری شروع به کار کرده‌اند، عمل نخواهد کرد. .PP گزینه‌های معتبر \fBauto\fR: .IP \(bu 2 \fIgidmapping\fP=\fICONTAINER_GID:HOST_GID:SIZE\fP: برای اجبار به وجود یک نگاشت GID در فضای نام کاربری. .IP \(bu 2 \fIsize\fP=\fISIZE\fP: جهت تعیین اندازه صریح برای فضای نام کاربری خودکار، برای مثال \fB--userns=auto:size=8192\fR. اگر \fBsize\fR مشخص نشود، \fBauto\fR اندازه‌ای را برای فضای نام کاربری تخمین می‌زند. .IP \(bu 2 \fIuidmapping\fP=\fICONTAINER_UID:HOST_UID:SIZE\fP: برای اجبار به وجود یک نگاشت UID در فضای نام کاربری. .PP شناسه کاربر و گروه (UID و GID) میزبان در \fIgidmapping\fP و \fIuidmapping\fP می‌توانند به صورت اختیاری با نماد \fB@\fR پیشوندگذاری شوند. در این حالت، پادمن شناسه میانی متناظر با شناسه میزبان را جستجو کرده و شناسه میانی یافته‌شده را به شناسه کانتینر نگاشت می‌کند. برای جزئیات به \fB--uidmap\fP مراجعه کنید. .PP \fBcontainer:\fP\fIid\fP: پیوستن به فضای نام کاربری کانتینر مشخص‌شده. .PP \fBhost\fP یا \fB""\fP (رشته خالی): اجرا در فضای نام کاربری فراخواننده. فرایندهای در حال اجرا درون کانتینر همان امتیازاتی را روی میزبان دارند که هر فرایند دیگری که توسط کاربر فراخواننده اجرا می‌شود داراست. .PP \fBkeep-id\fP: یک فضای نام کاربری ایجاد می‌کند که در آن UID:GID کاربر فعلی به همان مقادیر درون کانتینر نگاشت می‌شوند. برای کانتینرهای ایجادشده توسط root، نگاشت فعلی در یک فضای نام کاربری جدید ایجاد می‌شود. .PP علاوه بر این، فرایند init در داخل کانتینر تحت شناسه کاربری (UID) کاربر فعلی اجرا خواهد شد. این رفتار دستور \fBUSER\fR ایمیج را لغو می‌کند مگر آنکه گزینه \fB--user\fR را به‌طور صریح مشخص نمایید. .PP گزینه‌های معتبر \fBkeep-id\fR: .IP \(bu 2 \fIuid\fP=UID: بازنویسی UID درون کانتینر که کاربر فعلی به آن نگاشت می‌گردد. .IP \(bu 2 \fIgid\fP=GID: بازنویسی GID درون کانتینر که کاربر فعلی به آن نگاشت می‌گردد. .IP \(bu 2 \fIsize\fP=SIZE: بازنویسی اندازه فضای نام کاربری پیکربندی‌شده. این گزینه برای پر نشدن تمامی شناسه‌های در دسترس مفید است. هنگام اجرا به عنوان کاربر root پشتیبانی نمی‌شود. .PP \fBnomap\fP: یک فضای نام کاربری ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه فعلی به درون کانتینر نگاشت نمی‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر root مجاز نیست. .PP \fBns:\fP\fInamespace\fP: اجرای پاد در فضای نام کاربری موجودِ ارائه‌شده. .SS \fB--wait\fP, \fB-w\fP اجرای پادها و کانتینرها در پیش‌زمینه (foreground). مقدار پیش‌فرض false است. .PP در هر زمان می‌توانید دستور \fBpodman pod ps\fR را در شل دیگری اجرا کنید تا فهرستی از پادها و کانتینرهای در حال اجرا را مشاهده نمایید. .PP هنگامی که در حالت tty متصل هستید، می‌توانید با فشردن کلیدهای ترکیبی Ctrl-C یا با دریافت هر سیگنال وقفه دیگری، پادها و کانتینرها را از بین ببرید. .PP تمامی پادها، کانتینرها و حجم‌های ایجادشده توسط \fBpodman kube play\fR در هنگام خروج حذف می‌شوند. .SH "مثال‌ها (EXAMPLES)" ایجاد مجدد پاد و کانتینرهای شرح‌داده‌شده در فایل YAML مشخص‌شده روی میزبان: .EX $ podman kube play demo.yml 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 .EE .PP ایجاد مجدد پاد و کانتینرهای مشخص‌شده در فایل YAML ارائه‌شده به stdin: .EX $ cat demo.yml | podman kube play - 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 .EE .PP متوقف کردن و حذف پاد و کانتینرها بر اساس توضیحات فایل YAML مشخص‌شده: .EX $ podman kube play --down demo.yml Pods stopped: 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 Pods removed: 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 .EE .PP ارائه چندین فایل کانفیگ‌مپ به عنوان منابع متغیرهای محیطی در پادها و کانتینرهای مشخص‌شده: .EX $ 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 .EE .PP ایجاد پاد متصل به دو شبکه با اختصاص IP ایستا روی هر یک: .EX $ podman kube play demo.yml --network net1:ip=10.89.1.5 --network net2:ip=10.89.10.10 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 .EE .PP لطفاً توجه داشته باشید که شبکه‌ها باید ابتدا با استفاده از دستور podman-network-create(1) ایجاد شده باشند. .PP ایجاد و برچیدن از یک URL اشاره‌کننده به فایل YAML: .EX $ podman kube play https://podman.io/demo.yml 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 $ podman kube play --down https://podman.io/demo.yml Pods stopped: 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 Pods removed: 52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6 .EE .PP در صورتی که فایل YAML مورد اشاره توسط نشانی URL پس از ایجاد پادها و کانتینرها دچار تغییر یا دگرگونی شده باشد، دستور \fBpodman kube play --down\fR با URL کار نخواهد کرد. .SH "پشتیبانی Podman Kube Play" این سند فیلدهای YAML کوبرنتیز را که در حال حاضر توسط دستور \fBpodman kube play\fP پشتیبانی می‌شوند مشخص می‌کند. .PP نکته: مقدار \fBN/A\fP به این معناست که این گزینه در یک محیط پادمن تک‌گره‌ای (single-node) قابل پشتیبانی نیست. .SH "فیلدهای پاد (Pod Fields)" .TS allbox; l l l l . \fBفیلد (Field)\fP \fBپشتیبانی (Support)\fP 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 خیر .TE .SH "فیلدهای کانتینر (Container Fields)" .TS allbox; l l l l . \fBفیلد (Field)\fP \fBپشتیبانی (Support)\fP 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 خیر .TE .SH "فیلدهای PersistentVolumeClaim" .TS allbox; l l l l . \fBفیلد (Field)\fP \fBپشتیبانی (Support)\fP volumeName خیر storageClassName ✅ volumeMode خیر accessModes ✅ selector خیر resources\&.limits خیر resources\&.requests ✅ .TE .SH "فیلدهای ConfigMap" .TS allbox; l l l l . \fBفیلد (Field)\fP \fBپشتیبانی (Support)\fP binaryData ✅ data ✅ immutable خیر .TE .SH "فیلدهای Deployment" .TS allbox; l l l l . \fBفیلد (Field)\fP \fBپشتیبانی (Support)\fP replicas T{ ✅ (تعداد واقعی رپلیکا نادیده گرفته شده و روی ۱ تنظیم می‌شود) T} selector ✅ template ✅ minReadySeconds خیر strategy\&.type خیر strategy\&.rollingUpdate\&.maxSurge خیر strategy\&.rollingUpdate\&.maxUnavailable خیر revisionHistoryLimit خیر progressDeadlineSeconds خیر paused خیر .TE .SH "فیلدهای DaemonSet" .TS allbox; l l l l . \fBفیلد (Field)\fP \fBپشتیبانی (Support)\fP selector ✅ template ✅ minReadySeconds خیر strategy\&.type خیر strategy\&.rollingUpdate\&.maxSurge خیر strategy\&.rollingUpdate\&.maxUnavailable خیر revisionHistoryLimit خیر .TE .SH "فیلدهای Job" .TS allbox; l l l l . \fBفیلد (Field)\fP \fBپشتیبانی (Support)\fP activeDeadlineSeconds خیر selector خیر (به‌طور خودکار توسط k8s تنظیم می‌شود) template ✅ backoffLimit خیر completionMode خیر completions T{ خیر (با kube generate روی ۱ تنظیم می‌شود) T} manualSelector خیر parallelism T{ خیر (با kube generate روی ۱ تنظیم می‌شود) T} podFailurePolicy خیر suspend خیر ttlSecondsAfterFinished خیر .TE .SH "همچنین ببینید (SEE ALSO)" \fBpodman(1)\fP, \fBpodman-kube(1)\fP, \fBpodman-kube-down(1)\fP, \fBpodman-network-create(1)\fP, \fBpodman-kube-generate(1)\fP, \fBpodman-build(1)\fP, \fBcontainers-certs.d(5)\fP