Skip to main content

OpenShift vs Vanilla Kubernetes

หน้านี้ถือว่าคุณรู้ Kubernetes พื้นฐานแล้ว (ดู Kubernetes section) — โฟกัสเฉพาะสิ่งที่ OpenShift เปลี่ยน/เพิ่มเข้ามา จาก K8s มาตรฐาน

Route vs Ingress​

OpenShift มี Route object ของตัวเองมาก่อน Kubernetes จะมี Ingress มาตรฐานเสียอีก (Route เกิดก่อน Ingress API หลายปี) — ทำงานผ่าน built-in HAProxy router ที่ deploy มาพร้อม cluster ตั้งแต่ต้น ไม่ต้องติดตั้ง Ingress Controller แยกเหมือน K8s เปล่า

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app
spec:
  host: my-app.apps.cluster.example.com
  to:
    kind: Service
    name: my-app
  tls:
    termination: edge
🧠 จำง่ายๆ

"Route = Ingress ที่มากับเครื่องตั้งแต่โรงงาน" — K8s เปล่าต้องซื้อ/ติดตั้ง Ingress Controller เอง (nginx-ingress, Traefik ฯลฯ) ส่วน OpenShift มี router แถมมาให้พร้อมใช้ทันทีตั้งแต่วันแรก ไม่ต้องตั้งค่าอะไรเพิ่ม

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

OpenShift เวอร์ชันใหม่ (4.x+) รองรับ Ingress object มาตรฐานของ K8s ด้วยเช่นกัน — แต่เบื้อง หลัง Ingress ที่สร้างจะถูกแปลงเป็น Route โดยอัตโนมัติ ผ่าน controller ที่ Red Hat เขียนไว้ (Ingress-to-Route conversion) ทำให้ไม่ว่าจะเขียน Ingress หรือ Route ตรงๆ สุดท้าย ก็ไปออกที่ HAProxy router ตัวเดียวกันอยู่ดี ข้อจำกัดคือ Ingress ที่ถูกแปลงมาจะไม่สามารถใช้ feature เฉพาะของ Route ได้ (เช่น wildcardPolicy, traffic splitting ระหว่างหลาย Service ผ่าน weight) ทีมที่ต้องการ feature ขั้นสูงของ routing จึงยังต้องเขียน Route ตรงๆ แทนที่จะ พึ่ง auto-conversion จาก Ingress

Project vs Namespace​

Project คือ Namespace ที่มี annotation และ RBAC default เพิ่มเติมของ OpenShift ทุก Project ที่สร้างผ่าน oc new-project จะได้ RBAC เริ่มต้นที่ผูก creator เป็น admin role ของ project นั้นโดยอัตโนมัติ (ต่าง K8s เปล่าที่ Namespace เป็น object ว่างเปล่า ไม่มี RBAC ติดมาด้วยเลย)

oc new-project my-team          # สร้าง Project พร้อม RBAC default
oc get namespace my-team        # ยังเรียกดูผ่าน Namespace API ได้ปกติ (มันคือ Namespace จริงๆ)
🧠 จำง่ายๆ

"Project = Namespace ที่มาพร้อมกุญแจบ้านให้เจ้าของทันที" — K8s เปล่าสร้าง Namespace แล้วต้อง ไปตั้ง RBAC เองทุกครั้งว่าใครมีสิทธิ์อะไร ส่วน OpenShift สร้าง Project แล้วคนสร้างได้สิทธิ์ admin ของ project นั้นทันทีโดยไม่ต้องตั้งเพิ่ม

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

Project ไม่ใช่ Kubernetes resource จริงๆ แต่เป็น virtual object ที่ OpenShift API สร้างครอบ Namespace ไว้อีกที (ผ่าน project.openshift.io API group) เวลา oc delete project my-team จริงๆ แล้วมันลบ Namespace underlying ที่ชื่อเดียวกันอยู่ดี — เหตุผลที่ OpenShift ทำแบบนี้แทนที่จะ extend Namespace ตรงๆ คือ Kubernetes core API ไม่อนุญาตให้ 3rd-party เพิ่ม field ลงใน built-in resource ได้ตามใจ ต้องสร้าง wrapper resource แยกแทน เป็น pattern เดียวกับที่หลาย platform บน K8s ใช้เวลาต้องการ "ปรับแต่ง" built-in resource ที่ แก้ตรงๆ ไม่ได้

oc CLI vs kubectl​

oc คือ superset ของ kubectl — คำสั่งพื้นฐานใช้แทนกันได้เกือบหมด (oc get pods ทำงาน เหมือน kubectl get pods เป๊ะ) แต่ oc มีคำสั่งเสริมเฉพาะของ OpenShift

oc new-app https://github.com/org/myapp     # สร้าง BuildConfig+DeploymentConfig+Service ให้อัตโนมัติ
oc rollout status dc/my-app                  # ดูสถานะ rollout ของ DeploymentConfig
oc whoami                                    # ดู user ที่ login อยู่ (SSO/OAuth integration)
oc adm policy add-role-to-user admin my-user -n my-team  # จัดการ RBAC แบบ OpenShift
🧠 จำง่ายๆ

"oc คือ kubectl + ชุดเครื่องมือช่างเสริม" — ใช้ kubectl ทำอะไรได้ oc ก็ทำได้เหมือนกัน แต่ oc มี "เครื่องมือพิเศษ" เพิ่มเติมสำหรับงานเฉพาะของ OpenShift (build, deploy, RBAC management) ที่ kubectl เปล่าไม่มี

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

oc ไม่ใช่แค่ wrapper ของ kubectl ที่เพิ่มคำสั่ง — มันคือ binary แยกที่ compile มาจาก kubectl source code เดียวกัน (OpenShift เป็น downstream ของ kubernetes/kubectl) แล้ว "ต่อเติม" subcommand เฉพาะทางเข้าไป ทำให้ oc ใช้แทน kubectl ได้ 100% ในทุกบริบท (รวมถึง scripts/CI pipeline ที่เขียนด้วย kubectl syntax) โดยไม่ต้องติดตั้งทั้งสองตัวแยกกัน — ทีมที่ เขียน CI/CD script ที่ reuse ข้าม cluster (ทั้ง vanilla K8s และ OpenShift) จึงมักเลือกใช้ oc เป็น binary เดียวครอบคลุมทั้งสองกรณี แทนที่จะ maintain script แยกสองชุด

English Summary

OpenShift's Route predates the Kubernetes Ingress API and ships with a built-in HAProxy router out of the box — no separate Ingress Controller install needed. Modern OpenShift auto- converts standard Ingress objects into Routes behind the scenes, but that conversion loses Route-specific features like weighted traffic splitting. Project is a virtual wrapper around a standard Namespace (via a separate API group, since core Kubernetes resources can't be extended directly) that adds default admin RBAC for the creator — something vanilla Namespace creation never does. oc is a superset binary of kubectl built from the same source, so it can fully replace kubectl in scripts while adding OpenShift-specific subcommands like oc new-app and oc adm policy.