Kubernetes Multi-tenancy: ใช้แค่ Namespace มันพอแล้วหรือ?

Table of Contents#

• บทนำ (Introduction)
• Kubernetes Multi-tenancy คืออะไร?
• เหตุผลที่ต้องเป็น Kubernetes Multi-tenancy
• ทำไม Namespace ไม่สามารถทำ Isolation ได้จริง?
• Namespace เหมาะสำหรับ Use Cases แบบไหน?
• ถ้า Namespace ยังไม่ดีพอ มีทางเลือกอื่นหรือไม่?
  • 1. ใช้ Hierarchical Namespace Controller (HNC) เข้ามาช่วย
  • 2. สร้าง Virtual Cluster โดยใช้ vCluster
  • 3. สร้าง Kubernetes Cluster แยกสำหรับแต่ละ Tenant
• บทสรุป (Conclusion)

บทนำ (Introduction)#

Kubernetes เริ่มจะเป็นเหมือนดวงอาทิตย์ของระบบ IT ในปัจจุบัน หลายบริษัทเริ่มใช้ Kubernetes ในการ host ระบบหรือ applications ต่าง ๆ มากขึ้น และเมื่อมีจำนวน cluster มากขึ้นก็เริ่มคิดถึงการแชร์ cluster เพื่อประหยัดค่าใช้จ่ายและเพื่อให้ง่ายต่อการดูแล

แต่คำถามคือเราจะแยก resources ระหว่าง tenants (ผู้ใช้งาน) ได้ยังไง? ซึ่งสิ่งแรกที่หลายคนนึกถึงก็คือการใช้ Kubernetes Namespaces เข้ามาช่วย แต่ความจริงแล้ว namespaces นั้นไม่สามารถทำ isolation ได้ดีอย่างที่หลายคนเข้าใจ ซึ่งเหตุผลคืออะไรและจะมีอะไรที่มาแทนได้นั้นเดี๋ยวมาว่ากันต่อไป

Kubernetes Multi-tenancy คืออะไร?#

โดยทั่วไปแล้วคำว่า multi-tenancy ในโลกของ IT หมายถึงการที่ระบบ, platform หรือ application หนึ่งให้บริการแก่ผู้ใช้งาน (tenants) หลายรายพร้อมกันบน infrastructure เดียวกัน ซึ่ง tenant แต่ละรายจะต้องมีพื้นที่ของตัวเองแยกออกจากคนอื่นเพื่อความเป็นส่วนตัวของข้อมูล เช่น compute, network หรือ database

ในบริบทของ Kubernetes นั้น multi-tenancy จึงหมายถึงการที่เรามี Kubernetes cluster หนึ่งแล้วให้ tenants หลายรายมาใช้งานร่วมกัน ซึ่ง tenant ในที่นี้อาจจะเป็นทีมต่าง ๆ ภายในบริษัท, แผนก หรือแม้แต่ลูกค้าภายนอกเลยก็ได้

เหตุผลที่ต้องเป็น Kubernetes Multi-tenancy#

การนำระบบต่าง ๆ มารวมไว้บน Kubernetes cluster เดียวกันมีข้อดีในแง่ของ…

• ประสิทธิภาพการใช้งาน Resources ดีขึ้น: เราสามารถแชร์ resources ที่มีอยู่ให้ tenants ต่าง ๆ ใช้งานร่วมกันได้ ซึ่งทำให้ราคาที่จ่ายคุ้มค่ากว่าการแยกของใครของมัน
• ความง่ายในการดูแล: แทนที่ admin จะต้องดูแลหลาย clusters การรวมมาที่ cluster เดียวก็ทำให้การดูแลง่ายขึ้น
• การแชร์ Service ต่าง ๆ: Tenants สามารถแชร์ services กันได้หรือทำได้ง่ายขึ้นเมื่ออยู่บน cluster เดียวกัน สามารถสร้างครั้งเดียวใช้ได้หลายคน เช่น Kubernetes Ingress หรือ observability stack เป็นต้น
• ลดค่าใช้จ่าย: ในแง่ของค่า support จาก distro ต่าง ๆ, ค่าบริการ nodes จาก cloud providers รวมถึงค่าใช้จ่ายในส่วนของ operations ที่ซ่อนอยู่อีก

ทำไม Namespace ไม่สามารถทำ Isolation ได้จริง?#

เมื่อพูดถึงการแบ่งแยก tenants ระหว่างกัน หลายคนจะนึกถึงการใช้ namespaces ซึ่งเป็น feature พื้นฐานที่ใช้สำหรับการแยก resources อยู่แล้ว ซึ่งข้อดีของมันก็คือ…

