Manipulasi alamat IP tidak akan membantu di sini. Satu-satunya solusi dalam hal ini adalah pengorganisasian antarmuka tambahan pada node kluster, yang akan berada di VLAN yang diperlukan, dan pengorganisasian akses ke antarmuka tambahan dari proyek yang kami butuhkan di dalam kluster. Dan sebuah proyek bernama Multus CNI dapat membantu dalam hal ini .
Multus CNI
Seperti yang Anda ketahui, secara default, POD di Kubernetes memiliki satu antarmuka tempat semua interaksi dengannya berlangsung. Multus memungkinkan Anda membuat beberapa antarmuka di POD selain antarmuka default. Faktanya, Multus sendiri adalah CNI-Plugin, yang pada gilirannya mengontrol panggilan dari CNI-Plugin lainnya. Untuk Multus ini disebut Plugin meta CNI. Apa yang dilakukan Multus diilustrasikan dengan baik dalam gambar dari artikel Demystifing Multus :
Tentu saja, jumlah antarmuka tambahan bisa lebih dari satu.
Konfigurasi Multus CNI di OpenShift
Jadi, mari kita coba selesaikan masalah akses ke VLAN khusus di stan kami. Secara default, semua node cluster diberikan satu antarmuka yang terletak di OpenShift VLAN (IP: 192.168.111 / 24). Kami ingin mengatur akses dari proyek multesest ke sumber daya jaringan 192.168.112 / 24 yang terletak di VLAN Dibatasi. VLAN Dibatasi dan VLAN OpenShift tidak dirutekan satu sama lain.
Pertama, tambahkan antarmuka dari VLAN Dibatasi ke sejumlah node (dalam kasus kami, ini adalah Node1 dan Node2), dan beri label node-role.kubernetes.io/multus-node= 'yes' pada node ini . Sumber daya dari VLAN Terbatas akan tersedia dari node dengan label multus-node. Mari buat proyek multus-test kita:
[ocp@shift-is01 macvlan]$ oc new-project multus-test
Dukungan Multus CNI telah hadir di OpenShift sejak lama, tidak perlu menambahkannya secara terpisah. Manajemen konfigurasi multus dilakukan melalui CR di jaringan CRD.operator.openshift.io . Anda perlu mengedit sumber daya ini dengan menambahkan konfigurasi Plugin CNI untuk antarmuka baru:
oc edit networks.operator.openshift.io cluster
spec: additionalNetworks: - name : net1 namespace: multus-test type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "master": "ens224", "ipam": { "type": "static" } }
Momen ini membutuhkan decoding. Apa yang telah kita definisikan dengan konfigurasi ini?
- Untuk POD, antarmuka bernama "net1" akan ditambahkan dalam proyek multus-test
- Konfigurasi antarmuka ini akan ditentukan melalui Plugin CNI "ipvlan";
- Plugin CNI ipvlan dikonfigurasi dalam Mode L2;
- Antarmuka fisik dari simpul ens224 digunakan sebagai antarmuka utama untuk net1;
- Terakhir, plugin statis IPAM akan digunakan untuk mengelola pengalamatan IP.
Memilih Plugin CNI
Untuk antarmuka tambahan kami, Anda perlu memilih Plugin CNI yang digunakan. Daftar Plugin CNI yang mungkin dapat ditemukan di situs web www.cni.dev . Dalam contoh kami, kami menggunakan plugin ipvlan . Faktanya, ini adalah jembatan paling sederhana yang memungkinkan kontainer berkomunikasi melalui antarmuka jaringan eksternal host. Dalam kasus ini, semua koneksi keluar menggunakan alamat IP mereka sendiri, tetapi akan memiliki alamat MAC dari antarmuka jaringan eksternal. Gambar dari situs hicu.be menggambarkan dengan baik plugin ipvlan:
Dalam lingkungan produktif, plugin macvlan lebih sering dipilih , yang berbeda dari ipvlan karena koneksi keluar memiliki alamat MAC yang unik. Tetapi dalam kasus ini, seringkali infrastruktur jaringan perlu disiapkan sehingga peralatan jaringan memungkinkan transmisi paket dengan alamat MAC yang berbeda dari satu port.
Memilih Plugin IPAM
Selain mengatur antarmuka jaringan, kita perlu menentukan aturan untuk menerbitkan alamat IP untuk antarmuka baru. Ini juga ditangani oleh Plugin CNI, yang mengimplementasikan fungsi Manajemen Alamat IP (atau IPAM). Daftar plugin IPAM- yang mungkin juga dapat ditemukan di www.cni.dev . Dalam contoh ini, kami menggunakan plugin IPAM statis paling sederhana yang memberikan alamat tetap ke POD kami.
Jika ada banyak POD seperti itu, IPAM statis akan menjadi tidak nyaman. Pilihan yang baik di sini adalah menggunakan plugin dhcp (ini memberikan alamat IP POD melalui permintaan ke server DHCP eksternal) atau menggunakan plugin keberadaan .
Dukungan untuk Plugin IPAM ini juga tersedia secara default di OpenShift , Anda tidak perlu menginstalnya secara terpisah.
Akses VLAN terbatas
Setelah menentukan konfigurasi Multus kami, sumber daya yang disebut Definisi Lampiran Jaringan akan muncul di kluster, yang mencerminkan konfigurasi Multus saat ini:
Definisi Lampiran Jaringan
[ocp@shift-is01 macvlan]$ oc get network-attachment-definitions --all-namespaces NAMESPACE NAME AGE multus-test net1 3m4s [ocp@shift-is01 macvlan]$ oc get network-attachment-definitions.k8s.cni.cncf.io -n multus-test net1 -o yaml apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: creationTimestamp: "2020-11-02T16:44:46Z" generation: 1 managedFields: - apiVersion: k8s.cni.cncf.io/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:ownerReferences: .: {} k:{"uid":"01a4f46a-fc3c-495f-b196-b39352421e2a"}: .: {} f:apiVersion: {} f:blockOwnerDeletion: {} f:controller: {} f:kind: {} f:name: {} f:uid: {} f:spec: .: {} f:config: {} manager: cluster-network-operator operation: Update time: "2020-11-02T16:44:46Z" name: net1 namespace: multus-test ownerReferences: - apiVersion: operator.openshift.io/v1 blockOwnerDeletion: true controller: true kind: Network name: cluster uid: 01a4f46a-fc3c-495f-b196-b39352421e2a resourceVersion: "25898949" selfLink: /apis/k8s.cni.cncf.io/v1/namespaces/multus-test/network-attachment-definitions/net1 uid: 7a7d718b-82c5-46fe-8f72-8fd4299508ec spec: config: |- { "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "master": "ens224", "ipam": { "type": "static" } }
Mari buat POD percobaan dengan antarmuka tambahan yang akan memiliki akses ke VLAN terbatas kami:
pod-ipvlan-static.yaml
[ocp@shift-is01 ipvlan]$ cat ./pod-ipvlan-static.yaml apiVersion: v1 kind: Pod metadata: namespace: multus-test name: test-multus-pod labels: app: test-multus-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "net1", "ips": ["192.168.112.250/24"] } ]' spec: nodeSelector: node-role.kubernetes.io/multus-node: yes containers: - name: test-multus-pod image: centos/tools command: ["/bin/bash", "-c", "sleep 9000000"]
Mari pergi ke POD yang dibuat untuk melihat konfigurasi jaringannya dan memeriksa ketersediaan alamat di VLAN terbatas (di jaringan 192.168.112.0/24):
ocp@shift-is01 ipvlan]$ oc rsh test-multus-pod sh-4.2# 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 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if2142: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 0a:58:0a:fe:04:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.254.4.160/24 brd 10.254.4.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::bc4b:abff:fe0b:91f8/64 scope link valid_lft forever preferred_lft forever 4: net1@if826: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether 00:50:56:96:f3:02 brd ff:ff:ff:ff:ff:ff inet 192.168.112.250/24 brd 192.168.112.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::50:5600:196:f302/64 scope link valid_lft forever preferred_lft forever sh-4.2# ping 192.168.112.1 -c 3 PING 192.168.112.1 (192.168.112.1) 56(84) bytes of data. 64 bytes from 192.168.112.1: icmp_seq=1 ttl=64 time=0.179 ms 64 bytes from 192.168.112.1: icmp_seq=2 ttl=64 time=0.230 ms 64 bytes from 192.168.112.1: icmp_seq=3 ttl=64 time=0.223 ms --- 192.168.112.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2041ms rtt min/avg/max/mdev = 0.179/0.210/0.230/0.028 ms
Seperti yang Anda lihat dari output dari perintah "ip a", POD menerima antarmuka jaringan net1 @ if826 tambahan dan alamat IP yang kami tentukan dalam manifesnya. Karena antarmuka tambahan bekerja melalui adaptor ethernet di VLAN terbatas, dari POD ini kami mendapat akses ke segmen jaringan yang kami butuhkan.
Penulis: Sergey Artemov, Kepala Departemen Solusi DevOps, Jet Infosystems
Bergabunglah dengan saluran Telegram kami @DevSecOps Talks !