Kubernetes vs OKD vs OpenShift, 도대체 뭐가 다른가?

몇 해 전 겨울, 플랫폼 검토 회의가 끝나고 후배 한 명이 저를 따로 붙잡았습니다. 화이트보드에는 세 단어가 나란히 남아 있었습니다. Kubernetes, OKD, OpenShift.

질문은 짧았습니다.

"셋 다 Kubernetes 사용하는 것 아닌가요? 도대체 뭐가 다른 거죠?"

틀린 질문이 아닙니다. OpenShift도 OKD도 Kubernetes를 기반으로 씁니다.

검색하면 이런 설명이 제일 먼저 나옵니다.

Kubernetes = 기본 오픈소스, OKD = 무료 OpenShift, OpenShift = 유료 OKD

개념을 처음 잡을 때는 편합니다. 저도 한동안 이렇게 설명했고요. 그런데 실제로 플랫폼을 세우고 운영을 넘겨받는 순간부터 이 문장은 힘을 잃더라고요. 세 플랫폼의 거리는 무료냐 유료냐에서 벌어지지 않기 때문입니다.

그래서 질문을 바꿔봤습니다.

"우리 회사는 컨테이너 플랫폼을 어디까지 직접 만들고, 어디까지 직접 운영하고, 어디부터 벤더에게 책임을 맡길 것인가?"

이 각도로 보면 셋의 거리가 꽤 선명해집니다.

Kubernetes부터

Kubernetes는 컨테이너화된 애플리케이션을 배포하고 관리하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다.

컨테이너가 몇 개라면 사람 손으로도 됩니다. 수백 개, 수천 개가 되면 얘기가 달라집니다.

어떤 서버에 컨테이너를 배치할 것인가? 컨테이너가 죽으면 누가 다시 띄우는가? 서버 한 대가 통째로 나가면? 애플리케이션을 확장하려면? 새 버전은 어떻게 배포하는가?

Kubernetes가 이 문제들을 받아냅니다. Scheduling, Self-healing, Service Discovery, Load Balancing, Rolling Update, Scaling, Secret/Config 관리, Storage 연계.

여기까지만 보면 필요한 게 거의 다 있는 것처럼 보입니다.

기업 환경에 들어가면 다음 질문이 줄줄이 붙습니다. 사용자 인증은 어떻게 하지? 개발자 권한은 누가 관리하지? 이미지는 어디에 저장하지? 외부 트래픽은 어떻게 받지? 모니터링, 로그, 인증서, 업그레이드, 보안 정책, 그리고 클러스터 OS는 누가 책임지지?

Kubernetes는 강력하지만, 기업이 필요로 하는 플랫폼 기능 전부를 하나의 완제품으로 내놓지는 않습니다. 대신 필요한 구성 요소를 골라 조합하는 자유도가 높습니다.

자유도가 높다는 말을 뒤집으면, 고른 것에 대한 책임을 우리가 진다는 뜻입니다.

엔진은 훌륭한데, 계기판이 없습니다

자동차로 비유해보겠습니다.

Kubernetes는 아주 잘 만든 엔진과 구동계에 가깝습니다.

엔진 자체는 훌륭합니다. 그런데 차를 몰려면 엔진만으로는 안 됩니다. 계기판도, 브레이크도, 차체도, 에어컨도, 정비 체계도 있어야 굴러갑니다.

Kubernetes도 마찬가지입니다. 기업이 이걸 플랫폼이라고 부르며 운영하려면 주변에 붙일 것이 한참 남습니다. Ingress/Gateway, Monitoring, Logging, Registry, Storage, Network, IAM, Security, GitOps, Backup.

원하는 기술을 직접 고른다는 것, 이게 Kubernetes의 큰 장점입니다.

그리고 같은 이유로 운영팀에는 짐이 됩니다.

각 구성요소의 버전 호환성은 누가 검증합니까? 업그레이드는 어떤 순서로 갑니까? 장애가 났을 때 Kubernetes 문제인지 CNI 문제인지 Ingress 문제인지 누가 판단합니까?

엔터프라이즈 환경에서 더 크게 터진 쪽은 Kubernetes 자체가 아니라 그 주변을 어떻게 짜고 어떻게 굴릴 것인가였습니다. 적어도 제 경험은 그랬습니다.

그래서 OpenShift는

여기서 Red Hat OpenShift가 들어옵니다.

OpenShift는 Kubernetes를 기반으로, 기업이 컨테이너 플랫폼을 운영하는 데 필요한 기능들을 한데 묶어놓은 플랫폼입니다.

거칠게 말하면 Kubernetes를 기업에서 쓰도록 구성요소와 운영 체계까지 통합한 엔터프라이즈 Kubernetes 플랫폼입니다.

