Tentang penemuan layanan

Dokumen ini menjelaskan cara penemuan layanan di Google Kubernetes Engine (GKE) menyederhanakan pengelolaan aplikasi dan cara memperluas penemuan layanan di luar satu cluster menggunakan cakupan Cloud DNS, Layanan Multi-cluster (MCS), dan Service Directory.

Dokumen ini ditujukan untuk pengguna, Developer, dan Admin serta arsitek GKE. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami rujuk dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE Enterprise umum.

Sebelum membaca dokumen ini, pastikan Anda memahami konsep berikut:

Ringkasan

Penemuan layanan adalah mekanisme yang memungkinkan layanan dan aplikasi menemukan dan berkomunikasi satu sama lain secara dinamis tanpa meng-hardcode alamat IP atau konfigurasi endpoint. Penemuan layanan membantu memastikan bahwa aplikasi selalu memiliki akses ke alamat IP Pod terbaru, bahkan saat Pod dijadwalkan ulang atau Pod baru ditambahkan. GKE menawarkan beberapa cara untuk mengimplementasikan penemuan layanan, termasuk kube-dns, deployment kube-dns kustom, dan Cloud DNS. Anda dapat mengoptimalkan lebih lanjut performa DNS dengan NodeLocal DNSCache.

Manfaat penemuan layanan

Penemuan layanan memberikan manfaat berikut:

  • Pengelolaan aplikasi yang disederhanakan: penemuan layanan menghilangkan kebutuhan untuk meng-hardcode alamat IP dalam konfigurasi aplikasi Anda. Aplikasi berkomunikasi menggunakan nama Service logis, yang secara otomatis di-resolve ke alamat IP Pod yang benar. Pendekatan ini menyederhanakan konfigurasi, terutama di lingkungan dinamis tempat alamat IP Pod dapat berubah karena penskalaan atau penjadwalan ulang.
  • Penskalaan dan ketahanan yang disederhanakan: penemuan layanan menyederhanakan penskalaan dengan memisahkan konsumen layanan dari alamat IP Pod, yang sering berubah. Saat aplikasi Anda diskalakan, atau jika Pod gagal dan diganti, Kubernetes akan otomatis memperbarui Pod yang tersedia untuk menerima traffic untuk Layanan tertentu. Penemuan layanan membantu memastikan bahwa permintaan ke nama Layanan yang stabil hanya diarahkan ke Pod yang sehat, sehingga aplikasi Anda dapat menskalakan atau memulihkan dari kegagalan tanpa intervensi manual atau konfigurasi ulang klien.
  • Ketersediaan tinggi: GKE menggunakan load balancing bersama dengan penemuan layanan untuk membantu memastikan ketersediaan tinggi dan meningkatkan responsivitas aplikasi Anda, bahkan saat beban berat.

Load balancing dengan penemuan layanan

GKE membantu memastikan ketersediaan tinggi untuk aplikasi Anda dengan menggabungkan berbagai tingkat load balancing dengan penemuan layanan.

  • Layanan Internal: untuk layanan yang hanya dapat diakses dalam cluster, dataplane GKE (kube-proxy atau Cilium) bertindak sebagai load balancer. Load balancer mendistribusikan traffic masuk secara merata ke beberapa Pod yang berfungsi dengan baik, sehingga mencegah kelebihan beban dan membantu memastikan ketersediaan tinggi.
  • Layanan Eksternal: untuk layanan yang perlu dapat diakses dari luar cluster, GKE menyediakan Load Balancer Google Cloud . Load balancer ini mencakup Load Balancer eksternal Google Cloud untuk akses internet publik dan Load Balancer internal Google Cloud untuk akses dalam jaringan Virtual Private Cloud Anda. Load balancer ini mendistribusikan traffic di seluruh node di cluster Anda. Dataplane di setiap node kemudian merutekan lebih lanjut traffic ke Pod yang sesuai.

Dalam skenario internal dan eksternal, penemuan layanan terus memperbarui daftar Pod yang tersedia untuk setiap Layanan. Update berkelanjutan ini membantu memastikan bahwa dataplane (untuk layanan internal) dan load balancer Google Cloud (untuk layanan eksternal) mengarahkan traffic hanya ke instance yang sehat.

Kasus penggunaan untuk penemuan layanan

