WIUNIX ACADEMY
عیب‌یابی DNS و ارتباط Service در Kubernetes با بررسی CoreDNS
صفحهٔ 2 از 3؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من11 مقدار قابل‌تغییر
از نوع خطا برای انتخاب بررسی بعدی استفاده کنید
در NXDOMAIN ابتدا نام، فضای نام و قواعد رکورد را بررسی کنید؛ رفتار Service بدون IP مجازی و آمادگی مقصدها هم مهم است. در timeout، پیش از محتوای رکورد به دسترسی DNS و سیاست شبکه بپردازید. در SERVFAIL، پردازش CoreDNS، مجوز خواندن منابع و مسیر DNS بالادستی را بررسی کنید. شکست UDP در کنار موفقیت TCP می‌تواند نشانهٔ مشکل اندازهٔ پاسخ یا مسیر انتقال باشد؛ الزاماً رکورد گم نشده است.
پسوندهای search ممکن است برای یک نام چند پرس‌وجو ایجاد کنند. نام کاملِ دارای نقطهٔ پایانی ابزار مقایسه است، نه مجوز تغییر سراسری ndots. آزمون اجرایی این راهنما رکورد A و مسیر IPv4 را دنبال می‌کند؛ نتیجهٔ آن را به AAAA یا همهٔ مسیرهای دوپشته تعمیم ندهید.
قدم بعدی
پشت Service مربوط به DNS چه مقصد آماده‌ای وجود دارد؟
نام kube-dns و برچسب k8s-app=kube-dns در بسیاری از نصب‌های CoreDNS باقی مانده‌اند، اما ابتدا وجود واقعی آن‌ها را در توزیع خود تأیید کنید. EndpointSlice خالی یا مقصد ناآماده می‌تواند علت Service بی‌پاسخ باشد. صرف وجود ClusterIP به معنای وجود مقصد سالم نیست.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
kubectl --context='lab' -n kube-system get pods -l k8s-app=kube-dns -o wide
kubectl --context='lab' -n kube-system get service kube-dns -o yaml
kubectl --context='lab' -n kube-system get endpointslice -l kubernetes.io/service-name=kube-dns -o wide
kubectl --context='lab' -n kube-system logs -l k8s-app=kube-dns --all-containers=true --tail=100 --timestampsPodها، Service و EndpointSliceهای DNS با هم تطبیق داده شده باشند و مقصد آمادهٔ مورد انتظار وجود داشته باشد.
قدم بعدی
انتخاب مقصد Service را با پورت واقعی برنامه تطبیق دهید
selector سرویس را با برچسب Podها و targetPort را با پورتی که برنامه واقعاً روی آن گوش می‌دهد مقایسه کنید. آمادگی مقصدها را از EndpointSlice بخوانید. Service معمولی ممکن است پاسخ DNS داشته باشد، اما هیچ مقصد آماده‌ای پشت آن نباشد. سیاست خروجی مبدأ و ورودی مقصد را جداگانه بررسی کنید؛ شکست DNS و timeout اتصال ممکن است دو علت مستقل داشته باشند.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
kubectl --context='lab' -n 'academy-lab' describe service 'api'
kubectl --context='lab' -n 'academy-lab' get endpointslice -l kubernetes.io/service-name='api' -o yaml
kubectl --context='lab' -n 'academy-lab' get networkpolicy
kubectl --context='lab' -n 'academy-lab' get networkpolicyنام سرویس، پورت‌ها و مقصدهای آماده با برنامهٔ مورد انتظار تطبیق داشته باشند یا ناسازگاری دقیق مشخص شده باشد.
قدم بعدی
خرابی نام‌های داخلی و بیرونی را با هم مقایسه کنید
اگر نام‌های داخلی Kubernetes پاسخ می‌گیرند ولی دامنهٔ بیرونی تحت مالکیت شما نه، مسیر forward، خروجی شبکه، سرور DNS پاسخ‌گوی اصلی دامنه (authoritative) و resolver نود را بررسی کنید. ارجاع نامناسب به stub مربوط به systemd-resolved می‌تواند حلقهٔ ارسال ایجاد کند. تنظیم resolver در kubelet را بدون مسئول کلاستر عوض نکنید. نام‌های خصوصی و لاگ پرس‌وجوها را عمومی نکنید.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
kubectl --context='lab' -n 'academy-lab' exec 'dns-client' -c 'tools' -- dig +time=2 +tries=1 'example.com.' A
kubectl --context='lab' -n kube-system get configmap coredns -o yaml
kubectl --context='lab' describe clusterrole system:corednsمشخص شود شکست به نام‌های بیرونی محدود است یا DNS داخلی را هم درگیر می‌کند.
قدم بعدی
درخواست با نام و IP را از یک مبدأ مقایسه کنید
برای Service موجودِ HTTP، درخواست با نام را با درخواست به IP واقعی Service مقایسه کنید و Host را یکسان نگه دارید. curl باید از قبل در کانتینر تشخیصی مجاز موجود باشد. کدهای ۴۰۱، ۴۰۳ یا ۴۰۴ ممکن است رسیدن درخواست را نشان دهند، درحالی‌که احراز هویت یا مسیریابی برنامه هنوز درست نیست. پاسخ مطلوب مسیر سلامت را با مسئول سرویس تعیین کنید. این پنل فقط GET مسیر انتخاب‌شده را می‌فرستد و پراکسی محیطی را دخالت نمی‌دهد.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
kubectl --context='lab' -n 'academy-lab' exec 'dns-client' -c 'tools' -- curl --noproxy '*' --connect-timeout 3 --max-time 8 --output /dev/null --write-out 'HTTP %{http_code}\n' 'http://api.academy-lab.svc.cluster.local:8080/healthz'
kubectl --context='lab' -n 'academy-lab' exec 'dns-client' -c 'tools' -- curl --noproxy '*' --connect-timeout 3 --max-time 8 --output /dev/null --write-out 'HTTP %{http_code}\n' -H 'Host: api.academy-lab.svc.cluster.local' 'http://10.96.20.30:8080/healthz'رسیدن درخواست GET و پاسخ برنامه در مسیر نام و IP جداگانه ثبت شده باشند؛ موفقیت انتقال را با موفقیت کاربردی یکی نگیرید.
علت روشن‌شده را اصلاح و همان آزمون‌ها را تکرار کنید
نام اشتباه، selector نادرست، ناآمادگی مقصد، مجوز DNS یا سیاست محدود شبکه را در منبع اصلی تنظیمات اصلاح کنید. تغییر CoreDNS بر کل کلاستر اثر می‌گذارد و به بازبینی و راه بازگشت مستقل نیاز دارد. پس از اصلاح همان آزمون‌های پیشین را تکرار کنید، یکی از کارهای معمول برنامه را که پیش از تغییر درست انجام می‌شد، دوباره امتحان کنید و UDP و TCP را مقایسه کنید. یک پاسخ موفق برای اعلام پایان حادثه کافی نیست.