OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1

“Kubernetes และ OpenShift แตกต่างกันอย่างไร” – คำถามนี้เกิดขึ้นด้วยความสม่ำเสมอที่น่าอิจฉา แม้ว่าในความเป็นจริงแล้วสิ่งนี้จะเหมือนกับการถามว่ารถยนต์แตกต่างจากเครื่องยนต์อย่างไร หากเรายังคงเปรียบเทียบต่อไป รถยนต์ก็เป็นผลิตภัณฑ์สำเร็จรูป คุณสามารถใช้มันได้ทันที: เข้าและออก ในทางกลับกัน เพื่อให้เครื่องยนต์พาคุณไปที่ไหนสักแห่งได้ จะต้องเสริมด้วยสิ่งอื่นๆ มากมายก่อนจึงจะได้รถคันเดียวกันในที่สุด

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1

ดังนั้น 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 ขึ้นอยู่กับ ได้รับการรับรอง Kubernetes. ดังนั้นหลังจากการฝึกอบรมที่เหมาะสม ผู้ใช้จึงรู้สึกประหลาดใจกับพลังของ kubectl และผู้ที่เปลี่ยนมาใช้ OpenShift จาก Kubernetes Cluster มักจะบอกว่าพวกเขาชอบสิ่งนั้นมากเพียงใดหลังจากเปลี่ยนเส้นทาง kubeconfig ไปยังคลัสเตอร์ 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 – ส่งคืนพ็อดตามที่คาดไว้

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1

• kubectl รับเนมสเปซ – ส่งคืนเนมสเปซตามที่คาดไว้

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
คำสั่ง kubectl create -f mydeployment.yaml จะสร้างทรัพยากร kubernetes เช่นเดียวกับบนแพลตฟอร์ม Kubernetes อื่นๆ ดังที่แสดงในวิดีโอด้านล่าง:


กล่าวอีกนัยหนึ่ง Kubernetes API ทั้งหมดพร้อมใช้งานอย่างเต็มรูปแบบใน OpenShift ในขณะที่ยังคงความเข้ากันได้ 100% นั่นคือเหตุผล OpenShift ได้รับการยอมรับว่าเป็นแพลตฟอร์ม Kubernetes ที่ได้รับการรับรองโดย Cloud Native Computing Foundation (CNCF). 

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
$>คอมไพล์โคลน github.com/sclorg/nodejs-ex.git
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 แอปใหม่ github.com/sclorg/nodejs-ex.git – our_application_name

OpenShift/odo
$>คอมไพล์โคลน github.com/sclorg/nodejs-ex.git
$> odo สร้างส่วนประกอบ nodejs myapp
$>โอโดะดัน

• สวิตช์บริบท: เปลี่ยนเนมสเปซงานหรือคลัสเตอร์งาน

Kubernetes/kubectl
1- สร้างบริบทใน kubeconfig สำหรับโครงการ "myproject"
2- kubectl ชุดบริบท...

OpenShift/oc
oc โครงการ “โครงการของฉัน”

การควบคุมคุณภาพ: “มีคุณลักษณะที่น่าสนใจอย่างหนึ่งปรากฏที่นี่ แต่ยังอยู่ในเวอร์ชันอัลฟ่า บางทีเราอาจจะนำมันไปผลิตได้?”

ลองจินตนาการถึงการนั่งอยู่ในรถแข่งแล้วมีคนบอกว่า “เราได้ติดตั้งเบรกรูปแบบใหม่ และพูดตามตรงว่าความน่าเชื่อถือยังไม่ดีนัก... แต่อย่ากังวล เราจะปรับปรุงเบรกอย่างแข็งขันในระหว่างการแข่งขัน ของแชมป์” คุณชอบโอกาสนี้อย่างไร? พวกเราที่ Red Hat ไม่ค่อยมีความสุขนัก 🙂

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

ทำไมเป็นอย่างนั้น? เนื่องจากเช่นเดียวกับการพัฒนาซอฟต์แวร์อื่นๆ แนวคิดเบื้องต้นใน 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 (CVE-2018-1002105): ถูกค้นพบใน Kubernetes 1.11 และการแก้ไขสำหรับรุ่นก่อนหน้านี้ได้รับการเผยแพร่จนถึงเวอร์ชัน 1.10.11 เท่านั้น โดยปล่อยให้เวอร์ชันนี้อยู่ในช่องโหว่ใน Kubernetes รุ่นก่อนหน้าทั้งหมด จาก 1.x เป็น 1.9

