OCP를 운영자 관점으로 이해한다는 것

OCP를 안다는 것은 콘솔에서 Pod를 보는 정도가 아니라, 클러스터가 어떤 계층으로 살아 있고 어디가 깨졌을 때 어떤 증거를 먼저 볼지 설명할 수 있다는 뜻에 가깝습니다. OCP는 Kubernetes 위에 얹힌 제품명만이 아니라 설치 입력, RHCOS 노드, ClusterOperator, MachineConfig, 네트워크/Route, OLM, 이미지 레지스트리, GitOps 배포, 장애 증거가 맞물린 플랫폼으로 봐야 합니다.

1. 설치 결과보다 설치 입력을 먼저 본다

OCP 설치를 볼 때는 설치가 끝났는지보다 어떤 입력으로 클러스터가 만들어졌는지를 먼저 확인합니다. DNS, VIP, install-config, agent ISO 또는 IPI/UPI 방식, 이미지 pull 준비, bootstrap 완료 지점, API/Ingress 접근 경로가 맞아야 설치 결과도 해석할 수 있습니다.

예를 들어 SNO 환경에서는 bastion이 DNS, installer, 검증 호스트 역할을 함께 맡을 수 있습니다. 이 경우 API, api-int, wildcard apps, node hostname이 같은 방향을 가리키는지 확인하고, 설치 후에는 ISO 부팅 루프처럼 가상화 계층에서 생기는 문제도 같이 봐야 합니다.

openshift-install version
openshift-install agent wait-for bootstrap-complete --dir ./install-dir
openshift-install agent wait-for install-complete --dir ./install-dir

curl -k https://api.example.lab:6443/readyz
oc whoami
oc get clusterversion
oc get nodes -o wide
oc get co

2. ClusterOperator 상태를 플랫폼 건강도로 본다

OCP에서 애플리케이션 Pod만 보면 플랫폼 상태를 놓치기 쉽습니다. 실제 운영 판단은 ClusterVersion, ClusterOperator, node, MCP, 이벤트를 같이 봐야 합니다. ClusterOperator가 Available=False 또는 Degraded=True이면 애플리케이션 장애처럼 보이는 증상이 플랫폼 계층에서 시작됐을 수 있습니다.

oc get clusterversion
oc get co
oc get co | awk 'NR==1 || $3!="True" || $4!="False" || $5!="False"'
oc describe co authentication
oc describe co ingress
oc describe co monitoring
oc get events -A --sort-by=.lastTimestamp | tail -n 80

3. RHCOS와 MachineConfig를 노드 운영의 중심으로 본다

OCP 4.x 노드는 일반 Linux 서버처럼 yum으로 하나씩 고치는 방식이 아니라, Machine Config Operator와 RHCOS 변경 흐름으로 관리됩니다. kubelet, CRI-O, systemd, kernel argument, 파일 배포 같은 변경은 MachineConfig/MachineConfigPool 상태와 노드 reboot 흐름까지 같이 봐야 합니다.

oc get mcp
oc describe mcp worker
oc get machineconfig | head
oc get nodes
oc adm node-logs <node-name> --path=journal
oc debug node/<node-name>
chroot /host
systemctl status kubelet
journalctl -u kubelet -n 120 --no-pager

4. 네트워크는 Pod 통신과 외부 노출을 분리해서 본다

OCP 네트워크 문제는 Pod 내부 통신, Service, Route/Ingress, DNS, NetworkPolicy, 노드 방화벽 중 어디인지 분리해야 합니다. Route가 안 열린다고 바로 애플리케이션 문제로 보면 안 되고, Service endpoint와 router pod, IngressController 상태를 차례로 확인해야 합니다.

oc get network.operator cluster -o yaml
oc -n openshift-ingress-operator get ingresscontroller
oc -n openshift-ingress get pods -o wide
oc get route -A
oc get svc,endpoints -n <namespace>
oc describe route <route-name> -n <namespace>
oc run netcheck --rm -it --image=registry.access.redhat.com/ubi9/ubi -- bash
curl -sv http://service-name.namespace.svc.cluster.local:8080/healthz

5. OLM과 Operator 카탈로그를 Day-2 운영 이슈로 본다

Operator 설치는 버튼 클릭이 아니라 CatalogSource, Subscription, InstallPlan, CSV 상태가 이어지는 흐름입니다. 특히 disconnected 또는 restricted 환경에서는 release payload mirror와 Operator catalog mirror가 다릅니다. release image를 mirror했다고 해서 OperatorHub 카탈로그까지 안정화됐다고 말하면 안 됩니다.

