उत्पादनात कुबर्नेट्स वापरून इस्टिओ कसा चालवायचा. भाग 1

काय इस्टिओ? हे तथाकथित सेवा जाळी आहे, एक तंत्रज्ञान जे नेटवर्कवर अमूर्ततेचा एक स्तर जोडते. आम्‍ही क्लस्‍टरमध्‍ये ट्रॅफिकचा सर्व किंवा काही भाग रोखतो आणि त्‍याच्‍या सहाय्याने विशिष्‍ट ऑपरेशन्स करतो. कोणता? उदाहरणार्थ, आम्ही स्मार्ट राउटिंग करतो, किंवा आम्ही सर्किट ब्रेकर पध्दत लागू करतो, आम्ही "कॅनरी डिप्लॉयमेंट" आयोजित करू शकतो, ट्रॅफिक अंशतः सेवेच्या नवीन आवृत्तीवर स्विच करू शकतो किंवा आम्ही बाह्य परस्परसंवाद मर्यादित करू शकतो आणि क्लस्टरपासून ते सर्व ट्रिप नियंत्रित करू शकतो. बाह्य नेटवर्क. विविध सूक्ष्म सेवांमधील ट्रिप नियंत्रित करण्यासाठी धोरण नियम सेट करणे शक्य आहे. शेवटी, आम्ही संपूर्ण नेटवर्क परस्परसंवाद नकाशा मिळवू शकतो आणि मेट्रिक्सचा एकत्रित संग्रह अनुप्रयोगांसाठी पूर्णपणे पारदर्शक बनवू शकतो.

मध्ये कामाच्या यंत्रणेबद्दल वाचू शकता अधिकृत दस्तऐवजीकरण. Istio हे खरोखर शक्तिशाली साधन आहे जे तुम्हाला अनेक कार्ये आणि समस्या सोडविण्यास अनुमती देते. या लेखात, मला Istio सह प्रारंभ करताना सामान्यतः उद्भवणार्या मुख्य प्रश्नांची उत्तरे द्यायची आहेत. हे आपल्याला जलद हाताळण्यास मदत करेल.

हे कसे कार्य करते

Istio मध्ये दोन मुख्य क्षेत्रे असतात - कंट्रोल प्लेन आणि डेटा प्लेन. कंट्रोल प्लेनमध्ये मुख्य घटक असतात जे बाकीचे योग्य ऑपरेशन सुनिश्चित करतात. सध्याच्या आवृत्तीत (1.0) कंट्रोल प्लेनमध्ये तीन मुख्य घटक आहेत: पायलट, मिक्सर, सिटाडेल. आम्ही सिटाडेलचा विचार करणार नाही, सेवांमध्ये परस्पर TLS सुनिश्चित करण्यासाठी प्रमाणपत्रे व्युत्पन्न करणे आवश्यक आहे. चला पायलट आणि मिक्सरचे डिव्हाइस आणि हेतू जवळून पाहू.

पायलट हा मुख्य नियंत्रण घटक आहे जो क्लस्टरमध्ये आमच्याकडे काय आहे याबद्दल सर्व माहिती वितरीत करतो - सेवा, त्यांचे एंडपॉइंट आणि रूटिंग नियम (उदाहरणार्थ, कॅनरी डिप्लॉयमेंटचे नियम किंवा सर्किट ब्रेकर नियम).

मिक्सर हा एक पर्यायी कंट्रोल प्लेन घटक आहे जो मेट्रिक्स, लॉग आणि नेटवर्क परस्परसंवादाबद्दल कोणतीही माहिती गोळा करण्याची क्षमता प्रदान करतो. ते धोरण नियमांचे पालन आणि दर मर्यादेचे पालन यावरही देखरेख ठेवतात.

साइडकार प्रॉक्सी कंटेनर वापरून डेटा प्लेन लागू केला जातो. पॉवरफुल बाय डीफॉल्ट वापरला जातो. दूत प्रॉक्सी. हे दुसर्या अंमलबजावणीद्वारे बदलले जाऊ शकते, जसे की nginx (nginmesh).

Istio अनुप्रयोगांसाठी पूर्णपणे पारदर्शकपणे कार्य करण्यासाठी, एक स्वयंचलित इंजेक्शन प्रणाली आहे. नवीनतम अंमलबजावणी Kubernetes 1.9+ आवृत्त्यांसाठी (म्युटेशनल अॅडमिशन वेबहुक) योग्य आहे. Kubernetes आवृत्ती 1.7, 1.8 साठी इनिशियलाइजर वापरणे शक्य आहे.

