Spiro Stathakis نقل EKS إلى IPv6؛ واجهات المنصة ملأت شبكة IPv4 الصغيرة

الخلاصة

• شغّل Spiro Stathakis منصة طلبات isp6 على EKS مع ipFamily: ipv6، وأبقى شبكات IPv4 من حجم ‎/28 لتوافق الخدمات القديمة.
• استهلكت واجهات العقد الأساسية وواجهات نقاط الخدمة مزدوجة البروتوكول تلك المساحة، فوسّع الفريق الشبكات العامة إلى ‎/27 والخاصة إلى ‎/26.

كان تقليص IPv4 إلى أصغر شبكة فرعية تقبلها AWS إعلاناً عملياً عن اتجاه المنصة. يروي Spiro Stathakis تجربته بنفسه في RIPE Labs: استخدمت isp6 تخصيصها الخاص من IPv6 لحاويات منصة الطلبات على EKS، وتركت لـ IPv4 حيزاً صغيراً للتوافق. ثم وصلت واجهات البنية التحتية، فضاقت الشبكة قبل أن يصبح التخلص من الاعتماد القديم ممكناً.

حجم ‎/28 يعني 16 عنواناً حسابياً. لكن AWS تحتجز أول أربعة عناوين وآخر عنوان في كل شبكة IPv4 فرعية، فلا يبقى إلا 11 عنواناً قابلاً للاستخدام. ينسب Stathakis استهلاكها إلى الواجهة الأساسية لكل عقدة وواجهات نقاط الخدمة مزدوجة البروتوكول. وذكر أن الفريق نقل الشبكات العامة إلى ‎/27 والخاصة إلى ‎/26. لم ينشر كشفاً مؤرخاً بعدد الواجهات في كل شبكة، ولذلك لا يمكن استنتاج الرصيد المتبقي اليوم من حجم الشبكات وحده.

وثائق EKS الرسمية تضع حداً واضحاً لمعنى اختيار IPv6: تتلقى الحاويات والخدمات عناوين IPv6، لكن الحاوية التي تتصل بوجهة لا تدعم إلا IPv4 تستخدم عنواناً محلياً في العقدة، ثم يحوّل مكوّن الشبكة مصدر الاتصال إلى عنوان IPv4 الأساسي للعقدة. تبقى الخدمة القديمة قابلة للوصول، وقد يمر الاعتماد عليها من دون خطأ ظاهر. أما عائلة عناوين العنقود فتُحسم عند إنشائه ولا تُغيَّر بعد ذلك.

احتفظ فريق isp6 ببوابة NAT واحدة للمقاصد التي بقيت على IPv4. وعلى بعض نقاط AWS مزدوجة البروتوكول سمح بمرور IPv6 فقط إلى المنفذ 443، بحيث يفشل العميل الذي يختار سجل A بدلاً من الرجوع خفية إلى IPv4. وساعدت سجلات تدفق NAT على كشف المسارات التي لم تنتقل. معرفة حجم هذا الاعتماد الآن تحتاج جرداً مؤرخاً للشبكات والواجهات وعينة من تلك السجلات.

تجربة Stathakis تضع الاسم التسويقي جانباً وتفتح دفتر العناوين. يمكن للحاويات أن تعمل على IPv6 بالكامل، بينما تواصل العقد ونقاط الخدمة والمقاصد القديمة صرف عناوين IPv4. كانت ‎/28 خطة النية؛ عدد الواجهات كتب خطة التشغيل.