উৎপাদনে Kubernetes ব্যবহার করে কিভাবে Istio চালাবেন। অংশ 1

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

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

কিভাবে এটি কাজ করে

Istio দুটি প্রধান অঞ্চল নিয়ে গঠিত - নিয়ন্ত্রণ সমতল এবং ডেটা সমতল। কন্ট্রোল প্লেনে প্রধান উপাদান রয়েছে যা বাকিগুলির সঠিক অপারেশন নিশ্চিত করে। বর্তমান সংস্করণে (1.0), কন্ট্রোল প্লেনে তিনটি প্রধান উপাদান রয়েছে: পাইলট, মিক্সার, সিটাডেল। আমরা সিটাডেল বিবেচনা করব না; পরিষেবাগুলির মধ্যে পারস্পরিক TLS পরিচালনা নিশ্চিত করতে সার্টিফিকেট তৈরি করা প্রয়োজন। আসুন পাইলট এবং মিক্সারের নকশা এবং উদ্দেশ্যটি ঘনিষ্ঠভাবে দেখি।

পাইলট হল প্রধান নিয়ন্ত্রণ উপাদান যা ক্লাস্টারে আমাদের কী আছে সে সম্পর্কে সমস্ত তথ্য বিতরণ করে - পরিষেবা, তাদের শেষ পয়েন্ট এবং রাউটিং নিয়ম (উদাহরণস্বরূপ, ক্যানারি স্থাপনার নিয়ম বা সার্কিট ব্রেকার নিয়ম)।

মিক্সার হল একটি ঐচ্ছিক নিয়ন্ত্রণ সমতল উপাদান যা মেট্রিক্স, লগ এবং নেটওয়ার্ক মিথস্ক্রিয়া সম্পর্কে যেকোনো তথ্য সংগ্রহ করার ক্ষমতা প্রদান করে। তিনি নীতির নিয়মাবলীর সাথে সম্মতি এবং হারের সীমার সাথে সম্মতিও পর্যবেক্ষণ করেন।

সাইডকার প্রক্সি কন্টেইনার ব্যবহার করে ডেটা প্লেন প্রয়োগ করা হয়। ডিফল্ট শক্তিশালী দূত প্রক্সি সার্ভার. এটি অন্য বাস্তবায়নের সাথে প্রতিস্থাপন করা যেতে পারে, উদাহরণস্বরূপ nginx (nginmesh)।

Istio যাতে অ্যাপ্লিকেশনগুলির জন্য সম্পূর্ণ স্বচ্ছভাবে কাজ করে, সেখানে একটি স্বয়ংক্রিয় ইনজেকশন সিস্টেম রয়েছে। সর্বশেষ বাস্তবায়ন Kubernetes সংস্করণ 1.9+ (মিউটেশনাল অ্যাডমিশন ওয়েবহুক) জন্য উপযুক্ত। Kubernetes সংস্করণ 1.7, 1.8 এর জন্য ইনিশিয়ালাইজার ব্যবহার করা সম্ভব।

সাইডকার কন্টেইনারগুলি GRPC প্রোটোকল ব্যবহার করে পাইলটের সাথে সংযোগ করে, যা আপনাকে ক্লাস্টারে ঘটতে থাকা পরিবর্তনগুলি পুশ করার জন্য মডেলটিকে অপ্টিমাইজ করতে দেয়৷ GRPC 1.6 সংস্করণ থেকে এনভয়-এ ব্যবহার করা শুরু হয়েছে, ইস্টিওতে এটি 0.8 সংস্করণ থেকে ব্যবহার করা হয়েছে এবং এটি একটি পাইলট-এজেন্ট - দূতের উপরে একটি গোলং র‍্যাপার যা লঞ্চ প্যারামিটারগুলি কনফিগার করে।

পাইলট এবং মিক্সার সম্পূর্ণরূপে রাষ্ট্রহীন উপাদান, সমস্ত রাষ্ট্র মেমরি রাখা হয়. তাদের জন্য কনফিগারেশন Kubernetes কাস্টম রিসোর্সেস আকারে সেট করা হয়েছে, যা etcd এ সংরক্ষিত আছে।
Istio-এজেন্ট পাইলট ঠিকানা গ্রহণ করে এবং এটিতে একটি GRPC স্ট্রীম খোলে।

যেমনটি আমি বলেছি, Istio সমস্ত কার্যকারিতা প্রয়োগ করে অ্যাপ্লিকেশনের জন্য সম্পূর্ণ স্বচ্ছ। চলুন চিন্তা করা যাক কিভাবে. অ্যালগরিদম এই মত:

