🥇วิธีเรียกใช้ Istio โดยใช้ Kubernetes ในการผลิต ตอนที่ 1

อะไร อิสติโอ? นี่คือสิ่งที่เรียกว่า Service mesh ซึ่งเป็นเทคโนโลยีที่เพิ่มเลเยอร์ของสิ่งที่เป็นนามธรรมผ่านเครือข่าย เราสกัดกั้นทราฟฟิกทั้งหมดหรือบางส่วนในคลัสเตอร์และดำเนินการบางอย่างกับมัน อันไหน? ตัวอย่างเช่น เราทำการกำหนดเส้นทางอย่างชาญฉลาด หรือเราใช้วิธีการตัดวงจร เราสามารถจัดระเบียบ "การปรับใช้ canary" การเปลี่ยนทราฟฟิกบางส่วนเป็นบริการเวอร์ชันใหม่ หรือเราสามารถจำกัดการโต้ตอบภายนอกและควบคุมการเดินทางทั้งหมดจากคลัสเตอร์ไปยัง เครือข่ายภายนอก เป็นไปได้ที่จะตั้งกฎนโยบายเพื่อควบคุมการเดินทางระหว่างไมโครเซอร์วิสต่างๆ ในที่สุด เราสามารถรับแผนผังการโต้ตอบของเครือข่ายทั้งหมด และทำให้การรวบรวมเมตริกแบบรวมเป็นหนึ่งเดียวโปร่งใสอย่างสมบูรณ์สำหรับแอปพลิเคชัน

คุณสามารถอ่านเกี่ยวกับกลไกการทำงานใน เอกสารราชการ. Istio เป็นเครื่องมือที่ทรงพลังมากที่ช่วยให้คุณแก้ปัญหาและงานต่างๆ ได้มากมาย ในบทความนี้ ฉันต้องการตอบคำถามหลักที่มักเกิดขึ้นเมื่อเริ่มต้นใช้งาน Istio สิ่งนี้จะช่วยให้คุณจัดการกับมันได้เร็วขึ้น

หลักการของการดำเนินงาน

Istio ประกอบด้วยสองส่วนหลัก - ส่วนควบคุมและส่วนข้อมูล ระนาบควบคุมประกอบด้วยส่วนประกอบหลักที่ช่วยให้มั่นใจถึงการทำงานที่ถูกต้องของส่วนที่เหลือ ในเวอร์ชันปัจจุบัน (1.0) ระนาบควบคุมมีองค์ประกอบหลักสามส่วน: ไพล็อต มิกเซอร์ ป้อมปราการ เราจะไม่พิจารณา Citadel จำเป็นต้องสร้างใบรับรองเพื่อให้แน่ใจว่ามี TLS ร่วมกันระหว่างบริการต่างๆ มาดูอุปกรณ์และจุดประสงค์ของ Pilot and Mixer ให้ละเอียดยิ่งขึ้น

นักบินเป็นองค์ประกอบควบคุมหลักที่กระจายข้อมูลทั้งหมดเกี่ยวกับสิ่งที่เรามีในคลัสเตอร์ - บริการ จุดสิ้นสุด และกฎการกำหนดเส้นทาง (เช่น กฎสำหรับการปรับใช้ Canary หรือกฎเบรกเกอร์)

มิกเซอร์เป็นส่วนประกอบของระนาบควบคุมที่เป็นทางเลือกที่ให้ความสามารถในการรวบรวมเมตริก บันทึก และข้อมูลใดๆ เกี่ยวกับการโต้ตอบของเครือข่าย เขายังตรวจสอบการปฏิบัติตามกฎนโยบายและการปฏิบัติตามขีดจำกัดอัตรา

ระนาบข้อมูลถูกนำไปใช้โดยใช้คอนเทนเนอร์พร็อกซีไซด์คาร์ ที่มีประสิทธิภาพจะใช้เป็นค่าเริ่มต้น ผู้รับมอบฉันทะ. สามารถแทนที่ได้ด้วยการนำไปใช้อื่น เช่น nginx (nginmesh)

เพื่อให้ Istio ทำงานได้อย่างโปร่งใสต่อการใช้งาน จึงมีระบบหัวฉีดอัตโนมัติ การใช้งานล่าสุดเหมาะสำหรับ Kubernetes เวอร์ชัน 1.9 ขึ้นไป (เว็บฮุคการยอมรับแบบกลายพันธุ์) สำหรับ Kubernetes เวอร์ชัน 1.7, 1.8 คุณสามารถใช้ Initializer ได้

