지난번 kubernetes 에서 mongodb replica set 세팅 하는 방법을 정리했다. ( https://blog.1day1.org/598 )

그런데, 이제 mongo db 내부에서 replica set 을 설정한다.

(kube => pod 접속)
$ kubectl exec -ti mongod-0 -c mongod-container bash
   or
$ kubectl exec -ti mongod-0 -- bash

(pod 내에서 mongo console 실행)
# mongo

처음에는 다음처럼 나온다.

rs.status()
{
	"ok" : 0,
	"errmsg" : "no replset config has been received",
	"code" : 94,
	"codeName" : "NotYetInitialized"
}

리플리카 셋을 설정한다.

config = {_id: "MainRepSet", version: 1, members: [
       { _id: 0, host : "mongod-0.mongodb-service:27017" },
       { _id: 1, host : "mongod-1.mongodb-service:27017" },
       { _id: 2, host : "mongod-2.mongodb-service:27017" },
       { _id: 3, host : "mongod-3.mongodb-service:27017" }
 ]}
 rs.initiate(config)

초기 설정 후 관리계정을 만들어 준다.

use admin
db.createUser({user:"admin",pwd:passwordPrompt(),roles:[{role:"root",db:"admin"}]})

(사용은)
db.getSiblingDB('admin').auth("admin", passwordPrompt())

(수정)
db.updateUser("admin", {pwd:passwordPrompt()})

정상 세팅은 다음 처럼 나온다.

이후에 primary 에서 데이터를 등록하면 secondary 에 반영된다.

kubernetes 에서  delete / apply 등으로 새로 세팅하거나 했을때 기존 설정이 정상 동작 하지 않는 경우.
Primary 가 없거나 하는 경우.

Our replica set config is invalid or we are not a member of it

설정을 재등록(?) 해준다. 

conf = rs.conf()
rs.reconfig(conf, {force:true})

[추가] 몇몇 주요 명령

1. replica set 추가

rs.add("mongod-3.mongodb-service:27017")

2. sync 상태 보기

PRIMARY> rs.printSlaveReplicationInfo()

source: mongod-1.mongodb-service:27017
	syncedTo: Fri Feb 28 2020 02:56:26 GMT+0000 (UTC)
	0 secs (0 hrs) behind the primary 
source: mongod-2.mongodb-service:27017
	syncedTo: Fri Feb 28 2020 02:56:26 GMT+0000 (UTC)
	0 secs (0 hrs) behind the primary 
source: mongod-3.mongodb-service:27017
	syncedTo: Fri Feb 28 2020 02:56:26 GMT+0000 (UTC)
	0 secs (0 hrs) behind the primary 

3. 특정노드 에러메시지 (해결책 - 찾는 중)

PRIMARY> rs.status()
..
"stateStr" : "(not reachable/healthy)",
..
"lastHeartbeatMessage" : "Our replica set configuration is invalid or does not include us",
..

PRIMARY> rs.printSlaveReplicationInfo()
...
...
source: mongod-0.mongodb-service:27017
	syncedTo: Thu Jan 01 1970 00:00:00 GMT+0000 (UTC)
	1584736418 secs (440204.56 hrs) behind the primary 

원인이 뭘까? 특별히 비정상 종료 같은 것은 없던 것 같은데. config 서버를 따로 두지 않는 문제일까?

  해결책 1) 해당 pvc / pod 를 삭제한다 => 쿠버네티스 가 알아서 재가동 하면서 정상 처리 된다. (옳은 방법인지는 의문)

kubectl delete pvc mongodb-persistent-storage-claim-mongod-0
kubectl delete pod/mongod-0

몽고디비를 서비스에 도입해보려고 테스트 중이다.

여러가지 설치 방법이 있지만, 쿠버네티스 를 활용해서 하려한다.

1. microk8s 를 설치한다.
https://microk8s.io/docs/ 설치방법은 너무 쉽다.
몇몇 서비스를 활성화 시킨다.

microk8s.enable dns storage ingress registry

microk8s.kubectl 은 링크걸어두면 편하다.

sudo ln -s microk8s.kubectl /snap/bin/kubectl

or

sudo snap alias microk8s.kubectl kubectl

2. 몽고디비 replica set 설정을 사용한다.
https://maruftuhin.com/blog/mongodb-replica-set-on-kubernetes/ 의 설정을 참조

$ openssl rand -base64 741 > ./replica-set-key.txt
$ kubectl create secret generic shared-bootstrap-data \
  --from-file=internal-auth-mongodb-keyfile=./replica-set-key.txt

3. 설정을 사용해 몽고디비를 가동한다.

kubectl apply -f replica-sets/mongodb-rc.yaml

다음과 같은 명령으로 상황을 모니터링 하면 좋다.

kubectl get all -o wide
kubectl get pvc -o wide
kubectl get nodes -o wide

정상적으로 실행되지 않고, pending 으로 시간이 걸린다면, 삭제했다가 다시 실행해본다.

(전체 삭제)
kubectl delete -f replica-sets/mongodb-rc.yaml

