राजदूत। 1। परिचय

अभिवादन! यो एउटा छोटो लेख हो जसले प्रश्नहरूको जवाफ दिन्छ: "राजदूत के हो?", "यो किन आवश्यक छ?" र "कहाँ सुरु गर्ने?"।

यो के हो

Envoy C++ मा लेखिएको L4-L7 ब्यालेन्सर हो, उच्च प्रदर्शन र उपलब्धतामा केन्द्रित। एकातिर, यो कुनै न कुनै रूपमा nginx र haproxy को एक एनालग हो, तिनीहरूसँग प्रदर्शनमा तुलना गर्न सकिन्छ। अर्कोतर्फ, यो माइक्रोसर्भिस आर्किटेक्चर तर्फ बढी उन्मुख छ र यसको कार्यक्षमता जाभा र गो ब्यालेन्सरहरू भन्दा खराब छैन, जस्तै जुउल वा ट्राफिक।

haproxy/nginx/envoy को तुलना तालिका, यसले पूर्ण सत्य भएको दाबी गर्दैन, तर सामान्य चित्र दिन्छ।

nginx
haproxy
पठाइयो
ट्राफिक

github मा ताराहरू
11.2k/मिरर
1.1k/मिरर
12.4k
27.6k

मा लेखिएको छ
C
C
सी ++
go

एपीआई
कुनै
सकेट मात्र / धक्का
डाटाप्लेन/पुल
खींचो

सक्रिय स्वास्थ्य जाँच
कुनै
हो
हो
हो

खुला ट्रेसिङ
बाह्य प्लगइन
कुनै
हो
हो

J.W.T.
बाह्य प्लगइन
कुनै
हो
कुनै

विस्तार
लुआ/सी
लुआ/सी
लुआ/सी++
कुनै

किन

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

• स्थिर रिकोइल।

तथ्य यो हो कि यतिबेला मा पठाइयो कुनै क्यासिङ समर्थन छैन। गुगल केटाहरू यो प्रयास गर्दैछन् ठिक। यो विचार एक पटक लागू हुनेछ पठाइयो RFC अनुपालनको सबै सूक्ष्मताहरू (चिडियाघरको हेडरहरू) र विशेष कार्यान्वयनहरूको लागि इन्टरफेस बनाउँछ। तर अहिलेको लागि यो अल्फा पनि छैन, वास्तुकला छलफलमा छ, PR खुला (जब म PR लेख लेख्दै थिए, PR जमेको थियो, तर यो बिन्दु अझै सान्दर्भिक छ)।

अहिलेको लागि, स्ट्याटिक्सको लागि nginx प्रयोग गर्नुहोस्।

• स्थिर कन्फिगरेसन।

तपाईं यसलाई प्रयोग गर्न सक्नुहुन्छ, तर पठाइयो त्यसका लागि सिर्जना गरिएको होइन । स्थिर कन्फिगरेसनमा रहेका सुविधाहरू खुलासा हुने छैनन्। त्यहाँ धेरै क्षणहरू छन्:

yaml मा कन्फिगरेसन सम्पादन गर्दा, तपाईं गल्ती हुनुहुनेछ, शब्दावलीको लागि विकासकर्ताहरूलाई हप्काउनुहुन्छ र सोच्नुहोस् कि nginx/haproxy कन्फिगरेसनहरू, कम संरचित भए पनि, थप संक्षिप्त छन्। कुरो यही हो। Nginx र Haproxy को कन्फिगरेसन हातले सम्पादनको लागि सिर्जना गरिएको थियो, र पठाइयो कोडबाट उत्पादनको लागि। सम्पूर्ण कन्फिगरेसन मा वर्णन गरिएको छ प्रोटोबफ, प्रोटो फाइलहरू बाट उत्पन्न गल्ती गर्न धेरै गाह्रो छ।

क्यानरी, b/g डिप्लोइमेन्ट परिदृश्यहरू र अधिक सामान्य रूपमा केवल गतिशील कन्फिगरेसनमा लागू गरिन्छ। मैले भनेको छैन कि यो स्थिर रूपमा गर्न सकिँदैन, हामी सबैले गर्छौं। तर यसका लागि तपाईंले कुनै पनि ब्यालेन्सरमा, बैसाखी लगाउनु पर्छ पठाइयो सहित

राजदूत अपरिहार्य कार्यहरू:

• जटिल र गतिशील प्रणालीहरूमा ट्राफिक सन्तुलन। यसमा सेवा जाल समावेश छ, तर यो एक मात्र आवश्यक छैन।
• वितरित ट्रेसिङ कार्यक्षमता, जटिल प्राधिकरण वा अन्य कार्यक्षमता को आवश्यकता मा उपलब्ध छ पठाइयो बाकस बाहिर वा सुविधाजनक रूपमा लागू, तर nginx/haproxy मा तपाईं लुआ र शंकास्पद प्लगइनहरू द्वारा घेरिएको हुनुपर्छ।

