আপনি যে কুবারনেটিস ভার্সনের জন্য ডকুমেন্টেশন দেখছেন : v1.30
Kubernetes v1.30 ডকুমেন্টেশন আর সক্রিয়ভাবে রক্ষণাবেক্ষণ করা হয় না। আপনি বর্তমানে যে ভার্সনটি দেখছেন সেটি একটি স্ট্যাটিক স্ন্যাপশট। আপ-টু-ডেট ডকুমেন্টেশনের জন্য, দেখুন সর্বশেষ ভার্সন
সার্ভিস, লোড ব্যালেন্সিং এবং নেটওয়ার্কিং
কুবারনেটিস নেটওয়ার্ক মডেল
একটি ক্লাস্টারের প্রতিটি পড
তার নিজস্ব ক্লাস্টার-ওয়াইড আইপি ঠিকানা পায়।
এর অর্থ হলো আপনাকে পডের
মধ্যে স্পষ্টভাবে লিঙ্ক তৈরি করার দরকার নেই
এবং পোর্টগুলো হোস্ট করার জন্য আপনাকে ম্যাপিং কন্টেইনার পোর্টগুলোর সাথে মোকাবিলা করতে হবে না।
এটি একটি পরিষ্কার, পিছনের-সামঞ্জস্যপূর্ণ মডেল (backwards-compatible model) তৈরি করে
যেখানে পোর্ট বরাদ্দকরণ, নামকরণ, সার্ভিস আবিষ্কার (service discovery), লোড ব্যালেন্সিং, অ্যাপ্লিকেশন কনফিগারেশন এবং মাইগ্রেশনের
দৃষ্টিকোণ থেকে পডগুলোকে
অনেকটা ভিএম (Virtual Machine) বা ফিজিক্যাল হোস্টের মতোই
বিবেচনা করা যেতে পারে।
কুবারনেটিস যেকোন নেটওয়ার্কিং বাস্তবায়নে নিম্নলিখিত মৌলিক প্রয়োজনীয়তাগুলো আরোপ করে (যেকোনো ইচ্ছাকৃত নেটওয়ার্ক বিভাজন নীতি ব্যতীত):
- পড NAT ছাড়া অন্য কোনো নোডে অন্য সব পডের সঙ্গে যোগাযোগ করতে পারে
- একটি নোডের এজেন্ট (যেমন system daemons, kubelet) সেই নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে
দ্রষ্টব্য: হোস্ট নেটওয়ার্কে (যেমন লিনাক্স) চলমান পডগুলোকে
সমর্থন করে এমন প্ল্যাটফর্মগুলোর জন্য,
যখন পডগুলো একটি নোডের হোস্ট নেটওয়ার্কের সাথে সংযুক্ত থাকে তখনও
তারা সমস্ত নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে NAT ছাড়া ৷
এই মডেলটি শুধুমাত্র সামগ্রিকভাবে কম জটিল নয়, এটি প্রধানত কুবারনেটিসের ইচ্ছার সাথে সামঞ্জস্যপূর্ণ যাতে ভিএম থেকে কন্টেইনারে অ্যাপের লো-ফ্রিকশন পোর্টিং সক্ষম করা যায়। যদি আপনার কাজ আগে কোনো ভিএম-এ চলত, তাহলে আপনার ভিএম-এর IP ছিল এবং আপনার প্রোজেক্টের অন্যান্য ভিএম-এর সাথে কথা বলতে পারে। এটি একই মৌলিক মডেল।
কুবারনেটিস আইপি ঠিকানাগুলো পড
স্কোপে বিদ্যমান - একটি পডের
মধ্যে থাকা কন্টেনারগুলো
তাদের নেটওয়ার্ক নেমস্পেসগুলো ভাগ করে - তাদের IP ঠিকানা এবং MAC ঠিকানা সহ।
এর মানে হলো যে একটি পডের
মধ্যে থাকা কন্টেইনারগুলো একে অপরের পোর্টে লোকালহোস্টে
পৌঁছাতে পারে।
এটি আরো বোঝায় যে একটি পডের
মধ্যে থাকা কন্টেইনারগুলোকে পোর্ট ব্যবহারের সমন্বয় করতে হবে,
তবে এটি একটি ভিএম-এর প্রক্রিয়াগুলোর থেকে আলাদা নয়।
এটিকে "IP-per-pod" মডেল বলা হয়।
এটি কীভাবে প্রয়োগ করা হয় তা ব্যবহার করা নির্দিষ্ট কন্টেইনার রানটাইমের একটি ডিটেইল।
নোডেই
পোর্টের জন্য অনুরোধ করা সম্ভব যা আপনার পডে
ফরোয়ার্ড করা হয়
(যাকে হোস্ট পোর্ট বলা হয়), কিন্তু এটি একটি খুব বিশিষ্ট অপারেশন।
সেই ফরোয়ার্ডিং কীভাবে বাস্তবায়িত হয় তাও কন্টেইনার রানটাইমের ডিটেইল।
পড
নিজেই হোস্ট পোর্টের অস্তিত্ব বা অ-অস্তিত্ব সম্পর্কে অন্ধ।
কুবারনেটিস নেটওয়ার্কিং চারটি উদ্বেগের সমাধান করে:
- লুপব্যাকের মাধ্যমে একটি পডের মধ্যে কন্টেইনার যোগাযোগের জন্য নেটওয়ার্কিং ব্যবহার করে ।
- ক্লাস্টার নেটওয়ার্কিং বিভিন্ন পডের মধ্যে যোগাযোগ প্রদান করে।
- সার্ভিস API আপনাকে আপনার ক্লাস্টারের
বাইরে থেকে পৌঁছানোর জন্য পডসে চলমান একটি অ্যাপ্লিকেশন প্রকাশ
করতে দেয় ।
- ইনগ্রেস বিশেষত HTTP অ্যাপ্লিকেশন, ওয়েবসাইট এবং এপিআই প্রকাশ করার জন্য অতিরিক্ত কার্যকারিতা প্রদান করে।
- গেটওয়ে API হলো একটি অ্যাড-অন যেটি মডেলিং সার্ভিস নেটওয়ার্কিংয়ের জন্য API ধরণের একটি অভিব্যক্তিপূর্ণ (expressive), এক্সটেনসিবল, এবং ভূমিকা-ভিত্তিক পরিবার প্রদান করে।
- এছাড়া আপনি শুধুমাত্র আপনার ক্লাস্টারের মধ্যে ব্যবহারের জন্য সার্ভিসগুলো প্রকাশ করতে সার্ভিসগুলো ব্যবহার করতে পারেন ।
কানেক্টিং অ্যাপ্লিকেশানস উইথ সার্ভিস টিউটোরিয়াল আপনাকে একটি হ্যান্ডস-অন উদাহরণ সহ পরিষেবা এবং কুবারনেটিস নেটওয়ার্কিং সম্পর্কে শিখতে দেয়।
ক্লাস্টার নেটওয়ার্কিং ব্যাখ্যা করে কিভাবে আপনার ক্লাস্টারের জন্য নেটওয়ার্কিং সেট আপ করতে হয় এবং এর সাথে জড়িত প্রযুক্তিগুলোর একটি ওভারভিউ প্রদান করে।