목표는 도구 이름을 많이 늘어놓는 것이 아니라, 이 조합이 왜 요즘 플랫폼 엔지니어링 흐름과 맞는지 보는 것입니다. CI는 Tekton 쪽으로, CD는 Argo CD와 Rollouts 쪽으로, registry는 Harbor 기반 trust hub 쪽으로 역할이 나뉘고 있습니다.

1. Kubernetes 기반 CI/CD에서 자주 조합되는 구성

2. 오픈소스 기준으로 보는 각 컴포넌트

이 조합을 볼 때 중요한 것은 "이름이 유명한가"보다 "오픈소스 생태계에서 어떤 문제를 맡고 있는가"입니다. 같은 CI/CD라는 말 안에서도 Git forge, pipeline runtime, GitOps controller, registry, policy gate, 접근 제어가 맡는 계층은 서로 다릅니다.

3. 대체와 보완 트렌드도 같이 봐야 합니다

대체재는 "무엇이 더 좋다"보다 운영 모델의 차이로 보는 편이 낫습니다. Kubernetes-native로 갈수록 선언형 리소스, controller, GitOps, policy-as-code 쪽이 강해지고, forge-integrated CI로 갈수록 개발자 경험과 초기 도입 속도가 강해집니다.

4. 가장 트렌드성이 큰 축은 Tekton + GitOps입니다

이 조합의 핵심은 Tekton을 CI 실행면으로 두고 Argo CD를 CD/GitOps 면으로 둔 점입니다. Tekton은 Pipeline과 Task를 Kubernetes CRD로 다루기 때문에 pipeline 실행 자체가 클러스터 리소스가 됩니다. Argo CD는 Git 저장소의 desired state와 클러스터 live state를 비교하고, drift를 보여주며, sync를 통해 상태를 맞춥니다.

이 구조가 중요한 이유는 CI/CD가 더 이상 별도 서버 하나에서 shell script를 돌리는 방식으로만 남지 않는다는 점입니다. PipelineRun, TaskRun, Application, Rollout 같은 리소스가 모두 Kubernetes API로 관찰되고, 권한/RBAC/namespace/storage/logging 정책을 같은 운영 모델 안에서 다룰 수 있습니다.

Git commit
 -> Tekton PipelineRun
 -> build / test / scan / image push
 -> Harbor image digest
 -> GitOps manifest update
 -> Argo CD sync
 -> Kubernetes rollout
 -> route or health endpoint verification

5. Tekton Resolvers는 pipeline catalog 운영의 다음 단계입니다

Tekton 기반 pipeline을 운영하다 보면 Maven, Gradle, npm, pnpm, Kaniko, ArgoCD sync, SonarQube scanner, Trivy, Polaris, ZAP 같은 task/pipeline 자산이 늘어납니다. 여기서 최신 방향은 모든 Task를 클러스터 안에 복사해 두는 방식보다, Git 또는 OCI registry에 둔 표준 Task를 resolver로 참조하는 쪽입니다.

Tekton 공식 문서도 Remote Resolution을 통해 클러스터 밖 원격 소스의 Task와 Pipeline을 가져올 수 있다고 설명합니다. 이런 환경에서는 공통 보안 스캔, 이미지 빌드, ArgoCD sync, ingress 검증 같은 task를 공용 Git repo나 OCI artifact로 관리하면, 애플리케이션별 pipeline은 공통 task version만 고정해서 참조할 수 있습니다.

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
 generateName: app-release-
spec:
 pipelineRef:
 resolver: git
 params:
 - name: url
 value: https://git.example.com/platform/pipeline-catalog.git
 - name: revision
 value: main
 - name: pathInRepo
 value: pipelines/build-scan-gitops.yaml

6. Tekton Chains와 Results는 증거 중심 CI/CD로 가는 길입니다

앞으로 CI/CD에서 중요한 것은 "빌드가 성공했다"가 아니라 "무슨 소스, 어떤 의존성, 어떤 runner, 어떤 task, 어떤 이미지 digest로 만들어졌는가"입니다. Tekton Chains는 TaskRun/PipelineRun 실행을 관찰해 provenance와 attestation을 만들고, 서명한 뒤 저장하는 방향의 컴포넌트입니다. SLSA provenance는 산출물이 어떤 과정으로 만들어졌는지 설명하는 표준 메타데이터입니다.

Tekton Results는 실행 이력과 로그를 Pipeline controller 수명과 분리해 장기 보관하고 검색하는 축입니다. 이 둘을 강화하면 장애 분석, 릴리스 감사, 이미지 출처 검증이 "사람이 기억으로 추적하는 상태"에서 "query 가능한 실행 증거"로 이동합니다.

PipelineRun evidence model
- source repository and revision
- Pipeline / Task version
- input artifacts and dependencies
- output image digest
- vulnerability and quality gate result
- Argo CD application revision
- rollout and health check result

7. Harbor는 이미지 저장소에서 artifact trust hub로 이동 중입니다

Harbor는 private registry와 mirror 역할을 합니다. 최신 흐름에서는 여기서 한 단계 더 나아가 이미지, SBOM, signature, vulnerability scan 결과를 함께 관리하는 artifact trust hub가 됩니다. Harbor 공식 문서에는 SBOM 생성/복제, Cosign 또는 Notation 기반 artifact signing, vulnerability scan, tag immutability, robot account 같은 기능이 분리되어 있습니다.

예를 들어 release 이미지는 tag보다 digest 기준으로 배포하고, 이미지와 함께 SBOM과 signature를 붙이는 식으로 운영할 수 있습니다. 그러면 단순히 "이미지가 registry에 있다"가 아니라 "이 이미지는 어떤 pipeline에서 만들었고, 어떤 취약점 상태였고, 어떤 정책으로 배포 허용됐는지"를 설명할 수 있습니다.

Recommended Harbor policy direction
- immutable release tags
- digest-based deployment
- robot account per pipeline scope
- scan on push and scheduled rescan
- SBOM attached to image artifact
- signature attached to image artifact
- temporary allowlist with expiry only

8. Argo Rollouts는 "배포 완료"를 "점진적 검증"으로 바꿉니다

Kubernetes Deployment의 rolling update는 기본 안전장치로 충분한 경우가 많지만, 점진적 트래픽 전환과 metric 기반 자동 판단에는 한계가 있습니다. Argo Rollouts는 blue-green, canary, canary analysis, progressive delivery를 Kubernetes CRD로 제공하고, 배포 과정을 더 작게 나눠 검증할 수 있게 합니다.

트렌드 관점에서 Rollouts의 핵심은 배포가 한 번에 끝나는 이벤트가 아니라, 작은 트래픽 단위로 검증하고 문제가 있으면 자동 중단하거나 rollback하는 과정이라는 점입니다. Prometheus, Grafana, Kiali 같은 관찰 계층과 연결하면 배포 품질을 사람이 눈으로만 판단하지 않아도 됩니다.

9. SonarQube와 Trivy는 "나중에 검사"가 아니라 pipeline gate입니다

SonarQube는 전체 legacy code를 한 번에 다 고치자는 도구로 쓰면 금방 병목이 됩니다. 공식 문서의 Clean as You Code 방향처럼 새 코드 기준 quality gate를 우선 적용해야 합니다. PR 또는 main merge 시점에 new code의 bug, vulnerability, security hotspot, duplication, coverage 기준을 fail-fast gate로 두는 것이 현실적입니다.

Trivy는 이미지 취약점만 보는 도구가 아니라 SBOM, filesystem, Git repository, Kubernetes까지 폭넓게 스캔할 수 있는 scanner입니다. Trivy/Polaris/ZAP task를 pipeline catalog에 넣으면 보안 검사를 별도 프로젝트가 아니라 delivery flow 안에서 실행할 수 있습니다.

Pipeline gate order
1. source structure check
2. unit or smoke test
3. SonarQube new-code quality gate
4. image build with fixed tag and digest capture
5. Trivy vulnerability / SBOM scan
6. Polaris or policy check for Kubernetes manifests
7. Argo CD sync
8. rollout and route health verification

10. OAuth2 Proxy와 OIDC는 운영 UI 보호의 현실적인 축입니다

Tekton Dashboard, Prometheus, Alertmanager 같은 운영 UI를 OAuth2 Proxy와 OIDC provider로 보호하는 방향은 현실적입니다. 다만 reverse proxy 구성에서는 trusted proxy IP와 forwarded header 신뢰 경계를 정확히 잡아야 합니다. OAuth2 Proxy 공식 문서도 reverse proxy 사용 시 trusted proxy IP 설정을 주의하라고 경고합니다.

운영 트렌드는 모든 도구가 각자 계정을 들고 있는 구조에서, 중앙 IdP 중심으로 로그인과 그룹/RBAC를 맞추는 구조로 이동합니다. 최소한 CI/CD UI 표면은 같은 SSO 경계 안으로 묶는 것이 좋습니다.

11. 기반 컴포넌트와 트렌드 컴포넌트를 구분해야 합니다

모든 구성요소가 "트렌드 컴포넌트"는 아닙니다. Git forge, artifact repository, ingress controller, load balancer, storage, DNS는 트렌드라기보다 플랫폼을 굴러가게 하는 기반입니다. 반대로 Tekton Chains/Results, Resolvers, Argo CD, Argo Rollouts, Harbor SBOM/signing, SonarQube new-code gate, Trivy SBOM/Kubernetes scanning, OAuth2 Proxy SSO는 앞으로 운영 성숙도를 올리는 방향성과 직접 연결됩니다.

12. 추천하는 이동 순서

1. 이미지 태그 기준 정리: 개발, 검증, 운영 배포에서 tag와 digest를 어떤 기준으로 쓸지 먼저 정합니다.
2. Pipeline catalog를 resolver 기준으로 정리: 공통 Task/Pipeline을 Git repo 또는 OCI artifact 기준으로 version pinning합니다.
3. Results를 기본 증거 저장소로 둠: PipelineRun 성공/실패, 로그, artifact digest, 배포 결과를 장기 조회 가능하게 둡니다.
4. Chains + Harbor signature/SBOM 연결: build provenance, image digest, SBOM, signature를 릴리스 증거로 묶습니다.
5. GitOps sync와 Rollouts를 표준 CD로 둠: kubectl apply 중심 배포는 smoke나 긴급 lane으로 좁히고, 운영 배포는 Argo CD와 Rollouts로 보냅니다.
6. 품질/보안 gate를 fail-fast로 만듦: SonarQube new-code gate, Trivy/SBOM scan, Polaris manifest check를 통과 기준으로 둡니다.
7. SSO와 credential 주입 경계 정리: UI 표면은 OIDC/RBAC로 묶고, pipeline credential은 Secret manager나 Kubernetes Secret을 통해 주입합니다.

