استفاده از Kubernetes (کوبرنتیز) در سازمان‌ها، علی‌رغم مزایای فراوان، با چالش‌هایی همراه است که درک آن‌ها و یافتن راهکارهای مناسب می‌تواند برای موفقیت پروژه‌های فناوری اطلاعات حیاتی باشد.​

چالش‌های اصلی Kubernetes در سازمان‌ها

پیچیدگی در مدیریت و استقرار: Kubernetes به دلیل ساختار ماژولار و قابلیت‌های گسترده‌اش، نیازمند دانش فنی عمیق برای پیکربندی و نگهداری است.​

نیاز به منابع بالا: اجرای Kubernetes در محیط‌های با منابع محدود، مانند لبه شبکه یا دستگاه‌های IoT، می‌تواند چالش‌برانگیز باشد.​

امنیت و کنترل دسترسی: مدیریت دسترسی‌ها و اطمینان از امنیت در محیط‌های Kubernetes نیازمند تنظیمات دقیق و نظارت مداوم است.​

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


در این مقاله به بررسی چالش های کوبرنتیس و راهکار های آن پرداختیم .


نسخه : ۰٫۱

نویسنده : مهندس یاشار اسمعیل دخت


#kubernetes #linux #yashar_esmaildokht



https://t.iss.one/unixmens

با مفاهیم کوبر آشنا شویم :

در واقع Kubernetes (که به اختصار K8s نیز نامیده می‌شود) یک سیستم متن‌باز برای اتوماسیون استقرار، مقیاس‌گذاری و مدیریت برنامه‌های کانتینری است. این سیستم به شما این امکان را می‌دهد که برنامه‌های خود را در یک محیط توزیع‌شده و مقیاس‌پذیر اجرا کنید. در زیر به اجزای اصلی Kubernetes و توضیحات مربوط به هر یک از آن‌ها می‌پردازیم:
1. Pod

تعریف: Pod کوچک‌ترین واحد اجرایی در Kubernetes است و می‌تواند شامل یک یا چند کانتینر باشد که به اشتراک‌گذاری منابع و شبکه می‌پردازند.
ویژگی‌ها: Pods معمولاً برای اجرای یک سرویس یا یک برنامه خاص طراحی می‌شوند و می‌توانند به صورت موقتی یا دائمی باشند.

2. Service

تعریف: Service یک انتزاع است که به شما این امکان را می‌دهد تا به مجموعه‌ای از Pods که یک کار خاص را انجام می‌دهند، دسترسی پیدا کنید.
ویژگی‌ها: Services می‌توانند به عنوان یک نقطه دسترسی ثابت برای Pods عمل کنند و می‌توانند بار ترافیک را بین Pods توزیع کنند. انواع مختلفی از Services وجود دارد، از جمله ClusterIP، NodePort و LoadBalancer.

3. Deployment

تعریف: Deployment یک منبع Kubernetes است که به شما این امکان را می‌دهد تا به راحتی Pods را مدیریت کنید و استقرارهای جدید را انجام دهید.
ویژگی‌ها: با استفاده از Deployment، می‌توانید تعداد Pods را مقیاس‌گذاری کنید، نسخه‌های جدید را به‌روزرسانی کنید و در صورت بروز خطا، به نسخه‌های قبلی برگردید.

4. ReplicaSet

تعریف: ReplicaSet یک منبع Kubernetes است که تضمین می‌کند که تعداد مشخصی از Pods در هر زمان در حال اجرا باشند.
ویژگی‌ها: ReplicaSet معمولاً به عنوان بخشی از Deployment استفاده می‌شود و به شما این امکان را می‌دهد که تعداد Pods را مقیاس‌گذاری کنید.

5. StatefulSet

تعریف: StatefulSet برای مدیریت برنامه‌های Stateful (با وضعیت) طراحی شده است.
ویژگی‌ها: این نوع منبع به شما این امکان را می‌دهد که Pods را با شناسه‌های ثابت و ذخیره‌سازی پایدار مدیریت کنید.

6. ConfigMap و Secret

ConfigMap:

برای ذخیره‌سازی تنظیمات غیر حساس به کار می‌رود و به Pods اجازه می‌دهد تا به این تنظیمات دسترسی پیدا کنند.
Secret:

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

7. Volume

تعریف: Volume یک منبع ذخیره‌سازی است که به Pods اجازه می‌دهد تا داده‌ها را به صورت پایدار ذخیره کنند.
ویژگی‌ها: Volumes می‌توانند از انواع مختلفی از منابع ذخیره‌سازی (مانند NFS، AWS EBS و ...) استفاده کنند.

8. Namespace

تعریف: Namespace یک روش برای تقسیم منابع در یک کلاستر Kubernetes است.
ویژگی‌ها: با استفاده از Namespace، می‌توانید منابع را به صورت منطقی جدا کنید و به تیم‌های مختلف اجازه دهید که به صورت مستقل کار کنند.