1. আমরা পরিষেবাটির একটি নতুন সংস্করণ স্থাপন করব৷
2. কনটেইনারের সাইডকারে ইনজেকশন দেওয়ার পদ্ধতির উপর নির্ভর করে, কনফিগারেশন প্রয়োগের পর্যায়ে istio-init কন্টেইনার এবং istio-এজেন্ট কন্টেইনার (দূত) যোগ করা হয়, অথবা সেগুলি ইতিমধ্যেই Kubernetes সত্তার Pod বিবরণে ম্যানুয়ালি ঢোকানো যেতে পারে। .
3. istio-init কন্টেইনার হল একটি স্ক্রিপ্ট যা পডে iptables নিয়ম প্রয়োগ করে। ইস্টিও-এজেন্ট কন্টেইনারে ট্র্যাফিক মোড়ক সেট আপ করার জন্য দুটি বিকল্প রয়েছে: iptables পুনঃনির্দেশ নিয়ম ব্যবহার করুন, অথবা TPROXY. লেখার সময়, ডিফল্ট পদ্ধতিটি পুনঃনির্দেশিত নিয়মগুলির সাথে। Istio-init আপনাকে কনফিগার করতে দেয় যে কোন ধরণের ট্র্যাফিক আটকানো উচিত এবং istio-এজেন্টকে পাঠানো উচিত। উদাহরণস্বরূপ, সমস্ত আগত এবং সমস্ত বহির্গামী ট্র্যাফিককে বাধা দেওয়ার জন্য, আপনাকে পরামিতিগুলি সেট করতে হবে -i и -b অর্থে *. আপনি বাধা দিতে নির্দিষ্ট পোর্ট উল্লেখ করতে পারেন। একটি নির্দিষ্ট সাবনেটকে বাধা না দেওয়ার জন্য, আপনি পতাকা ব্যবহার করে এটি নির্দিষ্ট করতে পারেন -x.
4. init কন্টেইনারগুলি কার্যকর করার পরে, পাইলট-এজেন্ট (দূত) সহ প্রধানগুলি চালু করা হয়। এটি GRPC এর মাধ্যমে ইতিমধ্যেই নিয়োজিত পাইলটের সাথে সংযোগ করে এবং ক্লাস্টারে বিদ্যমান সমস্ত পরিষেবা এবং রাউটিং নীতি সম্পর্কে তথ্য পায়। প্রাপ্ত তথ্য অনুযায়ী, তিনি ক্লাস্টারগুলি কনফিগার করেন এবং কুবারনেটস ক্লাস্টারে আমাদের অ্যাপ্লিকেশনগুলির শেষ পয়েন্টগুলিতে সরাসরি বরাদ্দ করেন। এটি একটি গুরুত্বপূর্ণ বিষয় নোট করা প্রয়োজন: দূত গতিশীলভাবে শ্রোতাদের (আইপি, পোর্ট জোড়া) কনফিগার করে যা এটি শুনতে শুরু করে। অতএব, যখন অনুরোধগুলি পডে প্রবেশ করে এবং সাইডকারে পুনঃনির্দেশিত iptables নিয়মগুলি ব্যবহার করে পুনঃনির্দেশিত হয়, তখন দূত ইতিমধ্যেই সফলভাবে এই সংযোগগুলি প্রক্রিয়া করতে পারে এবং বুঝতে পারে যে ট্র্যাফিকের পরবর্তী কোথায় প্রক্সি করা দরকার৷ এছাড়াও এই পর্যায়ে, তথ্য মিক্সারে পাঠানো হয়, যা আমরা পরে দেখব এবং ট্রেসিং স্প্যানগুলি পাঠানো হয়।

ফলস্বরূপ, আমরা এনভয় প্রক্সি সার্ভারের একটি সম্পূর্ণ নেটওয়ার্ক পাই, যা আমরা একটি পয়েন্ট (পাইলট) থেকে কনফিগার করতে পারি। সমস্ত অন্তর্মুখী এবং বহির্মুখী অনুরোধ দূতের মাধ্যমে যায়। অধিকন্তু, শুধুমাত্র TCP ট্র্যাফিক বাধাপ্রাপ্ত হয়। এর মানে হল যে Kubernetes পরিষেবা IP পরিবর্তন না করেই UDP-এর উপর kube-dns ব্যবহার করে সমাধান করা হয়। তারপরে, রেজোলিউশনের পরে, বহির্গামী অনুরোধটি দূত দ্বারা আটকানো এবং প্রক্রিয়া করা হয়, যা সিদ্ধান্ত নেয় কোন শেষ বিন্দুতে অনুরোধ পাঠানো হবে (বা পাঠানো হবে না, অ্যাক্সেস নীতির ক্ষেত্রে বা সার্কিট ব্রেকার অ্যালগরিদম ট্রিগার করা হয়েছে)।

