취미생활

Elasticsearch Pod Pending 원인: local PV와 taint 충돌 해결

바리새인 — Sat, 9 May 2026 08:38:20 +0900

ECK로 운영 중인 Elasticsearch에서 data pod가 Pending에 머물고 custom resource는 ApplyingChanges 상태를 벗어나지 못하는 경우가 있다. 이때 ECK 설정만 보면 원인을 놓칠 수 있다. 실제 원인은 local PV의 node affinity와 Kubernetes node taint가 충돌해서 scheduler가 pod를 배치하지 못하는 상황일 수 있다.

아래는 이 문제를 빠르게 분리하기 위한 요약이다. 이후 본문에는 당시 확인했던 과정과 판단 변경 지점을 그대로 남겼다.

빠른 결론

ApplyingChanges는 ECK 관점의 상태이고, Pending은 scheduler 관점의 상태다.
data pod가 Pending이면 먼저 pod event를 확인한다.
local PV를 쓰는 경우 PV의 node affinity가 특정 노드로 pod를 묶는다.
해당 노드에 taint가 있고 pod에 toleration이 없으면 scheduler는 pod를 올릴 수 없다.
ECK 설정 오류와 스케줄링 불가능 상태를 분리해서 봐야 한다.

먼저 볼 명령

kubectl describe pod <pod-name> -n <namespace>
kubectl get pv <pv-name> -o yaml
kubectl describe node <node-name>

describe pod의 event에서 taint, node affinity, volume node affinity conflict 같은 메시지가 보이면 ECK 설정보다 Kubernetes 스케줄링 조건을 먼저 확인하는 편이 빠르다.

Kubernetes에서 ECK로 운영하던 Elasticsearch가 한동안 ApplyingChanges 상태에 머물렀고, 일부 data pod는 Pending에서 올라오지 못했다. 처음에는 ECK 설정 오류가 먼저 눈에 들어왔지만, 실제로 pod를 막고 있던 직접 원인은 따로 있었다.

이 글은 당시 무엇을 오해했고, 어디서 판단을 바꿨고, 어떤 검증을 근거로 복구를 마무리했는지를 남기기 위한 기술 회고다. 공개용 문서이므로 노드명, IP, 도메인, 네임스페이스, 계정, 내부 레지스트리 주소 같은 식별 정보는 모두 일반화했다.

시작점: ApplyingChanges와 Pending을 같은 층위로 보면 헷갈린다

장애 당시 표면 증상은 두 가지였다.

Elasticsearch custom resource는 ApplyingChanges에 머물렀다.
일부 hot data pod는 Pending이었다.

겉으로 보면 둘 다 "Elasticsearch가 아직 정상화되지 않았다"는 하나의 문장으로 묶인다. 실제로 나도 초반에는 그렇게 봤다. 그런데 이 둘은 같은 시점에 보일 수는 있어도, 같은 원인일 필요는 없다.

이번 일에서 첫 번째로 막힌 지점이 바로 여기였다. ECK condition에 validation 오류가 보이니 그쪽을 먼저 고쳐야 한다고 생각하기 쉬웠다. 하지만 Pending은 scheduler가 pod를 어디에도 올리지 못하고 있다는 뜻이고, 이 문제는 ECK 설정 validation과는 별개로 먼저 확인해야 했다.

처음 확인한 것: 리소스 부족이 아니라 스케줄링 정책 충돌인지

우선 본 것은 pod 이벤트였다. 이유는 단순했다. Pending은 CPU나 메모리 부족일 수도 있지만, taint, affinity, PVC 제약처럼 scheduler 정책 문제일 때도 많기 때문이다.

당시 이벤트에서 핵심적으로 보인 메시지는 이런 종류였다.

FailedScheduling
had untolerated taint
Preemption is not helpful for scheduling

여기서 판단이 한 번 바뀌었다. 선점으로도 해결되지 않는다는 메시지가 붙어 있으면, 단순한 리소스 경쟁이 아니라 "배치 규칙 자체가 맞지 않는다"는 쪽으로 봐야 한다. 즉, 이 시점부터는 "무슨 리소스가 부족한가"보다 "이 pod가 원래 어디에 올라가야 하는가"를 보는 쪽이 맞았다.

전환점 1: PVC가 local PV에 묶여 있다는 사실

다음으로 확인한 것은 PVC와 PV였다. Elasticsearch data pod는 영속 볼륨에 묶여 있고, 특히 local PV를 쓰는 경우에는 storage가 곧 스케줄링 제약이 된다.

확인 결과, 문제 pod의 PVC는 특정 local PV에 바인딩되어 있었고, 그 PV에는 특정 노드만 허용하는 node affinity가 걸려 있었다. 공개용으로 일반화하면 구조는 이렇다.

PVC -> 특정 local PV에 바인딩
local PV -> 특정 worker node에만 연결 가능

여기서 상황이 꽤 명확해졌다. 이 pod는 "아무 노드에나 못 가는" 상태였다. 이미 storage 때문에 목적지가 거의 고정되어 있었고, 따라서 확인 범위도 그 노드 하나로 좁혀졌다.

전환점 2: local PV가 붙은 노드에 남아 있던 NoSchedule taint

PVC가 특정 노드로 pod를 사실상 고정하고 있다는 것을 확인한 뒤, 그 노드의 taint를 봤다. 거기서 실제 직접 원인이 나왔다.

문제 노드에는 불필요한 NoSchedule taint가 남아 있었고, Elasticsearch pod에는 그 taint를 허용하는 toleration이 없었다. 결과는 단순했다.

1. storage 때문에 pod는 특정 노드에 가야 함
2. 그런데 그 노드에는 NoSchedule taint가 남아 있음
3. pod는 toleration이 없음
4. 그래서 scheduler가 배치하지 못함

이번 장애에서 핵심은 이 충돌이었다. Pending의 직접 원인은 local PV와 taint 정책이 어긋난 것이었고, ECK condition 오류는 같은 시점에 보인 별도 문제였다.

내가 초반에 오해한 부분: ECK 오류가 먼저라고 본 것

incident 기록에는 ECK condition에서도 두 가지가 잡혀 있었다.

xpack.security.enabled가 사용자 config에 포함되어 있어 forbidden validation이 발생한 점
NodeSet의 memory request와 limit이 달라 resource-aware management 조건이 깨진 점

이 정보만 보면 "설정 오류부터 고치면 pod도 올라오겠지"라고 생각하기 쉽다. 나도 초반에는 그쪽이 더 근본 원인처럼 보였다. 하지만 실제로는 순서가 달랐다.

이 validation 오류들은 분명 정리해야 했지만, 문제 pod를 Pending에 묶어 둔 직접 이유는 아니었다. scheduler 이벤트, PVC 바인딩, PV node affinity, node taint를 같이 놓고 보니 우선순위가 분명해졌다.

즉, 이번 사고에서 중요한 판단 전환점은 이거였다.

"ECK가 ApplyingChanges니까 operator 설정부터 고쳐야 한다"가 아니라
"pod가 특정 노드에만 갈 수 있는데 그 노드가 정책상 막혀 있다"를 먼저 해결해야 했다.