#k8s #kubernetes #container
https://t.iss.one/unixmens

KubeKey and K3s are both tools related to Kubernetes, but they serve different purposes and have different use cases. Here's a comparison of the two:
K3s

What it is: K3s is a lightweight, certified Kubernetes distribution designed for resource-constrained environments and edge computing. It is developed by Rancher Labs.
Key Features:
Lightweight: K3s is designed to be easy to install and run with minimal resource requirements.
Simplified: It removes some non-essential features of Kubernetes to streamline the installation and operation.
Single binary: K3s is packaged as a single binary, making it easy to deploy.
Built-in components: It includes components like a local storage provider and a service load balancer out of the box.
Use Cases: Ideal for IoT devices, edge computing, development environments, and scenarios where a full Kubernetes installation would be too heavy.

KubeKey

What it is: KubeKey is a tool for deploying and managing Kubernetes clusters. It is part of the KubeSphere ecosystem and is designed to simplify the installation and management of Kubernetes.
Key Features:
Multi-cluster management: KubeKey can manage multiple Kubernetes clusters and supports various installation methods.
Flexible: It can deploy different Kubernetes distributions, including K3s and standard Kubernetes.
User-friendly: KubeKey provides a simple command-line interface and configuration files to streamline the deployment process.
Use Cases: Suitable for users who want to deploy and manage Kubernetes clusters easily, whether for development, testing, or production environments.

Summary

K3s is a lightweight Kubernetes distribution, while KubeKey is a deployment tool that can install and manage Kubernetes clusters, including K3s.
If you need a lightweight Kubernetes solution, K3s is the way to go. If you want a tool to help you deploy and manage Kubernetes clusters, KubeKey is a good choice.


#k8s #kubernetes #k3s #kubekey

https://t.iss.one/unixmens

kubekey


#kubekey #kubernetes

https://t.iss.one/unixmens

با مفهوم kubecni آشنا شویم :


در واقع kube-cni یا به طور دقیق‌تر Container Network Interface (CNI) در Kubernetes یکی از مهم‌ترین اجزای شبکه‌ای‌ست که اغلب کاربران تازه‌کار از آن غافل می‌مانند. در ادامه با زبان ساده برات توضیح می‌دم:
🔷ا kube-cni یا CNI چیست؟

CNI (Container Network Interface)
یک استاندارد شبکه‌ای است که مشخص می‌کند چگونه کانتینرها در Kubernetes با یکدیگر و با دنیای بیرون ارتباط برقرار کنند.

کلمه kube-cni معمولاً اشاره به:

پلاگین‌های شبکه‌ای CNI مورد استفاده در Kubernetes دارد


🧠 چرا Kubernetes به CNI نیاز دارد؟

برخلاف Docker که به‌صورت پیش‌فرض خودش شبکه می‌سازد، Kubernetes مستقل از یک پیاده‌سازی خاص شبکه است. بنابراین:

Kubernetes از پلاگین CNI برای اتصال پادها به یکدیگر استفاده می‌کند.

خود Kubernetes هیچ شبکه‌ای ارائه نمی‌دهد؛ فقط انتظارات را تعریف می‌کند.

🔌 برخی پلاگین‌های معروف CNI

Calico

سریع، با پشتیبانی از امنیت (network policies)، مناسب برای production

Flannel
ساده و سبک، مناسب برای تست و شروع کار

Cilium
مبتنی بر eBPF، بسیار پیشرفته، مناسب برای امنیت و observability بالا

Weave Net
پیکربندی آسان، با encryption داخلی
Canal ترکیب Calico و Flannel
📦 بسته kube-cni چیست؟

در بعضی توزیع‌ها مثل Ubuntu/Debian:

بسته‌ای به نام kubernetes-cni یا kube-cni نصب می‌شود.

این بسته شامل فایل‌های باینری CNI در مسیر /opt/cni/bin است.

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

#k8s #kubernetes
#ebpf

https://t.iss.one/unixmens

Cloud native ai
☁️ #cloud #native #ai #k8s #kubernetes@unixmens

https://t.iss.one/unixmens

#DiyakoSecureBow
————————————
CISO as a Service (vCISO)

