두 쪽 모두 Kubernetes 다. 차이는 API 가 아니라 무엇까지 묶여서 오느냐 에 있다. 업스트림 Kubernetes 는 컨테이너 오케스트레이션 엔진이고, OpenShift 는 그 엔진에 런타임 · 네트워크 · 스토리지 · 레지스트리 · CI/CD · 모니터링 · 보안 정책을 붙여 하나의 구독 제품으로 만든 것이다.
그래서 비교는 "어느 쪽이 좋은가" 가 아니라 "조립을 직접 할 것인가, 조립된 것을 살 것인가" 의 문제가 된다.
| 영역 | OpenShift | 업스트림 Kubernetes |
|---|---|---|
| 기반 OS | RHEL CoreOS(권장) | RHEL · Rocky · Ubuntu 등 자유 |
| 설치·업그레이드 | openshift-install 로 Day 1 · Day 2 자동화 |
kubeadm · kops 등으로 직접. 버전 조합 검증도 직접 |
| 컨테이너 런타임 | CRI-O 고정 | containerd · CRI-O 중 선택 |
| 네트워크 | OVN-Kubernetes 기본, Multus 포함 | Calico · Cilium · Flannel 중 선택 |
| 인그레스 | 내장 HAProxy 라우터와 Route API | ingress-nginx · Traefik 등 직접 배포 |
| 레지스트리 | 내장 이미지 레지스트리 | Harbor 등 별도 구축 |
| 스토리지 | CSI + ODF(별도 구독) 통합 | CSI 드라이버 직접 설치 |
| CI/CD | Tekton · Argo CD 통합 | Jenkins · GitLab Runner 등 별도 |
| 모니터링·로그 | Prometheus · Grafana · Loki · Alertmanager 통합 | 직접 설치·튜닝 |
| 보안 정책 | SCC(SecurityContextConstraints) + SELinux 기본 강제 | Pod Security Standards 기본, 세부 정책은 OPA · Kyverno |
| 라이선스 | 상용 구독(지원 포함) | 무료 |
기술적으로 못 하는 것은 거의 없다. 다만 엔터프라이즈 환경에서 바로 쓰기 어려운 지점 이 있고, 그 대부분은 운영 인력이 메꿔야 한다.
운영 자동화가 없다. 롤링 업그레이드는 cordon → drain → upgrade 를 노드마다 반복하는 수작업이다. 노드가 열 대를 넘으면 무중단 업그레이드가 사실상 어렵다. 백업·복구는 Velero 같은 외부 도구를 직접 통합해야 한다.
보안이 기본으로 잠겨 있지 않다. PodSecurityPolicy 가 제거된 뒤 기본으로 남은 것은 Pod Security Standards 뿐이다. 그대로 두면 root 컨테이너와 hostPath 마운트가 허용된다. 감사 로그도 기본이 꺼져 있어 누가 무엇을 바꿨는지 추적되지 않는다. 이미지 서명 검증은 별도 구성이다.
운영자 지식 의존도가 높다. 관리 작업이 kubectl 과 YAML 중심이라 비개발자 접근이 어렵고, 모니터링·로그·인증서 갱신이 모두 손으로 붙인 조합이다. TLS 만료나 OIDC 토큰 문제로 나는 장애가 잦다.
라이선스는 0 이지만 TCO 는 0 이 아니다. CNI · CSI · 인그레스 · etcd 의 버전 충돌을 직접 해결해야 하고, 업스트림 릴리스의 지원 주기가 짧아 매년 버전을 올려야 한다. 공공·금융 보안 인증 과정에서 상용 플랫폼을 요구받는 경우도 있다.
자유도가 준다. 런타임 · 네트워크 · OS 선택이 사실상 고정되고, Red Hat 이 안내하는 구성 범위를 벗어나면 지원을 받기 어렵다. 구독 비용도 노드 수에 비례해 붙는다.
실무에서 더 자주 부딪히는 것은 SCC 다. 업스트림에서 잘 돌던 헬름 차트가 OpenShift 에서는 임의 UID 실행과 SCC 제약에 걸려 그대로 뜨지 않는다. 특정 UID 를 요구하거나 privileged 를 쓰는 워크로드는 SCC 를 따로 만들고 서비스 계정에 붙여야 한다.
상용 분석 플랫폼과 데이터 플랫폼 오퍼레이터는 대개 OpenShift 인증을 별도로 가지고 있다. 인증된 조합을 쓰면 인그레스 · SecurityContext · StorageClass 가 검증된 상태로 온다. 업스트림에서도 돌지만 그 세 가지를 직접 맞춰야 하고, 이것이 초기 구축 기간 차이의 대부분을 만든다.
privileged 권한이나 hostPath 를 요구하는 구성 요소가 있으면 OpenShift 에서는 SCC, 업스트림에서는 Pod Security Standards 의 네임스페이스 레이블을 손봐야 한다. 어느 쪽이든 "기본 상태로는 안 뜬다" 는 점은 같다.
| 상황 | 맞는 쪽 |
|---|---|
| 표준화와 감사 대응이 중요하고 운영 인력을 늘리기 어렵다 | OpenShift |
| 보안 인증에서 상용 플랫폼을 요구받는다 | OpenShift |
| 구성 자유도가 필요하고 Kubernetes 운영 인력이 있다 | 업스트림 |
| 비용 민감도가 높고 R&D 성격이다 | 업스트림 |