실제 조치: taint 제거와 ECK spec 정상화를 분리해서 처리

실제 복구는 한 번에 끝난 것이 아니라 두 층위로 나눠서 진행됐다.

첫 번째는 스케줄링을 막는 직접 원인을 제거하는 일이었다. local PV가 붙은 노드에 잘못 남아 있던 taint를 제거했다. 이 조치의 의미는 workload에 새 toleration을 추가했다기보다, 해당 노드에 남아 있던 불필요한 격리 설정을 원래 의도에 맞게 되돌린 것이다.

두 번째는 ECK spec을 정상화하는 일이었다. 사용자 config에서 제거해야 하는 reserved 설정을 빼고, resource-aware management가 다시 성립하도록 NodeSet memory request와 limit을 맞췄다.

여기서 중요한 점은 둘을 섞어 생각하지 않는 것이었다.

taint 제거는 Pending의 직접 원인 제거
ECK spec 수정은 operator reconciliation을 정상화하기 위한 정리

둘 다 필요했지만, 같은 문제를 두 번 푸는 조치는 아니었다.

왜 StatefulSet replica 조정과 pod 재생성을 했는가

원인 조치 이후에는 hot StatefulSet replica를 복구하고, 오래 남아 있던 pod를 다시 생성했다. 이 부분은 단순 재시작이 목적이 아니라, 수정된 스케줄링 조건과 ECK spec이 실제 상태에 반영되도록 흐름을 정리하는 의미가 있었다.

이 조치를 할 때도 기준은 분명했다. "설정이 바뀌었다"만으로 끝내지 않고, 실제 pod가 다시 생성되어 올바른 노드에 배치되는지까지 봐야 했다.

무엇을 보고 해결됐다고 판단했나

이번에는 단순히 pod 하나가 뜨는 것만으로 종료하지 않았다. 복구 판단은 세 층위에서 같이 확인했다.

첫째, pod 배치가 정상인지 봤다. hot pod와 warm pod가 각각 의도한 노드에 Running으로 올라왔는지가 가장 직접적인 확인이었다.

둘째, Elasticsearch custom resource 상태를 봤다. ApplyingChanges에서 벗어나 Ready로 돌아왔는지, 그리고 data node 수가 기대한 값으로 복구됐는지를 확인했다.

셋째, ECK condition이 실제로 정리됐는지를 봤다. 당시 기준으로는 다음 조건들이 다시 정상이어야 했다.

ReconciliationComplete=True
RunningDesiredVersion=True
ElasticsearchIsReachable=True
ResourcesAwareManagement=True

이렇게 서로 다른 층위를 같이 봐야 "scheduler 문제만 잠깐 풀렸다"거나 "operator 조건만 좋아 보인다"는 착시를 피할 수 있었다.

이번 일에서 남긴 운영 기준

이번 장애는 복잡한 버그라기보다, 서로 다른 문제를 한 덩어리로 보면 복구 순서가 흐려진다는 점을 보여줬다.

다음에 비슷한 상황을 다시 보면 확인 순서는 이렇게 가져가는 편이 낫다.

1. Pending pod의 event부터 본다.
2. 선점 불가 메시지가 보이면 리소스 부족보다 정책 충돌을 먼저 의심한다.
3. Stateful workload라면 PVC와 PV binding을 확인한다.
4. local PV라면 node affinity와 실제 대상 노드의 taint를 같이 본다.
5. 그 다음에 ECK condition과 validation 오류를 별도 축으로 정리한다.

정리하면, 이번 사고의 직접 원인은 local PV node affinity와 node taint 충돌이었다. 하지만 실제로 오래 막혔던 이유는 Pending과 ApplyingChanges를 너무 오래 같은 문제처럼 본 데 있었다. 나중에 다시 비슷한 상황을 만나면, 그 둘을 먼저 분리해서 보는 것이 가장 큰 시간 절약 포인트가 될 것이다.

Sources

Original incident: docs/incidents/2026-04-25-elasticsearch-pending.md

Elasticsearch DiskPressure 회고: Pending 복구 뒤에도 끝나지 않았던 로그 보관 문제

바리새인 — Sat, 9 May 2026 08:06:38 +0900

한 번은 Elasticsearch Pending 문제를 복구한 뒤에도 cluster가 완전히 정상으로 돌아오지 않은 적이 있었다. 표면적으로는 리소스가 다시 올라왔고 custom resource도 Ready로 보였는데, 실제로는 특정 노드에 DiskPressure가 남아 있었고 Elasticsearch health도 yellow에서 멈춰 있었다.

이 글은 당시 내가 무엇을 먼저 오해했고, 어디서 판단을 바꿨고, 어떤 검증을 근거로 "이제 정말 끝났다"고 결론 내렸는지를 남기기 위한 기술 회고다. 공개용 문서이므로 노드명, IP, 도메인, 네임스페이스, 계정명, 내부 레지스트리 주소 같은 식별 정보는 모두 일반화했다.

시작점: Pending은 풀렸는데 왜 아직 불안했나

출발점은 직전 장애의 후속 확인이었다. 이전 이슈에서 Elasticsearch pod의 Pending 자체는 복구됐고, 그래서 처음에는 남은 yellow 상태도 shard 재배치가 끝나면 자연스럽게 정리될 것이라고 생각했다.

그런데 실제로는 두 가지가 같이 남아 있었다.

Elasticsearch는 Ready로 보였다.
한 노드는 DiskPressure=True였고 cluster health는 yellow였다.

처음에는 이 둘을 같은 문제의 잔여 증상으로 묶어서 봤다. 즉 "Pending이 길었던 여파로 아직 재배치가 덜 끝났나 보다"라고 생각했다. 지금 돌아보면 이게 첫 번째 오해였다.

Pending 복구와 저장소 압박은 겹쳐 보일 수는 있어도 같은 원인일 필요는 없다. 그걸 너무 늦게 분리해서 본 것이 이번 회고의 시작점이다.

확인 순서를 바꾼 이유

판단이 바뀐 계기는 노드 루트 파일시스템 사용률이었다. 단순히 shard가 옮겨지는 중이라면 health가 잠시 흔들릴 수는 있어도, 노드 자체가 DiskPressure에 들어가는 현상까지 자연스럽게 설명되지는 않았다.

여기서부터는 시선을 스케줄링에서 저장소로 옮겼다. 순서는 의도적으로 이렇게 잡았다.

1. 노드가 실제로 왜 압박 상태인지 본다.
2. Elasticsearch가 어느 data node에서 디스크를 많이 쓰는지 본다.
3. 어떤 index 또는 data stream이 비정상적으로 큰지 본다.
4. 그다음에야 ILM과 rollover가 왜 멈췄는지 본다.

이 순서를 택한 이유는 간단했다. 처음부터 ILM 정책 이름이나 템플릿만 보면 "설정은 있는 것 같은데 왜 안 지워지지?"에서 오래 헤맬 수 있기 때문이다. 먼저 어디에 용량이 쌓였는지를 봐야, 나중에 정책 문제를 보더라도 맥락이 붙는다.

