RHOSO 18: OpenStack on OpenShift를 운영 관점으로 읽기

요즘 RHOSP 18이라고 부르는 주제는 공식 제품명으로 보면 Red Hat OpenStack Services on OpenShift 18.0, 줄여서 RHOSO 18입니다. 이름보다 중요한 변화는 OpenStack control plane을 더 이상 예전 director/undercloud 중심으로만 보지 않는다는 점입니다. RHOSO 18은 OpenShift 위에서 OpenStack control plane을 Operator와 CRD로 운영하고, compute 같은 data plane은 RHEL 노드와 Ansible 기반 적용 흐름으로 관리하는 모델입니다.

1. RHOSP 18보다 RHOSO 18로 봐야 하는 이유

기존 RHOSP 운영자는 undercloud, overcloud, TripleO, Heat 템플릿, director workflow에 익숙합니다. RHOSO 18에서는 이 사고방식을 그대로 가져가면 운영 지점이 어긋납니다. OpenStack 서비스는 OpenShift 클러스터 위에서 Kubernetes 리소스로 올라오고, 배포와 변경은 OpenStack Operator가 reconciliation하는 방식으로 흐릅니다.

공식 릴리스 노트에서도 RHOSP 17.1이 director 기반 OpenStack-on-OpenStack control plane 형식을 사용하는 마지막 제품군이라는 점을 명시합니다. 그래서 RHOSO 18을 볼 때는 "OpenStack을 설치한다"보다 "OpenShift 위에 OpenStack control plane을 선언하고, 외부 RHEL data plane을 연결한다"로 이해하는 편이 맞습니다.

2. 가장 큰 변화: control plane이 OpenShift 위로 간다

RHOSO 18의 control plane은 Keystone, Nova API, Neutron server, Glance, Cinder API, Placement, Horizon 같은 OpenStack 서비스가 OpenShift namespace 안의 Pod, Service, Secret, ConfigMap, route, PVC 같은 리소스로 표현됩니다. 운영자는 기존 systemd 서비스만 보는 대신 OpenShift의 Operator, CRD, Pod 상태, 이벤트, 로그를 같이 봐야 합니다.

이 변화는 장점과 부담을 동시에 줍니다. 장점은 선언형 배포, Operator 기반 조정, OpenShift 관측/보안/스케줄링 기능을 활용할 수 있다는 점입니다. 부담은 OpenStack 장애처럼 보여도 실제 원인이 OpenShift 노드, OLM, storage class, network attachment, certificate, secret, route 쪽에 있을 수 있다는 점입니다.

3. control plane과 data plane을 분리해서 봐야 한다

RHOSO 18에서 control plane은 OpenShift 위에 있고, data plane은 OpenStack 워크로드를 실제로 처리하는 RHEL 기반 노드들입니다. compute, network, storage 쪽 data plane 상태를 볼 때는 OpenShift CR 상태와 Ansible 적용 결과, 그리고 노드 자체의 서비스 상태를 같이 봐야 합니다.

운영자가 자주 보게 될 리소스는 대략 다음 흐름입니다.

• OpenStackControlPlane: OpenStack control plane 서비스 구성을 선언합니다.
• OpenStackDataPlaneNodeSet: data plane 노드 묶음과 노드별 설정을 선언합니다.
• OpenStackDataPlaneDeployment: data plane에 실제 설정 적용을 트리거하고 진행 상태를 남깁니다.
• OpenStackVersion: OpenStack Operator와 배포 버전 매핑을 확인하는 기준점입니다.

4. 설치 흐름은 Operator와 CRD 중심으로 읽는다

문서를 운영 관점으로 압축하면 RHOSO 18 배포 흐름은 다음 순서입니다. 설치 명령을 외우는 것보다 각 단계에서 어떤 계층이 준비되는지 구분하는 것이 중요합니다.