Berikut adalah kasus penggunaan umum untuk penemuan layanan:

  • Arsitektur microservice: dalam arsitektur microservice, aplikasi sering kali terdiri dari banyak layanan kecil yang independen dan perlu berinteraksi. Penemuan layanan memungkinkan aplikasi ini saling menemukan dan bertukar informasi, bahkan saat cluster diskalakan.
  • Mengaktifkan deployment tanpa waktu henti dan meningkatkan ketahanan: Penemuan layanan memfasilitasi update tanpa waktu henti untuk aplikasi, termasuk peluncuran terkontrol dan deployment canary. Fitur ini mengotomatiskan penemuan versi layanan baru dan mengalihkan traffic ke versi tersebut, yang membantu mengurangi waktu henti selama deployment dan memastikan transisi yang lancar bagi pengguna. Penemuan layanan juga meningkatkan ketahanan. Jika Pod gagal di GKE, Pod baru akan di-deploy, dan Penemuan layanan akan mendaftarkan Pod baru serta mengalihkan lalu lintas ke Pod tersebut, sehingga membantu meminimalkan downtime aplikasi.

Cara kerja penemuan layanan

Di GKE, aplikasi sering kali terdiri dari beberapa Pod yang perlu menemukan dan berkomunikasi satu sama lain. Penemuan layanan menyediakan kemampuan ini dengan menggunakan Domain Name System (DNS). Mirip dengan cara Anda menggunakan DNS untuk menemukan situs di internet, Pod di cluster GKE menggunakan DNS untuk menemukan dan terhubung dengan layanan menggunakan nama Service-nya. Pendekatan ini memungkinkan Pod berinteraksi secara efektif, di mana pun Pod berjalan di cluster, dan memungkinkan aplikasi berkomunikasi menggunakan nama layanan yang konsisten, bukan alamat IP yang tidak stabil.

Cara Pod melakukan resolusi DNS

Pod di cluster GKE me-resolve nama DNS untuk Layanan dan Pod lainnya menggunakan kombinasi data DNS yang dibuat secara otomatis dan konfigurasi DNS lokalnya.

Nama DNS layanan

Saat Anda membuat Layanan Kubernetes, GKE akan otomatis menetapkan nama DNS untuknya. Nama ini mengikuti format yang dapat diprediksi, yang dapat digunakan oleh Pod mana pun di cluster untuk mengakses Layanan:

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

Domain cluster default adalah cluster.local, tetapi Anda dapat menyesuaikan domain saat membuat cluster. Misalnya, Layanan yang diberi nama my-web-app di namespace default akan memiliki nama DNS my-web-app.default.svc.cluster.local.

Peran /etc/resolv.conf

Untuk menyelesaikan nama DNS ini, Pod mengandalkan file /etc/resolv.conf-nya. File konfigurasi ini memberi tahu Pod server nama mana yang harus mengirim kueri DNS-nya. Alamat IP server nama yang tercantum dalam file ini bergantung pada fitur DNS tertentu yang diaktifkan di cluster GKE Anda. Tabel berikut menguraikan IP server nama yang digunakan Pod, berdasarkan konfigurasi Anda:

Cloud DNS untuk GKE NodeLocal DNSCache Nilai server nama `/etc/resolv.conf`
Aktif Aktif `169.254.20.10`
Aktif Nonaktif `169.254.169.254`
Nonaktif Aktif Alamat IP Layanan `kube-dns`
Nonaktif Nonaktif Alamat IP Layanan `kube-dns`

Konfigurasi ini membantu memastikan bahwa kueri DNS dari Pod diarahkan ke komponen yang benar:

  • NodeLocal DNSCache: menyediakan pencarian lokal yang cepat di node.
  • IP server metadata (169.254.169.254): digunakan saat Cloud DNS untuk GKE diaktifkan tanpa NodeLocal DNSCache. Kueri DNS diarahkan ke alamat IP ini, yang digunakan Cloud DNS untuk mencegat dan menangani permintaan DNS.
  • kube-dns Alamat IP layanan: digunakan untuk resolusi dalam cluster standar saat Cloud DNS untuk GKE dinonaktifkan.

Arsitektur DNS di GKE

