उत्पादन में कुबेरनेट्स का उपयोग करके इस्तियो को कैसे चलाएं। भाग ---- पहला

क्या है Istio? यह तथाकथित सर्विस मेश है, एक ऐसी तकनीक जो नेटवर्क पर अमूर्तता की एक परत जोड़ती है। हम क्लस्टर में ट्रैफ़िक के सभी या कुछ हिस्से को रोकते हैं और इसके साथ संचालन का एक निश्चित सेट निष्पादित करते हैं। कौन-सा? उदाहरण के लिए, हम स्मार्ट रूटिंग करते हैं, या हम सर्किट ब्रेकर दृष्टिकोण लागू करते हैं, हम "कैनरी परिनियोजन" व्यवस्थित कर सकते हैं, आंशिक रूप से ट्रैफ़िक को सेवा के नए संस्करण में स्विच कर सकते हैं, या हम बाहरी इंटरैक्शन को सीमित कर सकते हैं और क्लस्टर से सभी यात्राओं को नियंत्रित कर सकते हैं बाहरी नेटवर्क. विभिन्न माइक्रोसर्विसेज के बीच यात्राओं को नियंत्रित करने के लिए नीति नियम निर्धारित करना संभव है। अंत में, हम संपूर्ण नेटवर्क इंटरैक्शन मैप प्राप्त कर सकते हैं और मेट्रिक्स के एकीकृत संग्रह को अनुप्रयोगों के लिए पूरी तरह से पारदर्शी बना सकते हैं।

आप कार्य के तंत्र के बारे में पढ़ सकते हैं आधिकारिक दस्तावेज. इस्तियो वास्तव में एक शक्तिशाली उपकरण है जो आपको कई कार्यों और समस्याओं को हल करने की अनुमति देता है। इस लेख में, मैं उन मुख्य प्रश्नों का उत्तर देना चाहूंगा जो आमतौर पर इस्तियो के साथ शुरुआत करते समय उठते हैं। इससे आपको इससे तेजी से निपटने में मदद मिलेगी.

आपरेशन के सिद्धांत

इस्तियो में दो मुख्य क्षेत्र होते हैं - नियंत्रण तल और डेटा तल। नियंत्रण विमान में मुख्य घटक होते हैं जो बाकी हिस्सों के सही संचालन को सुनिश्चित करते हैं। वर्तमान संस्करण (1.0) में नियंत्रण विमान के तीन मुख्य घटक हैं: पायलट, मिक्सर, सिटाडेल। हम सिटाडेल पर विचार नहीं करेंगे, सेवाओं के बीच पारस्परिक टीएलएस सुनिश्चित करने के लिए प्रमाणपत्र तैयार करना आवश्यक है। आइए पायलट और मिक्सर के उपकरण और उद्देश्य पर करीब से नज़र डालें।

पायलट मुख्य नियंत्रण घटक है जो क्लस्टर में हमारे पास जो कुछ भी है उसके बारे में सारी जानकारी वितरित करता है - सेवाएं, उनके समापन बिंदु और रूटिंग नियम (उदाहरण के लिए, कैनरी परिनियोजन के नियम या सर्किट ब्रेकर नियम)।

मिक्सर एक वैकल्पिक नियंत्रण विमान घटक है जो मेट्रिक्स, लॉग और नेटवर्क इंटरैक्शन के बारे में कोई भी जानकारी एकत्र करने की क्षमता प्रदान करता है। वह नीति नियमों के अनुपालन और दर सीमाओं के अनुपालन की भी निगरानी करता है।

डेटा प्लेन को साइडकार प्रॉक्सी कंटेनरों का उपयोग करके कार्यान्वित किया जाता है। डिफ़ॉल्ट रूप से शक्तिशाली का उपयोग किया जाता है। दूत प्रॉक्सी. इसे किसी अन्य कार्यान्वयन, जैसे nginx (nginmesh) द्वारा प्रतिस्थापित किया जा सकता है।

इस्तियो को अनुप्रयोगों के लिए पूरी तरह से पारदर्शी तरीके से काम करने के लिए, एक स्वचालित इंजेक्शन प्रणाली है। नवीनतम कार्यान्वयन कुबेरनेट्स 1.9+ संस्करण (म्यूटेशनल एडमिशन वेबहुक) के लिए उपयुक्त है। कुबेरनेट्स संस्करण 1.7, 1.8 के लिए इनिशियलाइज़र का उपयोग करना संभव है।

