واژه‌نامه

این واژه‌نامه به عنوان فهرستی جامع و استاندارد از اصطلاحات کوبرنتیز در نظر گرفته شده است. شامل اصطلاحات فنی خاص کوبرنتیز و همچنین اصطلاحات عمومی‌تر است که زمینه مفیدی ارائه می‌دهند.

فیلتر اصطلاحات بر اساس برچسب‌ها

اجزای داخلی کوبرنتیز.
مرتبط با توسعه متن‌باز کوبرنتیز.
نوعی از منابع که کوبرنتیز به طور پیش‌فرض پشتیبانی می‌کند.
سفارشی‌سازی‌های پشتیبانی‌شده کوبرنتیز.
مرتبط برای کاربران تازه‌کار کوبرنتیز.
نحوه ارتباط اجزای کوبرنتیز با یکدیگر (و با برنامه‌های خارج از کلاستر).
راه‌اندازی و نگهداری کوبرنتیز.
حفظ امنیت برنامه‌های کوبرنتیز.
نحوه مدیریت داده‌های پایدار توسط برنامه‌های کوبرنتیز.
نرم‌افزاری که استفاده از کوبرنتیز را آسان‌تر یا بهتر می‌کند.
نمایانگر نوع رایج کاربر کوبرنتیز.
برنامه‌هایی که روی کوبرنتیز اجرا می‌شوند.
معماری جامعه شیء اصلی افزونه مبانی شبکه عملیات امنیت ذخیره‌سازی ابزار نوع کاربر بار کاری (Workload) انتخاب همه لغو انتخاب همه

