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, DataDog र अन्य उपकरणहरू। तिनीहरूले मेट्रिक्स-सर्भरबाट मेट्रिकहरू प्राप्त गर्छन् र तिनीहरूलाई भण्डारण गर्छन्, र प्रयोगकर्ताले तिनीहरूलाई सोध्न र तदनुसार प्लट गर्न सक्छन्।

VerticalPodAutoscaler यसलाई अनुमति दिन्छ स्वचालित यो प्रक्रिया। यसले CPU र मेमोरी उपयोग इतिहास ट्र्याक गर्दछ र यस जानकारीको आधारमा नयाँ अनुरोधहरू र सीमाहरू सेट अप गर्दछ।

कम्प्युटिङ पावर कुशलतापूर्वक प्रयोग गर्नु सजिलो काम होइन। यो सधैं टेट्रिस खेल्नु जस्तै हो। यदि तपाइँ कम औसत खपत (~ 10% भन्नुहोस्) संग कम्प्युट पावरको लागि धेरै तिर्दै हुनुहुन्छ भने, हामी AWS Fargate वा Virtual Kubelet मा आधारित उत्पादनहरू हेर्न सिफारिस गर्छौं। तिनीहरू सर्भररहित/भुक्तानी-प्रति-उपयोग बिलिङ मोडेलमा बनाइएका छन्, जुन त्यस्ता परिस्थितिहरूमा सस्तो हुन सक्छ।

2. जीवन्तता र तत्परता जाँचहरू

पूर्वनिर्धारित रूपमा, Kubernetes मा जीवन्तता र तयारी जाँचहरू सक्षम छैनन्। र कहिलेकाहीँ तिनीहरू तिनीहरूलाई खोल्न बिर्सन्छन् ...

तर तपाईं कसरी घातक त्रुटिको घटनामा सेवा पुन: सुरु गर्न सक्नुहुन्छ? र लोड ब्यालेन्सरलाई कसरी थाहा हुन्छ कि पोड ट्राफिक स्वीकार गर्न तयार छ? वा कि यसले अधिक ट्राफिक ह्यान्डल गर्न सक्छ?

यी परीक्षणहरू प्रायः एक अर्कासँग भ्रमित हुन्छन्:

• जीवन्तता - "बाँच्ने क्षमता" जाँच, यदि यो असफल भएमा पोड पुन: सुरु हुन्छ;
• तत्परता - तयारी जाँच, यदि यो असफल भयो भने, यसले कुबेरनेट सेवाबाट पोड विच्छेद गर्दछ (यो प्रयोग गरेर जाँच गर्न सकिन्छ। kubectl get endpoints) र अर्को चेक सफलतापूर्वक पूरा नभएसम्म ट्राफिक यसमा आइपुग्दैन।

यी दुवै चेक पोडको सम्पूर्ण जीवन चक्रको समयमा प्रदर्शन गरिएको। यो धेरै महत्वपूर्ण छ।

एउटा सामान्य गलत धारणा यो हो कि तयारी जाँचहरू स्टार्टअपमा मात्र चलाइन्छ ताकि ब्यालेन्सरले पोड तयार छ भनेर थाहा पाउन सक्छ (Ready) र ट्राफिक प्रशोधन सुरु गर्न सक्छ। यद्यपि, यो तिनीहरूको प्रयोगको लागि विकल्पहरू मध्ये एक मात्र हो।

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

तसर्थ, केही अवस्थामा, कुनै पनि जाँचहरू गलत तरिकाले कन्फिगर गरिएका प्यारामिटरहरूसँग सक्षम गर्नु भन्दा राम्रो हुन्छ। माथि उल्लेख गरिए अनुसार, यदि जीवन्तता जाँच तयारी जाँच प्रतिलिपि, तब तपाईं ठूलो समस्यामा हुनुहुन्छ। सम्भावित विकल्प कन्फिगर गर्न हो तत्परता परीक्षण मात्रर खतरनाक जीवन्तता छोड्नुहोस्।

सामान्य निर्भरताहरू असफल हुँदा दुवै प्रकारका जाँचहरू असफल हुनु हुँदैन, अन्यथा यसले सबै पोडहरूको क्यास्केडिङ (हिमभाला-जस्तो) विफलता निम्त्याउँछ। अर्को शब्दमा, आफैलाई हानि नगर्नुहोस्.

