อุปกรณ์ Helm และข้อผิดพลาดของมัน

แนวคิดผู้ขนส่งสินค้า Typhon, Anton Swanepoel

ฉันชื่อ Dmitry Sugrobov เป็นนักพัฒนาซอฟต์แวร์ของ Leroy Merlin ในบทความนี้ ฉันจะบอกคุณว่าทำไมถึงต้องใช้ Helm วิธีทำให้การทำงานกับ Kubernetes ง่ายขึ้น สิ่งที่เปลี่ยนแปลงไปในเวอร์ชันที่สาม และวิธีใช้เพื่ออัปเดตแอปพลิเคชันในการผลิตโดยไม่ต้องหยุดทำงาน

นี่เป็นบทสรุปจากการกล่าวสุนทรพจน์ในที่ประชุม @การประชุม Kubernetes by Mail.ru โซลูชั่นคลาวด์ — ถ้าไม่อยากอ่านก็ดูคลิปได้เลย

ทำไมเราใช้ Kubernetes ในการผลิต

Leroy Merlin เป็นผู้นำในตลาดค้าปลีก DIY ในรัสเซียและยุโรป บริษัทของเรามีนักพัฒนามากกว่าร้อยคน พนักงานภายใน 33 คน และผู้คนจำนวนมากที่เยี่ยมชมไฮเปอร์มาร์เก็ตและเว็บไซต์ เพื่อทำให้พวกเขาทุกคนมีความสุข เราจึงตัดสินใจปฏิบัติตามแนวทางมาตรฐานอุตสาหกรรม พัฒนาแอปพลิเคชันใหม่โดยใช้สถาปัตยกรรมไมโครเซอร์วิส ใช้คอนเทนเนอร์เพื่อแยกสภาพแวดล้อมและรับประกันการจัดส่งที่เหมาะสม และใช้ Kubernetes เพื่อเรียบเรียง ราคาของการใช้ออเคสตราเตอร์กำลังถูกลงอย่างรวดเร็ว: จำนวนวิศวกรที่เชี่ยวชาญด้านเทคโนโลยีกำลังเพิ่มขึ้นในตลาด และผู้ให้บริการต่างๆ ก็เริ่มเสนอ Kubernetes เป็นบริการ

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

คำสาปของไฟล์ YAML ขนาดใหญ่ใน Kubernetes

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

Adam Reese ผู้ดูแลหลักของ Helm ได้แนะนำแนวคิดของ "วงจรการพัฒนาใน Kubernetes" ซึ่งมีลักษณะดังนี้:

1. คัดลอก YAML - คัดลอกไฟล์ YAML
2. วาง YAML - วางมัน
3. แก้ไขการเยื้อง - แก้ไขการเยื้อง
4. ทำซ้ำ - ทำซ้ำอีกครั้ง

ตัวเลือกนี้ใช้งานได้ แต่คุณต้องคัดลอกไฟล์ YAML หลายครั้ง เพื่อเปลี่ยนวงจรนี้ Helm จึงถูกประดิษฐ์ขึ้น

หางเสือคืออะไร

ประการแรก หางเสือ - ผู้จัดการแพ็คเกจซึ่งช่วยคุณค้นหาและติดตั้งโปรแกรมที่คุณต้องการ ในการติดตั้ง เช่น MongoDB คุณไม่จำเป็นต้องไปที่เว็บไซต์อย่างเป็นทางการและดาวน์โหลดไบนารี เพียงแค่รันคำสั่ง helm install stable/mongodb.

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

ประการที่สาม หางเสือ - ต้นแบบการปรับใช้. ด้วยเครื่องมือนี้ คุณสามารถติดตั้ง ย้อนกลับ และอัปเดตแอปพลิเคชันได้ ลองหาวิธีการทำเช่นนี้

วิธีใช้ Helm เพื่อปรับใช้แอปพลิเคชันของคุณเอง

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

• ระบุโฟลเดอร์ด้วยเทมเพลต
• แพ็คไฟล์เก็บถาวรลงใน .tar แล้วชี้ไปที่มัน
• วางเทมเพลตในพื้นที่เก็บข้อมูลระยะไกลและเพิ่มลิงก์ไปยังพื้นที่เก็บข้อมูลในไคลเอ็นต์ Helm

คุณต้องมีไฟล์ที่มีค่า -values.yaml ข้อมูลจากนั้นจะถูกแทรกลงในเทมเพลต มาสร้างมันกันเถอะ

