วิธีเชื่อมต่อคลัสเตอร์ Kubernetes ในศูนย์ข้อมูลต่างๆ

ยินดีต้อนรับสู่ซีรีส์ Kubernetes Quick Start ของเรา นี่เป็นคอลัมน์ปกติที่มีคำถามที่น่าสนใจที่สุดที่เราได้รับทางออนไลน์และในการฝึกอบรมของเรา คำตอบจากผู้เชี่ยวชาญ Kubernetes

ผู้เชี่ยวชาญวันนี้คือ Daniel Polenchik (ดานิเอเล่ โปเลนซิช). Daniel ทำงานเป็นผู้สอนและนักพัฒนาซอฟต์แวร์ที่ Learnk8s.

หากคุณต้องการตอบคำถามของคุณในโพสต์ถัดไป ติดต่อเราทางอีเมล หรือ ทวิตเตอร์: @learnk8s.

พลาดกระทู้ที่แล้วเหรอ? ค้นหาได้ที่นี่.

จะเชื่อมต่อคลัสเตอร์ Kubernetes ในศูนย์ข้อมูลต่างๆ ได้อย่างไร

สั้น: Kubefed v2 จะมาเร็วๆ นี้และฉันยังแนะนำให้อ่านเกี่ยวกับ พ่อค้าส่งของ и โครงการตัวกำหนดเวลาหลายคลัสเตอร์.

บ่อยครั้งที่โครงสร้างพื้นฐานถูกจำลองและกระจายไปทั่วภูมิภาคต่างๆ โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมที่มีการควบคุม

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

เมื่อใช้ Kubernetes คุณจะใช้กลยุทธ์ที่คล้ายกันและกระจายปริมาณงานไปยังภูมิภาคต่างๆ ได้

คุณสามารถมีได้ตั้งแต่หนึ่งคลัสเตอร์ขึ้นไปต่อทีม ภูมิภาค สภาพแวดล้อม หรือองค์ประกอบเหล่านี้รวมกัน

คลัสเตอร์ของคุณสามารถโฮสต์ในระบบคลาวด์และภายในองค์กรที่แตกต่างกันได้

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

กลุ่มผู้นำกลุ่มหนึ่ง

การสร้างคลัสเตอร์เดียวบนเครือข่ายเดียวไม่ใช่เรื่องง่าย

ลองจินตนาการว่าคุณเกิดอุบัติเหตุ การเชื่อมต่อระหว่างกลุ่มคลัสเตอร์ขาดหายไป

หากคุณมีเซิร์ฟเวอร์หลักหนึ่งเซิร์ฟเวอร์ ทรัพยากรครึ่งหนึ่งจะไม่สามารถรับคำสั่งใหม่ได้ เนื่องจากจะไม่สามารถติดต่อกับเซิร์ฟเวอร์หลักได้

และในขณะเดียวกัน คุณก็ยังมีตารางเส้นทางเก่า (kube-proxy ไม่สามารถดาวน์โหลดอันใหม่ได้) และไม่มีพ็อดเพิ่มเติม (kubelet ไม่สามารถขอการอัปเดตได้)

ที่แย่กว่านั้นคือ หาก Kubernetes ไม่เห็นโหนด จะทำเครื่องหมายว่าเป็นโหนดที่ไม่มีเจ้าของ และกระจายพ็อดที่หายไปไปยังโหนดที่มีอยู่

เป็นผลให้คุณมีพ็อดเพิ่มขึ้นสองเท่า

หากคุณสร้างเซิร์ฟเวอร์หลักหนึ่งเซิร์ฟเวอร์สำหรับแต่ละภูมิภาค จะมีปัญหากับอัลกอริทึมที่เป็นเอกฉันท์ในฐานข้อมูล etcd (ประมาณ เอ็ด — อันที่จริง ฐานข้อมูล etcd ไม่จำเป็นต้องอยู่บนเซิร์ฟเวอร์หลักเสมอไป สามารถทำงานบนกลุ่มเซิร์ฟเวอร์ที่แยกจากกันในภูมิภาคเดียวกันได้ จริงอยู่ในขณะเดียวกันก็ได้รับจุดล้มเหลวของคลัสเตอร์ แต่อย่างรวดเร็ว)