Kubernetes: 
مدیریت مدرن کانتینرها و استقرار خودکار اپلیکیشن‌ ها
دوره‌ ای تخصصی برای DevOps، معماران سیستم و علاقه‌ مندان به فناوری‌ های Cloud Native
در دنیای امروز که مقیاس‌ پذیری، تحویل سریع و پایداری نرم‌افزارها اولویت اصلی سازمان‌ هاست، یادگیری Kubernetes به عنوان هسته اصلی اکوسیستم Cloud Native یک ضرورت حرفه‌ ای به شمار می‌ آید.
این دوره با تمرکز بر مباحث امنیتی در Kubernetes طراحی شده تا شما را برای چالش‌ های واقعی در زیرساخت‌ های ابری آماده کند.
سرفصل‌ های کلیدی دوره:
-آشنایی با مفاهیم پایه Kubernetes
-نصب و راه‌ اندازی اولیه
-کار با منابع اصلی Kubernetes
-مدیریت پیکربندی (ConfigMaps, Secrets, ...)
-شبکه‌ سازی و انتشار سرویس‌ ها (Service, Ingress)
-ذخیره‌ سازی و مدیریت Volumeها
-نظارت، لاگ‌ گیری و دیباگ
-بروزرسانی، Self-Healing و ریکاوری
-امنیت در معماری Kubernetes (RBAC، NetworkPolicy، Pod Security، Secure Image، Secret Management، Audit Logs)

👥 مخاطبان این دوره:
-مهندسان DevOps و Site Reliability Engineers (SREs)
-توسعه‌ دهندگان نرم‌ افزار که می‌خواهند اپلیکیشن‌ های خود را بهتر مدیریت و امن کنند
-مدیران سیستم و زیرساخت
-معماران فنی و Cloud Architects
-علاقه‌ مندان به Cloud Native و مسیرهای حرفه‌ ای در Microservices و Containerization

🗓 تاریخ شروع: یکشنبه، ۳۰ تیر ۱۴۰۴
🕕 زمان برگزاری: دوشنبه و چهارشنبه‌ ها، ساعت ۱۸:۰۰ تا ۲۱:۰۰
🌐 محل برگزاری: به‌ صورت آنلاین

برای دریافت اطلاعات تکمیلی و ثبت‌ نام با ما در ارتباط باشید.
📞 09194348743
☎️ 02191691692 (1)
✉️ [email protected]

-Secure Business Continuity-
2025.06.11
——————————————————
#Cybersecurity #vCISO #Kubernetes #DevOps #DevSecOps #Cloud #Infrastructure #CyberSecurityTraining

https://www.linkedin.com/posts/diyako-secure-bow_diyakosecurebow-cybersecurity-vciso-activity-7338436390898102273-3DKg

چرا kubekey بهتر است ؟


در واقع KubeKey یک ابزار منبع باز است که برای نصب و مدیریت کلاسترهای Kubernetes طراحی شده است. این ابزار به کاربران این امکان را می‌دهد که به راحتی کلاسترهای Kubernetes را بر روی زیرساخت‌های مختلف، از جمله Bare Metal، ماشین‌های مجازی و همچنین ارائه‌دهندگان ابری راه‌اندازی کنند.

▎ویژگی‌های KubeKey:

1. نصب آسان: KubeKey فرآیند نصب Kubernetes را ساده می‌کند و به کاربران این امکان را می‌دهد که با چند دستور ساده، کلاستر خود را راه‌اندازی کنند.

2. پشتیبانی از انواع زیرساخت‌ها: KubeKey می‌تواند بر روی زیرساخت‌های مختلفی مانند Bare Metal، VMware، OpenStack و همچنین ارائه‌دهندگان ابری مانند AWS و GCP نصب شود.

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

4. مدیریت کلاستر: KubeKey همچنین ابزارهایی برای مدیریت و نگهداری کلاسترهای Kubernetes ارائه می‌دهد، از جمله به‌روزرسانی‌ها و مقیاس‌پذیری.

5. دسترس‌پذیری بالا: این ابزار به کاربران کمک می‌کند تا کلاسترهایی با دسترس‌پذیری بالا راه‌اندازی کنند و از قابلیت‌های مقیاس‌پذیری Kubernetes بهره‌مند شوند.

این ابزار تمام CNI کوبر را پشتیبانی می کنه .
فرض کنید شما قبلا با این ابزار کوبرنتیس خودتان را پیاده سازی نکردید . خوب مشکلی نیست . (برای مثال : شما با rancher استفاده کردید ) . این ابزار پشتیبانی میکنه .
باید بگم Kubekey همان Kuberspary است ، از Kubeadm برای استقرار خوشه ها استفاده می کند.
و Kubekey مبتنی بر Go و ansible هست .بنابراین نیازی به تکیه بر برخی از نرم افزارهای اساسی مانند Python Ansible نیست. همچنین این ساختار باعث می شود سرعت نصب Kubekey سریعتر باشد ، که برای نصب خوشه ای در محیط آفلاین مفید است.

اما ویژگی دیگش : میتونید بصورت air-gap هم نصب کنید .
همچنین Kubekey از افزونه ها برای سفارشی سازی ها هنگام نصب کلاستر ها پشتیبانی می کند.
ویژگی قشنگترش اینه که کنسول تحت وب هم داره .
این ابزار ساختار manifestو artifact داره .

./kk artifact export -m manifest-sample.yaml

