Canary test के साथ सुरक्षित server deployment

• Tada को संचालित करने वाली VCNC के Kim Taeho ने Kubernetes environment में canary deployment के अपने अनुभव साझा किए हैं.

• canary deployment नाम की उत्पत्ति उस प्रथा से हुई है जिसमें खनिक गैस रिसाव का पता लगाने के लिए खदान में पिंजरे में canary पक्षी साथ ले जाते थे.

• Spring Boot का major version बढ़ाने पर उस पर निर्भर libraries के version भी मजबूरन बदल जाते हैं, इसलिए इससे पैदा होने वाली performance समस्याओं या untested failures को कम से कम करने के लिए canary deployment आज़माया गया.

• Kubernetes में deployment के लिए Helm package manager का उपयोग किया जाता है; Helm की package unit को 'chart' कहा जाता है, और chart को Kubernetes cluster में install करने पर एक release बनती है.

• canary के लिए chart/release तैयार किया गया, और Ingress controller में annotation जोड़कर यह सेट किया गया कि केवल निर्धारित अनुपात के requests ही canary Ingress तक जाएँ.

आगे की चुनौतियाँ

• जब canary release में समस्या आती है, तो यह समझना कठिन होता है कि कारण canary के बदलाव हैं या पहले से मौजूद समस्या, इसलिए समान अनुपात में control group चलाकर metrics की तुलना करने का तरीका चाहिए.

• requests का एक हिस्सा उपयोगकर्ता से स्वतंत्र रूप से canary की ओर भेजा जाता है, इसलिए canary में समस्या होने पर भी retry के दौरान पुराना version request को process करके सफल हो सकता है, लेकिन कुल मिलाकर canary की समस्या का अनुभव करने वाले users का अनुपात बढ़ सकता है; इसलिए (जैसे LB में sticky handling होती है) user group के आधार पर canary routing करने से बेहतर नियंत्रण संभव होगा.