ฯลฯ ใช้ อัลกอริธึมแพเพื่อเจรจาค่าก่อนที่จะเขียนลงดิสก์
นั่นคือ กรณีส่วนใหญ่จะต้องได้รับความเห็นพ้องต้องกันก่อนจึงจะสามารถเขียนรัฐถึง ฯลฯ ได้

หากเวลาแฝงระหว่างอินสแตนซ์ ฯลฯ เพิ่มขึ้นอย่างมาก เช่นเดียวกับกรณีที่มีอินสแตนซ์ ฯลฯ สามรายการในภูมิภาคที่แตกต่างกัน จะใช้เวลานานในการเจรจาค่าและเขียนลงดิสก์
สิ่งนี้สะท้อนให้เห็นในตัวควบคุม Kubernetes

ผู้จัดการคอนโทรลเลอร์ต้องการเวลาเพิ่มเติมในการเรียนรู้เกี่ยวกับการเปลี่ยนแปลงและเขียนการตอบกลับไปยังฐานข้อมูล

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

etcd มีความอ่อนไหวต่อเวลาแฝงมาก เอกสารอย่างเป็นทางการแนะนำให้ใช้ SSD แทนฮาร์ดไดรฟ์ทั่วไป.

ขณะนี้ยังไม่มีตัวอย่างที่ดีของเครือข่ายขนาดใหญ่สำหรับคลัสเตอร์เดียว

โดยพื้นฐานแล้ว ชุมชนนักพัฒนาซอฟต์แวร์และกลุ่มคลัสเตอร์ SIG กำลังพยายามค้นหาวิธีการจัดระเบียบคลัสเตอร์ในลักษณะเดียวกับที่ Kubernetes จัดระเบียบคอนเทนเนอร์

ตัวเลือกที่ 1: การรวมคลัสเตอร์ด้วย kubefed

การตอบสนองอย่างเป็นทางการจาก SIG-cluster - kubefed2 เวอร์ชันใหม่ของไคลเอ็นต์และตัวดำเนินการสหพันธรัฐ kube ดั้งเดิม.

เป็นครั้งแรกที่เราพยายามจัดการคอลเลกชันของคลัสเตอร์เป็นออบเจ็กต์เดียวโดยใช้เครื่องมือ kube federation

เริ่มต้นได้ดี แต่ท้ายที่สุดแล้ว สหพันธ์ kube ไม่เคยได้รับความนิยมเพราะไม่สนับสนุนทรัพยากรทั้งหมด

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

ลองนึกภาพว่าคุณจะอธิบายการแบ่งพาร์ติชันเรพลิกาสำหรับแต่ละคลัสเตอร์ในสหพันธรัฐโดยใช้เพียงคำอธิบายประกอบได้อย่างไร

มันเป็นระเบียบอย่างสมบูรณ์

SIG-cluster ทำงานหนักมากหลังจาก kubefed v1 และตัดสินใจแก้ไขปัญหาจากมุมที่ต่างออกไป

แทนที่จะใส่คำอธิบายประกอบ พวกเขาตัดสินใจปล่อยคอนโทรลเลอร์ที่ติดตั้งบนคลัสเตอร์ สามารถปรับแต่งได้โดยใช้ Custom Resource Definitions (CRD)

สำหรับแต่ละทรัพยากรที่จะเป็นส่วนหนึ่งของสหพันธรัฐ คุณมีคำจำกัดความ CRD ที่กำหนดเองซึ่งมีสามส่วน:

• คำจำกัดความมาตรฐานของทรัพยากร เช่น การใช้งาน
• ส่วน placementโดยที่คุณกำหนดวิธีการกระจายทรัพยากรในสหพันธรัฐ
• ส่วน overrideโดยที่สำหรับทรัพยากรเฉพาะ คุณสามารถแทนที่น้ำหนักและพารามิเตอร์จากตำแหน่งได้

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

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

อย่างที่คุณเห็น การจัดหามีการกระจายไปยังสองคลัสเตอร์: cluster1 и cluster2.

คลัสเตอร์แรกมีเรพลิกาสามรายการ และคลัสเตอร์ที่สองตั้งค่าเป็น 5

หากคุณต้องการควบคุมจำนวนเรพลิกาได้มากขึ้น kubefed2 จะจัดเตรียมออบเจ็กต์ ReplicaSchedulingPreference ใหม่ที่สามารถชั่งน้ำหนักเรพลิกาได้:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

