🔵 عنوان مقاله
Kubernetes RBAC authorizing HTTP proxy

🟢 خلاصه مقاله:
** این مقاله الگوی یک HTTP proxy را توضیح می‌دهد که برای مجازسازی درخواست‌ها به RBAC در Kubernetes تکیه می‌کند. پراکسی هویت کاربر را با TokenReview یا OIDC تأیید می‌کند، سپس با ارسال SubjectAccessReview به API سرور می‌پرسد آیا کاربر برای عمل متناظر با مسیر و متد HTTP مجاز است یا نه. در صورت تأیید، درخواست به سرویس مقصد هدایت می‌شود و هدرهای هویتی امن تزریق می‌گردد؛ در غیر این صورت، پاسخ 403 برمی‌گردد. این راهکار می‌تواند به‌صورت sidecar، به‌عنوان یک Deployment مستقل، یا از طریق external auth در Ingressهایی مانند NGINX/Envoy پیاده‌سازی شود. برای کارایی بهتر، کش نتایج SAR با TTL کوتاه، همگام‌سازی با تغییرات RBAC، و fail-closed توصیه می‌شود. از نظر امنیتی باید مرز اعتماد روشن باشد: هدرهای هویتی کلاینت حذف/بازنویسی شوند، ارتباطات TLS/mTLS باشد، و دسترسی ServiceAccount پراکسی حداقلی بماند. این الگو به‌ویژه برای داشبوردها و سرویس‌های چندمستاجری مفید است و از سیاست‌های آشنای RBAC برای کنترل یکنواخت و قابل ممیزی استفاده می‌کند.

#Kubernetes #RBAC #HTTPProxy #Ingress #Envoy #NGINX #CloudSecurity #ZeroTrust

🟣لینک مقاله:
https://ku.bz/pQqpkgLM7

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Kubernetes Logs Unavailable Behind a Proxy: Diagnosing API Server Communication Issues

🟢 خلاصه مقاله:
اگر محیط شما پشت یک HTTP proxy قرار دارد، ممکن است برخی دستورات kubectl مثل kubectl logs، kubectl exec و port-forward شکست بخورند، در حالی‌که kubectl get یا describe کار می‌کنند. دلیل رایج این مشکل تنظیم‌نشدن NO_PROXY برای آدرس‌ها و دامنه‌های داخلی کلاستر است؛ در نتیجه، ترافیک داخلی به‌اشتباه از proxy عبور می‌کند و اتصال‌های upgrade/stream (مثل SPDY/WebSocket) می‌شکنند. نشانه‌ها شامل خطاهایی مانند EOF یا context deadline exceeded است. برای رفع مشکل، NO_PROXY/no_proxy را با مواردی مانند localhost، 127.0.0.1، نام و IP مربوط به API server، دامنه‌های .cluster.local و .svc، و بازه‌های IP داخلی (مثلاً 10.0.0.0/8) تنظیم کنید. به حروف بزرگ/کوچک متغیرها دقت کنید و در سیستم‌عامل‌های مختلف مطابق دستورالعمل همان محیط آن‌ها را ست کنید. پس از به‌روزرسانی NO_PROXY، عملیات‌های stream مثل kubectl logs و exec معمولاً بدون مشکل انجام می‌شوند.

#Kubernetes #kubectl #Proxy #Networking #NO_PROXY #Troubleshooting #DevOps #HTTP

🟣لینک مقاله:
https://ku.bz/jCJf115lB

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
MariaDB operator

🟢 خلاصه مقاله:
مدیریت MariaDB با رویکرد declarative در Kubernetes ممکن است؛ MariaDB operator با استفاده از CRDs به‌جای فرمان‌های دستی، استقرار و پیکربندی را از طریق مانيفست‌های YAML و جریان‌های GitOps خودکار می‌کند. این ابزار وظایفی مانند ایجاد و به‌روزرسانی نمونه‌ها یا کلاسترها، مدیریت کاربر و تنظیمات، اتصال Secrets و Storage، مقیاس‌پذیری، به‌روزرسانی‌های مرحله‌ای، پشتیبان‌گیری/بازگردانی و حتی failover را در چرخه عمر دیتابیس هماهنگ می‌کند. نتیجه، کاهش خطای انسانی و سربار عملیاتی، یکپارچگی با اکوسیستم Cloud-Native و تداوم وضعیت پایدار در محیط‌های مختلف است. جزئیات CRDها و نمونه‌ها در github.com/mariadb-operator در دسترس است.

