كيفية بدء Istio باستخدام Kubernetes في الإنتاج. الجزء الأول

ما هو استيو ؟ هذه هي شبكة الخدمة ، وهي تقنية تضيف طبقة من التجريد عبر الشبكة. نحن نعترض كل أو جزء من حركة المرور في الكتلة وننفذ مجموعة محددة من العمليات معها. أيهما؟ على سبيل المثال ، نقوم بالتوجيه الذكي ، أو نطبق نهج قاطع الدائرة ، يمكننا تنظيم "نشر الكناري" ، وتحويل حركة المرور جزئيًا إلى إصدار جديد من الخدمة ، ويمكننا تقييد التفاعلات الخارجية والتحكم في جميع الرحلات من المجموعة إلى الشبكة الخارجية. من الممكن وضع قواعد سياسة للتحكم في الحملات بين الخدمات الصغيرة المختلفة. أخيرًا ، يمكننا الحصول على خريطة التفاعل الكاملة عبر الشبكة وجعل المجموعة الموحدة من المقاييس شفافة تمامًا للتطبيقات.

حول آلية العمل يمكن العثور عليها في الوثائق الرسمية . Istio هي أداة قوية حقًا يمكنها حل العديد من المشكلات والمشكلات. في هذه المقالة ، أود أن أجيب على الأسئلة الأساسية التي تنشأ عادة في بداية العمل مع Istio. هذا سوف يساعدك على التعامل معها بشكل أسرع.



مبدأ العمل


تتكون Istio من منطقتين رئيسيتين - مستوى التحكم ومستوى البيانات. يحتوي مستوى التحكم على المكونات الرئيسية التي تضمن التشغيل الصحيح للباقي. في الإصدار الحالي (1.0) ، تحتوي طائرة التحكم على ثلاثة مكونات رئيسية: Pilot ، Mixer ، Citadel. لن ننظر في القلعة ، فمن الضروري إنشاء شهادات لضمان TLS المتبادل بين الخدمات. دعونا نلقي نظرة فاحصة على الجهاز والغرض من Pilot و Mixer.



Pilot هو عنصر التحكم الرئيسي الذي ينشر جميع المعلومات حول ما لدينا في المجموعة - الخدمات ونقاط النهاية وقواعد التوجيه (على سبيل المثال ، قواعد نشر Canary أو قواعد قاطع الدائرة).

Mixer - مكون اختياري لمستوى التحكم ، يوفر القدرة على جمع المقاييس والسجلات وأي معلومات حول تفاعلات الشبكة. كما يراقب الامتثال لقواعد السياسة والامتثال لحدود الأسعار.

يتم تنفيذ مستوى البيانات باستخدام حاويات الوكيل الجانبي. بشكل افتراضي ، يتم استخدام خادم الوكيل المبعوث القوي. يمكن استبداله بتنفيذ آخر ، على سبيل المثال nginx (nginmesh).

لكي يعمل Istio بشفافية تامة للتطبيقات ، هناك نظام حقن تلقائي. أحدث تطبيق مناسب لإصدارات Kubernetes 1.9+ (الرد التلقائي على الويب). بالنسبة لإصدارات Kubernetes 1.7 و 1.8 ، من الممكن استخدام المُهيئ.

ترتبط حاويات Sidecar بالطيار عبر بروتوكول GRPC ، والذي يسمح بتحسين نموذج دفع التغييرات التي تحدث في الكتلة. بدأ استخدام GRPC في Envoy منذ الإصدار 1.6 ، في Istio تم استخدامه منذ الإصدار 0.8 وهو وكيل تجريبي - غلاف على golang عبر المبعوث الذي يقوم بتكوين معلمات الإطلاق.

Pilot و Mixer هما مكوِنان عديمو الجنسية تمامًا ، ويتم الاحتفاظ بجميع الحالات في الذاكرة. يتم تحديد التكوين لها على أنها الموارد المخصصة Kubernetes ، والتي يتم حفظها في etcd.
يستلم وكيل Istio عنوان Pilot ويفتح تدفق GRPC إليه.

