Kubernetes YAML सत्यापनकर्ता
kubectl apply करने से पहले एक या कई Kubernetes मैनिफेस्ट (--- से अलग किए हुए) पेस्ट करें और असली स्कीमा के विरुद्ध जांचें।
यहाँ .yaml/.yml फ़ाइल ड्रॉप करें, या ऊपर मैनिफेस्ट टेक्स्ट पेस्ट करें।
"---" से अलग किए गए कई मैनिफेस्ट अलग-अलग दस्तावेज़ों के रूप में जांचे जाते हैं।
एडवांस्ड विकल्प
पार्सिंग और सत्यापन आपके ब्राउज़र में ही होते हैं — सार्वजनिक CDN से केवल रिसोर्स स्कीमा लाया जाता है, आपका मैनिफेस्ट कभी नहीं।
ऊपर Kubernetes मैनिफ़ेस्ट पेस्ट करें (या नमूना लोड करें), जाँच के नतीजे यहाँ दिखाई देंगे।
kubectl से पहले Kubernetes मैनिफ़ेस्ट की गलतियाँ पकड़ना
अक्सर `kubectl apply` के अस्वीकार होने पर ही पहली बार पता चलता है कि Kubernetes मैनिफ़ेस्ट में कोई गलती है — और तब तक आप डिप्लॉय के बीच में होते हैं, ऐसे एरर संदेश को घूरते हुए जिसमें JSON Schema वैलिडेशन पाथ (`spec.template.spec.containers[0].image: Required value`) लिखा होता है और जो उस YAML फ़ाइल से सीधे जुड़ता नहीं दिखता जिसे आप अभी एडिट कर रहे थे। उसी तरह की गलती पहले ही, सही पंक्ति हाइलाइट होकर पकड़ ली जाए, तो वह संदर्भ बदलने के बजाय पाँच सेकंड का सुधार बन जाती है।
YAML के सिंटैक्स में कुछ तीखे किनारे हैं जो ज़्यादातर दूसरे कॉन्फ़िग फ़ॉर्मैट में नहीं दिखते: इंडेंटेशन मायने रखता है और टैब/स्पेस का बेमेल मेल कुछ मामलों में एरर देने के बजाय चुपचाप अलग (गलत) ढाँचा बना देता है, लंबी कई-रिसोर्स वाली फ़ाइल में `---` दस्तावेज़ सेपरेटर का हिसाब रखना आसान नहीं है, और नेस्टिंग का एक फ़ालतू स्तर YAML के रूप में सही पढ़ा जाता है जबकि Kubernetes के लिए उसका मतलब बिल्कुल अलग होता है। यह टूल उसी तरह की लाइब्रेरी से पार्स करता है जो पार्सिंग भर सोर्स की जगह की पूरी जानकारी रखती है, इसलिए सिंटैक्स की समस्या उसी असली पंक्ति पर बताई जाती है जहाँ वह है, न कि सिर्फ़ "इस 200 पंक्तियों की फ़ाइल में कहीं"।
पुराने (deprecated) apiVersion एक धीमा जाल हैं: `extensions/v1beta1` Deployment, `apps/v1beta1`/`apps/v1beta2` StatefulSet और DaemonSet, और `networking.k8s.io/v1beta1` Ingress, ये सब आज भी बिल्कुल सही YAML की तरह पार्स होते हैं और पुराने क्लस्टर पर चलते भी थे — जब तक क्लस्टर को उस वर्शन से आगे अपग्रेड न कर दिया जाए जहाँ Kubernetes पुराने API ग्रुप को पूरी तरह हटा देता है, और तब उसे इस्तेमाल करने वाला हर मैनिफ़ेस्ट बिना पहले से किसी चेतावनी के अप्लाई होना बंद कर देता है। एडिट करते समय ही इन्हें पकड़ लेना (सही बदले हुए apiVersion के सुझाव के साथ) क्लस्टर अपग्रेड के दौरान पता चलने से बचाता है।
असली Kubernetes OpenAPI स्पेक के ख़िलाफ़ स्कीमा वैलिडेशन बाक़ी चीज़ें पकड़ता है: `replicas` फ़ील्ड जो संख्या के बजाय कोट वाली स्ट्रिंग बन गया, वैध सीमा से बाहर का `containerPort`, या Deployment का `spec.selector` जैसा ज़रूरी फ़ील्ड जो मैनिफ़ेस्ट के बीच कॉपी-पेस्ट करते समय मिट गया। इनमें से कोई भी YAML सिंटैक्स की गलती नहीं है — फ़ाइल ठीक से पार्स होती है — और ठीक इसीलिए एक अलग स्कीमा जाँच वह पकड़ लेती है जो फ़ाइल को जल्दी से आँखों से पढ़ने पर आम तौर पर छूट जाता है।
अक्सर पूछे जाने वाले सवाल
क्या यह `kubectl apply --dry-run` या `kubeconform` की जगह लेता है?
नहीं। `kubectl apply --dry-run=server` ही वह एकमात्र जाँच है जो आपके असली क्लस्टर के API सर्वर (उसमें इंस्टॉल किसी भी CRD और एडमिशन वेबहुक सहित) के ख़िलाफ़ चलती है, और `kubeconform`/`kubeval` CI पाइपलाइन के लिए बने परिपक्व CLI टूल हैं। यह उसी तरह की चीज़ें जाँचता है — YAML सिंटैक्स, स्कीमा का ढाँचा, पुराने apiVersion — बस ब्राउज़र टैब से, जब आपने अभी `kubectl` कहीं कॉन्फ़िगर नहीं किया हो या किसी और का भेजा मैनिफ़ेस्ट रिव्यू कर रहे हों।
स्कीमा कहाँ से आते हैं?
`yannh/kubernetes-json-schema` से, जो Kubernetes के अपने OpenAPI-आधारित JSON Schema का कम्युनिटी द्वारा संभाला जाने वाला, अपने-आप अपडेट होने वाला मिरर है, और आपके चुने Kubernetes वर्शन के लिए ज़रूरत पड़ने पर किसी सार्वजनिक CDN से लाया जाता है। आपके मैनिफ़ेस्ट का कुछ भी कहीं नहीं भेजा जाता — सिर्फ़ (वर्शन वाली, सार्वजनिक) स्कीमा फ़ाइल डाउनलोड होती है, वही फ़ाइल उस kind/वर्शन को जाँचने वाले हर यूज़र के लिए।
सिर्फ़ 10 रिसोर्स kind ही क्यों?
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob और PersistentVolumeClaim हाथ से लिखे ज़्यादातर मैनिफ़ेस्ट को कवर करते हैं। बाक़ी kind को भी पूरी YAML सिंटैक्स जाँच और पुराने apiVersion की पहचान मिलती है — बस उनका स्कीमा-ढाँचा वैलिडेशन अभी नहीं होता।
क्या मेरा YAML कभी मेरे ब्राउज़र से बाहर जाता है?
नहीं। पार्सिंग और स्कीमा वैलिडेशन दोनों इसी टैब में सादे JavaScript से चलते हैं — इस टूल का एकमात्र नेटवर्क अनुरोध आपके चुने रिसोर्स kind और Kubernetes वर्शन की सार्वजनिक JSON Schema फ़ाइल लाना है, आपके मैनिफ़ेस्ट की सामग्री कभी नहीं।