โครงสร้าง CRD และ API ยังไม่พร้อม และงานที่กำลังดำเนินการอยู่ในพื้นที่เก็บข้อมูลโครงการอย่างเป็นทางการ

จับตาดู kubefed2 แต่จำไว้ว่ายังไม่เหมาะสำหรับการผลิต

เรียนรู้เพิ่มเติมเกี่ยวกับ kubefed2 จาก บทความอย่างเป็นทางการเกี่ยวกับ kubefed2 ในบล็อกเกี่ยวกับ Kubernetes และใน พื้นที่เก็บข้อมูลอย่างเป็นทางการของโครงการ kubefed.

ตัวเลือกที่ 2: รวมคลัสเตอร์ในลักษณะของ Booking.com

นักพัฒนาของ Booking.com ไม่ได้ทำงานบน kubefed v2 แต่ได้มาพร้อมกับ Shipper ซึ่งเป็นผู้ดำเนินการสำหรับการจัดส่งบนหลายคลัสเตอร์ ในหลายภูมิภาค และในระบบคลาวด์หลายแห่ง

พ่อค้าส่งของ ค่อนข้างคล้ายกับ kubefed2

เครื่องมือทั้งสองช่วยให้คุณสามารถปรับแต่งกลยุทธ์การปรับใช้หลายคลัสเตอร์ของคุณได้ (คลัสเตอร์ใดที่ใช้และจำนวนแบบจำลองที่มี)

แต่ เป้าหมายของผู้จัดส่งคือการลดความเสี่ยงของข้อผิดพลาดระหว่างการจัดส่ง

ใน Shipper คุณสามารถกำหนดชุดขั้นตอนที่อธิบายการแบ่งแบบจำลองระหว่างการใช้งานก่อนหน้าและปัจจุบันกับปริมาณการรับส่งข้อมูลขาเข้า

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

นอกจากนี้ผู้จัดส่งยังมีข้อจำกัดมาก

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

แทนที่จะจัดส่งแบบมาตรฐาน คุณต้องสร้างทรัพยากรแอปพลิเคชันที่มีแผนภูมิ Helm:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper เป็นตัวเลือกที่ดีสำหรับการจัดการหลายคลัสเตอร์ แต่ความสัมพันธ์ที่ใกล้ชิดกับ Helm กลับเป็นอุปสรรคเท่านั้น

จะเป็นอย่างไรถ้าเราเปลี่ยนจาก Helm เป็น ปรับแต่ง หรือ กัปตัน?

ค้นหาข้อมูลเพิ่มเติมเกี่ยวกับ Shipper และปรัชญาได้ที่ ข่าวประชาสัมพันธ์อย่างเป็นทางการนี้.

หากคุณต้องการเจาะลึกโค้ด มุ่งหน้าไปยังพื้นที่เก็บข้อมูลโครงการอย่างเป็นทางการ.

ตัวเลือกที่ 3: การรวมคลัสเตอร์ "เวทย์มนตร์"

Kubefed v2 และ Shipper ทำงานร่วมกับการรวมคลัสเตอร์ โดยจัดหาทรัพยากรใหม่ให้กับคลัสเตอร์ผ่านการกำหนดทรัพยากรแบบกำหนดเอง

แต่ถ้าคุณไม่ต้องการเขียนการส่งมอบ, StatefulSets, DaemonSets ฯลฯ ทั้งหมดใหม่เพื่อรวมเข้าด้วยกันล่ะ

จะรวมคลัสเตอร์ที่มีอยู่ในสหพันธรัฐโดยไม่ต้องเปลี่ยน YAML ได้อย่างไร

multi-cluster-scheduler เป็นโครงการ Admiralityซึ่งเกี่ยวข้องกับการกำหนดเวลาปริมาณงานบนคลัสเตอร์

แต่แทนที่จะคิดวิธีใหม่ในการโต้ตอบกับคลัสเตอร์และรวมทรัพยากรในคำจำกัดความที่กำหนดเอง ตัวกำหนดเวลาหลายคลัสเตอร์จะถูกฝังอยู่ในวงจรการใช้งาน Kubernetes มาตรฐานและดักฟังการโทรทั้งหมดที่สร้างพ็อด

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

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

