في نهاية العام الماضي ،
قدم Reddit مكوّنًا إضافيًا لـ kubectl ، مما يساعد على تصحيح الأخطاء في مجموعات نظام Kubernetes -
kubectl-debug . بدت هذه الفكرة على الفور مثيرة للاهتمام ومفيدة لمهندسينا ، لذلك قررنا النظر في تنفيذها وسعداءًا بمشاركة نتائجنا مع قراء المركز.
لماذا هذا ضروري حتى؟
في الوقت الحالي ، هناك إزعاج خطير في عملية تصحيح شيء ما في إطار القرون. الهدف الرئيسي عند تجميع صورة الحاوية هو
تقليلها ، أي اجعله أصغر حجمًا ممكنًا ويحتوي على "فائض" أقل قدر ممكن من الداخل. ومع ذلك ، عندما يتعلق الأمر بمشاكل في تشغيل البرنامج النهائي في حاويات أو تصحيح اتصالاته مع خدمات أخرى في الكتلة / الخارج ... تلعب بساطتها خدعة علينا - بعد كل شيء ،
لا يوجد شيء في الحاويات للعملية الفعلية لإيجاد المشاكل. كقاعدة عامة ، لا تتوفر أدوات مساعدة مثل netstat / ip / ping / curl / wget ، إلخ.
وغالبًا ما ينتهي كل هذا إلى حقيقة قيام المهندس بتثبيته على البرنامج الضروري في حاوية التشغيل من أجل "رؤية" المشكلة ورؤيتها. في مثل هذه الحالات ، بدا البرنامج المساعد kubectl-debug أداة مفيدة للغاية - لأنه يحفظ من الألم العاجل.
من خلال مساعدتها ، يمكنك
تشغيل حاوية تحتوي على جميع الأدوات اللازمة على متنها في سياق
جراب للمشكلة
باستخدام أمر واحد ودراسة جميع العمليات "من الخارج" ، من الداخل. إذا واجهت أي وقت مضى استكشاف أخطاء Kubernetes الآن ، فهذا يبدو جذابًا ، أليس كذلك؟
ما هو هذا البرنامج المساعد؟
بشكل عام ، تبدو بنية هذا الحل بمثابة حزمة من
البرنامج المساعد لـ kubectl
وكوكيل يبدأ في استخدام جهاز التحكم DaemonSet. يقدم المكوّن الإضافي الأوامر التي تبدأ بـ
kubectl debug … ويتفاعل مع الوكلاء على عقد الكتلة. العامل ، بدوره ، يعمل على الشبكة المضيفة ، ويتم تثبيت docker.sock المضيف في جراب الوكيل للوصول الكامل إلى الحاويات الموجودة على هذا الخادم.
وفقًا لذلك ، عند طلب تشغيل حاوية تصحيح الأخطاء في الحافظة المحددة:
هناك عملية لتحديد
hostIP ، ويتم إرسال طلب إلى الوكيل (يعمل على مضيف مناسب) لإطلاق حاوية تصحيح الأخطاء في مساحات الأسماء المقابلة لـ pod الهدف.
يتوفر عرض أكثر تفصيلاً لهذه الخطوات في
وثائق المشروع .
ما هو المطلوب للعمل؟
يدعي مؤلف kubectl-debug أنه متوافق مع إصدارات عميل / مجموعة
Kubernetes 1.12.0+ ، ومع ذلك ، كان لدي K8s 1.10.8 في متناول اليد ، حيث كان كل شيء يعمل دون مشاكل مرئية ... مع ملاحظة واحدة: لكي
kubectl debug فريق
kubectl debug في هذا النموذج ، إصدار
kubectl هو بالضبط
1.12+ . خلاف ذلك ، جميع الأوامر متشابهة ، ولكن يتم استدعاؤها فقط من خلال
kubectl-debug …عند بدء تشغيل قالب DaemonSet الموصوف في
README يجب ألا تنسى الملام الذي تستخدمه على العقد: بدون تسامح مناسب ، لن تتمكن قرون الوكيل من الاستقرار هناك ، ونتيجة لذلك ، لن تتمكن من استخدام القرون التي تعيش على مثل هذه العقد يمكن الاتصال مع المصحح.
مساعدة مصحح الأخطاء شاملة للغاية ويبدو أنها تصف جميع الإمكانات الحالية لبدء / تكوين المكون الإضافي. بشكل عام ، يسر الأداة المساعدة مع عدد كبير من التوجيهات لتشغيل: يمكنك إرفاق الشهادات ، وتحديد سياق kubectl ، وتحديد تكوين kubectl منفصل أو عنوان خادم API الكتلة ، وأكثر من ذلك.
العمل مع المصحح
يتم التثبيت حتى لحظة "كل شيء يعمل" إلى مرحلتين:
- تنفيذ
kubectl apply -f agent_daemonset.yml ؛ - قم بتثبيت المكون الإضافي مباشرة - بشكل عام ، كل شيء كما هو موضح هنا .
كيفية استخدامها؟ افترض أن لدينا المشكلة التالية: لم يتم جمع مقاييس إحدى الخدمات في المجموعة - ونريد التحقق مما إذا كانت هناك مشكلات في الشبكة بين Prometheus والخدمة المستهدفة. كما قد تعتقد ، فإن صورة بروميثيوس تفتقر إلى الأدوات المطلوبة.
دعونا نحاول الاتصال بالحاوية باستخدام Prometheus (إذا كانت هناك عدة حاويات في الحافظة ، فستحتاج إلى تحديد الحاوية التي سيتم الاتصال بها ، وإلا فإن مصحح الأخطاء سيختار الحاوية الأولى افتراضيًا):
kubectl-debug --namespace kube-prometheus prometheus-main-0 Defaulting container name to prometheus. pulling image nicolaka/netshoot:latest... latest: Pulling from nicolaka/netshoot 4fe2ade4980c: Already exists ad6ddc9cd13b: Pull complete cc720038bf2b: Pull complete ff17a2bb9965: Pull complete 6fe9f5dade08: Pull complete d11fc7653a2e: Pull complete 4bd8b4917a85: Pull complete 2bd767dcee18: Pull complete Digest: sha256:897c19b0b79192ee5de9d7fb40d186aae3c42b6e284e71b93d0b8f1c472c54d3 Status: Downloaded newer image for nicolaka/netshoot:latest starting debug container... container created, open tty... [1] → root @ /
في السابق ، اكتشفنا أن الخدمة الإشكالية تعمل على العنوان 10.244.1.214 وتستمع إلى المنفذ 8080. بالطبع ، يمكننا التحقق من توفر الأجهزة المضيفة أيضًا ، ومع ذلك ، من أجل عملية تصحيح موثوق بها ، يجب إعادة إنتاج هذه العمليات في ظروف مماثلة (أو أقرب ما يمكن). لذلك ، يعد التحقق من حاوية / حاوية باستخدام Prometheus هو الخيار الأفضل. لنبدأ بأخرى بسيطة:
[1] → ping 10.244.1.214 PING 10.244.1.214 (10.244.1.214) 56(84) bytes of data. 64 bytes from 10.244.1.214: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from 10.244.1.214: icmp_seq=2 ttl=64 time=0.061 ms 64 bytes from 10.244.1.214: icmp_seq=3 ttl=64 time=0.047 ms 64 bytes from 10.244.1.214: icmp_seq=4 ttl=64 time=0.049 ms ^C --- 10.244.1.214 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 61ms rtt min/avg/max/mdev = 0.047/0.053/0.061/0.007 ms
كل شيء على ما يرام. ربما المنفذ غير متوفر؟
[1] → curl -I 10.244.1.214:8080 HTTP/1.1 200 OK Date: Sat, 12 Jan 2019 14:01:29 GMT Content-Length: 143 Content-Type: text/html; charset=utf-8
وليس هناك مشكلة. بعد ذلك سوف نتحقق مما إذا كان الاتصال الفعلي بين بروميثيوس ونقطة النهاية بالمقاييس يحدث:
[2] → tcpdump host 10.244.1.214 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:04:19.234101 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [P.], seq 4181259750:4181259995, ack 2078193552, win 1444, options [nop,nop,TS val 3350532304 ecr 1334757657], length 245: HTTP: GET /metrics HTTP/1.1 14:04:19.234158 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [.], ack 245, win 1452, options [nop,nop,TS val 1334787600 ecr 3350532304], length 0 14:04:19.290904 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [P.], seq 1:636, ack 245, win 1452, options [nop,nop,TS val 1334787657 ecr 3350532304], length 635: HTTP: HTTP/1.1 200 OK 14:04:19.290923 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [.], ack 636, win 1444, options [nop,nop,TS val 3350532361 ecr 1334787657], length 0 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel
طلبات الحصول على إجابات قادمة. بناءً على نتائج هذه العمليات ، يمكننا أن نستنتج أنه لا توجد مشاكل على مستوى تفاعل الشبكة ، مما يعني (على الأرجح) أنك بحاجة إلى النظر من الجانب المطبق. نحن نتواصل مع الحاوية مع المُصدر (أيضًا ، بالطبع ، باستخدام مصحح الأخطاء المعني ، لأن المصدرين دائمًا لديهم صور أضيق الحدود للغاية) ... وندهشنا أن نجد أن هناك مشكلة في تكوين الخدمة - على سبيل المثال ، لقد نسينا أن نوجه المصدّر إلى الصورة الصحيحة. عنوان تطبيق الوجهة
تم حل القضية!بالطبع ، هناك طرق أخرى للتصحيح ممكنة في الموقف الموضح هنا ، لكننا سنتركها خارج نطاق المقالة. والنتيجة هي أن kubectl-debug لديه الكثير من الفرص للاستخدام: يمكنك تشغيل أي صورة في العمل ، وإذا كنت ترغب في ذلك ، يمكنك حتى تجميع بعض الصورة المحددة (مع مجموعة الأدوات اللازمة).
ما التطبيقات الأخرى تتبادر إلى الذهن على الفور؟
- تطبيق "صامت" ، لم يقم مطورو البرامج
الضارة بتنفيذ التسجيل العادي به. لكن لديه القدرة على الاتصال بمنفذ الخدمة والتصحيح باستخدام أداة محددة ، والتي ، بالطبع ، لا ينبغي وضعها في الصورة النهائية. - شغّل بجوار التطبيق القتالي المطابق في الوضع "اليدوي" ، ولكن مع تشغيل debug - للتحقق من التفاعل مع الخدمات المجاورة.
بشكل عام ، من الواضح أن هناك حالات أكثر بكثير يمكن أن تكون فيها هذه الأداة مفيدة. سيتمكن المهندسون الذين يواجهونهم في العمل يوميًا من تقييم إمكانات الأداة من حيث تصحيح الأخطاء "المباشر".
الاستنتاجات
Kubectl-debug هي أداة مفيدة واعدة. بالطبع ، هناك مجموعات Kubernetes والتطبيقات التي ليس لها معنى كبير ، ولكن لا تزال هناك حالات أكثر احتمالًا عندما تقدم مساعدة لا تقدر بثمن في تصحيح الأخطاء - خاصةً إذا كان الأمر يتعلق بالبيئة القتالية والحاجة إلى العثور بسرعة ، هنا والآن ، على الأسباب المشكلة التي واجهتها
كشفت أول تجربة استخدام عن الحاجة الماسة إلى القدرة على الاتصال بأداة / حاوية ، والتي لا تبدأ حتى النهاية (على سبيل المثال ، تحدث حالة تعليق في
CrashLoopbackOff ) ، فقط للتحقق من أسباب عدم بدء التطبيق. في هذه المناسبة ، قمت بإنشاء
مشكلة مقابلة في مستودع المشروع ، والتي استجاب لها المطور بشكل إيجابي ووعد بالتنفيذ في المستقبل القريب. سعيد جدا مع ردود الفعل سريعة وكافية. لذلك سوف نتطلع إلى ميزات جديدة للأداة وتحسينها!
PS
اقرأ أيضًا في مدونتنا: