কুবারনেটসে নেটওয়ার্কিংয়ের জন্য ক্যালিকো: ভূমিকা এবং সামান্য অভিজ্ঞতা

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

কুবারনেটস নেটওয়ার্কিং অ্যাপ্লায়েন্সের একটি দ্রুত ভূমিকা

একটি Kubernetes ক্লাস্টার একটি নেটওয়ার্ক ছাড়া কল্পনা করা যাবে না. আমরা ইতিমধ্যে তাদের মৌলিক বিষয়বস্তু প্রকাশ করেছি: "Kubernetes নেটওয়ার্কিং একটি সচিত্র নির্দেশিকা"এবং"নিরাপত্তা পেশাদারদের জন্য Kubernetes নেটওয়ার্ক নীতির একটি ভূমিকা».

এই নিবন্ধের প্রসঙ্গে, এটা মনে রাখা গুরুত্বপূর্ণ যে K8s নিজেই কন্টেইনার এবং নোডগুলির মধ্যে নেটওয়ার্ক সংযোগের জন্য দায়ী নয়: এর জন্য, বিভিন্ন CNI প্লাগইন (কন্টেইনার নেটওয়ার্কিং ইন্টারফেস)। এই ধারণা সম্পর্কে আমরা আরো তারা আমাকেও বলেছে.

উদাহরণস্বরূপ, এই প্লাগইনগুলির মধ্যে সবচেয়ে সাধারণ পশমী কাপড় — প্রতিটি নোডের উপরে একটি সাবনেট বরাদ্দ করে সমস্ত ক্লাস্টার নোডের মধ্যে সম্পূর্ণ নেটওয়ার্ক সংযোগ প্রদান করে। যাইহোক, সম্পূর্ণ এবং অনিয়ন্ত্রিত অ্যাক্সেসিবিলিটি সবসময় উপকারী নয়। ক্লাস্টারে কিছু ধরণের ন্যূনতম বিচ্ছিন্নতা নিশ্চিত করতে, ফায়ারওয়ালের কনফিগারেশনে হস্তক্ষেপ করা প্রয়োজন। সাধারণ ক্ষেত্রে, এটি একই CNI-এর নিয়ন্ত্রণে রাখা হয়, যে কারণে iptables-এ তৃতীয় পক্ষের হস্তক্ষেপ ভুলভাবে ব্যাখ্যা করা যেতে পারে বা সম্পূর্ণ উপেক্ষা করা যেতে পারে।

এবং একটি Kubernetes ক্লাস্টারে নেটওয়ার্ক নীতি ব্যবস্থাপনা সংগঠিত করার জন্য "বাক্সের বাইরে" প্রদান করা হয়েছে NetworkPolicy API. এই সংস্থানটি, নির্বাচিত নামস্থানে বিতরণ করা হয়েছে, এতে এক অ্যাপ্লিকেশন থেকে অন্য অ্যাপ্লিকেশনে অ্যাক্সেসের পার্থক্য করার নিয়ম থাকতে পারে। এটি আপনাকে নির্দিষ্ট পড, পরিবেশ (নেমস্পেস) বা আইপি ঠিকানাগুলির ব্লকগুলির মধ্যে অ্যাক্সেসযোগ্যতা কনফিগার করার অনুমতি দেয়:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

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

এটা যৌক্তিক যে 2 ধরনের ট্রাফিক আছে: পডে প্রবেশ করা (ইনগ্রেস) এবং এটি থেকে বের হওয়া (Egress)।

প্রকৃতপক্ষে, আন্দোলনের দিকনির্দেশের ভিত্তিতে রাজনীতি এই 2 শ্রেণীতে বিভক্ত।

পরবর্তী প্রয়োজনীয় বৈশিষ্ট্য হল একটি নির্বাচক; যার জন্য নিয়ম প্রযোজ্য। এটি একটি পড (বা পডের একটি গ্রুপ) বা একটি পরিবেশ (যেমন একটি নামস্থান) হতে পারে। একটি গুরুত্বপূর্ণ বিশদ: এই উভয় ধরনের বস্তুর একটি লেবেল থাকতে হবে (লেবেল Kubernetes পরিভাষায়) - এগুলিই রাজনীতিবিদদের সাথে কাজ করে।