كما قلت ، تطبق Istio جميع الوظائف الشفافة تمامًا للتطبيقات. دعونا نكتشف كيف. الخوارزمية هي كما يلي:

  1. انشر نسخة جديدة من الخدمة.
  2. اعتمادًا على نهج حقن الحاوية الجانبية ، يتم إضافة حاوية istio-init وحاوية عامل istio (مبعوث) في مرحلة تطبيق التكوين ، أو يمكن إدراجها يدويًا في وصف Pod الخاص بكيان Kubernetes.
  3. حاوية istio-init عبارة عن برنامج نصي يطبق قواعد iptables للموقد. هناك خياران لإعداد التفاف حركة المرور في حاوية وكيل istio: استخدام قواعد iptables لإعادة التوجيه ، أو TPROXY . في وقت كتابة هذا التقرير ، يتم استخدام النهج الافتراضي مع قواعد إعادة التوجيه. في istio-init يمكن تكوين حركة المرور التي يجب اعتراضها وتوجيهها إلى وكيل istio. على سبيل المثال ، من أجل اعتراض كل حركة المرور الواردة والصادرة ، تحتاج إلى تعيين معلمات -i و -b على * . يمكنك تحديد منافذ معينة ليتم اعتراضها. لكي لا يتم اعتراض شبكة فرعية معينة ، يمكنك تحديدها باستخدام علامة -x .
  4. بعد تنفيذ حاويات التهيئة ، يتم إطلاق الحاويات الرئيسية ، بما في ذلك وكيل الطيار (المبعوث). يتصل الطيار الذي تم نشره بالفعل عبر GRPC ويتلقى معلومات حول جميع الخدمات وسياسات التوجيه الموجودة في المجموعة. وفقًا للبيانات المستلمة ، يقوم بتكوين المجموعات ويعينها مباشرةً نقاط النهاية لتطبيقاتنا في مجموعة Kubernetes. من الجدير بالذكر أيضًا نقطة مهمة: يقوم المبعوث بشكل حيوي بإعداد المستمعين (IP ، أزواج المنافذ) التي يبدأ الاستماع إليها. لذلك ، عندما تدخل الطلبات إلى pod ، تتم إعادة توجيهها باستخدام قواعد iptables لإعادة التوجيه في sidecar ، يمكن للمبعوث معالجة هذه الاتصالات بنجاح وفهم مكان حركة مرور الوكيل بشكل أكبر. أيضًا في هذه المرحلة ، يتم إرسال المعلومات إلى Mixer ، والتي سنناقشها لاحقًا ، وإرسال امتدادات التتبع.

ونتيجة لذلك ، نحصل على شبكة كاملة من الخوادم الوكيلة للمبعوثين ، والتي يمكننا تكوينها من نقطة واحدة (Pilot). تمر جميع الطلبات الواردة والصادرة من خلال المبعوث. علاوة على ذلك ، يتم اعتراض حركة مرور TCP فقط. وهذا يعني أن عنوان IP لخدمة Kubernetes يحل باستخدام kube-dns عبر UDP دون تغيير. بعد ذلك ، بعد الحل ، يتم اعتراض الطلب الصادر ومعالجته بواسطة المبعوث ، والذي يقرر بالفعل نقطة النهاية التي سيتم إرسال الطلب إليها (أو لا ، في حالة سياسات الوصول أو تشغيل خوارزميات قاطع الدائرة).

مع ترتيب Pilot ، تحتاج الآن إلى فهم كيفية عمل الخلاط وسبب حاجته. يمكنك قراءة الوثائق الرسمية الموجودة هنا .

يتكون الخلاط في شكله الحالي من مكونين: القياس عن بُعد ، سياسة السياسة (قبل الإصدار 0.8 كان مكونًا واحدًا من الخلاط المتساوي). كلاهما عبارة عن خلاط ، كل منهما مسؤول عن مهمته. يستقبل القياس عن بُعد Istio عبر GRPC من حاويات التقرير الجانبي معلومات حول من يذهب إلى أين وبأي معلمات. يقبل Istio-policy التحقق من الطلبات للتحقق مما إذا كانت قواعد السياسة مستوفاة. يتم إجراء اختبارات Poilicy ، بالطبع ، ليس لكل طلب ، ولكن يتم تخزينها مؤقتًا على العميل (في السيارة الجانبية) لفترة معينة. يتم إرسال تدقيق التقرير عن طريق الطلبات المجمعة. سنرى بعد ذلك بقليل كيفية التكوين والمعلمات التي تحتاج إلى إرسالها.

