'\" t
.nh
.TH podman-kube.unit 5

.SH "نام (NAME)"
podman-kube.unit \- فایل‌های واحد systemd برای مدیریت استقرارهای YAML کوبرنتیز در پودمن با استفاده از Quadlet


.SH "خلاصه دستور (SYNOPSIS)"
\fIname\fP\&.kube


.SH "توضیحات (DESCRIPTION)"
واحد‌های Kube با پسوند \fB\&.kube\fR نام‌گذاری می‌شوند و شامل یک بخش \fB[Kube]\fR هستند که نحوه اجرای \fBpodman kube play\fR را به عنوان یک سرویس توصیف می‌کند. فایل سرویس حاصل شامل خطی مانند \fBExecStart=podman kube play … file.yml\fR خواهد بود، و بیشتر کلیدهای این بخش گزینه‌های خط فرمان ارسال‌شده به Podman را کنترل می‌کنند. با این حال، برخی گزینه‌ها بر جزئیات نحوه راه‌اندازی و تعامل systemd با کانتینر نیز تأثیر می‌گذارند.

.PP
تنها یک کلید الزامی وجود دارد، \fBYaml\fR، که مسیر فایل YAML کوبرنتیز را مشخص می‌کند.


.SH "خلاصه کاربرد (USAGE SUMMARY)"
فایل \fB\&.kube\fR در هنگام بوت یا بارگذاری مجدد توسط \fBpodman-system-generator\fR پردازش شده و یک \fB\&.service\fR در systemd ایجاد می‌کند که \fBpodman kube play\fR را اجرا می‌نماید. این سرویس مانند هر واحد دیگری قابل مدیریت است:

.EX
systemctl --user start name.service
.EE


.SH "گزینه‌ها (OPTIONS)"
گزینه‌های معتبر برای \fB[Kube]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های \fB[Kube]\fR\fP	\fBمعادل در \fBpodman kube play\fR\fP
AutoUpdate=registry	T{
--annotation "io.containers.autoupdate=registry"
T}
ConfigMap=/tmp/config.map	--configmap /tmp/config.map
ContainersConfModule=/etc/nvd\&.conf	--module=/etc/nvd\&.conf
ExitCodePropagation=how	T{
نحوه انتشار وضعیت خطای کانتینر
T}
GlobalArgs=--log-level=debug	--log-level=debug
KubeDownForce=true	--force (برای \fBpodman kube down\fR)
LogDriver=journald	--log-driver journald
Network=host	--network host
PodmanArgs=--annotation=key=value	--annotation=key=value
PublishPort=8080:80	--publish 8080:80
SetWorkingDirectory=yaml	تنظیم \fBWorkingDirectory\fR فایل واحد به مکان فایل YAML
UserNS=keep-id:uid=200,gid=210	T{
--userns keep-id:uid=200,gid=210
T}
Yaml=/tmp/kube.yaml	T{
podman kube play /tmp/kube.yaml
T}
.TE

.PP
کلیدهای پشتیبانی‌شده در بخش \fB[Kube]\fR عبارتند از:

