Kubernetes เทียบกับ CloudFoundry [ปิด]

CloudFoundry / Diego เวอร์ชันถัดไปจะให้การสนับสนุนเนทีฟสำหรับคอนเทนเนอร์ Docker ซึ่งจะได้รับการจัดระเบียบข้ามโฮสต์หลายตัว [ ลิงก์ ] ฟังดูคล้ายกับ Kubernetes มาก

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

ดังนั้นฉันจึงสงสัยเกี่ยวกับกรณีการใช้งานที่ Kubernetes จะเพิ่มมูลค่าได้มากกว่า CloudFoundry?

ในฐานะที่เป็นทั้งผู้สื่อสาร CloudFoundry (อดีต) และ Kubernetes (ปัจจุบัน) ฉันอาจมีคุณสมบัติที่ไม่เหมือนใครที่จะตอบคำถามนี้

PaaS เหมือน

ฉันชอบเรียก CloudFoundry ว่า "Application PaaS" และ Kubernetes ว่า "Container PaaS" แต่ความแตกต่างนั้นค่อนข้างละเอียดอ่อนและลื่นไหลเนื่องจากทั้งสองโครงการเปลี่ยนแปลงตลอดเวลาเพื่อแข่งขันในตลาดเดียวกัน

ความแตกต่างระหว่างทั้งสองคือ CF มีเลเยอร์การจัดเตรียมที่ใช้แอพผู้ใช้ (12 ปัจจัย) (เช่น jar หรือ gem) และ buildpack สไตล์ Heroku (เช่น Java + Tomcat หรือ Ruby) และสร้างหยด (คล้ายกับ a อิมเมจ Docker) CF ไม่เปิดเผยอินเทอร์เฟซการจัดคอนเทนเนอร์ให้กับผู้ใช้ แต่ Kubernetes ทำ

ผู้ชม

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

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

ความแตกต่างนี้อาจเปลี่ยนแปลงได้ในอนาคต:

• CloudFoundry สามารถเริ่มยอมรับอิมเมจนักเทียบท่าได้ ( Lattice ยอมรับอิมเมจ Docker )
• Kubernetes สามารถเพิ่มเลเยอร์การสร้างภาพได้ ( OpenShift ทำอะไรแบบนี้ )

การเปรียบเทียบคุณสมบัติ

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

ทั้ง CF และ K8 มีคุณสมบัติที่คล้ายกันมากมายเช่น containerization, namespacing, authentication,

ข้อได้เปรียบในการแข่งขันของ Kubernetes:

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

ข้อดีในการแข่งขันของ CloudFoundry:

• การรับรองความถูกต้องตามผู้ใหญ่การจัดกลุ่มผู้ใช้และการสนับสนุนหลายผู้เช่า [x]
• นำแอปของคุณเอง
• รวมตัวจัดสรรภาระงาน
• ปรับใช้ปรับขนาดและรักษาชีวิตโดย BOSH [x]
• การบันทึกที่มีประสิทธิภาพและการรวมเมตริก [x]
• GUI เว็บสำหรับองค์กร [x]

[x] คุณสมบัติเหล่านี้ไม่ได้เป็นส่วนหนึ่งของ Diego หรือรวมอยู่ใน Lattice

การปรับใช้

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

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

บริบททางประวัติศาสตร์

Diego เป็นการเขียนซ้ำของ Droplet Execution Agent ของ CF เดิมได้รับการพัฒนาก่อนที่ Kubernetes จะประกาศและมีการใช้ขอบเขตคุณลักษณะมากขึ้นเนื่องจากแนวการแข่งขันมีการพัฒนา เป้าหมายเดิมคือการสร้างหยด (แอปพลิเคชันผู้ใช้ + CF buildpack) และเรียกใช้ในคอนเทนเนอร์ Warden (เปลี่ยนชื่อเป็นการ์เด้นเมื่อเขียนใหม่ใน Go) นับตั้งแต่ก่อตั้งขึ้นก็ยังได้รับการบรรจุใหม่เป็นLatticeซึ่งค่อนข้างเป็น CloudFoundry-lite (แม้ว่าชื่อนี้จะถูกนำมาใช้โดยโครงการที่มีอยู่). ด้วยเหตุนี้ Lattice จึงค่อนข้างคล้ายของเล่นเนื่องจากมีการลดจำนวนผู้ชมและขอบเขตของผู้ใช้ลงโดยเจตนาขาดคุณสมบัติที่จะทำให้ "พร้อมสำหรับองค์กร" อย่างชัดเจน คุณสมบัติที่ CF มีให้แล้ว ส่วนหนึ่งเป็นเพราะ Lattice ใช้ในการทดสอบส่วนประกอบหลักโดยไม่มีค่าใช้จ่ายบางส่วนจาก CF ที่ซับซ้อนมากขึ้น แต่คุณยังสามารถใช้ Lattice ในสภาพแวดล้อมที่มีความน่าเชื่อถือสูงภายในซึ่งการรักษาความปลอดภัยและการเช่าหลายรายไม่ได้เป็นสิ่งที่น่ากังวลมากนัก .

นอกจากนี้ยังควรค่าแก่การกล่าวถึงว่า CloudFoundry และ Warden (เอนจิ้นคอนเทนเนอร์) ก่อนหน้า Docker ด้วยเช่นกันภายในสองสามปี

ในทางกลับกัน Kubernetes เป็นโครงการค่อนข้างใหม่ที่ Google พัฒนาขึ้นตามการใช้งานคอนเทนเนอร์หลายปีกับ BORG และ Omega Kubernetes อาจถูกมองว่าเป็นการจัดระเบียบคอนเทนเนอร์รุ่นที่ 3 ที่ Google เช่นเดียวกับ Diego คือการจัดเตรียมคอนเทนเนอร์รุ่นที่ 3 ที่ Pivotal / VMware (v1 เขียนที่ VMware; v2 ที่ VMware พร้อมความช่วยเหลือของ Pivotal Labs; v3 ที่ Pivotal หลังจากเข้ายึดโครงการ) .

Cloud Foundry เป็นเครื่องมือที่ยอดเยี่ยมโดยสมมติว่าคุณเต็มใจที่จะทำงานภายใต้ข้อ จำกัด ของการเสนอขายเนื่องจากมีความเห็น / กำหนดไว้มาก UI ของเว็บดูดีในวันแรก แต่ไม่ค่อยได้ใช้หลังจากที่คุณเริ่มทำงานกับไคลเอนต์และกำหนดค่าไปป์ไลน์ CI / CD ของคุณ ฉันพบว่า Cloud Foundry นั้นยอดเยี่ยมจนกว่ากรณีการใช้งานจะปรากฏขึ้นซึ่งไม่ได้รับการสนับสนุนอย่างเต็มที่ภายใน Cloud Foundry การส่งมอบกรณีการใช้งานเหล่านี้อาจทำให้โครงการล่าช้าในขณะที่คุณพยายามแก้ไขปัญหาเหล่านั้นด้วยเหตุนี้คุณจึงสูญเสียการมองเห็นโครงสร้างพื้นฐานและการสนับสนุนประโยชน์ของส่วนประกอบเหล่านั้นซึ่งส่วนใหญ่ทำงานนอก Cloud Foundry (ลองนึกถึงฐานข้อมูลหลาย ๆ ฐานข้อมูล, คาฟคา, ฮาวูป, คาสซานดรา ฯลฯ ) ฉันสงสัยว่าเมื่อเวลาผ่านไปโมเมนตัมรอบ ๆ Docker และความยืดหยุ่นของ Cloud Foundry จะนำผู้ใช้ไปยัง Kubernetes Mesos หรือ Docker Swarm / Datacenter เป็นไปได้ว่า Cloud Foundry สามารถติดตามทั้งสามนี้ได้ แต่ดูเหมือนจะไม่น่าเป็นไปได้เนื่องจากความนิยมของโครงการโอเพ่นซอร์สเหล่านี้

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

จริงอยู่ที่ฉันพูดแบบนี้ในฐานะนักพัฒนา Kubernetes อาจมีคนถามคำถามเดียวกันกับ Kubernetes vs Mesos, Amazon ECS vs Kubernetes หรือ Docker Swarm vs Kubernetes

ฉันหวังว่าเมื่อเวลาผ่านไปเราทุกคนมีแนวโน้มไปในทิศทางเดียวกันและสามารถทำงานร่วมกันได้มากขึ้นและใช้เวลาน้อยลงในการสร้างสรรค์งานของกันและกัน

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

ความแตกต่างที่สำคัญในความคิดของฉันคือแนวทางที่พวกเขากำลังดำเนินการ:

CF สร้างรันไทม์จากส่วนประกอบ 3 ส่วนโดยอัตโนมัติ: ไบนารีแอปพลิเคชันที่ผู้ใช้ให้มา, buildpack ที่มีมิดเดิลแวร์ที่จำเป็นในการเรียกใช้แอปและอิมเมจระบบปฏิบัติการ (stemcell) ผู้ใช้ CF (ผู้พัฒนา) ต้องจัดเตรียมไบนารีของแอปพลิเคชันเท่านั้น (เช่นไฟล์ jar ที่เรียกใช้งานได้) CF ดูแลส่วนที่เหลือนั่นคือการบรรจุหีบห่อและเรียกใช้แอป

Kubernetes คาดหวังจากอิมเมจ Docker ของนักพัฒนาซอฟต์แวร์ที่มีมิดเดิลแวร์และ OS ในตัวอยู่แล้วและพร้อมที่จะรัน ด้วยเหตุนี้ Kubernetes“ deployment manifest” (เช่นแผนภูมิ Helm) ไม่เพียง แต่อธิบายถึงแอปหรือบริการเดียว แต่ยังรวมถึงบริการ [micro] ทั้งหมดที่ประกอบด้วยโซลูชันของคุณในขณะรันไทม์ คุณส่งคำอธิบายรันไทม์ของคุณเพียงคำอธิบายเดียวและ Kubernetes จะดูแลเกี่ยวกับสถานะรันไทม์จริงที่ตรงกับคำอธิบายของคุณ

ดังนั้นแนวทาง CF ช่วยให้สามารถจัดการกับกรณีการใช้งานดังกล่าวเช่น "แทนที่ระบบปฏิบัติการด้วยข้อบกพร่องด้านความปลอดภัยที่ได้รับการแก้ไขแล้วในระบบคลาวด์ทั้งหมดของคุณโดยไม่ต้องหยุดทำงานสำหรับบริการของคุณ" แต่ยังมุ่งเน้นไปที่บริการต่อการปรับใช้บริการแทนคำอธิบายโดยเปิดเผยของรันไทม์เป้าหมายที่ "เหมาะ" ของระบบของคุณ

Cloud Foundry เป็นระบบคลาวด์คอมพิวติ้งแพลตฟอร์มแบบโอเพนซอร์ส Cloud Foundry ช่วยให้สามารถปรับใช้โครงการในพื้นที่ต่างๆและยังผูกบริการคลาวด์กับแอปพลิเคชันของคุณ

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

การปรับใช้ kubernetes ใด ๆ ต้องใช้ทรัพยากรสองอย่างเป็นอย่างน้อย:

1) deployment.yaml: ทรัพยากรนี้กำหนดเวอร์ชันของอิมเมจที่ต้องรับจากการลงทะเบียนคอนเทนเนอร์ของคุณแบบจำลอง (แบบจำลองพ็อด) กลยุทธ์การเปิดตัวการปรับขนาดและโพรบเป็นต้น

2) service.yaml: เป็นอินเทอร์เฟซระหว่างพ็อดภายในของคุณกับโลกภายนอกทราฟฟิกภายนอกทั้งหมดจะรับฟังพอร์ตที่กำหนดในทรัพยากรนี้จากที่ที่มันกระจายโหลดไปยังพ็อดภายใน

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

เพิ่มเติมเกี่ยวกับ kubernetes คุณสามารถดูได้ด้านล่าง: https://kubernetes.io/docs/

[pcf vs kubernetes] [1] ความแตกต่างระหว่าง pcf และ kubernetes

                                PCF

(สิ่งที่เป็นนามธรรมของแพลตฟอร์มในระดับแอปพลิเคชัน) • Pivotal Cloud Foundry เป็นนามธรรมระดับสูงของการพัฒนาแอปพลิเคชันบนระบบคลาวด์

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

• PCF เป็นตัวอย่างหนึ่งของ PaaS "แอปพลิเคชัน" (เรียกอีกอย่างว่า Cloud Foundry Application Runtime)

•ผู้พัฒนาดูแลแอปพลิเคชันในอนาคต

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

                       Kubernetes 

(สิ่งที่เป็นนามธรรมของแพลตฟอร์มที่ระดับคอนเทนเนอร์) • Kubernetes เป็นตัวกำหนดตารางเวลาคอนเทนเนอร์หรือออเคสตเตอเรเตอร์

•เรามีสิ่งที่เป็นนามธรรมของแพลตฟอร์มในระดับคอนเทนเนอร์การสร้างและปรับใช้คอนเทนเนอร์เป็นส่วนหนึ่งของแอปพลิเคชันที่สมบูรณ์

• Kubernetes เป็น PaaS "คอนเทนเนอร์" (บางครั้งเรียกว่า CaaS)

•ด้วยเครื่องมือการจัดระเบียบคอนเทนเนอร์นักพัฒนาจะสร้างและดูแลรักษาคอนเทนเนอร์ในอนาคต

•สำหรับการใช้งานใหม่ทีมวิศวกรของคุณทำงานได้มากขึ้นและผลผลิตลดลง

แนวโน้มหลังจาก 4 ปีมีลักษณะดังนี้:

คลัสเตอร์ Kubernetes มีราคาถูกมากในปัจจุบันและสภาพแวดล้อมการใช้เครื่องมือสำหรับ kubernetes ก็ดีขึ้น

นอกจากนี้คุณสมบัติการแข่งขันส่วนใหญ่ที่แสดงโดยผู้โพสต์อื่น ๆ นั้นง่ายต่อการทำซ้ำภายใน kubernetes ในทุกวันนี้