สถาปัตยกรรม Service Mesh ด้วย Istio

1. บทนำ

ในบทช่วยสอนนี้ เราจะพูดถึงพื้นฐานของสถาปัตยกรรม SerivcesMesh และทำความเข้าใจว่าสถาปัตยกรรมนี้ ช่วยเสริมสถาปัตยกรรมระบบแบบกระจายได้อย่างไร

เราจะเน้นที่ Istio เป็นหลัก ซึ่งเป็นการนำ Service Mesh ไปใช้งาน ในกระบวนการนี้ เราจะครอบคลุมสถาปัตยกรรมหลักของ Istio และทำความเข้าใจว่าจะได้รับประโยชน์จากสถาปัตยกรรมนี้บน Kubernetes อย่างไร

2. SerivcesMesh คืออะไร?

ในช่วง 2-3 ทศวรรษที่ผ่านมา เราได้เห็นแล้วว่าการใช้งานแบบรวมระบบเป็นกลุ่มเดียวเริ่มสลายตัวเป็นแอพพลิเคชั่นขนาดเล็กลงได้อย่างไร สิ่งที่พบคือ พบว่ามีความนิยมอย่างไม่เคยปรากฏมาก่อนกับสถาปัตยกรรมการประมวลผลแบบคลาวด์และไมโครเซอร์วิส นอกจากนี้ เทคโนโลยีการบรรจุคอนเทนเนอร์ เช่น Docker และระบบการประสานอย่าง Kubernetes ก็ได้เข้ามาช่วยในเรื่องนี้

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

รวมถึงข้อกังวลอื่นๆ เช่น ระบบความปลอดภัยและความสามารถในการสังเกตที่จำเป็นต้องดูแลด้วย:

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

4. บทนำสู่ Istio

Istio เป็นการใช้งานโอเพ่นซอร์สของบริการเมชที่พัฒนาโดย IBM, Google และ Lyft สามารถเลเยอร์บนแอปพลิเคชันแบบกระจายและให้ประโยชน์จาก SerivcesMesh ทั้งหมด เช่น การจัดการการรับส่งข้อมูล การรักษาความปลอดภัย และความสามารถในการสังเกต

ได้รับการออกแบบมาเพื่อทำงานกับการปรับใช้ที่หลากหลาย เช่น โฮสต์บนคลาวด์ ในคอนเทนเนอร์ Kubernetes และในผู้ให้บริการที่ทำงานบนเครื่องเสมือน แม้ว่า Istio จะเป็นแพลตฟอร์มที่ไม่เป็นกลาง แต่ก็มักใช้ร่วมกับไมโครเซอร์วิสที่ใช้งานบนแพลตฟอร์ม Kubernetes

โดยพื้นฐานแล้ว Istio ทำงานโดยปรับใช้ Envoy เวอร์ชันขยายเป็นพร็อกซีให้กับทุกไมโครเซอร์วิสในฐานะผู้ช่วยส่วนตัว:

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

Istio ค่อนข้างยืดหยุ่นในแง่ของการผสานรวมกับไลบรารีและแพลตฟอร์มภายนอก ตัวอย่างเช่น เราสามารถผสานรวม Istio กับแพลตฟอร์มการบันทึกข้อมูลภายนอก การวัดระยะไกล หรือระบบนโยบาย

5. การทำความเข้าใจคอมโพเนนต์ของ Istio

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

ในส่วนนี้ เราจะพูดถึงรายละเอียดของส่วนประกอบหลัก

5.1. ระนาบข้อมูล

ระนาบข้อมูลของ Istio ประกอบด้วยเวอร์ชันเพิ่มเติมของพร็อกซี Envoy เป็นหลัก Envoy เป็นโอเพนซอร์ส edge และ service proxy ที่แยกข้อกังวลของเครือข่ายออกจากแอพพลิเคชั่นพื้นฐาน แอปพลิเคชันเพียงแค่ส่งและรับข้อความไปและกลับจาก localhost โดยไม่ต้องมีความรู้เกี่ยวกับโทโพโลยีเครือข่าย