전환점 1: 문제는 재배치가 아니라 오래된 backing index 누적이었다

노드 상태와 Elasticsearch allocation을 같이 보니 그림이 훨씬 선명해졌다. local PV를 쓰는 data node 하나에서 사용량이 과도하게 커져 있었고, 큰 비중을 차지한 것은 로그성 data stream이었다.

특히 눈에 띈 것은 두 종류였다.

metricbeat 계열 data stream
게임 서버 로그를 적재하던 minecraft-logs data stream

여기서 중요한 건 단순히 "인덱스가 크다"가 아니었다. 오래된 backing index가 계속 남아 있었고, 새 데이터가 들어오면서 전체 크기가 누적되는 구조가 보였다. 이 시점에서 문제를 "순간적인 트래픽 증가"가 아니라 "보관 정책 실패"로 보기 시작했다.

즉, 처음에 내가 따라가던 가설은 "cluster가 아직 덜 안정화됐다"였지만, 실제로는 "정리돼야 할 로그가 정리되지 않고 있었다"가 더 정확했다.

전환점 2: 둘 다 ILM 문제였지만 고장 방식은 달랐다

조금 더 들어가 보니 두 data stream은 결과는 비슷했지만 실패 방식이 서로 달랐다. 이 차이를 확인한 것이 가장 큰 판단 전환점이었다.

metricbeat: 정책은 있었지만 실행 권한이 깨져 있었다

처음 metricbeat를 봤을 때는 더 헷갈렸다. ILM policy 자체는 존재했기 때문이다. 그래서 한동안은 "정책이 있는데 아직 rollover 시점이 안 왔나" 같은 쪽으로 생각이 기울었다.

하지만 ILM explain을 확인하면서 상황이 달라졌다. rollover가 반복 실패하고 있었고, 오류는 권한 문제였다. 당시 핵심 오류는 이런 형태였다.

action [indices:admin/rollover] is unauthorized for API key
failed_step: check-rollover-ready

이 메시지를 보고 나서야 "정책 존재"와 "정책이 실제로 실행 가능함"은 완전히 다른 문제라는 점이 분명해졌다. metricbeat는 ILM이 없는 게 아니라, 과거 권한 상태로 저장된 실행 주체 때문에 rollover를 계속 못 하고 있었다.

minecraft 로그: 참조한 정책 이름은 있었지만 실제 policy는 없었다

반대로 minecraft-logs는 더 직접적인 오류였다. data stream 쪽 설정은 특정 ILM policy를 참조하고 있었지만, 정작 그 policy 객체가 클러스터에 존재하지 않았다.

오류는 아주 명확했다.

policy [minecraft-logs-ilm] does not exist

이 경우는 아예 정리 로직이 붙어 있지 않은 상태나 다름없었다. 데이터는 계속 쌓이는데 지워질 조건을 해석할 정책이 없으니, 오래된 backing index가 계속 남는다.

여기서 두 번째 오해도 정리됐다. 나는 처음에 둘 다 "로그가 많아서 디스크가 찼다" 정도로 뭉뚱그렸는데, 실제로는

하나는 "정책은 있으나 실행 실패"
다른 하나는 "정책 참조만 있고 실체 없음"

이라는 전혀 다른 실패였다.

왜 노드에서 임시 정리를 먼저 했는가

이 시점에는 근본 원인이 보였지만, 노드 압박도 동시에 풀어야 했다. 다만 여기서 조심한 것은 Elasticsearch local PV 아래 파일을 직접 지우지 않는 것이었다. 디스크가 급하다고 data path를 수동으로 건드리면 장애를 더 키울 가능성이 높다.

그래서 먼저 한 일은 운영체제 레벨에서 안전하게 줄일 수 있는 항목만 정리하는 것이었다.

system journal 축소
사용하지 않는 container image 정리
패키지 캐시 정리

이 단계의 목적은 문제를 해결하는 것이 아니라, 노드가 DiskPressure에서 잠시 빠져나와 다시 운영 가능한 상태를 확보하는 것이었다. 실제로 이 조치 뒤에는 루트 파일시스템 사용률이 내려가고 DiskPressure=False로 돌아왔다.

중요했던 건 여기서 멈추지 않은 것이다. 이 상태만 보면 해결된 것처럼 느껴질 수 있지만, Elasticsearch 내부에는 여전히 오래된 backing index가 남아 있었고, 그대로 두면 같은 일이 다시 반복될 구조였다.

실제 해결: 보관 정책 재정의, rollover, 그리고 non-write backing index 삭제

근본 해결은 두 data stream의 보관 기준을 다시 명확히 두는 것이었다.

rollover: 7일 또는 primary shard 10GB
delete: 30일

metricbeat는 정책을 다시 써 넣은 뒤, 실패하던 ILM 단계를 재시도하고 rollover를 일으켰다. 그리고 새 write index가 생긴 것을 확인한 다음에 오래된 backing index를 삭제했다.

minecraft-logs는 누락된 policy를 만든 뒤 rollover를 수행하고, 더 이상 write index가 아닌 오래된 backing index들을 삭제했다.

여기서 내가 특히 신경 쓴 검증은 "삭제가 성공하느냐"가 아니라 "지워도 되는 대상을 고른 게 맞느냐"였다. 실제 작업 흐름은 아래와 같은 판단 순서를 따른다.

1. data stream의 현재 write index 확인
2. ILM policy 수정 또는 생성
3. rollover 수행
4. 새 backing index 생성 확인
5. 이전 non-write backing index 삭제

이 순서는 실제 작업 흐름을 일반화한 것이다. 환경마다 이름과 호출 방식은 다를 수 있고, 위 텍스트는 공개용 설명을 위한 예시다. 실제로 하지 않은 추가 조치나 자동화는 여기서 한 것처럼 적지 않았다.

무엇을 보고 "진짜 해결됐다"고 판단했나

이번에는 단순히 에러 메시지가 줄어든 것을 종료 기준으로 잡지 않았다. 대신 서로 다른 층위의 상태가 함께 좋아지는지를 확인했다.

Elasticsearch cluster health가 green으로 돌아오는가
custom resource phase가 계속 Ready인가
문제 노드의 DiskPressure가 해제됐는가
node별 Elasticsearch disk allocation이 실제로 감소했는가
새 write index가 생성됐고 오래된 대형 backing index가 사라졌는가

이 중에서 특히 중요했던 것은 node별 disk 사용률 감소였다. 정책이 "설정돼 있다"는 것과, 실제로 디스크 누수가 멈췄다는 것은 다르다. 이번에는 후자까지 확인하고 나서야 종료할 수 있었다.

최종적으로 cluster health는 green으로 복구됐고, 문제 노드의 DiskPressure도 해제됐다. 그제야 직전 Pending 이슈와는 별개의 꼬리 문제까지 정리됐다고 볼 수 있었다.

이번 일에서 남은 교정 포인트

이번 사고는 복잡한 신기능 장애라기보다, 내가 상태를 너무 빨리 낙관적으로 해석한 사건에 가까웠다.

당시 내가 놓쳤던 포인트는 세 가지였다.

