Kubernetes में हज़ारों CRD के उपयोग के लिए स्केल करना

Upbound द्वारा बनाया गया Crossplane, Kubernetes में cloud control plane प्रदान करता है। इसलिए AWS, Azure, GCP जैसे cloud resources के लिए सैकड़ों CRD(Custom Resource Definition) मौजूद हैं। Crossplane में इन्हें MR(Managed Resource) कहा जाता है.

उन्नत Kubernetes उपयोगकर्ता भी आम तौर पर कुछ दर्जन CR ही संचालित करते रहे हैं, लेकिन Crossplane में सैकड़ों MR का उपयोग करना पड़ता है, इसलिए यह देखना शुरू किया गया कि Kubernetes कितने CRD संभाल सकता है और उसकी सीमाएँ क्या हैं।

इसे client-side समस्याओं और server-side समस्याओं में बाँटकर देखा जा सकता है.

क्लाइंट-साइड समस्याएँ

• क्लाइंट में discovery प्रक्रिया समस्या बनती है।
• kubectl जैसे क्लाइंट यह पता लगाने के लिए discovery करते हैं कि सर्वर कौन-कौन से API प्रदान करता है, और इसके लिए सभी API endpoints को एक बार घूमना पड़ता है।
• CR, API endpoints के रूप में उपलब्ध कराए जाते हैं।
• https://example.org/apis/rds.aws.upbound.io/v1/instances/cool-db जैसे MR को देखने के लिए पहले https://example.org/apis/ में समर्थित API groups ढूँढने होते हैं, फिर https://example.org/apis/rds.aws.upbound.io में समर्थित versions देखने होते हैं, और फिर https://example.org/apis/rds.aws.upbound.io/v1 में समर्थित CR ढूँढने होते हैं।
• AWS, Azure, GCP cloud providers के लिए Crossplane MR लगभग 2,000 हैं और वे 300 API groups और versions में बँटे हुए हैं।
• क्लाइंट discovery के लिए 300 HTTP requests भेजता है।
• आज की network स्थिति में यह बहुत बड़ी समस्या नहीं लगती, लेकिन जो समस्याएँ सामने आईं वे rate limit और cache थीं।

क्लाइंट rate limit

• औसतन प्रति सेकंड 5 requests की rate limit लगी होती है (100 तक burst), और हर 10 मिनट में discovery cache अमान्य कर दी जाती है।
• इसे rate limit बढ़ाकर हल किया जा सकता है, और अब भी default प्रति सेकंड 5 requests है, लेकिन इसे 300 तक बढ़ाया जा सकता है।
• kubectl v1.22 में इस सीमा को बढ़ाने का issue उठाया गया था, और discovery cache को भी 10 मिनट के बजाय 5 घंटे कर दिया गया, इसलिए Kubernetes v1.25 में क्लाइंट इस बढ़ी हुई limit का उपयोग कर सकता है।

क्लाइंट cache

• Rate limit बंद करके test करने पर भी 300 API groups को query करने में लगभग 20 सेकंड लग रहे थे।
• पहले लगा कि यह network समस्या है, लेकिन बाद में पता चला कि यह cache files को देखने की प्रक्रिया में होने वाली समस्या थी।
• इसे Kubernetes 1.25 में ठीक किया गया, जिससे macOS पर यह 25 गुना तेज हुआ और Linux पर 2 गुना।

आगे के क्लाइंट सुधार

• क्लाइंट में rate limit लगाना तर्कसंगत है, लेकिन वास्तव में यह सर्वर की ठीक से सुरक्षा नहीं करता।
• Kubernetes 1.20 में जोड़ा गया API Priority and Fairness (AP&F), server-side पर queue और traffic shaping प्रदान करता है ताकि API server सुरक्षित रहे।
• Discovery के लिए एक aggregated HTTP endpoint को KEP में मंजूरी मिल चुकी है और इसे 1.26 में alpha के रूप में समर्थन मिलने की योजना है।

सर्वर-साइड समस्याएँ

OpenAPI schema calculation

• सैकड़ों CRD register करने के बाद पाया गया कि API requests लगभग एक घंटे तक बहुत धीमी हो जाती थीं।
• Profiling से पता चला कि यह समस्या OpenAPI v2 schema की गणना करने वाले logic की वजह से थी।
• जब CRD जोड़ी या update की जाती है, तो OpenAPI controller CR का swagger spec बनाता है, फिर उसे सभी CR के swagger के साथ मिलाकर एक बड़ा spec बनाता है, और फिर उसे JSON में serialize करके /openapi/v2 पर उपलब्ध कराता है।
• /openapi/v2 को lazy calculation में बदल दिया गया ताकि इसकी गणना तभी हो जब किसी वास्तविक CR endpoint का request आए।
• यह बदलाव v1.24.0 में शामिल हुआ और 1.20.13, 1.21.7, 1.22.4 में backport किया गया।

etcd क्लाइंट

• OpenAPI समस्या हल करने के बाद सामने आया यह नया bottleneck था।
• पता चला कि API server, प्रति CRD 4MiB memory का उपयोग करता है।
• यह GKE, EKS जैसी managed Kubernetes सेवाओं में और बड़ी समस्या है, क्योंकि वे API server की CPU और memory सीमित रखते हैं। संसाधन अधिक चाहिए हों तो API server अपने आप scale होता है, लेकिन दुर्भाग्य से CRD जोड़े जाने को scale करने का संकेत नहीं माना जाता। इसलिए जब तक API server बार-बार OOM killed न हो, तब तक यह scale नहीं होता।
• GKE, AKE, EKS में test करने पर auto-healing तो हुआ, लेकिन API server 5 सेकंड से 1 घंटे तक उपलब्ध नहीं रहा। Cluster पूरी तरह बंद नहीं हुआ, लेकिन सारी reconciliation रुक गई।
• Profiling से पता चला कि logging library Zap, memory का 20% ले रही थी।
• API server, CR के हर version के लिए एक अलग etcd client बनाता है, और हर etcd client एक Zap logger बनाता है।
• नतीजतन, duplicate loggers के कारण memory बढ़ी ही नहीं, बल्कि API server और etcd के बीच अनावश्यक TCP connections भी बन गए।
• Maintainers ने भी माना कि सभी CR endpoints के लिए एक ही etcd client इस्तेमाल करना सही होगा, लेकिन Kubernetes 1.25 release बहुत नज़दीक होने के कारण सब कुछ बदलना मुश्किल था, इसलिए इसे छोटे बदलाव के रूप में किया गया और सभी etcd clients को एक logger साझा करने के लिए बदला गया।
  -यह 1.25 में शामिल होने वाला है और 1.22, 1.23, 1.24 में backport किया जाएगा। इससे memory उपयोग 20% कम होगा।

आगे के सर्वर-साइड सुधार

• भविष्य में CR version के हिसाब से अलग-अलग बनाए जाने वाले etcd clients को transport के हिसाब से एक-एक (हर etcd cluster पर) बनाने की योजना है।
• GKE, EKS, AKE engineering teams के साथ भी मिलकर कई Crossplane CRD installations को संभालने पर काम चल रहा है।

[roxie]

मुफ़्त करना -> अमान्य करना

[roxie]

क्लाइंट -> क्लाइंट