คูเบอร์เน็ตส์

Kubernetes ( / ˌ k ( j ) uː b ər ˈ n ɛ t ɪ s , - ˈ n eɪ t ɪ s , - ˈ n eɪ t iː z , - ˈ n ɛ t iː z / ) หรือที่รู้จักกันในชื่อK8sเป็น ระบบ จัดการคอนเทนเนอร์แบบ โอเพนซอร์ส เพื่อทำให้การปรับใช้ซอฟต์แวร์การขยายขนาด และการจัดการ เป็นไปโดยอัตโนมัติ ^[³^]^[⁴^]เดิมทีออกแบบโดยGoogleปัจจุบันโครงการนี้ได้รับการดูแลโดยชุมชนผู้มีส่วนร่วมทั่วโลก และเครื่องหมายการค้าเป็นของCloud Native Computing Foundation

ชื่อKubernetesมาจากคำภาษากรีกโบราณκυβερνήτης , kubernḗtēs ( helmsman, pilot )ซึ่งเป็นที่มาของคำว่าcyberneticsและ (ผ่านภาษาละติน) governor ด้วย "Kubernetes" มักจะย่อด้วยตัวเลขย่อ "K8s" ซึ่งหมายถึง "ตัวอักษร K ตามด้วยตัวอักษร 8 ตัว ตามด้วย s" ^[⁵^]

Kubernetes รวบรวมคอมพิวเตอร์หนึ่งเครื่องหรือมากกว่านั้น ไม่ว่าจะเป็นเครื่องเสมือนหรือเครื่องจริงเข้าเป็นคลัสเตอร์ที่สามารถรันเวิร์กโหลดในคอนเทนเนอร์ได้ โดยทำงานร่วมกับรันไทม์คอนเทนเนอร์ต่างๆ เช่นcontainerdและCRI-O [ ^{6 ] ความ}เหมาะสมในการรันและจัดการเวิร์กโหลดทุกขนาดและรูปแบบทำให้มีการนำไปใช้อย่างแพร่หลายในระบบคลาวด์และศูนย์ข้อมูล มีการแจกจ่ายแพลตฟอร์มนี้หลายเวอร์ชัน ทั้งจากผู้จำหน่ายซอฟต์แวร์อิสระ (ISV) และข้อเสนอที่โฮสต์บนคลาวด์จากผู้ให้บริการคลาวด์สาธารณะรายใหญ่ทั้งหมด^{[ 7 ]}

ซอฟต์แวร์ประกอบด้วยระนาบควบคุมและโหนดที่แอปพลิเคชันจริงทำงานอยู่ รวมถึงเครื่องมือต่างๆ เช่นkubeadmและkubectlซึ่งสามารถใช้เพื่อโต้ตอบกับAPI ที่ใช้REST ได้ ^{[ 8 ]}

ประวัติศาสตร์

Google ประกาศเปิดตัว Kubernetes เมื่อวันที่ 6 มิถุนายน 2014 ^{[ 9 ]}โครงการนี้ได้รับการคิดค้นและสร้างขึ้นโดยพนักงานของ Google ได้แก่ Joe Beda, Brendan Burns และ Craig McLuckie ต่อมามีพนักงานคนอื่นๆ ของ Google เข้าร่วมช่วยสร้างโครงการนี้ด้วย ได้แก่ Ville Aikas, Dawn Chen, Brian Grant, Tim Hockin และ Daniel Smith ^{[ 10 ]}^{[ 11 ]}บริษัทอื่นๆ เช่นRed HatและCoreOSก็เข้าร่วมโครงการในเวลาต่อมา โดยมีผู้ร่วมสนับสนุนที่โดดเด่น เช่น Clayton Coleman และKelsey Hightower ^{[ 9 ]}

การออกแบบและการพัฒนา Kubernetes ได้รับแรงบันดาลใจจาก ตัวจัดการคลัสเตอร์ Borg ของ Google และ อิงตามทฤษฎี Promise ^{[ 12 ]}^{[ 13 ]}ผู้มีส่วนร่วมหลักหลายคนเคยทำงานกับ Borg มาก่อน^{[ 14 ]}^{[ 15 ]}พวกเขาตั้งชื่อรหัส Kubernetes ว่า " Project 7 " ตามชื่อตัวละครSeven of Nine จาก Star Trekซึ่งเป็นอดีต สมาชิก Borg ^[¹⁶^]และตั้งชื่อโลโก้เป็นพวงมาลัยเรือเจ็ดซี่ (ออกแบบโดย Tim Hockin) แตกต่างจาก Borg ซึ่งเขียนด้วยภาษา C++ ^{[ 14} ] ^Kubernetes^{เขียน}ด้วยภาษาGo

Kubernetes ได้รับการประกาศในเดือนมิถุนายน พ.ศ. 2557 และเวอร์ชัน 1.0 ได้รับการเผยแพร่เมื่อวันที่ 21 กรกฎาคม พ.ศ. 2558 ^{[ 17 ]} Google ได้ร่วมมือกับLinux Foundationเพื่อก่อตั้ง Cloud Native Computing Foundation (CNCF) ^{[ 18 ]}และเสนอ Kubernetes เป็นเทคโนโลยีเริ่มต้น

Google ได้ให้บริการ Kubernetes แบบจัดการอยู่แล้ว คือGKEและRed Hatก็สนับสนุน Kubernetes ในฐานะส่วนหนึ่งของOpenShiftมาตั้งแต่เริ่มโครงการ Kubernetes ในปี 2014 ^{[ 19 ]}ในปี 2017 คู่แข่งหลักๆ ได้รวมตัวกันสนับสนุน Kubernetes และประกาศเพิ่มการสนับสนุนแบบเนทีฟสำหรับ Kubernetes:

VMware (ผู้สนับสนุนPivotal Cloud Foundry ) ^{[ 20 ]}ในเดือนสิงหาคม
Mesosphere, Inc. (ผู้สนับสนุน Marathon และMesos ) ^{[ 21 ]}ในเดือนกันยายน
Docker, Inc. (ผู้สนับสนุนDocker ) ^{[ 22 ]}ในเดือนตุลาคม
Microsoft Azure ^{[ 23 ]}ในเดือนตุลาคมเช่นกัน
AWSประกาศสนับสนุน Kubernetes ผ่านทาง Elastic Kubernetes Service (EKS) ^{[ 24 ]}ในเดือนพฤศจิกายน

เมื่อวันที่ 6 มีนาคม 2018 โครงการ Kubernetes ขึ้นมาอยู่ในอันดับที่ 9 ในรายการ โครงการ GitHubตามจำนวนการคอมมิตและอยู่ในอันดับที่ 2 ตามจำนวนผู้เขียนและปัญหา รองจากเคอร์เนลLinux ^{[ 25 ]}

จนถึงเวอร์ชัน 1.18 Kubernetes ปฏิบัติตามนโยบายการสนับสนุนแบบ N-2 ซึ่งหมายความว่าเวอร์ชันย่อยสามเวอร์ชันล่าสุดจะได้รับการอัปเดตด้านความปลอดภัยและการแก้ไขข้อบกพร่อง^{[ 26 ]}ตั้งแต่เวอร์ชัน 1.19 เป็นต้นไป Kubernetes ปฏิบัติตามนโยบายการสนับสนุนแบบ N-3 ^{[ 27 ]}

แนวคิด

Kubernetes กำหนดชุดของส่วนประกอบพื้นฐาน ("ส่วนประกอบพื้นฐาน") ที่รวมกันเป็นกลไกในการปรับใช้ บำรุงรักษา และปรับขนาดแอปพลิเคชันตามCPUหน่วยความจำ หรือเมตริกที่กำหนดเอง^{[ 28 ]} Kubernetes มีการเชื่อมต่อแบบหลวมๆและสามารถขยายได้เพื่อตอบสนองความต้องการของเวิร์กโหลดที่แตกต่างกัน ส่วนประกอบภายใน ตลอดจนส่วนขยายและคอนเทนเนอร์ที่ทำงานบน Kubernetes อาศัย API ของ Kubernetes ^{[ 29 ]}^{[ 30 ]}

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

