오늘의 기술 토픽

Kubernetes Operators & CRDs

이번 브리프는 Kubernetes의 확장 메커니즘인 Custom Resource Definition(CRD)과 Operator 패턴을 중심으로 다룬다. CRD로 새로운 리소스 타입을 정의하고 Operator가 이를 지속적으로 감시하며 원하는 상태를 유지하는 원리를 소개한다. 이와 함께 Operator 개발 도구인 Kubebuilder와 Operator SDK, 그리고 선언적 배포 관리를 위한 Argo CD, 인프라 프로비저닝까지 CRD/Operator 패턴으로 확장한 Crossplane을 함께 살펴본다. 전체적으로 Kubernetes 생태계가 애플리케이션뿐 아니라 인프라 전체를 코드로 선언하고 자동화하는 방향으로 나아가고 있음을 보여준다.

🔑 핵심 요점

  • CRD는 Kubernetes API를 확장해 사용자 정의 리소스 타입을 등록하는 기능이다.
  • Operator는 CRD로 정의된 리소스를 지속적으로 관찰(reconcile)하며 원하는 상태(desired state)를 유지하는 컨트롤러다.
  • 복잡한 운영 지식(백업, 장애 복구, 스케일링 등)을 코드화해 자동화하는 것이 Operator 패턴의 핵심 목적이다.
  • Kubebuilder, Operator SDK 같은 프레임워크를 사용하면 Go로 직접 Operator를 빠르게 개발할 수 있다.
  • Crossplane은 CRD/Operator 패턴을 클라우드 인프라 프로비저닝까지 확장한 사례다.
  • Argo CD 같은 GitOps 도구와 결합하면 CRD 기반 리소스 변경 이력까지 Git으로 관리할 수 있다.
  • 결국 이 흐름은 애플리케이션과 인프라 모두를 ‘코드로 선언’하는 방향으로 수렴한다.

🛠 핵심 기술 쉽게 이해하기

Kubernetes Operators & CRDs

CRD(Custom Resource Definition)는 Kubernetes API 서버에 새로운 리소스 타입을 등록하는 기능이고, Operator는 그 리소스를 감시하며 실제 상태를 원하는 상태로 맞춰주는 컨트롤러다. 즉 CRD가 ‘무엇을 관리할지’를 정의한다면 Operator는 ‘어떻게 관리할지’를 실행하는 소프트웨어다.

왜 필요한가 — 데이터베이스, 메시지 큐 같은 복잡한 시스템의 설치, 백업, 장애 복구, 업그레이드 같은 운영 지식을 사람이 매번 수동으로 하지 않고 코드로 자동화하기 위해 사용한다.

발표에서는 — 이번 브리프의 중심 주제로, CRD와 Operator의 관계 및 reconcile 루프 개념을 기본 원리로 다룬다.

Kubebuilder / Operator SDK

Go 언어로 Kubernetes Operator를 만들 때 반복적인 보일러플레이트 코드를 자동 생성해주는 프레임워크다. CRD 스캐폴딩, 컨트롤러 골격, 테스트 환경 구성까지 함께 제공한다.

왜 필요한가 — Operator를 처음부터 직접 만들면 Kubernetes API 클라이언트, watch 로직 등을 일일이 구현해야 하는데, 이 도구들은 그 과정을 표준화하고 단축해준다.

발표에서는 — Operator 개발을 시작할 때 가장 널리 쓰이는 진입점 도구로 언급된다.

Crossplane

CRD와 Operator 패턴을 클라우드 인프라(예: AWS RDS, GCP VPC 등)까지 확장해, 클라우드 리소스를 Kubernetes 리소스처럼 선언적으로 정의하고 관리할 수 있게 해주는 오픈소스 프로젝트다.

왜 필요한가 — 애플리케이션과 인프라를 하나의 API(Kubernetes API)와 GitOps 워크플로로 통합 관리하고 싶을 때 사용한다.

발표에서는 — Operator 패턴이 애플리케이션 레벨을 넘어 인프라 프로비저닝까지 확장된 대표 사례로 소개된다.

Argo CD

Git 저장소에 선언된 상태를 기준으로 Kubernetes 클러스터의 실제 상태를 지속적으로 동기화하는 GitOps 배포 도구다.

왜 필요한가 — CRD/Operator로 정의한 리소스 변경 이력을 Git으로 추적하고, 배포를 코드 리뷰와 자동화된 파이프라인으로 관리하기 위해 사용한다.

발표에서는 — CRD 기반 리소스 관리와 결합되는 GitOps 도구로 함께 다뤄진다.

🧭 추구 방향과 흐름

  • 인프라의 코드화(Everything as Code) — CRD와 Operator를 통해 애플리케이션 운영 지식뿐 아니라 클라우드 인프라 프로비저닝까지 선언적 코드로 표현하는 흐름이 커지고 있다. Crossplane 같은 프로젝트가 이 방향을 잘 보여준다.
  • 운영 자동화와 셀프힐링 — Operator의 reconcile 루프는 사람의 개입 없이 시스템이 스스로 원하는 상태를 유지하도록 만든다. 이는 운영팀의 반복 작업을 줄이고 장애 대응 시간을 단축하는 방향으로 이어진다.
  • 플랫폼 엔지니어링과 GitOps의 결합 — CRD/Operator 기반 리소스를 Argo CD 같은 GitOps 도구와 결합해, 개발자가 Git PR만으로 인프라와 애플리케이션을 함께 요청·배포할 수 있는 셀프서비스 플랫폼을 지향하는 흐름이 나타난다.

🚀 바로 활용하기

  1. 로컬에 kind나 minikube로 클러스터를 띄우고 kubectl get crd로 기본 제공 CRD 목록을 확인해본다.
  2. Kubebuilder 공식 튜토리얼을 따라 간단한 Operator를 처음부터 만들어본다.
  3. Crossplane 공식 문서의 Getting Started를 통해 CRD로 클라우드 리소스를 선언해보는 실습을 해본다.
  4. Argo CD를 설치해 Git 저장소의 매니페스트가 클러스터에 자동 동기화되는 과정을 직접 경험해본다.

🔗 참고 자료

  • Kubernetes 공식 문서 — CRD와 Custom Controller 개념의 공식 설명을 확인할 수 있다.
  • Kubebuilder — Go로 Operator를 만드는 표준 프레임워크의 공식 가이드다.
  • Crossplane — CRD/Operator 패턴을 인프라 프로비저닝으로 확장한 프로젝트의 공식 사이트다.
  • Argo CD 공식 문서 — GitOps 기반 배포 동기화 도구의 공식 문서다.
  • CNCF — Operator 패턴과 관련 프로젝트들의 생태계 배경을 파악할 수 있다.