podman-kube.unit(5) File Formats Manual podman-kube.unit(5)

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

name.kube

واحد‌های Kube با پسوند .kube نام‌گذاری می‌شوند و شامل یک بخش [Kube] هستند که نحوه اجرای podman kube play را به عنوان یک سرویس توصیف می‌کند. فایل سرویس حاصل شامل خطی مانند ExecStart=podman kube play … file.yml خواهد بود، و بیشتر کلیدهای این بخش گزینه‌های خط فرمان ارسال‌شده به Podman را کنترل می‌کنند. با این حال، برخی گزینه‌ها بر جزئیات نحوه راه‌اندازی و تعامل systemd با کانتینر نیز تأثیر می‌گذارند.

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

فایل .kube در هنگام بوت یا بارگذاری مجدد توسط podman-system-generator پردازش شده و یک .service در systemd ایجاد می‌کند که podman kube play را اجرا می‌نماید. این سرویس مانند هر واحد دیگری قابل مدیریت است:

systemctl --user start name.service

گزینه‌های معتبر برای [Kube] در زیر فهرست شده‌اند:

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

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

مشخص می‌کند که آیا پادها و کانتینرهای این بار کاری کوبرنتیز به‌طور خودکار به‌روزرسانی شوند یا خیر (podman-auto-update(1)). AutoUpdate را می‌توان چندین بار مشخص کرد. مقادیر زیر پشتیبانی می‌شوند:

  • registry: برای ساخت کانتینر نیاز به یک ارجاع تصویر کاملاً واجد شرایط (به عنوان مثال، quay.io/podman/stable:latest) دارد. این الزام برای دانستن این است که دقیقاً کدام تصویر باید بررسی و دریافت (pull) شود. اگر از شناسه تصویر (Image ID) استفاده شده باشد، Podman دیگر نمی‌داند کدام تصویر را باید بررسی/دریافت کند.
  • local: به Podman می‌گوید تصویری را که کانتینر استفاده می‌کند با تصویری با نام خام آن در فضای ذخیره‌سازی محلی مقایسه کند. اگر تصویری به صورت محلی به‌روزرسانی شود، Podman به سادگی واحد systemd را که Quadlet کوبرنتیز را اجرا می‌کند، مجدداً راه‌اندازی (restart) می‌کند.
  • name/(local|registry): به Podman دستور می‌دهد که به‌روزرسانی خودکار local یا registry را روی نام کانتینر مشخص‌شده انجام دهد.

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

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

بارگذاری ماژول مشخص‌شده containers.conf(5).

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

کنترل نحوه خروج PID اصلی سرویس systemd. مقادیر زیر پشتیبانی می‌شوند: - all: خروج با کد غیرصفر در صورتی که تمام کانتینرها با شکست مواجه شده باشند (یعنی با کد غیرصفر خارج شده باشند) - any: خروج با کد غیرصفر در صورتی که هر یک از کانتینرها با شکست مواجه شده باشد - none: خروج با کد صفر و نادیده گرفتن کانتینرهای شکست‌خورده

مقدار پیش‌فرض فعلی none است.

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

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

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

حذف تمام منابع، از جمله حجم‌ها (volumes)، هنگام فراخوانی podman kube down. معادل گزینه --force در Podman است.

درایور گزارش‌گیری (logging) برای کانتینر. گزینه‌های موجود در حال حاضر عبارتند از k8s-file، journald، none، passthrough و passthrough-tty، که json-file برای سازگاری با اسکریپت‌ها نام مستعار k8s-file است. (پیش‌فرض journald).

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

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

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

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

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

حالت‌های خاص:

  • اگر name شبکه با .network خاتمه یابد، یک شبکه Podman به نام systemd-$name استفاده می‌شود و سرویس systemd تولیدشده شامل یک وابستگی به $name-network.service خواهد بود. چنین شبکه‌ای را می‌توان به طور خودکار با استفاده از یک فایل Quadlet با نام $name.network ایجاد کرد. نکته: فایل .network مربوطه باید وجود داشته باشد.
  • اگر name با .container خاتمه یابد، کانتینر از پشته شبکه کانتینر دیگری که توسط $name.container ایجاد شده است مجدداً استفاده خواهد کرد. سرویس systemd تولیدشده شامل یک وابستگی به $name.service خواهد بود. نکته: فایل .container مربوطه باید وجود داشته باشد.

