รวมนักเทียบท่า Swarm และ Kubernetes

บริษัท ของฉันพยายามเล่นให้ทันในพื้นที่ DevOps ฉันได้ทำการค้นคว้ามากมายเกี่ยวกับการจัดเก็บแอปพลิเคชันและระบบ orchestration ที่สอดคล้องกับมัน ฉันเจอบทความ (สิ่งที่ฉันหวังว่าจะได้รับการบันทึก) ที่พวกเขากำลังพูดถึงการรวม Swarm เข้ากับ Kubernetes เพื่อรับฟังก์ชั่นที่ดีขึ้น ในบทความนี้พวกเขาไม่ได้กำหนดสิ่งที่พวกเขาได้รับจากการทำเช่นนั้น

ฉันสงสัยว่าจะให้ประโยชน์อะไรบ้าง การเพิ่มเลเยอร์พิเศษของความซับซ้อนกำลังจะให้ผลตอบแทนมากหรือไม่?

แก้ไข:ฉันกำลังมองหามืออาชีพด้านเทคนิค / แย้งของ KISS เป็นคำขวัญที่ดี แต่ไม่ได้โต้เถียงกับ CEO หรือ Board ของคุณ

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

— EvanM
แหล่งที่มา

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

— Jiri Klouda

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

— EvanM

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

— EvanM

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

— Jiri Klouda

คำตอบ:

อัปเดต: Docker เพิ่งเปิดตัวรองรับ Kubernetesเป็นตัวกำหนดตารางเวลาซึ่งจะเปลี่ยนสถานการณ์และทำให้ Kubernetes เป็นเพียงตัวกำหนดตารางเวลาสำรองให้กับ Docker Swarm

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

เหล่านี้คือสองขนานและรายการเทียบเท่าส่วนใหญ่เทคโนโลยี หากธุรกิจของคุณมีเหตุผลทางธุรกิจที่ถูกต้องตามกฎหมายในการปรับใช้ในผู้ให้บริการคลาวด์หลายรายเพื่อความน่าเชื่อถือและต้องการปรับใช้กับทั้ง AWS ECS (Elastic Container Service - ยึดตาม Docker) และ Google GKE (Engine Engine - ยึดตาม Kubernetes) คุณสร้างไปป์ไลน์ซึ่งจะสร้างซอฟต์แวร์และแพคเกจของคุณในคอนเทนเนอร์สำหรับการปรับใช้ในทั้งสองอย่างนั้นจะเป็นอย่างอื่น แต่ทำมันเพียงเพราะคุณต้องการเล่นกับเทคโนโลยีใหม่จะไม่รับผิดชอบมาก

— Jiri Klouda
แหล่งที่มา

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

— EvanM

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

— Jiri Klouda

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

— EvanM

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

— Jiri Klouda

เหตุผลหนึ่งในการใช้ Kubernetes เป็นตัวกำหนดตารางเวลาหากคุณใช้หรือพิจารณาว่า Azure เป็นผู้ให้บริการคลาวด์คือบริการ AKS ที่ค่อนข้างใหม่ (kubernetes ที่มีการจัดการ) ในกรณีนี้คุณจะไม่รวม kubernetes กับ docker swarm

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

— PussInBoots
แหล่งที่มา