3. प्रत्येक HTTP सेवाको लागि लोड ब्यालेन्सर

सम्भवतः, तपाइँसँग तपाइँको क्लस्टरमा HTTP सेवाहरू छन् जुन तपाइँ बाहिरी संसारमा फर्वार्ड गर्न चाहानुहुन्छ।

यदि तपाइँ यस रूपमा सेवा खोल्नुहोस् type: LoadBalancer, यसको नियन्त्रक (सेवा प्रदायकको आधारमा) ले बाह्य लोडब्यालेन्सर उपलब्ध गराउनेछ र वार्ता गर्नेछ (L7 मा चलिरहेको छैन, तर L4 मा पनि), र यसले लागतलाई असर गर्न सक्छ (बाह्य स्थिर IPv4 ठेगाना, कम्प्युटिङ पावर, प्रति-सेकेन्ड बिलिङ। ) धेरै संख्यामा त्यस्ता स्रोतहरू सिर्जना गर्न आवश्यक छ।

यस अवस्थामा, यो एक बाह्य लोड ब्यालेन्सर प्रयोग गर्न धेरै तार्किक छ, सेवाहरू खोल्ने रूपमा type: NodePort। वा अझ राम्रो, जस्तै केहि विस्तार गर्नुहोस् nginx-इनग्रेस-नियन्त्रक (वा ट्राफिक), जो एक मात्र हुनेछ नोडपोर्ट बाह्य लोड ब्यालेन्सरसँग सम्बद्ध अन्तिम बिन्दु र प्रयोग गरी क्लस्टरमा ट्राफिक मार्ग गर्नेछ इन्ट्रेस- Kubernetes स्रोतहरू।

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

4. क्लस्टरको विशेषताहरूलाई ध्यान नदिइकन स्वतः स्केलिङ

क्लस्टरमा नोडहरू थप्दा र तिनीहरूलाई हटाउँदा, तपाईंले ती नोडहरूमा CPU प्रयोग जस्ता केही आधारभूत मेट्रिकहरूमा भर पर्नु हुँदैन। पोड योजना धेरैलाई ध्यानमा राख्नु पर्छ प्रतिबन्धहरु, जस्तै पोड/नोड सम्बद्धता, दाग र सहनशीलता, संसाधन अनुरोधहरू, QoS, आदि। बाह्य अटोस्केलर प्रयोग गरेर जसले यी सूक्ष्मताहरूलाई ध्यानमा राख्दैन समस्याहरू निम्त्याउन सक्छ।

कल्पना गर्नुहोस् कि एक निश्चित पोड अनुसूचित हुनुपर्छ, तर सबै उपलब्ध CPU पावर अनुरोध गरिएको छ/डिससेम्बल र पोड राज्यमा अड्किन्छ Pending। बाह्य अटोस्केलरले औसत हालको CPU लोड देख्छ (अनुरोध गरिएको होइन) र विस्तार सुरु गर्दैन। (स्केल आउट) - अर्को नोड थप्दैन। नतिजाको रूपमा, यो पोड अनुसूचित हुनेछैन।

यस अवस्थामा, उल्टो स्केलिंग (स्केल-इन) - क्लस्टरबाट नोड हटाउन सधैं लागू गर्न गाह्रो हुन्छ। कल्पना गर्नुहोस् कि तपाईंसँग स्टेटफुल पोड छ (निरन्तर भण्डारण जडान भएको)। निरन्तर मात्रा सामान्यतया सम्बन्धित छ विशिष्ट उपलब्धता क्षेत्र र क्षेत्र मा प्रतिकृति छैन। यसैले, यदि बाह्य अटोस्केलरले यो पोडको साथ नोड मेटाउँछ भने, अनुसूचकले यो पोडलाई अर्को नोडमा अनुसूचित गर्न सक्षम हुने छैन, किनकि यो उपलब्धता क्षेत्रमा मात्र गर्न सकिन्छ जहाँ निरन्तर भण्डारण अवस्थित छ। पोड राज्यमा अड्किनेछ Pending.

