4주차 - Percona Distribution for MongoDB 오퍼레이터

 

1. MongoDB 개요

  - 대표적인 NoSQL 데이터 베이스

  - document 지향 DB로 key:value값으로 저장이 가능하며, 손쉬운 확장이 가능함.

  - Percona 오퍼레이터를 통해서 MongoDB 클러스터를 관리할 수 있다.

 

2. Percona 오퍼레이터 설치 (공식문서)

2.1 percona-server-mongodb-operator 파일을 가져옵니다.

git clone -b v1.12.0 https://github.com/percona/percona-server-mongodb-operator
cd percona-server-mongodb-operator

2.2 먼저 crd를 배포합니다.

kubectl apply --server-side -f deploy/crd.yaml

 

2.3 namespace를 만들어 환경을 분리합니다. (이후부터 반드시 해당 네임스페이스에서 작업을 해야합니다)

kubectl create namespace <namespace name>

 

2.4 RBAC (Role-Base Access Control, 역할 기반 액세스 제어)를 구성합니다.

kubectl apply -f deploy/rbac.yaml

 

2.5 operator를 설치합니다.

$ kubectl apply -f deploy/operator.yaml

 

2.6 MongoDB 사용자에 대해서 계정정보를 보안 저장하기 위해 쿠버네티스 secret을 생성해 저장합니다.

kubectl create -f deploy/secrets.yaml

# secret yaml은 아래와 같습니다.

apiVersion: v1                                                   
kind: Secret                                                     
metadata:                                                        
  name: my-cluster-name-secrets                                  
type: Opaque                                                     
stringData:                                                      
  MONGODB_BACKUP_USER: backup                                    
  MONGODB_BACKUP_PASSWORD: backup123456                           
  MONGODB_CLUSTER_ADMIN_USER: clusterAdmin                        
  MONGODB_CLUSTER_ADMIN_PASSWORD: clusterAdmin123456              
  MONGODB_CLUSTER_MONITOR_USER: clusterMonitor                    
  MONGODB_CLUSTER_MONITOR_PASSWORD: clusterMonitor123456          
  MONGODB_USER_ADMIN_USER: userAdmin                             
  MONGODB_USER_ADMIN_PASSWORD: userAdmin123456                   
  PMM_SERVER_USER: admin                                         
  PMM_SERVER_PASSWORD: admin
  
  
  
  # secret 내용을 살펴보면 위의 내용이 암호화됨을 확인