1. RHOCP 클러스터 준비
2. OpenStack Operator 설치
3. OpenStack 접근용 Secret과 기본 설정 준비
4. RHOCP / control plane / data plane 네트워크 준비
5. OpenStackControlPlane CR 생성
6. OpenStackDataPlaneNodeSet CR 생성
7. OpenStackDataPlaneDeployment로 data plane 적용
8. OpenStack 서비스 endpoint, compute, network, storage 검증

초기 점검은 OpenShift 클러스터 자체가 정상인지, OpenStack Operator와 CRD가 들어왔는지, control plane/data plane CR이 어떤 상태인지부터 확인합니다.

oc get clusterversion
oc get nodes -o wide
oc get co

oc get operators -A | grep -i openstack
oc get crd | grep -i openstack
oc explain openstackcontrolplane.spec

oc get openstackversion -A
oc get openstackcontrolplane -A
oc get openstackdataplanenodeset -A
oc get openstackdataplanedeployment -A

5. OpenShift 요구사항과 네트워크 설계를 먼저 고정한다

RHOSO control plane을 올리는 OpenShift 클러스터는 단순 테스트용 Kubernetes가 아니라 운영 control plane의 기반입니다. 공식 계획 문서는 RHOSO 18 control plane을 호스팅할 RHOCP 클러스터 요구사항으로 RHOCP 4.18 기반의 사전 준비된 3노드 bare metal 클러스터를 최소 조건으로 제시합니다. HA 구성을 의도한다면 control plane/worker 역할 분리, storage, network, 장애 도메인을 더 엄격하게 봐야 합니다.

네트워크는 더 중요합니다. control plane VIP, OpenShift pod/service 네트워크, data plane 관리망, storage망, tenant/provider network, network attachment, NNCP/Nmstate 적용 상태가 섞이면 장애 원인을 찾기 어렵습니다. RHOSO 18에서는 "OpenStack network가 안 된다"를 바로 Neutron 문제로 보지 말고, OpenShift 네트워크와 data plane NIC 설정까지 같이 분리해야 합니다.

oc get nncp,nnce -A
oc get network-attachment-definition -A
oc -n openstack get svc -o wide
oc -n openstack get endpoints,endpointslice

openstack endpoint list
openstack network agent list
openstack compute service list
openstack hypervisor list

6. control plane 장애는 OpenShift 리소스로 추적한다

API 응답 지연, Keystone 인증 실패, Horizon 접속 실패, Nova API 오류가 보이면 먼저 OpenShift namespace 안의 Pod와 Service, route, Secret, Operator 로그를 확인합니다. 기존 OpenStack 운영처럼 서비스 로그만 보기 전에 Operator가 원하는 상태를 만들고 있는지, 배포가 Degraded인지, 관련 Pod가 CrashLoop인지부터 봐야 합니다.

NS=openstack

oc -n ${NS} get pods -o wide
oc -n ${NS} get svc,route,secret,cm
oc -n ${NS} get openstackcontrolplane -o yaml
oc -n ${NS} get openstackversion -o yaml

oc -n ${NS} describe openstackcontrolplane <control-plane-name>
oc -n ${NS} logs deploy/openstack-operator-controller-manager --tail=200

7. data plane 장애는 CR 상태와 노드 상태를 같이 본다

Compute 노드가 안 붙거나 VM 생성이 실패하면 OpenStack CLI 결과만으로는 부족합니다. OpenStackDataPlaneNodeSet과 OpenStackDataPlaneDeployment의 condition, data plane job 로그, Ansible 실행 결과, 노드별 systemd 서비스, libvirt, ovs/ovn, storage multipath 상태를 같이 확인해야 합니다.

NS=openstack

oc -n ${NS} get openstackdataplanenodeset
oc -n ${NS} describe openstackdataplanenodeset <nodeset-name>
oc -n ${NS} get openstackdataplanedeployment
oc -n ${NS} describe openstackdataplanedeployment <deployment-name>

oc -n ${NS} get jobs,pods -o wide | grep -i dataplane
oc -n ${NS} logs job/<dataplane-job-name> --tail=200

8. Day-2 운영 기준