साइडकार कंटेनर GRPC प्रोटोकॉल वापरून पायलटशी जोडलेले आहेत, जे तुम्हाला क्लस्टरमध्ये होणाऱ्या बदलांसाठी पुश मॉडेल ऑप्टिमाइझ करण्याची परवानगी देते. GRPC दूतामध्ये आवृत्ती 1.6 पासून वापरली जात आहे, Istio मध्ये ती आवृत्ती 0.8 पासून वापरली जात आहे आणि एक पायलट-एजंट आहे - लाँच पर्याय कॉन्फिगर करणारा दूतावर गोलांग रॅपर आहे.

पायलट आणि मिक्सर पूर्णपणे स्टेटलेस घटक आहेत, सर्व स्थिती मेमरीमध्ये ठेवली जाते. त्यांच्यासाठी कॉन्फिगरेशन Kubernetes कस्टम रिसोर्सेसच्या स्वरूपात सेट केले आहे, जे etcd मध्ये संग्रहित आहेत.
Istio-एजंटला पायलटचा पत्ता मिळतो आणि त्यावर GRPC प्रवाह उघडतो.

मी म्हटल्याप्रमाणे, Istio अनुप्रयोगांसाठी सर्व कार्यक्षमता पूर्णपणे पारदर्शकपणे लागू करते. कसे ते पाहू. अल्गोरिदम हे आहे:

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

परिणामी, आम्हाला दूत प्रॉक्सी सर्व्हरचे संपूर्ण नेटवर्क मिळते जे आम्ही एका बिंदूपासून (पायलट) कॉन्फिगर करू शकतो. सर्व इनबाउंड आणि आउटबाउंड विनंत्या दूताद्वारे जातात. शिवाय, फक्त TCP वाहतूक रोखली जाते. याचा अर्थ असा की Kubernetes सेवा IP बदलल्याशिवाय UDP वर kube-dns वापरून सोडवला जातो. नंतर, निराकरणानंतर, बाहेर जाणारी विनंती दूताद्वारे रोखली जाते आणि त्यावर प्रक्रिया केली जाते, जे आधीच ठरवते की विनंती कोणत्या एंडपॉईंटला पाठवायची (किंवा पाठविली जाऊ नये, ऍक्सेस पॉलिसी किंवा अल्गोरिदमच्या सर्किट ब्रेकरच्या बाबतीत).

आम्ही पायलट शोधून काढले, आता आम्हाला मिक्सर कसे कार्य करते आणि ते का आवश्यक आहे हे समजून घेणे आवश्यक आहे. त्यासाठी तुम्ही अधिकृत कागदपत्रे वाचू शकता येथे.

सध्याच्या स्वरूपात मिक्सरमध्ये दोन घटक असतात: istio-telemetry, istio-policy (आवृत्ती 0.8 पूर्वी हा एक istio-मिक्सर घटक होता). ते दोघेही मिक्सर आहेत, ज्यापैकी प्रत्येकजण स्वतःच्या कार्यासाठी जबाबदार आहे. Istio टेलीमेट्री GRPC द्वारे साइडकार रिपोर्ट कंटेनर्समधून कोण कुठे आणि कोणत्या पॅरामीटर्ससह जाते याबद्दल माहिती प्राप्त करते. Istio-policy पॉलिसी नियम समाधानी आहेत हे सत्यापित करण्यासाठी विनंत्या तपासा स्वीकारते. पॉलिसी चेक अर्थातच, प्रत्येक विनंतीसाठी केले जात नाहीत, परंतु क्लायंटवर (साइडकारमध्ये) विशिष्ट वेळेसाठी कॅश केले जातात. अहवाल धनादेश बॅच विनंत्या म्हणून पाठवले जातात. कॉन्फिगर कसे करायचे आणि कोणते पॅरामीटर्स थोड्या वेळाने पाठवायचे ते पाहू.

मिक्सर हा एक अत्यंत उपलब्ध घटक मानला जातो जो टेलीमेट्री डेटाच्या असेंब्ली आणि प्रोसेसिंगचे अखंड काम सुनिश्चित करतो. मल्टी-लेव्हल बफर म्हणून सिस्टीम परिणामी प्राप्त होते. सुरुवातीला, डेटा कंटेनरच्या साइडकार बाजूला बफर केला जातो, नंतर मिक्सरच्या बाजूला, आणि नंतर तथाकथित मिक्सर बॅकएंडवर पाठविला जातो. परिणामी, सिस्टमचे कोणतेही घटक अयशस्वी झाल्यास, बफर वाढतो आणि सिस्टम पुनर्संचयित केल्यानंतर फ्लश केला जातो. मिक्सर बॅकएंड हे टेलीमेट्री डेटा पाठवण्याचे अंतिम बिंदू आहेत: statsd, newrelic, इ. तुम्ही तुमचा स्वतःचा बॅकएंड लिहू शकता, हे अगदी सोपे आहे आणि ते कसे करायचे ते आम्ही पाहू.