첫째, Pending이 풀렸다고 해서 storage pressure까지 같이 해결됐다고 보면 안 된다. 스케줄링 복구와 데이터 축적 문제는 별개의 축이다.

둘째, ILM은 정책 이름이 있느냐만 보면 안 된다. policy 존재, template 연결, rollover 조건, delete phase, 실행 권한이 모두 살아 있어야 실제 보관이 동작한다.

셋째, local PV를 쓰는 Elasticsearch에서는 인덱스 보관 정책이 곧 노드 운영 정책이다. Elasticsearch 안에서의 누적 문제가 곧 Kubernetes 노드 condition으로 드러난다.

다음에 비슷한 징후를 보면

이번 회고 이후로는 비슷한 상황에서 확인 순서를 이렇게 가져갈 생각이다.

1. Pending이나 yellow를 보더라도 바로 재배치 문제라고 단정하지 않는다.
2. node condition과 Elasticsearch allocation을 같이 본다.
3. 큰 index를 찾을 때는 현재 크기보다 오래된 backing index 누적 여부를 먼저 본다.
4. ILM은 정책 존재 여부와 실행 실패 원인을 분리해서 본다.
5. 디스크가 급해도 Elasticsearch data path는 직접 지우지 않는다.

이번 글의 목적은 정답을 미리 써 두는 것이 아니라, 당시 내가 어디서 막혔는지 나중에 다시 복원할 수 있게 만드는 것이다. 그 기준에서 보면 이번 사건의 핵심은 "명령어"보다 "잘못 묶어 본 가설을 언제 해체했는가"에 있었다.

Sources

Original incident: docs/incidents/2026-04-25-elasticsearch-log-retention-disk-pressure.md

authentik OIDC를 Kubernetes에 붙일 때 반드시 알아야 할 핵심

바리새인 — Sun, 26 Apr 2026 07:39:57 +0900

Kubernetes 안에 authentik을 올리고, 내부 운영 서비스에 OIDC 로그인을 붙이다 보면 처음에는 내부 HTTP로 빠르게 확인하고 나중에 외부 HTTPS 요구가 생기는 경우가 많다.

이번 글은 그 과정에서 어떤 점을 확인했고, 왜 결국 authentik도 외부 HTTPS host 기준으로 정리해야 했는지를 기록한 내용이다.

구성 자체는 단순했다.

authentik = Identity Provider
ooo service = OIDC Client
Kubernetes Ingress = authentik 외부 진입점
cert-manager + Let's Encrypt = TLS 인증서 발급
외부 PostgreSQL = authentik DB

하지만 실제 운영에서는 아래 세 가지가 핵심이었다.

1. authentik Helm chart가 existingSecret + 외부 PostgreSQL 구성을 제대로 받는가
2. OIDC discovery가 실제 host 기준으로 올바른 issuer/endpoints를 내보내는가
3. 외부 사용자가 로그인해야 한다면 authentik host도 외부 HTTPS로 열려 있어야 하는가

1. 내부 HTTP로도 초기 확인은 가능하다

초기 점검 단계에서는 authentik을 내부망 전용 HTTP로 올려도 기본 동작은 확인할 수 있다.

예를 들면 아래와 같은 항목이다.

- Helm lint / template 통과
- existingSecret 주입 확인
- PostgreSQL 연결 확인
- initial setup / health check 응답 확인
- OIDC discovery 문서 생성 확인

확인 URL은 이런 식으로 볼 수 있다.

/if/flow/initial-setup/ -> 200
/application/o/<app>/.well-known/openid-configuration -> 200

이 단계에서는 "authentik이 기본적으로 동작하는가"를 빠르게 보는 데 의미가 있다.

즉, 내부 HTTP는 초기 검증용으로는 충분하다.

하지만 이 상태가 실제 외부 사용자 로그인까지 보장하는 것은 아니다.

2. 외부 로그인 요구가 생기면 구조가 달라진다

문제는 ooo 서비스가 외부에서 접근 가능하고, 실제 사용자 로그인도 외부 브라우저에서 해야 하는 경우다.

처음에는 이런 생각을 하기 쉽다.

ooo service만 외부에 열고
authentik은 내부 주소로 둬도 되지 않을까?

하지만 OIDC는 그렇게 단순하지 않다.

OIDC는 브라우저 redirect 기반 프로토콜이다.

즉, 로그인 중간에 사용자의 브라우저가 실제로 issuer, authorization_endpoint 주소로 이동해야 한다.

구조가 아래처럼 되어 있다면 문제가 생긴다.

ooo service = 외부 공개
authentik = 내부 전용

외부 사용자는 로그인 중에 결국 내부 주소를 따라가게 되고, 브라우저에서 해당 주소에 접근할 수 없게 된다.

따라서 운영 판단은 명확하다.

- 내부망 전용 서비스면 ooo도 내부/VPN 전용으로 유지
- 외부 사용자가 로그인해야 하면 authentik도 외부 HTTPS host로 노출

정리하면 이렇다.

외부 사용자가 로그인해야 한다면
authentik도 사용자의 브라우저에서 접근 가능한 HTTPS 주소여야 한다.

3. 가장 중요한 검증 지점은 OIDC Discovery다

authentik 쪽에서 가장 중요하게 본 것은 OIDC discovery 문서였다.

왜냐하면 이 문서가 실제 로그인 흐름에 쓰이는 기준 주소를 보여주기 때문이다.

확인해야 할 값은 아래와 같다.

issuer
authorization_endpoint
token_endpoint
userinfo_endpoint
jwks_uri

운영 기준 주소가 외부 HTTPS host라면, 이 값들도 전부 같은 기준으로 나와야 한다.

예를 들면 아래와 같은 형태여야 한다.

https://auth.example.com/application/o/my-app/
https://auth.example.com/application/o/authorize/
https://auth.example.com/application/o/token/
https://auth.example.com/application/o/userinfo/
https://auth.example.com/application/o/my-app/jwks/

특히 중요한 것은 issuer다.

issuer 값이 외부 HTTPS 주소와 다르면 로그인, 토큰 검증, 콜백 처리에서 문제가 발생할 수 있다.

여기서 내부 HTTP 주소가 섞여 있으면 나중에 로그인, 콜백, 세션 처리에서 어색한 문제가 이어질 수 있다.

그래서 설정 파일만 보는 것보다 discovery 결과를 직접 확인하는 것이 더 안전하다.

4. Helm chart에서 hostname 값을 억지로 찾기보다 결과를 확인한다

이런 작업을 하면 보통 HOST, hostname, public_url 비슷한 값을 먼저 찾게 된다.

하지만 실제 chart와 공식 문서를 보면 항상 기대한 이름으로 준비되어 있지는 않을 수 있다.

그래서 임의 키를 추가하기보다 아래 순서로 확인하는 편이 안전하다.

1. Ingress host가 원하는 host로 설정됐는가
2. Ingress가 Host / X-Forwarded-* 헤더를 정상 전달하는가
3. Application / Provider 생성 후 discovery 결과가 실제 기대 host로 보이는가

여기서 중요한 것은 설정 이름이 그럴듯한지가 아니다.

