مروری بر معماری Kubernetes

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

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

کوبرنتیس
در هسته معماری Kubernetes صفحه کنترل Kubernetes قرار دارد که از سرور API Kubernetes، etcd، زمانبندی و مدیر کنترلر تشکیل شده است. این اجزا برای مدیریت خوشه Kubernetes با هم کار می کنند.

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

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

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

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

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

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

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

کشف خدمات
خدمات راهی برای کشف آدرس IP و پورت یک پاد که یک سرویس خاص را اجرا می کند ارائه می دهد. این به مشتریان امکان می دهد بدون نیاز به دانستن آدرس IP یا پورت هر پاد به سرویس متصل شوند.

انواع خدمات
سرویس ها را می توان برای استفاده از انواع مختلف دسترسی به شبکه، مانند ClusterIP، NodePort و LoadBalancer پیکربندی کرد.

• ClusterIP:ClusterIP نوع سرویس پیش فرض در Kubernetes است. این یک آدرس IP مجازی برای مجموعه‌ای از پادها فراهم می‌کند که فقط در خوشه Kubernetes قابل دسترسی هستند.
• NodePort:NodePort راهی برای نمایش یک سرویس در یک پورت استاتیک در هر گره کارگر در خوشه ارائه می دهد. این امکان دسترسی به سرویس را از خارج از خوشه فراهم می کند.
• متعادل کننده بار:LoadBalancer با استفاده از متعادل‌کننده بار ارائه‌دهنده ابر، راهی برای نمایش خارجی یک سرویس ارائه می‌کند. این اجازه می دهد تا سرویس از خارج از خوشه با استفاده از یک آدرس IP عمومی قابل دسترسی باشد. انتخاب بین استفاده از NodePort، ClusterIP، یا LoadBalancer به مورد خاص و نیازهای شما بستگی دارد.

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

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

توجه به این نکته مهم است که سرویس‌های نوع LoadBalancer ممکن است هزینه‌های اضافی را نیز متحمل شوند، زیرا اغلب نیاز به استفاده از سرویس تعادل بار ارائه‌دهنده ابر دارند که ممکن است به طور جداگانه شارژ شود.

بیایید تمام فیلدهای Service.yml را بررسی کنیم:

apiVersion: v1
kind: Service
metadata:
  name: my-service # Name of the service
  labels:
    app: my-app
spec:
  type: LoadBalancer # Type of the service
  selector:
    app: my-app
  ports:
    - name: http
      port: 80 # Port exposed by the service
      targetPort: 8080 # Port of the pod that the service is directing traffic to
      protocol: TCP # Protocol used by the service

apiVersion:

نسخه Kubernetes API برای استفاده برای این شی. در این مورد، v1، نسخه اصلی API است.
kind: نوع شیء برای ایجاد. در این مورد، این یک سرویس است.

فراداده:

داده هایی که به شناسایی سرویس کمک می کند، مانند نام و labels.name: نام service.labels: جفت های کلید-مقدار که می توانند برای سازماندهی و انتخاب اشیا استفاده شوند.

spec: مشخصات سرویس.

type: نوع خدمات. در این مورد، LoadBalancer است که با استفاده از متعادل کننده بار یک ارائه دهنده ابر، سرویس را به صورت خارجی در معرض دید قرار می دهد.

انتخابگر: برچسب هایی که برای انتخاب غلاف هایی استفاده می شود که سرویس ترافیک را به آن ها هدایت می کند.

پورت ها: پورت هایی که سرویس به آنها گوش می دهد و ترافیک را به آنها هدایت می کند.