คอนเทนเนอร์ Sidecar เชื่อมต่อกับ Pilot โดยใช้โปรโตคอล GRPC ซึ่งช่วยให้คุณปรับโมเดลพุชให้เหมาะสมสำหรับการเปลี่ยนแปลงที่เกิดขึ้นในคลัสเตอร์ GRPC ถูกใช้ใน Envoy ตั้งแต่เวอร์ชัน 1.6 ใน Istio มีการใช้ตั้งแต่เวอร์ชัน 0.8 และเป็นตัวแทนนักบิน - ตัวห่อหุ้ม golang เหนือทูตที่กำหนดค่าตัวเลือกการเปิดตัว

ไพล็อตและมิกเซอร์เป็นส่วนประกอบที่ไร้สถานะโดยสมบูรณ์ สถานะทั้งหมดจะถูกเก็บไว้ในหน่วยความจำ การกำหนดค่าสำหรับสิ่งเหล่านี้ถูกตั้งค่าในรูปแบบของ Kubernetes Custom Resources ซึ่งจัดเก็บไว้ใน etcd
Istio-agent ได้รับที่อยู่ของนักบินและเปิดสตรีม GRPC ไปยังที่อยู่นั้น

ดังที่ฉันได้กล่าวไปแล้วว่า Istio ใช้ฟังก์ชันทั้งหมดอย่างโปร่งใสกับแอปพลิเคชัน มาดูกันว่าเป็นอย่างไร อัลกอริทึมคือ:

การปรับใช้บริการเวอร์ชันใหม่
คอนเทนเนอร์ istio-init และคอนเทนเนอร์ istio-agent (envoy) จะถูกเพิ่มในขั้นตอนของการใช้การกำหนดค่า หรือสามารถแทรกด้วยตนเองในคำอธิบายของเอนทิตี Kubernetes Pod ทั้งนี้ขึ้นอยู่กับวิธีการฉีดคอนเทนเนอร์ sidecar
คอนเทนเนอร์ istio-init เป็นสคริปต์ที่ใช้กฎ iptables กับพ็อด มีสองตัวเลือกในการกำหนดค่าทราฟฟิกที่จะรวมไว้ในคอนเทนเนอร์ istio-agent: ใช้กฎการเปลี่ยนเส้นทาง iptables หรือ ทีพร็อกซี่. ในขณะที่เขียน วิธีการเริ่มต้นคือกฎการเปลี่ยนเส้นทาง ใน istio-init คุณสามารถกำหนดค่าว่าการรับส่งข้อมูลใดควรถูกสกัดกั้นและส่งไปยัง istio-agent ตัวอย่างเช่น ในการสกัดกั้นทราฟฟิกขาเข้าและขาออกทั้งหมด คุณต้องตั้งค่าพารามิเตอร์ -i и -b สู่ความหมาย *. คุณสามารถระบุพอร์ตเฉพาะเพื่อสกัดกั้น เพื่อไม่ให้สกัดกั้นเครือข่ายย่อยเฉพาะ คุณสามารถระบุได้โดยใช้แฟล็ก -x.
หลังจากดำเนินการคอนเทนเนอร์ init แล้ว คอนเทนเนอร์หลักจะถูกเปิดตัว รวมถึงตัวแทนนักบิน (ผู้แทน) โดยจะเชื่อมต่อกับ Pilot ที่ปรับใช้แล้วผ่าน GRPC และรับข้อมูลเกี่ยวกับบริการที่มีอยู่ทั้งหมดและนโยบายการกำหนดเส้นทางในคลัสเตอร์ จากข้อมูลที่ได้รับ เขากำหนดค่าคลัสเตอร์และกำหนดโดยตรงไปยังจุดสิ้นสุดของแอปพลิเคชันของเราในคลัสเตอร์ Kubernetes นอกจากนี้ยังจำเป็นต้องสังเกตจุดสำคัญ: ทูตกำหนดค่าผู้ฟังแบบไดนามิก (IP, คู่พอร์ต) ที่เริ่มฟัง ดังนั้น เมื่อคำขอเข้าสู่พ็อด จะถูกเปลี่ยนเส้นทางโดยใช้กฎการเปลี่ยนเส้นทาง iptables ใน sidecar ผู้ส่งทูตสามารถประมวลผลการเชื่อมต่อเหล่านี้ได้สำเร็จ และเข้าใจตำแหน่งที่จะส่งพร็อกซีทราฟฟิกต่อไป นอกจากนี้ ในขั้นตอนนี้ ข้อมูลจะถูกส่งไปยัง Mixer ซึ่งเราจะดูในภายหลัง และส่งช่วงการติดตาม