#MariaDB #Kubernetes #Operator #CRD #GitOps #CloudNative #DatabaseAutomation #DevOps

🟣لینک مقاله:
https://ku.bz/s6l43vX8s

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Cost-optimized ml on production: autoscaling GPU nodes on Kubernetes to zero using keda

🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با استفاده از Kubernetes و KEDA ظرفیت GPU را بر اساس طول صف پیام‌ها به‌صورت خودکار تا صفر کاهش دهیم و هزینه اجرای ML در محیط تولید را کم کنیم. معماری مبتنی بر یک message queue (مثل Kafka، RabbitMQ یا AWS SQS) است و KEDA با ScaledObject تعداد پادهای مصرف‌کننده GPU را نسبت به backlog تنظیم می‌کند (minReplicaCount=0). با فعال‌بودن Cluster Autoscaler و یک GPU node pool با حداقل اندازه صفر، نودهای GPU فقط هنگام نیاز ایجاد و سپس آزاد می‌شوند. نکات کلیدی شامل تنظیم nodeSelector/tolerations، درخواست nvidia.com/gpu، کنترل pollingInterval/cooldownPeriod، کاهش cold start با pre-pull و پایش با Prometheus/Grafana است. نتیجه: پرداخت هزینه GPU فقط هنگام وجود کار، همراه با حفظ قابلیت اطمینان و کنترل تأخیر.

#Kubernetes #KEDA #GPU #MLOps #Autoscaling #CostOptimization #MessageQueue #ProductionML

🟣لینک مقاله:
https://ku.bz/Zhb9q3BZx

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Kube Composer – Visual Kubernetes YAML Builder

🟢 خلاصه مقاله:
**Kube Composer یک ابزار بصری برای ساخت و مدیریت فایل‌های YAML در Kubernetes است که نوشتن و نگهداری مانیفست‌ها را ساده‌تر و کم‌خطاتر می‌کند. با فرم‌های راهنما و اعتبارسنجی لحظه‌ای بر اساس شِماهای Kubernetes، می‌توان منابع رایج مثل Deployment، Service، Ingress، ConfigMap، Secret و RBAC را دقیق و سریع پیکربندی کرد. این ابزار امکان وارد کردن YAMLهای موجود برای ویرایش و بصری‌سازی و همچنین خروجی گرفتن YAMLهای تمیز و قابل استفاده در Git، GitOps و CI/CD را فراهم می‌کند. با الگوها و تنظیمات از پیش‌ساخته برای محیط‌های مختلف، Kube Composer سرعت ورود اعضای جدید تیم را بالا می‌برد، خطاها را کاهش می‌دهد و رویه‌های استاندارد را در سراسر پروژه‌ها یکپارچه می‌کند.

#KubeComposer #Kubernetes #YAML #DevOps #CloudNative #K8s #PlatformEngineering #ConfigurationManagement

🟣لینک مقاله:
https://ku.bz/-5NWYJX7c

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Kubetail

🟢 خلاصه مقاله:
Kubetail یک اسکریپت bash سبک است که لاگ‌های چندین pod را در Kubernetes به‌صورت هم‌زمان و در یک جریان واحد نمایش می‌دهد؛ یعنی همان کاری که kubectl logs -f انجام می‌دهد، اما برای چند pod به‌طور یکجا. این ابزار فقط روی کلاینت اجرا می‌شود و چیزی داخل کلاستر نصب نمی‌کند، بنابراین با kubeconfig و دسترسی‌های فعلی شما کار می‌کند.

با اشاره به الگوهای نام، برچسب‌ها یا namespace، می‌توانید لاگ‌ چندین سرویس را هم‌زمان دنبال کنید و خروجی هر pod را در یک تایم‌لاین یکپارچه—معمولاً با رنگ یا تفکیک—ببینید. Kubetail برای دیباگ سریع microservices و رفع اشکال سناریوهای توزیع‌شده عالی است. البته جایگزین سیستم‌های ذخیره‌سازی و مشاهده‌پذیری بلندمدت نیست؛ هدفش ساده‌سازی و سرعت‌بخشی به tail/trace لحظه‌ای لاگ‌هاست.

#Kubetail #Kubernetes #kubectl #DevOps #Logs #Bash #Observability #SRE

