หญิงสาวบนสกู๊ตเตอร์ ภาพประกอบ Freepik, โลโก้ Nomad จาก ฮาชิ คอร์ป

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

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

คุณต้องการอะไร

ทีมงานของเราสนับสนุนบริการตรวจสอบและวิเคราะห์ประสิทธิภาพทั่วไปจำนวนหนึ่ง: จุดสิ้นสุด API สำหรับหน่วยวัดที่เขียนใน Go, การส่งออก Prometheus, ตัวแยกวิเคราะห์บันทึก เช่น Logstash และ กอลลัมรวมถึงฐานข้อมูล เช่น InfluxDB หรือ Elasticsearch แต่ละบริการเหล่านี้ทำงานในคอนเทนเนอร์ของตัวเอง เราต้องการระบบที่เรียบง่ายเพื่อให้ทุกอย่างทำงานต่อไป

เราเริ่มต้นด้วยรายการข้อกำหนดสำหรับการจัดการคอนเทนเนอร์:

• ใช้งานชุดบริการบนเครื่องหลายเครื่อง
• ภาพรวมของบริการที่ทำงานอยู่
• การเชื่อมโยงระหว่างบริการ
• รีสตาร์ทอัตโนมัติหากบริการหยุดทำงาน
• การบำรุงรักษาโครงสร้างพื้นฐานโดยทีมงานขนาดเล็ก

นอกจากนี้สิ่งต่อไปนี้จะดี แต่ไม่จำเป็นต้องเพิ่มเติม:

• เครื่องติดแท็กตามความสามารถ (เช่น เครื่องติดแท็กด้วยดิสก์ที่รวดเร็วสำหรับบริการ I/O จำนวนมาก)
• ความสามารถในการเรียกใช้บริการโดยอิสระจากผู้จัดทำ (เช่น ระหว่างการพัฒนา)
• สถานที่ทั่วไปสำหรับแชร์การกำหนดค่าและความลับ
• จุดสิ้นสุดสำหรับเมตริกและบันทึก

ทำไม Kubernetes ถึงไม่เหมาะกับเรา

ขณะที่เราสร้างต้นแบบด้วย Kubernetes เราสังเกตเห็นว่าเรากำลังเพิ่มเลเยอร์ตรรกะที่ซับซ้อนมากขึ้นซึ่งเราอาศัยอย่างมาก

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

นอกจากนี้ ระบบนิเวศของ Kubernetes ยังมีการพัฒนาอย่างรวดเร็ว ต้องใช้เวลาและความพยายามอย่างมากในการติดตามแนวทางปฏิบัติที่ดีที่สุดและเครื่องมือล่าสุด Kubectl, minikube, kubeadm, หางเสือ, รถไถเดินตาม, kops, oc - รายการดำเนินต่อไปเรื่อยๆ เครื่องมือเหล่านี้ไม่จำเป็นทั้งหมดเมื่อคุณเริ่มต้น แต่คุณไม่รู้ว่าจะต้องใช้อะไรบ้าง ดังนั้นคุณจึงต้องตระหนักถึงทุกสิ่ง ด้วยเหตุนี้ เส้นโค้งการเรียนรู้จึงค่อนข้างชัน

เมื่อใดควรใช้ Kubernetes

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

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

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

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

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

ไม่รวมแบตเตอรี่

Nomad คือ 20% ของการจัดการที่จัดเตรียม 80% ของสิ่งที่จำเป็น สิ่งที่ต้องทำคือจัดการการปรับใช้ Nomad ดูแลเรื่องการปรับใช้ รีสตาร์ทคอนเทนเนอร์ในกรณีที่เกิดข้อผิดพลาด... เท่านี้ก็เรียบร้อย

ประเด็นสำคัญของ Nomad คือสิ่งที่มันทำ ขั้นต่ำ: ไม่มีการจัดการสิทธิ์แบบละเอียดหรือ นโยบายเครือข่ายแบบขยายได้รับการออกแบบมาเป็นพิเศษ ส่วนประกอบเหล่านี้มีให้จากภายนอกหรือไม่มีเลย

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

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

