تظل مراقبة ping مهمة لأن الحوسبة السحابية المُدارة وKubernetes تنقلان أعطال الشبكة من مكان إلى آخر بدلًا من القضاء عليها. فتعديل واحد على مجموعة أمان (Security Group)، أو مسار NAT معطّل، أو سجل DNS خاطئ، قد يجعل أحمال عمل سليمة غير قابلة للوصول بينما تُظهر جميع الـ Pods حالة Ready. وتكشف فحوص قابلية الوصول المستمرة عبر ICMP وTCP، من خارج بيئتك ومن داخلها، هذه الأعطال قبل أن يلاحظها المستخدمون.
البنية التحتية المُدارة ما زالت شبكة
يتولى المزوّد تشغيل العتاد، لكن إعداد الشبكة الافتراضية يبقى مسؤوليتك، ومن هناك تبدأ معظم حوادث تعذّر الوصول:
- مجموعات الأمان وقوائم التحكم في الوصول للشبكة (NACL). قاعدة واحدة شديدة التقييد تُطبَّق عبر البنية التحتية ككود قد تعزل طبقة كاملة بصمت.
- بوابات NAT. أحمال العمل الخاصة التي تفقد مسار NAT لا تستطيع الوصول إلى سجلات الحاويات أو واجهات الدفع البرمجية أو الخدمات السحابية التي تعتمد عليها.
- ربط VPC (Peering) وبوابات العبور (Transit Gateway). تعديل جدول توجيه أو فصل أحد المرفقات يقطع حركة المرور بين شبكات VPC والحسابات.
- DNS. تتعطل المناطق الخاصة وقواعد المحلِّل بطرق تبدو كأنها انقطاع كامل.
- زمن الاستجابة بين مناطق التوافر والمناطق الجغرافية. بعد التحويل عند الفشل (Failover) قد تمر الحركة عبر مناطق أخرى فتضيف عشرات المللي ثانية.
لا يظهر أي من ذلك في رسوم استخدام المعالج إلى أن تبدأ الطلبات في انتهاء مهلتها.
غالبًا ما يكون ICMP محظورًا، فاستخدم TCP ping
كثيرًا ما يفشل ping التقليدي في السحابة عن قصد. ففي AWS، تسمح مجموعة الأمان الافتراضية بالحركة الواردة من أعضاء المجموعة نفسها فقط، لذا تُسقَط حزم ICMP القادمة من الإنترنت ما لم تُضف قاعدة صريحة. وتنتهي مجموعات أمان الشبكة في Azure بقاعدة افتراضية هي DenyAllInBound. أما الشبكة الافتراضية التي تنشئها Google Cloud تلقائيًا فتتضمن قاعدة تسمح بـ ICMP، لكن شبكات VPC المخصصة ترفض كل حركة واردة ما لم تفتحها بنفسك. وموازنات الأحمال المُدارة لا تستجيب عادةً لـ ICMP إطلاقًا.
الحل العملي هو TCP ping: قياس زمن مصافحة TCP مع منفذ يجب أن يكون متاحًا في كل الأحوال. ومن الأهداف المناسبة:
- مستمعو موازن الأحمال على المنفذ 443 أو 80
- نقاط نهاية وحدة تحكم Ingress في Kubernetes
- خدمات NodePort (النطاق الافتراضي 30000-32767) إن كنت تعرضها
- خوادم Bastion وبوابات VPN على منافذ خدماتها
يتحقق فحص TCP من المسار نفسه الذي تسلكه الحركة الحقيقية، بما في ذلك مجموعات الأمان والمستمعون، دون فتح ICMP للعالم. وأبقِ على ICMP داخليًا حيث يُسمح به لفحص الاتصال بين العُقد وعبر الروابط الهجينة.
ما تغطيه مسابير Kubernetes وما لا تغطيه
يشغّل الـ kubelet مسابير liveness وreadiness وstartup على العقدة التي تستضيف الحاوية. وهي تجيب عن سؤال واحد: هل الحاوية سليمة من منظور تلك العقدة؟ ولا تخبرك إن كان بإمكان أي طرف آخر الوصول إليها.
| المشكلة | مسابير kubelet | مراقبة ping / TCP |
|---|---|---|
| تعليق عملية الحاوية | نعم | لا |
| إزالة الـ Pod من نقاط نهاية الخدمة | نعم | بشكل غير مباشر |
| تعذّر الوصول إلى Ingress أو موازن الأحمال | لا | نعم |
| فقدان العقدة اتصالها بالشبكة | لا | نعم |
| تعطل تبعية خارجية أو مسار NAT | لا | نعم، من الداخل |
| ارتفاع زمن الاستجابة في منطقة معينة | لا | نعم |
عند فشل مسبار liveness تُعاد تشغيل الحاوية بدلًا من تنبيهك. لذا راقب العُقد ونقاط نهاية Ingress والتبعيات الخارجية الحرجة عبر ping، واترك صحة الحاويات للمسابير. ولاحظ أن عناوين ClusterIP لا تستجيب عادةً لـ ICMP في وضع iptables الخاص بـ kube-proxy، فاختبر الخدمات عبر TCP.
نقاط القياس الخارجية مقابل المسابير الداخلية
تحتاج إلى الاثنين معًا. فالفحوص الداخلية، مثل نشر Prometheus Blackbox Exporter، تتحقق من المسارات بين الخدمات داخل الشبكة، ومن الخروج عبر NAT، ومن DNS الخاص. أما الفحوص الخارجية فتتحقق مما يعيشه عملاؤك فعلًا: DNS والتوجيه وموازن الأحمال وIngress.
تُجري مراقبة ping من UpScanX فحوص ICMP وTCP وUDP من أكثر من 15 موقعًا حول العالم، فتتضح المشكلات الإقليمية فورًا: إذا رصدت فرانكفورت وسنغافورة قفزة بمقدار 120 مللي ثانية بينما بقيت فرجينيا مستقرة، فاشتبه في التوجيه لا في العنقود. ويعتمد الإعداد النموذجي فاصلًا زمنيًا من 30 إلى 60 ثانية، ويُطلق التنبيه بعد فشلين أو ثلاثة متتالية من أكثر من موقع واحد.
الروابط الهجينة ومتعددة السحابات
تُعد شبكات VPN بين المواقع، ودوائر Direct Connect أو ExpressRoute، والأنفاق بين السحابات نقاطًا عمياء تقليدية. فقد يظهر النفق «يعمل» في وحدة التحكم بينما سحب BGP المسارات أو بلغ فقدان الحزم 3-5%. راقب عبر ping مضيفًا مستقرًا على كل طرف من كل رابط، وأطلق التنبيه عند التدهور المستمر لا عند الانقطاع الكامل فقط. وللاطلاع على أساسيات زمن الاستجابة وفقدان الحزم والتذبذب، راجع كيف تعمل مراقبة ping.
أهم النقاط
- تنقل السحابة وKubernetes مخاطر الشبكة إلى إعدادات تتحكم فيها أنت: مجموعات الأمان وNACL وNAT والربط بين الشبكات وDNS.
- توقّع أن يكون ICMP محظورًا افتراضيًا في معظم البيئات، واستخدم TCP ping مع موازنات الأحمال وIngress ومنافذ الخدمات.
- تفحص مسابير kubelet صحة الحاويات لا قابلية الوصول إليها، لذا راقب العُقد وIngress والتبعيات بشكل منفصل.
- اجمع بين المسابير الداخلية والفحوص الخارجية من مواقع متعددة للتمييز بين مشكلات العنقود ومشكلات التوجيه.
- أرسل التنبيهات إلى حيث ينظر فريقك أصلًا؛ إذ يدعم UpScanX البريد الإلكتروني وSlack وTelegram وMicrosoft Teams وWebhook.