Kubernetes Operator를 작성할 때 피해야 할 Anti-patterns

🔁 1. Reconciliation Loop 남용 / 비효율적인 처리

• 문제: Reconcile 루프에서 너무 많은 로직을 처리하거나, 상태가 바뀌지 않아도 리소스를 계속 업데이트하거나, 외부 API를 호출하는 경우.
• 예시:
  • 매번 Deployment를 업데이트하여 rollout이 반복됨
  • 외부 DB나 API를 reconcile 루프마다 계속 호출
• 해결: 상태 변화가 있을 때만 필요한 작업을 수행하고, idempotent하게 구현.

---

📦 2. Status 필드 미사용 또는 오용

• 문제: CR의 .status 필드를 사용하지 않거나, 너무 많은 정보를 넣어서 상태 추적이 어려운 경우.
• 해결: 적절한 정보를 넣어 관찰 가능한 상태를 만들고, 컨트롤러는 이 상태를 기준으로 동작해야 함.

---

🧠 3. 컨트롤러가 너무 많은 책임을 가짐 (God Operator)

• 문제: 하나의 Operator가 너무 많은 리소스를 다루고 복잡한 로직을 모두 포함하는 경우.
• 해결: 역할을 분리하고, 가능한 한 단일 책임 원칙(SRP)을 따름.

---

🔄 4. Finalizer 미사용 또는 제거 실수

• 문제: CR이 삭제될 때 필요한 클린업 작업을 위해 finalizer를 등록하지 않거나, 수동으로 지워버려 리소스 누수 발생.
• 해결: 적절한 finalizer 설정 및 처리 로직 구현.

---

🚨 5. OwnerReference 잘못 설정

• 문제: CR이 소유하는 리소스에 OwnerReference를 잘못 지정하거나 누락해 GC가 제대로 동작하지 않음.
• 해결: 하위 리소스에 올바른 OwnerReference를 설정해 쿠버네티스 GC와 연동.

---

🔍 6. Event 기록 누락

• 문제: 사용자가 디버깅하거나 상태를 파악할 수 있도록 Event를 기록하지 않음.
• 해결: record.Eventf 등을 이용해 주요 이벤트를 기록.

---

⏱️ 7. rate limiting / exponential backoff 없이 재시도

• 문제: 에러 발생 시 재시도를 무한히 빠르게 하여 API 서버나 외부 시스템에 부하를 줌.
• 해결: controller-runtime에서 제공하는 RequeueAfter, rate limiting 기능 사용.

---

🧪 8. 테스트 부족

• 문제: 컨트롤러의 동작에 대한 유닛 테스트, 통합 테스트가 부족하여 변경 시 회귀 버그 발생.
• 해결: envtest, controller-runtime의 fake client 등을 활용한 테스트 작성.

---

🧩 9. Spec 변경 감지를 위한 annotation hack

• 문제: 리소스의 변화를 감지하기 위해 annotation에 hash 값을 기록하는 등의 hacky 방식 사용.
• 해결: 이런 방식이 필요한 경우도 있지만, 명확한 설계와 이유 없이 쓰는 건 유지보수에 안 좋음.

---

🛠️ 10. Custom Resource를 일반 Config처럼 사용

• 문제: CRD를 그냥 ConfigMap 대체로 쓰는 경우, controller 로직 없이 선언만 있는 상태가 됨.
• 해결: CRD는 선언한 Desired State와 Reconciler를 통해 관리되는 상태(stateful system)를 의미함.