OpenShift 환경에서는 Kubernetes뿐 아니라 네트워크, 인증, 모니터링, Operator 기반 관리, Web Console, 이미지 관련 기능 같은 것들이 한 생태계 안에서 함께 옵니다.

차이는 다른 곳에 하나 더 있습니다.

검증과 지원입니다.

기업 시스템에서 장애가 터지면 GitHub Issue를 뒤지는 것으로 끝나지 않는 경우가 많습니다. 금융, 공공, 통신, 대기업이면 특히 그렇습니다.

원인을 끝까지 찾아내는 일, 보안 취약점에 대응하는 일, 지원되는 업그레이드 경로를 따라가는 일, 그리고 문제가 생겼을 때 책임지고 받아주는 기술지원 창구. 이게 다 필요합니다.

OpenShift Subscription 가격에는 이 지원 체계의 값이 들어 있습니다.

그래서 OpenShift를 "돈 내고 쓰는 Kubernetes"라고 정리하면 중요한 걸 놓칩니다.

OKD는 어디쯤 있나

제일 헷갈리는 게 OKD입니다.

보통 이렇게 설명합니다. "OKD는 무료 OpenShift입니다."

절반은 이해를 돕고, 절반은 빠집니다.

OKD는 OpenShift와 가까운 커뮤니티 기반 Kubernetes 배포판입니다.

OpenShift와 비슷한 아키텍처와 기술을 만져보지만, 상용 OpenShift와 같은 제품 지원 체계가 따라오지는 않습니다.

그러니까 OKD의 특징은 가격표에 있지 않습니다.

운영 책임이 어디에 놓이느냐에 있습니다.

OpenShift에서 문제가 생기면 지원 계약에 따라 Red Hat에 기술 지원을 요청합니다. OKD에서는 커뮤니티와 우리 팀의 기술 역량에 훨씬 많이 기대게 됩니다.

개발 환경에서는 이 차이가 작아 보입니다. 24시간 도는 Production에서는 전혀 다른 얘기가 됩니다.

'무료'라는 단어가 이상해지는 지점

소프트웨어 라이선스 비용이 없다고 운영 비용까지 없는 건 아닙니다.

새벽 2시에 클러스터에서 문제가 터졌다고 해보겠습니다.

Pod가 안 뜹니다. 원인을 보니 애플리케이션 문제가 아닙니다. Node를 봅니다. 정상입니다. CNI를 봅니다. 뭔가 이상한 징후가 있습니다. API Server 상태를 봅니다. etcd latency도 봅니다. 스토리지와 네트워크까지 훑습니다.

여기서 진짜 질문이 나옵니다.

"그래서 이 문제를 최종적으로 누가 해결할 것인가?"

OpenShift라면 지원 창구가 있습니다. OKD라면 상당 부분이 운영 조직의 몫으로 남습니다.

저도 예전에 "라이선스 비용 0원"이라고 적힌 장표를 회의에서 그대로 읽은 적이 있습니다. 그 장표에는 다음 1년치 온콜과 야근 이야기가 한 줄도 없었습니다. 지금 봐도 그건 제가 게을렀던 겁니다.

OKD의 비용을 "라이선스 비용 = 0"으로 적으면 곤란합니다. 실제로는 "플랫폼 비용 = 소프트웨어 + 인프라 + 운영 인력 + 장애 대응 + 업그레이드 + 기술 부채"에 가깝습니다.

무료 소프트웨어가 제일 싼 플랫폼은 아닌 이유입니다.

셋을 나란히 놓으면

구분	Kubernetes	OKD	OpenShift
기반	Kubernetes	Kubernetes 기반	Kubernetes 기반
성격	오픈소스 오케스트레이션 플랫폼	커뮤니티 배포판	엔터프라이즈 플랫폼
주변 기능	필요에 따라 직접 구성	통합된 구성요소 제공	검증된 플랫폼 구성 제공
자유도	매우 높음	높음	제품 정책 내에서 표준화
기술지원	선택한 배포판/벤더 등에 따라 다름	기본적으로 커뮤니티 중심	Red Hat 지원
구축 난이도	구성 방법에 따라 다름	상대적으로 복잡	표준화된 설치 방식 제공
운영 책임	운영 조직/공급자 구조에 따라 다름	운영 조직 비중 큼	운영 조직 + Vendor
비용 구조	구성에 따라 다름	Subscription 비용 없음	Subscription 비용 발생
적합한 환경	높은 커스터마이징이 필요한 환경	자체 기술 역량이 충분한 조직	엔터프라이즈 운영 및 지원이 중요한 조직

여기서 중요한 건 누가 더 좋냐가 아닙니다.

조직이 무엇을 원하는가입니다.

Kubernetes 쪽이 맞는 조직

플랫폼 엔지니어링 역량이 충분하고 특정 벤더에 묶이지 않으려는 조직이라면, Kubernetes 위에 직접 플랫폼을 짜는 쪽이 잘 맞습니다.