কিছু ধরণের লেবেল দ্বারা একত্রিত সীমিত সংখ্যক নির্বাচক ছাড়াও, বিভিন্ন পরিবর্তনে "অনুমতি/অস্বীকার করুন/সবাই" এর মতো নিয়মগুলি লেখা সম্ভব। এই উদ্দেশ্যে, ফর্মের নির্মাণগুলি ব্যবহার করা হয়:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— এই উদাহরণে, পরিবেশের সমস্ত পড ইনকামিং ট্র্যাফিক থেকে ব্লক করা হয়েছে। বিপরীত আচরণ নিম্নলিখিত নির্মাণ সঙ্গে অর্জন করা যেতে পারে:

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

একইভাবে বহির্গামীর জন্য:

  podSelector: {}
  policyTypes:
  - Egress

- এটা বন্ধ করতে. এবং এখানে যা অন্তর্ভুক্ত করতে হবে:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

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

ক্যালিকো জানা: তত্ত্ব

ক্যালিকো প্লাগইনটি ফ্ল্যানেলের সাথে একীকরণে ব্যবহার করা যেতে পারে (সাবপ্রজেক্ট খাল) বা স্বাধীনভাবে, নেটওয়ার্ক সংযোগ এবং প্রাপ্যতা ব্যবস্থাপনা ক্ষমতা উভয়ই কভার করে।

K8s "বক্সড" সলিউশন এবং ক্যালিকো থেকে API সেট ব্যবহার করে কোন সুযোগগুলি প্রদান করে?

NetworkPolicy-এ যা তৈরি করা হয়েছে তা এখানে:

• রাজনীতিবিদরা পরিবেশ দ্বারা সীমাবদ্ধ;
• নীতিগুলি লেবেল দ্বারা চিহ্নিত পডগুলিতে প্রয়োগ করা হয়;
• নিয়মগুলি পড, পরিবেশ বা সাবনেটগুলিতে প্রয়োগ করা যেতে পারে;
• নিয়মে প্রোটোকল, নাম বা প্রতীকী পোর্ট স্পেসিফিকেশন থাকতে পারে।

ক্যালিকো কীভাবে এই ফাংশনগুলিকে প্রসারিত করে তা এখানে:

• নীতিগুলি যে কোনও বস্তুতে প্রয়োগ করা যেতে পারে: পড, ধারক, ভার্চুয়াল মেশিন বা ইন্টারফেস;
• নিয়মে একটি নির্দিষ্ট ক্রিয়া থাকতে পারে (নিষেধ, অনুমতি, লগিং);
• নিয়মের লক্ষ্য বা উত্স হতে পারে একটি পোর্ট, পোর্টের একটি পরিসর, প্রোটোকল, HTTP বা ICMP বৈশিষ্ট্য, আইপি বা সাবনেট (৪র্থ বা ৬ষ্ঠ প্রজন্ম), যেকোনো নির্বাচক (নোড, হোস্ট, পরিবেশ);
• উপরন্তু, আপনি DNAT সেটিংস এবং ট্র্যাফিক ফরওয়ার্ডিং নীতিগুলি ব্যবহার করে ট্র্যাফিকের উত্তরণ নিয়ন্ত্রণ করতে পারেন।

ক্যালিকো রিপোজিটরিতে গিটহাবের প্রথম প্রতিশ্রুতি জুলাই 2016 তারিখে, এবং এক বছর পরে প্রকল্পটি কুবারনেটস নেটওয়ার্ক সংযোগ সংগঠিত করার ক্ষেত্রে একটি অগ্রণী অবস্থান নিয়েছিল - এটি প্রমাণিত হয়, উদাহরণস্বরূপ, সমীক্ষার ফলাফল দ্বারা, দ্য নিউ স্ট্যাক দ্বারা পরিচালিত:

