오늘의 기술 토픽

Kubernetes Operators & CRDs

이번 글은 별도의 밋업 발표 없이 Kubernetes Operators와 CRD(Custom Resource Definition)를 중심으로 정리한 기술 브리프입니다. Kubernetes가 왜 CRD와 Operator 패턴을 통해 API를 확장 가능하게 설계했는지, 그리고 이 패턴이 어떻게 인프라 자동화 생태계 전반으로 퍼져나갔는지를 다룹니다. Kubebuilder, Crossplane 같은 관련 도구들이 이 패턴을 어떻게 구체화하는지도 함께 살펴봅니다.

🔑 핵심 요점

  • CRD는 Kubernetes API에 사용자 정의 리소스 타입을 추가하는 확장 메커니즘이다.
  • Operator는 CRD로 정의한 커스텀 리소스를 지속적으로 관찰하고 원하는 상태(desired state)로 수렴시키는 컨트롤러다.
  • Operator 패턴 덕분에 데이터베이스, 메시지 큐 같은 복잡한 애플리케이션의 운영 지식을 코드로 캡슐화할 수 있다.
  • Kubebuilder와 Operator SDK는 Go 기반으로 Operator를 빠르게 만들 수 있게 해주는 프레임워크다.
  • Crossplane은 Operator 패턴을 클라우드 인프라 프로비저닝까지 확장한 사례다.
  • reconcile loop 개념을 이해하면 Kubernetes 생태계의 대부분의 컨트롤러 동작 원리를 파악할 수 있다.

🛠 핵심 기술 쉽게 이해하기

Kubernetes Operators & CRDs

CRD는 Kubernetes API에 새로운 리소스 종류를 등록하는 방법이고, Operator는 이 커스텀 리소스를 감시하며 실제 상태를 원하는 상태로 맞춰주는 컨트롤러 프로그램이다. 둘을 합치면 Kubernetes 자체의 기본 오브젝트(Pod, Deployment 등)처럼 동작하는 새로운 도메인 전용 API를 만들 수 있다.

왜 필요한가 — 복잡한 애플리케이션이나 인프라의 운영 절차(설치, 백업, 장애 복구 등)를 사람이 수동으로 반복하지 않고 코드로 자동화하기 위해 사용한다.

발표에서는 — 이번 글에서는 CRD가 어떻게 API를 확장하고 Operator가 reconcile loop를 통해 상태를 맞추는지를 핵심 개념으로 다룬다.

Kubebuilder / Operator SDK

Kubebuilder와 Operator SDK는 CRD와 컨트롤러 코드를 빠르게 스캐폴딩해주는 개발 프레임워크다. controller-runtime 라이브러리를 기반으로 반복적인 보일러플레이트 코드를 자동 생성해준다.

왜 필요한가 — Operator를 처음부터 client-go로 직접 구현하려면 시간이 오래 걸리므로, 표준화된 구조로 개발 속도를 높이기 위해 사용한다.

발표에서는 — Operator 패턴을 실제로 구현할 때 사용하는 대표적인 도구로 언급된다.

Crossplane

Crossplane은 Operator 패턴을 클라우드 인프라(예: AWS RDS, GCP Bucket) 프로비저닝까지 확장한 오픈소스 프로젝트다. 클라우드 리소스를 Kubernetes 커스텀 리소스처럼 선언적으로 관리할 수 있게 해준다.

왜 필요한가 — Terraform 같은 별도 도구 없이 Kubernetes API 안에서 인프라와 애플리케이션을 통합 관리하기 위해 사용한다.

발표에서는 — Operator 패턴이 애플리케이션 운영을 넘어 인프라 계층까지 확장된 사례로 소개된다.

Custom Controllers (client-go / controller-runtime)

client-go와 controller-runtime은 Kubernetes API 서버와 통신하며 리소스 변화를 감지하고 reconcile 로직을 실행하는 저수준 Go 라이브러리다.

왜 필요한가 — Kubebuilder 같은 프레임워크 내부에서 실제로 Watch, Informer, Work queue 같은 핵심 동작을 담당하기 때문에 Operator 동작 원리를 깊이 이해하려면 필요하다.

발표에서는 — Operator의 reconcile loop가 내부적으로 어떤 라이브러리 위에서 동작하는지 설명하는 맥락에서 다뤄진다.

🧭 추구 방향과 흐름

  • 선언적 API로 확장되는 플랫폼 — Kubernetes는 CRD를 통해 코어 API를 건드리지 않고도 무한히 확장 가능한 구조를 지향한다. 이는 각 팀이 자신들의 도메인에 맞는 커스텀 리소스를 자유롭게 정의하고 플랫폼처럼 소비할 수 있게 만든다.
  • 운영 자동화(Day-2 Operations)의 코드화 — Operator 패턴은 백업, 스케일링, 장애 복구 같은 운영자의 암묵적 지식을 코드로 옮기는 흐름을 대표한다. 앞으로도 데이터베이스, 메시징 시스템 등 상태 저장(stateful) 워크로드 운영이 Operator 형태로 표준화될 가능성이 높다.
  • 인프라와 애플리케이션 관리의 통합 — Crossplane 사례처럼 클라우드 인프라 프로비저닝까지 Kubernetes API 안으로 흡수하려는 움직임이 커지고 있다. 이는 GitOps와 결합해 애플리케이션과 인프라를 하나의 선언적 파이프라인으로 관리하려는 방향으로 이어진다.

🚀 바로 활용하기

  1. 로컬 환경(kind 또는 minikube)에 Kubernetes 클러스터를 띄우고 kubectl로 기본 CRD 예제를 만들어본다.
  2. Kubebuilder 공식 튜토리얼을 따라 간단한 Operator를 처음부터 끝까지 구현해본다.
  3. Crossplane 공식 문서의 Getting Started 가이드를 보고 클라우드 리소스를 Kubernetes 리소스처럼 선언해본다.
  4. reconcile loop 개념이 익숙하지 않다면 Kubernetes 공식 문서의 Controller 개념 문서를 먼저 읽는다.

🔗 참고 자료