لن يساعد التلاعب في عنوان IP هنا. سيكون الحل الوحيد في هذه الحالة هو تنظيم واجهات إضافية على العقد العنقودية ، والتي ستكون في شبكات VLAN المطلوبة ، وتنظيم الوصول إلى واجهات إضافية من المشاريع التي نحتاجها داخل المجموعة. ويمكن لمشروع يسمى Multus CNI أن يساعد في ذلك .
Multus CNI
كما تعلم ، بشكل افتراضي ، يحتوي POD في Kubernetes على واجهة واحدة يتم من خلالها التفاعل معها. يتيح لك Multus إنشاء واجهات متعددة في POD بالإضافة إلى الواجهة الافتراضية. في الواقع ، يعد Multus نفسه مكونًا إضافيًا لـ CNI-Plugin ، والذي بدوره يتحكم في استدعاء مكونات CNI-Plugin الأخرى. لهذا يسمى Multus البرنامج المساعد CNI meta. تم توضيح ما يفعله Multus جيدًا في الصورة من مقالة Demystifing Multus :
بالطبع ، يمكن أن يكون عدد الواجهات الإضافية أكثر من واحد.
تكوين Multus CNI في OpenShift
لذلك ، دعونا نحاول حل مشكلة الوصول إلى شبكة محلية ظاهرية مخصصة في كشكنا. بشكل افتراضي ، يتم تعيين جميع عُقد المجموعة على واجهة واحدة موجودة في OpenShift VLAN (IP: 192.168.111 / 24). نريد تنظيم الوصول من مشروع الاختبار المتعدد إلى موارد شبكة 192.168.112 / 24 الموجودة في شبكة VLAN المقيدة. لا يتم توجيه VLAN المقيدة و VLAN OpenShift إلى بعضهما البعض.
أولاً ، دعنا نضيف واجهة من VLAN المقيدة إلى عدد من العقد (في حالتنا ، هذه هي Node1 و Node2) ، ونضع تسمية node-role.kubernetes.io/multus-node= "نعم" على هذه العقد . ستتوفر الموارد من شبكة VLAN المقيدة من العقد ذات التسمية متعددة العقد. لنقم بإنشاء مشروع الاختبار المتعدد الخاص بنا:
[ocp@shift-is01 macvlan]$ oc new-project multus-test
كان دعم Multus CNI موجودًا في OpenShift لفترة طويلة ، ولا داعي لإضافته بشكل منفصل. تتم إدارة التكوين المتعدد عبر CR في شبكات CRD networks.operator.openshift.io . تحتاج إلى تحرير هذا المورد عن طريق إضافة تكوين CNI Plugin للواجهة الجديدة:
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" } }
هذه اللحظة تتطلب فك التشفير. ما الذي حددناه بهذا التكوين؟
- بالنسبة إلى POD ، ستتم إضافة واجهة باسم "net1" في مشروع الاختبار المتعدد
- سيتم تحديد تكوين هذه الواجهة من خلال CNI Plugin "ipvlan" ؛
- تم تكوين CNI Plugin ipvlan في وضع L2 ؛
- يتم استخدام الواجهة المادية لعقدة ens224 كواجهة رئيسية لـ net1 ؛
- أخيرًا ، سيتم استخدام المكون الإضافي IPAM الثابت لإدارة عناوين IP.
اختيار البرنامج المساعد CNI
بالنسبة إلى واجهتنا الإضافية ، تحتاج إلى تحديد المكون الإضافي CNI المستخدم. يمكن العثور على قائمة البرنامج المساعد CNI على الموقع الإلكتروني www.cni.dev . في مثالنا ، نستخدم المكون الإضافي ipvlan . في الواقع ، هذا هو أبسط جسر يسمح للحاويات بالاتصال من خلال واجهة الشبكة الخارجية للمضيف. في هذه الحالة ، تستخدم جميع الاتصالات الصادرة عنوان IP الخاص بها ، ولكن سيكون لها عنوان MAC الخاص بواجهة الشبكة الخارجية. توضح الصورة من موقع hicu.be جيدًا المكون الإضافي ipvlan:
في البيئات الإنتاجية ، غالبًا ما يتم اختيار المكون الإضافي macvlan ، والذي يختلف عن ipvlan في أن الاتصالات الصادرة لها عناوين MAC فريدة. ولكن في هذه الحالة ، غالبًا ما يكون من الضروري إعداد البنية التحتية للشبكة بحيث تسمح معدات الشبكة بنقل الحزم بعناوين MAC مختلفة من منفذ واحد.
تحديد البرنامج المساعد IPAM
بالإضافة إلى تنظيم واجهة الشبكة ، نحتاج إلى تحديد قواعد إصدار عنوان IP للواجهة الجديدة. يتم التعامل مع هذا أيضًا بواسطة CNI Plugin ، والذي يقوم بتنفيذ وظائف إدارة عنوان IP (أو IPAM). يمكن أيضًا العثور على قائمة الإضافات IPAM- المحتملة على www.cni.dev . في هذا المثال ، استخدمنا أبسط مكون إضافي IPAM ثابت يقوم بتعيين عنوان ثابت لـ POD الخاص بنا.
إذا كان هناك العديد من هذه PODs ، فستصبح IPAM الثابتة غير مريحة. الخيار الجيد هنا هو إما استخدام المكون الإضافي dhcp (يقوم بتعيين عناوين IP الخاصة بـ POD عبر طلب إلى خادم DHCP خارجي) أو استخدام المكون الإضافي لمكان وجوده .
يتوفر دعم البرنامج المساعد IPAM أيضًا بشكل افتراضي بتنسيق OpenShift ، لست بحاجة إلى تثبيتها بشكل منفصل.
وصول مقيد لشبكة VLAN
بعد تحديد تكوين Multus الخاص بنا ، يجب أن يظهر مورد يسمى تعريف مرفق الشبكة في المجموعة ، مما يعكس تكوين Multus الحالي:
تعريف مرفق الشبكة
[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" } }
لنقم بإنشاء POD اختباري بواجهة إضافية يمكنها الوصول إلى شبكة VLAN المقيدة:
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"]
دعنا ننتقل إلى POD الذي تم إنشاؤه لعرض تكوين الشبكة الخاص به والتحقق من توفر العناوين في شبكة VLAN المقيدة (على شبكة 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
كما ترى من إخراج الأمر "ip a" ، تلقى POD واجهة شبكة إضافية net1 @ if826 وعنوان IP الذي حددناه في بيانه. نظرًا لأن الواجهة الإضافية تعمل من خلال محول إيثرنت في شبكة VLAN المقيدة ، فقد حصلنا من هذا POD على وصول إلى جزء الشبكة الذي نحتاجه.
المؤلف: سيرجي أرتيموف ، رئيس قسم حلول DevOps ، Jet Infosystems
انضم إلى قناة Telegram الخاصة بنا على محادثاتDevSecOps !