สภาพแวดล้อมที่หลากหลาย (การจัดเตรียมการควบคุมคุณภาพการผลิต ฯลฯ ) ด้วย Kubernetes

อะไรคือแนวทางปฏิบัติที่ดีสำหรับ K8S ในการจัดการสภาพแวดล้อมที่หลากหลาย (QA, Staging, Production, Dev ฯลฯ )

ตัวอย่างเช่นสมมติว่าทีมกำลังทำงานกับผลิตภัณฑ์ที่ต้องใช้ API สองสามตัวพร้อมกับแอปพลิเคชันส่วนหน้า โดยปกติสิ่งนี้จะต้องมีอย่างน้อย 2 สภาพแวดล้อม:

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

ดังนั้นสมมติว่าทีมกำลังใช้ Kubernetes แนวทางปฏิบัติที่ดีในการจัดสภาพแวดล้อมเหล่านี้คืออะไร จนถึงตอนนี้เราได้พิจารณาสองทางเลือก:

1. ใช้คลัสเตอร์ K8s สำหรับแต่ละสภาพแวดล้อม
2. ใช้คลัสเตอร์ K8 เพียงคลัสเตอร์เดียวและเก็บไว้ในเนมสเปซที่ต่างกัน

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

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

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

อาจมีข้อกังวลอื่น ๆ ดังนั้นฉันจึงติดต่อชุมชน K8s บน StackOverflow เพื่อทำความเข้าใจให้ดีขึ้นว่าผู้คนรับมือกับความท้าทายประเภทนี้อย่างไร

การพิจารณาหลายคลัสเตอร์

ดูบล็อกโพสต์นี้จาก Vadim Eisenberg ( IBM / Istio ): รายการตรวจสอบ: ข้อดีข้อเสียของการใช้คลัสเตอร์ Kubernetes หลายรายการและวิธีการกระจายปริมาณงานระหว่างกัน

ฉันต้องการเน้นข้อดี / ข้อเสียบางประการ:

เหตุผลที่ต้องมีหลายคลัสเตอร์

• การแยกการผลิต / การพัฒนา / การทดสอบ: โดยเฉพาะอย่างยิ่งสำหรับการทดสอบ Kubernetes เวอร์ชันใหม่ของ service mesh ของซอฟต์แวร์คลัสเตอร์อื่น ๆ
• การปฏิบัติตามข้อบังคับ: ตามข้อบังคับบางอย่างแอปพลิเคชันบางตัวต้องทำงานในคลัสเตอร์แยกกัน / VPN แยก
• การแยกที่ดีขึ้นเพื่อความปลอดภัย
• Cloud / on-prem: เพื่อแบ่งภาระระหว่างบริการในองค์กร

เหตุผลที่ต้องมีคลัสเตอร์เดียว

• ลดค่าใช้จ่ายในการตั้งค่าการบำรุงรักษาและการดูแลระบบ
• ปรับปรุงการใช้ประโยชน์
• ลดต้นทุน

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

• 1 คลัสเตอร์สำหรับ DEV และ STAGING (คั่นด้วยเนมสเปซอาจแยกได้ด้วยซ้ำโดยใช้นโยบายเครือข่ายเช่นในCalico )
• 1 คลัสเตอร์สำหรับ PROD

ความเท่าเทียมกันของสิ่งแวดล้อม

เป็นเรื่องที่ดีที่จะพัฒนาการแสดงละครและการผลิตให้ใกล้เคียงกันมากที่สุด:

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

รวม CI เครื่องมือที่มีประสิทธิภาพด้วย / ซีดีหางเสือ คุณสามารถใช้ความยืดหยุ่นของค่าหางเสือเพื่อตั้งค่าการกำหนดค่าเริ่มต้นเพียงแค่แทนที่การกำหนดค่าที่แตกต่างจากสภาพแวดล้อมไปยังอีก

GitLab CI / CD พร้อม AutoDevopsมีการผสานรวมที่มีประสิทธิภาพกับ Kubernetes ซึ่งช่วยให้คุณจัดการคลัสเตอร์ Kubernetes หลายคลัสเตอร์ที่มีการสนับสนุนหางเสืออยู่แล้ว

การจัดการหลายคลัสเตอร์ ( kubectlการโต้ตอบ)

