볼륨과 스테이트풀셋
파드는 일시적이며, 언제나 삭제될 수 있음을 감안해야하며 파드 그 자체는 Stateless 하다. 이러한 파드의 교체와 배치를 담당하는 것이 디플로이먼트이다. 디플로이먼트는 레플리카셋을 통해 파드를 scale out하며, 이 때 만들어지는 파드들은 상호 대체 가능하다.
파드가 사라져도, 데이터를 남기고 싶다면
파드 그 자체에 상태(데이터)를 남겨야만 하는 Stateful 애플리케이션으로는 MySQL, mongoDB, redis와 같은 데이터베이스가 있을 수 있습니다. 데이터베이스 애플리케이션이 담긴 파드가 사라질 때, 데이터가 함께 사라지도록 두어서는 안될 것입니다.
그래서 쿠버네티스에도 영속적인(Persistence) 데이터(프로그램의 실행이 종료되어도 사라지지 않는 데이터)를 저장하기 위해 볼륨(Volume)을 연결할 수 있습니다. 여타 클라우드 서비스에서 볼륨을 따로 분리해 놓는 것과 마찬가지입니다.
Q. 볼륨과 퍼시스턴스 볼륨(Persistence Volume)은 어떤 차이가 있나요? AWS EC2에도 비슷한 개념이 있습니다. EBS와 인스턴스 스토어 볼륨의 차이점과 연결해서 설명해주세요.
A. 인스턴스 스토어 볼륨에 저장된 데이터는 인스턴스 중지, 종료 또는 하드웨어 장애에 대한 영구성을 제공하지 않기 때문에 인스턴스 스토어는 임시 스토리지로 이상적이다.데이터를 장기적으로 유지하거나 암호화하려는 경우에는 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용해야한다. EBS 볼륨은 인스턴스 중지 및 종료 시에도 데이터를 보존해 주고, EBS 스냅샷을 통해 손쉽게 백업할 수 있고, 한 인스턴스에서 데이터를 제거하여 다른 인스턴스에 재연결할 수 있고, 전체 볼륨 암호화를 지원한다.
파드가 삭제되면 쿠버네티스는 볼륨을 삭제하지만, 퍼시스턴트(persistent) 볼륨은 삭제 하지 않습니다.
파드에 볼륨을 연결하면, 데이터를 영속적으로 저장하는 것이 가능하다.
Stateful한 애플리케이션을 관리하려면
그런데, 파드 명세에 PV를 정의해서 직접 연결하는 것은 좋은 방법이 아니다.
Q. 왜 파드와 PV를 직접 연결하는 것이 좋지 않은가요?
A.직접 연결할려면 파드내에 볼륨을 마운트를 해야하고 그러면 쿠버네티스와 인프라스트럭쳐가 강결합이 되기때문에 스토리지 서버의 변화가 파드에 직접적인 영향을 끼치게 된다.
이 때 이러한 의존도를 줄이기 위해, 퍼시스턴스 볼륨 클레임(Persistence Volume Claim, 이하 PVC)을 이용하여 PV와 연결한다.
PVC는 파드가 볼륨의 세부 사항을 몰라도 볼륨을 사용할 수 있게 도와준다.
- PV는 실제로 데이터가 저장되는 공간
- PVC는 PV를 선택, 연결해주는 요청 그 자체
Q. PVC는 어떻게 작동되나요?
A.----------------------------------------------------------------------수정---------------------------------
Stateful한 애플리케이션이 수평 확장한다면
앞서 설명했다시피, 파드를 정의할 때 PVC를 통해 볼륨에 연결할 수가 있다. 그런데, 그냥 이러한 파드를 디플로이먼트로 배포해도, PVC를 통해 연결되는 볼륨은 하나이기 때문에, 결국 같은 스토리지를 사용하는 모양새가 되어버린다.

파드마다 별도의 데이터를 저장할 수 있게 만드려면, 수평확장되는 파드에 서로 다른 PV가 연결되어야 한다. 파드가 PV를 동적으로 요청해서 그때그때 볼륨이 생성되게 하면 어떨까? 스토리지 클래스(StorageClass) 리소스는 사용자가 요청할 때, 자동으로 PV를 프로비저닝 할 수 있게 돕는다.

스테이트풀셋
스테이트풀셋은 애플리케이션 구성(파드)을 복제하더라도, 스토리지 클래스를 이용해 파드가 필요로 하는 볼륨을 자동으로 프로비저닝하여 연결한다. 따라서 첫번째 파드를 primary(master), 두번째 파드를 secondary 복제본처럼 구성하는 것도 가능하다. 디플로이먼트와 스테이트풀셋 둘 다 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다는 점에는 같지만, 가장 결정적인 차이점은 다음과 같다.
바로, 스테이트풀셋은 파드의 순서와 고유성을 보장합니다.
이는 앞서, 가축과 애완동물의 비유를 떠올리면 좋다. 스테이트풀셋이 생성한 파드는 상호 대체할 수 없는 파드다.

