واژه‌نامه

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

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

اجزای داخلی کوبرنتیز.
مرتبط با توسعه متن‌باز کوبرنتیز.
نوعی از منابع که کوبرنتیز به طور پیش‌فرض پشتیبانی می‌کند.
سفارشی‌سازی‌های پشتیبانی‌شده کوبرنتیز.
مرتبط برای کاربران تازه‌کار کوبرنتیز.
نحوه ارتباط اجزای کوبرنتیز با یکدیگر (و با برنامه‌های خارج از کلاستر).
راه‌اندازی و نگهداری کوبرنتیز.
حفظ امنیت برنامه‌های کوبرنتیز.
نحوه مدیریت داده‌های پایدار توسط برنامه‌های کوبرنتیز.
نرم‌افزاری که استفاده از کوبرنتیز را آسان‌تر یا بهتر می‌کند.
نمایانگر نوع رایج کاربر کوبرنتیز.
برنامه‌هایی که روی کوبرنتیز اجرا می‌شوند.
معماری جامعه شیء اصلی افزونه مبانی شبکه عملیات امنیت ذخیره‌سازی ابزار نوع کاربر بار کاری (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ها و …) کاربرد ندارد.

  • Persistent Volume

    An API object that represents a piece of storage in the cluster. Available as a general, pluggable resource that persists beyond the lifecycle of any individual Pod.

    [+]

    PersistentVolumes (PVs) provide an API that abstracts details of how storage is provided from how it is consumed. PVs are used directly in scenarios where storage can be created ahead of time (static provisioning). For scenarios that require on-demand storage (dynamic provisioning), PersistentVolumeClaims (PVCs) are used instead.

  • Persistent Volume Claim

    Claims storage resources defined in a PersistentVolume so that it can be mounted as a volume in a container.

    [+]

    Specifies the amount of storage, how the storage will be accessed (read-only, read-write and/or exclusive) and how it is reclaimed (retained, recycled or deleted). Details of the storage itself are described in the PersistentVolume object.

  • Platform Developer

    A person who customizes the Kubernetes platform to fit the needs of their project.

    [+]

    A platform developer may, for example, use Custom Resources or Extend the Kubernetes API with the aggregation layer to add functionality to their instance of Kubernetes, specifically for their application. Some Platform Developers are also contributors and develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions.

  • Pod

    The smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster.

    [+]

    A Pod is typically set up to run a single primary container. It can also run optional sidecar containers that add supplementary features like logging. Pods are commonly managed by a Deployment.

  • Pod Disruption

    Pod disruption is the process by which Pods on Nodes are terminated either voluntarily or involuntarily.

    [+]

    Voluntary disruptions are started intentionally by application owners or cluster administrators. Involuntary disruptions are unintentional and can be triggered by unavoidable issues like Nodes running out of resources, or by accidental deletions.

  • Pod Disruption Budget
    همچنین شناخته شده به عنوان: PDB

    A Pod Disruption Budget allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time.

    [+]

    Involuntary disruptions cannot be prevented by PDBs; however they do count against the budget.

  • Pod Lifecycle

    The sequence of states through which a Pod passes during its lifetime.

    [+]

    The Pod Lifecycle is defined by the states or phases of a Pod. There are five possible Pod phases: Pending, Running, Succeeded, Failed, and Unknown. A high-level description of the Pod state is summarized in the PodStatus phase field.

  • Pod Priority

    Pod Priority indicates the importance of a Pod relative to other Pods.

    [+]

    Pod Priority gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload.

  • Pod Security Policy

    Enables fine-grained authorization of Pod creation and updates.

    [+]

    A cluster-level resource that controls security sensitive aspects of the Pod specification. The PodSecurityPolicy objects define a set of conditions that a Pod must run with in order to be accepted into the system, as well as defaults for the related fields. Pod Security Policy control is implemented as an optional admission controller.

    PodSecurityPolicy was deprecated as of Kubernetes v1.21, and removed in v1.25. As an alternative, use Pod Security Admission or a 3rd party admission plugin.

  • PodTemplate
    همچنین شناخته شده به عنوان: pod template

    An API object that defines a template for creating Pods. The PodTemplate API is also embedded in API definitions for workload management, such as Deployment or StatefulSets.

    [+]

    Pod templates allow you to define common metadata (such as labels, or a template for the name of a new Pod) as well as to specify a pod's desired state. Workload management controllers use Pod templates (embedded into another object, such as a Deployment or StatefulSet) to define and manage one or more Pods. When there can be multiple Pods based on the same template, these are called replicas. Although you can create a PodTemplate object directly, you rarely need to do so.

  • Preemption

    Preemption logic in Kubernetes helps a pending Pod to find a suitable Node by evicting low priority Pods existing on that Node.

    [+]

    If a Pod cannot be scheduled, the scheduler tries to preempt lower priority Pods to make scheduling of the pending Pod possible.

  • PriorityClass

    A PriorityClass is a named class for the scheduling priority that should be assigned to a Pod in that class.

    [+]

    A PriorityClass is a non-namespaced object mapping a name to an integer priority, used for a Pod. The name is specified in the metadata.name field, and the priority value in the value field. Priorities range from -2147483648 to 1000000000 inclusive. Higher values indicate higher priority.

  • Probe

    A check that the kubelet periodically performs against a container that is running in a pod, that will define container's state and health and informing container's lifecycle.

    [+]

    To learn more, read container probes.

  • Proxy

    In computing, a proxy is a server that acts as an intermediary for a remote service.

    [+]

    A client interacts with the proxy; the proxy copies the client's data to the actual server; the actual server replies to the proxy; the proxy sends the actual server's reply to the client.

    kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.

    You can run kube-proxy as a plain userland proxy service. If your operating system supports it, you can instead run kube-proxy in a hybrid mode that achieves the same overall effect using less system resources.

  • QoS Class

    QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.

    [+]

    QoS Class of a Pod is set at creation time based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction. Kubernetes can assign one of the following QoS classes to a Pod: Guaranteed, Burstable or BestEffort.

  • Quantity

    A whole-number representation of small or large numbers using SI suffixes.

    [+]

    Quantities are representations of small or large numbers using a compact, whole-number notation with SI suffixes. Fractional numbers are represented using milli units, while large numbers can be represented using kilo, mega, or giga units.

    For instance, the number 1.5 is represented as 1500m, while the number 1000 can be represented as 1k, and 1000000 as 1M. You can also specify binary-notation suffixes; the number 2048 can be written as 2Ki.

    The accepted decimal (power-of-10) units are m (milli), k (kilo, intentionally lowercase), M (mega), G (giga), T (tera), P (peta), E (exa).

    The accepted binary (power-of-2) units are Ki (kibi), Mi (mebi), Gi (gibi), Ti (tebi), Pi (pebi), Ei (exbi).

  • RBAC (Role-Based Access Control)

    Manages authorization decisions, allowing admins to dynamically configure access policies through the Kubernetes API.

    [+]

    RBAC utilizes four kinds of Kubernetes objects:

    Role
    Defines permission rules in a specific namespace.
    ClusterRole
    Defines permission rules cluster-wide.
    RoleBinding
    Grants the permissions defined in a role to a set of users in a specific namespace.
    ClusterRoleBinding
    Grants the permissions defined in a role to a set of users cluster-wide.

    For more information, see RBAC.

  • Replica

    A copy or duplicate of a Pod or a set of pods. Replicas ensure high availability, scalability, and fault tolerance by maintaining multiple identical instances of a pod.

    [+]

    Replicas are commonly used in Kubernetes to achieve the desired application state and reliability. They enable workload scaling and distribution across multiple nodes in a cluster.

    By defining the number of replicas in a Deployment or ReplicaSet, Kubernetes ensures that the specified number of instances are running, automatically adjusting the count as needed.

    Replica management allows for efficient load balancing, rolling updates, and self-healing capabilities in a Kubernetes cluster.

  • ReplicaSet

    A ReplicaSet (aims to) maintain a set of replica Pods running at any given time.

    [+]

    Workload objects such as Deployment make use of ReplicaSets to ensure that the configured number of Pods are running in your cluster, based on the spec of that ReplicaSet.

  • ReplicationController

    A workload resource that manages a replicated application, ensuring that a specific number of instances of a Pod are running.

    [+]

    The control plane ensures that the defined number of Pods are running, even if some Pods fail, if you delete Pods manually, or if too many are started by mistake.

  • 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) یا قطعی برق که بر یک منطقه خرابی گسترده‌تر تأثیر می‌گذارد، آفلاین شود، کوبرنتیز آن را اختلال غیرارادی می‌نامد.

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

  • اخراج آغاز شده با 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) که در کنترل پلین تعریف شده است انجام دهد، این نمونه‌ای از الگوی اپراتور است.

  • اویکشن(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/) است. ماموریت آن فراگیر کردن رایانش بومی ابری است.

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

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

    [+]

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

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

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

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

    [+]

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

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

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

    به کاربران اجازه می‌دهد تا ایجاد خودکار فضای ذخیره‌سازی 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)

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

    [+]

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

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

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

    [+]

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

  • توکن وب JSON (JWT)

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

    [+]

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

  • جاب (Job)

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

    [+]

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

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

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

    [+]

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

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

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

    [+]

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

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

    دروازه‌های ویژگی (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.

  • رویداد (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؛ اما می‌توانند هر ارائه نرم‌افزاری باشند که توسط یک برنامه کاربردی قابل استفاده باشد.

  • عضو (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 استاتیک پشتیبانی نمی‌شوند.

  • کلاستر (Cluster)

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

    [+]

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

  • کنترل کننده

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

    [+]

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

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

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

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

    [+]

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

  • گروه 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)