OpenShift Interview Prep — คำถามที่พบบ่อย

1. OpenShift กับ Kubernetes เปล่าต่างกันหลักๆ ยังไง?

OpenShift คือ enterprise Kubernetes distribution ของ Red Hat ที่เพิ่ม: built-in routing (Route + HAProxy router แทนที่ต้องติดตั้ง Ingress Controller เอง), built-in CI/CD (BuildConfig + S2I แทนที่ต้องพึ่ง external CI), security defaults ที่เข้มกว่า (SCC บังคับ non-root), และ developer experience ที่ครบกว่า (web console, oc new-app) แลกกับ license cost และ vendor lock-in บางส่วน

🧠 จำง่าย + 🎯 Beyond

จำว่า "OpenShift = K8s + batteries included + security เข้มกว่า + ค่าใช้จ่าย" — Beyond: มุมที่ interviewer ระดับ senior มักถามต่อคือ "แล้วทำไมบางองค์กรเลือก vanilla K8s (EKS/GKE/AKS) แทน OpenShift ทั้งที่ OpenShift ดูครบกว่า" คำตอบที่ดีคือพูดถึง flexibility vs standardization trade-off: OpenShift บังคับ convention หลายอย่าง (SCC, Route) ที่ทำให้ ทีมมี guardrail ดี แต่ก็แลกกับความยืดหยุ่นที่ลดลง และ ecosystem tool บางตัวที่ออกแบบมาสำหรับ K8s มาตรฐานอาจต้องปรับตัวเพิ่มถึงจะใช้กับ OpenShift ได้ลื่นไหล 100% — องค์กรที่มีทีม platform engineering แข็งแรงอยู่แล้วมักเลือก vanilla K8s + เครื่องมือเลือกเอง ส่วนองค์กรที่ต้องการ "ของที่พร้อมใช้และมี enterprise support" มักเลือก OpenShift

2. SecurityContextConstraints ทำงานยังไง ต่างจาก PodSecurityPolicy/Pod Security Admission ยังไง?

SCC ตรวจสอบ Pod spec ตอน admission (ก่อน Pod ถูกสร้างจริง) เหมือนกับ PodSecurityPolicy/Pod Security Admission ของ K8s แต่ต่างกันที่ วิธี assign: SCC ผูกกับ ServiceAccount/user ผ่าน RBAC (ใครมีสิทธิ์ใช้ SCC ไหนก็ได้ SCC นั้นไปใช้กับ Pod ที่ ตัวเองสร้าง) ส่วน Pod Security Admission ผูกกับ Namespace ผ่าน label (ทุก Pod ใน namespace นั้นถูกบังคับระดับเดียวกันหมด ไม่ขึ้นกับว่าใครเป็นคนสร้าง)

🧠 จำง่าย + 🎯 Beyond

จำว่า "SCC ผูกกับคน (ใครสร้าง Pod), Pod Security Admission ผูกกับที่ (namespace ไหน)" — Beyond: ความต่างนี้มีผลจริงในทางปฏิบัติ — ถ้าทีมมี Pod หลายแบบที่ต้องการ security level ต่างกัน ใน namespace เดียวกัน (เช่น app ทั่วไปต้องการ restricted แต่ monitoring agent บางตัว ต้องการสิทธิ์สูงกว่า) SCC ทำได้ง่ายกว่ามาก (แค่ให้ ServiceAccount ของ monitoring agent มีสิทธิ์ ใช้ SCC ที่สูงกว่า โดย Pod อื่นใน namespace เดียวกันยังใช้ restricted ตามเดิม) ส่วน Pod Security Admission ที่ผูกกับ namespace ทำแบบนี้ไม่ได้ตรงๆ (ต้องแยก namespace ออกจากกันถ้า ต้องการ security level ต่างกันจริงๆ) — เป็นจุดที่แสดงว่าเข้าใจความแตกต่างเชิง design มากกว่า แค่รู้ว่า "มันคือ security mechanism เหมือนกัน"

3. อธิบาย S2I build process ทั้งหมดตั้งแต่ push code จนได้ running Pod

