แก้ปัญหา apiVersion ของ K8S Resourceไม่ตรงกับที่เราใช้ แบบไม่ต้องเดา
Kubernetes จนถึงวันนี้ มาไกลจนถึง version 1.14 แล้ว ซึ่ง K8S Api ก็ปรับ version อย่างรวดเร็ว ปัญหาของการที่ Api พัฒนาเร็วมากก็คือ บางทีก็เร็วจน Tutorial หรือ ตัวอย่างบน Internet ปรับตามไม่ทัน เวลาเราไป search ตัวอย่างมาใช้ก็อาจจะทำให้เกิดปัญหาได้
ยกตัวอย่างเช่น สมมุติว่าเราต้องการประกาศ RBAC ClusterRole สิ่งที่เราจะทำก็คือไปหา code ใน Internet เพื่อนำมาเป็นแบบและปรับใช้ ตัวอย่างเช่น
ทีนี้พอเราเอา Code นี้มา apply ใช้ ปรากฏว่า K8S ตอบกลับมาว่า
อ่านจาก Error message เราก็พอจะรู้แหละว่า ตอนนี้ version ไม่ใช่ v1alpha1 แล้ว น่าจะต้องเปลี่ยน version ให้ตรง แต่ version ที่จะต้องใช้คืออะไรล่ะ
จริงๆแล้ว kubectl มีคำสั่งที่ใช้ดูว่า ใน cluster ของเรา api แต่ละตัวใช้ version อะไรอยู่โดยการใช้คำสั่ง
kubectl explain [ชื่อของ k8s resource type]
ซึ่งในกรณีนี้ resource type ที่เราสนใจคือ clusterrole ก็พิมพ์คำสั่งว่า
จะเห็นได้ว่าเมื่อเราพิมพ์ kubectl explain clusterrole แล้ว จะปรากฏผลลัพธ์รายละเอียดของ Api ใน cluster ของเรา รวมถึง Version ที่ support ด้วย (กรอบสีแดงในตัวอย่าง) เราก็เอา version ในตัวอย่างมาแก้ไฟล์ yml เราได้เลย
เท่านั้นแหละก็เรียบร้อยแล้ว สั่ง kubectl apply ได้เลย ซึ่งรอบนี้ก็จะผ่านแน่นอนครับ เพราะเราเอา version ที่ support มาใช้เลย แบบไม่ต้องเดา
นอกจากนี้ถ้าเราต้องการรู้ชื่อทั้งหมด ของ K8S Api resource เรายังสามารถสั่งให้ kubectl แสดงรายการของ K8S resource ทั้งหมดที่เรามีได้ผ่านคำสั่ง
kubectl api-resources
ซึ่งจะได้ผลลัพธ์รายการของ resource ที่เราสามารถใช้ได้ทั้งหมดใน cluster รวมไปถึงสิ่งที่ผมชอบมากก็คือ ชื่อเล่น (Shortname) ของแต่ละ resource ที่สามารถเอามาใช้ใน kubectl command อื่นๆได้อีกด้วย ดังรูปตัวอย่างนี้
นอกจากนี้ถ้าเราต้องการรู้ว่า แต่ละ Api resource อยู่ใน Api Group ไหน และเราจะสามารถจัดการกับ Api เหล่านั้นด้วย verbs ใดได้บ้าง (POST, PUT, PATCH, DELETE, …) เราสามารถใช้ command เดิม แต่เพิ่ม flag -o wide ดังตัวอย่าง
kubectl api-resources -o wide
ซึ่ง Information ในส่วนนี้ ทั้งในส่วนของ Api Group และ Verbs จะเป็นข้อมูลสำคัญในการกำหนด Permission ผ่าน RBAC (Role Based Access Control) ซึ่งเป็นระบบในการให้สิทธิ์ในการเรียก Api ของ Account ใน K8S ได้ ซึ่งไว้ผมจะมาเล่าให้ฟังใน Blog ต่อไปนะครับ
