الانتظار: الفنون الصغيرة التي يجب أن تتعلمها

في وقت سابق من هذا العام، في إحدى ورش عمل تحت عنواناختبار الطلب الخاص بك على Kubernetes مع GKE و GitHub الإجراءاتأواجه نفس المشكلة مرتين: يحتاج الخدمة A إلى الخدمة B، ولكن الخدمة A تبدأ أسرع من الخدمة B، ويفشل النظام.

الانتظار في Kubernetes

قد يبدو غريبًا الانتظار في Kubernetes. إن طبيعة تصحيح نفسية منصة Kubernetes هي واحدة من أكبر مزاياها. دعونا نفكر في اثنين من أدوات: تطبيق Python و قاعدة بيانات PostgreSQL.

يبدأ التطبيق بسرعة جداً ويحاول بطيئاً إنشاء اتصال إلى قاعدة البيانات، في حين أن قاعدة البيانات تبدأ بنفسها مع البيانات المتوفرة، فإن الاتصال لا يحدث.Failedالدولة .

بعد فترة من الوقت ، يطلب Kubernetes حالة البوكس التطبيقية. لأنها فشلت ، فإنه ينتهكها ويبدأ البوكس الجديد. في هذه المرحلة ، يمكن أن يحدث شيئان: البوكس التطبيقية لم تكن جاهزة حتى الآن ، ويعود إلى الربع الأول ، أو أنها جاهزة ، وتتصل التطبيق في النهاية.

لتسريع العملية ، يقدم Kubernetesاختبار Startup: :

startupProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

مع المحاكاة أعلاه ، ينتظر Kubernetes 10 ثانية في البداية قبل طلب حالة القفز.إذا فشل ، فإنه ينتظر 10 ثانية أخرى.إزالة وتكرار 30 مرات قبل أن يفشل بالتأكيد.

قد ترى أن HTTP/healthكوبنهاغن يقدم اثنين من الألعاباختبارإعدادات التكوين:httpGetأوexecالسبب الرئيسي هو مناسبة لتطبيقات الويب ، في حين أن السبب الرئيسي هو لتطبيقات أخرى.هذا يعني أننا بحاجة إلى معرفة ما هي أنواع المكونات التي تحتوي على pod وكيفية التحقق من حالةها ، بحسب ما يمكن.أنا لا خبير PostgreSQL ، لذلك كنت أبحث عن إجراء التحقق من حالة.Bitnami Helm Chartيبدو كما هو الحال عند تطبيقها:

startupProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - -e
      - exec pg_isready -U $PG_USER -h $PG_HOST -p $PG_PORT

يرجى ملاحظة أن السؤال أعلاه هو سهولة ، حيث يتجاهل بشكل سعيد اسم قاعدة البيانات و شهادة SSL.

يمكنك تحديد مدة تأخير طويلة في البدء ، ثم زيادة أقل. ومع ذلك ، كلما كانت المكونات متعددة ، كلما كان من الصعب تحديدها ، لأنك بحاجة إلى أن تكون خبير في كل من المكونات الأساسية.

سيكون من المفيد البحث عن بدائل.

منتدى4x

الخيارات الثنائية هي الأدوات التي تركز على الانتظار. منذ فترة طويلة، وجدتالانتظارهذا هو السبب، الفكرة بسيطة:

./wait-for هو نسخة مصممة لتنظيم خدمات مثل محطات docker.

./wait-forهو نسخة مصممة لتنظيم خدمات مثل محطات Docker.shوalpineمتوافق

إليك كيفية الانتظار لـ HTTP API:

sh -c './wait-for http://my.api/health -- echo "The api is up! Let's use it"'

لقد حصلت على العمل، ولكن في ذلك الوقت، كنت بحاجة إلى نسخ الكتابة والبحث عن التحديثات يدويًا.

4xيلعب الوظيفة نفسها، ولكن متوفر كحد أقصى، ويقدم المزيد من الخدمات للانتظار: HTTP، DNS، قواعد البيانات، ومواقع الرسائل.

