MicroShift पर Secure Gateway
Red Hat Device Edge पर Secure Gateway डिप्लॉय करें, जहाँ gateway और इसका encrypted cache Roboflow Deployment Manager द्वारा प्रबंधित MicroShift workloads के रूप में चलते हैं।
सुरक्षित गेटवे यह MicroShift, जो एज डिवाइसों के लिए Red Hat का Kubernetes वितरण है, का उपयोग करके Red Hat Device Edge पर भी चलता है। एक समर्पित इंस्टॉलर गेटवे और उसके एन्क्रिप्टेड कैश को Kubernetes वर्कलोड के रूप में तैनात करता है, जिनकी निगरानी Roboflow Deployment Manager (rfdm) द्वारा की जाती है, जो RHEL होस्ट पर चलता है। आपको Docker डिप्लॉयमेंट जैसा ही गेटवे मिलता है (एक नियंत्रित egress बिंदु जो Roboflow API को प्रॉक्सी करता है और आपके फ़्लीट के लिए मॉडल वज़न और कंटेनर इमेज कैश करता है), जिसे Red Hat Device Edge पर मानकीकृत होस्ट्स के लिए पैकेज किया गया है।
आर्किटेक्चर
Roboflow Deployment Manager RHEL होस्ट पर एक systemd सेवा के रूप में चलता है और MicroShift के Kubernetes API के माध्यम से वर्कलोड्स को प्रबंधित करता है। यह गेटवे को कॉन्फ़िगर, अपडेट और चालू रखता है।
गेटवे और उसका कैश बैकएंड (SeaweedFS, एन्क्रिप्शन-एट-रेस्ट वाला S3-संगत स्टोर)
roboflow-edgeनेमस्पेस में Deployments के रूप में चलते हैं।एक
LoadBalancerService डिवाइस IP पर गेटवे को प्रकाशित करती है: पोर्ट443पर HTTPS और पोर्ट80.पर HTTP-से-HTTPS रीडायरेक्ट। कैश MicroShift के LVMS storage provisioner द्वारा प्रावधान किए गए एक persistent volume पर संग्रहीत होता है। volume claim 60 GB का है, जो गेटवे के 50 GB कैश और अतिरिक्त जगह के लिए पर्याप्त है।
सभी वर्कलोड MicroShift की डिफ़ॉल्ट restricted सुरक्षा प्रोफ़ाइल के तहत बिना विशेषाधिकार के चलते हैं: कोई privileged container नहीं, कोई root उपयोगकर्ता नहीं, और कोई कस्टम security context grant नहीं।
यह एक single-node डिप्लॉयमेंट है। High availability और multi-node क्लस्टर समर्थित नहीं हैं।
पूर्वापेक्षाएँ
x86_64 पर Red Hat Enterprise Linux 9.6 होस्ट, वैध Red Hat subscription के साथ। इंस्टॉलर बंडल इसके लिए बनाया गया है
linux-amd64केवल।Red Hat build of MicroShift 4.16 या उससे नया, जो आपके OpenShift pull secret के साथ इंस्टॉल और रन हो रहा हो। 4.20 (EUS) अनुशंसित है; देखें समर्थन मैट्रिक्स.
कम-से-कम 60 GB खाली वाले LVM volume group। MicroShift का LVMS provisioner इससे गेटवे का कैश वॉल्यूम बनाता है; यदि कोई volume group नहीं है, या खाली स्थान बहुत कम है, तो storage request
लंबित रहता हैऔर कैश कभी शुरू नहीं होता।skopeoहोस्ट पर इंस्टॉल किया गया (sudo dnf install skopeo। इंस्टॉलर इसके साथ bundled images को CRI-O के storage में कॉपी करता है और यदि यह गायब हो तो रुक जाता है।OpenShift CLI (
oc) होस्ट पर इंस्टॉल किया गया हो, और उसका संस्करण आपके MicroShift रिलीज़ से मेल खाता हो। MicroShift इसे इंस्टॉल नहीं करता, और इस पेज पर दिए गए सत्यापन तथा troubleshooting कमांड इसका उपयोग करते हैं। इसे sudo कीsecure_path(/usr/binकाम करता है):sudoहटा देता है/usr/local/binसेPATHको, इसलिएocवहाँ अनपैक करने पर मिलता हैsudo: oc: command not found.पोर्ट्स
80और443डिवाइस IP पर गेटवे के लिए उपलब्धकनेक्टेड इंस्टॉल के लिए, आउटबाउंड HTTPS
api.roboflow.comऔरrepo.roboflow.com
यदि firewalld चल रहा है, जो स्टॉक RHEL इंस्टॉलेशन में होता है, तो इंस्टॉल करने से पहले गेटवे के पोर्ट खोलें और MicroShift के pod नेटवर्क को trusted zone में डालें। इसके बिना, pod networking और client access दोनों विफल हो जाते हैं:
firewalld को reload करने से MicroShift pod networking तब तक टूट जाती है जब तक OVN pods पुनः शुरू नहीं हो जाते, इसलिए reload के बाद समस्या निवारण.
में दिए गए recovery चरण का पालन करें। इंस्टॉलर MicroShift के डिफ़ॉल्ट ingress router को अक्षम कर देता है ताकि गेटवे डिवाइस पर पोर्ट 80 और 443 का स्वामी बन सके। यदि आप इस होस्ट पर पहले से router के माध्यम से अन्य workloads सेवा दे रहे हैं, तो यह डिप्लॉयमेंट मॉडल उनसे टकराता है: गेटवे के लिए एक समर्पित डिवाइस का उपयोग करें।
कनेक्टेड होस्ट पर इंस्टॉल करें
MicroShift इंस्टॉलर बंडल डाउनलोड करें और उसकी अखंडता सत्यापित करें:
इसे निकालें और इंस्टॉलर को root के रूप में चलाएँ:
इंस्टॉलर:
यह जाँचता है कि MicroShift चल रहा है और समर्थित संस्करण पर है, तथा storage के लिए एक LVM volume group उपलब्ध है।
बंडल की गई Secure Gateway और SeaweedFS images को होस्ट के container storage में लोड करता है। रजिस्ट्री से कुछ भी pull नहीं किया जाता।
CRI-O की कॉन्फ़िगरेशन में images को pin करता है ताकि Kubernetes की disk-pressure garbage collection उन्हें कभी न हटाए।
MicroShift के डिफ़ॉल्ट ingress router को अक्षम करता है और MicroShift को पुनः प्रारंभ करता है, जिससे गेटवे के लिए पोर्ट 80 और 443 मुक्त हो जाते हैं।
Roboflow Deployment Manager को systemd सेवा के रूप में इंस्टॉल करता है और उसकी device configuration लिखता है।
Deployment Manager को शुरू करता है, जो
roboflow-edgeनेमस्पेस बनाता है और गेटवे तथा कैश को तैनात करता है।
परिनियोजन सत्यापित करें:
दोनों pods को चल रहा होना चाहिएहोने चाहिए, और health check को HTTP 200 लौटाना चाहिए। -k फ़्लैग तब तक आवश्यक है जब तक आप गेटवे के प्रमाणपत्र पर भरोसा नहीं करते; देखें TLS और ट्रस्ट.
एयर-गैप्ड इंस्टॉल करें
यही बंडल बिना इंटरनेट एक्सेस वाले होस्ट्स पर भी इंस्टॉल होता है। कंटेनर images इसमें OCI archives के रूप में शिप होती हैं और सीधे होस्ट के container storage में लोड की जाती हैं। वर्कलोड सटीक version tags को संदर्भित करते हैं, इसलिए इंस्टॉल के समय या बाद में कभी भी रजिस्ट्री से कुछ भी pull नहीं किया जाता।
कनेक्टेड मशीन पर बंडल डाउनलोड और सत्यापित करें, इसे रिमूवेबल मीडिया या अपने आंतरिक file transfer process से डिवाइस तक पहुँचाएँ, फिर extract करके चलाएँ install-microshift.sh ठीक ऊपर दिए अनुसार। सत्यापन वही है।
TLS और ट्रस्ट
डिफ़ॉल्ट रूप से, Roboflow Deployment Manager गेटवे के लिए एक self-signed certificate बनाता है और उसे secure-gateway-tls Secret (type kubernetes.io/tls) में roboflow-edge नेमस्पेस। गेटवे pod इस Secret को mount करता है और पोर्ट 443 पर HTTPS सर्व करता है। यह certificate Deployment Manager reinstalls के बाद भी बना रहता है। Deployment Manager इसे तब बदल देता है जब यह गायब हो, जब इसकी समाप्ति के 30 दिनों के भीतर हो, जब certificate और private key मेल न खाते हों, या जब यह उन सभी नामों को अब कवर न करता हो जिन्हें नया certificate कवर करता।
आपके अपने certificate को उन सभी नामों को कवर करना होगा, अन्यथा Deployment Manager अगली reconcile पर उसे self-signed वाले से बदल देता है:
repo.roboflow.com,*.roboflow.comऔरlocalhost. क्लाइंट्स गेटवे तक इनके अंतर्गत पहुँचते हैंrepo.roboflow.com, इसलिए यदि certificate इसे कवर नहीं करता, तो container image pulls विफल हो जाते हैं।secure-gateway,secure-gateway.roboflow-edge.svcऔरsecure-gateway.roboflow-edge.svc.cluster.localडिवाइस का hostname
IP addresss
127.0.0.1और डिवाइस IP
अपने स्वयं के certificate का उपयोग करने के लिए, Secret की सामग्री बदलें और गेटवे को पुनः प्रारंभ करें:
अपने certificate को उसकी समाप्ति से 30 दिनों से अधिक पहले नवीनीकृत करें। यदि Secret में मौजूद certificate अपने अंतिम 30 दिनों में प्रवेश कर जाता है, तो Deployment Manager उसे नए सिरे से जनरेट किए गए self-signed certificate से बदल देता है। डिवाइस का IP address या hostname बदलने का भी यही प्रभाव होता है, इसलिए इनमें से किसी को भी बदलने से पहले अपना certificate फिर से जारी करें।
Deployment Manager एक trust bundle भी roboflow-trust-bundle ConfigMap के रूप में प्रकाशित करता है, जिसे गेटवे में mount किया जाता है। गेटवे इसका उपयोग आपके फ़्लीट में अन्य Roboflow-प्रबंधित डिवाइसों द्वारा प्रस्तुत TLS certificates पर भरोसा करने के लिए करता है, ताकि आपको certificates हाथ से वितरित किए बिना डिवाइस गेटवे के साथ प्रमाणित हो सकें।
Inference Servers को कनेक्ट करना
हर उस मशीन पर जो Roboflow Inference Server चलाती है, गेटवे का client install script चलाएँ। यह गेटवे के प्रमाणपत्र को मशीन के trust store में जोड़ता है और उसके Roboflow ट्रैफ़िक (API calls, model weights, और container image pulls) को गेटवे के माध्यम से रूट करता है:
फ़्लैग यहाँ आवश्यक है: मशीन अभी गेटवे के प्रमाणपत्र पर भरोसा नहीं करती, और यही script इंस्टॉल करती है। इसे केवल उस नेटवर्क पथ पर चलाएँ जिसे आप नियंत्रित करते हैं, या script को स्वयं कॉपी करके पहले जाँचें। -k वैकल्पिक रूप से, किसी individual Inference Server को
के साथ गेटवे की ओर इंगित करें SECURE_GATEWAY environment variable; देखें Inference Servers को कनेक्ट करना. स्पष्ट scheme (SECURE_GATEWAY=https://<device-ip>) को versions के बीच उपयोग करें; certificate को उस IP को कवर करना चाहिए। लंबित runtime-hardening build bare-address और plaintext व्यवहार को बदलता है, जैसा कि में वर्णित है Security Configuration Migration. Inference Server को भी गेटवे के certificate पर भरोसा करना होगा, जिसे client install script आपके लिए संभालता है। केवल गेटवे को outbound access की आवश्यकता होती है api.roboflow.com और repo.roboflow.com.
समस्या निवारण
कैश वॉल्यूम अटका हुआ लंबित रहता है
कोई LVM volume group नहीं है, या कोई ऐसा नहीं है जिसमें 60 GB खाली हो। खाली स्थान की जाँच करें sudo vgs; जब किसी volume group में क्षमता आ जाए, तो volume स्वतः bind हो जाता है। छोटे volume पर चलाने के लिए, कम करें storage_size और CACHE_MAX_SIZE_GB को साथ /opt/rfdm/config/rfconfig.json.
गेटवे LoadBalancer Service अटकी हुई <लंबित>
डिवाइस पर पोर्ट 80/443 अभी भी व्यस्त हैं, आमतौर पर क्योंकि डिफ़ॉल्ट router अभी भी सक्षम है। इंस्टॉलर इसे at में एक snippet के माध्यम से सेट करता है /etc/microshift/config.d/10-roboflow-ingress.yaml, न कि /etc/microshift/config.yaml. पुष्टि करें sudo microshift show-config --mode effective रिपोर्ट करता है ingress.status: Removed, तो यदि वह गायब हो तो snippet को पुनर्स्थापित करें, और MicroShift को पुनः प्रारंभ करें; यह भी जाँचें कि कोई अन्य host process 80 या 443 से bound न हो।
firewalld reload के बाद connections विफल हो जाते हैं
firewalld को reload करने से MicroShift pod networking तब तक टूट जाती है जब तक OVN networking pods पुनः शुरू नहीं हो जाते। openshift-ovn-kubernetes नेमस्पेस में pods को हटाएँ ताकि वे फिर से बन जाएँ, या MicroShift को पुनः प्रारंभ करें।
Node बना रहता है NotReady; ovnkube-master pod इसके साथ crash-loop में फँसता है MTU (...) of network interface ... is too small for specified overlay MTU (1500)
आपके network interface का MTU 1500 से कम है (cloud VPCs और VPN links पर सामान्य; GCP 1460 का उपयोग करता है)। pod MTU को interface MTU माइनस 100 पर सेट करें /etc/microshift/ovn.yaml: 1460 interface के लिए, फ़ाइल में एकमात्र पंक्ति होनी चाहिए mtu: 1360. फिर चलाएँ sudo systemctl stop microshift, echo 1 | sudo microshift-cleanup-data --ovnऔर sudo systemctl start microshift. cleanup चरण आवश्यक है क्योंकि पिछला MTU OVN database में संग्रहीत रहता है।
गेटवे pods अटके हुए ImagePullBackOff host image cleanup के बाद
Image pinning सटीक bundled references की रक्षा करता है, लेकिन podman rmi या podman image prune होस्ट पर अभी भी उसी storage CRI-O द्वारा उपयोग किए जाने वाले sibling images और shared layers को हटा सकता है। डिवाइस पर container storage को prune करने से बचें; यदि images गायब हैं, तो उन्हें फिर से लोड करने के लिए installer पुनः चलाएँ।
गेटवे लॉग्स Init handshake failed ... starting in local-cache-only mode
स्टार्टअप पर गेटवे Roboflow API तक नहीं पहुँच सका (गलत API key, outbound connectivity नहीं, या कैश अभी भी शुरू हो रहा था)। यह ट्रैफ़िक सेवा देता रहता है और स्थानीय रूप से कैश भी करता है, लेकिन अपने S3-समर्थित कैश के बिना चलता है और अगली restart तक backend को telemetry या events रिपोर्ट नहीं कर सकता। कारण ठीक करें, फिर चलाएँ sudo oc rollout restart deployment/secure-gateway -n roboflow-edge --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
लॉग्स कहाँ हैं
Deployment Manager: sudo journalctl -u rfdm. Gateway और cache: sudo oc logs deployment/secure-gateway -n roboflow-edge (और deployment/seaweedfs), के साथ --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
समर्थन मैट्रिक्स
4.19
9.6
4.20 (EUS)
9.6
अनुशंसित
4.21
9.6
RHEL 10 पर MicroShift 4.21 Red Hat Technology Preview है और Secure Gateway के लिए समर्थित नहीं है।
MicroShift 4.16 न्यूनतम समर्थित संस्करण है। सम-संख्या वाले MicroShift रिलीज़ Extended Update Support (EUS) के साथ आते हैं, इसलिए लंबी अवधि वाले edge deployments के लिए 4.20 सबसे अच्छा विकल्प है।
अंतिम अपडेट
क्या यह उपयोगी था?