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

همه فکر می‌کنن Auto Scaling فقط مخصوص Kubernetes هست،
اما در واقع میشه با استفاده از Docker Swarm Cluster و ابزارهای جانبی،
یک سیستم خودکارِ مقیاس‌پذیری (Auto Scaling) قدرتمند و هوشمند پیاده‌سازی کرد.

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

#DevOps #Kubernetes #Docker #Swarm #AutoScaling

با pdb آشنا شویم :

در واقع Pod Disruption Budget (PDB) سیاستی است که مشخص می‌کند حداکثر چه تعداد پاد از یک برنامه می‌تواند به‌صورت هم‌زمان از کار بیفتد یا حذف شود — در زمان اتفاقات اختیاری (voluntary disruptions) مثل:

ارتقای نودها (Node upgrade)

و drain کردن نودها (مثلاً برای maintenance)

حذف دستی پادها توسط ادمین‌ها


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


دو نوع پارامتر اصلی در PDB

در فایل YAML مربوط به PDB، دو فیلد کلیدی برای تعریف بودجه در دسترس داریم:

1. minAvailable
یعنی حداقل چند پاد باید همیشه در حال اجرا باشند.
مثال:

minAvailable: 2

اگر برنامه شما 3 پاد دارد، این مقدار یعنی حداکثر 1 پاد را می‌توان هم‌زمان از کار انداخت.


2. maxUnavailable
یعنی حداکثر چند پاد می‌توانند هم‌زمان از کار بیفتند.
مثال:

maxUnavailable: 1

یعنی در هر لحظه، فقط 1 پاد می‌تواند غیرفعال باشد.



نمی‌توان هم‌زمان هر دو مقدار را در یک PDB تعریف کرد. یکی از آن‌ها باید انتخاب شود

نمونه فایل YAML

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: webapp-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: webapp

این مثال می‌گوید:

برای پادهایی که label آن‌ها app=webapp است،

همیشه حداقل ۲ پاد باید running باشند.

اگر deployment شما ۳ replica دارد، فقط یکی از آن‌ها را می‌توان در زمان upgrade یا drain از کار انداخت.

انواع اختلال (Disruptions)

نوع اختلال توضیح تحت کنترل PDB؟

در واقع Voluntary (اختیاری) کارهایی مثل drain node، upgrade cluster، delete pod دستی کاربردی است
و Involuntary (غیر اختیاری) crash نود، kernel panic، خطای سخت‌افزاری معنا ندارد


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

رفتار در سناریوهای واقعی

فرض کنید یک Deployment با 3 پاد دارید و یک PDB با minAvailable: 2.
اگر نودها را drain کنید:

همچنین #Kubernetes بررسی می‌کند که با حذف هر پاد، هنوز ۲ پاد فعال باقی می‌مانند یا نه.

اگر نه، عملیات drain تا زمان جایگزینی پاد جدید به تعویق می‌افتد.

ابزارها و مشاهده وضعیت PDB

برای دیدن لیست PDBها:

kubectl get pdb

برای دیدن جزئیات هر PDB:

kubectl describe pdb <pdb-name>

نکات فنی و توصیه‌ها

همیشه برای Deploymentها یا StatefulSet‌های حیاتی (مثل frontend، API یا database replicas) PDB تعریف کنید
اگر replica فقط ۱ عدد است، تعریف PDB ممکن است باعث شود upgrade یا drain متوقف شود.
در سرویس‌های stateless معمولاً maxUnavailable بهتر است، و در سرویس‌های stateful minAvailable.
ابزارهایی مثل Cluster Autoscaler یا Kured (برای reboot خودکار نودها) با PDB کار می‌کنند.


#pdb #k8s #linux
https://t.iss.one/unixmens