Kubernetes ใช้สถาปัตยกรรมหลัก/สำเนาส่วนประกอบของ Kubernetes สามารถแบ่งออกเป็นส่วนที่จัดการโหนด แต่ละโหนด และส่วนที่เป็นส่วนหนึ่งของระนาบควบคุม^{[ 29 ]}^{[ 31 ]}

ระนาบควบคุม

ระนาบควบคุมของ Kubernetes จัดการภาระงานและกำกับการสื่อสารทั่วทั้งระบบ ประกอบด้วยส่วนประกอบต่างๆ เช่นการเข้ารหัส TLSการควบคุมการเข้าถึงตามบทบาท (RBAC) และ วิธี การตรวจสอบสิทธิ์ ที่แข็งแกร่ง การแยกเครือข่าย แต่ละกระบวนการสามารถทำงานได้ทั้งบนโหนดเดียวหรือบนหลายโหนดเพื่อรองรับคลัสเตอร์ที่มีความพร้อมใช้งานสูง [ ^{31 ] ส่วนประกอบ}ต่างๆ ของระนาบควบคุมของ Kubernetes มีดังต่อไปนี้^{[ 32 ]}

ฯลฯ

Etcd ^{[ 33 ]}เป็นที่เก็บข้อมูลแบบคีย์-ค่าแบบ กระจาย น้ำหนักเบา และคงอยู่ถาวร (เดิมพัฒนาขึ้นเป็นส่วนหนึ่งของ CoreOS) โดยจะจัดเก็บข้อมูลการกำหนดค่าของคลัสเตอร์อย่างน่าเชื่อถือ ซึ่งแสดงถึงสถานะโดยรวมของคลัสเตอร์ ณ จุดเวลาใดเวลาหนึ่ง Etcd ให้ความสำคัญกับความสอดคล้องมากกว่าความพร้อมใช้งานในกรณีที่เกิดการแบ่งเครือข่าย (ดูทฤษฎีบท CAP ) ความสอดคล้องนี้มีความสำคัญอย่างยิ่งต่อการจัดตารางเวลาและการดำเนินงานบริการอย่างถูกต้อง

เซิร์ฟเวอร์ API

เซิร์ฟเวอร์ API ให้บริการ Kubernetes APIโดยใช้JSONผ่านHTTPSซึ่งเป็นอินเทอร์เฟซทั้งภายในและภายนอกสำหรับ Kubernetes ^{[ 29 ]}^{[ 34 ]}เซิร์ฟเวอร์ API ประมวลผล ตรวจสอบความถูกต้อง ของคำขอ RESTและอัปเดตสถานะของวัตถุ API ใน etcd ทำให้ไคลเอนต์สามารถกำหนดค่าเวิร์กโหลดและคอนเทนเนอร์ในโหนดผู้ทำงานได้^{[ 35 ]}เซิร์ฟเวอร์ API ใช้ API watch ของ etcd เพื่อตรวจสอบคลัสเตอร์ ดำเนินการเปลี่ยนแปลงการกำหนดค่าที่สำคัญ หรือกู้คืนความแตกต่างของสถานะของคลัสเตอร์กลับไปยังสถานะที่ต้องการตามที่ประกาศไว้ใน etcd

ตัวอย่างเช่น ผู้ปฏิบัติงานที่เป็นมนุษย์อาจระบุว่าต้องมีอินสแตนซ์ของ "pod" เฉพาะ (ดูด้านล่าง) จำนวน 3 อินสแตนซ์ทำงานอยู่ และ etcd จะบันทึกข้อเท็จจริงนี้ไว้ หากตัวควบคุมการปรับใช้พบว่ามีเพียง 2 อินสแตนซ์ทำงานอยู่ (ซึ่งขัดแย้งกับการประกาศของ etcd) ^{[ 36 ]}มันจะกำหนดเวลาสร้างอินสแตนซ์เพิ่มเติมของ pod นั้น^{[ 31 ]}

ผู้กำหนดตารางเวลา

ตัวกำหนดตารางเวลาเป็นส่วนประกอบที่ขยายได้ซึ่งเลือกโหนดที่พอดที่ยังไม่ได้กำหนดตารางเวลา (หน่วยพื้นฐานของภาระงานที่จะถูกกำหนดตารางเวลา) ทำงานโดยพิจารณาจากความพร้อมใช้งานของทรัพยากรและข้อจำกัดอื่นๆ ตัวกำหนดตารางเวลาจะติดตามการจัดสรรทรัพยากรในแต่ละโหนดเพื่อให้แน่ใจว่าภาระงานจะไม่ถูกกำหนดตารางเวลาเกินกว่าทรัพยากรที่มีอยู่ ด้วยเหตุนี้ ตัวกำหนดตารางเวลาจึงต้องทราบข้อกำหนดของทรัพยากร ความพร้อมใช้งานของทรัพยากร และข้อจำกัดหรือคำสั่งนโยบายอื่นๆ ที่ผู้ใช้กำหนด เช่น คุณภาพของบริการ ข้อกำหนดความสัมพันธ์/การต่อต้านความสัมพันธ์ และความใกล้เคียงของข้อมูล บทบาทของตัวกำหนดตารางเวลาคือการจับคู่ "อุปทาน" ของทรัพยากรกับ "ความต้องการ" ของภาระงาน^{[ 37 ]}

Kubernetes อนุญาตให้เรียกใช้ตัวกำหนดตารางเวลาหลายตัวภายในคลัสเตอร์เดียว ดังนั้นปลั๊กอิน ตัวกำหนดตารางเวลา จึงสามารถพัฒนาและติดตั้งเป็นส่วนขยายในกระบวนการของตัวกำหนดตารางเวลาพื้นฐานได้โดยการเรียกใช้เป็นตัวกำหนดตารางเวลาแยกต่างหาก ตราบใดที่เป็นไปตามกรอบงานกำหนดตารางเวลาของ Kubernetes ^{[ 38 ]}ซึ่งช่วยให้ผู้ดูแลระบบคลัสเตอร์สามารถขยายหรือแก้ไขพฤติกรรมของตัวกำหนดตารางเวลาเริ่มต้นของ Kubernetes ตามความต้องการของตนได้

ตัวควบคุม

ตัวควบคุมคือลูปการกระทบยอดที่ขับเคลื่อนสถานะคลัสเตอร์จริงไปสู่สถานะที่ต้องการ โดยสื่อสารกับเซิร์ฟเวอร์ API เพื่อสร้าง อัปเดต และลบทรัพยากรที่จัดการ (เช่น พอดหรือเอนด์พอยต์บริการ) ^{[ 39 ]}^{[ 34 ]}

ตัวควบคุมตัวอย่างหนึ่งคือตัวควบคุม ReplicaSet ซึ่งจัดการการจำลองและการปรับขนาดโดยการรันสำเนาของพอดจำนวนที่กำหนดไว้ทั่วทั้งคลัสเตอร์ ตัวควบคุมยังจัดการการสร้างพอดทดแทนหากโหนดพื้นฐานล้มเหลว^{[ 39 ]}ตัวควบคุมอื่นๆ ที่เป็นส่วนหนึ่งของระบบ Kubernetes หลัก ได้แก่ ตัวควบคุม DaemonSet สำหรับการรันพอดเพียงหนึ่งพอดบนทุกเครื่อง (หรือกลุ่มย่อยของเครื่อง) และตัวควบคุม Job สำหรับการรันพอดที่ทำงานจนเสร็จสมบูรณ์ (เช่น เป็นส่วนหนึ่งของงานแบบแบตช์) ^{[ 40 ]}ตัวเลือกป้ายกำกับมักเป็นส่วนหนึ่งของคำจำกัดความของตัวควบคุมที่ระบุชุดของพอดที่ตัวควบคุมจัดการ^{[ 41 ]}

ตัวจัดการคอนโทรลเลอร์เป็นกระบวนการเดียวที่จัดการคอนโทรลเลอร์ Kubernetes หลักหลายตัว (รวมถึงตัวอย่างที่อธิบายไว้ข้างต้น) กระจายเป็นส่วนหนึ่งของการติดตั้ง Kubernetes มาตรฐานและตอบสนองต่อการสูญเสียโหนด^{[ 32 ]}

