#Kubernetes

100 Kubernetes Errors &
Solutions
➖➖➖➖➖➖➖➖➖➖➖➖➖
Group:
©️ https://news.1rj.ru/str/DevopsDocGP
Channel:
©️ https://news.1rj.ru/str/DevopsDoc

DevOps Learning Path for Beginners

چرا بعد از نصب لینوکس، ویندوز بوت نمی‌شود؟

مقدمه

وقتی روی کامپیوترت هم ویندوز و هم لینوکس نصب می‌کنی، یه چیزی به اسم بوت‌لودر (Bootloader) تصمیم می‌گیره که کدوم سیستم‌عامل اجرا بشه. بوت‌لودر یه برنامه کوچیکه که قبل از سیستم‌عامل اجرا می‌شه و راه رو برای بالا آوردن ویندوز یا لینوکس باز می‌کنه.

در ویندوز، این کار رو Windows Boot Manager (BOOTMGR) انجام می‌ده، اما در لینوکس معمولاً از GRUB (GRand Unified Bootloader) استفاده می‌شه. مشکل اینجاست که وقتی لینوکس رو بعد از ویندوز نصب می‌کنی، GRUB جای بوت‌لودر ویندوز رو می‌گیره و ممکنه ویندوز رو توی لیست بوت قرار نده. نتیجه؟ فقط لینوکس بوت می‌شه و خبری از ویندوز نیست!

بوت‌لودر چیست و چه کاری انجام می‌دهد؟

بوت‌لودر یه برنامه کوچیکه که روی پارتیشن EFI ذخیره می‌شه و تعیین می‌کنه که سیستم بعد از روشن شدن، چه چیزی رو اجرا کنه.

بوت‌لودرهای معروف:


✅ GRUB → مخصوص لینوکس
✅ Windows Boot Manager (BOOTMGR) → مخصوص ویندوز
✅ rEFInd → یه بوت‌لودر گرافیکی که می‌تونه بین ویندوز و لینوکس سوییچ کنه

چرا بعد از نصب اوبونتو، ویندوز بوت نمی‌شود؟

وقتی اوبونتو رو روی یه دیسک دیگه نصب کردی، مراحل زیر اتفاق افتاده:

اول GRUB جای بوت‌لودر ویندوز رو گرفته و فقط خودش اجرا می‌شه.
دوم ویندوز رو به لیست بوت اضافه نکرده، پس ویندوزت دیده نمی‌شه.
سوم حتی اگه اولویت بوت بایوس رو روی دیسک ویندوز بذاری، باز هم GRUB بوت می‌شه چون کنترل EFI رو به دست گرفته.

چگونه مشکل را حل کنیم؟

بررسی کنیم که GRUB ویندوز را شناسایی کرده یا نه
اگه ویندوز توی GRUB نیست، توی اوبونتو این دستور رو بزن:

sudo os-prober

اگه ویندوز رو پیدا کرد، GRUB رو آپدیت کن:

sudo update-grub

بعد سیستم رو ریست کن و ببین توی منوی GRUB ویندوز اضافه شده یا نه.

اگر GRUB ویندوز را شناسایی نکرد، دستی اضافه کنیم

پارتیشن EFI رو پیدا کن:

sudo fdisk -l

بعد اینو توی فایل تنظیمات GRUB اضافه کن:

sudo nano /etc/grub.d/40_custom

متن زیر رو داخلش قرار بده (مطمئن شو که مسیر درست باشه):

