কিছুক্ষণ আগে আমি MetalLB এর জন্য রাউটিং সেট আপ করার একটি খুব অস্বাভাবিক কাজের সম্মুখীন হয়েছিলাম। সব ঠিক হয়ে যাবে, কারণ... সাধারণত MetalLB-এর কোনো অতিরিক্ত ক্রিয়া প্রয়োজন হয় না, তবে আমাদের ক্ষেত্রে আমাদের কাছে একটি খুব সাধারণ নেটওয়ার্ক কনফিগারেশন সহ একটি মোটামুটি বড় ক্লাস্টার রয়েছে।

এই নিবন্ধে আমি আপনাকে বলব কিভাবে আপনার ক্লাস্টারের বাহ্যিক নেটওয়ার্কের জন্য উত্স-ভিত্তিক এবং নীতি-ভিত্তিক রাউটিং কনফিগার করবেন।

আমি MetalLB ইনস্টল এবং কনফিগার করার বিষয়ে বিস্তারিতভাবে যাব না, যেহেতু আমি অনুমান করছি আপনার ইতিমধ্যে কিছু অভিজ্ঞতা আছে। আমি সরাসরি পয়েন্টে যাওয়ার পরামর্শ দিই, যথা রাউটিং সেট আপ করুন। সুতরাং আমাদের চারটি মামলা রয়েছে:

কেস 1: যখন কোন কনফিগারেশন প্রয়োজন হয় না

আসুন একটি সহজ ক্ষেত্রে তাকান.

MetalLB দ্বারা জারি করা ঠিকানাগুলি আপনার নোডগুলির ঠিকানাগুলির মতো একই সাবনেটে থাকলে অতিরিক্ত রাউটিং কনফিগারেশনের প্রয়োজন হয় না৷

উদাহরণস্বরূপ, আপনার একটি সাবনেট আছে 192.168.1.0/24, এটি একটি রাউটার আছে 192.168.1.1, এবং আপনার নোড ঠিকানাগুলি গ্রহণ করে: 192.168.1.10-30, তারপর MetalLB এর জন্য আপনি পরিসীমা সামঞ্জস্য করতে পারেন 192.168.1.100-120 এবং নিশ্চিত হন যে তারা কোনো অতিরিক্ত কনফিগারেশন ছাড়াই কাজ করবে।

তা কেন? কারণ আপনার নোডগুলিতে ইতিমধ্যেই রুট কনফিগার করা আছে:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

এবং একই পরিসরের ঠিকানাগুলি কোনও অতিরিক্ত ক্রিয়া ছাড়াই সেগুলিকে পুনরায় ব্যবহার করবে৷

কেস 2: যখন অতিরিক্ত কাস্টমাইজেশন প্রয়োজন হয়

আপনার নোডের কনফিগার করা IP ঠিকানা বা সাবনেটের রুট না থাকলে আপনাকে অতিরিক্ত রুট কনফিগার করতে হবে যার জন্য MetalLB ইস্যু করে ঠিকানা।

আমি একটু বিস্তারিত ব্যাখ্যা করব। যখনই MetalLB একটি ঠিকানা আউটপুট করে, এটি একটি সাধারণ অ্যাসাইনমেন্টের সাথে তুলনা করা যেতে পারে যেমন:

ip addr add 10.9.8.7/32 dev lo

মনোযোগ দিন:

• a) ঠিকানা একটি উপসর্গ সঙ্গে বরাদ্দ করা হয় /32 অর্থাৎ, একটি রুট স্বয়ংক্রিয়ভাবে এটির জন্য সাবনেটে যুক্ত হবে না (এটি কেবল একটি ঠিকানা)
• b) ঠিকানাটি যেকোনো নোড ইন্টারফেসের সাথে সংযুক্ত থাকে (উদাহরণস্বরূপ লুপব্যাক)। এখানে লিনাক্স নেটওয়ার্ক স্ট্যাকের বৈশিষ্ট্যগুলি উল্লেখ করা দরকার। আপনি যে ইন্টারফেসে ঠিকানা যোগ করুন না কেন, কার্নেল সর্বদা arp অনুরোধ প্রক্রিয়া করবে এবং তাদের যেকোনো একটিতে arp প্রতিক্রিয়া পাঠাবে, এই আচরণটি সঠিক বলে বিবেচিত হয় এবং তদ্ব্যতীত, Kubernetes-এর মতো গতিশীল পরিবেশে বেশ ব্যাপকভাবে ব্যবহৃত হয়।

এই আচরণটি কাস্টমাইজ করা যেতে পারে, উদাহরণস্বরূপ কঠোর এআরপি সক্ষম করে:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