스테이트풀셋을 사용할 때의 주의사항
- 파드에 지정된 스토리지는 관리자에 의해 퍼시스턴트 볼륨 프로비저너를 기반으로 하는 storage class 를 요청해서 프로비전하거나 사전에 프로비전이 되어야한다.
- 헤드리스 서비스가 필요하다.
Q. 네트워크 트래픽에 따라 요청이 랜덤하게 분산되는 일반적인 서비스에 비해, 헤드리스 서비스는 특정 스테이트풀셋에게 트래픽을 보냅니다. 왜 그렇게 해야 하나요?
A. 헤드리스 서비스는 클러스터 ip 부분은 none으로 하여 클러스터ip가 없는 서비스이다. 스테이트풀셋에서 데이터베이스와 같이 master, slave 구조가 있는 서비스들의 경우에는 서비스를 통해서 로드밸런서 하는 것을 잘 사용하지않기에 개별 Pod의 주소를 알고 접속해야하며 Pod의 DNS 이름이나 주소를 알아야 한다.헤드리스 서비스에 셀렉터(.spec.selector) 필드를 설정하면 쿠버네티스 API로 확인할 수 있는 엔드포인트(endpoint)가 만들어진다. 서비스와 연결된 파드를 직접 가리키는 DNA A 레코드도 만들어진다.
만약 셀렉터가 없는 경우 엔드포인트가 만들어지지 않으며 셀렉터가 없더라도 DNS 시스템은 ExternalName 타입의 서비스에서 사용할 CNAME 레코드가 만들어집니다.
Pod들은 DNS이름을 가질 수 는 있으나, {pod name}.{service name}.{name space}.svc.cluster.local 식으로 이름을 가지기 때문에, Pod을 DNS를 이용해서 접근하려면 service name이 있어야 한다. 그러나 statefulset에 의한 서비스들은 앞에서 언급하였듯이 쿠버네티스 service를 이용해서 로드밸런싱을 하는 것이 아니기 때문에, 로드밸런서의 역할은 필요가 없고, 논리적으로, Pod들을 묶어줄 수 있는 service만 있으면 되기 때문에 headless 서비스를 활용한다.
쿠버네티스 네트워크
인그레스
인그레스는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 게이트웨이이며 일반적으로 HTTP를 관리하며 로드 밸런서, SSL Termination (클러스터 내에서는 HTTP로만 통신하게 하는 전환 과정), 가상 호스팅을 제공한다.
인그레스의 필요성
애플리케이션을 외부에 노출시키는 방법으로 앞서 서비스를 배웠다. 외부 IP 주소를 할당해주는 서비스와 로드 밸런서를 생성하고 컨테이너로 트래픽을 보내는 방법을 이용한다. 이렇게 파드를 노출시킬 수 있는데, 왜 인그레스를 별도로 사용해야 할까?
바로 인그레스 리소스는 로드 밸런싱과 더불어 호스트 기반 라우팅을 지원하기 때문이다.
앞서 만든 서비스는 LoadBalancer에서 ClusterIP로 바꿨기 때문에 인그레스가 로드 밸런서의 역할을 수행해야 합니다.
아주 단순한 애플리케이션도 서비스는 두 개 이상의 HTTP 요청을 가지는 것이 보통이다. 보통 각각 Web Server와 WAS로 대표됩니다. 이러한 서비스의 접근을 별도의 포트로 구분하여 접속하게 할 수도 있지만, 하나의 호스트 상에서 라우팅으로 구분하면 보다 유연한 서비스를 만들 수 있다.
예를 들어, Web Server는 /로, WAS는 /api로 라우팅 할 수 있습니다.
YAML 파일에서 spec.rules.host 에 별도의 호스트를 지정하여 Web Server는 www.mydomain.click, WAS는 api.mydomain.click으로 설정하는 것도 가능합니다.
그렇다면 인그레스 컨트롤러는 무엇일까? 인그레스 컨트롤러라고 해서 뭔가 특별한 프로그램은 아니다. 우리가 흔히 잘 알고 있는 nginx와 같은 애플리케이션이 바로 인그레스 컨트롤러이다. (nginx가 하는 일이 결국 호스트 기반 라우팅과 로드 밸런싱이라는 점을 기억하세요)
즉, 인그레스 컨트롤러는 규칙을 이행하는 실질적인 애플리케이션 컨테이너이다.
'TIL' 카테고리의 다른 글
| 62일차 서비스 모니터링 (0) | 2022.07.13 |
|---|---|
| 57일차 컨테이너 오케스트레이션 (0) | 2022.07.13 |
| 54~55일차 컨테이너 오케스트레이션 실습 (0) | 2022.07.04 |
| 53일차 컨테이너 오케스트레이션 (0) | 2022.07.01 |
| 52일차 컨테이너 오케스트레이션 (0) | 2022.06.30 |