필요한 기능을 정확히 알고 CNI, Ingress, Monitoring, Logging, Registry, GitOps, Security를 직접 고르고 운영한다면 자유도는 확실히 큽니다.

그 자유에 붙어 오는 운영 책임까지 함께 받는다는 조건이 달립니다.

OKD 쪽

OpenShift 계열의 플랫폼 구조는 쓰고 싶은데 상용 Subscription 비용이 부담스럽거나, 자체 운영 역량이 충분한 조직이라면 OKD가 선택지에 들어옵니다.

개발·검증 환경이나 연구 목적에서도 의미가 있고요.

Production이라면 얘기가 다릅니다. "OpenShift랑 비슷한데 무료니까 OKD"라는 접근은 위험합니다.

운영 인력과 장애 대응 체계를 먼저 보는 편이 낫습니다. 누가 업그레이드하는지, 누가 장애를 분석하는지, 누가 보안 문제에 대응하는지, 어디까지 자체 해결이 되는지. 이게 흐릿한 채로 넘어가면 무료라는 단어는 나중에 청구서로 돌아옵니다.

OpenShift 쪽 — 책임 구조가 먼저인 곳

기업 환경에서는 기술만큼 무거운 게 하나 있습니다.

책임 구조입니다.

금융이나 공공처럼 서비스 안정성, 보안, 감사, 변경관리가 걸린 환경에서는 문제가 터졌을 때 공식 지원 체계가 있느냐 없느냐가 큽니다.

OpenShift 비용을 Kubernetes 기능 사용료로만 보면 비쌉니다. 그 안에는 플랫폼 구성요소의 검증, 제품 생명주기, 보안 업데이트, 호환성, 기술지원의 값이 함께 들어 있습니다.

기업에서 기능표만 비교해 제품을 고르기 어려운 이유가 여기 있습니다.

운영에 들어가면 질문이 바뀝니다

Kubernetes를 처음 공부할 때는 기능이 궁금합니다.

Deployment가 뭔지, Service가 뭔지, Ingress가 뭔지, Pod가 어떻게 Scheduling되는지 봅니다.

Production을 굴리기 시작하면 질문이 통째로 갈아 끼워집니다.

장애가 나면 누가 책임지는가? 업그레이드는 누가 검증하는가? 보안 취약점은 누가 판단하는가? CNI 장애는 누가 잡는가? OS 문제와 Kubernetes 문제의 경계는 어디인가? 애플리케이션 장애와 플랫폼 장애의 경계는 어디인가?

플랫폼 선택은 기술 선택이면서 동시에 책임 구조를 설계하는 일이었습니다.

그래서 뭐가 제일 좋은가

정답은 없습니다.

Kubernetes가 가장 자유롭다고 항상 좋지 않습니다. OpenShift가 상용 제품이라고 항상 좋지 않습니다. OKD가 무료라고 가장 경제적이지도 않습니다.

조직의 기술 역량과 운영 모델이 답을 정합니다.

저라면 플랫폼을 고를 때 이 질문들을 먼저 던지겠습니다. 우리 조직은 Kubernetes 주변 생태계를 직접 설계할 역량이 있는가. 24시간 Production 장애를 자체적으로 분석하고 끝까지 잡는가. 업그레이드와 보안 패치의 책임을 누가 지는가. 장애가 났을 때 공식 Vendor Support가 필요한 시스템인가. 플랫폼 자유도와 운영 표준화 중 어느 쪽이 더 급한가.

여기에 답이 나오면 세 플랫폼 중 무엇이 우리 쪽인지 훨씬 또렷해집니다.

차이는 가격표에 있지 않습니다

셋을 아주 멀리서 보면 Kubernetes라는 공통 기반 위에 다 같이 서 있습니다.

운영 관점으로 당겨보면 거리가 꽤 벌어집니다.

Kubernetes는 자유도를 줍니다. OKD는 OpenShift 계열의 플랫폼 경험을 커뮤니티 기반으로 줍니다. OpenShift는 거기에 엔터프라이즈 제품 생명주기와 Vendor Support를 얹습니다.

그래서 "어느 것이 더 좋은 기술인가"보다 먼저 물어야 할 게 있습니다.

"우리는 어디까지 직접 만들고, 어디까지 직접 운영하고, 어디부터 다른 조직이나 벤더에게 책임을 맡길 것인가?"

컨테이너 플랫폼을 고르는 일은 소프트웨어 하나를 고르는 일이 아닙니다. 기술과 비용, 운영 역량, 그리고 장애가 났을 때의 책임 구조까지 같이 설계하는 일입니다.

그날 그 후배한테는 이 얘기를 절반도 못 해줬습니다. 화이트보드에 세 단어만 다시 동그라미 쳐놓고 회의실을 나왔거든요. 저도 그때 정리가 다 돼 있진 않았습니다.