K8 এর সাথে অনেক বড় পরিচালিত সমাধান, যেমন আমাজন ইকেএস, Azure AKS, গুগল জিকেই এবং অন্যরা এটি ব্যবহারের জন্য সুপারিশ করতে শুরু করে।

পারফরম্যান্সের জন্য, এখানে সবকিছু দুর্দান্ত। তাদের পণ্য পরীক্ষা করার সময়, ক্যালিকো ডেভেলপমেন্ট টিম জ্যোতির্বিদ্যাগত কর্মক্ষমতা প্রদর্শন করেছে, প্রতি সেকেন্ডে 50000 কন্টেইনার তৈরির হার সহ 500টি ফিজিক্যাল নোডে 20 টিরও বেশি কন্টেইনার চালাচ্ছে। স্কেলিং এর সাথে কোন সমস্যা চিহ্নিত করা হয়নি। যেমন ফলাফল ঘোষণা করা হয়েছিল ইতিমধ্যেই প্রথম সংস্করণের ঘোষণায়। থ্রুপুট এবং রিসোর্স খরচের উপর ফোকাস করে স্বাধীন অধ্যয়নগুলিও নিশ্চিত করে যে ক্যালিকোর কর্মক্ষমতা প্রায় ফ্ল্যানেলের মতোই ভাল। উদাহরণস্বরূপ:

প্রকল্পটি খুব দ্রুত বিকাশ করছে, এটি K8s, OpenShift, OpenStack পরিচালিত জনপ্রিয় সমাধানগুলিতে কাজ সমর্থন করে, এটি ব্যবহার করে একটি ক্লাস্টার স্থাপন করার সময় ক্যালিকো ব্যবহার করা সম্ভব। লাথি, সার্ভিস মেশ নেটওয়ার্ক নির্মাণের উল্লেখ আছে (এখানে একটি উদাহরণ Istio এর সাথে একযোগে ব্যবহৃত হয়)।

ক্যালিকোর সাথে অনুশীলন করুন

ভ্যানিলা কুবারনেটস ব্যবহার করার সাধারণ ক্ষেত্রে, CNI ইনস্টল করা ফাইলটি ব্যবহার করার জন্য নেমে আসে calico.yaml, অফিসিয়াল ওয়েবসাইট থেকে ডাউনলোড করা, ব্যবহার করে kubectl apply -f.

একটি নিয়ম হিসাবে, প্লাগইনটির বর্তমান সংস্করণটি Kubernetes-এর সর্বশেষ 2-3 সংস্করণের সাথে সামঞ্জস্যপূর্ণ: পুরানো সংস্করণগুলিতে অপারেশন পরীক্ষা করা হয় না এবং নিশ্চিত করা হয় না। ডেভেলপারদের মতে, ক্যালিকো লিনাক্স কার্নেলে 3.10 এর উপরে চলমান CentOS 7, Ubuntu 16 বা Debian 8, iptables বা IPVS-এর উপরে চলে।

পরিবেশের মধ্যে বিচ্ছিন্নতা

সাধারণ বোঝার জন্য, ক্যালিকো স্বরলিপিতে নেটওয়ার্ক নীতিগুলি স্ট্যান্ডার্ডগুলির থেকে কীভাবে আলাদা এবং কীভাবে নিয়মগুলি তৈরি করার পদ্ধতি তাদের পাঠযোগ্যতা এবং কনফিগারেশন নমনীয়তাকে সহজ করে তা বোঝার জন্য আসুন একটি সাধারণ ক্ষেত্রে দেখি:

ক্লাস্টারে 2টি ওয়েব অ্যাপ্লিকেশন স্থাপন করা হয়েছে: Node.js এবং PHP-এ, যার মধ্যে একটি Redis ব্যবহার করে। PHP থেকে Redis-এ অ্যাক্সেস ব্লক করতে, Node.js-এর সাথে সংযোগ বজায় রাখার সময়, নিম্নলিখিত নীতি প্রয়োগ করুন:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