(pvc 삭제)
kubectl delete pvc mongodb-persistent-storage-claim-mongod-0

정상적이라면 다음처럼 나온다.

kubectl get pods -o wide

NAME       READY   STATUS    RESTARTS   AGE     IP            NODE            
mongod-0   1/1     Running   0          6m45s   10.1.32.109   192.168.77.20   
mongod-1   1/1     Running   0          6m43s   10.1.70.10    kube-mk8s       
mongod-2   1/1     Running   0          6m42s   10.1.32.110   192.168.77.20   
mongod-3   1/1     Running   0          6m41s   10.1.70.11    kube-mk8s       

4. mongo 접속하여 replica set 설정한다. (세부 설정은 별도로 정리 예정)

(kube => pod 접속)
kubectl exec -ti mongod-0 -c mongod-container bash

(pod 내에서 mongo console 실행)
mongo

해당 replica set 의 몽고 서버에 접속하기 위해 dns 설정이 잘 되었는지 확인해본다.

kubectl apply -f https://k8s.io/examples/admin/dns/busybox.yaml
kubectl exec -ti busybox -- nslookup mongod-0.mongodb-service

설정을 확인해서 정상적으로 pod IP 가 나와야 한다.

이런식으로 나오면 실패.

Server:    127.0.0.53
Address 1: 127.0.0.53

nslookup: can't resolve 'mongod-0.mongodb-service'

아래처럼 나와야 정상.

Server:    10.152.183.10
Address 1: 10.152.183.10 kube-dns.kube-system.svc.cluster.local

Name:      mongod-0.mongodb-service
Address 1: 10.1.32.109 mongod-0.mongodb-service.default.svc.cluster.local

[추가]

혹시 microk8s 설치시 다음과 같은 메시지나 나오고 진행이 안된다면.

error: too early for operation, device not yet seeded or device model not acknowledged

snapd 를 삭제했다가 다시 설치해본다.

sudo apt purge snapd
sudo apt install snapd

쿠버네티스 를 사용하기 위해 알아보고 있다. (이미 대세가 된지 오래)

단순 개발환경에 적용하기 보다. 실무에 적용하기 위해 연습/학습 단계 부터 단계적으로 해본다.

현재로서는 다음 단계로 진행예정.

1. microk8s (우분투 기반) - 로컬
2. kubeadm , kubespray 등을 이용한 세팅 - (클라우드 or 실서버)
3. helm 등의 패키지(?) 개념의 설치/세팅

아직 용어도 익숙치 않아서 시간이 걸리겠지만, 하나씩 해보면서 목표를 이뤄나간다.

장비도 노트북(그램) , 서버(PC) , 클라우드(D.O , GCP) 등 여러환경에서 해본다.

LG 그램을 사용중이다. 윈도우가 기본 설치가 되어 있지만, 개발에 필요해서 우분투를 설치해서 사용하려 한다.

USB 부팅(설치) 디스크를 만들고 부팅을 시도 했는데. 다음과 같은 에러가 나면서 부팅이 되지 않는다.

Failed to open \EFI\BOOT\NULL - Not Found
Faild to load image \EFI\BOOT\NULL : Not Found
start_image() returned Not Found

위와 같은 에러가 나는 경우. USB 설치 디스크의 해당 위치를 보면

grubx64.efi
mmx64.efi
bootx64.efi

등의 파일이 있는데.

난 grubx64.efi 를 복사해서 NULL 파일로 이름을 바꿔줬다. (NULL.efi 가 아닌 그냥 NULL )

다시 재부팅을 해보니 정상적으로 부팅화면으로 넘어갔다.

ps. 여러가지 그램 바이오스 세팅을 바꾸는 방법이 구글링 하면 나오는데.
난 위 방법으로 했다. (secure boot : disable 등 몇가지는 설정했다.)

예전 부터 가상서버를 써왔다. 국내/해외. 본격적으로 써온지도 5년이 넘었다.
(특히 해외업체들의 서비스가 괜찮아 많이 쓰고 있다. https://blog.1day1.org/564 에 소개를 하기도 했다)

국내업체들은 아직 불편한 부분이 많다.
그 사이 AWS 도 국내 서비스도 하고 있다.

이미 AWS 쪽은 대세가 된 kubernetes , 위 업체중 디지털오션 만 공식(?) 지원하고 있다. 서비스로서 지원.

벌쳐 / 리노드는 아직 공식 지원하지는 않는다. 별개로 kubernetes 설치해서 사용할 수는 있다.

디지털오션은 서비스로 지원해서, 쿠버네티스 클러스터를 구성하기 쉽도록 했다.(마스터는 별도 비용을 받지 않는 듯 하다)
노드 비용만 계산이 되는 듯 하다.(10$ 플랜부터 사용가능)

런칭한지는 좀 되었지만, 아직 실 사용은 해보지 않아 언급하진 않았다.
조만간 서비스를 쿠버네티스 기반으로 옮길것을 검토중이라 정리 차원에서 글을 쓴다.

도입하면서 나오는 이슈들을 정리할 생각이다.