🔴 🍽️ 🤛🏿 यदि प्रमाणपत्र सड़े हुए हैं और क्लस्टर एक कद्दू में बदल जाता है तो क्या करें? 🗝️ 🧓🏿 🤜🏻

यदि kubectl get pod प्रतिक्रिया में kubectl get pod कमांड मिलता है:

 Unable to connect to the server: x509: certificate has expired or is not yet valid

फिर, सबसे अधिक संभावना है, एक वर्ष बीत चुका है, आपकी कुबेरनेट के प्रमाणपत्र समाप्त हो गए हैं, क्लस्टर घटकों ने उनका उपयोग करना बंद कर दिया है, उनके बीच बातचीत बंद हो गई है और आपका क्लस्टर एक कद्दू में बदल गया है।

क्या करना है और एक क्लस्टर को कैसे पुनर्स्थापित करना है?

सबसे पहले, हमें यह समझने की आवश्यकता है कि अद्यतन किए जाने वाले प्रमाणपत्र कहाँ स्थित हैं।

क्लस्टर स्थापित करने के तरीके के आधार पर, प्रमाण पत्र फ़ाइलों का स्थान और नाम भिन्न हो सकता है। इसलिए, उदाहरण के लिए, एक क्लस्टर बनाते समय, कुबेदम सर्वोत्तम प्रथाओं के अनुसार प्रमाण पत्र फ़ाइलों को विघटित करता है । इस प्रकार, सभी प्रमाणपत्र /etc/kuberenetes/pki , /etc/kuberenetes/pki में एक्सटेंशन .crt , निजी कुंजियों वाली फ़ाइलों में क्रमशः .key फ़ाइलों में स्थित होते हैं। प्लस /etc/kubernetes/ in /etc/kubernetes/ are /etc/kubernetes/ फ़ाइलें उपयोगकर्ता कॉन्फ़िगरेशन व्यवस्थापक, प्रबंधक नियंत्रक, शेड्यूलर और मास्टर नोड से क्यूबलेट के लिए एक्सेस कॉन्फ़िगरेशन के साथ। .Conf फ़ाइलों में प्रमाण पत्र बेस-एनकोडेड रूप में user.client-certificate-data फ़ील्ड में निहित होते हैं।

आप इसे जारी करने की तिथि को देख सकते हैं कि यह किसके द्वारा जारी किया गया था और किसके द्वारा प्रमाण पत्र पर हस्ताक्षर किए गए थे

shcert

 #!/bin/bash [ -f "$1" ] || exit if [[ $1 =~ \.(crt|pem)$ ]]; then openssl x509 -in "$1" -text -noout fi if [[ $1 =~ \.conf$ ]]; then certfile=$(mktemp) grep 'client-certificate-data:' "$1"| awk '{ print $2}' | base64 -d > "$certfile" openssl x509 -in "$certfile" -text -noout rm -f "$certfile" fi

अभी भी प्रमाणपत्र हैं जो एपीआई में प्रमाणीकरण के लिए काम नोड्स पर क्यूबलेट का उपयोग करते हैं। यदि आपने क्लस्टर में नोड्स जोड़ने के लिए kubeadm ज्वाइन किया है, तो सबसे अधिक संभावना है कि TLS बूटस्ट्रैपिंग प्रक्रिया का उपयोग करके नोड को कनेक्ट किया गया था, इस स्थिति में क्यूबलेट अपने प्रमाणपत्र को स्वतः नवीनीकृत कर सकता है - यदि इसे --rotate-certificates विकल्प दिया गया हो। कुबेरनेट के हाल के संस्करणों में, यह विकल्प पहले से ही डिफ़ॉल्ट रूप से सक्षम है।
यह जांचना कि नोड टीएलएस बूटस्ट्रैप प्रक्रिया का उपयोग करके जुड़ा हुआ है, काफी सरल है - इस मामले में, / /etc/kubernetes/kubelet.conf -client- /var/lib/kubelet/pki/kubelet-client-current.pem - /etc/kubernetes/kubelet.conf फ़ाइल आमतौर पर /etc/kubernetes/kubelet.conf फ़ाइल में क्लाइंट-प्रमाणपत्र फ़ील्ड में निर्दिष्ट होती है। जो वर्तमान प्रमाण पत्र के लिए एक सहानुभूति है।

आप shcert स्क्रिप्ट का उपयोग करके इस प्रमाणपत्र की समाप्ति तिथियां भी देख सकते हैं shcert