مقادیر معتبر 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)، هدایت پورت به‌طور پیش‌فرض از 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 استفاده کنید.

  • <نام یا شناسه شبکه>[:OPTIONS,...]: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این نام یا شناسه شبکه‌ای است که توسط podman network create ایجاد شده است. امکان تعیین همان گزینه‌های توضیح‌داده‌شده در حالت bridge در بالا وجود دارد. از گزینه --network چندین بار برای تعیین شبکه‌های اضافی استفاده کنید.
    برای سازگاری با نسخه‌های پیشین، امکان تعیین شبکه‌ها با کاما در اولین آرگومان --network نیز وجود دارد، اما این کار مانع از استفاده شما از گزینه‌های شرح‌داده‌شده در بخش bridge بالا می‌شود.
  • none: ایجاد یک فضای نام شبکه برای کانتینر اما بدون پیکربندی رابط‌های شبکه برای آن، بنابراین کانتینر هیچ اتصال شبکه‌ای نخواهد داشت.
  • container:id: استفاده مجدد از پشته شبکه کانتینر دیگر.
  • host: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام ایزوله. هشدار: این کار به کانتینر دسترسی کامل به سوکت‌های انتزاعی دامنه‌ی یونیکس (Unix domain sockets) و سوکت‌های TCP/UDP متصل به localhost را می‌دهد. از آنجا که این سازوکارها اغلب برای جلوگیری از دسترسی به سرویس‌های حساس سیستمی و ایزوله‌سازی آن‌ها از دسترسی نهادهای خارجی استفاده می‌شوند، استفاده از این گزینه ممکن است یک آسیب‌پذیری امنیتی تلقی شود.
  • ns:path: مسیر فضای نام شبکه‌ای که باید به آن متصل شد.
  • private: ایجاد یک فضای نام جدید برای کانتینر. این حالت برای کانتینرهای با دسترسی ریشه از حالت bridge و برای کانتینرهای بدون دسترسی ریشه از pasta استفاده می‌کند.
  • pasta[:OPTIONS,...]: استفاده از pasta(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode).
    این حالت پیش‌فرض برای کانتینرهای بدون دسترسی ریشه است و فقط در حالت بدون ریشه پشتیبانی می‌شود.
    به‌طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط پاد از میزبان کپی می‌شوند. هدایت پورت، آدرس IP مبدأ اصلی را حفظ می‌کند. گزینه‌های شرح‌داده‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما تعیین کرد.
    از نظر گزینه‌های pasta(1)، گزینه --config-net به‌طور پیش‌فرض داده می‌شود تا شبکه در هنگام شروع کانتینر پیکربندی شود، و --no-map-gw نیز به‌طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم از کانتینر به میزبان با استفاده از آدرس گیت‌وی جلوگیری شود. مورد دوم را می‌توان با ارسال --map-gw در گزینه‌های خاص pasta لغو کرد (با وجود اینکه یک گزینه واقعی pasta(1) نیست).
    برای یکپارچگی بهتر با مدیریت DNS، گزینه --dns-forward 169.254.1.1 به‌طور پیش‌فرض ارسال می‌شود و این آدرس به عنوان اولین تحلیل‌کننده (resolver) به resolv.conf(5) اضافه می‌شود. در صورتی که بخواهید از آدرس IP متفاوتی استفاده کنید، امکان ارسال صریح --dns-forward وجود دارد.
    برای اینکه مدخل host.containers.internal در /etc/hosts کار کند و اتصال به میزبان را مجاز کند، گزینه --map-guest-addr 169.254.1.2 به‌طور پیش‌فرض ارسال می‌شود. مجدداً، می‌توان آن را به صورت صریح برای انتخاب آدرس IP متفاوت تنظیم کرد.
    همچنین، در صورتی که به ترتیب هیچ هدایت پورت TCP یا UDP از میزبان به کانتینر پیکربندی نشده باشد (از طریق --publish در Podman یا با ارسال مستقیم گزینه‌های -t/-u در pasta)، گزینه‌های -t none و -u none ارسال می‌شوند تا هدایت خودکار پورت بر اساس پورت‌های متصل غیرفعال شود. به همین ترتیب، -T none و -U none برای غیرفعال کردن همین قابلیت از کانتینر به میزبان داده می‌شوند.
    تمام گزینه‌ها را می‌توان در containers.conf(5) نیز تنظیم کرد؛ کلید pasta_options را در بخش network در آن فایل ببینید.
    چند مثال:
  • pasta:--map-gw: اجازه دسترسی مستقیم به میزبان با استفاده از آدرس گیت‌وی را به کانتینر می‌دهد.
  • 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 5201 از کانتینر به میزبان، با استفاده از رابط loopback به جای رابط tap برای بهبود عملکرد.

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

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

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

انتشار یک پورت کانتینر، یا بازه‌ای از پورت‌ها، به میزبان.

هر دو hostPort و containerPort را می‌توان به صورت بازه‌ای از پورت‌ها تعیین کرد. هنگام تعیین بازه برای هر دو، تعداد پورت‌های کانتینر در بازه باید با تعداد پورت‌های میزبان در بازه مطابقت داشته باشد.

اگر hostIP برابر 0.0.0.0 باشد، تنها به آدرس‌های IPv4 متصل می‌شود، اگر روی [::] تنظیم شود تنها به آدرس‌های IPv6 متصل می‌شود. در تمامی موارد دیگر دقیقاً به آدرس IP داده‌شده متصل خواهد شد. اگر hostIP اصلاً تنظیم نشود، پورت به تمام آدرس‌های IP روی میزبان، هم v4 و هم v6 (در صورت امکان) متصل می‌شود.

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

به‌طور پیش‌فرض، Podman پورت‌های TCP را منتشر می‌کند. برای انتشار پورت UDP به جای آن، udp را به عنوان پروتکل مشخص کنید. برای انتشار هم پورت‌های TCP و هم UDP، گزینه --publish را دو بار تنظیم کنید، به ترتیب با پروتکل‌های tcp و udp. کانتینرهای با دسترسی ریشه همچنین می‌توانند پورت‌ها را با استفاده از پروتکل sctp منتشر کنند.

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

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

انتشار پورت تنها برای کانتینرهایی پشتیبانی می‌شود که از فضای نام شبکه اختصاصی خود از طریق شبکه‌های bridge یا حالت شبکه pasta استفاده می‌کنند.

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

دستورالعمل WorkingDirectory را در بخش [Service] فایل واحد سرویس systemd تنظیم می‌کند. برای فعال‌سازی podman kube play جهت حل صحیح مسیرهای نسبی استفاده می‌شود. مقادیر پشتیبانی‌شده عبارتند از yaml و unit تا دایرکتوری کاری را به ترتیب روی مسیر فایل YAML یا فایل واحد Quadlet تنظیم کند.

همچنین کاربران می‌توانند دستورالعمل WorkingDirectory را به صراحت در بخش [Service] فایل .kube تنظیم کنند. لطفاً توجه داشته باشید که اگر دستورالعمل WorkingDirectory در بخش [Service] تنظیم شده باشد، Quadlet آن را تنظیم نخواهد کرد حتی اگر SetWorkingDirectory مقداردهی شده باشد.

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

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

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

این گزینه با GIDMap=، UIDMap=، SubUIDMap= و SubGIDMap= ناسازگار است.

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

کلید کاربر میزبان کاربر کانتینر
auto $UID nil (شناسه UID کاربر میزبان به داخل کانتینر نگاشت نمی‌شود.)
host $UID 0 (حساب کاربری پیش‌فرض به کاربر ریشه در کانتینر نگاشت می‌شود.)
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 با یک بازه استفاده‌نشده از شناسه‌های فرعی کاربر که کانتینرهای Podman مجاز به تخصیص آن هستند، مشخص شده باشد. مثال: 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 می‌توانند به صورت اختیاری با نماد @ پیشوند داشته باشند. در این حالت، podman شناسه میانی متناظر با شناسه میزبان را جستجو کرده و شناسه میانیِ یافت‌شده را به شناسه کانتینر نگاشت می‌کند. برای جزئیات بیشتر به 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: اجرای کانتینر در فضای نام کاربر موجودِ داده‌شده.

مسیر مطلق یا نسبی نسبت به مکان فایل واحد، به فایل YAML کوبرنتیز مورد استفاده.

استقرار از یک YAML محلی:

[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

podman-kube-generate(1), podman-kube-play(1), podman-systemd.unit(5), systemd.unit(5)