[25.09.01~03] 정기관 서버 트러블 슈팅 및 분석

아래 내용은 모두 2025.09 기준 ⇒ 달라질 수 있음

[ 1. 정기관 서버 PROXMOX 연결 방법 ]

물리 서버

• PC_1 : Proxy 및 (Next:?⇒ 역할이 뭐지) VM
• IP : tailscale ⇒ 100.?.?.?

⇒ tailscale로 PC1과 연결 후, PC1의 VM인 192.168.0.101 ProxyVM을 통해서 Proxmox내부로

사용 대역 : 172.16.x.x / 172.30.x.x

• PC_2(PowerEdge R730) : PROXMOX

• 공유기 2개 및 주전원 / 보조전원(APC)
• 공유기 IP : 172.30.0.1
• 포트 포워딩

접속 방법

[ 2. 네트워크 트래픽 처리 구조 ]

전체 구조

Topic 1 : NginxProxyManager (NPM)의 역할

NPM = PC_1의 VM(Proxy 101 : 172.30.0.101)

• NPM(101)은 MetalLB에서 부여한 VIP(172.30.10.1)로 전달하는 매개체

차피 NPM은 고정된 VIP 하나로 연결하는 역할인데 굳이 두는 이유 = 공유기와 Direct 연결 한계
⇒ 트래픽 및 보안에 대한 설정 가능 → EX) 특정 도메인만 허용 / SSL 등
⇒ MetalLB ARP 동적 할당 → 일반 공유기에서는 ARP 프록시 불가능

ARP BroadCast = 지금 VIP를 맡은 노드가 자기 MAC을 응답

= 공유기 기준 VIP는 항상 같은 주소지만, 어느 노드(172.30.0.X)의 MAC이 답하느냐가 달라짐

= 공유기는 테이블을 보고 MAC을 찾아가야하기 때문에 동적 ARP Proxing이 어려움

Topic 2 : MetalLB의 ARP proxing

Service → type:NodePort : 모든 Node(172.30.0.X)에서 동일한 포트 31259[80]/32024[443] OPEN

MetalLB의 역할

• VIP를 만들고 외부에 OPEN

• Node와 ARP 즉, VIP로 노드의 MAC(NIC의 믈리주소)을 찾고 연결

172.30.0.X:31259는 외부 통신이 안되는가 = False : 그럼 왜 MetalLB가 할당한 VIP가 필요한가?
⇒ HA → 장에 발생 시 ARP를 교체 가능
⇒ LB → 부하분산
⇒ K8s 추상화 → 내부에서 Node IP가 변경되도 똑같이 172.30.10.1로 ARP 프록시

Topic 3 : Ingress-Nginx Pod and Service

3-1. MetalLB - Node - Kubeproxy

MetalLB는 특정 노드를 Speaker(대표)로 선택하고 그 노드에 트래픽을 전달

kube-proxy : ingress-nginx-controller가 있는 노드로 트래픽을 전달

3-2. Ingress-nginx (Service/Pod)

ingress-nginx-controller : LoadBalancer(Service) ⇒ ingress-nginx-pod를 endpoint로 소유

ingress-nginx : nginx가 실제 동작하는 Pod를 생성 및 관리하는 Deployment

• 해당 Deployment로 인해 생성 및 관리되는 pod ⇒ ingress-nginx-pod

• 이 pod들이 각각의 ENDPOINT
참고 : 그럼 Speaker는 반드시 ingress-nginx-controller가 있어야 할까?
2️⃣ 그 노드에 꼭 Ingress Pod가 있어야 할까?
(1) ExternalTrafficPolicy: Cluster (기본값)
• VIP → NodePort → kube-proxy → 클러스터 어디에 있는 Ingress Pod로든 전달됨.
• 즉, 해당 노드에 Ingress Pod가 없어도 동작합니다.
• kube-proxy가 패킷을 클러스터 내부 네트워크로 다시 전달해 주거든요.

(트래픽이 Node1으로 들어왔다가, 실제 Ingress Pod는 Node2에 있다면 Node1 → Node2로 다시 전달)
(2) ExternalTrafficPolicy: Local
• VIP → NodePort → 그 노드에 실제 Pod가 있는 경우에만 트래픽 전달.
• 이 설정은 클라이언트의 실제 Source IP를 보존하려는 경우 자주 씁니다.
• 이 모드에서는 Ingress Pod가 없는 노드는 VIP 담당 노드로 선정되면 안 됨. (트래픽이 드롭될 수 있음)

Topic 4 : Host/Path Nginx Proxing

4-1. Ingress → Nginx.conf

컨트롤러(규칙 수집 & conf 생성) + nginx 프로세스(conf 적용 & 요청 처리)

nginx-ingress는 sample 실제 ingress 규칙 = host기반 Proxying

⇒ ingress의 생성 및 수정 발생 시 controller가 nginx.conf에 반영

= pod 내에 접속해서 nginx.conf를 수정 했을 때, 적용이 안되거나, 유지가 안되었던 이유

마무리로 k8s-service [10.43] → k8s-pod [10.42]

[ 3. 정기관 서버 다운으로 인한 PV 다중연결 문제 ]

정전으로 인해 서버가 다운되고, 복구 작업 초기 정기관 서버 내부에서 확인했을 때, 전체 node가 모두 off 상태였다. 다시 키면 쉽게 해결될 줄 알았던 문제가 공유기 포트포워딩 쪽에 문제가 생겨 이틀간 고민하고, 다양한 방법을 찾아봤는데 이를 기록해보고자 한다.

원인 : 정전으로 인한 포트포워딩 초기화

가장 근원이었던 원인은 단순했다. 포트포워딩이 비활성화 되어, nginx proxy, manager로 연결되는 포트포워딩이 작동하지 않았던 것이다.

• 구형 IPTIME 펌웨어에서 전원 복구 시 포트포워딩 활성 플래그만 초기화되는 알려진 issue 사례 (iptime 고객센터)

결국 포트포워딩을 해결했고, 재부팅하니 문제가 해결되었다.

이 과정에서 의문점 하나가 생겼는데 네트워크 쪽 문제와 달리 온프레미스 환경 내부에서는 Harbor의 PV-PVC 연결에서 에러가 발생했고, 이를 분석해 보려한다.

의문점 : 네트워크가 끊긴 것과, PV 중복 문제는 무슨 상관일까

• 문제 : 하나의 pvc가 여러 PV를 동시에 잡고 있음 (설정에 안 맞음)

K8s의 Dynamic Provisioning

• PVC : pod가 저장 공간을 요청하는 객체 (어떤 pv와 연결해야하는지)

• StorageClass : 스토리지의 정의 + provisioner (설계도)

• PV : 실제 저장공간

과정

CSI(Container Storage Interface) 

• Provisioner : PVC 생성되는 걸 모니터링 & PV를 생성

• Attacher : 컨테이너(pod)에 PV를 연결

• Controller : 스토리지 서버에서 볼륨 생성 및 삭제

Proxmox-CSI

rancher가 proxmox api를 사용해서 템플릿 복제를 진행하듯이

k8s 볼륨을 proxmox api로 관리하는 중간 다리 역할

1. 즉 PVC가 만들어지면, CSI가 api를 호출하여, 볼륨(실제 디스크)을 형성

2. 해당 볼륨을 Proxmox VM의 K8s 노드에 연결

3. CSI node가 요청한 pod와 pv 마운트

CSI-proxmox setting

CSI-Proxmox(driver)가 ProxmoxAPI(https://pve.uoslife.net:8006)에 접속 시

⇒ TLS 검증 진행 (ca.crt 파일)

즉 1차로 PVC가 생성

→ PV 생성 및 PV-PVC 바인딩

→ API 호출

→ 요청 pod에 PV(VM에 attach된 디스크) 연결

이 과정에서 네트워크 연결이 끊기면 (포트포워딩 실패)

PV는 이미 생성 및 PVC-PV bound는 성공했지만,

API를 이용해서 attach 실패 → api unreachable or CA(TLS) fail

결과적으로

AttachVolume.Attach failed이지만 Pod 상태가 ContainerCreating

⇒ VolumeAttachment 2개 꼬임 문제 발생

해결책

1. CA 인증 회피 (검증 필요)
• pve.uoslife.net 즉, 외부 도메인을 거치지 않고
• url: https://172.30.0.2:8006/api2/json로 설정
• caFile(ca.crt)로 이미 CA검증은 받고 있고, 굳이 외부 DNS를 거쳐서 네트워크 인증을 받아야 할 필요가 있을까?
• 내부 네트워크로도 충분할 것으로 예상

참고

name space : csi-proxmox