결과가 실제로 원하는 외부 HTTPS 주소로 나오는지가 중요하다.

특히 Ingress 뒤에 authentik이 있을 경우 아래 헤더 흐름도 중요하다.

Host
X-Forwarded-Proto
X-Forwarded-Host

이 값들이 어긋나면 authentik이 내부 HTTP 기준 URL을 생성할 수 있다.

따라서 최종 판단은 discovery 문서로 하는 것이 좋다.

5. Secret은 values.yaml에 직접 넣지 않고 existingSecret으로 분리했다

민감정보는 Helm values에 직접 넣지 않았다.

분리한 값은 아래와 같다.

authentik secret key
PostgreSQL host
PostgreSQL port
PostgreSQL database
PostgreSQL user
PostgreSQL password

이 값들은 Git 밖의 env 파일에서 Kubernetes Secret으로 만든 뒤, chart에서는 existingSecret만 참조하도록 구성했다.

이 방식의 장점은 분명하다.

- values.yaml에 민감값이 들어가지 않는다
- Secret 재적용과 Helm 배포를 분리할 수 있다
- preflight에서 required key 존재 여부를 따로 검증할 수 있다

운영 환경에서는 이런 구조가 훨씬 안전하다.

특히 인증 시스템은 Secret 값이 많기 때문에 values 파일에 직접 넣기 시작하면 나중에 Git 관리와 배포 관리가 복잡해진다.

6. cert-manager와 Let's Encrypt는 별도로 상태를 확인해야 한다

Ingress에 TLS와 cert-manager annotation을 추가했다고 바로 끝나는 것은 아니다.

실제로는 아래 순서로 봐야 한다.

kubectl get ingress -n <namespace>
kubectl get certificate,order,challenge -n <namespace>

중요한 점은 이거다.

Ingress 반영 완료 != 인증서 발급 완료

Ingress는 생성됐지만 Certificate가 아직 READY=False일 수 있다.

또는 Order, Challenge가 pending 상태일 수도 있다.

그래서 운영 문서에는 반드시 아래 항목을 나눠서 적는 것이 좋다.

- Ingress 적용 여부
- Certificate READY 여부
- HTTPS 응답 여부
- OIDC discovery HTTPS 응답 여부

인증서가 아직 준비되지 않았는데 OIDC 오류로 착각하면 문제 원인을 잘못 잡을 수 있다.

7. 로그인뿐 아니라 로그아웃 흐름도 같이 봐야 한다

OIDC 연동은 discovery만 맞는다고 끝나지 않는다.

실제 사용자가 체감하는 부분은 보통 두 가지다.

1. 포털에서 앱 타일을 눌렀을 때 어디로 이동하는가
2. 앱에서 logout 했을 때 authentik 세션도 같이 정리되는가

로그인은 되는데 로그아웃이 이상한 경우도 많다.

예를 들면 아래와 같은 상태다.

- 앱에서는 로그아웃됐지만 authentik 세션은 살아 있음
- 다시 앱에 들어가면 자동 로그인됨
- logout 후 redirect URL이 기대한 곳과 다름

그래서 다음 값도 운영 문서에 함께 고정해두는 것이 좋다.

- authentik Application Launch URL
- provider invalidation flow
- User Logout stage 포함 여부
- app logout -> authentik end-session redirect

이걸 문서에 남겨두지 않으면 나중에 "로그인은 되는데 로그아웃이 이상하다" 같은 반쪽짜리 상태가 되기 쉽다.

8. 마지막은 groups claim과 role mapping 확인이다

OIDC가 연결됐다고 바로 모든 권한 연동이 끝난 것은 아니다.

discovery 문서에는 groups claim 지원이 보일 수 있다.

하지만 실제 토큰이나 userinfo에 원하는 형태로 내려오는지는 별도로 확인해야 한다.

마지막 체크는 아래 흐름으로 보는 것이 좋다.

1. 로그인 성공
2. callback / session 흐름 확인
3. discovery issuer/endpoints 확인
4. groups claim 실제 수신 확인
5. app 내부 role mapping 기대값과 비교

이 단계까지 확인해야 "로그인이 된다"가 아니라 "권한 연동도 된다"로 정리할 수 있다.

실전 체크리스트

authentik OIDC를 Kubernetes에 붙일 때는 아래 순서로 확인하는 것이 좋다.

1. Secret은 existingSecret으로 분리했는가
2. 외부 PostgreSQL 연결이 정상인가
3. initial setup / health check가 정상인가
4. Ingress host가 실제 운영 host인가
5. cert-manager Certificate가 READY=True인가
6. OIDC discovery의 issuer가 외부 HTTPS 기준인가
7. authorization_endpoint, token_endpoint, userinfo_endpoint가 외부 HTTPS 기준인가
8. 로그인 callback이 정상인가
9. logout / invalidation flow가 정상인가
10. groups claim과 app role mapping이 정상인가

정리

이번 경험을 한 줄로 줄이면 이렇다.

authentik OIDC는 내부 HTTP로 빠른 기능 확인은 가능하지만,
외부 사용자가 실제 로그인해야 하는 순간부터는 authentik도 외부 HTTPS host 기준으로 정리해야 한다.

운영에서 특히 중요했던 포인트는 아래와 같다.

1. Secret은 existingSecret으로 분리
2. 외부 PostgreSQL 연결은 preflight에서 실제 login까지 확인
3. Host 설정은 키 이름보다 discovery 결과로 검증
4. 외부 로그인 요구가 있으면 issuer host도 외부 HTTPS로 노출
5. cert-manager는 ingress 적용과 certificate READY를 나눠서 확인
6. login뿐 아니라 logout / invalidation flow까지 문서화
7. groups claim과 role mapping까지 확인

결국 OIDC 문제는 "붙었다 / 안 붙었다"보다 실제 브라우저가 어디로 이동하는지와 discovery가 어떤 URL을 내보내는지를 차분히 보는 쪽이 더 빠르다.

Kubernetes 노드 점검 직후 재부팅: busybox exec format error와 원인 분리

바리새인 — Sat, 25 Apr 2026 23:39:54 +0900

운영 중 특정 노드에서 디스크 점검 직후 재부팅이 발생했다.
처음에는 점검 명령이 원인처럼 보였지만, 실제로는 debug image 문제
가능성이 있었다.

Node 재부팅이 발생했을 때는 "명령 때문인지, 환경 때문인지" 먼저
분리하는 것이 중요하다.

1. 증상

Warning Rebooted 발생
NodeReady 재진입
동일 노드 pod 재시작

2. 정상 reboot 여부 확인

정상 reboot라면 systemd-shutdown 로그가 남는다.
하지만 이번에는 로그가 끊겨 있었다.

정상 reboot 아님 가능성

3. busybox debug 실패

kubectl debug node/<node>{=html} --image=busybox:1.36

결과:

exec format error

exec format error는 보통 아키텍처 mismatch 또는 이미지 호환성
문제에서 발생한다.

4. ubuntu로 재현

kubectl debug node/<node>{=html} --image=ubuntu:22.04

df, du 등 점검 수행 → 정상 완료

재부팅 없음