दुवै, आवश्यक भएमा, उच्च प्रदर्शन प्रदान गर्नुहोस्।

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

दूतलाई बाइनरीहरूमा डकर छविको रूपमा मात्र वितरण गरिएको छ। छविमा पहिले नै स्थिर कन्फिगरेसनको उदाहरण समावेश छ। तर, हामी संरचना बुझ्नको लागि मात्र यसमा चासो राख्छौं।

envoy.yaml स्थिर कन्फिगरेसन

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite: www.google.com
                  cluster: service_google
          http_filters:
          - name: envoy.router
  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_google
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.google.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
        sni: www.google.com

गतिशील कन्फिगरेसन

हामी कुन समस्याको समाधान खोजिरहेका छौं? तपाईले लोड अन्तर्गत लोड ब्यालेन्सर कन्फिगरेसन मात्र पुन: लोड गर्न सक्नुहुन्न; "साना" समस्याहरू उत्पन्न हुनेछन्:

• कन्फिगरेसन प्रमाणीकरण।

कन्फिगरेसन ठूलो हुन सक्छ, यो धेरै ठूलो हुन सक्छ, यदि हामीले यसलाई एकै पटक ओभरलोड गर्यौं भने, त्रुटिको सम्भावना कतै बढ्छ।

• लामो समयसम्म जडानहरू।

नयाँ श्रोता सुरु गर्दा, तपाईंले पुरानोमा चलिरहेको जडानहरूको ख्याल गर्न आवश्यक छ; यदि परिवर्तनहरू बारम्बार हुन्छन् र त्यहाँ लामो समयसम्म जडानहरू छन् भने, तपाईंले सम्झौताको खोजी गर्नुपर्नेछ। नमस्ते, kubernetes nginx मा प्रवेश गर्दछ।

• सक्रिय स्वास्थ्य जाँच।

यदि हामीसँग सक्रिय स्वास्थ्य जाँचहरू छन् भने, हामीले ट्राफिक पठाउनु अघि ती सबैलाई नयाँ कन्फिगरेसनमा डबल-जाँच गर्न आवश्यक छ। यदि त्यहाँ धेरै अपस्ट्रिमहरू छन् भने, यसले समय लिन्छ। नमस्ते haproxy।

यो मा कसरी समाधान हुन्छ पठाइयोकन्फिगरेसन गतिशील रूपमा लोड गरेर, पूल मोडेल अनुसार, तपाईंले यसलाई अलग-अलग भागहरूमा विभाजन गर्न सक्नुहुन्छ र परिवर्तन नभएको भागलाई पुन: सुरु गर्न सक्नुहुन्छ। उदाहरणका लागि, एक श्रोता, जुन पुन: सुरु गर्न महँगो छ र विरलै परिवर्तन हुन्छ।

कन्फिगरेसन पठाइयो (माथिको फाइलबाट) निम्न निकायहरू छन्:

• श्रोता - एक विशिष्ट आईपी / पोर्टमा झुण्डिएको श्रोता
• भर्चुअल होस्ट - डोमेन नाम द्वारा भर्चुअल होस्ट
• मार्ग - सन्तुलन नियम
• क्लस्टर - सन्तुलन प्यारामिटरहरूको साथ अपस्ट्रीमहरूको समूह
• अन्तबिन्दु - अपस्ट्रीम उदाहरण ठेगाना

यी प्रत्येक संस्थाहरू र केही अन्यहरू गतिशील रूपमा भर्न सकिन्छ; यसको लागि, कन्फिगरेसनले सेवाको ठेगाना निर्दिष्ट गर्दछ जहाँबाट कन्फिगरेसन प्राप्त हुनेछ। सेवा REST वा gRPC हुन सक्छ, gRPC राम्रो छ।

सेवाहरूलाई क्रमशः नाम दिइएको छ: LDS, VHDS, RDS, CDS र EDS। तपाईं स्थिर र गतिशील कन्फिगरेसन संयोजन गर्न सक्नुहुन्छ, एक गतिशील स्रोत स्थिर एकमा निर्दिष्ट गर्न सकिँदैन।

धेरै जसो कार्यहरूको लागि, अन्तिम तीन सेवाहरू लागू गर्न पर्याप्त छ, तिनीहरूलाई एडीएस (एकत्रित खोज सेवा) भनिन्छ। java र त्यहाँ जानुहोस् gRPC डाटाप्लेनको तयार-निर्मित कार्यान्वयन छ जसमा तपाईंले आफ्नो स्रोतबाट वस्तुहरू भर्नु पर्छ।

