volumeBindingMode - WaitForFirstConsumer (Pod가 생성된 후 동일한 AZ에 상주하도록 persistent Volume이 프로비저닝되도록 하기 위해 volumeBindingMode는 WaitForFirstConsumer로 구성)
Storage Class를 생성합니다.
생성된 스토리지 클래스를 확인합니다.
출력 결과를 확인합니다.
mysql-gp2가 storageClassName으로 선언되었습니다.
ConfigMap 생성
컨피그맵은 key-vlaue Pair로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트입니다. 파드는 볼륨 내에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있습니다. 이러한 컨피그맵을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있습니다.
1.namespace /configmap 생성
Stateful DB를 생성할 것입니다. 새로운 namespace를 생성합니다.
Configmap을 생성합니다.
configmap은 아래와 같이 구성되어 있습니다.
ConfigMap은 master.cnf, slave.cnf를 저장하고 StatefulSet에 정의된 leader 및 follower pod를 초기화할 때 전달합니다. master.cnf는 데이터 변경 기록을 제공하기 위해 바이너리 로그 옵션(log-bin)이 있는 MySQL leader pod용입니다. 팔로어 서버로 전송됩니다. slave.cnf는 super-read-only 옵션이 있는 follower 포드용입니다.
Service 생성
Kubernetes Service는 Pod의 논리적 집합들과 액세스하는 정책을 정의합니다. serviceSpec에서 유형을 지정하고, 다양한 방식으로 서비스를 노출할 수 있습니다. StatefulSet는 현재 포드의 도메인을 제어하고 안정적인 DNS 항목으로 각 포드에 직접 도달하기 위해 헤드리스 서비스가 필요합니다. clusterIP에 "None"을 지정하면 헤드리스 서비스를 생성할 수 있습니다.
이것은 Amazon Aurora 에서 Endpoint 를 기반으로 Cluster를 구성하는 것과 유사합니다.
아래와 같이 Service를 Apply 합니다.
실제 yaml을 확인해 봅니다. (mysql-services.yaml)
mysql service는 DNS 확인용이므로 StatefulSet 컨트롤러에 의해 포드가 배치될 때 pod-name.mysql을 사용하여 포드를 확인할 수 있습니다. mysql-read는 모든 follower에 대한 로드 밸런싱을 수행하는 클라이언트 서비스입니다.
StatefuleSet 구성
mysql-statefulset.yml을 기반으로 StatefuleSet을 구성합니다.
정상적으로 생성되었는지 확인합니다.
생성 되는데 5분 정도 시간이 소요됩니다.
동적 생성된 PVC를 확인합니다.
아래와 같은 결과를 확인할 수 있습니다.
PVC를 아래 명령을 통해 확인합니다.
아래와 같은 출력 결과를 확인 할 수 있습니다.
EC2 대시보드의 볼륨에서도 동일한 결과를 확인 할 수 있습니다.
SQL Test
1.SQL 테스팅.
다음 명령을 실행하여 mysql-client 를 사용해서 일부 데이터를 mysql-0.mysql 에 보낼 수 있습니다 .
정상적으로 read되는 지 확인해 봅니다.
아래와 같이 출력됩니다.
상호간 분산 테스트를 위해서 아래 명령을 통해 확인 해 봅니다.
2. Container 장애 시험
새로운 Cloud9창에서 아래 명령을 통해 MySQL을 응답하지 않는 상태로 만듭니다.
앞서 상호 분산테스트 하였던 Cloud9창에서 어떤 변화가 일어나는지 확인해 봅니다. 아래 명령을 통해 mysql 상태를 확인해 봅니다.
아래와 같은 출력결과를 확인할 수 있습니다.
다시 정상으로 복귀 시키고, 확인해 봅니다.
아래와 같은 결과를 확인할 수 있습니다.
3.Pod 삭제 시험
실패한 포드를 시뮬레이션하려면 다음 명령을 사용하여 mysql-1 포드를 삭제합니다.
앞서 Cloud9 창에서 다시 100에서만 응답되는 것을 확인할 수 있습니다.
StatefulSet 컨트롤러는 실패한 포드를 인식하고 동일한 이름과 링크를 가진 복제본 수를 유지하기 위해 새 포드를 만듭니다.
4.Scaling 시험
이제 스케일링을 시험해 봅니다. replica를 3개까지 확장합니다.
아래 명령을 통해 확장되는 것을 확인합니다.
다시 앞서 Cloud9 창에서 다시 100,101,102에서 분산해 Read가 일어나는 것을 확인 할 수 있습니다.
새로 배포 된 팔로워 (mysql-2)가 다음 명령으로 동일한 데이터 세트를 가지고 있는지 확인합니다. 동일한 메세지가 출력됩니다.
이제 다시 축소해 봅니다. 하지만 데이터 또는 PVC를 삭제하지는 않습니다. 수동삭제 해야 합니다.
여전히 PVC가 존재하는 지 확인해 봅니다.
기본적으로 PersistentVolumeClaim을 삭제하면 연결된 영구 볼륨이 삭제됩니다. 볼륨을 유지하고 싶다면, "data-mysql-2"라는 PersistentVolumeClaim과 연결된 PersistentVolume의 reclaim 정책을 "Retain"으로 변경합니다.
이제 PersistentVolumeClaim data-mysql-2를 삭제해도 AWS EC2 콘솔에서 상태가 "사용 가능" 상태인 EBS 볼륨을 계속 볼 수 있습니다.
apiVersion: v1
kind: ConfigMap
metadata:
name: mysql-config
namespace: mysql
labels:
app: mysql
data:
master.cnf: |
# Apply this config only on the leader.
[mysqld]
log-bin
slave.cnf: |
# Apply this config only on followers.
[mysqld]
super-read-only
# Headless service for stable DNS entries of StatefulSet members.
apiVersion: v1
kind: Service
metadata:
namespace: mysql
name: mysql
labels:
app: mysql
spec:
ports:
- name: mysql
port: 3306
clusterIP: None
selector:
app: mysql
---
# Client service for connecting to any MySQL instance for reads.
# For writes, you must instead connect to the leader: mysql-0.mysql.
apiVersion: v1
kind: Service
metadata:
namespace: mysql
name: mysql-read
labels:
app: mysql
spec:
ports:
- name: mysql
port: 3306
selector:
app: mysql
EoF