• ง่ายและสะดวกในการตั้งค่า (configure) เพราะเป็นสิ่งที่ติดมากับ Kubernetes
• ใช้ resource น้อยมาก รวมถึงมีงานที่ต้องทำ (overhead) น้อยมากในการจัดการ

แต่ namespaces เองก็มาพร้อมกับข้อจำกัดหลายอย่าง ได้แก่

1. Tenant อื่น ๆ สามารถมองเห็นและเข้าถึง resources ที่เป็น cluster-scoped ของเราได้ เช่น custom resource definitions (CRDs) หรือ persistent volumes
   • สมมุติว่า tenant A สร้าง CRDs ขึ้นมา โดยอาจจะเป็น backup ของ Velero ซึ่งเป็น cluster-scoped ดังนั้น tenant อื่นก็สามารถเห็นหรือเข้าถึง backup ของ tenant A ได้เช่นกัน
   • ในกรณีของ persistent volumes ถ้า tenant หนึ่งไปผูก (mount) persistent volume เข้ากับ pod ผ่าน persistent volume claim (PVC) แล้ว tenants อื่น ๆ ก็ยังสามารถสร้าง PVC ไป mount กับ persistent volume เดียวกันนั้นเพื่อเข้าถึงข้อมูลได้
   • แม้การใช้ RBAC (Role-based Access Control) ก็อาจจะช่วยป้องกัน 2 ข้อด้านบนได้ก็จริง แต่ก็ต้องมีการกำหนด permissions ให้ดี ซึ่งเมื่อเจอกับ tenants จำนวนมากหรือมีการเปลี่ยนแปลงบ่อยก็อาจจะเกิดข้อผิดพลาดได้
2. บาง tenants อาจมีการใช้ resources (CPU หรือ memory) มากเกินไปจนกระทบกับ tenants อื่น ๆ ได้
   • เช่น หากเกิด memory leak ใน namespace หนึ่งจะกระทบกับ namespaces อื่นได้
   • แม้เราสามารถใช้ resource quota หรือ limit range ในการจำกัดการใช้งาน CPU หรือ memory ของแต่ละ namespace ได้ แต่มันก็ยังมีข้อจำกัดอยู่ดี สมมุติว่าเรามี CPU อยู่ 10 cores กับ 5 namespaces เราสามารถหาร 5 เพื่อแบ่ง namespace ละ 2 cores ได้ แต่มันก็ไม่สามารถเกลี่ย resources ได้ดีพอเพราะบาง namespaces อาจต้องการแค่ 1 core ในขณะที่บาง namespaces อาจใช้มากกว่า 2 cores
3. Namespaces ไม่ได้ทำ isolation ในระดับ kernel ดังนั้น containers ที่มี permissions มากเกินไป เช่น เป็น root หรือมี priviledge flags อาจสามารถเข้าถึง resources ใน namespaces อื่นได้

Namespace เหมาะสำหรับ Use Cases แบบไหน?#

การแยก tenant ด้วย namespace อาจจะเพียงพอสำหรับในบางกรณีที่ความต้องการ isolation อยู่ในระดับที่ไม่สูงมาก

• ทุก tenants อยู่ในองค์กรเดียวกันและเป็นทีมที่ไว้ใจกันได้ โดยอาจเป็น application ที่มีทีมหนึ่งดูแลในส่วนของ service A และอีกทีมดูแล service B ซึ่งอยู่บน cluster เดียวกันแต่แยกกันด้วย namespace

  • แต่ถ้าเป็นคนละ business unit (BU) หรือคนละแผนกกัน เช่น ทีม HR กับทีม sales ที่ดูแลรับผิดชอบกันคนละ application การแยกด้วย namespace อย่างเดียวก็อาจจะไม่เพียงพอ(ก็ได้) เช่น ข้อมูลของทีม HR อาจจะเป็นสิ่งที่ sensitive มากสำหรับบริษัท

• ไม่ใช่ production environment เช่น อาจเป็นแค่ dev/test environment ที่ยอมรับความเสี่ยงได้มากกว่า

• Application ที่เป็น stateless โดยมีการอ่านข้อมูลเท่านั้น ไม่มีการเขียน state หรือข้อมูลสำคัญ เช่น เว็บแสดงข้อมูลทั่วไป

ถ้า Namespace ยังไม่ดีพอ มีทางเลือกอื่นหรือไม่?#

ลองทำความเข้าใจตารางเปรียบเทียบนี้เพื่อให้เห็นภาพรวมก่อนครับ แล้วเดี๋ยวมาอธิบายกันต่อ

• HNC คือ Hierarchical Namespace Controller
• ดาว (★) ยิ่งมาก = ยิ่งดี (สำหรับหัวข้อนั้น) แต่ไม่ได้แปลว่าดาวมากที่สุดคือ solution ที่ดีที่สุด

