Mengonfigurasi beberapa antarmuka jaringan untuk pod

Dokumen ini menjelaskan cara mengonfigurasi Google Distributed Cloud untuk menyediakan beberapa antarmuka jaringan, multi-NIC, untuk pod Anda. Fitur multi-NIC untuk pod dapat membantu memisahkan lalu lintas bidang kontrol dari lalu lintas bidang data, sehingga menciptakan antar pesawat. Antarmuka jaringan tambahan juga memungkinkan kemampuan multicast untuk pod Anda. Multi-NIC untuk pod didukung untuk cluster pengguna, hybrid cluster, dan cluster mandiri. Hal ini tidak diizinkan untuk cluster jenis admin.

Halaman ini ditujukan untuk pakar Jaringan yang menginstal, mengonfigurasi, dan mendukung peralatan jaringan. Untuk mempelajari lebih lanjut tentang peran umum dan contoh tugas yang kami di konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise yang umum.

Isolasi bidang jaringan penting untuk sistem yang menggunakan fungsi jaringan virtualisasi (NFV), seperti software-defined networking di area yang luas jaringan (SD-WAN), broker keamanan akses cloud (CASB), dan penyedia firewall (NG-FW). Jenis NFV ini bergantung pada akses ke banyak antarmuka untuk menjaga agar manajemen dan bidang data tetap terpisah, saat beroperasi sebagai kontainer.

Konfigurasi beberapa antarmuka jaringan mendukung pengaitan jaringan dengan kumpulan node, yang dapat memberikan manfaat performa. {i>Clusters<i} dapat berisi campuran jenis node. Saat Anda mengelompokkan komputer berperforma tinggi ke dalam satu kumpulan node, Anda dapat menambahkan antarmuka tambahan ke kumpulan node arus lalu lintas.

Menyiapkan beberapa antarmuka jaringan

Umumnya, ada tiga langkah untuk menyiapkan beberapa antarmuka jaringan untuk pod:

  1. Aktifkan multi-NIC untuk cluster Anda dengan Kolom multipleNetworkInterfaces di resource kustom cluster.

  2. Menentukan antarmuka jaringan dengan NetworkAttachmentDefinition resource kustom.

  3. Menetapkan antarmuka jaringan ke pod dengan anotasi k8s.v1.cni.cncf.io/networks.

Informasi tambahan disediakan untuk membantu Anda mengonfigurasi dan menggunakan multi-NIC dengan cara yang paling sesuai dengan kebutuhan jaringan Anda.

Mengaktifkan multi-NIC

Aktifkan multi-NIC untuk pod Anda dengan menambahkan kolom multipleNetworkInterfaces ke bagian clusterNetwork dari 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 jaringan tambahan antarmuka. Resource kustom NetworkAttachmentDefinition sesuai dengan jaringan yang tersedia untuk pod Anda. Anda dapat menentukan resource kustom dalam konfigurasi cluster, seperti yang ditunjukkan dalam contoh berikut, atau Anda dapat buat 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" }
    ]
  }
}'

Bila Anda menentukan resource kustom NetworkAttachmentDefinition di dalam file konfigurasi cluster, Google Distributed Cloud menggunakan nama ini untuk mengontrol Resource kustom NetworkAttachmentDefinition setelah pembuatan cluster. Google Distributed Cloud memperlakukan resource kustom ini di dalam namespace cluster sebagai sumber kebenaran dan merekonsiliasinya dengan namespace default dari cluster target.

Diagram berikut mengilustrasikan cara Google Distributed Cloud melakukan rekonsiliasi NetworkAttachmentDefinition resource kustom dari cluster khusus namespace ke namespace default.

Rekonsiliasi NetworkLampiranDefinition

Meskipun opsional, sebaiknya Anda menentukan NetworkAttachmentDefinition resource kustom dengan cara ini, selama cluster pembuatan konten. Cluster pengguna akan mendapatkan manfaat paling banyak saat Anda menentukan resource kustom selama pembuatan cluster, karena Anda kemudian dapat mengontrol NetworkAttachmentDefinition resource kustom dari cluster admin.

Jika Anda memilih untuk tidak menentukan resource kustom NetworkAttachmentDefinition selama pembuatan cluster, Anda dapat menambahkan NetworkAttachmentDefinition resource langsung ke cluster target yang ada. Google Distributed Cloud merekonsiliasi NetworkAttachmentDefinition resource kustom yang ditentukan di cluster namespace. Rekonsiliasi juga dilakukan setelah penghapusan. Ketika seorang NetworkAttachmentDefinition resource kustom dihapus dari cluster namespace, Google Distributed Cloud menghapus resource kustom dari target .

Menetapkan antarmuka jaringan ke pod

Gunakan anotasi k8s.v1.cni.cncf.io/networks untuk menetapkan satu atau beberapa jaringan antarmuka ke pod. Setiap antarmuka jaringan ditetapkan dengan namespace dan nama resource kustom NetworkAttachmentDefinition, yang dipisahkan oleh elemen garis miring ke depan (/).

---
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: NAMESPACE/NAD_NAME
spec:
  containers:
  ...

Ganti kode berikut:

  • NAMESPACE: namespace. Gunakan default untuk untuk namespace default, yang merupakan standar. Lihat Masalah keamanan sebagai pengecualian.
  • NAD_NAME: nama Resource kustom NetworkAttachmentDefinition.

Gunakan daftar yang dipisahkan koma untuk menentukan beberapa antarmuka jaringan.

