**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 untuk node hibrida
Dengan *Amazon EKS Hybrid Nodes*, Anda menggabungkan mesin fisik atau virtual yang berjalan di lingkungan lokal atau edge ke kluster Amazon EKS yang berjalan di AWS Cloud. Pendekatan ini membawa banyak manfaat, tetapi juga memperkenalkan konsep dan arsitektur jaringan baru bagi mereka yang akrab dengan menjalankan klaster Kubernetes dalam satu lingkungan jaringan.
Bagian berikut menyelam jauh ke dalam Kubernetes dan konsep jaringan untuk EKS Hybrid Nodes dan merinci bagaimana lalu lintas mengalir melalui arsitektur hybrid. Bagian ini mengharuskan Anda memahami pengetahuan dasar jaringan Kubernetes, seperti konsep pod, node, layanan, bidang kontrol Kubernetes, kubelet, dan kube-proxy.
Kami merekomendasikan membaca halaman-halaman ini secara berurutan[Konsep jaringan untuk node hibrida](hybrid-nodes-concepts-networking.md), dimulai dengan[Konsep Kubernetes untuk node hibrida](hybrid-nodes-concepts-kubernetes.md), lalu, dan akhirnya[Arus lalu lintas jaringan untuk node hibrida](hybrid-nodes-concepts-traffic-flows.md).
**Topics**
+ [Konsep jaringan untuk node hibrida](hybrid-nodes-concepts-networking.md)
+ [Konsep Kubernetes untuk node hibrida](hybrid-nodes-concepts-kubernetes.md)
+ [Arus lalu lintas jaringan untuk node hibrida](hybrid-nodes-concepts-traffic-flows.md)
# Konsep jaringan untuk node hibrida
Bagian ini merinci konsep jaringan inti dan kendala yang harus Anda pertimbangkan saat merancang topologi jaringan Anda untuk EKS Hybrid Nodes.
## Konsep jaringan untuk EKS Hybrid Nodes
![\[Diagram jaringan node hibrida tingkat tinggi\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-highlevel-network.png)
**VPC sebagai hub jaringan**
Semua lalu lintas yang melintasi rute batas cloud melalui VPC Anda. Ini termasuk lalu lintas antara bidang kontrol EKS atau pod yang berjalan AWS ke node hibrida atau pod yang berjalan di atasnya. Anda dapat menganggap VPC cluster Anda sebagai hub jaringan antara node hybrid Anda dan cluster lainnya. Arsitektur ini memberi Anda kontrol penuh atas lalu lintas dan peruteannya tetapi juga menjadikannya tanggung jawab Anda untuk mengonfigurasi rute, grup keamanan, dan firewall dengan benar untuk VPC.
**Pesawat kontrol EKS ke VPC**
Bidang kontrol EKS memasang **Elastic Network Interfaces (ENIs)** ke VPC Anda. Ini ENIs menangani lalu lintas ke dan dari server API EKS. Anda mengontrol penempatan bidang kontrol EKS ENIs saat mengonfigurasi klaster, saat EKS ENIs menempel pada subnet yang Anda lewati selama pembuatan klaster.
EKS mengaitkan Grup Keamanan dengan EKS ENIs yang melekat pada subnet Anda. Kelompok keamanan ini memungkinkan lalu lintas ke dan dari pesawat kontrol EKS melalui ENIs. Ini penting untuk EKS Hybrid Nodes karena Anda harus mengizinkan lalu lintas dari node hybrid dan pod yang berjalan di atasnya ke bidang kontrol EKS ENIs.
**Jaringan Node Jarak Jauh**
Jaringan node jarak jauh, khususnya node jarak jauh CIDRs, adalah rentang yang IPs ditugaskan ke mesin yang Anda gunakan sebagai node hibrida. Saat Anda menyediakan node hibrid, node tersebut berada di pusat data lokal atau lokasi edge Anda, yang merupakan domain jaringan yang berbeda dari bidang kontrol EKS dan VPC. Setiap node hybrid memiliki alamat IP, atau alamat, dari node jarak jauh CIDR yang berbeda dari subnet di VPC Anda.
Anda mengonfigurasi cluster EKS dengan node jarak jauh ini CIDRs sehingga EKS tahu untuk merutekan semua lalu lintas yang ditujukan untuk node hybrid IPs melalui VPC cluster Anda, seperti permintaan ke kubelet API. Koneksi ke `kubelet` API digunakan dalam`kubectl attach`,,`kubectl cp`, `kubectl exec``kubectl logs`, dan `kubectl port-forward` perintah.
**Jaringan Pod Jarak Jauh**
Jaringan pod jarak jauh adalah rentang yang IPs ditetapkan ke pod yang berjalan pada node hybrid. Umumnya, Anda mengonfigurasi CNI Anda dengan rentang ini dan fungsionalitas IP Address Management (IPAM) dari CNI menangani penetapan sepotong rentang ini ke setiap node hybrid. Saat Anda membuat pod, CNI memberikan IP ke pod dari irisan yang dialokasikan ke node tempat pod telah dijadwalkan.
Anda mengonfigurasi cluster EKS dengan pod jarak jauh ini CIDRs sehingga control plane EKS tahu untuk merutekan semua lalu lintas yang ditujukan untuk pod yang berjalan pada node hybrid melalui VPC klaster Anda, seperti komunikasi dengan webhook.
![\[Jaringan Pod Jarak Jauh\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/hybrid-nodes-remote-pod-cidrs.png)
**Lokal ke VPC**
Jaringan lokal yang Anda gunakan untuk node hibrid harus merutekan ke VPC yang Anda gunakan untuk kluster EKS Anda. Ada beberapa [opsi konektivitas Network-to-Amazon VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) yang tersedia untuk menghubungkan jaringan lokal Anda ke VPC. Anda juga dapat menggunakan solusi VPN Anda sendiri.
Penting bagi Anda untuk mengonfigurasi perutean dengan benar di sisi AWS Cloud di VPC dan di jaringan lokal Anda, sehingga kedua jaringan merutekan lalu lintas yang tepat melalui koneksi untuk kedua jaringan tersebut.
Di VPC, semua lalu lintas yang menuju ke node jarak jauh dan jaringan pod jarak jauh harus merutekan melalui koneksi ke jaringan lokal Anda (disebut sebagai “gateway”). Jika beberapa subnet Anda memiliki tabel rute yang berbeda, Anda harus mengonfigurasi setiap tabel rute dengan rute untuk node hibrida dan pod yang berjalan di atasnya. Hal ini berlaku untuk subnet di mana bidang kontrol EKS ENIs dilampirkan, dan subnet yang berisi EC2 node atau pod yang harus berkomunikasi dengan node hibrida.
Di jaringan lokal, Anda harus mengonfigurasi jaringan untuk mengizinkan lalu lintas ke dan dari VPC kluster EKS Anda dan layanan AWS lain yang diperlukan untuk node hibrid. Lalu lintas untuk cluster EKS melintasi gateway di kedua arah.
## Kendala jaringan
**Jaringan yang sepenuhnya dirutekan**
Kendala utama adalah bahwa bidang kontrol EKS dan semua node, cloud atau node hybrid, perlu membentuk jaringan yang **sepenuhnya dirutekan**. Ini berarti bahwa semua node harus dapat menjangkau satu sama lain pada lapisan tiga, dengan alamat IP.
Bidang kontrol EKS dan node awan sudah dapat dijangkau satu sama lain karena mereka berada dalam jaringan datar (VPC). Node hybrid, bagaimanapun, berada dalam domain jaringan yang berbeda. Inilah sebabnya mengapa Anda perlu mengonfigurasi perutean tambahan di VPC dan di jaringan lokal Anda untuk merutekan lalu lintas antara node hibrida dan cluster lainnya. Jika node hybrid dapat dijangkau satu sama lain dan dari VPC, node hybrid Anda dapat berada dalam satu jaringan datar tunggal atau di beberapa jaringan tersegmentasi.
**Pod jarak jauh yang dapat dirutekan CIDRs**
Agar control plane EKS dapat berkomunikasi dengan pod yang berjalan pada node hybrid (misalnya, webhook atau Metrics Server) atau untuk pod yang berjalan di cloud node untuk berkomunikasi dengan pod yang berjalan pada node hybrid (beban kerja komunikasi timur-barat), pod jarak jauh CIDR Anda harus dapat dirutekan dari VPC. Ini berarti bahwa VPC harus dapat merutekan lalu lintas ke pod CIDRs melalui gateway ke jaringan lokal Anda dan bahwa jaringan lokal Anda harus dapat merutekan lalu lintas pod ke node yang tepat.
Penting untuk dicatat perbedaan antara persyaratan perutean pod di VPC dan lokal. VPC hanya perlu tahu bahwa setiap lalu lintas yang menuju pod jarak jauh harus melalui gateway. Jika Anda hanya memiliki satu pod jarak jauh CIDR, Anda hanya perlu satu rute.
Persyaratan ini berlaku untuk semua hop di jaringan lokal Anda hingga router lokal di subnet yang sama dengan node hybrid Anda. Ini adalah satu-satunya router yang perlu mengetahui potongan CIDR pod yang ditetapkan untuk setiap node, memastikan bahwa lalu lintas untuk pod tertentu dikirim ke node tempat pod telah dijadwalkan.
Anda dapat memilih untuk menyebarkan rute ini untuk pod lokal CIDRs dari router lokal lokal Anda ke tabel rute VPC, tetapi tidak perlu. Jika pod lokal Anda sering CIDRs berubah dan tabel rute VPC Anda perlu diperbarui untuk mencerminkan pod yang berubah, sebaiknya Anda menyebarkan CIDRs pod lokal CIDRs ke tabel rute VPC, tetapi hal ini jarang terjadi.
Perhatikan, kendala untuk membuat pod lokal Anda dapat CIDRs dirutekan adalah opsional. Jika Anda tidak perlu menjalankan webhook pada node hybrid atau pod di cloud node berbicara dengan pod pada node hybrid, Anda tidak perlu mengonfigurasi routing untuk pod CIDRs di jaringan lokal Anda.
*Mengapa pod lokal CIDRs harus dapat dirutekan dengan node hybrid?*
Saat menggunakan EKS dengan VPC CNI untuk node cloud Anda, VPC CNI menugaskan langsung IPs dari VPC ke pod. Ini berarti tidak diperlukan perutean khusus, karena kedua pod cloud dan bidang kontrol EKS dapat mencapai Pod secara IPs langsung.
Saat menjalankan on-premise (dan dengan yang lain CNIs di cloud), pod biasanya berjalan di jaringan overlay yang terisolasi dan CNI menangani pengiriman lalu lintas antar pod. Ini biasanya dilakukan melalui enkapsulasi: CNI mengubah pod-to-pod lalu lintas menjadi lalu node-to-node lintas, mengurus enkapsulasi dan de-enkapsulasi di kedua ujungnya. Dengan cara ini, tidak perlu konfigurasi tambahan pada node dan pada router.
Jaringan dengan node hibrida unik karena menyajikan kombinasi kedua topologi - bidang kontrol EKS dan node cloud (dengan VPC CNI) mengharapkan jaringan datar termasuk node dan pod, sedangkan pod yang berjalan pada node hibrida berada dalam jaringan overlay dengan menggunakan VXLAN untuk enkapsulasi (secara default di Cilium). Pod yang berjalan pada node hybrid dapat mencapai control plane EKS dan pod yang berjalan di cloud node dengan asumsi jaringan lokal dapat merutekan ke VPC. Namun, tanpa merutekan pod CIDRs di jaringan lokal, lalu lintas apa pun yang kembali ke IP pod lokal akan dihapus pada akhirnya jika jaringan tidak tahu cara menjangkau jaringan overlay dan merutekan ke node yang benar.
# 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: \$1 Service ClusterIP: \$1 Service port: `172.16.31.14` \$1 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 `clusters0.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: \$1 Tidak perlu mengkonfigurasi router Anda dengan BGP atau mempertahankan rute statis \$1 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.
# 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.