Gateway API คือขั้นกว่าของการทำ Ingress บน Kubernetes

Image credit: https://unsplash.com/photos/_UIVmIBB3JU

TL;DR

Kubernetes Gateway API เป็นการทำ Fine-grain แยกจาก Ingress Resource เดิมเพื่อให้ทีม Infra และทีม Dev แยกส่วนบริหารจัดการ ตามความรับผิดชอบได้ดีขึ้น

บทความนี้เหมาะกับผู้ที่คุ้นเคยกับ Kubernetes และเคยใช้งาน Ingress Controller บน Kubernetes

Kubernetes Ingress คืออะไร

Kubernetes เป็นระบบบริหารจัดการ Container, ซึ่ง Container ทำงานอยู่บน Overlay network ไม่สามารถถูกเข้าถึงหรือเรียกใช้งานตรงๆ ได้ จึงต้องมี Ingress มาเป็นตัวกลางเพื่อให้เข้าใช้งาน Applications ที่รันอยู่ใน Kubernetes ได้

Ref: NGINX Ingress Controller
ในภาพจะใช้ NGINX มาทำเป็น NGINX Ingress Controller ครับโดยมีขั้นตอนคือ

1. สร้าง NGINX Ingress Controller กล่องสีเขียว เราอาจเทียบได้กับการสร้าง Reverse Proxy ขึ้นมาใช้งาน 1 ชุดก็ได้
2. สร้าง Ingress โดยผ่าน Kubernetes API กล่องสีขาว เราอาจเทียบได้กับการ Configure Reverse proxy ให้ listen และส่ง Load ไปยัง Backend(services) ที่ต้องการก็ได้, ให้สังเกตคำว่า Kubernetes API โดย API ในที่นี้หมายถึง Interface ที่รองรับการติดต่อแบบ Application Programming(API = Application Programming Interface) หรือเราสามารถสร้าง Ingress โดยเรียกผ่าน API ได้นั่นเองครับ

Gateway API ไม่เกี่ยวข้องกับ API Gateway

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

Gateway API คำหลักคือ Gateway ในที่นี้คือทางเข้าใช้งาน ก็คือทางเข้าใช้งาน Applications ที่รันอยู่ใน Kubernetes นั่นเองครับ ส่วน API เป็นส่วนเสริมที่แสดงถึงการเป็น Interface(Application Programming Interface) ว่าเราสามารถสร้างทางเข้า(Gateway) นี้ผ่าน API ได้

ฉะนั้น API Gateway คือการบริหารจัดการการเข้าใช้งาน API Services ต่างๆ อาจเกี่ยวหรือไม่เกี่ยวกับ Kubernetes ก็ได้
แต่ Gateway API โฟกัสไปที่ทางเข้าไปยัง Application ใน Kubernetes ฉะนั้นจึงเป็นเคสของ Kubernetes เท่านั้น ส่วน Applications ที่รันอยู่ภายใน Kubernetes อาจเป็นหรือไม่เป็น API Services ก็ได้

เข้าเนื้อหา ทำไมต้องใช้ Gateway API

จากภาพ NGINX Ingress Controller ตามกล่องสีเขียวด้านบน ทำหน้าที่สองข้อด้วยกันคือ

1. รับ requests จากภายนอก การเลือกเปิดรับ Port, Name(FQDN), Policies , TLS termination ซึ่งงานแบบนี้มักเป็นงานของทีม Infra
2. ส่งต่อ requests ไปยัง services หลังบ้าน รวมไปถึงการทำ A/B testing, การอัพเกรด App version, Traffic splitting, header manipulating ซึ่งเป็นงานของทีม App

จะเห็นได้ว่าทั้งสองงานถูกดูแลด้วยทีม 2 ทีม ซึ่งท่าที่ใช้ทำ Ingress แบบเดิมๆ นั้นจะใช้วิธีการสร้าง Kubernetes Resource ชื่อว่า kind: ingress หรือเรียกได้ว่ามี Kubernetes Resource แค่หนึ่งเดียวที่ทุกทีมต้องมาใช้งานร่วมกัน ทำให้มีการให้สิทธิ์ที่มากเกินจำเป็น หรือหากถูกดูแลโดยทีมเดียว เมื่ออีกทีมต้องการแก้ไขก็ต้องร้องขอ ทำให้เกิดความยุ่งยากและล่าช้า

Ref: Gateway API
Pain point นี้ถูกแก้ด้วย Kubernetes Resources ตัวใหม่ชื่อว่า gateway และ HTTPRoute โดยทีม Infra สามารถบริหารจัดการ kind: gateway โดยจัดการ Name, Certificates และ Policies ได้ ส่วนทีม App สามารถจัดการ kind: HTTPRoute เช่น Path, การจัดการ App ต่างๆ ได้ด้วยตนเอง โดยเลือกจับคู่กับ gateway ที่มีให้ใช้งานได้

ตัวอย่างการใช้งานสร้าง kind: gateway สำหรับทีม Infra โดยตั้งชื่อ Gateway และระบุ Name, Port, Policies ที่ต้องการ

การใช้งานสร้าง kind: HTTP Route สำหรับทีม Dev โดยเลือกใช้ Gateway, ระบุ Path และ Services ที่ต้องการ

ลงไปดูมีการ Implement NGINX Pod แบบเดียวกับท่า Ingress ปกติครับ และสามารถต่อแบบ NodePort และรองรับ Cloud LoadBalancer ของ AWS, Azure, GCP ได้
Ref: NGINX Implementation

หนึ่งในท่าที่ทำได้คือการ Map NodePort ซึ่งทำในลักษณะเดียวกันกับ Ingress ปกติ

จะเห็นได้ว่าฝั่ง NGINX ทั้ง NGINX pod และ Services เรียกได้ว่าถอดแบบมาจากการทำ NGINX Ingress Controller ปกติเลย แต่จุดต่างจะอยู่ที่ตัว Kubernetes Resources ที่การทำ Gateway API มี Resources ให้ใช้มากกว่า ทำ Granular ได้ดีกว่า โดย Resources ทั้งหมดที่มีให้ใช้งานคือ GatewayClass, Gateway, HTTPRoute, TCPRoute, Service

Gateway API เมื่อนำมาใช้จะต้อง Implement คู่กับ Gateway(เทียบได้กับกล่องสีเขียวในรูปด้านบน) ซึ่งยังไม่พร้อมใช้งานบน Production

ณ ปัจจุบัน NGINX Ingress Controller เดิมๆ มีการใช้งานมากที่สุดเป็นอันดับ 1 อยู่แล้วครับ และมีความน่าเชื่อถือสูงมากใน Production ฉะนั้น NGINX จึงยังคงแนะนำให้ใช้ NGINX Ingress Controller บน Production

ถ้าต้องการใช้งานแบบแยก Resources เป็น Infra กับ Dev บน Production ยังมีทางเลือก Commercial คือ NGINX Plus Ingress Controller ซึ่งมี CRD เป็น Custom resources ที่ชื่อ kind: Virtualserver และ kind: Virtualserverroute พร้อมใช้งานบน Production มาก่อนหน้านี้ประมาณ 2-3 ปี
อีกตัวหนึ่งที่ GA แล้วคือ Google Kubernetes Engine ครับ