0Pricing
Linux Networking & TCP/IP for Developers · บทเรียน

การค้นหาบริการและ DNS ใน Kubernetes

เรียนรู้ว่าคอนเทนเนอร์ค้นหากันเองได้อย่างไร ตั้งแต่ DNS ของคลัสเตอร์ ออบเจ็กต์ Service ไปจนถึงกระบวนการแปลงชื่อที่ทำให้ไมโครเซอร์วิสเรียกถึงกันได้ด้วยชื่อ

การค้นหาบริการและ DNS ใน Kubernetes เป็นบทเรียน Linux Networking & TCP/IP for Developers ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Linux Networking & TCP/IP for Developers และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Linux Networking & TCP/IP for Developers มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

The Discovery Problem

Container IPs are ephemeral — pods restart and get new addresses constantly. Hardcoding IPs is impossible.

Service discovery lets workloads find each other by stable names instead of changing IPs.

The Service Abstraction

A Kubernetes Service provides a stable virtual IP (ClusterIP) and DNS name that load-balances across a set of pods selected by labels.

apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector:
    app: orders
  ports:
    - port: 80

Cluster DNS

Every cluster runs a DNS server (CoreDNS). It automatically creates records for each Service so workloads can resolve them by name.

The DNS Naming Scheme

Services follow a predictable FQDN pattern:

service.namespace.svc.cluster.local

Within the same namespace, just orders works. Across namespaces use orders.payments.

curl http://orders.payments.svc.cluster.local

How a Pod Resolves Names

Each pod's /etc/resolv.conf points at the cluster DNS and includes search domains, so short names expand to full Service FQDNs automatically.

cat /etc/resolv.conf

ClusterIP Load Balancing

A ClusterIP is virtual — kube-proxy programs iptables or IPVS rules so traffic to it is distributed across the healthy backing pods. Clients never see individual pod IPs.

Headless Services

Set clusterIP: None for a headless Service. DNS then returns the individual pod IPs directly, which is ideal for stateful sets and client-side load balancing.

spec:
  clusterIP: None
  selector:
    app: db

Endpoints and EndpointSlices

Behind each Service, Kubernetes maintains EndpointSlices listing the ready pod IPs. As pods come and go, these update so DNS and routing stay current.

kubectl get endpointslices

Resolving from Inside a Pod

You can debug discovery by running nslookup from a pod to verify a Service name resolves to its ClusterIP.

kubectl exec -it shell -- nslookup orders

External Name Services

An ExternalName Service maps a cluster DNS name to an outside hostname via a CNAME, letting you reference external systems with cluster-internal names.

spec:
  type: ExternalName
  externalName: api.example.com

Common Discovery Failures

When name resolution fails, check:

  • Label selector mismatch (no endpoints)
  • Wrong namespace in the FQDN
  • CoreDNS pods unhealthy
  • NetworkPolicy blocking DNS (port 53)

Quick Check

Test your service discovery knowledge.

Recap

You now understand container service discovery:

  • Services give stable ClusterIPs and DNS names
  • CoreDNS resolves service.namespace.svc.cluster.local
  • EndpointSlices track ready pods
  • Headless and ExternalName Services for special cases
  • Debug with nslookup from inside pods

This builds on your Docker network modes and Kubernetes networking basics.

คำถามที่พบบ่อย

บทเรียน “การค้นหาบริการและ DNS ใน Kubernetes” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การค้นหาบริการและ DNS ใน Kubernetes” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Linux Networking & TCP/IP for Developers ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Linux Networking & TCP/IP for Developers มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การค้นหาบริการและ DNS ใน Kubernetes”

เรียนรู้ว่าคอนเทนเนอร์ค้นหากันเองได้อย่างไร ตั้งแต่ DNS ของคลัสเตอร์ ออบเจ็กต์ Service ไปจนถึงกระบวนการแปลงชื่อที่ทำให้ไมโครเซอร์วิสเรียกถึงกันได้ด้วยชื่อ คุณปฏิบัติ Linux Networking & TCP/IP for Developers ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Linux Networking & TCP/IP for Developers หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Linux Networking & TCP/IP for Developers บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การค้นหาบริการและ DNS ใน Kubernetes” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Linux Networking & TCP/IP for Developers นี้ได้ไหม

ได้ บทเรียน Linux Networking & TCP/IP for Developers ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. โหมดเครือข่ายของ Docker
  2. พื้นฐานเครือข่าย Kubernetes
  3. นโยบายเครือข่ายในคอนเทนเนอร์
  4. การค้นหาบริการและ DNS ใน Kubernetes
← กลับไปที่ Linux Networking & TCP/IP for Developers