พ็อดดั้งเดิมต้องผ่านวงจรการวางแผนอื่น ซึ่งหลังจากการสำรวจความคิดเห็นของสหพันธ์ทั้งหมดแล้ว จึงมีการตัดสินใจวางตำแหน่ง

ในที่สุดพ็อดก็ถูกส่งไปยังคลัสเตอร์เป้าหมาย

เป็นผลให้คุณมีพ็อดพิเศษที่ไม่ทำอะไรเลย แค่กินพื้นที่เท่านั้น

ข้อดีคือคุณไม่จำเป็นต้องเขียนทรัพยากรใหม่เพื่อรวมวัสดุสิ้นเปลือง

ทรัพยากรแต่ละรายการที่สร้างพ็อดจะพร้อมสำหรับการผสานโดยอัตโนมัติ

สิ่งนี้น่าสนใจ เพราะจู่ๆ คุณมีสิ่งของแจกจ่ายไปทั่วหลายภูมิภาคโดยที่คุณไม่ได้สังเกตด้วยซ้ำ อย่างไรก็ตาม นี่ค่อนข้างเสี่ยง เพราะทุกอย่างที่นี่อาศัยเวทย์มนตร์

แต่ในขณะที่ผู้จัดส่งพยายามลดผลกระทบของการส่งมอบเป็นส่วนใหญ่ แต่ตัวกำหนดเวลาแบบหลายคลัสเตอร์จะจัดการกับงานทั่วไปมากกว่า และอาจเหมาะสมกับงานแบบแบตช์มากกว่า

ไม่มีกลไกการจัดส่งแบบค่อยเป็นค่อยไปขั้นสูง

สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับ multi-cluster-scheduler ได้ที่ หน้าพื้นที่เก็บข้อมูลอย่างเป็นทางการ.

หากคุณต้องการอ่านเกี่ยวกับการทำงานของตัวกำหนดเวลาหลายคลัสเตอร์ Admiralty มี กรณีการใช้งานที่น่าสนใจกับ Argo — เวิร์กโฟลว์ กิจกรรม CI และ CD Kubernetes

เครื่องมือและโซลูชั่นอื่นๆ

การเชื่อมต่อและการจัดการหลายคลัสเตอร์เป็นงานที่ซับซ้อน และไม่มีโซลูชันแบบสากล

หากคุณต้องการสำรวจหัวข้อนี้เพิ่มเติม ต่อไปนี้เป็นแหล่งข้อมูลบางส่วน:

• เรือดำน้ำโดย Rancher เป็นเครื่องมือที่เชื่อมต่อเครือข่ายซ้อนทับของคลัสเตอร์ Kubernetes ต่างๆ
• การใช้เป้าหมายของเครือข่ายค้าปลีก Unimatrix รวมกับ Spinnaker เพื่อประสานการปรับใช้ข้ามหลายคลัสเตอร์.
• ลองใช้ IPV6 และ เครือข่ายเดียวในหลายภูมิภาค.
• คุณสามารถใช้ service mesh ได้ เป็นต้น Istio สำหรับการเชื่อมต่อหลายคลัสเตอร์.
• Cilium ข้อเสนอปลั๊กอินอินเทอร์เฟซเครือข่ายคอนเทนเนอร์ ฟังก์ชั่นตาข่ายคลัสเตอร์ซึ่งช่วยให้คุณสามารถรวมหลายคลัสเตอร์เข้าด้วยกัน

นั่นคือทั้งหมดสำหรับวันนี้

ขอบคุณที่อ่านจนจบ!

หากคุณรู้วิธีการเชื่อมต่อหลายคลัสเตอร์อย่างมีประสิทธิภาพมากขึ้น บอกพวกเรา.

เราจะเพิ่มวิธีการของคุณลงในลิงก์

ขอขอบคุณเป็นพิเศษกับ Chris Nesbitt-Smith (คริส เนสบิตต์-สมิธ) และวินเซนต์ เดอ สเม (วินเซนต์ เดอ สเม็ต) (วิศวกรความน่าเชื่อถือใน swatmobile.io) เพื่ออ่านบทความและแบ่งปันข้อมูลที่เป็นประโยชน์เกี่ยวกับวิธีการทำงานของสหพันธ์

ที่มา: will.com