Docker-Swarm, Kubernetes, Mesos & Core-OS Fleet

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

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

ฉันกำลังแสดงรายการคำถามสองสามข้อด้วยกัน แต่จะดีมากถ้ามีคนระบุรายละเอียดทั้งหมดและตอบคำถาม

1. Kubernetes กับ Mesos:

   ลิงค์นี้

   ความแตกต่างระหว่าง Mesos ของ Apache และ Kubernetes ของ Google คืออะไร

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

2. Kubernetes กับ Core-OS Fleet:

   ถ้าฉันใช้ kubernetes จำเป็นต้องมียานพาหนะหรือไม่

3. Docker-Swarm เข้ากับสิ่งที่กล่าวมาข้างต้นอย่างไร?

การเปิดเผยข้อมูล: ฉันเป็นวิศวกรนำเกี่ยวกับ Kubernetes

ฉันคิดว่า Mesos และ Kubernetes ส่วนใหญ่มีเป้าหมายเพื่อแก้ไขปัญหาที่คล้ายกันของการเรียกใช้แอปพลิเคชันแบบกลุ่มพวกเขามีประวัติที่แตกต่างกันและวิธีการที่แตกต่างกันในการแก้ปัญหา

Mesos ให้ความสำคัญกับพลังงานในการจัดตารางเวลาทั่วไปและเสียบเข้ากับกำหนดการที่แตกต่างหลากหลาย ซึ่งหมายความว่าจะช่วยให้ระบบเช่น Hadoop และ Marathon มีอยู่ในสภาพแวดล้อมการจัดตารางเวลาเดียวกัน Mesos มุ่งเน้นที่การใช้ภาชนะบรรจุน้อยกว่า มี Mesos อยู่ก่อนที่จะมีความสนใจอย่างกว้างขวางในตู้คอนเทนเนอร์และได้รับการแยกส่วนในการรองรับตู้คอนเทนเนอร์

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

เรือเดินสมุทรเป็นตัวแทนจำหน่ายภารกิจระดับล่าง มันมีประโยชน์สำหรับการบูตระบบคลัสเตอร์เช่น CoreOS ใช้เพื่อแจกจ่ายเอเจนต์ kubernetes และไบนารีออกไปยังเครื่องในคลัสเตอร์เพื่อเปิดคลัสเตอร์ kubernetes มันไม่ได้มีจุดประสงค์เพื่อแก้ปัญหาการพัฒนาแอพพลิเคชั่นแบบเดียวกันลองคิดดูเพิ่มเติมเช่น systemd / init.d / upstart สำหรับคลัสเตอร์ของคุณ ไม่จำเป็นถ้าคุณเรียกใช้ kubernetes คุณสามารถใช้เครื่องมืออื่น ๆ (เช่น Salt, Puppet, Ansible, Chef, ... ) เพื่อให้ได้การแจกแจงแบบไบนารีที่เหมือนกัน

Swarm เป็นความพยายามของนักเทียบท่าเพื่อขยาย Docker API ที่มีอยู่เพื่อให้กลุ่มของเครื่องดูเหมือน Docker API เดียว โดยพื้นฐานแล้วประสบการณ์ของเราที่ Google และที่อื่น ๆ บ่งชี้ว่าโหนด API ไม่เพียงพอสำหรับ API คลัสเตอร์ คุณสามารถดูการสนทนามากมายได้ที่นี่: https://github.com/docker/docker/pull/8859และที่นี่: https://github.com/docker/docker/issues/8781

หวังว่าจะช่วย! เข้าร่วมกับเราใน IRC @ # google-container ถ้าคุณต้องการพูดคุยเพิ่มเติม

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

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

ในคำปราศรัย DockerCon โซโลมอน Hykes แนะนำ Swarm จะเป็นระดับที่สามารถให้อินเทอร์เฟซทั่วไปลงบน orchestration และเฟรมเวิร์กการกำหนดเวลาจำนวนมาก จากสิ่งที่ฉันเห็น Swarm ได้รับการออกแบบมาเพื่อมอบเวิร์กโฟลว์การปรับใช้ Docker ที่ราบรื่นการทำงานกับเฟรมเวิร์กคอนเทนเนอร์เวิร์กโฟลว์ที่มีอยู่เช่น Deis แต่มีความยืดหยุ่นเพียงพอที่จะรองรับการปรับใช้ "หนา" และการจัดการทรัพยากรเช่น Mesos

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

เท่าที่ฉันเข้าใจ:

Mesos, Kubernetes และ Fleet ต่างพยายามแก้ปัญหาที่คล้ายกันมาก แนวคิดก็คือคุณแยกเอาฮาร์ดแวร์ของคุณออกจากนักพัฒนาและ 'เครื่องมือจัดการคลัสเตอร์' จะคัดแยกให้คุณทั้งหมด จากนั้นสิ่งที่คุณต้องทำคือให้คอนเทนเนอร์แก่คลัสเตอร์ให้ข้อมูลบางอย่าง (ให้มันทำงานอย่างถาวรขยายขนาดถ้า X เกิดขึ้น ฯลฯ ) และผู้จัดการคลัสเตอร์จะทำให้มันเกิดขึ้น

ด้วย Mesos จะจัดการคลัสเตอร์ทั้งหมดให้คุณ แต่จะไม่รวมตัวกำหนดตารางเวลา ตัวกำหนดตารางเวลาเป็นบิตที่บอกว่าโอเคกระบวนการนี้ต้องการ 2 procs และ RAM 512MB และฉันมีเครื่องตรงนั้นฟรีนั่นดังนั้นฉันจะเรียกใช้บนเครื่องนั้น มีโปรแกรมเสริมปลั๊กอินสำหรับ Mesos: Marathon และ Chronos และคุณสามารถเขียนของคุณเองได้ สิ่งนี้ทำให้คุณมีพลังในการกระจายทรัพยากรและการปรับขนาดคลัสเตอร์เป็นต้น

Fleet และ Kubernetes ดูเหมือนจะสรุปรายละเอียดเหล่านั้นออกไป (ดังนั้นคุณไม่ต้องเขียนกำหนดการของคุณเองโดยทั่วไป) ซึ่งหมายความว่าคุณต้องกำหนดงานของคุณและส่งในรูปแบบ / ลักษณะที่กำหนดโดย Fleet หรือ Kubernetes จากนั้นพวกเขาจะเข้ามาและกำหนดเวลางาน (คอนเทนเนอร์) ให้คุณ

ดังนั้นฉันเดาว่า: การใช้ Mesos อาจหมายถึงงานเขียนตัวกำหนดตารางเวลาของคุณเองอีกเล็กน้อย แต่อาจให้ความยืดหยุ่นมากกว่านี้หากจำเป็น

ฉันคิดว่าความคิดในการใช้ Kubernetes อยู่ด้านบนของ Mesos คือ Kubernetes ทำหน้าที่เป็นตัวกำหนดตารางเวลาสำหรับ Mesos โดยส่วนตัวแล้วฉันไม่แน่ใจว่าประโยชน์ที่จะได้รับจากการทำงานด้วยตัวของมันเอง (หวังว่าจะมีใครบางคนกระโดดเข้ามาและอธิบาย!)

อย่างที่ MikeB กล่าวว่า .. มันเป็นวันแรกและทั้งหมดก็พร้อมแล้วที่จะคว้า (จับตามอง ECS ของ Amazon ด้วย) ดังนั้นจึงมีมาตรฐานการแข่งขันมากมายและทับซ้อนกันมากมาย!

-edit- ฉันไม่ได้พูดถึงนักเทียบท่าฝูงเพราะฉันไม่ได้มีประสบการณ์มากกับมัน

สำหรับใครก็ตามที่มาที่นี่หลังจากปี 2560 ฝูงบินถูกยกเลิก ห้ามใช้อีกต่อไป

เอกสาร Fleetพูดว่า "กองทัพเรือจะไม่พัฒนาอย่างแข็งขันหรือการเก็บรักษาโดย CoreOS" และเชื่อมโยงไปประสานคอนเทนเนอร์: ย้ายจากเรือเดินสมุทรที่จะ Kubernetes กองเรือรบถูกลบออกจาก Container Linux ( เดิมชื่อ CoreOS Linux ) และแทนที่ด้วย Kubernetes kubelet (ตัวแทน) สิ่งนี้ใกล้เคียงกับ pivot ขององค์กรเพื่อเสนอTectonic (a Kubernetes distro) เป็นผลิตภัณฑ์หลักของพวกเขา