นอกจากนี้ ยังสามารถติดตั้งคอนโทรลเลอร์แบบกำหนดเองในคลัสเตอร์ได้ ซึ่งจะช่วยให้สามารถขยายพฤติกรรมและ API ของ Kubernetes ได้มากขึ้นเมื่อใช้งานร่วมกับทรัพยากรแบบกำหนดเอง (ดูรายละเอียดในหัวข้อทรัพยากรแบบกำหนดเอง คอนโทรลเลอร์ และโอเปอเรเตอร์ด้านล่าง)

โหนด

โหนด หรือที่รู้จักกันในชื่อ เวิร์กเกอร์ หรือ มินเนียน คือเครื่องที่ใช้ในการติดตั้งคอนเทนเนอร์ (เวิร์กโหลด) ทุกโหนดในคลัสเตอร์จะต้องมีรันไทม์ สำหรับคอนเทนเนอร์ รวมถึงส่วนประกอบต่างๆ ที่กล่าวถึงด้านล่าง เพื่อใช้ในการสื่อสารกับโครงสร้างเครือข่ายหลักของคอนเทนเนอร์เหล่านั้น

คูเบเล็ต

kubelet มีหน้าที่รับผิดชอบสถานะการทำงานของแต่ละโหนด เพื่อให้แน่ใจว่าคอนเทนเนอร์ทั้งหมดบนโหนดนั้นอยู่ในสภาพสมบูรณ์ โดยจะดูแลการเริ่มต้น การหยุด และการบำรุงรักษาคอนเทนเนอร์แอปพลิเคชันที่จัดเป็นพอดตามคำสั่งของคอนโทรลเพลน^{[ 29 ]}^{[ 42 ]} kubelet จะตรวจสอบสถานะของพอด และหากไม่อยู่ในสถานะที่ต้องการ พอดจะถูกปรับใช้ใหม่ไปยังโหนดเดิม สถานะของโหนดจะถูกส่งต่อทุกๆ สองสามวินาทีผ่านข้อความ heartbeat ไปยังเซิร์ฟเวอร์ API เมื่อคอนโทรลเพลนตรวจพบความล้มเหลวของโหนด ตัวควบคุมระดับสูงกว่าจะสังเกตเห็นการเปลี่ยนแปลงสถานะนี้และเปิดใช้งานพอดบนโหนดที่มีสุขภาพดีอีกโหนดหนึ่ง^{[ 43 ]}

รันไทม์คอนเทนเนอร์

รันไทม์คอนเทนเนอร์มีหน้าที่รับผิดชอบวงจรชีวิตของคอนเทนเนอร์ รวมถึงการเริ่มต้น การกระทบยอด และการยุติคอนเทนเนอร์ kubelet โต้ตอบกับรันไทม์คอนเทนเนอร์ผ่านทางอินเทอร์เฟซรันไทม์คอนเทนเนอร์ (CRI) ^{[ 44 ]}^{[ 45 ]}ซึ่งแยกการบำรุงรักษา Kubernetes หลักออกจากการใช้งาน CRI จริง

เดิมที kubelet เชื่อมโยงอย่างแน่นหนากับDockerในฐานะรันไทม์คอนเทนเนอร์^{[ 46 ]}ต่อมาได้พัฒนา CRI และ "dockershim" ที่เชื่อมต่อกับ Docker ด้านหนึ่ง และ (ผ่าน CRI) กับ Kubelet อีกด้านหนึ่ง ตั้งแต่เดือนพฤศจิกายน 2020 ^{[ 47 ]}จนถึงเดือนเมษายน 2022 Kubernetes ได้ยกเลิกการใช้งานshim ^{[ 48 ]}^{[ 44 ]}^{[ 49 ]}ด้วยการเปิดตัว v1.24 ในเดือนพฤษภาคม 2022 "dockershim" ได้ถูกลบออกทั้งหมด ทำให้การสนับสนุน Docker ในฐานะรันไทม์คอนเทนเนอร์อย่างเป็นทางการสิ้นสุดลง^{[ 50 ]}

ณ ปี 2026 รันไทม์คอนเทนเนอร์ที่สอดคล้องกับมาตรฐาน CRI ที่ใช้งานกันอย่างแพร่หลาย ได้แก่containerdและCRI- O

kube-proxy

kube-proxy เป็นการใช้งานพร็อกซีเครือข่ายและตัวกระจายโหลดและรองรับการแยกบริการพร้อมกับการดำเนินการเครือข่ายอื่นๆ^{[ 29 ]}มีหน้าที่ในการกำหนดเส้นทางการรับส่งข้อมูลไปยังคอนเทนเนอร์ที่เหมาะสมตาม IP และหมายเลขพอร์ตของคำขอขาเข้า

เนมสเปซ

ใน Kubernetes เนมสเปซถูกใช้เพื่อแยกทรัพยากรที่จัดการออกเป็นกลุ่มที่แตกต่างกันและไม่ทับซ้อนกัน^{[ 51 ]}มีจุดประสงค์เพื่อใช้ในสภาพแวดล้อมที่มีผู้ใช้จำนวนมากกระจายอยู่ทั่วหลายทีมหรือหลายโครงการ หรือแม้กระทั่งแยกสภาพแวดล้อมต่างๆ เช่น การพัฒนา การทดสอบ และการผลิต

พ็อด

หน่วยการประมวลผลพื้นฐานที่สามารถใช้งานได้ใน Kubernetes คือ pod ^{[ 52 ]}ซึ่งประกอบด้วยคอนเทนเนอร์หนึ่งตัวหรือมากกว่าที่อยู่บนโหนดเดียวกัน^{[ 29 ]}แต่ละ pod จะได้รับที่อยู่ IP ที่ไม่ซ้ำกันภายในคลัสเตอร์ ทำให้แอปพลิเคชันสามารถใช้พอร์ตได้โดยไม่มีความเสี่ยงที่จะเกิดข้อขัดแย้ง^{[ 53 ]}ภายใน pod คอนเทนเนอร์ทั้งหมดจะมีบริบทที่ใช้ร่วมกันและสามารถอ้างอิงถึงกันได้

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

ภาระงาน

Kubernetes รองรับการทำงานแบบนามธรรมหลายระดับที่เหนือกว่าพอดแบบธรรมดา これによりผู้ใช้สามารถกำหนดและจัดการการทำงานแบบนามธรรมระดับสูงเหล่านี้ได้โดยไม่ต้องใช้การจัดการพอดแต่ละตัวด้วยตนเอง การทำงานแบบนามธรรมหลายอย่างที่รองรับโดยการติดตั้ง Kubernetes มาตรฐานนั้นมีรายละเอียดดังต่อไปนี้

ชุดจำลอง (ReplicaSets), ตัวควบคุมการจำลอง (Replication Controllers) และการปรับใช้ (Deployments)

จุดประสงค์ของ ReplicaSet คือการรักษาสภาพการทำงานของชุด Pod จำลองให้คงที่ตลอดเวลา ดังนั้นจึงมักใช้เพื่อรับประกันความพร้อมใช้งานของ Pod ที่เหมือนกันตามจำนวนที่กำหนด^{[ 54 ]} ReplicaSet ยังอาจกล่าวได้ว่าเป็นกลไกการจัดกลุ่มที่ช่วยให้ Kubernetes รักษาจำนวนอินสแตนซ์ที่ประกาศไว้สำหรับ Pod ที่กำหนด คำจำกัดความของ ReplicaSet ใช้ตัวเลือก ซึ่งการประเมินตัวเลือกนี้จะส่งผลให้ระบุ Pod ทั้งหมดที่เกี่ยวข้องกับมัน

ReplicationController คล้ายกับ ReplicaSet ทำหน้าที่เดียวกันและมีพฤติกรรมคล้ายกับ ReplicaSet ซึ่งก็คือเพื่อให้แน่ใจว่าจะมีจำนวนสำเนาของพอดตามที่กำหนดไว้เสมอตามที่ต้องการ เวิร์กโหลด ReplicationController เป็นตัวก่อนหน้าของ ReplicaSet แต่ในที่สุดก็ถูกยกเลิกเพื่อใช้ ReplicaSet แทน เพื่อให้สามารถใช้งานตัวเลือกป้ายกำกับแบบชุดได้^{[ 54 ]}