정리

Kubernetes 기반 CI/CD에서 중요한 구성 요소는 "새 도구를 더 설치하는 것"보다 "각 도구의 운영 역할을 명확히 나누는 것"에 가깝습니다. Tekton은 Kubernetes-native CI 실행면, Argo CD는 GitOps desired state, Argo Rollouts는 progressive delivery, Harbor는 SBOM/signature/vulnerability 중심 trust hub, SonarQube와 Trivy는 quality/security gate, OAuth2 Proxy와 OIDC는 운영 UI 보호면으로 보면 됩니다.

따라서 다음 개선 방향은 단순 기능 추가가 아니라 증거 중심 배포입니다. 어떤 commit이 어떤 PipelineRun으로 어떤 digest를 만들었고, 어떤 SBOM과 scan 결과를 통과했으며, 어떤 Argo CD revision으로 어떤 health check를 확인했는지 남기는 구조가 Kubernetes 기반 CI/CD의 다음 단계입니다.

공식 문서 링크

• Gitea documentation
• Forgejo and forge comparison
• Tekton overview
• Tekton Chains SLSA provenance
• Tekton Results API
• Tekton Pipeline Remote Resolution
• Jenkins documentation
• Argo CD GitOps overview
• Flux documentation
• Argo Rollouts progressive delivery
• Flagger progressive delivery
• Harbor overview
• Harbor SBOM integration
• Harbor artifact signing
• Sigstore Cosign keyless signing
• SonarQube Community Build
• SonarQube Clean as You Code
• Trivy SBOM scanning
• Anchore Syft and Grype
• Semgrep documentation
• CodeQL documentation
• Kyverno introduction
• OPA Gatekeeper introduction
• OAuth2 Proxy reverse proxy configuration

공인 인터넷풀에서 Virtual Router와 VM NIC까지 트래픽이 어디에서 멈추는지 확인하는 절차입니다. 명령은 승인된 장애 대응 대상에서만 실행합니다. 명령은 본인에게 권한이 있는 시스템과 승인된 장애 대응 범위 안에서만 실행해야 합니다.

1. 전체 경로를 한 줄로 고정한다

처음부터 장비별 담당자에게 흩어져 물으면 시간이 오래 걸립니다. 먼저 패킷이 지나야 하는 경로를 한 줄로 적고, 각 구간마다 “봤다/못 봤다”를 채우는 방식으로 좁혀야 합니다.

Internet client
  -> ISP / external routing
  -> edge router / upstream firewall
  -> public internet pool / VIP / floating IP
  -> internal L3 gateway or firewall
  -> Virtual Router / NAT gateway external interface
  -> DNAT / SNAT / policy route / conntrack
  -> Virtual Router / NAT gateway internal interface
  -> hypervisor bridge / OVS / tap-vif
  -> VM NIC
  -> OS firewall / service socket

이 경로를 써 놓으면 “공인풀 문제인지”, “내부 방화벽 문제인지”, “가상화 구간 문제인지”를 감으로 말하지 않게 됩니다. 같은 5-tuple을 각 지점에서 확인하는 것이 핵심입니다.

2. 추적 튜플과 관측 지점을 먼저 정한다

장애 설명을 “접속 안 됨”으로 두면 캡처 결과를 서로 비교할 수 없습니다. 출발지, 목적 공인 IP, 포트, DNAT 후 사설 IP, 가상 NIC의 MAC, 하이퍼바이저 브리지를 먼저 고정합니다.

client            : 198.51.100.50
public pool       : 203.0.113.0/24
public IP         : 203.0.113.10
protocol/port     : tcp/443
internal transit  : 172.16.10.0/24
nat external      : eth2
nat internal      : eth0
vm private IP     : 10.10.0.25
vm mac            : 52:54:00:aa:bb:cc
hypervisor bridge : br-int / qbr / vif
service           : 10.10.0.25:443

특정 출발지만 실패하는지, 전체 출발지가 실패하는지, 같은 공인 풀의 다른 IP는 정상인지도 같이 적습니다. 이 세 가지가 없으면 라우팅, 방화벽, NAT, VM 서비스 중 어디를 먼저 봐야 하는지 흔들립니다.

3. 공인 인터넷풀과 엣지에서 먼저 본다

공인 IP가 클라우드 포털에 할당되어 있어도 외부 경로에서 그 prefix가 제대로 광고되고, 엣지 장비가 해당 IP를 알고, 상단 방화벽 세션이 만들어지는지는 별도 문제입니다. 먼저 공인풀과 엣지에서 패킷 진입 여부를 확인합니다.

CLIENT=198.51.100.50
PUBLIC_IP=203.0.113.10
PUBLIC_POOL=203.0.113.0/24
PORT=443

# 외부 테스트 지점에서 증상을 먼저 고정한다.
traceroute -n -T -p "${PORT}" "${PUBLIC_IP}"
mtr -n -T -P "${PORT}" "${PUBLIC_IP}"
nc -vz -w 3 "${PUBLIC_IP}" "${PORT}"

# Linux edge 또는 route reflector에서 보는 기본 확인 예시.
ip route get "${PUBLIC_IP}"
ip route show table all | grep -E "203\.0\.113|default"
ip neigh show | grep "${PUBLIC_IP}" || true

# 네트워크 장비 CLI는 장비별 문법이 다르므로 같은 항목을 확인한다.
show ip route 203.0.113.10
show ip bgp 203.0.113.0/24
show arp | include 203.0.113.10
show firewall session source 198.51.100.50 destination 203.0.113.10 destination-port 443

여기서 중요한 것은 “라우트가 있다” 하나로 끝내지 않는 것입니다. prefix 광고, next-hop, ARP/ND, 방화벽 세션, deny counter, return route를 같이 봐야 합니다. 특히 outbound return route가 다른 장비로 빠지면 외부에서는 timeout으로만 보입니다.

4. 엣지 outside/inside는 동시에 캡처한다

엣지 outside에서 SYN이 보이는데 inside로 안 넘어가면 엣지 방화벽, VIP/FIP, NAT, 정책 라우팅 문제입니다. outside에서도 안 보이면 클라이언트, ISP, upstream route 쪽입니다. 두 지점을 같은 시각에 잡아야 말이 갈리지 않습니다.

CLIENT=198.51.100.50
PUBLIC_IP=203.0.113.10
PORT=443
STAMP=$(date +%Y%m%d_%H%M%S)

timeout 90 tcpdump -nn -s0 -B 8192 -i edge-outside \
  "host ${CLIENT} and host ${PUBLIC_IP} and tcp port ${PORT}" \
  -w /var/tmp/edge-outside-${STAMP}.pcap &

timeout 90 tcpdump -nn -s0 -B 8192 -i edge-inside \
  "host ${CLIENT} and host ${PUBLIC_IP} and tcp port ${PORT}" \
  -w /var/tmp/edge-inside-${STAMP}.pcap &

wait

tcpdump -nn -r /var/tmp/edge-outside-${STAMP}.pcap | head -n 40
tcpdump -nn -r /var/tmp/edge-inside-${STAMP}.pcap | head -n 40

캡처는 화면 몇 줄보다 pcap으로 남기는 편이 낫습니다. 장애가 끝난 뒤에도 SYN, SYN-ACK, RST, ICMP fragmentation needed, TTL 변화를 다시 볼 수 있기 때문입니다.

5. 내부 L3/방화벽 구간은 정책 라우팅과 역방향을 본다

엣지 안쪽까지 들어온 패킷이 NAT/Virtual Router로 가지 않으면 내부 구간입니다. 이때는 목적지로 가는 forward route만 보지 말고, 출발지로 돌아가는 return path와 policy routing을 같이 봐야 합니다.

PUBLIC_IP=203.0.113.10
PRIVATE_IP=10.10.0.25
TRANSIT_SRC=172.16.10.10
PORT=443

ip route get "${PRIVATE_IP}" from "${TRANSIT_SRC}"
ip rule show
ip route show table all | grep -E "203\.0\.113|172\.16\.10|10\.10\.0"

nft list ruleset | grep -E "203\.0\.113|172\.16\.10|10\.10\.0|dport ${PORT}" || true
iptables-save -t nat | grep -E "203\.0\.113|10\.10\.0|dport ${PORT}" || true
iptables-save -t filter | grep -E "203\.0\.113|10\.10\.0|dport ${PORT}|DROP|REJECT" || true

conntrack -L -p tcp 2>/dev/null | grep -E "203\.0\.113\.10|10\.10\.0\.25|dport=${PORT}|sport=${PORT}" | head -n 80

비대칭 경로는 흔한 함정입니다. 들어오는 길은 A 방화벽인데 나가는 길은 B 라우터라면 conntrack 기반 장비는 세션을 못 맞추고 drop할 수 있습니다. 내부 ACL counter가 증가하는지, default route보다 더 구체적인 route가 있는지도 같이 봅니다.

6. NAT/Virtual Router에서는 NAT 전후를 분리한다

Virtual Router나 NAT gateway에서는 external interface의 공인 IP 흐름과 internal interface의 사설 IP 흐름이 같은 요청인지 연결해야 합니다. external에만 있고 internal에 없으면 NAT, filter, interface mapping, conntrack 문제로 좁혀집니다.

CLIENT=198.51.100.50
PUBLIC_IP=203.0.113.10
PRIVATE_IP=10.10.0.25
PORT=443
STAMP=$(date +%Y%m%d_%H%M%S)

ip -br addr
ip route

timeout 90 tcpdump -nn -s0 -B 8192 -i eth2 \
  "host ${CLIENT} and host ${PUBLIC_IP} and tcp port ${PORT}" \
  -w /root/nat-ext-${STAMP}.pcap &

timeout 90 tcpdump -nn -s0 -B 8192 -i eth0 \
  "host ${CLIENT} and host ${PRIVATE_IP} and tcp port ${PORT}" \
  -w /root/nat-int-${STAMP}.pcap &

