با مفهوم 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

چرا 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

ا. 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

When we say Linux knowledge is very important, the reasons are both technical and strategic. This importance can be explained in a few layers:

The basic infrastructure of the IT and Cloud world :

More than 90% of large Internet services (from Google and Facebook to Amazon and Netflix) run on Linux.

The dominant operating system is in public schools such as AWS, GCP and Azure Linux.

Most important databases (MySQL, postgresql, mongodb, oracle DB works better on Linux)

Security and control :

Linux is the open source (Open Source); That is, it has transparency in the code and the security audit capability.

Low -level security tools and hardness (such as Selinux, Apparmor, iPTables, Nftables ,cgroup , namespace) are more powerful in Linux.

A specialist who knows Linux can take full control of the system, not just superficial use.

Devops and Automation :


Almost all Devops (ANSIBLE, TERRAFORM, KUBERNETES, DOCKER, JENKINS) tools are born on Linux and have the best performance on Linux.

Scripting with Bash and combining it with Linux tools (Sed, AWK, GREP, etc.) is the main part of automation.

Network infrastructure and internet :

Vital Internet services (DNS, Web, Mail, Proxy, VPN) have been developed on the Linux platform.

For a network or security specialist, Linux knowledge means direct management of infrastructure service

Stability and scalability :

Linux is a scalable and stable operating system; From mobile (Android) to supercamapiers.

The world's top 5 superpowers work on Linux.

Engineering :

Linux teaches the user how the system works, not just how to use it.

This makes the person upgraded from the "simple user" to the "engineer and architect"
🔑 :
Linux knowledge is important because the cornerstone of the modern digital world, security, and organizational transformation is based on Linux.


#linux #devops #k8s #clustering #kernel

ابزار 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

با 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

"همیشه decentralize قلب تپنده است"
در واقع، تمرکززدایی (Decentralization) جوهره‌ی پایداری و انعطاف‌پذیری سیستم‌های امروزیه. هرچه سیستم از یک نقطه‌ی مرکزی مستقل‌تر باشه، تاب‌آورتر و مقیاس‌پذیرتر می‌شه. این مفهوم در DevOps، Cloud و حتی در فلسفه‌ی جامعه‌شناسی دیجیتال هم معنا داره:
وابستگی = آسیب‌پذیری.

"وابستگی به یک ساختار اشتباه است"
در معماری نرم‌افزار، وابستگی زیاد به یک زیرساخت، یک پلتفرم یا حتی یک تیم، باعث می‌شه سیستم نتونه با تغییرات محیطی سازگار بشه. اگه یه سرویس یا گره از کار بیفته، کل ساختار دچار اختلال می‌شه.
برای همین فلسفه‌ی microservices و distributed systems بر اساس low coupling و high cohesion بنا شده.
🔹 "بهتر است سرویس‌های حیاتی به‌صورت مجزا و مستقل استقرار پیدا کنند"
این همون اصل fault isolation و resiliency design هست.
با جداسازی سرویس‌های حیاتی در nodeها یا namespaceهای جدا، خطر propagation خطا کاهش پیدا می‌کنه. Kubernetes با مفاهیمی مثل Namespace, Deployment, StatefulSet, PDB و NetworkPolicy دقیقاً برای چنین سناریوهایی طراحی شده.
"فلسفه k8s روی app هست و deployment"
دقیقاً. Kubernetes نه برای مدیریت سرورها بلکه برای مدیریت چرخه‌ی حیات اپلیکیشن‌ها طراحی شده.
یعنی: تمرکز از زیرساخت به اپلیکیشن به‌عنوان واحد اصلی عملیات (Application-Centric) منتقل شده.
در اینجا مفاهیمی مثل:

Auto Scaling → پاسخ به تغییر بار به‌صورت پویا

Rollback / Rollout → برگشت سریع در صورت خطا

Canary / Blue-Green / A/B Deployment → پیاده‌سازی تدریجی و کنترل‌شده‌ی تغییرات
در واقع ابزارهایی هستند برای تحقق فلسفه‌ی resiliency و zero-downtime deployment

اگر بخوام در یک جمله خلاصه کنم:

کوبر تبلور فلسفه‌ی عدم وابستگی، تمرکز بر اپلیکیشن، و طراحی برای تغییر است

#devops #k8s
https://t.iss.one/unixmens

Security #Observability with #eBPF

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

چرا سازمان‌های بزرگ و بین‌المللی Kubernetes را اولویت اول نمی‌دانند؟


https://t.iss.one/unixmens

#linux #devops #k8s #organization #monitoring #ci #cd