ที่แกนหลัก Envoy เป็นเครือข่ายพร็อกซี ทำงานที่เลเยอร์ L3 และ L4 ของโมเดล OSI ทำงานโดยใช้ตัวกรองเครือข่ายแบบเสียบได้ เพื่อดำเนินการจัดการการเชื่อมต่อ นอกจากนี้ Envoy ยังสนับสนุนตัวกรองชั้น L7 สำหรับการรับส่งข้อมูลแบบ HTTP นอกจากนี้ Envoy ยังรองรับการขนส่ง HTTP/2 และ gRPC ระดับเฟิร์สคลาสอีกด้วย

ฟีเจอร์หลายอย่างที่ Istio จัดให้เป็นเมชบริการนั้น เปิดใช้งานจริงโดยฟีเจอร์ที่มีอยู่แล้วภายในของพร็อกซี Envoy:

• การควบคุมการรับส่งข้อมูล: Envoy เปิดใช้งานแอปพลิเคชันของการควบคุม การรับส่งข้อมูลแบบละเอียดด้วยกฎการกำหนดเส้นทางที่สมบูรณ์ สำหรับการรับส่งข้อมูล HTTP, gRPC, WebSocket และ TCP
• ความยืดหยุ่นของเครือข่าย: Envoy รองรับการทดลองใหม่แบบอัตโนมัติ การตัดวงจร และการแก้ไขข้อบกพร่อง
• ความปลอดภัย: Envoy ยังสามารถบังคับใช้นโยบายความปลอดภัยและใช้การควบคุมการเข้าถึงและการจำกัดอัตราการสื่อสารระหว่างบริการพื้นฐาน

อีกเหตุผลหนึ่งที่ Envoy ทำงานได้ดีกับ Istio ก็คือความสามารถในการขยาย โดยจัดเตรียมโมเดลส่วนขยายแบบเสียบได้โดยใช้ WebAssembly สิ่งนี้มีประโยชน์มากในการบังคับใช้นโยบายแบบกำหนดเองและการสร้างการวัดและส่งข้อมูลทางไกล นอกจากนี้ เรายังสามารถขยายพร็อกซี Envoy ใน Istio โดยใช้ส่วนขยายของ Istio ตาม Proxy-Wasm sandbox API

5.2. Control Plane

ดังที่เราได้เห็นก่อนหน้านี้ ระนาบควบคุมมีหน้าที่จัดการและกำหนดค่าพร็อกซี Envoy ในระนาบข้อมูล ส่วนประกอบที่รับผิดชอบสิ่งนี้ในระนาบควบคุมคือ istiod ที่รับผิดชอบในการแปลงกฎการกำหนดเส้นทางระดับสูงและพฤติกรรมการควบคุมทราฟฟิกเป็นการกำหนดค่าเฉพาะของ Envoy และเผยแพร่ไปยัง sidecars ที่รันไทม์

หากเราจำสถาปัตยกรรมของระนาบควบคุม Istio ได้ จะสังเกตเห็นว่าเคยเป็นส่วนประกอบอิสระที่ทำงานร่วมกัน ประกอบด้วย Pilot สำหรับการค้นพบบริการ, Galley สำหรับการกำหนดค่า, Citadel สำหรับการสร้างใบรับรอง และ Mixer สำหรับการขยาย เนื่องจากความซับซ้อน ส่วนประกอบแต่ละส่วน จึงถูกรวมเข้าเป็นองค์ประกอบเดียวกันที่เรียกว่า istiod

โดยพื้นฐานแล้ว istiod ยังคงใช้โค้ดและ API เดียวกันกับส่วนประกอบแต่ละส่วน ตัวอย่างเช่น Pilot มีหน้าที่รับผิดชอบในการสรุปกลไกการค้นพบบริการเฉพาะแพลตฟอร์มและสังเคราะห์ให้เป็นรูปแบบมาตรฐานที่สามารถใช้ได้ ดังนั้น Istio จึงสามารถรองรับการค้นพบได้ในหลายสภาพแวดล้อม เช่น Kubernetes หรือ Virtual Machines

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

6. Istio ทำงานอย่างไร

