Docker & Kubernetes for Developers · Pelajaran

Penemuan Layanan dan DNS di K8s

Pelajari cara Kubernetes menangani penemuan layanan dan resolusi DNS untuk komunikasi antarlayanan.

Pelajaran 3 dari 411 langkah

Penemuan Layanan dan DNS di K8s adalah pelajaran Docker & Kubernetes for Developers gratis di CoddyKit. Ini adalah pelajaran 3 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Docker & Kubernetes for Developers, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Docker & Kubernetes for Developers mencakup 4 pelajaran total.

Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.

Intro to Service Discovery

Welcome to Service Discovery & DNS in K8s! In a dynamic Kubernetes cluster, Pods are constantly created, destroyed, and moved, leading to ever-changing IP addresses.

How do applications running in one Pod find and communicate with applications in another Pod or Service?

This is where Service Discovery comes in. It's how services find each other without needing to know their specific, ephemeral IP addresses.

The Role of DNS in K8s

You might already know about DNS (Domain Name System) on the internet. It translates human-readable names like google.com into IP addresses.

Kubernetes uses a similar concept internally. Instead of relying on unstable Pod IPs, K8s assigns stable DNS names to its Services.

This allows your applications to connect to other services using simple, consistent names.

CoreDNS: The K8s DNS Server

Every Kubernetes cluster comes with its own DNS server, typically CoreDNS (or sometimes kube-dns in older versions).

CoreDNS runs as a Pod within your cluster and is responsible for resolving all internal Kubernetes service names to their corresponding cluster IP addresses.

It's automatically configured for you when you set up your cluster.

How Pods Get DNS Config

When a Pod starts, Kubernetes automatically injects DNS configuration into it.

  • Each Pod's /etc/resolv.conf file is updated to point to the cluster's CoreDNS Service IP.
  • It also includes search paths, allowing you to use shorter service names.

This means any application inside a Pod can immediately use the cluster's DNS for name resolution.

Service DNS Names

When you create a Kubernetes Service (e.g., a ClusterIP Service), CoreDNS automatically creates a DNS record for it.

The most common format for a Service's DNS name within its own namespace is simply: <service-name>.

For example, a service named my-web-app in the default namespace can be reached by other Pods in the same namespace using just my-web-app.

Example: Same-Namespace Access

Let's say you have a deployment hello-app and a service hello-service in the default namespace. Any other Pod in default can reach it via hello-service.

Here's a simple example of a Deployment and Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 1
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello-container
        image: busybox
        command: ["sh", "-c", "while true; do echo Hello K8s; sleep 5; done"]

---

apiVersion: v1
kind: Service
metadata:
  name: hello-service
spec:
  selector:
    app: hello
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Testing Same-Namespace DNS

After applying the YAML from the previous scene, you can test service discovery. First, create a temporary Pod (e.g., debug-pod) in the same namespace.

Then, exec into debug-pod and try to ping the service:

  • kubectl run debug-pod --image=busybox --restart=Never --rm -it --command -- sh
  • Inside the pod: ping hello-service

You should see the hello-service ClusterIP being resolved!

Cross-Namespace DNS (FQDN)

What if your services are in different namespaces? Kubernetes uses a Fully Qualified Domain Name (FQDN) format:

<service-name>.<namespace-name>.svc.cluster.local

For convenience, if the Pod's namespace is in its DNS search path (which it usually is), you can often use a shorter form:

<service-name>.<namespace-name>

This allows clear and unambiguous communication across different parts of your application.

Example: Cross-Namespace Access

Let's imagine a backend-service in the prod namespace. From a Pod in the default namespace, you'd access it like this:

ping backend-service.prod

Kubernetes DNS handles the resolution, directing traffic to the correct service, even across namespaces.

This provides strong isolation while still enabling communication where needed.

Quick Check

Which of the following statements are TRUE regarding Kubernetes Service Discovery and DNS?

Recap: Service Discovery & DNS

Great job! In this lesson, you learned how Kubernetes handles service discovery and DNS resolution for internal communication:

  • Pods have ephemeral IPs, requiring a stable discovery mechanism.
  • CoreDNS is the cluster's internal DNS server.
  • Services get stable DNS names, resolvable by other Pods.
  • Pods are automatically configured to use the cluster's DNS.
  • You can access services in the same namespace by name or in other namespaces using FQDNs.

This powerful system ensures your applications can always find each other reliably!

Gratis untuk memulai

Belajar Docker & Kubernetes for Developers dengan tutor AI — gratis

Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.

Kursus
12
Pelajaran
48

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Penemuan Layanan dan DNS di K8s” gratis?

Ya — teks lengkap “Penemuan Layanan dan DNS di K8s” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Docker & Kubernetes for Developers, upgrade ke CoddyKit PRO. Kursus Docker & Kubernetes for Developers mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Penemuan Layanan dan DNS di K8s”?

Pelajari cara Kubernetes menangani penemuan layanan dan resolusi DNS untuk komunikasi antarlayanan. Kamu berlatih Docker & Kubernetes for Developers dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Docker & Kubernetes for Developers?

Tidak diperlukan pengalaman sebelumnya. Docker & Kubernetes for Developers di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 3 dari 4.

Berapa lama pelajaran “Penemuan Layanan dan DNS di K8s” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Docker & Kubernetes for Developers ini?

Ya. Setiap pelajaran Docker & Kubernetes for Developers menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

  1. Ingress dan Perutean Kubernetes
  2. Mengimplementasikan Kebijakan Jaringan
  3. Penemuan Layanan dan DNS di K8s
  4. Terminasi TLS dan Pengamanan Ingress dengan HTTPS
← Kembali ke Docker & Kubernetes for Developers