Kubernetes Ingress ยุคใหม่: ย้ายจาก ingress-nginx ไป Gateway API ทีละขั้นตอน

kubectl get ingress -A
kubectl get ingress -A -o yaml | grep "nginx.ingress.kubernetes.io" | sort | uniq -c | sort -rn

ขั้นตอนที่ 3: แปลง Kubernetes Ingress เป็น HTTPRoute

เครื่องมือ ingress2gateway จากโครงการ Kubernetes ช่วยแปลง Ingress Resource เป็น Gateway API ได้ส่วนหนึ่ง แต่ต้องตรวจผลทุกไฟล์ ตัวอย่าง HTTPRoute ที่ได้

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
    - name: public-gateway
      namespace: gateway-system
  hostnames:
    - "shop.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: shop-api
          port: 8080

ถ้า Route อยู่คนละ Namespace กับ Gateway ต้องตั้ง allowedRoutes ใน Gateway ให้รับ Route จาก Namespace นั้น และถ้า Route ชี้ไป Service ข้าม Namespace ต้องสร้าง ReferenceGrant

ขั้นตอนที่ 4: ทดสอบก่อนเปลี่ยน DNS

ทดสอบผ่าน IP ของ Gateway ใหม่โดยตรงด้วย curl แล้วกำหนด Host Header เอง

curl -sv --resolve shop.example.com:443:<gateway-ip> https://shop.example.com/api/health

ตรวจ Redirect, Header, Timeout, ขนาด Request Body สูงสุด และ WebSocket ให้เหมือนระบบเดิม ค่าเริ่มต้นของ Controller แต่ละตัวต่างกัน จุดนี้มักเป็นต้นเหตุของปัญหาหลังย้าย

ขั้นตอนที่ 5: ย้าย Traffic ทีละส่วน

ลด TTL ของ DNS ล่วงหน้า แล้วย้ายทีละ Hostname เริ่มจากระบบที่ไม่สำคัญ เก็บ ingress-nginx ไว้คู่ขนานจนกว่าจะมั่นใจ แล้วจึงลบ Ingress Resource เดิมและถอน Controller เก่าออก

ถ้ายังไม่พร้อมย้ายไป Gateway API

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

คำถามที่พบบ่อย

Kubernetes Ingress จะถูกยกเลิกไหม?

Ingress API ยังอยู่ใน Kubernetes และใช้งานได้ต่อไป สิ่งที่ยุติคือโครงการ ingress-nginx ส่วน Ingress API ไม่มีการพัฒนาฟีเจอร์ใหม่แล้ว และ Gateway API คือทิศทางหลักของโครงการ

Gateway API พร้อมใช้ใน Production หรือยัง?

แกนหลักของ Gateway API อย่าง Gateway และ HTTPRoute อยู่ในสถานะ GA ตั้งแต่เวอร์ชัน 1.0 ปี 2023 และ Controller หลายตัวรองรับในระดับ Production แล้ว

ต้องย้าย Kubernetes Ingress ทุกตัวพร้อมกันไหม?

ไม่ต้อง Ingress Controller เดิมและ Gateway API Controller รันคู่ขนานกันได้ ให้ย้ายทีละ Hostname หรือทีละแอป

ingress2gateway แปลงได้ครบทุกอย่างไหม?

ไม่ครบ เครื่องมือแปลงโครงสร้างพื้นฐานได้ดี แต่ Annotation เฉพาะของ Controller เดิมอาจแปลงไม่ได้หรือแปลงได้บางส่วน ต้องตรวจผลและทดสอบทุกครั้ง

สรุป

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

THAI DATA CLOUD ให้บริการ Cloud Server และ Cloud Linux Server ที่ใช้สร้าง Kubernetes Cluster ได้ พร้อม Private Network สำหรับเชื่อมต่อระหว่าง Node [ตรวจสอบ: มีบริการ Managed Kubernetes หรือไม่ และรองรับ Load Balancer แบบใด] หากต้องการให้ทีมช่วยวางแผนย้าย ปรึกษาได้ที่ ติดต่อ THAI DATA CLOUD