wait

tcpdump -nn -r /root/nat-ext-${STAMP}.pcap | head -n 40
tcpdump -nn -r /root/nat-int-${STAMP}.pcap | head -n 40

동시에 rule과 counter도 봅니다. rule 존재 여부만 보면 안 됩니다. 테스트 전후로 packet/byte counter가 증가해야 실제 트래픽이 그 rule을 탄 것입니다.

PUBLIC_IP=203.0.113.10
PRIVATE_IP=10.10.0.25
PORT=443

iptables-save -t nat | grep -E "${PUBLIC_IP}|${PRIVATE_IP}|dport ${PORT}|--dport ${PORT}"
iptables-save -t filter | grep -E "${PUBLIC_IP}|${PRIVATE_IP}|dport ${PORT}|--dport ${PORT}|DROP|REJECT"

iptables -t nat -L PREROUTING -nv --line-numbers | grep -E "${PUBLIC_IP}|${PORT}"
iptables -L -nv --line-numbers | grep -E "${PRIVATE_IP}|${PORT}|DROP|REJECT"

cat /proc/sys/net/netfilter/nf_conntrack_count 2>/dev/null
cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null
conntrack -S 2>/dev/null || true
conntrack -L -p tcp 2>/dev/null | grep -E "${PUBLIC_IP}|${PRIVATE_IP}|dport=${PORT}|sport=${PORT}" | head -n 80

운영 중에는 오래된 interface 정보나 stale NAT rule도 확인해야 합니다. 공인 subnet은 현재 eth2에 있는데 DNAT rule이 과거 eth3 기준으로 만들어져 있으면 rule은 있어도 패킷이 안 맞습니다. conntrack table이 가득 찬 상황도 포트포워딩 장애처럼 보일 수 있습니다.

7. 하이퍼바이저 가상구간은 bridge, OVS, tap/vif까지 본다

NAT internal에서 VM 사설 IP로 나간 패킷이 하이퍼바이저 브리지에서 보이는데 VM NIC에서 안 보이면 가상 스위치 구간입니다. KVM이면 tap/qbr/br-int, OVS면 port와 flow, Xen 계열이면 vif 상태와 host 로그를 봅니다.

PRIVATE_IP=10.10.0.25
VM_MAC=52:54:00:aa:bb:cc
PORT=443

ip -br link
bridge link show
bridge fdb show | grep -i "${VM_MAC}" || true

ovs-vsctl show
ovs-ofctl dump-flows br-int | grep -Ei "10\.10\.0\.25|52:54:00:aa:bb:cc|nw_dst|nw_src" || true

timeout 60 tcpdump -nn -s0 -B 8192 -i br-int \
  "host ${PRIVATE_IP} and tcp port ${PORT}" \
  -w /var/tmp/hv-br-int-${PRIVATE_IP}.pcap

# tap/vif/qbr 이름을 찾은 뒤 VM 포트 직전에서도 한 번 더 본다.
timeout 60 tcpdump -nn -s0 -B 8192 -i <tap-or-vif-interface> \
  "host ${PRIVATE_IP} and tcp port ${PORT}" \
  -w /var/tmp/hv-vif-${PRIVATE_IP}.pcap

여기서는 VM IP만으로 부족할 수 있습니다. VM MAC, tap/vif 이름, security group chain, OVS flow, bridge FDB를 묶어 봐야 “브리지까지 왔는데 VM 포트로 못 갔다”를 증명할 수 있습니다.

8. VM NIC까지 들어오면 OS와 서비스 문제로 전환한다

VM의 eth0에서 SYN이 보이고 VM이 RST를 보내면 네트워크 경로는 VM까지 도달한 것입니다. 그 다음은 OS firewall, listen socket, 서비스 바인딩, 애플리케이션 로그입니다.

CLIENT=198.51.100.50
PRIVATE_IP=10.10.0.25
PORT=443

ip -br addr
ip route
ss -lntp | grep ":${PORT}\b" || true

nft list ruleset | grep -E "dport ${PORT}|${CLIENT}|${PRIVATE_IP}|drop|reject" || true
iptables -S | grep -E "dport ${PORT}|${CLIENT}|${PRIVATE_IP}|DROP|REJECT" || true

timeout 60 tcpdump -nn -s0 -B 8192 -i eth0 \
  "host ${CLIENT} and tcp port ${PORT}" \
  -w /tmp/vm-eth0-${PORT}.pcap

curl -vk "https://127.0.0.1:${PORT}/" --connect-timeout 3
curl -vk "https://${PRIVATE_IP}:${PORT}/" --connect-timeout 3

VM 안에서 tcpdump가 보이는데 서비스가 응답하지 않으면 포털의 공인 IP 설정이나 상단 라우팅을 계속 볼 이유가 줄어듭니다. 반대로 VM 안에서는 아무것도 안 보이는데 하이퍼바이저 브리지에는 보이면 가상 NIC 전 단계로 돌아갑니다.

9. 관측 결과로 구간을 바로 판정한다

아래 표처럼 관측 결과를 구간 판정으로 바꿔야 다음 액션이 빨라집니다. 중요한 것은 한 지점의 로그가 아니라, 같은 시간대의 여러 지점 캡처가 서로 이어지는지입니다.

10. SYN은 보이는데 끊기면 MTU와 fragment를 본다

터널, VXLAN, Geneve, GRE, IPSec, 방화벽 장비가 섞인 구간에서는 handshake 일부만 보이고 payload에서 멈추는 장애가 나옵니다. 이때는 MTU, MSS clamp, ICMP fragmentation needed 차단 여부를 같이 봅니다.

PUBLIC_IP=203.0.113.10
PRIVATE_IP=10.10.0.25

ping -M do -s 1472 "${PUBLIC_IP}"
tracepath -n "${PUBLIC_IP}"

tcpdump -nn -s0 -i any \
  "icmp or (host ${PUBLIC_IP} and (tcp[tcpflags] & (tcp-syn|tcp-rst) != 0))"

# 터널/VXLAN/오버레이 구간이면 VM MSS clamp 또는 path MTU blackhole 여부를 같이 본다.
ip link show | grep -E "mtu|vxlan|geneve|gre|tun"

MTU 문제는 “가끔 됨”, “작은 응답은 됨”, “TLS handshake에서 멈춤”처럼 보일 수 있습니다. 단순 포트 오픈 확인으로는 놓치기 쉽습니다.

11. 장애 보고는 구간과 근거로 끝낸다

보고서는 길게 쓰는 것보다, 어느 구간까지 봤고 어디서 끊겼는지를 명확히 남기는 것이 중요합니다. 아래 형식이면 네트워크, 방화벽, 가상화, OS 담당자가 같은 증거를 기준으로 움직일 수 있습니다.

증상
  - 198.51.100.50 -> 203.0.113.10:443 접속 실패
  - 같은 공인 풀의 다른 IP 또는 다른 출발지는 정상 여부:

고정한 경로
  - public pool / public IP:
  - edge outside / inside:
  - internal transit:
  - NAT external / internal:
  - hypervisor bridge / VM port:
  - VM NIC / service:

동시 캡처 판정
  - edge outside:
  - edge inside:
  - internal L3:
  - NAT external:
  - NAT internal:
  - hypervisor bridge:
  - VM NIC:

rule/counter/session
  - route or policy route:
  - firewall/ACL counter:
  - DNAT/SNAT rule and counter:
  - conntrack state:
  - OVS/bridge port state:
  - VM listen/firewall:

결론
  - 끊기는 구간:
  - 근거:
  - 임시 조치:
  - 영구 조치:
  - 재현 테스트 결과:

정리

공인 인터넷풀부터 내부 구간, 가상구간까지 이어지는 장애는 포털 화면이나 단일 장비 로그만으로 끝내면 계속 되돌아옵니다. 먼저 5-tuple과 전체 경로를 고정하고, 엣지 outside/inside, 내부 L3, NAT external/internal, 하이퍼바이저 브리지, VM NIC를 같은 시각에 확인합니다. 패킷이 안 보이는 첫 지점이 우선 조치 구간이고, 패킷이 보이는데 응답이 틀어진 지점이 다음 분석 구간입니다.

아래 절차는 CloudStack Virtual Router 경로를 좁히는 실무 점검 흐름입니다. 구조는 CloudStack 계열 Virtual Router를 기준으로 잡았지만, NAT gateway나 방화벽 VM을 쓰는 환경에서도 같은 방식으로 응용할 수 있습니다.

1. 먼저 5-tuple과 경로를 고정한다

트래픽 추적은 “접속이 안 된다”로 시작하면 안 됩니다. 출발지, 목적지 공인 IP, 목적지 포트, DNAT 후 VM 사설 IP, VM 포트, VR의 외부/내부 인터페이스를 먼저 고정합니다.

출발지 : 198.51.100.50
목적 공인IP : 203.0.113.10
목적 포트 : tcp/3389
VM 사설IP : 10.10.0.25
VM 포트 : tcp/3389
VR external : eth2
VR internal : eth0
VR 상태 : MASTER
증상 : 특정 출발지에서만 timeout 또는 RST, 다른 출발지는 정상

운영 중에는 여기에 테스트 시간, 테스트한 출발지, 성공한 출발지, 실패한 출발지를 같이 적습니다. 특정 출발지만 실패하는지, 모든 출발지가 실패하는지에 따라 의심 지점이 완전히 달라집니다.

# CloudStack/VR 계층에서 먼저 확인할 값
cloudmonkey list publicipaddresses ipaddress=203.0.113.10
cloudmonkey list portforwardingrules ipaddressid=<public-ip-id>
cloudmonkey list virtualmachines id=<vm-id>

# VR 안에서 현재 인터페이스와 라우팅 확인
ip -br addr
ip route
cat /proc/net/nf_conntrack 2>/dev/null | head || true
conntrack -S 2>/dev/null || true

2. tcpdump는 VR 양쪽 인터페이스에 동시에 건다

VR external에서만 보면 “들어왔다”까지만 알 수 있고, internal에서만 보면 “VM에 전달됐다”만 알 수 있습니다. 둘을 같은 시간대에 같이 잡아야 NAT 전후가 이어집니다.