.SS \fBAutoUpdate=\fR
مشخص می‌کند که آیا پادها و کانتینرهای این بار کاری کوبرنتیز به‌طور خودکار به‌روزرسانی شوند یا خیر (podman-auto-update(1)). \fBAutoUpdate\fR را می‌توان چندین بار مشخص کرد. مقادیر زیر پشتیبانی می‌شوند:
.IP \(bu 2
\fBregistry\fR: برای ساخت کانتینر نیاز به یک ارجاع تصویر کاملاً واجد شرایط (به عنوان مثال، quay.io/podman/stable:latest) دارد. این الزام برای دانستن این است که دقیقاً کدام تصویر باید بررسی و دریافت (pull) شود. اگر از شناسه تصویر (Image ID) استفاده شده باشد، Podman دیگر نمی‌داند کدام تصویر را باید بررسی/دریافت کند.
.IP \(bu 2
\fBlocal\fR: به Podman می‌گوید تصویری را که کانتینر استفاده می‌کند با تصویری با نام خام آن در فضای ذخیره‌سازی محلی مقایسه کند. اگر تصویری به صورت محلی به‌روزرسانی شود، Podman به سادگی واحد systemd را که Quadlet کوبرنتیز را اجرا می‌کند، مجدداً راه‌اندازی (restart) می‌کند.
.IP \(bu 2
\fBname/(local|registry)\fR: به Podman دستور می‌دهد که به‌روزرسانی خودکار \fBlocal\fR یا \fBregistry\fR را روی نام کانتینر مشخص‌شده انجام دهد.

.SS \fBConfigMap=path\fR
استفاده از ConfigMap YAML کوبرنتیز در \fIpath\fP برای فراهم کردن مقادیر متغیرهای محیطی درون کانتینرهای پاد. (این گزینه در کلاینت راه دور Podman در دسترس نیست)

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

.SS \fBContainersConfModule=module\fR
بارگذاری ماژول مشخص‌شده containers.conf(5).

.PP
این گزینه را می‌توان چندین بار ذکر کرد.

.SS \fBExitCodePropagation=how\fR
کنترل نحوه خروج PID اصلی سرویس systemd. مقادیر زیر پشتیبانی می‌شوند:
- \fBall\fR: خروج با کد غیرصفر در صورتی که تمام کانتینرها با شکست مواجه شده باشند (یعنی با کد غیرصفر خارج شده باشند)
- \fBany\fR: خروج با کد غیرصفر در صورتی که هر یک از کانتینرها با شکست مواجه شده باشد
- \fBnone\fR: خروج با کد صفر و نادیده گرفتن کانتینرهای شکست‌خورده

.PP
مقدار پیش‌فرض فعلی \fBnone\fR است.

.SS \fBGlobalArgs=\fR
این کلید شامل فهرستی از آرگومان‌ها است که مستقیماً بعد از دستور \fBpodman\fR در فایل تولیدشده قرار می‌گیرند. این گزینه می‌تواند برای دسترسی به ویژگی‌های Podman که توسط مولد (generator) پشتیبانی نمی‌شوند استفاده شود. از آنجا که مولد از تداخلات غیرمنتظره‌ای که ممکن است توسط این آرگومان‌ها ایجاد شود آگاه نیست، استفاده از این گزینه توصیه نمی‌شود.

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

.PP
این کلید را می‌توان چندین بار ذکر کرد.

.SS \fBKubeDownForce=true\fR
حذف تمام منابع، از جمله حجم‌ها (volumes)، هنگام فراخوانی \fBpodman kube down\fR.
معادل گزینه \fB--force\fR در Podman است.

.SS \fBLogDriver=driver\fR
درایور گزارش‌گیری (logging) برای کانتینر. گزینه‌های موجود در حال حاضر عبارتند از \fBk8s-file\fP، \fBjournald\fP، \fBnone\fP، \fBpassthrough\fP و \fBpassthrough-tty\fP، که \fBjson-file\fP برای سازگاری با اسکریپت‌ها نام مستعار \fBk8s-file\fP است. (پیش‌فرض \fBjournald\fP).

.PP
دستور podman info در زیر، درایور گزارش‌گیری پیش‌فرض سیستم را نمایش می‌دهد.

.EX
$ podman info --format '{{ .Host.LogDriver }}'
journald
.EE

.PP
درایور \fBpassthrough\fP جریان‌های استاندارد (stdin، stdout، stderr) را به کانتینر هدایت می‌کند. این گزینه با کلاینت راه دور Podman، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2)، و در یک tty مجاز نیست، زیرا در برابر حملات از طریق TIOCSTI آسیب‌پذیر است.

.PP
درایور \fBpassthrough-tty\fP همانند \fBpassthrough\fP است، با این تفاوت که در صورت تمایل کاربر، امکان استفاده در یک TTY را نیز فراهم می‌کند.

.SS \fBNetwork=mode\fR
تنظیم حالت شبکه برای کانتینر.

.PP
حالت‌های خاص:
.IP \(bu 2
اگر \fBname\fR شبکه با \fB\&.network\fR خاتمه یابد، یک شبکه Podman به نام \fBsystemd-$name\fR استفاده می‌شود و سرویس systemd تولیدشده شامل یک وابستگی به \fB$name-network.service\fR خواهد بود. چنین شبکه‌ای را می‌توان به طور خودکار با استفاده از یک فایل Quadlet با نام \fB$name.network\fR ایجاد کرد. نکته: فایل \fB\&.network\fR مربوطه باید وجود داشته باشد.
.IP \(bu 2
اگر \fBname\fR با \fB\&.container\fR خاتمه یابد، کانتینر از پشته شبکه کانتینر دیگری که توسط \fB$name.container\fR ایجاد شده است مجدداً استفاده خواهد کرد. سرویس systemd تولیدشده شامل یک وابستگی به \fB$name.service\fR خواهد بود. نکته: فایل \fB\&.container\fR مربوطه باید وجود داشته باشد.

.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)، هدایت پورت به‌طور پیش‌فرض از \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: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام ایزوله. هشدار: این کار به کانتینر دسترسی کامل به سوکت‌های انتزاعی دامنه‌ی یونیکس (Unix domain sockets) و سوکت‌های TCP/UDP متصل به localhost را می‌دهد. از آنجا که این سازوکارها اغلب برای جلوگیری از دسترسی به سرویس‌های حساس سیستمی و ایزوله‌سازی آن‌ها از دسترسی نهادهای خارجی استفاده می‌شوند، استفاده از این گزینه ممکن است یک آسیب‌پذیری امنیتی تلقی شود.
.IP \(bu 2
\fBns:\fP\fIpath\fP: مسیر فضای نام شبکه‌ای که باید به آن متصل شد.
.IP \(bu 2
\fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر. این حالت برای کانتینرهای با دسترسی ریشه از حالت \fBbridge\fP و برای کانتینرهای بدون دسترسی ریشه از \fBpasta\fP استفاده می‌کند.
.IP \(bu 2
\fBpasta[:OPTIONS,...]\fP: استفاده از \fBpasta\fP(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode).
.br
این حالت پیش‌فرض برای کانتینرهای بدون دسترسی ریشه است و فقط در حالت بدون ریشه پشتیبانی می‌شود.
.br
به‌طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط پاد از میزبان کپی می‌شوند. هدایت پورت، آدرس IP مبدأ اصلی را حفظ می‌کند. گزینه‌های شرح‌داده‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما تعیین کرد.
.br
از نظر گزینه‌های pasta(1)، گزینه \fB--config-net\fP به‌طور پیش‌فرض داده می‌شود تا شبکه در هنگام شروع کانتینر پیکربندی شود، و \fB--no-map-gw\fP نیز به‌طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم از کانتینر به میزبان با استفاده از آدرس گیت‌وی جلوگیری شود. مورد دوم را می‌توان با ارسال \fB--map-gw\fP در گزینه‌های خاص pasta لغو کرد (با وجود اینکه یک گزینه واقعی pasta(1) نیست).
.br
برای یکپارچگی بهتر با مدیریت DNS، گزینه \fB--dns-forward 169.254.1.1\fP به‌طور پیش‌فرض ارسال می‌شود و این آدرس به عنوان اولین تحلیل‌کننده (resolver) به 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 در Podman یا با ارسال مستقیم گزینه‌های \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: اجازه دسترسی مستقیم به میزبان با استفاده از آدرس گیت‌وی را به کانتینر می‌دهد.
.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 5201 از کانتینر به میزبان، با استفاده از رابط loopback به جای رابط tap برای بهبود عملکرد.
.RE

.SS \fBPodmanArgs=\fR
این کلید شامل فهرستی از آرگومان‌ها است که مستقیماً به انتهای دستور \fBpodman\fR در فایل تولیدشده ارسال می‌شوند. این گزینه می‌تواند برای دسترسی به ویژگی‌های Podman که در غیر این صورت توسط مولد پشتیبانی نمی‌شوند استفاده شود. از آنجا که مولد از تداخلات غیرمنتظره‌ای که ممکن است توسط این آرگومان‌ها ایجاد شود آگاه نیست، استفاده از این گزینه توصیه نمی‌شود.

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

.PP
این کلید را می‌توان چندین بار ذکر کرد.

.SS \fBPublishPort=[[hostIP:][hostPort]:]containerPort[/protocol]\fR
انتشار یک پورت کانتینر، یا بازه‌ای از پورت‌ها، به میزبان.

.PP
هر دو \fIhostPort\fP و \fIcontainerPort\fP را می‌توان به صورت بازه‌ای از پورت‌ها تعیین کرد. هنگام تعیین بازه برای هر دو، تعداد پورت‌های کانتینر در بازه باید با تعداد پورت‌های میزبان در بازه مطابقت داشته باشد.

.PP
اگر \fIhostIP\fP برابر \fB0.0.0.0\fR باشد، تنها به آدرس‌های IPv4 متصل می‌شود، اگر روی \fB[::]\fR تنظیم شود تنها به آدرس‌های IPv6 متصل می‌شود. در تمامی موارد دیگر دقیقاً به آدرس IP داده‌شده متصل خواهد شد. اگر \fIhostIP\fP اصلاً تنظیم نشود، پورت به تمام آدرس‌های IP روی میزبان، هم v4 و هم v6 (در صورت امکان) متصل می‌شود.

.PP
مقدار پیش‌فرض \fIhostIP\fP را می‌توان در \fBcontainers.conf(5)\fP با استفاده از گزینه \fBdefault_host_ips\fR در بخش \fB[network]\fR پیکربندی کرد. این گزینه آرایه‌ای را می‌پذیرد تا بتوان چندین آدرس IP متصل را تنظیم کرد. برای مثال، تنظیم \fBdefault_host_ips = ["127.0.0.1", "::1"]\fR باعث می‌شود پورت به ترتیب روی آدرس‌های localhost مربوط به ipv4 و ipv6 منتشر شود. یک \fIhostIP\fP صریحِ تنظیم‌شده در دستور، همیشه بر گزینه پیکربندی اولویت دارد.

.PP
به‌طور پیش‌فرض، Podman پورت‌های TCP را منتشر می‌کند. برای انتشار پورت UDP به جای آن، \fBudp\fR را به عنوان پروتکل مشخص کنید. برای انتشار هم پورت‌های TCP و هم UDP، گزینه \fB--publish\fR را دو بار تنظیم کنید، به ترتیب با پروتکل‌های \fBtcp\fR و \fBudp\fR. کانتینرهای با دسترسی ریشه همچنین می‌توانند پورت‌ها را با استفاده از پروتکل \fBsctp\fR منتشر کنند.

.PP
نیازی به مشخص کردن پورت میزبان نیست (مانند \fBpodman run -p 127.0.0.1::80\fR). اگر مشخص نشود، پورت کانتینر به صورت تصادفی به پورتی روی میزبان اختصاص می‌یابد.

.PP
از \fBpodman port\fP برای مشاهده نگاشت واقعی استفاده کنید: \fBpodman port $CONTAINER $CONTAINERPORT\fR.

.PP
انتشار پورت تنها برای کانتینرهایی پشتیبانی می‌شود که از فضای نام شبکه اختصاصی خود از طریق شبکه‌های \fBbridge\fR یا حالت شبکه \fBpasta\fR استفاده می‌کنند.

.PP
برای شبکه‌های پل بدون دسترسی ریشه، هدایت پورت به‌طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند، که یک پروکسی فضای کاربر است و IPهای مبدأ کلاینت را حفظ نمی‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR از \fBcontainers.conf(5)\fP باعث سوئیچ به هدایت در سطح کرنل pasta از طریق \fBpesto\fR می‌شود که آدرس IP کلاینت اصلی را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند.

.SS \fBSetWorkingDirectory=yaml\fR
دستورالعمل \fBWorkingDirectory\fR را در بخش \fB[Service]\fR فایل واحد سرویس systemd تنظیم می‌کند.
برای فعال‌سازی \fBpodman kube play\fR جهت حل صحیح مسیرهای نسبی استفاده می‌شود.
مقادیر پشتیبانی‌شده عبارتند از \fByaml\fR و \fBunit\fR تا دایرکتوری کاری را به ترتیب روی مسیر فایل YAML یا فایل واحد Quadlet تنظیم کند.

.PP
همچنین کاربران می‌توانند دستورالعمل \fBWorkingDirectory\fR را به صراحت در بخش \fB[Service]\fR فایل \fB\&.kube\fR تنظیم کنند.
لطفاً توجه داشته باشید که اگر دستورالعمل \fBWorkingDirectory\fR در بخش \fB[Service]\fR تنظیم شده باشد، Quadlet آن را تنظیم نخواهد کرد حتی اگر \fBSetWorkingDirectory\fR مقداردهی شده باشد.

.SS \fBUserNS=mode\fR
تنظیم حالت فضای نام کاربر (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
این گزینه با \fBGIDMap=\fP، \fBUIDMap=\fP، \fBSubUIDMap=\fP و \fBSubGIDMap=\fP ناسازگار است.

.PP
نگاشت‌های کلید --userns= برای کاربر بدون ریشه (Rootless):

.TS
allbox;
l l l 
l l l .
\fBکلید\fP	\fBکاربر میزبان\fP	\fBکاربر کانتینر\fP
auto	$UID	T{
nil (شناسه UID کاربر میزبان به داخل کانتینر نگاشت نمی‌شود.)
T}
host	$UID	T{
0 (حساب کاربری پیش‌فرض به کاربر ریشه در کانتینر نگاشت می‌شود.)
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\fR در فایل‌های /etc/subuid و /etc/subgid با یک بازه استفاده‌نشده از شناسه‌های فرعی کاربر که کانتینرهای Podman مجاز به تخصیص آن هستند، مشخص شده باشد. مثال: \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 پیشوند داشته باشند.
در این حالت، podman شناسه میانی متناظر با شناسه میزبان را جستجو کرده و شناسه میانیِ یافت‌شده را به شناسه کانتینر نگاشت می‌کند.
برای جزئیات بیشتر به \fBUIDMap=\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 \fBYaml=path\fR
مسیر مطلق یا نسبی نسبت به مکان فایل واحد، به فایل YAML کوبرنتیز مورد استفاده.


.SH "مثال‌ها (EXAMPLES)"
استقرار از یک YAML محلی:

.EX
[Unit]
Description=A kubernetes yaml based service
Before=local-fs.target

[Kube]
Yaml=/opt/k8s/deployment.yml

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target
.EE


.SH "همچنین ببینید (SEE ALSO)"
podman-kube-generate(1),
podman-kube-play(1),
podman-systemd.unit(5),
systemd.unit(5)