थोडक्यात, इस्टिओ-टेलिमेट्रीसह कार्य करण्याची योजना खालीलप्रमाणे आहे.

1. सेवा 1 सेवा 2 ला विनंती पाठवते.
2. सेवा 1 सोडताना, विनंती स्वतःच्या साइडकारमध्ये गुंडाळली जाते.
3. साइडकार दूत विनंती सेवे 2 कडे कशी जाते याचे निरीक्षण करतो आणि आवश्यक माहिती तयार करतो.
4. नंतर अहवाल विनंती वापरून ते istio-telemetry वर पाठवते.
5. हा अहवाल बॅकएंडला पाठवायचा की नाही, कोणता आणि कोणता डेटा पाठवायचा हे इस्टिओ-टेलिमेट्री ठरवते.
6. Istio-telemetry आवश्यक असल्यास बॅकएंडला अहवाल डेटा पाठवते.

आता फक्त मुख्य घटक (पायलट आणि साइडकार दूत) असलेल्या सिस्टीममध्ये 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

सर्व मुख्य नियंत्रण घटक (कंट्रोल प्लेन) Kubernetes मधील नेमस्पेस istio-system मध्ये स्थित असतील.

कमीतकमी, आम्हाला फक्त पायलट तैनात करणे आवश्यक आहे. यासाठी आपण वापरणार आहोत असे कॉन्फिगरेशन.

आणि आम्ही कंटेनरचे इंजेक्शन साइडकार व्यक्तिचलितपणे कॉन्फिगर करू.

इनिट कंटेनर:

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

सर्वकाही यशस्वीरित्या सुरू होण्यासाठी, तुम्हाला पायलटसाठी सर्व्हिस खाते, क्लस्टररोल, क्लस्टररोलबाइंडिंग, सीआरडी तयार करणे आवश्यक आहे, ज्याचे वर्णन आढळू शकते. येथे.

परिणामी, आम्ही ज्या सेवेमध्ये दूतासह साइडकार इंजेक्ट करतो ती यशस्वीपणे सुरू व्हायला हवी, पायलटकडून सर्व शोध आणि प्रक्रिया विनंत्या प्राप्त झाल्या पाहिजेत.

हे समजून घेणे महत्त्वाचे आहे की सर्व कंट्रोल प्लेन घटक स्टेटलेस ऍप्लिकेशन्स आहेत आणि समस्यांशिवाय क्षैतिजरित्या मोजले जाऊ शकतात. सर्व डेटा कुबरनेट संसाधनांच्या सानुकूल वर्णनाच्या स्वरूपात etcd मध्ये संग्रहित केला जातो.

तसेच, Istio (अद्याप प्रायोगिक) मध्ये क्लस्टरच्या बाहेर धावण्याची क्षमता आहे आणि अनेक कुबर्नेट्स क्लस्टर्समध्ये सेवा शोध पाहण्याची आणि फंबल करण्याची क्षमता आहे. आपण याबद्दल अधिक वाचू शकता येथे.

मल्टी-क्लस्टर इन्स्टॉलेशनसाठी, खालील मर्यादांची जाणीव ठेवा:

1. पॉड सीआयडीआर आणि सर्व्हिस सीआयडीआर सर्व क्लस्टर्समध्ये अद्वितीय असणे आवश्यक आहे आणि ते ओव्हरलॅप होऊ नये.
2. सर्व CIDR पॉड्स क्लस्टर्समधील कोणत्याही CIDR पॉड्समधून प्रवेश करण्यायोग्य असले पाहिजेत.
3. सर्व Kubernetes API सर्व्हर एकमेकांना प्रवेश करण्यायोग्य असणे आवश्यक आहे.

Istio सह प्रारंभ करण्यास मदत करण्यासाठी ही प्रारंभिक माहिती आहे. तथापि, अजूनही अनेक तोटे आहेत. उदाहरणार्थ, बाह्य रहदारी (क्लस्टरच्या बाहेर) राउटिंगची वैशिष्ट्ये, साइडकार डीबग करण्यासाठी दृष्टीकोन, प्रोफाइलिंग, मिक्सर सेट करणे आणि कस्टम मिक्सर बॅकएंड लिहिणे, ट्रेसिंग यंत्रणा सेट करणे आणि दूत वापरून त्याचे ऑपरेशन.
या सर्वांचा आपण पुढील प्रकाशनांमध्ये विचार करू. तुमचे प्रश्न विचारा, मी ते कव्हर करण्याचा प्रयत्न करेन.

स्त्रोत: www.habr.com