من المفترض أن يكون Mixer مكونًا متاحًا للغاية يوفر عملًا غير متقطع على جمع بيانات القياس عن بُعد ومعالجتها. يتحول النظام إلى مخزن مؤقت متعدد المستويات. في البداية ، يتم تخزين البيانات مؤقتًا على الجانب الجانبي للحاويات ، ثم على جانب الخلاط ثم إرسالها إلى ما يسمى بخلاطات الخلاط. ونتيجة لذلك ، في حالة فشل أي من مكونات النظام ، ينمو المخزن المؤقت ويتعطل بعد استرداد النظام. تعد واجهات المزج الخلفية نقاط النهاية لإرسال بيانات القياس عن بُعد: statsd و newrelic وما إلى ذلك. يمكنك كتابة الواجهة الخلفية ، إنها بسيطة للغاية ، وسنرى كيفية القيام بذلك.



للتلخيص ، فإن مخطط العمل مع القياس عن بعد هو على النحو التالي.

  1. ترسل الخدمة 1 طلبًا للخدمة 2.
  2. عند مغادرة الخدمة 1 ، يتم تغليف الطلب في جانبها الجانبي.
  3. يراقب مبعوث Sidecar كيفية تمرير طلب الخدمة 2 وإعداد المعلومات اللازمة.
  4. ثم يرسلها إلى القياس عن بعد باستخدام طلب التقرير.
  5. يحدد نظام Istio-telemetry ما إذا كان سيتم إرسال هذا التقرير إلى الخلفية ، وإلى أي البيانات وأي بيانات سيتم إرسالها.
  6. يرسل Istio-telemetry بيانات التقرير إلى الواجهة الخلفية إذا لزم الأمر.

الآن دعونا نرى كيفية الانتشار في نظام Istio ، الذي يتكون فقط من المكونات الرئيسية (الطيار والمبعوث الجانبي).

أولاً ، دعنا نلقي نظرة على التكوين الرئيسي (الشبكة) الذي يقرأه Pilot:

 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 

توجد جميع مكونات مستوى التحكم الرئيسية في مساحة الاسم في نظام Kubernetes.

الحد الأدنى الذي نحتاجه لنشر Pilot فقط. للقيام بذلك ، سوف نستخدم هذا التكوين.

وقم بتكوين الحاوية الجانبية للحقن يدوياً.

الحاوية الأولية:

 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 for Pilot ، ويمكن العثور على أوصاف لها هنا .

ونتيجة لذلك ، يجب أن تبدأ الخدمة التي نقوم فيها بحقن السيارة الجانبية بمبعوث بنجاح ، والحصول على كل الاكتشافات من الطيار ومعالجة الطلبات.

من المهم أن نفهم أن جميع مكونات مستوى التحكم هي تطبيقات عديمة الحالة ويمكن تحجيمها أفقيًا دون أي مشاكل. جميع البيانات موجودة في etcd كأوصاف مخصصة لموارد Kubernetes.

Istio أيضًا (حتى الآن تجريبيًا) لديه القدرة على الركض خارج المجموعة والقدرة على المشاهدة والتلعثم لاكتشاف الخدمة بين العديد من مجموعات Kubernetes. يمكنك قراءة المزيد عن هذا هنا .

بالنسبة للتركيب متعدد الكتل ، يجب مراعاة القيود التالية:

  1. يجب أن يكون Pod CIDR و Service CIDR فريدًا عبر كل المجموعات ويجب ألا يتداخل.
  2. يجب أن تكون جميع CIDRs Pod متاحة من أي CIDRs Pod بين المجموعات.
  3. يجب أن تكون جميع خوادم Kubernetes API متاحة لبعضها البعض.

هذه هي المعلومات الأولية لمساعدتك على بدء استخدام Istio. ومع ذلك ، لا يزال هناك العديد من المزالق. على سبيل المثال ، ميزات توجيه حركة المرور الخارجية (إلى خارج المجموعة) ، ومناهج تصحيح الأخطاء الجانبية ، وتحديد الملفات ، وإعداد خلاط وكتابة خلفية خالط مخصصة ، وإنشاء آلية تتبع وتشغيلها باستخدام المبعوث.
سننظر في كل هذا في المنشورات التالية. اطرح أسئلتك ، سأحاول تغطيتها.

Source: https://habr.com/ru/post/ar419319/


All Articles