البداية السريعة لـ Envoy Gateway: مرّر أول طلب لديك خلال 10 دقائق

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

المتطلبات المسبقة

أنت بحاجة إلى Kubernetes cluster واحد عامل على الأقل، مثل:

• محليًا: kind و minikube و k3d
• سحابيًا: EKS و GKE و AKS
• Home lab: حتى K3s + MetalLB تعمل

وستحتاج أيضًا إلى:

• kubectl
• helm
• Cluster يستطيع توفير عنوان LoadBalancer، أو Cluster لا تمانع أن تستخدم فيه port-forward

⚠️ إذا كان الـ cluster لديك لا يدعم LoadBalancer، فالوثائق الرسمية توصي بإقرانه مع MetalLB. عدم وجود عنوان خارجي ليس نهاية العالم، ستختبر فقط عبر port-forward بدلًا من ذلك.

الخطوة 1: تثبيت Envoy Gateway

ثبّت مستوى التحكم:

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.7.0 \
  -n envoy-gateway-system \
  --create-namespace

انتظر حتى يصبح جاهزًا:

kubectl wait --timeout=5m -n envoy-gateway-system \
  deployment/envoy-gateway \
  --for=condition=Available

بعد اكتمال ذلك، سيكون Envoy Gateway controller يعمل داخل الـ cluster. ويمكنه الآن قراءة موارد Gateway API وتوليد إعدادات Envoy المقابلة.

الخطوة 2: طبّق موارد البداية السريعة الرسمية

يوفر الـ repo الرسمي مثالًا مجمّعًا يتضمن:

• GatewayClass
• Gateway
• HTTPRoute
• تطبيق backend تجريبي

طبّقه مباشرة:

kubectl apply -f \
  https://github.com/envoyproxy/gateway/releases/download/v1.7.0/quickstart.yaml \
  -n default

فكّر في هذا على أنه الفريق الرسمي يجهز لك مشهد demo كامل. شغّله أولًا، ثم فكّكه لاحقًا.

الخطوة 3: تحقق أن المرور يمر فعليًا

الخيار A: الـ Cluster لديه LoadBalancer

احصل على عنوان Gateway:

export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')

أرسل طلبًا:

curl --verbose \
  --header "Host: www.example.com" \
  http://$GATEWAY_HOST/get

إذا حصلت على HTTP 200، فهذا يعني:

• أن Gateway يعمل كـ ingress حقيقي
• وأن HTTPRoute ارتبط بنجاح
• وأن الخدمة الخلفية يتم التوجيه إليها بشكل صحيح

الخيار B: لا يوجد LoadBalancer، استخدم Port-Forward

اعثر على خدمة Envoy:

export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system \
  --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg \
  -o jsonpath='{.items[0].metadata.name}')

حوّل المنفذ المحلي 8888 إلى منفذ Gateway 80:

kubectl -n envoy-gateway-system port-forward service/${ENVOY_SERVICE} 8888:80

وفي terminal آخر:

curl --verbose \
  --header "Host: www.example.com" \
  http://localhost:8888/get

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

أين تنظر عندما يتعطل شيء

أكثر المشاكل شيوعًا ليست أن Envoy Gateway معطوب، بل أن حلقة واحدة من السلسلة لم ترتبط جيدًا:

أوامر مفيدة:

kubectl get pods -n envoy-gateway-system
kubectl get gatewayclass
kubectl get gateway -A
kubectl get httproute -A
kubectl get svc,pod -n default

وللتعمّق أكثر في حالة Gateway:

kubectl get gateway/eg -o yaml

أهم الأشياء التي يجب فحصها:

• status.addresses
• حالات الـ Listener
• ما إذا كانت الـ routes قد تم قبولها

ماذا فعلت فعليًا الآن

أنت نفذت فقط بضعة أوامر، لكنك أنجزت سلسلة كاملة من البداية إلى النهاية:

1. ثبّت Envoy Gateway
2. أنشأت GatewayClass لإخبار الـ cluster أي gateway controller يجب استخدامه
3. أنشأت Gateway يصرّح بمنفذ ingress والبروتوكول
4. أنشأت HTTPRoute يوجّه المرور إلى خدمة backend
5. قام Envoy Gateway بترجمة هذه التصريحات إلى إعدادات يستطيع Envoy Proxy تنفيذها

ولهذا تحديدًا تستحق Gateway API الاستخدام. أنت تكتب موارد Kubernetes، ولا تدير كومة من ملفات إعدادات البروكسي يدويًا.

الخطوة التالية

الآن وبعد أن أصبح أول طلب يمر لديك، تشرح المقالة التالية وظيفة كل واحد من هذه الموارد فعليًا لبناء النموذج الذهني الصحيح: 👉 المفاهيم الأساسية