1. ใช้ Hierarchical Namespace Controller (HNC) เข้ามาช่วย#

• HNC คือ Kubernetes addon ที่ช่วยให้เราสามารถจัดการ namespace แบบเป็นลำดับชั้น (hierarchy) ได้
• สมมุติเรามี namespace ชื่อ team-a และ team-b เราสามารถสร้าง subnamespaces ย่อยลงไปอีกได้ เช่น

├── team-a
│   ├── team-a-project-1
│   └── team-a-project-2
└── team-b
    ├── team-b-project-1
    └── team-b-project-2
Copy

• ถ้าเรากำหนด resource quota ไว้ที่ team-a ว่าให้ใช้ CPU ได้ไม่เกิน 4 cores ทุก subnamespaces ของ team-a ก็จะได้รับ quota CPU 4 cores ไปด้วยโดยอัตโนมัติ
• หรือกำหนด RBAC ให้ user nopnithi เป็น admin ของ team-a นั่นหมายความว่า nopnithi ก็จะเป็น admin ของ team-a-project-1 และ team-a-project-2 ด้วยเช่นกัน
• แต่ในส่วนข้อจำกัดอื่น ๆ ของ namespace ก็ยังคงเหมือนเดิมครับ

ที่จริงยังมี Capsule ที่เป็น open source ที่ช่วยเรื่องการจัดการ namespace สำหรับ multi-tenancy ด้วย และสิ่งที่เพิ่มมาจาก HNC คือมี proxy ที่ช่วยให้ tenant มองเห็นเฉพาะ namespace ตัวเอง

2. สร้าง Virtual Cluster โดยใช้ vCluster#

• vCluster คือ open source project ที่ช่วยให้เราสร้าง virtual clusters ขึ้นมาภายใน Kubernetes cluster หลักได้
• แต่ละ virtual cluster จะมี control plane (API server, etcd หรือ controllers) ของตัวเองและมีการ sync resources บางอย่างระหว่างกัน ทำให้ได้ isolation ที่ดีกว่า namespace
• Tenant แต่ละรายจะเห็น virtual cluster เป็น Kubernetes cluster ปกติ ทำให้ควบคุมอะไรต่าง ๆ ได้ง่ายขึ้นเหมือนการสร้าง cluster แยก
• อย่างไรก็ตาม virtual cluster ก็ยังมีข้อจำกัดในการ isolate physical node อยู่ เพราะ pod ถูกสร้างบน cluster เดียวกัน

ที่จริงระหว่างขั้นที่ 2 และ 3 ยังมี project ชื่อ Karmada อยู่ด้วย แต่ส่วนตัวผมอาจจะยังไม่ได้มีโอกาสได้ลองใช้มันเท่าที่ควร

3. สร้าง Kubernetes Cluster แยกสำหรับแต่ละ Tenant#

• เป็นวิธีที่ทำ isolation ได้แบบเบ็ดเสร็จที่สุด และมีอิสระในการจัดการ cluster ของตัวเองมากที่สุด
• แต่ก็ต้องแลกมาด้วยค่าใช้จ่ายที่สูงขึ้น ทั้งในแง่ของ resources และ operations ที่ต้องจัดการหลาย clusters

บทสรุป (Conclusion)#

การเลือกใช้ namespace, virtual cluster หรือการแยก Kubernetes cluster ในการทำ multi-tenancy นั้นไม่มี solution ที่ดีที่สุด (one-size-fits-all) แต่ขึ้นอยู่กับความต้องการและข้อจำกัดของแต่ละองค์กร โดยปัจจัยที่ต้องคำนึงถึง คือ…

• ระดับของการ Isolate ที่ต้องการ
• Resources หรืองบประมาณที่มี
• ความยากง่ายในการดูแล Clusters
• ความยืดหยุ่นสำหรับ Tenant แต่ละราย (เช่น CRDs หรือเวอร์ชั่นของ cluster)

ถ้าไม่ได้มีข้อจำกัดอะไรเป็นพิเศษ การเลือกใช้ virtual cluster ก็ดูจะเป็นทางเลือกที่น่าสนใจเพราะให้ความสมดุลทั้งในแง่ของ isolation, resource utilization และการบริหารจัดการ cluster ที่ดีกว่าเมื่อเทียบกับ namespace ในขณะที่ค่าใช้จ่ายนั้นก็ยังไม่เยอะเท่ากับการสร้าง Kubernetes cluster แยกไปเลย หรือหากในบริบทที่ไม่ได้ต้องการ isolation แบบเข้มข้นนัก ผมคิดว่า HNC ก็น่าจะตอบโจทย์เช่นกัน