_Topology Aware Routing_ (Routing yang Mempertimbangkan Topologi)

Topology Aware Routing mengatur perilaku routing untuk memprioritaskan menjaga trafik tetap berada di zona asalnya. Dalam beberapa kasus, hal ini dapat membantu mengurangi biaya atau meningkatkan performa jaringan.

Motivasi

Kluster Kubernetes semakin sering diterapkan di lingkungan multi-zona. Topology Aware Routing menyediakan mekanisme untuk membantu menjaga trafik tetap berada di zona asalnya. Saat menghitung endpoint untuk sebuah Service, kontroler EndpointSlice mempertimbangkan topologi (wilayah dan zona) dari setiap endpoint dan mengisi field hints untuk mengalokasikannya ke suatu zona. Komponen kluster seperti kube-proxy kemudian dapat menggunakan hints tersebut dan memanfaatkannya untuk mempengaruhi cara trafik diarahkan (dengan memprioritaskan endpoint yang secara topologis lebih dekat).

Mengaktifkan Topology Aware Routing

Kamu dapat mengaktifkan Topology Aware Routing untuk sebuah Service dengan mengatur anotasi service.kubernetes.io/topology-mode ke Auto. Ketika terdapat cukup banyak endpoint yang tersedia di setiap zona, Topology Hints akan diisi pada EndpointSlices untuk mengalokasikan endpoint secara individual ke zona tertentu, sehingga trafik diarahkan lebih dekat ke tempat asalnya.

Kapan Fitur ini Bekerja dengan Baik

Fitur ini bekerja paling baik ketika:

1. Trafik masuk didistribusikan secara merata

Jika sebagian besar trafik berasal dari satu zona saja, trafik tersebut dapat membebani subset endpoint yang dialokasikan ke zona tersebut. Fitur ini tidak direkomendasikan jika trafik masuk diperkirakan berasal dari satu zona saja.

2. Service memiliki 3 atau lebih endpoint per zona

Dalam kluster dengan tiga zona, ini berarti 9 atau lebih endpoint. Jika ada kurang dari 3 endpoint per zona, kemungkinan besar (≈50%) kontroler EndpointSlice tidak dapat mengalokasikan endpoint secara merata dan akan kembali menggunakan pendekatan routing default yang berlaku di seluruh kluster.

Cara Kerjanya

Heuristik "Auto" berusaha mengalokasikan sejumlah endpoint secara proporsional ke setiap zona. Perlu dicatat bahwa heuristik ini bekerja paling baik untuk Service yang memiliki jumlah endpoint yang signifikan.

Kontroler EndpointSlice

Kontroler EndpointSlice bertanggung jawab untuk mengatur hints pada EndpointSlices ketika heuristik ini diaktifkan. Kontroler mengalokasikan jumlah endpoint secara proporsional ke setiap zona. Proporsi ini didasarkan pada core CPU tersedia yang dialokasikan untuk Node yang berjalan di zona tersebut. Misalnya, jika satu zona memiliki 2 core CPU dan zona lain hanya memiliki 1 core CPU, kontroler akan mengalokasikan dua kali lebih banyak endpoint ke zona dengan 2 core CPU.

Contoh berikut menunjukkan seperti apa EndpointSlice ketika hints telah diisi:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: example-hints
  labels:
    kubernetes.io/service-name: example-svc
addressType: IPv4
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
      - "10.1.2.3"
    conditions:
      ready: true
    hostname: pod-1
    zone: zone-a
    hints:
      forZones:
        - name: "zone-a"

kube-proxy

Komponen kube-proxy memfilter endpoint yang diarahkan berdasarkan hints yang diatur oleh kontroler EndpointSlice. Dalam sebagian besar kasus, ini berarti kube-proxy mampu mengarahkan trafik ke endpoint yang berada di zona yang sama. Namun terkadang kontroler mengalokasikan endpoint dari zona berbeda untuk memastikan distribusi endpoint yang lebih merata antar zona. Hal ini akan menyebabkan sebagian trafik diarahkan ke zona lain.

Pengamanan (Safeguard)

Control plane Kubernetes dan kube-proxy pada setiap Node menerapkan aturan pengamanan sebelum menggunakan Topology Aware Hints. Jika aturan ini tidak terpenuhi, kube-proxy akan memilih endpoint dari mana saja dalam kluster kamu, tanpa memperhatikan zona.

1. Jumlah endpoint tidak mencukupi: Jika jumlah endpoint lebih sedikit daripada jumlah zona dalam kluster, kontroler tidak akan memberikan hints apa pun.