GKE menyediakan arsitektur yang fleksibel untuk penemuan layanan, Terutama dengan menggunakan DNS. Komponen berikut bekerja sama untuk menyelesaikan kueri DNS dalam cluster Anda:

  • kube-dns: penyedia DNS dalam cluster default untuk cluster Standar GKE. Layanan ini berjalan sebagai deployment Pod terkelola di namespace kube-system dan memantau Kubernetes API untuk Layanan baru guna membuat data DNS yang diperlukan.
  • Cloud DNS:Layanan DNS terkelola sepenuhnya dari Google Cloud. NodeLocal DNSCache menawarkan alternatif yang sangat skalabel dan andal untuk kube-dns dan merupakan penyedia DNS default untuk cluster GKE Autopilot.
  • NodeLocal DNSCache: add-on GKE yang meningkatkan performa pencarian DNS. NodeLocal DNSCache menjalankan cache DNS di setiap node di cluster Anda, yang bekerja dengan kube-dns atau Cloud DNS untuk melayani kueri DNS secara lokal, sehingga mengurangi latensi dan beban pada penyedia DNS pusat cluster. Untuk cluster GKE Autopilot, NodeLocal DNSCache diaktifkan secara default dan tidak dapat diganti.
  • Deployment kube-dns Kustom: Deployment yang memungkinkan Anda men-deploy dan mengelola instance kube-dns Anda sendiri, yang memberikan kontrol lebih besar atas konfigurasi dan resource kube-dns.

Pilih penyedia DNS Anda

Tabel berikut merangkum penyedia DNS yang tersedia di GKE, termasuk fitur dan waktu yang tepat untuk memilih setiap penyedia:

Penyedia Fitur Kapan harus memilih
`kube-dns` Resolusi DNS dalam cluster untuk Layanan dan Pod. Semua cluster dengan kebutuhan jaringan standar. Versi baru `kube-dns` cocok untuk cluster skala kecil dan besar.
Cloud DNS Fitur DNS lanjutan (zona pribadi, pengarahan traffic, load balancing global), dan integrasi dengan layanan Google Cloud lainnya. Mengekspos layanan secara eksternal, lingkungan multi-cluster, atau untuk cluster dengan kecepatan kueri DNS (QPS) yang tinggi.
Deployment `kube-dns` Kustom Kontrol tambahan atas konfigurasi, alokasi resource, dan potensi untuk menggunakan penyedia DNS alternatif. Cluster berskala besar atau kebutuhan DNS tertentu yang memerlukan penskalaan yang lebih agresif atau kontrol terperinci atas alokasi resource.

Penemuan layanan di luar satu cluster

Anda dapat memperluas penemuan layanan di luar satu cluster GKE dengan menggunakan metode berikut:

Cakupan Cloud DNS

Cluster yang menggunakan Cloud DNS untuk DNS cluster dapat beroperasi dalam salah satu dari tiga cakupan yang tersedia:

  • Cakupan cluster: ini adalah perilaku default untuk Cloud DNS. Dalam mode ini, Cloud DNS berfungsi setara dengan kube-dns dengan menyediakan resolusi DNS secara eksklusif untuk resource yang berada dalam cluster. Data DNS hanya dapat di-resolve dari dalam cluster, dan mematuhi skema Layanan Kubernetes standar: <svc>.<ns>.svc.cluster.local.
  • Cakupan VPC aditif: fitur opsional ini memperluas cakupan cluster dengan membuat Service tanpa head dapat di-resolve dari resource lain dalam jaringan VPC yang sama, seperti VM Compute Engine atau klien lokal yang terhubung menggunakan Cloud VPN atau Cloud Interconnect.
  • Cakupan VPC: dengan konfigurasi ini, data DNS untuk Layanan cluster dapat di-resolve dalam seluruh jaringan VPC. Pendekatan ini berarti bahwa klien mana pun yang berada di VPC yang sama atau terhubung ke VPC tersebut (melalui Cloud VPN atau Cloud Interconnect) dapat langsung me-resolve nama Layanan.

Untuk mengetahui informasi selengkapnya tentang DNS cakupan VPC, lihat Menggunakan Cloud DNS untuk GKE.

Layanan Multi-cluster

Multi-cluster Services (MCS) memungkinkan penemuan layanan dan pengelolaan traffic di beberapa cluster GKE. MCS memungkinkan Anda membangun aplikasi yang mencakup cluster sekaligus mempertahankan pengalaman layanan yang terpadu.

MCS memanfaatkan penemuan layanan berbasis DNS untuk menghubungkan Layanan di seluruh cluster. Saat Anda membuat instance MCS, instance tersebut akan membuat data DNS dalam format <svc>.<ns>.svc.clusterset.local. Catatan ini di-resolve ke alamat IP endpoint Layanan di setiap cluster yang berpartisipasi.