আমরা পাইলট বাছাই করেছি, এখন আমাদের বুঝতে হবে কিভাবে মিক্সার কাজ করে এবং কেন এটি প্রয়োজন। আপনি এটিতে অফিসিয়াল ডকুমেন্টেশন পড়তে পারেন এখানে.

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

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

সংক্ষেপে, istio-টেলিমেট্রির সাথে কাজ করার স্কিমটি নিম্নরূপ।

1. পরিষেবা 1 পরিষেবা 2-কে একটি অনুরোধ পাঠায়৷
2. পরিষেবা 1 ছেড়ে যাওয়ার সময়, অনুরোধটি নিজস্ব সাইডকারে মোড়ানো হয়।
3. সাইডকার দূত কীভাবে অনুরোধটি পরিষেবা 2-এ যায় তা পর্যবেক্ষণ করে এবং প্রয়োজনীয় তথ্য প্রস্তুত করে।
4. তারপর এটি রিপোর্ট অনুরোধ ব্যবহার করে istio-টেলিমেট্রিতে পাঠায়।
5. ইস্টিও-টেলিমেট্রি নির্ধারণ করে যে এই প্রতিবেদনটি ব্যাকএন্ডে পাঠানো দরকার, কোনটি এবং কোন ডেটা পাঠানো দরকার।
6. প্রয়োজনে ইস্টিও-টেলিমেট্রি ব্যাকএন্ডে রিপোর্ট ডেটা পাঠায়।

এখন দেখা যাক কিভাবে সিস্টেমে Istio স্থাপন করা যায়, শুধুমাত্র প্রধান উপাদান (পাইলট এবং সাইডকার দূত) সমন্বিত।

প্রথমে, প্রধান কনফিগারেশন (জাল) দেখি যা পাইলট পড়ে:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

আমরা কুবারনেটসের নেমস্পেস ইস্টিও-সিস্টেমের সমস্ত প্রধান নিয়ন্ত্রণ উপাদান রাখব।

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

এবং আমরা কন্টেইনারের ইনজেকশন সাইডকারটি ম্যানুয়ালি কনফিগার করব।

Init ধারক:

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

এবং সাইডকার:

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

সবকিছু সফলভাবে শুরু করার জন্য, আপনাকে পাইলটের জন্য একটি ServiceAccount, ClusterRole, ClusterRoleBinding, CRD তৈরি করতে হবে, যার বিবরণ পাওয়া যাবে এখানে.

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

এটা বোঝা গুরুত্বপূর্ণ যে সমস্ত কন্ট্রোল প্লেন উপাদান স্টেটলেস অ্যাপ্লিকেশন এবং সমস্যা ছাড়াই অনুভূমিকভাবে মাপানো যেতে পারে। Kubernetes সম্পদের কাস্টম বিবরণের আকারে etcd-এ সমস্ত ডেটা সংরক্ষণ করা হয়।

Istio এছাড়াও (এখনও পরীক্ষামূলক) একটি ক্লাস্টারের বাইরে চালানোর ক্ষমতা এবং বেশ কয়েকটি Kubernetes ক্লাস্টারের মধ্যে পরিষেবা আবিষ্কার দেখার এবং ভাগ করার ক্ষমতা রয়েছে। আপনি এই সম্পর্কে আরো পড়তে পারেন এখানে.

একটি মাল্টি-ক্লাস্টার ইনস্টলেশনের জন্য, নিম্নলিখিত সীমাবদ্ধতাগুলি বিবেচনা করুন:

1. পড সিআইডিআর এবং সার্ভিস সিআইডিআর অবশ্যই সমস্ত ক্লাস্টার জুড়ে অনন্য হতে হবে এবং ওভারল্যাপ করা উচিত নয়।
2. সমস্ত পড সিআইডিআর অবশ্যই ক্লাস্টারগুলির মধ্যে যে কোনও পড সিআইডিআর থেকে পৌঁছাতে হবে৷
3. সমস্ত Kubernetes API সার্ভার একে অপরের কাছে অ্যাক্সেসযোগ্য হতে হবে।

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

উত্স: www.habr.com