2. Tidak mungkin mencapai alokasi yang seimbang: Dalam beberapa kasus, tidak mungkin mencapai alokasi endpoint yang seimbang antar zona. Misalnya, jika zona-a dua kali lebih besar dari zona-b, tetapi hanya ada 2 endpoint, endpoint yang dialokasikan ke zona-a mungkin menerima dua kali lebih banyak trafik dibanding zona-b. Kontroler tidak memberikan hints jika nilai "kelebihan beban kerja (expected overload)" ini tidak bisa ditekan di bawah ambang batas yang dapat diterima untuk setiap zona. Penting untuk dicatat bahwa ini bukan berdasarkan umpan balik waktu nyata. Masih mungkin bagi endpoint individu untuk mengalami kelebihan beban kerja.

3. Satu atau lebih Node kekurangan informasi: Jika ada Node yang tidak memiliki label topology.kubernetes.io/zone atau tidak melaporkan nilai CPU yang dapat dialokasikan, control plane tidak akan mengatur hints endpoint yang mempertimbangkan topologi, sehingga kube-proxy tidak memfilter endpoint berdasarkan zona.

4. Satu atau lebih endpoint tidak memiliki hint zona: Jika ini terjadi, kube-proxy menganggap sedang terjadi transisi dari atau ke Topology Aware Hints. Memfilter endpoint untuk Service dalam kondisi ini berisiko, sehingga kube-proxy kembali menggunakan semua endpoint.

5. Sebuah zona tidak terwakili dalam hints: Jika kube-proxy tidak dapat menemukan setidaknya satu endpoint dengan hint yang menargetkan zona tempatnya berjalan, kube-proxy akan kembali menggunakan endpoint dari semua zona. Ini biasanya terjadi saat kamu menambahkan zona baru ke kluster yang sudah ada.

Batasan (Constraint)

• Topology Aware Hints tidak digunakan ketika internalTrafficPolicy diatur ke Local pada sebuah Service. Kamu bisa menggunakan kedua fitur ini dalam satu kluster pada Service yang berbeda, tetapi tidak pada Service yang sama.

• Pendekatan ini tidak akan bekerja dengan baik untuk Service yang memiliki sebagian besar trafik berasal dari subset zona tertentu. Pendekatan ini mengasumsikan bahwa trafik masuk akan kira-kira proporsional dengan kapasitas Node di setiap zona.

• Kontroler EndpointSlice mengabaikan Node yang belum siap (NotReady) saat menghitung proporsi tiap zona. Ini bisa menimbulkan konsekuensi yang tidak diinginkan jika sebagian besar Node dalam keadaan belum siap.

• Kontroler EndpointSlice mengabaikan Node yang memiliki label node-role.kubernetes.io/control-plane atau node-role.kubernetes.io/master. Ini bisa menjadi masalah jika beban kerja juga berjalan di Node-Node tersebut.

• Kontroler EndpointSlice tidak mempertimbangkan tolerations saat men-deploy atau menghitung proporsi tiap zona. Jika Pod yang mendukung sebuah Service terbatas pada subset Node dalam kluster, hal ini tidak akan diperhitungkan.

• Fitur ini mungkin tidak bekerja dengan baik bersama autoscaling. Misalnya, jika sebagian besar trafik berasal dari satu zona, hanya endpoint yang dialokasikan ke zona tersebut yang akan menangani trafik itu. Hal ini dapat menyebabkan Horizontal Pod Autoscaler tidak mendeteksi kejadian ini, atau Pod baru yang ditambahkan justru mulai di zona berbeda.

Heuristik Kustom

Kubernetes diterapkan dalam berbagai cara yang berbeda, sehingga tidak ada satu heuristik tunggal untuk mengalokasikan endpoint ke zona yang akan cocok untuk setiap kasus penggunaan. Salah satu tujuan utama fitur ini adalah memungkinkan pengembangan heuristik kustom jika heuristik bawaan tidak sesuai dengan kebutuhan kasus penggunaan kamu. Langkah awal untuk mengaktifkan heuristik kustom telah disertakan dalam rilis 1.27. Ini adalah implementasi terbatas yang mungkin belum mencakup beberapa situasi relevan dan masuk akal.

Selanjutnya

• Ikuti tutorial Menghubungkan Aplikasi dengan Service
• Pelajari tentang field trafficDistribution yang sangat terkait dengan anotasi service.kubernetes.io/topology-mode dan menyediakan opsi fleksibel untuk routing trafik dalam Kubernetes.