การปรับใช้เป็นกลไกการจัดการระดับสูงกว่าสำหรับ ReplicaSet ในขณะที่ตัวควบคุม ReplicaSet จัดการขนาดของ ReplicaSet ตัวควบคุมการปรับใช้จะจัดการสิ่งที่เกิดขึ้นกับ ReplicaSet ไม่ว่าจะเป็นการต้องดำเนินการอัปเดตหรือยกเลิกการอัปเดต เป็นต้น เมื่อการปรับใช้ถูกปรับขนาดขึ้นหรือลง จะส่งผลให้การประกาศของ ReplicaSet เปลี่ยนแปลง และการเปลี่ยนแปลงในสถานะที่ประกาศนี้จะได้รับการจัดการโดยตัวควบคุม ReplicaSet ^{[ 36 ]}

StatefulSets

StatefulSets คือตัวควบคุมที่บังคับใช้คุณสมบัติของความเป็นเอกลักษณ์และลำดับระหว่างอินสแตนซ์ของพอด และสามารถใช้เพื่อเรียกใช้แอปพลิเคชันที่มีสถานะได้^{[ 55 ]}ในขณะที่การปรับขนาดแอปพลิเคชันที่ไม่มีสถานะเป็นเพียงเรื่องของการเพิ่มพอดที่ทำงานมากขึ้น การทำเช่นนั้นสำหรับเวิร์กโหลดที่มีสถานะทำได้ยากกว่า เนื่องจากสถานะจำเป็นต้องได้รับการเก็บรักษาไว้หากพอดถูกรีสตาร์ท หากแอปพลิเคชันถูกปรับขนาดขึ้นหรือลง สถานะอาจจำเป็นต้องได้รับการกระจายใหม่

ฐานข้อมูลเป็นตัวอย่างของเวิร์กโหลดที่มีสถานะ เมื่อทำงานในโหมดความพร้อมใช้งานสูง ฐานข้อมูลจำนวนมากมาพร้อมกับแนวคิดของอินสแตนซ์หลักและอินสแตนซ์รอง ในกรณีนี้ แนวคิดเรื่องลำดับของอินสแตนซ์มีความสำคัญ แอปพลิเคชันอื่นๆ เช่นApache Kafkaกระจายข้อมูลไปยังโบรกเกอร์ต่างๆ ดังนั้น โบรกเกอร์แต่ละตัวจึงไม่เหมือนกัน ในกรณีนี้ แนวคิดเรื่องความเป็นเอกลักษณ์ของอินสแตนซ์จึงมีความสำคัญ

DaemonSets

DaemonSets มีหน้าที่รับผิดชอบในการทำให้แน่ใจว่ามีการสร้าง pod บนทุกโหนดในคลัสเตอร์^{[ 56 ]}โดยทั่วไป เวิร์กโหลดส่วนใหญ่จะปรับขนาดตามจำนวนสำเนาที่ต้องการ โดยขึ้นอยู่กับความพร้อมใช้งานและข้อกำหนดด้านประสิทธิภาพตามที่แอปพลิเคชันต้องการ อย่างไรก็ตาม ในสถานการณ์อื่นๆ อาจจำเป็นต้องปรับใช้ pod บนทุกโหนดในคลัสเตอร์ โดยปรับขนาดจำนวน pod ทั้งหมดเมื่อมีการเพิ่มโหนด และทำการเก็บกวาดขยะเมื่อมีการลบออก ซึ่งเป็นประโยชน์อย่างยิ่งสำหรับกรณีการใช้งานที่เวิร์กโหลดมีความขึ้นอยู่กับโหนดหรือเครื่องโฮสต์จริง เช่น การรวบรวมบันทึก ตัวควบคุมการเข้าถึง และบริการจัดเก็บข้อมูล

บริการ

บริการ Kubernetes คือชุดของพอดที่ทำงานร่วมกัน เช่น ชั้นหนึ่งของ แอปพลิเคชัน แบบหลายชั้นชุดของพอดที่ประกอบเป็นบริการจะถูกกำหนดโดยตัวเลือกป้ายกำกับ^{[ 29 ]} Kubernetes มีโหมดการค้นหาบริการ สองโหมด คือ การใช้ตัวแปรสภาพแวดล้อมหรือการใช้ Kubernetes DNS ^{[ 57 ]}การค้นหาบริการจะกำหนดที่อยู่ IP และชื่อ DNS ที่เสถียร ให้กับบริการ และกระจายโหลดการรับส่งข้อมูลแบบวนรอบ ไป ยังการเชื่อมต่อเครือข่ายของที่อยู่ IP นั้นในหมู่พอดที่ตรงกับตัวเลือก (แม้ว่าความล้มเหลวจะทำให้พอดต้องย้ายจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่ง) ^{[ 53 ]}โดยค่าเริ่มต้น บริการจะถูกเปิดเผยภายในคลัสเตอร์ (เช่นพอดแบ็กเอนด์อาจถูกจัดกลุ่มเป็นบริการ โดยมีการกระจายโหลดคำขอจากพอดฟรอนท์เอนด์ระหว่างพอดเหล่านั้น) แต่บริการยังสามารถเปิดเผยภายนอกคลัสเตอร์ได้ (เช่น เพื่อให้ไคลเอนต์เข้าถึงพอดฟรอนท์เอนด์) ^{[ 58 ]}

เล่ม

โดยค่าเริ่มต้น ระบบไฟล์ในคอนเทนเนอร์ Kubernetes ให้พื้นที่จัดเก็บชั่วคราวซึ่งหมายความว่าการรีสตาร์ทคอนเทนเนอร์จะลบระบบไฟล์ทั้งหมด ดังนั้น รูปแบบการจัดเก็บข้อมูลนี้จึงค่อนข้างจำกัด ยกเว้นแอปพลิเคชันที่ไม่ซับซ้อน วอลุ่ม Kubernetes ^{[ 59 ]}ให้พื้นที่จัดเก็บถาวร พื้นที่จัดเก็บนี้ยังสามารถใช้เป็นพื้นที่ดิสก์ที่ใช้ร่วมกันสำหรับคอนเทนเนอร์ภายในพอดได้อีกด้วย วอลุ่มจะถูกติดตั้งในคอนเทนเนอร์ที่จุดติดตั้งเฉพาะที่กำหนดโดยการกำหนดค่าพอด และไม่สามารถติดตั้งบนวอลุ่มอื่นหรือเชื่อมโยงไปยังวอลุ่มอื่นได้ วอลุ่มเดียวกันสามารถติดตั้งได้ที่จุดต่างๆ ในโครงสร้างต้นไม้ของระบบไฟล์โดยคอนเทนเนอร์ต่างๆ

แผนที่การกำหนดค่าและความลับ

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

ข้อมูลจาก ConfigMaps และ Secrets จะพร้อมใช้งานสำหรับทุกอินสแตนซ์ของแอปพลิเคชันที่วัตถุเหล่านี้ถูกผูกไว้ผ่าน Deployment Secret และ/หรือ ConfigMap จะถูกส่งไปยังโหนดก็ต่อเมื่อ Pod บนโหนดนั้นต้องการเท่านั้น ซึ่งจะถูกจัดเก็บไว้ในหน่วยความจำบนโหนดนั้นเท่านั้น เมื่อ Pod ที่ขึ้นอยู่กับ Secret หรือ ConfigMap ถูกลบ สำเนาในหน่วยความจำของ Secret และ ConfigMaps ที่ผูกไว้ทั้งหมดก็จะถูกลบไปด้วยเช่นกัน

ข้อมูลจาก ConfigMap หรือ Secret สามารถเข้าถึงได้โดยพอดด้วยวิธีใดวิธีหนึ่งต่อไปนี้: ^{[ 60 ]}

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

ความแตกต่างที่สำคัญที่สุดระหว่าง Secret และ ConfigMap คือ Secret ได้รับการออกแบบมาโดยเฉพาะเพื่อเก็บข้อมูลที่ปลอดภัยและเป็นความลับ แม้ว่าจะไม่ได้เข้ารหัสเมื่อจัดเก็บตามค่าเริ่มต้น และต้องมีการตั้งค่าเพิ่มเติมเพื่อให้การใช้ Secret ภายในคลัสเตอร์มีความปลอดภัยอย่างเต็มที่^{[ 61 ]} Secret มักใช้เพื่อจัดเก็บข้อมูลที่เป็นความลับหรือละเอียดอ่อน เช่น ใบรับรอง ข้อมูลประจำตัวสำหรับการทำงานกับรีจิสทรีรูปภาพ รหัสผ่าน และคีย์SSH

