प्रोहोस्टर > Блог > प्रशासन > Kubernetes मा DNS को साथ समस्याहरू। सार्वजनिक पोस्टमार्टम

Kubernetes मा DNS को साथ समस्याहरू। सार्वजनिक पोस्टमार्टम

नोट अनुवाद: यो कम्पनीको इन्जिनियरिङ ब्लगबाट सार्वजनिक पोस्टमार्टमको अनुवाद हो तयारी गर्नुहोस्। यसले Kubernetes क्लस्टरमा कन्ट्र्याकको समस्यालाई वर्णन गर्दछ, जसले केही उत्पादन सेवाहरूको आंशिक डाउनटाइम निम्त्यायो।

पोस्टमार्टमको बारेमा अलि बढी जान्न वा भविष्यमा केही सम्भावित DNS समस्याहरू रोक्न चाहनेहरूका लागि यो लेख उपयोगी हुन सक्छ।

Kubernetes मा DNS को साथ समस्याहरू। सार्वजनिक पोस्टमार्टम
यो DNS होइन
यो DNS हुन सक्दैन
यो DNS थियो

Preply मा पोस्टमार्टम र प्रक्रियाहरूको बारेमा थोरै

पोस्टमार्टमले उत्पादनमा भएको खराबी वा केही घटनाको वर्णन गर्दछ। पोस्टमार्टममा घटनाहरूको समयरेखा, प्रयोगकर्ताको प्रभाव, मूल कारण, लिइएका कार्यहरू, र सिकेका पाठहरू समावेश हुन्छन्।

SRE खोज्दै

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

घटनामा संलग्न व्यक्तिहरूले सजाय वा प्रतिशोधको डर बिना नै विस्तृत रूपमा बोल्न सक्छन् भन्ने महसुस गर्नुपर्छ। दोष छैन! पोस्टमार्टम लेख्नु कुनै सजाय होइन, तर सम्पूर्ण कम्पनीको लागि सिक्ने अवसर हो।

CALMS र DevOps राख्नुहोस्: S साझेदारीको लागि हो

Kubernetes मा DNS को साथ समस्याहरू। पोस्टमार्टम

मिति: 28.02.2020

लेखकहरू: Amet U., Andrey S., Igor K., Alexey P.

स्थिति: समाप्त भयो

संक्षिप्त: Kubernetes क्लस्टरमा केही सेवाहरूको लागि आंशिक DNS अनुपलब्धता (26 मिनेट)

विलियने: A, B र C सेवाहरूको लागि 15000 घटनाहरू हराए

प्रमुख कारण: कुबे-प्रोक्सीले कन्ट्र्याक तालिकाबाट पुरानो प्रविष्टिलाई सही तरिकाले हटाउन असक्षम थियो, त्यसैले केही सेवाहरू अझै पनि अवस्थित नभएका पोडहरूमा जडान गर्न प्रयास गरिरहेका थिए।

E0228 20:13:53.795782       1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...

ट्रिगर: Kubernetes क्लस्टर भित्र कम लोडको कारण, CoreDNS-autoscaler ले डिप्लोइमेन्टमा पोडहरूको संख्या तीनबाट दुईमा घटायो।

समाधान: एप्लिकेसनको अर्को डिप्लोइमेन्टले नयाँ नोडहरू सिर्जना गर्न थाल्यो, CoreDNS-autoscaler ले क्लस्टरलाई सेवा दिन थप पोडहरू थप्यो, जसले कन्ट्र्याक तालिकाको पुन: लेख्न उत्प्रेरित गर्‍यो।

पत्ता लगाउने: प्रोमिथियस अनुगमनले A, B र C सेवाहरूको लागि 5xx त्रुटिहरूको ठूलो संख्या पत्ता लगायो र अन-ड्युटी इन्जिनियरहरूलाई कल गर्न थाल्यो।

Kubernetes मा DNS को साथ समस्याहरू। सार्वजनिक पोस्टमार्टम
Kibana मा 5xx त्रुटिहरू

Действия

प्रभाव
टाइप गर्नुहोस्
जिम्मेवार
उद्देश्य

CoreDNS को लागि अटोस्केलर असक्षम गर्नुहोस्
रोकियो
एमेट यू।
DEVOPS-695

क्यासिङ DNS सर्भर सेटअप गर्नुहोस्
घट्नु
म्याक्स वि.
DEVOPS-665

कन्ट्र्याक निगरानी सेट अप गर्नुहोस्
रोकियो
एमेट यू।
DEVOPS-674

सिकेका पाठहरू

के राम्रो भयो:

  • अनुगमन राम्रै भयो । प्रतिक्रिया छिटो र व्यवस्थित थियो
  • हामीले नोडहरूमा कुनै सीमाहरू मारेका छैनौं

के गलत थियो:

  • अझै अज्ञात वास्तविक मूल कारण, समान विशिष्ट बग कन्ट्राक मा
  • सबै कार्यहरूले परिणामहरू मात्र सही गर्छ, मूल कारण होइन (बग)
  • हामीलाई थाहा थियो कि ढिलो वा चाँडो हामीलाई DNS मा समस्या हुन सक्छ, तर हामीले कार्यहरूलाई प्राथमिकता दिएनौं।

जहाँ हामी भाग्यशाली छौं:

  • अर्को डिप्लोइमेन्ट CoreDNS-autoscaler द्वारा ट्रिगर गरिएको थियो, जसले कन्ट्र्याक तालिकालाई ओभरराइट गर्यो।
  • यो बगले केही सेवाहरूलाई मात्र असर गर्यो

टाइमलाइन (EET)

समय
प्रभाव

22:13
CoreDNS-autoscaler ले पोडहरूको संख्या तीनबाट दुईमा घटायो

22:18
ड्युटीमा रहेका इन्जिनियरहरूले अनुगमन प्रणालीबाट कलहरू प्राप्त गर्न थाले

22:21
ड्युटीमा रहेका इन्जिनियरहरूले त्रुटिको कारण पत्ता लगाउन थाले।

22:39
ड्युटीमा रहेका इन्जिनियरहरूले पछिल्लो संस्करणको नयाँ सेवाहरू मध्ये एकलाई फिर्ता गर्न थाले

22:40
5xx त्रुटिहरू देखा पर्न बन्द भयो, स्थिति स्थिर भएको छ

  • पत्ता लगाउने समय: 4 मिनेट
  • कार्य अघि समय: 21 मिनेट
  • ठीक गर्न समय: 1 मिनेट

थप जानकारी

CPU को उपयोग कम गर्न को लागी, लिनक्स कर्नेलले conntrack भनिने केहि प्रयोग गर्दछ। छोटकरीमा, यो एक उपयोगिता हो जसले NAT रेकर्डहरूको सूची समावेश गर्दछ जुन विशेष तालिकामा भण्डारण गरिन्छ। जब अर्को प्याकेट उही पोडबाट पहिले जस्तै पोडमा आइपुग्छ, अन्तिम आईपी ठेगाना पुन: गणना गरिने छैन, तर कन्ट्र्याक तालिकाबाट लिइनेछ।
Kubernetes मा DNS को साथ समस्याहरू। सार्वजनिक पोस्टमार्टम
कन्ट्र्याक कसरी काम गर्दछ

परिणामहरू

यो केहि उपयोगी लिङ्कहरु संग हाम्रो पोस्टमार्टम को एक उदाहरण थियो। विशेष गरी यस लेखमा, हामी जानकारी साझा गर्छौं जुन अन्य कम्पनीहरूको लागि उपयोगी हुन सक्छ। यसैले हामी गल्ती गर्न डराउँदैनौं र यसैले हामी हाम्रो पोस्टमार्टम सार्वजनिक गर्छौं। यहाँ केहि थप रोचक सार्वजनिक पोस्टमार्टमहरू छन्:

स्रोत: www.habr.com

एक टिप्पणी थप्न