เป็นผลให้เราได้รับเครือข่ายทูตพร็อกซีเซิร์ฟเวอร์ทั้งหมดที่เราสามารถกำหนดค่าได้จากจุดเดียว (Pilot) คำขอขาเข้าและขาออกทั้งหมดต้องผ่านทูต นอกจากนี้ ทราฟฟิก TCP เท่านั้นที่ถูกสกัดกั้น ซึ่งหมายความว่า IP ของบริการ Kubernetes ได้รับการแก้ไขโดยใช้ kube-dns ผ่าน UDP โดยไม่มีการเปลี่ยนแปลง จากนั้น หลังจากแก้ไขแล้ว คำขอที่ส่งออกจะถูกสกัดกั้นและดำเนินการโดยทูต ซึ่งเป็นผู้ตัดสินใจแล้วว่าควรส่งคำขอไปที่ปลายทางใด (หรือไม่ส่ง ในกรณีของนโยบายการเข้าถึงหรือตัวตัดวงจรของอัลกอริทึม)

เราพบ Pilot แล้ว ตอนนี้เราต้องเข้าใจวิธีการทำงานของ Mixer และเหตุใดจึงจำเป็น คุณสามารถอ่านเอกสารอย่างเป็นทางการได้ ที่นี่.

มิกเซอร์ในรูปแบบปัจจุบันประกอบด้วยสององค์ประกอบ: istio-telemetry, istio-policy (ก่อนเวอร์ชัน 0.8 เป็นส่วนประกอบ istio-mixer หนึ่งองค์ประกอบ) ทั้งคู่เป็นผู้ผสมซึ่งแต่ละคนมีหน้าที่รับผิดชอบงานของตนเอง การวัดและส่งข้อมูลทางไกลของ Istio รับข้อมูลว่าใครไปที่ไหนและด้วยพารามิเตอร์ใดจากคอนเทนเนอร์รายงานรถด้านข้างผ่าน GRPC นโยบาย Istio ยอมรับคำขอตรวจสอบเพื่อยืนยันว่าเป็นไปตามกฎของนโยบาย แน่นอนว่าการตรวจสอบความสกปรกไม่ได้ดำเนินการสำหรับทุกคำขอ แต่จะถูกแคชไว้บนไคลเอนต์ (ในรถจักรยานยนต์พ่วงข้าง) ในระยะเวลาหนึ่ง การตรวจสอบรายงานจะถูกส่งเป็นคำขอแบบกลุ่ม มาดูวิธีการกำหนดค่าและพารามิเตอร์ที่ควรส่งในภายหลัง

มิกเซอร์ควรเป็นส่วนประกอบที่มีความพร้อมใช้งานสูงซึ่งช่วยให้มั่นใจได้ว่างานประกอบและการประมวลผลข้อมูลทางไกลจะไม่หยุดชะงัก ระบบได้มาจากบัฟเฟอร์หลายระดับ ในขั้นต้น ข้อมูลจะถูกบัฟเฟอร์ที่ด้านไซด์คาร์ของคอนเทนเนอร์ จากนั้นที่ด้านมิกเซอร์ แล้วจึงส่งไปยังแบ็กเอนด์มิกเซอร์ที่เรียกว่า ผลที่ตามมาคือ หากส่วนประกอบใดๆ ของระบบล้มเหลว บัฟเฟอร์จะขยายใหญ่ขึ้นและถูกล้างหลังจากกู้คืนระบบแล้ว แบ็กเอนด์มิกเซอร์คือจุดสิ้นสุดสำหรับการส่งข้อมูล telemetry: statsd, newrelic เป็นต้น คุณสามารถเขียนแบ็กเอนด์ของคุณเองได้ ซึ่งค่อนข้างง่าย และเราจะดูวิธีการทำ

โดยสรุป รูปแบบการทำงานกับ istio-telemetry มีดังต่อไปนี้