हम प्रमाणपत्रों को नवीनीकृत करने की समस्या पर लौटते हैं।

यदि आपने kubeadm का उपयोग करके क्लस्टर स्थापित किया है, तो मेरे पास आपके लिए अच्छी खबर है। संस्करण 1.15 के साथ शुरू, kubeadm एक कमांड के साथ लगभग सभी नियंत्रण विमान प्रमाण पत्र को अपडेट कर सकता है

 kubeadm alpha certs renew all

यह आदेश / etc / kubernetes निर्देशिका में सभी प्रमाणपत्रों को नवीनीकृत करेगा, भले ही वे पहले ही समाप्त हो चुके हों और सब कुछ टूट गया हो।

केवल क्यूबलेट प्रमाणपत्र को अपडेट नहीं किया जाएगा - यह वह है जो /etc/kubernetes/kubelet.conf फ़ाइल में निहित है!

अद्यतन: kubeadm, संस्करण 1.17 से शुरू होता है, जिसमें सभी नोड्स (यहां तक कि पहले विज़ार्ड पर जहां kubeadm init किया गया था) culet प्रमाणपत्र का स्वत: नवीनीकरण शामिल है। चेकिंग बहुत सरल है - /etc/kubernetes/kubelet.conf में फ़ाइल /etc/kubernetes/kubelet.conf रास्ता / /var/lib/kubelet/pki/kubelet-client-current.pem क्लाइंट सर्टिफिकेट फील्ड में दर्शाया जाएगा।

इस प्रमाणपत्र को नवीनीकृत करने के लिए, उपयोगकर्ता खाता बनाएँ कमांड का उपयोग करें

 kubeadm alpha kubeconfig user --client-name system:node:kube.slurm.io --org system:nodes > /etc/kubernetes/kubelet.conf

यदि सिस्टम में उपयोगकर्ता खाता है, तो यह कमांड इस खाते के लिए प्रमाणपत्र को अपडेट करता है। --client-name विकल्प में सही होस्ट नाम निर्दिष्ट करने के लिए मत भूलना, आप मौजूदा प्रमाणपत्र के विषय क्षेत्र में होस्ट नाम को देख सकते हैं:

 shcert /etc/kubernetes/kubelet.conf

और हां, प्रमाण पत्र को अपडेट करने के बाद, आपको नियंत्रण विमान के सभी घटकों को फिर से शुरू करने की आवश्यकता है, पूरे नोड को रिबूट करना या कंटेनर, आदि, एपीआई, नियंत्रक-प्रबंधक और अनुसूचक को डॉक docker stop साथ docker stop और फिर क्यूबिक सिस्टेक्टल systemctl restart kubelet ।

यदि आपके क्लस्टर का पुराना संस्करण है: 1.13 या उससे कम, तो यह आसानी से 1.15 पर kubeadm को अपग्रेड करने के लिए काम नहीं करेगा, क्योंकि यह क्यूबलेट और कुबेरनेट्स-सीनी निर्भरता के साथ खींचता है, जिससे समस्याएं हो सकती हैं, क्योंकि क्लस्टर घटकों के प्रदर्शन एक से अधिक संस्करणों में भिन्न होते हैं। मंच, गारंटी नहीं। इस स्थिति से सबसे आसान तरीका किसी अन्य मशीन पर कुबेदम स्थापित करना है, द्विआधारी फ़ाइल /usr/bin/kubeadm , इसे मृतक समूह के मास्टर नोड्स में कॉपी करना और केवल प्रमाणपत्रों को नवीनीकृत करने के लिए इसका उपयोग करना है। और क्लस्टर को पुनर्जीवित करने के बाद, इसे नियमित तरीकों का उपयोग करके चरण दर चरण अपडेट करें, हर बार कुबेडम के एक संस्करण को नए सिरे से स्थापित करें।

और अंत में, संस्करण 1.15 से kubeadm ने सीखा कि कैसे kubeadm upgrade कमांड के साथ क्लस्टर को अपडेट करते समय सभी-सभी प्रमाणपत्रों को नवीनीकृत करना है। इसलिए यदि आप नियमित रूप से वर्ष में कम से कम एक बार अपने क्लस्टर को अपडेट करते हैं, तो आपके प्रमाणपत्र हमेशा मान्य होंगे।

लेकिन अगर क्लस्टर को कुबेदम का उपयोग करके स्थापित नहीं किया गया है, तो आपको ओपनसीएल को चुनना होगा और सभी प्रमाणपत्रों को व्यक्तिगत रूप से नवीनीकृत करना होगा।

