port وtargetPort وcontainerPort بشكل صحيح، واختر بين ClusterIP وNodePort وLoadBalancer.","html":"شغّل kubectl get pods -o wide مرتين، مع rollout بينهما، وستجد كل عنوان IP مختلفًا. الـ Pods تُستبدل باستمرار: إصدارات جديدة، وإعادة جدولة، وتوسّع. كل ما كان يتذكّر عنوان IP لـ Pod صار يشير إلى لا شيء. الـ Service هو الشيء الثابت الذي تشير إليه بدلًا من ذلك.
apiVersion: v1\nkind: Service\nmetadata:\n name: notes-api\n labels:\n app.kubernetes.io/name: notes-api\nspec:\n selector:\n app.kubernetes.io/name: notes-api\n ports:\n - name: http\n port: 80\n targetPort: httpهذا ينشئ عنوان IP افتراضيًا واسم DNS، notes-api، يدومان ما دام الـ Service موجودًا. الاتصالات إليه تُوزَّع على الـ Pods التي يطابقها الـ selector الخاص به، وهو استعلام الـ labels نفسه الذي يستخدمه الـ Deployment. يتتبّع Kubernetes المجموعة الحالية من الـ Pods الجاهزة المطابقة في EndpointSlices ويحدّثها كلما جاءت Pods وذهبت. والعملاء لا يلاحظون شيئًا.
الـ ClusterIP ليس جهازًا، ولا تستمع عليه أي عملية. طبقة الشبكة في كل node (kube-proxy، أو بديل مبني على eBPF في كثير من الـ clusters) تبرمج قواعد تعيد كتابة الحزم المرسلة إلى عنوان IP الخاص بالـ Service ومنفذه لتذهب إلى أحد الـ Pods الجاهزة. لهذا لا تستطيع تنفيذ ping على عنوان IP الخاص بـ Service، ولا داعي للقلق حين لا يجيب: المنافذ المصرَّح بها هي وحدها الموجودة. ولهذا أيضًا لا يكلّف الـ Service شيئًا تقريبًا، فأنشئ واحدًا لكل حمل عمل يستقبل حركة.
هنا تعيش معظم أخطاء الـ Services.
\ncontainerPort في مواصفات الـ Pod هو المنفذ الذي تستمع عليه عمليتك: 3000. إنه معلوماتي، مثل EXPOSE، لكن تسميته (name: http) تتيح للكائنات الأخرى الإشارة إليه.targetPort في الـ Service هو المكان الذي تُسلَّم إليه الحركة على الـ Pod. يجب أن يطابق المكان الذي يستمع عليه التطبيق فعلًا. وهنا يستخدم الاسم http، الذي يُحلّ إلى 3000.port في الـ Service هو ما يتّصل به العملاء: 80.يعطي DNS الخاص بالـ cluster كل Service اسمًا بالشكل <service>.<namespace>.svc.cluster.local. من Pod في الـ namespace نفسه يكفي الاسم القصير notes-api؛ ومن namespace آخر استخدم notes-api.notes أو الاسم الكامل.
يحتاج notes-api إلى قاعدة بيانات، فأعطه واحدة بالطريقة نفسها. للتدرّب في kind، شغّل Postgres كـ Deployment بنسخة واحدة مع Service من نوع ClusterIP:
\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: notes-db\nspec:\n replicas: 1\n selector:\n matchLabels:\n app.kubernetes.io/name: notes-db\n template:\n metadata:\n labels:\n app.kubernetes.io/name: notes-db\n spec:\n containers:\n - name: postgres\n image: postgres:17\n env:\n - name: POSTGRES_USER\n value: notes\n - name: POSTGRES_PASSWORD\n value: notes # moved to a Secret in the next lesson\n - name: POSTGRES_DB\n value: notes\n ports:\n - name: postgres\n containerPort: 5432\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: notes-db\nspec:\n selector:\n app.kubernetes.io/name: notes-db\n ports:\n - name: postgres\n port: 5432\n targetPort: postgresالمضيف في DATABASE_URL الخاص بـ notes-api صار الآن notes-db، تمامًا كما كان db في Compose. والفاصل --- يفصل بين كائنين في ملف واحد.
| النوع | \nيمكن الوصول إليه من | \nاستخدمه لـ | \n
|---|---|---|
ClusterIP (الافتراضي) | \nداخل الـ cluster | \nالحركة بين الخدمات، مثل notes-api ← notes-db | \n
NodePort | \nعنوان IP لكل node على منفذ ضمن 30000–32767 | \nالاختبارات السريعة، أو كلبنة بناء لموازنات الأحمال الخارجية | \n
LoadBalancer | \nعنوان موازن أحمال سحابي | \nعرض خدمة واحدة للعموم على cluster مُدار | \n
وهناك أيضًا الـ Service من نوع headless، مع clusterIP: None. لا يحصل على عنوان IP افتراضي؛ بل يُرجع اسم الـ DNS الخاص به عناوين IP للـ Pods المفردة. تستخدمه قواعد البيانات والأنظمة العنقودية الأخرى حين يحتاج كل عضو إلى أن يُخاطَب مباشرة. لن تحتاج إليه لـ notes-api.
يُبنى LoadBalancer فوق النوعين الآخرين: ينشئ مزوّد السحابة موازن أحمال يحوّل في العادة إلى منافذ الـ nodes، وهذه تحوّل إلى الـ Service (وبعض الـ controllers يرسل الحركة مباشرة إلى عناوين IP الخاصة بالـ Pods بدلًا من ذلك). واحد لكل خدمة عامة يصبح مكلفًا ومتكرّرًا حين تكون لديك خدمات HTTP كثيرة؛ والدرس 5.4 يغطّي Gateway API، الذي يضع مسارات كثيرة خلف نقطة دخول واحدة.
kubectl apply -f k8s/\nkubectl get svc\nkubectl get endpointslices -l kubernetes.io/service-name=notes-api\nkubectl port-forward svc/notes-api 8080:80\ncurl localhost:8080/readyzالأمر port-forward يحفر نفقًا من منفذ محلي إلى الـ Service عبر الـ API server. إنه للتشخيص، لا للحركة الحقيقية. إذا لم يسرد الـ EndpointSlice أي عناوين، فالـ Service لا يطابق أي Pods جاهزة: قارن الـ selector بمخرجات kubectl get pods --show-labels، ثم تحقّق من الجاهزية.
مشكلتان صارتا ظاهرتين الآن في الـ YAML: كلمة مرور مكتوبة نصًّا صريحًا، وإعدادات مخلوطة داخل الـ Deployment. الدرس التالي يُخرج الاثنتين.
\n","toc":[{"id":"sec-1","text":"Service لـ notes-api","level":2},{"id":"sec-2","text":"ثلاثة منافذ، وثلاثة معانٍ","level":2},{"id":"sec-3","text":"إيجاد الـ Services بالاسم","level":2},{"id":"sec-4","text":"أنواع الـ Services","level":2},{"id":"sec-5","text":"الوصول إليه من حاسوبك","level":2}],"takeaways":["الـ Service يعطي مجموعة متغيّرة من الـ Pods عنوان IP افتراضيًا واسم DNS ثابتين، ويوزّع الاتصالات على الـ Pods الجاهزة التي يطابقها الـ selector الخاص به.","الحقلport هو ما يتّصل به العملاء على الـ Service؛ وtargetPort هو وجهة الحركة على الـ Pod، ويجب أن يطابق المنفذ الذي يستمع عليه الـ container.","داخل الـ cluster، تصل الـ Pods إلى الـ Service باسمه، مثل notes-db في الـ namespace نفسه أو notes-db.notes.svc.cluster.local من أي مكان.","استخدم ClusterIP للحركة الداخلية، وLoadBalancer لعرض خدمة واحدة عبر موازن أحمال سحابي، وNodePort للاختبار أساسًا.","الـ EndpointSlice الفارغ يعني أن الـ Service لا يطابق أي Pods جاهزة؛ تحقّق من الـ selector والجاهزية أولًا."],"further":[{"title":"Service","url":"https://kubernetes.io/docs/concepts/services-networking/service/"},{"title":"DNS for Services and Pods","url":"https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/"},{"title":"Use Port Forwarding to Access Applications in a Cluster","url":"https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/"}],"quiz":[{"q":"يستمع notes-api على 3000. الـ Service فيه port: 80 وtargetPort: 3000. أي عنوان تستخدمه الـ Pods الأخرى في الـ namespace نفسه؟
http://notes-api:3000","why":"المنفذ 3000 منفذ الـ Pod. عملاء الـ Service يتّصلون بالـ port الخاص بالـ Service، وهو 80."},{"text":"http://<pod-ip>:80","why":"عناوين IP الخاصة بالـ Pods تتغيّر مع كل استبدال، ولا شيء في الـ Pod يستمع على 80."},{"text":"http://notes-api (المنفذ 80)","why":"صحيح. اسم الـ Service يُحلّ عبر DNS الخاص بالـ cluster، والمنفذ 80 يُحوَّل إلى 3000 على Pod جاهز."},{"text":"http://localhost:80","why":"localhost هو الـ Pod المتّصِل نفسه، لا الـ Service."}],"answer":2},{"q":"الأمر kubectl get endpointslices -l kubernetes.io/service-name=notes-api لا يعرض أي endpoints، لكن ثلاثة Pods من notes-api في حالة Running. ما الذي تتحقّق منه أولًا؟
latest.","why":"الـ tags لا تؤثّر في مطابقة الـ Service."},{"text":"هل DNS الخاص بالـ cluster يعمل.","why":"الـ DNS يحلّ اسم الـ Service، لكن الـ endpoints تُحسب من الـ labels والجاهزية، باستقلال عن الـ DNS."}],"answer":0},{"q":"تحتاج إلى أن يكون notes-api قابلًا للوصول من الإنترنت على cluster مُدار في AWS، وهو الخدمة العامة الوحيدة. أي نوع Service يناسب؟
","options":[{"text":"ClusterIP","why":"الـ ClusterIP لا يمكن الوصول إليه إلا من داخل الـ cluster."},{"text":"NodePort، مع اتّصال المستخدمين بعنوان IP لأحد الـ nodes على المنفذ 30080","why":"هذا يعرض كل node على منفذ عالٍ وينكسر حين تُستبدل الـ nodes. إنه لبنة بناء، لا نقطة وصول عامة."},{"text":"Headless (clusterIP: None)","why":"الـ Services من نوع headless تعطي سجلات DNS لكل Pod، لأشياء مثل قواعد البيانات ذات الهويات الثابتة. لا تعرض شيئًا للخارج."},{"text":"LoadBalancer، الذي يجهّز موازن أحمال سحابيًا أمام الـ Service","why":"صحيح. لخدمة عامة واحدة هو الخيار الأبسط. ومع خدمات HTTP كثيرة ستتشارك نقطة دخول واحدة عبر Gateway API بدلًا من ذلك."}],"answer":3},{"q":"أي targetPort صحيح لـ container يصرّح بـ ports: [{ name: http, containerPort: 3000 }]؟
targetPort: 80، ليطابق منفذ الـ Service.","why":"الحقل targetPort هو المكان الذي تصل إليه الحركة داخل الـ Pod. لا شيء يستمع على 80 هناك."},{"text":"targetPort: http، اسم منفذ الـ container (أو 3000).","why":"صحيح. المنفذ المسمّى يستمر في العمل حتى لو غيّرت الرقم لاحقًا في مكان واحد."},{"text":"targetPort: notes-api، اسم الـ Deployment.","why":"الحقل targetPort يأخذ رقمًا أو اسم منفذ container، لا اسم كائن."},{"text":"targetPort: 30000، من نطاق NodePort.","why":"نطاق NodePort يخصّ nodePort، وهو حقل مختلف على جهة الـ node."}],"answer":1}],"exercise":{"kind":"spot-bug","language":"yaml","code":"apiVersion: v1\nkind: Service\nmetadata:\n name: notes-api\nspec:\n selector:\n app.kubernetes.io/name: notes-api\n ports:\n - port: 80\n targetPort: 80\n---\n# excerpt from the Deployment's Pod template\ncontainers:\n - name: api\n image: ghcr.io/skylane/notes-api:1.4.0\n ports:\n - containerPort: 3000","bugLines":[10],"title":"الـ endpoints موجودة، والطلبات تفشل","prompt":"الـ Service أدناه له ثلاثة endpoints، والـ Pods في حالتَي Running وReady، ومع ذلك يحصل curl notes-api من Pod آخر على connection refused في كل مرة. اختر السطر المسبّب.
السطر 10 يرسل الحركة إلى المنفذ 80 على الـ Pods، لكن notes-api يستمع على 3000، فيُرفض كل اتصال. وجّه targetPort إلى منفذ الـ container، ويفضَّل بالاسم حتى لا ينحرف أحدهما عن الآخر:
# Service\n ports:\n - port: 80\n targetPort: http\n# Pod template\n ports:\n - name: http\n containerPort: 3000