এই ক্ষেত্রে, আরপি প্রতিক্রিয়াগুলি শুধুমাত্র তখনই পাঠানো হবে যদি ইন্টারফেসে স্পষ্টভাবে একটি নির্দিষ্ট আইপি ঠিকানা থাকে। আপনি যদি MetalLB ব্যবহার করার পরিকল্পনা করেন এবং আপনার kube-proxy IPVS মোডে চলছে তাহলে এই সেটিংটি প্রয়োজন৷

যাইহোক, মেটালএলবি আরপি অনুরোধগুলি প্রক্রিয়া করার জন্য কার্নেল ব্যবহার করে না, তবে এটি নিজেই ব্যবহারকারী-স্পেসে করে, তাই এই বিকল্পটি মেটালএলবি-র অপারেশনকে প্রভাবিত করবে না।

আসুন আমাদের টাস্কে ফিরে আসি। যদি জারি করা ঠিকানাগুলির জন্য রুটটি আপনার নোডগুলিতে বিদ্যমান না থাকে তবে এটি সমস্ত নোডে আগে থেকে যুক্ত করুন:

ip route add 10.9.8.0/24 dev eth1

কেস 3: যখন আপনার উত্স-ভিত্তিক রাউটিং প্রয়োজন

আপনি যখন একটি পৃথক গেটওয়ের মাধ্যমে প্যাকেটগুলি গ্রহণ করবেন তখন আপনাকে উত্স-ভিত্তিক রাউটিং কনফিগার করতে হবে, ডিফল্টরূপে কনফিগার করা নয়, তাই প্রতিক্রিয়া প্যাকেটগুলিও একই গেটওয়ের মধ্য দিয়ে যেতে হবে।

উদাহরণস্বরূপ, আপনার একই সাবনেট আছে 192.168.1.0/24 আপনার নোডগুলিতে উত্সর্গীকৃত, তবে আপনি MetalLB ব্যবহার করে বাহ্যিক ঠিকানাগুলি ইস্যু করতে চান। ধরুন আপনার একটি সাবনেট থেকে একাধিক ঠিকানা আছে 1.2.3.0/24 VLAN 100-এ অবস্থিত এবং আপনি বাহ্যিকভাবে Kubernetes পরিষেবাগুলি অ্যাক্সেস করতে তাদের ব্যবহার করতে চান।

যোগাযোগ করার সময় 1.2.3.4 আপনি একটি ভিন্ন সাবনেট থেকে অনুরোধ করা হবে 1.2.3.0/24 এবং একটি উত্তর জন্য অপেক্ষা করুন. নোড যা বর্তমানে MetalLB-ইস্যু করা ঠিকানার জন্য মাস্টার 1.2.3.4, রাউটার থেকে প্যাকেট গ্রহণ করবে 1.2.3.1, কিন্তু তার জন্য উত্তর অগত্যা একই রুট যেতে হবে, মাধ্যমে 1.2.3.1.

যেহেতু আমাদের নোডে ইতিমধ্যেই একটি কনফিগার করা ডিফল্ট গেটওয়ে রয়েছে 192.168.1.1, তারপর ডিফল্টরূপে প্রতিক্রিয়া তার কাছে যাবে, এবং না 1.2.3.1, যার মাধ্যমে আমরা প্যাকেজ পেয়েছি।

কিভাবে এই পরিস্থিতি মোকাবেলা করতে?

এই ক্ষেত্রে, আপনাকে আপনার সমস্ত নোডগুলিকে এমনভাবে প্রস্তুত করতে হবে যাতে তারা অতিরিক্ত কনফিগারেশন ছাড়াই বাহ্যিক ঠিকানাগুলি পরিবেশন করতে প্রস্তুত থাকে। অর্থাৎ, উপরের উদাহরণের জন্য, আপনাকে আগে থেকেই নোডে একটি VLAN ইন্টারফেস তৈরি করতে হবে:

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

এবং তারপর রুট যোগ করুন:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

দয়া করে মনে রাখবেন যে আমরা একটি পৃথক রাউটিং টেবিলে রুট যোগ করি 100 এতে গেটওয়ের মাধ্যমে একটি প্রতিক্রিয়া প্যাকেট পাঠানোর জন্য প্রয়োজনীয় শুধুমাত্র দুটি রুট থাকবে 1.2.3.1, ইন্টারফেসের পিছনে অবস্থিত eth0.100.

এখন আমাদের একটি সহজ নিয়ম যোগ করতে হবে:

ip rule add from 1.2.3.0/24 lookup 100

যা স্পষ্টভাবে বলে: যদি প্যাকেটের উৎস ঠিকানা থাকে 1.2.3.0/24, তারপর আপনাকে রাউটিং টেবিল ব্যবহার করতে হবে 100. এটিতে আমরা ইতিমধ্যেই বর্ণনা করেছি যে পথটি তাকে প্রেরণ করবে 1.2.3.1

