뭔가를 띄우는 게 문제가 아니라 운영하다가 장애가 났을 때 빠르게 대처하는 게 더 큰 문제가 아닌가? 그런 까닭에 문제를 추상화는 Operator 에 부정적이었다. 그러나 돌이켜보면 추상화 수준이야 어떻든 충분히 테스트하고 운영환경에 내보내면 문제가 없지 않았을까? 로그만 잘 남으면 소스코드를 분석해서 깊게 들여다 보는데도 문제 없을 것 같다. 다만 Operator가 실질적으로 운영비용과 학습곡선을 줄여주는지는 여전히 의문이다. 그래도 시도해볼 순 있겠지.
관심가는 Operators
- Airflow : 자체운영보다 비용효율적일까?
- AquaSecurity : 보안은 항상 새로운 시도를 해보려 한다.
- aws-service-operator : 보안 체계를 개선하는데 도움이 될까?
- Cassandra: Cassandra를 운영하는 조직이 관심을 보일까?
- Cert-manager: 모임의 K8s 클러스터에서 잘 활용하고 있다.
- elastic : 자체운영보다 비용효율적일까?
- external secret operator : 보안 체계를 개선하는데 도움이 될까?
- gatekeeper : 보안 체계를 개선하는데 도움이 될까?
- kafka : 자체 운영용 레시피가 워낙 잘 되어 있어 관심이 덜 간다.
- Percona : 근래에 Percona를 쓸 기회가 없어 이런 Operator 가 있는 줄 몰랐다.
- Redis : Sentinel 지원을 잘 하는게 있을까? 항상 완성도가 문제이다.
- Rook : 모임의 K8s 클러스터에서 잘 활용하고 있다.
- Shell operator : Event 발생시 이것저것 하고 싶을 때 쓸만해 보인다. 이 Operator의 제작자인 Flant는 러시아에서 K8s 사업을 하는 것 같다. 그런 까닭인지 GitHub에 재미난 도구를 여럿 공개했다.
리뷰
spotahome/redis-operator 의 초기 테스트 결과는 매우 훌륭하다.
Author Details
Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.