RHOSO 18 Day-2 운영은 세 계층을 동시에 보는 방식으로 정리할 수 있습니다. 첫째, OpenShift 계층입니다. ClusterOperator, Node, MCP, OLM, storage, network 상태가 control plane 안정성을 좌우합니다. 둘째, RHOSO 선언 계층입니다. OpenStackControlPlane과 DataPlane CR의 desired/current 상태를 봐야 합니다. 셋째, OpenStack 서비스 계층입니다. endpoint, compute service, network agent, volume service, 이미지와 flavor, tenant 리소스 검증이 필요합니다.

# OpenShift 계층
oc get co
oc get nodes -o wide
oc get mcp
oc get events -A --sort-by=.lastTimestamp | tail -n 120

# RHOSO 계층
oc -n openstack get openstackcontrolplane,openstackdataplanenodeset,openstackdataplanedeployment
oc -n openstack get pods -o wide
oc -n openstack get jobs --sort-by=.metadata.creationTimestamp

# OpenStack 서비스 계층
openstack token issue
openstack service list
openstack endpoint list
openstack compute service list
openstack network agent list
openstack volume service list

9. RHOSP 17.1에서 넘어갈 때는 adoption을 별도 프로젝트로 봐야 한다

RHOSP 17.1 환경을 RHOSO 18로 넘기는 작업은 단순 업그레이드가 아닙니다. 공식 문서도 RHOSP 17.1 deployment adoption, director Operator environment adoption, Nmstate provider migration, VM migration을 별도 문서 흐름으로 나눕니다. 기존 cloud의 네트워크와 storage, compute role, instance HA, 운영 절차를 그대로 새 control plane에 얹을 수 있는지 사전에 검증해야 합니다.

Adoption 전에 먼저 분리해서 확인할 항목

- 기존 RHOSP 17.1 서비스 버전과 현재 누적 패치 수준
- undercloud/director에 남아 있는 역할과 Heat 템플릿 의존성
- neutron 네트워크, provider network, VLAN, routed spine-leaf 설계
- nova compute host, instance HA, evacuation 기준
- cinder/glance/swift/manila 백엔드와 backend별 adoption 지원 여부
- os-net-config/ifcfg에서 Nmstate 전환이 필요한 범위
- 장애 시 rollback 지점과 tenant 영향 범위

10. 운영자가 헷갈리면 안 되는 기준

• RHOSO 18은 OpenStack을 버리는 것이 아니라 OpenStack control plane 운영 방식을 OpenShift 위로 옮기는 변화입니다.
• OpenStack API 장애처럼 보여도 OpenShift Operator, OLM, network, storage, certificate 문제가 원인일 수 있습니다.
• Data plane은 선언만으로 끝나지 않고 실제 RHEL 노드, Ansible 실행, systemd 서비스, NIC/storage 상태까지 확인해야 합니다.
• 네트워크는 OpenShift network, RHOSO control plane network, data plane network, tenant/provider network를 분리해서 설계해야 합니다.
• RHOSP 17.1에서 넘어가는 작업은 업그레이드가 아니라 adoption/migration 프로젝트로 계획해야 합니다.

정리

RHOSO 18의 핵심은 OpenStack을 OpenShift 위에서 운영 가능한 control plane으로 재구성했다는 점입니다. 그래서 운영자는 OpenStack CLI와 서비스 로그만 보는 방식에서 벗어나 OpenShift Operator, CRD, Pod, route, storage, network, data plane deployment 상태를 함께 읽어야 합니다. 새 환경을 구축하든 기존 RHOSP 17.1을 넘기든, 먼저 control plane과 data plane 경계를 명확히 나누고 네트워크와 storage 설계를 고정한 뒤 검증 명령을 계층별로 쌓아가는 방식이 안전합니다.

참고한 공식 문서

• Red Hat RHOSO 18.0 Release notes
• Red Hat RHOSO 18.0 Planning your deployment
• Red Hat RHOSO 18.0 documentation index
• Deploying Red Hat OpenStack Services on OpenShift
• Adopting a Red Hat OpenStack Platform 17.1 deployment
• Validating and troubleshooting the deployed cloud