**Bantu tingkatkan halaman ini** Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. Untuk berkontribusi pada panduan pengguna ini, pilih **Edit halaman ini pada GitHub** tautan yang terletak di panel kanan setiap halaman. Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Konsep Kubernetes untuk node hibrida Halaman ini merinci konsep-konsep utama Kubernetes yang mendukung arsitektur sistem EKS Hybrid Nodes. ## Pesawat kontrol EKS di VPC IPs Bidang kontrol EKS ENIs disimpan dalam `kubernetes` `Endpoints` objek di `default` namespace. Ketika EKS membuat yang baru ENIs atau menghapus yang lebih lama, EKS memperbarui objek ini sehingga daftar IPs selalu up-to-date. Anda dapat menggunakan titik akhir ini melalui `kubernetes` Layanan, juga di `default` namespace. Layanan ini, dari `ClusterIP` jenis, selalu diberi IP pertama dari CIDR layanan cluster. Misalnya, untuk layanan CIDR`172.16.0.0/16`, IP layanan akan`172.16.0.1`. Secara umum, ini adalah bagaimana Pod (terlepas dari apakah berjalan di cloud atau node hybrid) mengakses server API EKS Kubernetes. Pod menggunakan IP layanan sebagai IP tujuan, yang diterjemahkan ke IPs salah satu bidang kontrol EKS yang sebenarnya ENIs. Pengecualian utama adalah`kube-proxy`, karena mengatur terjemahan. ## Titik akhir server API EKS IP `kubernetes` layanan bukan satu-satunya cara untuk mengakses server EKS API. EKS juga membuat nama DNS Route53 saat Anda membuat cluster Anda. Ini adalah `endpoint` bidang cluster EKS Anda saat memanggil aksi EKS `DescribeCluster` API. ``` { "cluster": { "endpoint": "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com", "name": "my-cluster", "status": "ACTIVE" } } ``` Dalam akses endpoint publik atau kluster akses endpoint publik dan pribadi, node hybrid Anda akan menyelesaikan nama DNS ini ke IP publik secara default, yang dapat dirutekan melalui internet. Dalam kluster akses titik akhir pribadi, nama DNS diselesaikan menjadi pribadi IPs dari bidang kontrol EKS. ENIs Ini adalah bagaimana `kubelet` dan `kube-proxy` mengakses server API Kubernetes. Jika Anda ingin semua lalu lintas klaster Kubernetes mengalir melalui VPC, Anda perlu mengonfigurasi klaster Anda dalam mode akses pribadi atau memodifikasi server DNS lokal Anda untuk menyelesaikan titik akhir kluster EKS ke privat bidang kontrol EKS. IPs ENIs ## Titik akhir `kubelet` Ini `kubelet` mengekspos beberapa titik akhir REST, memungkinkan bagian lain dari sistem untuk berinteraksi dengan dan mengumpulkan informasi dari setiap node. Di sebagian besar cluster, sebagian besar lalu lintas ke `kubelet` server berasal dari bidang kontrol, tetapi agen pemantauan tertentu mungkin juga berinteraksi dengannya. Melalui antarmuka ini, `kubelet` menangani berbagai permintaan: mengambil log (`kubectl logs`), mengeksekusi perintah di dalam container (), dan port-forwarding traffic (`kubectl exec`). `kubectl port-forward` Setiap permintaan ini berinteraksi dengan runtime kontainer yang mendasarinya melalui`kubelet`, tampak mulus bagi administrator dan pengembang klaster. Konsumen yang paling umum dari API ini adalah Kubernetes API server. Saat Anda menggunakan salah satu `kubectl` perintah yang disebutkan sebelumnya, `kubectl` buat permintaan API ke server API, yang kemudian memanggil `kubelet` API node tempat pod berjalan. Ini adalah alasan utama mengapa IP node harus dapat dijangkau dari bidang kontrol EKS dan mengapa, bahkan jika pod Anda berjalan, Anda tidak akan dapat mengakses log mereka atau `exec` jika rute node salah dikonfigurasi. **Node IPs** Ketika bidang kontrol EKS berkomunikasi dengan node, ia menggunakan salah satu alamat yang dilaporkan dalam status `Node` objek (`status.addresses`). Dengan node cloud EKS, kubelet biasanya melaporkan IP pribadi EC2 instance sebagai an `InternalIP` selama pendaftaran node. IP ini kemudian divalidasi oleh Cloud Controller Manager (CCM) memastikan itu milik instance. EC2 Selain itu, CCM biasanya menambahkan nama publik IPs (as`ExternalIP`) dan DNS (`InternalDNS`dan`ExternalDNS`) instance ke status node. Namun, tidak ada CCM untuk node hybrid. Ketika Anda mendaftarkan node hybrid dengan EKS Hybrid Nodes CLI (`nodeadm`), ia mengkonfigurasi kubelet untuk melaporkan IP mesin Anda secara langsung dalam status node, tanpa CCM. ``` apiVersion: v1 kind: Node metadata: name: my-node-1 spec: providerID: eks-hybrid:///us-west-2/my-cluster/my-node-1 status: addresses: - address: 10.1.1.236 type: InternalIP - address: my-node-1 type: Hostname ``` Jika mesin Anda memiliki beberapa IPs, kubelet akan memilih salah satu dari mereka mengikuti logikanya sendiri. Anda dapat mengontrol IP yang dipilih dengan `--node-ip` bendera, yang dapat Anda berikan dalam `nodeadm` `spec.kubelet.flags` konfigurasi. Hanya IP yang dilaporkan dalam `Node` objek yang membutuhkan rute dari VPC. Mesin Anda dapat memiliki IPs yang lain yang tidak dapat dijangkau dari cloud. ## `kube-proxy` `kube-proxy`bertanggung jawab untuk mengimplementasikan abstraksi Layanan pada lapisan jaringan setiap node. Ini bertindak sebagai proxy jaringan dan penyeimbang beban untuk lalu lintas yang ditujukan ke Layanan Kubernetes. Dengan terus memantau server API Kubernetes untuk perubahan yang terkait dengan Layanan dan Titik Akhir, memperbarui aturan jaringan host yang mendasarinya `kube-proxy` secara dinamis untuk memastikan lalu lintas diarahkan dengan benar. Dalam `iptables` mode, `kube-proxy` program beberapa `netfilter` rantai untuk menangani lalu lintas layanan. Aturan membentuk hierarki berikut: 1. **Rantai KUBE-SERVICES**: Titik masuk untuk semua lalu lintas layanan. Ini memiliki aturan yang cocok dengan setiap layanan `ClusterIP` dan port. 1. **KUBE-SVC-XXX rantai: Rantai** khusus layanan memiliki aturan penyeimbangan beban untuk setiap layanan. 1. **KUBE-SEP-XXX rantai: Rantai** khusus titik akhir memiliki aturan yang sebenarnya. `DNAT` Mari kita periksa apa yang terjadi untuk sebuah layanan `test-server` di `default` namespace: \* Service ClusterIP: \* Service port: `172.16.31.14` \* Backing pods:`80`,, dan `10.2.0.110` `10.2.1.39` `10.2.2.254` Saat kami memeriksa `iptables` aturan (menggunakan`iptables-save –0— grep -A10 KUBE-SERVICES`): 1. Dalam rantai **KUBE-SERVICES**, kami menemukan aturan yang cocok dengan layanan: ``` -A KUBE-SERVICES -d 172.16.31.14/32 -p tcp -m comment --comment "default/test-server cluster IP" -m tcp --dport 80 -j KUBE-SVC-XYZABC123456 ``` + Aturan ini cocok dengan paket yang ditujukan untuk 172.16.31. 14:80 + Komentar menunjukkan untuk apa aturan ini: `default/test-server cluster IP` + Paket yang cocok melompat ke rantai `KUBE-SVC-XYZABC123456` 1. XYZABC123456Rantai **KUBE-SVC memiliki aturan load balancing** berbasis probabilitas: ``` -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POD1XYZABC -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-POD2XYZABC -A KUBE-SVC-XYZABC123456 -j KUBE-SEP-POD3XYZABC ``` + Aturan pertama: 33,3% peluang untuk melompat `KUBE-SEP-POD1XYZABC` + Aturan kedua: 50% kemungkinan lalu lintas yang tersisa (33,3% dari total) untuk melompat `KUBE-SEP-POD2XYZABC` + Aturan terakhir: Semua lalu lintas yang tersisa (33,3% dari total) melompat ke `KUBE-SEP-POD3XYZABC` 1. Rantai **KUBE-SEP-XXX** individu melakukan DNAT (Destination NAT): ``` -A KUBE-SEP-POD1XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.0.110:80 -A KUBE-SEP-POD2XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.1.39:80 -A KUBE-SEP-POD3XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.2.254:80 ``` + Aturan DNAT ini menulis ulang IP tujuan dan port untuk mengarahkan lalu lintas ke pod tertentu. + Setiap aturan menangani sekitar 33,3% dari lalu lintas, memberikan keseimbangan beban yang merata antara`10.2.0.110`, dan. `10.2.1.39` `10.2.2.254` Struktur rantai multi-level ini memungkinkan `kube-proxy` untuk secara efisien menerapkan penyeimbangan beban layanan dan pengalihan melalui manipulasi paket tingkat kernel, tanpa memerlukan proses proxy di jalur data. ### Dampak pada operasi Kubernetes Kerusakan `kube-proxy` pada node mencegah node tersebut merutekan lalu lintas Layanan dengan benar, menyebabkan batas waktu atau koneksi gagal untuk pod yang mengandalkan Layanan cluster. Ini bisa sangat mengganggu ketika node pertama kali terdaftar. CNI perlu berbicara dengan server API Kubernetes untuk mendapatkan informasi, seperti pod CIDR node, sebelum dapat mengkonfigurasi jaringan pod apa pun. Untuk melakukan itu, ia menggunakan IP `kubernetes` Layanan. Namun, jika `kube-proxy` belum dapat memulai atau gagal menetapkan `iptables` aturan yang tepat, permintaan yang masuk ke IP `kubernetes` layanan tidak diterjemahkan ke bidang kontrol EKS yang sebenarnya IPs ENIs. Akibatnya, CNI akan memasuki crash loop dan tidak ada pod yang dapat berjalan dengan baik. Kita tahu pod menggunakan IP `kubernetes` layanan untuk berkomunikasi dengan server API Kubernetes, tetapi `kube-proxy` perlu terlebih dahulu menetapkan `iptables` aturan untuk membuatnya berfungsi. Bagaimana cara `kube-proxy` berkomunikasi dengan server API? `kube-proxy`Harus dikonfigurasi untuk menggunakan server API Kubernetes yang sebenarnya IP/s atau nama DNS yang menyelesaikannya. Dalam kasus EKS, EKS mengonfigurasi default `kube-proxy` untuk menunjuk ke nama DNS Route53 yang dibuat EKS saat Anda membuat cluster. Anda dapat melihat nilai ini di `kube-proxy` ConfigMap dalam `kube-system` namespace. Isi dari ini ConfigMap adalah a `kubeconfig` yang disuntikkan ke dalam `kube-proxy` pod, jadi cari `clusters–0—.cluster.server` bidangnya. Nilai ini akan cocok dengan `endpoint` bidang kluster EKS Anda (saat memanggil EKS `DescribeCluster` API). ``` apiVersion: v1 data: kubeconfig: |- kind: Config apiVersion: v1 clusters: - cluster: certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt server: https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com name: default contexts: - context: cluster: default namespace: default user: default name: default current-context: default users: - name: default user: tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token kind: ConfigMap metadata: name: kube-proxy namespace: kube-system ``` ## Pod jarak jauh yang dapat dirutekan CIDRs [Konsep jaringan untuk node hibrida](hybrid-nodes-concepts-networking.md)Halaman ini merinci persyaratan untuk menjalankan webhook pada node hybrid atau agar pod berjalan di cloud node berkomunikasi dengan pod yang berjalan pada node hybrid. Persyaratan utamanya adalah router lokal perlu mengetahui node mana yang bertanggung jawab atas IP pod tertentu. Ada beberapa cara untuk mencapai hal ini, termasuk Border Gateway Protocol (BGP), rute statis, dan proxy Address Resolution Protocol (ARP). Ini tercakup dalam bagian berikut. **Protokol Gerbang Perbatasan (BGP)** Jika CNI Anda mendukungnya (seperti Cilium dan Calico), Anda dapat menggunakan mode BGP CNI Anda untuk menyebarkan rute ke pod CIDRs per node Anda dari node Anda ke router lokal Anda. Saat menggunakan mode BGP CNI, CNI Anda bertindak sebagai router virtual, sehingga router lokal Anda berpikir pod CIDR milik subnet yang berbeda dan node Anda adalah gateway ke subnet itu. ![Perutean BGP node hibrid](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-bgp.png) **Rute statis** Atau, Anda dapat mengonfigurasi rute statis di router lokal Anda. Ini adalah cara paling sederhana untuk merutekan pod CIDR lokal ke VPC Anda, tetapi ini juga yang paling rawan kesalahan dan sulit dipertahankan. Anda perlu memastikan bahwa rute selalu up-to-date dengan node yang ada dan pod yang ditetapkan CIDRs. Jika jumlah node Anda kecil dan infrastruktur statis, ini adalah opsi yang layak dan menghilangkan kebutuhan akan dukungan BGP di router Anda. Jika Anda memilih ini, kami sarankan untuk mengonfigurasi CNI Anda dengan irisan pod CIDR yang ingin Anda tetapkan ke setiap node alih-alih membiarkan IPAM-nya memutuskan. ![Perutean statis node hibrid](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-static-routes.png) **Proksi Protokol Resolusi Alamat (ARP)** Proxy ARP adalah pendekatan lain untuk membuat pod lokal IPs dapat dirutekan, sangat berguna ketika node hybrid Anda berada di jaringan Layer 2 yang sama dengan router lokal Anda. Dengan proksi ARP diaktifkan, sebuah node merespons permintaan ARP untuk pod yang dihost-nya, meskipun IPs itu IPs milik subnet yang berbeda. Ketika perangkat di jaringan lokal Anda mencoba untuk mencapai IP pod, pertama-tama ia mengirimkan permintaan ARP yang menanyakan “Siapa yang memiliki IP ini?”. Node hybrid hosting pod itu akan merespons dengan alamat MAC-nya sendiri, mengatakan “Saya dapat menangani lalu lintas untuk IP itu.” Ini menciptakan jalur langsung antara perangkat di jaringan lokal Anda dan pod tanpa memerlukan konfigurasi router. Agar ini berfungsi, CNI Anda harus mendukung fungsionalitas ARP proxy. Cilium memiliki dukungan bawaan untuk ARP proxy yang dapat Anda aktifkan melalui konfigurasi. Pertimbangan utamanya adalah bahwa pod CIDR tidak boleh tumpang tindih dengan jaringan lain di lingkungan Anda, karena ini dapat menyebabkan konflik perutean. Pendekatan ini memiliki beberapa keunggulan: \* Tidak perlu mengkonfigurasi router Anda dengan BGP atau mempertahankan rute statis \* Bekerja dengan baik di lingkungan di mana Anda tidak memiliki kendali atas konfigurasi router Anda ![Proksi ARP node hibrida](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-arp-proxy.png) ## Pod-to-Pod enkapsulasi Di lingkungan lokal, CNIs biasanya menggunakan protokol enkapsulasi untuk membuat jaringan overlay yang dapat beroperasi di atas jaringan fisik tanpa perlu mengkonfigurasi ulang. Bagian ini menjelaskan cara kerja enkapsulasi ini. Perhatikan bahwa beberapa detail mungkin berbeda tergantung pada CNI yang Anda gunakan. Enkapsulasi membungkus paket jaringan pod asli di dalam paket jaringan lain yang dapat dirutekan melalui jaringan fisik yang mendasarinya. Hal ini memungkinkan pod untuk berkomunikasi di seluruh node yang menjalankan CNI yang sama tanpa memerlukan jaringan fisik untuk mengetahui cara merutekan pod CIDRs tersebut. Protokol enkapsulasi yang paling umum digunakan dengan Kubernetes adalah Virtual Extensible LAN (VXLAN), meskipun yang lain (seperti`Geneve`) juga tersedia tergantung pada CNI Anda. ### Enkapsulasi VXLAN VXLAN merangkum frame Ethernet Layer 2 dalam paket UDP. Ketika sebuah pod mengirimkan lalu lintas ke pod lain pada node yang berbeda, CNI melakukan hal berikut: 1. CNI mencegat paket dari Pod A 1. CNI membungkus paket asli dalam header VXLAN 1. Paket yang dibungkus ini kemudian dikirim melalui tumpukan jaringan reguler node ke node tujuan 1. CNI pada node tujuan membuka bungkus paket dan mengirimkannya ke Pod B Inilah yang terjadi pada struktur paket selama enkapsulasi VXLAN: Pod-to-PodPaket Asli: ``` +-----------------+---------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: Pod A IP | Src Port | | | Dst: Pod B MAC | Dst: Pod B IP | Dst Port | | +-----------------+---------------+-------------+-----------------+ ``` Setelah Enkapsulasi VXLAN: ``` +-----------------+-------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node A MAC | Src: Node A | Src: Random | VNI: xx | Packet (unchanged | | Dst: Node B MAC | Dst: Node B | Dst: 4789 | | from above) | +-----------------+-------------+--------------+------------+---------------------------+ ``` VXLAN Network Identifier (VNI) membedakan antara jaringan overlay yang berbeda. ### Skenario komunikasi pod **Pod pada node hybrid yang sama** Ketika pod pada node hibrida yang sama berkomunikasi, biasanya tidak diperlukan enkapsulasi. CNI mengatur rute lokal yang mengarahkan lalu lintas antar pod melalui antarmuka virtual internal node: ``` Pod A -> veth0 -> node's bridge/routing table -> veth1 -> Pod B ``` Paket tidak pernah meninggalkan node dan tidak memerlukan enkapsulasi. **Pod pada node hibrida yang berbeda** Komunikasi antar pod pada node hybrid yang berbeda membutuhkan enkapsulasi: ``` Pod A -> CNI -> [VXLAN encapsulation] -> Node A network -> router or gateway -> Node B network -> [VXLAN decapsulation] -> CNI -> Pod B ``` Hal ini memungkinkan lalu lintas pod untuk melintasi infrastruktur jaringan fisik tanpa memerlukan jaringan fisik untuk memahami routing IP pod.