เมื่อคุณทำงานกับคลัสเตอร์ Kubernetes หลายคลัสเตอร์มันง่ายที่จะยุ่งกับบริบทและเรียกใช้kubectlในคลัสเตอร์ที่ไม่ถูกต้อง นอกเหนือจากนั้น Kubernetes ยังมีข้อ จำกัดสำหรับการกำหนดเวอร์ชันที่ไม่ตรงกันระหว่างไคลเอนต์ ( kubectl) และเซิร์ฟเวอร์ (kubernetes master) ดังนั้นการเรียกใช้คำสั่งในบริบทที่ถูกต้องไม่ได้หมายความว่าการเรียกใช้เวอร์ชันไคลเอ็นต์ที่ถูกต้อง

เพื่อเอาชนะสิ่งนี้:

• ใช้asdfจัดการหลายkubectlเวอร์ชัน
• ตั้งค่าKUBECONFIG env var เพื่อเปลี่ยนระหว่างkubeconfigไฟล์หลาย ๆไฟล์
• ใช้kube-ps1เพื่อติดตามบริบท / เนมสเปซปัจจุบันของคุณ
• ใช้kubectxและkubensเพื่อเปลี่ยนอย่างรวดเร็วระหว่างคลัสเตอร์ / เนมสเปซ
• ใช้นามแฝงเพื่อรวมเข้าด้วยกัน

ฉันมีบทความที่อธิบายถึงวิธีการทำสิ่งนี้: การใช้ kubectl เวอร์ชันต่างๆกับคลัสเตอร์ Kubernetes หลายรายการ

ฉันขอแนะนำให้อ่านต่อไปนี้:

• การเรียนรู้ไฟล์ KUBECONFIGโดย Ahmet Alp Balkan ( Google Engineer )
• วิธีที่ Zalando จัดการคลัสเตอร์ Kubernetes กว่า 140+โดย Henning Jacobs ( Zalando Tech )

ใช้คลัสเตอร์แยกต่างหากอย่างแน่นอนสำหรับการพัฒนาและสร้างอิมเมจนักเทียบท่าเพื่อให้คลัสเตอร์การจัดเตรียม / การผลิตของคุณสามารถปิดกั้นความปลอดภัยได้อย่างชาญฉลาด ไม่ว่าคุณจะใช้กลุ่มที่แยกต่างหากสำหรับstaging + productionขึ้นอยู่กับคุณที่จะตัดสินใจบนพื้นฐานของความเสี่ยง / ค่าใช้จ่าย - แน่นอนทำให้พวกเขาหลีกเลี่ยงแยกต่างหากจะช่วยให้มีผลกระทบต่อstagingproduction

ฉันขอแนะนำอย่างยิ่งให้ใช้ GitOps เพื่อโปรโมตเวอร์ชันของแอประหว่างสภาพแวดล้อมของคุณ

เพื่อลดความผิดพลาดของมนุษย์เราขอแนะนำให้คุณพิจารณาการทำ CI / CD และการส่งเสริมการขายโดยอัตโนมัติให้มากที่สุดเท่าที่จะทำได้

นี่คือการสาธิตวิธีการทำให้ CI / CD โดยอัตโนมัติด้วยสภาพแวดล้อมที่หลากหลายบน Kubernetes โดยใช้ GitOpsสำหรับการโปรโมตระหว่างสภาพแวดล้อมและสภาพแวดล้อมการแสดงตัวอย่างบนคำขอดึงซึ่งดำเนินการบน GKE แม้ว่า Jenkins X จะรองรับคลัสเตอร์ kubernetes ส่วนใหญ่

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

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

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

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

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

• อย่างน้อย 3 มาสเตอร์สำหรับคลัสเตอร์การผลิตและอย่างน้อยหนึ่งมาสเตอร์สำหรับการจัดเตรียม
• ไฟล์กำหนดค่า Kubectl 2 ไฟล์ที่จะเพิ่มลงในระบบ CI / CD

อย่าลืมว่าอาจมีได้มากกว่าหนึ่งสภาพแวดล้อม ตัวอย่างเช่นฉันเคยทำงานใน บริษัท ที่มีสภาพแวดล้อมอย่างน้อย 3 แห่ง:

• QA: นี่คือจุดที่เราปรับใช้ทุกวันและที่ที่เราทำ QA ภายในก่อนที่จะปล่อยให้กับลูกค้า
• Client QA: นี่คือที่ที่เราปรับใช้ก่อนที่จะปรับใช้กับการผลิตเพื่อให้ไคลเอนต์สามารถตรวจสอบสภาพแวดล้อมก่อนที่จะปล่อยสู่การผลิต)
• การผลิต: นี่คือที่ที่ใช้บริการการผลิต

ฉันคิดว่าคลัสเตอร์ชั่วคราว / ตามความต้องการเหมาะสม แต่สำหรับบางกรณีการใช้งาน (การทดสอบการโหลด / ประสิทธิภาพหรือการรวม / การทดสอบตั้งแต่ต้นทางถึงปลายทาง "ใหญ่มาก" แต่สำหรับสภาพแวดล้อมแบบถาวร / เหนียวมากขึ้นฉันเห็นค่าใช้จ่ายที่อาจลดลง โดยเรียกใช้ภายในคลัสเตอร์เดียว

ฉันเดาว่าฉันต้องการติดต่อกับชุมชน k8s เพื่อดูว่ารูปแบบใดที่ใช้สำหรับสถานการณ์เช่นที่ฉันได้อธิบายไว้

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

• ตรวจสอบให้แน่ใจว่าคุณจัดกลุ่มโหนดตามสภาพแวดล้อมโดยใช้ป้ายกำกับ จากนั้นคุณสามารถใช้nodeSelectorทรัพยากรบนเพื่อให้แน่ใจว่ากำลังรันบนโหนดเฉพาะ วิธีนี้จะช่วยลดโอกาสในการใช้ทรัพยากร (ส่วนเกิน) ที่ล้นระหว่างสภาพแวดล้อม

• ถือว่าเนมสเปซของคุณเป็นเครือข่ายย่อยและห้ามการรับส่งข้อมูลขาออก / ขาเข้าทั้งหมดโดยค่าเริ่มต้น ดูhttps://kubernetes.io/docs/concepts/services-networking/network-policies/

• มีกลยุทธ์ในการจัดการบัญชีบริการ ClusterRoleBindingsหมายความว่ามีบางอย่างที่แตกต่างกันหากคลัสเตอร์โฮสต์มากกว่าหนึ่งสภาพแวดล้อม

• ใช้การตรวจสอบข้อเท็จจริงเมื่อใช้เครื่องมือเช่น Helm แผนภูมิบางรายการติดตั้งบัญชีบริการอย่างโจ่งแจ้งด้วยสิทธิ์ทั้งคลัสเตอร์ แต่สิทธิ์ในบัญชีบริการควร จำกัด เฉพาะสภาพแวดล้อมที่อยู่

การใช้หลายคลัสเตอร์ถือเป็นบรรทัดฐานในรายการเพื่อบังคับใช้การแยกที่ชัดเจนระหว่างการผลิตและ "ไม่ใช่การผลิต"

ในจิตวิญญาณนั้นโปรดทราบว่าGitLab 13.2 (กรกฎาคม 2020)รวมถึง:

การปรับใช้คลัสเตอร์ Kubernetes หลายรายการใน Core

การใช้ GitLab เพื่อปรับใช้คลัสเตอร์ Kubernetes หลายรายการกับ GitLab ก่อนหน้านี้จำเป็นต้องมีใบอนุญาตระดับพรีเมียม
ชุมชนของเราพูดและเรารับฟัง: การปรับใช้กับหลายคลัสเตอร์มีประโยชน์สำหรับผู้ร่วมให้ข้อมูลแต่ละคน
จากความคิดเห็นของคุณเริ่มต้นใน GitLab 13.2 คุณสามารถปรับใช้กับกลุ่มหลายกลุ่มและกลุ่มโครงการใน Core

ดูเอกสารและปัญหา /

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

นโยบายเครือข่าย - เพื่อห้ามปริมาณงานสภาพแวดล้อม dev / qa โต้ตอบกับร้านค้า prod / staging

การควบคุมการเข้าถึง - ผู้ที่สามารถเข้าถึงทรัพยากรสภาพแวดล้อมต่างๆโดยใช้ ClusterRoles, Roles เป็นต้น