कन्फिगरेसनले निम्न फारम लिन्छ:

envoy.yaml गतिशील कन्फिगरेसन

dynamic_resources:
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_clr
  cds_config:
    ads: {}
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          rds:
            route_config_name: local_route
            config_source:
              ads: {}
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_clr
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: xds_clr
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: xds
                port_value: 6565

सुरुमा पठाइयो यो कन्फिगरेसनको साथ, यो कन्ट्रोल-प्लेनमा जडान हुनेछ र RDS, CDS र EDS कन्फिगरेसन अनुरोध गर्ने प्रयास गर्नेछ। अन्तरक्रिया प्रक्रिया कसरी हुन्छ वर्णन गरिएको छ यहाँ.

छोटकरीमा, पठाइयो अनुरोध गरिएको स्रोतको प्रकार, नोडको संस्करण र प्यारामिटरहरू सङ्केत गर्ने अनुरोध पठाउँछ। प्रतिक्रियामा, यसले स्रोत र संस्करण प्राप्त गर्दछ; यदि नियन्त्रण-विमानमा संस्करण परिवर्तन भएको छैन भने, यसले प्रतिक्रिया गर्दैन।
त्यहाँ 4 अन्तरक्रिया विकल्पहरू छन्:

• सबै प्रकारका स्रोतहरूको लागि एउटा gRPC स्ट्रिम, स्रोतको पूर्ण स्थिति पठाइन्छ।
• अलग स्ट्रिमहरू, पूर्ण अवस्था।
• एक धारा, वृद्धिशील अवस्था।
• अलग स्ट्रिमहरू, वृद्धिशील अवस्था।

वृद्धिशील xDS ले तपाईंलाई नियन्त्रण-प्लेन र बीचको ट्राफिक कम गर्न अनुमति दिन्छ पठाइयो, यो ठूला कन्फिगरेसनहरूको लागि सान्दर्भिक छ। तर यसले अन्तरक्रियालाई जटिल बनाउँछ; अनुरोधमा सदस्यता रद्द र सदस्यता लिनका लागि स्रोतहरूको सूची समावेश छ।

हाम्रो उदाहरणले ADS प्रयोग गर्दछ - RDS, CDS, EDS र गैर-वृद्धि मोडको लागि एउटा स्ट्रिम। वृद्धिशील मोड सक्षम गर्न, तपाईंले निर्दिष्ट गर्न आवश्यक छ api_type: DELTA_GRPC

अनुरोधले नोड प्यारामिटरहरू समावेश गरेको हुनाले, हामी विभिन्न उदाहरणहरूको लागि नियन्त्रण-प्लेनमा विभिन्न स्रोतहरू पठाउन सक्छौं पठाइयो, यो सेवा जाल निर्माण गर्न को लागी सुविधाजनक छ।

वार्मअप

मा पठाइयो स्टार्टअपमा वा नियन्त्रण-प्लेनबाट नयाँ कन्फिगरेसन प्राप्त गर्दा, स्रोत वार्मअप प्रक्रिया सुरु हुन्छ। यसलाई श्रोता वार्मअप र क्लस्टर वार्मअपमा विभाजन गरिएको छ। पहिलो आरडीएस/एलडीएसमा परिवर्तन हुँदा, दोस्रो सीडीएस/ईडीएस हुँदा सुरु हुन्छ। यसको मतलब यो हो कि यदि केवल अपस्ट्रीमहरू परिवर्तन हुन्छ भने, श्रोता पुन: सिर्जना हुँदैन।

वार्म-अप प्रक्रियाको बखत, टाइमआउटको समयमा नियन्त्रण-प्लेनबाट निर्भर स्रोतहरू अपेक्षा गरिन्छ। यदि टाइमआउट भयो भने, प्रारम्भिकरण सफल हुने छैन र नयाँ श्रोताले पोर्टमा सुन्न सुरु गर्दैन।
प्रारम्भिक आदेश: EDS, CDS, सक्रिय स्वास्थ्य जाँच, RDS, LDS। सक्रिय स्वास्थ्य जाँचहरू सक्षम भएपछि, ट्राफिक एक सफल स्वास्थ्य जाँच पछि मात्र माथि जान्छ।

यदि श्रोता पुन: सिर्जना गरिएको थियो भने, पुरानो DRAIN स्थितिमा जान्छ र सबै जडानहरू बन्द भएपछि वा समय समाप्त भएपछि मेटिनेछ। --drain-time-s, पूर्वनिर्धारित 10 मिनेट।

फेरि जारी राखौंला।

स्रोत: www.habr.com