เราได้เรียนรู้ว่าคุณลักษณะทั่วไปของ SerivcesMesh คืออะไร นอกจากนี้เราได้ศึกษาพื้นฐานของสถาปัตยกรรม Istio และส่วนประกอบหลักแล้ว คราวนี้มาทำความเข้าใจว่า Istio นำเสนอคุณลักษณะเหล่านี้ผ่านองค์ประกอบหลักในสถาปัตยกรรมอย่างไร

เราจะเน้นที่คุณสมบัติหมวดหมู่เดียวกับที่ได้ดำเนินการไปก่อนหน้านี้

6.1. การจัดการทราฟฟิก

เราควบคุมการรับส่งข้อมูลในเครือข่ายบริการได้อย่างละเอียดโดยใช้ API การจัดการการรับส่งข้อมูลของ Istio เราสามารถใช้ API เหล่านี้เพื่อเพิ่มการกำหนดค่าการรับส่งข้อมูลของเราเองไปยัง Istio นอกจากนี้ เราสามารถกำหนดทรัพยากร API โดยใช้ทรัพยากรที่กำหนดเองของ Kubernetes (CRD) ทรัพยากร API หลักที่ช่วยเราควบคุมการกำหนดเส้นทางการรับส่งข้อมูล คือบริการเสมือนและกฎปลายทาง:

โดยพื้นฐานแล้ว บริการเสมือนช่วยให้เรากำหนดค่าวิธีส่งคำขอไปยังบริการภายใน SerivcesMesh ของ Istio ดังนั้น บริการเสมือนจึงประกอบด้วยกฎการกำหนดเส้นทาง ตั้งแต่หนึ่งกฎขึ้นไปที่ได้รับการประเมินตามลำดับ หลังจากประเมินกฎการกำหนดเส้นทางของบริการเสมือนแล้ว กฎปลายทางจะถูกนำไปใช้ กฎปลายทางช่วยให้เราควบคุมการรับส่งข้อมูลไปยังปลายทางได้ เช่น การจัดกลุ่มอินสแตนซ์ของบริการตามเวอร์ชัน

6.2. ความปลอดภัย

การรักษาความปลอดภัยใน Istio เริ่มต้นด้วยการจัดเตรียมข้อมูลประจำตัวที่รัดกุมให้กับทุกบริการ ตัวแทน Istio ที่ทำงานคู่กับพร็อกซี Envoy ทุกตัวทำงานร่วมกับ istiod เพื่อทำให้การหมุนเวียนคีย์และใบรับรองเป็นแบบอัตโนมัติ:

Istio มีการตรวจสอบสิทธิ์สองประเภท - การตรวจสอบสิทธิ์แบบเพียร์และการตรวจสอบคำขอ การตรวจสอบสิทธิ์แบบเพียร์ใช้สำหรับการตรวจสอบสิทธิ์บริการต่อบริการ โดยที่ Istio เสนอ TLS ร่วมกันเป็นโซลูชันแบบฟูลสแตก คำขอตรวจสอบสิทธิ์จะใช้สำหรับการตรวจสอบสิทธิ์ผู้ใช้ปลายทางโดยที่ Istio เสนอการตรวจสอบ JSON Web Token (JWT) โดยผู้ให้บริการตรวจสอบสิทธิ์แบบกำหนดเองหรือผู้ให้บริการ OpenID Connect (OIDC)

Istio ยังอนุญาตให้เราควบคุมการเข้าถึงบริการโดยใช้นโยบายการอนุญาตกับบริการ นโยบายการอนุญาตบังคับใช้การควบคุมการเข้าถึงการรับส่งข้อมูลขาเข้าในพร็อกซี Envoy ด้วยเหตุนี้ เราจึงสามารถใช้การควบคุมการเข้าถึงในระดับต่างๆ: SerivcesMesh เนมสเปซ และบริการทั้งหมด

6.3. การสังเกต

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

ก่อนหน้านี้ สถาปัตยกรรมการวัดและส่งข้อมูลทางไกลของ Istio ได้รวม Mixer เป็นส่วนประกอบหลัก แต่เริ่มต้นด้วย Telemetry v2 คุณลักษณะที่จัดเตรียมโดย Mixer ถูกแทนที่ด้วยปลั๊กอิน Envoy proxy:

