2.3. 클러스터 진단
어떨 때 쓰는가
- 장애 원인을 찾기 어려워 기술 지원에 문의할 때
- 여러 자원의 상태를 한꺼번에 모아 남겨야 할 때
- 이벤트가 사라지기 전에 확보해야 할 때
- 정기 점검 기록을 만들 때
진단이 모으는 것
장애를 조사하려면 여러 화면을 오가야 합니다. 파드 상태, 이벤트, 로그, 노드 자원, 구성요소 버전이 모두 필요한데 각각 다른 곳에 있습니다.
진단 기능은 이것들을 정해진 형식으로 묶어 파일 하나 로 만듭니다.
손으로 모으는 것과 무엇이 다른가
| 손으로 모을 때 | 진단 기능 |
|---|---|
| 무엇을 모아야 할지 그때그때 판단 | 필요한 항목이 정해져 있어 빠뜨리지 않습니다 |
| 여러 명령어를 순서대로 실행 | 버튼 한 번 |
| 모으는 동안 이벤트가 사라질 수 있음 | 한 시점의 상태를 함께 저장합니다 |
| 비밀번호가 그대로 담길 수 있음 | 인증 정보를 자동으로 가립니다 |
이벤트는 한 시간쯤 지나면 사라집니다(2.1 장). 장애 직후에 진단을 돌려 두면 나중에도 그 시점의 이벤트를 볼 수 있습니다.
진단 실행
클러스터 > 클러스터 진단 으로 들어갑니다.
- 수집 범위를 고릅니다. 특정 네임스페이스만 지정하거나 클러스터 전체를 지정합니다.
- 진단 시작 을 누릅니다.
- 진행 상황이 화면에 표시됩니다.
클러스터 규모에 따라 몇 분이 걸립니다. 진단이 도는 동안 다른 화면으로 이동해도 수집은 계속됩니다.
같은 시점에 진단을 두 번 실행할 수 없습니다. 먼저 실행한 진단이 끝난 뒤 다시 시작합니다.
문제가 특정 네임스페이스에 한정된다면 범위를 좁히십시오. 클러스터 전체를 수집하면 파일이 크고 오래 걸립니다.
수집 결과 내려받기
수집이 끝나면 내려받기 버튼이 나타납니다. 압축 파일로 저장됩니다.
파일 구성
내려받은 압축 파일을 풀면 아래 구조가 나옵니다.
| 경로 | 내용 |
|---|---|
version | 제품·콘솔·Kubernetes·노드별 버전과 수집 시각. 사람이 바로 읽는 형식입니다 |
manifest.json | 수집 정보 전체. 실행 번호, 클러스터 이름, 수집 시각, 수집 범위, 로그 대상 네임스페이스, 로그 기간, 버전 정보, 노드별 수집 성공·실패, 가림 처리 적용 여부와 규칙 버전, 수집 중 발생한 경고 |
cluster/ | 자원 목록 — nodes.json, namespaces.json, pods.json, events.json, services.json, deployments.json, daemonsets.json |
logs/<네임스페이스>/<파드>.log | 지정한 범위의 컨테이너 로그 |
nodes/<노드 이름>/ | 노드에서 직접 모은 자료 — 시스템 로그(journal), uname, ip a, df -h, 컨테이너 목록(crictl ps), Kubernetes 버전과 인증서 만료 확인 결과, sysctl, lscpu, free, vmstat, 시각 동기화 상태 |
버전 정보는 압축 파일 안에 이미 들어 있습니다. version 과 manifest.json 에 제품 버전,
콘솔 버전, Kubernetes 버전, 노드별 버전이 함께 기록되므로 기술 지원에 전달할 때는 내려받은
.tar.gz 파일 하나만 보내면 됩니다. 버전을 따로 확인해 적어 보낼 필요가 없습니다.
수집 도중 일부 항목을 가져오지 못해도 수집 자체는 중단되지 않습니다. 가져오지 못한 항목은
manifest.json 의 경고 목록과 노드별 성공·실패 기록에 남으므로, 자료를 받은 쪽에서 무엇이
빠졌는지 알 수 있습니다.
자료를 다룰 때 주의할 것
수집한 자료에는 환경 정보가 들어 있습 니다. 비밀번호와 인증 정보는 자동으로 가려지지만, 외부로 보내기 전에 내용을 확인하십시오.
가려지지 않을 수 있는 것이 있습니다.
- 애플리케이션 로그에 찍힌 값 (개인 정보, 접속 문자열)
- ConfigMap 에 평문으로 넣은 설정
- 환경 변수에 직접 적은 값
민감한 값이 로그에 남지 않게 하는 것이 근본 대책입니다. 감춰야 하는 값은 Secret 으로 관리하십시오(3.4 장).