티스토리 뷰

개발/Kubernetes 이해

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 1: Bootstrap Node 구성

ccambo 2020. 12. 23. 20:20
728x90
반응형

How to building real world sample step by step - Part 1

게시글 참고

이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다.

  • PART 2에서는 Galera Cluster에 참여할 노드들 구성
  • PART 3에서는 사용하지 않는 부트스트랩을 제거하고, 외부 접속을 위한 서비스를 생성하며, 안전한 Scale Up/Down 처리 구성

이 문서는 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 기능을 구성해서 노드들을 추가하고 클러스터에 참여하도록 하는 방법을 검토해 본다.

참고 자료

728x90
반응형
저작자표시 비영리 동일조건

'개발 > Kubernetes 이해' 카테고리의 다른 글

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 2: Nodes 참여와 서비스 생성 및 StatefulSet 구성  (0) 2021.01.05
[Kubernetes-Storage] CentOS 8에 Dynamic NFS Client Provisioner 구성하기  (0) 2021.01.05
[Kubernetes - Operator] KUDO 설치 및 간단한 사용법 검증  (1) 2020.12.21
[Kubernetes - Operator] Kubernetes 상의 Operator Tools 간략 비교  (0) 2020.12.21
[Kubernetes - Operator] Kubernetes상의 Operator 나름대로 정리  (8) 2020.12.21
공유하기 링크
댓글
250x250
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG more
«   2024/10   »
일 월 화 수 목 금 토
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 31
글 보관함