ในทางกลับกัน Red Hat ได้แพตช์ OpenShift กลับไปเป็นเวอร์ชัน 3.2 (Kubernetes 1.2 มาแล้ว) บันทึก OpenShift เก้ารุ่นและแสดงให้เห็นถึงความเอาใจใส่ลูกค้าอย่างชัดเจน (รายละเอียดเพิ่มเติม ที่นี่).

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 ไม่ได้ทำให้คุณมีแพลตฟอร์มระดับองค์กร คุณจะต้องเพิ่มการตรวจสอบสิทธิ์ เครือข่าย ความปลอดภัย การตรวจสอบ การจัดการบันทึก และอื่นๆ นอกจากนี้ คุณจะต้องตัดสินใจเลือกที่ยากลำบากจากเครื่องมือที่มีอยู่มากมาย (เพื่อชื่นชมความหลากหลายของระบบนิเวศ ลองดูสิ กราฟ CNCF) และรับประกันความสอดคล้องและการเชื่อมโยงกันเพื่อให้ทำงานเป็นหนึ่งเดียว นอกจากนี้ คุณจะต้องดำเนินการอัปเดตและการทดสอบการถดถอยเป็นประจำทุกครั้งที่มีการเผยแพร่เวอร์ชันใหม่ของส่วนประกอบใดๆ ที่คุณใช้ นั่นคือนอกเหนือจากการสร้างและบำรุงรักษาแพลตฟอร์มแล้ว คุณจะต้องจัดการกับซอฟต์แวร์ทั้งหมดนี้ด้วย ไม่น่าจะมีเวลาเหลืออีกมากในการแก้ปัญหาทางธุรกิจและบรรลุความได้เปรียบทางการแข่งขัน

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

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
OpenShift เป็นแพลตฟอร์ม Kubernetes อันชาญฉลาด

ลองดูภาพด้านบน: ทุกสิ่งที่อยู่นอกสี่เหลี่ยม 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 เองและโดยพันธมิตรบุคคลที่สาม (ดู ไดเร็กทอรีตัวดำเนินการ Red Hat หรือร้านค้าผู้ประกอบการ โอเปอเรเตอร์ฮับ.ioสร้างโดย Red Hat สำหรับนักพัฒนาบุคคลที่สาม)

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
แค็ตตาล็อก OpenShift 4 ที่ผสานรวมประกอบด้วยตัวดำเนินการ Kubernetes มากกว่า 180 ราย

3. เครื่องมือสำหรับนักพัฒนา

ตั้งแต่ปี 2011 เป็นต้นมา OpenShift มีให้บริการในรูปแบบแพลตฟอร์ม PaaS (Platform-as-a-Service) ที่ทำให้ชีวิตของนักพัฒนาง่ายขึ้นมาก ช่วยให้พวกเขามุ่งเน้นไปที่การเขียนโค้ด และให้การสนับสนุนดั้งเดิมสำหรับภาษาการเขียนโปรแกรม เช่น Java, Node.js , PHP, Ruby, Python, Go รวมถึงบริการบูรณาการและจัดส่ง CI/CD อย่างต่อเนื่อง ฐานข้อมูล ฯลฯ ข้อเสนอ OpenShift 4 แคตตาล็อกที่กว้างขวางซึ่งรวมบริการมากกว่า 100 รายการจากผู้ให้บริการ Kubernetes ที่พัฒนาโดย Red Hat และพันธมิตรของเรา

OpenShift 4 ต่างจาก Kubernetes ตรงที่มี GUI เฉพาะ (คอนโซลนักพัฒนาซอฟต์แวร์) ซึ่งช่วยให้นักพัฒนาปรับใช้แอปพลิเคชันจากแหล่งต่างๆ ได้อย่างง่ายดาย (git, รีจิสทรีภายนอก, Dockerfile ฯลฯ) ลงในเนมสเปซและแสดงภาพความสัมพันธ์ระหว่างส่วนประกอบของแอปพลิเคชันได้อย่างชัดเจน

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
Developer Console ให้มุมมองที่ชัดเจนเกี่ยวกับส่วนประกอบของแอปพลิเคชัน และทำให้การทำงานกับ Kubernetes เป็นเรื่องง่าย

นอกจากนี้ OpenShift ยังมีชุดเครื่องมือพัฒนา Codeready ซึ่งรวมถึงโดยเฉพาะ พื้นที่ทำงานที่มีโค้ดพร้อมซึ่งเป็น IDE แบบคอนเทนเนอร์เต็มรูปแบบพร้อมเว็บอินเทอร์เฟซที่ทำงานบน OpenShift โดยตรง และนำแนวทาง IDE-as-a-service ไปใช้ ในทางกลับกัน สำหรับผู้ที่ต้องการทำงานในโหมดโลคัลอย่างเคร่งครัด ก็ยังมี Codeready Containers ซึ่งเป็นเวอร์ชันเต็มของ OpenShift 4 ที่สามารถติดตั้งบนแล็ปท็อปได้

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
Integrated IDE เป็นบริการสำหรับการพัฒนาที่มีประสิทธิภาพบนแพลตฟอร์ม Kubernetes/OpenShift

OpenShift นำเสนอระบบ CI/CD เต็มรูปแบบตั้งแต่แกะกล่อง โดยอิงตาม Jenkins ที่ใส่คอนเทนเนอร์และปลั๊กอิน DSL สำหรับการทำงานกับไปป์ไลน์หรือระบบ CI/CD ที่เน้น Kubernetes Tekton (ขณะนี้อยู่ในเวอร์ชันตัวอย่างเทคโนโลยี) โซลูชันทั้งสองนี้ผสานรวมกับคอนโซล OpenShift อย่างสมบูรณ์ ช่วยให้คุณสามารถเรียกใช้ทริกเกอร์ไปป์ไลน์ ดูการปรับใช้ บันทึก และอื่นๆ

