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..

한 번은 Elasticsearch Pending 문제를 복구한 뒤에도 cluster가 완전히 정상으로 돌아오지 않은 적이 있었다. 표면적으로는 리소스가 다시 올라왔고 custom resource도 Ready로 보였는데, 실제로는 특정 노드에 DiskPressure가 남아 있었고 Elasticsearch health도 yellow에서 멈춰 있었다.이 글은 당시 내가 무엇을 먼저 오해했고, 어디서 판단을 바꿨고, 어떤 검증을 근거로 "이제 정말 끝났다"고 결론 내렸는지를 남기기 위한 기술 회고다. 공개용 문서이므로 노드명, IP, 도메인, 네임스페이스, 계정명, 내부 레지스트리 주소 같은 식별 정보는 모두 일반화했다.시작점: Pending은 풀렸는데 왜 아직 불안했나출발점은 직전 장애의 후속 확인이었다. 이..

Kubernetes 안에 authentik을 올리고, 내부 운영 서비스에 OIDC 로그인을 붙이다 보면 처음에는 내부 HTTP로 빠르게 확인하고 나중에 외부 HTTPS 요구가 생기는 경우가 많다.이번 글은 그 과정에서 어떤 점을 확인했고, 왜 결국 authentik도 외부 HTTPS host 기준으로 정리해야 했는지를 기록한 내용이다.구성 자체는 단순했다.authentik = Identity Providerooo service = OIDC ClientKubernetes Ingress = authentik 외부 진입점cert-manager + Let's Encrypt = TLS 인증서 발급외부 PostgreSQL = authentik DB하지만 실제 운영에서는 아래 세 가지가 핵심이었다.1. authent..

운영 중 특정 노드에서 디스크 점검 직후 재부팅이 발생했다.처음에는 점검 명령이 원인처럼 보였지만, 실제로는 debug image 문제가능성이 있었다.👉 Node 재부팅이 발생했을 때는 "명령 때문인지, 환경 때문인지" 먼저분리하는 것이 중요하다.1. 증상Warning Rebooted 발생NodeReady 재진입동일 노드 pod 재시작2. 정상 reboot 여부 확인정상 reboot라면 systemd-shutdown 로그가 남는다.하지만 이번에는 로그가 끊겨 있었다.👉 정상 reboot 아님 가능성3. busybox debug 실패kubectl debug node/{=html} --image=busybox:1.36결과:exec format error👉 exec format error는 보통 아키텍처..

Kubernetes 운영 현황판에서 CPU와 memory는 정상적으로 나오는데 rootdisk만 N/A로 표시되는 문제가 발생했다.처음에는 Metricbeat가 디스크 정보를 수집하지 못하는 문제처럼 보였지만,실제 원인은 대시보드 API pod에 Elasticsearch 접속 환경변수가 주입되지않은 것이었다.이 글은 Kubernetes API, Metricbeat, Elasticsearch, application runtimeenv를 단계별로 점검하며 원인을 좁힌 과정을 정리한다.🔍 핵심 포인트 (먼저 정리)👉 N/A는 데이터 없음이 아니라 조회 실패일 가능성이 높다👉 CPU / Memory와 Disk는 데이터 경로가 다르다CPU / Memory → metrics-server → Kubernetes..

Elasticsearch Pod Pending 문제를 해결한 이후에도 cluster 상태가yellow로 유지되는 현상이 발생했다.확인 결과 스케줄링 문제가 아니라 로그성 data stream 증가로 인한 디스크압박(DiskPressure) 이 원인이었다.이 글에서는 실제 운영 환경에서 발생한 문제를 기준으로인덱스 용량 확인 → ILM 설정 → 정리 과정까지 정리한다.🔍 1. 증상노드 상태 확인:kubectl describe node {=html}👉 DiskPressure 발생Elasticsearch 상태:kubectl get elasticsearch -n {=html}👉 Ready 상태지만 내부적으로 shard allocation 제한 발생⚠️ 2. 원인 확인 (인덱스 크기)Elasticsearch..