Dokumen ini menjelaskan cara mengonfigurasi GKE di VMware untuk menyediakan beberapa antarmuka jaringan, multi-NIC, untuk Pod Anda. Fitur multi-NIC untuk Pod dapat membantu memisahkan traffic bidang kontrol dari traffic bidang data, sehingga menciptakan isolasi antarbidang. Antarmuka jaringan tambahan juga memungkinkan kemampuan multicast untuk Pod Anda. Multi-NIC untuk Pod didukung untuk cluster pengguna, tetapi tidak diizinkan untuk cluster admin.
Isolasi bidang jaringan penting untuk sistem yang menggunakan virtualisasi fungsi jaringan (NFV), seperti software-defined networking di jaringan area luas (SD-WAN), broker keamanan akses cloud (CASB), dan firewall generasi berikutnya (NG-FW). Jenis NFV ini bergantung pada akses ke beberapa antarmuka untuk menjaga agar kontrol dan bidang data tetap terpisah.
Konfigurasi beberapa antarmuka jaringan mendukung pengaitan antarmuka jaringan dengan kumpulan node, yang dapat memberikan manfaat performa. Misalnya, cluster dapat berisi campuran berbagai jenis node. Saat mengelompokkan mesin berperforma tinggi ke dalam satu kumpulan node, Anda dapat membuat antarmuka tambahan ke kumpulan node tersebut untuk meningkatkan arus traffic.
Menyiapkan beberapa antarmuka jaringan
Secara umum, ada tiga langkah untuk menyiapkan beberapa antarmuka jaringan untuk Pod Anda:
Aktifkan multi-NIC untuk cluster pengguna Anda menggunakan kolom
multipleNetworkInterfaces
danenableDataplaneV2
di file konfigurasi cluster.Tentukan antarmuka jaringan dengan bagian
additionalNodeInterfaces
di file konfigurasi cluster, dan buat satu atau beberapa resource kustomNetworkAttachmentDefinition
.Tetapkan antarmuka jaringan ke Pod dengan anotasi
k8s.v1.cni.cncf.io/networks
.
Mengaktifkan multi-NIC
Aktifkan multi-NIC untuk Pod Anda dengan menetapkan kolom multipleNetworkInterfaces
dan enableDataplaneV2
di file konfigurasi cluster pengguna ke true
.
apiVersion: v1 multipleNetworkInterfaces: true enableDataplaneV2: true ...
Menentukan antarmuka jaringan
Di file konfigurasi cluster, tentukan antarmuka jaringan node tambahan di bagian additionalNodeInterfaces
.
Misalnya, berikut adalah bagian dari file konfigurasi cluster pengguna yang menampilkan antarmuka jaringan node tambahan:
apiVersion: v1 multipleNetworkInterfaces: true enableDataplaneV2: true network: serviceCIDR: "10.96.0.0/20" podCIDR: "192.168.0.0/16" vCenter: networkName: network-private310 ... # New multiple network configs additionalNodeInterfaces: - networkName: "gke-network-1" ipBlockFilePath: "my-block-yaml" type: static
Setelah membuat cluster dengan konfigurasi sebelumnya, Anda harus membuat satu atau beberapa resource kustom NetworkAttachmentDefinition
(NAD) dalam cluster pengguna tempat Anda menentukan antarmuka jaringan tambahan. NetworkAttachmentDefinitions
sesuai dengan jaringan yang tersedia untuk Pod Anda. Contoh berikut menunjukkan manifes untuk NetworkAttachmentDefinition
:
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: gke-network-1 namespace: default spec: config: '{ "cniVersion":"0.3.0", "type": "ipvlan", "master": "ens224", # defines the node interface that this Pod interface would map to "mode": "l2", "ipam": { "type": "whereabouts", "range": "172.16.0.0/24" } }'
Simpan manifes sebagai file YAML, misalnya, my-nad.yaml
, lalu buat NetworkAttachmentDefinition
:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f my-nad.yaml
Menetapkan antarmuka jaringan ke Pod
Gunakan anotasi k8s.v1.cni.cncf.io/networks
untuk menetapkan satu atau beberapa antarmuka jaringan ke Pod. Setiap antarmuka jaringan ditentukan dengan namespace dan nama NetworkAttachmentDefinition
, yang dipisahkan dengan garis miring (/
). Gunakan daftar yang dipisahkan koma untuk menentukan beberapa antarmuka jaringan.
Pada contoh berikut, dua antarmuka jaringan ditetapkan ke Pod samplepod
. Antarmuka jaringan ditentukan oleh nama dua NetworkAttachmentDefinitions
, gke-network-1
, dan gke-network-2
, yang dibuat di namespace default
.
--- apiVersion: v1 kind: Pod metadata: name: samplepod annotations: k8s.v1.cni.cncf.io/networks: default/gke-network-1,default/gke-network-2 spec: containers: ...
Membatasi antarmuka jaringan ke kumpulan node
Jika tidak ingin NetworkAttachmentDefinition
berlaku untuk seluruh cluster, Anda dapat membatasi fungsinya ke kumpulan node.
Anda dapat mengelompokkan node cluster menggunakan label standar yang ditetapkan ke node atau label khusus Anda sendiri. Anda kemudian dapat menentukan label node dalam manifes NetworkAttachmentDefinition
menggunakan anotasi k8s.v1.cni.cncf.io/nodeSelector
. GKE di VMware memaksakan Pod apa pun yang mereferensikan resource kustom ini untuk di-deploy pada node yang memiliki label ini.
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: annotations: k8s.v1.cni.cncf.io/nodeSelector: LABEL_KEY=LABEL_VALUE name: gke-network-1 spec: ...
Contoh berikut menunjukkan label my-label=multinicNP
yang ditunjukkan pada NetworkAttachmentDefinition
, dan memaksa deployment semua Pod yang diberi jaringan gke-network-1
ke node yang memiliki label ini.
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: annotations: k8s.v1.cni.cncf.io/nodeSelector: my-label=multinicNP name: gke-network-1 spec: ...
Untuk menerapkan label kustom ke node, gunakan perintah kubectl label nodes
:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes NODE_NAME LABEL_KEY=LABEL_VALUE
Ganti kode berikut:
NODE_NAME
: nama Node yang Anda beri label.LABEL_KEY
: kunci yang akan digunakan untuk label.LABEL_VALUE
: nilai label.
Dalam contoh ini, node my-node
diberi label environment=production
:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes my-node environment=production
Masalah keamanan
NetworkAttachmentDefinition
memberikan akses penuh ke jaringan, sehingga administrator cluster harus berhati-hati dalam menyediakan akses untuk membuat, memperbarui, atau menghapus akses kepada pengguna lain. Jika NetworkAttachmentDefinition
tertentu harus diisolasi, Anda dapat menentukan namespace non-default saat membuatnya, dan hanya Pod dari namespace tersebut yang dapat
mengaksesnya.
Dalam diagram berikut, Pod dari namespace default
tidak dapat mengakses antarmuka jaringan di namespace privileged
.
Plugin CNI yang didukung
Bagian ini mencantumkan
plugin Cni yang didukung oleh fitur multi-NIC untuk GKE di VMware. Hanya gunakan plugin berikut saat menentukan NetworkAttachmentDefinition
.
Pembuatan antarmuka:
ipvlan
macvlan
bridge
Plugin meta:
portmap
sbr
tuning
Plugin IPAM:
host-local
static
whereabouts
Konfigurasi rute
Pod dengan satu atau beberapa NetworkAttachmentDefinitions
yang ditetapkan memiliki beberapa antarmuka jaringan. Secara default, tabel perutean Pod dalam situasi ini diperluas dengan antarmuka tambahan yang tersedia secara lokal hanya dari NetworkAttachmentDefinitions
yang ditetapkan. Paket yang terikat untuk gateway default tetap dikonfigurasi untuk menggunakan antarmuka default Pod, eth0
.
Anda dapat mengubah perilaku ini menggunakan plugin CNI berikut:
sbr
static
whereabouts
Misalnya, Anda mungkin ingin sebagian besar traffic melewati gateway default, yang berarti traffic akan melewati antarmuka jaringan default. Namun, Anda ingin beberapa traffic tertentu melewati salah satu antarmuka non-default. Traffic bisa jadi sulit dibedakan berdasarkan IP tujuan (perutean normal), karena endpoint yang sama tersedia di kedua jenis antarmuka. Dalam hal ini, pemilihan rute berbasis sumber (SBR) dapat membantu.
Plugin SBR
Plugin sbr
memberi aplikasi kontrol atas keputusan pemilihan rute. Aplikasi mengontrol apa yang digunakan sebagai alamat IP sumber koneksi yang dibuatnya. Saat aplikasi memilih untuk menggunakan alamat IP NetworkAttachmentDefinition
untuk IP sumbernya, paket akan masuk ke tabel perutean tambahan yang telah disiapkan sbr
. Tabel perutean sbr
mengirimkan traffic melalui gateway defaultnya sendiri, yang akan melewati antarmuka NetworkAttachmentDefinition
. IP gateway default di dalam tabel tersebut dikontrol dengan kolom gateway
di dalam plugin whereabouts
atau static
. Plugin sbr
berjalan sebagai plugin berantai. Untuk mengetahui informasi selengkapnya tentang plugin sbr
, termasuk informasi penggunaan, lihat Plugin pemilihan rute berbasis sumber.
Contoh berikut menunjukkan "gateway":"21.0.111.254"
yang ditetapkan di whereabouts
, dan sbr
ditetapkan sebagai plugin berantai setelah ipvlan
:
# ip route
default via 192.168.0.64 dev eth0 mtu 1500
192.168.0.64 dev eth0 scope link
# ip route list table 100
default via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
Statis dan plugin keberadaan
Plugin whereabouts
pada dasarnya adalah ekstensi dari plugin static
dan keduanya berbagi konfigurasi perutean. Untuk contoh konfigurasi, lihat plugin pengelolaan alamat IP statis.
Anda dapat menentukan gateway dan rute yang akan ditambahkan ke tabel perutean Pod. Namun, Anda tidak dapat memodifikasi gateway default Pod dengan cara ini.
Contoh berikut menunjukkan penambahan "routes": [{ "dst": "172.31.0.0/16" }]
dalam NetworkAttachmentDefinition
:
# ip route
default via 192.168.0.64 dev eth0 mtu 1500
172.31.0.0/16 via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
192.168.0.64 dev eth0 scope link
Contoh konfigurasi
Bagian ini menggambarkan beberapa konfigurasi jaringan umum yang didukung oleh fitur multi-NIC.
Lampiran jaringan tunggal yang digunakan oleh beberapa Pod:
Beberapa lampiran jaringan yang digunakan oleh satu Pod:
Beberapa lampiran jaringan yang mengarah ke antarmuka yang sama dengan yang digunakan oleh satu Pod:
Lampiran jaringan yang sama digunakan beberapa kali oleh satu Pod:
Memecahkan masalah
Jika antarmuka jaringan tambahan salah dikonfigurasi, Pod tempatnya tidak akan dimulai. Bagian ini menyoroti cara menemukan informasi untuk memecahkan masalah terkait fitur multi-NIC.
Memeriksa peristiwa Pod
Multus melaporkan kegagalan melalui peristiwa Pod Kubernetes. Gunakan perintah kubectl describe
berikut untuk melihat peristiwa untuk Pod tertentu:
kubectl describe pod POD_NAME
Memeriksa log
Untuk setiap node, Anda dapat menemukan log Whereabouts dan Multus di lokasi berikut:
/var/log/whereabouts.log
/var/log/multus.log
Meninjau antarmuka Pod
Gunakan perintah kubectl exec
untuk memeriksa antarmuka Pod Anda. Setelah NetworkAttachmentDefinitions
berhasil diterapkan, antarmuka Pod akan terlihat seperti output berikut:
user@node1:~$ kubectl exec samplepod-5c6df74f66-5jgxs -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 00:50:56:82:3e:f0 brd ff:ff:ff:ff:ff:ff
inet 21.0.103.112/21 scope global net1
valid_lft forever preferred_lft forever
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 36:23:79:a9:26:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.2.191/32 scope global eth0
valid_lft forever preferred_lft forever
Mendapatkan status Pod
Gunakan kubectl get
untuk mengambil status jaringan untuk Pod tertentu:
kubectl get pods POD_NAME -oyaml
Berikut ini contoh output yang menunjukkan status Pod dengan beberapa jaringan:
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/network-status: |-
[{
"name": "",
"interface": "eth0",
"ips": [
"192.168.1.88"
],
"mac": "36:0e:29:e7:42:ad",
"default": true,
"dns": {}
},{
"name": "default/gke-network-1",
"interface": "net1",
"ips": [
"21.0.111.1"
],
"mac": "00:50:56:82:a7:ab",
"dns": {}
}]
k8s.v1.cni.cncf.io/networks: gke-network-1