در واقع در یک محیط آفلاین ، شما با KK برای ساخت config-sample.yaml استفاده میکنید
در یک محیط آفلاین ، هنگام استفاده از دستورات خوشه ای و ارتقاء خوشه ، image ها به طور پیش فرض به رجیستری خصوصی منتقل می شود. اگر رجیستری خصوصی به اطلاعات احراز هویت نیاز دارد ، می توانید آن را در قسمت .spec.registry.auths در پرونده config-sample.yaml پیکربندی کنیم

نکته بعدی : ریجستری ساختن تو kubekey هم دنیایی هست . میتونید ریجستری بسازید . یا artifact هاش را به ریجستری که دوست دارید ارسال کنید : برای مثال :

./kk init registry -f config-sample.yaml -a kubekey-artifact.tar.gz

برای push :

./kk artifact image push -f config-sample.yaml -a kubekey-artifact.tar.gz

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


#kubekey #k8s #kubernetes


https://t.iss.one/unixmens

با مفهوم pod و deployment و تفاوت های آن آشنا شویم :

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

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

یک توسعه‌دهنده یا مدیر پروژه یا دواپس مجموعه‌ای از پادهای لازم برای اجرای یک اپلیکیشن را در کوبرنیتز طراحی می‌کند. سرویس کوبرنتیز نیز به واسطه توانایی در مدیریت داده‌ها می‌تواند این اطلاعات گوناگون در پادهای مختلف را مدیریت کند
دیپلویمنت در سرویس کوبرنتیز رفتار یا ویژگی‌های مدنظر درباره یک کانتینر را مشخص می‌کند. مدیران پروژه‌های مختلف از دیپلویمنت برای شخصی‌سازی و تخصصی‌کردن رفتار هر پاد در پروژه خود استفاده می‌کنند. در واقع ویژگی هایی که در deployment هست . در pod نیست !!!

در زیر به برخی از ویژگی‌ها و قابلیت‌هایی که Deployment دارد و Pod ندارد، اشاره میکنم :
1. مدیریت نسخه‌ها (Versioning)

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

2. تدریجی بودن استقرار (Rolling Updates)

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

3. خودکارسازی (Self-healing)

ا Deployment: در صورت بروز خطا در یکی از پادها، به طور خودکار آن را جایگزین می‌کند و اطمینان حاصل می‌کند که تعداد مشخصی از پادها همیشه در حال اجرا هستند.
ا Pod: خود به خود نمی‌تواند پادهای معیوب را جایگزین کند و نیاز به مدیریت دستی دارد.

4. مقیاس‌پذیری (Scaling)

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

5. مدیریت وضعیت (State Management)

ا Deployment: وضعیت فعلی و مورد انتظار پادها را پیگیری می‌کند و در صورت نیاز به طور خودکار به وضعیت مطلوب برمی‌گردد.
ا Pod: فقط وضعیت خود را نشان می‌دهد و هیچ قابلیت مدیریت وضعیت ندارد.

6. استفاده از الگوها (Templates)

ا Deployment: از الگوهای (templates) برای تعریف نحوه ایجاد پادها استفاده می‌کند، که شامل تنظیمات کانتینر، برچسب‌ها و سایر ویژگی‌ها است.
ا Pod: فقط یک نمونه از یک کانتینر را تعریف می‌کند و هیچ الگوی خاصی ندارد.


خب شیرین بود ؟؟؟؟


خب حالا ما فرضا یه pod داریم . آیا میتونیم تبدیلش کنیم به deployments ؟؟؟؟


باید گفت : بلی


مراحل تبدیل Pod به Deployment

دریافت تنظیمات Pod:
ابتدا باید تنظیمات Pod فعلی خود را دریافت کنید. می‌توانید از دستور زیر استفاده کنید:




kubectl get pod <pod-name> -o yaml > pod.yaml


این دستور تنظیمات Pod را در یک فایل به نام pod.yaml ذخیره می‌کند.

فایل pod.yaml را باز کنید و تغییرات اعمال کنید:

تغییر نوع منبع: در بالای فایل، kind: Pod را به kind: Deployment تغییر دهید.
اضافه کردن metadata: یک بخش spec جدید اضافه کنید که شامل تعداد تکرارها (replicas) و الگوی (template) Pod باشد.
تنظیمات selector: یک بخش selector اضافه کنید که برچسب‌های Pod را مشخص کند.

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
         ...

در ادامه

kubectl apply -f deployment.yaml

نکته : اگر دیگر به Pod قدیمی نیاز ندارید، می‌توانید آن را حذف کنید

    kubectl delete pod <pod-name>

نکات :

تعداد تکرارها: در بخش replicas می‌توانید تعداد پادهایی که می‌خواهید در حال اجرا باشند را مشخص کنید.
برچسب‌ها: اطمینان حاصل کنید که برچسب‌ها در بخش selector و template یکسان باشند تا Deployment بتواند پادها را به درستی مدیریت کند.