$ kubectl get secret $MYNICK-secrets -o json | jq

  {
  "apiVersion": "v1",
  "data": {
    "MONGODB_BACKUP_PASSWORD": "YmFja3VwMTIzNDU2",
    "MONGODB_BACKUP_USER": "YmFja3Vw",
    "MONGODB_CLUSTER_ADMIN_PASSWORD": "Y2x1c3RlckFkbWluMTIzNDU2",
    "MONGODB_CLUSTER_ADMIN_USER": "Y2x1c3RlckFkbWlu",
    "MONGODB_CLUSTER_MONITOR_PASSWORD": "Y2x1c3Rlck1vbml0b3IxMjM0NTY=",
    "MONGODB_CLUSTER_MONITOR_USER": "Y2x1c3Rlck1vbml0b3I=",
    "MONGODB_USER_ADMIN_PASSWORD": "dXNlckFkbWluMTIzNDU2",
    "MONGODB_USER_ADMIN_USER": "dXNlckFkbWlu",
    "PMM_SERVER_PASSWORD": "YWRtaW4=",
    "PMM_SERVER_USER": "YWRtaW4="
  }, (...)

 

2.7 클러스터 생성을 위해 이제 MongoDB를 포함한 pod를 3개 생성하겠습니다.

kubectl apply -f deploy/cr.yaml

 

3. ReplicaSet 정보 확인

# mongoDB 접속
kubectl exec -it myclient1 -- mongo --quiet "mongodb+srv://clusterAdmin:clusterAdmin123456@$MYNICK-db-rs0.psmdb.svc.cluster.local/admin?replicaSet=rs0&ssl=false"


# 복제셋 정보 확인
rs0:PRIMARY> db.isMaster()

"_id" : 0,                                                                                                                                                                             
"name" : "janghun-db-rs0-0.janghun-db-rs0.psmdb.svc.cluster.local:27017",                                                                                                               
"health" : 1,                                                                                                                                                                           
"state" : 1,                                                                                                                                                                            
"stateStr" : "PRIMARY",

    (...)
    
"_id" : 1,                                                                                                                                                                              
"name" : "janghun-db-rs0-1.janghun-db-rs0.psmdb.svc.cluster.local:27017",                                                                                                               
"health" : 1,                                                                                                                                                                           
"state" : 2,                                                                                                                                                                            
"stateStr" : "SECONDARY",

    (...)
    
"_id" : 2,                                                                                                                                                                              
"name" : "janghun-db-rs0-2.janghun-db-rs0.psmdb.svc.cluster.local:27017",                                                                                                               
"health" : 1,                                                                                                                                                                           
"state" : 2,                                                                                                                                                                            
"stateStr" : "SECONDARY",



# 복제 셋의 세컨더리가 복제를 언제까지 동기화했는지 확인
rs0:PRIMARY> rs.printSecondaryReplicationInfo()           

source: janghun-db-rs0-1.janghun-db-rs0.psmdb.svc.cluster.local:27017                                                                                                                                   
        syncedTo: Sat Jun 25 2022 08:42:25 GMT+0000 (UTC)                                                                                                                                               
        0 secs (0 hrs) behind the primary                                                                                                                                                               
source: janghun-db-rs0-2.janghun-db-rs0.psmdb.svc.cluster.local:27017                                                                                                                                   
        syncedTo: Sat Jun 25 2022 08:42:25 GMT+0000 (UTC)                                                                                                                                               
        0 secs (0 hrs) behind the primary

 

 

3. 장애 상황 실습

3.1. 프라이머리 파드 삭제

 

아래 명령어를 통해서 현재 Primary 상태를 알 수 있다.

 

$ rs0:PRIMARY>db.isMaster()

Primary라고 적힌 곳을 보면 janghun-db-rs0-0이라고 되어있다.

자 이제 실수로 Primary rs0-0을 날려보자.

$ kubectl delete pod $MYNICK-db-rs0-0

 

Primary가 janghun-db-rs0-1로 변경된 것을 알 수 있다.

실제로 다시 명령어를 통해서 rs0-0으로 접근하면, SECONDARY라고 변경된 것을 확인할 수 있다.

kubectl exec -it myclient1 -- mongo --quiet "mongodb://doik:qwe123@$MYNICK-db-rs0-0.$MYNICK-db-rs0.psmdb.svc/admin?ssl=false"

 

3.2 강제로 프라이머리 노드 drain

현재 실습 중에는 Primary인 janghun-db-rs0-1이 속한 노드는 k8s-w1 노드이다.

k8s-w1 노드를 drain 시키도록 하겠다.

 

kubectl drain k8s-w1 --delete-emptydir-data --force --ignore-daemonsets

k8s-w1에 할당된 janghun-db-rs0-1은 현재 pending 상태로 유지되고 있다. 다시 db.isMaster를 조회해보면

Primary가 다시 janghun-db-rs0-0으로 변경된 것을 확인 할 수 있다.

 

 

3.3 노드 2개가 전부 drain 된 상태라면 어떻게 될까

 

오로지 1개의 replicaset만 살아있기 때문에, janghun-db-rs0-2는 별도로 승격되지 않는다.

이제 모두 uncordon을 통해서 drain 상태를 해제하고, replicaset에 Primary가 등장하는지 확인하자.

kubectl uncordon k8s-w1 ; kubectl uncordon k8s-w2 ; kubectl uncordon k8s-w3

janghun-db-rs0-1이 primary가 정상적으로 됨을 확인했다.

 

 

 

이상으로 MongoDB 오퍼레이터인 Percona 오퍼레이터 실습을 마치도록 하겠습니다.