‫หวังว่าเนื้อหา YAML นี้จะเริ่มสมเหตุสมผล
‫และนี่คือที่ที่เราเรียนรู้วิธีสร้าง YAML นี้โดยพื้นฐานตั้งแต่เริ่มต้น
‫เมื่อฉันเริ่มเรียนรู้รูปแบบ Kubernetes
‫YAML อันดับแรก ฉันเริ่มจากการใช้ตัวอย่างเอกสารใช่ไหม
‫จากเอกสารของพวกเขาใน kubernetes
‫เว็บไซต์ io หรืออาจมาจากที่อื่น
‫สิ่งที่เกี่ยวกับสถานที่อื่นๆ ก็เหมือนกับ Docker คือบล็อกเหล่านั้นและสิ่งอื่น
‫ๆ ทั้งหมดนั้นล้าสมัย
‫สิ่งที่เกี่ยวกับ Kubernetes คือสิ่งที่เปลี่ยนแปลงไปตามกาลเวลา
‫โดยเฉพาะอย่างยิ่งเมื่อพูดถึงเรื่องต่างๆ เช่น
‫การปรับใช้ พ็อด และเนื้อหาหลักอื่นๆ
‫พวกเขาได้ปรับแต่งรูปแบบของพวกเขา
‫เวอร์ชันใน API มีการเปลี่ยนแปลง
‫เราต้องการอยู่กับปัจจุบัน
‫ซึ่งหมายความว่าคุณจำเป็นต้องรู้วิธีเริ่มต้นจากศูนย์
‫คุณจะรู้ได้อย่างไรว่าไฟล์ของคุณต้องเปลี่ยนเมื่อใด
‫แทนที่จะไปอ่านเอกสารแบบสุ่มเพื่อดูว่ามีอะไรเปลี่ยนแปลงหรือไม่
‫ฉันคิดว่าส่วนนี้เป็นทักษะที่ฉันต้องใช้เวลาสักพักกว่าจะเข้าใจสิ่งนี้
‫และวิธีสร้างไฟล์โดยไม่ต้องใช้เทมเพลตที่มีอยู่แล้ว
‫เราได้พูดถึงสี่ประเภทในการบรรยายครั้งที่แล้ว
‫และรูทคีย์ของชนิดนั้น ซึ่งเป็นประเภททรัพยากร คือสิ่งที่ฉันต้องการเน้นก่อน
‫เพราะคุณสามารถรับรายการเหล่านั้นในคลัสเตอร์ได้
‫ในกลุ่มทดสอบการตั้งค่าของเรา สิ่งเหล่านี้ส่วนใหญ่จะเหมือนกันระหว่างพวกเราทุกคน
‫เมื่อคุณเริ่มใช้งานจริงและคุณเริ่มเพิ่มเนื้อหาของบุคคลที่สามลงในคลัสเตอร์ของคุณ
‫รายการนี้จะยาวขึ้นขึ้นอยู่กับสิ่งที่คุณใช้ เนื่องจากเครื่องมือของบุคคลที่สามสามารถเพิ่มออบเจ็กต์ทรัพยากรใหม่ให้กับ API ได้
‫มาทำ kubectl api-resources กัน
‫คุณจะได้รับวัตถุต่าง ๆ อย่างน้อยหลายสิบชิ้นที่เราสามารถเลื่อนดูและพูดคุยกันเป็นเวลาหลายชั่วโมง
‫เราจะไม่ทำอย่างนั้น
‫เราได้พูดถึงบางส่วนแล้ว เช่น Deployments
‫และ Pods และ ReplicaSets and Services
‫สิ่งเหล่านี้คือของนอกกรอบมาตรฐาน
‫ส่วนที่เหลืออีกมากที่คุณไม่เคยสัมผัสได้
‫นั่นคือสิ่งที่ Kubernetes มีอยู่มากมายที่คุณอาจไม่ต้องการพลังทั้งหมดจากมันจริงๆ
‫ไม่สำคัญว่าคุณจะต้องอ่านและจดจำสิ่งเหล่านี้ทั้งหมด
‫คุณจะสังเกตเห็นคอลัมน์ประเภทนี้ทางด้านขวา
‫นั่นคือสิ่งที่เกิดขึ้นในไฟล์ YAML ของเรา
‫หากเราต้องการสร้างพ็อด คุณจะเห็นว่ามีพ็อดใจดีอยู่ที่นี่
‫หากเราต้องการสร้างการปรับใช้
‫มีชนิดที่เรียกว่าการปรับใช้
‫คุณจะเห็นกลุ่ม API ด้วย
‫กลุ่ม API นั้นเกี่ยวข้องกับเวอร์ชัน
‫API คุณจะเห็นว่าในวินาที
‫สิ่งนี้ไม่ได้ทำให้เราต้องมีคู่มือที่จำเป็นอย่างแน่นอน
‫แต่ถ้าฉันนั่งอยู่ที่นี่และพูดว่า
‫ฉันต้องสร้างพ็อด ฉันจะดูรายการนี้เพื่อหาพ็อดในประเภทของทรัพยากร
‫ก็จะได้เห็นแบบที่ว่า
‫นั่นคือสิ่งที่ฉันรู้ว่าฉันต้องใส่ใน YAML ของฉัน
‫ฉันจะดูว่ามีกลุ่ม API หรือไม่ เพราะนั่นจะบอกฉันว่าจะหาเวอร์ชันที่ฉันสามารถใช้ได้ได้ที่ไหน
‫เพราะคุณอาจเห็นเอกสารประกอบต่าง
‫ๆ สำหรับสมมติว่ามีการปรับใช้
‫เนื่องจากการปรับใช้มีหลายเวอร์ชันเมื่อเวลาผ่านไป
‫มี v1beta1, v1beta2
‫จริง ๆ แล้วมันถูกย้ายไปมาใน API เพราะมีของเก่าและของใหม่
‫ดังนั้นจึงอาจสร้างความสับสนเล็กน้อย
‫หากคุณดูรายการนี้ คุณจะพบว่ามีการปรับใช้บนนี้
‫และมีการปรับใช้ที่นี่
‫ความแตกต่างเพียงอย่างเดียวระหว่างทั้งสองคือแถวกลางนี้
‫กลุ่ม API
‫กลุ่ม API นั้นอยู่ใน API ของทรัพยากรประเภทนี้ที่สามารถเข้าถึง
‫สร้าง ลบ ฯลฯ
‫นี่เป็นเรื่องเล็กน้อยในวัชพืช แต่เมื่อคุณเริ่มทำงานกับสิ่งนี้
‫คุณจะต้องใช้เวลาเล็กน้อยเมื่อคุณเห็นกรณีต่างๆ
‫เช่น การเห็นการใช้งานสองประเภทที่นี่
‫อันไหนที่ฉันใช้?
‫คุณเริ่มทำวิจัยและคุณจะพบในเอกสารประกอบหรือในคู่มือ
‫API ซึ่งเราจะพิจารณาในอีกเล็กน้อย
‫คุณจะเห็นสิ่งที่จะบอกคุณว่ามีคนเลิกใช้แล้ว
‫และอีกคนหนึ่งกำลังย้ายไปที่อื่น และในกรณีนี้กับการปรับใช้
‫เวอร์ชันใหม่ของเวอร์ชันนั้น ในเวอร์ชันล่าสุดคือ
‫API ของแอป
‫คำสั่งถัดไปที่เข้ากันได้ เพื่อช่วยให้เราได้ภาพที่ดีขึ้น
‫บวกกับเวอร์ชัน API คือคำสั่งเวอร์ชัน kubectl API
‫นั่นทำให้เรามีรายการที่สั้นลงซึ่งเป็นเพียงเวอร์ชันต่างๆ
‫ของ API ที่เราจำเป็นต้องกังวล
‫ในกรณีของการทำให้ใช้งานได้
‫คุณจะเห็นว่ามีบางอย่างที่คุ้นเคย
‫โปรดจำไว้ว่า เราเห็นว่ามีแอปหนึ่ง และมีส่วนขยายสำหรับการปรับใช้
‫เราจะเห็นสิ่งเหล่านี้ปรากฏขึ้นที่นี่
‫ในทางเทคนิค มีส่วนขยายของ
‫v1beta1 API มี API ของแอปซึ่งคุณสามารถดูเวอร์ชันต่างๆ
‫ได้สามเวอร์ชัน
‫คุณอาจต้องการใช้แอป V1 ไม่ใช่รุ่นเบต้าที่เก่ากว่า
‫แต่คุณสามารถเห็นได้ว่า API นั้นใช้เวอร์ชันใดที่เลิกใช้แล้วของ
‫API นี้ในขณะที่เปิดตัวเวอร์ชันใหม่
‫ด้วยวิธีนี้ โดยพื้นฐานแล้ว YAML เก่าของคุณจะไม่พังจนกว่าจะมีเวอร์ชันต่างๆ
‫ผ่านไปและพวกเขาจะดึงข้อมูลออกจาก API เมื่อไม่จำเป็นต้องใช้อีกต่อไป
‫สิ่งที่มักเกิดขึ้นตลอดอายุการใช้งาน YAML
‫ของคุณ ถ้าคุณอยู่ในยุคแรกๆ ของ Kubernetes
‫คือคุณอาจใช้ไฟล์ YAML ที่ระบุว่า extensions/v1beta1 สำหรับเวอร์ชัน
‫API และประเภทนั้นเป็นการทำให้ใช้งานได้
‫แต่เนื่องจาก API นั้นเปลี่ยนไป
‫และตอนนี้พวกเขากำลังเรียกมันว่า API ของแอป
‫และเวอร์ชันนั้นแตกต่างออกไป คุณจะยังคงมีการใช้งานอยู่บ้าง
‫แต่คุณจะเปลี่ยนเวอร์ชัน API นั้นเป็น apps/v1
‫ในตอนนี้
‫วิธีที่ฉันรู้ก็คือเพราะฉันต้องทำการค้นหาและคุณต้องดูเอกสารประกอบ
‫คุณเห็นในตัวอย่างที่ โอ้ เฮ้
‫มันบอกว่าแอพตอนนี้ มันไม่ได้บอกว่าส่วนขยายอีกต่อไป
‫มันแปลก. เดี๋ยวผมไปดูให้ จากนั้นคุณจะพบปัญหา
‫Kubernetes ใน GitHub ที่พูดถึงเรื่องนี้
‫มันยุ่งเล็กน้อย ไม่มีรายการการเลิกใช้งานที่ชัดเจนของทุกสิ่งที่เปลี่ยนแปลงตลอดเวลา
‫ดังนั้นจึงอาจเป็นสิ่งที่เป็นปัญหาได้
‫วิธีที่คุณจะรู้ว่าวิธีนี้ใช้ไม่ได้ผลคือเมื่อคุณนำ
‫YAML แบบเก่ามาใช้กับคลัสเตอร์ใหม่ และมันจะบอกคุณว่า
‫ฉันไม่รองรับเวอร์ชัน API นี้อีกต่อไป
‫หรือผมไม่รู้ว่าแบบนี้คืออะไร
‫ดังนั้นมันจะทำให้คุณมีข้อผิดพลาดที่ดีที่แจ้งให้คุณทราบว่า
‫เฮ้ นั่นคือปัญหา จากนั้น คุณอาจทำการค้นหาอย่างรวดเร็วและค้นหาว่าสิ่งใดที่ล้าสมัย
‫ประเด็นที่ฉันทำอยู่คือชนิดและเวอร์ชัน
‫API นั้นใช้ร่วมกันเพื่อตัดสินใจว่าคุณจะได้รับทรัพยากรใดและเวอร์ชัน
‫API ใดที่คุณจะสามารถใช้สำหรับทรัพยากรนั้นได้
‫นี่เป็นสองสิ่งแรกที่คุณต้องคิดก่อนสร้าง
‫YAML ด้วยซ้ำ
‫เมื่อคุณมีแล้ว คุณจะสร้างส่วนข้อมูลเมตา
‫สิ่งเดียวที่คุณต้องมีคือชื่อของทรัพยากรที่คุณจะสร้าง
‫แค่ตั้งชื่อให้มันดีๆ
‫จากนั้นคุณจะไปที่สเปก นั่นคือจุดที่การดำเนินการทั้งหมดเกิดขึ้นเนื่องจากข้อมูลจำเพาะจะแตกต่างไปจากเดิมอย่างสิ้นเชิงตามทรัพยากรที่คุณกำลังสร้าง
‫หากคุณกำลังสร้างพื้นที่เก็บข้อมูลกับการปรับใช้ คุณสามารถจินตนาการได้ว่า
‫YAML จะแตกต่างกันอย่างไรใช่ไหม
‫ในการบรรยายครั้งต่อไป เราจะพูดถึงคำสั่ง
‫kubectl เพื่อช่วยคุณสำรวจ API สำหรับข้อมูลจำเพาะต่างๆ
‫ทั้งหมดที่คุณสามารถใส่ลงใน YAML ของคุณสำหรับทรัพยากรต่างๆ