ระบบนิเวศเร่ร่อนขององค์ประกอบคู่ที่หลวม

จุดแข็งที่แท้จริงของ Nomad คือระบบนิเวศของมัน สามารถทำงานร่วมกับผลิตภัณฑ์อื่นๆ ที่เป็นอุปกรณ์เสริมได้อย่างสมบูรณ์ เช่น กงสุล (ที่เก็บคีย์-ค่า) หรือ หกคะเมน (กำลังประมวลผลความลับ) ภายในไฟล์ Nomad มีส่วนสำหรับดึงข้อมูลจากบริการเหล่านี้:

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

ที่นี่เราอ่านกุญแจ service/geo-api/log-verbosity จากกงสุลและในขณะที่ทำงาน เราจะเปิดเผยมันกับตัวแปรสภาพแวดล้อม LOG_LEVEL. เรายังนำเสนอกุญแจ secret/geo-api-key จากห้องนิรภัยเป็น API_KEY. เรียบง่ายแต่ทรงพลัง!

เนื่องจากความเรียบง่าย Nomad จึงสามารถขยายบริการอื่น ๆ ผ่าน API ได้อย่างง่ายดาย ตัวอย่างเช่น รองรับแท็กสำหรับงาน เราแท็กบริการทั้งหมดด้วยตัวชี้วัด trv-metrics. วิธีนี้ทำให้ Prometheus สามารถค้นหาบริการเหล่านี้ได้อย่างง่ายดายผ่านทางกงสุล และตรวจสอบจุดสิ้นสุดเป็นระยะ /metrics สำหรับข้อมูลใหม่ สามารถทำได้เช่นเดียวกันสำหรับบันทึกโดยใช้ โลกิ.

มีตัวอย่างอื่นๆ มากมายของความสามารถในการขยาย:

• รันงาน Jenkins โดยใช้ hook และกงสุลจะตรวจสอบการปรับใช้งาน Nomad อีกครั้งเมื่อการกำหนดค่าบริการเปลี่ยนไป
• Ceph เพิ่มระบบไฟล์แบบกระจายให้กับ Nomad
• Fabio สำหรับการบาลานซ์โหลด

ทั้งหมดนี้ช่วยให้ พัฒนาโครงสร้างพื้นฐานแบบออร์แกนิก โดยไม่มีการเชื่อมต่อพิเศษใดๆ กับผู้ขาย

คำเตือนที่เป็นธรรม

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

เมื่อเปรียบเทียบกับ Kubernetes ชุมชน Nomad มีขนาดไม่ใหญ่นัก Kubernetes มีคอมมิตประมาณ 75 คอมมิตและผู้มีส่วนร่วม 000 คน ในขณะที่ Nomad มีคอมมิตประมาณ 2000 คอมมิตและผู้มีส่วนร่วม 14 คน Nomad จะมีช่วงเวลาที่ยากลำบากในการตามความเร็วของ Kubernetes แต่บางทีอาจไม่จำเป็นต้องเป็นเช่นนั้น! มันเป็นระบบที่มีความเชี่ยวชาญมากกว่า และชุมชนขนาดเล็กยังหมายความว่าคำขอดึงของคุณมีแนวโน้มที่จะได้รับการสังเกตและยอมรับมากกว่า เมื่อเปรียบเทียบกับ Kubernetes

สรุป

ประเด็นสำคัญ: อย่าใช้ Kubernetes เพียงเพราะใครๆ ก็ทำกัน ประเมินความต้องการของคุณอย่างรอบคอบและตรวจสอบว่าเครื่องมือใดมีประโยชน์มากกว่า

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

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

หากเปรียบเทียบ Kubernetes กับรถยนต์ Nomad ก็คงเป็นสกู๊ตเตอร์ บางครั้งคุณต้องการสิ่งหนึ่งและบางครั้งคุณก็ต้องการอีกสิ่งหนึ่ง ทั้งสองมีสิทธิที่จะดำรงอยู่

ที่มา: will.com