أي أداة تستخدمها، يمكنك استخدامها داخلاكسسوارات init: :

قد يكون لديك Pod العديد من المكونات التي تعمل على التطبيقات داخلها، ولكن قد يكون لديك أيضًا واحد أو أكثر من المكونات init التي يتم تشغيلها قبل بدء المكونات التطبيقية.

المكونات الأساسية هي المكونات الأساسية، باستثناء:

يجب أن تنتهي كل مستودع init بنجاح قبل بدء المستودع التالي.

قد يكون لديك Pod العديد من المكونات التي تعمل على التطبيقات داخلها، ولكن قد يكون لديك أيضًا واحد أو أكثر من المكونات init التي يتم تشغيلها قبل بدء المكونات التطبيقية.

المكونات الأساسية هي المكونات الأساسية، باستثناء:

يجب أن تنتهي كل مستودع init بنجاح قبل بدء المستودع التالي.

تخيل التاليPodهذا يعتمد على PostgreSQLDeployment: :

apiVersion: v1
kind: Pod
metadata:
  labels:
    type: app
    app: recommandations
spec:
  containers:
    - name: recommandations
      image: recommandations:latest
      envFrom:
        - configMapRef:
            name: postgres-config

التطبيق هو Python ويبدأ بسرعة كبيرة. يحاول الانضمام إلى قاعدة بيانات PostgreSQL. لسوء الحظ، لم يتم الانتهاء من إنشاء قاعدة بيانات، لذلك لا يتم الانضمام، ويمكن Kubernetes إعادة تشغيل القاعدة.

يمكننا إصلاحها معinitContainerوسيتم إرسال مستودع:

apiVersion: v1
kind: Pod
metadata:
  labels:
    type: app
    app: recommandations
spec:
  initContainers:
    - name: wait-for-postgres
      image: atkrad/wait4x:3.1
      command:
        - wait4x
        - postgresql
        - postgres://$(DATABASE_URL)?sslmode=disable
      envFrom:
        - configMapRef:
            name: postgres-config
  containers:
    - name: recommandations
      image: recommandations:latest
      envFrom:
        - configMapRef:
            name: postgres-config

في المادة السابقة، فإنinitContainerلا تتوقف حتى تتمكن قاعدة البيانات من قبول اتصالات.recommandationsيمكن أن تبدأ Kubernetes لا تحتاج إلى إلغاءPodكما هو الحال في الإعدادات السابقة! يؤدي ذلك إلى أقل من الوثائق وربما أقل من الإشارات.

عندما يصبح الانتظار واضحا

أعلاه هو تحسين صغير، ولكن يمكنك القيام به دون ذلك.في الحالات الأخرى، يصبح الانتظار واجبًا.

• الطائرات تطبق إعلان على الجانب Kubernetes
• في الخطوة التالية ، يتم تشغيل الاختبار
• عندما تبدأ الاختبار قبل قراءة التطبيق ، فإنه لا يتحقق.

نحن بحاجة إلى الانتظار حتى النقطة الخلفية جاهزة قبل اختبارنا.wait4xمن أجل الانتظار لـPodللحصول على طلبات قبل بدء الاختبارات:

      - name: Wait until the application has started
        uses: addnab/docker-run-action@v3                                       #1
        with:
          image: atkrad/wait4x:latest
          run: wait4x http ${{ env.BASE_URL }}/health --expect-status-code 200  #2

1. GitHub Action يسمح بإجراء محطات. قد تم تحميل Go binary بدلا من ذلك.
2. انتظر حتى يعود نقطة نهاية /صحة إلى رمز رد 200.

النتيجة

طريقة رائعة لتجنب إعادة تشغيل غير ضرورية عند بدء الخدمات التي تعتمد على بعضها البعض.initContainer. .wait4xهو أداة يمكن استخدامها في سياقات أخرى.هذه هي الآن جزء من حزام الأداة.

To go further:

• 4x
• لذلك، هل تحتاج إلى الانتظار لبعض الموارد Kubernetes؟

نشر في A Java Geek في أبريل 20th, 2025