• name: نام بندر. این اختیاری است، اما می تواند برای اهداف مستندسازی مفید باشد.
• پورت: شماره پورتی که سرویس به آن گوش خواهد داد.
• targetPort: شماره درگاهی که سرویس ترافیک را به آن هدایت می کند.
• پروتکل: پروتکل مورد استفاده سرویس که می تواند TCP، UDP یا SCTP باشد. اگر مشخص نشده باشد، TCP به طور پیش فرض استفاده می شود. به طور کلی، فایل سرویس YAML یک سرویس نامگذاری شده را تعریف می کند که به پورت 80 گوش می دهد و ترافیک را با برچسب برنامه به پادها هدایت می کند: my-app. این از نوع LoadBalancer است، بنابراین می توان با استفاده از متعادل کننده بار ارائه دهنده ابر به صورت خارجی به آن دسترسی داشت.

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

ConfigMaps/Secrets
ConfigMaps و Secrets راهی برای ذخیره داده های پیکربندی و اطلاعات حساس در خوشه Kubernetes ارائه می دهند. می توان از آنها برای ذخیره متغیرهای محیطی، آرگومان های خط فرمان و فایل های پیکربندی استفاده کرد.

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

بیایید با مثال تمام نقاط استقرار را درک کنیم:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

apiVersion:

این فیلد نسخه Kubernetes API را که فایل YAML از آن استفاده می کند، مشخص می کند. در این مثال، ما از نسخه apps/v1 استفاده می کنیم.

kind: این فیلد نوع شی ای را که ما ایجاد می کنیم را مشخص می کند. در این مثال، ما یک شی Deployment ایجاد می کنیم.

فراداده:

این فیلد حاوی ابرداده های مربوط به شی، مانند نام، برچسب ها و حاشیه نویسی است. در این مثال، ما به Deployment یک نام nginx-deployment می‌دهیم. فراداده برای شناسایی و برچسب گذاری منابع و همچنین ارائه سایر اطلاعات مرتبط در مورد منبع استفاده می شود.

spec: این فیلد وضعیت مورد نظر شی را مشخص می کند. در این مثال، ما مشخص می‌کنیم که 3 نسخه از استقرار nginx خود را می‌خواهیم.

انتخابگر:

این فیلد برچسب هایی را مشخص می کند که باید برای تطبیق Pods با این Deployment استفاده شوند. در این مثال، ما از برنامه برچسب استفاده می کنیم: nginx.

قالب:

این فیلد حاوی الگوی Pod است که باید برای ایجاد پادهای جدید برای این Deployment استفاده شود. در این مثال، ما مشخص می‌کنیم که Pods باید یک برچسب برنامه داشته باشد: nginx.

ابرداده در قالب:

این فیلد حاوی ابرداده‌هایی درباره الگوی Pod است، مانند برچسب‌ها و حاشیه‌نویسی‌ها. در این مثال، ما مشخص می‌کنیم که Pods باید یک برچسب برنامه داشته باشد: nginx.

مشخصات درون قالب:

این فیلد وضعیت مورد نظر Pods را که از این الگو ایجاد می شود را مشخص می کند. در این مثال، ما مشخص می‌کنیم که هر Pod باید یک ظرف واحد به نام nginx داشته باشد و از تصویر nginx:latest داکر استفاده کند. ما همچنین مشخص می کنیم که کانتینر باید در پورت 80 گوش دهد.

ورود
Ingress یک شی Kubernetes است که راهی برای نمایش مسیرهای HTTP و HTTPS از خارج از خوشه Kubernetes به سرویس‌های درون خوشه ارائه می‌کند. این به شما امکان می دهد قوانینی را برای مسیریابی ترافیک به سرویس های مختلف بر اساس مسیر درخواست، میزبان و سایر پارامترها تعریف کنید.

نتیجه
Kubernetes یک سیستم قدرتمند و پیچیده برای مدیریت برنامه های کاربردی کانتینری در مقیاس است. در این مقاله به اصول معماری Kubernetes از جمله Pods، Nodes، Cluster و Services پرداختیم. ما همچنین انواع مختلف خدمات و نحوه استفاده از آنها را برای متعادل کردن بار و کشف سرویس بررسی کردیم.

با درک کامل از این مفاهیم، ​​باید برای شروع کار با Kubernetes و مدیریت برنامه های کانتینری خود به خوبی مجهز باشید.