Skip to main content

Networking

Route รายละเอียดเชิงลึก​

Route ทำงานผ่าน router pod (HAProxy ที่ deploy เป็น DaemonSet-like หรือ Deployment ขึ้นกับ configuration) ที่ listen บน port 80/443 ของ Node แล้ว route traffic เข้า Service ที่ถูกต้องตาม hostname (คล้ายหลักการเดียวกับ Ingress Controller ของ K8s แต่ implementation เป็นของ OpenShift เอง)

spec:
  host: my-app.apps.cluster.example.com
  to:
    kind: Service
    name: my-app
    weight: 100
  alternateBackends:
    - kind: Service
      name: my-app-canary
      weight: 10
🧠 จำง่ายๆ

"Route มี 'น้ำหนัก' แบ่ง traffic ได้ในตัว" — weight ใน spec คือ "สัดส่วนปริมาณ" traffic ที่ ส่งไปแต่ละ Service เทียบกันตรงๆ (100:10 = ส่วนใหญ่ไปที่หลัก น้อยไปที่ canary) ทำ canary deployment ได้โดยไม่ต้องติดตั้ง service mesh เพิ่มเลย

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

alternateBackends + weight คือ built-in traffic splitting ที่ทำให้ OpenShift ทำ canary release/blue-green deployment แบบง่ายๆ ได้โดยไม่ต้องพึ่ง Istio/service mesh เลย — แต่ ข้อจำกัดที่คนมักไม่รู้คือ weight แบ่งตาม "จำนวน connection ใหม่" ไม่ใช่ "จำนวน request" เป๊ะๆ (เพราะ HAProxy ทำงานที่ connection level เป็นหลัก โดยเฉพาะถ้าใช้ HTTP keep-alive หรือ WebSocket ที่ connection หนึ่งมีหลาย request ซ้อนอยู่) ถ้า client บางตัวเปิด connection ค้าง ไว้นาน (long-lived connection) สัดส่วน traffic จริงที่แต่ละ backend ได้รับอาจเบี้ยวไปจาก weight ที่ตั้งไว้พอสมควร — ทีมที่ต้องการ traffic splitting ที่แม่นยำระดับ request จริงๆ (ไม่ใช่ connection) มักต้องเสริมด้วย service mesh อยู่ดีสำหรับ use case ที่ sensitive มากๆ

Router & TLS Termination Options​

Terminationทำงานที่ไหนใช้เมื่อ
edgeTLS ถูก decrypt ที่ router (HAProxy) traffic ไปหา Pod เป็น plain HTTPส่วนใหญ่ของกรณีทั่วไป ง่ายสุด
passthroughTLS ไม่ถูกแตะเลย ส่งผ่านไปให้ Pod decrypt เองต้องการ end-to-end encryption เข้มงวด เช่น compliance
reencryptRouter decrypt แล้ว encrypt ใหม่อีกรอบก่อนส่งไป Podต้องการทั้ง inspect traffic ที่ router และ encrypt ถึงปลายทาง
🧠 จำง่ายๆ

"edge = ยามเปิดซองอ่านแล้วส่งต่อแบบเปิด, passthrough = ยามไม่แตะซองเลยส่งทั้งซอง, reencrypt = ยามเปิดอ่านแล้วซีลซองใหม่ก่อนส่งต่อ" — ยิ่งปิดซองนานเท่าไหร่ (reencrypt) ยิ่งปลอดภัยแต่ยิ่งเปลือง CPU ยิ่งเปิดเร็ว (edge) ยิ่งง่ายแต่แลก security บางส่วน

🎯 Beyond: จุดที่ชาวบ้านไม่ค่อยรู้

passthrough termination มีข้อจำกัดที่คนมักไม่รู้จนกว่าจะเจอปัญหา: เพราะ router ไม่ decrypt TLS เลย มันอ่าน hostname ปลายทางได้แค่จาก SNI (Server Name Indication) ใน TLS handshake เท่านั้น (ไม่ใช่จาก HTTP header เหมือน edge/reencrypt) ผลคือ passthrough route ทำ path-based routing ไม่ได้เลย (route ได้แค่ตาม hostname เท่านั้น ไม่สามารถแยก path /api กับ /web ไปคนละ backend ได้เหมือน edge route) และ client ที่ไม่รองรับ SNI (เก่ามากๆ หรือ บาง legacy system) จะต่อ passthrough route ไม่ได้เลย — เป็นข้อจำกัดทางเทคนิคที่มาจาก fundamental ของ TLS protocol เอง ไม่ใช่ข้อจำกัดที่ OpenShift ตั้งใจใส่มา

English Summary

Route is served by a built-in HAProxy router pod reading hostname-based rules, and supports weighted traffic splitting across alternateBackends for canary/blue-green deploys without a service mesh — though weight splits by connection count, not per-request, so long-lived connections can skew the actual traffic ratio. TLS termination comes in three flavors: edge (decrypt at router, simplest), passthrough (untouched end-to-end, but router can only route by SNI hostname — no path-based routing, and legacy clients without SNI support fail entirely), and reencrypt (decrypt-then-reencrypt, for inspecting traffic while still encrypting to the Pod).