นอกจากนี้ Istio ยังสร้างการติดตามแบบกระจายผ่านผู้รับมอบฉันทะของทูต Istio รองรับแบ็กเอนด์การติดตามจำนวนมาก เช่น Zipkin, Jaeger, Lightstep และ Datadog นอกจากนี้เรายังสามารถควบคุมอัตราการสุ่มตัวอย่างสำหรับการสร้างการติดตาม นอกจากนี้ Istio ยังสร้างบันทึกการเข้าถึงสำหรับการรับส่งข้อมูลบริการในรูปแบบชุดที่กำหนดค่าได้

7. ลงมือทำกับ Istio

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

7.1. การติดตั้ง

มีหลายวิธีในการติดตั้ง Istio แต่วิธีที่ง่ายที่สุด คือ การดาวน์โหลดและดึงข้อมูลรุ่นล่าสุดสำหรับระบบปฏิบัติการเฉพาะ เช่น Windows แพ็กเกจที่แยกออกมามีไบนารีไคลเอ็นต์ istioctl ในไดเร็กทอรี bin เราสามารถใช้ istioctl เพื่อติดตั้ง Istio บนคลัสเตอร์ Kubernetes เป้าหมายได้:

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

เรากำลังใช้ kubectl โดยสันนิษฐานว่าคลัสเตอร์ Kubernetes เช่น Minikube และ Kubernetes CLI kubectl มีอยู่ในเครื่องของเราแล้ว

7.2. ตัวอย่างการสมัคร

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

เราจะไม่ลงรายละเอียดเกี่ยวกับไมโครเซอร์วิสเหล่านี้ แต่สามารถสร้างได้ง่ายๆ โดยใช้ Spring Boot และ REST API สิ่งสำคัญที่สุดคือ เราสร้างอิมเมจ Docker สำหรับไมโครเซอร์วิส เพื่อให้เราสามารถปรับใช้บน Kubernetes

7.3. การปรับใช้

การปรับใช้ปริมาณงานที่มีคอนเทนเนอร์บนคลัสเตอร์ Kubernetes เช่น Minikube ค่อนข้างตรงไปตรงมา เราจะใช้ทรัพยากรและบริการเพื่อประกาศและเข้าถึงปริมาณงาน โดยปกติเรากำหนดไว้ในไฟล์ YAML:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

เนื่องจากเราได้เปิดใช้งานการฉีดอัตโนมัติของพร็อกซีไซด์คาร์ Envoy สำหรับเนมสเปซเริ่มต้น เราจะดูแลให้ทุกอย่าง หรืออีกทางหนึ่ง เราสามารถใช้คำสั่ง kube-inject ของ istioctl เพื่อฉีดพร็อกซีไซด์คาร์ Envoy ด้วยตนเอง

7.4. การเข้าถึงแอปพลิเคชัน

ตอนนี้ Istio รับผิดชอบในการจัดการการรับส่งข้อมูลแบบSerivcesMeshทั้งหมด ดังนั้นการรับส่งข้อมูลใดๆ ไปหรือออกจากภายนอกSerivcesMesh จะไม่ได้รับอนุญาตตามค่าเริ่มต้น Istio ใช้เกตเวย์เพื่อจัดการการรับส่งข้อมูลขาเข้าและขาออกจากเมช ด้วยวิธีนี้ เราสามารถควบคุมการจราจรที่เข้าหรือออกจากSerivcesMeshได้อย่างแม่นยำ Istio มีการปรับใช้พร็อกซีเกตเวย์ที่กำหนดค่าไว้ล่วงหน้า: istio-ingressgateway และ istio-egressgateway

เราจะสร้างเกตเวย์และบริการเสมือนสำหรับแอปพลิเคชัน เพื่อให้เกิดผลลัพธ์นี้:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8. กรณีใช้งานทั่วไปกับ Istio

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

8.1. ขอเส้นทาง

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