समस्या यह है कि प्रमाणपत्र में विस्तारित फ़ील्ड होते हैं, और विभिन्न क्लस्टर इंस्टॉलेशन टूल फ़ील्ड के अपने सेट को जोड़ सकते हैं। इसके अलावा, खुलता कॉन्फ़िगरेशन और प्रमाणपत्र सामग्री के आउटपुट में इन क्षेत्रों के नाम सहसंबद्ध हैं, लेकिन कमजोर रूप से। यह आवश्यक है कि Google और चयन करें।

मैं ओपनसेल के लिए एक उदाहरण विन्यास दूंगा, जिसमें अलग-अलग वर्गों का वर्णन किया गया है, जो प्रत्येक प्रकार के प्रमाणपत्र के लिए विशिष्ट हैं। सीएसआर बनाते और हस्ताक्षर करते समय हम संबंधित अनुभाग का उल्लेख करेंगे। इस कॉन्फ़िगरेशन का उपयोग रैंचर द्वारा एक साल पहले स्थापित क्लस्टर को पुनर्जीवित करने के लिए किया गया था।

openssl.cnf

 [req] distinguished_name = req_distinguished_name req_extensions = v3_req [v3_req] keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [client] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [apiproxyclient] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth [etcd] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [api] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = ec2-us-east-1-1a-c1-master-2 DNS.2 = ec2-us-east-1-1a-c1-master-3 DNS.3 = ec2-us-east-1-1a-c1-master-1 DNS.4 = localhost DNS.5 = kubernetes DNS.6 = kubernetes.default DNS.7 = kubernetes.default.svc DNS.8 = kubernetes.default.svc.cluster.local IP.1 = 10.0.0.109 IP.2 = 10.0.0.159 IP.3 = 10.0.0.236 IP.4 = 127.0.0.1 IP.5 = 10.43.0.1

प्रमाणपत्र में वास्तविक विशेषताओं और अतिरिक्त नामों को कमांड का उपयोग करके देखा जा सकता है

 openssl x509 -in cert.crt -text

सर्वर API के लिए प्रमाणपत्र को नवीनीकृत करते समय, मुझे एक समस्या थी: अद्यतन प्रमाण पत्र काम नहीं करता था। इसका समाधान एक प्रमाण पत्र जारी करना था जो कि अतीत में 1 वर्ष के लिए वैध था।

ओपनसेल में, आप एक साधारण कमांड के साथ अतीत में मान्य प्रमाण पत्र जारी नहीं कर सकते हैं, कोड सख्ती से कहता है कि प्रमाण पत्र केवल वर्तमान क्षण से मान्य है। लेकिन आप स्थानीय स्तर पर libfaketime लाइब्रेरी का उपयोग करके वापस जा सकते हैं

 yum install libfaketime LD_PRELOAD=/usr/lib64/faketime/libfaketime.so.1 FAKETIME="-365d" openssl x509 -req ...

हम निम्नलिखित एल्गोरिथम के अनुसार विस्तारित प्रमाण पत्र जारी करते हैं:

हम एक मौजूदा प्रमाणपत्र का उपयोग करके एक सीएसआर बनाते हैं, कॉन्फ़िगरेशन फ़ाइल में उन्नत विशेषताओं की सूची के साथ वांछित अनुभाग निर्दिष्ट करें:

 openssl x509 -x509toreq -in "node.cert" -out "node.csr" -signkey "node.key" -extfile "openssl.cnf" -extensions client

हम इसे संबंधित रूट प्रमाणपत्र के साथ साइन करते हैं, 1 साल पहले के समय को बदलते हुए और कॉन्फ़िगरेशन फ़ाइल में उन्नत विशेषताओं की सूची के साथ वांछित अनुभाग को निर्दिष्ट करते हैं।

 LD_PRELOAD=/usr/lib64/faketime/libfaketime.so.1 FAKETIME="-365d" openssl x509 -req -days 36500 -in "node.csr" -CA "kube-ca.pem" -CAkey "kube-ca-key.pem" -CAcreateserial -out "node.new.cert" -extfile "openssl.cnf" -extensions client

हम विशेषताओं की जांच करते हैं और नियंत्रण विमान घटकों को पुनरारंभ करते हैं।

सर्गेई बोंदरेव,
स्लम शिक्षक
slurm.io

यदि प्रमाणपत्र सड़े हुए हैं और क्लस्टर एक कद्दू में बदल जाता है तो क्या करें?

More articles: