“Kubernetes และ OpenShift แตกต่างกันอย่างไร” – คำถามนี้เกิดขึ้นด้วยความสม่ำเสมอที่น่าอิจฉา แม้ว่าในความเป็นจริงแล้วสิ่งนี้จะเหมือนกับการถามว่ารถยนต์แตกต่างจากเครื่องยนต์อย่างไร หากเรายังคงเปรียบเทียบต่อไป รถยนต์ก็เป็นผลิตภัณฑ์สำเร็จรูป คุณสามารถใช้มันได้ทันที: เข้าและออก ในทางกลับกัน เพื่อให้เครื่องยนต์พาคุณไปที่ไหนสักแห่งได้ จะต้องเสริมด้วยสิ่งอื่นๆ มากมายก่อนจึงจะได้รถคันเดียวกันในที่สุด
ดังนั้น Kubernetes จึงเป็นกลไกที่ใช้ประกอบรถยนต์ (แพลตฟอร์ม) ยี่ห้อ OpenShift ซึ่งจะพาคุณไปสู่เป้าหมาย
ในบทความนี้ เราต้องการเตือนคุณและตรวจสอบประเด็นสำคัญต่อไปนี้โดยละเอียดเพิ่มเติมอีกเล็กน้อย:
- Kubernetes เป็นหัวใจของแพลตฟอร์ม OpenShift และเป็น Kubernetes ที่ได้รับการรับรอง 100% เป็นโอเพ่นซอร์สโดยสมบูรณ์และไม่มีลักษณะกรรมสิทธิ์แม้แต่น้อย สั้น ๆ :
- API คลัสเตอร์ OpenShift คือ Kubernetes XNUMX%
- หากคอนเทนเนอร์ทำงานบนระบบ Kubernetes อื่นๆ คอนเทนเนอร์จะทำงานบน OpenShift โดยไม่มีการเปลี่ยนแปลงใดๆ ไม่จำเป็นต้องทำการเปลี่ยนแปลงแอปพลิเคชัน
- OpenShift ไม่เพียงแต่เพิ่มคุณสมบัติและฟังก์ชันที่เป็นประโยชน์ให้กับ Kubernetes เท่านั้น เช่นเดียวกับรถยนต์ OpenShift นั้นแกะกล่อง สามารถนำไปผลิตได้ทันที และดังที่เราจะแสดงด้านล่างนี้ ทำให้ชีวิตของนักพัฒนาง่ายขึ้นมาก นั่นคือเหตุผลที่ OpenShift รวมเป็นสองคน เป็นทั้งแพลตฟอร์ม PaaS ระดับองค์กรที่ประสบความสำเร็จและเป็นที่รู้จักจากมุมมองของนักพัฒนา และในขณะเดียวกัน ก็เป็นโซลูชัน Container-as-a-Service ที่น่าเชื่อถืออย่างยิ่งจากมุมมองของการดำเนินงานทางอุตสาหกรรม
OpenShift คือ Kubernetes ที่ได้รับการรับรอง CNCF 100%
OpenShift ขึ้นอยู่กับ
คุณคงเคยได้ยินเกี่ยวกับยูทิลิตีบรรทัดคำสั่งของ OpenShift ที่เรียกว่า OC มันเข้ากันได้กับคำสั่ง kubectl อย่างสมบูรณ์ แถมยังมีตัวช่วยที่มีประโยชน์มากมายที่จะมีประโยชน์เมื่อทำงานหลายอย่าง แต่ก่อนอื่น เพิ่มเติมอีกเล็กน้อยเกี่ยวกับความเข้ากันได้ของ OC และ kubectl:
คำสั่ง kubectl
ทีมโอซี
kubectl รับฝัก
oc รับพ็อด
kubectl รับเนมสเปซ
oc รับเนมสเปซ
kubectl สร้าง -f Deployment.yaml
oc สร้าง -f Deployment.yaml
ผลลัพธ์ของการใช้ kubectl บน OpenShift API มีลักษณะดังนี้:
• kubectl get pods – ส่งคืนพ็อดตามที่คาดไว้
• kubectl รับเนมสเปซ – ส่งคืนเนมสเปซตามที่คาดไว้
คำสั่ง kubectl create -f mydeployment.yaml จะสร้างทรัพยากร kubernetes เช่นเดียวกับบนแพลตฟอร์ม Kubernetes อื่นๆ ดังที่แสดงในวิดีโอด้านล่าง:
กล่าวอีกนัยหนึ่ง Kubernetes API ทั้งหมดพร้อมใช้งานอย่างเต็มรูปแบบใน OpenShift ในขณะที่ยังคงความเข้ากันได้ 100% นั่นคือเหตุผล
OpenShift เพิ่มคุณสมบัติที่เป็นประโยชน์ให้กับ Kubernetes
Kubernetes API พร้อมใช้งาน 100% ใน OpenShift แต่ kubectl ยูทิลิตี้ Kubernetes มาตรฐานขาดฟังก์ชันและความสะดวกสบายอย่างชัดเจน นั่นเป็นเหตุผลที่ Red Hat ได้เพิ่มคุณสมบัติที่มีประโยชน์และเครื่องมือบรรทัดคำสั่งให้กับ Kubernetes เช่น OC (ย่อมาจากไคลเอนต์ OpenShift) และ ODO (OpenShift DO ยูทิลิตี้นี้มุ่งเป้าไปที่นักพัฒนา)
1. ยูทิลิตี้ OC - Kubectl เวอร์ชันที่ทรงพลังและสะดวกยิ่งขึ้น
ตัวอย่างเช่น ต่างจาก kubectl ตรงที่ช่วยให้คุณสร้างเนมสเปซใหม่และสลับบริบทได้อย่างง่ายดาย และยังเสนอคำสั่งที่มีประโยชน์มากมายสำหรับนักพัฒนา เช่น การสร้างคอนเทนเนอร์อิมเมจและปรับใช้แอปพลิเคชันโดยตรงจากซอร์สโค้ดหรือไบนารี (Source-to-image, s2i)
มาดูตัวอย่างว่าตัวช่วยในตัวและฟังก์ชันขั้นสูงของยูทิลิตี้ OC ช่วยให้การทำงานในแต่ละวันง่ายขึ้นได้อย่างไร
ตัวอย่างแรกคือการจัดการเนมสเปซ แต่ละคลัสเตอร์ Kubernetes จะมีเนมสเปซหลายรายการเสมอ โดยปกติจะใช้เพื่อสร้างสภาพแวดล้อมการพัฒนาและการใช้งานจริง แต่ยังสามารถใช้เพื่อมอบ Sandbox ส่วนบุคคลให้กับนักพัฒนาแต่ละคนได้ ในทางปฏิบัติ สิ่งนี้ส่งผลให้นักพัฒนาต้องสลับระหว่างเนมสเปซบ่อยครั้ง เนื่องจาก kubectl ทำงานในบริบทของพื้นที่ปัจจุบัน ดังนั้น ในกรณีของ kubectl ผู้คนจึงใช้สคริปต์ตัวช่วยในการดำเนินการนี้ แต่เมื่อใช้ OC หากต้องการสลับไปยังพื้นที่ที่ต้องการ เพียงพูดว่า “เนมสเปซโปรเจ็กต์ oc”
จำไม่ได้ว่าชื่อเนมสเปซที่คุณต้องการเรียกว่าอะไร? ไม่มีปัญหา เพียงพิมพ์ “oc get project” เพื่อแสดงรายการทั้งหมด สงสัยว่าสิ่งนี้จะทำงานอย่างไรหากคุณมีสิทธิ์เข้าถึงเนมสเปซชุดย่อยที่จำกัดบนคลัสเตอร์เท่านั้น เนื่องจาก kubectl จะทำสิ่งนี้อย่างถูกต้องก็ต่อเมื่อ RBAC อนุญาตให้คุณเห็นช่องว่างทั้งหมดบนคลัสเตอร์ และในคลัสเตอร์ขนาดใหญ่ ไม่ใช่ทุกคนจะได้รับสิทธิ์ดังกล่าว ดังนั้นเราจึงตอบว่า สำหรับ OC นี่ไม่ใช่ปัญหาแต่อย่างใด และจะสร้างรายการทั้งหมดในสถานการณ์ดังกล่าวได้อย่างง่ายดาย สิ่งเล็กๆ น้อยๆ เหล่านี้ประกอบขึ้นเป็นการวางแนวองค์กรของ Openshift และความสามารถในการปรับขนาดที่ดีของแพลตฟอร์มนี้ในแง่ของผู้ใช้และแอปพลิเคชัน
2. ODO - kubectl เวอร์ชันปรับปรุงสำหรับนักพัฒนา
อีกตัวอย่างหนึ่งของการปรับปรุง Red Hat OpenShift เหนือ Kubernetes ก็คือยูทิลิตีบรรทัดคำสั่ง ODO ได้รับการออกแบบมาสำหรับนักพัฒนาและช่วยให้คุณสามารถปรับใช้โค้ดในเครื่องกับคลัสเตอร์ OpenShift ระยะไกลได้อย่างรวดเร็ว นอกจากนี้ยังสามารถปรับปรุงประสิทธิภาพกระบวนการภายในเพื่อซิงค์การเปลี่ยนแปลงโค้ดทั้งหมดกับคอนเทนเนอร์บนคลัสเตอร์ OpenShift ระยะไกลได้ทันทีโดยไม่ต้องสร้างใหม่ ลงทะเบียน และปรับใช้อิมเมจอีกครั้ง
มาดูกันว่า OC และ ODO ช่วยให้การทำงานกับคอนเทนเนอร์และ Kubernetes ง่ายขึ้นได้อย่างไร
เพียงเปรียบเทียบเวิร์กโฟลว์สองสามรายการเมื่อสร้างบนพื้นฐานของ kubectl และเมื่อใช้ OC หรือ ODO
• การปรับใช้โค้ดบน OpenShift สำหรับผู้ที่ไม่พูด YAML:
Kubernetes/kubectl
$>คอมไพล์โคลน
1- สร้าง Dockerfile ที่สร้างรูปภาพจากโค้ด
-----
จากโหนด
WORKDIR /usr/src/app
คัดลอกแพ็คเกจ*.json ./
คัดลอกดัชนี js ./
คัดลอก ./app ./app
รันการติดตั้ง npm
เปิดเผย 3000
CMD [ “npm”, “เริ่มต้น” ] ————–
2- เราสร้างภาพ
$>พ็อดแมนบิลด์...
3- เข้าสู่ระบบรีจิสทรี
เข้าสู่ระบบ Podman...
4- วางรูปภาพในรีจิสตรี
พ็อดแมนดัน
5- สร้างไฟล์ yaml สำหรับการปรับใช้แอปพลิเคชัน (deployment.yaml, service.yaml, ingress.yaml) - นี่คือขั้นต่ำที่แน่นอน
6- ปรับใช้ไฟล์รายการ:
Kubectl ใช้ -f
OpenShift/oc
$> oc แอปใหม่
OpenShift/odo
$>คอมไพล์โคลน
$> odo สร้างส่วนประกอบ nodejs myapp
$>โอโดะดัน
• สวิตช์บริบท: เปลี่ยนเนมสเปซงานหรือคลัสเตอร์งาน
Kubernetes/kubectl
1- สร้างบริบทใน kubeconfig สำหรับโครงการ "myproject"
2- kubectl ชุดบริบท...
OpenShift/oc
oc โครงการ “โครงการของฉัน”
การควบคุมคุณภาพ: “มีคุณลักษณะที่น่าสนใจอย่างหนึ่งปรากฏที่นี่ แต่ยังอยู่ในเวอร์ชันอัลฟ่า บางทีเราอาจจะนำมันไปผลิตได้?”
ลองจินตนาการถึงการนั่งอยู่ในรถแข่งแล้วมีคนบอกว่า “เราได้ติดตั้งเบรกรูปแบบใหม่ และพูดตามตรงว่าความน่าเชื่อถือยังไม่ดีนัก... แต่อย่ากังวล เราจะปรับปรุงเบรกอย่างแข็งขันในระหว่างการแข่งขัน ของแชมป์” คุณชอบโอกาสนี้อย่างไร? พวกเราที่ Red Hat ไม่ค่อยมีความสุขนัก 🙂
ดังนั้นเราจึงพยายามระงับเวอร์ชันอัลฟ่าจนกว่าเวอร์ชันจะสมบูรณ์เพียงพอ และเราได้ทำการทดสอบการต่อสู้อย่างละเอียดและรู้สึกว่าเวอร์ชันเหล่านั้นปลอดภัยในการใช้งาน โดยปกติแล้ว ทุกอย่างจะต้องผ่านขั้นตอน Dev Preview ก่อน จากนั้นจึงผ่านไป
ทำไมเป็นอย่างนั้น? เนื่องจากเช่นเดียวกับการพัฒนาซอฟต์แวร์อื่นๆ แนวคิดเบื้องต้นใน Kubernetes ไม่ใช่ทั้งหมดที่จะเผยแพร่ในขั้นสุดท้าย หรือเข้าถึงและยังคงฟังก์ชันการทำงานที่ตั้งใจไว้ แต่การใช้งานแตกต่างอย่างสิ้นเชิงจากเวอร์ชันอัลฟ่า ด้วยลูกค้า Red Hat หลายพันรายที่ใช้ OpenShift เพื่อรองรับปริมาณงานที่มีความสำคัญต่อภารกิจ เราจึงให้ความสำคัญเป็นพิเศษกับความเสถียรของแพลตฟอร์มและการสนับสนุนระยะยาว
Red Hat มุ่งมั่นที่จะเผยแพร่ OpenShift บ่อยๆ และอัปเดตเวอร์ชันของ Kubernetes ที่มาพร้อมกับ OpenShift ตัวอย่างเช่น GA รุ่นปัจจุบันของ OpenShift 4.3 ในขณะที่เขียนบทความนี้มี Kubernetes 1.16 ซึ่งเป็นเพียงหน่วยเดียวที่อยู่เบื้องหลัง Kubernetes เวอร์ชันอัปสตรีมที่มีหมายเลข 1.17 ดังนั้นเราจึงพยายามมอบ Kubernetes ระดับองค์กรให้กับลูกค้า และให้การควบคุมคุณภาพเพิ่มเติมในขณะที่เราเปิดตัว OpenShift เวอร์ชันใหม่
การแก้ไขซอฟต์แวร์: “มีช่องโหว่ในเวอร์ชันของ Kubernetes ที่เรามีในการผลิต และคุณสามารถปิดได้โดยการอัปเดตสามเวอร์ชันขึ้นไปเท่านั้น หรือมีตัวเลือกอะไรบ้าง?
ในโปรเจ็กต์โอเพ่นซอร์ส Kubernetes การแก้ไขซอฟต์แวร์มักจะเผยแพร่โดยเป็นส่วนหนึ่งของรุ่นถัดไป ซึ่งบางครั้งครอบคลุมการเปิดตัวหลักชัยหนึ่งหรือสองรุ่นก่อนหน้า โดยให้ความคุ้มครองย้อนหลังเพียง 6 เดือน
Red Hat ภูมิใจในการเปิดตัวการแก้ไขที่สำคัญเร็วกว่าโปรแกรมอื่นๆ และให้การสนับสนุนยาวนานกว่ามาก ยกตัวอย่างช่องโหว่การยกระดับสิทธิ์ของ Kubernetes (
ในทางกลับกัน
OpenShift และ Red Hat ขับเคลื่อน Kubernetes ไปข้างหน้าอย่างไร
Red Hat เป็นผู้มีส่วนร่วมซอฟต์แวร์รายใหญ่เป็นอันดับสองในโครงการ Kubernetes โอเพ่นซอร์ส ตามหลัง Google เพียงคนเดียว โดย 3 ใน 5 นักพัฒนาที่มีผลงานมากที่สุดมาจาก Red Hat ข้อเท็จจริงที่ไม่ค่อยมีใครรู้อีกประการหนึ่ง: ฟังก์ชั่นที่สำคัญมากมายปรากฏใน Kubernetes ตามความคิดริเริ่มของ Red Hat โดยเฉพาะเช่น:
- อาร์แบค. Kubernetes ไม่มีฟังก์ชัน RBAC (ClusterRole, ClusterRoleBinding) จนกระทั่งวิศวกร Red Hat ตัดสินใจใช้งานฟังก์ชันเหล่านี้โดยเป็นส่วนหนึ่งของแพลตฟอร์ม และไม่ใช่ฟังก์ชัน OpenShift เพิ่มเติม Red Hat กลัวที่จะปรับปรุง Kubernetes หรือไม่? ไม่แน่นอน เพราะ Red Hat ปฏิบัติตามหลักการโอเพ่นซอร์สอย่างเคร่งครัดและไม่เล่นเกม Open Core การปรับปรุงและนวัตกรรมที่ขับเคลื่อนโดยชุมชนการพัฒนา แทนที่จะเป็นกรรมสิทธิ์ นั้นมีศักยภาพมากขึ้นและนำไปใช้อย่างกว้างขวางมากขึ้น ซึ่งสอดคล้องกับเป้าหมายหลักของเราในการสร้างซอฟต์แวร์โอเพ่นซอร์สที่มีประโยชน์ต่อลูกค้าของเรามากขึ้น
- นโยบายความปลอดภัยสำหรับพ็อด (นโยบายความปลอดภัยของพ็อด) แนวคิดของการเรียกใช้แอปพลิเคชันอย่างปลอดภัยภายในพ็อดนี้เดิมนำมาใช้ใน OpenShift ภายใต้ชื่อ SCC (ข้อจำกัดบริบทด้านความปลอดภัย) เช่นเดียวกับในตัวอย่างก่อนหน้านี้ Red Hat ตัดสินใจแนะนำการพัฒนาเหล่านี้ในโปรเจ็กต์ Kubernetes แบบเปิดเพื่อให้ทุกคนสามารถใช้งานได้
ตัวอย่างชุดนี้สามารถดำเนินการต่อได้ แต่เราเพียงต้องการแสดงให้เห็นว่า Red Hat มุ่งมั่นที่จะพัฒนา Kubernetes และทำให้ดียิ่งขึ้นสำหรับทุกคน
เป็นที่ชัดเจนว่า OpenShift คือ Kubernetes อะไรคือความแตกต่าง? 🙂
เราหวังว่าการอ่านมาถึงขนาดนี้ คุณจะตระหนักว่า Kubernetes เป็นองค์ประกอบหลักของ OpenShift ตัวหลักแต่ไกลจากตัวเดียว กล่าวอีกนัยหนึ่ง การติดตั้ง Kubernetes ไม่ได้ทำให้คุณมีแพลตฟอร์มระดับองค์กร คุณจะต้องเพิ่มการตรวจสอบสิทธิ์ เครือข่าย ความปลอดภัย การตรวจสอบ การจัดการบันทึก และอื่นๆ นอกจากนี้ คุณจะต้องตัดสินใจเลือกที่ยากลำบากจากเครื่องมือที่มีอยู่มากมาย (เพื่อชื่นชมความหลากหลายของระบบนิเวศ ลองดูสิ
แต่ในกรณีของ OpenShift ทาง Red Hat จะนำความซับซ้อนทั้งหมดมาไว้บนตัวมันเอง และเพียงแต่มอบแพลตฟอร์มที่มีฟังก์ชันการทำงานที่สมบูรณ์แก่คุณ ซึ่งไม่เพียงแต่รวมถึง Kubernetes เท่านั้น แต่ยังรวมถึงชุดเครื่องมือโอเพ่นซอร์สที่จำเป็นทั้งชุดที่เปลี่ยน Kubernetes ให้เป็นระดับองค์กรที่แท้จริง โซลูชันที่คุณสามารถเปิดตัวสู่การผลิตได้อย่างใจเย็นและทันที และแน่นอนว่า หากคุณมีกลุ่มเทคโนโลยีของตัวเอง คุณก็สามารถผสานรวม OpenShift เข้ากับโซลูชันที่มีอยู่ได้
ลองดูภาพด้านบน: ทุกสิ่งที่อยู่นอกสี่เหลี่ยม Kubernetes คือจุดที่ Red Hat เพิ่มฟังก์ชันการทำงานที่ Kubernetes ไม่มีตามที่พวกเขาพูดโดยการออกแบบ และตอนนี้เราจะดูที่ส่วนหลักของพื้นที่เหล่านี้
1. OS ที่แข็งแกร่งเป็นฐาน: RHEL CoreOS หรือ RHEL
Red Hat เป็นผู้ให้บริการชั้นนำด้านการกระจาย Linux สำหรับแอปพลิเคชันที่สำคัญทางธุรกิจมานานกว่า 20 ปี ประสบการณ์ที่สะสมและปรับปรุงอย่างต่อเนื่องของเราในด้านนี้ช่วยให้เราสามารถนำเสนอพื้นฐานที่เชื่อถือได้และไว้วางใจได้อย่างแท้จริงสำหรับการดำเนินงานทางอุตสาหกรรมของคอนเทนเนอร์ RHEL CoreOS ใช้เคอร์เนลเดียวกันกับ RHEL แต่ได้รับการปรับให้เหมาะสมสำหรับงานต่างๆ เป็นหลัก เช่น การรันคอนเทนเนอร์และการรันคลัสเตอร์ Kubernetes: ขนาดที่ลดลงและความไม่เปลี่ยนรูปทำให้การตั้งค่าคลัสเตอร์ การปรับขนาดอัตโนมัติ การปรับใช้แพตช์ ฯลฯ ง่ายขึ้น คุณสมบัติทั้งหมดเหล่านี้ทำให้ รากฐานที่สมบูรณ์แบบสำหรับการมอบประสบการณ์ผู้ใช้แบบเดียวกันด้วย OpenShift ในสภาพแวดล้อมการประมวลผลที่หลากหลาย ตั้งแต่ Bare Metal ไปจนถึงคลาวด์ส่วนตัวและสาธารณะ
2. ระบบอัตโนมัติของการดำเนินงานด้านไอที
กระบวนการติดตั้งอัตโนมัติและการปฏิบัติงานวันที่ 4 (ซึ่งก็คือการปฏิบัติงานในแต่ละวัน) คือจุดแข็งของ OpenShift ทำให้ง่ายต่อการบริหารจัดการ อัปเดต และรักษาประสิทธิภาพของแพลตฟอร์มคอนเทนเนอร์ในระดับสูงสุด ซึ่งสามารถทำได้โดยการสนับสนุนตัวดำเนินการ Kubernetes ในระดับเคอร์เนล OpenShift XNUMX
OpenShift 4 ยังเป็นระบบนิเวศของโซลูชันทั้งหมดที่ใช้ตัวดำเนินการ Kubernetes ซึ่งพัฒนาโดย Red Hat เองและโดยพันธมิตรบุคคลที่สาม (ดู
แค็ตตาล็อก OpenShift 4 ที่ผสานรวมประกอบด้วยตัวดำเนินการ Kubernetes มากกว่า 180 ราย
3. เครื่องมือสำหรับนักพัฒนา
ตั้งแต่ปี 2011 เป็นต้นมา OpenShift มีให้บริการในรูปแบบแพลตฟอร์ม PaaS (Platform-as-a-Service) ที่ทำให้ชีวิตของนักพัฒนาง่ายขึ้นมาก ช่วยให้พวกเขามุ่งเน้นไปที่การเขียนโค้ด และให้การสนับสนุนดั้งเดิมสำหรับภาษาการเขียนโปรแกรม เช่น Java, Node.js , PHP, Ruby, Python, Go รวมถึงบริการบูรณาการและจัดส่ง CI/CD อย่างต่อเนื่อง ฐานข้อมูล ฯลฯ ข้อเสนอ OpenShift 4
OpenShift 4 ต่างจาก Kubernetes ตรงที่มี GUI เฉพาะ (
นอกจากนี้ OpenShift ยังมีชุดเครื่องมือพัฒนา Codeready ซึ่งรวมถึงโดยเฉพาะ
Integrated IDE เป็นบริการสำหรับการพัฒนาที่มีประสิทธิภาพบนแพลตฟอร์ม Kubernetes/OpenShift
OpenShift นำเสนอระบบ CI/CD เต็มรูปแบบตั้งแต่แกะกล่อง โดยอิงตาม Jenkins ที่ใส่คอนเทนเนอร์และปลั๊กอิน
4. เครื่องมือการใช้งาน
OpenShift ช่วยให้คุณสามารถปรับใช้ทั้งแอปพลิเคชันเก็บสถานะแบบดั้งเดิมและโซลูชันบนระบบคลาวด์ตามสถาปัตยกรรมใหม่ เช่น ไมโครเซอร์วิสหรือแบบไร้เซิร์ฟเวอร์ โซลูชัน OpenShift Service Mesh มาพร้อมเครื่องมือสำคัญสำหรับการบำรุงรักษาไมโครเซอร์วิส เช่น Istio, Kiali และ Jaeger ตั้งแต่แกะกล่อง ในทางกลับกัน โซลูชัน OpenShift Serverless ไม่เพียงแต่มี Knative เท่านั้น แต่ยังรวมถึงเครื่องมืออย่าง Keda ที่สร้างขึ้นโดยเป็นส่วนหนึ่งของความคิดริเริ่มร่วมกับ Microsoft เพื่อมอบฟังก์ชัน Azure บนแพลตฟอร์ม OpenShift
โซลูชันครบวงจร OpenShift ServiceMesh (Istio, Kiali, Jaeger) จะมีประโยชน์ในการพัฒนาไมโครเซอร์วิส
เพื่อลดช่องว่างระหว่างแอปพลิเคชันและคอนเทนเนอร์แบบเดิม ขณะนี้ OpenShift อนุญาตให้ย้ายเครื่องเสมือนไปยังแพลตฟอร์ม OpenShift โดยใช้ Container Native Virtualization (ปัจจุบันอยู่ใน TechPreview) ทำให้แอปพลิเคชันไฮบริดเป็นจริง และอำนวยความสะดวกในการโยกย้ายระหว่างคลาวด์ต่างๆ ทั้งส่วนตัวและสาธารณะ
เครื่องเสมือน Windows 2019 ที่ทำงานบน OpenShift ผ่าน Container Native Virtualization (ปัจจุบันอยู่ในเวอร์ชันตัวอย่างด้านเทคนิค)
5. เครื่องมือสำหรับคลัสเตอร์
แพลตฟอร์มระดับองค์กรใดๆ จะต้องมีการตรวจสอบและการบริการบันทึกแบบรวมศูนย์ กลไกการรักษาความปลอดภัย การรับรองความถูกต้องและการอนุญาต และเครื่องมือการจัดการเครือข่าย และ OpenShift นำเสนอทั้งหมดนี้ทันที และเป็นโอเพ่นซอร์สทั้งหมด 100% รวมถึงโซลูชันเช่น ElasticSearch, Prometheus, Grafana โซลูชันทั้งหมดนี้มาพร้อมกับแดชบอร์ด ตัวชี้วัด และการแจ้งเตือนที่สร้างและกำหนดค่าไว้แล้วโดยใช้ความเชี่ยวชาญด้านการตรวจสอบคลัสเตอร์ที่กว้างขวางของ Red Hat ช่วยให้คุณสามารถควบคุมและตรวจสอบสภาพแวดล้อมการผลิตของคุณได้อย่างมีประสิทธิภาพตั้งแต่เริ่มต้น
OpenShift ยังมาพร้อมกับสิ่งสำคัญที่เป็นมาตรฐานสำหรับลูกค้าองค์กร เช่น การตรวจสอบสิทธิ์กับผู้ให้บริการ oauth ในตัว การผสานรวมกับผู้ให้บริการข้อมูลรับรอง รวมถึง LDAP, ActiveDirectory, OpenID Connect และอื่นๆ อีกมากมาย
แดชบอร์ด Grafana ที่กำหนดค่าล่วงหน้าสำหรับการตรวจสอบคลัสเตอร์ OpenShift
ตัววัด Prometheus ที่กำหนดค่าไว้ล่วงหน้ามากกว่า 150 รายการและการแจ้งเตือนสำหรับการตรวจสอบคลัสเตอร์ OpenShift
จะยังคง
ฟังก์ชันการทำงานที่หลากหลายของโซลูชันและประสบการณ์ที่กว้างขวางของ Red Hat ในด้าน Kubernetes เป็นเหตุผลที่ OpenShift ประสบความสำเร็จในตำแหน่งที่โดดเด่นในตลาด ดังแสดงในรูปด้านล่าง (อ่านเพิ่มเติม
“ปัจจุบัน Red Hat เป็นผู้นำตลาดด้วยส่วนแบ่ง 44%
บริษัทกำลังเก็บเกี่ยวผลประโยชน์จากกลยุทธ์การขายที่เน้นลูกค้าเป็นศูนย์กลาง โดยจะให้คำปรึกษาและฝึกอบรมนักพัฒนาระดับองค์กรก่อน จากนั้นจึงเปลี่ยนไปใช้การสร้างรายได้เมื่อองค์กรเริ่มปรับใช้คอนเทนเนอร์ในการผลิต”
(ที่มา:
เราหวังว่าคุณจะสนุกกับบทความนี้ ในโพสต์ต่อๆ ไปของซีรีส์นี้ เราจะมาดูรายละเอียดเกี่ยวกับข้อดีของ OpenShift ที่เหนือกว่า Kubernetes ในแต่ละหมวดหมู่ที่กล่าวถึงที่นี่
ที่มา: will.com