🟣لینک مقاله:
https://ku.bz/9BypVmZBZ

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Under the hood: Amazon EKS Auto Mode

🟢 خلاصه مقاله:
Amazon EKS Auto Mode با خودکارسازی راه‌اندازی، مقیاس‌دهی و نگه‌داری کنترل پلین و worker nodeها، بار مدیریت زیرساخت Kubernetes را برمی‌دارد تا تیم‌ها بر توسعه محصول تمرکز کنند. در این مطلب، AWS توضیح می‌دهد این رویکرد برای بارهای کاری Kubernetes چه مزایایی دارد؛ از تأمین خودکار ظرفیت و مقیاس‌پذیری متناسب با ترافیک تا کاهش اضافه‌ظرفیت و ساده‌سازی عملیات برای سناریوهای مختلف مانند microservices و پردازش دسته‌ای. همچنین نگاهی به سازوکار درونی EKS Auto Mode ارائه می‌شود—نحوه ایجاد و نگه‌داری منابع کلاستر، تصمیم‌های مقیاس‌دهی، اعمال به‌روزرسانی‌ها و وصله‌های امنیتی با حداقل اختلال، و ادغام با قابلیت‌های شبکه، ذخیره‌سازی و observability در AWS. در پایان، به ملاحظات هزینه، بهترین‌روش‌ها و نحوه هم‌راست‌سازی با CI/CD اشاره می‌شود تا تیم‌ها با اعتماد بیشتری از این اتوماسیون استفاده کنند.

#AmazonEKS #Kubernetes #AWS #Cloud #DevOps #Containers #Autoscaling #PlatformEngineering

🟣لینک مقاله:
https://ku.bz/pdcLkB9Hn

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Smesh: Lightweight Kubernetes-Integrated Sidecar Mesh Without Proxies

🟢 خلاصه مقاله:
** Smesh یک service mesh سبک برای Kubernetes است که به‌صورت آزمایشی نشان می‌دهد می‌توان با استفاده از eBPF ترافیک pod را در سطح kernel رهگیری و با سربار کم به یک sidecar proxy هدایت کرد. ایده این است که رهگیری در kernel انجام شود تا تأخیر و مصرف CPU کاهش یابد و پیاده‌سازی ساده‌تر شود، در حالی‌که وظایف سیاست‌گذاری، مسیریابی یا مشاهده‌پذیری همچنان توسط sidecar انجام می‌شود. این پروژه فعلاً یک PoC است و برای آزمون ایده‌ها، سنجش کارایی و بحث در جامعه ارائه شده؛ جزئیات و کد در github.com/thebsdboxsmesh در دسترس است.

#Kubernetes #ServiceMesh #eBPF #Sidecar #CloudNative #Networking #K8s #OpenSource

🟣لینک مقاله:
https://ku.bz/Wx7wMJLqF

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
A Hands-on Guide to Kubernetes Observability with Whisker

🟢 خلاصه مقاله:
این لَب تعاملی نشان می‌دهد چگونه با استفاده از ابزار متن‌باز Whisker به رصدپذیری Kubernetes دست پیدا کنید تا مسائل مربوط به Network Policies را سریع پیدا و برطرف کنید. شرکت‌کنندگان با بررسی جریان ترافیک بین Pods و Services، شناسایی خطاهای پیکربندی سیاست‌های شبکه، و ردیابی ارتباط Pod‑to‑Pod می‌آموزند مشکل از کجاست و چگونه آن را اصلاح کنند. همچنین با رویه‌های عیب‌یابی شفاف و همبست‌سازی مشاهدات با مفاهیم Kubernetes (مثل Deployments، Services و NetworkPolicies)، می‌توانید اثر سیاست‌ها بر ارتباطات سرویس‌ها را بسنجید و مسیرهای مسدود یا پرخطر را تشخیص دهید. در پایان، استفاده روزمره از Whisker برای کاهش زمان عیب‌یابی و بهبود قابلیت اطمینان و امنیت کلاستر را فرامی‌گیرید.

#Kubernetes #Observability #Whisker #NetworkPolicies #Troubleshooting #OpenSource #DevOps #CloudNative

🟣لینک مقاله:
https://ku.bz/Yqn88cNMP

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Deploying a .NET Weather Forecast App to AKS Using GitHub Actions and Argo CD

