🔵 عنوان مقاله
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

🔵 عنوان مقاله
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

🔵 عنوان مقاله
Wrangling Kubernetes contexts (3 minute read)

🟢 خلاصه مقاله:
**مشکل از یک وضعیت سراسری پنهان شروع می‌شود: خط current-context در ~/.kube/config تعیین می‌کند kubectl به کدام cluster وصل شود، و همین باعث می‌شود به‌سادگی اشتباهاً روی production فرمان اجرا کنید. راهکار امن‌تر این است که فقط config مربوط به development را به‌صورت پیش‌فرض نگه دارید و برای رفتن به production همیشه به‌طور صریح با KUBECONFIG (مثلاً از طریق shell aliases) سوییچ کنید. با این کار هر عمل پرریسک باید عمداً با یک پیشوند مشخص اجرا شود، به جای تکیه بر context سراسری و فراموش‌شدنی؛ نتیجه، کاهش چشمگیر خطاهای ناخواسته در محیط production است.

#Kubernetes #kubectl #DevOps #Kubeconfig #SRE #CloudNative #ProductionSafety

🟣لینک مقاله:
https://natkr.com/2025-11-14-kubernetes-contexts/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Safeguarding OKE: Passwordless kubectl Access with OCI Instance Principals

🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با تکیه بر OCI Instance Principals و بدون نیاز به رمز یا کلیدهای بلندمدت، دسترسی kubectl به یک کلاستر OKE را فعال کنیم. ایده اصلی این است که بارهای کاری روی Compute به‌عنوان پرینسیپل خودِ ماشین احراز هویت شوند و با استفاده از توکن‌های کوتاه‌عمر به API کلاستر دسترسی بگیرند. برای این کار، ابتدا ماشین‌ها را در یک dynamic group قرار می‌دهیم، سپس با IAM policies محدود و دقیق، فقط کمینه مجوزهای لازم برای کلاستر (مثلاً use روی cluster) را در سطح یک compartment یا حتی یک کلاستر خاص می‌دهیم. روی همان ماشین، OCI CLI کنار kubectl نصب می‌شود و kubeconfig طوری پیکربندی می‌گردد که از OCI CLI exec plugin استفاده کند؛ در نتیجه هر بار kubectl اجرا می‌شود، توکن موقتی را از OCI با مکانیزم Instance Principals می‌گیرد و نیازی به ذخیره رمز/کلید نیست. در نهایت با تنظیم RBAC داخل کلاستر، دسترسی‌ها دقیقاً به نقش‌هایی که تعریف کرده‌ایم محدود می‌شود. این الگو امنیت را افزایش می‌دهد، از افشای اعتبارنامه‌ها جلوگیری می‌کند، گردش توکن‌ها را خودکار می‌سازد و برای سناریوهای CI/CD و زیرساخت‌های موقتی در OCI بسیار مناسب است.

#Kubernetes #OKE #OracleCloud #OCI #IAM #kubectl #DevOps #CloudSecurity

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon