01 · OVERVIEW

개요

RKE2 기반 Kubernetes 클러스터에서 서비스를 Ingress로 외부에 노출하는 테스트를 진행했습니다. Ingress 리소스를 작성하기 전에 클러스터 구성을 확인했지만 사용할 수 있는 IngressClass가 존재하지 않았습니다.

02 · PROBLEM

문제 상황

Ingress를 구성하기 위해 현재 등록된 IngressClass를 조회했으나 리소스가 존재하지 않는다는 결과가 반환됐습니다.

$ kubectl get ingressclass
No resources found
03 · SCOPE

영향과 비영향을 분리했습니다

확인된 영향은 Ingress를 통한 외부 HTTP 진입 경로를 구성할 수 없다는 점입니다. 이 출력만으로 Pod, Service, 노드 네트워크 또는 애플리케이션 자체가 실패했다고 결론 내릴 수는 없습니다.

영향: 외부 Ingress 경로 미구성. 아직 미확인: Pod Ready, Service Endpoints, NodePort, DNS, TLS.
04 · EVIDENCE

현재 확정된 사실

  • kubectl get ingressclass 결과가 비어 있었습니다.
  • Ingress YAML에 넣을 검증된 클래스 이름이 없었습니다.
  • 클래스가 없다는 사실만으로 Controller 설치 여부까지 확정할 수는 없습니다.
  • 정상 외부 응답과 Controller 로그는 아직 확보하지 못했습니다.
05 · HYPOTHESIS

가설을 계층별로 나눴습니다

애플리케이션 계층Pod 또는 Service가 Ready가 아님
리소스 계층Ingress apiVersion·className이 맞지 않음
Controller 계층Controller가 없거나 Class를 등록하지 않음
외부 네트워크 계층포트·DNS·방화벽이 아직 연결되지 않음
06 · REQUEST PATH

요청 경로로 진단했습니다

Client
  → DNS / Load Balancer
  → Ingress Controller
  → Ingress rule + IngressClass
  → Service
  → Ready Pod

Ingress 리소스는 라우팅 선언일 뿐 요청을 직접 처리하지 않습니다. 따라서 Controller가 실제로 실행되고 해당 Class를 감시하는지 먼저 확인해야 합니다.

07 · VERIFICATION PLAN

확인한 명령과 아직 확인할 명령

실행 결과가 남은 명령
kubectl get ingressclass
# No resources found
다음 실행이 필요한 명령
kubectl get pods -n kube-system
kubectl get daemonset,deploy -A
kubectl get helmchart -A
kubectl get svc,endpoints -A
kubectl describe ingress <name>

두 묶음을 구분해 실행하지 않은 명령에 결과가 있었던 것처럼 보이지 않게 했습니다.

08 · ROOT CAUSE RANGE

현재 원인 범위

사용 가능한 Ingress Controller가 설치되지 않았거나, Controller는 있지만 IngressClass를 등록하지 않았거나, RKE2 기본 애드온이 비활성화·미배포된 상태 중 하나로 범위를 좁혔습니다.

아직 Root Cause가 아닙니다. IngressClass 없음은 원인 후보를 좁히는 관찰 결과이며 Controller 리소스와 로그를 봐야 확정할 수 있습니다.
09 · OPTIONS

해결 경로를 비교했습니다

YAML에 임의의 className 입력감시하는 Controller가 없으면 아무 효과가 없음
기존 RKE2 애드온 복구원래 설치가 깨진 경우 구성 일관성을 유지
Controller 신규 설치명시적이지만 기존 포트·애드온과 충돌 여부 확인 필요
현 상태 확인 후 결정클러스터 구성 증거를 먼저 확보해 중복 설치를 방지
10 · NEXT ACTION

다음 조치 순서

  1. kube-system에서 ingress 관련 Pod와 HelmChart를 찾습니다.
  2. 배포가 있다면 Events·로그·Service 포트를 확인합니다.
  3. 없다면 RKE2 설치 옵션에서 기본 Controller 비활성화 여부를 확인합니다.
  4. 기존 구성을 복구하거나 한 종류의 Controller만 설치합니다.
  5. 생성된 IngressClass 이름을 YAML에 명시합니다.
  6. 테스트 Service → Ingress → 외부 HTTP 순서로 검증합니다.
11 · DONE CRITERIA

해결 완료 기준

  • Ingress Controller Pod가 Ready 상태여야 합니다.
  • kubectl get ingressclass에 사용할 클래스가 보여야 합니다.
  • Ingress Address와 Events에 오류가 없어야 합니다.
  • Service Endpoints가 실제 Pod를 가리켜야 합니다.
  • 클러스터 외부에서 테스트 호스트로 HTTP 200을 확인해야 합니다.

이 증거가 모두 생기기 전까지 상태는 Investigating입니다.

12 · CURRENT RESULT

현재 결과

문제를 애플리케이션 YAML 하나로 좁히지 않고 Controller와 클러스터 애드온 계층으로 이동시켰습니다. 그러나 아직 외부 응답을 복구하지 않았으므로 해결 사례가 아니라 진행 중인 진단 기록으로 공개합니다.

현재 판단: IngressClass 출력만으로 설치를 시작하지 않고 기존 Controller·RKE2 애드온 상태를 먼저 확인해야 합니다.
13 · PREVENTION

해결 후 남길 운영 문서

  • Controller 종류·버전·설치 방식
  • IngressClass 이름과 기본 클래스 여부
  • 노출 포트, DNS, TLS 연결 구조
  • 재현 가능한 설치 매니페스트 또는 Helm values
  • Ready·라우팅·외부 응답 확인 명령
14 · RECORD LIMITS

지금 부족한 증거

Controller Pod 목록, RKE2 설정 파일, HelmChart 상태, 테스트 Service·Ingress YAML, 외부 curl 응답이 아직 기록에 없습니다. 이 다섯 자료가 있어야 원인을 확정하고 “해결 완료”로 바꿀 수 있습니다.

필요 자료를 확보하면 이 페이지에 실제 Controller, Class 이름, 변경 파일, 명령 출력, HTTP 검증 결과를 추가합니다.
15 · LEARNING

배운 점

Ingress가 동작하지 않는다고 처음부터 YAML 문법만 수정하면 안 됩니다. 외부 요청이 통과하는 각 계층을 나누고, 선언 리소스인 Ingress와 실제 데이터 평면인 Controller를 구분해야 합니다.