ในความคาดหมาย วิตาลี คาบารอฟ สัมภาษณ์ มิทรี สโตลยารอฟ () ผู้อำนวยการด้านเทคนิคและผู้ร่วมก่อตั้งบริษัท Flant Vitaly ถาม Dmitry เกี่ยวกับสิ่งที่ Flant ทำ เกี่ยวกับ Kubernetes การพัฒนาระบบนิเวศ และการสนับสนุน เราได้พูดคุยกันว่าทำไม Kubernetes จึงจำเป็น และจำเป็นหรือไม่ และยังเกี่ยวกับไมโครเซอร์วิส, Amazon AWS, แนวทาง “ฉันจะโชคดี” สำหรับ DevOps, อนาคตของ Kubernetes เอง, ทำไม, เมื่อใดและอย่างไรที่ Kubernetes จะเข้ายึดครองโลก, โอกาสของ DevOps และสิ่งที่วิศวกรควรเตรียมพร้อมสำหรับใน อนาคตอันสดใสและใกล้ตัวด้วยความเรียบง่ายและโครงข่ายประสาทเทียม
ฟังเป็นพอดแคสต์บน DevOps Deflop - พอดแคสต์ภาษารัสเซียเกี่ยวกับ DevOps และด้านล่างนี้คือเวอร์ชันข้อความ
ที่นี่และด้านล่างเขาถามคำถาม วิศวกรจาก Express42
เกี่ยวกับ ฟลานท์
- สวัสดีดิมา คุณเป็นผู้อำนวยการด้านเทคนิค”"และยังเป็นผู้ก่อตั้งอีกด้วย โปรดบอกเราว่าบริษัททำอะไรและคุณอยู่ในบริษัทอะไร?
ดีมิทรี: จากภายนอกดูเหมือนว่าเราเป็นคนที่ลงมือติดตั้ง Kubernetes ให้กับทุกคนและทำอะไรบางอย่างกับมัน แต่นั่นไม่เป็นความจริง เราเริ่มต้นจากการเป็นบริษัทที่เกี่ยวข้องกับ Linux แต่กิจกรรมหลักของเราคือการให้บริการด้านการผลิตและโครงการแบบครบวงจรที่มีภาระงานสูงมาเป็นเวลานาน โดยปกติแล้วเราสร้างโครงสร้างพื้นฐานทั้งหมดตั้งแต่เริ่มต้น จากนั้นจะต้องรับผิดชอบมันเป็นเวลานาน ดังนั้นงานหลักที่ “แฟลนท์” ทำเพื่อได้เงินก็คือ รับผิดชอบและดำเนินการผลิตแบบครบวงจร.
ฉันในฐานะผู้อำนวยการด้านเทคนิคและหนึ่งในผู้ก่อตั้งบริษัท ใช้เวลาทั้งวันทั้งคืนในการพยายามหาวิธีเพิ่มการเข้าถึงการผลิต ทำให้การดำเนินงานง่ายขึ้น ทำให้ชีวิตของผู้ดูแลระบบง่ายขึ้น และชีวิตของนักพัฒนาก็น่าอยู่ยิ่งขึ้น .
เกี่ยวกับคูเบอร์เนเทส
— ช่วงนี้ฉันเห็นรายงานมากมายจาก Flant และ เกี่ยวกับคูเบอร์เนเตส คุณมาได้อย่างไร?
ดีมิทรี: ฉันเคยพูดถึงเรื่องนี้หลายครั้งแล้ว แต่ฉันก็ไม่รังเกียจที่จะพูดซ้ำเลย ฉันคิดว่ามันถูกต้องที่จะพูดซ้ำหัวข้อนี้เพราะมีความสับสนระหว่างเหตุและผล
เราต้องการเครื่องมือจริงๆ เราเผชิญปัญหามากมาย พยายามดิ้นรน เอาชนะมันด้วยไม้ค้ำยันต่างๆ และรู้สึกว่าจำเป็นต้องมีเครื่องมือ เราผ่านทางเลือกต่างๆ มากมาย สร้างจักรยานยนต์ของเราเอง และได้รับประสบการณ์ เรามาถึงจุดที่เราเริ่มใช้ Docker เกือบจะทันทีที่มันปรากฏขึ้น - ประมาณปี 2013 ในช่วงเวลาที่ปรากฏเรามีประสบการณ์มากมายกับคอนเทนเนอร์เราได้เขียนอะนาล็อกของ "นักเทียบท่า" แล้ว - ไม้ค้ำยันบางส่วนของเราใน Python ด้วยการถือกำเนิดของ Docker จึงเป็นไปได้ที่จะโยนไม้ค้ำยันออกไป และใช้โซลูชันที่เชื่อถือได้และได้รับการสนับสนุนจากชุมชน
ด้วย Kubernetes เรื่องราวก็คล้ายกัน เมื่อถึงเวลาที่มันเริ่มได้รับแรงผลักดัน - สำหรับเรา นี่คือเวอร์ชัน 1.2 - เรามีไม้ค้ำยันมากมายสำหรับทั้ง Shell และ Chef ซึ่งเราพยายามจะประสานกับ Docker เรากำลังพิจารณา Rancher และโซลูชันอื่นๆ อย่างจริงจัง แต่แล้ว Kubernetes ก็ปรากฏขึ้น โดยที่ทุกอย่างได้รับการปฏิบัติเหมือนที่เราเคยทำหรือดีกว่านั้น ไม่มีอะไรจะบ่น
ใช่ มีความไม่สมบูรณ์บางอย่างที่นี่ มีความไม่สมบูรณ์บางอย่างอยู่ที่นั่น - มีความไม่สมบูรณ์มากมาย และโดยทั่วไปแล้ว 1.2 ก็แย่มาก แต่... Kubernetes ก็เหมือนกับอาคารที่กำลังก่อสร้าง - คุณดูโครงการแล้วเข้าใจ ว่าจะเย็นสบาย หากอาคารตอนนี้มีฐานรากและสองชั้นคุณก็เข้าใจว่าไม่ควรย้ายเข้าจะดีกว่า แต่ไม่มีปัญหากับซอฟต์แวร์ - คุณสามารถใช้งานได้แล้ว
เราไม่มีเวลาคิดที่จะใช้ Kubernetes หรือไม่ เรากำลังรอมันมานานก่อนที่มันจะปรากฏขึ้น และพยายามสร้างแอนะล็อกด้วยตัวเราเอง
เกี่ยวกับคูเบอร์เนเทส
— คุณมีส่วนร่วมโดยตรงในการพัฒนา Kubernetes หรือไม่?
ดีมิทรี: ปานกลาง. แต่เรามีส่วนร่วมในการพัฒนาระบบนิเวศ เราส่งคำขอดึงจำนวนหนึ่ง: ไปยัง Prometheus ไปยังผู้ปฏิบัติงานหลายราย ไปยัง Helm - ไปยังระบบนิเวศ น่าเสียดายที่ฉันไม่สามารถติดตามทุกสิ่งที่เราทำและอาจผิดพลาดได้ แต่ไม่มีกลุ่มใดกลุ่มหนึ่งจากเราไปสู่แกนกลาง
— ในขณะเดียวกัน คุณได้พัฒนาเครื่องมือหลายอย่างเกี่ยวกับ Kubernetes หรือไม่?
ดีมิทรี: กลยุทธ์คือ: เราไปและดึงคำขอไปยังทุกสิ่งที่มีอยู่แล้ว หากคำขอดึงไม่ได้รับการยอมรับ เราก็แค่แยกคำขอเหล่านั้นเองและดำเนินการจนกว่าคำขอเหล่านั้นจะได้รับการยอมรับพร้อมกับงานสร้างของเรา จากนั้นเมื่อถึงต้นน้ำ เราก็กลับไปสู่ต้นน้ำอีกครั้ง
ตัวอย่างเช่น เรามีตัวดำเนินการ Prometheus ซึ่งเราสลับไปมาที่ต้นทางของการประกอบของเราน่าจะ 5 ครั้งแล้ว เราต้องการฟีเจอร์บางอย่าง เราได้ส่งคำขอดึงแล้ว เราต้องเปิดตัวในวันพรุ่งนี้ แต่เราไม่ต้องการรอให้ปล่อยต้นทาง ดังนั้นเราจึงรวบรวมเพื่อตัวเราเอง และเผยแพร่แอสเซมบลีของเราด้วยฟีเจอร์ของเรา ซึ่งเราต้องการด้วยเหตุผลบางอย่าง ไปยังคลัสเตอร์ทั้งหมดของเรา ตัวอย่างเช่น พวกเขาส่งมันกลับมาให้เราที่ต้นน้ำพร้อมกับคำว่า "พวกเรา เรามาทำกรณีทั่วไปกว่านี้กันเถอะ" เราหรือคนอื่นก็ทำให้เสร็จ และเมื่อเวลาผ่านไปมันก็กลับมารวมกันอีกครั้ง
เราพยายามพัฒนาทุกสิ่งที่มีอยู่. องค์ประกอบหลายอย่างที่ยังไม่มี ยังไม่ได้ถูกประดิษฐ์ขึ้น หรือถูกประดิษฐ์ขึ้น แต่ไม่มีเวลานำไปใช้ - เรากำลังดำเนินการอยู่ และไม่ใช่เพราะเราชอบกระบวนการหรือการสร้างจักรยานในฐานะอุตสาหกรรม แต่เพียงเพราะเราต้องการเครื่องมือนี้ คำถามนี้มักถูกถามว่าทำไมเราถึงทำสิ่งนี้หรือสิ่งนั้น? คำตอบนั้นง่ายมาก - ใช่ เพราะเราต้องไปไกลกว่านี้ แก้ปัญหาในทางปฏิบัติ และเราแก้ไขมันด้วย tula นี้
เส้นทางจะเป็นเช่นนี้เสมอ: เราค้นหาอย่างระมัดระวัง และหากเราไม่พบวิธีแก้ปัญหาใด ๆ ในการทำรถเข็นจากขนมปัง เราก็ทำขนมปังของเราเองและรถเข็นของเราเอง
เครื่องมือฟลันตา
— ฉันรู้ว่าตอนนี้ Flant มีตัวดำเนินการ addon ตัวดำเนินการเชลล์ และเครื่องมือ dapp/werf ตามที่ฉันเข้าใจ นี่เป็นเครื่องดนตรีชนิดเดียวกันในชาติที่ต่างกัน ฉันเข้าใจด้วยว่ามีเครื่องมือที่แตกต่างกันมากมายภายใน Flaunt นี่เป็นเรื่องจริงเหรอ?
ดีมิทรี: เรามีอะไรอีกมากมายบน GitHub จากสิ่งที่ฉันจำได้ตอนนี้ เรามีแผนที่สถานะ - แผงสำหรับ Grafana ที่ทุกคนเคยเจอ มีการกล่าวถึงในบทความเกือบทุกวินาทีเกี่ยวกับการตรวจสอบ Kubernetes บนสื่อ เป็นไปไม่ได้ที่จะอธิบายสั้นๆ ว่า Statusmap คืออะไร โดยต้องมีบทความแยกต่างหาก แต่มีประโยชน์มากในการตรวจสอบสถานะเมื่อเวลาผ่านไป เนื่องจากใน Kubernetes เรามักจะต้องแสดงสถานะเมื่อเวลาผ่านไป เรายังมี LogHouse ซึ่งเป็นสิ่งที่มีพื้นฐานมาจาก ClickHouse และมนต์ดำสำหรับการรวบรวมบันทึกใน Kubernetes
สาธารณูปโภคมากมาย! และจะมีมากกว่านี้อีก เนื่องจากในปีนี้จะมีการเปิดตัวโซลูชันภายในจำนวนหนึ่ง ที่มีขนาดใหญ่มากตามตัวดำเนินการ addon มีส่วนเสริมมากมายสำหรับ Kubernetes รวมถึงวิธีการติดตั้ง sert manager อย่างถูกต้อง - เครื่องมือสำหรับจัดการใบรับรองวิธีติดตั้ง Prometheus อย่างถูกต้องด้วยอุปกรณ์เสริมมากมาย - สิ่งเหล่านี้แตกต่างกันประมาณยี่สิบ ไบนารีที่ส่งออกข้อมูลและรวบรวมบางสิ่งบางอย่าง Prometheus นี้มีกราฟิกและการแจ้งเตือนที่น่าทึ่งที่สุด ทั้งหมดนี้เป็นเพียงส่วนเสริมของ Kubernetes ที่ติดตั้งในคลัสเตอร์ และเปลี่ยนจากเรียบง่ายไปเป็นเจ๋ง ซับซ้อน อัตโนมัติ ซึ่งปัญหาหลายอย่างได้รับการแก้ไขแล้ว ใช่ เราทำมาก
การพัฒนาระบบนิเวศ
“สำหรับฉันแล้วดูเหมือนว่าสิ่งนี้มีส่วนช่วยอย่างมากในการพัฒนาเครื่องมือนี้และวิธีการใช้งาน” คุณสามารถประมาณคร่าวๆ ได้ว่าใครจะมีส่วนช่วยในการพัฒนาระบบนิเวศแบบเดียวกันนี้อีกบ้าง
ดีมิทรี: ในรัสเซีย บริษัทที่ดำเนินกิจการในตลาดของเราไม่มีใครใกล้เคียงด้วยซ้ำ. แน่นอนว่านี่เป็นคำพูดที่ดังเพราะมีผู้เล่นหลักเช่น Mail และ Yandex - พวกเขากำลังทำอะไรบางอย่างกับ Kubernetes เช่นกัน แต่ถึงแม้พวกเขาจะไม่ได้เข้าใกล้การมีส่วนร่วมของบริษัทต่างๆ ทั่วโลกที่ทำมากกว่าเรามากนักก็ตาม เป็นการยากที่จะเปรียบเทียบ Flant ซึ่งมีพนักงาน 80 คน กับ Red Hat ซึ่งมีวิศวกร 300 คนต่อ Kubernetes เพียงอย่างเดียว ถ้าจำไม่ผิด มันยากที่จะเปรียบเทียบ เรามีคน 6 คนในแผนก RnD รวมทั้งฉันด้วยที่ตัดเครื่องมือทั้งหมดของเรา คน 6 คนเทียบกับวิศวกร Red Hat 300 คน เปรียบเทียบได้ยาก
- อย่างไรก็ตาม เมื่อทั้ง 6 คนนี้ยังสามารถทำสิ่งที่มีประโยชน์และแปลกแยกได้จริง ๆ เมื่อต้องเผชิญกับปัญหาเชิงปฏิบัติและมอบแนวทางแก้ไขให้กับชุมชน - เป็นกรณีที่น่าสนใจ ฉันเข้าใจว่าในบริษัทเทคโนโลยีขนาดใหญ่ซึ่งมีทีมพัฒนาและสนับสนุน Kubernetes เป็นของตัวเอง โดยหลักการแล้ว เครื่องมือเดียวกันนี้สามารถพัฒนาได้ นี่คือตัวอย่างสำหรับพวกเขาเกี่ยวกับสิ่งที่สามารถพัฒนาและมอบให้กับชุมชนได้ ซึ่งเป็นแรงผลักดันให้กับชุมชนทั้งหมดที่ใช้ Kubernetes
ดีมิทรี: นี่อาจเป็นคุณลักษณะของผู้รวมระบบซึ่งเป็นลักษณะเฉพาะของมัน เรามีโครงการมากมายและเราเห็นสถานการณ์ที่แตกต่างกันมากมาย สำหรับเรา วิธีหลักในการสร้างมูลค่าเพิ่มคือการวิเคราะห์กรณีเหล่านี้ ค้นหาสิ่งที่เหมือนกัน และทำให้ราคาถูกที่สุดเท่าที่จะเป็นไปได้สำหรับเรา เรากำลังดำเนินการเรื่องนี้อย่างแข็งขัน เป็นเรื่องยากสำหรับฉันที่จะพูดคุยเกี่ยวกับรัสเซียและโลก แต่เรามีวิศวกร DevOps ประมาณ 40 คนในบริษัทที่ทำงานบน Kubernetes ฉันไม่คิดว่าจะมีบริษัทหลายแห่งในรัสเซียที่มีผู้เชี่ยวชาญที่เข้าใจ Kubernetes มากเท่าๆ กัน ถ้ามี
ฉันเข้าใจทุกอย่างเกี่ยวกับตำแหน่งงาน DevOps Engineer ทุกคนเข้าใจทุกอย่าง และคุ้นเคยกับการเรียกวิศวกร DevOps ว่า DevOps Engineer เราจะไม่พูดถึงเรื่องนี้ วิศวกร DevOps ที่น่าทึ่งทั้ง 40 คนเผชิญหน้าและแก้ไขปัญหาทุกวัน เราแค่วิเคราะห์ประสบการณ์นี้และพยายามสรุป เราเข้าใจดีว่าถ้ามันยังคงอยู่ในตัวเราภายในหนึ่งหรือสองปีเครื่องมือก็จะไร้ประโยชน์เพราะที่ไหนสักแห่งในชุมชน Tula สำเร็จรูปจะปรากฏขึ้น ไม่มีประโยชน์ที่จะสะสมประสบการณ์นี้ภายใน - มันเป็นเพียงการระบายพลังงานและเวลาให้เป็น dev/null และเราไม่รู้สึกเสียใจกับมันเลย เราเผยแพร่ทุกสิ่งด้วยความยินดีเป็นอย่างยิ่ง และเข้าใจว่าจำเป็นต้องเผยแพร่ พัฒนา ส่งเสริม ส่งเสริม เพื่อให้ผู้คนใช้และเพิ่มประสบการณ์ จากนั้นทุกสิ่งจะเติบโตและมีชีวิต หลังจากนั้นสองปีเครื่องมือก็ไม่ถูกทิ้งลงถังขยะ ไม่ใช่เรื่องน่าเสียดายที่จะยังคงเพิ่มความแข็งแกร่งต่อไป เพราะเห็นได้ชัดว่ามีคนใช้เครื่องมือของคุณ และหลังจากผ่านไปสองปี ทุกคนก็ใช้มัน
นี่เป็นส่วนหนึ่งของกลยุทธ์สำคัญของเรากับ dapp/werf. จำไม่ได้ว่าเริ่มทำเมื่อไร น่าจะประมาณ 3 ปีที่แล้ว ในตอนแรกก็มักอยู่บนเปลือก มันเป็นการพิสูจน์แนวคิดที่ยอดเยี่ยม เราได้แก้ไขปัญหาบางอย่างของเราแล้ว มันได้ผล! แต่มีปัญหากับเชลล์จึงไม่สามารถขยายเพิ่มเติมได้ การเขียนโปรแกรมบนเชลล์เป็นงานอื่น เรามีนิสัยชอบเขียนด้วยภาษา Ruby ดังนั้นเราจึงสร้างบางสิ่งบางอย่างใน Ruby ขึ้นมาใหม่ พัฒนา พัฒนา พัฒนา และพบกับความจริงที่ว่าชุมชน กลุ่มคนที่ไม่ได้พูดว่า "เราต้องการมัน หรือเราไม่ต้องการมัน" ” เงยหน้ามองรูบี้ ตลกขนาดนั้นเลยเหรอ? เรารู้ว่าเราควรเขียนเนื้อหาทั้งหมดนี้ใน Go เพียงเพื่อให้บรรลุจุดแรกในรายการตรวจสอบ: เครื่องมือ DevOps ควรเป็นไบนารีแบบคงที่. จะเป็น Go หรือไม่นั้นไม่สำคัญนัก แต่ไบนารี่แบบคงที่ที่เขียนด้วย Go นั้นดีกว่า
เราใช้ความพยายาม เขียน dapp ใหม่ใน Go และเรียกมันว่า werf DApp ไม่ได้รับการสนับสนุนอีกต่อไป ไม่ได้รับการพัฒนา และทำงานในเวอร์ชันล่าสุดบางเวอร์ชัน แต่มีเส้นทางการอัปเกรดแบบสัมบูรณ์ไปจนถึงระดับสูงสุด และคุณสามารถติดตามได้
เหตุใด dapp จึงถูกสร้างขึ้น?
— คุณช่วยบอกเราสั้นๆ ได้ไหมว่าเหตุใด dapp จึงถูกสร้างขึ้น แก้ปัญหาอะไรได้บ้าง?
ดีมิทรี: เหตุผลแรกอยู่ในสภา ในตอนแรก เราประสบปัญหาร้ายแรงกับรุ่นเมื่อ Docker ไม่มีความสามารถแบบหลายขั้นตอน ดังนั้นเราจึงสร้างแบบหลายขั้นตอนด้วยตัวเราเอง จากนั้นเรามีปัญหาอีกมากมายในการทำความสะอาดภาพ ไม่ช้าก็เร็ว ทุกคนที่ทำ CI/CD ต้องเผชิญกับปัญหาว่ามีภาพที่รวบรวมไว้จำนวนมาก คุณต้องกำจัดสิ่งที่ไม่จำเป็นออกไปและทิ้งสิ่งที่จำเป็นออกไป
เหตุผลที่สองคือการปรับใช้ ใช่ มีหมวกกันน็อคแต่จะแก้ปัญหาได้เพียงบางส่วนเท่านั้น น่าตลกดีที่มีเขียนไว้ว่า “Helm คือผู้จัดการแพ็คเกจสำหรับ Kubernetes” ว่า "สิ่งนั้น" คืออะไร นอกจากนี้ยังมีคำว่า "Package Manager" - ความคาดหวังตามปกติจาก Package Manager คืออะไร? เราพูดว่า: "ตัวจัดการแพ็คเกจ - ติดตั้งแพ็คเกจ!" และเราคาดหวังให้เขาบอกเราว่า “พัสดุถูกส่งไปแล้ว”
เป็นเรื่องที่น่าสนใจที่เราพูดว่า: "พวงมาลัย ติดตั้งแพ็คเกจ" และเมื่อเขาตอบว่าเขาติดตั้งแล้ว ปรากฎว่าเขาเพิ่งเริ่มการติดตั้ง - เขาระบุ Kubernetes: "เปิดตัวสิ่งนี้!" และไม่ว่ามันจะเริ่มต้นหรือไม่ก็ตาม ไม่ว่าจะใช้งานได้หรือไม่ก็ตาม Helm ไม่สามารถแก้ปัญหานี้ได้ทั้งหมด
ปรากฎว่า Helm เป็นเพียงตัวประมวลผลล่วงหน้าข้อความที่โหลดข้อมูลลงใน Kubernetes
แต่ในฐานะส่วนหนึ่งของการปรับใช้ใดๆ เราต้องการทราบว่าแอปพลิเคชันดังกล่าวได้รับการเผยแพร่เพื่อการใช้งานจริงหรือไม่ การเปิดตัวสู่ผลิตภัณฑ์หมายความว่าแอปพลิเคชันได้ย้ายไปที่นั่น มีการใช้งานเวอร์ชันใหม่แล้ว และอย่างน้อยก็ไม่ขัดข้องและตอบสนองอย่างถูกต้อง หางเสือไม่สามารถแก้ปัญหานี้ได้ แต่อย่างใด ในการแก้ปัญหา คุณจำเป็นต้องใช้ความพยายามอย่างมาก เนื่องจากคุณต้องให้คำสั่ง Kubernetes เพื่อเผยแพร่และติดตามสิ่งที่เกิดขึ้นที่นั่น ไม่ว่าจะใช้งานหรือเปิดตัวก็ตาม และยังมีงานอีกมากมายที่เกี่ยวข้องกับการใช้งาน การทำความสะอาด และการประกอบ
แผน
ปีนี้เราจะเริ่มพัฒนาท้องถิ่น เราต้องการบรรลุสิ่งที่เคยมีใน Vagrant - เราพิมพ์ว่า "vagrant up" และเราปรับใช้เครื่องเสมือน เราต้องการไปยังจุดที่มีโปรเจ็กต์ใน Git เราเขียนว่า "werf up" ที่นั่น และมันจะดึงสำเนาของโปรเจ็กต์ในเครื่องขึ้นมา ซึ่งปรับใช้ใน mini-Kub ในเครื่อง โดยมีไดเร็กทอรีทั้งหมดที่สะดวกสำหรับการพัฒนาที่เชื่อมต่อกัน . ขึ้นอยู่กับภาษาของการพัฒนา สิ่งนี้จะทำแตกต่างกัน แต่อย่างไรก็ตาม เพื่อให้สามารถดำเนินการพัฒนาในเครื่องได้อย่างสะดวกภายใต้ไฟล์ที่เมาท์
ขั้นตอนต่อไปสำหรับเราคือ ลงทุนอำนวยความสะดวกให้กับนักพัฒนา. หากต้องการปรับใช้โปรเจ็กต์ภายในเครื่องอย่างรวดเร็วด้วยเครื่องมือเดียว ให้พัฒนา พุชลงใน Git จากนั้นโปรเจ็กต์จะเข้าสู่ขั้นตอนหรือการทดสอบ ขึ้นอยู่กับไปป์ไลน์ จากนั้นใช้เครื่องมือเดียวกันเพื่อไปที่การใช้งานจริง ความสามัคคี การรวมเป็นหนึ่ง และความสามารถในการทำซ้ำของโครงสร้างพื้นฐานตั้งแต่สภาพแวดล้อมในท้องถิ่นไปจนถึงการขายเป็นจุดที่สำคัญมากสำหรับเรา แต่นี่ยังไม่อยู่ในเรากำลังดำเนินการ - เราแค่วางแผนที่จะดำเนินการเท่านั้น
แต่เส้นทางไปยัง dapp/werf นั้นเหมือนกับเส้นทาง Kubernetes ในตอนแรกเสมอ เราพบปัญหา แก้ไขด้วยวิธีแก้ปัญหา - เราคิดวิธีแก้ปัญหาบางอย่างสำหรับตัวเราเองบนเชลล์หรืออะไรก็ได้ จากนั้นพวกเขาก็พยายามปรับวิธีแก้ปัญหาเหล่านี้ให้ตรงขึ้น สรุปและรวมพวกมันเป็นไบนารีในกรณีนี้ ซึ่งเราก็แค่แบ่งปัน
มีอีกวิธีหนึ่งในการดูเรื่องราวทั้งหมดนี้พร้อมการเปรียบเทียบ
Kubernetes เป็นโครงรถที่มีเครื่องยนต์ ไม่มีประตู กระจก วิทยุ ต้นคริสต์มาส ไม่มีอะไรเลย แค่โครงกับเครื่องยนต์.. และนั่นคือพวงมาลัย - นี่คือพวงมาลัย เจ๋ง - มีพวงมาลัย แต่คุณต้องมีพินพวงมาลัย, แร็คพวงมาลัย, กระปุกเกียร์และล้อด้วยและคุณจะทำไม่ได้หากไม่มีมัน
ในกรณีของ werf นี่เป็นอีกองค์ประกอบหนึ่งของ Kubernetes เฉพาะตอนนี้ในเวอร์ชันอัลฟ่าของ werf เท่านั้น เช่น Helm ที่ถูกคอมไพล์ภายใน werf เพราะเราเบื่อที่ต้องทำมันเอง มีเหตุผลหลายประการในการทำเช่นนี้ ฉันจะบอกคุณโดยละเอียดว่าทำไมเราจึงรวบรวมหางเสือทั้งหมดพร้อมกับตัวไถพรวนภายใน werf .
ตอนนี้ werf เป็นองค์ประกอบที่บูรณาการมากขึ้น เราได้พวงมาลัยพินพวงมาลัยที่เสร็จแล้ว - ฉันไม่ค่อยเก่งเรื่องรถยนต์ แต่นี่เป็นบล็อกขนาดใหญ่ที่สามารถแก้ปัญหาได้ค่อนข้างหลากหลายอยู่แล้ว เราไม่จำเป็นต้องดูแค็ตตาล็อกด้วยตัวเอง เลือกชิ้นส่วนมาต่อกัน ลองคิดดูว่าจะขันเข้าด้วยกันอย่างไร เราได้รับชุดรวมสำเร็จรูปที่สามารถแก้ไขปัญหาจำนวนมากได้ในคราวเดียว แต่ภายในนั้นถูกสร้างขึ้นจากส่วนประกอบโอเพ่นซอร์สเดียวกัน โดยยังคงใช้ Docker ในการประกอบ และใช้ Helm สำหรับฟังก์ชันบางอย่าง และยังมีไลบรารีอื่นๆ อีกหลายแห่ง นี่เป็นเครื่องมือที่ผสานรวมเพื่อนำ CI/CD เย็นออกจากกล่องอย่างรวดเร็วและสะดวก
Kubernetes บำรุงรักษายากหรือไม่?
— คุณพูดถึงประสบการณ์ที่คุณเริ่มใช้ Kubernetes นี่คือเฟรมสำหรับคุณ เครื่องยนต์ และคุณสามารถแขวนสิ่งของต่างๆ มากมายไว้บนนั้น เช่น ตัวถัง พวงมาลัย แป้นเหยียบแบบเกลียว ที่นั่ง คำถามเกิดขึ้น - Kubernetes ให้การสนับสนุนคุณได้ยากแค่ไหน? คุณมีประสบการณ์มากมาย คุณใช้เวลาและทรัพยากรมากเพียงใดในการสนับสนุน Kubernetes โดยแยกจากสิ่งอื่นๆ ทั้งหมด
ดีมิทรี: นี่เป็นคำถามที่ยากมาก และหากต้องการตอบ เราต้องเข้าใจว่าการสนับสนุนคืออะไรและเราต้องการอะไรจาก Kubernetes บางทีคุณอาจเปิดเผยได้?
— เท่าที่ฉันรู้และเท่าที่เห็น ตอนนี้หลายทีมต้องการลองใช้ Kubernetes ทุกคนควบคุมตัวเองเพื่อวางมันไว้บนเข่า ฉันรู้สึกว่าผู้คนไม่เข้าใจความซับซ้อนของระบบนี้เสมอไป
ดีมิทรี: ประมาณนั้นแหละ.
— การติดตั้ง Kubernetes ตั้งแต่เริ่มต้นเพื่อให้พร้อมสำหรับการผลิตนั้นยากเพียงใด
ดีมิทรี: คุณคิดว่าการปลูกถ่ายหัวใจยากแค่ไหน? ฉันเข้าใจว่านี่เป็นคำถามประนีประนอม การใช้มีดผ่าตัดและไม่ทำผิดพลาดไม่ใช่เรื่องยาก หากพวกเขาบอกคุณว่าจะตัดที่ไหนและจะเย็บที่ไหน ขั้นตอนเองก็ไม่ซับซ้อน เป็นการยากที่จะรับประกันครั้งแล้วครั้งเล่าว่าทุกอย่างจะสำเร็จ
การติดตั้ง Kubernetes และทำให้มันใช้งานได้ง่ายมาก เจี๊ยบ! — ติดตั้งแล้ว มีวิธีการติดตั้งมากมาย แต่จะเกิดอะไรขึ้นเมื่อเกิดปัญหา?
คำถามเกิดขึ้นเสมอ - เรายังไม่ได้คำนึงถึงอะไรบ้าง? เรายังไม่ได้ทำอะไรเลย? พารามิเตอร์เคอร์เนล Linux ใดที่ระบุไม่ถูกต้อง พระเจ้า เรายังพูดถึงพวกเขาด้วยเหรอ?! ส่วนประกอบใดของ Kubernetes ที่เราส่งมอบ และส่วนประกอบใดที่เราไม่มี มีคำถามมากมายเกิดขึ้น และเพื่อที่จะตอบคำถามเหล่านี้ คุณต้องใช้เวลา 15-20 ปีในอุตสาหกรรมนี้
ฉันมีตัวอย่างล่าสุดในหัวข้อนี้ที่อาจเปิดเผยความหมายของปัญหา “Kubernetes บำรุงรักษายากหรือไม่” ก่อนหน้านี้เราได้พิจารณาอย่างจริงจังว่าเราควรลองใช้ Cilium เป็นเครือข่ายใน Kubernetes หรือไม่
ให้ฉันอธิบายว่าซีเลียมคืออะไร Kubernetes มีการใช้งานระบบย่อยเครือข่ายที่แตกต่างกันมากมาย และหนึ่งในนั้นก็เจ๋งมาก - Cilium ความหมายของมันคืออะไร? ในเคอร์เนลเมื่อไม่นานมานี้มีความเป็นไปได้ที่จะเขียน hooks สำหรับเคอร์เนลซึ่งบุกรุกระบบย่อยเครือข่ายและระบบย่อยอื่น ๆ ไม่ทางใดก็ทางหนึ่งและอนุญาตให้คุณข้ามชิ้นใหญ่ในเคอร์เนล
ในอดีตเคอร์เนล Linux มีเส้นทาง IP, ตัวกรองเกิน, บริดจ์และส่วนประกอบเก่าๆ มากมายที่มีอายุ 15, 20, 30 ปี โดยทั่วไปแล้วพวกมันใช้งานได้ดีทุกอย่าง แต่ตอนนี้พวกมันวางตู้คอนเทนเนอร์ซ้อนกันและดูเหมือนหอคอยที่มีอิฐ 15 ก้อนวางซ้อนกันและคุณยืนบนขาข้างเดียว - รู้สึกแปลก ๆ ระบบนี้มีการพัฒนาในอดีตโดยมีความแตกต่างหลายประการ เช่น ไส้ติ่งในร่างกาย ในบางสถานการณ์อาจมีปัญหาด้านประสิทธิภาพ เป็นต้น
มี BPF ที่ยอดเยี่ยมและความสามารถในการเขียน hooks สำหรับเคอร์เนล - พวกนั้นเขียน hooks ของตัวเองสำหรับเคอร์เนล แพ็คเกจเข้ามาในเคอร์เนล Linux โดยนำออกมาที่อินพุตประมวลผลเองตามที่ควรจะเป็นโดยไม่ต้องใช้บริดจ์ไม่มี TCP โดยไม่มีสแต็ก IP - กล่าวโดยย่อคือข้ามทุกสิ่งที่เขียนในเคอร์เนล Linux แล้วคาย มันออกไปในภาชนะ
เกิดอะไรขึ้น ประสิทธิภาพที่ยอดเยี่ยมมาก คุณสมบัติที่ยอดเยี่ยม - เจ๋งมาก! แต่เราดูเรื่องนี้และพบว่าในแต่ละเครื่องมีโปรแกรมที่เชื่อมต่อกับ Kubernetes API และขึ้นอยู่กับข้อมูลที่ได้รับจาก API นี้จะสร้างโค้ด C และคอมไพล์ไบนารีที่โหลดเข้าสู่เคอร์เนลเพื่อให้ hooks เหล่านี้ทำงาน ในพื้นที่เคอร์เนล
จะเกิดอะไรขึ้นถ้ามีอะไรผิดพลาด? พวกเราไม่รู้. เพื่อทำความเข้าใจสิ่งนี้ คุณต้องอ่านโค้ดทั้งหมดนี้ เข้าใจตรรกะทั้งหมด และมันน่าทึ่งมากว่ามันยากแค่ไหน แต่ในทางกลับกัน มีบริดจ์ ตัวกรองเน็ต เส้นทาง IP เหล่านี้ ฉันยังไม่ได้อ่านซอร์สโค้ดของพวกเขา และวิศวกร 40 คนที่ทำงานในบริษัทของเราก็ไม่มีเช่นกัน อาจมีเพียงไม่กี่คนที่เข้าใจบางส่วน
และความแตกต่างคืออะไร? ปรากฎว่ามีเส้นทาง IP, เคอร์เนล Linux และมีเครื่องมือใหม่ - มันสร้างความแตกต่างอะไรเราไม่เข้าใจอย่างใดอย่างหนึ่ง แต่เรากลัวที่จะใช้สิ่งใหม่ๆ - เพราะอะไร? เพราะหากเครื่องมือมีอายุ 30 ปีก็จะพบข้อบกพร่องทั้งหมดภายใน 30 ปี ข้อผิดพลาดทั้งหมดได้ถูกเหยียบย่ำและคุณไม่จำเป็นต้องรู้ทุกอย่าง - มันทำงานเหมือนกล่องดำและใช้งานได้ตลอดเวลา ทุกคนรู้ดีว่าไขควงวินิจฉัยตัวไหนที่จะติดไว้ที่ตำแหน่งใด tcpdump ตัวไหนที่จะทำงานในช่วงเวลาใด ทุกคนรู้จักยูทิลิตี้การวินิจฉัยเป็นอย่างดีและเข้าใจวิธีการทำงานของส่วนประกอบชุดนี้ในเคอร์เนล Linux ไม่ใช่วิธีการทำงาน แต่จะใช้งานอย่างไร
และซีเลียมสุดเจ๋งนั้นยังไม่อายุ 30 ปี แต่ยังไม่แก่ Kubernetes มีปัญหาเดียวกัน คัดลอก Cilium นั้นได้รับการติดตั้งอย่างสมบูรณ์แบบ Kubernetes ได้รับการติดตั้งอย่างสมบูรณ์แบบ แต่เมื่อมีสิ่งผิดปกติเกิดขึ้นในการใช้งานจริง คุณสามารถเข้าใจได้อย่างรวดเร็วว่าเกิดอะไรขึ้นในสถานการณ์วิกฤติหรือไม่
เมื่อเราพูดว่าการบำรุงรักษา Kubernetes นั้นยากหรือไม่ ไม่เลย มันง่ายมาก และใช่ มันยากอย่างไม่น่าเชื่อ Kubernetes ทำงานได้ดีด้วยตัวมันเอง แต่มีความแตกต่างนับพันล้าน
เกี่ยวกับแนวทาง “ฉันจะโชคดี”
— มีบริษัทใดบ้างที่เกือบจะรับประกันว่าความแตกต่างเหล่านี้จะปรากฏขึ้นหรือไม่? สมมติว่ายานเดกซ์โอนบริการทั้งหมดไปยัง Kubernetes โดยฉับพลันจะมีภาระมากมายที่นั่น
ดีมิทรี: ไม่ นี่ไม่ใช่การสนทนาเกี่ยวกับภาระ แต่เกี่ยวกับสิ่งที่ง่ายที่สุด ตัวอย่างเช่น เรามี Kubernetes เราปรับใช้แอปพลิเคชันที่นั่น คุณรู้ได้อย่างไรว่ามันใช้งานได้? ไม่มีเครื่องมือสำเร็จรูปที่จะเข้าใจว่าแอปพลิเคชันไม่ขัดข้อง ไม่มีระบบสำเร็จรูปที่ส่งการแจ้งเตือน คุณต้องกำหนดค่าการแจ้งเตือนเหล่านี้และแต่ละกำหนดการ และเรากำลังอัปเดต Kubernetes
ฉันมีอูบุนตู 16.04 พูดได้เลยว่านี่เป็นเวอร์ชันเก่า แต่เราก็ยังใช้อยู่ เพราะเป็น LTS มี systemd ซึ่งมีความแตกต่างกันนิดหน่อยคือมันไม่ล้างกลุ่ม C Kubernetes เปิดตัวพ็อด สร้างกลุ่ม C จากนั้นลบพ็อด และปรากฏว่า - ฉันจำรายละเอียดไม่ได้ ขออภัย - ชิ้น systemd นั้นยังคงอยู่ สิ่งนี้นำไปสู่ความจริงที่ว่าเมื่อเวลาผ่านไปรถยนต์ทุกคันเริ่มชะลอตัวลงอย่างมาก นี่ไม่ใช่คำถามเกี่ยวกับการโหลดสูงด้วยซ้ำ หากมีการเปิดตัวพ็อดถาวร เช่น หากมีงาน Cron ที่สร้างพ็อดอย่างต่อเนื่อง เครื่องที่ใช้ Ubuntu 16.04 จะเริ่มช้าลงหลังจากผ่านไปหนึ่งสัปดาห์ จะมีค่าเฉลี่ยการโหลดสูงอย่างต่อเนื่องเนื่องจากมีการสร้างกลุ่ม C จำนวนหนึ่ง นี่เป็นปัญหาที่ใครก็ตามที่เพิ่งติดตั้ง Ubuntu 16 และ Kubernetes ไว้ด้านบนจะต้องเผชิญ
สมมติว่าเขาอัปเดต systemd หรืออย่างอื่น แต่ในเคอร์เนล Linux สูงถึง 4.16 มันสนุกยิ่งกว่า - เมื่อคุณลบกลุ่ม C มันจะรั่วไหลในเคอร์เนลและไม่ได้ถูกลบจริงๆ ดังนั้นหลังจากใช้งานเครื่องนี้เป็นเวลาหนึ่งเดือนจึงไม่สามารถดูสถิติหน่วยความจำสำหรับเตาไฟได้ เรานำไฟล์ออกมา ม้วนมันในโปรแกรม และไฟล์หนึ่งม้วนเป็นเวลา 15 วินาที เนื่องจากเคอร์เนลใช้เวลานานมากในการนับกลุ่ม C หนึ่งล้านกลุ่มภายในตัวมันเอง ซึ่งดูเหมือนจะถูกลบออกไป แต่ไม่ - พวกมันกำลังรั่ว .
ยังมีสิ่งเล็กๆ น้อยๆ มากมายที่นี่และที่นั่น นี่ไม่ใช่ปัญหาที่บางครั้งบริษัทยักษ์ใหญ่อาจต้องเผชิญภายใต้ภาระงานหนักมาก ไม่สิ มันเป็นเรื่องของชีวิตประจำวัน ผู้คนสามารถใช้ชีวิตแบบนี้ได้เป็นเวลาหลายเดือน - พวกเขาติดตั้ง Kubernetes, ปรับใช้แอปพลิเคชัน - ดูเหมือนว่าจะได้ผล สำหรับหลายๆ คนนี่เป็นเรื่องปกติ พวกเขาจะไม่รู้ด้วยซ้ำว่าแอปพลิเคชันนี้จะขัดข้องด้วยเหตุผลบางประการ พวกเขาจะไม่ได้รับการแจ้งเตือน แต่สำหรับพวกเขานี่คือบรรทัดฐาน ก่อนหน้านี้ เราใช้งานเครื่องเสมือนโดยไม่มีการตรวจสอบ ตอนนี้เราย้ายไปที่ Kubernetes และไม่มีการตรวจสอบด้วย - อะไรคือความแตกต่าง
คำถามก็คือ เมื่อเราเดินบนน้ำแข็ง เราจะไม่มีทางรู้ความหนาของมันได้ เว้นแต่เราจะวัดล่วงหน้า หลายคนเดินแล้วไม่กังวลเพราะเคยเดินมาก่อน
จากมุมมองของฉัน ความแตกต่างและความซับซ้อนของระบบปฏิบัติการใดๆ ก็คือเพื่อให้แน่ใจว่าความหนาของน้ำแข็งนั้นเพียงพอที่จะแก้ปัญหาของเราได้ นี่คือสิ่งที่เรากำลังพูดถึง
ในด้านไอที สำหรับฉันแล้วดูเหมือนว่ามีวิธี "ฉันจะโชคดี" มากเกินไป หลายๆ คนติดตั้งซอฟต์แวร์และใช้ไลบรารีซอฟต์แวร์โดยหวังว่าพวกเขาจะโชคดี โดยทั่วไปแล้วหลายคนโชคดี นั่นอาจเป็นเหตุผลว่าทำไมมันถึงได้ผล
— จากการประเมินในแง่ร้ายของฉัน ดูเหมือนว่า: เมื่อมีความเสี่ยงสูงและแอปพลิเคชันจะต้องได้ผล จำเป็นต้องมีการสนับสนุนจาก Flaunt หรืออาจมาจาก Red Hat หรือคุณต้องการทีมงานภายในของคุณเองที่ทุ่มเทให้กับ Kubernetes โดยเฉพาะ ซึ่งพร้อมแล้ว เพื่อดึงมันออก
ดีมิทรี: โดยหลักการแล้วมันก็เป็นเช่นนั้น การเข้าถึงเรื่องราวของ Kubernetes สำหรับทีมเล็กๆ ด้วยตัวคุณเองนั้นมีความเสี่ยงหลายประการ
เราต้องการคอนเทนเนอร์หรือไม่?
— คุณช่วยบอกเราหน่อยได้ไหมว่า Kubernetes ในรัสเซียแพร่หลายแค่ไหน?
ดีมิทรี: ฉันไม่มีข้อมูลนี้ และฉันก็ไม่แน่ใจว่าใครมีข้อมูลนี้บ้าง เราพูดว่า: “Kubernetes, Kubernetes” แต่มีวิธีอื่นในการดูปัญหานี้ ฉันก็ไม่รู้เหมือนกันว่าคอนเทนเนอร์แพร่หลายแค่ไหน แต่ฉันรู้ตัวเลขจากรายงานบนอินเทอร์เน็ตว่า 70% ของคอนเทนเนอร์ถูกควบคุมโดย Kubernetes เป็นแหล่งที่เชื่อถือได้สำหรับตัวอย่างจำนวนมากทั่วโลก
อีกคำถามหนึ่ง - เราจำเป็นต้องมีคอนเทนเนอร์หรือไม่? ความรู้สึกส่วนตัวของฉันและตำแหน่งโดยรวมของบริษัท Flant คือ Kubernetes เป็นมาตรฐานโดยพฤตินัย
จะไม่มีอะไรนอกจาก Kubernetes
นี่คือตัวเปลี่ยนเกมอย่างแท้จริงในด้านการจัดการโครงสร้างพื้นฐาน สมบูรณ์แบบ - แค่นั้นแหละ ไม่มี Ansible, Chef, เครื่องเสมือน, Terraform อีกต่อไป ฉันไม่ได้พูดถึงวิธีการฟาร์มรวมแบบเก่า Kubernetes เป็นผู้เปลี่ยนแปลงอย่างแท้จริงและตอนนี้ก็จะเป็นเช่นนี้เท่านั้น
เห็นได้ชัดว่าสำหรับบางคนอาจใช้เวลาสองสามปี และสำหรับบางคนอาจถึงสองสามทศวรรษกว่าจะเข้าใจสิ่งนี้ ฉันไม่สงสัยเลยว่าจะไม่มีอะไรนอกจาก Kubernetes และรูปลักษณ์ใหม่นี้: เราไม่ทำลายระบบปฏิบัติการอีกต่อไป แต่ใช้ โครงสร้างพื้นฐานเป็นรหัสไม่ใช่เฉพาะกับโค้ด แต่ด้วย yml - โครงสร้างพื้นฐานที่อธิบายไว้อย่างชัดเจน ฉันรู้สึกว่ามันจะเป็นแบบนี้ตลอดไป
— นั่นคือ บริษัท เหล่านั้นที่ยังไม่ได้เปลี่ยนมาใช้ Kubernetes จะเปลี่ยนไปใช้แน่นอนหรือคงถูกลืมเลือน ฉันเข้าใจคุณถูกต้องใช่ไหม?
ดีมิทรี: สิ่งนี้ไม่เป็นความจริงทั้งหมดเช่นกัน ตัวอย่างเช่น หากเรามีหน้าที่ใช้งานเซิร์ฟเวอร์ DNS ก็สามารถทำงานได้บน FreeBSD 4.10 และสามารถทำงานได้อย่างสมบูรณ์แบบเป็นเวลา 20 ปี แค่ทำงานก็จบแล้ว บางทีในอีก 20 ปีข้างหน้า บางสิ่งบางอย่างจะต้องได้รับการอัปเดตอีกครั้ง หากเรากำลังพูดถึงซอฟต์แวร์ในรูปแบบที่เราเปิดตัวและใช้งานได้จริงเป็นเวลาหลายปีโดยไม่มีการอัปเดตใดๆ โดยไม่ทำการเปลี่ยนแปลง แน่นอนว่าจะไม่มี Kubernetes เขาไม่จำเป็นที่นั่น
ทุกอย่างที่เกี่ยวข้องกับ CI/CD - ทุกที่ที่ต้องการการจัดส่งแบบต่อเนื่อง ซึ่งคุณต้องอัปเดตเวอร์ชัน ทำการเปลี่ยนแปลง ทุกที่ที่คุณต้องการสร้างความทนทานต่อข้อผิดพลาด - เฉพาะ Kubernetes เท่านั้น
เกี่ยวกับไมโครเซอร์วิส
- ที่นี่ฉันมีความไม่ลงรอยกันเล็กน้อย หากต้องการทำงานกับ Kubernetes คุณต้องมีการสนับสนุนภายนอกหรือภายใน - นี่คือจุดแรก ประการที่สอง เมื่อเราเพิ่งเริ่มต้นการพัฒนา เราเป็นสตาร์ทอัพขนาดเล็ก เรายังไม่มีอะไรเลย การพัฒนาสำหรับ Kubernetes หรือสถาปัตยกรรมไมโครเซอร์วิสโดยทั่วไปอาจมีความซับซ้อนและไม่ได้ให้เหตุผลทางเศรษฐกิจเสมอไป ฉันสนใจความคิดเห็นของคุณ - สตาร์ทอัพจำเป็นต้องเริ่มเขียน Kubernetes ตั้งแต่เริ่มต้นทันทีหรือพวกเขายังสามารถเขียนเสาหินได้แล้วมาเฉพาะที่ Kubernetes เท่านั้น?
ดีมิทรี: คำถามเด็ด. ฉันมีพูดคุยเกี่ยวกับไมโครเซอร์วิส หลายครั้งที่ฉันเจอคนพยายามตอกตะปูด้วยกล้องจุลทรรศน์ แนวทางนั้นถูกต้อง เราเองออกแบบซอฟต์แวร์ภายในด้วยวิธีนี้ แต่เมื่อคุณทำเช่นนี้ คุณจะต้องเข้าใจอย่างชัดเจนว่าคุณกำลังทำอะไรอยู่ คำที่ฉันเกลียดที่สุดเกี่ยวกับไมโครเซอร์วิสคือ “ไมโคร” ในอดีต คำนี้มีต้นกำเนิดอยู่ที่นั่น และด้วยเหตุผลบางอย่างผู้คนจึงคิดว่าไมโครมีขนาดเล็กมาก น้อยกว่าหนึ่งมิลลิเมตร เช่นเดียวกับไมโครมิเตอร์ นี่เป็นสิ่งที่ผิด
ตัวอย่างเช่น มีก้อนหินใหญ่ก้อนหนึ่งที่เขียนโดยคน 300 คน และทุกคนที่มีส่วนร่วมในการพัฒนาเข้าใจดีว่ามีปัญหาอยู่ที่นั่น และควรแบ่งออกเป็นชิ้นเล็ก ๆ ประมาณ 10 ชิ้น โดยแต่ละชิ้นเขียนโดยคน 30 คน ในเวอร์ชันขั้นต่ำ นี่เป็นสิ่งสำคัญจำเป็นและเจ๋ง แต่เมื่อสตาร์ทอัพมาหาเรา โดยที่ 3 คนเก่งและเจ๋งมากเขียนไมโครเซอร์วิส 60 ไมโครเซอร์วิสไว้บนเข่าทุกครั้งที่มองหา Corvalol
สำหรับฉันดูเหมือนว่ามีการพูดถึงเรื่องนี้มาแล้วหลายพันครั้ง - เรามีเสาหินแบบกระจายในรูปแบบใดรูปแบบหนึ่ง สิ่งนี้ไม่สมเหตุสมผลทางเศรษฐกิจ แต่โดยทั่วไปแล้วเป็นเรื่องยากมากในทุกสิ่ง ฉันเพิ่งเห็นสิ่งนี้หลายครั้งจนทำให้ฉันเจ็บปวดมาก ฉันก็เลยพูดถึงมันต่อไป
สำหรับคำถามเริ่มแรกมีข้อขัดแย้งระหว่างข้อเท็จจริงที่ว่าในแง่หนึ่ง Kubernetes นั้นน่ากลัวที่จะใช้เพราะยังไม่ชัดเจนว่าสิ่งใดที่อาจพังหรือใช้งานไม่ได้ในทางกลับกันเป็นที่ชัดเจนว่าทุกอย่างไปที่นั่น และจะไม่มีอะไรนอกจาก Kubernetes คำตอบ - ชั่งน้ำหนักจำนวนผลประโยชน์ที่ได้รับ จำนวนงานที่คุณสามารถแก้ไขได้. นี่อยู่ด้านหนึ่งของเครื่องชั่ง ในทางกลับกัน มีความเสี่ยงที่เกี่ยวข้องกับการหยุดทำงานหรือเวลาตอบสนองที่ลดลง ระดับความพร้อมใช้งาน - พร้อมตัวบ่งชี้ประสิทธิภาพที่ลดลง
นี่แหละ - ไม่ว่าเราจะเคลื่อนไหวอย่างรวดเร็ว และ Kubernetes ก็ช่วยให้เราทำหลายสิ่งได้เร็วและดีขึ้นมาก หรือเราใช้โซลูชันที่เชื่อถือได้และผ่านการทดสอบตามเวลา แต่ดำเนินการได้ช้ากว่ามาก นี่คือทางเลือกที่ทุกบริษัทต้องทำ คุณสามารถมองมันเป็นเส้นทางในป่า เมื่อคุณเดินครั้งแรก คุณสามารถพบงู เสือ หรือแบดเจอร์บ้า และเมื่อคุณเดิน 10 ครั้ง คุณได้เหยียบย่ำเส้นทางที่ถูกรื้อออก กิ่งก้านและเดินได้ง่ายขึ้น ทุกครั้งที่เส้นทางกว้างขึ้น ต่อมาเป็นถนนลาดยาง และต่อมาเป็นถนนที่สวยงาม
Kubernetes ไม่หยุดนิ่ง คำถามอีกครั้ง: ในด้านหนึ่ง Kubernetes เป็นไบนารี 4-5 ในทางกลับกัน มันคือระบบนิเวศทั้งหมด นี่คือระบบปฏิบัติการที่เรามีในเครื่องของเรา นี่คืออะไร? Ubuntu หรือ Curios? นี่คือเคอร์เนล Linux ซึ่งเป็นส่วนประกอบเพิ่มเติมจำนวนหนึ่ง สิ่งเหล่านี้ทั้งหมดที่นี่ มีงูพิษตัวหนึ่งถูกโยนลงมาจากถนน มีการสร้างรั้วที่นั่น Kubernetes กำลังพัฒนาอย่างรวดเร็วและเป็นแบบไดนามิก และปริมาณความเสี่ยงและปริมาณของสิ่งที่ไม่ทราบก็ลดลงทุกเดือน และด้วยเหตุนี้ ขนาดเหล่านี้จึงมีการปรับสมดุลใหม่
ตอบคำถามว่าสตาร์ทอัพควรทำเช่นไร ฉันจะบอกว่า - มาโบกมือจ่าย 150 รูเบิล และรับบริการ DevOps แบบครบวงจรที่ง่ายดาย หากคุณเป็นสตาร์ทอัพขนาดเล็กที่มีนักพัฒนาเพียงไม่กี่คน วิธีนี้ได้ผล แทนที่จะจ้าง DevOps ของคุณเอง ซึ่งจะต้องเรียนรู้วิธีการแก้ปัญหาและจ่ายเงินเดือนในเวลานี้ คุณจะได้รับโซลูชันแบบครบวงจรสำหรับทุกปัญหา ใช่ มีข้อเสียอยู่บ้าง เราในฐานะผู้ให้บริการภายนอกไม่สามารถมีส่วนร่วมและตอบสนองต่อการเปลี่ยนแปลงได้อย่างรวดเร็ว แต่เรามีความเชี่ยวชาญและแนวปฏิบัติที่พร้อมทำมากมาย เรารับประกันว่าในทุกสถานการณ์ เราจะคิดออกอย่างรวดเร็วและฟื้น Kubernetes ขึ้นมาจากความตายอย่างแน่นอน
ฉันขอแนะนำอย่างยิ่งให้จ้างบุคคลภายนอกให้กับสตาร์ทอัพและธุรกิจที่จัดตั้งขึ้นจนถึงขนาดที่คุณสามารถอุทิศทีมงาน 10 คนให้กับการดำเนินงานได้ เพราะไม่เช่นนั้นก็ไม่มีประโยชน์ การจ้างบุคคลภายนอกนี้เป็นเรื่องที่สมเหตุสมผลอย่างแน่นอน
เกี่ยวกับอเมซอนและกูเกิล
— โฮสต์จากโซลูชันจาก Amazon หรือ Google สามารถถือเป็นบุคคลภายนอกได้หรือไม่
ดีมิทรี: ใช่ แน่นอนว่าวิธีนี้ช่วยแก้ปัญหาได้หลายประการ แต่มีความแตกต่างอีกครั้ง คุณยังต้องเข้าใจวิธีใช้งาน ตัวอย่างเช่น มีสิ่งเล็กๆ น้อยๆ มากมายในการทำงานของ Amazon AWS: Load Balancer จำเป็นต้องได้รับการวอร์มอัพ หรือต้องเขียนคำขอล่วงหน้าว่า “พวกเรา เราจะรับปริมาณการใช้งาน วอร์มอัพ Load Balancer ให้เรา!” คุณจำเป็นต้องรู้ความแตกต่างเหล่านี้
เมื่อคุณหันไปหาคนที่เชี่ยวชาญเรื่องนี้ คุณจะปิดเรื่องทั่วไปเกือบทั้งหมด ขณะนี้เรามีวิศวกร 40 คน ภายในสิ้นปีนี้อาจมีถึง 60 คน - เราเจอสิ่งเหล่านี้แน่นอน แม้ว่าเราจะเจอปัญหานี้อีกในบางโปรเจ็กต์เราก็รีบถามกันและรู้วิธีแก้ไข
คำตอบน่าจะเป็น แน่นอนว่า เรื่องราวที่จัดทำให้บางส่วนง่ายขึ้น คำถามคือคุณพร้อมที่จะเชื่อถือผู้ให้บริการโฮสต์เหล่านี้หรือไม่ และพวกเขาจะแก้ไขปัญหาของคุณหรือไม่ Amazon และ Google ทำได้ดี สำหรับทุกกรณีของเรา - อย่างแน่นอน เราไม่มีประสบการณ์เชิงบวกอีกต่อไป คลาวด์อื่นๆ ทั้งหมดที่เราพยายามทำงานด้วยทำให้เกิดปัญหามากมาย - Ager และทุกสิ่งที่อยู่ในรัสเซีย และ OpenStack ทุกประเภทในการใช้งานที่แตกต่างกัน: Headster, Overage - สิ่งที่คุณต้องการ ล้วนสร้างปัญหาที่คุณไม่อยากแก้ไข
ดังนั้นคำตอบคือใช่ แต่ในความเป็นจริงแล้ว มีโซลูชันโฮสต์ที่ครบถ้วนไม่มากนัก
ใครบ้างที่ต้องการ Kubernetes?
— แล้วใครล่ะที่ต้องการ Kubernetes? ใครบ้างที่ควรเปลี่ยนมาใช้ Kubernetes แล้ว ใครคือลูกค้า Flaunt ทั่วไปที่มาเพื่อ Kubernetes โดยเฉพาะ
ดีมิทรี: นี่เป็นคำถามที่น่าสนใจ เพราะตอนนี้ หลายคนเข้ามาหาเราหลังจากตื่นจาก Kubernetes: “พวกเรา เรารู้ว่าคุณกำลังทำ Kubernetes ทำเพื่อพวกเรา!” เราตอบพวกเขา: “ท่านสุภาพบุรุษ เราไม่ทำ Kubernetes เราผลิตและทุกอย่างที่เกี่ยวข้องกับมัน” เนื่องจากปัจจุบันเป็นไปไม่ได้เลยที่จะสร้างผลิตภัณฑ์โดยไม่ทำ CI/CD ทั้งหมดและเรื่องราวทั้งหมดนี้ ทุกคนได้ย้ายออกจากแผนกที่เรามีการพัฒนาโดยการพัฒนา แล้วเอารัดเอาเปรียบโดยการเอารัดเอาเปรียบ
ลูกค้าของเราคาดหวังสิ่งที่แตกต่าง แต่ทุกคนกำลังรอปาฏิหาริย์ดีๆ ที่พวกเขามีปัญหาบางอย่าง และตอนนี้ - กระโดดเลย! — Kubernetes จะแก้ปัญหาเหล่านั้น ผู้คนเชื่อในปาฏิหาริย์ ในใจพวกเขาเข้าใจว่าจะไม่มีปาฏิหาริย์ แต่ในจิตวิญญาณพวกเขาหวังว่า - จะเกิดอะไรขึ้นถ้า Kubernetes นี้จะแก้ปัญหาทุกอย่างให้เราตอนนี้พวกเขาพูดถึงมันมากมาย! ทันใดนั้นเขาก็จาม! - และกระสุนเงินจาม! — และเรามีความพร้อมในการทำงาน 100% นักพัฒนาทุกคนสามารถเผยแพร่สิ่งใดก็ตามที่เข้าสู่การใช้งานจริง 50 ครั้ง และมันก็ไม่ขัดข้อง โดยทั่วไปปาฏิหาริย์!
เมื่อคนเหล่านี้มาหาเรา เราก็พูดว่า “ขออภัย แต่ไม่มีปาฏิหาริย์ใดๆ เลย” เพื่อสุขภาพที่ดีคุณต้องกินให้ดีและออกกำลังกาย การจะมีผลิตภัณฑ์ที่เชื่อถือได้ จะต้องสร้างความน่าเชื่อถือ เพื่อให้มี CI/CD ที่สะดวกสบาย คุณต้องทำให้เป็นแบบนี้ นั่นเป็นงานที่ต้องทำมาก
ตอบคำถามว่าใครต้องการ Kubernetes - ไม่มีใครต้องการ Kubernetes
บางคนมีความเข้าใจผิดว่าพวกเขาต้องการ Kubernetes ผู้คนต้องการ พวกเขามีความจำเป็นอย่างลึกซึ้งที่จะหยุดคิด ศึกษา และสนใจในทุกปัญหาของโครงสร้างพื้นฐานและปัญหาในการใช้งานแอปพลิเคชันของตน พวกเขาต้องการให้แอปพลิเคชันทำงานได้และปรับใช้เท่านั้น สำหรับพวกเขา Kubernetes คือความหวังว่าพวกเขาจะหยุดได้ยินเรื่องราวที่ว่า "เรานอนอยู่ตรงนั้น" หรือ "เราไม่สามารถเปิดตัวได้" หรืออย่างอื่น
ผู้อำนวยการด้านเทคนิคมักจะมาหาเรา พวกเขาถามเขาสองสิ่ง: ด้านหนึ่งให้คุณลักษณะแก่เรา อีกด้านหนึ่งคือความมั่นคง เราขอแนะนำให้คุณรับมันเองและทำมัน กระสุนเงินหรือที่ชุบเงินก็คือ คุณจะเลิกคิดถึงปัญหาเหล่านี้และเสียเวลาไปเปล่าๆ คุณจะมีคนพิเศษที่จะปิดเรื่องนี้
ข้อความที่เราหรือใครก็ตามต้องการ Kubernetes นั้นไม่ถูกต้อง
ผู้ดูแลระบบต้องการ Kubernetes จริงๆ เพราะมันเป็นของเล่นที่น่าสนใจมากที่คุณสามารถเล่นและปรับแต่งได้ พูดตามตรงทุกคนชอบของเล่น เราทุกคนต่างก็เป็นเด็กที่ไหนสักแห่ง และเมื่อเราเห็นสิ่งใหม่ เราก็อยากเล่นมัน สำหรับบางคนก็ท้อแท้ เช่น ในฝ่ายบริหาร เพราะเล่นมามากพอแล้วและเหนื่อยจนไม่อยากเล่นแล้ว แต่สิ่งนี้ไม่ได้สูญหายไปจากใครเลย เช่น ถ้าฉันเบื่อของเล่นในด้านการบริหารระบบและ DevOps มานานแล้ว ฉันก็ยังรักของเล่นชิ้นนี้อยู่ แต่ก็ยังซื้อชิ้นใหม่อยู่ ทุกคนไม่ทางใดก็ทางหนึ่งยังคงต้องการของเล่นบางประเภท
ไม่ต้องเล่นกับโปรดักชั่น อะไรก็ตามที่ฉันแนะนำอย่างเด็ดขาดว่าอย่าทำและสิ่งที่ฉันเห็นตอนนี้มีมากมาย: “โอ้ ของเล่นใหม่!” — พวกเขาวิ่งไปซื้อ ซื้อมัน และ: “เอามันไปโรงเรียนแล้วแสดงให้เพื่อน ๆ ทุกคนดู” อย่าทำอย่างนั้น ฉันขอโทษ ลูก ๆ ของฉันเพิ่งโตขึ้น ฉันเห็นบางสิ่งในตัวเด็ก ๆ อยู่เสมอ สังเกตเห็นมันในตัวเอง แล้วจึงเล่าให้คนอื่นฟัง
คำตอบสุดท้ายคือ: คุณไม่จำเป็นต้องใช้ Kubernetes คุณต้องแก้ไขปัญหาของคุณ
สิ่งที่คุณจะได้รับคือ:
- สินค้าไม่ตก;
- แม้ว่าเขาจะพยายามล้ม แต่เรารู้เรื่องนี้ล่วงหน้า และเราสามารถใส่อะไรบางอย่างลงไปได้
- เราสามารถเปลี่ยนได้ตามความเร็วที่ธุรกิจต้องการและสะดวกไม่ทำให้เราเกิดปัญหาใดๆ
มีความต้องการที่แท้จริงสองประการ: ความน่าเชื่อถือและไดนามิก/ความยืดหยุ่นของการเปิดตัว ทุกคนที่กำลังทำโปรเจกต์ไอทีบางประเภทอยู่ในขณะนี้ ไม่ว่าจะเป็นธุรกิจประเภทไหน นุ่มนวลต่อโลก และใครก็ตามที่เข้าใจในสิ่งนี้ จำเป็นต้องแก้ไขความต้องการเหล่านี้ Kubernetes ด้วยแนวทางที่ถูกต้อง ด้วยความเข้าใจที่ถูกต้องและประสบการณ์ที่เพียงพอจะช่วยให้คุณแก้ไขปัญหาได้
เกี่ยวกับไร้เซิร์ฟเวอร์
— หากคุณมองไกลออกไปในอนาคตอีกเล็กน้อย จากนั้นพยายามแก้ไขปัญหาการไม่ปวดหัวกับโครงสร้างพื้นฐาน ด้วยความเร็วในการเปิดตัวและความเร็วในการเปลี่ยนแปลงแอปพลิเคชัน โซลูชันใหม่ ๆ จะปรากฏขึ้น เช่น ไร้เซิร์ฟเวอร์ คุณรู้สึกถึงศักยภาพในทิศทางนี้และสมมติว่าเป็นอันตรายต่อ Kubernetes และโซลูชันที่คล้ายกันหรือไม่
ดีมิทรี: นี่ต้องขอย้ำอีกครั้งว่าผมไม่ใช่ผู้ทำนายที่มองไปข้างหน้าแล้วบอกว่ามันจะเป็นแบบนี้! แม้ว่าฉันเพิ่งทำสิ่งเดียวกัน ฉันมองดูเท้าของตัวเอง และเห็นปัญหาต่างๆ มากมาย เช่น วิธีการทำงานของทรานซิสเตอร์ในคอมพิวเตอร์ มันตลกใช่มั้ย? เรากำลังพบข้อบกพร่องบางอย่างใน CPU
ทำให้ระบบไร้เซิร์ฟเวอร์มีความน่าเชื่อถือ ราคาถูก มีประสิทธิภาพและสะดวกสบาย แก้ไขปัญหาระบบนิเวศทั้งหมดได้ ในที่นี้ฉันเห็นด้วยกับอีลอน มัสก์ว่าจำเป็นต้องมีดาวเคราะห์ดวงที่สองเพื่อสร้างความทนทานต่อความผิดพลาดของมนุษยชาติ แม้ว่าฉันจะไม่รู้ว่าเขาพูดอะไร แต่ฉันเข้าใจว่าฉันยังไม่พร้อมที่จะบินไปดาวอังคารด้วยตัวเองและมันจะไม่เกิดขึ้นในวันพรุ่งนี้
ด้วยความไร้เซิร์ฟเวอร์ เห็นได้ชัดว่านี่คือสิ่งที่ถูกต้องตามอุดมคติ เช่น การทนต่อความผิดพลาดของมนุษยชาติ การมีดาวเคราะห์สองดวงย่อมดีกว่าดวงเดียว แต่ตอนนี้จะทำอย่างไร? การส่งการสำรวจครั้งเดียวจะไม่เป็นปัญหาหากคุณมุ่งความสนใจไปที่มัน ฉันคิดว่าการส่งการสำรวจหลายครั้งและตั้งถิ่นฐานผู้คนหลายพันคนที่นั่นก็เป็นเรื่องที่สมจริงเช่นกัน แต่เพื่อให้มนุษย์ครึ่งหนึ่งอาศัยอยู่ที่นั่น ดูเหมือนว่ามันจะเป็นไปไม่ได้เลย และไม่ได้รับการพิจารณา
ด้วยเซิร์ฟเวอร์แบบตัวต่อตัว: มันเจ๋ง แต่มันก็ยังห่างไกลจากปัญหาของปี 2019 ใกล้ถึงปี 2030 มาดูกันได้เลย ฉันไม่สงสัยเลยว่าเราจะอยู่ได้เราจะอยู่ได้อย่างแน่นอน (ย้ำก่อนเข้านอน) แต่ตอนนี้เราต้องแก้ไขปัญหาอื่น ๆ มันเหมือนกับการเชื่อในเทพนิยายม้าสีรุ้ง ใช่ สองสามเปอร์เซ็นต์ของคดีได้รับการแก้ไขแล้ว และพวกเขาก็แก้ไขได้อย่างสมบูรณ์แบบ แต่โดยส่วนตัวแล้ว การไร้เซิร์ฟเวอร์นั้นเป็นสายรุ้ง... สำหรับฉัน หัวข้อนี้อยู่ไกลเกินไปและเข้าใจยากเกินไป ฉันไม่พร้อมที่จะพูดคุย ในปี 2019 คุณไม่สามารถเขียนแอปพลิเคชันเดียวแบบไร้เซิร์ฟเวอร์ได้
Kubernetes จะพัฒนาไปอย่างไร
— ในขณะที่เราก้าวไปสู่อนาคตอันไกลโพ้นที่อาจแสนวิเศษนี้ คุณคิดว่า Kubernetes และระบบนิเวศโดยรอบจะพัฒนาอย่างไร
ดีมิทรี: ฉันคิดเรื่องนี้มาเยอะมากและได้คำตอบที่ชัดเจนแล้ว อย่างแรกคือ statefull อย่างไรก็ตาม การไร้สัญชาติทำได้ง่ายกว่า ในตอนแรก Kubernetes ลงทุนมากขึ้นในเรื่องนี้ ทุกอย่างเริ่มต้นจากมัน Stateless ทำงานได้เกือบจะสมบูรณ์แบบใน Kubernetes ไม่มีอะไรจะบ่น ยังคงมีปัญหาอยู่มากหรือค่อนข้างจะมีความแตกต่าง ทุกสิ่งที่นั่นใช้ได้ผลดีสำหรับเราอยู่แล้ว แต่นั่นคือเราเอง จะใช้เวลาอีกอย่างน้อยสองสามปีกว่าสิ่งนี้จะได้ผลสำหรับทุกคน นี่ไม่ใช่ตัวบ่งชี้จากการคำนวณ แต่เป็นความรู้สึกของฉันจากหัว
กล่าวโดยสรุป statefull ควร - และจะ - พัฒนาอย่างแข็งแกร่งมาก เนื่องจากแอปพลิเคชันทั้งหมดของเราจัดเก็บสถานะไว้ ไม่มีแอปพลิเคชันไร้สัญชาติ นี่เป็นภาพลวงตา คุณจำเป็นต้องมีฐานข้อมูลบางประเภทและอย่างอื่นเสมอ Statefull คือการปรับทุกอย่างที่เป็นไปได้ให้ตรง แก้ไขจุดบกพร่องทั้งหมด ปรับปรุงปัญหาทั้งหมดที่กำลังเผชิญอยู่ หรือเรียกมันว่าการรับมาใช้
ระดับของสิ่งที่ไม่รู้ ระดับของปัญหาที่ยังไม่ได้รับการแก้ไข ระดับความน่าจะเป็นที่จะเผชิญกับบางสิ่งจะลดลงอย่างมาก นี่เป็นเรื่องราวที่สำคัญ และผู้ดำเนินการ - ทุกอย่างที่เกี่ยวข้องกับการเข้ารหัสของตรรกะการดูแลระบบ ตรรกะการควบคุมเพื่อให้ได้บริการที่ง่ายดาย: บริการที่ง่ายดายของ MySQL, บริการที่ง่ายดายของ RabbitMQ, บริการที่ง่ายดายของ Memcache - โดยทั่วไปแล้ว ส่วนประกอบทั้งหมดเหล่านี้ที่เราจำเป็นต้องรับประกันว่าจะได้ผล กล่อง. นี่เป็นเพียงการแก้ความเจ็บปวดที่เราต้องการฐานข้อมูล แต่เราไม่ต้องการจัดการมัน หรือเราต้องการ Kubernetes แต่เราไม่ต้องการจัดการมัน
เรื่องราวของการพัฒนาผู้ปฏิบัติงานในรูปแบบใดรูปแบบหนึ่งนี้จะมีความสำคัญในอีกไม่กี่ปีข้างหน้า
ฉันคิดว่าความสะดวกในการใช้งานควรเพิ่มขึ้นอย่างมาก - กล่องจะกลายเป็นสีดำมากขึ้นเรื่อย ๆ เชื่อถือได้มากขึ้นเรื่อย ๆ โดยมีปุ่มที่เรียบง่ายมากขึ้นเรื่อย ๆ
ครั้งหนึ่งฉันเคยฟังบทสัมภาษณ์เก่าๆ ของ Isaac Asimov จากยุค 80 บน YouTube ทาง Saturday Night Live ซึ่งเป็นรายการอย่าง Urgant ที่น่าสนใจเท่านั้น พวกเขาถามเขาเกี่ยวกับอนาคตของคอมพิวเตอร์ เขาบอกว่าอนาคตนั้นเรียบง่ายเหมือนกับวิทยุ เดิมทีเครื่องรับวิทยุเป็นสิ่งที่ซับซ้อน ในการจับคลื่น คุณต้องหมุนปุ่มเป็นเวลา 15 นาที หมุนไม้เสียบ และโดยทั่วไปจะรู้ว่าทุกอย่างทำงานอย่างไร เข้าใจหลักฟิสิกส์ของการส่งคลื่นวิทยุ เป็นผลให้เหลือเพียงปุ่มเดียวในวิทยุ
ตอนนี้ในปี 2019 วิทยุอะไร? ในรถยนต์ เครื่องรับวิทยุจะค้นหาคลื่นและชื่อของสถานีทั้งหมด ฟิสิกส์ของกระบวนการไม่เปลี่ยนแปลงใน 100 ปี แต่ความสะดวกในการใช้งานมีการเปลี่ยนแปลง ตอนนี้และไม่เพียงตอนนี้เท่านั้น ในปี 1980 เมื่อมีการสัมภาษณ์กับ Azimov ทุกคนใช้วิทยุและไม่มีใครคิดว่ามันทำงานอย่างไร มันได้ผลเสมอ - นั่นคือการให้
อาซิมอฟก็บอกว่ามันจะเหมือนกับคอมพิวเตอร์ - ความสะดวกในการใช้งานจะเพิ่มขึ้น. แม้ว่าในปี 1980 คุณจะต้องได้รับการฝึกฝนให้กดปุ่มบนคอมพิวเตอร์ แต่จะไม่เป็นเช่นนั้นในอนาคต
ฉันรู้สึกว่าด้วย Kubernetes และโครงสร้างพื้นฐาน จะทำให้ง่ายต่อการใช้งานเพิ่มขึ้นอย่างมาก ในความคิดของฉันสิ่งนี้ชัดเจน - มันอยู่บนพื้นผิว
จะทำอย่างไรกับวิศวกร?
— จะเกิดอะไรขึ้นกับวิศวกรและผู้ดูแลระบบที่สนับสนุน Kubernetes?
ดีมิทรี: เกิดอะไรขึ้นกับนักบัญชีหลังจากการถือกำเนิดของ 1C? ไล่เลี่ยกัน. ก่อนหน้านี้พวกเขานับบนกระดาษ - ตอนนี้อยู่ในโปรแกรมแล้ว ผลิตภาพแรงงานเพิ่มขึ้นตามขนาด แต่ตัวแรงงานเองไม่ได้หายไป หากก่อนหน้านี้ต้องใช้วิศวกร 10 คนในการขันหลอดไฟ ตอนนี้มีวิศวกรเพียงคนเดียวก็เพียงพอแล้ว
สำหรับฉันแล้ว ดูเหมือนว่าจำนวนซอฟต์แวร์และจำนวนงานกำลังเติบโตในอัตราที่เร็วกว่า DevOps ใหม่ ๆ และประสิทธิภาพก็เพิ่มขึ้น ขณะนี้มีปัญหาการขาดแคลนโดยเฉพาะในตลาดและจะคงอยู่เป็นเวลานาน ต่อมาทุกอย่างจะกลับคืนสู่สภาวะปกติซึ่งประสิทธิภาพการทำงานจะเพิ่มขึ้น จะไม่มีเซิร์ฟเวอร์มากขึ้นเรื่อยๆ เซลล์ประสาทจะติดอยู่กับ Kubernetes ซึ่งจะเลือกทรัพยากรทั้งหมดให้ตรงตามที่ต้องการ และโดยทั่วไปจะ ทำทุกอย่างเท่าที่ควร - บุคคลนั้นเพียงแค่ก้าวออกไปและไม่เข้าไปยุ่ง
แต่บางคนก็ยังจำเป็นต้องตัดสินใจ เห็นได้ชัดว่าระดับคุณสมบัติและความเชี่ยวชาญของบุคคลนี้สูงกว่า ปัจจุบันแผนกบัญชีไม่ต้องการพนักงาน 10 คนคอยดูแลสมุดเพื่อไม่ให้มือเมื่อย มันไม่จำเป็นเลย เอกสารจำนวนมากได้รับการสแกนและจดจำโดยอัตโนมัติโดยระบบจัดการเอกสารอิเล็กทรอนิกส์ หัวหน้าบัญชีที่ฉลาดเพียงคนเดียวก็เพียงพอแล้ว มีทักษะที่มากกว่าเดิมและมีความเข้าใจที่ดีอยู่แล้ว
โดยทั่วไปนี่เป็นแนวทางในทุกอุตสาหกรรม รถยนต์ก็เช่นเดียวกัน ก่อนหน้านี้รถยนต์คันหนึ่งมาพร้อมกับช่างเครื่องและคนขับสามคน ปัจจุบันการขับรถเป็นกระบวนการง่ายๆ ที่เราทุกคนมีส่วนร่วมทุกวัน ไม่มีใครคิดว่ารถยนต์เป็นสิ่งที่ซับซ้อน
DevOps หรือวิศวกรรมระบบจะไม่หายไป - งานระดับสูงและประสิทธิภาพจะเพิ่มขึ้น
— ฉันยังได้ยินแนวคิดที่น่าสนใจว่างานจะเพิ่มขึ้นจริงๆ
ดีมิทรี: แน่นอน ร้อยเปอร์เซ็นต์! เนื่องจากจำนวนซอฟต์แวร์ที่เราเขียนมีเพิ่มขึ้นอย่างต่อเนื่อง จำนวนปัญหาที่เราแก้ไขด้วยซอฟต์แวร์มีเพิ่มขึ้นอย่างต่อเนื่อง ปริมาณงานมีเพิ่มขึ้น ตอนนี้ตลาด DevOps ร้อนแรงมาก นี้สามารถเห็นได้ในความคาดหวังเงินเดือน ในทางที่ดี โดยไม่ต้องลงรายละเอียด ควรมีรุ่นน้องที่ต้องการ X, คนกลางที่ต้องการ 1,5X และรุ่นพี่ที่ต้องการ 2X และตอนนี้ หากคุณดูที่ตลาดเงินเดือน DevOps ของมอสโก ผู้เยาว์ต้องการจาก X ถึง 3X และผู้อาวุโสต้องการจาก X ถึง 3X
ไม่มีใครรู้ว่ามันราคาเท่าไหร่ ระดับเงินเดือนวัดจากความมั่นใจของคุณ - พูดตามตรงว่าเป็นโรงพยาบาลบ้าที่สมบูรณ์ ตลาดที่ร้อนจัดมาก
แน่นอนว่าสถานการณ์นี้จะเปลี่ยนแปลงในไม่ช้า - ควรเกิดความอิ่มตัวบ้าง นี่ไม่ใช่กรณีของการพัฒนาซอฟต์แวร์ แม้ว่าทุกคนต้องการนักพัฒนา และทุกคนต้องการนักพัฒนาที่ดี แต่ตลาดก็เข้าใจว่าใครมีค่าอะไร - อุตสาหกรรมได้ปักหลักแล้ว นั่นไม่ใช่กรณีของ DevOps ในปัจจุบัน
— จากที่ได้ยินมาก็สรุปว่าผู้ดูแลระบบคนปัจจุบันไม่ควรกังวลมากเกินไป แต่ถึงเวลาที่จะยกระดับทักษะและเตรียมพร้อมสำหรับความจริงที่ว่าพรุ่งนี้จะมีงานเพิ่มขึ้นแต่จะมีคุณสมบัติที่สูงขึ้น
ดีมิทรี: หนึ่งร้อยเปอร์เซ็นต์. โดยทั่วไปแล้ว เราอาศัยอยู่ในปี 2019 และกฎแห่งชีวิตคือ: การเรียนรู้ตลอดชีวิต - เราเรียนรู้ตลอดชีวิตของเรา. สำหรับฉันดูเหมือนว่าตอนนี้ทุกคนรู้และรู้สึกถึงสิ่งนี้แล้ว แต่ก็ยังไม่เพียงพอที่จะรู้ - คุณต้องทำ ทุกๆวันเราต้องเปลี่ยนแปลง หากเราไม่ทำเช่นนี้ ไม่ช้าก็เร็ว เราก็จะถูกทิ้งให้อยู่ข้างสนามของอาชีพนี้
เตรียมพร้อมที่จะหักมุม 180 องศา ฉันไม่ได้ตัดทอนสถานการณ์ที่มีบางสิ่งเปลี่ยนแปลงไปอย่างสิ้นเชิงมีสิ่งใหม่เกิดขึ้น - มันเกิดขึ้น กระโดด! - และตอนนี้เราทำแตกต่างออกไป สิ่งสำคัญคือต้องเตรียมพร้อมสำหรับสิ่งนี้และไม่ต้องกังวล อาจเกิดขึ้นได้ว่าพรุ่งนี้ทุกสิ่งที่ฉันทำจะกลายเป็นสิ่งที่ไม่จำเป็น - ไม่มีอะไร ฉันเรียนมาตลอดชีวิตและพร้อมที่จะเรียนรู้อย่างอื่น มันไม่ใช่ปัญหา ไม่จำเป็นต้องกลัวความมั่นคงในงาน แต่คุณต้องเตรียมพร้อมที่จะเรียนรู้สิ่งใหม่ๆ อยู่เสมอ
ความปรารถนาและการโฆษณาสักครู่
- คุณมีความปรารถนาบ้างไหม?
ดีมิทรี: ใช่ ฉันมีความปรารถนาหลายประการ
แรกและค้าขาย - สมัครสมาชิก . เรียนผู้อ่าน ไปที่ YouTube และสมัครรับข้อมูลช่องของเรา ในอีกประมาณหนึ่งเดือน เราจะเริ่มขยายบริการวิดีโอ เราจะมีเนื้อหาการศึกษามากมายเกี่ยวกับ Kubernetes ที่เปิดกว้างและหลากหลาย: ตั้งแต่สิ่งที่ใช้งานได้จริง ไปจนถึงห้องปฏิบัติการ ไปจนถึงสิ่งทางทฤษฎีพื้นฐานเชิงลึก และวิธีการใช้ Kubernetes ที่ ระดับของหลักการและรูปแบบ
ความปรารถนาทางการค้าครั้งที่สอง - ไปที่ และติดดาวเพราะเรากินมัน ถ้าไม่ให้ดาวเราก็ไม่มีกิน มันเหมือนกับมานาในเกมคอมพิวเตอร์ เราทำอะไรบางอย่าง เราทำ เราพยายาม มีคนบอกว่าจักรยานพวกนี้แย่มาก เป็นคนที่ทุกอย่างผิดไปหมด แต่เรายังคงดำเนินต่อไปและดำเนินการอย่างซื่อสัตย์อย่างยิ่ง เราเห็นปัญหา แก้ไขและแบ่งปันประสบการณ์ของเรา ดังนั้นให้ดาวแก่เรามันจะไม่หายไปจากคุณ แต่จะมาหาเราเพราะเรากินพวกมัน
ความปรารถนาประการที่สามที่สำคัญและไม่ค้าขายอีกต่อไป - หยุดเชื่อเรื่องเทพนิยาย. คุณเป็นมืออาชีพ DevOps เป็นอาชีพที่จริงจังและมีความรับผิดชอบมาก หยุดเล่นในที่ทำงาน ให้มันคลิกเพื่อคุณแล้วคุณจะเข้าใจมัน ลองนึกภาพว่าคุณมาโรงพยาบาล และหมอกำลังทำการทดลองกับคุณอยู่ ฉันเข้าใจว่าสิ่งนี้อาจทำให้บางคนไม่พอใจ แต่เป็นไปได้มากว่านี่ไม่เกี่ยวกับคุณ แต่เกี่ยวกับคนอื่น บอกคนอื่นให้หยุดด้วย สิ่งนี้ทำลายชีวิตพวกเราทุกคนจริงๆ - หลายคนเริ่มปฏิบัติต่อฝ่ายปฏิบัติการ ผู้ดูแลระบบ และ DevOps เหมือนคนโง่ที่ทำลายบางสิ่งอีกครั้ง สิ่งนี้ "พัง" บ่อยที่สุดเนื่องจากการที่เราไปเล่นและไม่ได้มองด้วยสติที่เย็นชาว่ามันเป็นเช่นนั้นและเป็นเช่นนั้น
นี่ไม่ได้หมายความว่าคุณไม่ควรทดลอง เราจำเป็นต้องทดลองเราทำเอง พูดตามตรงบางครั้งพวกเราเองก็เล่นเกม - แน่นอนว่านี่แย่มาก แต่ไม่มีมนุษย์คนใดที่แปลกสำหรับเรา มาประกาศปี 2019 ให้เป็นปีแห่งการทดลองที่จริงจังและรอบคอบ ไม่ใช่เกมที่กำลังอยู่ระหว่างการผลิต อาจจะเป็นเช่นนั้น
- ขอบคุณมาก!
ดีมิทรี: ขอบคุณ Vitaly ทั้งสำหรับเวลาและการสัมภาษณ์ เรียนผู้อ่านขอขอบคุณมากหากคุณมาถึงจุดนี้โดยฉับพลัน ฉันหวังว่าเราจะนำความคิดมาให้คุณอย่างน้อยสองสามข้อ
ในการสัมภาษณ์ มิทรีได้กล่าวถึงประเด็นของเวิร์ฟ ตอนนี้เป็นมีดสวิสสากลที่แก้ปัญหาได้เกือบทั้งหมด แต่มันก็ไม่เป็นเช่นนั้นเสมอไป บน ในงานเทศกาล Dmitry Stolyarov จะบอกคุณเกี่ยวกับเครื่องมือนี้โดยละเอียด ในรายงาน จะมีทุกอย่าง: ปัญหาและความแตกต่างที่ซ่อนอยู่ของ Kubernetes ตัวเลือกสำหรับการแก้ปัญหาเหล่านี้และรายละเอียดการใช้งาน werf ในปัจจุบัน เข้าร่วมกับเราในวันที่ 27 และ 28 พฤษภาคม เราจะสร้างเครื่องมือที่สมบูรณ์แบบ
ที่มา: will.com