साइडकार कंटेनर जीआरपीसी प्रोटोकॉल का उपयोग करके पायलट से जुड़े होते हैं, जो आपको क्लस्टर में होने वाले परिवर्तनों के लिए पुश मॉडल को अनुकूलित करने की अनुमति देता है। GRPC का उपयोग एन्वॉय में संस्करण 1.6 से किया जा रहा है, इस्तियो में इसका उपयोग संस्करण 0.8 से किया जा रहा है और यह एक पायलट-एजेंट है - एन्वॉय पर एक गोलांग रैपर जो लॉन्च विकल्पों को कॉन्फ़िगर करता है।

पायलट और मिक्सर पूरी तरह से स्टेटलेस घटक हैं, सभी स्टेट को मेमोरी में रखा जाता है। उनके लिए कॉन्फ़िगरेशन कुबेरनेट्स कस्टम रिसोर्सेज के रूप में सेट किया गया है, जो आदि में संग्रहीत हैं।
इस्तियो-एजेंट को पायलट का पता मिलता है और वह उसके लिए एक GRPC स्ट्रीम खोलता है।

जैसा कि मैंने कहा, इस्तियो अनुप्रयोगों के लिए पूरी तरह से पारदर्शी सभी कार्यक्षमता लागू करता है। आइए देखें कैसे. एल्गोरिथ्म यह है:

1. सेवा का एक नया संस्करण परिनियोजित करना.
2. साइडकार कंटेनर इंजेक्शनिंग दृष्टिकोण के आधार पर, इस्तियो-इनिट कंटेनर और इस्तियो-एजेंट कंटेनर (दूत) को कॉन्फ़िगरेशन लागू करने के चरण में जोड़ा जाता है, या उन्हें पहले से ही कुबेरनेट्स पॉड इकाई के विवरण में मैन्युअल रूप से डाला जा सकता है।
3. Istio-init कंटेनर एक स्क्रिप्ट है जो पॉड पर iptables नियम लागू करती है। ट्रैफ़िक को इस्तियो-एजेंट कंटेनर में लपेटने के लिए कॉन्फ़िगर करने के लिए दो विकल्प हैं: iptables रीडायरेक्ट नियमों का उपयोग करें, या TPROXY. लेखन के समय, डिफ़ॉल्ट दृष्टिकोण रीडायरेक्ट नियमों के साथ है। Istio-init में, यह कॉन्फ़िगर करना संभव है कि कौन से ट्रैफ़िक को रोका जाना चाहिए और istio-agent को भेजा जाना चाहिए। उदाहरण के लिए, आने वाले और बाहर जाने वाले सभी ट्रैफ़िक को रोकने के लिए, आपको पैरामीटर सेट करने की आवश्यकता है -i и -b अर्थ में *. आप इंटरसेप्ट करने के लिए विशिष्ट पोर्ट निर्दिष्ट कर सकते हैं। किसी विशिष्ट सबनेट को बाधित न करने के लिए, आप इसे ध्वज का उपयोग करके निर्दिष्ट कर सकते हैं -x.
4. इनिट कंटेनरों के निष्पादित होने के बाद, पायलट-एजेंट (दूत) सहित मुख्य कंटेनरों को लॉन्च किया जाता है। यह GRPC के माध्यम से पहले से ही तैनात पायलट से जुड़ता है और क्लस्टर में सभी मौजूदा सेवाओं और रूटिंग नीतियों के बारे में जानकारी प्राप्त करता है। प्राप्त आंकड़ों के अनुसार, वह क्लस्टर को कॉन्फ़िगर करता है और उन्हें सीधे कुबेरनेट्स क्लस्टर में हमारे अनुप्रयोगों के अंतिम बिंदुओं पर असाइन करता है। एक महत्वपूर्ण बिंदु पर ध्यान देना भी आवश्यक है: दूत गतिशील रूप से श्रोताओं (आईपी, पोर्ट जोड़े) को कॉन्फ़िगर करता है जिसे वह सुनना शुरू करता है। इसलिए, जब अनुरोध पॉड में प्रवेश करते हैं, तो साइडकार में रीडायरेक्ट आईपीटेबल्स नियमों का उपयोग करके रीडायरेक्ट किया जाता है, दूत पहले से ही इन कनेक्शनों को सफलतापूर्वक संसाधित कर सकता है और समझ सकता है कि ट्रैफ़िक को आगे कहां प्रॉक्सी करना है। साथ ही इस स्तर पर, जानकारी मिक्सर को भेजी जाती है, जिसे हम बाद में देखेंगे, और ट्रेसिंग स्पैन भेजे जाते हैं।

