7.4. 클러스터 인증서
어떨 때 보는가
- 정기 점검에서 인증서 만료를 확인할 때
- 클러스터 접속이 갑자기 되지 않을 때
- 클러스터를 설치하고 1년이 가까워질 때
클러스터 인증서란
Kubernetes 구성요소끼리 통신할 때 쓰는 인증서입니다.
클러스터 안에서는 여러 프로그램이 서로를 부릅니다. kubelet 이 API 서버를, API 서버가 etcd 를, 컨트롤러가 API 서버를 부릅니다. 이 통신은 모두 암호화되고 상호 인증 됩니다. 아무 프로그램이나 API 서버에 명령을 내릴 수 없어야 하기 때문입니다.
그 인증에 쓰는 것이 클러스터 인증서입니다.
| 인증서 | 쓰는 곳 |
|---|---|
| API 서버 | 다른 구성요소가 API 서버를 신뢰하는 근거 |
| kubelet | API 서버가 각 노드를 신뢰하는 근거 |
| etcd | 데이터 저장소 접근 인증 |
| 컨트롤러·스케줄러 | API 서버에 접속할 때의 신분 |
이 인증서들은 클러스터를 설치할 때 자동으로 만들어지고, 각 노드의 파일로 보관됩니다.
애플리케이션 인증서와 무엇이 다른가
7.3 장의 cert-manager 인증서와 목적이 다릅니다.
| 클러스터 인증서 | 애플리케이션 인증서 | |
|---|---|---|
| 쓰는 곳 | Kubernetes 구성요소끼리 | 사용자 브라우저와 서비스 사이 |
| 만드는 주체 | 클러스터 설치 도구 | cert-manager |
| 저장 위치 | 노드의 파 일 | 클러스터의 Secret |
| 갱신 | 운영 담당자가 수행 | 자동 |
| 만료되면 | 클러스터가 멈춥니다 | 브라우저 경고가 뜹니다 |
만료 결과가 다릅니다. 애플리케이션 인증서가 만료되면 접속에 경고가 뜨지만 서비스는 돌아갑니다. 클러스터 인증서가 만료되면 구성요소끼리 통신이 끊겨 클러스터가 동작을 멈춥니다.
인증서가 만료되면 무슨 일이 생기는가
한꺼번에 모든 것이 멈추지는 않습니다. 단계적으로 나타납니다.
| 증상 | 뜻 |
|---|---|
| Console 접속이 안 됨 | API 서버 인증서 문제 |
노드가 NotReady 로 바뀜 | kubelet 인증서 문제 |
| 배포가 반영되지 않음 | 컨트롤러가 API 서버에 접속하지 못함 |
| 이미 떠 있는 파드는 계속 동작 | 파드 실행 자체는 인증서와 무관합니다 |
마지막 항목이 중요합니다. 인증서가 만료돼도 이미 도는 애플리케이션은 계속 동작합니다. 새 배포나 재시작이 안 될 뿐입니다.
그래서 알아채기 어렵고, 파드가 종료되는 순간 복구되지 않아 장애가 됩니다. 증상이 없을 때 확인해 두어야 하는 이유 입니다.
콘솔이 인증서 정보를 가져오는 방법
인증서는 클러스터 API 가 아니라 각 노드의 파일 로 보관됩니다. 그래서 Console 이 API 를 불러 읽을 수 없습니다.
COP 는 이를 위해 모든 노드에 인증서 읽기 도구 를 하나씩 띄워 둡니다. Console 은 그 도구에 물어 각 노드의 인증서 정보를 모읍니다.
| 알아 둘 것 | 설명 |
|---|---|
| 노드마다 조회 | 노드 수만큼 요청이 나갑니다. 노드가 많으면 목록이 뜨는 데 시간이 걸립니다 |
| 일부 노드 실패 가능 | 한 노드가 응답하지 않아도 나머지는 표시됩니다 |
| 읽기 전용 | 이 화면은 조회만 합니다. 갱신 기능은 없습니다 |
목록 화면
클러스터 > 인증서 로 들어갑니다.
화면 위쪽에 요약이 나옵니다.
| 요약 항목 | 설명 |
|---|---|
| 인증서 수 | 전체 인증서 개수 |
| 가장 이른 만료 | 클러스터에서 가장 먼저 만료되는 시각 |
| 경고 · 위험 · 만료 | 상태별 개수 |
가장 이른 만료 를 먼저 보십시오. 이 값 하나로 클러스터 전체의 여유를 판단할 수 있습니다.
표에는 인증서별로 다음이 나옵니다.
| 열 | 설명 |
|---|---|
| 노드 | 어느 노드의 인증서인지 |
| 인증서 이름 | 어느 구성요소가 쓰는지 |
| 파일 이름 | 노드에 저장된 파일 |
| 발급일 | 인증서를 만든 날 |
| 만료일 | 유효 기간이 끝나는 날 |
| 남은 기간 | 만료까지 남은 날 수 |
노드 이름과 인증서 유형은 분류 칩으로 표시됩니다. 상태와 구분되도록 차분한 색을 씁니다(1.2 장).
상태 판정 기준
남은 기간에 따라 네 단계로 나뉩니다.
| 상태 | 남은 기간 | 뜻 |
|---|---|---|
| 정상 | 120일 초과 | 조치 불필요 |
| 경고 | 120일 이하 | 갱신 일정을 잡을 때입니다 |
| 위험 | 30일 이하 | 즉시 조치가 필요합니다 |
| 만료 | 0일 이하 | 이미 만료됐습니다 |
경고를 120일로 잡은 것은 갱신 작업에 계획과 승인이 필요하기 때문 입니다. 클러스터를 다시 시작해야 하므로 일정 조율에 시간이 걸립니다.
이 기준은 운영 담당자가 환경에 맞게 바꿀 수 있습니다.
노드별로 확인해야 하는 이유
노드마다 인증서가 따로 있고 만료 시각도 다릅니다.
| 상황 | 왜 다른가 |
|---|---|
| 노드를 나중에 추가했다 | 그 노드의 인증서는 추가한 날부터 유효합니다 |
| 노드를 교체했다 | 교체한 노드만 만료가 늦습니다 |
| 일부 노드만 갱신했다 | 갱신한 노드만 늦어집니다 |
그래서 가장 이른 만료만 보고 안심하면 안 됩니다. 목록 전체를 확인하거나 노드로 정렬해 확인하십시오.
일부 노드를 읽지 못할 때
화면에 "일부 노드 조회 실패" 안내가 나올 수 있습니다. 그 노드의 인증서는 목록에 나오지 않습니다.
| 원인 | 확인할 것 |
|---|---|
노드가 NotReady | 클러스터 > 노드 (2.1 장) |
| 읽기 도구 파드가 안 떠 있음 | 그 노드에 배치된 파드 목록 |
| 노드가 응답하지 않음 | 네트워크 상태 |
읽지 못한 노드가 있으면 그 노드의 인증서는 확인되지 않은 것입니다. 안내 문구에 나온 노드 이름을 운영 담당자에게 전달하십시오.
확인 주기
| 시점 | 하는 일 |
|---|---|
| 매월 정기 점검 | 가장 이른 만료를 확인 |
| 경고(120일 이내) | 갱신 일정을 잡습니다 |
| 위험(30일 이내) | 즉시 조치 |
| 노드를 추가한 뒤 | 새 노드의 인증서 만료 시각 확인 |
| 클러스터 업그레이드 뒤 | 갱신됐는지 확인 |
클러스터 인증서는 보통 1년 유효합니다. 설치하고 1년쯤 지난 시점이 위험하므로 그 전에 달력에 표시해 두십시오.
갱신
인증서 갱신은 노드에 접속해 클러스터를 다시 시작해야 하므로 운영 담당자가 수행합니다. 이 화면은 확인용입니다.
만료가 가까운 인증서를 발견하면 다음을 전달하십시오.
- 인증서 이름
- 해당 노드
- 만료일과 남은 기간
갱신은 노드를 하나씩 차례로 다시 시작 하는 방식으로 진행합니다. 한꺼번에 내리지 않으므로 서비스가 멈추지 않습니다.
갱신 중에 일어나는 일
| 상태 | 설명 |
|---|---|
| 클러스터 API | 관리 노드를 다시 시작하는 동안 잠시 응답하지 않습니다 |
| Console 접속 | 그동안 되지 않습니다 |
| 새 배포·재시작 | 되지 않습니다 |
| 이미 떠 있는 파드 | 계속 동작합니다 |
| 서비스 트래픽 | 영향 없습니다 |
사용자 서비스는 멈추지 않지만 관리 작업은 잠시 막힙니다. 배포 일정과 겹치지 않게 시간을 정하십시오.
갱신이 끝나면 이 화면에서 만료일이 새로 바뀐 것을 확인하십시오. 노드를 하나씩 진행하므로, 작업 중에는 노드마다 만료일이 다르게 보이는 것이 정상입니다.