Troubleshooting on blog.212clab

OTel 메트릭 대시보드 트러블슈팅

Mon, 20 Apr 2026 00:00:00 +0000

문제 상황

Grafana 대시보드 “애플리케이션 모니터링(Spring Boot)“에서:

애플리케이션 드롭다운에 gateway만 표시됨
auth-guard, order-core, seat, queue 등 다른 서비스가 보이지 않음
http_server_requests_seconds_count{namespace="dev-webs"} 쿼리 시 gateway만 결과 반환

원인 분석

1. 메트릭 수집 경로가 2가지로 분리되어 있었음

경로	메트릭 이름	라벨	대상
PodMonitor → Prometheus 직접 스크레이핑	`http_server_requests_seconds_*`	`status`, `uri`, `namespace`	gateway만
OTel Agent → OTel Collector → Remote Write	`http_server_request_duration_seconds_*`	`http_response_status_code`, `http_route`	모든 서비스

2. gateway만 Micrometer 메트릭이 있었던 이유

gateway: Spring Cloud Gateway로 micrometer-registry-prometheus 의존성 포함
다른 서비스: OTel Java Agent만 사용, Micrometer 의존성 없음

3. OTel 메트릭에 namespace 라벨 누락

OTel Collector의 transform processor에서 namespace 라벨을 설정하려 했으나:

모니터링 데이터 S3 Object Storage 적재 구조

Mon, 20 Apr 2026 00:00:00 +0000

문제 상황

Staging 환경에서 Spot 인스턴스가 회수되고 새 노드가 다른 AZ에 생성되었을 때, 모니터링 Pod(Loki, Tempo 등)가 기존 PVC를 마운트하지 못하고 Pending 상태에 빠지는 문제가 발생했다.

증상

Spot 노드 회수 → 새 노드가 다른 AZ(예: ap-northeast-2a → 2c)에 프로비저닝
모니터링 Pod 재스케줄 → 기존 PVC(EBS)가 이전 AZ에 고정되어 있어 마운트 실패
Pod: Pending → Warning: FailedAttachVolume
로그/트레이스 수집 중단

근본 원인: EBS는 단일 AZ에 바인딩된다

[기존 상태]
 Node (ap-northeast-2a) ← Spot
 └── Loki Pod
 └── PVC → EBS (ap-northeast-2a에 고정)

[Spot 회수 후]
 Node (ap-northeast-2c) ← 새로 프로비저닝
 └── Loki Pod (Pending)
 └── PVC → EBS (ap-northeast-2a) ← 마운트 불가!

EBS 볼륨은 생성된 AZ에서만 사용할 수 있다. Spot 인스턴스는 가용한 AZ 어디든 뜰 수 있기 때문에 AZ 불일치가 빈번하게 발생했다.

환경별 모니터링 대시보드 분기처리

Mon, 20 Apr 2026 00:00:00 +0000

문제 상황

Dev(kubeadm)와 Staging(EKS) 환경의 인프라 구성이 달라서 모니터링 대시보드가 작동하지 않는 문제 발생.

환경별 인프라 차이

구성요소	Dev (kubeadm)	Staging (EKS)
PostgreSQL	로컬 Pod (postgres:16-alpine)	AWS RDS
Redis	로컬 Pod (redis:7-alpine)	AWS ElastiCache
메트릭 수집	Prometheus exporter	CloudWatch
데이터소스	Prometheus	CloudWatch

증상

Dev 환경에서 “RDS PostgreSQL 모니터링” 대시보드 → No data
Dev 환경에서 “ElastiCache Redis 모니터링” 대시보드 → No data
원인: CloudWatch 데이터소스가 없음 (AWS 환경이 아님)

해결

1. 환경별 대시보드 분리

동일한 기능의 대시보드를 두 가지 버전으로 생성:

CloudTrail + S3 Bucket Policy 순환 의존성 문제

Mon, 13 Apr 2026 00:00:00 +0000

문제 상황

stacks/audit-security/에서 CloudTrail을 활성화하려고 terraform apply 실행.

에러

Error: creating CloudTrail Trail (playball-audit-trail): InsufficientS3BucketPolicyException: 
Incorrect S3 bucket policy is detected for bucket: playball-audit-logs

원인 분석

순환 의존성(Circular Dependency):

CloudTrail 생성 → S3 bucket policy에 CloudTrail 쓰기 권한 필요
 ↕
S3 bucket policy → CloudTrail ARN 참조 필요 (module.cloudtrail.source_arn)
 ↕
CloudTrail ARN → CloudTrail이 생성되어야 존재

코드에서 dynamic "statement"로 module.cloudtrail.source_arn != null일 때만 policy를 추가하도록 했는데, CloudTrail이 아직 안 만들어졌으니 source_arn = null → dynamic block 스킵 → policy에 CloudTrail 권한 없음 → CloudTrail 생성 실패.

Route53 레코드 삭제 + Secrets Manager 초기화 문제

Fri, 10 Apr 2026 00:00:00 +0000

2026-04-10 | Prod 팀원 apply 시 Route53 삭제, Secret 값 초기화 이슈

문제 상황

Route53 레코드 삭제: EKS 재기동/축소 후 Route53 레코드가 사라짐
Secrets Manager 초기화: terraform apply 시 DB/Redis 비밀번호 등이 덮어써짐

원인 1: external-dns `policy: sync`

문제

policy: sync  # 레코드 삭제도 허용

policy: sync는 k8s의 Ingress/Service가 삭제되면 해당 Route53 레코드도 삭제. EKS를 내리거나 축소하면 → Ingress 삭제 → external-dns가 Route53 레코드 삭제.

흐름

EKS 종료/축소
 → Ingress 리소스 삭제
 → external-dns: "이 Ingress에 연결된 DNS 레코드 삭제해야지" (sync 정책)
 → Route53에서 argocd.playball.one, grafana.playball.one 등 삭제
 → 서비스 접근 불가

수정

# staging/prod 양쪽
policy: upsert-only  # 레코드 생성/갱신만, 삭제 안 함

수정 파일

파일	브랜치
`303-goormgb-k8s-helm/staging/values/infra/values-external-dns.yaml`	develop, argocd-sync/staging
`303-goormgb-k8s-helm/prod/values/infra/values-external-dns.yaml`	develop, argocd-sync/prod

upsert-only vs sync

	sync	upsert-only
레코드 생성	O	O
레코드 갱신	O	O
레코드 삭제	O (위험)	X
EKS 재기동	레코드 삭제됨	레코드 유지

참고

upsert-only에서는 불필요한 레코드가 남을 수 있음 → 수동 정리 필요
레코드 자동 삭제가 필요하면 --txt-owner-id로 ownership 관리 후 sync 사용 가능하지만, EKS가 자주 올리고 내리는 환경에서는 upsert-only가 안전

원인 2: Secrets Manager `secret_version` 덮어쓰기

문제 (Prod)

# prod/secrets.tf (수정 전)
resource "aws_secretsmanager_secret_version" "discord" {
 secret_string = jsonencode(var.common_secrets["prod/monitoring/discord-webhook-alerts"])
 # lifecycle ignore_changes 없음 → apply마다 tfvars 값으로 덮어씀
}

terraform apply할 때마다:

Istio Sidecar 시작 타이밍 (holdApplicationUntilProxyStarts)

Wed, 08 Apr 2026 00:00:00 +0000

문제 상황

dev-webs Pod가 1/2 Running 상태로 멈춤. readiness probe가 context deadline exceeded 에러 발생.

증상

kubectl get pods -n dev-webs
# NAME READY STATUS RESTARTS
# dev-api-gateway-xxx 1/2 Running 0

kubectl describe pod dev-api-gateway-xxx -n dev-webs
# Readiness probe failed: Get "http://10.x.x.x:8085/actuator/health/readiness": context deadline exceeded

원인 분석

Istio sidecar(envoy-proxy)가 완전히 시작되기 전에 앱 컨테이너가 먼저 시작됨. 앱이 외부 서비스(DB, Redis 등)에 연결하려고 하면 sidecar가 아직 준비 안 되어서 실패.

k6-operator MaxVUs Parallelism Error

Sun, 05 Apr 2026 00:00:00 +0000

문제 상황

4000 VU 부하테스트 실행 시 즉시 실패:

Status: error (Pod: Succeeded)
Summary not available (test may have ended too quickly)

k6-operator 로그:

k6 inspect: {MaxVUs:1 ...}
ERROR: Parallelism argument cannot be larger than maximum VUs in the script
{"maxVUs": 1, "parallelism": 2, "error": "number of instances > number of VUs"}

원인 분석

k6-operator 실행 흐름

1. TestRun CR 생성
 ↓
2. Initializer Pod 실행
 - k6 inspect: 스크립트 분석 (maxVUs 확인) ← 환경변수 없음!
 - k6 archive: 스크립트 압축
 ↓
3. Runner Pod 생성 (VUS, DURATION 환경변수 주입)
 ↓
4. 테스트 실행

문제 코드

// scripts.go에서 생성되는 k6 스크립트
const _vus = __ENV.K6_VUS ? parseInt(__ENV.K6_VUS) : (parseInt(__ENV.VUS) || 1);
// ↑
// 기본값 1!

단계	환경변수	_vus 값
k6 inspect (Initializer)	없음	1 (기본값)
k6 run (Runner)	VUS=4000	4000

k6 inspect는 스크립트의 export const options를 분석해서 maxVUs를 결정함. 환경변수가 없으면 기본값 1이 사용되어 maxVUs=1로 판단됨.

DiskPressure & CrashLoopBackOff Troubleshooting

Thu, 02 Apr 2026 00:00:00 +0000

문제 상황

mini-gmk 노드에서 argocd-repo-server 파드가 1,253개 생성됨 (Evicted 상태)
DiskPressure: True
여러 서비스 CrashLoopBackOff (ai-defense, seat 등)

원인 분석

1. DiskPressure (mini-gmk)

경로	용량	원인
/opt/local-path-provisioner	53G	Loki chunks 40G + orphan PV
Loki retention	없음	로그가 무한 축적

2. CrashLoopBackOff

서비스	원인
staging ai-defense	`imagePullSecrets: []` 누락 (기본값 ecr-pull-secret 사용)
dev ai-defense	`TM_OFFLINE_LLM_AUDIT_PATH` 누락 (PermissionError: logs/)
dev seat	`SPRING_KAFKA_BOOTSTRAP_SERVERS` 누락

해결

DiskPressure 해결

# 1. orphan PV 삭제 (~8G 확보)
sudo rm -rf /opt/local-path-provisioner/pvc-*_data_cloudbeaver-data
sudo rm -rf /opt/local-path-provisioner/pvc-*_monitoring_data-prometheus-*
# (사용 중이 아닌 PV들)

# 2. Loki chunks 삭제 (~40G 확보)
sudo find /opt/local-path-provisioner/pvc-*_monitoring_storage-loki-0/chunks -type f -mtime +1 -delete
sudo rm -rf /opt/local-path-provisioner/pvc-*_monitoring_storage-loki-0/chunks/*

# 3. 시스템 로그 정리
sudo journalctl --vacuum-size=200M

# 4. Evicted 파드 기록 삭제
kubectl delete pods -A --field-selector=status.phase=Failed
kubectl delete pods -A --field-selector=status.phase=Succeeded

Helm Values 수정

1. Loki retention 추가 (dev/staging)

# dev/values/monitoring/values-loki.yaml
loki:
 compactor:
 retention_enabled: true
 delete_request_store: filesystem
 limits_config:
 retention_period: 72h  # 3일

2. revisionHistoryLimit 추가 (공통 차트)

# common-charts/apps/java-service/templates/deployment.yaml
# common-charts/apps/ai-service/templates/deployment.yaml
spec:
 revisionHistoryLimit: 3

3. staging ai-defense imagePullSecrets

# staging/values/apps/values-ai-defense.yaml
imagePullSecrets: [] # IRSA 사용하므로 비활성화

4. dev ai-defense 환경변수

# dev/values/apps/values-ai-defense.yaml
env:
 - name: TM_OFFLINE_LLM_AUDIT_PATH
 value: "/tmp/logs/offline_llm_audit.jsonl"

5. dev seat Kafka 설정

# dev/values/apps/values-seat.yaml
env:
 - name: SPRING_KAFKA_BOOTSTRAP_SERVERS
 value: "kafka.messaging.svc.cluster.local:9092"

커밋

feat(sprint5/troubleshooting): resolve disk pressure and CrashLoopBackOff issues

- common-charts: add revisionHistoryLimit: 3
- dev/staging loki: add compactor for retention
- staging ai-defense: add imagePullSecrets: []
- dev ai-defense: add TM_OFFLINE_LLM_AUDIT_PATH
- dev seat: add Kafka bootstrap servers

교훈

Loki retention 필수 - compactor 없으면 retention_period가 작동 안 함
local-path-provisioner orphan PV - PVC 삭제해도 디렉토리는 자동 삭제 안 됨
staging은 IRSA 사용 - imagePullSecrets: [] 명시 필요 (기본값 override)
revisionHistoryLimit - 기본값 10은 너무 많음, 3으로 제한

WireGuard + Cilium IP 대역 충돌 트러블슈팅

Sun, 29 Mar 2026 00:00:00 +0000

날짜

2026-03-29

문제 상황

Cilium(eBPF) 전환 후 외부에서 WireGuard VPN 연결 실패

증상

외부(핫스팟)에서 ping 10.0.0.1 실패 (100% packet loss)
ssh grgb-vpn 연결 불가
집 내부 네트워크에서는 정상 작동

원인 분석

1차 진단: tcpdump

sudo tcpdump -i enp3s0 udp port 51820 -n
# 결과: 0 packets - 패킷이 서버까지 도달하지 않음

처음에는 공유기/ISP 문제로 의심했으나…

2차 진단: Cilium 설정 확인

kubectl -n kube-system get cm cilium-config -o yaml | grep cluster-pool
# cluster-pool-ipv4-cidr: 10.0.0.0/8

3차 진단: 라우팅 테이블 확인

ip route | grep 10.0.0
# 10.0.0.0/24 via 10.0.0.224 dev cilium_host

근본 원인

Cilium이 10.0.0.0/8 전체를 클러스터 네트워크로 사용
WireGuard도 10.0.0.0/24 사용
IP 대역 충돌으로 Cilium이 WireGuard 트래픽을 cilium_host로 라우팅

해결

WireGuard 네트워크 대역 변경

10.0.0.0/24 -> 172.30.0.0/24 (Cilium과 겹치지 않는 사설 IP 대역)

Java OOM 트러블슈팅

Mon, 23 Mar 2026 00:00:00 +0000

문제 상황

온프렘 K8s 클러스터(mini-might 워커 노드)에서 Java 앱의 메모리 부족으로 OOM Killer가 호출되어 노드가 다운된 이슈 분석 및 해결 방안.

증상

k9s에서 mini-might 노드의 모든 파드가 Unknown 상태로 표시
재부팅 후 파드들이 순차적으로 복구됨
kubectl describe node mini-might Events에서 Rebooted 확인

NodeNotReady 5분 전 - 노드가 죽음
Rebooted 58초 전 - 재부팅 감지
NodeReady 17초 전 - 복구 완료

원인 분석

1. dmesg에서 OOM 로그 확인

mini-might 노드에 SSH 접속 후:

ALB Elastic IP 자동 할당 이슈

Sun, 22 Mar 2026 00:00:00 +0000

문제 상황

발생일: 2026-03-22
환경: EKS Staging (goormgb-staging-eks)
증상: Internet-facing ALB에 Elastic IP가 자동으로 할당되어 비용 발생

증상

발견 경위

ArgoCD를 type: LoadBalancer (NLB)에서 type: ClusterIP (ALB Ingress)로 변경
NLB 삭제 후 EIP 2개가 남아있음을 발견
EIP 연결 해제/릴리스 시도 시 권한 에러 발생

에러 메시지

An error occurred (AuthFailure) when calling the DisassociateAddress operation:
You do not have permission to access the specified resource.

확인된 상태

aws ec2 describe-network-interfaces \
 --filters "Name=addresses.private-ip-address,Values=10.0.18.47" \
 --query 'NetworkInterfaces[*].[Description,NetworkInterfaceId]'

# 결과: ELB app/k8s-stagingalb-4f414fcf8f/...

원인 분석

AWS 공식 답변

Internet-facing ALB의 자동 EIP 할당은 정상 동작입니다.

EKS 노드 클러스터 조인 실패 점검지

Sat, 21 Mar 2026 00:00:00 +0000

문제 상황

EKS 노드 그룹이 생성되었으나 클러스터에 조인되지 않음
kubectl get nodes 결과 노드가 보이지 않음
EC2 인스턴스는 Running 상태

점검 항목

1. VPC DNS 설정

설정	필수값	확인
`enable_dns_hostnames`	`true`
`enable_dns_support`	`true`

확인 방법:

resource "aws_vpc" "main" {
 enable_dns_hostnames = true
 enable_dns_support = true
}

2. 서브넷 태그

EKS 컨트롤러가 서브넷을 인식하려면 특정 태그 필요

서브넷	태그	확인
Public	`kubernetes.io/role/elb = 1`
Private	`kubernetes.io/role/internal-elb = 1`
공통	`kubernetes.io/cluster/<클러스터명> = shared`

확인 방법:

EKS 트러블슈팅 - Node Group 생성 실패 및 vpc-cni addon 누락

Sat, 21 Mar 2026 00:00:00 +0000

문제 상황

EKS 1.34 클러스터 구축 중 발생한 두 가지 주요 이슈와 해결 과정 정리.

1. Node Group 생성 실패 - kubelet 라벨 문제

증상

Node Group 상태: CREATE_FAILED
에러 메시지: NodeCreationFailure - Unhealthy nodes in the kubernetes cluster
EC2 인스턴스는 실행 중이지만 클러스터에 조인 안 됨

원인 분석

SSM으로 노드에 접속하여 kubelet 로그 확인:

sudo journalctl -u kubelet -n 50

kubelet 에러:

unknown 'kubernetes.io' or 'k8s.io' labels specified with --node-labels

근본 원인

Terraform EKS 모듈에서 노드그룹 라벨에 node-role.kubernetes.io/infra 사용:

K8s Taint vs NodeSelector 트러블슈팅

Fri, 20 Mar 2026 00:00:00 +0000

문제 상황

dev-webs의 Pod들이 Degraded 상태로 ArgoCD 알림 발생:

dev-order-core
dev-seat
dev-queue

원인 분석

앱 전용 노드(mini-might)가 리소스 부족

원인: Control-plane(mini-gmk)에 node-role.kubernetes.io/control-plane:NoSchedule taint가 있어서, 인프라 Pod들(istio, loki, calico, coredns, metrics-server 등)이 control-plane에서 생성되지 못하고 앱 전용 worker 노드로 밀려옴

mini-might (worker) 에 배치된 인프라 Pod들:
- istio-ingressgateway (2개)
- istiod
- kiali
- loki-0, loki-chunks-cache-0, loki-results-cache-0
- calico-apiserver (2개), calico-kube-controllers, calico-typha
- coredns (2개)
- metrics-server
- alloy

→ 앱 Pod 배포 시 리소스 경합 발생, 새 Pod Pending

Kubernetes Service Selector & Endpoints 트러블슈팅

Thu, 19 Mar 2026 00:00:00 +0000

문제 상황

API 요청 시 503 Service Unavailable 에러
Istio 로그: no_healthy_upstream
파드는 Running 상태인데 서비스 연결 안 됨

원인 분석

Service selector 라벨과 Pod 라벨 불일치

# 엔드포인트 확인 - <none>이면 문제!
kubectl -n staging-webs get endpoints api-gateway
NAME ENDPOINTS AGE
api-gateway <none> 34h # ← 파드 IP가 없음!

동작 원리

┌─────────────────────────────────────────────────────────┐
│ Service (api-gateway) │
│ selector: │
│ app: staging-api-gateway │
│ app.kubernetes.io/part-of: staging-webs ← 필수! │
└─────────────────────────────────────────────────────────┘
 │
 ▼ selector 라벨 가진 파드 검색
┌─────────────────────────────────────────────────────────┐
│ Endpoints (자동 생성) │
│ addresses: │
│ - 10.0.20.100 (파드1 IP) │
│ - 10.0.20.101 (파드2 IP) │
└─────────────────────────────────────────────────────────┘
 │
 ▼ 트래픽 로드밸런싱
┌─────────────────────────────────────────────────────────┐
│ Pod (라벨이 selector와 매칭되어야 함) │
│ labels: │
│ app: staging-api-gateway ✓ │
│ app.kubernetes.io/part-of: staging-webs ✓ │
└─────────────────────────────────────────────────────────┘

핵심: Service selector의 모든 라벨이 Pod에 있어야 Endpoints에 등록됨

Java Spring Boot Probe 트러블슈팅

Wed, 18 Mar 2026 00:00:00 +0000

문제 상황

Staging EKS 환경에서 Java Spring Boot 앱들이 CrashLoopBackOff 상태로 계속 재시작됨.

증상

Pod가 시작 후 60초 내에 SIGTERM (exit code 143) 수신
liveness probe 실패로 kubelet이 컨테이너 강제 종료
404 에러 (초기) → 503/500 에러 (수정 후)

원인 분석

1. Context Path 누락 (1차 원인)

Spring Boot 앱들이 context path를 사용:

auth-guard: /auth
queue: /queue
seat: /seat
order-core: /order

하지만 probe 설정은:

livenessProbe:
 httpGet:
 path: /actuator/health/liveness  # 404 에러!

실제 경로는:

OpenTelemetry + Istio mTLS 트러블슈팅

Wed, 18 Mar 2026 00:00:00 +0000

문제 상황

EKS Staging 환경에서 Java 서비스들이 CrashLoopBackOff 상태로 시작 실패. 로그 분석 결과 OTEL (OpenTelemetry) agent가 OTEL Collector에 연결 실패하는 문제 발견.

환경

Kubernetes: EKS 1.34
Istio: mTLS STRICT 모드 활성화
OTEL Agent: opentelemetry-javaagent v2.11.0
OTEL Collector: opentelemetry-collector (Deployment)
Namespace: staging-webs (앱), monitoring (OTEL Collector)

증상

Pod 상태

staging-webs auth-guard-xxx 0/1 CrashLoopBackOff 17
staging-webs order-core-xxx 0/1 CrashLoopBackOff 21
staging-webs queue-xxx 0/1 CrashLoopBackOff 22
staging-webs seat-xxx 0/1 CrashLoopBackOff 21

에러 로그

[otel.javaagent] ERROR io.opentelemetry.exporter.internal.grpc.GrpcExporter -
Failed to export metrics. Server is UNAVAILABLE.
Make sure your collector is running and reachable from this network.
Full error message: upstream connect error or disconnect/reset before headers.
retried and the latest reset reason: remote connection failure,
transport failure reason: TLS_error:|268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:TLS_error_end

원인 분석

1. 정상적인 Istio mTLS 트래픽 흐름

일반적인 서비스 간 통신:

Chrome QUIC/HTTP3 간헐적 404 트러블슈팅

Tue, 17 Mar 2026 00:00:00 +0000

홈서버(kubeadm) + SK브로드밴드 환경에서 Chrome 브라우저 간헐적 404 오류 해결

홈서버 인프라 환경

1.1 전체 네트워크 아키텍처

flowchart TB
 subgraph Internet["인터넷"]
 CF["Cloudflare Edge<br/>(서울 PoP)"]
 ISP["SK브로드밴드<br/>공인 IP: 동적<br/>(39.119.192.15)"]
 end

 subgraph HomeNetwork["홈 네트워크 (192.168.45.0/24)"]
 subgraph Router["SK브로드밴드 공유기"]
 NAT["NAT/DHCP"]
 FW_R["방화벽"]
 PF["포트포워딩<br/>:80 → .154:80<br/>:443 → .154:443"]
 DHCP_RES["DHCP 예약<br/>mini-gmk: .123<br/>mini-might: .154"]
 end

 subgraph ControlPlane["mini-gmk (Control Plane)<br/>192.168.45.123"]
 UFW_C["ufw 방화벽<br/>22, 6443, 10250-10252<br/>2379-2380, 179"]
 K8S_CP["Kubernetes Control Plane<br/>kube-apiserver<br/>etcd, scheduler<br/>controller-manager"]
 ISTIOD["istiod (pilot)"]
 CERTM["cert-manager"]
 DDNS["ddns-cloudflare<br/>CronJob"]
 ESO["external-secrets-operator"]
 CALICO_CP["calico-typha<br/>calico-kube-controllers"]
 end

 subgraph Worker["mini-might (Worker)<br/>192.168.45.154"]
 UFW_W["ufw 방화벽<br/>22, 80, 443<br/>10250, 30000-32767"]
 INGRESS["istio-ingressgateway<br/>externalIPs: .154"]
 GW["java-cloud-gateway<br/>:8085"]
 AUTH["auth-guard (x2)<br/>:8080"]
 APPS["order-core :8083<br/>seat :8082<br/>queue :8081"]
 CALICO_W["calico-node"]
 end

 subgraph VPN_Access["팀원 접속"]
 VPN["Tailscale/WireGuard<br/>VPN"]
 SSH["SSH 터널<br/>:22"]
 end
 end

 subgraph Clients["클라이언트"]
 Chrome["Chrome<br/>(QUIC/HTTP3)"]
 Safari["Safari<br/>(HTTP/2)"]
 Firefox["Firefox<br/>(HTTP/2)"]
 Mobile["모바일 LTE"]
 TeamMember["팀원 (VPN)"]
 end

 Chrome -->|"QUIC/UDP:443<br/>❌ 간헐적 실패"| ISP
 Safari -->|"HTTP/2/TCP:443"| ISP
 Firefox -->|"HTTP/2/TCP:443"| ISP
 Mobile -->|"HTTP/2"| ISP

 Chrome -->|"QUIC/UDP:443<br/>✅ 안정적"| CF
 CF -->|"HTTP/2/TCP:443"| ISP

 ISP --> NAT
 NAT --> FW_R
 FW_R --> PF
 PF -->|":443"| UFW_W
 UFW_W --> INGRESS

 INGRESS --> GW
 GW --> AUTH
 AUTH --> APPS

 TeamMember -->|"VPN"| VPN
 VPN --> SSH
 SSH --> UFW_C
 SSH --> UFW_W

 DDNS -->|"API 호출"| CF

 ISTIOD -.->|"xDS"| INGRESS
 CERTM -.->|"TLS 인증서"| INGRESS
 ESO -.->|"Secret 동기화"| DDNS

 classDef problem fill:#ff6b6b,stroke:#c0392b,color:#fff
 classDef solution fill:#2ecc71,stroke:#27ae60,color:#fff
 classDef infrastructure fill:#3498db,stroke:#2980b9,color:#fff

 class Chrome problem
 class CF solution
 class Router,ControlPlane,Worker infrastructure

1.2 SK브로드밴드 공유기 설정

flowchart LR
 subgraph SKRouter["SK브로드밴드 공유기 설정"]
 direction TB

 subgraph DHCP["DHCP 설정"]
 DHCP_RANGE["DHCP 범위: 192.168.45.100 ~ .200"]
 DHCP_RES1["예약 1: mini-gmk<br/>MAC: XX:XX:XX:XX:XX:XX<br/>IP: 192.168.45.123"]
 DHCP_RES2["예약 2: mini-might<br/>MAC: YY:YY:YY:YY:YY:YY<br/>IP: 192.168.45.154"]
 end

 subgraph PortForward["포트포워딩"]
 PF_HTTP["외부 :80 → 192.168.45.154:80"]
 PF_HTTPS["외부 :443 → 192.168.45.154:443"]
 PF_VPN["외부 :51820 → 192.168.45.123:51820<br/>(WireGuard, 선택)"]
 end

 subgraph Firewall["방화벽 설정"]
 FW_IN["인바운드: 80, 443 허용"]
 FW_OUT["아웃바운드: 전체 허용"]
 FW_ICMP["ICMP: 허용 (ping)"]
 end

 subgraph NAT_Config["NAT 설정"]
 NAT_TYPE["NAT 타입: 대칭형 (Symmetric)"]
 NAT_UDP["UDP 타임아웃: 30초 (문제 원인)"]
 NAT_TCP["TCP 타임아웃: 3600초"]
 end
 end

 style NAT_UDP fill:#ff6b6b,stroke:#c0392b,color:#fff

공유기 설정 상세:

Swagger 403, ArgoCD 대시보드, CORS 이슈 해결

Wed, 11 Mar 2026 00:00:00 +0000

2026-03-11 | Swagger 403, ArgoCD 대시보드, CORS 이슈 해결

1. Swagger 403 → OAuth 로그인 리다이렉트

문제

swagger.dev.goormgb.space 접속 시 403 Forbidden 페이지 표시
로그인 페이지로 리다이렉트 되지 않음

원인

브라우저에 stale cookie (만료된 _oauth2_proxy 쿠키) 존재
OAuth2 Proxy가 쿠키를 검증하고 “유효하지 않음” → 403 반환
정상 흐름: 쿠키 없음 → 302 리다이렉트 → 로그인

[정상 흐름 - 쿠키 없음]
사용자 → OAuth2 Proxy → 쿠키 없음 → 302 → Google 로그인

[문제 상황 - 만료된 쿠키]
사용자 → OAuth2 Proxy → 쿠키 있음 (만료됨) → 403 Forbidden
 ↑ 여기서 멈춤!

해결: EnvoyFilter로 403→302 리다이렉트

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
 name: swagger-403-redirect
 namespace: istio-system
spec:
 workloadSelector:
 labels:
 istio: ingressgateway
 configPatches:
 - applyTo: HTTP_FILTER
 match:
 context: GATEWAY
 listener:
 filterChain:
 filter:
 name: envoy.filters.network.http_connection_manager
 subFilter:
 name: envoy.filters.http.router
 patch:
 operation: INSERT_BEFORE
 value:
 name: envoy.filters.http.lua
 typed_config:
 "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
 inlineCode: |
 function envoy_on_response(response_handle)
 local host = response_handle:headers():get(":authority") or ""
 local status = response_handle:headers():get(":status")

 -- swagger 도메인의 403 응답만 처리
 if string.find(host, "swagger") and status == "403" then
 local path = response_handle:headers():get("x-original-uri") or "/"
 local redirect_url = "/oauth2/start?rd=" .. path

 -- 302 리다이렉트로 변경
 response_handle:headers():replace(":status", "302")
 response_handle:headers():add("location", redirect_url)
 response_handle:headers():add("cache-control", "no-cache, no-store")
 end
 end

핵심 포인트

envoy_on_response: 응답 단계에서 가로채기
swagger 도메인만 처리 (다른 서비스 영향 없음)
403 → 302 변환 + /oauth2/start 리다이렉트
OAuth2 Proxy가 다시 로그인 프로세스 시작

2. CORS 에러로 프론트엔드 “하얗게 터짐”

문제

프론트엔드에서 API 호출 시 CORS 에러
브라우저 콘솔에 에러만 보이고 페이지 하얗게 터짐

원인

백엔드가 400, 500 에러 응답에 CORS 헤더를 포함하지 않음

[정상 응답 200]
Access-Control-Allow-Origin: https://dev.goormgb.space ✓
→ 프론트엔드가 응답 본문 읽기 가능

[에러 응답 500]
Access-Control-Allow-Origin: (없음) ✗
→ 브라우저가 응답 차단 → 프론트엔드에서 에러 원인 파악 불가
→ 에러 핸들링 불가 → 하얗게 터짐

왜 에러 응답에도 CORS 헤더가 필요한가?

브라우저 보안 정책: Origin이 다르면 모든 응답에 CORS 헤더 필요
에러 핸들링: CORS 헤더 없으면 response.json() 자체가 불가능
UX 개선: 에러 메시지를 사용자에게 보여줄 수 있음

해결 방안 (백엔드 팀 전달)

// Spring Boot - 에러 응답에도 CORS 헤더 포함
@Configuration
public class CorsConfig implements WebMvcConfigurer {
 @Override
 public void addCorsMappings(CorsRegistry registry) {
 registry.addMapping("/**")
 .allowedOrigins("https://dev.goormgb.space")
 .allowedMethods("*")
 .allowCredentials(true);
 }
}

// 또는 @ControllerAdvice에서 모든 예외 응답에 헤더 추가

3. /auth/token/refresh 404 에러

문제

프론트엔드에서 /auth/token/refresh 호출 시 404

원인: 경로 불일치

구분	경로
프론트엔드 호출	`/auth/token/refresh`
API Gateway 라우팅	`Path=/auth/**` → Auth-Guard
Auth-Guard 실제 경로	`/token/refresh` (클래스 레벨 @RequestMapping 없음)

프론트: /auth/token/refresh
 ↓
API Gateway: /auth/** 매칭 → Auth-Guard로 전달
 ↓
Auth-Guard: /auth/token/refresh 받음
 ↓
404! (실제로는 /token/refresh만 존재)

해결 방안 (백엔드 팀 전달)

옵션 1: StripPrefix 필터 추가 (권장)

Troubleshooting on blog.212clab

OTel 메트릭 대시보드 트러블슈팅

문제 상황

원인 분석

1. 메트릭 수집 경로가 2가지로 분리되어 있었음

2. gateway만 Micrometer 메트릭이 있었던 이유

3. OTel 메트릭에 namespace 라벨 누락

모니터링 데이터 S3 Object Storage 적재 구조

문제 상황

증상

근본 원인: EBS는 단일 AZ에 바인딩된다

환경별 모니터링 대시보드 분기처리

문제 상황

환경별 인프라 차이

증상

해결

1. 환경별 대시보드 분리

CloudTrail + S3 Bucket Policy 순환 의존성 문제

문제 상황

에러

원인 분석

Route53 레코드 삭제 + Secrets Manager 초기화 문제

문제 상황

원인 1: external-dns policy: sync

문제

흐름

수정

수정 파일

upsert-only vs sync

참고

원인 2: Secrets Manager secret_version 덮어쓰기

문제 (Prod)

Istio Sidecar 시작 타이밍 (holdApplicationUntilProxyStarts)

문제 상황

증상

원인 분석

k6-operator MaxVUs Parallelism Error

문제 상황

원인 분석

k6-operator 실행 흐름

문제 코드

DiskPressure & CrashLoopBackOff Troubleshooting

문제 상황

원인 분석

1. DiskPressure (mini-gmk)

2. CrashLoopBackOff

해결

DiskPressure 해결

Helm Values 수정

1. Loki retention 추가 (dev/staging)

2. revisionHistoryLimit 추가 (공통 차트)

3. staging ai-defense imagePullSecrets

4. dev ai-defense 환경변수

5. dev seat Kafka 설정

커밋

교훈

WireGuard + Cilium IP 대역 충돌 트러블슈팅

날짜

문제 상황

증상

원인 분석

1차 진단: tcpdump

2차 진단: Cilium 설정 확인

3차 진단: 라우팅 테이블 확인

근본 원인

해결

WireGuard 네트워크 대역 변경

Java OOM 트러블슈팅

문제 상황

증상

원인 분석

1. dmesg에서 OOM 로그 확인

ALB Elastic IP 자동 할당 이슈

문제 상황

증상

발견 경위

에러 메시지

확인된 상태

원인 분석

AWS 공식 답변

원인 1: external-dns `policy: sync`

원인 2: Secrets Manager `secret_version` 덮어쓰기