Kubernetes v1.33: Octarine release updates
มี update สำคัญอะไรบ้างใน Kubernetes v1.33
Kubernetes v1.33 มาพร้อมฟีเจอร์ใหม่และการปรับปรุงมากมาย มาดูกันว่าทีม Release Team เลือกเน้นอะไรบ้าง!
Stable: Sidecar containers
Sidecar pattern คือการ deploy container เสริมเข้าไปใน Pod เพื่อช่วยเสริมความสามารถ เช่น networking, logging หรือการเก็บ metrics
ใน Kubernetes v1.33, Sidecar containers ได้เข้าสู่สถานะ Stable
ใน Kubernetes, sidecar ถูก implement เป็น init container ประเภทพิเศษที่มี restartPolicy: Always ทำให้ sidecar:
- เริ่มทำงานก่อน application containers
- รันอยู่ตลอดช่วงชีวิตของ Pod
- ปิดตัวเองอัตโนมัติหลังจาก main container ออกจากระบบ
sidecar ยังสามารถใช้ probes (startup, readiness, liveness) เพื่อรายงานสถานะการทำงานได้ และมีการปรับค่า Out-Of-Memory (OOM) score ให้สอดคล้องกับ container หลักเพื่อป้องกันไม่ให้ sidecar ถูก kill ก่อนกำหนดภายใต้สถานการณ์หน่วยความจำตึงตัว
Beta: In-place resource resize for vertical scaling of Pods
Workloads สามารถกำหนดได้ผ่าน API อย่างเช่น Deployment, StatefulSet เป็นต้น โดย API เหล่านี้จะอธิบาย template สำหรับ Pods ที่ควรจะรัน รวมถึงกำหนด resource เช่น memory และ CPU และจำนวน replica ของ Pods ที่ควรรัน
Workloads สามารถทำการ horizontal scaling ได้โดยการอัปเดตจำนวน Pod replicas หรือทำ vertical scaling โดยการอัปเดต resource ที่ต้องการใน container(s) ของ Pods
ก่อนที่จะมีการปรับปรุงครั้งนี้ resource ของ container ที่กำหนดไว้ใน spec ของ Pod จะเป็นแบบ immutable (ไม่สามารถเปลี่ยนแปลงได้) และการอัปเดตรายละเอียดใด ๆ ใน Pod template จะทำให้ต้องสร้าง Pod replacement ขึ้นใหม่เสมอ
แต่ถ้าเราสามารถอัปเดต resource configuration ของ Pods ที่มีอยู่แล้วได้แบบ dynamic โดยไม่ต้อง restart ล่ะ?
นี่คือเป้าหมายของ KEP-1287 ที่ออกแบบมาเพื่ออนุญาตให้มีการ in-place Pod updates
ฟีเจอร์นี้ถูกปล่อยเป็น alpha ในเวอร์ชัน v1.27 และได้ graduated เป็น beta ใน v1.33
การเปลี่ยนแปลงนี้เปิดโอกาสให้:
- ทำ vertical scale-up ของกระบวนการแบบ stateful โดยไม่มี downtime
- ทำ seamless scale-down เมื่อ traffic ลดลง
- หรือแม้กระทั่งการจัดสรร resource ปริมาณมากในช่วง startup แล้วค่อยลดลงเมื่อ setup เสร็จสมบูรณ์
Alpha: ไฟล์ .kuberc สำหรับกำหนด user preferences ของ kubectl
ในเวอร์ชัน v1.33, kubectl ได้แนะนำฟีเจอร์ใหม่ในระดับ alpha ซึ่งเป็นการตั้งค่าแบบ opt-in ผ่านไฟล์ configuration ชื่อ .kuberc สำหรับกำหนด user preferences
ไฟล์นี้สามารถเก็บ:
- kubectl aliases และ
- overrides (เช่น ตั้งค่าให้ใช้ server-side apply เป็นค่า default)
ในขณะที่ข้อมูลเกี่ยวกับ cluster credentials และ host information ยังคงอยู่ในไฟล์ kubeconfig
การแยกไฟล์ลักษณะนี้ ช่วยให้สามารถแชร์ user preferences เดียวกันสำหรับการใช้งาน kubectl ได้ ไม่ว่าจะเชื่อมต่อไปยัง cluster ไหน หรือใช้ kubeconfig อันไหนก็ตาม
ในการเปิดใช้งานฟีเจอร์ alpha นี้:
- ผู้ใช้ต้องตั้งค่า environment variable เป็น
KUBECTL_KUBERC=true - และสร้างไฟล์ configuration ชื่อ .kuberc
โดยค่าเริ่มต้น:
- kubectl จะมองหาไฟล์ .kuberc ที่ตำแหน่ง
~/.kube/kuberc
หรือหากต้องการระบุ path อื่น:
- สามารถใช้ —kuberc flag ได้ เช่น:
kubectl --kuberc /var/kube/rcฟีเจอร์ที่เข้าสู่สถานะ Stable ใน Kubernetes v1.33
Backoff limits per index สำหรับ Indexed Jobs
ใน release นี้ ได้เลื่อนสถานะฟีเจอร์ที่อนุญาตให้สามารถตั้งค่า backoff limits แยกตามแต่ละ index สำหรับ Indexed Jobs ได้
ตามปกติแล้ว backoffLimit parameter ใน Kubernetes Jobs จะกำหนดจำนวนครั้งที่สามารถ retry ได้ก่อนที่จะพิจารณาว่า Job ทั้งงานล้มเหลว
การปรับปรุงครั้งนี้ทำให้แต่ละ index ภายใน Indexed Job สามารถมี backoff limit ของตัวเองได้
ช่วยให้สามารถควบคุมพฤติกรรมการ retry ของแต่ละ task ได้อย่างละเอียดมากขึ้น
สิ่งนี้ทำให้การล้มเหลวของบาง indices จะไม่ทำให้ Job ทั้งหมดถูกยุติเร็วกว่าที่ควร
โดยที่ indices อื่น ๆ ยังสามารถประมวลผลงานของตัวเองต่อไปได้อย่างอิสระ
Job success policy
โดยการใช้ .spec.successPolicy ผู้ใช้สามารถกำหนดได้ว่า:
- pod indexes ใดบ้างที่จำเป็นต้องสำเร็จ (ผ่านการระบุใน
succeededIndexes) - หรือกำหนดจำนวน pods ที่ต้องสำเร็จกี่ตัว (ผ่าน
succeededCount) - หรือจะใช้ทั้งสองอย่างร่วมกันก็ได้
ฟีเจอร์นี้เป็นประโยชน์กับหลายประเภทของ workload เช่น:
- งานประเภท simulation ที่ไม่จำเป็นต้องให้ทุก pod สำเร็จครบถ้วน
- รูปแบบ leader-worker ที่สำคัญแค่เพียง leader สำเร็จก็เพียงพอที่จะตัดสินผลลัพธ์สุดท้ายของ Job
ปรับปรุงความปลอดภัยของ Bound ServiceAccount token
การปรับปรุงครั้งนี้ได้เพิ่มฟีเจอร์ต่าง ๆ เช่น:
- การใส่ unique token identifier (เช่น JWT ID Claim หรือที่รู้จักกันในชื่อ JTI)
- และข้อมูลของ node ไว้ภายใน tokens
ซึ่งช่วยให้สามารถทำ validation และ auditing ได้อย่างแม่นยำยิ่งขึ้น
นอกจากนี้ยังรองรับ:
- การกำหนดข้อจำกัดเฉพาะตาม node
- เพื่อให้แน่ใจว่า tokens สามารถใช้งานได้เฉพาะบน node ที่กำหนดไว้เท่านั้น
ด้วยเหตุนี้จึง:
- ช่วยลดความเสี่ยงของการนำ token ไปใช้งานผิดวัตถุประสงค์
- และลดโอกาสเกิด security breaches ได้
การปรับปรุงทั้งหมดนี้ ขณะนี้ได้เข้าสู่สถานะ Generally Available (GA) แล้ว
โดยมีเป้าหมายเพื่อ:
- เพิ่มความแข็งแกร่งโดยรวมของความปลอดภัยสำหรับ service account tokens ภายใน Kubernetes clusters
Subresource support ใน kubectl
argument --subresource ขณะนี้ได้เข้าสู่สถานะ Generally Available (GA) แล้ว สำหรับ kubectl subcommands เช่น:
getpatcheditapply- และ
replace
โดย argument นี้ช่วยให้ผู้ใช้สามารถ:
- ดึงข้อมูล (fetch) และ
- อัปเดต (update) subresources ของ resource ทุกประเภทที่รองรับการใช้งาน subresources ได้
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ subresources ที่รองรับ
สามารถเข้าไปดูได้ที่ kubectl reference
Multiple Service CIDRs
การปรับปรุงครั้งนี้ได้แนะนำการ implement รูปแบบใหม่ของ allocation logic สำหรับ Service IPs
ภายใน cluster ทั้งหมด:
- ทุก Service ที่มีประเภท
ClusterIPจะต้องมี IP address ที่ไม่ซ้ำกันถูกกำหนดให้
หากพยายามสร้าง Service โดยระบุ cluster IP ที่มีการใช้งานไปแล้ว:
- ระบบจะคืนค่าผิดพลาด (return an error)
IP address allocator logic ที่ปรับปรุงใหม่นี้:
- ใช้ API objects ใหม่สองตัวที่เข้าสู่สถานะ Stable คือ ServiceCIDR และ IPAddress
ตอนนี้ APIs เหล่านี้ได้เข้าสู่สถานะ Generally Available (GA) แล้ว
และช่วยให้ผู้ดูแลระบบ cluster สามารถ:
- เพิ่มจำนวน IP addresses สำหรับ ClusterIP Services ได้แบบ dynamic (โดยการสร้าง ServiceCIDR objects ใหม่)
nftables backend สำหรับ kube-proxy
nftables backend สำหรับ kube-proxy ตอนนี้ได้เข้าสู่สถานะ Stable แล้ว
โดยเพิ่มการ implement รูปแบบใหม่ที่:
- ปรับปรุงประสิทธิภาพ (performance) และ
- เพิ่มความสามารถในการขยายระบบ (scalability)
สำหรับการ implement Services ภายใน Kubernetes clusters
ด้วยเหตุผลด้านความเข้ากันได้ (compatibility reasons):
- iptables ยังคงถูกตั้งให้เป็นค่า default บน Linux nodes
หากต้องการลองใช้งาน nftables backend
สามารถตรวจสอบได้จาก migration guide
Topology aware routing และ trafficDistribution: PreferClose
ใน release นี้ ได้เลื่อนสถานะ topology-aware routing และ traffic distribution ไปสู่สถานะ GA (Generally Available)
ซึ่งช่วยให้สามารถ:
- ปรับแต่งการไหลของ service traffic ใน multi-zone clusters ได้อย่างมีประสิทธิภาพมากขึ้น
topology-aware hints ที่อยู่ใน EndpointSlices จะช่วยให้ component อย่างเช่น kube-proxy:
- สามารถจัดลำดับความสำคัญในการ route traffic ไปยัง endpoints ที่อยู่ใน zone เดียวกัน
- ซึ่งช่วยลด latency และลดค่าใช้จ่ายจากการส่งข้อมูลข้าม zone (cross-zone data transfer costs)
นอกจากนี้:
-
ได้มีการเพิ่ม trafficDistribution field เข้าไปใน Service specification
-
พร้อมตัวเลือก PreferClose option ที่ช่วย:
- ชี้นำ traffic ให้ไปยัง endpoints ที่ใกล้ที่สุดตาม network topology โดยอัตโนมัติ
การตั้งค่านี้ช่วยเพิ่ม:
- ประสิทธิภาพการทำงาน (performance) และ
- ประหยัดค่าใช้จ่าย (cost-efficiency)
โดยการลดการสื่อสารข้าม zone (inter-zone communication) ให้เหลือน้อยที่สุด
Issues:
ตัวเลือกใหม่ใน CPU Manager สำหรับ reject workload ที่ไม่ align กับ SMT
ฟีเจอร์นี้ได้เพิ่มตัวเลือก policy options ให้กับ CPU Manager
ทำให้สามารถ:
- ปฏิเสธ (reject) workloads ที่ไม่สอดคล้องกับการตั้งค่า Simultaneous Multithreading (SMT) ได้
การปรับปรุงครั้งนี้ ซึ่งขณะนี้ได้เข้าสู่สถานะ Generally Available (GA) แล้ว
ช่วยให้:
- เมื่อ pod ร้องขอการใช้งาน CPU cores แบบ exclusive
- CPU Manager สามารถบังคับการจัดสรรทั้งคู่ของ core (core pairs) ได้
- ซึ่ง core pair ประกอบด้วย primary และ sibling threads
- บนระบบที่เปิดใช้งาน SMT-enabled systems
ส่งผลให้สามารถ:
- ป้องกันสถานการณ์ที่ workloads ต้องไปแชร์ CPU resources กันโดยไม่ตั้งใจ
กำหนด Pod affinity และ anti-affinity ด้วย matchLabelKeys และ mismatchLabelKeys
ฟิลด์ matchLabelKeys และ mismatchLabelKeys พร้อมใช้งานแล้วในเงื่อนไขของ Pod affinity
โดยช่วยให้ผู้ใช้สามารถ:
- ควบคุมขอบเขต (scope) ได้อย่างละเอียดว่า Pods ควรจะอยู่ร่วมกัน (Affinity) หรือไม่ควรอยู่ร่วมกัน (AntiAffinity)
ตัวเลือกใหม่ที่เข้าสู่สถานะ Stable เหล่านี้:
- ถูกออกแบบมาเพื่อเสริมกลไกที่มีอยู่แล้วอย่าง labelSelector
ฟิลด์ affinity เหล่านี้ช่วยสนับสนุนการ:
- ปรับปรุงการ schedule อย่างมีประสิทธิภาพสำหรับ versatile rolling updates
- รวมถึงการแยก (isolate) การให้บริการของ services ที่ถูกจัดการโดย tools หรือ controllers ตาม global configurations
พิจารณา taints และ tolerations เมื่อคำนวณ PodTopologySpread
ฟีเจอร์นี้ได้ปรับปรุง PodTopologySpread โดยการเพิ่มสองฟิลด์ใหม่คือ:
nodeAffinityPolicyและnodeTaintsPolicy
ฟิลด์เหล่านี้ช่วยให้ผู้ใช้สามารถ:
- ระบุได้ว่าควรพิจารณา node affinity rules และ node taints หรือไม่
เมื่อทำการคำนวณการกระจายตัวของ pods ข้าม nodes
ตามค่าเริ่มต้น:
-
nodeAffinityPolicyจะถูกตั้งค่าเป็นHonor
หมายความว่า: -
จะคำนวณเฉพาะ nodes ที่ตรงกับ pod’s node affinity หรือ selector เท่านั้น
ส่วน:
-
nodeTaintsPolicyตั้งค่าเริ่มต้นเป็นIgnore
ซึ่งหมายความว่า: -
จะไม่พิจารณา node taints เว้นแต่ผู้ใช้จะระบุให้พิจารณา
การปรับปรุงนี้:
- ช่วยให้สามารถควบคุมตำแหน่งการวาง pods ได้ละเอียดขึ้น
- เพื่อให้แน่ใจว่า pods ถูก schedule ไปยัง nodes ที่ตรงตามทั้งเงื่อนไข affinity และ taint toleration
- และช่วยป้องกันสถานการณ์ที่ pods ต้องค้างอยู่ในสถานะ pending เพราะไม่สามารถหาตำแหน่งที่ตรงตามข้อกำหนดได้
Volume populators
หลังจากที่ถูกปล่อยในสถานะ beta ตั้งแต่เวอร์ชัน v1.24, volume populators ได้ graduated เป็นสถานะ GA (Generally Available) ในเวอร์ชัน v1.33
ฟีเจอร์ที่เพิ่งเข้าสู่สถานะ stable นี้:
- มอบวิธีการให้ผู้ใช้สามารถทำการ pre-populate volumes ด้วยข้อมูลจากแหล่งต่าง ๆ ได้
- ไม่ได้จำกัดแค่ clone จาก PersistentVolumeClaim (PVC) หรือจาก volume snapshots เท่านั้น
กลไกนี้อาศัย:
- ฟิลด์ชื่อ dataSourceRef ภายใน PersistentVolumeClaim
โดยฟิลด์นี้:
- มีความยืดหยุ่นมากกว่าฟิลด์ dataSource แบบที่มีอยู่ก่อนแล้ว
- และเปิดโอกาสให้สามารถใช้ custom resources เป็นแหล่งข้อมูล (data sources) ได้
มี controller พิเศษที่ชื่อว่า:
- volume-data-source-validator
ซึ่งทำหน้าที่:
- ตรวจสอบความถูกต้องของการอ้างอิง data source references
นอกจากนี้ยังมี:
- CustomResourceDefinition (CRD) ตัวใหม่ในสถานะ stable สำหรับ API kind ที่ชื่อว่า VolumePopulator
โดย VolumePopulator API จะอนุญาตให้:
- volume populator controllers ลงทะเบียนประเภทของ data sources ที่พวกเขารองรับได้
ในการใช้งาน volume populators:
- คุณต้องตั้งค่า cluster ของคุณให้มี CRD ที่เหมาะสมก่อน
Always honor PersistentVolume reclaim policy
การปรับปรุงครั้งนี้ได้แก้ไขปัญหาที่:
- นโยบายการ reclaim ของ Persistent Volume (PV) ไม่ถูกทำตามอย่างสม่ำเสมอ
ส่งผลให้เกิดความเสี่ยงต่อการรั่วไหลของ storage resource
โดยเฉพาะในกรณีที่:
- PV ถูกลบก่อนที่ Persistent Volume Claim (PVC) ที่เกี่ยวข้องจะถูกลบ
ในสถานการณ์เช่นนี้:
- นโยบาย reclaim แบบ “Delete” อาจไม่ถูกดำเนินการ
- ทำให้ storage assets ที่อยู่เบื้องหลังยังคงเหลืออยู่โดยไม่ตั้งใจ
เพื่อแก้ไขปัญหานี้:
- Kubernetes ตอนนี้ได้เพิ่ม finalizers ให้กับ PVs ที่เกี่ยวข้อง
เพื่อให้แน่ใจว่า:
- นโยบาย reclaim policy จะถูกบังคับใช้ไม่ว่าจะลบ PV หรือ PVC ก่อนก็ตาม
การปรับปรุงนี้:
- ป้องกันการเก็บ storage resources ไว้โดยไม่ตั้งใจ
- และรักษาความสอดคล้องในการบริหารจัดการ PV lifecycle
ฟีเจอร์ใหม่ใน Beta
รองรับ Direct Service Return (DSR) ใน Windows kube-proxy
DSR มอบการเพิ่มประสิทธิภาพด้าน performance โดย:
- อนุญาตให้ traffic ขากลับที่ถูก route ผ่าน load balancers สามารถ bypass (ข้าม) load balancer แล้วตอบกลับไปยัง client ได้โดยตรง
- ซึ่งช่วยลดภาระงานบน load balancer และ
- ลด overall latency ลงด้วย
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ DSR บน Windows, สามารถอ่านได้ที่หัวข้อ Direct Server Return (DSR) in a nutshell
DSR ถูกแนะนำครั้งแรกในเวอร์ชัน v1.14
และได้ถูก promoted เป็นสถานะ beta โดยทีม SIG Windows
ซึ่งเป็นส่วนหนึ่งของ:
Structured parameter support สำหรับ Dynamic Resource Allocation (DRA)
แม้ว่า structured parameter support จะยังคงเป็นฟีเจอร์ในสถานะ beta อยู่ใน Kubernetes v1.33
แต่ส่วนสำคัญนี้ของ Dynamic Resource Allocation (DRA) ก็ได้รับการปรับปรุงอย่างมีนัยสำคัญ
มีการออกเวอร์ชันใหม่ v1beta2 ที่:
- ทำให้ resource.k8s.io API มีความเรียบง่ายขึ้น
และผู้ใช้ทั่วไปที่มี role namespaced cluster edit:
- ตอนนี้สามารถใช้งาน DRA ได้แล้ว
kubelet ในเวอร์ชันนี้ได้เพิ่มการรองรับ:
- seamless upgrade
ทำให้ driver ที่ deploy เป็น DaemonSets สามารถใช้กลไก rolling update mechanism ได้
สำหรับการ implement DRA:
- การปรับปรุงนี้ช่วยป้องกันไม่ให้มีการลบและสร้าง ResourceSlices ใหม่
- ทำให้ ResourceSlices คงอยู่ได้แม้ระหว่างการ upgrade
นอกจากนี้:
- มีการเพิ่ม grace period 30 วินาที
ก่อนที่ kubelet จะทำการ cleanup หลังจาก unregister driver - ซึ่งช่วยให้รองรับ driver ที่ไม่ได้ใช้ rolling updates ได้ดีขึ้น
Dynamic Resource Allocation (DRA) สำหรับ network interfaces
การรายงานข้อมูล network interface แบบ standardized ผ่าน DRA
ซึ่งถูกแนะนำครั้งแรกในเวอร์ชัน v1.32
ตอนนี้ได้ graduated เป็นสถานะ beta ในเวอร์ชัน v1.33
การเปลี่ยนแปลงนี้ช่วยให้:
- การเชื่อมต่อกับระบบ network ภายใน Kubernetes สามารถทำได้แบบ native มากขึ้น
- และทำให้การพัฒนาและการบริหารจัดการอุปกรณ์ network (networking devices) มีความง่ายขึ้น
เรื่องนี้ได้ถูกพูดถึงไปแล้วใน: v1.32 release announcement blog
ปรับปรุงการจัดการ queue ใน Scheduler (Handle unscheduled pods early)
ฟีเจอร์นี้ช่วยปรับปรุง queue scheduling behavior
เบื้องหลังการทำงาน:
- scheduler จะทำการดึง (popping) pods ออกจาก backoffQ
(ซึ่งเป็น pods ที่ไม่ได้ถูก back off เนื่องจาก error) - ในกรณีที่ activeQ ว่างเปล่า
ก่อนหน้านี้:
- scheduler จะเข้าสู่สถานะ idle (ว่าง) แม้ว่า activeQ จะว่างอยู่ก็ตาม
การปรับปรุงครั้งนี้:
- ช่วยเพิ่มประสิทธิภาพในการ schedule โดยการป้องกันไม่ให้ scheduler ว่างงานโดยไม่จำเป็น
Asynchronous preemption ใน Kubernetes Scheduler
Preemption มีหน้าที่เพื่อ:
- ให้ pods ที่มี priority สูงกว่าได้รับ resource ที่ต้องการ
- โดยการขับไล่ (evicting) pods ที่มี priority ต่ำกว่าออกไป
Asynchronous Preemption ซึ่งเปิดตัวในเวอร์ชัน v1.32 ในสถานะ alpha
ตอนนี้ได้ graduated เป็นสถานะ beta ในเวอร์ชัน v1.33
ด้วยการปรับปรุงนี้:
- งานหนัก ๆ เช่น API calls เพื่อทำการลบ pods
- จะถูกประมวลผลแบบ parallel (ขนาน)
ซึ่งทำให้:
- scheduler สามารถดำเนินการ schedule pods อื่น ๆ ต่อไปได้โดยไม่เกิดความล่าช้า
การปรับปรุงนี้:
- มีประโยชน์อย่างยิ่งใน clusters ที่มี Pod churn สูง (มีการสร้างและลบ pods บ่อยครั้ง)
- หรือเกิด scheduling failures บ่อยครั้ง
เพื่อให้มั่นใจว่า:
- กระบวนการ schedule จะมีประสิทธิภาพและมีความทนทานมากขึ้น (efficient and resilient scheduling process)\
ClusterTrustBundles
ClusterTrustBundle ซึ่งเป็น cluster-scoped resource
ถูกออกแบบมาเพื่อใช้เก็บ X.509 trust anchors (เช่น root certificates)
ฟีเจอร์นี้ได้ graduated เป็นสถานะ beta ในเวอร์ชัน v1.33
API ตัวนี้ช่วยให้:
- certificate signers ที่ทำงานภายใน cluster (in-cluster)
- สามารถเผยแพร่ (publish) และสื่อสาร (communicate) X.509 trust anchors ไปยัง cluster workloads ได้ง่ายขึ้น
Fine-grained SupplementalGroups control
ฟีเจอร์นี้ถูกนำมาใช้ครั้งแรกในเวอร์ชัน v1.31
และได้ graduated เป็นสถานะ beta ในเวอร์ชัน v1.33
พร้อมทั้งถูกเปิดใช้งานเป็นค่าเริ่มต้นแล้ว (enabled by default)
โดยมีเงื่อนไขว่า:
- cluster ของคุณต้องเปิดใช้งาน SupplementalGroupsPolicy feature gate
ในกรณีนั้น:
- ฟิลด์
supplementalGroupsPolicyภายในsecurityContextของ Pod - จะรองรับสองนโยบายคือ:
-
Merge policy (ค่าเริ่มต้น):
- รักษาความเข้ากันได้ย้อนหลัง (backward compatibility)
- โดยการรวมกลุ่มที่ระบุไว้กับกลุ่มที่มาจากไฟล์ /etc/group ของ container image
-
Strict policy:
- ใช้เฉพาะกลุ่มที่ระบุไว้อย่างชัดเจนเท่านั้น
การปรับปรุงนี้ช่วย:
- แก้ไขข้อกังวลด้านความปลอดภัย
- โดยเฉพาะกรณีที่การมี membership ของกลุ่มจาก container images โดยปริยาย
- อาจนำไปสู่การเข้าถึงไฟล์โดยไม่ได้ตั้งใจ (unintended file access permissions) และการหลีกเลี่ยงการควบคุม policy
รองรับการ mount OCI images เป็น volumes
การรองรับการใช้งาน Open Container Initiative (OCI) images เป็น volumes ใน Pods
ซึ่งถูกแนะนำครั้งแรกในเวอร์ชัน v1.31
ตอนนี้ได้ graduated เป็นสถานะ beta แล้ว
ฟีเจอร์นี้ช่วยให้ผู้ใช้สามารถ:
- ระบุ image reference เพื่อใช้เป็น volume ใน Pod
- พร้อมทั้ง reuse volume นั้นเป็น volume mount ภายใน containers ต่าง ๆ ได้
การรองรับนี้:
- เปิดโอกาสให้สามารถแพ็กข้อมูลใน volume แยกออกจากกัน
- และสามารถแชร์ข้อมูลเหล่านั้นระหว่าง containers ภายใน Pod ได้
- โดยไม่ต้องรวมข้อมูลเหล่านั้นเข้าไปใน main image
ซึ่งจะช่วย:
- ลดความเสี่ยงด้านช่องโหว่ (reducing vulnerabilities)
- และทำให้การสร้าง image ง่ายขึ้น (simplifying image creation)
รองรับ User namespaces ภายใน Linux Pods
หนึ่งใน KEP ที่เก่าแก่ที่สุด ณ เวลาที่เขียนนี้คือ KEP-127
ซึ่งว่าด้วยเรื่อง Pod security improvement โดยการใช้ Linux User namespaces สำหรับ Pods
KEP นี้:
- ถูกเปิดครั้งแรกตั้งแต่ช่วงปลายปี 2016
- และหลังจากมีการปรับปรุงหลายรอบ
- ได้มีการปล่อยในสถานะ alpha release ในเวอร์ชัน v1.25
- ตามมาด้วย initial beta ในเวอร์ชัน v1.30 (ซึ่งในตอนนั้นถูกตั้งค่าให้ disabled by default)
- และใน v1.33 ได้ถูกย้ายมาเป็น on-by-default beta แล้ว
การรองรับนี้:
- จะ ไม่ส่งผลกระทบ ต่อ Pods ที่มีอยู่เดิม
- เว้นแต่คุณจะระบุ
pod.spec.hostUsersด้วยตัวเองเพื่อ opt-in
ตามที่ได้กล่าวไว้ใน:
-
v1.30 sneak peek blog การเปลี่ยนแปลงนี้ถือเป็น:
-
หมุดหมายที่สำคัญ (important milestone) สำหรับการลดความเสี่ยงจาก vulnerabilities
ตัวเลือก Pod procMount
procMount option ซึ่งถูกแนะนำครั้งแรกในสถานะ alpha ในเวอร์ชัน v1.12
และเป็น off-by-default beta ในเวอร์ชัน v1.31
ตอนนี้ได้ย้ายมาเป็น on-by-default beta ในเวอร์ชัน v1.33 แล้ว
การปรับปรุงนี้ช่วย:
- เพิ่มประสิทธิภาพของ Pod isolation
- โดยการเปิดโอกาสให้ผู้ใช้สามารถปรับแต่งการเข้าถึง /proc filesystem ได้ละเอียดขึ้น
โดยเฉพาะ:
- มีการเพิ่มฟิลด์เข้าไปใน
Pod securityContext - เพื่อให้ผู้ใช้สามารถ override พฤติกรรมปกติที่ทำการ masking และ marking บางเส้นทางของ /proc ให้เป็นแบบ read-only ได้
ซึ่งมีประโยชน์มากในกรณีที่:
- ผู้ใช้ต้องการรัน unprivileged containers ภายใน Kubernetes Pod ที่ใช้ user namespaces
ตามปกติ:
- container runtime (ผ่าน CRI implementation) จะทำการ start outer container ด้วยการตั้งค่า mount สำหรับ /proc ที่เข้มงวดมาก
แต่หากต้องการ:
-
รัน nested containers ภายใน unprivileged Pod ได้สำเร็จ
ผู้ใช้จำเป็นต้องมีกลไกเพื่อ: -
ผ่อนคลายค่า default เหล่านั้น
และฟีเจอร์นี้:
- ก็มอบความสามารถดังกล่าวให้
นโยบายใหม่ใน CPUManager เพื่อกระจาย CPUs ข้าม NUMA nodes
ฟีเจอร์นี้:
- เพิ่มตัวเลือก policy option ใหม่ให้กับ CPU Manager
เพื่อให้สามารถกระจาย (distribute) การใช้งาน CPUs ข้าม Non-Uniform Memory Access (NUMA) nodes
แทนที่จะรวมการใช้งานไว้บน node เดียว
การเปลี่ยนแปลงนี้:
- ช่วยปรับปรุงการจัดสรร CPU resource allocation
โดยการกระจาย workloads ให้สมดุลข้ามหลาย ๆ NUMA nodes
ซึ่งจะส่งผลให้:
- เพิ่มประสิทธิภาพ (performance) และ
- เพิ่มการใช้ทรัพยากรอย่างมีประสิทธิภาพ (resource utilization)
ในระบบที่ใช้ multi-NUMA systems
Zero-second sleeps สำหรับ container PreStop hooks
Kubernetes 1.29 ได้แนะนำ Sleep action สำหรับ preStop lifecycle hook ใน Pods
ซึ่งช่วยให้:
- containers สามารถหยุดพัก (pause) ไว้ตามระยะเวลาที่กำหนดก่อนที่จะทำการ termination
กลไกนี้:
-
เป็นวิธีที่ตรงไปตรงมา (straightforward method) เพื่อทำการหน่วงเวลาการ shutdown ของ container
-
อำนวยความสะดวกให้กับ tasks ต่าง ๆ เช่น:
- การ connection draining หรือ
- การทำ cleanup operations
ตอนนี้:
- Sleep action ภายใน preStop hook
สามารถกำหนด zero-second duration ได้ในฐานะฟีเจอร์ beta
ซึ่งเปิดโอกาสให้สามารถ:
- กำหนด no-op preStop hook ได้
(คือ preStop hook ที่มีการกำหนดไว้ แต่ไม่ต้องการ delay จริง ๆ)
สิ่งนี้มีประโยชน์เมื่อ:
- ต้องการมี preStop hook ด้วยเหตุผลทางเทคนิค แต่ไม่ต้องการให้เกิดการหน่วงเวลา
Internal tooling: validation-gen
เบื้องหลังการทำงาน:
- ระบบภายในของ Kubernetes เริ่มต้นใช้กลไกใหม่ในการตรวจสอบความถูกต้อง (validating) ของ objects และการเปลี่ยนแปลงของ objects
ในเวอร์ชัน Kubernetes v1.33
ได้แนะนำเครื่องมือภายในตัวใหม่ชื่อว่า:
- validation-gen
ซึ่งเป็นเครื่องมือที่:
- ผู้พัฒนา (Kubernetes contributors) ใช้ในการสร้าง declarative validation rules
เป้าหมายหลักของการเปลี่ยนแปลงนี้คือ:
- เพื่อเพิ่มความแข็งแกร่ง (robustness) และ
- เพิ่มความง่ายในการดูแลรักษา (maintainability) ของ API validations
โดยการ:
- ทำให้ developers สามารถระบุข้อกำหนดการตรวจสอบ (validation constraints) ได้ในลักษณะ declarative
- ลดความผิดพลาดจากการเขียนโค้ดด้วยมือ (manual coding errors) และ
- ทำให้เกิดความสอดคล้องกัน (consistency) ทั่วทั้ง codebase
ฟีเจอร์ใหม่ใน Alpha
กำหนด tolerance ได้เองใน HorizontalPodAutoscalers (HPA)
ตอนนี้ HPA สามารถ:
- กำหนด tolerance ได้
- ใช้เพื่อลดการ scaling ที่เกิดจาก metric เปลี่ยนเล็กน้อย
- ช่วยให้ scaling มีเสถียรภาพขึ้น ไม่สวิงบ่อยโดยไม่จำเป็น
กำหนด delay สำหรับ container restart ได้
ฟีเจอร์ configurable container restart delay:
- เปิดตัว alpha1 ใน v1.32
- เพิ่ม kubelet-level configuration สำหรับควบคุม CrashLoopBackOff behavior
- ทำให้สามารถปรับแต่ง delay ก่อน restart container ได้ละเอียดขึ้น
กำหนด custom container stop signals ได้
ก่อนเวอร์ชัน Kubernetes v1.33:
- การตั้งค่า stop signals สามารถทำได้เฉพาะใน container image definitions เท่านั้น
(เช่น ผ่าน StopSignal configuration field ใน image metadata)
หากคุณต้องการ:
-
เปลี่ยนแปลงพฤติกรรมการ termination
คุณจำเป็นต้อง: -
สร้าง custom container image ใหม่
โดยการเปิดใช้งาน (alpha) ContainerStopSignals feature gate ใน Kubernetes v1.33
ตอนนี้คุณสามารถ:
- กำหนด custom stop signals ได้โดยตรงภายใน Pod specifications
การกำหนดนี้:
- จะอยู่ในฟิลด์
container's lifecycle.stopSignal - และต้องมีฟิลด์
Pod's spec.os.nameระบุไว้ด้วย
หากไม่ได้ระบุ:
- containers จะ fallback กลับไปใช้ stop signal ที่กำหนดไว้ใน image (ถ้ามี)
- หรือใช้ค่าเริ่มต้นของ container runtime (โดยปกติคือ SIGTERM สำหรับ Linux)
DRA Enhancements (ปรับปรุงใหญ่มากสำหรับ Dynamic Resource Allocation)
Kubernetes v1.33 ยังคงพัฒนา Dynamic Resource Allocation (DRA)
พร้อมฟีเจอร์ใหม่ ๆ ที่ออกแบบมาเพื่อตอบโจทย์โครงสร้างพื้นฐานที่มีความซับซ้อนในปัจจุบัน
DRA คือ:
- API สำหรับร้องขอและแบ่งปัน resources ระหว่าง pods และ containers ภายใน pod
โดยปกติ resources เหล่านี้คือ:
- อุปกรณ์ต่าง ๆ เช่น GPUs, FPGAs, และ network adapters
ต่อไปนี้คือ alpha DRA feature gates ทั้งหมดที่ถูกแนะนำใน v1.33:
-
คล้ายกับ Node taints, โดยการเปิดใช้งาน DRADeviceTaints feature gate:
- อุปกรณ์ (devices) จะรองรับการใช้ taints และ tolerations
- ผู้ดูแลระบบ (admin) หรือ component ของ control plane สามารถ taint อุปกรณ์เพื่อจำกัดการใช้งานได้
- การ schedule pods ที่พึ่งพาอุปกรณ์เหล่านี้สามารถถูก pause ไว้ขณะที่ taint ยังคงอยู่
- หรือสามารถ evict pods ที่ใช้อุปกรณ์ที่ถูก taint ได้
-
โดยการเปิดใช้งาน DRAPrioritizedList feature gate:
- DeviceRequests จะได้ฟิลด์ใหม่ชื่อว่า
firstAvailable - ฟิลด์นี้เป็น list แบบมีลำดับ (ordered list)
- อนุญาตให้ผู้ใช้กำหนดได้ว่าการร้องขอ resource สามารถตอบสนองได้หลายรูปแบบ รวมถึงการไม่ต้องจัดสรรเลย หาก hardware บางตัวไม่พร้อมใช้งาน
- DeviceRequests จะได้ฟิลด์ใหม่ชื่อว่า
-
ด้วยการเปิด DRAAdminAccess feature gate:
- เฉพาะผู้ใช้ที่ได้รับสิทธิ์ในการสร้าง ResourceClaim หรือ ResourceClaimTemplate
ใน namespace ที่มี labelresource.k8s.io/admin-access: "true"เท่านั้นที่สามารถใช้ฟิลด์adminAccessได้ - เพื่อป้องกันไม่ให้ non-admin users ใช้ฟีเจอร์
adminAccessอย่างไม่เหมาะสม
- เฉพาะผู้ใช้ที่ได้รับสิทธิ์ในการสร้าง ResourceClaim หรือ ResourceClaimTemplate
-
แม้ว่าจะสามารถ consume device partitions ได้ตั้งแต่ v1.31:
- แต่ vendors จำเป็นต้อง pre-partition อุปกรณ์ไว้ล่วงหน้า
-
ด้วยการเปิด DRAPartitionableDevices feature gate ใน v1.33:
- vendors สามารถประกาศหลาย partition ได้ รวมถึง partition ที่มีการ overlap กัน
- Kubernetes scheduler จะเลือก partition ตาม workload requests
- และป้องกันไม่ให้มีการจัดสรร partitions ที่ขัดแย้งกันในเวลาเดียวกัน
ฟีเจอร์นี้:
- ให้อิสระกับ vendors ในการสร้าง partitions แบบ dynamic ในช่วงเวลาที่ทำการ allocate จริง
- ทั้งการ allocate และการแบ่ง partition จะทำงานแบบอัตโนมัติและโปร่งใสต่อผู้ใช้งาน (automatic and transparent)
หมายเหตุ:
- feature gates เหล่านี้จะไม่มีผลใด ๆ
- เว้นแต่คุณจะเปิดใช้งาน DynamicResourceAllocation feature gate ด้วย
Robust image pull policy สำหรับ authenticate images แม้เป็น IfNotPresent หรือ Never
ฟีเจอร์นี้ช่วยให้ผู้ใช้สามารถ:
- มั่นใจได้ว่า kubelet จะทำการตรวจสอบการยืนยันตัวตนสำหรับการดึง image (image pull authentication check)
- สำหรับ credentials ชุดใหม่ทุกครั้ง
- โดยไม่คำนึงว่า image นั้นมีอยู่บน node แล้วหรือไม่ก็ตาม
Downward API รองรับ node topology labels
ฟีเจอร์ใหม่นี้:
- เปิดให้ Node topology labels สามารถเข้าถึงได้โดยตรงผ่าน downward API
ก่อนที่จะมี Kubernetes v1.33:
- หาก workloads ต้องการข้อมูล topology ของ node
- จะต้องใช้วิธีแก้ไขชั่วคราว โดยให้ init container ทำการ query ข้อมูลจาก Kubernetes API ด้วยตัวเอง
การมาของฟีเจอร์ (alpha) ใหม่นี้:
- ช่วยลดความซับซ้อนในการเข้าถึงข้อมูล Node topology
- ทำให้ workloads สามารถดึงข้อมูลได้โดยตรง ง่ายขึ้น สะดวกขึ้น ไม่ต้องมีการ workaround เพิ่มอีกต่อไป
ปรับปรุง pod status ด้วย generation และ observedGeneration
ก่อนการเปลี่ยนแปลงนี้:
- ฟิลด์
metadata.generationยังไม่ได้ถูกใช้งานใน pods
พร้อมกับการขยายการรองรับ metadata.generation:
- ฟีเจอร์นี้จะมีการเพิ่มฟิลด์ใหม่ชื่อว่า
status.observedGeneration - เพื่อช่วยให้สามารถแสดงสถานะของ pod (pod status) ได้ชัดเจนยิ่งขึ้น
รองรับ split level 3 cache architecture ใน CPU Manager
ก่อนหน้านี้:
- CPU Manager ของ kubelet ยังไม่รองรับโครงสร้าง split L3 cache architecture
(หรือที่รู้จักกันว่า Last Level Cache (LLC))
ปัญหาที่เกิดขึ้นคือ:
- การกระจาย CPU assignments อาจไม่ได้พิจารณาการแบ่งของ L3 cache
- ซึ่งอาจนำไปสู่ปัญหา noisy neighbor (คือ workloads รบกวนกันบน CPU เดียวกัน)
การปรับปรุงครั้งนี้:
- เป็นฟีเจอร์ระดับ alpha
- ที่ช่วยให้ CPU Manager สามารถจัดสรร CPU cores ได้ดีขึ้น
- เพื่อเพิ่มประสิทธิภาพโดยรวม (better performance)
รองรับ Pressure Stall Information (PSI) metrics สำหรับ scheduling improvements
PSI metrics:
- ตรวจวัด resource pressure (เช่น CPU, memory stalls) บน Linux
- ใช้ cgroupv2
- ช่วยให้ Kubernetes มีข้อมูลที่ละเอียดขึ้นในการตัดสินใจ schedule Pod
Secret-less image pulls ด้วย kubelet
on-disk credential provider ของ kubelet
ตอนนี้รองรับ:
- การดึง Kubernetes ServiceAccount (SA) token แบบเลือกได้ (optional)
การเปลี่ยนแปลงนี้:
- ช่วยทำให้การ authentication กับ image registries ง่ายขึ้น
- โดยเปิดทางให้ cloud providers สามารถเชื่อมต่อกับ OIDC compatible identity solutions ได้สะดวกยิ่งขึ้น
ฟีเจอร์ที่เลื่อนสถานะ (Graduations), ฟีเจอร์ที่ยกเลิก (Deprecations) และฟีเจอร์ที่ถูกถอดออก (Removals) ใน Kubernetes v1.33
ฟีเจอร์ที่เลื่อนสถานะเป็น Stable
นี่คือรายการฟีเจอร์ทั้งหมดที่เลื่อนสถานะเป็น Stable (หรือเรียกว่า General Availability (GA)) ใน Kubernetes v1.33
หากต้องการดูรายการเต็มรวมถึงฟีเจอร์ใหม่ และฟีเจอร์ที่เลื่อนจาก alpha → beta → stable สามารถดูได้ใน release notes
ใน release นี้ มีฟีเจอร์ที่ถูกโปรโมทเป็น Stable ทั้งหมด 18 รายการ
- Take taints/tolerations into consideration when calculating PodTopologySpread skew
- Introduce MatchLabelKeys to Pod Affinity and Pod Anti Affinity
- Bound service account token improvements
- Generic data populators
- Multiple Service CIDRs
- Topology Aware Routing
- Portworx file in-tree to CSI driver migration
- Always Honor PersistentVolume Reclaim Policy
- nftables kube-proxy backend
- Deprecate status.nodeInfo.kubeProxyVersion field
- Add subresource support to kubectl
- Backoff Limit Per Index For Indexed Jobs
- Job success/completion policy
- Sidecar Containers
- CRD Validation Ratcheting
- node: cpumanager: add options to reject non SMT-aligned workload
- Traffic Distribution for Services
- Recursive Read-only (RRO) mounts
ฟีเจอร์ที่ยกเลิก (Deprecations) และฟีเจอร์ที่ถูกถอดออก (Removals)
ในขณะที่ Kubernetes พัฒนาและเติบโต ฟีเจอร์บางตัวอาจถูกยกเลิก (deprecated), ถอดออก (removed) หรือถูกแทนที่ด้วยฟีเจอร์ที่ดีกว่า เพื่อให้โปรเจกต์มีสุขภาพที่ดีในระยะยาว
สามารถอ่านรายละเอียดเพิ่มเติมได้จาก Kubernetes deprecation and removal policy ประกาศการยกเลิกฟีเจอร์หลายรายการก่อนหน้านี้มีในบทความ Deprecations and Removals blog post
การยกเลิก Endpoints API (เวอร์ชัน Stable)
EndpointSlices API อยู่ในสถานะ stable ตั้งแต่เวอร์ชัน v1.21 และได้เข้ามาแทนที่ Endpoints API แบบเดิมอย่างมีประสิทธิภาพ แม้ว่า Endpoints API เดิมจะมีความเรียบง่ายและตรงไปตรงมา แต่เมื่อระบบต้องขยาย (scale) ไปยังการจัดการ network endpoints จำนวนมาก ก็เริ่มเกิดปัญหาในการรองรับ
EndpointSlices API ได้เพิ่มความสามารถใหม่ ๆ เช่น การรองรับ dual-stack networking ซึ่งทำให้ Endpoints API แบบเก่าพร้อมสำหรับการเข้าสู่กระบวนการ deprecation แล้ว
การ deprecation นี้มีผลกระทบเฉพาะผู้ที่ใช้งาน Endpoints API โดยตรงผ่าน workloads หรือ scripts เท่านั้น ผู้ใช้กลุ่มนี้ควรเริ่มวางแผนย้ายไปใช้ EndpointSlices แทน เพื่อให้สอดคล้องกับแนวทางใหม่ของ Kubernetes และหลีกเลี่ยงปัญหาในอนาคต
เร็ว ๆ นี้จะมีบล็อกโพสต์เฉพาะกิจเพื่ออธิบายรายละเอียดเพิ่มเติมเกี่ยวกับผลกระทบจากการ deprecation และแนวทางการย้ายระบบ (migration plan) อย่างชัดเจน
คุณสามารถอ่านข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงครั้งนี้ได้ใน KEP-4974: Deprecate v1.Endpoints
การถอดข้อมูลเวอร์ชัน kube-proxy ออกจาก node status
หลังจากถูกประกาศ deprecation ตั้งแต่ในเวอร์ชัน v1.31 ตามที่ได้มีการเน้นย้ำไว้ใน v1.31 release announcement
ฟิลด์ .status.nodeInfo.kubeProxyVersion สำหรับ Nodes ก็ถูกลบออกในเวอร์ชัน v1.33
ฟิลด์นี้เคยถูกตั้งค่าโดย kubelet แต่ค่าที่ได้ไม่ได้มีความแม่นยำอย่างสม่ำเสมอ และเนื่องจากฟิลด์นี้ได้ถูกปิดการใช้งานเป็นค่าเริ่มต้นตั้งแต่เวอร์ชัน v1.31 แล้ว ในเวอร์ชัน v1.33 จึงมีการลบฟิลด์นี้ออกอย่างถาวร
การถอด in-tree gitRepo volume driver
gitRepo volume type ถูกประกาศ deprecated มาตั้งแต่เวอร์ชัน v1.11 หรือเกือบ 7 ปีที่แล้ว นับตั้งแต่การ deprecation นั้น ก็มีความกังวลด้านความปลอดภัยตามมา รวมถึงประเด็นที่ว่า gitRepo volume types สามารถถูกโจมตีเพื่อให้ผู้ไม่หวังดีสามารถทำ remote code execution ในระดับ root บน node ได้
ในเวอร์ชัน v1.33 โค้ดของ in-tree driver สำหรับ gitRepo ได้ถูกลบออกอย่างเป็นทางการ
อย่างไรก็ตาม ยังมีทางเลือกอื่น ๆ เช่น git-sync และ initContainers โดยใน Kubernetes API นั้น gitVolumes ยังไม่ได้ถูกลบออก ดังนั้น pods ที่ใช้ gitRepo volumes ยังคงสามารถถูกรับเข้ามาได้โดย kube-apiserver แต่ถ้า kubelet มีการตั้งค่า feature-gate GitRepoVolumeDriver เป็น false จะไม่ทำการรัน pods เหล่านี้ และจะแจ้ง error ที่เหมาะสมกลับไปยังผู้ใช้
แนวทางนี้เปิดโอกาสให้ผู้ใช้เลือก opt-in เพื่อกลับมาใช้ driver ได้อีกประมาณ 3 รุ่น เพื่อให้มีเวลาเพียงพอในการแก้ไข workloads ของตนเอง
โดยมีแผนจะลบ feature gate ของ kubelet และโค้ด in-tree plugin ออกอย่างถาวรในเวอร์ชัน v1.39
การถอดการรองรับ host network สำหรับ Windows pods
Windows Pod networking มีเป้าหมายเพื่อให้สามารถใช้งานได้เทียบเท่ากับฝั่ง Linux และเพิ่มความหนาแน่นของ cluster ได้ดีขึ้น ด้วยการอนุญาตให้ containers ใช้ Node’s networking namespace ได้โดยตรง
การ implement แบบเดิมเริ่มต้นในสถานะ alpha ตั้งแต่เวอร์ชัน v1.26 แต่เนื่องจากเจอพฤติกรรมที่ไม่คาดคิดของ containerd และมีทางเลือกอื่น ๆ ที่สามารถใช้งานได้ ทางโครงการ Kubernetes จึงตัดสินใจยกเลิก KEP ที่เกี่ยวข้อง และได้ถอดการรองรับนี้ออกอย่างสมบูรณ์ในเวอร์ชัน v1.33
โปรดทราบว่า การถอนการรองรับนี้ ไม่ส่งผลกระทบ ต่อ HostProcess containers ซึ่งยังคงสามารถใช้ host network และเข้าถึงระดับ host level access ได้ตามปกติ การถอน KEP ใน v1.33 นี้ เป็นการยกเลิกเฉพาะความพยายามที่จะให้ Pods ใช้ host network เท่านั้น ซึ่งไม่เคยมีเสถียรภาพเนื่องจากข้อจำกัดทางเทคนิคในตรรกะของ Windows networking เอง
Release theme and logo
ธีมของ Kubernetes v1.33 คือ Octarine: The Color of Magic ได้แรงบันดาลใจจากซีรีส์ Discworld ของ Terry Pratchett
การออกเวอร์ชันนี้ต้องการเน้นย้ำถึง “เวทมนตร์ของ open source” ที่ Kubernetes ได้สร้างขึ้นทั่วทั้ง ecosystem
ถ้าคุณคุ้นเคยกับโลกของ Discworld คุณอาจจำได้ว่า มีมังกรหนองน้ำตัวเล็ก ๆ เกาะอยู่บนยอดหอคอยของ Unseen University กำลังมองขึ้นไปยังดวงจันทร์ Kubernetes เหนือเมือง Ankh-Morpork โดยมีฉากหลังเป็นดวงดาว 64 ดวง
ในขณะที่ Kubernetes กำลังก้าวเข้าสู่ทศวรรษที่สอง พวกเราขอเฉลิมฉลองทั้งเวทมนตร์แห่งความเชี่ยวชาญของผู้ดูแลโครงการ ความอยากรู้อยากเห็นของผู้ร่วมพัฒนารุ่นใหม่ ๆ และจิตวิญญาณแห่งการร่วมมือที่ขับเคลื่อนโครงการนี้ให้ก้าวไปข้างหน้า
การออก v1.33 เป็นการเตือนใจว่า ดังที่ Pratchett เขียนไว้ว่า
มันยังคงเป็นเวทมนตร์อยู่ แม้ว่าคุณจะรู้ว่ามันทำงานอย่างไร
แม้ว่าคุณจะรู้จักโค้ดเบสของ Kubernetes อย่างทะลุปรุโปร่ง แต่เมื่อหันกลับมามองในตอนท้ายของรอบ release cycle คุณจะเห็นได้ว่ามันยังคงเปี่ยมไปด้วยความมหัศจรรย์
Kubernetes v1.33 เป็นข้อพิสูจน์ถึงพลังแห่งนวัตกรรมแบบ open source ที่ไม่มีวันจางหาย
ซึ่งผู้ร่วมพัฒนาหลายร้อยคนจากทั่วโลกได้ทำงานร่วมกันเพื่อสร้างสิ่งที่พิเศษอย่างแท้จริง
เบื้องหลังฟีเจอร์ใหม่ ๆ ทุกตัว คือความพยายามของ community ที่คอยดูแลและปรับปรุงโครงการนี้อย่างต่อเนื่อง เพื่อให้มั่นใจว่า Kubernetes จะยังคงปลอดภัย น่าเชื่อถือ และออก release ได้ตรงตามกำหนด
แต่ละเวอร์ชันที่ออกมาได้ต่อยอดจากเวอร์ชันก่อนหน้า สร้างบางสิ่งที่ยิ่งใหญ่กว่าที่เราทำได้เพียงลำพัง
หมายเหตุ:
- Octarine คือสีที่ 8 ในตำนาน มองเห็นได้เฉพาะผู้ที่มีความไวต่อเวทมนตร์ เช่น พ่อมด แม่มด และแมว (รวมถึงบางคนที่จ้อง IPtable rules นานเกินไปด้วย)
Any sufficiently advanced technology is indistinguishable from magicใช่หรือไม่?- มีดวงดาว 64 ดวงในภาพ ไม่ใช่เรื่องบังเอิญ เพราะมี 64 KEPs (Kubernetes Enhancement Proposals) รวมอยู่ใน v1.33 ด้วย
- ดูเพิ่มเติมได้ในหัวข้อ Project Velocity สำหรับ v1.33 🚀