🟢 خلاصه مقاله:
**این راهنما نحوه استقرار یک اپلیکیشن پیش‌بینی هوا با .NET روی AKS را با رویکرد GitOps توضیح می‌دهد: در مرحله CI، GitHub Actions تصویر کانتینر را می‌سازد، برچسب‌گذاری می‌کند و به رجیستری ارسال می‌کند؛ در مرحله CD، Argo CD مخزن Git را رصد کرده و مانیفست‌ها یا Helm chart را با کلاستر همگام و استقرار را اعمال می‌کند. ساختار مخزن شامل کد، Dockerfile و مانیفست‌های Kubernetes است؛ برای محیط‌های مختلف می‌توان از namespace، شاخه‌ها یا مسیرهای جداگانه استفاده کرد. پیکربندی‌ها و اسرار دسترسی از طریق Secrets در GitHub و Kubernetes مدیریت می‌شوند و Pull Secret رجیستری برای کلاستر تنظیم می‌شود. مزیت اصلی، جداسازی روشن CI/CD، مشاهده‌پذیری، تشخیص Drift، ردیابی تغییرات و امکان Rollback آسان است. در نهایت با هر Commit، تصویر جدید ساخته و به‌صورت خودکار توسط Argo CD روی AKS به‌روزرسانی و اجرا می‌شود.

#AKS #ArgoCD #GitHubActions #dotnet #Kubernetes #GitOps #CI/CD

🟣لینک مقاله:
https://ku.bz/yj4-3B2y-

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Cloudflare Kubernetes Gateway

🟢 خلاصه مقاله:
Cloudflare Kubernetes Gateway روشی Kubernetes-first برای مدیریت ترافیک ورودی به سرویس‌های شما ارائه می‌کند و تعریف Gateway و Route را از طریق Gateway API به پیکربندی‌های Cloudflare مانند Load Balancer، DNS و TLS تبدیل می‌کند. نتیجه، دسترسی خارجی ساده‌تر با همگرایی بین قصد اعلام‌شده در کلاستر و واقعیت لبه است.

این راهکار امنیت و کارایی را از طریق WAF، محافظت DDoS، TLS مدیریت‌شده و مسیریابی دقیق در لبه تقویت می‌کند و با شبکه Anycast جهانی Cloudflare، تاخیر را کاهش و دسترس‌پذیری را افزایش می‌دهد. از منظر عملیات، کاملا با GitOps و CI/CD همخوان است، استراتژی‌های Canary/Blue-Green و سناریوهای چند-کلاستر/چند-مستاجری را ساده می‌کند.

با سلامت‌سنجی، failover خودکار و لاگ/متریک‌های لبه و کلاستر، رصدپذیری و پایداری تقویت می‌شود. در مجموع، راهی استاندارد و امن برای مدیریت ترافیک north-south در Kubernetes است—فارغ از این‌که کلاسترها در کجا اجرا شوند.

#Cloudflare #Kubernetes #GatewayAPI #Ingress #CloudNative #DevOps #Security #Networking

🟣لینک مقاله:
https://ku.bz/xKLFSN26Q

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Kubernetes Orphaned Resources Finder

🟢 خلاصه مقاله:
** خلاصه فارسی: Kor در آدرس github.com/yonahdKor ابزاری برای کشف منابع بلااستفاده در Kubernetes است. این ابزار منابعی مانند ConfigMaps، Secrets، Services، ServiceAccounts، Deployments، Statefulsets و Roles را که دیگر استفاده نمی‌شوند شناسایی و فهرست می‌کند تا پاکسازی ایمن، کاهش هزینه و بهبود امنیت و نگه‌داری کلاستر ساده‌تر شود. Kor برای ممیزی‌ها، مهاجرت‌ها و نگه‌داری دوره‌ای مفید است و با کاهش شلوغی کلاستر، ریسک و خطاهای عملیاتی را پایین می‌آورد.

#Kubernetes #Kor #DevOps #CloudNative #ClusterCleanup #CostOptimization #Security #SRE

🟣لینک مقاله:
https://ku.bz/v0vhddycw

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Post-Quantum Cryptography in Kubernetes

