दूत. 1. परिचय

शुभेच्छा! हा एक छोटा लेख आहे जो प्रश्नांची उत्तरे देतो: “दूत म्हणजे काय?”, “त्याची गरज का आहे?” आणि "कोठे सुरू करावे?".

हे काय आहे?

दूत हा C++ मध्ये लिहिलेला L4-L7 बॅलन्सर आहे, जो उच्च कार्यक्षमता आणि उपलब्धतेवर केंद्रित आहे. एकीकडे, हे काही प्रकारे nginx आणि haproxy चे analogue आहे, त्यांच्याशी तुलना करता येते. दुसरीकडे, हे मायक्रोसर्व्हिस आर्किटेक्चरकडे अधिक केंद्रित आहे आणि त्याची कार्यक्षमता जावा आणि गो बॅलन्सर्सपेक्षा वाईट नाही, जसे की झुउल किंवा ट्रॅफिक.

haproxy/nginx/envoy ची तुलना सारणी, ते पूर्ण सत्य असल्याचा दावा करत नाही, परंतु एक सामान्य चित्र देते.

nginx
हाप्रॉक्सी
दूत
ट्रॅफिक

github वर तारे
11.2k/मिरर
1.1k/मिरर
12.4k
27.6k

मध्ये लिहिले आहे
C
C
C ++
go

API
नाही
फक्त सॉकेट/पुश
डेटाप्लेन/पुल
खेचणे

सक्रिय आरोग्य तपासणी
नाही
होय
होय
होय

खुल्या ट्रेसिंग
बाह्य प्लगइन
नाही
होय
होय

जेडब्ल्यूटी
बाह्य प्लगइन
नाही
होय
नाही

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

का

हा एक तरुण प्रकल्प आहे, तेथे बर्‍याच गोष्टी गहाळ आहेत, काही सुरुवातीच्या अल्फामध्ये आहेत. परंतु दूत, त्याच्या तरुणपणामुळे, वेगाने विकसित होत आहे आणि आधीच अनेक मनोरंजक वैशिष्ट्ये आहेत: डायनॅमिक कॉन्फिगरेशन, बरेच तयार फिल्टर, आपले स्वतःचे फिल्टर लिहिण्यासाठी एक साधा इंटरफेस.
अनुप्रयोगाची क्षेत्रे यावरून अनुसरण करतात, परंतु प्रथम 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 वर प्रवेश करत आहे.

• सक्रिय आरोग्य तपासणी.

आमच्याकडे सक्रिय आरोग्य तपासणी असल्यास, आम्हाला रहदारी पाठवण्यापूर्वी त्या सर्व नवीन कॉन्फिगरेशनमध्ये पुन्हा तपासणे आवश्यक आहे. भरपूर अपस्ट्रीम असल्यास, यास वेळ लागतो. हॅप्रॉक्सी.

मध्ये हे कसे सोडवले जाते दूतकॉन्फिगरेशन डायनॅमिकरित्या लोड करून, पूल मॉडेलनुसार, तुम्ही ते वेगळ्या भागांमध्ये विभागू शकता आणि जो भाग बदलला नाही तो पुन्हा सुरू करू शकत नाही. उदाहरणार्थ, एक श्रोता, जो पुन्हा सुरू करणे महाग आहे आणि क्वचितच बदलतो.

कॉन्फिगरेशन दूत (वरील फाइलमधून) खालील संस्था आहेत:

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

यापैकी प्रत्येक घटक आणि इतर काही डायनॅमिक पद्धतीने भरले जाऊ शकतात; यासाठी, कॉन्फिगरेशन सेवेचा पत्ता निर्दिष्ट करते जिथून कॉन्फिगरेशन प्राप्त केले जाईल. सेवा REST किंवा gRPC असू शकते, gRPC श्रेयस्कर आहे.

सेवांची अनुक्रमे नावे आहेत: LDS, VHDS, RDS, CDS आणि EDS. तुम्ही स्थिर आणि डायनॅमिक कॉन्फिगरेशन एकत्र करू शकता, या मर्यादेसह डायनॅमिक संसाधन स्थिर मध्ये निर्दिष्ट केले जाऊ शकत नाही.

बर्याच कार्यांसाठी, शेवटच्या तीन सेवांची अंमलबजावणी करणे पुरेसे आहे, त्यांना एडीएस (एकत्रित शोध सेवा) म्हणतात. जावा आणि तिथे जा 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-time-s, डीफॉल्ट 10 मिनिटे.

चालू ठेवण्यासाठी

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