Hyugo

Hyugo/Database Operator In Kubernetes study 2주차

Created Fri, 27 Oct 2023 19:24:51 +0900 Modified Mon, 27 Nov 2023 05:11:47 +0000
1974 Words 9 min

학습내용 정리

쿠버네티스 오퍼레이터

  • CRD Custom Resource Definition : 오퍼레이터로 사용할 상태 관리용 객체들의 Spec 을 정의
  • CR Custom Resource : CRD의 Spec 를 지키는 객체들의 실제 상태 데이터 조합
  • CC Custom Controller : CR의 상태를 기준으로 현재의 상태를 규정한 상태로 처리하기 위한 컨트롤 루프
  • 오퍼레이터는 Helm 기능을 포함하며, 배포 업그레이드 운영까지 확장해서 관리
  • CRD 구성 및 배포, Custom Controller 연계 및 실행 등을 모두 합쳐 놓은 것 == Operator
  • 오퍼레이터 허브에서 각 기술 성숙도에 따라 레벨이 다름

실습

오퍼레이터를 통해 MySQL 클러스터 및 Wordpress를 배포 하는 실습을 수행하였으나, 실습에 대한 결과를 캡쳐하는것은 큰 의미가 없는것으로 느껴져 생략

MySQL Cluster 구성

  • MySQL Operator를 통해 MySQL클러스터가 구성됨
  • 구성된 클러스터에서 StatefulSet 으로 각 Pod가 순차적으로 배포되고, 컨테이너가 실행
  • PVC를 통해 볼륨을 보존해 보관, 해당 PVC가 삭제될때까지 데이터가 유지된다.
  • Operator를 통해 각종 필요 리소스들이 체계적으로 배포되고 사용자가 사용하기 쉬운 환경이 배포됨

작동 확인사항

  • MySQL라우터를 통해서 MySQL의 각 Pod에 트래픽이 전달됨
  • 이전 스터디에서 배운 Headless Service를 통해 subDomain으로 각 Pod에 직접 접속 가능
  • DB의 가중치 설정 설정변경으로 Main이 변경됨
  • 다량의 데이터 INSERT를 통해 MySQL 세컨더리 파드에 복제 확인 및 세컨더리 Pod의 ReadOnly확인
  • Pod의 스케일링을 통해 sts가 state한 상태로 Pod를 스케쥴링 함을 확인했다.
  • 클러스터 내에서 DB백업에 대한 수행
  • 이전 배포된 Mysql Cluster를 DB로 사용하여 워드프레스를 배포해 보았다.

스터디간 느낀 점 및 추가 스터디 사항

MySQL Operator는 여러 커스텀 리소스및 쿠버네티스 리소스를 통해 DB 배포 및 클러스터 작업을 완전 자동화 해줍니다. 이전 Windows Server에서 Oracle DB의 클러스터 구성을 진행해 본 기억이 있는데, 해당 서버에 Cluster구성을 위해서 Windows Server의 Failover Cluster구성작업을 수행했습니다. 그때 당시 클러스터 구성을 위해서 OS상에 AD조인, Disk 구성, 쿼럼 설정, 권한설정 등 복잡한 절차가 선행됐고, Oracle Clustering 작업을 위해서 전문 DBA를 모셔와야하는 큰 불편함이 있었습니다. 하지만 금일 스터디에서 아주 간단하게 MySQL의 Cluster구성을 수행하는 것을 보고 Kubernetes를 사용하면 고가용성 서비스 구성을 자동화 할 수 있는 아주 좋은 도구가 될 수 있음을 확인했습니다. 또 스터디에서 테스트한 각종 데이터 안정성과 관련된 부분들을 보면서, 안정적으로 DB를 사용할 수 있을정도로 쿠버네티스 클러스터 및 오퍼레이터의 기술이 발전했다는걸 알 수 있었습니다. 오픈소스 데이터베이스 즉 직접 관리해야하는 데이터베이스는 쿠버네티스에 배포해 더 편리하게 사용할 수 있겠다는 생각이 생겼습니다. 예전에 Reids sentinel구성을 쿠버네티스에서 진행했었는데, 그때는 직접 Configmap을 만들고, 커멘드를 실행 할 수 있게끔 설정해 reids 이미지를 수정하지않고 명령어를 통해 클러스터링을 수행했었습니다. 이번 스터디에서는 헬름 명령어에 오퍼레이터 형식으로 각종 리소스를 새로 선언하고, 배포하는 방식으로 수행해 보았습니다. 굉장히 좋은 경험이였고, 앞으로 오퍼레이터에 대해서 더 자세한 사항을 배워 갈 수 있었으면 좋겠습니다.

추가 학습내용

오퍼레이터 패턴

  • 오퍼레이터 패턴 은 서비스 또는 서비스 셋을 관리하는 운영자의 주요 목표를 포착하는 것을 목표로 한다.
  • 정 애플리케이션 및 서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우 대처 방법에 대해 깊이 알고 있다.
  • 오퍼레이터 패턴은 쿠버네티스 자체가 제공하는 것 이상의 작업을 자동화하기 위해 코드를 작성하는 방법
  • 따라서 이번 스터디에서 배포한 오퍼레이터인 MySQL Cluster는 쿠버네티스에서 자동화를 지원하는 것 이상의 DB 배포 -> Cluster 구성의 단계를 자동화하기위해 만든 오퍼레이터이다.

Custom Resource(CR)란 무엇인가

  • Custom Resource는 쿠버네티스의 API 익스텐션.
  • 쿠버네티스 API 에서 특정 종류의 API 오브젝트 모음을 저장하는 엔드포인트이다.
  • CRD혹은 aggregate API를 통해서 생성할 수 있다. *API 오브젝트 모음이란 Pod 리소스에 오브젝트 모음이 포함돼 있어 kubectl 명령어로 직접 조회가 가능하다, CR또한 해당 명령어를 통해 API 조회가 가능함

CRD vs API 애그리게이트

사용 편의성

CRD애그리게이트 API
프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다.프로그래밍하고 바이너리와 이미지를 빌드해야 한다.
실행할 추가 서비스가 없다. CR은 API 서버에서 처리한다.추가 서비스를 생성하면 실패할 수 있다.
CRD가 생성된 후에는 지속적인 지원이 없다. 모든 버그 픽스는 일반적인 쿠버네티스 마스터 업그레이드의 일부로 선택된다.업스트림에서 버그 픽스를 주기적으로 선택하고 애그리게이트 API 서버를 다시 빌드하고 업데이트해야 할 수 있다.
여러 버전의 API를 처리할 필요가 없다. 예를 들어, 이 리소스에 대한 클라이언트를 제어할 때 API와 동기화하여 업그레이드할 수 있다.인터넷에 공유할 익스텐션을 개발할 때와 같이 여러 버전의 API를 처리해야 한다.