عرفنا أنّ الخدمات تكشف تطبيقاتنا، لكن كشف كل خدمة بموزّع أحمال منفصل مكلف ومعقّد. الـ Ingress يحلّ هذا بأناقة. درس متوسّط المستوى.
المشكلة: مداخل كثيرة
تخيّل تطبيقًا بعدّة خدمات: واجهة، وواجهة برمجة (API)، ولوحة تحكّم. لو كشفت كلًّا منها عبر خدمة LoadBalancer مستقلّة، لدفعت ثمن عدّة موزّعات أحمال وأدرت عدّة عناوين. نحتاج مدخلًا واحدًا ذكيًّا.
ما هو الـ Ingress؟
الـ Ingress كائن يوفّر نقطة دخول واحدة لترافيك HTTP و HTTPS القادم من خارج العنقود، ويوجّهه إلى الخدمات الداخلية المناسبة وفق قواعد تعتمد على:
- المضيف (Host): مثلًا
api.example.comإلى خدمة الـ API، وapp.example.comإلى الواجهة. - المسار (Path): مثلًا
/apiإلى خدمة والباقي إلى أخرى.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-svc
port:
number: 80
نقطة أساسية: يحتاج مُتحكِّمًا (Ingress Controller)
هنا يقع كثيرون في الخطأ: كائن الـ Ingress مجرّد مجموعة قواعد؛ لا يفعل شيئًا وحده. لتنفيذ هذه القواعد فعليًا، يجب أن يعمل في عنقودك مُتحكِّم Ingress (Ingress Controller) — وهو المكوّن الذي يقرأ قواعدك ويوجّه الترافيك بناءً عليها.
بعبارة أخرى: الـ Ingress يصف ماذا تريد، والمُتحكِّم هو من ينفّذه. إن لم يكن هناك مُتحكِّم، فلن تعمل قواعدك.
لماذا تستخدمه؟
- مدخل واحد بدل عدّة موزّعات أحمال — أوفر وأبسط.
- توجيه ذكي حسب المضيف والمسار.
- مكان مركزي لإدارة TLS/HTTPS لعدّة خدمات.
الخطوات التالية
بهذا اكتملت لبنات Kubernetes الأساسية: Pod و ReplicaSet و Deployment و Service و Namespace و Ingress. تاليًا ستنتقل إلى إدارة الإعدادات (ConfigMaps و Secrets)، والتطبيق العملي بنشر تطبيق كامل. راجع الخدمات وما هو Kubernetes؟.