4. เครื่องมือการใช้งาน

OpenShift ช่วยให้คุณสามารถปรับใช้ทั้งแอปพลิเคชันเก็บสถานะแบบดั้งเดิมและโซลูชันบนระบบคลาวด์ตามสถาปัตยกรรมใหม่ เช่น ไมโครเซอร์วิสหรือแบบไร้เซิร์ฟเวอร์ โซลูชัน OpenShift Service Mesh มาพร้อมเครื่องมือสำคัญสำหรับการบำรุงรักษาไมโครเซอร์วิส เช่น Istio, Kiali และ Jaeger ตั้งแต่แกะกล่อง ในทางกลับกัน โซลูชัน OpenShift Serverless ไม่เพียงแต่มี Knative เท่านั้น แต่ยังรวมถึงเครื่องมืออย่าง Keda ที่สร้างขึ้นโดยเป็นส่วนหนึ่งของความคิดริเริ่มร่วมกับ Microsoft เพื่อมอบฟังก์ชัน Azure บนแพลตฟอร์ม OpenShift

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
โซลูชันครบวงจร OpenShift ServiceMesh (Istio, Kiali, Jaeger) จะมีประโยชน์ในการพัฒนาไมโครเซอร์วิส

เพื่อลดช่องว่างระหว่างแอปพลิเคชันและคอนเทนเนอร์แบบเดิม ขณะนี้ OpenShift อนุญาตให้ย้ายเครื่องเสมือนไปยังแพลตฟอร์ม OpenShift โดยใช้ Container Native Virtualization (ปัจจุบันอยู่ใน TechPreview) ทำให้แอปพลิเคชันไฮบริดเป็นจริง และอำนวยความสะดวกในการโยกย้ายระหว่างคลาวด์ต่างๆ ทั้งส่วนตัวและสาธารณะ

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
เครื่องเสมือน Windows 2019 ที่ทำงานบน OpenShift ผ่าน Container Native Virtualization (ปัจจุบันอยู่ในเวอร์ชันตัวอย่างด้านเทคนิค)

5. เครื่องมือสำหรับคลัสเตอร์

แพลตฟอร์มระดับองค์กรใดๆ จะต้องมีการตรวจสอบและการบริการบันทึกแบบรวมศูนย์ กลไกการรักษาความปลอดภัย การรับรองความถูกต้องและการอนุญาต และเครื่องมือการจัดการเครือข่าย และ OpenShift นำเสนอทั้งหมดนี้ทันที และเป็นโอเพ่นซอร์สทั้งหมด 100% รวมถึงโซลูชันเช่น ElasticSearch, Prometheus, Grafana โซลูชันทั้งหมดนี้มาพร้อมกับแดชบอร์ด ตัวชี้วัด และการแจ้งเตือนที่สร้างและกำหนดค่าไว้แล้วโดยใช้ความเชี่ยวชาญด้านการตรวจสอบคลัสเตอร์ที่กว้างขวางของ Red Hat ช่วยให้คุณสามารถควบคุมและตรวจสอบสภาพแวดล้อมการผลิตของคุณได้อย่างมีประสิทธิภาพตั้งแต่เริ่มต้น

OpenShift ยังมาพร้อมกับสิ่งสำคัญที่เป็นมาตรฐานสำหรับลูกค้าองค์กร เช่น การตรวจสอบสิทธิ์กับผู้ให้บริการ oauth ในตัว การผสานรวมกับผู้ให้บริการข้อมูลรับรอง รวมถึง LDAP, ActiveDirectory, OpenID Connect และอื่นๆ อีกมากมาย

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
แดชบอร์ด Grafana ที่กำหนดค่าล่วงหน้าสำหรับการตรวจสอบคลัสเตอร์ OpenShift

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
ตัววัด Prometheus ที่กำหนดค่าไว้ล่วงหน้ามากกว่า 150 รายการและการแจ้งเตือนสำหรับการตรวจสอบคลัสเตอร์ OpenShift

จะยังคง

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

OpenShift เป็น Kubernetes เวอร์ชันองค์กร ส่วนที่ 1
“ปัจจุบัน Red Hat เป็นผู้นำตลาดด้วยส่วนแบ่ง 44%
บริษัทกำลังเก็บเกี่ยวผลประโยชน์จากกลยุทธ์การขายที่เน้นลูกค้าเป็นศูนย์กลาง โดยจะให้คำปรึกษาและฝึกอบรมนักพัฒนาระดับองค์กรก่อน จากนั้นจึงเปลี่ยนไปใช้การสร้างรายได้เมื่อองค์กรเริ่มปรับใช้คอนเทนเนอร์ในการผลิต”

(ที่มา: www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863)

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

ที่มา: will.com

เพิ่มความคิดเห็น