ป้ายกำกับและตัวเลือก

Kubernetes ช่วยให้ไคลเอ็นต์ (ผู้ใช้หรือส่วนประกอบภายใน) สามารถแนบคีย์ที่เรียกว่าป้ายกำกับไปยังวัตถุ API ใดๆ ในระบบ เช่น พอดและโหนดในทำนองเดียวกัน ตัวเลือกป้ายกำกับคือการสอบถามป้ายกำกับที่แก้ไขไปยังวัตถุที่ตรงกัน^{[ 29 ]}เมื่อมีการกำหนดบริการ เราสามารถกำหนดตัวเลือกป้ายกำกับที่จะใช้โดยเราเตอร์บริการ/ตัวกระจายโหลดเพื่อเลือกอินสแตนซ์พอดที่จะส่งทราฟฟิกไป ดังนั้น การเปลี่ยนป้ายกำกับของพอดหรือการเปลี่ยนตัวเลือกป้ายกำกับบนบริการสามารถใช้เพื่อควบคุมว่าพอดใดได้รับทราฟฟิกและพอดใดไม่ได้รับ ซึ่งสามารถใช้เพื่อรองรับรูปแบบการปรับใช้ต่างๆ เช่นการปรับใช้แบบ blue-greenหรือการทดสอบ A/Bความสามารถในการควบคุมแบบไดนามิกว่าบริการใช้ทรัพยากรที่ใช้งานอย่างไรนั้นทำให้เกิดการเชื่อมต่อแบบหลวมๆ ภายในโครงสร้างพื้นฐาน

ตัวอย่างเช่น หากพอดของแอปพลิเคชันมีป้ายกำกับสำหรับระบบtier(เช่นfrontend, backend, เป็นต้น) และrelease_track(เช่นcanary, production, เป็นต้น) การดำเนินการกับโหนดทั้งหมดของbackendและcanaryสามารถใช้ตัวเลือกป้ายกำกับได้ เช่น: ^{[ 41 ]}

tier=backend AND release_track=canary

เช่นเดียวกับป้ายกำกับ ตัวเลือกฟิลด์ก็ช่วยให้เราเลือกทรัพยากร Kubernetes ได้เช่นกัน แต่ต่างจากป้ายกำกับตรงที่ การเลือกจะขึ้นอยู่กับค่าแอตทริบิวต์ที่มีอยู่ในทรัพยากรที่เลือก ไม่ใช่การจัดหมวดหมู่ที่ผู้ใช้กำหนดเองmetadata.nameและmetadata.namespaceเป็นตัวเลือกฟิลด์ที่จะมีอยู่ในวัตถุ Kubernetes ทุกประเภท ตัวเลือกอื่นๆ ที่สามารถใช้ได้นั้นขึ้นอยู่กับประเภทของวัตถุ/ทรัพยากร

ส่วนเสริม

ส่วนเสริม (Add-ons) คือฟีเจอร์เพิ่มเติมของคลัสเตอร์ Kubernetes ที่ถูกนำมาใช้ในรูปแบบของแอปพลิเคชันที่ทำงานอยู่ภายในคลัสเตอร์นั้น พอด (Pods) อาจได้รับการจัดการโดย Deployments, ReplicationControllers และอื่นๆ มีส่วนเสริมมากมาย บางส่วนที่สำคัญ ได้แก่:

เอ็นเอสดี: Cluster DNS เป็นเซิร์ฟเวอร์ DNS ตัวหนึ่ง นอกเหนือจากเซิร์ฟเวอร์ DNS อื่นๆ ในสภาพแวดล้อม ซึ่งทำหน้าที่ให้บริการระเบียน DNS สำหรับบริการของ Kubernetes คอนเทนเนอร์ที่เริ่มต้นโดย Kubernetes จะรวมเซิร์ฟเวอร์ DNS นี้ในการค้นหา DNS โดยอัตโนมัติ
ส่วนติดต่อผู้ใช้บนเว็บ: นี่คือ UI บนเว็บที่ใช้งานได้ทั่วไปสำหรับคลัสเตอร์ Kubernetes ช่วยให้ผู้ดูแลระบบสามารถจัดการและแก้ไขปัญหาแอปพลิเคชันที่ทำงานอยู่ในคลัสเตอร์ รวมถึงตัวคลัสเตอร์เองได้ด้วย
การตรวจสอบทรัพยากร: ระบบตรวจสอบทรัพยากรคอนเทนเนอร์จะบันทึกข้อมูลเมตริกเกี่ยวกับคอนเทนเนอร์ลงในฐานข้อมูลส่วนกลาง และมีส่วนติดต่อผู้ใช้สำหรับเรียกดูข้อมูลเหล่านั้น
การตรวจสอบต้นทุน: แอปพลิเคชันตรวจสอบต้นทุนของ Kubernetes ช่วยให้สามารถแยกย่อยต้นทุนตาม Pods, Nodes, Namespaces และ Labels ได้
การบันทึกข้อมูลระดับคลัสเตอร์: เพื่อป้องกันการสูญหายของข้อมูลเหตุการณ์ในกรณีที่โหนดหรือพ็อดล้มเหลว สามารถบันทึกบันทึกของคอนเทนเนอร์ไปยังที่เก็บข้อมูลบันทึกส่วนกลางที่มีอินเทอร์เฟซสำหรับการค้นหา/เรียกดูได้ Kubernetes ไม่มีที่เก็บข้อมูลบันทึกโดยตรง แต่สามารถผสานรวมโซลูชันการบันทึกที่มีอยู่มากมายเข้ากับคลัสเตอร์ Kubernetes ได้

พื้นที่จัดเก็บ

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

ในอดีต Kubernetes เหมาะสำหรับบริการแบบไร้สถานะ (stateless services) เท่านั้น อย่างไรก็ตาม แอปพลิเคชันจำนวนมากมีฐานข้อมูล ซึ่งต้องการการจัดเก็บข้อมูลแบบถาวร ทำให้เกิดการสร้างพื้นที่จัดเก็บข้อมูลแบบถาวรสำหรับ Kubernetes การนำพื้นที่จัดเก็บข้อมูลแบบถาวรมาใช้กับคอนเทนเนอร์เป็นหนึ่งในความท้าทายที่สำคัญที่สุดของผู้ดูแลระบบ Kubernetes, DevOps และวิศวกรคลาวด์ คอนเทนเนอร์อาจมีอายุสั้น แต่ข้อมูลภายในคอนเทนเนอร์นั้นไม่ใช่ ดังนั้นจึงจำเป็นต้องมั่นใจว่าข้อมูลจะยังคงอยู่แม้ในกรณีที่คอนเทนเนอร์หยุดทำงานหรือฮาร์ดแวร์ล้มเหลว เมื่อใช้งานคอนเทนเนอร์กับ Kubernetes หรือแอปพลิเคชันแบบคอนเทนเนอร์ องค์กรต่างๆ มักตระหนักว่าพวกเขาต้องการพื้นที่จัดเก็บข้อมูลแบบถาวร พวกเขาต้องการพื้นที่จัดเก็บข้อมูลที่รวดเร็วและเชื่อถือได้สำหรับฐานข้อมูล รูปภาพรูท และข้อมูลอื่นๆ ที่คอนเทนเนอร์ใช้งาน

นอกจากภูมิทัศน์แล้ว Cloud Native Computing Foundation (CNCF) ยังได้เผยแพร่ข้อมูลอื่นๆ เกี่ยวกับ Kubernetes Persistent Storage รวมถึงบล็อกที่ช่วยกำหนดรูปแบบการจัดเก็บข้อมูลที่แนบกับคอนเทนเนอร์ รูปแบบนี้สามารถคิดได้ว่าเป็นรูปแบบที่ใช้ Kubernetes เองเป็นส่วนประกอบของระบบหรือบริการจัดเก็บข้อมูล^{[ 62 ]}

