Kubernetes वापरताना 10 सामान्य चुका

नोंद. अनुवाद: या लेखाचे लेखक पाइपटेल या छोट्या झेक कंपनीतील अभियंते आहेत. त्यांनी कुबर्नेट्स क्लस्टर्सच्या ऑपरेशनशी संबंधित [कधीकधी सामान्य, परंतु तरीही] अत्यंत गंभीर समस्या आणि गैरसमजांची एक अद्भुत यादी तयार केली.

Kubernetes वापरण्याच्या वर्षानुवर्षे, आम्ही मोठ्या संख्येने क्लस्टर्स (व्यवस्थापित आणि व्यवस्थापित नसलेले - GCP, AWS आणि Azure वर) काम केले आहे. कालांतराने काही चुकांची सतत पुनरावृत्ती होत असल्याचे आमच्या लक्षात येऊ लागले. तथापि, यात कोणतीही लाज नाही: आम्ही त्यापैकी बहुतेक स्वतः केले आहेत!

लेखात सर्वात सामान्य त्रुटी आहेत आणि त्या कशा दुरुस्त करायच्या हे देखील नमूद केले आहे.

1. संसाधने: विनंत्या आणि मर्यादा

हा आयटम निश्चितपणे सर्वात जवळचे लक्ष आणि यादीतील प्रथम स्थानास पात्र आहे.

CPU विनंती सहसा एकतर अजिबात निर्दिष्ट नाही किंवा खूप कमी मूल्य आहे (प्रत्येक नोडवर शक्य तितक्या शेंगा ठेवण्यासाठी). अशा प्रकारे, नोड्स ओव्हरलोड होतात. उच्च भाराच्या काळात, नोडची प्रक्रिया शक्ती पूर्णपणे वापरली जाते आणि विशिष्ट वर्कलोडला फक्त तेच मिळते जे त्याने "विनंती" केली होती. CPU थ्रॉटलिंग. यामुळे ऍप्लिकेशन लेटन्सी, कालबाह्यता आणि इतर अप्रिय परिणाम वाढतात. (आमच्या इतर अलीकडील भाषांतरात याबद्दल अधिक वाचा: “CPU मर्यादा आणि Kubernetes मध्ये आक्रमक थ्रॉटलिंग"- अंदाजे. अनुवाद.)

सर्वोत्तम प्रयत्न (अत्यंत नाही शिफारस केलेले):

resources: {}

अत्यंत कमी CPU विनंती (अत्यंत नाही शिफारस केलेले):

   resources:
      Requests:
        cpu: "1m"

दुसरीकडे, नोड प्रोसेसर पूर्णपणे लोड केलेला नसला तरीही, CPU मर्यादेच्या उपस्थितीमुळे पॉड्सद्वारे घड्याळाची चक्रे अवास्तव वगळली जाऊ शकतात. पुन्हा, यामुळे विलंब वाढू शकतो. पॅरामीटर भोवती वाद सुरू आहे CPU CFS कोटा लिनक्स कर्नल आणि CPU थ्रॉटलिंगमध्ये सेट मर्यादेनुसार, तसेच CFS कोटा अक्षम करणे... अरेरे, CPU मर्यादा सोडवण्यापेक्षा जास्त समस्या निर्माण करू शकतात. याविषयी अधिक माहिती खालील लिंकवर मिळू शकेल.

अत्यधिक निवड (अति वचनबद्ध) स्मृती समस्या मोठ्या समस्या होऊ शकते. CPU मर्यादेपर्यंत पोहोचणे म्हणजे घड्याळाची चक्रे वगळणे आवश्यक आहे, तर मेमरी मर्यादेपर्यंत पोहोचणे पॉड मारणे आवश्यक आहे. तुम्ही कधी निरीक्षण केले आहे OOMkill? होय, आपण नेमके तेच बोलत आहोत.

तुम्हाला हे घडण्याची शक्यता कमी करायची आहे का? मेमरी जास्त प्रमाणात वाटप करू नका आणि मेमरी विनंती मर्यादेपर्यंत सेट करून गॅरंटीड QoS (सेवेची गुणवत्ता) वापरा (खालील उदाहरणाप्रमाणे). मध्ये याबद्दल अधिक वाचा हेनिंग जेकब्स सादरीकरणे (झालांडो येथील प्रमुख अभियंता).

फुटण्यायोग्य (OOM मारले जाण्याची उच्च शक्यता):

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

हमी:

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

संसाधने सेट करताना संभाव्यत: काय मदत करेल?

च्या मदतीने मेट्रिक्स-सर्व्हर तुम्ही सध्याच्या CPU संसाधनाचा वापर आणि पॉड्सद्वारे मेमरी वापर पाहू शकता (आणि त्यांच्या आत असलेले कंटेनर). बहुधा, आपण ते आधीच वापरत आहात. फक्त खालील आदेश चालवा:

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

तथापि, ते फक्त वर्तमान वापर दर्शवतात. हे आपल्याला परिमाणांच्या क्रमाची अंदाजे कल्पना देऊ शकते, परंतु शेवटी आपल्याला याची आवश्यकता असेल कालांतराने मेट्रिक्समधील बदलांचा इतिहास (प्रश्नांची उत्तरे देण्यासाठी: “पीक सीपीयू लोड काय होता?”, “काल सकाळी लोड किती होता?”, इ.). यासाठी तुम्ही वापरू शकता Prometheus, डेटाडॉग आणि इतर साधने. ते फक्त मेट्रिक्स-सर्व्हरकडून मेट्रिक्स मिळवतात आणि ते संग्रहित करतात आणि वापरकर्ता त्यांना क्वेरी करू शकतो आणि त्यानुसार प्लॉट करू शकतो.

व्हर्टिकलपॉडऑटोस्केलर तो संमत स्वयंचलित ही प्रक्रिया. हे CPU आणि मेमरी वापर इतिहास ट्रॅक करते आणि या माहितीवर आधारित नवीन विनंत्या आणि मर्यादा सेट करते.

संगणकीय शक्ती कार्यक्षमतेने वापरणे सोपे काम नाही. हे सर्व वेळ टेट्रिस खेळण्यासारखे आहे. तुम्ही कमी सरासरी वापरासह (~10% म्हणा) मोजणी पॉवरसाठी खूप जास्त पैसे देत असल्यास, आम्ही AWS Fargate किंवा Virtual Kubelet वर आधारित उत्पादने पाहण्याची शिफारस करतो. ते सर्व्हरलेस/पे-पर-वापर बिलिंग मॉडेलवर तयार केले आहेत, जे अशा परिस्थितीत स्वस्त असू शकतात.

2. सजीवता आणि तत्परता तपासणी

डीफॉल्टनुसार, कुबर्नेट्समध्ये जिवंतपणा आणि तयारी तपासणे सक्षम नाहीत. आणि कधी कधी ते चालू करायला विसरतात...

परंतु घातक त्रुटी आढळल्यास तुम्ही सेवा रीस्टार्ट कशी करू शकता? आणि लोड बॅलन्सरला कसे कळते की पॉड रहदारी स्वीकारण्यास तयार आहे? किंवा ते अधिक रहदारी हाताळू शकते?

या चाचण्या सहसा एकमेकांशी गोंधळलेल्या असतात:

• चैतन्य — “जगण्याची” तपासणी, जे पॉड अयशस्वी झाल्यास रीस्टार्ट करते;
• तत्परता — तत्परता तपासणी, जर ते अयशस्वी झाले, तर ते कुबर्नेट्स सेवेमधून पॉड डिस्कनेक्ट करते (हे वापरून तपासले जाऊ शकते kubectl get endpoints) आणि पुढील तपासणी यशस्वीरीत्या पूर्ण होईपर्यंत रहदारी त्याकडे येत नाही.

या दोन्ही तपासण्या पॉडच्या संपूर्ण जीवन चक्रादरम्यान सादर केले. ते खूप महत्वाचे आहे.

एक सामान्य गैरसमज असा आहे की रेडिनेस प्रोब्स फक्त स्टार्टअपवर चालवल्या जातात जेणेकरून बॅलन्सरला कळू शकेल की पॉड तयार आहे (Ready) आणि रहदारीवर प्रक्रिया करणे सुरू करू शकते. तथापि, त्यांच्या वापरासाठी हा फक्त एक पर्याय आहे.

आणखी एक म्हणजे पॉडवरील रहदारी जास्त आहे हे शोधण्याची शक्यता आहे आणि ते ओव्हरलोड करते (किंवा पॉड संसाधन-केंद्रित गणना करते). या प्रकरणात, तयारी तपासणी मदत करते पॉडवरील भार कमी करा आणि ते “थंड” करा. भविष्यात तत्परता तपासणी यशस्वीपणे पूर्ण करण्यास अनुमती देते पॉडवरील भार पुन्हा वाढवा. या प्रकरणात (तत्परता चाचणी अयशस्वी झाल्यास), जिवंतपणा चाचणी अयशस्वी होणे खूप प्रतिकूल असेल. निरोगी आणि कठोर परिश्रम करणारी पॉड रीस्टार्ट का?

म्हणून, काही प्रकरणांमध्ये, चुकीच्या पद्धतीने कॉन्फिगर केलेल्या पॅरामीटर्ससह सक्षम करण्यापेक्षा कोणतेही तपासणे चांगले नाही. वर सांगितल्याप्रमाणे, जर जिवंतपणा तपासणी तयारी तपासणीच्या प्रती, तर तुम्ही मोठ्या संकटात आहात. कॉन्फिगर करणे हा संभाव्य पर्याय आहे फक्त तयारी चाचणीआणि धोकादायक जिवंतपणा बाजूला सोडा.

जेव्हा सामान्य अवलंबित्व अयशस्वी होते तेव्हा दोन्ही प्रकारच्या तपासण्या अयशस्वी होऊ नयेत, अन्यथा यामुळे सर्व शेंगांचे कॅस्केडिंग (हिमस्खलन सारखे) अयशस्वी होईल. दुसऱ्या शब्दात, स्वतःला इजा करू नका.

3. प्रत्येक HTTP सेवेसाठी लोडबॅलन्सर

बहुधा, तुमच्या क्लस्टरमध्ये तुमच्या HTTP सेवा आहेत ज्या तुम्ही बाहेरच्या जगाला फॉरवर्ड करू इच्छिता.

आपण म्हणून सेवा उघडल्यास type: LoadBalancer, त्याचा नियंत्रक (सेवा प्रदात्यावर अवलंबून) बाह्य लोडबॅलन्सर प्रदान करेल आणि वाटाघाटी करेल (L7 वर चालणे आवश्यक नाही, परंतु L4 वर देखील चालेल), आणि यामुळे किंमतीवर परिणाम होऊ शकतो (बाह्य स्थिर IPv4 पत्ता, संगणकीय शक्ती, प्रति-सेकंद बिलिंग ) मोठ्या संख्येने अशी संसाधने तयार करण्याची आवश्यकता असल्यामुळे.

या प्रकरणात, एक बाह्य लोड बॅलन्सर वापरणे अधिक तर्कसंगत आहे, सेवा उघडणे type: NodePort. किंवा अजून चांगले, असे काहीतरी विस्तृत करा nginx-ingress-कंट्रोलर (किंवा ट्रॅफिक), जो एकटाच असेल नोडपोर्ट बाह्य लोड बॅलन्सरशी निगडीत एंडपॉईंट आणि वापरून क्लस्टरमधील रहदारी मार्गी लावेल प्रवेश करणे-कुबर्नेट्स संसाधने.

इतर इंट्रा-क्लस्टर (मायक्रो) सेवा ज्या एकमेकांशी संवाद साधतात अशा सेवांचा वापर करून "संवाद" करू शकतात क्लस्टरआयपी आणि DNS द्वारे अंगभूत सेवा शोध यंत्रणा. फक्त त्यांचा सार्वजनिक DNS/IP वापरू नका, कारण याचा विलंबावर परिणाम होऊ शकतो आणि क्लाउड सेवांची किंमत वाढू शकते.

4. क्लस्टरची वैशिष्ट्ये विचारात न घेता ऑटोस्केलिंग करणे

क्लस्टरमध्ये नोड्स जोडताना आणि त्यांना काढून टाकताना, तुम्ही त्या नोड्सवरील CPU वापरासारख्या काही मूलभूत मेट्रिक्सवर अवलंबून राहू नये. पॉड नियोजन अनेक खात्यात घेणे आवश्यक आहे निर्बंध, जसे की पॉड/नोड अॅफिनिटी, कलंक आणि सहनशीलता, संसाधन विनंत्या, QoS, इ. या बारकावे विचारात न घेणारे बाह्य ऑटोस्केलर वापरल्याने समस्या उद्भवू शकतात.

कल्पना करा की एक विशिष्ट पॉड शेड्यूल केलेला असावा, परंतु सर्व उपलब्ध सीपीयू पॉवरची विनंती केली जाते/डिसेम्बल केली जाते आणि पॉड राज्यात अडकतो Pending. बाह्य ऑटोस्केलर सरासरी वर्तमान CPU लोड पाहतो (विनंती केलेला नाही) आणि विस्तार सुरू करत नाही (स्केल-आउट) - दुसरा नोड जोडत नाही. परिणामी, हा पॉड शेड्यूल होणार नाही.

या प्रकरणात, उलट स्केलिंग (स्केल-इन) — क्लस्टरमधून नोड काढून टाकणे नेहमीच अधिक कठीण असते. कल्पना करा की तुमच्याकडे स्टेटफुल पॉड आहे (सतत स्टोरेज कनेक्ट केलेले आहे). सतत खंड सहसा संबंधित विशिष्ट उपलब्धता क्षेत्र आणि प्रदेशात प्रतिरूपित नाहीत. अशा प्रकारे, जर बाह्य ऑटोस्केलरने या पॉडसह नोड हटवला, तर शेड्युलर हा पॉड दुसर्‍या नोडवर शेड्यूल करू शकणार नाही, कारण हे केवळ उपलब्धता क्षेत्रामध्ये केले जाऊ शकते जेथे पर्सिस्टंट स्टोरेज आहे. राज्यात पॉड अडकेल Pending.

कुबर्नेट्स समुदायात खूप लोकप्रिय क्लस्टर-ऑटोस्केलर. हे क्लस्टरवर चालते, प्रमुख क्लाउड प्रदात्यांकडून API चे समर्थन करते, सर्व निर्बंध विचारात घेते आणि वरील प्रकरणांमध्ये स्केल करू शकते. हे सर्व सेट मर्यादा राखून स्केल-इन करण्यास सक्षम आहे, ज्यामुळे पैशांची बचत होते (जे अन्यथा न वापरलेल्या क्षमतेवर खर्च केले जाईल).

5. IAM/RBAC क्षमतांकडे दुर्लक्ष करणे

साठी सतत गुपिते IAM वापरकर्ते वापरण्यापासून सावध रहा मशीन आणि अनुप्रयोग. भूमिका आणि सेवा खाती वापरून तात्पुरता प्रवेश व्यवस्थापित करा (सेवा खाती).

ऍप्लिकेशन कॉन्फिगरेशनमध्ये ऍक्‍सेस की (आणि गुपिते) हार्डकोड केल्या आहेत, तसेच क्लाउड 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जर त्यांना त्याची गरज नसेल. हे अंमलात आणणे थोडे कठीण आहे, विशेषत: RBAC K8 मध्ये, परंतु निश्चितपणे प्रयत्न करणे योग्य आहे.

6. शेंगांसाठी स्वयंचलित विरोधी आत्मीयतेवर अवलंबून राहू नका

कल्पना करा की तुमच्याकडे नोडवर काही उपयोजनांच्या तीन प्रतिकृती आहेत. नोड पडतो, आणि त्यासह सर्व प्रतिकृती. अप्रिय परिस्थिती, बरोबर? पण सर्व प्रतिकृती एकाच नोडवर का होत्या? Kubernetes उच्च उपलब्धता (HA) प्रदान करणार नाही का?!

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

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

इतकंच. आता पॉड्स वेगवेगळ्या नोड्सवर शेड्यूल केले जातील (ही स्थिती केवळ शेड्यूलिंग दरम्यान तपासली जाते, परंतु त्यांच्या ऑपरेशन दरम्यान नाही - म्हणून requiredDuringSchedulingIgnoredDuringExecution).

येथे आपण याबद्दल बोलत आहोत podAntiAffinity वेगवेगळ्या नोड्सवर: topologyKey: "kubernetes.io/hostname", - आणि भिन्न उपलब्धता क्षेत्रांबद्दल नाही. पूर्ण वाढ झालेला HA लागू करण्यासाठी, तुम्हाला या विषयात खोलवर जावे लागेल.

7. PodDisruption Budgets दुर्लक्षित करणे

कल्पना करा की तुमच्याकडे कुबर्नेट्स क्लस्टरवर उत्पादन लोड आहे. कालांतराने, नोड्स आणि क्लस्टर स्वतःच अपडेट करावे लागतात (किंवा डिकमिशन केलेले). PodDisruptionBudget (PDB) हे क्लस्टर प्रशासक आणि वापरकर्ते यांच्यातील सेवा हमी करारासारखे काहीतरी आहे.

PDB तुम्हाला नोड्सच्या कमतरतेमुळे सेवा व्यत्यय टाळण्याची परवानगी देतो:

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

या उदाहरणात, तुम्ही, क्लस्टरचा वापरकर्ता म्हणून, प्रशासकांना सांगता: "अहो, माझ्याकडे एक प्राणीसंग्रहालय सेवा आहे आणि तुम्ही काहीही केले तरी, मला या सेवेच्या किमान 2 प्रतिकृती नेहमी उपलब्ध असायला आवडेल."

आपण याबद्दल अधिक वाचू शकता येथे.

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

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

एक सामान्य गैरसमज असा आहे की जर तुम्ही नॉन-प्रॉड लोड एका नेमस्पेसमध्ये आणि प्रोड लोड दुसऱ्यामध्ये उपयोजित केले तर ते एकमेकांवर कोणत्याही प्रकारे प्रभाव टाकणार नाही... तथापि, संसाधन विनंत्या/मर्यादा, कोटा सेट करणे आणि प्राधान्य वर्ग सेट करणे वापरून एक विशिष्ट स्तर अलगाव साध्य केला जाऊ शकतो. डेटा प्लेनमधील काही "शारीरिक" अलगाव हे आपुलकी, सहनशीलता, कलंक (किंवा नोडसेलेक्टर) द्वारे प्रदान केले जातात, परंतु असे वेगळे करणे खूप आहे कठीण अंमलबजावणी करणे

ज्यांना एकाच क्लस्टरमध्ये दोन्ही प्रकारचे वर्कलोड एकत्र करणे आवश्यक आहे त्यांना जटिलतेला सामोरे जावे लागेल. जर अशी कोणतीही गरज नसेल, आणि तुम्हाला ते घेणे परवडेल आणखी एक क्लस्टर (सार्वजनिक ढगात म्हणा), तर तसे करणे चांगले. हे इन्सुलेशनची उच्च पातळी प्राप्त करेल.

9. बाह्य वाहतूक धोरण: क्लस्टर

बर्‍याचदा आपण पाहतो की क्लस्टरमधील सर्व रहदारी NodePort सारख्या सेवेद्वारे येते, ज्यासाठी डीफॉल्ट धोरण सेट केले जाते. externalTrafficPolicy: Cluster... याचा अर्थ असा की नोडपोर्ट क्लस्टरमधील प्रत्येक नोडवर उघडे आहे, आणि आपण इच्छित सेवेशी (पॉड्सचा संच) संवाद साधण्यासाठी त्यापैकी कोणत्याही वापरू शकता.

त्याच वेळी, वर नमूद केलेल्या नोडपोर्ट सेवेशी संबंधित वास्तविक पॉड्स सामान्यत: केवळ विशिष्ट ठिकाणी उपलब्ध असतात. या नोड्सचा उपसंच. दुसऱ्या शब्दांत, जर मी आवश्यक पॉड नसलेल्या नोडशी कनेक्ट केले, तर ते रहदारी दुसर्‍या नोडकडे पाठवेल, एक हॉप जोडत आहे आणि वाढती विलंबता (जर नोड वेगवेगळ्या उपलब्धता झोन/डेटा केंद्रांमध्ये स्थित असतील तर, विलंबता खूप जास्त असू शकते; याशिवाय, बाहेर पडणाऱ्या रहदारीचा खर्च वाढेल).

दुसरीकडे, एखाद्या विशिष्ट Kubernetes सेवेमध्ये धोरण सेट असल्यास externalTrafficPolicy: Local, नंतर NodePort फक्त त्या नोड्सवर उघडेल जिथे आवश्यक पॉड्स प्रत्यक्षात चालू आहेत. बाह्य लोड बॅलन्सर वापरताना जे स्थिती तपासते (आरोग्य तपासणी) endpoints (ते कसे करते AWS ELB), तो फक्त आवश्यक नोड्सवर रहदारी पाठवेल, ज्याचा विलंब, संगणकीय गरजा, बाहेर पडणे (आणि सामान्य ज्ञान तेच सांगते) वर फायदेशीर प्रभाव पडेल.

तुम्ही आधीच असे काहीतरी वापरत असण्याची दाट शक्यता आहे ट्रॅफिक किंवा nginx-ingress-कंट्रोलर नोडपोर्ट एंडपॉइंट म्हणून (किंवा लोडबॅलन्सर, जे नोडपोर्ट देखील वापरते) HTTP प्रवेश ट्रॅफिकला रूट करण्यासाठी आणि हा पर्याय सेट केल्याने अशा विनंत्यांसाठी विलंबता लक्षणीयरीत्या कमी होऊ शकते.

В हे प्रकाशन तुम्ही externalTrafficPolicy, त्याचे फायदे आणि तोटे याबद्दल अधिक जाणून घेऊ शकता.

10. क्लस्टर्समध्ये बांधू नका आणि कंट्रोल प्लेनचा गैरवापर करू नका

पूर्वी, सर्व्हरला योग्य नावाने कॉल करण्याची प्रथा होती: अँटोन, HAL9000 आणि Colossus... आज ते यादृच्छिकपणे व्युत्पन्न केलेल्या अभिज्ञापकांनी बदलले आहेत. तथापि, सवय राहिली, आणि आता योग्य नावे क्लस्टरमध्ये जातात.

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

क्लस्टर पाळीव प्राण्यांमध्ये बदलण्यात काहीच मजा नाही, म्हणून आम्ही सराव करताना त्यांना वेळोवेळी काढून टाकण्याची शिफारस करतो आपत्ती पुनर्प्राप्ती (हे मदत करेल अनागोंदी अभियांत्रिकी - अंदाजे अनुवाद.). याव्यतिरिक्त, नियंत्रण स्तरावर कार्य करणे दुखापत होणार नाही (नियंत्रण विमान). त्याला स्पर्श करण्यास घाबरणे हे चांगले लक्षण नाही. इ मृत? मित्रांनो, तुम्ही खरोखर अडचणीत आहात!

दुसरीकडे, तुम्ही त्यात फेरफार करून वाहून जाऊ नये. काळाबरोबर नियंत्रण स्तर मंद होऊ शकतो. बहुधा, हे त्यांच्या रोटेशनशिवाय मोठ्या संख्येने ऑब्जेक्ट्स तयार झाल्यामुळे आहे (डीफॉल्ट सेटिंग्जसह हेल्म वापरताना एक सामान्य परिस्थिती, म्हणूनच कॉन्फिगमॅप्स/सिक्रेट्समध्ये त्याची स्थिती अद्यतनित केली जात नाही - परिणामी, हजारो ऑब्जेक्ट्समध्ये जमा होतात. नियंत्रण स्तर) किंवा kube-api ऑब्जेक्ट्सच्या सतत संपादनासह (स्वयंचलित स्केलिंगसाठी, CI/CD साठी, मॉनिटरिंगसाठी, इव्हेंट लॉग, कंट्रोलर्स इ.).

याव्यतिरिक्त, आम्ही व्यवस्थापित Kubernetes प्रदात्यासह SLA/SLO करार तपासण्याची आणि हमींवर लक्ष देण्याची शिफारस करतो. विक्रेता हमी देऊ शकतो नियंत्रण स्तर उपलब्धता (किंवा त्याचे उपघटक), परंतु आपण त्यास पाठवलेल्या विनंत्यांचा p99 विलंब नाही. दुसऱ्या शब्दांत, आपण प्रविष्ट करू शकता kubectl get nodes, आणि फक्त 10 मिनिटांनंतर उत्तर प्राप्त करा आणि हे सेवा कराराच्या अटींचे उल्लंघन होणार नाही.

11. बोनस: नवीनतम टॅग वापरणे

पण हे आधीच एक क्लासिक आहे. अलीकडे आपण हे तंत्र कमी वेळा पाहिले आहे, कारण अनेकांनी, कटू अनुभवातून शिकून, टॅग वापरणे बंद केले आहे. :latest आणि आवृत्त्या पिन करणे सुरू केले. हुर्रे!

ECR इमेज टॅगची अपरिवर्तनीयता राखते; आम्ही शिफारस करतो की आपण या उल्लेखनीय वैशिष्ट्यासह स्वत: ला परिचित करा.

सारांश

रात्रभर सर्वकाही कार्य करेल अशी अपेक्षा करू नका: कुबर्नेट्स हा रामबाण उपाय नाही. खराब अॅप कुबेरनेट्समध्येही असेच राहील (आणि ते कदाचित खराब होईल). निष्काळजीपणामुळे नियंत्रण स्तराची अत्यधिक जटिलता, मंद आणि तणावपूर्ण काम होईल. याव्यतिरिक्त, आपणास आपत्ती पुनर्प्राप्ती धोरणाशिवाय सोडण्याचा धोका आहे. Kubernetes कडून अलगाव आणि बॉक्सच्या बाहेर उच्च उपलब्धता प्रदान करण्याची अपेक्षा करू नका. तुमचा अनुप्रयोग खरोखर क्लाउड नेटिव्ह बनवण्यासाठी थोडा वेळ घालवा.

मधील विविध संघांच्या अयशस्वी अनुभवांशी आपण परिचित होऊ शकता हा कथासंग्रह हेनिंग जेकब्स द्वारे.

या लेखात दिलेल्या त्रुटींच्या यादीत जोडू इच्छिणारे आमच्याशी Twitter वर संपर्क करू शकतात (@MarekBartik, @MstrsObserver).

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्स क्लस्टर्स डिझाइन करणे: किती असावेत?";
• «द एबीसी ऑफ सिक्युरिटी इन कुबर्नेट्स: ऑथेंटिकेशन, ऑथरायझेशन, ऑडिटिंग";
• «Kubernetes मध्ये ऑटोस्केलिंग आणि संसाधन व्यवस्थापन"(पुनरावलोकन आणि व्हिडिओ अहवाल);
• «Kubernetes मध्ये ConfigMaps: जाणून घेण्यासारखे बारकावे».

स्त्रोत: www.habr.com