아주 기본적일 수 있지만, Kubernetes의 잘못된 설정이 큰 장애로 이어질 수도 있습니다.
Health check
Kubernetes Pod와 이를 기반으로 한 리소스에서는 주기적으로 리소스 상태를 확인할 수 있도록 Probe 등의 옵션을 제공합니다.
보통 웹의 경우 이를 위한 API 엔드포인트를 설정해 두는데,
이 주소를 잘못 설정하게 될 경우 오히려 장애 상황으로 이어질 수 있습니다.
- 실제로 재직했던 회사에서 설정 변경 과정에서 이를 잘못 설정하여 문제가 생겼던 적이 있습니다.
다행히도 최초 발견 후 빠르게 담당자가 조치하여 복구할 수 있었습니다.
Label과 Selector
Label이란, Kubernetes의 리소스들을 식별하기 위한 key-value 형태의 정보를 말합니다.
Kubernetes와 파생 프로그램에서 설정해 주는 경우도 있고, 사용자가 직접 설정할 수도 있습니다.
Selector란, 위에서 설정한 Label을 이용해 리소스를 필터링하는 개념입니다.
가장 대표적으로 Service에서 통신할 Pod를 설정하거나, 리소스가 배치될 노드/클러스터를 지정할 때 사용하고, 그 외에도 아주 다양하게 활용할 수 있습니다.
Label과 Selector를 잘못 설정할 경우, 의도치 않은 결과를 가져올 수도 있습니다.
사례 1: Elasticsearch
이전에 내부망에서 Elasticsearch 서비스를 운영할 때, 간헐적인 네트워크 순단이 발생했던 적이 있었습니다.
해당 Elasticsearch는 배포 전 비밀 정보 설정을 위해 1번 작동 후 종료되는 Pod가 있고,
이후에 실제 Pod가 배포되는 방식이었습니다.
문제는 이 ELK Pod와 일회성 Pod의 Label이 동일하게 설정되어 있어 간헐적으로 종료된 Pod에 요청이 가고 있었고, 이를 수정하여 실제로 네트워크 순단을 해결하였습니다.
사례 2: Selector와 IP 방화벽
외부 API를 연동할 때, 보통 보안을 위해 방화벽 설정을 하게 되고 이를 위해 K8s 환경에서는 특정 노드만 방화벽을 개방하게 됩니다.
따라서 외부 API가 필요한 리소스는 방화벽이 개방된 노드에 배치되도록 Selector를 지정해야 합니다.
- 첫 회사에서는 내부 망에서 특정 클러스터 대상으로만 방화벽이 개방된 서비스가 있어 관련 설정이 중요했습니다. K8s 전환 과정에서 이로 인한 이슈도 있었습니다.
- 작성 시점 현 회사에서는 증권사 연동을 위한 방화벽 설정이 필요하고, 변동사항이 있으면 리소스가 배치될 노드 정보 변경도 필요합니다.
- 트래픽이 늘어난 상황에서 새로 생긴 노드에 Pod가 배치되고, 해당 노드에는 방화벽이 개방되어 있지 않아 문제가 생긴 적도 있습니다.
사례 3: Label의 글자 수 제한
Label의 글자 수는 63자를 넘을 수 없습니다.
이전 프로젝트에서 사용자들에게 입력값을 받아 리소스를 생성하고, 이 값을 바탕으로 Label을 설정하는 기능이 있었습니다.
이때 사용자들이 너무 긴 값을 입력하여 일부 리소스에서 Label에 들어갈 값이 63자를 넘게 되고, 이를 Helm chart에 반영할 수 없는 오류가 발생하는 문제가 있었습니다.
당시에는 UI에서 사용자 입력값에 길이 제한을 추가하였고, 문제가 생긴 리소스는 모두 수정하였습니다.