เราสามารถใช้กฎการกำหนดเส้นทางของบริการเสมือน เพื่อให้เกิดผลลัพธ์ตามนี้:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

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

8.2. Circuit Breaking

โดยทั่วไปแล้ว เบรกเกอร์จะเป็นรูปแบบการออกแบบซอฟต์แวร์เพื่อตรวจจับความล้มเหลวและสรุปสาเหตุในการป้องกันความล้มเหลวจากการเรียงซ้อนเพิ่มเติม ซึ่งช่วยในการสร้างแอปพลิเคชันไมโครเซอร์วิสที่ยืดหยุ่นซึ่งจำกัดผลกระทบของความล้มเหลวและความหน่วงแฝง

ใน Istio เราสามารถใช้การกำหนดค่า trafficPolicy ใน DestinationRule เพื่อใช้การตัดวงจรเมื่อเรียกใช้บริการ เช่น บริการสินค้าคงคลัง:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

โดยเราได้กำหนดค่า DestinationRule ด้วย maxConnections เป็น 1, httpMaxPendingRequests เป็น 1 และ maxRequestsPerConnection เป็น 1 ซึ่งหมายความว่าหากเรามีจำนวนคำขอพร้อมกันมากกว่า 1 รายการ เบรกเกอร์จะเริ่มดักฟังคำขอบางรายการ .

8.3. การเปิดใช้งาน TLS ร่วมกัน

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

แม้ว่า Istio จะอัปเกรดการรับส่งข้อมูลทั้งหมดระหว่างบริการที่มีพร็อกซีเป็น TLS ร่วมกันโดยอัตโนมัติ แต่บริการเหล่านี้ยังสามารถรับการรับส่งข้อมูลแบบข้อความธรรมดาได้ เรามีตัวเลือกในการบังคับใช้ TLS ทั้งแบบเมชร่วมกันด้วยนโยบาย PeerAuthentication:

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

นอกจากนี้เรายังมีตัวเลือกในการบังคับใช้ TLS ร่วมกันต่อเนมสเปซหรือบริการแทนการใช้ทั้งแบบเมช อย่างไรก็ตาม นโยบาย PeerAuthentication เฉพาะบริการ จะมีความสำคัญมากกว่านโยบายทั้งเนมสเปซ

8.4. การควบคุมการเข้าถึงด้วย JWT

JSON Web Token (JWT) เป็นมาตรฐานสำหรับการสร้างข้อมูลที่เพย์โหลดมี JSON ยืนยันการอ้างสิทธิ์จำนวนหนึ่ง สิ่งนี้ได้รับการยอมรับอย่างกว้างขวางในการส่งต่อข้อมูลและการอ้างสิทธิ์มาตรฐานหรือกำหนดเองของผู้ใช้ที่ตรวจสอบสิทธิ์ระหว่างผู้ให้บริการข้อมูลประจำตัวและผู้ให้บริการ

เราสามารถเปิดใช้นโยบายการอนุญาตใน Istio เพื่ออนุญาตให้เข้าถึงบริการ เช่น บริการจองตาม JWT:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["testing@standupcode.com/testing@standupcode.io"]

โดย AuthorizationPolicy บังคับใช้คำขอทั้งหมดเพื่อให้มี JWT ที่ถูกต้องโดยตั้งค่า requestPrincipal เป็นค่าเฉพาะ Istio สร้างแอตทริบิวต์ requestPrincipal โดยการรวมการอ้างสิทธิ์ iss และย่อยของ JWT

9. คำอธิบายเพิ่มเติม

ตอนนี้เราได้เห็นแล้วว่า service mesh อย่าง Istio ทำให้ชีวิตของเราง่ายขึ้นในการจัดการข้อกังวลทั่วไปในสถาปัตยกรรมแบบกระจาย เช่น ไมโครเซอร์วิส ได้อย่างไร แต่ถึงกระนั้น Istio ก็ยังเป็นระบบที่ซับซ้อนที่เพิ่มความซับซ้อนของการปรับใช้ที่เป็นผลลัพธ์ เช่นเดียวกับเทคโนโลยีอื่นๆ Istio ไม่ใช่สัญลักษณ์แสดงหัวข้อย่อย และต้องพิจารณาการใช้อย่างเหมาะสม