Kubernetes समुदाय मा धेरै लोकप्रिय क्लस्टर-अटोस्केलर। यो क्लस्टरमा चल्छ, प्रमुख क्लाउड प्रदायकहरूबाट API लाई समर्थन गर्दछ, सबै प्रतिबन्धहरूलाई ध्यानमा राख्छ र माथिका केसहरूमा मापन गर्न सक्छ। यो सबै सेट सीमाहरू कायम राख्दै स्केल-इन गर्न सक्षम छ, जसले गर्दा पैसा बचत हुन्छ (जुन अन्यथा प्रयोग नगरिएको क्षमतामा खर्च हुनेछ)।

5. IAM/RBAC क्षमताहरूलाई बेवास्ता गर्दै

IAM प्रयोगकर्ताहरूको लागि निरन्तर गोप्य प्रयोग गर्नदेखि सावधान रहनुहोस् मेसिन र अनुप्रयोगहरू। भूमिका र सेवा खाताहरू प्रयोग गरेर अस्थायी पहुँच व्यवस्थित गर्नुहोस् (सेवा खाताहरू).

क्लाउड IAM मा पहुँच हुँदाहुँदै पनि गोप्यताको रोटेशनलाई बेवास्ता गर्नुका साथै एप्लिकेसन कन्फिगरेसनमा पहुँच कुञ्जीहरू (र गोप्यहरू) हार्डकोड गरिएका छन् भन्ने तथ्यलाई हामी प्रायः सामना गर्छौं। उपयुक्त भएमा प्रयोगकर्ताहरूको सट्टा IAM भूमिका र सेवा खाताहरू प्रयोग गर्नुहोस्।

kube2iam को बारेमा बिर्सनुहोस् र सेवा खाताहरूको लागि सीधा IAM भूमिकाहरूमा जानुहोस् (मा वर्णन गरिए अनुसार एउटै नामको नोट Štěpán Vraný):

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 K8s मा, तर निश्चित रूपमा प्रयासको लायक छ।

6. पोडहरूको लागि स्वचालित विरोधी-सम्बन्धमा भरोसा नगर्नुहोस्

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

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

// опущено для краткости
      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 बेवास्ता गर्दै

कल्पना गर्नुहोस् कि तपाइँसँग Kubernetes क्लस्टरमा उत्पादन लोड छ। आवधिक रूपमा, नोडहरू र क्लस्टर आफैं अद्यावधिक (वा खारेज) हुनुपर्छ। PodDisruptionBudget (PDB) क्लस्टर प्रशासक र प्रयोगकर्ताहरू बीचको सेवा ग्यारेन्टी सम्झौता जस्तै हो।

PDB ले तपाईंलाई नोडहरूको कमीको कारणले सेवा अवरोधहरूबाट बच्न अनुमति दिन्छ:

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

यस उदाहरणमा, तपाइँ, क्लस्टरको प्रयोगकर्ताको रूपमा, प्रशासकहरूलाई भन्नुहुन्छ: "हे, मसँग चिडियाखानाको सेवा छ, र तपाईले जे गरे पनि, म यो सेवाको कम्तिमा २ प्रतिकृतिहरू सधैं उपलब्ध गराउन चाहन्छु।"

तपाईं यस बारे थप पढ्न सक्नुहुन्छ यहाँ.

8. एक साझा क्लस्टरमा बहु प्रयोगकर्ता वा वातावरण

Kubernetes नेमस्पेस (नामस्थान) बलियो इन्सुलेशन प्रदान नगर्नुहोस्.

एउटा सामान्य गलत धारणा यो हो कि यदि तपाइँ एक नेमस्पेसमा गैर-प्रोड लोड डिप्लोय गर्नुहुन्छ र अर्कोमा प्रोड लोड गर्नुहुन्छ, त्यसपछि तिनीहरू एकअर्कालाई कुनै पनि हिसाबले प्रभाव पार्ने छैन... यद्यपि, स्रोत अनुरोध/सीमाहरू, सेटिङ कोटाहरू, र प्राथमिकता वर्गहरू सेट गरेर एक निश्चित स्तरको अलगाव प्राप्त गर्न सकिन्छ। डाटा प्लेनमा केही "शारीरिक" अलगावहरू समानता, सहिष्णुता, दाग (वा नोडसेलेक्टरहरू) द्वारा प्रदान गरिन्छ, तर यस्तो पृथकता एकदमै छ। कठिनाई कार्यान्वयन गर्ने।

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

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

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

एकै समयमा, माथि उल्लेखित NodePort सेवासँग सम्बन्धित वास्तविक पोडहरू सामान्यतया केवल एक निश्चितमा उपलब्ध हुन्छन्। यी नोडहरूको उपसेट। अर्को शब्दमा, यदि मैले आवश्यक पोड नभएको नोडमा जडान गरें भने, यसले ट्राफिकलाई अर्को नोडमा फर्वार्ड गर्नेछ, हप थप्दै र बढ्दो विलम्बता (यदि नोडहरू विभिन्न उपलब्धता क्षेत्रहरू/डेटा केन्द्रहरूमा अवस्थित छन् भने, विलम्बता धेरै उच्च हुन सक्छ; थप रूपमा, निकास ट्राफिक लागतहरू बढ्नेछ)।

अर्कोतर्फ, यदि एक निश्चित Kubernetes सेवासँग नीति सेट छ externalTrafficPolicy: Local, त्यसपछि NodePort ती नोडहरूमा मात्र खुल्छ जहाँ आवश्यक पोडहरू वास्तवमा चलिरहेका छन्। राज्य जाँच गर्ने बाह्य लोड ब्यालेन्सर प्रयोग गर्दा (स्वास्थ्य जाँच) endpoints (यसले कसरी गर्छ AWS ELB), उहाँ आवश्यक नोडहरूमा मात्र ट्राफिक पठाउनेछ, जसले ढिलाइ, कम्प्युटिङ आवश्यकताहरू, निकास बिलहरूमा लाभकारी प्रभाव पार्नेछ (र सामान्य ज्ञानले पनि त्यस्तै निर्देशन दिन्छ)।

त्यहाँ एक उच्च मौका छ कि तपाइँ पहिले देखि नै केहि प्रयोग गर्दै हुनुहुन्छ ट्राफिक वा nginx-इनग्रेस-नियन्त्रक नोडपोर्ट एन्डपोइन्टको रूपमा (वा लोड ब्यालेन्सर, जसले नोडपोर्ट पनि प्रयोग गर्दछ) HTTP प्रवेश ट्राफिकलाई रूट गर्न, र यो विकल्प सेट गर्नाले त्यस्ता अनुरोधहरूको विलम्बतालाई उल्लेखनीय रूपमा कम गर्न सक्छ।

В यो प्रकाशन तपाईं बाह्य यातायात नीति, यसको फाइदा र बेफाइदा बारे थप जान्न सक्नुहुन्छ।

10. क्लस्टरहरूमा बाँध्नुहोस् र नियन्त्रण विमानको दुरुपयोग नगर्नुहोस्

पहिले, सर्भरहरूलाई उचित नामहरूद्वारा कल गर्ने प्रचलन थियो: एन्टोन, HAL9000 र Colossus... आज तिनीहरू अनियमित रूपमा उत्पन्न पहिचानकर्ताहरूद्वारा प्रतिस्थापन गरिएका छन्। यद्यपि, बानी रह्यो, र अब उचित नामहरू क्लस्टरहरूमा जान्छन्।

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

क्लस्टरहरू घरपालुवा जनावरमा परिणत हुनुमा केही रमाइलो छैन, त्यसैले हामी अभ्यास गर्दा समय-समयमा तिनीहरूलाई हटाउन सिफारिस गर्छौं। प्राक्रतिक प्रकोप पछी पुनर निर्माण (यसले मद्दत गर्नेछ अराजकता ईन्जिनियरिङ् - लगभग। अनुवाद।)। थप रूपमा, यो नियन्त्रण तहमा काम गर्न चोट लाग्दैन (नियन्त्रण विमान)। उसलाई छुन डराउनु राम्रो संकेत होइन। आदि मरेको? साथीहरू, तपाईं साँच्चै समस्यामा हुनुहुन्छ!

अर्कोतर्फ, तपाईं यसलाई हेरफेर गर्नबाट टाढा हुनु हुँदैन। समय संग नियन्त्रण तह ढिलो हुन सक्छ। सम्भवतः, यो तिनीहरूको परिक्रमा बिना नै ठूलो संख्यामा वस्तुहरू सिर्जना भएको कारणले हो (पूर्वनिर्धारित सेटिङहरूसँग हेलम प्रयोग गर्दा सामान्य अवस्था, त्यसैले कन्फिगम्याप/सेक्रेटहरूमा यसको स्थिति अद्यावधिक गरिएको छैन - परिणाम स्वरूप, हजारौं वस्तुहरू जम्मा हुन्छन्। नियन्त्रण तह) वा kube-api वस्तुहरूको निरन्तर सम्पादनको साथ (स्वचालित स्केलिंगको लागि, CI/CD को लागि, निगरानीको लागि, घटना लगहरू, नियन्त्रकहरू, आदि)।

थप रूपमा, हामी व्यवस्थित Kubernetes प्रदायकसँग SLA/SLO सम्झौताहरू जाँच गर्न र ग्यारेन्टीहरूमा ध्यान दिन सिफारिस गर्छौं। विक्रेताले ग्यारेन्टी गर्न सक्छ नियन्त्रण तह उपलब्धता (वा यसको उपकम्पोनेन्टहरू), तर तपाईंले यसलाई पठाउनुभएको अनुरोधहरूको p99 ढिलाइ होइन। अर्को शब्दमा, तपाइँ प्रविष्ट गर्न सक्नुहुन्छ kubectl get nodes, र 10 मिनेट पछि मात्र जवाफ प्राप्त गर्नुहोस्, र यो सेवा सम्झौताका सर्तहरूको उल्लङ्घन हुनेछैन।

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

तर यो पहिले नै एक क्लासिक छ। पछिल्लो समय हामीले यो प्रविधि कमै भेटेका छौं, किनभने धेरैले तीतो अनुभवबाट सिकेर ट्याग प्रयोग गर्न छोडेका छन्। :latest र संस्करणहरू पिन गर्न थाले। हुर्रे!

ECR छवि ट्यागहरूको अपरिवर्तनीयता कायम राख्छ; हामी तपाईंलाई यो उल्लेखनीय सुविधासँग परिचित गराउन सिफारिस गर्छौं।

सारांश

सबै कुरा रातारात काम गर्ने आशा नगर्नुहोस्: Kubernetes एक रामबाण उपाय होइन। खराब एप Kubernetes मा पनि यसरी रहनेछ (र यो शायद खराब हुनेछ)। लापरवाहीले नियन्त्रण तहको अत्यधिक जटिलता, ढिलो र तनावपूर्ण कामको नेतृत्व गर्नेछ। थप रूपमा, तपाइँ एक आपदा रिकभरी रणनीति बिना छोडिने जोखिम। Kubernetes ले बक्स बाहिर अलगाव र उच्च उपलब्धता प्रदान गर्ने अपेक्षा नगर्नुहोस्। आफ्नो आवेदन साँच्चै क्लाउड नेटिभ बनाउन केही समय खर्च गर्नुहोस्।

तपाईं विभिन्न टोलीका असफल अनुभवहरूसँग परिचित हुन सक्नुहुन्छ कथाहरूको यो संग्रह हेनिंग जेकब्स द्वारा।

यस लेखमा दिइएको त्रुटिहरूको सूचीमा थप्न चाहनेहरूले हामीलाई ट्विटरमा सम्पर्क गर्न सक्नुहुन्छ (@MarekBartik, @MstrsObserver).

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes क्लस्टरहरू डिजाइन गर्दै: कतिवटा हुनुपर्छ?»;
• «कुबेरनेटमा सुरक्षाको एबीसी: प्रमाणीकरण, प्राधिकरण, अडिटिङ»;
• «Kubernetes मा स्वत: स्केलिंग र स्रोत व्यवस्थापन"(समीक्षा र भिडियो रिपोर्ट);
• «Kubernetes मा ConfigMaps: बारे जान्न लायक बारीकियों"।

स्रोत: www.habr.com