Helm เวอร์ชันที่สองมีแอปพลิเคชันเซิร์ฟเวอร์เพิ่มเติม - Tiller มันค้างอยู่นอก Kubernetes และรอคำขอจากไคลเอนต์ Helm และเมื่อถูกเรียก จะแทนที่ค่าที่ต้องการลงในเทมเพลตและส่งไปยัง Kubernetes

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

มันทำงานอย่างไร

รันคำสั่ง helm install. มาระบุชื่อของการเปิดตัวแอปพลิเคชันและกำหนดเส้นทางไปยังค่าต่างๆ.yaml ในตอนท้ายเราจะระบุพื้นที่เก็บข้อมูลซึ่งเป็นที่ตั้งของแผนภูมิและชื่อของแผนภูมิ ในตัวอย่าง ค่าเหล่านี้คือ "lmru" และ "bestchart" ตามลำดับ

helm install --name bestapp --values values.yaml lmru/bestchart

คำสั่งสามารถดำเนินการได้เพียงครั้งเดียว เมื่อดำเนินการอีกครั้งแทน install จำเป็นต้องใช้ upgrade. เพื่อความง่าย แทนที่จะใช้สองคำสั่ง คุณสามารถรันคำสั่งได้ upgrade พร้อมกุญแจเพิ่มเติม --install. เมื่อดำเนินการเป็นครั้งแรก Helm จะส่งคำสั่งเพื่อติดตั้งรีลีส และจะอัปเดตในอนาคต

helm upgrade --install bestapp --values values.yaml lmru/bestchart

ข้อผิดพลาดในการปรับใช้แอปพลิเคชันเวอร์ชันใหม่กับ Helm

ณ จุดนี้ของเรื่องราว ฉันกำลังเล่น Who Wants to Be a Millionaire กับผู้ชม และเรากำลังหาวิธีให้ Helm อัปเดตเวอร์ชันของแอป ดูวิดีโอ.

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

วิธีที่ 1. ห้ามเปลี่ยนแปลงข้อมูลตั้งแต่การเปิดตัวครั้งล่าสุด

แค็กกลาซิท เว็บไซต์อย่างเป็นทางการ Helm “แผนภูมิ Kubernetes สามารถมีขนาดใหญ่และซับซ้อนได้ ดังนั้น Helm จึงพยายามไม่แตะต้องสิ่งใดมากเกินไป” ดังนั้นหากคุณอัปเดตอิมเมจแอปพลิเคชันเวอร์ชันล่าสุดในรีจิสทรีนักเทียบท่าและรันคำสั่ง helm upgradeแล้วจะไม่มีอะไรเกิดขึ้น เฮล์มจะคิดว่าไม่มีอะไรเปลี่ยนแปลง และไม่จำเป็นต้องส่งคำสั่งไปยัง Kubernetes เพื่ออัปเดตแอปพลิเคชัน

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

วิธีที่ 2 อัปเดต LABEL ในรูปภาพ

ตามที่เขียนไว้เหมือนกัน เอกสาร, “Helm จะอัปเดตแอปพลิเคชันเฉพาะเมื่อมีการเปลี่ยนแปลงตั้งแต่รุ่นล่าสุด” ตัวเลือกเชิงตรรกะสำหรับสิ่งนี้ดูเหมือนจะเป็นการอัปเดต LABEL ในอิมเมจนักเทียบท่าเอง อย่างไรก็ตาม Helm ไม่ได้พิจารณารูปภาพของแอปพลิเคชันและไม่มีความคิดเกี่ยวกับการเปลี่ยนแปลงใดๆ ที่เกิดขึ้นกับรูปภาพเหล่านั้น ดังนั้น เมื่ออัปเดตป้ายกำกับในรูปภาพ Helm จะไม่ทราบเกี่ยวกับป้ายกำกับเหล่านั้น และคำสั่งอัปเดตแอปพลิเคชันจะไม่ถูกส่งไปยัง Kubernetes

วิธีที่ 3: ใช้คีย์ --force

มาดูคู่มือแล้วมองหากุญแจที่ต้องการ ที่สำคัญมีความหมายมากที่สุด --force. แม้ว่าชื่อจะชัดเจน แต่พฤติกรรมกลับแตกต่างจากที่คาดไว้ แทนที่จะบังคับให้อัปเดตแอปพลิเคชัน จุดประสงค์ที่แท้จริงคือการกู้คืนเวอร์ชันที่อยู่ในสถานะ FAILED หากคุณไม่ได้ใช้คีย์นี้ คุณจะต้องดำเนินการคำสั่งตามลำดับ helm delete && helm install --replace. แนะนำให้ใช้กุญแจแทน --forceซึ่งจะทำให้การดำเนินการตามลำดับของคำสั่งเหล่านี้เป็นแบบอัตโนมัติ ข้อมูลเพิ่มเติมในเรื่องนี้ ดึงคำขอ. เพื่อที่จะบอกให้ Helm อัปเดตเวอร์ชันของแอปพลิเคชัน ขออภัยที่คีย์นี้ใช้งานไม่ได้

วิธีที่ 4 เปลี่ยนป้ายกำกับโดยตรงใน Kubernetes

การอัพเดตเลเบลโดยตรงในคลัสเตอร์โดยใช้คำสั่ง kubectl edit - ความคิดที่ไม่ดี การดำเนินการนี้จะนำไปสู่ความไม่สอดคล้องกันของข้อมูลระหว่างแอปพลิเคชันที่ทำงานอยู่กับแอปพลิเคชันที่ถูกส่งไปปรับใช้ในตอนแรก ลักษณะการทำงานของ Helm ระหว่างการใช้งานในกรณีนี้แตกต่างจากเวอร์ชัน: Helm 2 จะไม่ทำอะไรเลย และ Helm 3 จะปรับใช้แอปพลิเคชันเวอร์ชันใหม่ เพื่อทำความเข้าใจว่าทำไม คุณต้องเข้าใจว่า Helm ทำงานอย่างไร

เฮล์มทำงานอย่างไร?

เพื่อตรวจสอบว่าแอปพลิเคชันมีการเปลี่ยนแปลงตั้งแต่รีลีสครั้งล่าสุดหรือไม่ Helm สามารถใช้:

• ใช้งานแอปพลิเคชันใน Kubernetes
• ค่าใหม่ yaml และแผนภูมิปัจจุบัน
• ข้อมูลการเผยแพร่ภายในของ Helm

สำหรับผู้ที่อยากรู้อยากเห็นมากขึ้น: Helm เก็บข้อมูลภายในเกี่ยวกับการเผยแพร่ที่ไหนโดยดำเนินการตามคำสั่ง helm historyเราจะได้ข้อมูลทั้งหมดเกี่ยวกับเวอร์ชันที่ติดตั้งโดยใช้ Helm

นอกจากนี้ยังมีข้อมูลโดยละเอียดเกี่ยวกับเทมเพลตและค่าที่ส่ง เราสามารถขอได้:

ใน Helm เวอร์ชันที่สอง ข้อมูลนี้จะอยู่ในเนมสเปซเดียวกันกับที่ Tiller กำลังทำงานอยู่ (ระบบ kube ตามค่าเริ่มต้น) ใน ConfigMap ซึ่งมีป้ายกำกับ “OWNER=TILLER”:

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

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

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

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

วิธีที่ 5. ใช้สวิตช์ --recreate-pods

ด้วยกุญแจ --recreate-pods คุณสามารถบรรลุสิ่งที่คุณวางแผนไว้แต่เดิมเพื่อให้บรรลุได้ด้วยกุญแจ --force. คอนเทนเนอร์จะรีสตาร์ท และตาม imagePullPolicy: นโยบายสำหรับแท็กล่าสุดเสมอ (เพิ่มเติมเกี่ยวกับเรื่องนี้ในเชิงอรรถด้านบน) Kubernetes จะดาวน์โหลดและเปิดใช้อิมเมจเวอร์ชันใหม่ การดำเนินการนี้จะไม่ใช่วิธีที่ดีที่สุด: หากไม่คำนึงถึง StrategyType ของการปรับใช้ อินสแตนซ์จะปิดอินสแตนซ์แอปพลิเคชันเก่าทั้งหมดทันทีและเริ่มเปิดตัวแอปพลิเคชันใหม่ ในระหว่างการรีสตาร์ท ระบบจะไม่ทำงาน ผู้ใช้จะต้องประสบปัญหา

ใน Kubernetes เองก็ประสบปัญหาที่คล้ายกันมาเป็นเวลานานเช่นกัน และตอนนี้ก็ครบ 4 ปีหลังจากเปิดร้าน »Ñ­ËÒปัญหาได้รับการแก้ไขแล้ว และตั้งแต่เวอร์ชัน 1.15 ของ Kubernetes เป็นต้นไป ความสามารถในการม้วนพ็อดรีสตาร์ทจะปรากฏขึ้น

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

จะอัปเดตเวอร์ชันแอปพลิเคชันโดยใช้ Helm ได้อย่างไร

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