মূলত আমরা Node.js থেকে Redis পোর্টে আগত ট্রাফিকের অনুমতি দিয়েছি। এবং তারা স্পষ্টতই অন্য কিছু নিষেধ করেনি। NetworkPolicy প্রদর্শিত হওয়ার সাথে সাথে, এতে উল্লেখিত সমস্ত নির্বাচকরা বিচ্ছিন্ন হতে শুরু করে, যদি না অন্যথায় নির্দিষ্ট করা হয়। যাইহোক, বিচ্ছিন্নতা নিয়মগুলি নির্বাচক দ্বারা আচ্ছাদিত নয় এমন অন্যান্য বস্তুর ক্ষেত্রে প্রযোজ্য নয়।

উদাহরণ ব্যবহার করে apiVersion কুবারনেটস বাক্সের বাইরে, কিন্তু কিছুই আপনাকে এটি ব্যবহার করতে বাধা দেয় না ক্যালিকো ডেলিভারি থেকে একই নামের সম্পদ. সেখানে সিনট্যাক্স আরও বিশদ, তাই আপনাকে নিম্নলিখিত ফর্মে উপরের ক্ষেত্রের নিয়মটি পুনরায় লিখতে হবে:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

নিয়মিত NetworkPolicy API-এর মাধ্যমে সমস্ত ট্র্যাফিকের অনুমতি বা অস্বীকার করার জন্য উপরে উল্লিখিত কনস্ট্রাক্টে বন্ধনী সহ এমন কনস্ট্রাক্ট রয়েছে যা বোঝা এবং মনে রাখা কঠিন। ক্যালিকোর ক্ষেত্রে, ফায়ারওয়াল নিয়মের যুক্তিকে বিপরীতে পরিবর্তন করতে, শুধু পরিবর্তন করুন action: Allow উপর action: Deny.

পরিবেশ দ্বারা বিচ্ছিন্নতা

এখন এমন একটি পরিস্থিতি কল্পনা করুন যেখানে একটি অ্যাপ্লিকেশন প্রমিথিউসে সংগ্রহের জন্য ব্যবসায়িক মেট্রিক্স তৈরি করে এবং Grafana ব্যবহার করে আরও বিশ্লেষণ করে। আপলোডে সংবেদনশীল ডেটা থাকতে পারে, যা আবার ডিফল্টরূপে সর্বজনীনভাবে দেখা যায়। চলো চোখ থেকে এই তথ্য আড়াল করা যাক:

প্রমিথিউস, একটি নিয়ম হিসাবে, একটি পৃথক পরিষেবা পরিবেশে স্থাপন করা হয় - উদাহরণে এটি একটি নামস্থান হবে:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

ক্ষেত্র metadata.labels এটা কোন দুর্ঘটনা হতে পরিণত. উপরে উল্লিখিত, namespaceSelector (পাশাপাশি podSelector) লেবেল দিয়ে কাজ করে। অতএব, একটি নির্দিষ্ট পোর্টের সমস্ত পড থেকে মেট্রিক্স নেওয়ার অনুমতি দেওয়ার জন্য, আপনাকে কিছু ধরণের লেবেল যুক্ত করতে হবে (বা বিদ্যমানগুলি থেকে নিতে হবে), এবং তারপরে একটি কনফিগারেশন প্রয়োগ করতে হবে যেমন:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

এবং যদি আপনি ক্যালিকো নীতিগুলি ব্যবহার করেন, সিনট্যাক্সটি এরকম হবে:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

সাধারণভাবে, নির্দিষ্ট প্রয়োজনের জন্য এই ধরনের নীতিগুলি যোগ করে, আপনি ক্লাস্টারে অ্যাপ্লিকেশনগুলির অপারেশনে দূষিত বা দুর্ঘটনাজনিত হস্তক্ষেপ থেকে রক্ষা করতে পারেন৷

