เวที ช่วยให้คุณปรับปรุงการสร้างสรรค์ได้ รวมถึงในโครงสร้างพื้นฐานของผู้ให้บริการคลาวด์ บนแพลตฟอร์มเวอร์ช่วลไลเซชั่น หรือในระบบ Bare-Metal ในการสร้างแพลตฟอร์มบนคลาวด์อย่างแท้จริง เราจำเป็นต้องควบคุมองค์ประกอบทั้งหมดที่ใช้อย่างเข้มงวด ดังนั้นจึงเพิ่มความน่าเชื่อถือของกระบวนการอัตโนมัติที่ซับซ้อน
วิธีแก้ปัญหาที่ชัดเจนคือใช้ Red Hat Enterprise Linux CoreOS (เวอร์ชันหนึ่งของ Red Hat Enterprise Linux) และ CRI-O เป็นมาตรฐาน และนี่คือสาเหตุ...
เนื่องจากหัวข้อการเดินเรือเป็นหัวข้อที่ดีมากในการค้นหาการเปรียบเทียบเมื่ออธิบายการทำงานของ Kubernetes และคอนเทนเนอร์ เราจึงลองพูดถึงปัญหาทางธุรกิจที่ CoreOS และ CRI-O แก้ไขโดยใช้ตัวอย่าง . ในปี 1803 Marc Brunel ได้รับมอบหมายให้ผลิตบล็อคเสื้อผ้า 100 ชิ้นสำหรับความต้องการของกองทัพเรืออังกฤษที่กำลังเติบโต บล็อกเสื้อผ้าเป็นเสื้อผ้าประเภทหนึ่งที่ใช้ผูกเชือกกับใบเรือ จนถึงต้นศตวรรษที่ 19 บล็อกเหล่านี้ทำด้วยมือ แต่บรูเนลสามารถจัดการการผลิตแบบอัตโนมัติและเริ่มผลิตบล็อกที่ได้มาตรฐานโดยใช้เครื่องมือกล กระบวนการอัตโนมัติของกระบวนการนี้หมายความว่าบล็อกที่ได้จะเหมือนกันโดยพื้นฐานแล้ว สามารถเปลี่ยนได้ง่ายหากแตกหัก และอาจผลิตได้ในปริมาณมาก
ทีนี้ลองจินตนาการดูว่าถ้าบรูเนลต้องทำงานนี้กับเรือจำลอง 20 ลำ (เวอร์ชัน Kubernetes) และสำหรับดาวเคราะห์ XNUMX ดวงที่มีกระแสน้ำและลมทะเลต่างกันโดยสิ้นเชิง (ผู้ให้บริการคลาวด์) นอกจากนี้ จำเป็นที่เรือทุกลำ (คลัสเตอร์ OpenShift) โดยไม่คำนึงถึงดาวเคราะห์ที่ใช้นำทาง จากมุมมองของกัปตัน (ผู้ปฏิบัติงานที่จัดการการปฏิบัติงานของกลุ่ม) จะต้องประพฤติตนเหมือนกัน เพื่อดำเนินการเปรียบเทียบทางทะเลต่อไป กัปตันเรือไม่สนใจเลยว่าจะใช้บล็อกเสื้อผ้า (CRI-O) ประเภทใดบนเรือ - สิ่งสำคัญสำหรับพวกเขาคือบล็อกเหล่านี้แข็งแกร่งและเชื่อถือได้
OpenShift 4 ซึ่งเป็นแพลตฟอร์มระบบคลาวด์กำลังเผชิญกับความท้าทายทางธุรกิจที่คล้ายกันมาก ต้องสร้างโหนดใหม่ในขณะที่สร้างคลัสเตอร์ ในกรณีที่โหนดใดโหนดหนึ่งล้มเหลว หรือเมื่อปรับขนาดคลัสเตอร์ เมื่อมีการสร้างและเริ่มต้นโหนดใหม่ ส่วนประกอบโฮสต์ที่สำคัญ รวมถึง CRI-O จะต้องได้รับการกำหนดค่าตามนั้น เช่นเดียวกับการผลิตอื่นๆ จะต้องจัดหา "วัตถุดิบ" ตั้งแต่เริ่มต้น ในกรณีเรือ วัตถุดิบจะเป็นโลหะและไม้ อย่างไรก็ตาม ในกรณีของการสร้างโฮสต์สำหรับการปรับใช้คอนเทนเนอร์ในคลัสเตอร์ OpenShift 4 คุณจำเป็นต้องมีไฟล์การกำหนดค่าและเซิร์ฟเวอร์ที่ API จัดให้เป็นอินพุต จากนั้น OpenShift จะมอบระบบอัตโนมัติในระดับที่ต้องการตลอดวงจรชีวิตทั้งหมด โดยให้การสนับสนุนผลิตภัณฑ์ที่จำเป็นแก่ผู้ใช้ และช่วยชดเชยการลงทุนในแพลตฟอร์ม
OpenShift 4 ถูกสร้างขึ้นในลักษณะที่ช่วยให้สามารถอัปเดตระบบได้อย่างสะดวกตลอดวงจรชีวิตของแพลตฟอร์ม (สำหรับเวอร์ชัน 4.X) สำหรับผู้ให้บริการคลาวด์คอมพิวติ้งรายใหญ่ แพลตฟอร์มเวอร์ชวลไลเซชัน และแม้แต่ระบบ Bare Metal ในการดำเนินการนี้ จะต้องสร้างโหนดบนพื้นฐานขององค์ประกอบที่ใช้แทนกันได้ เมื่อคลัสเตอร์ต้องการ Kubernetes เวอร์ชันใหม่ คลัสเตอร์จะได้รับ CRI-O เวอร์ชันที่สอดคล้องกันบน CoreOS ด้วย เนื่องจากเวอร์ชัน CRI-O เชื่อมโยงกับ Kubernetes โดยตรง จึงช่วยลดความยุ่งยากในการเรียงสับเปลี่ยนเพื่อการทดสอบ การแก้ไขปัญหา หรือการสนับสนุนได้อย่างมาก นอกจากนี้แนวทางนี้ยังช่วยลดต้นทุนสำหรับผู้ใช้ปลายทางและ Red Hat
นี่เป็นวิธีคิดพื้นฐานใหม่เกี่ยวกับคลัสเตอร์ Kubernetes และวางรากฐานสำหรับการวางแผนฟีเจอร์ใหม่ที่มีประโยชน์และน่าสนใจ CRI-O (Container Runtime Interface - Open Container Initiative ย่อมาจาก CRI-OCI) กลายเป็นตัวเลือกที่ประสบความสำเร็จมากที่สุดสำหรับการสร้างโหนดจำนวนมากซึ่งจำเป็นสำหรับการทำงานกับ OpenShift CRI-O จะแทนที่เอ็นจิ้น Docker ที่ใช้ก่อนหน้านี้โดยเสนอผู้ใช้ OpenShift ใช่ คุณได้ยินถูกแล้ว – เครื่องยนต์คอนเทนเนอร์ที่น่าเบื่อซึ่งสร้างขึ้นเพื่อการทำงานกับ Kubernetes โดยเฉพาะ
โลกแห่งคอนเทนเนอร์แบบเปิด
โลกกำลังเคลื่อนไปสู่คอนเทนเนอร์แบบเปิดมาเป็นเวลานาน ไม่ว่าจะอยู่ใน Kubernetes หรือในระดับที่ต่ำกว่า ส่งผลให้เกิดระบบนิเวศแห่งนวัตกรรมในทุกระดับ
ทุกอย่างเริ่มต้นจากการสร้าง Open Containers Initiative . ในช่วงแรกของการทำงานนี้ มีการกำหนดข้อกำหนดเฉพาะของคอนเทนเนอร์ и . สิ่งนี้ทำให้มั่นใจได้ว่าเครื่องมือต่างๆ สามารถใช้มาตรฐานเดียวได้ และรูปแบบการทำงานที่เป็นหนึ่งเดียว ข้อมูลจำเพาะถูกเพิ่มในภายหลัง ทำให้ผู้ใช้สามารถแบ่งปันได้อย่างง่ายดาย .
จากนั้นชุมชน Kubernetes ได้พัฒนามาตรฐานเดียวสำหรับอินเทอร์เฟซแบบเสียบได้ที่เรียกว่า . ด้วยเหตุนี้ ผู้ใช้ Kubernetes จึงสามารถเชื่อมต่อเอ็นจิ้นต่างๆ เพื่อทำงานกับคอนเทนเนอร์นอกเหนือจาก Docker ได้
วิศวกรที่ Red Hat และ Google มองเห็นความต้องการของตลาดสำหรับกลไกคอนเทนเนอร์ที่สามารถรับคำขอ Kubelet ผ่านโปรโตคอล CRI และเปิดตัวคอนเทนเนอร์ที่เข้ากันได้กับข้อกำหนด OCI ที่กล่าวถึงข้างต้น ดังนั้น . แต่ขอโทษที เราไม่ได้บอกว่าเนื้อหานี้จะทุ่มเทให้กับ CRI-O ใช่ไหม จริงๆแล้วมันเป็นเพียงแค่การเปิดตัว โครงการเปลี่ยนชื่อเป็น CRI-O
มะเดื่อ 1
นวัตกรรมด้วย CRI-O และ CoreOS
ด้วยการเปิดตัวแพลตฟอร์ม OpenShift 4 ก็มีการเปลี่ยนแปลง ซึ่งใช้เป็นค่าเริ่มต้นในแพลตฟอร์ม และ Docker ถูกแทนที่ด้วย CRI-O ซึ่งนำเสนอสภาพแวดล้อมที่คุ้มค่า เสถียร เรียบง่าย และน่าเบื่อสำหรับการเรียกใช้คอนเทนเนอร์ที่พัฒนาควบคู่ไปกับ Kubernetes สิ่งนี้ทำให้การสนับสนุนและการกำหนดค่าคลัสเตอร์ง่ายขึ้นอย่างมาก การกำหนดค่าคอนเทนเนอร์เอ็นจิ้นและโฮสต์ ตลอดจนการจัดการ จะกลายเป็นอัตโนมัติภายใน OpenShift 4
เดี๋ยวก่อน เป็นยังไงบ้าง?
ถูกต้อง ด้วยการถือกำเนิดของ OpenShift 4 ไม่จำเป็นต้องเชื่อมต่อกับแต่ละโฮสต์และติดตั้งคอนเทนเนอร์เอ็นจิ้น กำหนดค่าพื้นที่เก็บข้อมูล กำหนดค่าเซิร์ฟเวอร์การค้นหา หรือกำหนดค่าเครือข่ายอีกต่อไป แพลตฟอร์ม OpenShift 4 ได้รับการออกแบบใหม่ทั้งหมดเพื่อใช้ ไม่เพียงแต่ในแง่ของแอปพลิเคชันสำหรับผู้ใช้ปลายทางเท่านั้น แต่ยังรวมถึงการดำเนินงานระดับแพลตฟอร์มพื้นฐานด้วย เช่น การปรับใช้อิมเมจ การกำหนดค่าระบบ หรือการติดตั้งการอัปเดต
Kubernetes อนุญาตให้ผู้ใช้จัดการแอปพลิเคชันโดยการกำหนดสถานะและการใช้งานที่ต้องการ เพื่อให้แน่ใจว่าสถานะจริงตรงกับสถานะเป้าหมายให้ใกล้เคียงที่สุด นี้ เปิดโอกาสอันดีจากทั้งมุมมองของการพัฒนาและการปฏิบัติการ นักพัฒนาสามารถกำหนดสถานะที่ต้องการได้โดย ไปยังตัวดำเนินการในรูปแบบของไฟล์ YAML หรือ JSON จากนั้นตัวดำเนินการสามารถสร้างอินสแตนซ์แอปพลิเคชันที่จำเป็นในสภาพแวดล้อมการใช้งานจริง และสถานะการทำงานของอินสแตนซ์นี้จะสอดคล้องกับสถานะที่ระบุโดยสมบูรณ์
ด้วยการใช้ตัวดำเนินการในแพลตฟอร์ม OpenShift 4 จะนำกระบวนทัศน์ใหม่นี้ (โดยใช้แนวคิดเรื่องการตั้งค่าและสถานะจริง) มาสู่การจัดการ RHEL CoreOS และ CRI-O งานในการกำหนดค่าและจัดการเวอร์ชันของระบบปฏิบัติการและเอ็นจิ้นคอนเทนเนอร์นั้นเป็นแบบอัตโนมัติโดยใช้สิ่งที่เรียกว่า . MCO ช่วยให้การทำงานของผู้ดูแลระบบคลัสเตอร์ง่ายขึ้นอย่างมาก โดยทำให้ขั้นตอนสุดท้ายของการติดตั้งเป็นแบบอัตโนมัติ รวมถึงการดำเนินการหลังการติดตั้งในภายหลัง (การดำเนินการวันที่สอง) ทั้งหมดนี้ทำให้ OpenShift 4 เป็นแพลตฟอร์มคลาวด์ที่แท้จริง เราจะพูดถึงเรื่องนี้อีกสักหน่อย
วิ่งคอนเทนเนอร์
ผู้ใช้มีโอกาสใช้กลไก CRI-O ในแพลตฟอร์ม OpenShift ตั้งแต่เวอร์ชัน 3.7 ในสถานะ Tech Preview และจากเวอร์ชัน 3.9 ในสถานะ Generally Available (รองรับในปัจจุบัน) นอกจากนี้ Red Hat ยังใช้งานอย่างหนาแน่น ใน OpenShift Online ตั้งแต่เวอร์ชัน 3.10 ทั้งหมดนี้ทำให้ทีมงานที่ทำงานเกี่ยวกับ CRI-O ได้รับประสบการณ์อย่างกว้างขวางในการเปิดตัวคอนเทนเนอร์จำนวนมากบนคลัสเตอร์ Kubernetes ขนาดใหญ่ เพื่อให้เข้าใจพื้นฐานว่า Kubernetes ใช้ CRI-O อย่างไร เรามาดูภาพประกอบต่อไปนี้ซึ่งจะแสดงวิธีการทำงานของสถาปัตยกรรม
ข้าว. 2. วิธีการทำงานของคอนเทนเนอร์ในคลัสเตอร์ Kubernetes
CRI-O ช่วยให้การสร้างโฮสต์คอนเทนเนอร์ใหม่ง่ายขึ้นโดยการซิงโครไนซ์ระดับบนสุดทั้งหมดเมื่อเริ่มต้นโหนดใหม่ และเมื่อเปิดตัวแพลตฟอร์ม OpenShift เวอร์ชันใหม่ การแก้ไขแพลตฟอร์มทั้งหมดช่วยให้สามารถอัปเดต/ย้อนกลับธุรกรรมได้ และยังป้องกันการหยุดชะงักในการพึ่งพาระหว่างแกนหางของคอนเทนเนอร์ โปรแกรมคอนเทนเนอร์ โหนด (Kubelets) และโหนด Kubernetes Master ด้วยการจัดการส่วนประกอบแพลตฟอร์มทั้งหมดจากส่วนกลาง ด้วยการควบคุมและการกำหนดเวอร์ชัน จะมีเส้นทางที่ชัดเจนจากสถานะ A ไปยังสถานะ B เสมอ ซึ่งช่วยลดความซับซ้อนของกระบวนการอัปเดต ปรับปรุงความปลอดภัย ปรับปรุงการรายงานประสิทธิภาพ และช่วยลดค่าใช้จ่ายในการอัปเดตและการติดตั้งเวอร์ชันใหม่ .
แสดงให้เห็นถึงพลังขององค์ประกอบทดแทน
ดังที่กล่าวไว้ข้างต้น การใช้ Machine Config Operator ในการจัดการคอนเทนเนอร์โฮสต์และคอนเทนเนอร์เอ็นจิ้นใน OpenShift 4 มอบระบบอัตโนมัติระดับใหม่ที่ไม่เคยทำได้บนแพลตฟอร์ม Kubernetes มาก่อน เพื่อสาธิตคุณสมบัติใหม่ เราจะแสดงให้คุณเห็นว่าคุณสามารถเปลี่ยนแปลงไฟล์ crio.conf ได้อย่างไร เพื่อหลีกเลี่ยงไม่ให้คำศัพท์สับสน พยายามเน้นที่ผลลัพธ์
ขั้นแรก เรามาสร้างสิ่งที่เรียกว่าการกำหนดค่ารันไทม์ของคอนเทนเนอร์ - การกำหนดค่ารันไทม์ของคอนเทนเนอร์ คิดว่าเป็นทรัพยากร Kubernetes ที่แสดงถึงการกำหนดค่าสำหรับ CRI-O ในความเป็นจริง มันเป็นเวอร์ชันพิเศษของสิ่งที่เรียกว่า MachineConfig ซึ่งเป็นการกำหนดค่าใดๆ ที่ใช้งานกับเครื่อง RHEL CoreOS โดยเป็นส่วนหนึ่งของคลัสเตอร์ OpenShift
ทรัพยากรที่กำหนดเองนี้เรียกว่า ContainerRuntimeConfig สร้างขึ้นเพื่อให้ผู้ดูแลระบบคลัสเตอร์กำหนดค่า CRI-O ได้ง่ายขึ้น เครื่องมือนี้มีประสิทธิภาพเพียงพอที่จะใช้ได้กับบางโหนดเท่านั้น ทั้งนี้ขึ้นอยู่กับการตั้งค่า MachineConfigPool ให้มองว่าเป็นกลุ่มเครื่องจักรที่มีจุดประสงค์เดียวกัน
สังเกตสองบรรทัดสุดท้ายที่เรากำลังจะเปลี่ยนแปลงในไฟล์ /etc/crio/crio.conf สองบรรทัดนี้คล้ายกับบรรทัดในไฟล์ crio.conf มาก นั่นคือ:
vi ContainerRuntimeConfig.yaml
สรุป:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
ตอนนี้เรามาส่งไฟล์นี้ไปยังคลัสเตอร์ Kubernetes และตรวจสอบว่าไฟล์นั้นถูกสร้างขึ้นจริงหรือไม่ โปรดทราบว่าการดำเนินการจะเหมือนกับทรัพยากร Kubernetes อื่นๆ ทุกประการ:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
สรุป:
NAME AGE
set-log-and-pid 22h
เมื่อเราสร้าง ContainerRuntimeConfig แล้ว เราจำเป็นต้องแก้ไข MachineConfigPools ตัวใดตัวหนึ่งเพื่อส่งสัญญาณไปยัง Kubernetes ว่าเราต้องการใช้การกำหนดค่านี้กับกลุ่มเครื่องเฉพาะในคลัสเตอร์ ในกรณีนี้ เราจะเปลี่ยน MachineConfigPool สำหรับโหนดหลัก:
oc edit MachineConfigPool/master
บทสรุป (เพื่อความชัดเจนเหลือสาระสำคัญหลัก):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
ณ จุดนี้ MCO เริ่มสร้างไฟล์ crio.conf ใหม่สำหรับคลัสเตอร์ ในกรณีนี้ คุณจะดูไฟล์การกำหนดค่าที่เสร็จสมบูรณ์ได้โดยใช้ Kubernetes API โปรดจำไว้ว่า ContainerRuntimeConfig เป็นเพียงเวอร์ชันพิเศษของ MachineConfig ดังนั้นเราจึงสามารถดูผลลัพธ์ได้โดยดูที่บรรทัดที่เกี่ยวข้องใน MachineConfigs:
oc get MachineConfigs | grep rendered
สรุป:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
โปรดทราบว่าไฟล์การกำหนดค่าผลลัพธ์สำหรับโหนดหลักเป็นเวอร์ชันที่ใหม่กว่าการกำหนดค่าดั้งเดิม หากต้องการดูให้รันคำสั่งต่อไปนี้ เมื่อผ่านไป เราสังเกตว่านี่อาจเป็นหนึ่งในสายการบินที่ดีที่สุดในประวัติศาสตร์ของ Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
สรุป:
pids_limit = 2048
ตอนนี้มาตรวจสอบให้แน่ใจว่ามีการใช้การกำหนดค่ากับโหนดหลักทั้งหมดแล้ว ก่อนอื่นเราได้รับรายการโหนดในคลัสเตอร์:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ทีนี้มาดูไฟล์ที่ติดตั้งกัน คุณจะเห็นว่าไฟล์ได้รับการอัปเดตด้วยค่าใหม่สำหรับคำสั่ง pid และ debug ที่เราระบุไว้ในทรัพยากร ContainerRuntimeConfig ความสง่างามนั้นเอง:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
สรุป:
...
pids_limit = 2048
...
log_level = "debug"
...
การเปลี่ยนแปลงคลัสเตอร์ทั้งหมดนี้เกิดขึ้นโดยไม่ต้องรัน SSH ด้วยซ้ำ งานทั้งหมดเสร็จสิ้นโดยการเข้าถึงโหนดหลักของ Kuberentes นั่นคือพารามิเตอร์ใหม่เหล่านี้ได้รับการกำหนดค่าบนโหนดหลักเท่านั้น โหนดของผู้ปฏิบัติงานไม่มีการเปลี่ยนแปลง ซึ่งแสดงให้เห็นถึงประโยชน์ของวิธีการของ Kubernetes ในการใช้สถานะที่ระบุและสถานะตามจริงที่เกี่ยวข้องกับโฮสต์คอนเทนเนอร์และกลไกของคอนเทนเนอร์ที่มีองค์ประกอบที่ใช้แทนกันได้
ตัวอย่างด้านบนแสดงความสามารถในการเปลี่ยนแปลงคลัสเตอร์ OpenShift Container Platform 4 ขนาดเล็กที่มีโหนดที่ใช้งานจริง 3000 โหนด หรือคลัสเตอร์ที่ใช้งานจริงขนาดใหญ่ที่มี 4 โหนด ไม่ว่าในกรณีใด ปริมาณงานจะเท่าเดิมและน้อยมาก เพียงกำหนดค่าไฟล์ ContainerRuntimeConfig และเปลี่ยนป้ายกำกับหนึ่งรายการใน MachineConfigPool และคุณสามารถทำได้ด้วย OpenShift Container Platform XNUMX.X เวอร์ชันใดก็ได้ที่ใช้งาน Kubernetes ตลอดวงจรการใช้งาน
บ่อยครั้งที่บริษัทเทคโนโลยีพัฒนาอย่างรวดเร็วจนเราไม่สามารถอธิบายได้ว่าทำไมเราจึงเลือกเทคโนโลยีบางอย่างสำหรับส่วนประกอบพื้นฐาน ในอดีตกลไกคอนเทนเนอร์เป็นองค์ประกอบที่ผู้ใช้โต้ตอบโดยตรง เนื่องจากความนิยมของคอนเทนเนอร์เริ่มต้นจากการถือกำเนิดของเอ็นจิ้นคอนเทนเนอร์ ผู้ใช้จึงมักแสดงความสนใจในตัวมัน นี่เป็นอีกเหตุผลที่ Red Hat เลือก CRI-O คอนเทนเนอร์กำลังพัฒนาโดยมุ่งเน้นไปที่การประสานกันในขณะนี้ และเราพบว่า CRI-O มอบประสบการณ์ที่ดีที่สุดเมื่อทำงานกับ OpenShift 4
ที่มา: will.com