728x90
반응형
쿠버네티스를 운영하다 보면 이런 순간이 옵니다.
“Pod 상태 한눈에 보고 싶은데 kubectl 치기 귀찮다…”
“장애 났을 때 전체 구조를 빠르게 파악하고 싶다…”
이럴 때 등장하는 게 바로 Headlamp입니다.
Headlamp 한 줄 정의
Headlamp = Kubernetes 클러스터를 웹 화면(GUI)으로 관제·운영할 수 있는 오픈소스 대시보드
쉽게 말하면,
kubectl + 리소스 뷰어 + 로그 + YAML 편집기를
👉 브라우저 하나에 모아둔 운영 콘솔
입니다.
왜 Headlamp를 쓰는 걸까?
기존 Kubernetes Dashboard도 있었지만, 실운영 환경에서는 다음 같은 불편이 많았죠.
- 토큰 기반 로그인
- UI가 직관적이지 않음
- 로그/YAML 접근이 번거로움
Headlamp는 이런 부분을 깔끔하게 개선했습니다.
Headlamp 핵심 기능 정리
✅ 클러스터 전체 가시성
- Node Ready / NotReady 상태
- Namespace 별 리소스 구조
- Pod / Deployment / Service / Ingress 한 화면 관리
✅ 실시간 장애 파악
- CrashLoopBackOff
- Pending Pod
- ImagePullError
같은 상태를 리스트 + 색상으로 바로 확인할 수 있어요.
✅ 로그 & YAML 즉시 접근
- Pod 클릭 → 로그 바로 확인
- 리소스 YAML 브라우저에서 열기
- 필요하면 바로 수정 가능
운영 중 트러블슈팅 속도가 확 줄어듭니다.
✅ RBAC 자연 연동
- kubeconfig 기반 로그인
- 현재 계정 권한 그대로 반영
따로 토큰 복사할 필요가 없어서 운영 환경에 훨씬 안전합니다.
Kubernetes Dashboard vs Headlamp 차이
구분Headlamp기존 Dashboard
| UI | 현대적 | 다소 구식 |
| 설치 | 간단 | 은근 복잡 |
| 인증 | kubeconfig | 토큰 |
| 로그 확인 | 매우 쉬움 | 번거로움 |
| 확장성 | 플러그인 가능 | 거의 없음 |
| 운영 적합성 | 높음 | 낮음 |
그래서 요즘은:
👉 운영 = Headlamp + kubectl
👉 배포 흐름 = ArgoCD
이 조합이 많이 쓰입니다.
실무에서의 대표적인 사용 패턴
프랭크처럼 Amazon Web Services 기반 EKS를 운영한다고 가정하면 보통 이렇게 활용합니다.
장애 발생 시
- Headlamp 접속
- Pod 상태 전체 스캔
- Node 이상 여부 확인
배포 직후
- Deployment rollout 상태 체크
- Replica 정상 증가 여부 확인
개발자 문의 대응
- YAML 열어서 구조 설명
- Event 로그 공유
즉,
- kubectl → 깊은 작업용
- Headlamp → 상황 파악 + 1차 트러블슈팅용
입니다.
언제 쓰면 특히 효과적일까?
- 네임스페이스가 많은 환경
- 신규 인력이 투입된 조직
- 야간 장애 대응
- kubectl 익숙하지 않은 인원과 협업할 때
정리
K8s에서 말하는 Headlamp는 단순한 “웹 화면”이 아닙니다.
👉 운영 속도와 가시성을 끌어올려주는 Kubernetes 관제 레이어
kubectl을 완전히 대체하지는 않지만,
초기 장애 대응과 구조 파악 속도는 확실히 빨라집니다.
728x90
반응형