परिणामस्वरूप, हमें दूत प्रॉक्सी सर्वर का एक पूरा नेटवर्क मिलता है जिसे हम एक बिंदु (पायलट) से कॉन्फ़िगर कर सकते हैं। सभी आवक और जावक अनुरोध दूत के माध्यम से जाते हैं। इसके अलावा, केवल टीसीपी ट्रैफिक को रोका जाता है। इसका मतलब यह है कि कुबेरनेट्स सेवा आईपी को बिना बदले यूडीपी पर क्यूब-डीएनएस का उपयोग करके हल किया जाता है। फिर, समाधान के बाद, आउटगोइंग अनुरोध को इंटरसेप्ट किया जाता है और दूत द्वारा संसाधित किया जाता है, जो पहले से ही तय करता है कि अनुरोध किस एंडपॉइंट पर भेजा जाना चाहिए (या एक्सेस नीतियों या एल्गोरिदम के सर्किट ब्रेकर के मामले में नहीं भेजा जाना चाहिए)।

हमने पायलट का पता लगा लिया, अब हमें यह समझने की जरूरत है कि मिक्सर कैसे काम करता है और इसकी आवश्यकता क्यों है। आप इसके लिए आधिकारिक दस्तावेज़ पढ़ सकते हैं यहां.

अपने वर्तमान स्वरूप में मिक्सर में दो घटक होते हैं: इस्तियो-टेलीमेट्री, इस्तियो-पॉलिसी (संस्करण 0.8 से पहले यह एक इस्तियो-मिक्सर घटक था)। ये दोनों मिक्सर हैं, जिनमें से प्रत्येक अपने स्वयं के कार्य के लिए जिम्मेदार है। इस्तियो टेलीमेट्री जीआरपीसी के माध्यम से साइडकार रिपोर्ट कंटेनरों से इस बारे में जानकारी प्राप्त करती है कि कौन कहां और किन मापदंडों के साथ जाता है। इस्तियो-पॉलिसी यह सत्यापित करने के लिए चेक अनुरोध स्वीकार करती है कि पॉलिसी नियम संतुष्ट हैं। बेशक, हर अनुरोध के लिए पॉलिसी जांच नहीं की जाती है, लेकिन एक निश्चित समय के लिए क्लाइंट पर (साइडकार में) कैश किया जाता है। रिपोर्ट जाँचें बैच अनुरोध के रूप में भेजी जाती हैं। आइए देखें कि कैसे कॉन्फ़िगर करें और कौन से पैरामीटर थोड़ी देर बाद भेजे जाने चाहिए।

मिक्सर को एक अत्यधिक उपलब्ध घटक माना जाता है जो टेलीमेट्री डेटा के संयोजन और प्रसंस्करण पर निर्बाध कार्य सुनिश्चित करता है। परिणामस्वरूप सिस्टम को बहु-स्तरीय बफर के रूप में प्राप्त किया जाता है। प्रारंभ में, डेटा को कंटेनरों के साइडकार साइड पर बफर किया जाता है, फिर मिक्सर साइड पर, और फिर तथाकथित मिक्सर बैकएंड पर भेजा जाता है। परिणामस्वरूप, यदि कोई सिस्टम घटक विफल हो जाता है, तो बफर बढ़ता है और सिस्टम बहाल होने के बाद फ्लश हो जाता है। मिक्सर बैकएंड टेलीमेट्री डेटा भेजने के लिए अंतिम बिंदु हैं: स्टेट्सडी, न्यूरेलिक, आदि। आप अपना स्वयं का बैकएंड लिख सकते हैं, यह काफी सरल है, और हम देखेंगे कि इसे कैसे करना है।

संक्षेप में, इस्तियो-टेलीमेट्री के साथ काम करने की योजना इस प्रकार है।