1. ค่าสุ่ม โดยใช้ฟังก์ชันมาตรฐาน - {{ randAlphaNum 6 }}.
   มีข้อแม้: หลังจากการปรับใช้แต่ละครั้งโดยใช้แผนภูมิที่มีตัวแปรดังกล่าว ค่าคำอธิบายประกอบจะไม่ซ้ำกัน และ Helm จะถือว่ามีการเปลี่ยนแปลง ปรากฎว่าเราจะรีสตาร์ทแอปพลิเคชันเสมอแม้ว่าเราจะไม่ได้เปลี่ยนเวอร์ชันก็ตาม สิ่งนี้ไม่สำคัญเนื่องจากจะไม่มีการหยุดทำงาน แต่ก็ยังไม่เป็นที่พอใจ
2. วางปัจจุบัน วันและเวลา - {{ .Release.Date }}.
   ตัวแปรจะคล้ายกับค่าสุ่มที่มีตัวแปรเฉพาะอย่างถาวร
3. วิธีที่ถูกต้องกว่าคือการใช้ เช็คซัม. นี่คือ SHA ของรูปภาพหรือ SHA ของการคอมมิตครั้งล่าสุดในคอมไพล์ - {{ .Values.sha }}.
   พวกเขาจะต้องถูกนับและส่งไปยังไคลเอนต์ Helm ฝั่งที่เรียก เช่น ใน Jenkins หากแอปพลิเคชันมีการเปลี่ยนแปลง เช็คซัมก็จะเปลี่ยนไป ดังนั้น Helm จะอัปเดตแอปพลิเคชันเมื่อจำเป็นเท่านั้น

มาสรุปความพยายามของเรากัน

• Helm ทำการเปลี่ยนแปลงในลักษณะที่รุกรานน้อยที่สุด ดังนั้นการเปลี่ยนแปลงใดๆ ที่ระดับอิมเมจของแอปพลิเคชันใน Docker Registry จะไม่ส่งผลให้เกิดการอัปเดต: จะไม่มีอะไรเกิดขึ้นหลังจากดำเนินการคำสั่งแล้ว
• คีย์ --force ใช้เพื่อกู้คืนรุ่นที่มีปัญหาและไม่เกี่ยวข้องกับการอัปเดตที่บังคับ
• คีย์ --recreate-pods จะอัปเดตแอปพลิเคชันอย่างเข้มแข็ง แต่จะทำในลักษณะป่าเถื่อน: มันจะปิดคอนเทนเนอร์ทั้งหมดทันที ผู้ใช้จะต้องประสบปัญหานี้ คุณไม่ควรทำเช่นนี้ในเวอร์ชันที่ใช้งานจริง
• ทำการเปลี่ยนแปลงคลัสเตอร์ Kubernetes โดยตรงโดยใช้คำสั่ง kubectl edit อย่า: เราจะทำลายความสม่ำเสมอ และลักษณะการทำงานจะแตกต่างกันไปขึ้นอยู่กับเวอร์ชันของ Helm
• ด้วยการเปิดตัว Helm เวอร์ชันใหม่ ความแตกต่างมากมายก็ปรากฏขึ้น ปัญหาในพื้นที่เก็บข้อมูล Helm ได้รับการอธิบายด้วยภาษาที่ชัดเจน ซึ่งจะช่วยให้คุณเข้าใจรายละเอียดได้
• การเพิ่มคำอธิบายประกอบที่แก้ไขได้ลงในแผนภูมิจะทำให้มีความยืดหยุ่นมากขึ้น ซึ่งจะทำให้คุณสามารถเผยแพร่แอปพลิเคชันได้อย่างถูกต้องโดยไม่ต้องหยุดทำงาน

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

ลิงค์อื่นๆ ที่เกี่ยวข้อง:

1. ทำความรู้จักกับ หางเสือ 3
2. เว็บไซต์อย่างเป็นทางการของหางเสือ
3. พื้นที่เก็บข้อมูล Helm บน GitHub
4. 25 เครื่องมือ Kubernetes ที่มีประโยชน์: การปรับใช้และการจัดการ

รายงานนี้ถูกนำเสนอครั้งแรกที่ @การประชุม Kubernetes โดย Mail.ru Cloud Solutions ดู วีดีโอ การแสดงอื่น ๆ และสมัครรับประกาศกิจกรรมบน Telegram เกี่ยวกับ Kubernetes ที่ Mail.ru Group.

ที่มา: will.com