🟢 خلاصه مقاله:
با توجه به ظهور رایانه‌های کوانتومی، زیرساخت‌های Kubernetes در همه لایه‌ها—از کنترل‌پلین تا ترافیک سرویس‌به‌سرویس و زنجیره تأمین—در معرض ریسک رمزنگاری کلاسیک قرار می‌گیرند. راهبرد عملی، حرکت تدریجی به‌سمت چابکی رمزنگاری و استفاده از حالت‌های هیبریدی است: به‌کارگیری الگوریتم‌های منتخب NIST مانند CRYSTALS-Kyber برای تبادل کلید و CRYSTALS-Dilithium و SPHINCS+ برای امضا، در کنار الگوریتم‌های فعلی، تا ضمن حفظ سازگاری، در برابر سناریوی «اکنون جمع‌آوری کن، بعداً رمزگشایی کن» مقاوم شوید.

در لبه و بین سرویس‌ها، می‌توان با پروکسی‌ها و کتابخانه‌های سازگار با PQC آزمایش کرد؛ برای مثال، ساخت‌های OpenSSL 3 با liboqs یا بیلدهای سفارشی که در TLS 1.3 تبادل کلید هیبریدی مانند X25519+Kyber را مذاکره می‌کنند. در Kubernetes این تغییر معمولاً روی Ingress/Egress یا دیتاپلین سرویس مش پیاده می‌شود؛ گام‌به‌گام و قابل بازگشت، با سنجش اندازه هندشیک، تأخیر و مصرف CPU. از آن‌جا که WebPKI هنوز عمدتاً امضای کلاسیک می‌خواهد، رویکرد رایج کوتاه‌مدت این است: گواهی با امضای کلاسیک، اما تبادل کلید هیبریدی در TLS.

در داخل کلاستر، سرویس‌مش‌هایی مانند Istio و Linkerd می‌توانند mTLS را با پروکسی‌های سازگار با PQC در مرزها یا بیلدهای آزمایشی دیتاپلین توسعه دهند، در حالی که کنترل‌پلین هنوز گواهی کلاسیک صادر می‌کند. طول عمر گواهی‌ها را کوتاه نگه دارید، چرخش خودکار را فعال کنید و اثر افزایش اندازه هندشیک را بر MTU، کارایی و کانکارنسی پایش کنید.

برای کنترل‌پلین، ابتدا مسیرهای kube-apiserver، kubelet و etcd را ایمن کنید. اگر مؤلفه‌های بومی هنوز از PQC در TLS پشتیبانی مستقیم ندارند، می‌توان از سایدکار یا پروکسی جلویی برای پیاده‌سازی تبادل کلید هیبریدی استفاده کرد. برای داده در حال سکون، etcd از رمز متقارن استفاده می‌کند؛ مسئله PQC حفاظت از کلیدهای حفاظت‌کننده داده است. یکپارچه‌سازی Kubernetes KMS Provider با KMS خارجی که از لفاف‌گذاری کلید هیبریدی/PQC پشتیبانی می‌کند، ریسک کوانتومی را بدون تغییر در کد برنامه کاهش می‌دهد.

زنجیره تأمین نیز باید همراه شود: امضای تصاویر و اسناد را با بهترین‌روش فعلی ادامه دهید و در عین حال ابزارها و قالب‌های سازگار با PQC (مانند برنامه‌های آینده Sigstore) را رصد کنید. در محیط‌های آزمایشی، امضاهای موازی PQ را برای سنجش اندازه، هزینه تأیید و انطباق سیاستی بررسی کنید و مطمئن شوید SBOM، پذیرش و سیاست‌ها قابل ارتقا بمانند.

نقشه راه، مرحله‌ای و مبتنی بر اندازه‌گیری است: فهرست وابستگی‌های رمزنگاری را تهیه کنید، TLS 1.3 را همه‌جا فعال و الگوریتم‌های ضعیف را حذف کنید، آزمایش هیبرید را از مسیرهای کم‌ریسک آغاز و سپس به Ingress، سرویس‌مش و نقاط کنترل‌پلین گسترش دهید. برنامه‌های بازگشت داشته باشید، سازگاری را دقیق رصد کنید و بودجه کارایی تعریف کنید. هدف نهایی، چابکی رمزنگاری است تا با تثبیت استانداردهای PQC بتوانید سریع و ایمن مهاجرت کنید.

#PostQuantum #Kubernetes #PQC #TLS13 #ServiceMesh #Istio #etcd #CloudSecurity

🟣لینک مقاله:
https://ku.bz/DzzV1cR4z

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon