10 सामान्य कुबेरनेट्स गलतियाँ

टिप्पणी। अनुवाद।: इस लेख के लेखक एक छोटी चेक कंपनी पिपेटेल के इंजीनियर हैं। वे कुबेरनेट्स समूहों के संचालन से संबंधित [कभी-कभी सामान्य, लेकिन फिर भी] बहुत गंभीर समस्याओं और गलत धारणाओं की एक अद्भुत सूची तैयार करने में कामयाब रहे।

कुबेरनेट्स का उपयोग करने के वर्षों में, हमने बड़ी संख्या में क्लस्टर (प्रबंधित और अप्रबंधित दोनों - GCP, AWS और Azure पर) के साथ काम किया है। समय के साथ, हमने नोटिस करना शुरू कर दिया कि कुछ गलतियाँ लगातार दोहराई जा रही थीं। हालाँकि, इसमें कोई शर्म की बात नहीं है: हमने उनमें से अधिकांश स्वयं ही किया है!

लेख में सबसे आम त्रुटियां हैं और उन्हें ठीक करने का तरीका भी बताया गया है।

1. संसाधन: अनुरोध और सीमाएँ

यह आइटम निश्चित रूप से सबसे अधिक ध्यान देने योग्य और सूची में पहला स्थान पाने का हकदार है।

सीपीयू अनुरोध आमतौर पर या तो बिल्कुल निर्दिष्ट नहीं है या उसका मूल्य बहुत कम है (प्रत्येक नोड पर यथासंभव अधिक पॉड्स लगाने के लिए)। इस प्रकार, नोड्स अतिभारित हो जाते हैं। उच्च भार के समय, नोड की प्रसंस्करण शक्ति का पूरी तरह से उपयोग किया जाता है और एक विशेष कार्यभार को केवल वही प्राप्त होता है जो इसके द्वारा "अनुरोध" किया जाता है। CPU थ्रॉटलिंग. इससे एप्लिकेशन विलंबता, टाइमआउट और अन्य अप्रिय परिणाम बढ़ जाते हैं। (इसके बारे में हमारे अन्य हालिया अनुवाद में और पढ़ें: "कुबेरनेट्स में सीपीयू सीमा और आक्रामक थ्रॉटलिंग"- लगभग। अनुवाद।)

सर्वश्रेष्ठ प्रयास (अत्यंत नहीं अनुशंसित):

resources: {}

अत्यंत कम CPU अनुरोध (अत्यंत नहीं अनुशंसित):

   resources:
      Requests:
        cpu: "1m"

दूसरी ओर, सीपीयू सीमा की उपस्थिति से पॉड्स द्वारा घड़ी चक्रों को अनुचित रूप से छोड़ दिया जा सकता है, भले ही नोड प्रोसेसर पूरी तरह से लोड न हो। फिर, इससे देरी बढ़ सकती है। पैरामीटर को लेकर विवाद जारी है सीपीयू सीएफएस कोटा लिनक्स कर्नेल और सीपीयू में निर्धारित सीमाओं के आधार पर थ्रॉटलिंग, साथ ही सीएफएस कोटा को अक्षम करना... अफसोस, सीपीयू सीमाएँ जितनी समस्याएँ हल कर सकती हैं, उससे कहीं अधिक समस्याएँ पैदा कर सकती हैं। इसके बारे में अधिक जानकारी नीचे दिए गए लिंक पर पाई जा सकती है।

अत्यधिक चयन (अति प्रतिबद्धता) स्मृति समस्याएं बड़ी समस्याओं का कारण बन सकती हैं। सीपीयू सीमा तक पहुंचने में घड़ी चक्र को छोड़ना शामिल है, जबकि मेमोरी सीमा तक पहुंचने पर पॉड को खत्म करना शामिल है। क्या आपने कभी गौर किया है OOMकिल? हाँ, हम बिल्कुल इसी बारे में बात कर रहे हैं।

क्या आप ऐसा होने की संभावना को कम करना चाहते हैं? मेमोरी को अधिक आवंटित न करें और मेमोरी अनुरोध को सीमा पर सेट करके गारंटीकृत क्यूओएस (सेवा की गुणवत्ता) का उपयोग करें (जैसा कि नीचे दिए गए उदाहरण में है)। इसके बारे में और पढ़ें हेनिंग जैकब्स प्रस्तुतियाँ (ज़ालैंडो में लीड इंजीनियर)।

फटने योग्य (ओओएमकिल्ड होने की अधिक संभावना):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

गारंटीकृत:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

संसाधन स्थापित करते समय संभावित रूप से क्या मदद मिलेगी?

साथ मेट्रिक्स सर्वर आप पॉड्स (और उनके अंदर के कंटेनर) द्वारा वर्तमान सीपीयू संसाधन खपत और मेमोरी उपयोग देख सकते हैं। सबसे अधिक संभावना है, आप पहले से ही इसका उपयोग कर रहे हैं। बस निम्नलिखित आदेश चलाएँ:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

हालाँकि, वे केवल वर्तमान उपयोग दिखाते हैं। यह आपको परिमाण के क्रम का एक मोटा अंदाज़ा दे सकता है, लेकिन अंततः आपको इसकी आवश्यकता होगी समय के साथ मेट्रिक्स में परिवर्तन का इतिहास (जैसे सवालों के जवाब देने के लिए: "पीक सीपीयू लोड क्या था?", "कल सुबह लोड क्या था?", आदि)। इसके लिए आप उपयोग कर सकते हैं प्रोमिथेउस, DataDog और अन्य उपकरण. वे बस मेट्रिक्स-सर्वर से मेट्रिक्स प्राप्त करते हैं और उन्हें संग्रहीत करते हैं, और उपयोगकर्ता उनसे क्वेरी कर सकता है और तदनुसार उन्हें प्लॉट कर सकता है।

वर्टिकलपॉडऑटोस्केलर यह अनुमति देता है स्वचालित करने के लिए यह प्रोसेस। यह सीपीयू और मेमोरी उपयोग इतिहास को ट्रैक करता है और इस जानकारी के आधार पर नए अनुरोध और सीमाएं निर्धारित करता है।

कंप्यूटिंग शक्ति का कुशलतापूर्वक उपयोग करना कोई आसान काम नहीं है। यह हर समय टेट्रिस खेलने जैसा है। यदि आप कम औसत खपत (जैसे ~10%) के साथ गणना शक्ति के लिए बहुत अधिक भुगतान कर रहे हैं, तो हम AWS फार्गेट या वर्चुअल क्यूबलेट पर आधारित उत्पादों को देखने की सलाह देते हैं। वे सर्वर रहित/भुगतान-प्रति-उपयोग बिलिंग मॉडल पर बनाए गए हैं, जो ऐसी स्थितियों में सस्ता हो सकता है।

2. जीवंतता और तत्परता जांच

डिफ़ॉल्ट रूप से, कुबेरनेट्स में जीवंतता और तत्परता जांच सक्षम नहीं हैं। और कभी-कभी वे उन्हें चालू करना भूल जाते हैं...

लेकिन किसी घातक त्रुटि की स्थिति में आप सेवा पुनः आरंभ कैसे कर सकते हैं? और लोड बैलेंसर को कैसे पता चलता है कि एक पॉड ट्रैफ़िक स्वीकार करने के लिए तैयार है? या यह कि यह अधिक ट्रैफ़िक संभाल सकता है?

ये परीक्षण अक्सर एक-दूसरे से भ्रमित होते हैं:

• जीवंतता - "उत्तरजीविता" जांच, जो विफल होने पर पॉड को पुनरारंभ करता है;
• तत्परता - तत्परता की जांच करें, यदि यह विफल रहता है, तो यह कुबेरनेट्स सेवा से पॉड को डिस्कनेक्ट कर देता है (इसे इसका उपयोग करके जांचा जा सकता है) kubectl get endpoints) और जब तक अगला चेक सफलतापूर्वक पूरा नहीं हो जाता, तब तक उस पर ट्रैफ़िक नहीं आता।

ये दोनों जांचें पॉड के पूरे जीवन चक्र के दौरान प्रदर्शन किया गया. बहुत जरुरी है।

एक आम ग़लतफ़हमी यह है कि तत्परता जांच केवल स्टार्टअप पर ही चलाई जाती है ताकि बैलेंसर को पता चल सके कि पॉड तैयार है (Ready) और ट्रैफ़िक संसाधित करना शुरू कर सकता है। हालाँकि, यह उनके उपयोग के विकल्पों में से केवल एक है।

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

इसलिए, कुछ मामलों में, गलत तरीके से कॉन्फ़िगर किए गए मापदंडों के साथ उन्हें सक्षम करने से बेहतर कोई जांच नहीं है। जैसा कि ऊपर कहा गया है, यदि सजीवता जाँच प्रतियाँ तत्परता जाँच, तो आप बड़ी मुसीबत में हैं। संभावित विकल्प कॉन्फ़िगर करना है केवल तत्परता परीक्षणऔर खतरनाक सजीवता एक तरफ छोड़ दो।

सामान्य निर्भरता विफल होने पर दोनों प्रकार की जाँच विफल नहीं होनी चाहिए, अन्यथा इससे सभी पॉड्स की कैस्केडिंग (हिमस्खलन जैसी) विफलता हो जाएगी। दूसरे शब्दों में, अपने आप को नुकसान मत पहुँचाओ.

3. प्रत्येक HTTP सेवा के लिए लोडबैलेंसर

सबसे अधिक संभावना है, आपके क्लस्टर में HTTP सेवाएँ हैं जिन्हें आप बाहरी दुनिया में अग्रेषित करना चाहेंगे।

यदि आप सेवा को इस रूप में खोलते हैं type: LoadBalancer, इसका नियंत्रक (सेवा प्रदाता पर निर्भर करता है) एक बाहरी लोडबैलेंसर प्रदान करेगा और बातचीत करेगा (जरूरी नहीं कि L7 पर चल रहा हो, बल्कि L4 पर भी चल रहा हो), और यह लागत (बाहरी स्थैतिक IPv4 पता, कंप्यूटिंग शक्ति, प्रति सेकंड बिलिंग) को प्रभावित कर सकता है ) बड़ी संख्या में ऐसे संसाधन बनाने की आवश्यकता के कारण।

इस मामले में, सेवाओं को खोलते हुए एक बाहरी लोड बैलेंसर का उपयोग करना अधिक तर्कसंगत है type: NodePort. या इससे भी बेहतर, कुछ इस तरह का विस्तार करें nginx-प्रवेश-नियंत्रक (या ट्रैफ़िक), जो केवल एक ही होगा नोडपोर्ट एंडपॉइंट बाहरी लोड बैलेंसर से जुड़ा है और इसका उपयोग करके क्लस्टर में ट्रैफ़िक को रूट करेगा प्रवेश-कुबेरनेट्स संसाधन।

अन्य इंट्रा-क्लस्टर (सूक्ष्म) सेवाएँ जो एक-दूसरे के साथ बातचीत करती हैं, जैसी सेवाओं का उपयोग करके "संचार" कर सकती हैं क्लस्टरआईपी और DNS के माध्यम से एक अंतर्निहित सेवा खोज तंत्र। बस उनके सार्वजनिक DNS/IP का उपयोग न करें, क्योंकि इससे विलंबता प्रभावित हो सकती है और क्लाउड सेवाओं की लागत बढ़ सकती है।

4. किसी क्लस्टर की विशेषताओं को ध्यान में रखे बिना उसे ऑटोस्केल करना

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

कल्पना कीजिए कि एक निश्चित पॉड को शेड्यूल किया जाना चाहिए, लेकिन सभी उपलब्ध सीपीयू पावर का अनुरोध/विघटन किया जाता है और पॉड एक स्थिति में फंस जाता है Pending. बाहरी ऑटोस्केलर औसत वर्तमान सीपीयू लोड देखता है (अनुरोधित नहीं) और विस्तार शुरू नहीं करता है (बाहर निकालना) - दूसरा नोड नहीं जोड़ता. परिणामस्वरूप, यह पॉड शेड्यूल नहीं किया जाएगा.

इस मामले में, रिवर्स स्केलिंग (स्केल-इन) - किसी क्लस्टर से नोड को हटाना हमेशा कार्यान्वित करना अधिक कठिन होता है। कल्पना कीजिए कि आपके पास एक स्टेटफुल पॉड है (जिसमें लगातार स्टोरेज जुड़ा हुआ है)। लगातार वॉल्यूम आमतौर से संबंधित हैं विशिष्ट उपलब्धता क्षेत्र और क्षेत्र में दोहराया नहीं गया है। इस प्रकार, यदि कोई बाहरी ऑटोस्केलर इस पॉड के साथ एक नोड को हटा देता है, तो शेड्यूलर इस पॉड को किसी अन्य नोड पर शेड्यूल नहीं कर पाएगा, क्योंकि यह केवल उपलब्धता क्षेत्र में ही किया जा सकता है जहां लगातार स्टोरेज स्थित है। पॉड राज्य में अटका रहेगा Pending.

कुबेरनेट्स समुदाय में बहुत लोकप्रिय है क्लस्टर-ऑटोस्केलर. यह एक क्लस्टर पर चलता है, प्रमुख क्लाउड प्रदाताओं से एपीआई का समर्थन करता है, सभी प्रतिबंधों को ध्यान में रखता है और उपरोक्त मामलों में स्केल कर सकता है। यह सभी निर्धारित सीमाओं को बनाए रखते हुए स्केल-इन करने में भी सक्षम है, जिससे पैसे की बचत होती है (जो अन्यथा अप्रयुक्त क्षमता पर खर्च किया जाएगा)।

5. IAM/RBAC क्षमताओं की उपेक्षा करना

लगातार रहस्यों के साथ IAM उपयोगकर्ताओं का उपयोग करने से सावधान रहें मशीनें और अनुप्रयोग. भूमिकाओं और सेवा खातों का उपयोग करके अस्थायी पहुंच व्यवस्थित करें (सेवा खाते).

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

Kube2iam के बारे में भूल जाएं और सेवा खातों के लिए सीधे IAM भूमिकाओं पर जाएं (जैसा कि इसमें बताया गया है)। एक ही नाम का नोट स्टेपान व्रानी):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

एक टिप्पणी. उतना कठिन नहीं है, है ना?

इसके अलावा, सेवा खाते और इंस्टेंस प्रोफ़ाइल विशेषाधिकार न दें admin и cluster-adminअगर उन्हें इसकी आवश्यकता नहीं है. इसे लागू करना थोड़ा अधिक कठिन है, विशेषकर आरबीएसी K8s में, लेकिन निश्चित रूप से प्रयास के लायक है।

6. पॉड्स के लिए स्वचालित एंटी-एफ़िनिटी पर भरोसा न करें

कल्पना करें कि आपके पास एक नोड पर कुछ परिनियोजन की तीन प्रतिकृतियां हैं। नोड गिर जाता है, और इसके साथ ही सभी प्रतिकृतियां भी गिर जाती हैं। अप्रिय स्थिति, है ना? लेकिन सभी प्रतिकृतियाँ एक ही नोड पर क्यों थीं? क्या कुबेरनेट्स को उच्च उपलब्धता (एचए) प्रदान नहीं करना चाहिए?!

दुर्भाग्य से, कुबेरनेट्स शेड्यूलर, अपनी पहल पर, अलग अस्तित्व के नियमों का पालन नहीं करता है (विरोधी आत्मीयता) फली के लिए. उन्हें स्पष्ट रूप से कहा जाना चाहिए:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

बस इतना ही। अब पॉड्स को अलग-अलग नोड्स पर शेड्यूल किया जाएगा (यह स्थिति केवल शेड्यूलिंग के दौरान जांची जाती है, लेकिन उनके ऑपरेशन के दौरान नहीं - इसलिए requiredDuringSchedulingIgnoredDuringExecution).

यहां हम बात कर रहे हैं podAntiAffinity विभिन्न नोड्स पर: topologyKey: "kubernetes.io/hostname", - और विभिन्न उपलब्धता क्षेत्रों के बारे में नहीं। पूर्ण-विकसित एचए को लागू करने के लिए, आपको इस विषय पर गहराई से विचार करना होगा।

7. पॉडडिसरप्शनबजट को नजरअंदाज करना

कल्पना करें कि आपके पास कुबेरनेट्स क्लस्टर पर उत्पादन भार है। समय-समय पर, नोड्स और क्लस्टर को स्वयं अद्यतन (या डीकमीशन) करना पड़ता है। पॉडडिस्रप्शनबजट (पीडीबी) क्लस्टर प्रशासकों और उपयोगकर्ताओं के बीच एक सेवा गारंटी समझौते की तरह है।

पीडीबी आपको नोड्स की कमी के कारण होने वाली सेवा रुकावटों से बचने की अनुमति देता है:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

इस उदाहरण में, आप, क्लस्टर के एक उपयोगकर्ता के रूप में, व्यवस्थापकों से कहते हैं: "अरे, मेरे पास एक ज़ूकीपर सेवा है, और इससे कोई फर्क नहीं पड़ता कि आप क्या करते हैं, मैं चाहूंगा कि इस सेवा की कम से कम 2 प्रतिकृतियां हमेशा उपलब्ध रहें।"

आप इसके बारे में और अधिक पढ़ सकते हैं यहां.

8. एक सामान्य क्लस्टर में एकाधिक उपयोगकर्ता या वातावरण

कुबेरनेट्स नामस्थान (नामस्थान) मजबूत इन्सुलेशन प्रदान न करें.

एक आम ग़लतफ़हमी यह है कि यदि आप एक गैर-उत्पाद लोड को एक नेमस्पेस में और एक उत्पाद लोड को दूसरे में तैनात करते हैं, तो वे किसी भी प्रकार से एक दूसरे को प्रभावित नहीं करेंगे... हालाँकि, संसाधन अनुरोधों/सीमाओं का उपयोग करके, कोटा निर्धारित करके और प्राथमिकता क्लास सेट करके अलगाव का एक निश्चित स्तर प्राप्त किया जा सकता है। डेटा प्लेन में कुछ "भौतिक" अलगाव समानताएं, सहिष्णुता, दाग (या नोडसेलेक्टर्स) द्वारा प्रदान किया जाता है, लेकिन ऐसा अलगाव काफी है कठिन अमल में लाना।

जिन लोगों को दोनों प्रकार के कार्यभार को एक ही क्लस्टर में संयोजित करने की आवश्यकता है, उन्हें जटिलता से निपटना होगा। यदि ऐसी कोई आवश्यकता नहीं है, और आप इसे खरीद सकते हैं एक और क्लस्टर (कहें, सार्वजनिक क्लाउड में), तो ऐसा करना बेहतर है। इससे बहुत अधिक उच्च स्तर का इन्सुलेशन प्राप्त होगा।

9. बाहरी यातायात नीति: क्लस्टर

अक्सर हम देखते हैं कि क्लस्टर के अंदर का सारा ट्रैफ़िक NodePort जैसी सेवा के माध्यम से आता है, जिसके लिए डिफ़ॉल्ट नीति निर्धारित है externalTrafficPolicy: Cluster. इसका मतलब यह है कि नोडपोर्ट क्लस्टर में प्रत्येक नोड पर खुला है, और आप वांछित सेवा (पॉड्स का सेट) के साथ बातचीत करने के लिए उनमें से किसी का भी उपयोग कर सकते हैं।

साथ ही, उपर्युक्त नोडपोर्ट सेवा से जुड़े वास्तविक पॉड आमतौर पर केवल एक निश्चित पर ही उपलब्ध होते हैं इन नोड्स का सबसेट. दूसरे शब्दों में, यदि मैं किसी ऐसे नोड से जुड़ता हूं जिसमें आवश्यक पॉड नहीं है, तो यह ट्रैफ़िक को दूसरे नोड पर अग्रेषित कर देगा, एक हॉप जोड़ना और बढ़ती विलंबता (यदि नोड्स विभिन्न उपलब्धता क्षेत्रों/डेटा केंद्रों में स्थित हैं, तो विलंबता काफी अधिक हो सकती है; इसके अलावा, निकास यातायात लागत में वृद्धि होगी)।

दूसरी ओर, यदि किसी निश्चित कुबेरनेट्स सेवा में एक नीति निर्धारित है externalTrafficPolicy: Local, तो नोडपोर्ट केवल उन नोड्स पर खुलता है जहां आवश्यक पॉड्स वास्तव में चल रहे हैं। बाहरी लोड बैलेंसर का उपयोग करते समय जो स्थिति की जांच करता है (स्वास्थ्य जांच) समापनबिंदु (यह कैसे करता है AWS ईएलबी), वह केवल आवश्यक नोड्स पर ही ट्रैफ़िक भेजेगा, जिसका देरी, कंप्यूटिंग आवश्यकताओं, निकास बिलों पर लाभकारी प्रभाव पड़ेगा (और सामान्य ज्ञान भी यही निर्देशित करता है)।

इस बात की बहुत अधिक संभावना है कि आप पहले से ही कुछ इस तरह का उपयोग कर रहे हैं ट्रैफ़िक या nginx-प्रवेश-नियंत्रक HTTP प्रवेश ट्रैफ़िक को रूट करने के लिए एक नोडपोर्ट एंडपॉइंट (या लोडबैलेंसर, जो नोडपोर्ट का भी उपयोग करता है) के रूप में, और इस विकल्प को सेट करने से ऐसे अनुरोधों के लिए विलंबता को काफी कम किया जा सकता है।

В यह प्रकाशन आप externalTrafficPolicy, इसके फायदे और नुकसान के बारे में अधिक जान सकते हैं।

10. समूहों से न बंधे रहें और नियंत्रण स्तर का दुरुपयोग न करें

पहले, सर्वर को उचित नामों से कॉल करने की प्रथा थी: एंटोन, HAL9000 और कोलोसस... आज उन्हें बेतरतीब ढंग से उत्पन्न पहचानकर्ताओं द्वारा प्रतिस्थापित कर दिया गया है। हालाँकि, आदत बनी रही, और अब उचित नाम समूहों में जाते हैं।

एक विशिष्ट कहानी (वास्तविक घटनाओं पर आधारित): यह सब अवधारणा के प्रमाण के साथ शुरू हुआ, इसलिए क्लस्टर का गौरवपूर्ण नाम था परीक्षण...वर्ष बीत चुके हैं और इसका उपयोग अभी भी उत्पादन में किया जाता है, और हर कोई इसे छूने से डरता है।

गुच्छों को पालतू जानवरों में बदलने में कोई मज़ा नहीं है, इसलिए हम अभ्यास करते समय समय-समय पर उन्हें हटाने की सलाह देते हैं आपदा बहाली (ये सहायता करेगा अराजकता इंजीनियरिंग - लगभग। अनुवाद।). इसके अलावा, नियंत्रण परत पर काम करने में कोई दिक्कत नहीं होगी (विमान नियंत्रण). उसे छूने से डरना अच्छा संकेत नहीं है. इत्यादि मृत? दोस्तों, आप सचमुच मुसीबत में हैं!

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

इसके अलावा, हम प्रबंधित कुबेरनेट्स प्रदाता के साथ एसएलए/एसएलओ समझौतों की जांच करने और गारंटी पर ध्यान देने की सलाह देते हैं। विक्रेता गारंटी दे सकता है नियंत्रण परत उपलब्धता (या इसके उपघटक), लेकिन आपके द्वारा इसे भेजे गए अनुरोधों में p99 विलंब नहीं। दूसरे शब्दों में, आप प्रवेश कर सकते हैं kubectl get nodes, और केवल 10 मिनट के बाद उत्तर प्राप्त करें, और यह सेवा अनुबंध की शर्तों का उल्लंघन नहीं होगा।

11. बोनस: नवीनतम टैग का उपयोग करना

लेकिन यह पहले से ही एक क्लासिक है. हाल ही में हम इस तकनीक से कम परिचित हुए हैं, क्योंकि कई लोगों ने कड़वे अनुभव से सीखकर टैग का उपयोग करना बंद कर दिया है :latest और संस्करणों को पिन करना शुरू कर दिया। हुर्रे!

ईसीआर छवि टैग की अपरिवर्तनीयता बनाए रखता है; हमारा सुझाव है कि आप इस उल्लेखनीय विशेषता से परिचित हो जाएं।

सारांश

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

आप विभिन्न टीमों के असफल अनुभवों से परिचित हो सकते हैं कहानियों का यह संग्रह हेनिंग जैकब्स द्वारा।

जो लोग इस आलेख में दी गई त्रुटियों की सूची में जोड़ना चाहते हैं वे ट्विटर पर हमसे संपर्क कर सकते हैं (@मरेकबार्टिक, @MstrsObserver).

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «डिजाइनिंग कुबेरनेट क्लस्टर: कितने होने चाहिए?";
• «कुबेरनेट्स में सुरक्षा का एबीसी: प्रमाणीकरण, प्राधिकरण, लेखा परीक्षा";
• «कुबेरनेट्स में ऑटोस्केलिंग और संसाधन प्रबंधन"(समीक्षा और वीडियो रिपोर्ट);
• «कुबेरनेट्स में कॉन्फ़िगमैप्स: जानने लायक बारीकियाँ'.

स्रोत: www.habr.com