با این مراحل، شما می‌توانید یک Pod را به یک Deployment تبدیل کنید و از قابلیت‌های بیشتر Deployment در کوبرنتیز بهره‌مند شوید.
#kubernetes #k8s #tips

https://t.iss.one/unixmens

KubeVirt is an innovative tool designed to manage the lifecycle and scheduling of Virtual Machines (VMs) within Kubernetes clusters. It aims to bridge the gap between traditional virtualization and modern container orchestration, allowing for a hybrid environment where both VMs and containers can coexist. Here’s a detailed overview of KubeVirt, its comparisons with other projects, and its use cases.
Overview of KubeVirt
KubeVirt extends Kubernetes by enabling it to manage VMs alongside containerized applications. This integration allows organizations to leverage Kubernetes' orchestration capabilities for both types of workloads, providing a unified platform for managing resources in a datacenter or cloud environment.
KubeVirt vs. Other Projects
Kubernetes:
Kubernetes is primarily focused on automating the deployment and management of containerized applications.
KubeVirt acts as an add-on to Kubernetes, enabling it to manage VMs, thus enhancing Kubernetes' capabilities.
OpenStack:
OpenStack is a comprehensive IaaS platform that includes various components for compute, networking, and storage.
KubeVirt is a single component that specializes in VM scheduling and lifecycle management, relying on other systems for networking and storage.
Nova:
Nova is the VM scheduling component of OpenStack, supporting multiple virtualization technologies.
KubeVirt focuses specifically on KVM managed by Libvirt, allowing for a more streamlined and efficient management of VMs.
oVirt:
oVirt is a virtualization management platform that emphasizes high availability and infrastructure-level guarantees.
KubeVirt aims to provide similar consistency guarantees while also offering the scalability needed for cloud environments.
Libvirt:
Libvirt is a toolkit for managing VMs on a local node, providing lifecycle management and network/storage interface management.
KubeVirt utilizes Libvirt for managing KVM VMs, leveraging its existing capabilities rather than reinventing the wheel.
AWS EC2 and Google GCE:
Both EC2 and GCE are proprietary cloud services that lock users into specific pricing models and infrastructures.
KubeVirt is an open-source project that focuses solely on VM scheduling, providing flexibility and independence from specific cloud providers.
Use Cases
KubeVirt is designed to address several key use cases:
Cloud Virtualization:
It provides a feature set for managing VM scale-out, similar to the abstractions offered by cloud IaaS APIs.
Datacenter Virtualization:
KubeVirt aims to deliver strong infrastructure consistency guarantees, making it suitable for managing large numbers of VMs.
Kubernetes Trusted Workloads:
It allows for the execution of virtualized workloads that require the security guarantees provided by a hypervisor.
Combining Container and Virtualized Workloads:
KubeVirt enables the scheduling of both containerized and virtualized workloads on the same Kubernetes cluster, facilitating a more integrated approach to resource management.
Conclusion
KubeVirt is positioned as a powerful tool for organizations looking to manage VMs within a Kubernetes environment. By focusing on KVM and leveraging existing technologies like Libvirt, KubeVirt aims to provide a robust solution for both cloud and datacenter virtualization, while also supporting the coexistence of containerized applications. Its open-source nature and flexibility make it an attractive option for IaaS providers and enterprises alike.


#ovirt #kubevirt #linux #k8s #kubernetes #lcm #virtualization


https://t.iss.one/unixmens

KubeVirt is an innovative tool designed to manage the lifecycle and scheduling of Virtual Machines (VMs) within Kubernetes clusters. It aims to bridge the gap between traditional virtualization and modern container orchestration, allowing for a hybrid environment where both VMs and containers can coexist. Here’s a detailed overview of KubeVirt, its comparisons with other projects, and its use cases.
Overview of KubeVirt
KubeVirt extends Kubernetes by enabling it to manage VMs alongside containerized applications. This integration allows organizations to leverage Kubernetes' orchestration capabilities for both types of workloads, providing a unified platform for managing resources in a datacenter or cloud environment.
KubeVirt vs. Other Projects
Kubernetes:
Kubernetes is primarily focused on automating the deployment and management of containerized applications.
KubeVirt acts as an add-on to Kubernetes, enabling it to manage VMs, thus enhancing Kubernetes' capabilities.
OpenStack:
OpenStack is a comprehensive IaaS platform that includes various components for compute, networking, and storage.
KubeVirt is a single component that specializes in VM scheduling and lifecycle management, relying on other systems for networking and storage.
Nova:
Nova is the VM scheduling component of OpenStack, supporting multiple virtualization technologies.
KubeVirt focuses specifically on KVM managed by Libvirt, allowing for a more streamlined and efficient management of VMs.
oVirt:
oVirt is a virtualization management platform that emphasizes high availability and infrastructure-level guarantees.
KubeVirt aims to provide similar consistency guarantees while also offering the scalability needed for cloud environments.
Libvirt:
Libvirt is a toolkit for managing VMs on a local node, providing lifecycle management and network/storage interface management.
KubeVirt utilizes Libvirt for managing KVM VMs, leveraging its existing capabilities rather than reinventing the wheel.
AWS EC2 and Google GCE:
Both EC2 and GCE are proprietary cloud services that lock users into specific pricing models and infrastructures.
KubeVirt is an open-source project that focuses solely on VM scheduling, providing flexibility and independence from specific cloud providers.
Use Cases
KubeVirt is designed to address several key use cases:
Cloud Virtualization:
It provides a feature set for managing VM scale-out, similar to the abstractions offered by cloud IaaS APIs.
Datacenter Virtualization:
KubeVirt aims to deliver strong infrastructure consistency guarantees, making it suitable for managing large numbers of VMs.
Kubernetes Trusted Workloads:
It allows for the execution of virtualized workloads that require the security guarantees provided by a hypervisor.
Combining Container and Virtualized Workloads:
KubeVirt enables the scheduling of both containerized and virtualized workloads on the same Kubernetes cluster, facilitating a more integrated approach to resource management.
Conclusion
KubeVirt is positioned as a powerful tool for organizations looking to manage VMs within a Kubernetes environment. By focusing on KVM and leveraging existing technologies like Libvirt, KubeVirt aims to provide a robust solution for both cloud and datacenter virtualization, while also supporting the coexistence of containerized applications. Its open-source nature and flexibility make it an attractive option for IaaS providers and enterprises alike.


#kubevirt #linux #k8s #kubernetes #vm #virtualization

https://t.iss.one/unixmens

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

کتاب مرجع Devops
نویسنده : مهندس یاشار اسمعیل دخت

#devops #book #yashar_esmaildokht #linux #k8s #kubernetes #cloud #team #technology

https://t.iss.one/unixmens

Security #Observability with #eBPF

#linux #cilium #kubernetes #k8s #security
https://t.iss.one/unixmens

وقتی qemu/kvm پادشاه است 😍🫵😊☁️


Red Hat Virtualization (RHV)

Stack:

RHV-M Console/CLI

vdsm

libvirt

QEMU/KVM

VM


Host type: RHV Host

Notes: Uses vdsm (Virtual Desktop and Server Manager) to manage libvirt and VMs.


2. OpenShift Virtualization

Stack:

OpenShift Console/CLI

kubelet

libvirt

QEMU/KVM

KubeVirt Container


Host type: RHEL CoreOS Host

Notes: Virtualization runs inside containers with KubeVirt, allowing VMs to run alongside containers in OpenShift.

3. Red Hat OpenStack Platform (OSP)

Stack:

OpenStack Horizon/CLI

nova-compute

libvirt

QEMU/KVM

VM


Host type: OSP Compute

Notes: Uses nova-compute to manage VM lifecycle under OpenStack.

Key Takeaways

All three rely on QEMU/KVM + libvirt as the virtualization foundation.

RHV and OSP focus on VM-centric infrastructure.

OpenShift Virtualization integrates VMs into a container-native platform (via KubeVirt).


#qemu #kvm #redhat #linux #virtualization
#sddc #cloud #kubernetes
@unixmens

ا. GitLab Kubernetes Agent چیست؟

ا. GitLab Kubernetes Agent یک کامپوننت نرم‌افزاری است که داخل کلاستر Kubernetes نصب می‌شود و به صورت دوطرفه (bi-directional) با GitLab ارتباط برقرار می‌کند.
برخلاف روش قدیمی (integration با استفاده از kubeconfig یا API مستقیم)، این Agent یک کانال ارتباطی امن و پایدار بین GitLab و کلاستر ایجاد می‌کند

وظایف و قابلیت‌های اصلی

1. ارتباط امن و پایدار با کلاستر

بجای اینکه GitLab از بیرون به API کلاستر دسترسی داشته باشد (که خطرناک است)، Agent در داخل کلاستر اجرا شده و خودش ارتباط امن (TLS + gRPC) را با GitLab برقرار می‌کند.



2. GitOps (Declarative Deployments)

ا. Agent می‌تواند تغییرات تعریف‌شده در ریپازیتوری GitLab (مثل manifestها و Helm chartها) را به‌طور خودکار با وضعیت کلاستر هماهنگ کند.

یعنی وقتی شما کدی را commit کنید که شامل تغییر در Kubernetes manifests باشد، Agent این تغییرات را به کلاستر اعمال می‌کند.



3. CI/CD Integration

امکان اجرای jobهای CI/CD که نیاز به ارتباط با کلاستر دارند (مثل deploy، تست E2E، security scans).

دسترسی به کلاستر بدون نیاز به اشتراک‌گذاری kubeconfig در pipeline.



4. Cluster Observability

ا. Agent اطلاعات وضعیت کلاستر (nodes, pods, workloads) را به GitLab گزارش می‌دهد.