CLIENT=198.51.100.50
PUBLIC_IP=203.0.113.10
PRIVATE_IP=10.10.0.25
PORT=3389
STAMP=$(date +%Y%m%d_%H%M%S)

# VR external interface: 고객/인터넷 쪽에서 패킷이 들어오는지 확인
timeout 60 tcpdump -nn -s0 -B 8192 -i eth2 "host ${CLIENT} and host ${PUBLIC_IP} and tcp port ${PORT}" -w /root/vr-ext-${STAMP}.pcap &

# VR internal interface: DNAT 이후 VM 사설 IP로 넘어가는지 확인
timeout 60 tcpdump -nn -s0 -B 8192 -i eth0 "host ${CLIENT} and host ${PRIVATE_IP} and tcp port ${PORT}" -w /root/vr-int-${STAMP}.pcap &

wait

tcpdump -nn -r /root/vr-ext-${STAMP}.pcap | head -n 40
tcpdump -nn -r /root/vr-int-${STAMP}.pcap | head -n 40

파일로 저장하는 이유는 단순합니다. 장애 보고나 벤더 분석에서는 화면에 보이는 몇 줄보다 저장한 pcap이 훨씬 강한 증거입니다. 짧게 잡더라도 -nn, -s0, -B, -w를 붙여 재분석 가능하게 남깁니다.

3. 패킷 모양으로 구간을 판정한다

같은 포트라도 SYN, SYN-ACK, ACK, RST, FIN이 어디서 보이는지에 따라 원인이 달라집니다. 특히 RST가 VR에서 만들어진 것처럼 보이는지, DNAT 후 VM에서 돌아온 것인지 구분해야 합니다.

external에서 SYN 보임, internal에서 SYN 안 보임
 -> VR 내부의 firewall, DNAT, interface mapping, policy route, conntrack 문제를 우선 본다.

external과 internal 모두 SYN 보임, VM이 RST 응답
 -> 네트워크 경로는 VM까지 도달했다. VM OS 방화벽, 서비스 listen, 애플리케이션 상태를 본다.

external과 internal 모두 SYN/SYN-ACK/ACK 보임, 이후 payload 또는 FIN/RST에서 끊김
 -> L4 연결은 만들어졌다. 서비스 프로토콜, 애플리케이션, 세션 idle timeout, 중간 보안장비를 본다.

external에서 대상 출발지 패킷이 아예 안 보임
 -> VR 이전 구간이다. 상단 방화벽, IPS/WAF, 라우팅, 고객 측 NAT, 회선 구간을 본다.

특정 출발지만 실패하고 다른 출발지는 정상
 -> 전체 NAT/포트포워딩 장애보다 출발지 기반 차단, 비대칭 경로, conntrack stale entry를 먼저 의심한다.

외부 인터페이스와 내부 인터페이스 양쪽에서 같은 SYN과 RST가 보이면 다음 지점을 확인합니다. 그 경우 “VR이 막았다”가 아니라 패킷이 VM까지 들어갔고 VM 또는 VM 내부 서비스가 RST를 돌려준 것으로 봐야 합니다.

4. iptables는 존재 여부보다 counter를 본다

포트포워딩 rule이 있다는 사실만으로는 부족합니다. 실제 테스트 순간에 해당 rule의 packet/byte counter가 증가하는지 봐야 합니다. counter가 오르지 않으면 패킷이 그 rule을 안 타는 겁니다.

PUBLIC_IP=203.0.113.10
PRIVATE_IP=10.10.0.25
PORT=3389

iptables-save -t nat | grep -E "${PUBLIC_IP}|${PRIVATE_IP}|dport ${PORT}"
iptables-save -t filter | grep -E "${PUBLIC_IP}|${PRIVATE_IP}|dport ${PORT}|FIREWALL"

iptables -t nat -L PREROUTING -nv --line-numbers | grep -E "${PUBLIC_IP}|${PORT}"
iptables -L -nv --line-numbers | grep -E "${PRIVATE_IP}|${PORT}"

# 테스트 전후로 packet/byte counter가 증가하는지 비교한다.
iptables -t nat -L PREROUTING -nv --line-numbers > /root/nat-before.txt
sleep 10
iptables -t nat -L PREROUTING -nv --line-numbers > /root/nat-after.txt
diff -u /root/nat-before.txt /root/nat-after.txt | sed -n '1,120p'

CloudStack VR에서는 DNAT, MARK, CONNMARK, filter accept chain이 같이 움직입니다. 공인 IP 기준 chain은 있는데 DNAT rule의 -i가 현재 active public interface와 다르면, rule이 존재해도 트래픽이 안 탈 수 있습니다.

5. conntrack은 “세션이 만들어졌는지”를 보여준다

정상적으로 3-way handshake가 만들어지면 conntrack에는 원래 방향과 reply 방향이 같이 남습니다. [ASSURED]가 붙은 entry가 있으면 적어도 L4 세션은 양방향으로 본 적이 있다는 뜻입니다.

CLIENT=198.51.100.50
PUBLIC_IP=203.0.113.10
PRIVATE_IP=10.10.0.25
PORT=3389

conntrack -L -p tcp 2>/dev/null | grep -E "${CLIENT}|${PUBLIC_IP}|${PRIVATE_IP}|dport=${PORT}|sport=${PORT}" | head -n 80

cat /proc/sys/net/netfilter/nf_conntrack_count 2>/dev/null
cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null
conntrack -S 2>/dev/null

특정 출발지는 실패하고 다른 출발지는 정상인데, 정상 출발지의 conntrack만 보인다면 NAT rule 전체보다는 출발지 기반 차단이나 upstream 경로를 의심합니다. 반대로 conntrack table 사용률이 높고 VR packet drop 경보가 같이 있으면 conntrack 고갈이나 과다 트래픽을 먼저 봐야 합니다.

6. ips.json과 active interface 불일치를 확인한다

운영 주의사항에서 꽤 중요한 케이스가 있었습니다. VR의 public subnet은 현재 active interface에 붙어 있는데, /etc/cloudstack/ips.json에 과거 non-active interface 정보가 남아 있고, rule 생성 로직이 그쪽을 먼저 읽어 잘못된 interface로 DNAT/MARK rule을 만든 경우입니다.

PUBLIC_IP=203.0.113.10

ip -br addr
iptables-save -t nat | grep "${PUBLIC_IP}"

# ips.json 안에서 같은 public subnet이 active/add:true 인터페이스에 남아 있는지 확인한다.
jq '.[]? // empty' /etc/cloudstack/ips.json >/dev/null 2>&1 && jq --arg ip "${PUBLIC_IP}" '
 to_entries[]
 | {device: .key, values: .value}
 | .values[]
 | select((.public_ip // .cidr // "") | tostring | contains($ip))
 | {device, add: (.ADD // .add), cidr, network, public_ip, source_nat}
' /etc/cloudstack/ips.json

# jq가 없으면 최소한 public IP와 주변 라인을 본다.
grep -n -C 6 "${PUBLIC_IP}" /etc/cloudstack/ips.json

정상이어야 하는 모양
 - public subnet은 eth2에 있고 eth2 항목이 add:true
 - DNAT/MARK/CONNMARK rule도 -i eth2 기준으로 생성

문제였던 모양
 - public subnet은 eth2에서 쓰는데 ips.json의 과거 eth3 항목도 같은 subnet으로 남아 있음
 - 과거 eth3 항목은 add:false인데 rule 생성 로직이 먼저 읽음
 - DNAT/MARK rule이 non-active interface 기준으로 생성
 - external tcpdump와 iptables counter가 맞지 않거나 특정 포트포워딩만 실패

판정
 - 현재 ip a의 active interface와 iptables-save의 -i interface가 다르면 VR 재생성/절체 또는 버전 패치 여부를 본다.

7. VR 상태와 과다 트래픽은 같이 본다

VR redundant state, keepalived 상태, eth fault, conntrack 사용량, cnode 성능을 같이 봐야 합니다. 특히 대량 트래픽이 유입 중일 때는 VR 재기동이나 절체를 먼저 하면 더 큰 장애로 번질 수 있습니다. 트래픽이 자연 해소됐거나 상단에서 차단됐는지 확인한 뒤 조치해야 합니다.

grep -i 'Entering .* STATE' /var/log/messages | tail -n 40
systemctl status keepalived --no-pager 2>/dev/null || true
ip addr show | grep -E 'state|inet '

cat /proc/sys/net/netfilter/nf_conntrack_count 2>/dev/null
cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null
dmesg -T | grep -Ei 'vif|rx stalled|disabled state|conntrack|martian|drop' | tail -n 80

운영 주의사항에도 conntrack 과다, packet drop, VR eth daemon, redundant state 경보가 같은 묶음으로 등장합니다. 이 경보들은 “NAT rule이 틀렸다”와 다른 계층입니다. 포트포워딩 장애처럼 보여도 실제로는 VR이 과다 세션을 처리하느라 지연되거나 drop하는 상황일 수 있습니다.

8. zone 간 CIP 통신은 게스트 인터페이스까지 본다

공인 IP 포트포워딩이 아니라 사설망/CIP 간 통신 불가라면 VR NAT보다 VM 내부 인터페이스, host VIF, hypervisor 로그를 같이 봐야 합니다. 메모 중에는 특정 시간대 이후 VM의 인터페이스 down/up으로 통신이 회복된 케이스도 있었습니다. 이때는 고객 OS 이벤트, sosreport, host의 VIF 로그를 함께 묶어야 원인 분석이 됩니다.

• VM 안에서 ip addr, ip route, ss -lntp, OS firewall 상태 확인
• hypervisor/cnode에서 VIF disabled, guest rx stalled, link state 변경 로그 확인
• VM 내부 tcpdump와 host/VR tcpdump를 같은 시각에 비교
• 인터페이스 down/up으로 회복됐다면 회복 시간 전후 로그를 따로 보존

9. 장애 보고는 구간 판정으로 끝내야 한다

좋은 보고는 “확인했습니다”가 아니라 “여기까지는 통과했고 여기서 끊겼다”로 끝납니다. 아래 형식이면 고객, 보안장비 담당, 플랫폼 담당이 같은 증거를 보고 다음 액션을 정할 수 있습니다.

장애 증상
 - 198.51.100.50 -> 203.0.113.10:3389 접속 실패
 - 다른 출발지에서는 정상 또는 일부 포트만 정상

동시 캡처 결과
 - VR external: SYN 관측 여부
 - VR internal: DNAT 후 10.10.0.25:3389 전달 여부
 - VM 응답: SYN-ACK / RST / 무응답

NAT/FILTER 확인
 - DNAT rule 존재 여부
 - filter accept/drop rule 존재 여부
 - 테스트 전후 counter 증가 여부
 - rule interface와 active interface 일치 여부

conntrack 확인
 - ESTABLISHED / SYN_SENT / TIME_WAIT / ASSURED 상태
 - mark/zone 값
 - nf_conntrack_count 대비 max 사용률

판정
 - VR 이전 구간 / VR NAT-filter 구간 / VM OS 구간 / 애플리케이션 구간 중 어디인지
 - 임시 조치와 영구 조치
 - 재현 테스트 결과

정리

CloudStack Virtual Router 네트워크 장애는 포털 설정만 보고 판단하면 늦습니다. 먼저 5-tuple을 고정하고, VR external/internal에서 동시에 tcpdump를 잡고, iptables counter와 conntrack을 같은 시간대에 대조합니다. 패킷이 VR에 안 들어오면 상단 구간, external에는 있는데 internal로 안 가면 VR NAT/filter/interface mapping, VM까지 갔는데 RST가 오면 VM OS나 서비스, 세션은 생기는데 지연되면 애플리케이션 또는 과다 트래픽/conntrack 구간으로 좁히면 됩니다.

1. 먼저 용어를 끊어야 한다

2. 지금 보고 있는 화면이 어느 TTY인지 확인한다

사용자 프로세스 출력은 커널 콘솔과 다릅니다. 먼저 내 shell의 stdin/stdout/stderr가 어느 장치에 붙어 있는지 확인합니다.

tty

readlink -f /proc/$$/fd/0
readlink -f /proc/$$/fd/1
readlink -f /proc/$$/fd/2

ps -o pid,ppid,tty,stat,comm,args -p $$
ps -t "$(tty | sed 's#^/dev/##')" -o pid,ppid,tty,stat,comm,args

w
who
loginctl list-sessions
loginctl session-status "$XDG_SESSION_ID" 2>/dev/null || true

tty가 /dev/pts/0이면 지금 보는 화면은 SSH나 terminal emulator의 pseudo terminal입니다. 이 경우 echo hello는 kernel console로 가는 것이 아니라 현재 shell의 controlling terminal로 갑니다. 반대로 물리 콘솔에서 로그인했다면 /dev/tty1처럼 보일 수 있습니다.

3. 커널 콘솔 후보를 확인한다

커널 메시지, 부팅 로그, panic 로그, /dev/kmsg로 들어간 출력은 console= 설정과 등록된 console driver를 기준으로 흐릅니다. 이 부분은 /proc/cmdline과 /proc/consoles를 같이 봐야 합니다.

cat /proc/cmdline | tr ' ' '\n' | grep '^console=' || true
cat /proc/consoles

cat /sys/class/tty/tty0/active 2>/dev/null || true
fgconsole 2>/dev/null || true

systemctl status getty@tty1.service --no-pager
systemctl status serial-getty@ttyS0.service --no-pager 2>/dev/null || true
journalctl -u getty@tty1.service -b --no-pager | tail -n 80
journalctl -u serial-getty@ttyS0.service -b --no-pager 2>/dev/null | tail -n 80

console=tty0 console=ttyS0,115200처럼 여러 개가 있으면 커널 출력은 여러 console driver로 복제될 수 있습니다. 어떤 장치가 실제로 등록됐는지는 추측하지 말고 /proc/consoles로 확인합니다. VM 환경에서는 hypervisor 콘솔이 ttyS0에 붙어 있는 경우가 많고, bare metal에서는 tty0나 BMC serial redirection이 같이 보일 수 있습니다.

4. marker를 만들어 경로를 분리한다

추적할 때는 평소 로그를 그대로 보면 섞입니다. 짧은 marker를 만들어 사용자 TTY 출력과 커널 printk 출력을 따로 발생시킵니다.

# 사용자 프로세스가 자기 controlling terminal로 쓰는 경로
printf 'userspace-tty-marker pid=%s tty=%s\n' "$$" "$(tty)" > /dev/tty

# 커널 printk 경로를 강제로 만들 때. root 필요.
sudo sh -c 'echo "kernel-console-marker from /dev/kmsg" > /dev/kmsg'

# printk가 실제로 들어왔는지 확인
dmesg -T | tail -n 40
journalctl -k -b --no-pager | tail -n 40

여기서 /dev/tty로 보낸 marker는 현재 세션의 TTY 경로를 탑니다. /dev/kmsg로 보낸 marker는 printk 경로를 타고 등록된 console driver로 전달됩니다. 두 흐름을 구분하지 않으면 "콘솔에 찍혔다"는 사실만 남고 어디서 어디로 갔는지 판단하기 어렵습니다.

5. tracefs에서 이 커널이 제공하는 지점을 먼저 본다

커널 버전과 설정에 따라 함수 이름과 tracepoint가 조금씩 다릅니다. 바로 enable하지 말고 이 서버에 있는 지점부터 확인합니다.

sudo mount -t tracefs nodev /sys/kernel/tracing 2>/dev/null || true
cd /sys/kernel/tracing

sudo sh -c '
echo 0 > tracing_on
echo nop > current_tracer
: > trace
'

# 이 서버 커널에 실제로 있는 TTY/console 함수와 tracepoint부터 확인한다.
sudo grep -E '^(tty_write|n_tty_write|do_tty_write|vt_console_print|serial.*console.*write|uart_console_write|call_console_drivers|console_unlock)$' available_filter_functions | sort -u
sudo find events -maxdepth 2 -type d | grep -E '/(tty|console|printk)(/|$)|/(tty_|console|printk_)' | sort

운영 서버에서 안전하게 보려면 tracepoint가 있으면 tracepoint를 먼저 쓰고, 없거나 부족할 때 ftrace function filter로 내려가는 순서가 좋습니다. function graph를 무턱대고 전체 켜면 로그가 너무 커집니다.

6. tracepoint로 TTY write와 console 출력을 본다

tracepoint가 있으면 가장 깔끔합니다. 이벤트 이름은 커널별로 다를 수 있으니 존재하는 것만 enable하도록 작성합니다.

sudo sh -c '
cd /sys/kernel/tracing
echo 0 > tracing_on
: > trace

for event in   events/tty/tty_write   events/tty/tty_open   events/tty/tty_close   events/console/console   events/printk/console
do
  [ -e "${event}/enable" ] && echo 1 > "${event}/enable"
done

echo 1 > tracing_on
'

printf 'tracepoint-tty-marker pid=%s tty=%s\n' "$$" "$(tty)" > /dev/tty
sudo sh -c 'echo "tracepoint-kmsg-marker" > /dev/kmsg'

sudo sh -c '
cd /sys/kernel/tracing
echo 0 > tracing_on
tail -n 200 trace

for event in   events/tty/tty_write   events/tty/tty_open   events/tty/tty_close   events/console/console   events/printk/console
do
  [ -e "${event}/enable" ] && echo 0 > "${event}/enable"
done
'

출력에서 tty_write 계열이 보이면 사용자 프로세스가 TTY device에 write한 경로입니다. console 또는 printk 계열이 보이면 printk가 console driver로 flush되는 경로입니다. 둘이 같이 보인다고 같은 출력이라는 뜻은 아닙니다. marker 문자열과 PID, command 이름을 같이 봐야 합니다.

7. ftrace로 함수 호출 경로를 좁힌다

tracepoint만으로 부족하면 ftrace의 function tracer를 씁니다. 핵심은 전체 커널 함수를 켜지 않고 TTY/console 관련 함수만 filter에 넣는 것입니다.

sudo sh -c '
cd /sys/kernel/tracing
echo 0 > tracing_on
echo nop > current_tracer
: > set_ftrace_filter
: > set_ftrace_pid
: > trace

for func in   tty_write   n_tty_write   do_tty_write   vt_console_print   uart_console_write   call_console_drivers   console_unlock
do
  grep -qx "${func}" available_filter_functions && echo "${func}" >> set_ftrace_filter
done

echo function > current_tracer
echo 1 > tracing_on
'

printf 'ftrace-tty-marker pid=%s tty=%s\n' "$$" "$(tty)" > /dev/tty
sudo sh -c 'echo "ftrace-kmsg-marker" > /dev/kmsg'

sudo sh -c '
cd /sys/kernel/tracing
echo 0 > tracing_on
cat trace | tail -n 200
echo nop > current_tracer
: > set_ftrace_filter
'

tty_write, n_tty_write 쪽은 사용자 프로세스가 TTY에 쓰는 흐름을 보여줍니다. call_console_drivers, console_unlock, vt_console_print, serial console write 계열은 printk가 실제 console driver로 나가는 쪽을 볼 때 의미가 있습니다. 함수가 안 보이면 그 커널에서 inline됐거나 이름이 다르거나 trace 대상 심볼이 아닐 수 있습니다.

8. 특정 PID의 TTY write만 보고 싶을 때

현재 shell이나 특정 프로세스가 /dev/tty에 쓰는 경로만 좁혀 보려면 set_ftrace_pid를 같이 씁니다.

# 현재 shell이 /dev/tty에 쓰는 사용자 프로세스 경로만 좁혀 볼 때.
WRITER_PID=$$

sudo sh -c "
cd /sys/kernel/tracing
echo 0 > tracing_on
echo nop > current_tracer
: > trace
: > set_ftrace_filter
echo tty_write >> set_ftrace_filter
grep -qx n_tty_write available_filter_functions && echo n_tty_write >> set_ftrace_filter
echo ${WRITER_PID} > set_ftrace_pid
echo function > current_tracer
echo 1 > tracing_on
"

printf 'pid-filter-marker pid=%s tty=%s\n' "$$" "$(tty)" > /dev/tty

sudo sh -c '
cd /sys/kernel/tracing
echo 0 > tracing_on
cat trace
echo nop > current_tracer
: > set_ftrace_pid
: > set_ftrace_filter
'

PID filter는 사용자 프로세스가 system call을 타고 TTY에 쓰는 흐름에는 유용합니다. 하지만 printk flush는 다른 kernel context에서 발생할 수 있으므로 /dev/kmsg marker까지 같은 PID로만 보려고 하면 놓칠 수 있습니다.

9. dynamic_debug는 드라이버 내부 로그가 필요할 때만 켠다

ftrace가 호출 여부를 보여준다면 dynamic debug는 커널 소스의 pr_debug 지점이 살아 있을 때 내부 로그를 늘려 줍니다. 운영 장비에서는 반드시 파일 단위로 좁게 켜고 끝나면 끕니다.

sudo mount -t debugfs nodev /sys/kernel/debug 2>/dev/null || true

sudo grep -Ei 'drivers/tty/(tty_io|n_tty|vt|serial)'   /sys/kernel/debug/dynamic_debug/control | head -n 80

# 커널에 pr_debug 지점이 있고 CONFIG_DYNAMIC_DEBUG가 켜져 있을 때만 출력이 늘어난다.
sudo sh -c 'echo "file drivers/tty/tty_io.c +p" > /sys/kernel/debug/dynamic_debug/control'
sudo sh -c 'echo "file drivers/tty/n_tty.c +p" > /sys/kernel/debug/dynamic_debug/control'

dmesg -wT

# 다른 터미널에서 marker를 만든 뒤, 끝나면 반드시 끈다.
sudo sh -c 'echo "file drivers/tty/tty_io.c -p" > /sys/kernel/debug/dynamic_debug/control'
sudo sh -c 'echo "file drivers/tty/n_tty.c -p" > /sys/kernel/debug/dynamic_debug/control'

dynamic_debug/control에 항목이 없거나 CONFIG_DYNAMIC_DEBUG가 꺼진 커널이면 이 방식은 쓸 수 없습니다. 이때는 tracefs/ftrace나 bpftrace로 보는 편이 낫습니다.

10. bpftrace로 빠르게 PID와 comm만 찍기

서버에 bpftrace가 있고 kprobe 접근이 가능하면, 짧게 누가 tty_write를 타는지만 볼 수 있습니다.

# 함수가 커널 심볼로 노출되는지 먼저 확인한다.
sudo bpftrace -l 'kprobe:tty_write'
sudo bpftrace -l 'kprobe:n_tty_write'

# 단순히 어떤 프로세스가 tty_write 경로를 타는지 볼 때.
sudo bpftrace -e 'kprobe:tty_write { printf("pid=%d comm=%s\n", pid, comm); }'

# 별도 터미널에서:
printf 'bpftrace-tty-marker pid=%s tty=%s\n' "$$" "$(tty)" > /dev/tty

이 방식은 빠르지만 운영 커널 보안 설정, lockdown, BPF 권한, 심볼 노출 상태에 영향을 받습니다. 안 되면 tracefs로 돌아가면 됩니다.

11. 흔한 판정 기준

• SSH 화면에만 보이면 대부분 pts/N 경로입니다. /dev/console 문제가 아닙니다.
• VM 콘솔에는 보이는데 SSH에는 안 보이면 console=ttyS0, tty0, getty, hypervisor console mapping을 봅니다.
• 부팅 초기 메시지만 보이고 로그인 프롬프트가 없으면 kernel console은 살아 있지만 getty가 안 떠 있거나 target 전환이 막힌 상태일 수 있습니다.
• systemd service 로그는 기본적으로 journal로 갑니다. TTY에 직접 쓰려면 unit의 StandardOutput=tty, TTYPath= 같은 설정을 따로 봐야 합니다.
• panic, oops, printk는 프로세스 stdout이 아닙니다. dmesg, journalctl -k, console driver 경로로 봐야 합니다.

12. 끝나면 반드시 원복한다

trace와 dynamic debug는 잠깐 켜는 도구입니다. 특히 function tracer나 dynamic debug를 켜 둔 채 운영 서버를 방치하면 로그와 오버헤드가 커질 수 있습니다.

sudo sh -c '
cd /sys/kernel/tracing
echo 0 > tracing_on
echo nop > current_tracer
: > set_ftrace_filter
: > set_ftrace_pid
: > trace
find events -name enable -exec sh -c "echo 0 > \"$1\"" sh {} \;
'

sudo sh -c 'echo "file drivers/tty/tty_io.c -p" > /sys/kernel/debug/dynamic_debug/control' 2>/dev/null || true
sudo sh -c 'echo "file drivers/tty/n_tty.c -p" > /sys/kernel/debug/dynamic_debug/control' 2>/dev/null || true

정리

콘솔 출력 추적은 tty 하나만 보고 끝내면 안 됩니다. 먼저 현재 프로세스의 fd가 pts/N인지 ttyN인지 확인하고, 커널 console 후보는 /proc/cmdline과 /proc/consoles로 확인합니다. 그 다음 marker를 나눠 만든 뒤 tracepoint, ftrace, dynamic_debug 순서로 좁히면 "이 출력이 어느 TTY를 타고 어디까지 갔는지"를 재현 가능한 절차로 설명할 수 있습니다.

1. NIC와 route를 먼저 확인한다

ip addr show br-ex
ip addr show bond-egress
ip route

2. EgressIP 대상 노드와 namespace를 라벨로 묶는다

oc label node <worker-node> k8s.ovn.org/egress-assignable=
oc get nodes --show-labels | grep egress-assignable

oc label ns <namespace> egress=secondary
oc get ns --show-labels | grep egress=secondary

3. EgressIP는 /32 VIP로 보이는 것이 정상이다

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-secondary
spec:
  egressIPs:
    - 10.108.0.50
  namespaceSelector:
    matchLabels:
      egress: secondary

oc apply -f egress-secondary.yaml
oc get egressip -o wide
ip addr show br-ex | grep 10.108.0.50

4. source policy routing으로 송신 NIC를 고정한다

echo "108 egress108" >> /etc/iproute2/rt_tables
ip rule del from 10.108.0.50/32 table egress108 2>/dev/null || true
ip route flush table egress108 2>/dev/null || true
ip rule add from 10.108.0.50/32 table egress108 priority 1080
ip route add 10.108.0.0/24 dev bond-egress src 10.108.0.50 table egress108
ip route add default via 10.108.0.1 dev bond-egress table egress108
ip route get 8.8.8.8 from 10.108.0.50

5. tcpdump와 Pod 테스트로 증명한다

tcpdump -ni bond-egress host 8.8.8.8
tcpdump -ni bond-egress arp
conntrack -L | grep 10.108.0.50

oc run egress-test \
  --image=registry.access.redhat.com/ubi9/ubi \
  -n <namespace> \
  -it --rm -- bash

curl -s https://ifconfig.me

정리

OVN-Kubernetes EgressIP 장애는 리소스 생성 여부만 보면 안 됩니다. 노드 라벨, namespaceSelector, /32 VIP 표시, source policy routing, 보조 NIC tcpdump, Pod 외부 IP 확인을 한 줄로 연결해야 합니다.

1. SCC 컬럼을 읽는 기준

PRIV=true, hostPath, RunAsAny, VOLUMES=*가 같이 보이면 일반 애플리케이션에 줄 권한이 아닙니다.

oc get scc
oc describe scc restricted-v2
oc describe scc anyuid
oc describe scc privileged

2. anyuid는 root 실행 허용이다

anyuid는 privileged 컨테이너를 허용하는 정책은 아니지만 컨테이너 UID를 자유롭게 둡니다. 장기적으로는 이미지가 임의 UID에서도 동작하도록 고치는 것이 맞습니다.

oc adm policy add-scc-to-user anyuid -z <serviceaccount> -n <namespace>
oc get pod <pod> -n <namespace> -o jsonpath='{.spec.serviceAccountName}{"\n"}'
oc describe pod <pod> -n <namespace> | egrep -i "scc|uid|forbidden|security"

3. hostPath는 노드 파일시스템 접근이다

oc get pod <pod> -n <namespace> -o yaml | grep -n "hostPath" -A5
oc describe scc hostaccess
oc describe scc hostmount-anyuid

4. hostNetwork는 네트워크 격리 완화다

oc get pod <pod> -n <namespace> -o jsonpath='{.spec.hostNetwork}{"\n"}'
oc describe scc hostnetwork
oc describe scc hostnetwork-v2

5. privileged와 CAP_SYS_ADMIN은 최후의 선택이다

oc adm policy who-can use scc privileged
oc adm policy who-can use scc anyuid
oc get rolebinding,clusterrolebinding -A | grep -i scc

정리

SCC 문제를 만났을 때 목표는 Pod를 띄우는 것이 아니라 필요한 최소 권한으로 띄우는 것입니다. service account 단위로 제한하고, 임시 권한은 제거 계획까지 남겨야 합니다.

1. ArgoCD RBAC ConfigMap부터 확인한다

oc -n openshift-gitops get cm argocd-rbac-cm -o yaml
oc -n openshift-gitops get argocd
oc -n openshift-gitops get pods
oc -n openshift-gitops get route

2. 그룹을 만들고 필요한 권한만 연결한다

ArgoCD 사용자를 바로 cluster-admin처럼 다루지 말고 배포 대상 namespace와 운영 역할을 나눕니다.

apiVersion: user.openshift.io/v1
kind: Group
metadata:
  name: gitops-admins
users:
  - admin

oc apply -f gitops-admins.yaml
oc adm policy add-cluster-role-to-group admin gitops-admins
oc adm policy add-cluster-role-to-user admin \
  -z openshift-gitops-argocd-application-controller \
  -n openshift-gitops

3. Repository 연결은 secret과 권한 범위를 같이 본다

Repository를 연결할 때는 URL만 넣고 끝내면 안 됩니다. 인증 secret, CA, 프록시, read-only token 여부를 같이 봐야 합니다.

oc -n openshift-gitops get secret | grep -i repo
oc -n openshift-gitops describe secret <repo-secret-name>
oc -n openshift-gitops logs deploy/openshift-gitops-repo-server --tail=100

4. Application은 YAML로 남긴다

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sample-app
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: https://git.example.com/platform/sample-app.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: sample-prod
  syncPolicy:
    automated:
      prune: false
      selfHeal: true

5. 장애는 repo-server, controller, target namespace 순서로 본다

oc -n openshift-gitops get applications.argoproj.io
oc -n openshift-gitops describe application sample-app
oc -n openshift-gitops logs deploy/openshift-gitops-repo-server --tail=200
oc -n openshift-gitops logs deploy/openshift-gitops-application-controller --tail=200
oc -n sample-prod get events --sort-by=.lastTimestamp

정리

OpenShift GitOps 운영은 ArgoCD 화면을 여는 일이 아니라 RBAC, repository credential, Application YAML, target namespace 권한, sync 정책을 한 세트로 관리하는 일입니다.

1. PID 기준으로 증거를 고정한다

명령줄, 실행 파일, 현재 작업 디렉터리, 열린 파일, 네트워크 연결, 파일 해시를 한 번에 남깁니다.

PID=<pid>
ps -fp ${PID}
top -Hp ${PID}
cat /proc/${PID}/cmdline | tr "\0" " "; echo
readlink -f /proc/${PID}/exe
readlink -f /proc/${PID}/cwd
lsof -p ${PID}
ss -pant | grep "${PID}\|ESTAB"
sha256sum "$(readlink -f /proc/${PID}/exe)"

2. strace는 짧게 붙인다

epoll_wait 계열 반복과 외부 TLS 연결이 같이 보이면 네트워크 이벤트 루프를 가진 의심 프로세스로 판단할 수 있습니다.

strace -ttT -s 200 -p ${PID} -o /tmp/suspect-${PID}.strace
sleep 10
pkill -INT -f "strace -ttT -s 200 -p ${PID}"
tail -n 80 /tmp/suspect-${PID}.strace

3. 지속성은 cron, systemd, profile 순서로 본다

프로세스를 죽였는데 다시 살아나면 실행 파일보다 지속성 지점이 핵심입니다. crontab, systemd unit, rc.local, shell profile, PATH 오염을 봅니다.

crontab -l
sudo ls -al /etc/cron* /var/spool/cron 2>/dev/null
sudo systemctl list-unit-files | egrep -i "unknown|cache|update|tmp|miner|bash"
sudo find /etc/systemd/system -maxdepth 3 -type f -mtime -30 -ls
cat /etc/rc.local 2>/dev/null
grep -R "cache\|tmp\|curl\|wget\|bash" /etc/profile /etc/bashrc ~/.bash* 2>/dev/null
echo "$PATH"

4. 제거 전에 격리하고 차단한다

의심 파일은 격리 디렉터리에 복사하고 해시를 남긴 뒤 외부 통신지를 차단합니다. 그 다음 프로세스를 종료합니다.

mkdir -p /root/incident-artifacts
cp -a "$(readlink -f /proc/${PID}/exe)" /root/incident-artifacts/suspect-${PID}.bin
sha256sum /root/incident-artifacts/suspect-${PID}.bin > /root/incident-artifacts/suspect-${PID}.sha256
iptables -I OUTPUT -d <malicious-ip> -j REJECT
kill -TERM ${PID}
sleep 3
kill -KILL ${PID} 2>/dev/null || true

5. 복구 후 무결성을 확인한다

프로세스만 제거하면 끝이 아닙니다. 패키지 무결성, 신규 계정, SSH 키, sudoers, 최근 변경 파일을 봐야 합니다.

rpm -Va > /root/incident-artifacts/rpm-verify.txt 2>&1
last -a | head -n 50
lastlog | egrep -v "Never logged in"
find /root /home /tmp /var/tmp -xdev -type f -mtime -7 -ls
find /etc -type f -mtime -7 -ls
grep -R "ssh-rsa\|ssh-ed25519" /root /home 2>/dev/null

정리

침해 의심 프로세스 분석의 핵심은 PID 기준 증거 고정, 짧은 strace, lsof와 네트워크 연결 확인, cron/systemd 지속성 제거, 사후 무결성 검증입니다.

1. OpenStack 리소스 관계부터 잡는다

VM, 포트, 네트워크, 서브넷, 라우터, 보안 그룹 관계를 먼저 봅니다. 포트가 어떤 네트워크에 붙어 있고 fixed IP가 정상인지 확인해야 tcpdump 결과도 해석할 수 있습니다.

openstack server show <server-id>
openstack port list --server <server-id>
openstack port show <port-id>
openstack network show <network-id>
openstack subnet show <subnet-id>
openstack router list
openstack security group rule list <security-group-id>

2. 게스트 내부에서는 인터페이스, 라우팅, DNS를 분리한다

ping 실패가 곧 전체 네트워크 장애는 아닙니다. IP, default route, DNS, TCP 접속을 각각 나눠서 확인합니다.

ip addr
ip route
resolvectl status 2>/dev/null || cat /etc/resolv.conf
ping -c 3 <gateway-ip>
curl -sv --connect-timeout 3 http://<target-ip>:<port>/
traceroute <target-ip>
mtr -rw <target-ip>

3. 패킷은 양쪽에서 본다

tcpdump는 한 지점에서만 보면 반쪽짜리 증거입니다. 게스트에서 나갔는지, compute 노드의 tap/qbr/ovs 쪽에 보이는지, provider network로 나가는지 순서대로 봅니다.

# guest
sudo tcpdump -ni eth0 host <target-ip> -w /tmp/guest.pcap

# compute node
sudo tcpdump -ni any host <vm-fixed-ip> or host <target-ip>
sudo ovs-vsctl show
sudo ovs-ofctl dump-flows br-int | head

4. 스토리지는 attach 상태와 게스트 파일시스템을 나눠 본다

Cinder에서 attached라고 보여도 게스트가 디스크를 못 잡을 수 있고, 게스트 파일시스템 문제를 OpenStack 볼륨 장애로 오해할 수도 있습니다.

openstack volume list --long
openstack volume show <volume-id>
openstack server show <server-id> -c volumes_attached
openstack volume snapshot list --volume <volume-id>

lsblk
blkid
df -h
dmesg -T | egrep -i "sd[a-z]|nvme|xfs|ext4|i/o|error"

5. 로그는 서비스별로 같은 시간을 맞춘다

nova, neutron, cinder 로그는 장애 재현 시각이나 request id를 기준으로 같이 봐야 합니다. 상태 명령으로 후보를 줄인 뒤 필요한 로그만 보는 편이 빠릅니다.

openstack compute service list
openstack network agent list
openstack volume service list

sudo tail -n 200 /var/log/nova/nova-compute.log
sudo tail -n 200 /var/log/neutron/server.log
sudo tail -n 200 /var/log/cinder/volume.log

정리

OpenStack 장애 분석은 VM 안에서 시작하지 않습니다. 리소스 관계, 게스트 네트워크, 패킷 경로, 스토리지 attach, 서비스 로그를 같은 시간축으로 묶어야 합니다.

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

장애를 좁힐 때는 증상, 영향 범위, 대상 리소스, 최근 변경, 로그 시점을 먼저 맞춘다.

compute node 장애는 한 대의 서버 문제가 아니라 그 위에 올라간 VM 묶음의 서비스 장애로 번진다. 그래서 첫 판단은 hardware 교체가 아니라, 남아 있는 VM을 어디까지 안전하게 옮길 수 있는지에서 시작한다.

운영 장애 대응은 원인을 바로 단정하기보다 계층을 나눠 증거를 맞추는 쪽이 안전하다. read-only 확인, 변경 조치, 검증 명령을 분리해야 긴급 상황에서도 판단이 흔들리지 않는다.

이 글에서 다루는 케이스

겉으로 보이는 증상

• compute node hardware fault, reboot, hang, power off 이후 VM 제어가 불안정하다.
• 관리 포털에서는 VM이 Running으로 보이지만 실제 hypervisor에서는 domain이 없거나 멈춰 있다.
• 장애 host에서 migration, evacuation, maintenance 전환이 실패한다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 같은 문구가 어느 컴포넌트에서 반복되는지와 직전 상태 변화를 먼저 확인한다.

• Compute Node 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
• 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
• 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

• host의 전원, management network, storage path, xapi 상태를 먼저 분리한다.
• VM 단위 문제가 아니라 host 단위 문제인지 resident VM 목록으로 확인한다.
• hardware 교체 전후에는 service tool 로그와 hypervisor 로그를 같이 남긴다.

확인에 쓴 명령 흐름

명령은 현재 환경의 노드명, 리소스 ID, 서비스 이름을 확인한 뒤 대상에 맞게 실행한다.

xe host-list params=uuid,name-label,enabled
xe host-param-list uuid=<host-uuid>
xe vm-list resident-on=<host-uuid> params=uuid,name-label,power-state
xe task-list status=pending

systemctl status xapi --no-pager
tail -n 200 /var/log/xensource.log
tail -n 200 /var/log/messages

xe vm-migrate vm=<vm-uuid> host=<target-host-uuid> live=true
xe host-disable uuid=<host-uuid>

조치 전에 판단할 지점

• 가능하면 live migration으로 비우고, 불가능하면 HA 또는 cold migration 경로를 사용한다.
• xapi 재시작은 진행 중 task와 VM 영향도를 확인한 뒤 maintenance window에서 수행한다.
• 장애 host 격리 후 target host의 CPU, memory, SR 여유량을 확인한다.

복구됐다고 판단하는 기준

• 장애 host가 pool에서 disable/maintenance 상태인지 확인한다.
• 이전된 VM의 power state, NIC, disk attachment를 확인한다.
• xensource.log와 management-server.log에 신규 error가 반복되지 않는지 확인한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

장애를 좁힐 때는 증상, 영향 범위, 대상 리소스, 최근 변경, 로그 시점을 먼저 맞춘다.

compute node 장애는 한 대의 서버 문제가 아니라 그 위에 올라간 VM 묶음의 서비스 장애로 번진다. 그래서 첫 판단은 hardware 교체가 아니라, 남아 있는 VM을 어디까지 안전하게 옮길 수 있는지에서 시작한다.

운영 장애 대응은 원인을 바로 단정하기보다 계층을 나눠 증거를 맞추는 쪽이 안전하다. read-only 확인, 변경 조치, 검증 명령을 분리해야 긴급 상황에서도 판단이 흔들리지 않는다.

이 글에서 다루는 케이스

겉으로 보이는 증상

• compute node hardware fault, reboot, hang, power off 이후 VM 제어가 불안정하다.
• 관리 포털에서는 VM이 Running으로 보이지만 실제 hypervisor에서는 domain이 없거나 멈춰 있다.
• 장애 host에서 migration, evacuation, maintenance 전환이 실패한다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 같은 문구가 어느 컴포넌트에서 반복되는지와 직전 상태 변화를 먼저 확인한다.

• Compute Node 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
• 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
• 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

• host의 전원, management network, storage path, xapi 상태를 먼저 분리한다.
• VM 단위 문제가 아니라 host 단위 문제인지 resident VM 목록으로 확인한다.
• hardware 교체 전후에는 service tool 로그와 hypervisor 로그를 같이 남긴다.

확인에 쓴 명령 흐름

명령은 현재 환경의 노드명, 리소스 ID, 서비스 이름을 확인한 뒤 대상에 맞게 실행한다.

xe host-list params=uuid,name-label,enabled
xe host-param-list uuid=<host-uuid>
xe vm-list resident-on=<host-uuid> params=uuid,name-label,power-state
xe task-list status=pending

systemctl status xapi --no-pager
tail -n 200 /var/log/xensource.log
tail -n 200 /var/log/messages

xe vm-migrate vm=<vm-uuid> host=<target-host-uuid> live=true
xe host-disable uuid=<host-uuid>

조치 전에 판단할 지점

• 가능하면 live migration으로 비우고, 불가능하면 HA 또는 cold migration 경로를 사용한다.
• xapi 재시작은 진행 중 task와 VM 영향도를 확인한 뒤 maintenance window에서 수행한다.
• 장애 host 격리 후 target host의 CPU, memory, SR 여유량을 확인한다.

복구됐다고 판단하는 기준

• 장애 host가 pool에서 disable/maintenance 상태인지 확인한다.
• 이전된 VM의 power state, NIC, disk attachment를 확인한다.
• xensource.log와 management-server.log에 신규 error가 반복되지 않는지 확인한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

장애를 좁힐 때는 증상, 영향 범위, 대상 리소스, 최근 변경, 로그 시점을 먼저 맞춘다.

스토리지 계층 장애는 조급하게 attach/detach를 반복할수록 상태가 더 나빠질 수 있다. 특히 VDI/VBD, snapshot chain, tapdisk가 얽힌 경우에는 어떤 계층이 아직 disk를 붙잡고 있는지부터 봐야 한다.

볼륨 장애는 포털의 attach/detach 상태만 보고 판단하면 놓치는 지점이 많다. 실제로는 guest OS의 mount 상태, XenServer의 VDI/VBD 연결, SR 여유량, snapshot chain이 모두 한 줄로 맞아야 정상이라고 볼 수 있다.

이 글에서 다루는 케이스

겉으로 보이는 증상

• 볼륨 attach/detach가 실패하거나 포털 상태와 hypervisor 상태가 다르다.
• snapshot, coalesce, garbage, primary VHD, SR 용량 계산이 맞지 않는다.
• tapdisk 또는 VBD가 남아 VM disk I/O가 멈추거나 작업이 hang 상태가 된다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 같은 문구가 어느 컴포넌트에서 반복되는지와 직전 상태 변화를 먼저 확인한다.

• Storage / Volume 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
• 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
• 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

• CloudStack volume 상태, XenServer VDI/VBD 상태, SR free space를 한 번에 본다.
• 스냅샷 chain 문제는 현재 VHD, parent, coalesce task를 따로 확인한다.
• attach/detach 문제는 guest OS umount 여부와 hypervisor VBD 상태를 분리한다.

확인에 쓴 명령 흐름

명령은 현재 환경의 노드명, 리소스 ID, 서비스 이름을 확인한 뒤 대상에 맞게 실행한다.

xe sr-list params=uuid,name-label,physical-size,physical-utilisation
xe vdi-list name-label=<volume-name> params=uuid,name-label,virtual-size,physical-utilisation,sm-config
xe vbd-list vdi-uuid=<vdi-uuid> params=uuid,vm-uuid,device,currently-attached
xe task-list status=pending

tap-ctl list
lsof /var/log
tail -n 200 /var/log/SMlog
tail -n 200 /var/log/blktap/tapdisk.<pid>.log

df -h
lsblk -f
mount | grep <mount-point>

조치 전에 판단할 지점

• detach 전 guest OS filesystem flush/umount 여부를 확인한다.
• VBD가 남아 있으면 VM power state와 device path를 확인한 뒤 정리한다.
• SR 부족은 logical size와 physical utilization을 구분해서 capacity plan을 잡는다.

복구됐다고 판단하는 기준

• VDI/VBD 목록에서 orphan attachment가 사라졌는지 확인한다.
• VM 부팅 후 guest OS에서 disk, filesystem, mount 상태를 확인한다.
• snapshot/coalesce task가 새로 누적되지 않는지 확인한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

장애를 좁힐 때는 증상, 영향 범위, 대상 리소스, 최근 변경, 로그 시점을 먼저 맞춘다.

스토리지 계층 장애는 조급하게 attach/detach를 반복할수록 상태가 더 나빠질 수 있다. 특히 VDI/VBD, snapshot chain, tapdisk가 얽힌 경우에는 어떤 계층이 아직 disk를 붙잡고 있는지부터 봐야 한다.

볼륨 장애는 포털의 attach/detach 상태만 보고 판단하면 놓치는 지점이 많다. 실제로는 guest OS의 mount 상태, XenServer의 VDI/VBD 연결, SR 여유량, snapshot chain이 모두 한 줄로 맞아야 정상이라고 볼 수 있다.

이 글에서 다루는 케이스

겉으로 보이는 증상

• 볼륨 attach/detach가 실패하거나 포털 상태와 hypervisor 상태가 다르다.
• snapshot, coalesce, garbage, primary VHD, SR 용량 계산이 맞지 않는다.
• tapdisk 또는 VBD가 남아 VM disk I/O가 멈추거나 작업이 hang 상태가 된다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 같은 문구가 어느 컴포넌트에서 반복되는지와 직전 상태 변화를 먼저 확인한다.

• `root 10684 10683 16 16:58 ? 00:12:10 /usr/bin/vhd-util coalesce --debug -n /var/run/sr-mount/<UUID>/<UUID>.vhd`
• `아래 vhd파일 coalesce가 없으면 다음 볼륨 진행해도됩니다`

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

• CloudStack volume 상태, XenServer VDI/VBD 상태, SR free space를 한 번에 본다.
• 스냅샷 chain 문제는 현재 VHD, parent, coalesce task를 따로 확인한다.
• attach/detach 문제는 guest OS umount 여부와 hypervisor VBD 상태를 분리한다.

확인에 쓴 명령 흐름

명령은 현재 환경의 노드명, 리소스 ID, 서비스 이름을 확인한 뒤 대상에 맞게 실행한다.

xe sr-list params=uuid,name-label,physical-size,physical-utilisation
xe vdi-list name-label=<volume-name> params=uuid,name-label,virtual-size,physical-utilisation,sm-config
xe vbd-list vdi-uuid=<vdi-uuid> params=uuid,vm-uuid,device,currently-attached
xe task-list status=pending

tap-ctl list
lsof /var/log
tail -n 200 /var/log/SMlog
tail -n 200 /var/log/blktap/tapdisk.<pid>.log

df -h
lsblk -f
mount | grep <mount-point>

조치 전에 판단할 지점

• detach 전 guest OS filesystem flush/umount 여부를 확인한다.
• VBD가 남아 있으면 VM power state와 device path를 확인한 뒤 정리한다.
• SR 부족은 logical size와 physical utilization을 구분해서 capacity plan을 잡는다.

복구됐다고 판단하는 기준

• VDI/VBD 목록에서 orphan attachment가 사라졌는지 확인한다.
• VM 부팅 후 guest OS에서 disk, filesystem, mount 상태를 확인한다.
• snapshot/coalesce task가 새로 누적되지 않는지 확인한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

장애를 좁힐 때는 증상, 영향 범위, 대상 리소스, 최근 변경, 로그 시점을 먼저 맞춘다.

VM이 켜지지 않는다는 말은 platform 장애일 수도 있고, guest OS의 부팅 장애일 수도 있다. 운영자는 console에서 보이는 화면과 hypervisor의 power state를 분리해서 원인을 좁혀야 한다.

부팅 실패는 cloud platform 장애처럼 접수되지만 실제 원인은 guest OS 내부에 있는 경우가 많다. kernel, boot loader, filesystem을 건드리는 복구는 되돌리기 어려우므로 먼저 snapshot 가능 여부를 확인해야 한다.

이 글에서 다루는 케이스

겉으로 보이는 증상

• stop/start 후 VM이 부팅되지 않거나 single mode, grub, kernel panic 상태로 멈춘다.
• kernel upgrade, library deletion, filesystem 문제 이후 console 접속만 가능하다.
• cloud platform은 정상인데 guest OS 내부 문제로 서비스가 올라오지 않는다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 같은 문구가 어느 컴포넌트에서 반복되는지와 직전 상태 변화를 먼저 확인한다.

• Guest Boot 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
• 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
• 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

• hypervisor power state와 guest OS boot failure를 분리한다.
• console 화면, last boot log, root filesystem mount 가능 여부를 먼저 확인한다.
• 복구 전에는 disk snapshot 또는 image backup 가능 여부를 판단한다.

확인에 쓴 명령 흐름

명령은 현재 환경의 노드명, 리소스 ID, 서비스 이름을 확인한 뒤 대상에 맞게 실행한다.

virsh console <vm-name>
journalctl -xb --no-pager
dmesg -T | tail -n 100
lsblk -f
mount -o ro /dev/<root-device> /mnt

guestfish --ro -a <disk-image>
virt-rescue -a <disk-image>
grubby --info=ALL
systemctl get-default
systemctl status <service> --no-pager

조치 전에 판단할 지점

• single mode, rescue image, guestfish 중 가장 영향이 작은 경로부터 선택한다.
• grub/kernel 문제는 이전 kernel로 부팅 가능한지 확인한 뒤 기본 kernel을 되돌린다.
• 파일 삭제/라이브러리 손상은 동일 OS 버전 패키지로 복구한다.

복구됐다고 판단하는 기준

• 정상 multi-user target까지 부팅되는지 확인한다.
• network, disk mount, 주요 daemon이 정상인지 확인한다.
• 복구 중 임시로 붙인 disk/rescue 설정을 제거한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.