9.1. เราควรใช้ Service Mesh เป็นประจำหรือไม่?

แม้ว่าเราจะมองเห็นเหตุผลเพียงพอที่จะใช้บริการเมชแล้ว ลองมาเช็กเหตุผลที่อาจทำให้เราเลิกใช้เมชกันบ้าง:

ดังนั้น เรื่องราวของเครือข่ายบริการไม่ได้เกี่ยวกับผลประโยชน์ทั้งหมด แต่ไม่ได้หมายความว่าสิ่งเหล่านี้ไม่เป็นความจริง สิ่งสำคัญสำหรับเราคือการประเมินความต้องการและความซับซ้อนของแอปพลิเคชันอย่างรอบคอบ จากนั้นจึงชั่งน้ำหนักประโยชน์ของ SerivcesMesh กับความซับซ้อนที่เพิ่มขึ้น

9.2. อะไรคือทางเลือกแทน Istio?

แม้ว่า Istio จะค่อนข้างได้รับความนิยมและได้รับการสนับสนุนในอุตสาหกรรมนี้ แต่ก็ไม่ใช่ตัวเลือกเดียว ลองมาดูตัวเลือกสองอย่าง เช่น Linkerd และ Consul กัน

Linkerd เป็น SerivcesMesh โอเพ่นซอร์สที่สร้างขึ้นสำหรับแพลตฟอร์ม Kubernetes ค่อนข้างเป็นที่นิยมและมีสถานะเป็นโครงการในระยะเริ่มต้นใน CNCF ปัจจุบัน หลักการทำงานคล้ายกับบริการอื่นๆ เช่น Istio นอกจากนี้ยังใช้พร็อกซี TCP เพื่อจัดการการรับส่งข้อมูลแบบ SerivcesMesh Linkerd ใช้ micro-proxy ที่เขียนในภาษา Rust และรู้จักกันในชื่อ Linkerd-proxy

โดยรวมแล้ว Linkerd นั้นซับซ้อนน้อยกว่า Istio เนื่องจากรองรับเฉพาะ Kubernetes เท่านั้น แต่นอกเหนือจากนั้น รายการคุณลักษณะที่มีใน Linkerd จะคล้ายกับคุณลักษณะที่มีอยู่ใน Istio มาก สถาปัตยกรรมหลักของ Linkerd มีความคล้ายคลึงกับ Istio มาก แต่โดยพื้นฐานแล้ว Linkerd ประกอบด้วยองค์ประกอบหลักสามส่วน: interface, a data plane และ a control plane

Consul เป็นการใช้งานโอเพ่นซอร์สของบริการเมชจาก HashiCorp มีประโยชน์ในการผสานรวมกับชุดผลิตภัณฑ์การจัดการโครงสร้างพื้นฐานอื่นๆ จาก HashiCorp เพื่อให้มีความสามารถที่กว้างขึ้น data plane ใน Consul มีความยืดหยุ่นในการสนับสนุนพร็อกซี่และโมเดลการรวมแบบเนทีฟ โดยมาพร้อมกับพร็อกซีในตัว แต่สามารถทำงานได้ดีกับ Envoy เช่นกัน

นอกจาก Kubernetes แล้ว Consul ยังได้รับการออกแบบให้ทำงานร่วมกับแพลตฟอร์มอื่นๆ เช่น Nomad และทำงานโดยเรียกใช้ตัวแทนในทุกโหนดเพื่อดำเนินการตรวจสอบสภาพ ตัวแทนเหล่านี้พูดคุยกับเซิร์ฟเวอร์ Consul อย่างน้อยหนึ่งเซิร์ฟเวอร์ที่จัดเก็บและทำซ้ำข้อมูล แม้ว่าจะมีคุณสมบัติมาตรฐานทั้งหมดของ SerivcesMesh เช่น Istio แต่ก็เป็นระบบที่ซับซ้อนกว่าในการปรับใช้และจัดการ

10. บทสรุป

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