Pada contoh berikut, dua antarmuka jaringan ditetapkan ke samplepod Pod. Antarmuka jaringan ditentukan dengan nama dari dua NetworkAttachmentDefinition resource kustom, gke-network-1, dan gke-network-2, di 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 yang mana resource kustom NetworkAttachmentDefinition-nya valid. Google Distributed Cloud memaksa tiap pod yang merujuk ke resource kustom ini untuk yang di-deploy pada node spesifik tersebut. Dalam contoh berikut, Google Distributed Cloud memaksa deployment semua pod yang diberi Antarmuka jaringan gke-network-1 ke NodePool multinicNP. Google Distributed Cloud melabeli NodePool dengan Beri label baremetal.cluster.gke.io/node-pool sebagaimana mestinya.

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 sendiri, kumpulan kustom 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 metode baremetal.cluster.gke.io/label-taint-no-sync pada node tersebut untuk mencegah Google Distributed Cloud merekonsiliasi label. Gunakan Perintah kubectl get nodes --show-labels untuk memverifikasi apakah node diberi label.

Masalah keamanan

Resource kustom NetworkAttachmentDefinition memberikan akses penuh ke yang berbeda, jadi administrator cluster harus berhati-hati dalam menyediakan, memperbarui, atau menghapus akses ke pengguna lain. Jika suatu Resource kustom NetworkAttachmentDefinition harus diisolasi, dapat berupa ditempatkan di namespace non-default, karena hanya pod dari namespace tersebut yang dapat mengaksesnya. Untuk merekonsiliasi NetworkAttachmentDefinition resource kustom yang ditentukan di file konfigurasi cluster, mereka akan selalu ditempatkan di namespace.

Pada diagram berikut, pod dari namespace default tidak dapat mengakses jaringan dalam namespace privileged.

Penggunaan namespace untuk mengisolasi traffic jaringan

Plugin CNI yang didukung

Bagian ini mencantumkan Plugin CNI didukung oleh fitur multi-NIC untuk Google Distributed Cloud. Hanya gunakan plugin berikut saat menentukan NetworkAttachmentDefinition plugin resource Anda

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 {i>default<i}, tabel {i>routing<i} dalam situasi ini diperluas dengan antarmuka tambahan yang tersedia secara lokal dari NetworkAttachmentDefinition resource kustom saja. Gateway default-nya adalah masih dikonfigurasi untuk menggunakan antarmuka master/default pod, eth0.

Anda dapat mengubah perilaku ini menggunakan plugin CNI berikut:

  • sbr
  • static
  • whereabouts

Misalnya, Anda mungkin ingin semua traffic melewati gateway default, yaitu dalam antarmuka default-nya. Namun, beberapa traffic tertentu melewati salah satu antarmuka non-default. Lalu lintas bisa sulit untuk dibedakan berdasarkan IP tujuan (perutean normal), karena endpoint yang sama tersedia melalui kedua jenis antarmuka. Dalam hal ini, perutean berbasis sumber (SBR) dapat membantu.

Plugin SBR

Plugin sbr memberi aplikasi kontrol atas keputusan pemilihan rute. Tujuan aplikasi mengontrol apa yang digunakan sebagai alamat IP sumber dari koneksi yang terbentuk. Bila aplikasi memilih untuk menggunakan Alamat IP resource kustom NetworkAttachmentDefinition untuk IP sumbernya, paket mendarat di tabel perutean tambahan yang telah disiapkan sbr. Pemilihan rute sbr tabel akan 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. Masukkan Plugin sbr sebagai plugin berantai. Untuk 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

Plugin statis dan lokasi

Plugin whereabouts pada dasarnya adalah ekstensi dari plugin static dan keduanya memiliki konfigurasi perutean yang sama. Untuk contoh konfigurasi, lihat plugin pengelolaan alamat IP statis. Anda dapat menentukan gateway dan rute untuk ditambahkan ke tabel perutean pod. Anda tidak bisa, tetapi, modifikasi gateway default pod dengan cara ini.

Contoh berikut menunjukkan penambahan "routes": [{ "dst": "172.31.0.0/16" }] dalam NetworkAttachmentDefinition resource kustom:

# 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 digunakan oleh beberapa pod

Satu lampiran jaringan digunakan oleh beberapa pod

Beberapa lampiran jaringan digunakan oleh satu pod

Beberapa lampiran jaringan digunakan oleh satu pod

Beberapa lampiran jaringan yang mengarah ke antarmuka yang sama dengan 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

Lampiran jaringan yang sama digunakan beberapa kali oleh satu pod

Memecahkan masalah

Jika antarmuka jaringan tambahan salah dikonfigurasi, pod tempat keduanya berada tidak dapat dimulai. Bagian ini menyoroti cara menemukan informasi untuk memecahkan masalah dengan fitur multi-NIC.

Memeriksa peristiwa pod

Multus melaporkan kegagalan melalui peristiwa pod Kubernetes. Gunakan yang berikut Perintah kubectl describe untuk melihat peristiwa pada pod tertentu:

kubectl describe pod POD_NAME

Memeriksa log

Untuk setiap node, Anda dapat menemukan log Whereabouts dan Multus pada lokasi:

  • /var/log/whereabouts.log
  • /var/log/multus.log

Meninjau antarmuka pod

Gunakan perintah kubectl exec untuk memeriksa antarmuka pod Anda. Setelah NetworkAttachmentDefinition resource kustom berhasil diterapkan, pod antarmuka 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 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