ข้อมูลเพิ่มเติมเกี่ยวกับความนิยมสัมพัทธ์ของแนวทางเหล่านี้และแนวทางอื่นๆ สามารถพบได้ในแบบสำรวจภูมิทัศน์ของ CNCF เช่นกัน ซึ่งแสดงให้เห็นว่า OpenEBS ซึ่งเป็นแพลตฟอร์ม Stateful Persistent Storage จาก Datacore Software ^{[ 63 ]}และ Rook ซึ่ง เป็น โครงการจัดการพื้นที่จัดเก็บข้อมูลเป็นสองโครงการที่มีแนวโน้มมากที่สุดที่จะอยู่ในระหว่างการประเมินในช่วงฤดูใบไม้ร่วงปี 2019 ^{[ 64 ]}

Container Attached Storage เป็นรูปแบบการจัดเก็บข้อมูลประเภทหนึ่งที่เกิดขึ้นเมื่อ Kubernetes ได้รับความนิยมมากขึ้น แนวทางหรือรูปแบบของ Container Attached Storage อาศัย Kubernetes เองสำหรับความสามารถบางอย่าง ในขณะที่ส่งมอบบล็อก ไฟล์ อ็อบเจ็กต์ และอินเทอร์เฟซเป็นหลักให้กับเวิร์กโหลดที่ทำงานบน Kubernetes ^{[ 65 ]}

คุณลักษณะทั่วไปของ Container Attached Storage ได้แก่ การใช้ส่วนขยายของ Kubernetes เช่น คำจำกัดความทรัพยากรแบบกำหนดเอง และการใช้ Kubernetes เองสำหรับฟังก์ชันที่โดยปกติแล้วจะต้องพัฒนาและใช้งานแยกต่างหากสำหรับการจัดเก็บหรือการจัดการข้อมูล ตัวอย่างของฟังก์ชันที่ส่งมอบโดยคำจำกัดความทรัพยากรแบบกำหนดเองหรือโดย Kubernetes เอง ได้แก่ ตรรกะการลองใหม่ ซึ่งส่งมอบโดย Kubernetes เอง และการสร้างและการบำรุงรักษาบัญชีรายการสื่อจัดเก็บข้อมูลและวอลุ่มที่มีอยู่ ซึ่งโดยทั่วไปจะส่งมอบผ่านคำจำกัดความทรัพยากรแบบกำหนดเอง^{[ 66 ]}^{[ 67 ]}

อินเทอร์เฟซจัดเก็บข้อมูลคอนเทนเนอร์ (CSI)

ใน Kubernetes เวอร์ชัน 1.9 ได้มีการเปิดตัวเวอร์ชัน Alpha แรกของ Container Storage Interface (CSI) ^{[ 68 ]}ก่อนหน้านี้ ปลั๊กอินวอลุ่มจัดเก็บข้อมูลถูกรวมอยู่ในชุดการแจกจ่าย Kubernetes การสร้าง CSI ที่เป็นมาตรฐานทำให้โค้ดที่จำเป็นในการเชื่อมต่อกับระบบจัดเก็บข้อมูลภายนอกถูกแยกออกจากฐานโค้ดหลักของ Kubernetes เพียงหนึ่งปีต่อมา คุณสมบัติ CSI ก็เปิดให้ใช้งานทั่วไป (GA) ใน Kubernetes ^{[ 69 ]}

API

ส่วนประกอบสำคัญของระนาบควบคุม Kubernetes คือ API Server ซึ่งเปิดเผย HTTP API ที่สามารถเรียกใช้งานได้โดยส่วนอื่นๆ ของคลัสเตอร์ รวมถึงผู้ใช้ปลายทางและส่วนประกอบภายนอก API นี้เป็นREST API และมีลักษณะเป็นแบบประกาศ และเป็น API เดียวกันกับที่เปิดเผยให้กับระนาบควบคุม^{[ 70 ]} API Server ได้รับการสนับสนุนโดย etcd เพื่อจัดเก็บบันทึกทั้งหมดอย่างถาวร^{[ 71 ]}

วัตถุ API

ใน Kubernetes วัตถุทั้งหมดทำหน้าที่เป็น " บันทึกเจตนา " ของสถานะของคลัสเตอร์ และสามารถกำหนดสถานะที่ต้องการที่ผู้เขียนวัตถุต้องการให้คลัสเตอร์เป็นได้^{[ 72 ]}ด้วยเหตุนี้ วัตถุ Kubernetes ส่วนใหญ่จึงมีชุดฟิลด์ซ้อนกันชุดเดียวกัน ดังต่อไปนี้:

spec: อธิบายสถานะที่ต้องการของทรัพยากร ซึ่งสามารถควบคุมได้โดยผู้ใช้ปลายทาง หรือผู้ควบคุมระดับสูงกว่า
status: อธิบายสถานะปัจจุบันของทรัพยากร ซึ่งได้รับการอัปเดตอย่างต่อเนื่องโดยผู้ควบคุมทรัพยากร

วัตถุทั้งหมดใน Kubernetes อยู่ภายใต้ข้อกำหนด API เดียวกัน ข้อกำหนดบางส่วนได้แก่:

ต้องมีเมตาเดตาต่อไปนี้ภายใต้ฟิลด์ออบเจ็กต์ที่ซ้อนกันmetadata: ^{[ 73 ]}
- namespace: ป้ายกำกับที่ใช้แบ่งย่อยวัตถุต่างๆ
- name: สตริงที่ใช้ระบุวัตถุภายในเนมสเปซที่กำหนดไว้อย่างเฉพาะเจาะจง
- uid: สตริงที่ใช้ระบุวัตถุ API ใดๆ ในคลัสเตอร์ได้อย่างเฉพาะเจาะจง โดยไม่คำนึงถึงประเภท ชื่อ เนมสเปซ และเวลา กล่าวคือ แม้กระทั่งการลบและการสร้างใหม่ที่มีประเภท ชื่อ และเนมสเปซเดียวกันก็ตาม
อาจได้รับการจัดการโดยตัวควบคุมอื่นซึ่งกำหนดไว้ในmetadata.ownerReferencesฟิลด์: ^{[ 74 ]}
- จะต้องมีวัตถุอื่นอย่างน้อยหนึ่งชิ้นเป็นตัวควบคุมหลักของวัตถุที่ถูกควบคุม ซึ่งถูกกำหนดโดยcontrollerฟิลด์ดังกล่าว
อาจมีการเก็บขยะหากเจ้าของถูกลบ: ^{[ 75 ]}
- เมื่อมีการลบวัตถุหนึ่ง วัตถุที่เกี่ยวข้องทั้งหมดอาจถูกลบไปด้วยในลักษณะต่อเนื่อง

ทรัพยากร ตัวควบคุม และตัวดำเนินการที่กำหนดเอง

Kubernetes API สามารถขยายได้โดยใช้Custom Resourcesซึ่งเป็นตัวแทนของวัตถุที่ไม่ได้เป็นส่วนหนึ่งของการติดตั้ง Kubernetes มาตรฐาน Custom Resources เหล่านี้จะถูกประกาศโดยใช้Custom Resource Definitions (CRDs) ซึ่งเป็นทรัพยากรประเภทหนึ่งที่สามารถลงทะเบียนและยกเลิกการลงทะเบียนได้แบบไดนามิกโดยไม่ต้องปิดหรือรีสตาร์ทคลัสเตอร์ที่กำลังทำงานอยู่^{[ 76 ]}

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

การรวมกันของทรัพยากรที่กำหนดเองและตัวควบคุมที่กำหนดเองมักเรียกว่าKubernetes Operator ^{[ 77 ]} กรณีการใช้งานหลักของโอเป อเรเตอร์คือการจับภาพเป้าหมายของโอเปอเรเตอร์ที่เป็นมนุษย์ซึ่งกำลังจัดการบริการหรือชุดของบริการ และนำไปใช้โดยใช้ระบบอัตโนมัติ และด้วย API แบบประกาศที่สนับสนุนระบบอัตโนมัตินี้ โอเปอเรเตอร์ที่เป็นมนุษย์ซึ่งดูแลแอปพลิเคชันและบริการเฉพาะมีความรู้เชิงลึกเกี่ยวกับวิธีการทำงานของระบบ วิธีการปรับใช้ และวิธีการตอบสนองหากมีปัญหา

ตัวอย่างของปัญหาที่ผู้ปฏิบัติงานแก้ไข ได้แก่ การสำรองข้อมูลและกู้คืนสถานะของแอปพลิเคชัน และการจัดการการอัปเกรดโค้ดแอปพลิเคชันพร้อมกับการเปลี่ยนแปลงที่เกี่ยวข้อง เช่น แผนผังฐานข้อมูลหรือการตั้งค่าการกำหนดค่าเพิ่มเติม โครงการที่โดดเด่นหลายโครงการภายใต้โปรแกรมบ่มเพาะของ Cloud Native Computing Foundation ใช้รูปแบบผู้ปฏิบัติงานเพื่อขยาย Kubernetes รวมถึง Argo, Open Policy Agent และ Istio ^{[ 78 ]}

ความปลอดภัยของ API

Kubernetes กำหนดกลยุทธ์ต่อไปนี้สำหรับการควบคุมการเข้าถึง API ของตน^{[ 79 ]}

ความปลอดภัยในการขนส่ง

เซิร์ฟเวอร์ API ของ Kubernetes รับฟังบนพอร์ต TCPที่ให้บริการ ทราฟฟิก HTTPSเพื่อบังคับใช้ความปลอดภัยของเลเยอร์การขนส่ง (TLS)โดยใช้ใบรับรอง CA ^{[ 32 ]}

ใน Kubernetes เวอร์ชันเก่า เซิร์ฟเวอร์ API รองรับการรับฟังทั้งพอร์ต HTTP และ HTTPS (โดยหมายเลขพอร์ต HTTP ไม่มีการรักษาความปลอดภัยการขนส่งใดๆ) ฟังก์ชันนี้ถูกยกเลิกในเวอร์ชัน 1.10 และในที่สุดก็ถูกยกเลิกการสนับสนุนในเวอร์ชัน 1.20 ของ Kubernetes ^{[ 80 ]}

การตรวจสอบสิทธิ์

คำขอทั้งหมดที่ส่งไปยังเซิร์ฟเวอร์ API ของ Kubernetes คาดว่าจะต้องได้รับการตรวจสอบสิทธิ์ และรองรับกลยุทธ์การตรวจสอบสิทธิ์หลายแบบ ซึ่งบางส่วนแสดงไว้ด้านล่าง: ^{[ 81 ]}

ใบรับรองไคลเอ็นต์X.509
โทเค็นผู้ถือ
โทเค็นบัญชีบริการ สำหรับการเข้าถึง API แบบโปรแกรม

โดยทั่วไป ผู้ใช้จะต้องระบุและกำหนดรายละเอียด URL ของคลัสเตอร์พร้อมกับข้อมูลประจำตัวที่จำเป็นใน ไฟล์ kubeconfigซึ่งได้รับการสนับสนุนโดยเครื่องมือ Kubernetes อื่นๆ เช่น kubectl และไลบรารีไคลเอ็นต์ Kubernetes อย่างเป็นทางการ^{[ 82 ]}

การอนุญาต

API ของ Kubernetes รองรับโหมดการอนุญาตดังต่อไปนี้: ^{[ 83 ]}

โหมดการอนุญาตโหนด : กำหนดรายการการดำเนินการของคำขอ API ที่ kubelets ได้รับอนุญาตให้ดำเนินการเพื่อให้ทำงานได้อย่างถูกต้อง
โหมดการควบคุมการเข้าถึงตามคุณลักษณะ (ABAC) : มอบสิทธิ์การเข้าถึงให้กับผู้ใช้โดยใช้แนวนโยบายการควบคุมการเข้าถึงที่กำหนดไว้ ซึ่งเป็นการรวมคุณลักษณะต่างๆ เข้าด้วยกัน
โหมดควบคุมการเข้าถึงตามบทบาท (RBAC) : มอบสิทธิ์การเข้าถึงให้กับผู้ใช้ตามบทบาทที่กำหนด โดยแต่ละบทบาทจะกำหนดรายการการกระทำที่ได้รับอนุญาต
โหมด Webhook : สอบถามบริการ REST API เพื่อตรวจสอบว่าผู้ใช้ได้รับอนุญาตให้ดำเนินการตามที่กำหนดหรือไม่^{[ 32 ]}

ไคลเอ็นต์ API

Kubernetes รองรับไคลเอ็นต์ API อย่างเป็นทางการหลายตัว:

kubectl: บรรทัดคำสั่งสำหรับการโต้ตอบกับระนาบควบคุมของ Kubernetes ^{[ 84 ]}
ไลบรารีไคลเอ็นต์อย่างเป็นทางการที่ดูแลโดย Kubernetes สำหรับC , .NET , Go , Haskell , Java , JavaScript , Perl , PythonและRuby ^{[ 85 ]}

API คลัสเตอร์

หลักการออกแบบ API เดียวกันนี้ถูกนำมาใช้เพื่อกำหนด API สำหรับควบคุมโปรแกรมเพื่อสร้าง กำหนดค่า และจัดการคลัสเตอร์ Kubernetes ซึ่งเรียกว่า Cluster API ^{[ 86 ]}แนวคิดหลักที่ฝังอยู่ใน API คือการใช้โครงสร้างพื้นฐานเป็นซอฟต์แวร์หรือแนวคิดที่ว่าโครงสร้างพื้นฐานของคลัสเตอร์ Kubernetes นั้นเป็นทรัพยากร/วัตถุที่สามารถจัดการได้เช่นเดียวกับทรัพยากร Kubernetes อื่นๆ ในทำนองเดียวกัน เครื่องจักรที่ประกอบขึ้นเป็นคลัสเตอร์ก็ได้รับการปฏิบัติเสมือนเป็นทรัพยากร Kubernetes เช่นกัน API ประกอบด้วยสองส่วนคือ API หลัก และการใช้งานของผู้ให้บริการ การใช้งานของผู้ให้บริการประกอบด้วยฟังก์ชันเฉพาะของผู้ให้บริการคลาวด์ที่ช่วยให้ Kubernetes สามารถให้บริการ Cluster API ในลักษณะที่ผสานรวมเข้ากับบริการและทรัพยากรของผู้ให้บริการคลาวด์ได้เป็นอย่างดี^{[ 32 ]}

การใช้งาน

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

การวิจารณ์

ข้อวิจารณ์ทั่วไปของ Kubernetes คือมันซับซ้อนเกินไป Google ก็ยอมรับเรื่องนี้เช่นกัน^{[ 87 ]}

การแจกจ่าย

ผู้จำหน่ายหลายรายนำเสนอแพลตฟอร์มที่ใช้ Kubernetes หรือโครงสร้างพื้นฐานในรูปแบบบริการ (IaaS) ที่ใช้งาน Kubernetes ^{[ 88 ]}^{[ 89 ]}

โดยทั่วไปแล้วจะมีการจำแนกประเภทตามการแจกจ่ายแบบโอเพนซอร์ส เชิงพาณิชย์ หรือแบบจัดการ การแจกจ่ายที่น่าสนใจหลายรายการมีดังต่อไปนี้: ^{[ 90 ]}

การแจกจ่ายแบบโอเพนซอร์ส

อเมซอนอีเคเอสดี
k0s
เค3ส
เครื่องยนต์SUSE Rancher Kubernetes (RKE)
OKD.IO คือชุดซอฟต์แวร์ Kubernetes สำหรับชุมชนผู้ใช้งาน ซึ่งเป็นส่วนสำคัญของ Red Hat OpenShift

การจัดจำหน่ายเชิงพาณิชย์

แพลตฟอร์ม Nutanix Kubernetes (เดิมคือแพลตฟอร์ม D2iQ Kubernetes) ^{[ 91 ]}
Mirantis Kubernetes Engine (เดิมชื่อDocker Enterprise)
เรดแฮท โอเพ่นชิฟต์
VMware VKS (vSphere Kubernetes Service)
SUSE Rancher Prime ซึ่งรวมถึง Kubernetes รุ่น k3 และ RKE2

การแจกจ่ายแบบจัดการ