این کار امکان monitoring و visualization مستقیم از داخل GitLab UI را فراهم می‌کند.



5. Multi-cluster Management

با یک GitLab می‌توان چندین کلاستر را مدیریت کرد (Dev, Staging, Prod).

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



6. Policy Enforcement و Security

می‌توان policyهایی تعریف کرد (مثلاً فقط برخی namespaceها یا resourceها قابل دسترسی باشند).

این باعث می‌شود امنیت نسبت به روش قدیمی kubeconfig خیلی بالاتر باشد.

مشکلات روش kubeconfig قدیمی نسبت به GitLab Kubernetes Agent

امنیت :
نیاز به ذخیره kubeconfig در GitLab (ریسک نشت) ارتباط gRPC امن از داخل کلاستر
ا. GitOps محدود : پشتیبانی کامل (Pull-based deployment)
مقیاس‌پذیری سخت : (برای چندین کلاستر) اما در اجنت ساده تر است . (هر کلاستر Agent خودش را دارد)
ا Observability محدود : اما در اجنت یکپارچه با GitLab UI
مدیریت Policy دستی و پشتیبانی داخلی

#devops #gitlab #kubernetes #k8s #grpc #security #linux #cluster

https://t.iss.one/unixmens

رشد سریع دیتاسنترهای ابری، شبکه‌های 5G و سرویس‌های Cloud-native، نیاز به پردازش پرسرعت بسته‌های شبکه بیش از هر زمان دیگری اهمیت پیدا کرده است. روش سنتی مبتنی بر Kernel Networking Stack به دلیل overhead بالا، پاسخگوی نیازهای امروزی نیست.

برای رفع این مشکل دو رویکرد اصلی مطرح شده‌اند:

ا DPDK (Data Plane Development Kit): رویکرد Kernel bypass در User Space

ا eBPF/XDP (extended Berkeley Packet Filter): پردازش انعطاف‌پذیر در Kernel Space
اینجا به بررسی هر یک میپردازیم :

معماری و فلسفه طراحیeBPF

ا eBPF یک مکانیزم درون‌هسته‌ای (in-kernel) است که به برنامه‌ها اجازه می‌دهد کدهای کوچک و امن را در کرنل لینوکس اجرا کنند. فلسفه اصلی آن انعطاف‌پذیری و قابلیت مشاهده (observability) است. eBPF به کاربران اجازه می‌دهد بدون تغییر در کرنل، منطق دلخواه خود را در سطح شبکه، امنیت و مانیتورینگ اضافه کنند. برنامه‌های eBPF در محیطی ایزوله (sandbox) اجرا می‌شوند و توسط verifier کرنل اعتبارسنجی می‌شوند تا مانع ایجاد مشکلات پایداری شوند.



ا DPDK یک مجموعه کتابخانه و درایور است که هدف اصلی آن حداکثرسازی سرعت پردازش بسته‌ها در فضای کاربر (user space) است. فلسفه آن مبتنی بر دور زدن کرنل و حذف لایه‌های سربار مانند socket و interrupt است. DPDK با استفاده از تکنیک‌هایی مانند polling و zero-copy، پردازش بسته‌ها را به شکل مستقیم از NIC (کارت شبکه) به فضای کاربر منتقل می‌کند.

عملکرد و کارایی

ا eBPF بیشتر بر روی انعطاف‌پذیری و قابلیت برنامه‌ریزی تمرکز دارد. این یعنی می‌توان بدون نوشتن ماژول کرنل، سیاست‌های پیچیده فایروال، ردیابی جریان‌ها و ابزارهای observability مانند bcc یا Cilium را ساخت. از نظر کارایی، سرعت آن مناسب است اما به دلیل وجود در کرنل، همچنان محدودیت‌هایی دارد.

ا DPDK برای عملکرد خام (raw performance) طراحی شده است. در سیستم‌هایی که نیاز به میلیون‌ها بسته در ثانیه (Mpps) وجود دارد، DPDK انتخاب بهتری است. اما این سرعت با مصرف بالاتر منابع CPU و پیچیدگی بیشتر توسعه همراه است.

سطح پیاده‌سازی و توسعه

ا eBPF توسعه‌دهندگان را قادر می‌سازد با استفاده از زبان C یا LLVM-based زبان‌ها، کدهای کوچک و قابل بررسی تولید کنند. توسعه آن ساده‌تر است زیرا مستقیماً با کرنل لینوکس ادغام شده و نیاز به مدیریت مستقیم منابع سخت‌افزاری ندارد.

ا DPDK توسعه‌دهنده را ملزم می‌کند که با سطح پایین‌تری از سخت‌افزار و پردازش بسته‌ها کار کند. برنامه‌نویسی با DPDK نیازمند درک عمیق از معماری CPU، حافظه و NIC است.

کاربردها eBPF

ساخت فایروال‌های مدرن مانند Cilium در Kubernetes.

