Dokumen ini menjelaskan cara mengonfigurasi GDCV untuk Bare Metal guna menyediakan beberapa antarmuka jaringan, multi-NIC, untuk pod Anda. Multi-NIC untuk fitur pod dapat membantu memisahkan traffic bidang kontrol dari traffic bidang data, sehingga menciptakan isolasi antar-bidang. Antarmuka jaringan tambahan juga mengaktifkan kemampuan multicast untuk pod Anda. Multi-NIC untuk pod didukung untuk cluster pengguna, cluster hibrid, dan cluster mandiri. Fitur ini tidak diizinkan untuk cluster jenis 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 agar pengelolaan dan bidang data tetap terpisah, sekaligus berjalan sebagai container.
Beberapa konfigurasi antarmuka jaringan mendukung pengaitan antarmuka jaringan dengan kumpulan node, yang dapat memberikan manfaat performa. Cluster dapat berisi campuran berbagai jenis node. Saat mengelompokkan mesin berperforma tinggi ke dalam satu kumpulan node, Anda dapat menambahkan antarmuka tambahan ke kumpulan node tersebut untuk meningkatkan alur traffic.
Menyiapkan beberapa antarmuka jaringan
Secara umum, ada tiga langkah untuk menyiapkan beberapa antarmuka jaringan untuk pod Anda:
Aktifkan multi-NIC untuk cluster Anda dengan kolom
multipleNetworkInterfaces
di resource kustom cluster.Tentukan antarmuka jaringan dengan resource kustom
NetworkAttachmentDefinition
.Tetapkan antarmuka jaringan ke pod dengan anotasi
k8s.v1.cni.cncf.io/networks
.
Informasi tambahan diberikan untuk membantu Anda mengonfigurasi dan menggunakan fitur multi-NIC dengan cara yang paling sesuai dengan persyaratan jaringan Anda.
Aktifkan multi-NIC
Aktifkan multi-NIC untuk pod Anda dengan menambahkan kolom multipleNetworkInterfaces
ke bagian clusterNetwork
resource kustom cluster dan menyetelnya ke
true
.
...
clusterNetwork:
multipleNetworkInterfaces: true
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/20
...
Menentukan antarmuka jaringan
Gunakan resource kustom NetworkAttachmentDefinition
untuk menentukan antarmuka jaringan
tambahan. Resource kustom NetworkAttachmentDefinition
berkaitan dengan
jaringan yang tersedia untuk pod Anda. Anda dapat menentukan resource kustom
dalam konfigurasi cluster, seperti yang ditunjukkan dalam contoh berikut, atau Anda dapat
membuat resource kustom NetworkAttachmentDefinition
secara langsung.
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: my-cluster
namespace: cluster-my-cluster
spec:
type: user
clusterNetwork:
multipleNetworkInterfaces: true
...
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-network-1
namespace: cluster-my-cluster
spec:
config: '{
"cniVersion":"0.3.0",
"type": "ipvlan",
"master": "enp2342", # defines the node interface that this pod interface would
map to.
"mode": "l2",
"ipam": {
"type": "whereabouts",
"range": "172.120.0.0/24"
}
}'
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-network-2
namespace: cluster-my-cluster
spec:
config: '{
"cniVersion":"0.3.0",
"type": "macvlan",
"mode": "bridge",
"master": "vlan102",
"ipam": {
"type": "static",
"addresses": [
{
"address": "10.10.0.1/24",
"gateway": "10.10.0.254"
}
],
"routes": [
{ "dst": "192.168.0.0/16", "gw": "10.10.5.1" }
]
}
}'
Saat Anda menentukan resource kustom NetworkAttachmentDefinition
dalam
file konfigurasi cluster, GKE di Bare Metal akan menggunakan nama ini untuk mengontrol
resource kustom NetworkAttachmentDefinition
setelah pembuatan cluster.
GKE on Bare Metal memperlakukan resource kustom ini di dalam namespace cluster
sebagai sumber kebenaran dan merekonsiliasi ke namespace default
cluster target.
Diagram berikut mengilustrasikan cara GKE on Bare Metal merekonsiliasi resource kustom NetworkAttachmentDefinition
dari namespace khusus cluster ke namespace default
.
Meskipun bersifat opsional, sebaiknya tentukan
resource kustom NetworkAttachmentDefinition
dengan cara ini, selama pembuatan
cluster. Cluster pengguna mendapatkan manfaat paling besar jika Anda menentukan resource kustom
selama pembuatan cluster, karena Anda kemudian dapat mengontrol
resource kustom NetworkAttachmentDefinition
dari cluster admin.
Jika memilih untuk tidak menentukan resource kustom NetworkAttachmentDefinition
selama pembuatan cluster, Anda dapat menambahkan resource kustom
NetworkAttachmentDefinition
langsung ke cluster target yang ada. GKE on Bare Metal merekonsiliasi NetworkAttachmentDefinition
resource kustom yang ditentukan di namespace cluster. Rekonsiliasi juga terjadi setelah penghapusan. Jika
resource kustom NetworkAttachmentDefinition
dihapus dari namespace
cluster, GKE di Bare Metal akan menghapus resource kustom tersebut dari cluster
target.
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 resource kustom NetworkAttachmentDefinition
, yang dipisahkan dengan
garis miring (/
).
---
apiVersion: v1
kind: Pod
metadata:
name: samplepod
annotations:
k8s.v1.cni.cncf.io/networks: NAMESPACE/NAD_NAME
spec:
containers:
...
Ganti kode berikut:
NAMESPACE
: namespace. Gunakandefault
untuk namespace default, yang merupakan standar. Lihat Masalah keamanan untuk mendapatkan pengecualian.NAD_NAME
: nama resource kustomNetworkAttachmentDefinition
.
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
resource kustom NetworkAttachmentDefinition
, gke-network-1
dan
gke-network-2
, dalam namespace default cluster target.
---
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 NodePool
Gunakan anotasi k8s.v1.cni.cncf.io/nodeSelector
untuk menentukan kumpulan
node dengan resource kustom NetworkAttachmentDefinition
yang valid.
GKE pada Bare Metal memaksa setiap pod yang mereferensikan resource kustom ini untuk di-deploy pada node tertentu tersebut. Dalam contoh berikut,
GKE pada Bare Metal memaksa deployment semua pod yang diberi
antarmuka jaringan gke-network-1
ke NodePool multinicNP
.
GKE pada Bare Metal memberi label NodePool dengan label baremetal.cluster.gke.io/node-pool
yang sesuai.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
annotations:
k8s.v1.cni.cncf.io/nodeSelector: baremetal.cluster.gke.io/node-pool=multinicNP
name: gke-network-1
spec:
...
Anda tidak dibatasi untuk menggunakan label standar. Anda dapat membuat kumpulan kustom sendiri dari node cluster dengan menerapkan label kustom ke node tersebut.
Gunakan perintah kubectl label nodes
untuk menerapkan label kustom:
kubectl 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 Anda.LABEL_VALUE
: nama label.
Setelah node diberi label, terapkan anotasi baremetal.cluster.gke.io/label-taint-no-sync
pada node tersebut untuk mencegah GKE pada Bare Metal merekonsiliasi label. Gunakan
perintah kubectl get nodes --show-labels
untuk memverifikasi apakah node diberi label.
Masalah keamanan
Resource kustom NetworkAttachmentDefinition
memberikan akses penuh ke
jaringan, sehingga administrator cluster harus berhati-hati dalam menyediakan akses buat,
perbarui, atau hapus akses kepada pengguna lain. Jika resource kustom
NetworkAttachmentDefinition
tertentu harus diisolasi, resource tersebut dapat
ditempatkan di namespace non-default, yang hanya dapat diakses oleh pod dari namespace tersebut. Untuk merekonsiliasi resource kustom NetworkAttachmentDefinition
yang ditentukan
dalam file konfigurasi cluster, resource tersebut selalu ditempatkan di namespace
default.
Dalam diagram berikut, pod dari namespace default
tidak dapat mengakses
antarmuka jaringan dalam namespace privileged
.
Plugin CNI yang didukung
Bagian ini mencantumkan
plugin CNI
yang didukung oleh fitur multi-NIC untuk GKE di Bare Metal. Hanya gunakan
plugin berikut saat menentukan resource kustom
NetworkAttachmentDefinition
.
Pembuatan antarmuka:
ipvlan
macvlan
bridge
sriov
Plugin meta:
portmap
sbr
tuning
Plugin IPAM:
host-local
static
whereabouts
Konfigurasi rute
Pod dengan satu atau beberapa resource kustom NetworkAttachmentDefinition
yang ditetapkan memiliki beberapa antarmuka jaringan. Secara default, tabel perutean dalam situasi ini
diperluas dengan antarmuka tambahan yang tersedia secara lokal dari
resource kustom NetworkAttachmentDefinition
yang ditetapkan saja. Gateway default masih dikonfigurasi untuk menggunakan antarmuka master/default pod, eth0
.
Anda dapat memodifikasi perilaku ini menggunakan plugin CNI berikut:
sbr
static
whereabouts
Misalnya, Anda mungkin ingin semua traffic melewati gateway default, yaitu antarmuka default. Namun, beberapa traffic tertentu melewati salah satu antarmuka non-default. Traffic dapat sulit dibedakan berdasarkan IP tujuan (perutean normal), karena endpoint yang sama tersedia di kedua jenis antarmuka. Dalam hal ini, perutean 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 resource kustom NetworkAttachmentDefinition
untuk IP sumbernya, paket akan masuk ke tabel perutean tambahan yang telah disiapkan sbr
. Tabel pemilihan rute sbr
menetapkan antarmuka resource kustom NetworkAttachmentDefinition
sebagai gateway default. IP gateway default di dalam tabel tersebut dikontrol dengan kolom gateway
di dalam plugin whereabouts
atau static
. Menyediakan
plugin sbr
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
yang 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
Plugin statis dan lokasi
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 mengubah gateway default pod dengan cara ini.
Contoh berikut menunjukkan penambahan
"routes": [{ "dst": "172.31.0.0/16" }]
dalam resource kustom
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.
Satu lampiran jaringan yang digunakan oleh beberapa pod
Beberapa lampiran jaringan yang digunakan oleh satu pod
Beberapa lampiran jaringan yang mengarah ke antarmuka yang sama yang digunakan oleh pod tunggal
Lampiran jaringan yang sama digunakan beberapa kali oleh pod tunggal
Memecahkan masalah
Jika antarmuka jaringan tambahan salah dikonfigurasi, pod tempat antarmuka tersebut tidak akan dimulai. Bagian ini menyoroti cara menemukan informasi untuk memecahkan masalah pada fitur multi-NIC.
Memeriksa peristiwa pod
Multus
melaporkan kegagalan melalui peristiwa pod Kubernetes. Gunakan perintah kubectl describe
berikut untuk melihat peristiwa pada 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
resource kustom NetworkAttachmentDefinition
berhasil diterapkan, antarmuka pod
akan terlihat seperti output berikut:
$ 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