কেস 4: যখন আপনার নীতি-ভিত্তিক রাউটিং প্রয়োজন

নেটওয়ার্ক টপোলজি আগের উদাহরণের মতোই, তবে ধরা যাক আপনি বহিরাগত পুল ঠিকানাগুলি অ্যাক্সেস করতে সক্ষম হতে চান 1.2.3.0/24 আপনার শুঁটি থেকে:

বিশেষত্ব হল যে কোন ঠিকানায় প্রবেশ করার সময় 1.2.3.0/24, রেসপন্স প্যাকেট নোডে আঘাত করে এবং রেঞ্জে একটি সোর্স অ্যাড্রেস আছে 1.2.3.0/24 বাধ্যতামূলকভাবে পাঠানো হবে eth0.100, কিন্তু আমরা চাই Kubernetes এটাকে আমাদের প্রথম পডে রিডাইরেক্ট করুক, যা মূল অনুরোধ তৈরি করেছে।

এই সমস্যাটি সমাধান করা কঠিন বলে প্রমাণিত হয়েছে, তবে নীতি-ভিত্তিক রাউটিং এর জন্য এটি সম্ভব হয়েছে:

প্রক্রিয়াটি আরও ভালভাবে বোঝার জন্য, এখানে একটি নেটফিল্টার ব্লক ডায়াগ্রাম রয়েছে:

প্রথমত, আগের উদাহরণের মতো, আসুন একটি অতিরিক্ত রাউটিং টেবিল তৈরি করি:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

এখন iptables এ কয়েকটি নিয়ম যোগ করা যাক:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

এই নিয়মগুলি ইন্টারফেসে আগত সংযোগগুলি চিহ্নিত করবে eth0.100, ট্যাগ দিয়ে সমস্ত প্যাকেট চিহ্নিত করা 0x100, একই সংযোগের মধ্যে প্রতিক্রিয়াগুলিও একই ট্যাগ দিয়ে চিহ্নিত করা হবে৷

এখন আমরা একটি রাউটিং নিয়ম যোগ করতে পারি:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

অর্থাৎ, একটি উৎস ঠিকানা সহ সমস্ত প্যাকেট 1.2.3.0/24 এবং ট্যাগ 0x100 একটি টেবিল ব্যবহার করে রুট করা আবশ্যক 100.

এইভাবে, অন্য ইন্টারফেসে প্রাপ্ত অন্যান্য প্যাকেটগুলি এই নিয়মের অধীন নয়, যা তাদের স্ট্যান্ডার্ড Kubernetes টুল ব্যবহার করে রাউট করার অনুমতি দেবে।

আরও একটি জিনিস রয়েছে, লিনাক্সে একটি তথাকথিত বিপরীত পথ ফিল্টার রয়েছে, যা পুরো রাস্পবেরিকে নষ্ট করে দেয়; এটি একটি সাধারণ পরীক্ষা করে: সমস্ত আগত প্যাকেটের জন্য, এটি প্রেরকের ঠিকানা সহ প্যাকেটের উত্স ঠিকানা পরিবর্তন করে এবং পরীক্ষা করে কিনা। প্যাকেটটি একই ইন্টারফেসের মাধ্যমে চলে যেতে পারে যেখানে এটি গৃহীত হয়েছিল, যদি না হয় তবে এটি ফিল্টার করে দেবে।

সমস্যাটি হল যে আমাদের ক্ষেত্রে এটি সঠিকভাবে কাজ করবে না, তবে আমরা এটি অক্ষম করতে পারি:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

অনুগ্রহ করে মনে রাখবেন যে প্রথম কমান্ডটি rp_filter এর বিশ্বব্যাপী আচরণ নিয়ন্ত্রণ করে; যদি এটি নিষ্ক্রিয় না হয় তবে দ্বিতীয় কমান্ডের কোন প্রভাব থাকবে না। যাইহোক, অবশিষ্ট ইন্টারফেসগুলি rp_filter সক্ষম করে থাকবে।

ফিল্টারটির অপারেশন সম্পূর্ণরূপে সীমাবদ্ধ না করার জন্য, আমরা নেটফিল্টারের জন্য rp_filter বাস্তবায়ন ব্যবহার করতে পারি। একটি iptables মডিউল হিসাবে rpfilter ব্যবহার করে, আপনি বেশ নমনীয় নিয়ম কনফিগার করতে পারেন, উদাহরণস্বরূপ:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

ইন্টারফেসে rp_filter সক্ষম করুন eth0.100 ছাড়া সব ঠিকানার জন্য 1.2.3.0/24.

উত্স: www.habr.com