Edit This Page

EndpointSlice

FEATURE STATE: Kubernetes v1.17 [beta]

EndpointSlice menyediakan sebuah cara yang mudah untuk melacak endpoint jaringan dalam sebuah klaster Kubernetes. EndpointSlice memberikan alternatif yang lebih scalable dan lebih dapat diperluas dibandingkan dengan Endpoints.

Motivasi

Endpoints API telah menyediakan sebuah cara yang mudah dan sederhana untuk melacak endpoint jaringan pada Kubernetes. Sayangnya, seiring dengan besarnya klaster Kubernetes dan Service, batasan-batasan yang dimiliki API tersebut semakin terlihat. Terutama, hal tersebut termasuk kendala-kendala mengenai proses scaling endpoint jaringan dalam jumlah yang besar.

Karena semua endpoint jaringan untuk sebuah Service disimpan dalam satu sumber daya Endpoints, sumber daya tersebut dapat menjadi cukup besar. Hal itu dapat mempengaruhi kinerja dari komponen-komponen Kubernetes (terutama master control plane) dan menyebabkan lalu lintas jaringan dan pemrosesan yang cukup besar ketika Endpoints berubah. EndpointSlice membantu kamu menghindari masalah-masalah tersebut dan juga menyediakan platform yang dapat diperluas untuk fitur-fitur tambahan seperti topological routing.

Sumber daya EndpointSlice

Pada Kubernetes, sebuah EndpointSlice memiliki referensi-referensi terhadap sekumpulan endpoint jaringan. Controller EndpointSlice secara otomatis membuat EndpointSlice untuk sebuah Service Kubernetes ketika sebuah selektorAllows users to filter a list of resources based on labels. dituliskan. EndpointSlice tersebut akan memiliki referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan endpoint jaringan berdasarkan kombinasi Service dan Port yang unik. Nama dari sebuah objek EndpointSlice haruslah berupa nama subdomain DNS yang sah.

Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes yang bernama example.

apiVersion: discovery.k8s.io/v1beta1
kind: EndpointSlice
metadata:
  name: example-abc
  labels:
    kubernetes.io/service-name: example
addressType: IPv4
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
      - "10.1.2.3"
    conditions:
      ready: true
    hostname: pod-1
    topology:
      kubernetes.io/hostname: node-1
      topology.kubernetes.io/zone: us-west2-a

Secara bawaan, setiap EndpointSlice yang dikelola oleh controller EndpointSlice tidak akan memiliki lebih dari 100 endpoint. Di bawah skala tersebut, EndpointSlice akan memetakan 1:1 dengan Endpoints dan Service dan akan memiliki kinerja yang sama.

EndpointSlice dapat bertindak sebagai sumber kebenaran untuk kube-proxy sebagai acuan mengenai bagaimana cara untuk merutekan lalu lintas jaringan internal. Ketika diaktifkan, EndpointSlice semestinya memberikan peningkatan kinerja untuk Service yang memiliki Endpoints dalam jumlah besar.

Tipe-tipe Alamat

EndpointSlice mendukung tiga tipe alamat:

  • IPv4
  • IPv6
  • FQDN (Fully Qualified Domain Name)

Topologi

Setiap endpoint pada EndpointSlice dapat memiliki informasi topologi yang relevan. Hal ini digunakan untuk mengindikasikan di mana endpoint berada, berisi informasi mengenai Node yang bersangkutan, zona, dan wilayah. Ketika nilai-nilai tersebut tersedia, label-label Topology berikut akan ditambahkan oleh controller EndpointSlice:

  • kubernetes.io/hostname - Nama dari Node tempat endpoint berada.
  • topology.kubernetes.io/zone - Zona tempat endpoint berada.
  • topology.kubernetes.io/region - Region tempat endpoint berada.

Nilai-nilai dari label-label berikut berasal dari sumber daya yang diasosiasikan dengan tiap endpoint pada sebuah slice. Label hostname merepresentasikan nilai dari kolom NodeName pada Pod yang bersangkutan. Label zona dan wilayah merepresentasikan nilai dari label-label dengan nama yang sama pada Node yang bersangkutan.

Pengelolaan

