VPN-এর পিছনে থাকা প্রাইভেট registry থেকে AKS ইমেজ টানতে পারে না
kubelet নোড নেটওয়ার্ক দিয়ে টানে, pod-এর VPN দিয়ে নয়। নোড রুট, নোড DNS, pull যে প্রতিটি endpoint স্পর্শ করে, তারপর TLS ও পরিচয় দিয়ে সিদ্ধান্ত নিন।
আপনার ল্যাপটপে ইমেজ টানা ঠিকই কাজ করে, কিন্তু pod ImagePullBackOff-এ আটকে থাকে, আর কেউ পরামর্শ দেয় কর্পোরেট VPN ক্লায়েন্ট sidecar হিসেবে চালাতে। এতে কাজ হবে না, কারণ pull ঘটে আপনার কন্টেইনার তৈরির আগেই: kubelet নোডের container runtime-কে ইমেজ আনতে বলে, আর runtime নোডের network namespace ব্যবহার করে। workload-এর ভিতরের VPN ওই পথে কোনো route দিতে পারে না, আর তার নিজের সহায়ক ইমেজও আগে টানতে হয়।
কর্মের ক্রমই স্তর ঠিক করে
আগে আসে ইমেজের নাম রিজলভ করা। kubelet runtime-এর মাধ্যমে registry-র নাম resolve করে, সংযোগ করে, প্রমাণীকরণ করে, layer ডাউনলোড করে, তারপরেই কন্টেইনার চালু করে। pod যা VPN নিয়ে করে তা এই ক্রম শেষ হওয়ার পরে ঘটে, তাই ক্লাস্টারের ভিতরের টানেল pull-এর প্রমাণ নয়।
তাই cache করা ইমেজ এত বিশ্বাসযোগ্য মিথ্যা। সপ্তাহ আগে ইমেজ টানা নোডটি তা দিতেই থাকে, deployment সুস্থ দেখায়, আর ব্যর্থতা দেখা যায় কেবল যখন scheduler নতুন নোডে replica রাখে। ইভেন্টের সময়রেখায় scale-up, নোড প্রতিস্থাপন বা pool upgrade থাকলে সেগুলোকে কারণ নয়, ট্রিগার ধরুন।
তিনটি শর্ত মেরামত নির্ধারণ করে
ম্যানেজড নোড pool থেকে প্রাইভেট registry-তে পৌঁছানো নির্ভর করে রাউটিং, নাম রিজলভিং ও endpoint-এর সেটের উপর। নোড subnet যদি registry নেটওয়ার্কে route করতে না পারে, কোনো credential কাজে আসবে না। route থাকলেও নোডের DNS পথে registry নাম resolve না হলে সংযোগ শুরুই হয় না। manifest endpoint-এ দুটোই কাজ করলেও registry যে blob endpoint-এ redirect করে সেখানে না করলে pull মাঝপথে ব্যর্থ হয়।
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
শুধু VNet peering আপনাকে সব gateway transit ব্যবস্থা দেয় না, আর এক দিকে থাকা route কার্যকর route নয়। নোডের দরকার intended VPN gateway বা অনুমোদিত appliance দিয়ে সমর্থিত পথ, আর registry পক্ষের দরকার নোড subnet-এ ফেরার route।
সমাধান বাছার আগে ব্যর্থতা পড়ুন
pod-এর ইভেন্ট ও এটি যে নোডে পড়েছে সেখান থেকে শুরু করুন, নিজের আসল নাম দিয়ে: kubectl describe pod app-example -n team-example ও kubectl get pod app-example -n team-example -o wide। ইভেন্টের লেখা resolve না হওয়া hostname ও timeout, certificate প্রত্যাখ্যান ও অনুপস্থিত ইমেজ, অনুমোদন ব্যর্থতা ও বাকি সবের পার্থক্য দেখায়। এই চারটির চারজন আলাদা মালিক।
প্রমাণীকরণই সবচেয়ে বেশি অতিরিক্ত মূল্যায়িত উপায়। imagePullSecret runtime-কে registry credential দেয়; এটি route বসায় না, নোডের resolver বদলায় না, অবিশ্বস্ত certificate বৈধ করে না। ইভেন্টে pull অননুমোদিত বলা হলে পরিচয়ের পরিধি দেখুন। সংযোগ timeout হলে credential অপ্রাসঙ্গিক।
Kubernetes ইমেজ ডকুমেন্টেশন pull-এর আচরণ ও প্রাইভেট registry credential-এর তথ্যসূত্র, আর নেটওয়ার্ক বদলানোর আগে একবার পড়া উচিত, কারণ এটি প্রমাণীকরণ ও পরিবহনের সীমা স্পষ্ট করে।
pod-এর নিচে পথ তৈরি করুন
এই ক্রমে কাজ করুন, কারণ আগেরটি না হলে পরেরটি অর্থহীন। আগে নোড নেটওয়ার্ক route করুন: নোড subnet থেকে registry নেটওয়ার্কে সমর্থিত পথ আছে কি না নিশ্চিত করুন, নোডের কার্যকর route, দুই প্রান্তের security rule ও registry পক্ষের ফেরার route দেখুন।
তারপর নোডের প্রেক্ষাপট থেকে নাম resolve করুন। নোডের resolver pod-এর DNS configuration নয়, আর pod-এর ভিতরে সফলতা host runtime-এর প্রমাণ নয়। স্থায়ী hosts entry নয়, ম্যানেজড প্রাইভেট DNS ব্যবহার করুন; entry নোড প্রতিস্থাপনের আগ পর্যন্ত থাকে, তারপর নিঃশব্দে হারায়।
তারপর প্রতিটি endpoint প্রমাণ করুন। registry ক্লায়েন্টকে আলাদা authentication service ও আলাদা blob storage দিতে পারে। manifest endpoint-এ পৌঁছানো layer সম্পর্কে প্রায় কিছুই প্রমাণ করে না। শেষে TLS ও অনুমোদন সম্পূর্ণ করুন: registry নামের জন্য বৈধ ও সমর্থিত নোড configuration দিয়ে বিশ্বস্ত certificate, আর সেই repository পড়ার অনুমতি পাওয়া pull identity।
হাতে মেরামত না করা নোডে যাচাই করুন
যে পরীক্ষা গণ্য হয় তা হলো উপযুক্ত নোডে নতুন pull ও সব layer সম্পূর্ণ ডাউনলোড, ভালো হয় scale বা replacement-এ তৈরি নোড। এতে workload রাখতে পারে এমন সব pool ঢাকা পড়ে, ভুলে যাওয়াগুলোসহ। এক নোডে হাতে করা মেরামত deployment model নয়, আর পরের autoscale ইভেন্ট ফাঁকটি খুঁজে নেবে।
অন্য VNet-এ ক্লাস্টার নতুন করে বানালে পথ বদলাতে পারে, তবে সেটি প্রথম ডায়াগনস্টিক ধাপ নয়, শেষ উপায়। migration প্রস্তাব দেওয়ার আগে বর্তমান নোড নেটওয়ার্ককে প্রয়োজনীয় প্রাইভেট route ও সমর্থিত AKS নেটওয়ার্ক নিয়ন্ত্রণের সঙ্গে তুলনা করুন, আর চালুর পরের application connectivity আলাদা যাচাই হিসেবে রাখুন: pod-এর backend-এর সঙ্গে কথা বলা নোডের ইমেজ ডাউনলোডের চেয়ে ভিন্ন পরীক্ষা।