مانیتورینگ شبکه، سیستم و عملکرد برنامه‌ها (مانند bpftrace).

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

ابزارهای observability برای Cloud-native environments.

DPDK

ساخت سیستم‌های SDN و NFV با کارایی بالا.

استفاده در فایروال‌ها، load balancerها و IDS/IPS با نیاز به throughput بسیار بالا.

محیط‌هایی که latency و jitter باید حداقل باشد، مانند مخابرات و 5G core.

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

مزایا و محدودیت‌ها

ا eBPF مزایای بزرگی مانند سادگی توسعه، امنیت، قابلیت ترکیب با ابزارهای موجود لینوکس و عدم نیاز به bypass کرنل دارد. محدودیت اصلی آن، کارایی پایین‌تر نسبت به DPDK در بارهای بسیار سنگین است.

ا DPDK در کارایی بی‌نظیر است اما توسعه پیچیده‌تر، نیاز به منابع CPU بالا، و مدیریت دشوارتر دارد. همچنین برخلاف eBPF، tightly coupled با کرنل نیست و قابلیت observability گسترده ارائه نمی‌دهد.


مکمل بودن

ا eBPF و DPDK الزاماً رقیب مستقیم نیستند. در بسیاری از معماری‌های مدرن، این دو مکمل هم هستند:

ا eBPF: برای مشاهده‌پذیری (observability)، مانیتورینگ، امنیت و کنترل.

ا DPDK: برای دیتاپلین پرسرعت و پردازش سنگین بسته‌ها


#linux #kernel #devops #kubernetes #ebpf #dpdk


https://t.iss.one/unixmens

ابزار Kubernetes و چالش‌های آن: چرا ترکیب OpenShift/KubeSphere با KubeVirt بهترین گزینه برای سازمان‌هاست؟

مقدمه

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

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

چرا Kubernetes چالش‌برانگیز است؟

پیچیدگی عملیاتی: نصب، مدیریت و نگهداری Kubernetes حتی برای تیم‌های حرفه‌ای آسان نیست.

نیاز به مهارت بالا: تیم‌ها باید دانش عمیق در مفاهیم Networking، Storage، Security و CI/CD داشته باشند.

چالش‌های امنیتی: به‌صورت پیش‌فرض امنیت Kubernetes در سطح Enterprise کافی نیست.

مدیریت چندخوشه‌ای (Multi-Cluster): برای سازمان‌های بزرگ به یک کابوس مدیریتی تبدیل می‌شود.

هزینه آموزش و یادگیری: ورود تیم‌های جدید زمان‌بر و پرهزینه است

چرا گوگل هنوز Borg و Omega را ترجیح می‌دهد؟

مقیاس‌پذیری فراتر از Kubernetes: در دیتاسنترهای گوگل که میلیون‌ها کانتینر اجرا می‌شود، Borg و Omega بهینه‌تر هستند.

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

کاستومایز اختصاصی: Borg و Omega کاملاً بر اساس نیازهای خاص گوگل طراحی شده‌اند، در حالی که Kubernetes یک پلتفرم عمومی برای جامعه جهانی است.

راه‌حل سازمان‌ها: OpenShift و KubeSphere

برای بیشتر سازمان‌ها، استفاده مستقیم از Kubernetes بدون ابزارهای تکمیلی منجر به مشکلات جدی می‌شود. اینجا است که OpenShift و KubeSphere وارد میدان می‌شوند:

OpenShift (Red Hat):

امنیت سازمانی قوی (SELinux، RBAC پیشرفته).

تجربه توسعه‌دهنده کامل (داشبورد، CI/CD داخلی).

پشتیبانی رسمی و Enterprise از سوی Red Hat/IBM.


KubeSphere:

نصب ساده و رابط کاربری کاربرپسند.

مدیریت چند خوشه‌ای (Multi-Cluster) با قابلیت‌های گسترده.

ماژول‌های آماده برای DevOps، نظارت، و Service Mesh.

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

نقش KubeVirt: اتصال VMها و Containerها

یکی از مشکلات رایج سازمان‌ها این است که هنوز بارهای کاری Legacy (روی VMها) دارند.
با KubeVirt:

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

مهاجرت تدریجی از VM به Container بدون نیاز به دو پلتفرم جداگانه امکان‌پذیر می‌شود.

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


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

راه‌حل درست برای ورود به دنیای Cloud-Native در سطح سازمانی، استفاده از پلتفرم‌های تکمیلی مثل OpenShift یا KubeSphere و ترکیب آن‌ها با KubeVirt است. این ترکیب نه‌تنها مشکلات پیچیدگی و امنیت را کاهش می‌دهد، بلکه امکان همگرایی کامل میان بارهای کاری سنتی (VM) و مدرن (Container) را فراهم می‌کند.
#kubernetes #devops #clustering #k8s #linux #security #google #borg #omega
https://t.iss.one/unixmens