บริการ 1 ส่งคำขอไปยังบริการ 2
เมื่อออกจากบริการ 1 คำขอจะถูกห่อด้วยรถจักรยานยนต์พ่วงข้าง
เจ้าหน้าที่ Sidecar คอยติดตามว่าคำขอส่งไปยังบริการ 2 อย่างไร และเตรียมข้อมูลที่จำเป็น
จากนั้นส่งไปยัง istio-telemetry โดยใช้คำขอรายงาน
Istio-telemetry กำหนดว่าควรส่งรายงานนี้ไปยังแบ็กเอนด์หรือไม่ ควรส่งข้อมูลใดและใด
Istio-telemetry ส่งข้อมูลรายงานไปยังแบ็กเอนด์หากจำเป็น

ทีนี้มาดูวิธีการปรับใช้ Istio ในระบบ ซึ่งประกอบด้วยส่วนประกอบหลักเท่านั้น (ทูตนักบินและผู้ช่วยข้างเคียง)

ก่อนอื่น มาดูการกำหนดค่าหลัก (mesh) ที่ Pilot อ่าน:

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

ส่วนประกอบการควบคุมหลักทั้งหมด (ระนาบควบคุม) จะอยู่ในเนมสเปซ istio-system ใน Kubernetes

อย่างน้อยที่สุด เราจำเป็นต้องปรับใช้นักบินเท่านั้น สำหรับสิ่งนี้เราใช้ การกำหนดค่าดังกล่าว

และเราจะกำหนดค่าการฉีดด้านข้างของคอนเทนเนอร์ด้วยตนเอง

คอนเทนเนอร์เริ่มต้น:

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 for Pilot ซึ่งสามารถหาคำอธิบายได้ ที่นี่.

ด้วยเหตุนี้ บริการที่เราส่งรถเทียมพ่วงข้างรถทูตควรจะเริ่มต้นได้สำเร็จ ได้รับการค้นพบทั้งหมดจากนักบินและดำเนินการตามคำขอ

สิ่งสำคัญคือต้องเข้าใจว่าส่วนประกอบของระนาบควบคุมทั้งหมดเป็นแอปพลิเคชันไร้สถานะและสามารถปรับขนาดในแนวนอนได้โดยไม่มีปัญหา ข้อมูลทั้งหมดถูกจัดเก็บไว้ใน etcd ในรูปแบบของคำอธิบายที่กำหนดเองของทรัพยากร Kubernetes

นอกจากนี้ Istio (ยังอยู่ในช่วงทดลอง) มีความสามารถในการเรียกใช้ภายนอกคลัสเตอร์และความสามารถในการเฝ้าดูและคลำค้นหาบริการระหว่างคลัสเตอร์ Kubernetes ต่างๆ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ ที่นี่.

สำหรับการติดตั้งหลายคลัสเตอร์ โปรดทราบข้อจำกัดต่อไปนี้:

CIDR ของ Pod และ Service CIDR ต้องไม่ซ้ำกันในทุกคลัสเตอร์และต้องไม่ทับซ้อนกัน
พ็อด CIDR ทั้งหมดต้องสามารถเข้าถึงได้จากพ็อด CIDR ระหว่างคลัสเตอร์
เซิร์ฟเวอร์ Kubernetes API ทั้งหมดต้องสามารถเข้าถึงได้ซึ่งกันและกัน

นี่คือข้อมูลเบื้องต้นที่จะช่วยให้คุณเริ่มต้นใช้งาน Istio อย่างไรก็ตาม ยังมีข้อผิดพลาดมากมาย ตัวอย่างเช่น คุณลักษณะของการกำหนดเส้นทางทราฟฟิกภายนอก (นอกคลัสเตอร์) วิธีการดีบักไซด์คาร์ การทำโปรไฟล์ การตั้งค่ามิกเซอร์และการเขียนแบ็กเอนด์มิกเซอร์แบบกำหนดเอง การตั้งค่ากลไกการติดตามและการดำเนินการโดยใช้ทูต
ทั้งหมดนี้เราจะพิจารณาในสิ่งพิมพ์ต่อไปนี้ ถามคำถามของคุณ ฉันจะพยายามครอบคลุมพวกเขา

ที่มา: will.com

วิธีเรียกใช้ Istio โดยใช้ Kubernetes ในการผลิต ส่วนที่ 1

หลักการของการดำเนินงาน

เพิ่มความคิดเห็น ยกเลิกการตอบ