ক্যালিকোর নির্মাতাদের মতে, সর্বোত্তম অনুশীলন হল "সবকিছু ব্লক করুন এবং আপনার যা প্রয়োজন তা স্পষ্টভাবে খুলুন" পদ্ধতিতে নথিভুক্ত অফিসিয়াল ডকুমেন্টেশন (অন্যরা অনুরূপ পদ্ধতি অনুসরণ করে - বিশেষ করে, মধ্যে ইতিমধ্যে উল্লিখিত নিবন্ধ).

অতিরিক্ত ক্যালিকো অবজেক্ট ব্যবহার করা

আমি আপনাকে মনে করিয়ে দিই যে ক্যালিকো API-এর বর্ধিত সেটের মাধ্যমে আপনি নোডের প্রাপ্যতা নিয়ন্ত্রণ করতে পারেন, পডের মধ্যে সীমাবদ্ধ নয়। নিম্নলিখিত উদাহরণে ব্যবহার করে GlobalNetworkPolicy ক্লাস্টারে ICMP অনুরোধগুলি পাস করার ক্ষমতা বন্ধ রয়েছে (উদাহরণস্বরূপ, একটি পড থেকে একটি নোডে, পডের মধ্যে, বা একটি নোড থেকে একটি আইপি পডে পিং করা হয়):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

উপরের ক্ষেত্রে, ক্লাস্টার নোডগুলির পক্ষে ICMP এর মাধ্যমে একে অপরের কাছে "পৌছাতে" এখনও সম্ভব। এবং এই সমস্যা উপায় দ্বারা সমাধান করা হয় GlobalNetworkPolicy, একটি সত্তায় প্রয়োগ করা হয়েছে৷ HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

ভিপিএন কেস

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

ক্লায়েন্টরা স্ট্যান্ডার্ড UDP পোর্ট 1194 এর মাধ্যমে VPN এর সাথে সংযোগ করে এবং সংযুক্ত হলে, পড এবং পরিষেবাগুলির ক্লাস্টার সাবনেটের রুটগুলি গ্রহণ করে৷ পুরো সাবনেটগুলিকে পুশ করা হয় যাতে রিস্টার্ট করার সময় এবং ঠিকানা পরিবর্তন করার সময় পরিষেবাগুলি হারাতে না পারে৷

কনফিগারেশনের পোর্টটি স্ট্যান্ডার্ড, যা অ্যাপ্লিকেশনটি কনফিগার করার এবং এটি কুবারনেটস ক্লাস্টারে স্থানান্তর করার প্রক্রিয়াতে কিছু সূক্ষ্মতা আরোপ করে। উদাহরণস্বরূপ, একই AWS লোডব্যালেন্সারে UDP-এর জন্য গত বছরের শেষে আক্ষরিকভাবে অঞ্চলগুলির একটি সীমিত তালিকায় উপস্থিত হয়েছিল, এবং সমস্ত ক্লাস্টার নোডগুলিতে ফরওয়ার্ড করার কারণে নোডপোর্ট ব্যবহার করা যাবে না এবং সার্ভারের দৃষ্টান্তের সংখ্যা স্কেল করা অসম্ভব। দোষ সহনশীলতা উদ্দেশ্য. এছাড়াও, আপনাকে পোর্টের ডিফল্ট পরিসীমা পরিবর্তন করতে হবে...

সম্ভাব্য সমাধানের মাধ্যমে অনুসন্ধানের ফলস্বরূপ, নিম্নলিখিতগুলি বেছে নেওয়া হয়েছিল:

1. ভিপিএন সহ পড প্রতি নোড ইন নির্ধারিত হয় hostNetwork, অর্থাৎ প্রকৃত আইপিতে।
2. পরিষেবা মাধ্যমে বাইরে পোস্ট করা হয় ClusterIP. একটি পোর্ট শারীরিকভাবে নোডে ইনস্টল করা আছে, যা বাইরে থেকে ছোটখাটো রিজার্ভেশনের সাথে অ্যাক্সেসযোগ্য (একটি প্রকৃত আইপি ঠিকানার শর্তাধীন উপস্থিতি)।
3. যে নোডের উপর পড গোলাপ তা নির্ধারণ করা আমাদের গল্পের সুযোগের বাইরে। আমি শুধু বলব যে আপনি একটি নোডে পরিষেবাটিকে শক্তভাবে "নেল" করতে পারেন বা একটি ছোট সাইডকার পরিষেবা লিখতে পারেন যা VPN পরিষেবার বর্তমান আইপি ঠিকানা নিরীক্ষণ করবে এবং ক্লায়েন্টদের সাথে নিবন্ধিত DNS রেকর্ডগুলি সম্পাদনা করবে - যার যথেষ্ট কল্পনা আছে।

একটি রাউটিং দৃষ্টিকোণ থেকে, আমরা একটি VPN ক্লায়েন্টকে VPN সার্ভার দ্বারা জারি করা IP ঠিকানা দ্বারা অনন্যভাবে সনাক্ত করতে পারি। নীচে পরিষেবাগুলিতে এই জাতীয় ক্লায়েন্টের অ্যাক্সেস সীমাবদ্ধ করার একটি আদিম উদাহরণ, উপরে উল্লিখিত Redis-এ চিত্রিত:

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

এখানে, পোর্ট 6379 এর সাথে সংযোগ করা কঠোরভাবে নিষিদ্ধ, তবে একই সাথে ডিএনএস পরিষেবার ক্রিয়াকলাপ সংরক্ষিত রয়েছে, যার কার্যকারিতা প্রায়শই নিয়ম তৈরি করার সময় ক্ষতিগ্রস্থ হয়। কারণ, পূর্বে উল্লিখিত হিসাবে, যখন একটি নির্বাচক উপস্থিত হয়, ডিফল্ট অস্বীকার নীতি তার উপর প্রয়োগ করা হয় যদি না অন্যথায় নির্দিষ্ট করা হয়।

ফলাফল

এইভাবে, ক্যালিকোর উন্নত API ব্যবহার করে, আপনি নমনীয়ভাবে কনফিগার করতে পারেন এবং ক্লাস্টারের চারপাশে রাউটিং পরিবর্তন করতে পারেন। সাধারণভাবে, এটির ব্যবহার একটি কামান দিয়ে চড়ুই গুলি করার মতো দেখতে এবং BGP এবং IP-IP টানেলের সাথে একটি L3 নেটওয়ার্ক প্রয়োগ করা একটি ফ্ল্যাট নেটওয়ার্কে একটি সাধারণ Kubernetes ইনস্টলেশনে ভয়ঙ্কর দেখায়... যাইহোক, অন্যথায় টুলটি বেশ কার্যকর এবং দরকারী দেখায় .

নিরাপত্তার প্রয়োজনীয়তা পূরণের জন্য একটি ক্লাস্টারকে বিচ্ছিন্ন করা সবসময় সম্ভব নাও হতে পারে এবং এখানেই ক্যালিকো (বা অনুরূপ সমাধান) উদ্ধারে আসে। এই নিবন্ধে প্রদত্ত উদাহরণগুলি (ছোট পরিবর্তন সহ) AWS-এ আমাদের ক্লায়েন্টদের বিভিন্ন ইনস্টলেশনে ব্যবহৃত হয়।

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «নিরাপত্তা পেশাদারদের জন্য Kubernetes নেটওয়ার্ক নীতির একটি ভূমিকা";
• "কুবারনেটসে নেটওয়ার্কিং এর একটি সচিত্র নির্দেশিকা": অংশ 1 এবং 2 (নেটওয়ার্ক মডেল, ওভারলে নেটওয়ার্ক), অংশ 3 (পরিষেবা এবং ট্রাফিক প্রক্রিয়াকরণ);
• «কন্টেইনার নেটওয়ার্কিং ইন্টারফেস (CNI) - নেটওয়ার্ক ইন্টারফেস এবং লিনাক্স কন্টেইনারগুলির জন্য স্ট্যান্ডার্ড».

উত্স: www.habr.com