5. 결론

busybox → 실패
ubuntu → 정상

점검 명령 자체는 안전
debug image 문제 가능성 높음

6. 운영 대응

기본 debug image 변경

busybox ❌
ubuntu ✅

debug image는 "가벼움"보다 "호환성 검증"이 중요하다.

7. 실무 체크리스트

reboot 이벤트 확인
shutdown 로그 확인
debug image 최소 실행 테스트
다른 이미지로 재현
runbook 기본값 수정

Kubernetes 현황판 Root Disk가 N/A일 때: Metricbeat와 Elasticsearch 연결 문제 해결

바리새인 — Sat, 25 Apr 2026 22:15:09 +0900

Kubernetes 운영 현황판에서 CPU와 memory는 정상적으로 나오는데 root
disk만 N/A로 표시되는 문제가 발생했다.

처음에는 Metricbeat가 디스크 정보를 수집하지 못하는 문제처럼 보였지만,
실제 원인은 대시보드 API pod에 Elasticsearch 접속 환경변수가 주입되지
않은 것이었다.

이 글은 Kubernetes API, Metricbeat, Elasticsearch, application runtime
env를 단계별로 점검하며 원인을 좁힌 과정을 정리한다.

핵심 포인트 (먼저 정리)

N/A는 데이터 없음이 아니라 조회 실패일 가능성이 높다

CPU / Memory와 Disk는 데이터 경로가 다르다

CPU / Memory → metrics-server → Kubernetes API
Root Disk → Metricbeat → Elasticsearch → Dashboard API

1. 증상

NODE CPU MEMORY ROOT DISK READY STATUS
worker-1 1% 74% N/A True OK
worker-2 7% 72% N/A True OK
worker-3 4% 83% N/A True Watch
worker-4 31% 64% N/A True OK

2. Metricbeat 확인

kubectl get pods -n <monitoring-namespace>{=html} | grep metricbeat

모든 노드에 Running이면 정상

3. Elasticsearch 확인

kubectl port-forward svc/<es-service>{=html} 9200:9200 -n
<namespace>{=html}

curl 'http://localhost:9200/\_cat/indices/metricbeat-\*'

데이터 있으면 정상

4. Root filesystem 확인

curl 'http://localhost:9200/metricbeat-\*/\_search'

/ 또는 /hostfs mount 확인

5. 핵심 원인

Metricbeat 정상
Elasticsearch 정상
BUT Application → Elasticsearch 연결 실패

즉, env 문제

6. env 확인

kubectl exec deploy/<app>{=html} -- env | grep ES

값 없으면 문제

7. 해결

APP_ES_URL=http://...
APP_ES_USERNAME=elastic
APP_ES_PASSWORD=...

8. rollout restart

kubectl rollout restart deploy/<app>{=html}

9. 검증

root disk % 정상 표시

실무 체크리스트

Metricbeat pod 존재 여부\
ES 데이터 존재 여부\
mount point 확인\
env 존재 여부\
rollout 여부

결론

Disk N/A는 Metricbeat 문제가 아니다

대부분은 Elasticsearch 연결 문제(env)

데이터 경로를 나눠서 확인하면 빠르게 해결된다

Elasticsearch DiskPressure 원인 분석: ILM 보관 정책으로 해결한 사례

바리새인 — Sat, 25 Apr 2026 16:06:12 +0900

Elasticsearch Pod Pending 문제를 해결한 이후에도 cluster 상태가
yellow로 유지되는 현상이 발생했다.
확인 결과 스케줄링 문제가 아니라 로그성 data stream 증가로 인한 디스크
압박(DiskPressure) 이 원인이었다.

이 글에서는 실제 운영 환경에서 발생한 문제를 기준으로
인덱스 용량 확인 → ILM 설정 → 정리 과정까지 정리한다.

1. 증상

노드 상태 확인:

kubectl describe node <node-name>{=html}

DiskPressure 발생

Elasticsearch 상태:

kubectl get elasticsearch -n <namespace>{=html}

Ready 상태지만 내부적으로 shard allocation 제한 발생

⚠️ 2. 원인 확인 (인덱스 크기)

Elasticsearch 접근:

kubectl port-forward svc/<es-http-service>{=html} 9200:9200 -n
<namespace>{=html}

인덱스 크기 확인:

curl -s 'http://localhost:9200/\_cat/indices?v&s=store.size:desc'

디스크 사용량:

curl -s 'http://localhost:9200/\_cat/allocation?v'

문제 인덱스

metricbeat data stream (대용량) minecraft logs (중간 규모)

로그성 데이터가 계속 누적됨

3. 위험한 행동 (하지 말 것)

❌ local PV 내부 파일 직접 삭제
→ Elasticsearch index 깨짐

️ 4. 임시 대응 (디스크 확보)

journalctl --vacuum-size=500M crictl rmi --prune apt clean

OS/컨테이너 레벨 정리만 수행

5. ILM 정책 문제

문제 1:

rollover 실패 (권한 문제)

문제 2:

policy 자체 없음

로그는 계속 쌓이지만 삭제 안 됨

✅ 6. 해결: ILM 정책 설정

정책 기준:

rollover: 7일 또는 10GB
delete: 30일

예시:

curl -X PUT 'http://localhost:9200/\_ilm/policy/log-policy'\
-d '{ "policy": { "phases": { "hot": { "actions": { "rollover": {
"max_age": "7d", "max_primary_shard_size": "10gb" } } }, "delete": {
"min_age": "30d", "actions": { "delete": {} } } } } }'

7. Rollover + Index 정리

rollover 실행:

curl -X POST 'http://localhost:9200/``{=html}/_rollover'

오래된 index 삭제:

curl -X DELETE 'http://localhost:9200/``{=html}'

⚠️ 주의

삭제 전 반드시 확인:

curl 'http://localhost:9200/\_data_stream/``{=html}'

write index 삭제하면 장애 발생

✅ 8. 결과

DiskPressure 해소
Elasticsearch health → green

실무 체크리스트

ILM policy 존재 여부
template 연결 여부
rollover 설정 여부
delete phase 존재 여부
권한 정상 여부

결론

Elasticsearch DiskPressure는 단순 디스크 문제가 아니라
ILM 정책 미설정 문제

local PV 환경에서는 반드시 ILM을 설정해야 한다

Elasticsearch Pod Pending 원인 분석: local PV와 taint 충돌 해결

바리새인 — Sat, 25 Apr 2026 16:02:26 +0900

Kubernetes 환경에서 ECK로 운영 중인 Elasticsearch Pod가 장시간 Pending
상태에 머무르는 문제가 발생했다.
처음에는 리소스 부족을 의심했지만, 실제 원인은 local PV의 node
affinity와 node taint 정책 충돌이었다.

이 글에서는 해당 문제의 원인과 해결 과정을 실무 기준으로 정리한다.

1. 증상

kubectl get pods -n <namespace> -o wide
kubectl get elasticsearch,kibana -n <namespace>

es-es-hot-ssd-0   0/1   Pending

Kibana와 Operator는 정상
Elasticsearch만 ApplyingChanges 상태 유지

⚠️ 2. 스케줄링 이벤트

kubectl describe pod <pod-name> -n <namespace>

FailedScheduling
had untolerated taint
Preemption is not helpful

리소스 부족 ❌
스케줄링 정책 충돌 ✅

3. PVC / PV 확인

kubectl describe pv <pv-name>

Node Affinity:
  kubernetes.io/hostname in [node-a]

local PV = 특정 노드 강제 배치

4. 핵심 원인

kubectl describe node <node-name>

tier=frontend:NoSchedule

Pod에는 toleration 없음

정리

PVC → local PV 바인딩
PV → 특정 노드 고정
노드 → taint 존재
Pod → toleration 없음
결과 → Pending

5. 해결 방법

방법 1: taint 제거 (권장 - 잘못된 설정일 경우)

kubectl taint node <node-name> tier=frontend:NoSchedule-

방법 2: toleration 추가

tolerations:
  - key: tier
    operator: Equal
    value: frontend
    effect: NoSchedule

정책 유지가 목적이라면 이 방법

⚙️ 6. ECK 추가 체크

메모리 설정

resources:
  requests:
    memory: 2Gi
  limits:
    memory: 2Gi

request = limit 맞춰야 함

상태 확인

kubectl get elasticsearch <name> -n <namespace> \
-o jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\n"}{end}'

✅ 7. 최종 확인

kubectl get pods -n <namespace>

Running 상태 확인

8. 실무 체크리스트

1. pod event 확인
2. toleration 확인
3. PVC/PV binding 확인
4. local PV node affinity 확인
5. node taint 확인

결론

Elasticsearch Pending 문제는 단순 리소스 문제가 아니라
storage + scheduling 정책 충돌 문제였다.

local PV 사용 시 반드시 taint까지 함께 확인해야 한다.

Kubernetes에서 Slack Webhook을 안전하게 관리하는 방법 (Fluentd + Minecraft 알림)

바리새인 — Sat, 25 Apr 2026 15:51:55 +0900

Minecraft 서버 접속 로그를 기반으로 Slack 알림을 보내는 환경을 운영하던
중, Slack Webhook URL이 Kubernetes manifest에 평문으로 포함된 문제를
발견했다.

처음에는 단순히 동작 여부만 확인했지만, 운영 환경에서는 보안과 관리
방식이 더 중요하다.

이 글에서는 실제 운영 환경에서 Webhook을 Git과 분리하고 안전하게 관리한
방법을 정리한다.

1. 기존 구조

전체 흐름:

Minecraft 로그 → Fluentd → 로그 필터 → Slack Webhook

Fluentd 설정 예시:

<match minecraft.alert> @type slack webhook_url
"#{ENV['SLACK_WEBHOOK_URL']}" </match>{=html}

2. 문제점

기존 방식:

kind: Secret stringData: webhook_url: "<slack-webhook-url>{=html}"

문제:

Git 커밋 시 노출 위험
코드 리뷰/백업에서 유출 가능
블로그 작성 시 실수 복사 가능
Webhook 교체(rotate) 어려움

3. 개선 전략

핵심 원칙:

Secret 값은 Git에 넣지 않는다
Secret은 외부에서 생성한다
애플리케이션은 Secret을 참조만 한다

4. Secret 외부 관리

파일 위치:

/secure/path/monitoring.env

내용:

SLACK_WEBHOOK_URL=...

권한 설정:

chmod 600 monitoring.env

5. Secret 생성

kubectl create secret generic slack-webhook
--from-literal=webhook_url="$SLACK_WEBHOOK_URL"

6. Fluentd 연동

env: - name: SLACK_WEBHOOK_URL valueFrom: secretKeyRef: name:
slack-webhook key: webhook_url

7. 운영 팁 (중요)

Kubernetes Secret은 base64 → 암호화 아님
webhook 노출 시 즉시 재발급
Fluentd 장애 시 알림 중단됨
중요한 알림은 Grafana/Prometheus와 병행 추천

8. 실무 체크리스트

Git에 Secret 포함 여부 확인
Secret 외부 관리 여부 확인
환경변수 주입 정상 여부 확인
로그 필터 정상 동작 확인
Slack 전송 로그 확인

9. 결론

Webhook 같은 민감 정보는 반드시 Git에서 분리해야 한다.

운영 환경에서는

Secret + 외부 관리 구조

를 기본으로 사용하는 것이 안전하다.

Bitnami Kafka KRaft Controller ImagePullBackOff 원인 및 복구 방법

바리새인 — Sat, 25 Apr 2026 11:22:09 +0900

Bitnami Kafka KRaft Controller ImagePullBackOff 원인 및 복구 방법

Kubernetes 환경에서 Kafka(KRaft 모드) controller Pod 중 하나가 장시간 ImagePullBackOff 상태에 머무는 문제가 발생했다.
초기에는 노드 문제나 네트워크 이슈로 보였지만, 실제 원인은 이미지 repository 변경이었다.

이 글에서는 문제 원인과 복구 과정을 순서대로 정리한다.
(※ 네임스페이스, 노드명, 내부 주소 등은 모두 일반화된 값이다)

1. 증상

Kafka controller Pod 하나가 정상적으로 올라오지 않았다.

kubectl get pods -n -o wide

kafka-kraft-controller-2 0/1 Init:ImagePullBackOff

이벤트를 확인했다.

kubectl describe pod -n kafka-kraft-controller-2

Pulling image "docker.io/bitnami/kafka:4.0.0-debian-12-r10"
Back-off pulling image

2. 배포 방식 확인 (Helm)

helm list -n
helm get values -n
kubectl get sts -n -o yaml

Helm chart: bitnami/kafka
Chart version: 32.4.2
App version: 4.0.0

3. 실제 이미지 Pull 테스트

crictl pull docker.io/bitnami/kafka:4.0.0-debian-12-r10

결과: not found

4. 원인

docker.io/bitnami/kafka:4.0.0-debian-12-r10 → 삭제됨
docker.io/bitnamilegacy/kafka:4.0.0-debian-12-r10 → 사용 가능

5. 해결

helm upgrade --install bitnami/kafka
--version 32.4.2
--namespace
--set image.registry=docker.io
--set image.repository=bitnamilegacy/kafka
--set image.tag=4.0.0-debian-12-r10

6. 확인

kubectl rollout status sts/ -n
kubectl get pods -n

7. 결론

ImagePullBackOff 발생 시 이미지 존재 여부부터 확인해야 한다.

Kubernetes 노드 디스크 부족 해결: containerd 이미지와 로그 정리

바리새인 — Sat, 25 Apr 2026 10:55:20 +0900

Kubernetes 노드에서 root filesystem 사용량이 높아지면 아직 DiskPressure=False 상태라도 이미지 pull 실패, pod eviction, kubelet 이상 동작으로 이어질 수 있다. 이럴 때는 무작정 파일을 지우기보다 containerd 이미지, journald 로그, 실제 사용량을 순서대로 확인하는 것이 안전하다.

이 글에서는 Kubernetes 노드 디스크 사용량이 높을 때 확인한 순서와 정리 방법을 정리한다.

