تمثل التطبيقات الأحادية القديمة غالباً عنق زجاجة معماري كبير. بينما تفضل الصناعة بشدة الخدمات المصغرة، لا تزال العديد من المؤسسات تعتمد على أنظمة أحادية قوية ولكن جامدة. يعد نقل هذه الأنظمة إلى بنية الخدمات المصغرة جهداً عالي المخاطر ويتطلب جهداً كبيراً. ومع ذلك، لا يتعين عليك الاختيار بين إعادة الكتابة بالكامل وقبول قيود الأنظمة القديمة. هنا يأتي دور Istio وقدرات حقن الجار Sidecar القوية الخاصة به.
من خلال حقن وكيل Envoy كجار Sidecar في حاويات Pod الخاصة بنظامك الأحادي، يمكنك إدخال قدرات شبكة الخدمات—مثل mTLS، وإدارة حركة المرور، والرؤية—دون تغيير سطر واحد من كود التطبيق. يستكشف هذا المنشور الأنماط التقنية واستراتيجيات الأتمتة المطلوبة لتنفيذ ذلك بفعالية.
فهم آلية حقن الجار Sidecar
تكمن أتمتة Istio الأساسية في mutatingwebhookconfiguration. عند إنشاء Pod جديد في مساحة اسم Kubernetes مُعلّمة لحقن Istio، يقوم الخطاف (webhook) باعتراض مواصفات الـ Pod وتعديله قبل أن يعين المخطط عقدة. يضيف حاوية Envoy (الجار Sidecar) وحقن التكوين اللازم.
بالنسبة للأنظمة الأحادية القديمة، هذا أمرٌ يغير قواعد اللعبة. يبقى النظام الأحادي دون تغيير، لكن طبقة الشبكة تصبح ذكية. يمكنك التحكم في حركة المرور الداخلة، وفرض تحديد معدل الطلبات، وجمع آثار موزعة عبر بنيتك التحتية.
تسمية مساحة الاسم المستهدفة
أبسط طريقة لتمكين الحقن هي تسمية مساحة الاسم بالكامل. بينما تكون هذه الطريقة فعالة للخدمات المصغرة الجديدة، قد تكون هذه النهج الشامل عدوانياً جداً لنظام أحادي معقد يشارك البنية التحتية مع مكونات قديمة حرجة أخرى.
# Label the namespace to enable injection
kubectl label namespace legacy-app-ns istio-injection=enabledومع ذلك، غالباً ما يُفضل نهج أكثر دقة للاستقرار. بدلاً من تسمية مساحة الاسم، يمكنك إضافة تعليقات توضيحية (annotations) لحاويات Pod أو عمليات النشر المحددة. يضمن ذلك حصول أحمال العمل المحددة التي تمثل نظامك الأحادي فقط على الجار Sidecar، تاركاً موارد القديمة المشتركة الأخرى دون مساس.
أتمتة الحقن عبر Helm و CI/CD
التدخل اليدوي في عمليات النشر في بيئة الإنتاج هو مصدر للأخطاء. لتوسيع نطاق هذا النمط، الأتمتة هي المفتاح. إذا كنت تستخدم Helm لإدارة نشر نظامك الأحادي، يمكنك تبسيط عملية الحقن.
أولاً، تأكد من أن علامة istio-injection نشطة في عنقودك. ثم، انشر تطبيقك. إذا كنت تستخدم مشغل Istio أو مخططات Helm الخاصة بـ Istio، يحدث الحقن تلقائياً عند إنشاء الـ Pod.
# Deploy the legacy application
helm install legacy-monolith ./charts/monolith \
--namespace legacy-app-ns \
--set service.type=ClusterIPبعد النشر، تحقق من أن الجار Sidecar قد تم حقنه بشكل صحيح عن طريق التحقق من حالة الـ Pod.
kubectl get pods -n legacy-app-ns -o wideيجب أن ترى حاويتين تعملان: حاوية التطبيق الخاصة بك وحاملة istio-proxy.
التعامل مع قيود الشبكات القديمة
غالباً ما تحتوي الأنظمة الأحادية القديمة على عناوين IP ثابتة أو تعتمد على سلوكيات شبكية محددة قد تتعارض مع آليات اعتراض وكيل Envoy. للتخفيف من ذلك، يجب عليك تكوين قواعد iptables بعناية داخل الجار Sidecar.
بشكل افتراضي، تستخدم Istio موارد SidecarIngress و SidecarEgress للتحكم في حركة المرور التي يتم وسيطتها. بالنسبة للنظام الأحادي، تريد عادةً وسيط جميع حركة المرور الواردة ولكن السماح بالاتصالات المباشرة الصادرة إلى قواعد البيانات القديمة أو واجهات برمجة التطبيقات (APIs) التابعة لجهات خارجية لتجنب ارتفاعات في زمن الاستجابة.
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: legacy-sidecar-config
namespace: legacy-app-ns
spec:
workloadSelector:
labels:
app: legacy-monolith
egress:
- hosts:
- "./*" # Allow all outbound traffic
- "istio-system/*"
ingress:
- port:
number: 8080
protocol: HTTP
name: http
defaultEndpoint: "127.0.0.1:8080"الخاتمة
اعتماد شبكة خدمات للأنظمة الأحادية القديمة لا يتعلق بإصلاح الكود؛ بل يتعلق بإصلاح طبقة الشبكة. من خلال الاستفادة من أنماط حقن الجار Sidecar في Istio، تحصل على أمان ورؤية على مستوى المؤسسات مع الحفاظ على سلامة منطق أعمالك الحالي. سواء استخدمت علامات على مستوى مساحة الاسم أو تعليقات توضيحية دقيقة، فإن المفتاح هو الأتمتة. من خلال دمج هذه الأنماط في خطوط أنابيب CI/CD الخاصة بك، يمكنك تحديث بنيتك التحتية تدريجياً، مما يقلل من المخاطر ويمهد الطريق للتغييرات المعمارية المستقبلية. ابدأ بشكل صغير، راقب التأثير، ودع الشبكة تقوم بالعمل الشاق.