उत्पादनमा Kubernetes प्रयोग गरेर Istio कसरी चलाउने। भाग 1

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

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

कसरी यो काम गर्दछ

Istio दुई मुख्य क्षेत्रहरू समावेश गर्दछ - नियन्त्रण विमान र डेटा विमान। नियन्त्रण विमानले मुख्य घटकहरू समावेश गर्दछ जुन बाँकीको सही सञ्चालन सुनिश्चित गर्दछ। हालको संस्करण (1.0) मा नियन्त्रण विमान तीन मुख्य घटक छ: पायलट, मिक्सर, सिटाडेल। हामी सिटाडेललाई विचार गर्दैनौं, सेवाहरू बीच आपसी TLS सुनिश्चित गर्न प्रमाणपत्रहरू उत्पन्न गर्न आवश्यक छ। पाइलट र मिक्सरको यन्त्र र उद्देश्यलाई नजिकबाट हेरौं।

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

मिक्सर एक वैकल्पिक नियन्त्रण प्लेन कम्पोनेन्ट हो जसले मेट्रिक्स, लगहरू, र नेटवर्क अन्तरक्रियाको बारेमा कुनै पनि जानकारी सङ्कलन गर्ने क्षमता प्रदान गर्दछ। उसले नीति नियमहरूको पालना र दर सीमाहरूको अनुपालनको पनि अनुगमन गर्दछ।

डाटा प्लेन साइडकार प्रोक्सी कन्टेनरहरू प्रयोग गरेर लागू गरिएको छ। पूर्वनिर्धारित रूपमा शक्तिशाली प्रयोग गरिन्छ। दूत प्रोक्सी। यसलाई अर्को कार्यान्वयन द्वारा प्रतिस्थापन गर्न सकिन्छ, जस्तै nginx (nginmesh)।

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

साइडकार कन्टेनरहरू GRPC प्रोटोकल प्रयोग गरेर पायलटसँग जोडिएका छन्, जसले तपाईंलाई क्लस्टरमा हुने परिवर्तनहरूको लागि पुश मोडेललाई अनुकूलन गर्न अनुमति दिन्छ। GRPC संस्करण 1.6 देखि Envoy मा प्रयोग गरिएको छ, Istio मा यो संस्करण 0.8 बाट प्रयोग गरिएको छ र एक पायलट-एजेन्ट हो - लन्च विकल्पहरू कन्फिगर गर्ने दूतमाथि गोलाङ्ग र्यापर।

पायलट र मिक्सर पूर्ण रूपमा स्टेटलेस कम्पोनेन्टहरू हुन्, सबै राज्य मेमोरीमा राखिएको छ। तिनीहरूको लागि कन्फिगरेसन Kubernetes अनुकूलन संसाधनहरूको रूपमा सेट गरिएको छ, जुन etcd मा भण्डारण गरिन्छ।
Istio-एजेन्टले पायलटको ठेगाना पाउँछ र यसमा GRPC स्ट्रिम खोल्छ।

मैले भनेझैं, Istio अनुप्रयोगहरूमा पूर्ण रूपमा पारदर्शी सबै कार्यक्षमता लागू गर्दछ। कसरी हेरौं। एल्गोरिथ्म यो हो:

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

नतिजाको रूपमा, हामीले दूत प्रोक्सी सर्भरहरूको सम्पूर्ण नेटवर्क पाउँछौं जुन हामीले एक बिन्दु (पायलट) बाट कन्फिगर गर्न सक्छौं। सबै इनबाउन्ड र आउटबाउन्ड अनुरोधहरू राजदूत मार्फत जान्छन्। यसबाहेक, TCP ट्राफिक मात्र रोकिएको छ। यसको अर्थ Kubernetes सेवा IP लाई UDP माथि kube-dns प्रयोग गरेर बिना परिवर्तन गरी समाधान गरिन्छ। त्यसपछि, समाधान पछि, बहिर्गमन अनुरोधलाई दूतद्वारा रोकिन्छ र प्रशोधन गरिन्छ, जसले पहिले नै निर्णय गर्दछ कि कुन अन्तिम बिन्दुमा अनुरोध पठाइनेछ (वा पठाइएको छैन, पहुँच नीति वा एल्गोरिथ्मको सर्किट ब्रेकरको मामलामा)।