کلیک کن بروی [+] در زیر کلیک کنید تا توضیح بیشتری برای هر اصطلاح خاص دریافت کنید.

  • API کوبرنتیز

    اپلیکیشنی که قابلیت‌های کوبرنتیز را از طریق رابط RESTful ارائه می‌دهد و وضعیت کلاستر را ذخیره می‌کند.

    [+]

    منابع کوبرنتیز و «رکورد های هدف» همگی به‌صورت آبجکت‌های API ذخیره می‌شوند و از طریق فراخوانی‌های RESTful به API تغییر داده می‌شوند. API این امکان را فراهم می‌کند که پیکربندی به‌صورت اعلانی (declarative) مدیریت شود. کاربران می‌توانند مستقیما با API کوبرنتیز تعامل کنند یا از ابزارهایی مانند kubectl استفاده کنند. هسته‌ی API کوبرنتیز انعطاف‌پذیر است و می‌توان آن را برای پشتیبانی از منابع سفارشی نیز گسترش داد.

  • cAdvisor

    cAdvisor (Container Advisor) به کاربران کانتینر درکی از میزان استفاده از منابع و ویژگی‌های عملکرد سیستم عامل در حال اجرا ارائه می‌دهد.

    [+]

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

  • cgroup (گروه کنترل - control group)

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

    [+]

    cgroup یک ویژگی هسته لینوکس است که میزان استفاده از منابع (پردازنده، حافظه، ورودی/خروجی دیسک، شبکه) را برای مجموعه‌ای از پروسه‌ها محدود، محاسبه و ایزوله می‌کند.

  • CIDR

    CIDR (مسیریابی بین دامنه‌ای بدون کلاس - Classless Inter-Domain Routing) یک نمادگذاری برای توصیف بلوک‌های آدرس‌های IP است و به طور گسترده در پیکربندی‌های مختلف شبکه استفاده می‌شود.

    [+]

    در زمینه کوبرنتیز، به هر گره (Node) از طریق آدرس شروع و یک ماسک زیرشبکه با استفاده از CIDR، طیفی از آدرس‌های IP اختصاص داده می‌شود. این به گره‌ها اجازه می‌دهد تا به هر پاد یک آدرس IP منحصر به فرد اختصاص دهند. اگرچه در ابتدا مفهومی برای IPv4 بود، CIDR گسترش یافته و شامل IPv6 نیز می‌شود.

  • CLA (توافق نامه مجوز مشارکت‌کننده - Contributor License Agreement)

    شرایطی که تحت آن یک مشارکت‌کننده به یک پروژه متن‌باز برای مشارکت‌های خود مجوز اعطا می‌کند.

    [+]

    CLA ها به حل و فصل اختلافات حقوقی مربوط به مالکیت مادی و معنوی مشارکت‌شده (IP) کمک می کنند.

  • ConfigMap

    یک ابجکت API که برای ذخیره داده‌های غیرمحرمانه در جفت‌های کلید-مقدار استفاده می‌شود. پادها می‌توانند ConfigMaps را به عنوان متغیرهای محیطی، آرگومان‌های خط فرمان یا به عنوان فایل‌های پیکربندی در یک volume مصرف کنند.

    [+]

    یک ConfigMap به شما امکان می‌دهد پیکربندی مختص محیط را از ایمیج‌های کانتینر خود جدا کنید، به طوری که برنامه‌های شما به راحتی قابل حمل باشند.

  • containerd

    یک مجری کانتینر با تأکید بر سادگی، استحکام و قابلیت حمل

    [+]

    containerd یک مجری container است که به عنوان یک سرویس (daemon) در لینوکس یا ویندوز اجرا می‌شود. containerd وظیفه دریافت و ذخیره image کانتینر، اجرای کانتینرها، ارائه دسترسی به شبکه و موارد دیگر را بر عهده دارد.

  • Control Plane

    لایه هماهنگ‌سازی کانتینر که API و رابط‌ها را برای تعریف، استقرار و مدیریت چرخه عمر کانتینرها در معرض دید قرار می‌دهد.

    [+]

    این لایه از اجزای مختلفی تشکیل شده است، مانند (اما محدود به این موارد نیست):

    این اجزا می‌توانند به عنوان سرویس‌های سنتی سیستم عامل (daemons) یا به عنوان کانتینرها اجرا شوند. میزبان‌هایی که این اجزا را اجرا می‌کنند، از لحاظ تاریخی masters نامیده می‌شدند.

  • CRI-O

    ابزاری که به شما امکان می‌دهد از مجری کانتینر OCI با کوبرنتیز CRI استفاده کنید.

    [+]

    CRI-O پیاده‌سازی رابط مجری کانتینر (CRI) است که امکان استفاده از کانتینر مجری سازگار با ابتکار کانتینر باز (OCI) مشخصات مجری را فراهم می‌کند.

    استقرار CRI-O به کوبرنتیز اجازه می‌دهد تا از هر مجری سازگار با OCI به عنوان مجری کانتینر برای اجرای پادها استفاده کند و image کانتینر OCI را از رجیستری‌های راه دور دریافت کند.

  • CronJob

    یک Job را مدیریت می‌کند که بر اساس یک برنامه زمانی اجرا می‌شود.

    [+]

    مشابه یک خط در فایل crontab، یک شیء CronJob یک برنامه زمانی را با استفاده از قالب cron مشخص می‌کند.

  • CustomResourceDefinition

    کد سفارشی که منبعی را برای اضافه کردن به سرور API کوبرنتیز شما بدون ساخت یک سرور سفارشی کامل تعریف می‌کند.

    [+]

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

  • DaemonSet

    تضمین می‌کند که یک رونوشت از Pod در مجموعه‌ای از گره‌ها در cluster در حال اجرا است.

    [+]

    برای استقرار سرویس‌های سیستمی مانند جمع‌آوری‌کننده‌های لاگ و عوامل نظارتی که معمولاً باید روی هر گره (Node) اجرا شوند، استفاده می‌شود.

  • Data Plane
    لایه‌ای که ظرفیت‌هایی مانند CPU، حافظه، شبکه و فضای ذخیره‌سازی را فراهم می‌کند تا کانتینرها بتوانند اجرا شوند و به شبکه متصل شوند. [+]

    لایه‌ای که ظرفیت‌هایی مانند CPU، حافظه، شبکه و فضای ذخیره‌سازی را فراهم می‌کند تا کانتینرها بتوانند اجرا شوند و به شبکه متصل شوند.

  • Deployment

    یک شیء API که یک برنامه تکثیر شده را مدیریت می‌کند، معمولاً با اجرای Podها بدون حالت محلی.

    [+]

    هر رونوشت توسط یک پاد (Pod) نمایش داده می‌شود و Podها بین گره‌ها یک cluster توزیع می‌شوند. برای بارهای کاری(Workloads) که به نگهداری وضعیت محلی نیاز دارند، استفاده از StatefulSet را در نظر بگیرید.

  • Device Plugin

    افزونه‌های دستگاه روی worker گره‌ها اجرا می‌شوند و به Podها دسترسی به منابعی مانند سخت‌افزار محلی که نیاز به مراحل اولیه یا راه‌اندازی خاص ارائه‌دهنده دارند را فراهم می‌کنند.

    [+]

    افزونه‌های دستگاه، منابع را به kubelet منتشر می‌کنند، به طوری که پادهای بار کاری(Workloads) بتوانند به ویژگی‌های سخت‌افزاری مربوط به گره‌(node)ای که آن پاد در آن اجرا می‌شود، دسترسی داشته باشند. می‌توانید یک افزونه دستگاه را به عنوان DaemonSet مستقر کنید، یا نرم‌افزار افزونه دستگاه را مستقیماً روی هر گره هدف نصب کنید.

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

  • DeviceClass

    دسته‌ای از دستگاه‌ها در cluster که می‌تواند با تخصیص منابع پویا (DRA) مورد استفاده قرار گیرد.

    [+]

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

    برای اطلاعات بیشتر، به تخصیص پویای منابع مراجعه کنید.

  • Docker

    docker (به طور خاص، Docker Engine) یک فناوری نرم‌افزاری است که مجازی‌سازی در سطح سیستم عامل را ارائه می‌دهد و با نام کانتینر نیز شناخته می‌شود.

    [+]

    Docker از قابلیت‌های جداسازی منابع هسته لینوکس (kernel)، مانند cgroups و kernel namespaces، و همچنین از سیستم فایل‌هایی با قابلیت ادغام مانند OverlayFS و موارد دیگر استفاده می‌کند تا امکان اجرای کانتینرهای مستقل در یک نمونه لینوکس واحد را فراهم کند و از سربار راه‌اندازی و نگهداری ماشین‌های مجازی (VM) جلوگیری شود.

  • Dockershim

    Dockershim یکی از اجزای کوبرنتیز نسخه ۱.۲۳ و قبل از آن است. این مؤلفه به kubelet اجازه می‌دهد تا با Docker Engine ارتباط برقرار کند.

    [+]

    از نسخه ۱.۲۴، Dockershim از کوبرنتیز حذف شده است. برای اطلاعات بیشتر، به سوالات متداول Dockershim مراجعه کنید.

  • Downstream (ابهام‌زدایی)

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

    [+]
    • در جامعه کوبرنتیز: در مکالمات اغلب از پایین‌دست به معنای اکوسیستم، کد یا ابزارهای شخص ثالثی که به پایگاه کد اصلی کوبرنتیز متکی هستند، استفاده می‌شود. برای مثال، یک ویژگی جدید در کوبرنتیز ممکن است توسط برنامه‌های پایین‌دست برای بهبود عملکردشان پذیرفته شود.
    • در GitHub یا git: قرارداد این است که به یک مخزن انشعاب‌یافته به عنوان downstream اشاره شود، در حالی که مخزن منبع upstream در نظر گرفته می‌شود.
  • Downward API

    سازوکار کوبرنتیز برای نمایش مقادیر فیلدهای Pod و Container به کدی که در یک Container اجرا می‌شود.

    [+]

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

    Downward API کوبرنتیز به کانتینرها اجازه می‌دهد تا اطلاعات مربوط به خود یا زمینه خود را در یک خوشه(cluster) کوبرنتیز مصرف کنند. برنامه‌های موجود در کانتینرها می‌توانند به آن اطلاعات دسترسی داشته باشند، بدون اینکه برنامه نیاز داشته باشد به عنوان کلاینت API کوبرنتیز عمل کند.

    دو راه برای نمایش فیلدهای Pod و container به یک container در حال اجرا وجود دارد:

    این دو روش برای نمایش فیلدهای Pod و container با هم، downward API نامیده می‌شوند.

  • Endpoints

    یک نقطه پایانی Service یکی از Podها (یا سرورهای خارجی) است که سرویس را پیاده‌سازی می‌کند.

    [+]

    برای سرویس‌هایی با انتخابگر، کنترل کننده EndpointSlices به طور خودکار یک یا چند
    ایجاد می‌کند که آدرس‌های IP پادهای نقطه انتهایی انتخاب شده را ارائه می‌دهد.

    همچنین می‌توان EndpointSliceها را به صورت دستی ایجاد کرد تا نقاط پایانی سرویس‌هایی را که هیچ انتخابگر (selector) مشخصی ندارند، نشان دهند.

  • EndpointSlice

    EndpointSliceها آدرس‌های IP مربوط به Podها را با انتخابگر‌ها تطبیق می‌دهند.

    [+]

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

  • etcd

    یک مخزن کلید-مقدارِ سازگار و با دسترسی بالا که به عنوان مخزن پشتیبان کوبرنتیز برای تمام داده‌های خوشه‌ای استفاده می‌شود.

    [+]

    اگر cluster کوبرنتیز شما از etcd به عنوان حافظه پشتیبان خود استفاده می‌کند، مطمئن شوید که یک طرح پشتیبان‌گیری (/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) برای داده‌ها دارید.

    شما می‌توانید اطلاعات عمیق‌تری در مورد etcd را در مستندات رسمی بیابید.

  • Eviction

    تخلیه (Eviction) فرآیند خاتمه دادن به یک یا چند Pod روی گره‌ها است.

    [+]
  • Finalizer

    نهایی‌کننده‌ها کلیدهای namespace هستند که به کوبرنتیز می‌گویند تا زمان برآورده شدن شرایط خاص، قبل از حذف کامل منابع مشخص‌شده برای حذف، منتظر بماند. نهایی‌کننده‌ها کنترل کننده ها (controllers) را برای پاکسازی منابعی که شیء حذف‌شده متعلق به آن است، هشدار می‌دهند.

    [+]

    وقتی به کوبرنتیز می‌گویید که شیء‌ای را که finalizers برای آن مشخص شده است، حذف کند، API کوبرنتیز با پر کردن .metadata.deletionTimestamp شیء را برای حذف علامت‌گذاری می‌کند و کد وضعیت 202 (HTTP "Accepted") را برمی‌گرداند. شیء هدف در حالت خاتمه باقی می‌ماند در حالی که control plane یا سایر اجزا، اقدامات تعریف شده توسط finalizers را انجام می‌دهند. پس از اتمام این اقدامات، کنترل‌کننده finalizers مربوطه را از شیء هدف حذف می‌کند. هنگامی که فیلد metadata.finalizers خالی باشد، کوبرنتیز حذف را کامل در نظر می‌گیرد و شیء را حذف می‌کند.

    شما می‌توانید از finalizerها برای کنترل garbage collection منابع استفاده کنید. برای مثال، می‌توانید یک finalizer تعریف کنید تا منابع یا زیرساخت‌های مرتبط را قبل از اینکه کنترل‌کننده منبع هدف را حذف کند، پاک کند.

  • FlexVolume

    FlexVolume یک رابط منسوخ‌شده برای ایجاد افزونه‌های حجم خارج از هسته (out-of-tree) است. رابط ذخیره‌سازی کانتینر یک رابط جدیدتر است که چندین مشکل FlexVolume را برطرف می‌کند.

    [+]

    FlexVolumes کاربران را قادر می‌سازد تا درایورهای خود را بنویسند و پشتیبانی از Volumeهای خود را در کوبرنتیز اضافه کنند. فایل‌های باینری و وابستگی‌های درایور FlexVolume باید روی دستگاه‌های میزبان نصب شوند. این امر نیاز به دسترسی روت دارد. Storage SIG پیشنهاد می‌کند در صورت امکان، یک درایور رابط ذخیره‌سازی کانتینر پیاده‌سازی شود، زیرا محدودیت‌های FlexVolumes را برطرف می‌کند.

  • Gateway API

    خانواده‌ای از انواع API برای مدل‌سازی شبکه سرویس در کوبرنتیز.

    [+]

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

  • Helm Chart

    بسته‌ای از منابع از پیش پیکربندی‌شده‌ی کوبرنتیز که می‌توان آن‌ها را با ابزار Helm مدیریت کرد.

    [+]

    Chartها روشی تکرارپذیر برای ایجاد و اشتراک‌گذاری برنامه‌های کوبرنتیز ارائه می‌دهند. یک Chart واحد می‌تواند برای استقرار چیزی ساده، مانند یک Pod memcached، یا چیزی پیچیده، مانند یک برنامه وب کامل با سرورهای HTTP، پایگاه‌های داده، حافظه‌های پنهان و غیره، استفاده شود.

  • HostAliases

    HostAliases نگاشتی بین آدرس IP و نام میزبان است که به پرونده hosts یک Pod تزریق می‌شود.

    [+]

    HostAliases یک لیست اختیاری از نام‌های میزبان و آدرس‌های IP است که در صورت مشخص شدن، به پرونده hosts Pod تزریق می‌شوند. این فقط برای Podهای غیر hostNetwork معتبر است.

  • Image

    نمونه ذخیره شده از یک کانتینر که مجموعه‌ای از نرم‌افزارهای مورد نیاز برای اجرای یک برنامه را در خود نگه می‌دارد.

    [+]

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

  • Ingress

    یک شیء API که دسترسی خارجی به سرویس‌ها را در یک cluster، معمولاً HTTP، مدیریت می‌کند.

    [+]

    Ingress ممکن است متعادل‌سازی بار، خاتمه SSL و میزبانی مجازی مبتنی بر نام را ارائه دهد.

  • Istio

    یک پلتفرم متن‌باز (مختص کوبرنتیز نیست) که روشی یکنواخت برای یکپارچه‌سازی میکروسرویس‌ها، مدیریت جریان ترافیک، اعمال سیاست‌ها (Policy) و تجمیع داده‌های تله‌متری فراهم می‌کند.

    [+]

    افزودن Istio نیازمند تغییر کد برنامه نیست. Istio یک لایه‌ی زیرساختی میان سرویس و شبکه است که وقتی با استقرارهای سرویس ترکیب شود، معمولا مش سرویس (Service Mesh) نامیده می‌شود. کنترل پلین Istio جزئیات پلتفرم مدیریت کلاستر زیرین، که می‌تواند کوبرنتیز یا Mesosphere و … باشد، را انتزاع می‌کند.

  • kOps (عملیات‌های کوبرنتیز)

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

    [+]

    kOps یک سامانه تهیه‌سازی خودکار (provisioning) است:

    • نصب کاملا خودکار
    • استفاده از DNS برای شناسایی کلاسترها
    • خودترمیمی: همه‌چیز در Auto Scaling Group‌ها اجرا می‌شود
    • پشتیبانی از چندین سیستم‌عامل (Amazon Linux، Debian، Flatcar، RHEL، Rocky و Ubuntu)
    • پشتیبانی از دسترس‌پذیری بالا (High-Availability)
    • امکان تهیه‌سازی مستقیم یا تولید مانیفست‌های Terraform
  • kube-controller-manager

    جزء کنترل پلین که فرایندهای کنترلر را اجرا می‌کند.

    [+]

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

  • kube-proxy

    kube-proxy یک پروکسی شبکه است که روی هر گره (node) در کلاستر شما اجرا می‌شود و بخشی از مفهوم سرویس (Service) در کوبرنتیز را پیاده‌سازی می‌کند.

    [+]

    kube-proxy قوانین شبکه را روی گره‌ها نگه‌داری می‌کند. این قوانین شبکه به نشست‌های شبکه‌ی داخل یا خارج کلاستر اجازه می‌دهند با پادهای شما ارتباط شبکه‌ای برقرار کنند.

    اگر لایه‌ی فیلترکردن بسته در سیستم‌عامل وجود داشته و در دسترس باشد، kube-proxy از آن استفاده می‌کند؛ در غیر این صورت، خود kube-proxy ترافیک را فوروارد می‌کند.

  • kube-scheduler

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

    [+]

    عواملی که در تصمیم‌های scheduling در نظر گرفته می‌شوند شامل این‌ها هستند: نیازهای منابع به‌صورت فردی و جمعی، محدودیت‌های سخت‌افزاری/نرم‌افزاری/سیاستی، مشخصات Affinity (وابستگی) و Anti-Affinity (ضدوابستگی)، محلی‌بودن داده، تداخل بین ورک‌لودها، و ضرب‌الاجل‌ها.

  • Kubeadm

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

    [+]

    می‌توانید از kubeadm برای نصب اجزای کنترل پلین و همچنین اجزای گره worker استفاده کنید.

  • Kubectl
    همچنین شناخته شده به عنوان: kubectl

    ابزار خط فرمانی برای برقراری ارتباط با کنترل پلین کلاستر کوبرنتیز، با استفاده از API کوبرنتیز.

    [+]

    می‌توانید با kubectl آبجکت‌های کوبرنتیز را ایجاد، بازبینی، به‌روزرسانی و حذف کنید.

  • Kubelet

    عاملی که روی هر گره در کلاستر اجرا می‌شود. این عامل اطمینان می‌دهد کانتینرها در یک پاد در حال اجرا باشند.

    [+]

    kubelet مجموعه‌ای از PodSpecها را که از طریق سازوکارهای مختلف به آن ارائه می‌شوند دریافت می‌کند و تضمین می‌کند کانتینرهای توصیف‌شده در آن PodSpecها در حال اجرا و سالم باشند. kubelet کانتینرهایی را که توسط کوبرنتیز ایجاد نشده‌اند مدیریت نمی‌کند.

  • LimitRange

    قیودی را برای محدود کردن مصرف منابع به‌ازای کانتینرها یا پادها در یک نیم‌اسپیس (namespace) فراهم می‌کند.

    [+]

    LimitRange تعداد آبجکت‌هایی را که بر حسب نوع می‌توان ایجاد کرد محدود می‌کند، و همچنین میزان منابع محاسباتی‌ای را که هر کانتینر یا پاد می‌تواند در یک نیم‌اسپیس (namespace) درخواست/مصرف کند تعیین می‌کند.

  • Master

    اصطلاحی قدیمی که به‌عنوان مترادف گره هایی به‌کار می‌رود که کنترل پلین را میزبانی می‌کنند.

    [+]

    این اصطلاح هنوز توسط برخی ابزارهای فراهم سازی (Provisioning)، مانند kubeadm، و سرویس‌های مدیریت‌شده استفاده می‌شود تا با کلید kubernetes.io/role به گرهها لیبل بزنند و محل استقرار پادهای کنترل پلین را کنترل کنند.

  • Minikube

    ابزاری برای اجرای کوبرنتیز به‌صورت محلی.

    [+]

    Minikube یک کلاستر محلی کوبرنتیز را به‌صورت یکپارچه (all-in-one) یا چندگره‌ای داخل یک ماشین مجازی (VM) روی رایانۀ شما اجرا می‌کند. می‌توانید از Minikube برای آزمایش کوبرنتیز در یک محیط آموزشی استفاده کنید.

  • Namespace

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

    [+]

    نیم‌اسپیس‌ها برای سازمان‌دهی آبجکت‌ها در یک کلاستر استفاده می‌شوند و روشی برای تقسیم منابع کلاستر فراهم می‌کنند. نام منابع باید در هر نیم‌اسپیس یکتا باشد، اما لازم نیست در میان همه‌ی نیم‌اسپیس‌ها یکتا باشد. محدوده‌دهی مبتنی بر نیم‌اسپیس فقط برای آبجکت‌های نیم‌اسپیس‌دار (مثلا Deploymentها، Serviceها و …) کاربرد دارد و برای آبجکت‌های سراسری کلاستر (مثلا StorageClass، Nodeها، PersistentVolumeها و …) کاربرد ندارد.

  • PodTemplate
    همچنین شناخته شده به عنوان: قالب پاد

    یک آبجکت API که قالبی برای ایجاد پادها تعریف می‌کند. API مربوط به PodTemplate همچنین در تعریف‌های API برای مدیریت ورک‌لود (Workload)، مانند Deployment یا StatefulSet، جاسازی می‌شود.

    [+]

    قالب‌های پاد به شما امکان می‌دهند متادیتا (فراداده) مشترک (برای نمونه، برچسب‌ها یا قالبی برای نام یک پاد جدید) را تعریف کنید و نیز وضعیت مطلوب (desired state) پاد را مشخص کنید. کنترلرهای مدیریت Workload از قالب‌های پاد (جاسازی‌شده درون یک آبجکت دیگر، مانند Deployment یا StatefulSet) برای تعریف و مدیریت یک یا چند پاد استفاده می‌کنند. وقتی چندین پاد بر اساس یک قالب یکسان وجود داشته باشد، به آن‌ها رپلیکا (replicas) گفته می‌شود. اگرچه می‌توانید به‌صورت مستقیم یک آبجکت PodTemplate بسازید، به‌ندرت به این کار نیاز خواهید داشت.

  • PriorityClass

    PriorityClass کلاسی نام‌گذاری‌شده برای اولویت scheduling (زمان بندی) است که باید به پادهای آن کلاس تخصیص یابد.

    [+]

    PriorityClass یک آبجکت بدون نیم‌اسپیس است که یک نام را به یک مقدار عدد صحیح اولویت نگاشت می‌کند و برای یک پاد به‌کار می‌رود. نام در فیلد metadata.name مشخص می‌شود و مقدار اولویت در فیلد value قرار می‌گیرد. بازه‌ی اولویت‌ها از -2147483648 تا 1000000000 (شامل کران‌ها) است. مقدارهای بزرگ‌تر نشان‌دهنده‌ی اولویت بالاتر هستند.

  • Probe

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

    [+]

    برای آشنایی بیشتر، بخش probeهای کانتینر را بخوانید.

  • RBAC (کنترل دسترسی مبتنی بر نقش - Role-Based Access Control)

    تصمیم‌های مجوزدهی (Authorization) را مدیریت می‌کند و به مدیران اجازه می‌دهد از طریق API کوبرنتیز به‌صورت پویا سیاست‌های دسترسی را پیکربندی کنند.

    [+]

    RBAC از چهار نوع آبجکت کوبرنتیز استفاده می‌کند:

    Role
    قوانین مجوز (permission) را در یک namespace مشخص تعریف می‌کند.
    ClusterRole
    قوانین مجوز (permission) را در سطح سراسر کلاستر تعریف می‌کند.
    RoleBinding
    مجوزهای (permission) تعریف‌شده در یک Role را به مجموعه‌ای از کاربران در یک namespace مشخص اعطا می‌کند.
    ClusterRoleBinding
    مجوزهای (permission) تعریف‌شده در یک Role را به مجموعه‌ای از کاربران در سراسر کلاستر اعطا می‌کند.

    برای اطلاعات بیشتر، به RBAC مراجعه کنید.

  • ReplicaSet

    یک ReplicaSet (هدفش این است که) مجموعه‌ای از پادهای رپلیکا را در هر لحظه در حال اجرا نگه دارد.

    [+]

    آبجکت‌های ورک‌لود مانند Deployment از ReplicaSet استفاده می‌کنند تا بر اساس spec همان ReplicaSet، اطمینان دهند تعداد پادهای پیکربندی‌شده در کلاستر شما در حال اجرا هستند.

  • Resource Quotas

    Provides constraints that limit aggregate resource consumption per Namespace.

    [+]

    Limits the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that project.

  • ResourceClaim

    Describes the resources that a workload needs, such as devices. ResourceClaims are used in dynamic resource allocation (DRA) to provide Pods with access to a specific resource.

    [+]

    ResourceClaims can be created by workload operators or generated by Kubernetes based on a ResourceClaimTemplate.

  • ResourceClaimTemplate

    Defines a template that Kubernetes uses to create ResourceClaims. ResourceClaimTemplates are used in dynamic resource allocation (DRA) to provide per-Pod access to separate, similar resources.

    [+]

    When a ResourceClaimTemplate is referenced in a workload specification, Kubernetes automatically creates ResourceClaim objects based on the template. Each ResourceClaim is bound to a specific Pod. When the Pod terminates, Kubernetes deletes the corresponding ResourceClaim.

  • ResourceSlice

    Represents one or more infrastructure resources, such as devices, that are attached to nodes. Drivers create and manage ResourceSlices in the cluster. ResourceSlices are used for dynamic resource allocation (DRA).

    [+]

    When a ResourceClaim is created, Kubernetes uses ResourceSlices to find nodes that have access to resources that can satisfy the claim. Kubernetes allocates resources to the ResourceClaim and schedules the Pod onto a node that can access the resources.

  • Reviewer

    A person who reviews code for quality and correctness on some part of the project.

    [+]

    Reviewers are knowledgeable about both the codebase and software engineering principles. Reviewer status is scoped to a part of the codebase.

  • Secret

    Stores sensitive information, such as passwords, OAuth tokens, and SSH keys.

    [+]

    Secrets give you more control over how sensitive information is used and reduces the risk of accidental exposure. Secret values are encoded as base64 strings and are stored unencrypted by default, but can be configured to be encrypted at rest.

    A Pod can reference the Secret in a variety of ways, such as in a volume mount or as an environment variable. Secrets are designed for confidential data and ConfigMaps are designed for non-confidential data.

  • Security Context

    The securityContext field defines privilege and access control settings for a Pod or container.

    [+]

    In a securityContext, you can define: the user that processes run as, the group that processes run as, and privilege settings. You can also configure security policies (for example: SELinux, AppArmor or seccomp).

    The PodSpec.securityContext setting applies to all containers in a Pod.

  • Selector

    Allows users to filter a list of resources based on labels.

    [+]

    Selectors are applied when querying lists of resources to filter them by labels.

  • Service

    A method for exposing a network application that is running as one or more Pods in your cluster.

    [+]

    The set of Pods targeted by a Service is (usually) determined by a selector. If more Pods are added or removed, the set of Pods matching the selector will change. The Service makes sure that network traffic can be directed to the current set of Pods for the workload.

    Kubernetes Services either use IP networking (IPv4, IPv6, or both), or reference an external name in the Domain Name System (DNS).

    The Service abstraction enables other mechanisms, such as Ingress and Gateway.

  • Service Catalog

    A former extension API that enabled applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider.

    [+]

    It provided a way to list, provision, and bind with external Managed Services without needing detailed knowledge about how those services would be created or managed.

  • ServiceAccount

    Provides an identity for processes that run in a Pod.

    [+]

    When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, default. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same Namespace.

  • Shuffle-sharding

    A technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.

    [+]

    We are often concerned with insulating different flows of requests from each other, so that a high-intensity flow does not crowd out low-intensity flows. A simple way to put requests into queues is to hash some characteristics of the request, modulo the number of queues, to get the index of the queue to use. The hash function uses as input characteristics of the request that align with flows. For example, in the Internet this is often the 5-tuple of source and destination address, protocol, and source and destination port.

    That simple hash-based scheme has the property that any high-intensity flow will crowd out all the low-intensity flows that hash to the same queue. Providing good insulation for a large number of flows requires a large number of queues, which is problematic. Shuffle-sharding is a more nimble technique that can do a better job of insulating the low-intensity flows from the high-intensity flows. The terminology of shuffle-sharding uses the metaphor of dealing a hand from a deck of cards; each queue is a metaphorical card. The shuffle-sharding technique starts with hashing the flow-identifying characteristics of the request, to produce a hash value with dozens or more of bits. Then the hash value is used as a source of entropy to shuffle the deck and deal a hand of cards (queues). All the dealt queues are examined, and the request is put into one of the examined queues with the shortest length. With a modest hand size, it does not cost much to examine all the dealt cards and a given low-intensity flow has a good chance to dodge the effects of a given high-intensity flow. With a large hand size it is expensive to examine the dealt queues and more difficult for the low-intensity flows to dodge the collective effects of a set of high-intensity flows. Thus, the hand size should be chosen judiciously.

  • Sidecar Container

    One or more containers that are typically started before any app containers run.

    [+]

    Sidecar containers are like regular app containers, but with a different purpose: the sidecar provides a Pod-local service to the main app container. Unlike init containers, sidecar containers continue running after Pod startup.

    Read Sidecar containers for more information.

  • SIG (special interest group)

    Community members who collectively manage an ongoing piece or aspect of the larger Kubernetes open source project.

    [+]

    Members within a SIG have a shared interest in advancing a specific area, such as architecture, API machinery, or documentation. SIGs must follow the SIG governance guidelines, but can have their own contribution policy and channels of communication.

    For more information, see the kubernetes/community repo and the current list of SIGs and Working Groups.

  • Spec

    Defines how each object, like Pods or Services, should be configured and its desired state.

    [+]

    Almost every Kubernetes object includes two nested object fields that govern the object's configuration: the object spec and the object status. For objects that have a spec, you have to set this when you create the object, providing a description of the characteristics you want the resource to have: its desired state.

    It varies for different objects like Pods, StatefulSets, and Services, detailing settings such as containers, volumes, replicas, ports,
    and other specifications unique to each object type. This field encapsulates what state Kubernetes should maintain for the defined
    object.

  • StatefulSet

    Manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods.

    [+]

    Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

    If you want to use storage volumes to provide persistence for your workload, you can use a StatefulSet as part of the solution. Although individual Pods in a StatefulSet are susceptible to failure, the persistent Pod identifiers make it easier to match existing volumes to the new Pods that replace any that have failed.

  • Static Pod

    A pod managed directly by the kubelet daemon on a specific node,

    [+]

    without the API server observing it.

    Static Pods do not support ephemeral containers.

  • Storage Class

    A StorageClass provides a way for administrators to describe different available storage types.

    [+]

    StorageClasses can map to quality-of-service levels, backup policies, or to arbitrary policies determined by cluster administrators. Each StorageClass contains the fields provisioner, parameters, and reclaimPolicy, which are used when a Persistent Volume belonging to the class needs to be dynamically provisioned. Users can request a particular class using the name of a StorageClass object.

  • sysctl

    sysctl is a semi-standardized interface for reading or changing the attributes of the running Unix kernel.

    [+]

    On Unix-like systems, sysctl is both the name of the tool that administrators use to view and modify these settings, and also the system call that the tool uses.

    Container runtimes and network plugins may rely on sysctl values being set a certain way.

  • Taint

    A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of Pods on nodes or node groups.

    [+]

    Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node. A node should only schedule a Pod with the matching tolerations for the configured taints.

  • Toleration

    A core object consisting of three required properties: key, value, and effect. Tolerations enable the scheduling of pods on nodes or node groups that have matching taints.

    [+]

    Tolerations and taints work together to ensure that pods are not scheduled onto inappropriate nodes. One or more tolerations are applied to a pod. A toleration indicates that the pod is allowed (but not required) to be scheduled on nodes or node groups with matching taints.

  • UID

    A Kubernetes systems-generated string to uniquely identify objects.

    [+]

    Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID. It is intended to distinguish between historical occurrences of similar entities.

  • Upstream (disambiguation)

    May refer to: core Kubernetes or the source repo from which a repo was forked.

    [+]
    • In the Kubernetes Community: Conversations often use upstream to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools rely upon. For example, community members may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool.
    • In GitHub or git: The convention is to refer to a source repo as upstream, whereas the forked repo is considered downstream.
  • user namespace

    A kernel feature to emulate root. Used for "rootless containers".

    [+]

    User namespaces are a Linux kernel feature that allows a non-root user to emulate superuser ("root") privileges, for example in order to run containers without being a superuser outside the container.

    User namespace is effective for mitigating damage of potential container break-out attacks.

    In the context of user namespaces, the namespace is a Linux kernel feature, and not a namespace in the Kubernetes sense of the term.

  • Volume

    A directory containing data, accessible to the containers in a Pod.

    [+]

    A Kubernetes volume lives as long as the Pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data in the volume is preserved across container restarts.

    See storage for more information.

  • Volume Plugin

    A Volume Plugin enables integration of storage within a Pod.

    [+]

    A Volume Plugin lets you attach and mount storage volumes for use by a Pod. Volume plugins can be in tree or out of tree. In tree plugins are part of the Kubernetes code repository and follow its release cycle. Out of tree plugins are developed independently.

  • Watch

    A verb that is used to track changes to an object in Kubernetes as a stream. It is used for the efficient detection of changes.

    [+]

    A verb that is used to track changes to an object in Kubernetes as a stream. Watches allow efficient detection of changes; for example, a controller that needs to know whenever a ConfigMap has changed can use a watch rather than polling.

    See Efficient Detection of Changes in API Concepts for more information.

  • WG (working group)

    Facilitates the discussion and/or implementation of a short-lived, narrow, or decoupled project for a committee, SIG, or cross-SIG effort.

    [+]

    Working groups are a way of organizing people to accomplish a discrete task.

    For more information, see the kubernetes/community repo and the current list of SIGs and working groups.

  • Workload

    A workload is an application running on Kubernetes.

    [+]

    Various core objects that represent different types or parts of a workload include the DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet objects.

    For example, a workload that has a web server and a database might run the database in one StatefulSet and the web server in a Deployment.

  • آبجکت (Object)

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

    [+]

    یک آبجکت کوبرنتیز معمولا «سندی از هدف» (Record of Intent) است — به‌محض این‌که آبجکت را ایجاد کنید، کنترل پلین کوبرنتیز به‌طور پیوسته کار می‌کند تا اطمینان یابد موردی که این آبجکت نمایندگی می‌کند واقعا وجود دارد. با ایجاد یک آبجکت، عملا به سامانه‌ی کوبرنتیز می‌گویید می‌خواهید آن بخش از بارکاری (workload) کلاستر شما چگونه باشد؛ این همان «وضعیت مطلوب» (desired state) کلاستر شماست.

  • اپراتور کلاستر

    شخصی که خوشه ها را پیکربندی، کنترل و نظارت می‌کند.

    [+]

    مسئولیت اصلی آنها بالا و در حال اجرا نگه داشتن یک کلاستر است که ممکن است شامل فعالیت‌های نگهداری یا ارتقای دوره‌ای باشد.

  • اپلیکیشن‌ها (Applications)
    لایه‌ای که اپلیکیشن‌های مختلف کانتینر شده در آن اجرا می‌شوند. [+]

    لایه‌ای که اپلیکیشن‌های مختلف کانتینر شده در آن اجرا می‌شوند.

  • اختلال

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

    [+]

    اگر شما، به عنوان اپراتور cluster، یک Pod متعلق به یک برنامه را از بین ببرید، کوبرنتیز آن را اختلال داوطلبانه می‌نامد. اگر یک Pod به دلیل خرابی یک گره(node) یا قطعی برق که بر یک منطقه خرابی گسترده‌تر تأثیر می‌گذارد، آفلاین شود، کوبرنتیز آن را اختلال غیرارادی می‌نامد.

    برای اطلاعات بیشتر به اختلالات مراجعه کنید.

  • اختلال پاد (Pod Disruption)

    اختلال پاد (Pod Disruption) فرایندی است که طی آن پادها روی گره‌ها به‌صورت داوطلبانه یا غیرداوطلبانه خاتمه می‌یابند.

    [+]

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

  • اخراج آغاز شده با API.

    حذف آغاز شده توسط API فرآیندی است که طی آن شما از Eviction API برای ایجاد یک شیء Eviction که باعث خاتمه پاد به تدریج می‌شود، استفاده می‌کنید.

    [+]

    شما می‌توانید با فراخوانی مستقیم Evicion API با استفاده از یک کلاینت از kube-apiserver، مانند دستور kubectl drain، درخواست تخلیه را بدهید. وقتی یک شیء Eviction ایجاد می‌شود، سرور API، Pod را خاتمه می‌دهد.

    حذف‌های آغاز شده توسط API به PodDisruptionBudgets و terminationGracePeriodSeconds پیکربندی شده شما احترام می‌گذارند.

    حذف آغاز شده توسط API با حذف فشار گره یکسان نیست.

  • ارائه دهنده ابر (Cloud Provider)
    همچنین شناخته شده به عنوان: ارائه‌دهنده‌ی خدمات ابری (Cloud Service Provider)

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

    [+]

    ارائه دهندگان ابر، که گاهی اوقات ارائه دهندگان خدمات ابری (Cloud Service Providers یا CSPها) نامیده می‌شوند، پلتفرم‌ها یا خدمات رایانش ابری را ارائه می‌دهند.

    بسیاری از ارائه‌دهندگان خدمات ابری، زیرساخت مدیریت‌شده (که زیرساخت به عنوان سرویس یا IaaS نیز نامیده می‌شود) ارائه می‌دهند. در زیرساخت مدیریت‌شده، ارائه‌دهنده‌ی خدمات ابری مسئول سرورها، فضای ذخیره‌سازی و شبکه است، در حالی که شما لایه‌های بالاتر از آن، مانند اجرای یک کلاستر کوبرنتیز، را مدیریت می‌کنید.

    همچنین می‌توانید کوبرنتیز را به عنوان یک سرویس مدیریت‌شده بیابید؛ که گاهی اوقات به آن «پلتفرم به عنوان سرویس» یا PaaS گفته می‌شود. با کوبرنتیز مدیریت‌شده، ارائه‌دهنده ابر شما مسئول control plane کوبرنتیز و همچنین nodes و زیرساختی است که به آن متکی هستند: شبکه، ذخیره‌سازی و احتمالاً عناصر دیگری مانند لود بالانسرها.

  • افزونه‌ها

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

    [+]

    بسیاری از مدیران cluster از یک نمونه میزبانی شده یا توزیع شده از کوبرنتیز استفاده می‌کنند. این خوشه ها دارای افزونه‌های از پیش نصب شده هستند. در نتیجه، اکثر کاربران کوبرنتیز نیازی به نصب افزونه‌ها نخواهند داشت و حتی تعداد کمتری از کاربران نیاز به ایجاد افزونه‌های جدید خواهند داشت.

  • افزونه‌ها (Add-ons)

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

    [+]

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

  • الگوی اپراتور (Operator)

    الگوی اپراتور یک طراحی سامانه است که یک کنترل کننده را به یک یا چند منبع سفارشی (custom resource) پیوند می‌دهد.

    [+]

    می‌توانید کوبرنتیز را با افزودن کنترلرها به کلاستر خود گسترش دهید؛ فراتر از کنترلرهای توکار (built-in) که به‌عنوان بخشی از خود کوبرنتیز ارائه می‌شوند.

    اگر یک برنامه‌ی در حال اجرا نقش یک کنترلر را ایفا کند و دسترسی API داشته باشد تا وظایفی را روی یک منبع سفارشی (custom resource) که در کنترل پلین تعریف شده است انجام دهد، این نمونه‌ای از الگوی اپراتور است.

  • اولویت پاد (Pod Priority)

    اولویت پاد اهمیت یک پاد (Pod) را نسبت به سایر پادها نشان می‌دهد.

    [+]

    اولویت پاد امکان تعیین اولویت scheduling یک پاد را بالاتر یا پایین‌تر از سایر پادها فراهم می‌کند - قابلیتی مهم برای ورک‌لودهای کلاسترهای پروداکشن.

  • اویکشن(eviction) به‌دلیل فشار گره
    همچنین شناخته شده به عنوان: kubelet eviction

    «اویکشن به‌دلیل فشار گره» فرایندی است که در آن kubelet به‌صورت پیش‌دستانه پادها را برای بازپس‌گیری منابع روی گره‌ها خاتمه می‌دهد.

    [+]

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

    «اویکشن به‌دلیل فشار گره» با اویکشن آغازشده از طریق API یکسان نیست.

  • بنیاد رایانش بومی ابری (Cloud Native Computing Foundation - CNCF)

    بنیاد رایانش بومی ابری (CNCF) اکوسیستم‌های پایداری ایجاد می‌کند و جامعه‌ای را پیرامون [پروژه‌ها] (https://www.cncf.io/projects/) پرورش می‌دهد که کانتینرها را به عنوان بخشی از معماری میکروسرویس‌ها ارکستراسیون می‌کنند.

    کوبرنتیز یک پروژه CNCF است.

    [+]

    CNCF زیربنیادی از [بنیاد لینوکس] (https://www.linuxfoundation.org/) است. ماموریت آن فراگیر کردن رایانش بومی ابری است.

  • بودجه‌ی اختلال پاد (Pod Disruption Budget)
    همچنین شناخته شده به عنوان: PDB, PodDisruptionBudget

    بودجه‌ی اختلال پاد (Pod Disruption Budget) به مالک یک برنامه اجازه می‌دهد برای یک برنامه‌ی تکثیرشده آبجکتی ایجاد کند که تضمین کند تعداد یا درصد معینی از پادها با لیبل مشخص، در هیچ زمانی به‌صورت داوطلبانه اخراج (evicted) نشوند.

    [+]

    اختلالات غیرداوطلبانه توسط PDB قابل پیشگیری نیستند؛ بااین‌حال، در محاسبه‌ی بودجه منظور می‌شوند.

  • پاد (Pod)
    همچنین شناخته شده به عنوان: Pod

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

    [+]

    یک پاد معمولا برای اجرای یک کانتینر اصلی پیکربندی می‌شود. همچنین می‌تواند کانتینرهای سایدکار (sidecar) اختیاری را اجرا کند که قابلیت‌های تکمیلی مانند لاگ‌گردن را اضافه می‌کنند. پادها معمولا توسط یک Deployment مدیریت می‌شوند.

  • پاد آینه‌ای (Mirror Pod)

    یک پاد که kubelet برای نمایش یک پاد استاتیک از آن استفاده می‌کند.

    [+]

    وقتی kubelet در پیکربندی خود یک پاد استاتیک را پیدا می‌کند، به‌صورت خودکار تلاش می‌کند برای آن روی سرور API کوبرنتیز یک آبجکت پاد ایجاد کند. این یعنی پاد روی سرور API قابل‌مشاهده است، اما از آنجا قابل‌کنترل نیست.

    (برای نمونه، حذف کردن یک پاد آینه‌ای باعث نمی‌شود دیمون kubelet اجرای آن را متوقف کند).

  • پروکسی (Proxy)

    در رایانش، «پروکسی» سروری است که برای یک سرویس دوردست به‌عنوان میانجی عمل می‌کند.

    [+]

    کلاینت با پروکسی تعامل می‌کند؛ پروکسی داده‌های کلاینت را به سرور واقعی ارسال می‌کند؛ سرور واقعی به پروکسی پاسخ می‌دهد؛ و در نهایت، پروکسی پاسخ سرور واقعی را به کلاینت بازمی‌گرداند.

    kube-proxy یک پروکسی شبکه است که روی هر گره کلاستر شما اجرا می‌شود و بخشی از مفهوم Service در کوبرنتیز را پیاده‌سازی می‌کند.

    می‌توانید kube-proxy را به‌صورت یک سرویس پروکسی ساده در فضای کاربر اجرا کنید. اگر سیستم‌عامل شما از آن پشتیبانی کند، می‌توانید kube-proxy را در حالت ترکیبی اجرا کنید که با استفاده از منابع سیستمی کمتر، همان اثر کلی را به‌دست می‌آورد.

  • پروکسی نسخه‌های ترکیبی (MVP)
    همچنین شناخته شده به عنوان: MVP

    قابیتی که به kube-apiserver اجازه می‌دهد درخواست یک منبع را به یک سرور API همتای دیگر پروکسی کند.

    [+]

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

    MVP به‌طور پیش‌فرض غیرفعال است و می‌توان آن را با فعال‌کردن feature gate با نام UnknownVersionInteroperabilityProxy هنگام راه‌اندازی سرور API فعال کرد.

  • پیش‌دستی (Preemption)

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

    [+]

    اگر یک پاد نتواند schedule شود، scheduler تلاش می‌کند پادهای با اولویت پایین‌تر را پیش‌دستی (preempt) کند (از دسترس خارج کند) تا scheduling (زمان بندی) پاد در انتظار (pending) ممکن شود.

  • تأمین پویای حجم

    به کاربران اجازه می‌دهد تا ایجاد خودکار فضای ذخیره‌سازی Volumes را درخواست کنند.

    [+]

    تأمین پویا، نیاز مدیران cluster به پیش‌تأمین فضای ذخیره‌سازی را از بین می‌برد. در عوض، به طور خودکار فضای ذخیره‌سازی را بر اساس درخواست کاربر تأمین می‌کند. تأمین پویای فضای ذخیره‌سازی بر اساس یک شیء API به نام StorageClass است که به افزونه‌ی حجم اشاره دارد که Volume و مجموعه‌ای از پارامترها را برای ارسال به افزونه‌ی فضای ذخیره‌سازی فراهم می‌کند.

  • تأییدکننده (Approver)

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

    [+]

    در حالی که بازبینی کد بر کیفیت و صحت کد متمرکز است، تأیید بر پذیرش جامع یک مشارکت متمرکز است. پذیرش جامع شامل سازگاری رو‌به‌عقب/رو‌به‌جلو، رعایت قراردادهای API و فلگ‌ها، مسائل جزئی عملکرد و صحت، تعامل با سایر بخش‌های سیستم و موارد دیگر می‌شود. جایگاه تأییدکننده به بخشی از پایگاه کد محدود می‌شود. قبلاً به تأییدکنندگان، نگه‌دارنده (Maintainer) گفته می‌شد.

  • تخصیص منابع پویا
    همچنین شناخته شده به عنوان: DRA, Dynamic Resource Allocation

    یک ویژگی کوبرنتیز که به شما امکان می‌دهد منابع را بین Podها درخواست و به اشتراک بگذارید. این منابع اغلب مانند شتاب‌دهنده‌های سخت‌افزاری به Podها متصل می‌شوند.

    [+]

    با DRA، درایورهای دستگاه و مدیران cluster، کلاس‌های دستگاهی را که برای درخواست در Workload در دسترس هستند، تعریف می‌کنند. کوبرنتیز دستگاه‌های منطبق را به درخواست‌های خاص اختصاص می‌دهد و پادهای مربوطه را روی گره‌(node)هایی قرار می‌دهد که می‌توانند به دستگاه‌های اختصاص داده شده دسترسی داشته باشند.

  • تخلیه

    فرآیند حذف ایمن Podها از یک گره برای آماده‌سازی آن برای نگهداری یا حذف از cluster.

    [+]

    دستور kubectl drain برای علامت‌گذاری یک گره‌ها به عنوان خارج از سرویس استفاده می‌شود. هنگام اجرا، تمام Podها را از گره خارج می‌کند. اگر درخواست خروج موقتاً رد شود، kubectl drain تا زمانی که تمام Podها خاتمه یابند یا به یک مهلت زمانی قابل تنظیم برسند، دوباره تلاش می‌کند.

  • توسعه دهنده‌ی برنامه (Application Developer)

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

    [+]

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

  • توسعه‌دهنده (ابهام‌زدایی)

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

    [+]

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

  • توسعه‌دهنده‌ی پلتفرم

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

    [+]

    برای نمونه، یک توسعه‌دهنده‌ی پلتفرم می‌تواند از منابع سفارشی (Custom Resources) استفاده کند یا با گسترش API کوبرنتیز با لایه‌ی تجمیع قابلیت‌هایی را به نمونه‌ی کوبرنتیز خود بیفزاید که به‌طور ویژه برای برنامه‌ی او طراحی شده‌اند. برخی از توسعه‌دهندگان پلتفرم همچنین از مشارکت‌کنندگان پروژه‌اند و افزونه‌هایی را توسعه می‌دهند که به جامعه‌ی کوبرنتیز ارائه می‌شوند. دیگران افزونه‌های تجاری متن‌بسته یا مخصوص یک سایت/سازمان را توسعه می‌دهند.

  • توکن وب JSON (JWT)

    روشی برای نمایش ادعاها (claims) که بین دو طرف منتقل می‌شوند.

    [+]

    JWTها می‌توانند به‌صورت دیجیتال امضا و رمزنگاری شوند. کوبرنتیز از JWT به‌عنوان توکن احراز هویت استفاده می‌کند تا هویت موجودیت‌هایی را که می‌خواهند در یک کلاستر اقداماتی انجام دهند، تأیید کند.

  • جاب (Job)

    یک کار محدود یا دسته‌ای که تا زمان تکمیل اجرا می‌شود.

    [+]

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

  • جمع‌آوری زباله

    جمع‌آوری زباله(Garbage Collection) یک اصطلاح کلی برای سازوکارهای مختلفی است که کوبرنتیز برای پاکسازی منابع Cluster استفاده می‌کند.

    [+]

    کوبرنتیز از جمع‌آوری زباله برای پاکسازی منابعی مانند کانتینرها و تصاویر استفاده نشده، Podهای ناموفق، اشیاء متعلق به منبع مورد نظر، jobs تکمیل شده و منابعی که منقضی شده‌اند یا از کار افتاده‌اند، استفاده می‌کند.

  • چرخه‌ی عمر پاد

    توالی وضعیت‌هایی که یک پاد در طول عمر خود از آن‌ها عبور می‌کند.

    [+]

    چرخه‌ی عمر پاد با وضعیت‌ها یا فازهای یک پاد تعریف می‌شود. پنج فاز ممکن برای پاد وجود دارد: Pending، Running، Succeeded، Failed و Unknown. توصیف سطح‌بالای وضعیت پاد در فیلد phase از PodStatus خلاصه می‌شود.

  • حاشیه‌نویسی

    یک جفت کلید-مقدار که برای الصاق فراداده‌های دلخواه و غیرشناسایی به اشیاء استفاده می‌شود.

    [+]

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

  • حجم پایدار (Persistent Volume)
    همچنین شناخته شده به عنوان: PersistentVolume

    یک آبجکت API که نمایانگر بخشی از فضای ذخیره‌سازی در کلاستر است. این منبع به‌صورت عمومی و پلاگین‌پذیر در دسترس است و فراتر از چرخه‌ی عمر هر Pod منفرد پایدار می‌ماند.

    [+]

    PersistentVolumeها (PV) یک API فراهم می‌کنند که جزئیات نحوه‌ی تامین ذخیره‌سازی را از نحوه‌ی مصرف آن انتزاع می‌کند.
    PVها در سناریوهایی که ذخیره‌سازی از پیش قابل ایجاد است (تهیه‌ی ایستا - static provisioning) به‌صورت مستقیم استفاده می‌شوند.
    برای سناریوهایی که به ذخیره‌سازی بر حسب تقاضا نیاز دارند (تهیه‌ی پویا - dynamic provisioning)، به‌جای آن از PersistentVolumeClaimها (PVC) استفاده می‌شود. ‍‍

  • درخواست حجم پایدار (Persistent Volume Claim)
    همچنین شناخته شده به عنوان: PersistentVolumeClaim

    مطالبه‌ی منابع ذخیره‌سازی تعریف‌شده در یک حجم پایدار (PersistentVolume) تا بتوان آن را به‌صورت یک حجم در یک کانتینر مانت کرد.

    [+]

    میزان فضای ذخیره‌سازی، شیوه‌ی دسترسی به آن (فقط‌خواندنی، خواندن‌و‌نوشتن و/یا انحصاری) و شیوه‌ی بازپس‌گیری آن (نگه‌داری، بازیافت یا حذف) را مشخص می‌کند. جزئیات خود فضای ذخیره‌سازی در آبجکت PersistentVolume توصیف شده است.

  • دروازه ویژگی

    دروازه‌های ویژگی (Feature Gates) مجموعه‌ای از کلیدها (مقادیر رشته‌ای غیرشفاف) هستند که می‌توانید از آن‌ها برای کنترل فعال بودن ویژگی‌های کوبرنتیز در Cluster خود استفاده کنید.

    [+]

    شما می‌توانید این ویژگی‌ها را با استفاده از پرچم خط فرمان --feature-gates در هر جزء کوبرنتیز فعال یا غیرفعال کنید. هر مولفه کوبرنتیز به شما امکان می‌دهد مجموعه‌ای از دروازه‌های ویژگی مرتبط با آن مولفه را فعال یا غیرفعال کنید. مستندات کوبرنتیز فهرست کامل دروازه‌های ویژگی فعلی و آنچه را که کنترل می‌کنند، ارائه می‌دهد.

  • دستگاه

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

    [+]

    دستگاه‌ها می‌توانند محصولات تجاری مانند GPUها یا سخت‌افزارهای سفارشی مانند [بردها ASIC] (https://en.wikipedia.org/wiki/Application-specific_integrated_circuit) باشند. دستگاه‌های متصل معمولاً به درایورهایی نیاز دارند که به Podهای کوبرنتیز اجازه دسترسی به دستگاه‌ها را می‌دهند.

  • رابط ذخیره‌سازی کانتینر (CSI)

    رابط ذخیره‌سازی کانتینر (CSI) یک رابط استاندارد برای نمایش سیستم‌های ذخیره‌سازی به کانتینرها تعریف می‌کند.

    [+]

    CSI به ارائه‌دهندگان (سازندگان سرویس‌های ذخیره‌سازی) اجازه می‌دهد افزونه‌های ذخیره‌سازی سفارشی برای کوبرنتیز ایجاد کنند، بدون اینکه آنها را به مخزن کوبرنتیز اضافه کنند (افزونه‌های خارجی). برای استفاده از درایور CSI از یک ارائه‌دهنده ذخیره‌سازی، ابتدا باید آن را در cluster خود مستقر کنید. سپس می‌توانید یک Storage Class ایجاد کنید که از آن درایور CSI استفاده کند.

  • رابط شبکه‌ی کانتینر (Container network interface - CNI)

    افزونه‌های رابط شبکه کانتینر (CNI) نوعی افزونه شبکه هستند که به مشخصات appc/CNI پایبند هستند.

    [+]
  • رابط مجری کانتینر (CRI)
    همچنین شناخته شده به عنوان: CRI

    پروتکل اصلی برای ارتباط بین kubelet و مجری کانتینر.

    [+]

    رابط مجری کانتینر کوبرنتیز (CRI) پروتکل اصلی gRPC(https://grpc.io) را برای ارتباط بین اجزای گره(node) (/docs/concepts/architecture/#node-components) تعریف می‌کند. kubelet و container runtime.

  • رپلیکا (Replica)

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

    [+]

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

    با تعریف تعداد رپلیکا در یک Deployment یا ReplicaSet، کوبرنتیز تضمین می‌کند که تعداد مشخص‌شده‌ی نمونه‌ها در حال اجرا باشند و در صورت نیاز این تعداد را به‌طور خودکار تنظیم می‌کند.

    مدیریت رپلیکا امکان تعادل‌بار (load balancing) کارامد، به‌روزرسانی‌های تدریجی (rolling updates) و توانایی‌های خودترمیمی (self healing) را در یک کلاستر کوبرنتیز فراهم می‌سازد.

  • رویداد (Event)

    رویداد (Event) یک شیء در کوبرنتیز است که تغییرات وضعیت یا رخدادهای قابل‌توجه در سیستم را توصیف می‌کند.

    [+]

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

    رویدادها باید به‌عنوان داده‌هایی اطلاع‌رسان، غیرتضمینی (best-effort) و تکمیلی در نظر گرفته شوند.

    در کوبرنتیز، auditing نوع متفاوتی از ثبت رویداد (گروه API audit.k8s.io) را تولید می‌کند.

  • زبان عبارات مشترک (CEL)
    همچنین شناخته شده به عنوان: CEL

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

    [+]

    در کوبرنتیز، می‌توان از CEL برای اجرای کوئری‌ها و انجام فیلترینگ دقیق استفاده کرد. برای مثال، می‌توانید از عبارات CEL با کنترلر پذیرش پویا (Dynamic Admission Control) برای فیلتر کردن فیلدهای خاص در درخواست‌ها و با تخصیص پویای منابع (DRA) برای انتخاب منابع بر اساس ویژگی‌های خاص استفاده کنید.

  • زیرساخت تغییرناپذیر

    زیرساخت تغییرناپذیر به زیرساخت‌های رایانه‌ای (ماشین‌های مجازی، کانتینرها، لوازم شبکه) اشاره دارد که پس از استقرار، قابل تغییر نیستند.

    [+]

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

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

  • زیرساخت کلاستر
    لایه زیرساخت، VM‌ها، شبکه، گروه‌های امنیتی و موارد دیگر را فراهم و نگهداری می‌کند. [+]

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

  • سرور API
    همچنین شناخته شده به عنوان: kube-apiserver

    سرور API جزئی از کنترل پلین کوبرنتیز است که API کوبرنتیز را در اختیار قرار می‌دهد. سرور API رابط جلویی کنترل پلین کوبرنتیز است.

    [+]

    پیاده‌سازی اصلی سرور API کوبرنتیز، kube-apiserver است. kube-apiserver برای مقیاس‌پذیری افقی طراحی شده است؛ یعنی با استقرار نمونه‌های بیش‌تر مقیاس می‌گیرد. می‌توانید چندین نمونه از kube-apiserver را اجرا کرده و ترافیک را میان آن‌ها متوازن کنید.

  • سرویس مدیریت‌شده (Managed Service)

    یک محصول نرم‌افزاری که توسط یک ارائه‌دهنده‌ی شخص ثالث نگه‌داری می‌شود.

    [+]

    برخی نمونه‌های سرویس مدیریت‌شده عبارت‌اند از AWS EC2، Azure SQL Database و GCP Pub/Sub؛ اما می‌توانند هر ارائه نرم‌افزاری باشند که توسط یک برنامه کاربردی قابل استفاده باشد.

  • سیاست امنیتی پاد (Pod Security Policy)
    همچنین شناخته شده به عنوان: PodSecurityPolicy

    مجوزدهی دقیق برای ایجاد و به‌روزرسانی پاد را فعال می‌کند.

    [+]

    یک منبع در سطح کلاستر که جنبه‌های حساس امنیتی مشخصات پاد را کنترل می‌کند. آبجکت‌های PodSecurityPolicy مجموعه‌ای از شرایطی را تعریف می‌کنند که یک پاد باید با آن‌ها اجرا شود تا در سیستم پذیرفته شود؛ همچنین مقادیر پیش‌فرض برای فیلدهای مرتبط را تعیین می‌کنند. کنترلر «سیاست امنیتی پاد» به‌صورت یک پذیرش Admission Controller اختیاری پیاده‌سازی می‌شود.

    PodSecurityPolicy از کوبرنتیز v1.21 منسوخ شد و در v1.25 حذف گردید. به‌جای آن از پذیرش امنیتی پاد یا یک افزونه‌ی پذیرش شخص ثالث استفاده کنید.

  • عضو (Member)

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

    [+]

    می‌توان issue‌ ها و PR‌ ها را به اعضا اختصاص داد و اعضا از طریق تیم‌های GitHub در گروه‌های علاقه‌مندی ویژه (SIGs) مشارکت کنند. برای PRهای اعضا، تست‌های پیش‌ارسال (pre-submit) به‌صورت خودکار اجرا می‌شود. انتظار می‌رود یک عضو به‌عنوان مشارکت‌کننده‌ای فعال در جامعه باقی بماند.

  • عملیات کلاستر

    کار مربوط به مدیریت یک کلاستر کوبرنتیز: مدیریت عملیات روزانه و هماهنگی ارتقاءها.

    [+]

    نمونه‌هایی از کارهای مربوط به عملیات خوشه عبارتند از: استقرار گره‌های جدید برای مقیاس‌بندی خوشه؛ انجام ارتقای نرم‌افزار؛ ​​پیاده‌سازی کنترل‌های امنیتی؛ اضافه یا حذف فضای ذخیره‌سازی؛ پیکربندی شبکه کلاستر؛ مدیریت مشاهده‌پذیری در سطح کلاستر؛ و پاسخ به رویدادها.

  • کانتینر

    یک image اجرایی سبک و قابل حمل که شامل نرم‌افزار و تمام وابستگی‌های آن است.

    [+]

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

  • کانتینر Init ‏(Init Container)

    یک یا چند کانتینر اولیه‌سازی که باید پیش از اجرای هر کانتینر برنامه تا پایان اجرا شوند.

    [+]

    کانتینرهای اولیه‌سازی (init) مانند کانتینرهای معمول برنامه هستند، با یک تفاوت: کانتینرهای init باید پیش از آن‌که هر کانتینر برنامه‌ای بتواند شروع به کار کند، تا پایان اجرا شوند. کانتینرهای init به‌صورت متوالی اجرا می‌شوند؛ یعنی هر کانتینر init باید پیش از آغاز کانتینر init بعدی، اجرای خود را کامل کند.

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

    برای اطلاعات بیشتر، بخش کانتینرهای init را بخوانید.

  • کانتینر برنامه

    کانتینرهای برنامه (یا کانتینرهای اپ) کانتینرهایی در یک پاد هستند که پس از تکمیل هر کانتینرهای init آغاز می‌شوند.

    [+]

    یک کانتینر init به شما امکان می‌دهد جزئیات مقداردهی اولیه‌ای را که برای کل workload مهم هستند و نیازی به ادامه اجرا پس از شروع کانتینر برنامه ندارند، جدا کنید. اگر یک پاد هیچ کانتینر init نداشته باشد، تمام کانتینرهای داخل آن پاد، کانتینرهای برنامه (app containers) محسوب می‌شوند.

  • کانتینر زودگذر

    یک نوع کانتینر که می‌توانید به طور موقت درون یک Pod اجرا کنید.

    [+]

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

    کانتینرهای موقت توسط Pod استاتیک پشتیبانی نمی‌شوند.

  • کلاس QoS

    کلاس QoS (Quality of Service Class - کلاس کیفیت سرویس) روشی در اختیار کوبرنتیز می‌گذارد تا پادهای موجود در کلاستر را به چند کلاس دسته‌بندی کند و براساس آن درباره‌ی scheduling (زمان بندی) و اخراج (eviction) تصمیم بگیرد.

    [+]

    کلاس QoS یک پاد در زمان ایجاد آن و بر اساس تنظیمات درخواست‌ها (requests) و محدودیت‌ها (limits) برای منابع محاسباتی تعیین می‌شود. از کلاس‌های QoS برای تصمیم‌گیری درباره‌ی scheduling (زمان بندی) و اخراج پادها استفاده می‌شود. کوبرنتیز می‌تواند یکی از کلاس‌های QoS زیر را به یک پاد اختصاص دهد: Guaranteed، Burstable یا BestEffort.

  • کلاستر (Cluster)

    مجموعه‌ای از ماشین‌های worker، به نام گره‌ها، که برنامه‌های کانتینری‌شده را اجرا می‌کنند. هر کلاستر حداقل یک گره worker دارد.

    [+]

    گره(های) worker میزبان پادهایی هستند که اجزای بار کاری اپلیکیشن هستند. control plane گره‌های worker و پادها را در کلاستر مدیریت می‌کند. در محیط‌های عملیاتی، control plane معمولا روی چندین کامپیوتر اجرا می‌شود و یک کلاستر معمولا چندین گره را اجرا می‌کند و تحمل‌پذیری خطا و دسترسی بالا را فراهم می‌کند.

  • کمیت (Quantity)

    یک شیوه‌ی نمایش بر پایه‌ی عدد صحیح برای مقادیر کوچک یا بزرگ با استفاده از SI (سامانه‌ی بین‌المللی یکاها).

    [+]

    «کمیت‌ها» نمایش فشرده‌ای از اعداد کوچک یا بزرگ هستند که از نگارش عدد صحیح به‌همراه پسوندهای SI استفاده می‌کنند. اعداد اعشاری با واحد میلی نمایش داده می‌شوند، و اعداد بزرگ را می‌توان با واحدهای کیلو، مگا یا گیگا نمایش داد.

    برای نمونه، عدد 1.5 به‌صورت 1500m نمایش داده می‌شود، در حالی که عدد 1000 می‌تواند به‌صورت 1k و 1000000 به‌صورت 1M نمایش داده شود. همچنین می‌توانید از پسوندهای نگارش دودویی استفاده کنید؛ برای مثال عدد 2048 را می‌توان به‌شکل 2Ki نوشت.

    واحدهای ده‌دهی پذیرفته‌شده (توان‌های ۱۰) عبارت‌اند از: m (میلی)، k (کیلو ــ عمدا حروف کوچک)، M (مگا)، G (گیگا)، T (ترا)، P (پتا)، E (اگزا).

    واحدهای دودویی پذیرفته‌شده (توان‌های ۲) عبارت‌اند از: Ki (کیبی)، Mi (مبی)، Gi (گیبی)، Ti (تبی)، Pi (پبی)، Ei (اگزبی).

  • کنترل کننده

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

    [+]

    کنترل‌کننده‌ها وضعیت مشترک کلاستر شما را از طریق apiserver (بخشی از Control Plane) زیر نظر دارند.

    برخی از کنترل‌کننده‌ها نیز درون control plane اجرا می‌شوند و حلقه‌های کنترلی را فراهم می‌کنند که هسته عملیات کوبرنتیز هستند. به عنوان مثال: کنترل‌کننده استقرار، کنترل‌کننده daemonset، کنترل‌کننده namespace و کنترل‌کننده حجم پایدار (و موارد دیگر) همگی درون kube-controller-manager اجرا می‌شوند.

  • کنترلر پذیرش (Admission Controller)

    قطعه کدی که درخواست‌های ارسالی به سرور API کوبرنتیز را قبل از ماندگاری شیء، رهگیری می‌کند.

    [+]

    کنترلر‌های پذیرش برای سرور API کوبرنتیز قابل پیکربندی هستند و می‌توانند "اعتبارسنجی"، "تغییر" یا هر دو باشند. هر کنترلر پذیرش می‌تواند درخواست را رد کند. کنترلر‌های تغییر ممکن است اشیاء پذیرفته‌شده را تغییر دهند؛ کنترلر‌های اعتبارسنجی ممکن است این کار را نکنند.

  • کنترلر تکثیر (ReplicationController)

    یک منبع ورکلود که یک برنامه تکثیر‌شده را مدیریت می‌کند و اطمینان می‌دهد تعداد مشخصی از نمونه‌های پاد در حال اجرا هستند.

    [+]

    کنترل پلین تضمین می‌کند که تعداد تعیین‌شده‌ای از پادها در حال اجرا باشند؛ حتی اگر بعضی پادها از کار بیفتند، اگر شما پادهایی را به‌صورت دستی حذف کنید، یا اگر به اشتباه تعداد زیادی پاد راه‌اندازی شده باشد.

  • گروه API

    مجموعه‌ای از مسیرهای مرتبط در API کوبرنتیز.

    [+]

    شما می‌توانید با تغییر پیکربندی سرور API خود، هر گروه API را فعال یا غیرفعال کنید. همچنین می‌توانید مسیرها را به منابع خاص غیرفعال یا فعال کنید. گروه API، گسترش API کوبرنتیز را آسان‌تر می‌کند. گروه API در یک مسیر REST و در فیلد apiVersion یک شیء سریالی شده مشخص می‌شود.

    • برای اطلاعات بیشتر گروه API را مطالعه کنید.
  • گره (Node)

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

    [+]

    یک گره worker می‌تواند بسته‌ به کلاستر، یک ماشین مجازی (VM) یا ماشین فیزیکی باشد. روی آن دیمون‌ها یا سرویس‌های محلی لازم برای اجرای پادها اجرا می‌شوند و این گره توسط کنترل پلین مدیریت می‌شود. دیمون‌های روی گره شامل kubelet, kube-proxy و یک کانتینر ران‌تایم (container runtime) که CRI را پیاده‌سازی می‌کند (مانند Docker) است.

    در نسخه‌های اولیه‌ی کوبرنتیز، به گره‌ها «Minions» گفته می‌شد.

  • گواهی (Certificate)

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

    [+]

    گواهی‌ها به اپلیکیشن‌های درون یک کلاستر کوبرنتیز امکان دسترسی ایمن به API Kubernetes را می‌دهند. گواهی‌ها تأیید می‌کنند که کلاینت‌ها مجاز به دسترسی به API هستند.

  • لاگ‌کردن (Logging)

    لاگ‌ها فهرست رویدادهایی هستند که توسط کلاستر یا اپلیکیشن ثبت می‌شوند.

    [+]

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

  • لایه تجمیع

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

    [+]

    وقتی API سرور کوبرنتیز را برای پشتیبانی از API های اضافی پیکربندی کردید، می‌توانید اشیاء APIService را برای "claim" یک مسیر نشانی وب در API کوبرنتیز اضافه کنید.

  • لیبل (Label)

    آبجکت‌ها را با ویژگی‌های شناسایی‌کننده‌ای که برای کاربران معنادار و مرتبط هستند، تگ می‌کند.

    [+]

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

  • مانیفست (Manifest)

    تعریف یک آبجکت API کوبرنتیز در قالب JSON یا YAML.

    [+]

    یک مانیفست، وضعیت مطلوب (desired state) یک آبجکت را مشخص می‌کند؛ که کوبرنتیز پس از اعمال این مانیفست، آن وضعیت را حفظ می‌کند. در قالب YAML، هر فایل می‌تواند چندین مانیفست را در خود جای دهد.

  • متغیرهای محیطی کانتینر

    متغیرهای محیطی کانتینر، جفت‌های نام=مقدار هستند که اطلاعات مفیدی را در کانتینرهای در حال اجرا در یک pod ارائه می‌دهند.

    [+]

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

  • مجری کانتینر

    یک جزء اساسی که کوبرنتیز را قادر می‌سازد تا کانتینرها را به طور مؤثر اجرا کند. این بخش مسئول مدیریت اجرا و چرخه حیات کانتینرها در محیط کوبرنتیز است.

    [+]

    کوبرنتیز از مجری های کانتینر مانند containerd، CRI-O، و هرگونه پیاده‌سازی دیگر از Kubernetes CRI (رابط مجری کانتینر) پشتیبانی می‌کند.

  • مدت زمان

    یک مقدار رشته‌ای که نشان‌دهنده‌ی مدت زمان است.

    [+]

    قالب مدت زمان (کوبرنتیز) بر اساس نوع ‎time.Duration‎ از زبان برنامه‌نویسی Go است.

    در APIهای کوبرنتیز که از مدت زمان استفاده می‌کنند، مقدار به صورت مجموعه‌ای از اعداد صحیح غیر منفی همراه با پسوند واحد زمان بیان می‌شود. می‌توانید بیش از یک مقدار زمانی داشته باشید و مدت زمان، مجموع آن مقادیر زمانی است. واحدهای زمانی معتبر عبارتند از "ns"، "µs" (یا "us")، "ms"، "s"، "m" و "h".

    به عنوان مثال: 5s نشان دهنده مدت زمان پنج ثانیه و 1m30s نشان دهنده مدت زمان است. یک دقیقه و سی ثانیه است.

  • مدیر کنترلر ابری (Cloud Controller Manager)

    یک مولفه کوبرنتیز control plane که منطق کنترل مختص ابر را در خود جای می‌دهد. مدیر کنترل‌کننده ابری به شما امکان می‌دهد کلاستر خود را به API ارائه‌دهنده ابر خود پیوند دهید و مولفه‌هایی را که با آن پلتفرم ابر در تعامل هستند از مولفه‌هایی که فقط با کلاستر شما در تعامل هستند جدا می‌کند.

    [+]

    با جدا کردن منطق قابلیت همکاری بین کوبرنتیز و زیرساخت ابری زیربنایی، مؤلفه‌ی cloud-controller-manager، ارائه‌دهندگان ابر را قادر می‌سازد تا ویژگی‌ها را با سرعتی متفاوت در مقایسه با پروژه اصلی کوبرنتیز منتشر کنند.

  • مشارکت‌کننده

    کسی که کد، مستندات یا وقت خود را برای کمک به پروژه یا جامعه کوبرنتیز اهدا می‌کند.

    [+]

    مشارکت‌ها شامل pull request ها (PR)، issue ها، بازخورد، special interest groups (SIG) مشارکت، یا سازماندهی رویدادهای اجتماعی می‌شود.

  • مشارکت‌کننده‌ی کد (Code Contributor)

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

    [+]

    آن ها همچنین یک عضو جامعه (community member) فعال هستند که در یک یا چند Special Interest Groups (SIGs) شرکت می‌کنند.

  • معمار برنامه

    شخصی که مسئول طراحی سطح بالای یک برنامه است.

    [+]

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

  • معمار کلاستر

    شخصی که زیرساختی را طراحی می‌کند که شامل یک یا چند کلاستر کوبرنتیز است.

    [+]

    معماران خوشه‌ به بهترین شیوه‌ها برای سیستم‌های توزیع‌شده، برای مثال، در دسترس بودن بالا و امنیت، توجه دارند.

  • مقیاس‌گذاری افقی خودکار پادها
    همچنین شناخته شده به عنوان: HorizontalPodAutoscaler, HPA

    یک منبع API که به طور خودکار تعداد رونوشت های پاد (Pod) را بر اساس میزان استفاده هدفمند از CPU یا اهداف متریک سفارشی، مقیاس‌بندی می‌کند.

    [+]

    HPA معمولاً با ReplicationControllers، Deployments، یا ReplicaSets استفاده می‌شود. این روش را نمی‌توان روی اشیایی که قابلیت مقیاس‌بندی ندارند، مثلاً DaemonSets، اعمال کرد.

  • منابع (زیرساخت)

    قابلیت‌هایی که برای یک یا چند گره(node) (پردازنده، حافظه، پردازنده‌های گرافیکی و غیره) ارائه شده و برای مصرف توسط Pods که روی آن گره‌ها اجرا می‌شوند، در دسترس قرار می‌گیرد.

    کوبرنتیز همچنین از اصطلاح منبع برای توصیف منابع API استفاده می‌کند.

    [+]

    کامپیوترها امکانات سخت‌افزاری اساسی را فراهم می‌کنند: قدرت پردازش، حافظه ذخیره‌سازی، شبکه و غیره. این منابع ظرفیت محدودی دارند که با واحدی که برای آن منبع قابل استفاده است (تعداد پردازنده‌ها، بایت‌های حافظه و غیره) اندازه‌گیری می‌شود. کوبرنتیز منابع رایج را برای تخصیص به Workload‌ها، خلاصه می‌کند و از اجزای اولیه سیستم عامل (به عنوان مثال، لینوکس cgroups) برای مدیریت مصرف توسط workloads) استفاده می‌کند.

    همچنین می‌توانید از تخصیص منابع پویا برای مدیریت خودکار تخصیص منابع پیچیده استفاده کنید.

  • منبع API
    همچنین شناخته شده به عنوان: Resource

    یک موجودیت در سیستم تایپ کوبرنتیز، مربوط به یک endpoint در API کوبرنتیز. یک منبع معمولاً نشان‌دهنده‌ی شیء است. برخی منابع، عملیاتی را روی اشیاء دیگر نشان می‌دهند، مانند بررسی مجوز.

    [+]

    هر منبع، یک endpoint HTTP (URI) را در سرور API کوبرنتیز نشان می‌دهد که schema اشیاء یا عملیات روی آن منبع را تعریف می‌کند.

  • منبع نسخه گروهی
    همچنین شناخته شده به عنوان: GVR

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

    [+]

    منابع نسخه گروهی (GVR) گروه API، نسخه API و منبع (نام نوع شیء همانطور که در URI نشان داده می‌شود) مرتبط با دسترسی به یک شناسه خاص از شیء در کوبرنتیز را مشخص می‌کنند. GVRها به شما امکان می‌دهند اشیاء مختلف کوبرنتیز را تعریف و از هم متمایز کنید و روشی برای دسترسی به اشیاء مشخص کنید که حتی با تغییر APIها نیز پایدار باشد.

  • نام (Name)

    یک رشته که توسط کلاینت ارائه می‌شود و در URL منبع به یک آبجکت اشاره می‌کند؛ مانند /api/v1/pods/some-name.

    [+]

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

  • نتورک پالیسی (Network Policy)

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

    [+]

    نتورک پالیسی‌ها به شما کمک می‌کنند به‌صورت اعلانی (declarative) پیکربندی کنید که کدام پادها اجازه دارند به یکدیگر متصل شوند، کدام نیم‌اسپیس‌ها مجاز به برقراری ارتباط هستند، و به‌طور مشخص هر سیاست روی کدام شماره‌پورت‌ها اعمال شود. منبع‌های NetworkPolicy از لیبل‌ها برای انتخاب پادها استفاده می‌کنند و قوانینی تعریف می‌کنند که مشخص می‌کند چه ترافیکی به پادهای انتخاب‌شده مجاز است. نتورک پالیسی توسط پلاگین شبکه‌ی پشتیبانی‌شده‌ای که از سوی یک ارائه‌دهنده‌ی شبکه فراهم می‌شود پیاده‌سازی می‌گردند. توجه داشته باشید که ایجاد یک منبع شبکه بدون وجود کنترلری که آن را پیاده‌سازی کند، هیچ اثری نخواهد داشت.

  • وابستگی (Affinity)

    در کوبرنتیز، affinity مجموعه‌ای از قوانین است که به scheduler در مورد محل قرارگیری پادها راهنمایی می‌کند.

    [+]

    دو نوع affinity وجود دارد:

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

  • هوک‌های چرخه عمر کانتینر

    هوک های چرخه عمر، رویدادها را در چرخه عمر مدیریت کانتینر نمایش می‌دهند و به کاربر اجازه می‌دهند هنگام وقوع رویدادها، کدی را اجرا کند.

    [+]

    دو هوک در معرض کانتینرها قرار دارند: PostStart که بلافاصله پس از ایجاد کانتینر اجرا می‌شود و PreStop که مسدودکننده است و بلافاصله قبل از خاتمه کانتینر فراخوانی می‌شود.

آخرین تغییرات August 11, 2025 at 7:14 PM PST: Persian Localization - Part 1 (4dc706e43b)