oc get operatorhub cluster -o yaml
oc -n openshift-marketplace get catalogsource
oc -n openshift-marketplace get pods
oc get sub -A
oc get installplan -A
oc get csv -A
oc describe csv <csv-name> -n <namespace>

# disconnected 점검 예시
oc get imagecontentsourcepolicy
oc get imagedigestmirrorset
oc get imagecontentsourcepolicy -o yaml

OCP catalog 이슈는 "카탈로그 Pod가 죽는다"에서 멈추지 않고, 어떤 CatalogSource 이미지가 외부 registry를 보고 있는지, 내부 mirror 이미지의 cache가 유효한지, 현재 설치된 CSV가 실제 서비스에 필요한 live catalog에 의존하는지까지 분리해야 합니다.

6. 배포는 Deployment 성공이 아니라 Route 검증까지 본다

OCP 위 CI/CD를 설명할 때는 Git push에서 끝나지 않습니다. 소스 검증, 이미지 빌드, registry push, manifest 검사, Argo CD sync, rollout, Route HTTP 검증까지 하나의 사이클로 봐야 합니다. Tekton이나 GitOps를 쓰더라도 최종 성공 기준은 사용자가 접근하는 Route 또는 health endpoint가 정상인지입니다.

Git repository
  -> Tekton PipelineRun
  -> test / quality gate
  -> image build and push
  -> manifest or GitOps update
  -> Argo CD sync
  -> OCP Deployment rollout
  -> Service and Route validation
  -> HTTP 200 / healthz evidence

oc -n <app-namespace> get deploy,rs,pod,svc,route
oc -n <app-namespace> rollout status deployment/<app-name> --timeout=180s
oc -n <app-namespace> describe route <app-route>
curl -fsS http://<route-host>/healthz

# GitOps를 쓴다면 desired/live 상태를 같이 본다.
argocd app get <app-name>
argocd app sync <app-name>

7. 장애 분석은 증거 순서를 정해서 본다

OCP 장애를 볼 때는 증상을 바로 수정하지 않고, 증거 순서를 정합니다. 전체 클러스터 상태, 노드 상태, operator 상태, namespace 이벤트, workload 상태, 로그, 네트워크, storage, registry pull, quota/limit 순서로 좁혀가면 불필요한 변경을 줄일 수 있습니다.

oc get clusterversion
oc get co
oc get nodes
oc get mcp
oc get events -A --sort-by=.lastTimestamp | tail -n 120

NS=<namespace>
APP=<app>
oc -n ${NS} get deploy,rs,pod,svc,route,pvc
oc -n ${NS} describe pod -l app=${APP}
oc -n ${NS} logs deploy/${APP} --tail=200
oc -n ${NS} get quota,limitrange
oc adm must-gather

8. OCP 운영에서 강조할 기준

• OCP는 Kubernetes 리소스만이 아니라 ClusterOperator와 MachineConfig가 함께 움직이는 플랫폼입니다.
• SNO, compact, multi-node, disconnected 환경은 같은 명령을 써도 실패 원인이 다르게 나옵니다.
• Route 문제는 애플리케이션, Service, endpoint, IngressController, DNS를 분리해서 봐야 합니다.
• Operator 설치 문제는 CatalogSource, Subscription, InstallPlan, CSV, mirror registry를 한 흐름으로 봐야 합니다.
• CI/CD 성공은 PipelineRun 성공이 아니라 OCP rollout과 Route health 검증까지 포함해야 합니다.

정리

OCP를 운영한다는 것은 Pod, Deployment, Route만 따로 보는 일이 아닙니다. 설치 입력과 DNS, ClusterOperator, MCO/RHCOS, Route/Ingress, OLM catalog, disconnected mirror, Tekton/GitOps 배포, must-gather 기반 장애 분석을 하나의 흐름으로 연결해서 보는 일입니다. 장애가 발생했을 때는 먼저 계층을 나누고, 그 다음 명령과 로그로 증거를 좁혀야 불필요한 변경을 줄일 수 있습니다.

공식 문서 링크

• Red Hat OCP architecture documentation
• Red Hat OCP Machine configuration
• Red Hat OCP Operators overview
• Red Hat OCP networking and Routes
• Red Hat OCP monitoring overview
• Red Hat OCP troubleshooting