menuentry "Windows 11" {
    insmod part_gpt
    insmod chain
    set root=(hd0,gpt1)
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

بعد GRUB رو دوباره آپدیت کن:

sudo update-grub

حالا ریست کن و ببین ویندوز اضافه شده یا نه.

استفاده از boot-repair (راه‌حل خودکار)
اگه روش‌های بالا جواب نداد، این ابزار رو نصب کن و اجراش کن:

sudo apt install boot-repair
boot-repair

بعد گزینه Recommended Repair رو بزن و بذار خودش مشکل رو حل کنه.

بازگردانی بوت‌لودر ویندوز (اگر فقط ویندوز را می‌خواهی)

اگه می‌خوای کلاً GRUB رو حذف کنی و فقط ویندوز بوت بشه:

یه فلش ریکاوری ویندوز 11 یا 10 بساز و باهاش بوت کن.
وقتی صفحه نصب ویندوز اومد، Shift + F10 رو بزن تا CMD باز شه.
این دستورات رو اجرا کن:

bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd

سیستم رو ریست کن، حالا ویندوز بدون GRUB بوت می‌شه.

پیشنهاد: اگه هنوز اوبونتو رو لازم داری، بهتره GRUB رو درست کنی تا بتونی بین ویندوز و لینوکس سوییچ کنی، نه اینکه کلش رو حذف کنی.

Sometimes you wanna play on a bigger screen 📺

#hp 3par

اگر بخوایم یه تعریف خیلی ساده از SAN Storage ها بگیم باید گفت که این دستگاهها با توجه به اینکه تعداد هاردهای زیادی دارن میتونند فضای ذخیره سازی خیلی زیادی رو برای ما داخل شبکه ها به وجود بیارن از طرفی برای متصل کردنشون به شبکه و سرورها برای مصارفی مثل ذخیره سازی یا بک آپ باید از سوییچهای مخصوصی که به نام SAN switch شناخته میشن استفاده کرد و جالبتر اینه که برای اتصال سرور ها به SAN switch ها هم باید از کارتهای مخصوصی که به اونها HBA میگن استفاده کنید بد نیست بدونید که تمامی این ارتباطها از طریق فیبر های نوری انجام میشه.

موضوع ویدئو: به روز رسانی Firmware هاردهای 3par هست.

آدرس اینستاگرام:
🌐Instagram
-----------------------------
آدرس کانال یوتیوب:
📹Youtube Channel
-----------------------------
آدرس کانال تلگرام:
🆔 Telegram Channel

کارت‌های HBA (مخفف Host Bus Adapter) سخت‌افزارهایی هستن که برای اتصال سرور یا کامپیوتر به دستگاه‌های ذخیره‌سازی استفاده می‌شن. این کارت‌ها معمولاً روی اسلات PCIe نصب می‌شن و به سرور اجازه می‌دن تا با دستگاه‌های ذخیره‌سازی ارتباط برقرار کنه.
فرق HBA با RAID Controller چیه؟
مورد اول HBA: فقط یه واسط برای اتصال سرور به هارد یا استوریجه، بدون قابلیت مدیریت RAID.
مورد دوم RAID Controller: علاوه بر اتصال، امکان مدیریت RAID و افزایش کارایی رو هم فراهم می‌کنه.

مقاله ی ساده و روان Helm در Kubernetes

ابزار Helm چیست و چرا به آن نیاز داریم؟
اگر با Kubernetes کار کرده باشی، حتماً می‌دونی که برای راه‌اندازی یه اپلیکیشن روی کلاستر باید کلی فایل YAML بنویسی. هر اپلیکیشن معمولاً شامل Deployment، Service، ConfigMap، Secret، Ingress و ... هست که مدیریت اون‌ها به‌صورت دستی واقعاً وقت‌گیر و سخته.
ابزار Helm اومده که این کار رو راحت‌تر و سریع‌تر کنه! Helm مثل یه مدیر بسته (Package Manager) برای Kubernetes عمل می‌کنه. درست همون‌طور که توی لینوکس از apt یا yum برای نصب برنامه‌ها استفاده می‌کنی، توی Kubernetes هم Helm این کار رو برات انجام می‌ده.

مزایای استفاده از Helm
✅ نصب راحت اپلیکیشن‌ها: به جای نوشتن کلی فایل YAML، فقط یک دستور اجرا می‌کنی!
✅ به‌روزرسانی ساده: می‌تونی اپلیکیشن‌ها رو راحت‌تر به نسخه‌های جدید ارتقا بدی.
✅ مدیریت نسخه‌ها (Rollback): اگه چیزی خراب شد، می‌تونی خیلی راحت به نسخه قبلی برگردی.
✅ تنظیمات سفارشی‌ سازی‌ شده: می‌تونی مقادیر مورد نیاز رو تغییر بدی بدون دست‌کاری فایل‌های YAML.
✅ استفاده از چارت‌های آماده: کلی چارت (Chart) آماده برای نصب دیتابیس‌ها، وب‌سرورها و برنامه‌های مختلف وجود داره.

چارت (Chart) در Helm چیست؟
چارت در Helm در واقع بسته‌ای از فایل‌های YAML هست که تمام اجزای مورد نیاز یک اپلیکیشن رو شامل می‌شه. مثلاً اگه بخوای Nginx رو روی Kubernetes نصب کنی، باید چندین فایل YAML بنویسی، ولی با Helm، یه چارت آماده هست که همه چیزو برات انجام می‌ده.

ساختار یک چارت Helm به این شکله:

my-chart/
  ├── charts/            # چارت‌های دیگر (در صورت وجود وابستگی)
  ├── templates/         # فایل‌های YAML که برای دیپلوی استفاده می‌شوند
  ├── values.yaml        # مقادیر پیش‌فرض که قابل تغییر هستند
  ├── Chart.yaml         # توضیحات مربوط به چارت
  └── README.md          # توضیحات و نحوه استفاده

نصب یک اپلیکیشن با Helm
مثلاً برای نصب Nginx با Helm کافیه این دستور رو بزنی:

helm install my-nginx bitnami/nginx

این دستور یه پاد Nginx رو روی کلاستر Kubernetes اجرا می‌کنه بدون اینکه لازم باشه چندین فایل YAML بنویسی.

حذف اپلیکیشن
اگه بخوای اپلیکیشنی که با Helm نصب کردی رو حذف کنی:

helm uninstall my-nginx

لیست اپلیکیشن‌های نصب‌شده
برای دیدن اپ‌هایی که با Helm روی کلاستر Kubernetes نصب شدن:

helm list

چگونه Helm را نصب کنیم؟
نصب Helm خیلی سادست! توی لینوکس می‌تونی این کار رو با دستور زیر انجام بدی:

curl https://raw.githubusercontent.com/helm/helm/main/noscripts/get-helm-3 | bash

آیا همه ی Image های مورد استفاده برای ساخت کانتینر ها ، از طریق داکر فایل ساخته میشوند؟

نه، همه‌ی ایمیج‌ها با Dockerfile ساخته نمی‌شن! روش‌های دیگه‌ای هم برای ساخت ایمیج وجود داره که بعضی پروژه‌ها و شرکت‌ها از اون‌ها استفاده می‌کنن.

روش‌های جایگزین برای ساخت ایمیج کانتینر
اول ، Dockerfile: همچنان محبوب‌ترین روشه، اما تنها روش نیست.
دوم ، Buildpacks: یه روش خودکار که Cloud Native Buildpacks و Heroku Buildpacks استفاده می‌کنن. این روش نیازی به Dockerfile نداره و خودش محیط مناسب برای اجرای اپ رو تشخیص می‌ده.
سوم ، Bazel: یه ابزار گوگل برای ساخت ایمیج بدون نیاز به Dockerfile که مخصوص پروژه‌های بزرگ و پیچیده طراحی شده.
چهارم ، Nix: یه روش دیکری برای ساخت ایمیج‌های قابل بازتولید و مطمئن.
پنجم ، Singularity: برای محیط‌های HPC و تحقیقاتی، که Dockerfile نداره ولی کانتینر می‌سازه.
ششم ، Kaniko: مخصوص محیط‌هایی که داکر نصب نیست و نیازی به Docker daemon نداره.
هفتم ، Podman & Buildah: می‌تونن بدون نیاز به Docker daemon ایمیج بسازن، حتی از روش‌هایی غیر از Dockerfile.

همه‌ی ایمیج‌ها با Dockerfile ساخته نمی‌شن، اما بیشتر ایمیج‌ها هنوز از Dockerfile استفاده می‌کنن چون رایج‌تر و ساده‌تره. ولی تکنولوژی‌هایی مثل Buildpacks، Bazel و Kaniko در حال گسترش هستن و در بعضی پروژه‌ها جایگزین Dockerfile شدن.

این ارور پرینتر هم از ویندوز ۱۰ سر و کله‌اش پیدا شد.

به خاطر یه فیچر امنیتی این موضوع پیش میاد. معمولا موقعی که پرینتر رو یه PC با ویندوز ۱۰ نصب باشه و به اشتراک گذاشته میشه ممکنه این موضوع پیش بیاد. معمولا در دو حالت زیر:

۱. در حالتی که سیستم مقصد ویندوزی پایین‌تر باشه مثل ۷
۲. موقعی که بیلد ویندوز ۱۰ از بیلدهای قدیمی باشه.

حالا راه حل چیه؟ - یه سر به ریجستری و services بزنیم.

تو کامپیوتر مبدا ( پرینتر روش نصب شده) ریجستری رو باز میکنیم و به مسیر زیر می‌ریم:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print

اینجا یه کلید از نوع DWORD-32 با اسم RpcAuthnLevelPrivacyEnabled می‌سازیم.( به کوچیک و بزرگ بودن حروف دقت بشه.)

مقدارش رو برابر 0 قرار می‌دیم. حالا services رو به صورت Run as administrator باز می‌کنیم و سرویس Print Spooler رو ریستارت می‌کنیم.

اگه سیستم SSD داشت و حوصله نداشتی دنبال سرویس بگردی کلا سیستمو ریستارت کن. اصطلاحا straight forward ئه.

منبع
Mohamad Rostami

آیا Kubernetes براش مهمه که با چه روشی ما ایمیج رو ساختیم؟

نه، Kubernetes اصلاً به این اهمیت نمی‌ده که ایمیج با Dockerfile ساخته شده یا نه!
اون فقط به یه ایمیج کانتینری نیاز داره که از فرمت OCI (Open Container Initiative) یا Docker Image Format پشتیبانی کنه.

چطوری Kubernetes ایمیج‌ها رو اجرا می‌کنه؟
در واقع Kubernetes فقط یه کانتینر Runtime نیاز داره که بتونه ایمیج‌ها رو اجرا کنه. این Runtime می‌تونه containerd، CRI-O یا حتی Docker (در نسخه‌های قدیمی) باشه. فرقی نداره ایمیج با چی ساخته شده؛ مهم اینه که در قالب استاندارد OCI-compliant باشه. وقتی توی Kubernetes یه پاد (Pod) تعریف می‌کنی، اون فقط می‌ره ایمیج مشخص‌شده رو از رجیستری (مثلاً Docker Hub، AWS ECR، یا GitHub Container Registry) می‌گیره و اجرا می‌کنه.
پس Kubernetes به فرمت نهایی ایمیج نگاه می‌کنه، نه به روش ساخت اون!

دوستی جایی قشنگ نوشته بود:

در دنیایی که سرویس های مبتنی بر هوش مصنوعی بر سر "حل مسئله" با هم رقابت می کنند، تنها رقابت معناداری که برای ما انسان‌ها باقی می‌ماند، رقابت بر سر "تعریف مسئله" است.🤝

به نظرم وارد دوره ای از زمان شدیم ، که باید رویکرد فکریمون رو از تلاش برای رسیدن به پاسخ ، به تلاش برای پیدا کردن مسئله تغییر بدهیم.
پاسخ ها با سرعت وحشتناکی بدست میان ، مهم پیدا کردن مسئله و موضوعات مجهول هست ، حالا ابزاری هست که تفکر برای پاسخ را ممکن کرده ؛ باری از روی دوش انسان برداشته و به نوعی تقسیم وظایف کردیم . تا پیش از این ، دنیا مسئله ایجاد میکرد و ما آن را حل میکردیم ، امروزه روز ، ما مسئله تعریف میکنیم و هوش مصنوعی آن را حل میکند.

تفاوت روش های ساخت ایمیج در چیست ؟

فرق اساسی ایمیج‌هایی که با Dockerfile ساخته می‌شن با ایمیج‌هایی که با روش‌های دیگه ساخته می‌شن، بیشتر به نحوه‌ی تولید و بهینه‌سازی اون‌ها برمی‌گرده، نه به فرمت نهایی‌شون. یعنی در نهایت، همه‌ی ایمیج‌ها یک چیز استاندارد می‌شن (OCI-compatible)، اما روش ساخت‌شون می‌تونه متفاوت باشه.

مثلا Dockerfile:
مرحله‌به‌مرحله (Layered) ساخته می‌شه، که به کمک Caching سرعت Build رو بالا می‌بره.
دستورات داخل Dockerfile (مثل RUN, COPY, CMD) به ترتیب اجرا می‌شن و هرکدوم یه لایه‌ی جدا می‌سازن. ممکنه لایه‌های اضافی (بیشتر از نیاز) داشته باشه، که باعث بزرگ شدن ایمیج بشه.
اما روش‌های جایگزین (مثل Buildpacks، Bazel، Kaniko):
بعضی روش‌ها (مثلاً Buildpacks) سعی می‌کنن لایه‌های غیرضروری رو حذف کنن و ایمیج‌های بهینه‌تر بسازن. برخی ابزارها (مثل Bazel) می‌تونن Dependencyهای غیرضروری رو تشخیص بدن و حذف کنن. روش‌هایی مثل Kaniko و Buildah بدون نیاز به Docker daemon ایمیج می‌سازن، که روی سیستم‌هایی که امنیت مهمه، مفیدتره.

استاندارد OCI در ساخت ایمیج ها چیه؟

در واقع OCI (Open Container Initiative) یه استاندارد که می‌گه ایمیج‌های کانتینری باید یه ساختار مشخص و یکسان داشته باشن، فارغ از اینکه چجوری ساخته شدن.

چرا مهمه؟
قبل از OCI، بیشتر ایمیج‌ها فقط برای Docker ساخته می‌شدن، ولی الان هر ابزاری که از OCI تبعیت کنه می‌تونه اون ایمیج‌ها رو اجرا کنه، بدون وابستگی به Docker!

یعنی چی؟
اول ، Kubernetes می‌تونه ایمیج‌هایی که با Docker، Buildpacks، Bazel، Kaniko یا هر چیز دیگه ساخته شدن رو اجرا کنه، چون همه‌ی این ابزارها ایمیج‌های OCI-compatible تولید می‌کنن.
دوم ، containerd و CRI-O که توی Kubernetes استفاده می‌شن، فقط کافیه یه ایمیج استاندارد OCI بگیرن و اجراش کنن، دیگه مهم نیست که این ایمیج با چی ساخته شده.

نتیجه این میشه Kubernetes دیگه نیازی به Docker نداره، فقط کافیه ایمیج‌هایی که از استاندارد OCI تبعیت می‌کنن رو اجرا کنه، همین!