[Kubernetes Best Practice] 1. 기본 서비스 설치

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다. 모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다. 

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

설정 파일 관리

쿠버네티스에서는 모든 것을 선언적으로 표현합니다. 즉, 클러스터의 상태를 어떻게 변경할지 명령적 접근이 아닌 Desired State를 정의하는 선언전 방법을 사용합니다. 만약 명령적인 방법을 사용하게 된다면 쿠버네티스 클러스터의 상태와 명령들에 대해 사용자가 잘 알고있어야지만 사용할 수 있게 됩니다. 하지만 선언적인 방법을 사용함으로써 사용자는 자세한 내용을 알지 못하더라도 원하는 결과를 얻을 수 있게 됩니다. 

이러한 설정들은 일반적으로 YAML 파일을 통해 관리되어집니다. 최근 많이 사용되고 있는 GitOps의 경우 이러한 설정 파일들이 Git과 같은 버전관리 시스템에 유지하는 방법이고 이를 통해 버전 관리 시스템의 이점인 변경 사항 관리, 롤백 및 히스토리 추적 등과 같은 장점들을 이용하여 쿠버네티스 설정을 관리할 수 있게 되었습니다.

---

이미지 관리

일반적인 컨테이너 이미지를 구축하는 과정은 Supply Chain Attack에 취약합니다. Supply Chain Attack이란 의존 이미지에 악의적인 목적으로 코드나 바이너리를 삽입하여 사용자의 어플리케이션에 대한 보안 공격을 가하는 것을 의미합니다. 따라서 신뢰할 수 있는 이미지 공급자를 통해서 이미지를 구축하거나 의존성이 없는 이미지에서부터 구축하는 방법을 사용하는 것이 좋습니다. 물론 후자의 경우에는 구축 소요 시간 및 난이도가 증가하게 된다는 한계도 존재합니다.

이미지 태그에 관해서는 버전 태그를 변경할 수는 있지만 변경하지 않는 것을 권장합니다. 일반적으로는 이미지가 빌드된 커밋의 SHA 해시값과 버전을 결합하여 네이밍을 하는 방법(ex: v1.0.3-basedq122)을 사용합니다. 또한 태그를 명시하지 않으면 사용되는 latest 태그의 경우 새로운 이미지가 생성될 때마다 이미지 자체가 변경되기 때문에 명시적인 태그를 사용하는 것이 좋습니다.

---

Deployment

상태를 유지하지 않는 Stateless 어플리케이션을 구성할 때 고가용성을 위해 2개 이상의 레플리카를 구축하고 이를 ReplicaSet으로 관리한다. 또한 ReplicaSet의 버전 관리 및 롤아웃을 관리하는 Deployment을 사용하는 방법이 일반적입니다. 

---

ConfigMap을 통한 설정 분리

애플리케이션을 배포할 때, ConfigMap을 통해 설정을 분리하여 배포하게 됩니다. 이를 통해 얻을 수 있는 이점은 사용자의 요구사항이 변경되거나 설정의 변경이 필요할 때 설정이 통합된 어플리케이션보다 빠르게 대응할 수 있다는 점입니다. 

하지만 ConfigMap이 동일한 이름을 가지고 내용만 변경한다고 해서 이를 사용하는 Deployment는 변경되지 않고 Pod을 재시작함으로써 새로운 설정을 적용할 수 있습니다. 이를 해결하기 위한 방법으로는 변경되는 configMap의 버전에 따라 네이밍을 다르게 하고, 이를 Deployment에 적용하는 방법이 있습니다. 위의 방법과는 달리 HeathCheck 기능을 통해 자동으로 롤아웃됨으로 변경을 자동화할 수 있습니다. 

---

Secret 인증 관리

기본적으로 시크릿은 암호화되지 않은 상태로 쿠베네티스 안에 저장됩니다. Hashcorp의 Vault와 같은 Secret Management 프로젝트를 이용하여 시크릿을 보다 용이하게 관리할 수 있습니다. 

일반적으로 시크릿의 경우 배포 시점에 볼륨으로 마운트되어 애플리케이션에 주입되는데 이 때 tmpfs 램 기반의 파일 시스템으로 볼륨이 생성되어 마운트 되고, 이로 인해 물리적인 피해를 입더라도 시크릿이 노출될 위험이 적다고 합니다.

---

StatefulSet

Stateful한 애플리케이션을 배포하는 것은 Stateless한 애플리케이션보다 조금 더 복잡합니다. 기본적으로 쿠버네티스는 Pod은 임시적인 성질을 띄는데 이로인해 상태를 저장하기 어렵다는 특성을 가지고 있습니다. 이를 해결하기 위해 pod이 이동하거나 재시작할 때 데이터를 유지하는 PV를 사용하여 애플리케이션의 상태를 유지할 수 있습니다. StatefulSet은 일관된 pod의 이름과 Scaling에 대한 순서 지정과 같은 방법을 통해 일관성을 보장합니다. 

PV를 할당받기 위해 PVC를 사용하는 방법이 일반적입니다. 사용자는 이러한 스토리지에 대한 명세를 알 필요 없이 추상화 된 리소스에 요청을 보냄으로 PV를 할당받을 수 있습니다.

---

Headless Service

기본적으로 서비스는 해당하는 Pod들에 대해 로드밸런싱을 적용하여 하나의 Pod으로 트래픽을 보내게 됩니다. 하지만 StatefulSet의 경우 특정 Pod에 접근해야 할 필요성이 존재할 수 있고 이런 경우에는 모든 Pod에 대해 개별적인 DNS를 제공하는 Headless Service를 사용합니다. 단, Headless Service를 사용하는 경우 ClusterIP가 할당되지 않습니다. 

---

Helm

환경의 다양성으로 인해 쿠버네티스에 배포해야 할 리소스의 상태를 따로 관리해야하는 필요가 존재합니다. VCS 및 Branch 전략을 통해 이를 달성할 수도 있겠지만 일반적인 해결책은 Template 엔진을 사용합니다. Template 엔진의 대표적인 예는 Helm으로 어플리케이션의 변하는 부분과 변하지 않는 부분에 대해 분리하여 하나의 차트로 나타내는 역할을 합니다. 변하는 부분에 대한 파라미터화를 통해 다양한 환경에 좀 더 손쉽게 배포가 가능합니다.