हामीले पायलट पत्ता लगायौं, अब हामीले मिक्सर कसरी काम गर्छ र यो किन आवश्यक छ भनेर बुझ्न आवश्यक छ। तपाईं यसको लागि आधिकारिक कागजातहरू पढ्न सक्नुहुन्छ यहाँ.

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

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

संक्षेपमा, istio-telemetry सँग काम गर्ने योजना निम्नानुसार छ।

1. सेवा १ ले सेवा २ लाई अनुरोध पठाउँछ।
2. सेवा १ छोड्दा, अनुरोध आफ्नै साइडकारमा बेरिएको हुन्छ।
3. Sidecar दूतले कसरी अनुरोध सेवा 2 मा जान्छ निगरानी गर्दछ र आवश्यक जानकारी तयार गर्दछ।
4. त्यसपछि रिपोर्ट अनुरोध प्रयोग गरेर istio-telemetry मा पठाउँछ।
5. Istio-telemetry ले यो प्रतिवेदन ब्याकएन्डमा पठाउने वा कुन डाटा पठाउने भन्ने निर्धारण गर्दछ।
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

सबै कुरा सफलतापूर्वक सुरु गर्नको लागि, तपाईंले सेवा खाता, क्लस्टररोल, क्लस्टररोलबाइन्डिङ, पायलटका लागि CRD सिर्जना गर्न आवश्यक छ, जसको विवरणहरू फेला पार्न सकिन्छ। यहाँ.

नतिजाको रूपमा, हामीले दूतसँग साइडकार इन्जेक्सन गर्ने सेवा सफलतापूर्वक सुरु हुनुपर्छ, पाइलटबाट सबै खोजहरू प्राप्त गर्नुहोस् र अनुरोधहरू प्रक्रिया गर्नुहोस्।

यो बुझ्न महत्त्वपूर्ण छ कि सबै नियन्त्रण विमान कम्पोनेन्टहरू राज्यविहीन अनुप्रयोगहरू हुन् र कुनै समस्या बिना तेर्सो मापन गर्न सकिन्छ। सबै डाटा कुबेरनेट स्रोतहरूको अनुकूलन विवरणको रूपमा etcd मा भण्डारण गरिएको छ।

साथै, Istio (अझै पनि प्रयोगात्मक) मा क्लस्टर बाहिर चल्ने क्षमता र धेरै Kubernetes क्लस्टरहरू बीच सेवा खोज हेर्न र फम्बल गर्ने क्षमता छ। तपाईं यस बारे थप पढ्न सक्नुहुन्छ यहाँ.

बहु-क्लस्टर स्थापनाको लागि, निम्न सीमाहरू बारे सचेत रहनुहोस्:

1. Pod CIDR र Service CIDR सबै क्लस्टरहरूमा अद्वितीय हुनुपर्छ र ओभरल्याप हुनु हुँदैन।
2. सबै CIDR पोडहरू क्लस्टरहरू बीचको कुनै पनि CIDR पोडहरूबाट पहुँचयोग्य हुनुपर्छ।
3. सबै Kubernetes API सर्भरहरू एक अर्कामा पहुँचयोग्य हुनुपर्छ।

तपाईंलाई Istio को साथ सुरु गर्न मद्दतको लागि यो प्रारम्भिक जानकारी हो। यद्यपि, त्यहाँ अझै धेरै खाटहरू छन्। उदाहरणका लागि, बाह्य ट्राफिक (क्लस्टर बाहिर) राउट गर्ने विशेषताहरू, साइडकारहरू डिबग गर्ने दृष्टिकोण, प्रोफाइलिङ, मिक्सर सेटअप गर्ने र कस्टम मिक्सर ब्याकइन्ड लेख्ने, ट्रेसिङ मेकानिजम स्थापना गर्ने र दूत प्रयोग गरेर यसको सञ्चालन।
यी सबै हामी निम्न प्रकाशनहरूमा विचार गर्नेछौं। तपाईका प्रश्नहरू सोध्नुहोस्, म तिनीहरूलाई कभर गर्ने प्रयास गर्नेछु।

स्रोत: www.habr.com