티스토리 뷰
[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 1: Bootstrap Node 구성
ccambo 2020. 12. 23. 20:20How to building real world sample step by step - Part 1
게시글 참고
이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다.
이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 Galera 클러스터 구성을 위한 Bootstap Node 설정을 다룬다.
참고
- 이 문서는 KUDO에 대한 이해를 어느 정도 하고 있다는 것을 전제로 하며 MariaDB의 오픈 소스 클러스터링 솔루션인 Galera를 위한 Operator를 KUDO를 이용해서 만드는 과정을 정리한 것이다.
- 이 문서는 KUDO v0.17.0 기준으로 작성되었다.
KUDO에 관련된 정보는 이전 글들 참고
환경 설정
파일 시스템 레이아웃 구성
우선 작업할 내용은 개발 및 테스트 환경을 구성하는 것이다. 이전 글들에서 언급했던 것과 같이 아래와 같은 구성이 필요하다. (KUDO-CLI 명령을 통해서 구조 및 기본 파일들을 생성할 수 있다.)
작업할 대상은
~/kudo_sample/galera-operator
폴더를 기준으로 한다.. └── operator ├── operator.yaml ├── params.yaml └── templates 2 directories, 2 files
생성된 operator.yaml 파일은 아래와 같이 구성한다.
apiVersion: kudo.dev/v1beta1 appVersion: 0.1.0 kubernetesVersion: 0.16.0 kudoVersion: 0.17.2 maintainers: - email: ccambo@gmail.com name: ccambo name: galera-operator operatorVersion: 0.1.0 plans: {} tasks: []
생성된 params.yaml 파일은 아래와 같이 구성한다.
apiVersion: kudo.dev/v1beta1 parameters: []
그리고 자동으로 생성되지 않는
templates
디렉터리도 생성해 놓는다.배포 계획 생성
가장 먼저 작업할 내용은 모든 Operator가 반드시 가지고 있어야 할 배포 계획을 구성하는 것이다. (operator.yaml)
... plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: ...
위와 같이 기본 배포 계획 구성을 추가한다.
Bootstrap Config 설정
Galera 클러스터를 배포할 때 Bootstrap을 위해 수행할 단계가 존재하기 때문에 부트스트랩 노드를 구성해야 한다. 이 부트스트랩 노드는 클러스터의 다른 노드와 구성이 다르므로 이를 배포하기 위해서 구성해야 한다.
ConfigMap 리소스를 이용해서 부트스트랩 컨테이너에 전달해야 한다. 따라서 배포 계획에 Phases와 Steps를 추가해서 이를 처리하기 위한 구성을 아래와 같이 처리한다. (operator.yaml)
...
plans:
deploy:
strategy: serial
phases:
- name: deploy
strategy: serial
steps:
- name: bootstrap_config
tasks:
- bootstrap_config
tasks:
- name: bootstrap_config
kind: Apply
spec:
resources:
- bootstrap_config.yaml
...
지금까지의 작업으로 완성한 ~/kudo_sample/galera-operator/operator/operator.yaml
파일의 내용은 다음과 같다.
apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
name: ccambo
name: galera-operator
operatorVersion: 0.1.0
plans:
deploy:
strategy: serial
phases:
- name: deploy
strategy: serial
steps:
- name: bootstrap_config
tasks:
- bootstrap_config
tasks:
- name: bootstrap_config
kind: Apply
spec:
resources:
- bootstrap_config.yaml
위에서 추가한 Step/Task 의 내용은 부트스트랩 노드를 위한 ConfigMap 리소스를 사용하겠다는 의미로 templates/bootstrap_config.yaml
파일을 생성하고 아래와 같이 구성한다. (bootstrap_config.yaml)
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Name }}-bootstrap
namespace: {{ .Namespace }}
data:
galera.cnf: |
[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = mariabackup
wsrep_cluster_address = gcomm://
wsrep_sst_auth = "{{ .Params.SST_USER }}:{{ .Params.SST_PASSWORD }}"
binlog_format = ROW
위의 설정 내용은 ConfigMap 리소스로 단일 데이터로 galera.cnf 파일의 내용으로 Galera 설정 내용이다.
wsrep_cluster_address = gcomm://
: 이 설정을 통해서 이 노드가 부트스트랩 노드가 될 것을 지정한 것이다.name: {{ .Name }}-bootstrap
: 각 KUDO Instance에 유일한 값을 지정하는 것으로 ConfigMap도 유일한 이름으로 지정하기 위한 것이다.namespace: {{ .Namespace }}
: 네임스페이스에 속한 리소스로 한정되도록 하는 것이다.wsrep_sst_auth = "{{ .Params.SST_USER }}:{{ .Params.SST_PASSWORD }}"
: 노드 간의 동기화를 위해 Galera 클러스터 내부적으로 사용할 자격 증명을 지정한 것이다.
이제 ConfigMap에서 사용하도록 지정한 파라미터들 (.Params
로 시작하는)을 정의하기 위해 params.yaml
을 아래와 같이 구성한다.
apiVersion: kudo.dev/v1beta1
parameters:
- name: SST_USER
description: "User to perform SST as"
default: "root"
- name: SST_PASSWORD
description: "Password for SST user"
default: "admin"
위의 내용은 SST_USER, SST_PASSWORD 파라미터를 정의하고 기본 값을 설정한 것이다.
주의
일반적으로
Secret
리소스에 민감한 정보를 구성하는 것을 권장한다. 위와 같이 파라미터로 설정하는 방식은 암호화되지 않고 클러스터에 저장되기 때문에 쉽게 노출될 수 있다.
지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.
KUDO 설치 (using init)
가장 먼저 작업할 내용은 KUDO Operator 설치로 아래와 같이 수행한다.
$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait # Webhook TLS를 자체 서명한 버전으로 처리 $KUDO_HOME has been configured at /home/centos/.kudo Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition ✅ installed crds ✅ installed namespace ✅ installed service account Warning: admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 MutatingWebhookConfiguration ✅ installed webhook ✅ installed kudo controller ⌛Waiting for KUDO controller to be ready in your cluster... ✅ KUDO is ready!
Galera Operator 설치 (using install)
설치된 KUDO Operator에 작성한 Galera Operator를 설치한다. (KUDO는 Respository를 지원하지만 이번에는 로컬 디렉터리 (~/kudo_sample/galera-operator/operator)를 기준으로 설치한다.)
$ kubectl kudo install ./ Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition operator default/galera-operator created operatorversion default/galera-operator-0.1.0-0.1.0 created instance default/galera-operator-instance created
설치할 때 Instance 이름을 별도로 지정하지 않았기 때문에 패키지 이름을 그대로 사용한다. (galera-operator => galera-operator-instance가 된다)
설치된 Operator Instance 확인
설치된 Instance 정보는 아래와 같이 확인할 수 있다.
$ kubectl kudo plan status --instance=galera-operator-instance Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition Plan(s) for "galera-operator-instance" in namespace "default": . └── galera-operator-instance (Operator-Version: "galera-operator-0.1.0-0.1.0" Active-Plan: "deploy") └── Plan deploy (serial strategy) [COMPLETE], last updated 2020-12-23 06:17:06 └── Phase deploy (serial strategy) [COMPLETE] └── Step bootstrap_config [COMPLETE]
설치된 ConfigMap 확인
deploy plan의 bootstrap_config step으로 생성된 ConfigMap은 아래와 같이 확인할 수 있다.
$ kubectl get configmaps NAME DATA AGE galera-operator-instance-bootstrap 1 21m
생성된 ConfigMap의 내용은 아래와 같이 확인할 수 있다.
$ kubectl describe configmap galera-operator-instance-bootstrap Name: galera-operator-instance-bootstrap Namespace: default Labels: heritage=kudo kudo.dev/instance=galera-operator-instance kudo.dev/operator=galera-operator Annotations: kudo.dev/last-applied-configuration: {"kind":"ConfigMap","apiVersion":"v1","metadata":{"name":"galera-operator-instance-bootstrap","namespace":"default","creationTimestamp":nu... kudo.dev/last-plan-execution-uid: 3bb3d148-b420-47d5-83d9-baef16c4095c kudo.dev/phase: deploy kudo.dev/plan: deploy kudo.dev/step: bootstrap_config Data ==== galera.cnf: ---- [galera] wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_sst_method = mariabackup wsrep_cluster_address = gcomm:// wsrep_sst_auth = "root:admin" binlog_format = ROW Events: <none>
KUDO 및 Operator 삭제
지금까지 작업한 내용이 적용된 것을 확인했으므로 다음 작업을 위해서 KUDO Operator를 포함한 설치된 모든 리소스들을 삭제하도록 한다.
$ kubectl kudo init --unsafe-self-signed-webhook-ca --upgrade --dry-run --output yaml | kubectl delete -f - Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition customresourcedefinition.apiextensions.k8s.io "operators.kudo.dev" deleted customresourcedefinition.apiextensions.k8s.io "operatorversions.kudo.dev" deleted customresourcedefinition.apiextensions.k8s.io "instances.kudo.dev" deleted namespace "kudo-system" deleted serviceaccount "kudo-manager" deleted clusterrolebinding.rbac.authorization.k8s.io "kudo-manager-rolebinding" deleted Warning: admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 MutatingWebhookConfiguration mutatingwebhookconfiguration.admissionregistration.k8s.io "kudo-manager-instance-admission-webhook-config" deleted secret "kudo-webhook-server-secret" deleted service "kudo-controller-manager-service" deleted statefulset.apps "kudo-controller-manager" deleted
Bootstrap 서비스 구성
다음 작업은 부트스트랩 서비스를 정의하는 것으로, 클러스터 노드가 배포되면 부트스트랩 노드에 연결하기 때문에 이를 위한 서비스를 정의하는 과정이다.
- operator.yaml 파일에
bootstrap_service step
추가 - operator.yaml 파일에
bootstrap_service task
추가 - task에서 사용할
bootstrap_service.yaml
설정
위의 같은 작업을 처리한 operator.yaml은 다음과 같다.
apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
name: ccambo
name: galera-operator
operatorVersion: 0.1.0
plans:
deploy:
strategy: serial
phases:
- name: deploy
strategy: serial
steps:
- name: bootstrap_config
tasks:
- bootstrap_config
- name: bootstrap_service
tasks:
- bootstrap_service
tasks:
- name: bootstrap_config
kind: Apply
spec:
resources:
- bootstrap_config.yaml
- name: bootstrap_service
kind: Apply
spec:
resources:
- bootstrap_service.yaml
이제 Task에 리소스로 정의한 부트스트랩 서비스 리소스 파일을 templates/bootstrap_service.yaml
파일에 아래와 같이 구성한다.
apiVersion: v1
kind: Service
metadata:
name: {{ .Name }}-bootstrap-svc
namespace: {{ .Namespace }}
labels:
app: galera-bootstrap
spec:
ports:
- port: {{ .Params.MYSQL_PORT }}
name: mysql
- port: {{ .Params.SST_PORT }}
name: sst
- port: {{ .Params.REPLICATION_PORT }}
name: replication
- port: {{ .Params.IST_PORT }}
name: ist
selector:
app: galera-bootstrap
instance: {{ .Name }}
clusterIP: None
name: {{ .Name }}-bootstrap-svc
: 서비스의 이름도 고유한 값으로 설정app: galera-bootstrap
: 이 서비스를 사용하는 모든 인스턴스들을 관리하는데 사용할 레이블 설정port: {{ .Params.MYSQL_PORT }}
: mySQL 사용 포트를 파라미터와 연동하도록 설정port: {{ .Params.SST_PORT }}
: SST 연계용 포트를 파라미터와 연동하도록 설정port: {{ .Params.REPLICATION_PORT }}
: Replication용 포트를 파라미터와 연동하도록 설정port: {{ .Params.IST_PORT }}
: IST용 포트를 파라미터와 연동하도록 설정instance: {{ .Name }}
: 부트스트랩 인스턴스 Selector 설정
이 특별한 서비스는 하나의 인스턴스만 사용하기 때문에 클러스터 IP는 필요하지 않고, 서비스는 Headless일 수 있으며 Kubernetes는 관련된 DNS Endpoint를 생성하게 된다.
서비스를 정의하면서 추가로 사용한 파라미터들을 params.yaml
파일에 아래와 같이 정의한다.
apiVersion: kudo.dev/v1beta1
parameters:
- name: SST_USER
description: "User to perform SST as"
default: "root"
- name: SST_PASSWORD
description: "Password for SST user"
default: "admin"
- name: MYSQL_PORT
description: "MySQL port"
default: "3306"
- name: SST_PORT
description: "SST port"
default: "4444"
- name: REPLICATION_PORT
description: "Replication port"
default: "4567"
- name: IST_PORT
description: "IST port"
default: "4568"
지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.
KUDO 설치 (using init)
$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait # Webhook TLS를 자체 서명한 버전으로 처리
Galera Operator 설치 (using install)
$ kubectl kudo install ./
설치된 Operator Instance 확인
$ kubectl kudo plan status --instance=galera-operator-instance Plan(s) for "galera-operator-instance" in namespace "default": . └── galera-operator-instance (Operator-Version: "galera-operator-0.1.0-0.1.0" Active-Plan: "deploy") └── Plan deploy (serial strategy) [COMPLETE], last updated 2020-12-23 07:48:27 └── Phase deploy (serial strategy) [COMPLETE] ├── Step bootstrap_config [COMPLETE] └── Step bootstrap_service [COMPLETE]
설치된 Service 확인
deploy plan의 bootstrap_service step으로 생성된 service는 아래와 같이 확인할 수 있다.
$ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE galera-operator-instance-bootstrap-svc ClusterIP None <none> 3306/TCP,4444/TCP,4567/TCP,4568/TCP 80s kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 21d
생성된 서비스의 상세 정보는 아래와 같이 확인할 수 있다.
$ kubectl describe service galera-operator-instance-bootstrap-svc Name: galera-operator-instance-bootstrap-svc Namespace: default Labels: app=galera-bootstrap heritage=kudo kudo.dev/instance=galera-operator-instance kudo.dev/operator=galera-operator Annotations: kudo.dev/last-applied-configuration: {"kind":"Service","apiVersion":"v1","metadata":{"name":"galera-operator-instance-bootstrap-svc","namespace":"default","creationTimestamp":... kudo.dev/last-plan-execution-uid: 7fdc50f2-86b3-4a5f-adb1-eb6c57a90c81 kudo.dev/phase: deploy kudo.dev/plan: deploy kudo.dev/step: bootstrap_service Selector: app=galera-bootstrap,instance=galera-operator-instance Type: ClusterIP IP: None Port: mysql 3306/TCP TargetPort: 3306/TCP Endpoints: <none> Port: sst 4444/TCP TargetPort: 4444/TCP Endpoints: <none> Port: replication 4567/TCP TargetPort: 4567/TCP Endpoints: <none> Port: ist 4568/TCP TargetPort: 4568/TCP Endpoints: <none> Session Affinity: None Events: <none>
위의 결과와 같이 레이블과 포트 및 정의된 정보들이 제대로 설정된 것을 확인할 수 있다. 지금 시점에는 서비스를 사용할 부트스트랩 노드의 실제 인스턴스가 없기 때문에
Endpoint
정보가 없다.KUDO 및 Operator 삭제
$ kubectl kudo init --unsafe-self-signed-webhook-ca --upgrade --dry-run --output yaml | kubectl delete -f -
Bootstrap Node 배포
마지막 작업으로 위에서 설정한 Config, Service를 사용할 부트스트랩 노드의 실제 인스턴스를 배포하는 것이다.
- operator.yaml 파일에
bootstrap_deploy step
추가 - operator.yaml 파일에
bootstrap_deploy task
추가 - task에서 사용할
templates/bootstrap_deploy.yaml
파일 추가
위의 같은 작업을 처리한 operator.yaml은 다음과 같다.
apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
name: ccambo
name: galera-operator
operatorVersion: 0.1.0
plans:
deploy:
strategy: serial
phases:
- name: deploy
strategy: serial
steps:
- name: bootstrap_config
tasks:
- bootstrap_config
- name: bootstrap_service
tasks:
- bootstrap_service
- name: bootstrap_deploy
tasks:
- bootstrap_deploy
tasks:
- name: bootstrap_config
kind: Apply
spec:
resources:
- bootstrap_config.yaml
- name: bootstrap_service
kind: Apply
spec:
resources:
- bootstrap_service.yaml
- name: bootstrap_deploy
kind: Apply
spec:
resources:
- bootstrap_deploy.yaml
이제 Task에 리소스로 정의한 부트스트랩 배포 리소스 파일을 templates/bootstrap_deploy.yaml
파일에 아래와 같이 구성한다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Name }}-bootstrap
namespace: {{ .Namespace }}
labels:
app: galera-bootstrap
instance: {{ .Name }}
spec:
selector:
matchLabels:
app: galera-bootstrap
instance: {{ .Name }}
strategy:
type: Recreate
template:
metadata:
labels:
app: galera-bootstrap
instance: {{ .Name }}
spec:
containers:
- image: mariadb:latest
name: mariadb
args:
- "--ignore_db_dirs=lost+found"
env:
# Use secret in real usage
- name: MYSQL_ROOT_PASSWORD
value: {{ .Params.MYSQL_ROOT_PASSWORD }}
ports:
- containerPort: {{ .Params.MYSQL_PORT }}
name: mysql
- containerPort: {{ .Params.SST_PORT }}
name: sst
- containerPort: {{ .Params.REPLICATION_PORT }}
name: replication
- containerPort: {{ .Params.IST_PORT }}
name: ist
livenessProbe:
exec:
command: ["mysqladmin", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "ping"]
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
readinessProbe:
exec:
# Check we can execute queries over TCP (skip-networking is off).
command: ["mysql", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "-h", "127.0.0.1", "-e", "SELECT 1"]
initialDelaySeconds: 5
periodSeconds: 2
timeoutSeconds: 1
volumeMounts:
- name: {{ .Name }}-bootstrap
mountPath: /etc/mysql/conf.d
volumes:
- name: {{ .Name }}-bootstrap
configMap:
name: {{ .Name }}-bootstrap
items:
- key: galera.cnf
path: galera.cnf
이전에 정의한 리소스들에 비해서는 복잡해 보이지만 몇 가지만 추가된 것이다. 주요한 몇 가지는 아래와 같다.
selector:
matchLabels:
app: galera-bootstrap
instance: {{ .Name }}
리소스를 연결하는데 사용할 레이블과 인스턴스를 지정한 것이다.
ports:
- containerPort: {{ .Params.MYSQL_PORT }}
name: mysql
- containerPort: {{ .Params.SST_PORT }}
name: sst
- containerPort: {{ .Params.REPLICATION_PORT }}
name: replication
- containerPort: {{ .Params.IST_PORT }}
name: ist
컨테이너에서 사용할 포트들을 파라미터와 연계해서 지정한 것이다.
env:
# Use secret in real usage
- name: MYSQL_ROOT_PASSWORD
value: {{ .Params.MYSQL_ROOT_PASSWORD }}
env 섹션을 통해서 파라미터와 연계된 mySQL root 사용자 비밀번호를 저정한 것이다.
livenessProbe:
exec:
command: ["mysqladmin", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "ping"]
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
readinessProbe:
exec:
# Check we can execute queries over TCP (skip-networking is off).
command: ["mysql", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "-h", "127.0.0.1", "-e", "SELECT 1"]
initialDelaySeconds: 5
periodSeconds: 2
timeoutSeconds: 1
livenessProbe와 readinessProbe를 통해서 접근이 가능한지와 사용할 수 있는지에 대한 검증 명령을 지정한 것이다.
volumeMounts:
- name: {{ .Name }}-bootstrap
mountPath: /etc/mysql/conf.d
volumes:
- name: {{ .Name }}-bootstrap
configMap:
name: {{ .Name }}-bootstrap
items:
- key: galera.cnf
path: galera.cnf
ConfigMap이 정의된 Volume을 설정하고 컨테이너에서 사용할 수 있도록 마운트하는 것을 지정한 것이다. Volume도 유일한 이름으로 지정되어야 하고, ConfigMap에서 찾아야할 부분을 Key/Path로 지정해서 마운트될 때 /etc/mysql/conf.d
라는 이름의 파일로 처리될 수 있도록 지정한 것이다.
배포를 정의하면서 추가로 사용한 파라미터들을 params.yaml
파일에 아래와 같이 정의한다.
apiVersion: kudo.dev/v1beta1
parameters:
- name: SST_USER
description: "User to perform SST as"
default: "root"
- name: SST_PASSWORD
description: "Password for SST user"
default: "admin"
- name: MYSQL_PORT
description: "MySQL port"
default: "3306"
- name: SST_PORT
description: "SST port"
default: "4444"
- name: REPLICATION_PORT
description: "Replication port"
default: "4567"
- name: IST_PORT
description: "IST port"
default: "4568"
- name: MYSQL_ROOT_PASSWORD
description: "MySQL root password"
default: "admin"
지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.
KUDO 설치 (using init)
$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait # Webhook TLS를 자체 서명한 버전으로 처리
Galera Operator 설치 (using install)
$ kubectl kudo install ./
설치된 Operator Instance 확인
$ kubectl kudo plan status --instance=galera-operator-instance Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition Plan(s) for "galera-operator-instance" in namespace "default": . └── galera-operator-instance (Operator-Version: "galera-operator-0.1.0-0.1.0" Active-Plan: "deploy") └── Plan deploy (serial strategy) [IN_PROGRESS], last updated 2020-12-23 09:23:50 └── Phase deploy (serial strategy) [IN_PROGRESS] ├── Step bootstrap_config [COMPLETE] ├── Step bootstrap_service [COMPLETE] └── Step bootstrap_deploy [IN_PROGRESS]
위의 Plan 정보 중에 Phase, Step 이
IN_PROGRESS
로 나타나는 것은 실제 컨테이너가 구동되는 시간이 (이미지를 다운로드하고 구성하는 등의 시간) 필요하기 때문에 나타나는 것으로 시간이 지나면 정상적으로 표시된다. 만일 실패가 되면 원인을 찾아서 다시 처리해야 한다.참고
Docker의 상용화 정책으로 인해서 Docker Repository에서 Image를 다운로드하는 부분에 Rate Limit가 설정되어 있기 때문에 오류가 발생할 수도 있다.
설치된 Bootstrap Node 확인
부트스트랩 노드 인스턴스를 배포한 것이기 때문에 Pod가 생성되어 동작하는지를 아래와 같이 확인할 수 있다.
$ kubectl get pods NAME READY STATUS RESTARTS AGE galera-operator-instance-bootstrap-59855f6884-gz4rr 1/1 Running 0 5m7s
정상적으로 생성되어 동작하는 로그 정보는 아래와 같이 확인할 수 있다.
$ kubectl logs galera-operator-instance-bootstrap-59855f6884-gz4rr ... 2020-12-23 9:24:04 0 [Note] WSREP: Server initialized 2020-12-23 9:24:04 0 [Note] WSREP: Server status change initializing -> initialized 2020-12-23 9:24:04 0 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2020-12-23 9:24:04 2 [Note] WSREP: Bootstrapping a new cluster, setting initial position to 00000000-0000-0000-0000-000000000000:-1 2020-12-23 9:24:04 4 [Note] WSREP: Cluster table is empty, not recovering transactions 2020-12-23 9:24:04 2 [Note] WSREP: Server status change initialized -> joined 2020-12-23 9:24:04 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2020-12-23 9:24:04 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2020-12-23 9:24:04 0 [Note] Reading of all Master_info entries succeeded 2020-12-23 9:24:04 0 [Note] Added new Master_info '' to hash table 2020-12-23 9:24:04 0 [Note] mysqld: ready for connections. ...
위의 로그 결과와 같이 Galera 가 구성되었고 가입이 가능하도록 준비된 새 클러스터를 생성한 것을 확인할 수 있다.
그리고 ConfigMap이 제대로 마운트되어 실행되어 있는지는 아래와 같이 동작하는 컨테이너에 연결해서 확인할 수 있다.
$ kubectl exec -it galera-operator-instance-bootstrap-59855f6884-gz4rr /bin/bash kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead. root@galera-operator-instance-bootstrap-59855f6884-gz4rr:/# ls /etc/mysql/conf.d/ galera.cnf root@galera-operator-instance-bootstrap-59855f6884-gz4rr:/# cat /etc/mysql/conf.d/galera.cnf [galera] wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_sst_method = mariabackup wsrep_cluster_address = gcomm:// wsrep_sst_auth = "root:admin" binlog_format = ROW
그리고 bootstrap_service를 구성했을 때 지정되지 않았던
endpoint
가 제대로 설정되었는지는 아래와 같이 확인할 수 있다.$ kubectl describe service galera-operator-instance-bootstrap-svc Name: galera-operator-instance-bootstrap-svc Namespace: default Labels: app=galera-bootstrap heritage=kudo kudo.dev/instance=galera-operator-instance kudo.dev/operator=galera-operator Annotations: kudo.dev/last-applied-configuration: {"kind":"Service","apiVersion":"v1","metadata":{"name":"galera-operator-instance-bootstrap-svc","namespace":"default","creationTimestamp":... kudo.dev/last-plan-execution-uid: 11aebdd4-ff44-4f5c-a166-1bd56a9213ff kudo.dev/phase: deploy kudo.dev/plan: deploy kudo.dev/step: bootstrap_service Selector: app=galera-bootstrap,instance=galera-operator-instance Type: ClusterIP IP: None Port: mysql 3306/TCP TargetPort: 3306/TCP Endpoints: 10.244.84.141:3306 Port: sst 4444/TCP TargetPort: 4444/TCP Endpoints: 10.244.84.141:4444 Port: replication 4567/TCP TargetPort: 4567/TCP Endpoints: 10.244.84.141:4567 Port: ist 4568/TCP TargetPort: 4568/TCP Endpoints: 10.244.84.141:4568 Session Affinity: None Events: <none>
KUDO 및 Operator 삭제
$ kubectl kudo init --unsafe-self-signed-webhook-ca --upgrade --dry-run --output yaml | kubectl delete -f -
Conclusion
지금까지의 작업으로 완전하게 동작하는 Galera Bootstrap Node가 구성되어 연결을 수신힐 준비가 되었다는 것을 확인해 보았다.
PART 2에서는 더 많은 Operator 기능을 구성해서 노드들을 추가하고 클러스터에 참여하도록 하는 방법을 검토해 본다.
참고 자료
'개발 > Kubernetes 이해' 카테고리의 다른 글
- Total
- Today
- Yesterday
- provisioner
- docker
- CentOS 8
- terrminating
- Kudo
- dynamic nfs client provisioner
- CentOS
- leader
- NFS
- 쿠버네티스
- SolrCloud
- KUBECTL
- Packages
- custom resource
- ssh
- Galera Cluster
- zookeeper
- operator framework
- GIT
- Replica
- Node
- opencensus
- kudo-cli
- Cluster
- operator
- Kubernetes
- galera
- k8s
- macos
- collection
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |