Kubernetes Pod-এ প্রক্সি পরিবেশ ভেরিয়েবল সেট করুন

সমর্থিত HTTP প্রক্সি ভেরিয়েবলগুলো Kubernetes কন্টেইনার স্পেসিফিকেশনে রাখুন এবং সরাসরি ক্লাস্টার রুটগুলোকে ইমেজ-পুল কনফিগারেশন থেকে আলাদা রাখুন।

Kubernetes নোডে একটি কমান্ড shell প্রক্সি ব্যবহার করতে পারে, কিন্তু সেই নোডের Pod-এ কোনো প্রক্সি পরিবেশ থাকে না। কন্টেইনারের পরিবেশ তার ইমেজ ও Pod কনফিগারেশন দ্বারা নির্ধারিত হয়।

এই ভেরিয়েবলগুলো সমর্থন করে এমন অ্যাপ্লিকেশনের জন্য এর বিদ্যমান কন্টেইনার এন্ট্রিতে একটি env তালিকা যোগ করুন:

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

Deployment-এ এটি spec.template.spec.containers-এর মধ্যে সংশ্লিষ্ট কন্টেইনারের অধীনে থাকে। নতুন Pods যাতে এটি পায়, সেজন্য ওয়ার্কলোডটি তার স্বাভাবিক রোলআউটের মাধ্যমে হালনাগাদ করুন। প্রকৃত ক্লায়েন্ট চাইলে ছোট হাতের নামও দিন।

বাইপাস তালিকাটি একটি প্রাথমিক উদাহরণ, ক্লাস্টারের প্রতিটি রুটের তালিকা নয়। ক্লাস্টারের প্রকৃত DNS প্রত্যয় এবং অভ্যন্তরীণ গন্তব্যগুলো ব্যবহার করুন। সার্ভিস IP ব্যবহার করে এমন অ্যাপ্লিকেশনের তাদের ক্লায়েন্ট যে সিনট্যাক্স সমর্থন করে সেখানে প্রকৃত সার্ভিস রেঞ্জের প্রয়োজন হতে পারে।

Init কন্টেইনারগুলোর নিজস্ব কন্টেইনার স্পেসিফিকেশন থাকে। বাহ্যিক ডাউনলোড করার সময় সেখানে অভীষ্ট কনফিগারেশন যোগ করুন। প্রকাশ্য HTTP ডাউনলোডের জন্য HTTP প্রক্সি তালিকা থেকে একটি এন্ডপয়েন্ট এই কন্টেইনার পরিবেশ মানের জন্য প্রার্থী।

ইমেজ পুল অ্যাপ্লিকেশন চালুর আগে ঘটে এবং নোডের কন্টেইনার রানটাইম দ্বারা সম্পন্ন হয়। Pod env সেই পূর্ববর্তী রেজিস্ট্রি সংযোগ কনফিগার করতে পারে না।

সবশেষে, HTTP প্রক্সি ভেরিয়েবল শুধুমাত্র সেই ক্লায়েন্টদের প্রভাবিত করে যারা সেগুলো ব্যবহার করে। এগুলো Pod থেকে যেকোনো ডাটাবেস, UDP বা অন্য সকেট ট্রাফিক পুনর্নির্দেশ করে না।

সম্পর্কিত নিবন্ধ