Secara bawaan, EndpointSlice dibuat dan dikelola oleh controller EndpointSlice. Ada berbagai macam kasus lain untuk EndpointSlice, seperti implementasi service mesh, yang memungkinkan adanya entitas atau controller lain yang dapat mengelola beberapa EndpointSlice sekaligus. Untuk memastikan beberapa entitas dapat mengelola EndpointSlice tanpa mengganggu satu sama lain, sebuah label endpointslice.kubernetes.io/managed-by digunakan untuk mengindikasikan entitas yang mengelola sebuah EndpointSlice. Controller EndpointSlice akan menambahkan endpointslice-controller.k8s.io sebagai nilai dari label tersebut pada seluruh EndpointSlice yang dikelolanya. Entitas lain yang mengelola EndpointSlice juga diharuskan untuk menambahkan nilai yang unik untuk label tersebut.

Kepemilikan

Pada kebanyakan kasus, EndpointSlice akan dimiliki oleh Service yang diikutinya. Hal ini diindikasikan dengan referensi pemilik pada tiap EndpointSlice dan juga label kubernetes.io/service-name yang memudahkan pencarian seluruh EndpointSlice yang dimiliki oleh sebuah Service.

Controller EndpointSlice

Controller EndpointSlice mengamati Service dan Pod untuk memastikan EndpointSlice yang bersangkutan berada dalam kondisi terkini. Controller EndpointSlice akan mengelola EndpointSlice untuk setiap Service yang memiliki selektor. Ini akan merepresentasikan IP dari Pod yang cocok dengan selektor dari Service tersebut.

Ukuran EndpointSlice

Secara bawaan, jumlah endpoint yang dapat dimiliki tiap EndpointSlice dibatasi sebanyak 100 endpoint. Kamu dapat mengaturnya melalui opsi --max-endpoints-per-slice kube-controller-managerKomponen di master yang menjalankan kontroler. sampai dengan jumlah maksimum sebanyak 1000 endpoint.

Distribusi EndpointSlice

Tiap EndpointSlice memiliki sekumpulan port yang berlaku untuk seluruh endpoint dalam sebuah sumber daya. Ketika nama port digunakan untuk sebuah Service, Pod mungkin mendapatkan nomor target port yang berbeda-beda untuk nama port yang sama, sehingga membutuhkan EndpointSlice yang berbeda. Hal ini mirip dengan logika mengenai bagaimana subset dikelompokkan dengan Endpoints.

Controller EndpointSlice akan mencoba untuk mengisi EndpointSlice sebanyak mungkin, tetapi tidak secara aktif melakukan rebalance terhadap EndpointSlice tersebut. Logika dari controller cukup sederhana:

  1. Melakukan iterasi terhadap EndpointSlice yang sudah ada, menghapus endpoint yang sudah tidak lagi dibutuhkan dan memperbarui endpoint yang sesuai yang mungkin telah berubah.
  2. Melakukan iterasi terhadap EndpointSlice yang sudah dimodifikasi pada langkah pertama dan mengisinya dengan endpoint baru yang dibutuhkan.
  3. Jika masih tersisa endpoint baru untuk ditambahkan, mencoba untuk menambahkannya pada slice yang tidak berubah sebelumnya dan/atau membuat slice yang baru.

Terlebih penting, langkah ketiga memprioritaskan untuk membatasi pembaruan EndpointSlice terhadap distribusi dari EndpointSlice yang benar-benar penuh. Sebagai contoh, jika ada 10 endpoint baru untuk ditambahkan dan ada 2 EndpointSlice yang masing-masing memiliki ruang untuk 5 endpoint baru, pendekatan ini akan membuat sebuah EndpointSlice baru daripada mengisi 2 EndpointSlice yang sudah ada. Dengan kata lain, pembuatan sebuah EndpointSlice lebih diutamakan daripada pembaruan beberapa EndpointSlice.

Dengan kube-proxy yang berjalan pada tiap Node dan mengamati EndpointSlice, setiap perubahan pada sebuah EndpointSlice menjadi sangat mahal karena hal tersebut akan dikirimkan ke setiap Node dalam klaster. Pendekatan ini ditujukan untuk membatasi jumlah perubahan yang perlu dikirimkan ke setiap Node, meskipun hal tersebut berdampak pada banyaknya EndpointSlice yang tidak penuh.

Pada praktiknya, distribusi yang kurang ideal seperti ini akan jarang ditemukan. Kebanyakan perubahan yang diproses oleh controller EndpointSlice akan cukup kecil untuk dapat masuk pada EndpointSlice yang sudah ada, dan jika tidak, cepat atau lambat sebuah EndpointSlice baru akan segera dibutuhkan. Pembaruan bertahap (rolling update) dari Deployment juga menyediakan sebuah proses pengemasan ulang EndpointSlice yang natural seiring dengan digantikannya seluruh Pod dan endpoint yang bersangkutan.

Selanjutnya