1. सेवा 1 सेवा 2 को अनुरोध भेजती है।
2. सेवा 1 छोड़ते समय, अनुरोध को उसके अपने साइडकार में लपेट दिया जाता है।
3. साइडकार दूत निगरानी करता है कि अनुरोध सेवा 2 तक कैसे जाता है और आवश्यक जानकारी तैयार करता है।
4. फिर रिपोर्ट अनुरोध का उपयोग करके इसे इस्तियो-टेलीमेट्री को भेजता है।
5. इस्तियो-टेलीमेट्री यह निर्धारित करती है कि क्या यह रिपोर्ट बैकएंड पर भेजी जानी चाहिए, किसे और कौन सा डेटा भेजा जाना चाहिए।
6. जरूरत पड़ने पर इस्तियो-टेलीमेट्री रिपोर्ट डेटा को बैकएंड पर भेजता है।

अब आइए देखें कि सिस्टम में इस्तियो को कैसे तैनात किया जाए, जिसमें केवल मुख्य घटक (पायलट और साइडकार दूत) शामिल हों।

सबसे पहले, आइए पायलट द्वारा पढ़े जाने वाले मुख्य कॉन्फ़िगरेशन (मेष) को देखें:

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

सभी मुख्य नियंत्रण घटक (नियंत्रण विमान) कुबेरनेट्स में नेमस्पेस इस्तियो-सिस्टम में स्थित होंगे।

कम से कम, हमें केवल पायलट तैनात करने की आवश्यकता है। इसके लिए हम प्रयोग करते हैं ऐसा विन्यास.

और हम कंटेनर के इंजेक्शनिंग साइडकार को मैन्युअल रूप से कॉन्फ़िगर करेंगे।

इनिट कंटेनर:

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 बनाने की आवश्यकता है, जिसका विवरण पाया जा सकता है यहां.

परिणामस्वरूप, जिस सेवा में हम दूत के साथ साइडकार इंजेक्ट करते हैं उसे सफलतापूर्वक शुरू करना चाहिए, पायलट से सभी खोज प्राप्त करनी चाहिए और अनुरोधों को संसाधित करना चाहिए।

यह समझना महत्वपूर्ण है कि सभी नियंत्रण विमान घटक स्टेटलेस अनुप्रयोग हैं और इन्हें बिना किसी समस्या के क्षैतिज रूप से बढ़ाया जा सकता है। सभी डेटा को कुबेरनेट्स संसाधनों के कस्टम विवरण के रूप में आदि में संग्रहीत किया जाता है।

इसके अलावा, इस्तियो (अभी भी प्रयोगात्मक) में क्लस्टर के बाहर चलने की क्षमता है और कई कुबेरनेट क्लस्टर के बीच सेवा खोज को देखने और गड़बड़ी करने की क्षमता है। आप इसके बारे में और अधिक पढ़ सकते हैं यहां.

मल्टी-क्लस्टर इंस्टालेशन के लिए, निम्नलिखित सीमाओं से अवगत रहें:

1. पॉड सीआईडीआर और सर्विस सीआईडीआर सभी समूहों में अद्वितीय होने चाहिए और ओवरलैप नहीं होने चाहिए।
2. सभी सीआईडीआर पॉड्स को क्लस्टरों के बीच किसी भी सीआईडीआर पॉड्स से एक्सेस किया जाना चाहिए।
3. सभी कुबेरनेट्स एपीआई सर्वर एक दूसरे के लिए सुलभ होने चाहिए।

इस्तियो के साथ आरंभ करने में आपकी सहायता के लिए यह प्रारंभिक जानकारी है। हालाँकि, अभी भी कई ख़तरे हैं। उदाहरण के लिए, बाहरी ट्रैफ़िक (क्लस्टर के बाहर) को रूट करने की विशेषताएं, साइडकार को डिबग करने के तरीके, प्रोफाइलिंग, एक मिक्सर स्थापित करना और एक कस्टम मिक्सर बैकएंड लिखना, एक ट्रेसिंग तंत्र स्थापित करना और दूत का उपयोग करके इसका संचालन करना।
यह सब हम निम्नलिखित प्रकाशनों में विचार करेंगे। अपने प्रश्न पूछें, मैं उन्हें कवर करने का प्रयास करूंगा।

स्रोत: www.habr.com