[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 3: Bootstrap 삭제 및 서비스 중단 없이 Scale Up/Down 처리

<h1>How to building real world sample step by step - Part 3</h1> <blockquote> <h2><strong>게시글 참고</strong></h2> <p>이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다.</p> <ul> <li><a href="https://ccambo.blogspot.com/2020/12/kubernetes-operator-kudo-galera.html">PART 1</a>에서는 부트스트랩 노드 구성</li> <li><a href="https://ccambo.blogspot.com/2021/01/kubernetes-operator-kudo-galera_5.html">PART 2</a>에서는 클러스터에 노드들이 참여할 떄 사용할 서비스와 설정등을 구성하고 StatefulSet을 구성</li> </ul> </blockquote> <p>이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 구성된 Galera Cluster의 사용하지 않는 bootstrap 정보를 제거하고, 외부 연결을 위한 서비스 생성 및 서비스의 중단없이 Scale Up/Down 할 수 있도록 나머지 부분을 적용해 본다. 이 과정까지 완료되면 프로덕션 환경에 적용할 수 있는 정도가 된다.</p> <h2>Cleanup bootstrap node</h2> <p>PART 2 에서 모든 노드들을 클러스터에 참여시켰기 때문에 더 이상은 부트스트랩 노드가 필요하지 않다.</p> <p>따라서 <code>operator.yaml</code>에 부트스트랩 노드와 관련된 리소스를 제거하는 Step과 Task를 추가하도록 한다.</p> <pre><code class="language-yaml">... plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: ... - name: cleanup # 추가 tasks: - bootstrap_cleanup tasks: ... - name: bootstrap_cleanup # 추가 kind: Delete spec: resources: - bootstrap_deploy.yaml - bootstrap_service.yaml - bootstrap_config.yaml</code></pre> <p>추가된 <code>bootstrap_cleanup</code>은 삭제 작업으로 PART 1에서 만들었던 bootstrap 관련 리소스들이 대상이며 이 작업이 실행되면 resources로 지정된 *.yaml 파일에 정의된 부트스트랩 리소스들 (ConfigMap, Service, Deploy)이 모두 삭제된다.</p> <p><code>그러나 실제 Galera 노드들에서 사용하는 ConfigMap에 부트스트랩 노드 정보 (wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc)</code>가 남아 있기 떄문에 Galera 인스턴스가 누락된 노드를 중심으로 작동하므로 반드시 문제가 되는 것은 아닐지라도 완전성을 위해 관련된 정보도 삭제해 주는 것이 좋다.</p> <p>따라서 <code>opreator.yaml</code>파일에 ConfigMap을 수정할 수있는 Task를 추가하고 Step에서 이 Task를 이용하는 것으로 아래와 같이 변경한다.</p> <pre><code class="language-yaml">... plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: ... - name: cleanup tasks: - bootstrap_cleanup - config # 추가 tasks: ... - name: bootstrap_cleanup kind: Delete spec: resources: - bootstrap_deploy.yaml - bootstrap_service.yaml - bootstrap_config.yaml - name: config # 추가 kind: Apply spec: resources: - galera_config.yaml</code></pre> <p>이번에는 하나의 Step에서 두 개의 Task가 동작하도록 정의했다. deploy phase의 실행 전략을 <code>strategy: serial</code>로 지정했으므로 두 개의 Task는 순차적으로 처리된다.</p> <blockquote> <h2><strong>참고</strong></h2> <p>여기서 주의할 것은 PART 2에서 사용했던 <code>galera_config.yaml</code>을 다시 사용한다는 것이다. 즉, 노드를 설치할 때와 삭제할 때 설정 기능이 다른데 하나의 리소스를 재 사용하는 상황인 것이다. 이를 해결하기 위해서 템플릿에서 <code>.StepName</code> 변수를 활용해서 어떤 Step에서 호출되었는지를 식별해서 처리하는 방식을 사용한다.</p> </blockquote> <p><code>StepName 정보를 기준으로 내용을 구성</code>할 수 있도록 템플릿 리소스인 <code>templates/galera_config.yaml</code> 파일을 아래와 같이 수정한다.</p> <pre><code class="language-yaml">apiVersion: v1 kind: ConfigMap metadata: name: {{ .Name }}-nodeconfig namespace: {{ .Namespace }} data: galera.cnf: | [galera] wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_sst_method = mariabackup {{ if eq .StepName "firstboot_config" -}} wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc,{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}} {{ else -}} wsrep_cluster_address = gcomm://{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}} {{ end -}} wsrep_sst_auth = "{{ .Params.SST_USER }}:{{ .Params.SST_PASSWORD }}" binlog_format = ROW innodb.cnf: | [innodb] innodb_autoinc_lock_mode = 2 innodb_flush_log_at_trx_commit = 0 innodb_buffer_pool_size = 122M</code></pre> <p><code>wsrep_cluster_address</code> 정보를 지정할 때 템플릿에 조건부 처리를 지정했다. 즉, <code>firstboot_config</code> Step일 경우는 부트스트랩 구성이 적용되고, 그 외는 클러스터에 참여할 노드 정보들만 구성되는 것이다.</p> <pre><code class="language-yaml">{{ if eq .StepName "firstboot_config" -}} wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc,{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}} {{ else -}} wsrep_cluster_address = gcomm://{{ $.Name }}-galera-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-galera-{{ $v }}.{{ $.Name }}-hs{{end}} {{ end -}}</code></pre> <p><code>if</code>, <code>else</code>, <code>end</code> 구문은 <code>-}}</code> 으로 종료시키고 있다. 이는 템플릿 엔진에게 해당 라인을 빈줄로 뇌두지 말고 삭제하도록 지정하는 것이다.</p> <p>위와 같이 템플릿 내에 조건문을 사용해서 다른 여러 Task들에서 재 사용할 수 있다.</p> <p>이제 Pod가 재 시작되면 post-bootstrap cluster에 대한 올바른 구성을 가지고 다시 백업을 시작할 수 있게 된다.</p> <p>지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.</p> <ul> <li><p><strong>KUDO 설치 (using init)</strong></p> <pre><code class="language-bash">$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait # Webhook TLS를 자체 서명한 버전으로 처리</code></pre> </li> <li><p><strong>Galera Operator 설치 (using install)</strong></p> <pre><code class="language-bash">$ kubectl kudo install ./</code></pre> </li> <li><p><strong>설치된 Operator Instance 확인</strong></p> <pre><code class="language-bash">$ kubectl kudo plan status --instance=galera-operator-instance</code></pre> </li> <li><p><strong>설치된 ConfigMap 및 Pod 확인</strong></p> <pre><code class="language-bash">$ kubectl describe configmap galera-operator-instance-nodeconfig Name: galera-operator-instance-nodeconfig 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-nodeconfig","namespace":"default","creationTimestamp":n... kudo.dev/last-plan-execution-uid: 8cd36d4b-aeb5-473e-8997-1fad6090722a kudo.dev/phase: deploy kudo.dev/plan: deploy kudo.dev/step: cleanup Data ==== galera.cnf: ---- [galera] wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_sst_method = mariabackup wsrep_cluster_address = gcomm://galera-operator-instance-galera-0.galera-operator-instance-hs,galera-operator-instance-galera-1.galera-operator-instance-hs,galera-operator-instance-galera-2.galera-operator-instance-hs wsrep_sst_auth = "root:admin" binlog_format = ROW innodb.cnf: ---- [innodb] innodb_autoinc_lock_mode = 2 innodb_flush_log_at_trx_commit = 0 innodb_buffer_pool_size = 122M Events: <none></code></pre> <p>정상적으로 ConfigMap이 조건에 따라서 <code>wsrep_cluster_address</code> 설정 값이 부트스트랩 정보없이 노드들의 정보만으로 구성된 것을 확인할 수 있다.</p> <pre><code class="language-bash">$ kubectl get pods NAME READY STATUS RESTARTS AGE galera-operator-instance-galera-operator-0 1/1 Running 0 3m28s galera-operator-instance-galera-operator-1 1/1 Running 0 3m3s galera-operator-instance-galera-operator-2 1/1 Running 0 2m35s nfs-client-provisioner-b84668c6d-zxt8d 1/1 Running 0 91m</code></pre> <p>부트스트랩 노드가 제거되고 나머지 노드들만 존재하는 것을 확인할 수 있다.</p> </li> <li><p><strong>KUDO 및 Operator 삭제</strong></p> <pre><code class="language-bash">$ kubectl kudo init --unsafe-self-signed-webhook-ca --upgrade --dry-run --output yaml | kubectl delete -f -</code></pre> </li> </ul> <h2>Add service for connect from client</h2> <p>이제 클라이언트가 Galera Cluster에 연결할 수 있는 방법이 필요하다. Galera Cluster는 다중 마스터 구조이기 때문에 어디로 연결되더라도 안전하게 읽고 쓸 수 있다. 서비스는 어떤 의존성도 갖지않기 때문에 deploy plan의 어떤 단계에서 생성하던지 상관이 없지만 이미 클러스터 내부의 서비스를 생성한 단계가 있으므로 여기에 추가하도록 한다.</p> <p><code>operator.yaml</code> 파일의 이미 존재하는 <code>cluster_service</code> Task에 아래와 같이 추가한다.</p> <pre><code class="language-yaml">... - name: cluster_services kind: Apply spec: resources: - hs-service.yaml - cs-service.yaml # 추가 ...</code></pre> <p>이제 사용한 서비스 리소스인 <code>templates/cs-service.yaml</code> 파일을 생성하고 아래와 같이 구성한다.</p> <pre><code class="language-yaml">apiVersion: v1 kind: Service metadata: name: {{ .Name }}-cs namespace: {{ .Namespace }} labels: app: galera galera: {{ .Name }} spec: ports: - port: {{ .Params.MYSQL_PORT }} name: mysql selector: app: galera instance: {{ .Name }}</code></pre> <p><code>이 서비스는 mySQL 포트만 필요하고 클라이언트가 Galera Clustr에 연결할 수 있도록 load balancing된 ClusterIP를 제공</code>한다.</p> <p>지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.</p> <ul> <li><p><strong>KUDO 설치 (using init)</strong></p> <pre><code class="language-bash">$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait # Webhook TLS를 자체 서명한 버전으로 처리</code></pre> </li> <li><p><strong>Galera Operator 설치 (using install)</strong></p> <pre><code class="language-bash">$ kubectl kudo install ./</code></pre> </li> <li><p><strong>설치된 Operator Instance 확인</strong></p> <pre><code class="language-bash">$ kubectl kudo plan status --instance=galera-operator-instance</code></pre> </li> <li><p><strong>설치된 Service 확인</strong></p> <pre><code class="language-bash">$ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE galera-operator-instance-cs ClusterIP 10.104.170.201 <none> 3306/TCP 5m3s galera-operator-instance-hs ClusterIP None <none> 3306/TCP,4444/TCP,4567/TCP,4568/TCP 5m3s</code></pre> <p>실행 중인 클러스터에 모든 서비스가 생성된 것을 확인할 수 있다. 서비스의 상세 정보를 통해서 정상적으로 생성되었는지 확인한다.</p> <pre><code class="language-bash">$ kubectl describe service galera-operator-instance-cs Name: galera-operator-instance-cs Namespace: default Labels: app=galera galera=galera-operator-instance 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-cs","namespace":"default","creationTimestamp":null,"label... kudo.dev/last-plan-execution-uid: f5b71f8e-b9ef-49b0-81d1-8f82315e63d4 kudo.dev/phase: deploy kudo.dev/plan: deploy kudo.dev/step: cluster_services Selector: app=galera,instance=galera-operator-instance Type: ClusterIP IP: 10.104.170.201 Port: mysql 3306/TCP TargetPort: 3306/TCP Endpoints: 10.244.247.12:3306,10.244.84.132:3306 Session Affinity: None Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedToUpdateEndpointSlices 4m37s endpoint-slice-controller Error updating Endpoint Slices for Service default/galera-operator-instance-cs: failed to update galera-operator-instance-cs-brmb9 EndpointSlice for Service default/galera-operator-instance-cs: Operation cannot be fulfilled on endpointslices.discovery.k8s.io "galera-operator-instance-cs-brmb9": the object has been modified; please apply your changes to the latest version and try again</code></pre> <ul> <li><strong>클라이언트 연결 확인</strong></li> </ul> <p>생성한 서비스를 통해서 클라이언트가 Galera Cluster에 접속할 수 있다.</p> <pre><code class="language-bash">$ kubectl run mysql-client --image=mysql:5.7 -it --rm --restart=Never -- mysql -u root -h galera-operator-instance-cs -p</code></pre> <p>진행 중에 아래와 같은 메시지가 보이면 <code>params.yaml</code>에 정의했던 password를 입력하면 된다.</p> <pre><code>If you don't see a command prompt, try pressing enter.</code></pre><p><code>mysql></code> 프롬프트가 보이면 정상적으로 연결이 된 것이다.</p> </li> <li><p><strong>KUDO 및 Operator 삭제</strong></p> <pre><code class="language-bash">$ kubectl kudo init --unsafe-self-signed-webhook-ca --upgrade --dry-run --output yaml | kubectl delete -f -</code></pre> </li> </ul> <h2>Scale up/down without service interruption</h2> <p>KUDO는 파라미터의 값을 변경함으로써 연계된 Plan 이 구동된다. 파라미터로 정의한 <code>NODE_COUNT</code>를 변경하면 deploy plan이 구동될 것이기 때문에 ConfigMap을 변경하고 클러스터에 새로운 노드 수를 반영하기 위해서 StatefulSet이 재 시작될 필요가 있다.</p> <p>이런 작업을 반영하기 위해 <code>operator.yaml</code> 파일에 새로운 plan을 아래와 같이 추가한다.</p> <pre><code class="language-yaml">... plans: deploy: ... node_update: # 추가 strategy: serial phases: - name: deploy stratege: serial steps: - name: config tasks: - config - name: stateful tasks: - statefulset ...</code></pre> <p>이 Plan은 기존의 Task를 재 사용하는 것이기 때문에 별도의 Task 추가는 필요하지 않고 두 개의 Step이 순차적으로 실행되도록 정의한 것이다.</p> <p>이제 <code>NODE_COUNT</code> 파라미터가 변경되면 위에 정의한 새로운 Plan이 구동될 수 있도록 <code>params.yaml</code>의 파라미터 정보를 아래와 같이 추가한다.</p> <pre><code class="language-yaml">apiVersion: kudo.dev/v1beta1 parameters: ... - name: NODE_COUNT description: "Number of nodes to create in the cluster" default: "3" trigger: node_update # 추가 ...</code></pre> <p>PART 2 에서는 <code>trigger</code> 정보가 없었으며 이런 경우는 기본 값으로 <code>deploy</code> plan이 호출되게 된다. trigger를 지정해서 <code>node_update</code> plan을 호출하도록 한 것이다.</p> <p>지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.</p> <ul> <li><p><strong>KUDO 설치 (using init)</strong></p> <pre><code class="language-bash">$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait # Webhook TLS를 자체 서명한 버전으로 처리</code></pre> </li> <li><p><strong>Galera Operator 설치 (using install)</strong></p> <pre><code class="language-bash">$ kubectl kudo install ./</code></pre> </li> <li><p><strong>설치된 Operator Instance 확인</strong></p> <pre><code class="language-bash">$ kubectl kudo plan status --instance=galera-operator-instance</code></pre> </li> <li><p><strong>NODE_COUNT 변경 검증</strong></p> <pre><code class="language-bash">$ kubectl kudo update --instance galera-operator-instance -p NODE_COUNT=3</code></pre> <p>파라미터를 통한 변경이 적용되었기 때문에 변경에 따른 처리를 확인한다.</p> <pre><code class="language-bash">$ kubectl kudo plan status --instance=galera-operator-instance</code></pre> <p>Pod가 재 시작되는 시간이 있기 때문에 <code>IN_PROGRESS</code> 상태로 나타나며, 이 작업이 진행 중인 동안에 <code>kubectl get pods</code> 명령을 수행하면 추가된 수 만큼 노드가 배포가 되고, 이전에 동작하던 노드들은 한번에 하나씩 재 시작되는 것을 볼 수 있다. 반대로 <code>NODE_COUNT</code> 파라미터의 수를 줄이면 동작하던 노드들이 제거되는 것을 확인할 수 있다.</p> </li> <li><p><strong>KUDO 및 Operator 삭제</strong></p> <pre><code class="language-bash">$ kubectl kudo init --unsafe-self-signed-webhook-ca --upgrade --dry-run --output yaml | kubectl delete -f -</code></pre> </li> </ul> <h2>Process syncronization before shuting down nodes</h2> <p>Scale up은 상관이 없지만 down의 경우는 노드가 제거될 때 Galera Cluster의 노드가 동기화되지 않으면 클러스터의 상태에 문제가 발생할 수 있으므로 노드가 종료되기 전에 동기화를 해야할 필요가 있다.</p> <p>이를 위해서 상태를 검증하는 스크립트를 추가하고 StatefulSet의 spec에 <a href="https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/">preStop check</a>를 수정해서 처리를 수행하도록 <code>operator.yaml</code> 파일의 <code>deploy plan의 Statefulset Step 이전</code>에 적용될 수 있도록 Step과 Task를 추가한다.</p> <pre><code class="language-yaml">... plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: ... - name: node_scripts # 추가 tasks: - node_scripts ... - name: statefulset ... ... tasks: ... - name: node_scripts # 추가 kind: Apply spec: resources: - node_scripts.yaml</code></pre> <p>상태를 검증하는 스크립트를 위한 ConfigMap 리소스인 <code>templates/node_scripts.yaml</code> 파일을 생성하고 아래와 같이 구성한다.</p> <pre><code class="language-yaml">apiVersion: v1 kind: ConfigMap metadata: name: {{ .Name }}-node-scripts namespace: {{ .Namespace }} wait-for-sync.sh: | until mysql -u root -p{{ .Params.MYSQL_ROOT_PASSWORD }} -e "SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';" | grep -q Synced do echo "Waiting for sync" sleep 5 done</code></pre> <p>그리고 이 스크립트가 StatefulSet에 정상적으로 마운트될 수 있도록 <code>templates/statefulset.yaml</code>에 추가한다.</p> <pre><code class="language-yaml"> volumeMounts: - name: {{ .Name }}-config mountPath: /etc/mysql/conf.d - name: {{ .Name }}-datadir mountPath: /var/lib/mysql - name: {{ .Name }}-node-scripts # 추가 mountPath: /etc/galera/wait-for-sync.sh subPath: wait-for-sync.sh volumes: - name: {{ .Name }}-config configMap: name: {{ .Name }}-nodeconfig items: - key: galera.cnf path: galera.cnf - key: innodb.cnf path: innodb.cnf - name: {{ .Name }}-node-scripts # 추가 configMap: name: {{ .Name }}-node-scripts defaultMode: 0755</code></pre> <p>ConfigMap에서 subPath로 스크립트을 직접 마운트했다. subPath를 사용할 때 <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/">제한들</a>이 있지만 여기서는 큰 의미가 없다.</p> <p>또한 Kubernetes 클러스터를 구성하는 노드들의 장애로 부터 보호하기 위해서 분리된 노드들로 배포되도록 스케줄되어 있는지에 대한 확인이 필요하다. 이 작업은 AntiAffinity (반 선호도) 규칙을 사용해서 처리가 가능하며 테스트를 위해서 이 규칙을 비활성화 시킬 수 있다. <code>templates/statefulset.yaml</code> 파일에 아래와 같이 조건 섹션을 구성한다.</p> <pre><code class="language-yaml">... spec: {{ if eq .Params.ANTI_AFFINITY "true" }} affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "app" operator: In values: - galera - key: "instance" operator: In values: - {{ .Name }} topologyKey: "kubernetes.io/hostname" {{ end }} ...</code></pre> <blockquote> <h2><strong>참고</strong></h2> <p>상기 예제의 Anti-Affinity는 반 선호도에 대한 Pod Selector 개념으로 <code>topologyKey를 kubernetes.io/hostname으로 설정해서 Pod가 존재하는 동일한 Host가 아닌 다른 곳으로 배치</code>하나는 의미가 된다.</p> </blockquote> <p>사용된 <code>ANTI_AFFINITY</code> 파라미터를 <code>params.yaml</code> 파일에 추가한다.</p> <pre><code class="language-yaml">... - name: ANTI_AFFINITY description: "Enforce pod anit-affinity" default: False ...</code></pre> <p>지금까지의 작업으로 Operator는 Node 선호도를 관리하고 안전하게 Scale up/down이 가능하고, 외부의 클라이언트가 접근할 수 있도록 구성되었다.</p> <p>이 시점에서 몇 가지 벤치마크와 클러스터를 확장하고 축소하는 동시에 모든 것이 정상적으로 작동하는지를 확인해야 한다. <a href="https://www.percona.com/blog/2020/02/07/how-to-measure-mysql-performance-in-kubernetes-with-sysbench/">how to measure mysql performance in kubernetes with sysbench</a>를 이용해서 확인이 가능하다.</p> <h2>Conclusion</h2> <p>지금까지 Galera Cluster를 구성하고 운영하는 Operator를 단계별로 확인해 보았으며, 그 과정을 통해서 KUDO에서 제공하는 내장 변수들과 Sprig 템플릿 함수를 이용해서 조건부 템플릿을 적용해 리소스 파일들을 재 사용할 수 있다는 것도 확인했다.</p> <p>향후에는 시간이 허락하고 관련된 작업을 진행하게 된다면 지금까지 확인한 설치관련 (Day 1 Operation) 뿐만 아니라 운영 중 (Day 2 Operation) 에 발생할 수 있는 상황들에 대한 부분을 추가로 검토해 볼 예정이다.</p> <h2>참고 자료</h2> <ul> <li><a href="https://kudo.dev/blog/blog-2020-08-05-building-your-first-operator-3.html">Building your first KUDO Operator - Part 3</a></li> </ul>