Alibaba Cloud ACK (Alibaba Cloud Container Service for Kubernetes)
Amazon EKS (Elastic Kubernetes Service)
Canonical MicroK8s และ Charmed Kubernetes
บริการ Kubernetes ที่จัดการโดยDigitalOcean
Google GKE (Google Kubernetes Engine)
Huawei CCE (Huawei Cloud Container Engine)
บริการ IBM Cloud Kubernetes
Microsoft AKS (Azure Kubernetes Services)
Mirantis Kubernetes Engine พร้อมบริการจัดการ OpsCare Plus
Oracle Container Engine สำหรับ Kubernetes
วินด์ ริเวอร์ ซิสเต็มส์วินด์ ริเวอร์ สตูดิโอ

กำหนดการวางจำหน่าย

กำหนดการวางจำหน่าย
เวอร์ชั่น	วันที่วางจำหน่าย	วันที่สิ้นสุดอายุการใช้งาน^{[ 92 ]}	หมายเหตุ
ไม่รองรับ: 1.0	10 กรกฎาคม 2558		วางจำหน่ายครั้งแรก
ไม่รองรับ: 1.1	9 พฤศจิกายน 2558		^{[ 93 ]}
ไม่รองรับ: 1.2	16 มีนาคม 2559	23 ตุลาคม 2559	^{[ 94 ]}
ไม่รองรับ: 1.3	1 กรกฎาคม 2559	1 พฤศจิกายน 2559	^{[ 95 ]}
ไม่รองรับ: 1.4	26 กันยายน 2559	21 เมษายน 2560	^{[ 96 ]}
ไม่รองรับ: 1.5	12 ธันวาคม 2559	1 ตุลาคม 2560	^{[ 97 ]}
ไม่รองรับ: 1.6	28 มีนาคม 2560	23 พฤศจิกายน 2560	^{[ 98 ]}
ไม่รองรับ: 1.7	30 มิถุนายน 2560	4 เมษายน 2561	^{[ 99 ]}
ไม่รองรับ: 1.8	28 สิงหาคม 2560	12 กรกฎาคม 2561	^{[ 100 ]}
ไม่รองรับ: 1.9	15 ธันวาคม 2560	29 กันยายน 2561	^{[ 101 ]}
ไม่รองรับ: 1.10	28 มีนาคม 2561	13 กุมภาพันธ์ 2562	^{[ 102 ]}
ไม่รองรับ: 1.11	3 กรกฎาคม 2561	1 พฤษภาคม 2562	^{[ 103 ]}
ไม่รองรับ: 1.12	27 กันยายน 2561	8 กรกฎาคม 2562	^{[ 104 ]}
ไม่รองรับ: 1.13	3 ธันวาคม 2561	15 ตุลาคม 2562	^{[ 105 ]}
ไม่รองรับ: 1.14	25 มีนาคม 2562	11 ธันวาคม 2562	^{[ 106 ]}
ไม่รองรับ: 1.15	20 มิถุนายน 2562	6 พฤษภาคม 2563	^{[ 107 ]}
ไม่รองรับ: 1.16	22 ตุลาคม 2562	2 กันยายน 2020	^{[ 108 ]}
ไม่รองรับ: 1.17	9 ธันวาคม 2019	13 มกราคม 2564	^{[ 109 ]}
ไม่รองรับ: 1.18	25 มีนาคม 2563	18 มิถุนายน 2564	^{[ 110 ]}
ไม่รองรับ: 1.19	26 สิงหาคม 2563 ^{[ 111 ]}	28 ตุลาคม 2564	ตั้งแต่ Kubernetes เวอร์ชัน 1.19 เป็นต้นไป ระยะเวลาการสนับสนุนได้ขยายออกไปเป็นหนึ่งปีสำหรับการสนับสนุนเต็มรูปแบบ บวกกับระยะเวลาโหมดการบำรุงรักษาอีกสองเดือน^{[ 27 ]}^{[ 112 ]}
ไม่รองรับ: 1.20	8 ธันวาคม 2020	28 กุมภาพันธ์ 2565	^{[ 113 ]}
ไม่รองรับ: 1.21	8 เมษายน 2564	28 มิถุนายน 2565	^{[ 114 ]}
ไม่รองรับ: 1.22	4 สิงหาคม 2564	28 ตุลาคม 2565	^{[ 115 ]}
ไม่รองรับ: 1.23	7 ธันวาคม 2021	28 กุมภาพันธ์ 2566	^{[ 116 ]}
ไม่รองรับ: 1.24	3 พฤษภาคม 2565	28 กรกฎาคม 2566	^{[ 117 ]}
ไม่รองรับ: 1.25	23 สิงหาคม 2565	27 ตุลาคม 2566	^{[ 118 ]}
ไม่รองรับ: 1.26	9 ธันวาคม 2022	24 กุมภาพันธ์ 2567	^{[ 119 ]}
ไม่รองรับ: 1.27	11 เมษายน 2566	28 มิถุนายน 2567	^{[ 120 ]}
ไม่รองรับ: 1.28	15 สิงหาคม 2566	28 ตุลาคม 2567	^{[ 121 ]}
ไม่รองรับ: 1.29	13 ธันวาคม 2023	28 กุมภาพันธ์ 2568	^{[ 122 ]}
ไม่รองรับ: 1.30	17 เมษายน 2567	28 มิถุนายน 2568	^{[ 123 ]}
ไม่รองรับ: 1.31	13 สิงหาคม 2567	28 ตุลาคม 2568	^{[ 124 ]}
ไม่รองรับ: 1.32	11 ธันวาคม 2024	28 กุมภาพันธ์ 2569	^{[ 125 ]}
ไม่รองรับ: 1.33	23 เมษายน 2568	28 มิถุนายน 2569	^{[ 126 ]}
รองรับ: 1.34	27 สิงหาคม 2568	27 ตุลาคม 2569	^{[ 127 ]}
รองรับ: 1.35	17 ธันวาคม 2025	28 กุมภาพันธ์ 2560	^{[ 128 ]}
เวอร์ชันล่าสุด: 1.36	22 เมษายน 2569	28 มิถุนายน 2560	^{[ 129 ]}
ตำนาน: ไม่ได้รับการสนับสนุน ได้รับการสนับสนุน เวอร์ชั่นล่าสุด เวอร์ชันตัวอย่าง เวอร์ชันในอนาคต

รองรับ Windows

แผนภูมิด้านล่างแสดงภาพระยะเวลาที่แต่ละเวอร์ชันได้รับการสนับสนุน^{[ 92 ]}

ดูเพิ่มเติม

ลิงก์ภายนอก

เว็บไซต์อย่างเป็นทางการ
Kubernetes บนGitHub

[

[

6 ] ความ

[ 7 ]

[ 8 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]

[ 25 ]

[ 26 ]

[ 27 ]

[ 28 ]

[ 29 ]

[ 30 ]

[ 33 ]

[ 35 ]

[ 37 ]

[ 38 ]

[ 39 ]

[ 40 ]

[ 41 ]

[ 42 ]

[ 43 ]

[ 45 ]

[ 46 ]

[ 47 ]

[ 48 ]

[ 49 ]

[ 50 ]

[ 51 ]

[ 52 ]

[ 53 ]

[ 55 ]

[ 56 ]

[ 57 ]

[ 58 ]

[ 59 ]

[ 60 ]

[ 61 ]

[ 62 ]

[ 63 ]

[ 64 ]

[ 65 ]

[ 66 ]

[ 67 ]

[ 68 ]

[ 69 ]

[ 70 ]

[ 71 ]

[ 72 ]

[ 73 ]

[ 74 ]

[ 75 ]

[ 76 ]

[ 77 ]

[ 78 ]

[ 79 ]

[ 80 ]

[ 81 ]

[ 82 ]

[ 83 ]

[ 84 ]

[ 85 ]

[ 86 ]

[ 87 ]

[ 88 ]

[ 89 ]

[ 90 ]

[ 91 ]

[ 92 ]

[ 93 ]

[ 94 ]

[ 95 ]

[ 96 ]

[ 97 ]

[ 98 ]

[ 99 ]

[ 100 ]

[ 101 ]

[ 102 ]

[ 103 ]

[ 104 ]

[ 105 ]

[ 106 ]

[ 107 ]

[ 108 ]

[ 109 ]

[ 110 ]