yaml
sitemap: changefreq: yearly priority: 0.5 categories:
- Cloud Computing
- DevOps
- Open Source tags:
- Kubernetes
- Container Orchestration
- Microservices type: article title: درک معماری کوبرنتیس و تحول آن description: راهنمای عمیق درباره معماری کوبرنتیس، سیر تکاملی تاریخی آن، اجزاء هستهای و بهترین روشها برای ارکستراسیون مدرن کانتینرها. breadcrumb: Kubernetes Architecture index_title: درک معماری کوبرنتیس و تحول آن last_updated: May 17, 2026 article_date: 2026.05.17 brief: این مقاله به ریشههای ارکستراسیون کانتینرها میپردازد، طراحی لایهای کوبرنتیس را گام به گام بررسی میکند، هر جزء پل کنترل و گره را توضیح میدهد و بینشهای عملی دربارهٔ مقیاسپذیری، امنیت و روندهای آینده ارائه میدهد. خوانندگان یک مدل ذهنی واضح از نحوهٔ مدیریت بارهای کاری توسط کوبرنتیس در خوشهها، اهمیت رویکرد API‑first و چگونگی تغییر اکوسیستم توسط افزونههای نوظهور به دست خواهند آورد.
# درک معماری کوبرنتیس و تحول آن
ارکستراسیون کانتینرها شیوهٔ ساخت، استقرار و مدیریت برنامههای مدرن در مقیاس را دگرگون کرده است. در میان مجموعهٔ راهحلهایی که در اوایل دهه ۲۰۱۰ ظاهر شدند، **کوبرنتیس** — که اغلب به اختصار **K8s** نامیده میشود — به استاندارد دِفاکتو برای خودکارسازی استقرار، مقیاسپذیری و عملیات بارهای کاری کانتینری تبدیل شده است. این مقاله نیروهای تاریخی که منجر به پیدایش کوبرنتیس شدند را ردیابی میکند، معماری لایهای آن را تجزیه‑و‑تحلیل مینماید و تصمیمات طراحی که آن را در چشمانداز پویا و متغیر ابرها مرتبط میماند، برجسته میسازد.
## از مدیران خوشهٔ اولیه تا یک پل کنترل یکپارچه
سفر با مدیران خوشهٔ اختصاصی مانند **Borg** در گوگل و پروژههای متن باز نظیر **Mesos** آغاز شد. این سیستمها نشان دادند که مدیریت بزرگمقیاس کانتینرها نیازمند یک مدل اعلانی، زمانبندی مرکزی و تحمل خطای قوی است. زمانی که گوگل پروژهٔ متن باز **کوبرنتیس** را در سال ۲۰۱۴ منتشر کرد، درسهای آموخته شده از Borg را به یک پلتفرم مدولار مبتنی بر API تبدیل کرد. تغییر از اسکریپتهای امری به فلسفهٔ **API‑first** به این معنا بود که هر عملیات — ایجاد پاد، مقیاسپذیری یک دیپلویمنت یا بهروزرسانی یک سرویس — میتواند به عنوان یک منبع اعلانی بیان شود و توسط پل کنترل پردازش گردد.
## اجزاء هستهای پل کنترل کوبرنتیس
در قلب K8s مجموعهای از سرویسهای سستمتصل وجود دارد که با هم پل کنترل را تشکیل میدهند. هر جزء بهعنوان یک پردازش اجرا میشود و معمولاً بهصورت پادهای ایستای روی **گرهٔ مستر** مستقر میگردد. تعامل این سرویسها با ذخیرهساز کلید‑مقدار **etcd** منبع حقیقت سیستم را شکل میدهد.
### etcd – فروشگاه توزیعشدهٔ پیکربندی
`etcd` تمام وضعیت خوشه را ذخیره میکند، شامل اطلاعات گرهها، توصیف بارهای کاری و اشیای پیکربندی. این سرویس از الگوریتم اجماع Raft برای اطمینان از سازگاری در میان یک کُواروم گره استفاده میکند و در برابر خرابیهای جزئی مقاوم است. تمام اجزاء دیگر پل کنترل از `etcd` میخوانند و روی آن مینویسند تا یک منبع حقیقت واحد حفظ شود.
### kube‑apiserver – دروازهٔ جلویی
**kube‑apiserver** درخواستهای RESTful API را از کاربران، کنترلرها و اجزاء داخلی اعتبارسنجی و پردازش میکند. با افشای یک نقطهٔ انتهایی HTTP / JSON یکپارچه، مکانیزمهای ذخیرهسازی زیرین را انتزاع میکند و به توسعهدهندگان اجازه میدهد از طریق **kubectl**، کتابخانههای کلاینت یا کنترلرهای سفارشی با خوشه تعامل داشته باشند. افزونههای احراز هویت و مجوز، این دروازه را محافظت کرده و سیاستهای RBAC و کنترلهای پذیرش را اعمال مینمایند.
### scheduler – موتور تصمیمگیری
به محض اینکه یک مانیفست پاد جدید در `etcd` ذخیره شد، **scheduler** توپولوژی منابع خوشه را ارزیابی میکند، پیششرطها (مانند توافق گره، taint) و اولویتها (مانند توافق پاد، تعادل بار) را اعمال مینماید تا گرهٔ بهینهای انتخاب شود. چارچوب قابل توسعهٔ آن به مدیران اجازه میدهد منطق زمانبندی سفارشی را وصل کرده و بارهای کاری خاصی مثل آموزش AI با GPU یا پردازش لبهٔ کمتاخیر را پشتیبانی کنند.
### controller‑manager – هماهنگکنندهٔ وضعیت
**controller‑manager** مجموعهای از کنترلرها را میزباند که بهطور مداوم وضعیت مطلوب تعریفشده در API را با وضعیت واقعی مشاهدهشده در خوشه همگام میسازند. کنترلرها شامل **replication controller**، **deployment controller**، **statefulset controller** و **service controller** میشوند. هر کدام حلقهٔ سادهای دارند: مشاهدهٔ تغییرات، محاسبهٔ اختلاف و اجرای اقدام تصحیحی مانند ایجاد پاد یا بهروزرسانی endpointها.
### cloud‑controller‑manager – سازگارکنندهٔ خاص ابر
برای خوشههایی که در ابرهای عمومی اجرا میشوند، **cloud‑controller‑manager** APIهای خاص ارائهدهندگان (مانند تعادلبارها، ذخیرهسازی پایدار) را پشت یک واسط مشترک انتزاع میکند. این جداسازی به کوبرنتیس اجازه میدهد تا بیطرف نسبت به ابر باشد در حالی که همچنان از سرویسهای بومی مانند AWS ELB یا GCP Persistent Disk بهرهمند میشود.
## معماری گره: Runtime، Kubelet و Proxy
گرههای کاری کانتینرهای برنامهها را اجرا میکنند. هر گره سه عامل اصلی دارد:
* **container runtime** – نرمافزاری که ایمیجها را بارگیری و کانتینرها را اجرا میکند (Docker، containerd، CRI‑O). نسخههای جدید K8s از طریق **Container Runtime Interface (CRI)**، یک قرارداد gRPC‑based، با runtimeها تعامل میکند و امکان استفاده از runtimeهای قابل وصل را فراهم میآورد.
* **kubelet** – عاملی که گره را به API server ثبت میکند، مشخصات پاد را دریافت میکند و اطمینان مییابد کانتینرها با وضعیت مطلوب همخوانی دارند. این عامل سلامت را نظارت میکند، وضعیت را گزارش میدهد و محدودیتهای **cgroups** برای CPU و حافظه را اعمال مینماید.
* **kube‑proxy** – یک پراکسی شبکه که قوانین iptables یا IPVS را برای انتشار سرویسها در سراسر خوشه نگه میدارد و تعادل بار و چسبندگی نشست را مدیریت میکند.
## نمای تصویری در Mermaid
```mermaid
graph TD
subgraph ControlPlane["Control Plane"]
APIServer["\"kube-apiserver\""]
Scheduler["\"scheduler\""]
ControllerMgr["\"controller-manager\""]
CloudCM["\"cloud-controller-manager\""]
ETCD["\"etcd\""]
end
subgraph Nodes["Worker Nodes"]
Node1["\"Node 1\""]
Node2["\"Node 2\""]
Node3["\"Node 3\""]
end
APIServer --> ETCD
Scheduler --> APIServer
ControllerMgr --> APIServer
CloudCM --> APIServer
APIServer --> Node1
APIServer --> Node2
APIServer --> Node3
Node1 -->|runs| Kubelet1["\"kubelet\""]
Node2 -->|runs| Kubelet2["\"kubelet\""]
Node3 -->|runs| Kubelet3["\"kubelet\""]
Node1 -->|runs| Proxy1["\"kube-proxy\""]
Node2 -->|runs| Proxy2["\"kube-proxy\""]
Node3 -->|runs| Proxy3["\"kube-proxy\""]
این نمودار ارتباط دوسویه بین پل کنترل و هر گرهٔ کاری را نشان میدهد. تمام تغییرات وضعیت از طریق etcd عبور میکند، در حالی که scheduler و کنترلرها بهعنوان تصمیمگیرندگان مستقل عمل مینمایند.
استراتژیهای مقیاسپذیری و دسترسپذیری بالا
کوبرنتیس هم به صورت عمودی (افزودن منابع به یک گره) و هم به صورت افقی (افزودن گرههای بیشتر) مقیاس میگیرد. Horizontal Pod Autoscaler (HPA) بهطور خودکار تعداد replicaها را بر اساس استفادهٔ CPU مشاهدهشده یا معیارهای سفارشی تنظیم میکند. برای پل کنترل، دسترسپذیری بالا با اجرای چندین نمونهٔ API server پشت یک لود بالانسر و پیکربندی etcd بهصورت یک کلاستر با تعداد اعضای فرد حاصل میشود. مکانیزم leader election در scheduler و controller‑manager تضمین میکند که تنها یک نمونه اقدامات بحرانی را انجام دهد، در حالی که رونوشتهای آماده برای takeover آمادهاند.
مبانی امنیتی
امنیت در K8s بهصورت لایهای اعمال میشود:
- احراز هویت – هویت کلاینتهای API را با استفاده از گواهینامهها، توکنها یا ارائهدهندگان هویت خارجی اعتبارسنجی میکند.
- مجوزدهی – تصمیمگیریهای سیاستی را از طریق Role‑Based Access Control (RBAC) یا Attribute‑Based Access Control (ABAC) اعمال مینماید.
- کنترل پذیرش – بررسیهای پلاگینی نظیر pod security policies، اصالت تصویر یا محدودیتهای منابع را قبل از ذخیرهٔ یک شیء اعمال میکند.
- سیاستهای شبکه – جریانهای ترافیک مجاز بین پادها را با استفاده از انتخابگر برچسبها تعریف میکند.
- استانداردهای امنیتی پاد – مجموعهای از سیاستهای پیشتعریفشده (privileged, baseline, restricted) که پیکربندیهای ایمن پاد را راهنمایی میکنند.
گسترشپذیری از طریق منابع سفارشی
یکی از قدرتمندترین ویژگیهای K8s، Custom Resource Definition (CRD) است که به توسعهدهندگان امکان میدهد اشیای API جدیدی بدون تغییر در کد هسته بسازند. ترکیب این قابلیت با operators — که منطق دامنه‑خاص را در یک کنترلر محصور میکنند — اجازه میدهد برنامههای حالتدار پیچیده (پایگاههای داده، سامانههای پیامرسان) بهصورت خودکار با همان حلقهٔ همگامسازی که منابع داخلی را مدیریت میکند، خودکار شوند.
قابل مشاهده بودن و عیبیابی
قابلیت مشاهده مؤثر بر پایهٔ سه ستون است:
- متریکها – از طریق Metrics Server فراهم شده و توسط Prometheus جمعآوری میشوند و دیدی دربارهٔ مصرف منابع گره و پاد ارائه میدهند.
- لاگگیری – بهصورت متمرکز توسط fluentd یا Loki انجام میشود و جریانهای stdout/stderr کانتینرها را برای تحلیلهای قضایی جمعآوری میکند.
- ترسیم – چارچوبهای توزیعی مانند Jaeger جریان درخواستها را در میان میکروسرویسها ضبط میکنند و گلوگاههای تأخیر را آشکار میسازند.
این سیگنالها به داشبوردهایی مثل Grafana خورده میشوند و امکان بررسی سلامت زمان واقعی و بهینهسازی عملکرد را میدهند.
مسیر پیشرو: روندهای نوظهور
کوبرنتیس همچنان در حال تکامل است تا نیازهای محاسبات لبه، بارهای کاری سرورلس و خط لولههای متمرکز بر هوش مصنوعی را برآورده کند. پروژههای برجسته شامل:
- KubeEdge – APIهای هستهای را برای مدیریت دستگاهها و بارهای کاری در لبهٔ شبکه گسترش میدهد و بر اتصال متناوب و محدودیتهای کممصرف تمرکز دارد.
- Knative – بر پایهٔ K8s primitives سرورلس (توابع، eventing) را فراهم میکند و پیچیدگی زیرساخت را انتزاع مینماید.
- Cluster API – پروVISIONING خوشهٔ خود کوبرنتیس را بهصورت اعلانی استاندارد میکند و مدیریت چرخهٔ عمر سازگار در میان ابرها را تقویت میکند.
این پروژهها نمایانگر حرکت گستردهتر به سمت GitOps هستند، جایی که تمام وضعیت خوشه — شامل زیرساخت — در سیستم کنترل نسخه قرار دارد و بهصورت خودکار همگام میشود.
نتیجهگیری
معماری کوبرنتیس درسآموزی است در طراحی مدولار و مبتنی بر API. با جداسازی نگرانیها به اجزای تعریفشده— etcd برای حالت، API server برای نیت، scheduler برای تخصیص و کنترلرها برای همگامسازی— K8s یک بستر مقاوم و قابل گسترش ارائه میدهد که به انواع بارهای کاری میپردازد. فهم هر لایه، از مکانیزمهای اجماع پل کنترل تا تعاملات زمان‑اجرای سطح گره، مهندسان را قادر میسازد تا استقرارهای امن، مقیاسپذیر و با کارایی بالا طراحی کنند که از چند گرهٔ محلی تا خوشههای چند‑منطقهای جهانی را پوشش میدهد.