เฮ้ ฮับ!
เราเป็นตัวแทนของทีมงานแพลตฟอร์ม Exness ก่อนหน้านี้เพื่อนร่วมงานของเราได้เขียนบทความเกี่ยวกับ . วันนี้เราต้องการแบ่งปันประสบการณ์ในการย้ายบริการไปยัง Kubernetes
ขั้นแรก เราเสนอตัวเลขบางส่วนเพื่อความเข้าใจที่ดีขึ้นเกี่ยวกับสิ่งที่จะมีการพูดคุยกัน:
- แผนกพัฒนาของเราประกอบด้วยบุคลากรมากกว่า 100 คน รวมถึงทีมที่แตกต่างกันมากกว่า 10 ทีมที่มีกระบวนการ QA, DevOps และ Scrum แบบพึ่งพาตนเองได้ สแต็กการพัฒนา - Python, PHP, C++, Java และ Golang
- ขนาดของสภาพแวดล้อมการทดสอบและการใช้งานจริงมีขนาดประมาณ 2000 ตู้คอนเทนเนอร์ต่อตู้ พวกเขากำลังใช้งาน Rancher v1.6 บนระบบเสมือนจริงของตัวเองและภายใต้ VMware
แรงจูงใจ
อย่างที่พวกเขาพูดกันว่าไม่มีอะไรคงอยู่ตลอดไปและ Rancher ก็ประกาศยุติการสนับสนุนเวอร์ชัน 1.6 เมื่อนานมาแล้ว ใช่ เป็นเวลากว่าสามปีแล้วที่เราได้เรียนรู้วิธีเตรียมตัวและแก้ไขปัญหาที่เกิดขึ้น แต่บ่อยครั้งมากขึ้นที่เราต้องเผชิญกับปัญหาที่ไม่เคยได้รับการแก้ไข Rancher 1.6 ยังมีระบบการออกสิทธิที่แข็งตัวซึ่งคุณสามารถทำทุกอย่างหรือทำอะไรก็ได้เกือบทุกอย่าง
แม้ว่าการจำลองเสมือนที่เป็นเอกสิทธิ์จะให้การควบคุมพื้นที่จัดเก็บข้อมูลและความปลอดภัยของพื้นที่ได้มากขึ้น แต่ก็ทำให้มีต้นทุนการดำเนินงานที่ยอมรับได้ยาก เนื่องจากบริษัทมีการเติบโตอย่างต่อเนื่อง จำนวนโครงการ และข้อกำหนดสำหรับพวกเขา
เราต้องการปฏิบัติตามมาตรฐาน IaC และรับกำลังการผลิตได้อย่างรวดเร็ว หากจำเป็น ในตำแหน่งทางภูมิศาสตร์ใดๆ และไม่มีการล็อคผู้จำหน่าย และยังสามารถละทิ้งกำลังการผลิตได้อย่างรวดเร็วอีกด้วย
ขั้นตอนแรก
ก่อนอื่น เราต้องการพึ่งพาเทคโนโลยีและโซลูชันที่ทันสมัยซึ่งจะช่วยให้ทีมมีวงจรการพัฒนาที่รวดเร็วขึ้น และลดต้นทุนการดำเนินงานสำหรับการโต้ตอบกับแพลตฟอร์มที่ให้พลังงาน
แน่นอนว่าสิ่งแรกที่เรานึกถึงคือ Kubernetes แต่เราไม่ได้รู้สึกตื่นเต้นและทำการค้นคว้าข้อมูลเล็กๆ น้อยๆ เพื่อดูว่านี่เป็นตัวเลือกที่ถูกต้องหรือไม่ เราประเมินเฉพาะโซลูชันโอเพ่นซอร์สเท่านั้น และในการต่อสู้ที่ไม่ยุติธรรม Kubernetes ก็ได้รับชัยชนะอย่างไม่มีเงื่อนไข
ถัดมาเป็นคำถามในการเลือกเครื่องมือสำหรับสร้างคลัสเตอร์ เราเปรียบเทียบโซลูชันยอดนิยม: kops, kubespray, kubeadm
ในการเริ่มต้น kubeadm ดูเหมือนเส้นทางที่ซับซ้อนเกินไปสำหรับเรา ค่อนข้างเหมือนกับผู้ประดิษฐ์ "จักรยาน" และ kops ก็ไม่มีความยืดหยุ่นเพียงพอ
และผู้ชนะคือ:
เราเริ่มทดลองกับการจำลองเสมือนและ AWS ของเราเอง โดยพยายามสร้างสิ่งที่คล้ายกับรูปแบบการจัดการทรัพยากรครั้งก่อนของเราขึ้นมาใหม่ โดยที่ทุกคนใช้ "คลัสเตอร์" เดียวกัน และตอนนี้เรามีคลัสเตอร์แรกซึ่งประกอบด้วยเครื่องเสมือนขนาดเล็ก 10 เครื่อง ซึ่งสองสามเครื่องอยู่ใน AWS เราเริ่มพยายามย้ายทีมไปที่นั่น ทุกอย่างดูเหมือนจะ "ดี" และเรื่องราวก็จบลง แต่...
ปัญหาแรก
Ansible คือสิ่งที่ kubespray สร้างขึ้น ไม่ใช่เครื่องมือที่ช่วยให้คุณติดตาม IaC ได้: เมื่อทดสอบการใช้งาน/เลิกใช้งานโหนด มีบางอย่างผิดพลาดตลอดเวลาและจำเป็นต้องมีการแทรกแซงบางประเภท และเมื่อใช้ OS ที่แตกต่างกัน Playbook จะมีพฤติกรรมแตกต่างออกไป แตกต่างกัน . เมื่อจำนวนทีมและโหนดในคลัสเตอร์เพิ่มขึ้น เราเริ่มสังเกตเห็นว่า Playbook ใช้เวลาดำเนินการนานขึ้นเรื่อยๆ และผลก็คือ บันทึกของเราคือ 3,5 ชั่วโมง แล้วของคุณล่ะ? 🙂
และดูเหมือนว่า kubespray นั้นเป็นเพียง Ansible และทุกอย่างชัดเจนตั้งแต่แรกเห็น แต่:
ในช่วงเริ่มต้นของการเดินทาง ภารกิจคือการเปิดใช้ความสามารถเฉพาะใน AWS และในการจำลองเสมือน แต่ข้อกำหนดก็เปลี่ยนไปตามที่เกิดขึ้นบ่อยครั้ง
ด้วยเหตุนี้ จึงเห็นได้ชัดว่ารูปแบบเก่าของเราในการรวมทรัพยากรเข้าไว้ในระบบการจัดการเดียวนั้นไม่เหมาะสม - ในกรณีที่คลัสเตอร์อยู่ห่างไกลมากและได้รับการจัดการโดยผู้ให้บริการที่แตกต่างกัน
นอกจากนี้. เมื่อทุกทีมทำงานภายในคลัสเตอร์เดียวกัน บริการต่างๆ ที่ติดตั้ง NodeSelectors ไม่ถูกต้องสามารถบินไปยังโฮสต์ “ต่างประเทศ” ของทีมอื่นและใช้ทรัพยากรที่นั่นได้ และหากตั้งค่าความเสียหายไว้ ก็จะมีคำขออย่างต่อเนื่องว่าบริการหนึ่งหรือบริการอื่นไม่ทำงาน กระจายไม่ถูกต้องเนื่องจากปัจจัยมนุษย์ ปัญหาอีกประการหนึ่งคือการคำนวณต้นทุน โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงปัญหาในการกระจายบริการข้ามโหนด
อีกเรื่องหนึ่งคือการให้สิทธิ์แก่พนักงาน: แต่ละทีมต้องการที่จะ "เป็นหัวหน้า" ของคลัสเตอร์และจัดการคลัสเตอร์อย่างสมบูรณ์ ซึ่งอาจทำให้เกิดการล่มสลายโดยสิ้นเชิง เนื่องจากโดยพื้นฐานแล้วแต่ละทีมเป็นอิสระจากกัน
จะทำอย่างไร?
เมื่อคำนึงถึงสิ่งที่กล่าวมาข้างต้นและความปรารถนาของทีมที่จะเป็นอิสระมากขึ้น เราได้ข้อสรุปง่ายๆ: หนึ่งทีม - หนึ่งคลัสเตอร์
ดังนั้นเราจึงได้อันที่สอง:
แล้วกลุ่มที่สาม:
จากนั้นเราก็เริ่มคิดว่า สมมุติว่าภายในหนึ่งปีทีมของเราจะมีมากกว่าหนึ่งคลัสเตอร์? ในพื้นที่ทางภูมิศาสตร์ที่แตกต่างกัน เช่น หรืออยู่ภายใต้การควบคุมของผู้ให้บริการที่แตกต่างกัน และบางส่วนต้องการปรับใช้คลัสเตอร์ชั่วคราวอย่างรวดเร็วสำหรับการทดสอบบางอย่าง
Kubernetes เต็มรูปแบบจะมา! นี่คือ MultiKubernetes บางประเภทปรากฎ
ในเวลาเดียวกัน เราทุกคนจะต้องดูแลรักษาคลัสเตอร์เหล่านี้ทั้งหมด สามารถจัดการการเข้าถึงคลัสเตอร์เหล่านี้ได้อย่างง่ายดาย ตลอดจนสร้างคลัสเตอร์ใหม่และรื้อถอนคลัสเตอร์เก่าโดยไม่ต้องมีการแทรกแซงด้วยตนเอง
เวลาผ่านไประยะหนึ่งแล้วตั้งแต่เริ่มต้นการเดินทางของเราในโลกของ Kubernetes และเราตัดสินใจตรวจสอบโซลูชันที่มีอยู่อีกครั้ง ปรากฎว่ามีอยู่แล้วในตลาด - Rancher 2.2
ในขั้นตอนแรกของการวิจัยของเรา Rancher Labs ได้เปิดตัวเวอร์ชัน 2 ครั้งแรกแล้ว แต่ถึงแม้จะสามารถยกระดับได้อย่างรวดเร็วด้วยการเปิดตัวคอนเทนเนอร์ที่ไม่มีการพึ่งพาภายนอกด้วยพารามิเตอร์สองสามตัวหรือใช้แผนภูมิ HELM อย่างเป็นทางการ แต่ก็ดูหยาบคาย กับเราและเราไม่รู้ว่าเราจะสามารถพึ่งพาการตัดสินใจครั้งนี้ได้หรือไม่ว่าจะพัฒนาหรือละทิ้งไปอย่างรวดเร็ว กระบวนทัศน์คลัสเตอร์ = การคลิกใน UI เองก็ไม่เหมาะกับเราเช่นกัน และเราไม่ต้องการเชื่อมโยงกับ RKE เนื่องจากเป็นเครื่องมือที่ค่อนข้างแคบ
เวอร์ชัน Rancher 2.2 มีรูปลักษณ์ที่ใช้งานได้มากขึ้นแล้ว และเมื่อรวมกับเวอร์ชันก่อนหน้านี้แล้ว ก็มีคุณสมบัติที่น่าสนใจมากมายที่แกะกล่อง เช่น การบูรณาการกับผู้ให้บริการภายนอกหลายราย การกระจายสิทธิ์และไฟล์ kubeconfig เพียงจุดเดียว การเปิดตัว kubectl รูปภาพที่มีสิทธิ์ของคุณใน UI, เนมสเปซที่ซ้อนกันหรือที่เรียกว่าโปรเจ็กต์
นอกจากนี้ยังมีชุมชนที่ก่อตั้งขึ้นแล้วรอบๆ Rancher 2 และผู้ให้บริการชื่อ HashiCorp Terraform ก็ถูกสร้างขึ้นเพื่อจัดการ ซึ่งช่วยให้เรารวบรวมทุกอย่างเข้าด้วยกัน
เกิดอะไรขึ้น
ด้วยเหตุนี้ เราจึงได้คลัสเตอร์เล็กๆ คลัสเตอร์หนึ่งที่ใช้ Rancher ซึ่งคลัสเตอร์อื่นๆ ทั้งหมดสามารถเข้าถึงได้ รวมถึงคลัสเตอร์อื่นๆ ที่เชื่อมต่ออยู่ด้วย การเข้าถึงคลัสเตอร์ใดๆ ก็ตามสามารถให้สิทธิ์ได้ เช่นเดียวกับการเพิ่มผู้ใช้ลงในไดเร็กทอรี ldap โดยไม่คำนึงถึง ตั้งอยู่ที่ไหนและทรัพยากรของผู้ให้บริการรายใดที่ใช้
ระบบถูกสร้างขึ้นโดยใช้ gitlab-ci และ Terraform ซึ่งช่วยให้คุณสร้างคลัสเตอร์ของการกำหนดค่าใดๆ ในผู้ให้บริการคลาวด์หรือโครงสร้างพื้นฐานของเราเอง และเชื่อมต่อกับ Rancher ทั้งหมดนี้ทำในรูปแบบ IaC โดยแต่ละคลัสเตอร์จะถูกอธิบายโดยพื้นที่เก็บข้อมูล และสถานะของคลัสเตอร์จะถูกกำหนดเวอร์ชัน ในเวลาเดียวกัน โมดูลส่วนใหญ่จะเชื่อมต่อจากพื้นที่เก็บข้อมูลภายนอก ดังนั้นสิ่งที่เหลืออยู่คือการส่งผ่านตัวแปรหรืออธิบายการกำหนดค่าที่คุณกำหนดเองสำหรับอินสแตนซ์ ซึ่งจะช่วยลดเปอร์เซ็นต์ของการทำซ้ำโค้ด
แน่นอนว่า การเดินทางของเรายังอีกยาวไกลและยังมีงานที่น่าสนใจอีกมากมายรออยู่ข้างหน้า เช่น งานจุดเดียวที่มีบันทึกและตัววัดของคลัสเตอร์ใด ๆ เซอร์วิสเมช Gitops สำหรับการจัดการโหลดในมัลติคลัสเตอร์ และอื่นๆ อีกมากมาย เราหวังว่าคุณจะพบว่าประสบการณ์ของเราน่าสนใจ!
บทความนี้เขียนโดย A. Antipov, A. Ganush วิศวกรแพลตฟอร์ม
ที่มา: will.com