Saat klien di satu cluster mengakses MCS, permintaan akan dirutekan ke endpoint terdekat yang tersedia di salah satu cluster yang berpartisipasi. Distribusi traffic ini dikelola oleh kube-proxy (atau Cilium di GKE Dataplane V2 GKE) di setiap node, yang membantu memastikan komunikasi dan load balancing yang efisien di seluruh cluster.

Direktori Layanan untuk GKE

Service Directory untuk GKE menyediakan registry terpadu untuk penemuan layanan di seluruh deployment Kubernetes dan non-Kubernetes Anda. Service Directory dapat mendaftarkan layanan GKE dan non-GKE dalam satu registry.

Direktori Layanan sangat berguna jika Anda menginginkan salah satu hal berikut:

  • Antara registry tunggal untuk aplikasi Kubernetes dan non-Kubernetes dapat saling menemukan.
  • Alat penemuan layanan terkelola.
  • Kemampuan untuk menyimpan metadata tentang Layanan Anda yang dapat diakses oleh klien lain.
  • Kemampuan untuk menetapkan izin akses pada tingkat per Layanan. Layanan Direktori Layanan dapat di-resolve menggunakan DNS, HTTP, dan gRPC. Direktori Layanan terintegrasi dengan Cloud DNS, dan dapat mengisi data Cloud DNS yang cocok dengan layanan di Direktori Layanan.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Direktori Layanan untuk GKE.

Mengoptimalkan performa dan praktik terbaik DNS

Untuk membantu memastikan penemuan layanan yang andal dan efisien, terutama di cluster berskala besar atau dengan traffic tinggi, pertimbangkan praktik terbaik dan strategi pengoptimalan berikut.

Mengoptimalkan performa dengan NodeLocal DNSCache

Untuk cluster yang memiliki kepadatan Pod yang tinggi, atau aplikasi yang menghasilkan volume kueri DNS yang tinggi, Anda dapat meningkatkan kecepatan pencarian DNS dengan mengaktifkan NodeLocal DNSCache. NodeLocal DNSCache adalah add-on GKE yang menjalankan cache DNS di setiap node di cluster Anda. Saat Pod membuat permintaan DNS, permintaan tersebut akan ditujukan ke cache yang ada di node yang sama. Pendekatan ini mengurangi latensi dan traffic jaringan.

Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan dan mengonfigurasi fitur ini, lihat Menyiapkan NodeLocal DNSCache.

Menskalakan penyedia DNS Anda

Jika Anda menggunakan kube-dns dan mengalami waktu tunggu habis yang terputus-putus, terutama selama periode traffic tinggi, Anda mungkin perlu menskalakan jumlah replika kube-dns. kube-dns-autoscaler menyesuaikan jumlah replika berdasarkan jumlah node dan core dalam cluster, dan parameternya dapat disesuaikan untuk men-deploy lebih banyak replika lebih cepat.

Untuk petunjuk mendetail, lihat Menskalakan kube-dns.

Praktik terbaik umum

  • Pilih penyedia DNS yang sesuai: pilih penyedia DNS berdasarkan kebutuhan cluster Anda. Cloud DNS direkomendasikan untuk workload QPS tinggi, lingkungan multi-cluster, dan saat Anda memerlukan integrasi dengan jaringan VPC yang lebih luas. Versi baru kube-dns cocok untuk berbagai cluster, dari kecil hingga besar, yang memiliki kebutuhan penemuan layanan dalam cluster standar.
  • Hindari Spot VM atau Preemptible VM untuk kube-dns: membantu memastikan stabilitas layanan DNS cluster Anda dengan tidak menjalankan komponen sistem penting seperti kube-dns di Spot VM atau Preemptible VM. Penghentian node yang tidak terduga dapat menyebabkan masalah resolusi DNS.
  • Gunakan nama Layanan yang jelas dan deskriptif: terapkan konvensi penamaan yang konsisten dan bermakna untuk Layanan Anda agar konfigurasi aplikasi lebih mudah dibaca dan dipertahankan.
  • Atur dengan namespace: gunakan namespace Kubernetes untuk mengelompokkan layanan terkait. Pendekatan ini membantu mencegah konflik penamaan dan meningkatkan organisasi resource cluster.
  • Pantau dan validasi DNS: pantau metrik dan log DNS secara rutin untuk mengidentifikasi potensi masalah sebelum memengaruhi aplikasi Anda. Uji resolusi DNS secara berkala dari dalam Pod Anda untuk memastikan penemuan layanan berfungsi seperti yang diharapkan.

Langkah berikutnya