WIUNIX ACADEMY
عیب‌یابی DNS و ارتباط Service در Kubernetes با بررسی CoreDNS
از همان Pod مشکل‌دار، پاسخ DNS، مسیر رسیدن به CoreDNS و اتصال به Service را جداگانه بررسی کنید تا علت خطا پیش از تغییر تنظیمات روشن شود.
محیطت را انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من11 مقدار قابل‌تغییر
از اینجا شروع کن
در پایان چه چیزی خواهی داشت؟
با چند آزمون مقایسه‌ای مشخص کنید خطا از نام سرویس، تنظیم resolver، دسترسی به CoreDNS، انتخاب مقصدهای Service یا خود برنامه است.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
فرمان‌ها و تفاوت‌های محیط‌های منتخب با مستندات رسمی بررسی شده‌اند؛ این بررسی به معنای اجرای عملی روی همهٔ سیستم‌ها یا سرویس شما نیست. فرم فعلی نام‌های ساده تا ۳۲کاراکتر را می‌پذیرد؛ این محدودیت فرم است، نه Kubernetes. اگر نام واقعی طولانی‌تر است، مقدار نمونه را کپی نکنید؛ فرمان را در ویرایشگر خودتان با نام کامل تنظیم کنید. نام منبع را تغییر ندهید.
قبل از شروع
- کلاستر موجود با CoreDNS و Service معمولی از نوع ClusterIP؛ نام و فضای نام دقیق مبدأ و مقصد.
- مجوز خواندن وضعیت DNS و Service و اجرای ابزار در کانتینر تشخیصی مورد تأیید.
- وجود dig و curl در کانتینر مجاز؛ ابزار را خودسرانه به ایمیج برنامه اضافه نکنید.
قدم بعدی
ابزار میزبان انتخاب‌شده را آماده کنید
ابزارهای لازم را روی کامپیوتر یا سروری آماده کنید که فرمان‌های مدیریتی را از آن اجرا می‌کنید. پیش از تأیید، فهرست تغییر بسته‌ها را بخوانید؛ داخل کانتینر برنامه ابزار نصب نکنید. کلاستر، سرویس و باینری‌های اصلی باید از قبل با نسخهٔ مورد تأیید موجود باشند. پنل‌های بعد را در Bash اجرا کنید. نصب بسته روی همین میزبان تغییر ایجاد می‌کند، اما سرور برنامهٔ تازه‌ای راه نمی‌اندازد.
از kubectl لینوکسیِ موجود استفاده کنید که اختلاف آن با همهٔ نسخه‌های API Server حداکثر یک نسخهٔ فرعی باشد. پیش از ادامه نسخهٔ سرور را در کانتکست مجاز ببینید. برای این عیب‌یابی kubelet یا kubeadm نصب نکنید و مخزن بستهٔ کلاینت را بازنویسی نکنید.
میزبان انتخاب‌شده؛ نصب بسته فقط با مجوز تغییر همین میزبان
sudo dnf install ca-certificates bash coreutils bind-utils
if ! command -v curl >/dev/null 2>&1; then sudo dnf install curl; fi
cat /etc/os-release
command -v bash curl timeout
command -v kubectl
kubectl version --client --output=yaml
dig -vنسخهٔ سیستم با انتخاب شما یکسان باشد، ابزارها پیدا شوند و نسخهٔ کلاینت و سرویس با شرایط بالا سازگار باشند. اگر باینری موجود نیست یا سازگار نیست، ادامه ندهید.
حفاظت میزبان و مسیرهای نصب موجود را حفظ کنید
SELinux را در حالت enforcing و قواعد firewalld را فعال نگه دارید. ابزار کلاینت به خروجی مجازِ API، TLS یا SFTP نیاز دارد و پورت ورودی تازه‌ای لازم نیست. نتیجهٔ سرویس محدودشدهٔ systemd ممکن است با اجرای تعاملی فرق داشته باشد. خطای AVC، برچسب فایل و مجوز سرویس را با مسئول سیاست بررسی کنید؛ خاموش‌کردن SELinux یا دیوارهٔ آتش و مجوز گسترده راه‌حل نیست. خطای زنجیرهٔ اعتماد یا سیاست رمزنگاری به مقصد سازگار نیاز دارد، نه ضعیف‌کردن حفاظت سیستم. مسیر داده و پیکربندی سفارشی باید برچسب مناسب فعلی را حفظ کند؛ بازبرچسب‌گذاری بازگشتیِ کورکورانه انجام ندهید.
میزبان انتخاب‌شده؛ فقط خواندن وضعیت حفاظت
if command -v getenforce >/dev/null 2>&1; then getenforce; fi
if command -v firewall-cmd >/dev/null 2>&1; then firewall-cmd --state; fiمسیر DNS را از مسیر ارتباط با برنامه جدا کنید
دریافت پاسخ DNS فقط تبدیل نام را ثابت می‌کند، نه آماده‌بودن برنامه برای پذیرش درخواست. برقراری اتصال مستقیم به IP یک Pod نیز درست‌بودن selector، ترجمهٔ پورت Service یا DNS را ثابت نمی‌کند. مسیر را مرحله‌به‌مرحله دنبال کنید: resolver کانتینر مبدأ، Service مربوط به DNS، مقصدهای CoreDNS و رکورد مورد انتظار. سپس Service برنامه را جداگانه بسنجید.
این راهنما برای CoreDNS و ClusterIP معمولی است. اگر کلاستر از NodeLocal DNSCache، دامنهٔ اختصاصی، شبکهٔ میزبان یا service mesh استفاده می‌کند، جزئیات همان پیاده‌سازی را با مسئول آن تطبیق دهید. در جریان تشخیص، Corefile مشترک را جایگزین نکنید و همهٔ Podهای DNS را دوباره راه‌اندازی نکنید.
قدم بعدی
نام کامل سرویس و فضای نام هر دو سمت را مشخص کنید
نام کوتاه Service در فضای نام مبدأ جست‌وجو می‌شود؛ همین نام در فضای نام دیگری ممکن است به سرویس دیگری اشاره کند. پسوند دامنهٔ واقعی کلاستر را پیدا کنید و برای آزمون مستقل از فهرست جست‌وجو، نام کامل را با نقطهٔ پایانی بپرسید. cluster.local را برای هر کلاستر فرض نکنید.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
kubectl config get-contexts 'lab'
kubectl --context='lab' -n 'academy-lab' get pod 'dns-client' -o wide
kubectl --context='lab' -n 'academy-lab' get service 'api' -o widePod مبدأ، Service مقصد و نام کامل مورد انتظار بدون ابهام تعیین شده باشند.
قدم بعدی
تنظیم نام‌گشایی را داخل کانتینر مشکل‌دار بخوانید
تنظیم resolver همان کانتینر را ببینید؛ تنظیم نود لزوماً نشان‌دهندهٔ مسیر برنامه نیست. nameserver، پسوندهای search و ndots را کنار dnsPolicy، dnsConfig و hostNetwork بخوانید. با ClusterFirst نام‌های کلاستر به DNS کلاستر می‌روند، اما Default از تنظیم نود پیروی می‌کند. ممکن است برنامه کتابخانهٔ resolver یا حافظهٔ نهان خودش را داشته باشد؛ موفقیت ابزار خط فرمان فقط یک شاهد مقایسه‌ای است.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
kubectl --context='lab' -n 'academy-lab' exec 'dns-client' -c 'tools' -- cat /etc/resolv.conf
kubectl --context='lab' -n 'academy-lab' get pod 'dns-client' -o jsonpath='{.spec.dnsPolicy}{"\n"}{.spec.dnsConfig}{"\n"}{.spec.hostNetwork}{"\n"}'آدرس DNS و قواعد جست‌وجوی واقعیِ Pod ثبت شده باشند و با سیاست DNS آن سازگار باشند.
قدم بعدی
همان پرس‌وجو را با UDP و TCP امتحان کنید
فرمان‌ها به کانتینر مجازِ دارای dig نیاز دارند. وجود nslookup یا dig را در ایمیج برنامه فرض نکنید. در صورت نبود ابزار، از مسئول سرویس یک کانتینر تشخیصی تأییدشده بخواهید؛ استفاده از نمونهٔ رسمی dnsutils هم به بازبینی ایمیج و مجوزهای آن نیاز دارد. هر دو آزمون را از همان فضای شبکه و با مهلت محدود انجام دهید تا تفاوت مبدأ نتیجه را مخدوش نکند.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
kubectl --context='lab' -n 'academy-lab' exec 'dns-client' -c 'tools' -- dig +time=2 +tries=1 'api.academy-lab.svc.cluster.local.' A
kubectl --context='lab' -n 'academy-lab' exec 'dns-client' -c 'tools' -- dig +tcp +time=2 +tries=1 'api.academy-lab.svc.cluster.local.' A
kubectl --context='lab' -n 'academy-lab' exec 'dns-client' -c 'tools' -- dig +time=2 +tries=1 kubernetes.default.svc.'cluster.local'. Aوضعیت پاسخ، زمان پاسخ و تفاوت UDP/TCP برای نام کامل ثبت شده باشند؛ ناموجودبودن ابزار را شکست DNS حساب نکنید.