1. 노드 상태 확인

먼저 노드가 실제로 압박 상태인지 확인한다.

kubectl describe node <node-name>

확인할 항목은 아래와 같다.

DiskPressure
MemoryPressure
PIDPressure
Ready
event에 eviction 관련 메시지가 있는지

DiskPressure=False라도 root filesystem 사용률이 계속 올라가고 있다면 미리 정리하는 편이 낫다.

2. 디스크 사용량 확인

노드에 직접 접속할 수 있다면 df와 du로 확인한다.

df -h
du -xh /var/lib/containerd 2>/dev/null | sort -h | tail
du -xh /var/log 2>/dev/null | sort -h | tail

직접 SSH가 어렵다면 kubectl debug node로 확인할 수 있다.

kubectl debug node/<node-name> -q --image=busybox:1.36 -- sleep 600

3. 자주 커지는 위치

Kubernetes 노드에서 자주 커지는 위치는 보통 아래다.

/var/lib/containerd
/var/log
/var/log/journal
pod 로그 경로
오래된 이미지와 사용하지 않는 snapshot

containerd를 쓰는 환경에서는 Docker 명령이 아니라 crictl 또는 nerdctl 기준으로 확인해야 한다.

4. journald 로그 정리

journald 로그가 크면 보관 크기를 제한해 정리할 수 있다.

journalctl --disk-usage
journalctl --vacuum-size=1G

운영 환경에서는 일회성 정리만 하지 말고 /etc/systemd/journald.conf에 보관 제한을 두는 것이 좋다.

예시는 아래와 같다.

SystemMaxUse=1G
SystemKeepFree=2G

설정 변경 후에는 journald를 재시작한다.

systemctl restart systemd-journald

5. containerd 이미지 정리

사용하지 않는 이미지는 crictl로 정리할 수 있다.

crictl images
crictl rmi --prune

정리 전에는 현재 실행 중인 pod가 사용하는 이미지를 지우지 않는지 확인해야 한다. --prune은 사용하지 않는 이미지를 대상으로 하지만, 운영 중에는 작업 전후 상태를 반드시 확인하는 것이 좋다.

6. 정리 후 확인

정리 후에는 다시 사용량과 노드 상태를 확인한다.

df -h
kubectl describe node <node-name>

확인할 것은 아래다.

root filesystem 사용률이 내려갔는지
DiskPressure가 False인지
pod 재시작이나 eviction이 새로 발생하지 않았는지
kubelet/containerd 로그에 오류가 없는지

7. 재발 방지

반복되는 문제라면 아래 설정을 같이 봐야 한다.

journald 보관 크기 제한
logrotate 설정
kubelet image GC 설정
containerd snapshot 정리 정책
모니터링에서 root filesystem 사용률 알림

이미 한 번 찬 노드는 시간이 지나면 다시 찰 가능성이 높다. 임계치 알림을 걸고, 어떤 디렉터리가 커지는지 주기적으로 보는 편이 안전하다.

같이 보면 좋은 글

정리

Kubernetes 노드 디스크가 부족할 때는 /var/lib/containerd와 /var/log를 먼저 확인한다. journalctl --vacuum-size, crictl rmi --prune으로 급한 사용량을 줄일 수 있지만, 재발 방지를 위해 journald 제한, logrotate, image GC 설정까지 같이 봐야 한다.

취미생활

Elasticsearch Pod Pending 원인: local PV와 taint 충돌 해결

빠른 결론

먼저 볼 명령

관련 글

시작점: ApplyingChanges와 Pending을 같은 층위로 보면 헷갈린다

처음 확인한 것: 리소스 부족이 아니라 스케줄링 정책 충돌인지

전환점 1: PVC가 local PV에 묶여 있다는 사실

전환점 2: local PV가 붙은 노드에 남아 있던 NoSchedule taint

내가 초반에 오해한 부분: ECK 오류가 먼저라고 본 것

실제 조치: taint 제거와 ECK spec 정상화를 분리해서 처리

왜 StatefulSet replica 조정과 pod 재생성을 했는가

무엇을 보고 해결됐다고 판단했나

이번 일에서 남긴 운영 기준

Sources

Elasticsearch DiskPressure 회고: Pending 복구 뒤에도 끝나지 않았던 로그 보관 문제

시작점: Pending은 풀렸는데 왜 아직 불안했나

확인 순서를 바꾼 이유

전환점 1: 문제는 재배치가 아니라 오래된 backing index 누적이었다

전환점 2: 둘 다 ILM 문제였지만 고장 방식은 달랐다

metricbeat: 정책은 있었지만 실행 권한이 깨져 있었다

minecraft 로그: 참조한 정책 이름은 있었지만 실제 policy는 없었다

왜 노드에서 임시 정리를 먼저 했는가

실제 해결: 보관 정책 재정의, rollover, 그리고 non-write backing index 삭제

무엇을 보고 "진짜 해결됐다"고 판단했나

이번 일에서 남은 교정 포인트

다음에 비슷한 징후를 보면

Sources

authentik OIDC를 Kubernetes에 붙일 때 반드시 알아야 할 핵심

1. 내부 HTTP로도 초기 확인은 가능하다

2. 외부 로그인 요구가 생기면 구조가 달라진다

3. 가장 중요한 검증 지점은 OIDC Discovery다

4. Helm chart에서 hostname 값을 억지로 찾기보다 결과를 확인한다

5. Secret은 values.yaml에 직접 넣지 않고 existingSecret으로 분리했다

6. cert-manager와 Let's Encrypt는 별도로 상태를 확인해야 한다

7. 로그인뿐 아니라 로그아웃 흐름도 같이 봐야 한다

8. 마지막은 groups claim과 role mapping 확인이다

실전 체크리스트

정리

Kubernetes 노드 점검 직후 재부팅: busybox exec format error와 원인 분리

1. 증상

2. 정상 reboot 여부 확인

3. busybox debug 실패

4. ubuntu로 재현

5. 결론

6. 운영 대응

7. 실무 체크리스트

Kubernetes 현황판 Root Disk가 N/A일 때: Metricbeat와 Elasticsearch 연결 문제 해결

핵심 포인트 (먼저 정리)

1. 증상

2. Metricbeat 확인

3. Elasticsearch 확인

4. Root filesystem 확인

5. 핵심 원인

6. env 확인

7. 해결

8. rollout restart

9. 검증

실무 체크리스트

결론

Elasticsearch DiskPressure 원인 분석: ILM 보관 정책으로 해결한 사례

1. 증상

⚠️ 2. 원인 확인 (인덱스 크기)

문제 인덱스

3. 위험한 행동 (하지 말 것)

️ 4. 임시 대응 (디스크 확보)

5. ILM 정책 문제

✅ 6. 해결: ILM 정책 설정

7. Rollover + Index 정리

⚠️ 주의

✅ 8. 결과

실무 체크리스트

결론

Elasticsearch Pod Pending 원인 분석: local PV와 taint 충돌 해결

1. 증상

⚠️ 2. 스케줄링 이벤트

3. PVC / PV 확인

4. 핵심 원인

정리

5. 해결 방법