‫คำสั่งบางคำสั่งที่คุณใช้จนถึงตอนนี้ มีระบบอัตโนมัติเล็กน้อยที่เรียกว่าตัวสร้าง
‫เครื่องกำเนิดไฟฟ้าที่คุณคิดได้เหมือนกับเทมเพลต
‫โดยพื้นฐานแล้วจะสร้างข้อมูลจำเพาะหรือข้อกำหนดเพื่อใช้กับคลัสเตอร์
‫Kubernetes ตามตัวเลือกบรรทัดคำสั่งของคุณ
‫คุณนึกถึงคำสั่งต่างๆ เช่น เรียกใช้
‫เปิดเผย และสร้าง พวกเขามักจะมีตัวสร้างอยู่เบื้องหลังซึ่งให้เทมเพลตที่จำเป็นกับฟิลด์ทั้งหมดและค่าเริ่มต้นที่คุณไม่จำเป็นต้องระบุที่บรรทัดคำสั่ง
‫โดยพื้นฐานแล้ว จุดประสงค์ของตัวสร้างเหล่านี้คือการช่วยให้คุณใช้คำสั่งแบบบรรทัดเดียวได้ง่ายขึ้น
‫เช่นเดียวกับที่คุณเคยชินกับ Docker และ Docker Compose และ Swarm
‫หากต้องการใช้คำสั่งบรรทัดเดียวใน Kubernetes โดยปล่อยให้การตั้งค่าขั้นสูงบางอย่างเป็นค่าเริ่มต้น
‫จริงๆ Swarm ก็ทำแบบนี้เช่นกัน
‫Swarm มีค่าเริ่มต้นมากมายเมื่อคุณสร้างบริการและสแต็คที่เกิดขึ้นในเบื้องหลัง
‫คุณแค่ไม่รู้ เครื่องกำเนิดไฟฟ้าเหล่านี้เป็นเช่นนั้น
‫นี่คือตัวอย่างที่เรากำลังสร้างการทำให้ใช้งานได้ด้วยคำสั่ง
‫create และเราได้ให้ตัวเลือกสองสามอย่างเพื่อให้ตรงตามข้อกำหนดขั้นต่ำ
‫มันจะเติมข้อกำหนดที่เหลือด้วยเครื่องกำเนิด
‫เครื่องกำเนิดไฟฟ้าเหล่านี้จะแตกต่างกันไปตามประเภทของสิ่งที่คุณกำลังสร้าง
‫ไม่ว่าจะเป็นบริการ
‫การปรับใช้ งาน หรืองาน cron
‫สิ่งอื่น ๆ ที่เราจะพูดถึงในภายหลัง
‫เครื่องกำเนิดไฟฟ้าเหล่านี้สามารถเปลี่ยนแปลงได้ตลอดเวลาเมื่อ
‫Kubernetes แต่ละเวอร์ชันออกมา
‫พวกเขาอาจเปลี่ยนคุณสมบัติหนึ่งหรือสองคุณสมบัติของข้อกำหนดนั้น
‫ดังนั้นสิ่งเหล่านี้มีเวอร์ชัน
‫บางครั้ง หากคุณเคยเห็นในเอกสารประกอบ คุณอาจเห็น
‫YAML สำหรับ Kubernetes บางส่วน และมีบางอย่างเกี่ยวกับเบต้า
‫บ่อยครั้งเมื่อสร้างตัวสร้างครั้งแรก อาจมีรุ่นเบต้าและเมื่อเปลี่ยนเป็นตัวสร้างที่พัฒนาแล้ว
‫ก็จะมี V1
‫เราไม่สามารถรับรายชื่อตัวสร้างที่บรรทัดคำสั่งได้
‫เพราะมันครอบคลุมคำสั่งต่างๆ และตัวเลือกต่างๆ
‫ที่อาจใช้ตัวสร้าง
‫วิธีที่ง่ายที่สุดที่นี่ตลอดคำสั่งต่าง
‫ๆ เหล่านี้เพื่อดูว่าจะเกิดอะไรขึ้นหากคุณพิมพ์คำสั่งนั้นกับคลัสเตอร์คือใช้สองตัวเลือก
‫การวิ่งแบบแห้งซึ่งเป็นวิธีที่เรียบร้อยมากในการแสดงผลลัพธ์ของสิ่งที่คุณพิมพ์
‫และเราจะเห็นว่าในวินาทีนั้น
‫จากนั้น
‫-o ซึ่งหมายถึงเอาต์พุต เรากำลังบอกว่าเราต้องการผลลัพธ์ใน YAML
‫เรากำลังบอกว่ารันคำสั่งนี้เป็นหลัก แต่อย่าทำในทางเทคนิคบนคลัสเตอร์
‫ลองทำดูนะครับถ้าผมทำลงไปจะเป็นยังไง
‫ในเวลาเดียวกัน แสดงผลลัพธ์ YAML ของสิ่งที่จะถูกสร้างขึ้นหากฉันทำคำสั่งนี้เสร็จ
‫คุณจะได้เทมเพลตเล็กๆ น้อยๆ ที่ดี
‫คุณสามารถใช้สิ่งนั้นเพื่อเริ่มสร้าง YAML ของคุณเองที่เราจะใช้ในการบรรยายในภายหลัง
‫ในที่สุดเครื่องกำเนิดไฟฟ้าที่นี่
‫คุณอาจพิจารณาว่าเป็นค่าเริ่มต้นตามความเห็น
‫พวกเขาไม่มีความเห็นจริงๆ
‫พวกมันเล็กมาก
‫โดยปกติแล้วจะเป็น YAML 10 ถึง 15 บรรทัด
‫เพียงขั้นต่ำเปล่าเพื่อเริ่มต้นสิ่งต่างๆ
‫พวกเขามีความคิดเห็นซึ่งเป็นเหตุผลว่าทำไมพวกเขาถึงมีเวอร์ชันต่างๆ
‫คุณอาจเห็นเวอร์ชันเบต้าจบการศึกษาและอะไรก็ตาม
‫ฉันคิดว่าพวกเขามีความคิดเห็น
‫แต่พวกเขาก็โอเค ใช่ไหม สิ่งเหล่านี้จะใช้ได้กับกรณีการใช้งานส่วนใหญ่เมื่อคุณเพียงแค่ลองใช้เพื่อพัฒนาและทดสอบ
‫มาดูตัวอย่างสองสามตัวอย่างเพื่อดูตัวสร้างเหล่านี้ที่บรรทัดคำสั่ง
‫อันแรกนี่คือ Deployment เหมือนที่เราเคยใช้มาก่อน
‫การสร้างการปรับใช้
‫คุณจะสังเกตเห็นว่าฉันใส่ --dry-run ในตอนท้าย
‫หากคุณทำแบบแห้ง มันจะคายเฉพาะประเภทของทรัพยากรที่จะสร้างเท่านั้น
‫ซึ่งคล้ายกับชื่อของทรัพยากรที่เราเห็นเมื่อเราแสดงรายการด้วยคำสั่ง
‫kubectl get
‫ถ้าฉันกดลูกศรขึ้นที่นั่นแล้วพิมพ์ -o yaml
‫จากนั้นจะแสดงผลลัพธ์ YAML
‫ที่สร้างด้วยคำสั่งนั้นให้ฉันดู
‫เราจะพูดถึงข้อกำหนดของ
‫YAML ในภายหลัง สำหรับตอนนี้ คุณสามารถดูส่วนสำคัญของสิ่งที่ทำในพื้นหลังเมื่อเราสร้างคำสั่งการปรับใช้
‫ขั้นแรกจะแสดงเวอร์ชัน API ซึ่งเป็นเวอร์ชันของทรัพยากรประเภทนี้
‫ดังนั้น เรากำลังใช้เวอร์ชันแอป/เวอร์ชัน
‫1 ที่นี่ ประเภทนี้คือการปรับใช้ และนั่นเป็นเพราะว่าเรากำลังสร้างการทำให้ใช้งานได้
‫ถ้าเป็นงานก็เรียกว่างาน
‫ถ้าเป็น Service จะบอกว่า Service
‫ของแบบนั้น ข้อมูลเมตาจะอยู่ที่นั่นเสมอสำหรับทรัพยากรใดๆ
‫ที่คุณสร้าง
‫มันจะมีการประทับเวลา ซึ่งเป็นทางเลือก เพราะมันจะสร้างโดยอัตโนมัติเมื่อคุณสร้างสิ่งนี้จริงๆ
‫จากนั้นคุณจะมีป้ายกำกับและแอตทริบิวต์ชื่อที่คุณสามารถระบุได้ที่นี่
‫ในกรณีนี้ คุณจะเห็นว่ามันเต็มไปด้วยสิ่งที่ฉันให้ไว้ที่บรรทัดคำสั่ง
‫ฉันบอกว่าฉันต้องการเรียกมันว่าการทดสอบ
‫ดังนั้นจึงตั้งชื่อการทดสอบ
‫เป็นการกำหนดแอปเนื่องจากเราใช้ Deployment ที่นี่
‫ถือว่าเป็นแอป ไม่ใช่บริการหรืออย่างอื่น
‫มันกำลังเรียกการทดสอบฉลากนั้น
‫นี่เป็นเพียงค่าเริ่มต้นที่พร้อมใช้งานทันที
‫จากนั้นข้อมูลจำเพาะสำหรับการปรับใช้จะเป็นแบบจำลองหนึ่งรายการ
‫เราจะพูดถึงตัวเลือกในภายหลัง แต่โดยพื้นฐานแล้วสิ่งนี้จะกำหนดการเลือกพ็อดภายในการทำให้ใช้งานได้นี้
‫โดยพื้นฐานแล้วมันเป็นสิ่งที่ตรงกับการปรับใช้นั้นกับพ็อดของมัน
‫แล้วกลยุทธ์ ที่เราเว้นว่างไว้
‫เทมเพลตที่นี่มีไว้สำหรับ ReplicaSet
‫จากนั้นคุณจะเห็นคอนเทนเนอร์ที่จะสร้างภายใต้สเปกนั้น
‫ดังนั้นจึงมีชั้นข้อมูลจำเพาะที่ซ้อนกันอยู่เล็กน้อยเกิดขึ้นที่นี่
‫นั่นเป็นเพราะความซับซ้อนของเลเยอร์เหล่านี้ใช่ไหม
‫เรามีพ็อด
‫จากนั้น ReplicaSets และ Deployments นอกเหนือจากนั้น
‫คุณจะเห็นว่ามันกำลังสร้างทั้งหมดนั้นทันที
‫และเราจะนำไปใช้กับ API เมื่อเรากดคำสั่งนี้
‫มาสร้างอีกสองสามที่นี่ อันที่สองใช้ Jobs
‫แทน Deployments โดยปกติแล้วจะได้รับการออกแบบเมื่อคุณต้องการสร้างชุดของพ็อดที่จะทำงานเพียงครั้งเดียว
‫มีแนวโน้มที่จะตั้งค่าเริ่มต้นที่จะไม่เริ่มต้นใหม่
‫ในกรณีนี้ เราจะใช้รูปภาพเดียวกัน
‫ชื่อเดียวกัน เราจะทำให้มันแห้งด้วย
‫-output yaml คุณจะเห็นว่ามันแตกต่างกันมากน้อยเพียงใด
‫ในกรณีนี้ เนื่องจากเราไม่มีหลายระดับของการปรับใช้ที่มี
‫ReplicaSet ซ้อนอยู่ภายใน เราจึงไม่ต้องการข้อมูลจำเพาะหลายระดับ
‫อย่างแรกคุณจะเห็นว่าอันนี้สั้นกว่ามาก
‫สาเหตุส่วนใหญ่มาจากการที่ Deployments จะสร้าง
‫ReplicaSet ที่ซ้อนกันซึ่งจะสร้างพ็อดขึ้นมา
‫ดังนั้นจึงมีหลายระดับ
‫ในที่นี้ เราแค่มีงานแบทช์ที่สร้างพ็อดให้เราโดยตรง
‫คุณสามารถดูได้ที่ด้านบนว่าทั้งเวอร์ชัน API และประเภทมีการเปลี่ยนแปลง
‫ข้อมูลเมตาคล้ายกันมาก แม้ว่าในกรณีนี้
‫จะไม่สร้างป้ายกำกับแอป
‫ข้อมูลจำเพาะมีไว้สำหรับงานเท่านั้น และด้านล่าง
‫ข้อมูลจำเพาะภายในนั้น ภายในเทมเพลตนั้น เป็นข้อมูลจำเพาะสำหรับพ็อดคอนเทนเนอร์แต่ละอันใช่ไหม
‫ข้อมูลจำเพาะนี้จะถูกสร้างขึ้นสำหรับจำนวนเท่าใดก็ได้ที่ฉันขอให้สร้าง
‫เราสร้างหนึ่งรายการโดยค่าเริ่มต้นเท่านั้น
‫ดังนั้นจะมีหนึ่งคอนเทนเนอร์ที่รัน Nginx
‫พร้อมการทดสอบชื่อ คุณจะสังเกตเห็นว่านโยบายการรีสตาร์ทไม่เคยเกิดขึ้นเลย
‫นั่นคือการเปลี่ยนแปลง
‫กับวิธีอื่นๆ ส่วนใหญ่ในการสร้างคอนเทนเนอร์ใน Kubernetes
‫พวกเขาจะพยายามสร้างใหม่หรือรีสตาร์ทโดยอัตโนมัติ
‫ด้วยงานหรือใหม่กว่าด้วยงาน
‫cron คุณจะเห็นว่านโยบายการรีสตาร์ทถูกตั้งค่าเป็นไม่เลย
‫เนื่องจากโดยทั่วไปแล้วเมื่องานเสร็จสิ้น
‫งานก็จะเสร็จสิ้น และคุณไม่ต้องการให้คอนเทนเนอร์นั้นสร้างใหม่
‫สุดท้าย มาทำคำสั่งเปิดเผย
‫แม้ว่าจะมีการใช้งานแบบแห้งที่นี่ เมื่อคุณเรียกใช้
‫expose Deploy มันจะตรวจสอบการปรับใช้นั้นและพบว่าไม่มีอยู่จริง
‫ดังนั้นจึงไม่สามารถให้เอาต์พุตตัวอย่างแก่คุณได้
‫เนื่องจากไม่มีอินพุตที่ถูกต้องจริงๆ .
‫ในกรณีนี้ เราจำเป็นต้องสร้างการทำให้ใช้งานได้ในทางเทคนิค
‫ในส่วนนี้ เราไม่จำเป็นต้องมีการทำงานแบบแห้งและแบบเอาท์พุต
‫เราแค่ต้องการให้มันสร้างมันขึ้นมา
‫ลองทำกันดูนะ
‫จากนั้นกลับไปที่คำสั่ง expose แล้วลองอีกครั้ง
‫จากนั้นการวิ่งแบบแห้งนั้นจะได้ผลในครั้งนี้
‫เราจะมีเวอร์ชัน API ของ V1
‫คุณจะสังเกตเห็นว่าตอนนี้บริการเป็นประเภทแทนการทำให้ใช้งานได้หรืองาน
‫จากนั้น เราก็มีป้ายกำกับอื่นๆ ที่คล้ายกัน
‫คุณจะเห็นว่าข้อมูลจำเพาะนั้นเกี่ยวกับพอร์ตและโปรโตคอลทั้งหมด
‫เพราะนั่นคือสิ่งที่เป็นบริการจริงๆ
‫เป็นการรวมกันของเส้นทางเครือข่ายและซับเน็ต
‫IP และพอร์ต TCP หรือ UDP และอะไรทำนองนั้น
‫เครื่องกำเนิดไฟฟ้าไม่จำเป็นต้องเป็นเรื่องใหญ่
‫คุณไม่จำเป็นต้องจำหรือเรียนรู้ความแตกต่างระหว่างสิ่งเหล่านี้ทั้งหมด
‫เพราะคุณจะพบสิ่งเหล่านี้จำนวนมากด้วยคำสั่ง
‫kubectl run จะหายไปอย่างที่คุณจะรู้ได้ในไม่กี่นาที
‫จากนั้นในการบรรยายในภายหลัง
‫เราจะพูดถึงประเภทของวิธีการสร้างคอนเทนเนอร์ และอาจเป็นเพราะเหตุใดคุณจึงไม่ต้องใช้รันจำนวนมากและสร้างปริมาณงานการผลิตของคุณ
‫อย่าลืมลบการทดสอบการทำให้ใช้งานได้ หากคุณสร้างมันขึ้นมาสำหรับคำสั่งสุดท้ายที่เราทดสอบการเปิดเผย