Flow เต็ม: (1) push code เข้า git repo ที่ BuildConfig ชี้ไป → (2) webhook/trigger สั่ง build → (3) OpenShift สร้าง build pod ชั่วคราวที่รัน S2I builder image + source code → (4) builder image รัน assemble script (install dependency, compile) → (5) ได้ image ใหม่ push เข้า internal registry → (6) ImageStream อัปเดตชี้ไป image ใหม่ → (7) ImageChange trigger สั่งให้ Deployment/DeploymentConfig rollout เวอร์ชันใหม่ → (8) Pod ใหม่ถูกสร้างรัน run script ของ builder image

🧠 จำง่าย + 🎯 Beyond

จำ flow ย่อ "push → build pod ชั่วคราว → image ใหม่ → ImageStream อัปเดต → trigger rollout → Pod ใหม่" — Beyond: จุดที่คนมักอธิบายไม่ครบคือ "build pod" เป็น Pod ชั่วคราวที่แยกจาก Pod ที่รันแอปจริง — มันถูกสร้างขึ้นมาเฉพาะช่วง build แล้วถูกลบทิ้งทันทีที่ build เสร็จ (ไม่ใช่ Pod เดียวกันที่ build แล้วก็กลายเป็น Pod ที่รัน production traffic) การแยก build pod ออกจาก runtime Pod ชัดเจนแบบนี้มีประโยชน์ด้าน security: build process มักต้องการสิทธิ์/dependency เยอะกว่า (compiler, package manager, build tools) ซึ่งไม่ควรมีอยู่ใน production image เลย — S2I ทำให้ build environment กับ runtime environment แยกจากกันโดยธรรมชาติของ design เอง

4. ถ้า Pod ไม่ยอมขึ้นเพราะ SCC permission denied จะ debug ยังไง

oc get events -n my-team | grep -i scc
# มักเจอ: "unable to validate against any security context constraint"

oc get pod my-app -o yaml | grep -A5 securityContext   # เช็คว่า Pod spec ขอ privilege อะไร
oc get scc restricted -o yaml                            # เช็คว่า SCC อนุญาตแค่ไหน
oc describe serviceaccount default -n my-team             # เช็คว่า SA นี้ใช้ SCC ไหนได้บ้าง

🧠 จำง่าย + 🎯 Beyond

จำว่า "ดู Pod ขออะไร, ดู SCC ให้อะไร, ดูว่า SA มีสิทธิ์ใช้ SCC ที่ให้พอไหม" 3 จุดเช็คเรียง ตามลำดับ — Beyond: สาเหตุที่พบบ่อยที่สุดของ error นี้ที่คนมักมองข้ามคือ Dockerfile ตั้ง USER root หรือ USER 0 แบบ hardcode ไว้ตรงๆ ซึ่งขัดกับ restricted SCC ที่บังคับ UID สุ่มที่ไม่ใช่ 0 โดยตรง วิธีแก้ที่ถูกต้องไม่ใช่การขอ SCC ที่สูงขึ้น (เช่น anyuid) เป็นอันดับแรก แต่ควรแก้ Dockerfile ให้รองรับ arbitrary UID ก่อนเสมอ (ตามที่อธิบายใน Security Model) — การขอ SCC สูงขึ้นควรเป็นทางเลือกสุดท้ายเมื่อ image นั้นแก้ไม่ได้จริงๆ (เช่น third-party image ที่ไม่ได้ maintain เอง) เพราะเป็นการลด security posture ของทั้ง cluster ไม่ใช่แค่ project เดียว

English Summary

OpenShift adds batteries-included routing, CI/CD, and stricter security defaults over vanilla Kubernetes at the cost of licensing and some flexibility — organizations with strong platform teams often prefer vanilla K8s with hand-picked tooling instead. SCCs bind to the ServiceAccount/user creating a Pod (via RBAC), letting different Pods in the same namespace run under different security levels; Pod Security Admission binds to the namespace itself via labels, applying uniformly to everything in it — a meaningful design difference beyond "both are admission-time security checks." The S2I build flow spins up a temporary, isolated build Pod (separate from the runtime Pod) that's deleted after producing the image — keeping build-time tooling out of the production image by design. For SCC permission-denied errors, check what the Pod requests, what the SCC allows, and what the ServiceAccount can use, in that order — and fix the Dockerfile to support arbitrary UIDs before reaching for a broader SCC, which should be a last resort.