**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. # Arus lalu lintas jaringan untuk node hibrida Halaman ini merinci arus lalu lintas jaringan untuk EKS Hybrid Nodes dengan diagram yang menunjukkan jalur end-to-end jaringan untuk jenis lalu lintas yang berbeda. Arus lalu lintas berikut tercakup: + [Node hibrida `kubelet` ke bidang kontrol EKS](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) + [Pesawat kontrol EKS ke node hybrid (`kubelet`server)](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) + [Pod berjalan pada node hibrid ke bidang kontrol EKS](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) + [Pesawat kontrol EKS ke pod yang berjalan pada node hybrid (webhooks)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) + [Pod-to-Pod berjalan pada node hybrid](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) + [Pod pada node cloud ke pod pada node hibrid (lalu lintas timur-barat)](#hybrid-nodes-concepts-traffic-flows-east-west) ## Node hibrida `kubelet` ke bidang kontrol EKS ![\[Kubelet simpul hibrida ke bidang kontrol EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png) ### Permintaan **1. `kubelet` Memulai Permintaan** Ketika `kubelet` pada node hybrid perlu berkomunikasi dengan bidang kontrol EKS (misalnya, untuk melaporkan status node atau mendapatkan spesifikasi pod), ia menggunakan `kubeconfig` file yang disediakan selama pendaftaran node. Ini `kubeconfig` memiliki URL titik akhir server API (nama DNS Route53) daripada alamat IP langsung. `kubelet`Melakukan pencarian DNS untuk titik akhir (misalnya,). `https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com` Dalam kluster akses publik, ini menyelesaikan ke alamat IP publik (katakanlah`54.239.118.52`) milik layanan EKS yang berjalan di. AWS`kubelet`Kemudian membuat permintaan HTTPS aman ke titik akhir ini. Paket awal terlihat seperti ini: ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 52390 (random) | | | Dst: 54.239.118.52 | Dst: 443 | | +--------------------+---------------------+-----------------+ ``` **2. Perutean Router Lokal** Karena IP tujuan adalah alamat IP publik dan bukan bagian dari jaringan lokal, paket ini akan `kubelet` dikirim ke gateway defaultnya (router lokal lokal). Router memeriksa IP tujuan dan menentukan itu adalah alamat IP publik. Untuk lalu lintas publik, router biasanya meneruskan paket ke gateway internet atau router perbatasan yang menangani lalu lintas keluar ke internet. Ini dihilangkan dalam diagram dan akan tergantung pada bagaimana jaringan lokal Anda diatur. Paket ini melintasi infrastruktur jaringan lokal Anda dan akhirnya mencapai jaringan penyedia layanan internet Anda. **3. Pengiriman ke pesawat kontrol EKS** Paket ini berjalan melintasi internet publik dan jaringan transit sampai mencapai AWS jaringan. AWS jaringan merutekan paket ke titik akhir layanan EKS di wilayah yang sesuai. Ketika paket mencapai layanan EKS, itu diteruskan ke bidang kontrol EKS yang sebenarnya untuk cluster Anda. Routing ini melalui internet publik berbeda dari jalur privat VPC yang akan kita lihat di arus lalu lintas lainnya. Perbedaan utamanya adalah ketika menggunakan mode akses publik, lalu lintas dari lokal `kubelet` (meskipun bukan dari pod) ke bidang kontrol EKS tidak melalui VPC Anda - ia menggunakan infrastruktur internet global sebagai gantinya. ### Respons Setelah bidang kontrol EKS memproses `kubelet` permintaan, ia mengirimkan respons kembali: **3. Pesawat kontrol EKS mengirimkan respons** Bidang kontrol EKS menciptakan paket respons. Paket ini memiliki IP publik sebagai sumber dan IP node hybrid sebagai tujuan: ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 54.239.118.52 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 52390 | | +--------------------+---------------------+-----------------+ ``` **2. Perutean Internet** Paket respons berjalan kembali melalui internet, mengikuti jalur perutean yang ditentukan oleh penyedia layanan internet, hingga mencapai router tepi jaringan lokal Anda. **1. Pengiriman Lokal** Router lokal Anda menerima paket dan mengenali IP tujuan (`10.80.0.2`) sebagai milik jaringan lokal Anda. Ini meneruskan paket melalui infrastruktur jaringan lokal Anda sampai mencapai target node hybrid, di mana `kubelet` menerima dan memproses respons. ## Node hibrida `kube-proxy` ke bidang kontrol EKS Jika Anda mengaktifkan akses endpoint publik untuk cluster, lalu lintas kembali menggunakan internet publik. Lalu lintas ini berasal dari node hibrida ke bidang kontrol EKS dan mengikuti jalur yang sama dengan lalu lintas dari `kubelet` ke bidang kontrol EKS. `kube-proxy` ## Pesawat kontrol EKS ke node hybrid (`kubelet`server) ![\[Bidang kontrol EKS ke simpul hibrida\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png) ### Permintaan **1. Server API EKS Kubernetes memulai permintaan** Server API EKS Kubernetes mengambil alamat IP node (`10.80.0.2`) dari status objek node. Kemudian merutekan permintaan ini melalui ENI-nya di VPC, karena IP tujuan milik node jarak jauh yang dikonfigurasi CIDR (). `10.80.0.0/16` Paket awal terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 67493 (random) | | | Dst: 10.80.0.2 | Dst: 10250 | | +-----------------+---------------------+-----------------+ ``` **2. Pemrosesan jaringan VPC** Paket meninggalkan ENI dan memasuki lapisan jaringan VPC, di mana ia diarahkan ke gateway subnet untuk perutean lebih lanjut. **3. Pencarian tabel rute VPC** Tabel rute VPC untuk subnet yang berisi bidang kontrol EKS ENI memiliki rute tertentu (yang kedua dalam diagram) untuk simpul jarak jauh CIDR. Berdasarkan aturan routing ini, paket diarahkan ke gateway. VPC-to-onprem **4. Transit lintas batas** Gateway mentransfer paket melintasi batas cloud melalui koneksi yang Anda buat (seperti Direct Connect atau VPN) ke jaringan lokal Anda. **5. Penerimaan jaringan lokal** Paket tiba di router lokal lokal Anda yang menangani lalu lintas untuk subnet tempat node hybrid Anda berada. **6. Pengiriman akhir** Router lokal mengidentifikasi bahwa alamat IP (`10.80.0.2`) tujuan milik jaringan yang terhubung langsung dan meneruskan paket langsung ke node hibrida target, di mana `kubelet` menerima dan memproses permintaan. ### Respons Setelah node hybrid `kubelet` memproses permintaan, ia mengirimkan kembali respons mengikuti jalur yang sama secara terbalik: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 10250 | | | Dst: 10.0.0.132 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **6. `kubelet` Mengirim Respon** `kubelet`Pada node hybrid (`10.80.0.2`) membuat paket respons dengan IP sumber asli sebagai tujuan. Tujuan bukan milik jaringan lokal sehingga dikirim ke gateway default host, yang merupakan router lokal. **5. Perutean Router Lokal** Router menentukan bahwa tujuan IP (`10.0.0.132`) milik`10.0.0.0/16`, yang memiliki rute yang menunjuk ke gateway yang terhubung ke AWS. **4. Pengembalian Lintas Batas** Paket berjalan kembali melalui koneksi lokal ke VPC yang sama (seperti Direct Connect atau VPN), melintasi batas cloud dalam arah sebaliknya. **3. Perutean VPC** Ketika paket tiba di VPC, tabel rute mengidentifikasi bahwa IP tujuan milik CIDR VPC. Rute paket dalam VPC. **2. Pengiriman Jaringan VPC** Lapisan jaringan VPC meneruskan paket ke subnet dengan bidang kontrol EKS ENI (). `10.0.0.132` **1. Penerimaan ENI** Paket mencapai pesawat kontrol EKS ENI yang terpasang ke server API Kubernetes, menyelesaikan perjalanan pulang pergi. ## Pod berjalan pada node hibrid ke bidang kontrol EKS ![\[Pod berjalan pada node hibrid ke bidang kontrol EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png) ### Tanpa CNI NAT ### Permintaan Pod umumnya berbicara dengan server API Kubernetes melalui layanan. `kubernetes` IP layanan adalah IP pertama dari CIDR layanan cluster. Konvensi ini memungkinkan pod yang perlu dijalankan sebelum CoreDNS tersedia untuk mencapai server API, misalnya, CNI. Permintaan meninggalkan pod dengan IP layanan sebagai tujuan. Misalnya, jika layanan CIDR adalah`172.16.0.0/16`, IP layanan akan`172.16.0.1`. **1. Pod Memulai Permintaan** Pod mengirimkan permintaan ke `kubernetes` layanan IP (`172.16.0.1`) pada port server API (443) dari port sumber acak. Paketnya terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. Pengolahan CNI** CNI mendeteksi bahwa IP tujuan bukan milik pod CIDR mana pun yang dikelolanya. Karena **NAT keluar dinonaktifkan**, CNI meneruskan paket ke tumpukan jaringan host tanpa memodifikasinya. **3. Pemrosesan Jaringan Node** Paket memasuki tumpukan jaringan node di mana `netfilter` hook memicu `iptables` aturan yang ditetapkan oleh kube-proxy. Beberapa aturan berlaku dalam urutan sebagai berikut: 1. Paket pertama mengenai `KUBE-SERVICES` rantai, yang berisi aturan yang cocok dengan ClusterIP dan port setiap layanan. 1. Aturan pencocokan melompat ke `KUBE-SVC-XXX` rantai untuk `kubernetes` layanan (paket yang ditujukan untuk`172.16.0.1:443`), yang berisi aturan penyeimbangan beban. 1. Aturan penyeimbangan beban secara acak memilih salah satu `KUBE-SEP-XXX` rantai untuk bidang kontrol ENI IPs (`10.0.0.132`atau). `10.0.1.23` 1. `KUBE-SEP-XXX`Rantai yang dipilih memiliki aturan aktual yang mengubah IP tujuan dari IP layanan ke IP yang dipilih. Ini disebut Destination Network Address Translation (DNAT). Setelah aturan ini diterapkan, dengan asumsi bahwa IP ENI bidang kontrol EKS yang dipilih adalah`10.0.0.132`, paketnya terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` Node meneruskan paket ke gateway defaultnya karena IP tujuan tidak ada di jaringan lokal. **4. Perutean Router Lokal** Router lokal menentukan bahwa IP tujuan (`10.0.0.132`) milik VPC CIDR (`10.0.0.0/16`) dan meneruskannya ke gateway yang terhubung ke. AWS **5. Transit Lintas Batas** Paket berjalan melalui koneksi yang Anda buat (seperti Direct Connect atau VPN) melintasi batas cloud ke VPC. **6. Pengiriman Jaringan VPC** Lapisan jaringan VPC merutekan paket ke subnet yang benar di mana bidang kontrol EKS ENI () `10.0.0.132` berada. **7. Penerimaan ENI** Paket mencapai bidang kontrol EKS ENI yang terpasang ke server API Kubernetes. ### Respons Setelah bidang kontrol EKS memproses permintaan, ia mengirimkan respons kembali ke pod: **7. Server API Mengirim Respons** Server API EKS Kubernetes membuat paket respons dengan IP sumber asli sebagai tujuan. Paketnya terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` Karena IP tujuan milik pod jarak jauh yang dikonfigurasi CIDR (`10.85.0.0/16`), ia mengirimkannya melalui ENI di VPC dengan router subnet sebagai hop berikutnya. **6. Perutean VPC** Tabel rute VPC berisi entri untuk pod jarak jauh CIDR (`10.85.0.0/16`), mengarahkan lalu lintas ini ke gateway. VPC-to-onprem **5. Transit Lintas Batas** Gateway mentransfer paket melintasi batas cloud melalui koneksi yang Anda buat (seperti Direct Connect atau VPN) ke jaringan lokal Anda. **4. Penerimaan Jaringan Lokal** Paket tiba di router lokal lokal Anda. **3. Pengiriman ke node** Tabel router memiliki entri untuk `10.85.1.0/24` dengan `10.80.0.2` sebagai hop berikutnya, mengirimkan paket ke node kami. **2. Pemrosesan Jaringan Node** Karena paket diproses oleh tumpukan jaringan node, `conntrack` (bagian dari`netfilter`) mencocokkan paket dengan koneksi yang awalnya dibuat oleh pod. Karena DNAT awalnya diterapkan, `conntrack` membalikkan DNAT dengan menulis ulang IP sumber dari IP ENI bidang kontrol EKS ke IP layanan: `kubernetes` ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1. Pengolahan CNI** CNI mengidentifikasi bahwa IP tujuan milik sebuah pod dalam jaringannya dan mengirimkan paket ke namespace jaringan pod yang benar. Alur ini menunjukkan mengapa Remote Pod CIDRs harus dapat dirutekan dengan benar dari VPC sampai ke node tertentu yang menghosting setiap pod - seluruh jalur pengembalian bergantung pada perutean pod yang tepat di jaringan cloud dan IPs lokal. ### Dengan CNI NAT Aliran ini sangat mirip dengan yang *tanpa CNI NAT*, tetapi dengan satu perbedaan utama: CNI menerapkan sumber NAT (SNAT) ke paket sebelum mengirimnya ke tumpukan jaringan node. Ini mengubah IP sumber paket ke IP node, memungkinkan paket untuk dirutekan kembali ke node tanpa memerlukan konfigurasi routing tambahan. ### Permintaan **1. Pod Memulai Permintaan** Pod mengirimkan permintaan ke IP `kubernetes` layanan (`172.16.0.1`) pada port server API EKS Kubernetes (443) dari port sumber acak. Paketnya terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. Pengolahan CNI** CNI mendeteksi bahwa IP tujuan bukan milik pod CIDR mana pun yang dikelolanya. Karena **NAT keluar diaktifkan**, CNI menerapkan SNAT ke paket, mengubah IP sumber ke IP node sebelum meneruskannya ke tumpukan jaringan node: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` Catatan: CNI dan `iptables` ditampilkan dalam contoh sebagai blok terpisah untuk kejelasan, tetapi dalam praktiknya, ada kemungkinan beberapa CNIs penggunaan `iptables` untuk menerapkan NAT. **3. Pemrosesan Jaringan Node** Di sini `iptables` aturan yang ditetapkan oleh `kube-proxy` berperilaku sama seperti pada contoh sebelumnya, load balancing paket ke salah satu bidang kontrol EKS. ENIs Paket sekarang terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` Node meneruskan paket ke gateway defaultnya karena IP tujuan tidak ada di jaringan lokal. **4. Perutean Router Lokal** Router lokal menentukan bahwa IP tujuan (`10.0.0.132`) milik VPC CIDR (`10.0.0.0/16`) dan meneruskannya ke gateway yang terhubung ke. AWS **5. Transit Lintas Batas** Paket berjalan melalui koneksi yang Anda buat (seperti Direct Connect atau VPN) melintasi batas cloud ke VPC. **6. Pengiriman Jaringan VPC** Lapisan jaringan VPC merutekan paket ke subnet yang benar di mana bidang kontrol EKS ENI () `10.0.0.132` berada. **7. Penerimaan ENI** Paket mencapai bidang kontrol EKS ENI yang terpasang ke server API Kubernetes. ### Respons Setelah bidang kontrol EKS memproses permintaan, ia mengirimkan respons kembali ke pod: **7. Server API Mengirim Respons** Server API EKS Kubernetes membuat paket respons dengan IP sumber asli sebagai tujuan. Paketnya terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` Karena IP tujuan milik node jarak jauh yang dikonfigurasi CIDR (`10.80.0.0/16`), ia mengirimkannya melalui ENI-nya di VPC dengan router subnet sebagai hop berikutnya. **6. Perutean VPC** Tabel rute VPC berisi entri untuk node jarak jauh CIDR (`10.80.0.0/16`), mengarahkan lalu lintas ini ke gateway. VPC-to-onprem **5. Transit Lintas Batas** Gateway mentransfer paket melintasi batas cloud melalui koneksi yang Anda buat (seperti Direct Connect atau VPN) ke jaringan lokal Anda. **4. Penerimaan Jaringan Lokal** Paket tiba di router lokal lokal Anda. **3. Pengiriman ke node** Router lokal mengidentifikasi bahwa alamat IP (`10.80.0.2`) tujuan milik jaringan yang terhubung langsung dan meneruskan paket langsung ke node hibrida target. **2. Pemrosesan Jaringan Node** Karena paket diproses oleh tumpukan jaringan node, `conntrack` (bagian dari`netfilter`) mencocokkan paket dengan koneksi yang awalnya dibuat oleh pod dan karena DNAT awalnya diterapkan, itu membalikkan ini dengan menulis ulang IP sumber dari IP ENI bidang kontrol EKS ke IP layanan: `kubernetes` ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1. Pengolahan CNI** CNI mengidentifikasi paket ini milik koneksi di mana sebelumnya telah menerapkan SNAT. Ini membalikkan SNAT, mengubah IP tujuan kembali ke IP pod: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` CNI mendeteksi IP tujuan milik sebuah pod dalam jaringannya dan mengirimkan paket ke namespace jaringan pod yang benar. Alur ini menampilkan bagaimana CNI NAT-ing dapat menyederhanakan konfigurasi dengan memungkinkan paket dirutekan kembali ke node tanpa memerlukan perutean tambahan untuk pod. CIDRs ## Pesawat kontrol EKS ke pod yang berjalan pada node hybrid (webhooks) ![\[Pesawat kontrol EKS ke pod yang berjalan pada node hibrid\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png) Pola lalu lintas ini paling sering terlihat dengan webhooks, di mana bidang kontrol EKS perlu langsung memulai koneksi ke server webhook yang berjalan di pod pada node hybrid. Contohnya termasuk memvalidasi dan memutasi webhook masuk, yang dipanggil oleh server API selama validasi sumber daya atau proses mutasi. ### Permintaan **1. Server API EKS Kubernetes memulai permintaan** Ketika webhook dikonfigurasi di cluster dan operasi API yang relevan memicunya, server API EKS Kubernetes perlu membuat koneksi langsung ke pod server webhook. Server API pertama-tama mencari alamat IP pod dari sumber daya Service atau Endpoint yang terkait dengan webhook. Dengan asumsi pod webhook berjalan pada node hybrid dengan IP`10.85.1.23`, server API EKS Kubernetes membuat permintaan HTTPS ke endpoint webhook. Paket awal dikirim melalui bidang kontrol EKS ENI di VPC Anda karena `10.85.1.23` IP tujuan milik pod jarak jauh yang dikonfigurasi `10.85.0.0/16` CIDR (). Paketnya terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 41892 (random) | | | Dst: 10.85.1.23 | Dst: 8443 | | +-----------------+---------------------+-----------------+ ``` **2. Pemrosesan Jaringan VPC** Paket meninggalkan bidang kontrol EKS ENI dan memasuki lapisan jaringan VPC dengan router subnet sebagai lompatan berikutnya. **3. Pencarian Tabel Rute VPC** Tabel rute VPC untuk subnet yang berisi bidang kontrol EKS ENI berisi rute khusus untuk pod jarak jauh CIDR (). `10.85.0.0/16` Aturan routing ini mengarahkan paket ke VPC-to-onprem gateway (misalnya, Virtual Private Gateway untuk Direct Connect atau koneksi VPN): ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` **4. Transit Lintas Batas** Gateway mentransfer paket melintasi batas cloud melalui koneksi yang Anda buat (seperti Direct Connect atau VPN) ke jaringan lokal Anda. Paket ini mempertahankan sumber asli dan alamat IP tujuan saat melintasi koneksi ini. **5. Penerimaan Jaringan Lokal** Paket tiba di router lokal lokal Anda. Router berkonsultasi dengan tabel peruteannya untuk menentukan cara mencapai alamat 10.85.1.23. Agar ini berfungsi, jaringan lokal Anda harus memiliki rute untuk pod CIDRs yang mengarahkan lalu lintas ke node hibrid yang sesuai. Dalam hal ini, tabel rute router berisi entri yang menunjukkan bahwa `10.85.1.0/24` subnet dapat dijangkau melalui node hybrid dengan IP: `10.80.0.2` ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **6. Pengiriman ke node** Berdasarkan entri tabel routing, router meneruskan paket ke node hybrid (). `10.80.0.2` Ketika paket tiba di node, itu terlihat sama seperti ketika server EKS Kubernetes API mengirimnya, dengan IP tujuan masih menjadi IP pod. **7. Pengolahan CNI** Tumpukan jaringan node menerima paket dan, melihat bahwa IP tujuan bukan IP node itu sendiri, meneruskannya ke CNI untuk diproses. CNI mengidentifikasi bahwa IP tujuan milik pod yang berjalan secara lokal pada node ini dan meneruskan paket ke pod yang benar melalui antarmuka virtual yang sesuai: ``` Original packet -> node routing -> CNI -> Pod's network namespace ``` Server webhook di pod menerima permintaan dan memprosesnya. ### Respons Setelah pod webhook memproses permintaan, ia mengirimkan kembali respons mengikuti jalur yang sama secara terbalik: **7. Pod Mengirim Respons** Pod webhook membuat paket respons dengan IP sendiri sebagai sumber dan pemohon asli (ENI bidang kontrol EKS) sebagai tujuan: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.23 | Src: 8443 | | | Dst: 10.0.0.132 | Dst: 41892 | | +-----------------+---------------------+-----------------+ ``` CNI mengidentifikasi bahwa paket ini masuk ke jaringan eksternal (bukan pod lokal) dan meneruskan paket ke tumpukan jaringan node dengan IP sumber asli yang dipertahankan. **6. Pemrosesan Jaringan Node** Node menentukan bahwa IP tujuan (`10.0.0.132`) tidak berada di jaringan lokal dan meneruskan paket ke gateway default (router lokal). **5. Perutean Router Lokal** Router lokal berkonsultasi dengan tabel routing dan menentukan bahwa IP tujuan (`10.0.0.132`) milik VPC CIDR (). `10.0.0.0/16` Ini meneruskan paket ke gateway yang terhubung ke. AWS **4. Transit Lintas Batas** Paket berjalan kembali melalui koneksi lokal ke VPC yang sama, melintasi batas cloud dalam arah sebaliknya. **3. Perutean VPC** Ketika paket tiba di VPC, tabel rute mengidentifikasi bahwa IP tujuan milik subnet dalam VPC. Paket dirutekan sesuai di dalam VPC. **2. dan 1. EKS pesawat kontrol ENI Penerimaan** Paket mencapai ENI yang terpasang ke server API EKS Kubernetes, menyelesaikan perjalanan pulang pergi. Server API menerima respons webhook dan terus memproses permintaan API asli berdasarkan respons ini. Arus lalu lintas ini menunjukkan mengapa pod jarak jauh CIDRs harus dikonfigurasi dan dirutekan dengan benar: + VPC harus memiliki rute untuk pod jarak jauh yang CIDRs mengarah ke gateway lokal + Jaringan lokal Anda harus memiliki rute untuk pod CIDRs yang mengarahkan lalu lintas ke node tertentu yang menghosting pod tersebut + Tanpa konfigurasi routing ini, webhook dan layanan serupa lainnya yang berjalan di pod pada node hybrid tidak akan dapat dijangkau dari bidang kontrol EKS. ## Pod-to-Pod berjalan pada node hybrid ![\[Pod-to Pod berjalan pada node hybrid\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png) Bagian ini menjelaskan bagaimana pod yang berjalan pada node hybrid yang berbeda berkomunikasi satu sama lain. Contoh ini mengasumsikan CNI Anda menggunakan VXLAN untuk enkapsulasi, yang umum untuk seperti Cilium atau Calico. CNIs Proses keseluruhan serupa untuk protokol enkapsulasi lainnya seperti Geneve atau. IP-in-IP ### Permintaan **1. Pod A Memulai Komunikasi** Pod A (`10.85.1.56`) pada Node 1 ingin mengirim lalu lintas ke Pod B (`10.85.2.67`) di Node 2. Paket awal terlihat seperti ini: ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` **2. CNI Mencegat dan Memproses Paket** Ketika paket Pod A meninggalkan namespace jaringannya, CNI mencegatnya. CNI berkonsultasi dengan tabel routing dan menentukan: - Destination IP (`10.85.2.67`) milik pod CIDR - IP ini bukan pada node lokal tetapi milik Node 2 (`10.80.0.3`) - Paket perlu dienkapsulasi dengan VXLAN. Keputusan untuk merangkum sangat penting karena jaringan fisik yang mendasarinya tidak tahu cara merutekan pod CIDRs secara langsung - ia hanya tahu cara merutekan lalu lintas antar node. IPs CNI merangkum seluruh paket asli di dalam bingkai VXLAN. Ini secara efektif menciptakan “paket dalam paket” dengan header baru: ``` +-----------------+----------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node1 MAC | Src: 10.80.0.2 | Src: Random | VNI: 42 | Packet (unchanged | | Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472 | | from above) | +-----------------+----------------+--------------+------------+---------------------------+ ``` Poin-poin penting tentang enkapsulasi ini: - Paket luar dialamatkan dari Node 1 (`10.80.0.2`) ke Node 2 (`10.80.0.3`) - Port UDP `8472` adalah port VXLAN yang digunakan Cilium secara default - VXLAN Network Identifier (VNI) mengidentifikasi jaringan overlay mana yang dimiliki paket ini - Seluruh paket asli (dengan IP Pod A sebagai sumber dan IP Pod B sebagai tujuan) dipertahankan utuh di dalam Paket enkapsulasi sekarang memasuki tumpukan jaringan reguler Node 1 dan diproses dengan cara yang sama seperti paket lainnya: 1. **Pemrosesan Jaringan** Node: Tumpukan jaringan Node 1 merutekan paket berdasarkan tujuannya () `10.80.0.3` 1. **Pengiriman Jaringan Lokal**: + Jika kedua node berada pada jaringan Layer 2 yang sama, paket dikirim langsung ke Node 2 + Jika mereka berada di subnet yang berbeda, paket diteruskan ke router lokal terlebih dahulu 1. **Penanganan Router**: Router meneruskan paket berdasarkan tabel routingnya, mengirimkannya ke Node 2 **3. Menerima Pemrosesan Node** Ketika paket yang dienkapsulasi tiba di Node 2 (): `10.80.0.3` 1. Tumpukan jaringan node menerimanya dan mengidentifikasinya sebagai paket VXLAN (port UDP) `4789` 1. Paket diteruskan ke antarmuka VXLAN CNI untuk diproses **4. Dekapsulasi VXLAN** CNI pada Node 2 memproses paket VXLAN: 1. Ini menghapus header luar (Ethernet, IP, UDP, dan VXLAN) 1. Ini mengekstrak paket batin asli 1. Paket sekarang kembali ke bentuk aslinya: ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` CNI pada Node 2 memeriksa IP tujuan (`10.85.2.67`) dan: 1. Mengidentifikasi bahwa IP ini milik pod lokal 1. Rutekan paket melalui antarmuka virtual yang sesuai 1. Mengirimkan paket ke namespace jaringan Pod B ### Respons Ketika Pod B merespons Pod A, seluruh proses terjadi secara terbalik: 1. Pod B mengirimkan paket ke Pod A () `10.85.1.56` 1. CNI Node 2 merangkum dengan VXLAN, mengatur tujuan ke Node 1 () `10.80.0.2` 1. Paket yang dienkapsulasi dikirim ke Node 1 1. CNI Node 1 mendekapsulasinya dan memberikan respons asli ke Pod A ## Pod pada node cloud ke pod pada node hibrid (lalu lintas timur-barat) ![\[Pod pada node cloud ke pod pada node hibrid\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-east-west.png) ### Permintaan **1. Pod A Memulai Komunikasi** Pod A (`10.0.0.56`) pada EC2 Node ingin mengirim lalu lintas ke Pod B (`10.85.1.56`) pada Node Hybrid. Paket awal terlihat seperti ini: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.56 | Src: 52390 (random) | | | Dst: 10.85.1.56 | Dst: 8080 | | +-----------------+---------------------+-----------------+ ``` Dengan VPC CNI, Pod A memiliki IP dari VPC CIDR dan langsung dilampirkan ke ENI pada instance. EC2 Namespace jaringan pod terhubung ke jaringan VPC, sehingga paket masuk ke infrastruktur routing VPC secara langsung. **2. Perutean VPC** Tabel rute VPC berisi rute khusus untuk Remote Pod CIDR (`10.85.0.0/16`), mengarahkan lalu lintas ini ke gateway: VPC-to-onprem ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` Berdasarkan aturan routing ini, paket diarahkan ke gateway yang terhubung ke jaringan lokal Anda. **3. Transit Lintas Batas** Gateway mentransfer paket melintasi batas cloud melalui koneksi yang Anda buat (seperti Direct Connect atau VPN) ke jaringan lokal Anda. Paket ini mempertahankan sumber asli dan alamat IP tujuan selama transit ini. **4. Penerimaan Jaringan Lokal** Paket tiba di router lokal lokal Anda. Router berkonsultasi dengan tabel peruteannya untuk menentukan lompatan berikutnya untuk mencapai alamat 10.85.1.56. Router lokal Anda harus memiliki rute untuk pod CIDRs yang mengarahkan lalu lintas ke node hybrid yang sesuai. Tabel router memiliki entri yang menunjukkan bahwa `10.85.1.0/24` subnet dapat dijangkau melalui node hybrid dengan IP: `10.80.0.2` ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **5. Pemrosesan Jaringan Node** Router meneruskan paket ke node hybrid ()`10.80.0.2`. Ketika paket tiba di node, ia masih memiliki IP Pod A sebagai sumber dan IP Pod B sebagai tujuan. **6. Pengolahan CNI** Tumpukan jaringan node menerima paket dan, melihat bahwa IP tujuan bukan miliknya sendiri, meneruskannya ke CNI untuk diproses. CNI mengidentifikasi bahwa IP tujuan milik pod yang berjalan secara lokal pada node ini dan meneruskan paket ke pod yang benar melalui antarmuka virtual yang sesuai: ``` Original packet -> node routing -> CNI -> Pod B's network namespace ``` Pod B menerima paket dan memprosesnya sesuai kebutuhan. ### Respons **6. Pod B Mengirimkan Respon** Pod B membuat paket respon dengan IP sendiri sebagai sumber dan IP Pod A sebagai tujuan: ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 8080 | | | Dst: 10.0.0.56 | Dst: 52390 | | +-----------------+---------------------+-----------------+ ``` CNI mengidentifikasi bahwa paket ini ditujukan untuk jaringan eksternal dan meneruskannya ke tumpukan jaringan node. **5. Pemrosesan Jaringan Node** Node menentukan bahwa IP tujuan (`10.0.0.56`) bukan milik jaringan lokal dan meneruskan paket ke gateway defaultnya (router lokal). **4. Perutean Router Lokal** Router lokal berkonsultasi dengan tabel routing dan menentukan bahwa IP tujuan (`10.0.0.56`) milik VPC CIDR (). `10.0.0.0/16` Ini meneruskan paket ke gateway yang terhubung ke. AWS **3. Transit Lintas Batas** Paket berjalan kembali melalui koneksi lokal ke VPC yang sama, melintasi batas cloud dalam arah sebaliknya. **2. Perutean VPC** Ketika paket tiba di VPC, sistem routing mengidentifikasi bahwa IP tujuan milik subnet dalam VPC. Paket dirutekan melalui jaringan VPC menuju instance hosting Pod A. EC2 **1. Pod A Menerima Tanggapan** Paket tiba di EC2 instance dan dikirim langsung ke Pod A melalui ENI yang terpasang. Karena VPC CNI tidak menggunakan jaringan overlay untuk pod di VPC, tidak diperlukan dekapsulasi tambahan - paket tiba dengan header aslinya utuh. Arus lalu lintas timur-barat ini menunjukkan mengapa pod jarak jauh CIDRs harus dikonfigurasi dengan benar dan dapat dirutekan dari kedua arah: + VPC harus memiliki rute untuk pod jarak jauh yang CIDRs mengarah ke gateway lokal + Jaringan lokal Anda harus memiliki rute untuk pod CIDRs yang mengarahkan lalu lintas ke node tertentu yang menghosting pod tersebut.