2장. Operator 이해
2.1. Operator란 무엇인가?
개념적으로 Operator는 사람의 운영 지식을 소비자와 더 쉽게 공유할 수 있는 소프트웨어로 인코딩합니다.
Operator는 다른 소프트웨어를 실행하는 데 따르는 운영의 복잡성을 완화해주는 소프트웨어입니다. 소프트웨어 벤더 엔지니어링 팀의 확장, Kubernetes 환경(예: OpenShift Dedicated)을 모니터링하고 현재 상태를 사용하여 실시간으로 의사 결정을 내립니다. 고급 Operator는 업그레이드를 원활하게 처리하고 오류에 자동으로 대응하며 시간을 절약하기 위해 소프트웨어 백업 프로세스를 생략하는 등의 바로 가기를 실행하지 않습니다.
Operator는 Kubernetes 애플리케이션을 패키징, 배포, 관리하는 메서드입니다.
Kubernetes 애플리케이션은 Kubernetes API 및 kubectl 또는 oc 툴링을 사용하여 Kubernetes API에 배포하고 관리하는 앱입니다. Kubernetes를 최대한 활용하기 위해서는 Kubernetes에서 실행되는 앱을 제공하고 관리하기 위해 확장할 응집력 있는 일련의 API가 필요합니다. Operator는 Kubernetes에서 이러한 유형의 앱을 관리하는 런타임으로 생각할 수 있습니다.
2.1.1. Operator를 사용하는 이유는 무엇입니까?
Operator는 다음과 같은 기능을 제공합니다.
- 반복된 설치 및 업그레이드.
- 모든 시스템 구성 요소에 대한 지속적인 상태 점검.
- OpenShift 구성 요소 및 ISV 콘텐츠에 대한 OTA(Over-The-Air) 업데이트
- 필드 엔지니어의 지식을 캡슐화하여 한두 명이 아닌 모든 사용자에게 전파.
- Kubernetes에 배포하는 이유는 무엇입니까?
- Kubernetes (및 확장에 따라 OpenShift Dedicated)에는 시크릿 처리, 로드 밸런싱, 서비스 검색, 자동 스케일링 - 온프레미스 및 클라우드 공급자 전체에서 작동하는 복잡한 분산 시스템을 빌드하는 데 필요한 모든 기본 기능이 포함되어 있습니다.
- Kubernetes API 및
kubectl툴링으로 앱을 관리하는 이유는 무엇입니까? -
이러한 API는 기능이 다양하고 모든 플랫폼에 대한 클라이언트가 있으며 클러스터의 액세스 제어/감사에 연결됩니다. Operator는 Kubernetes 확장 메커니즘인 CRD(사용자 정의 리소스 정의)를 사용하므로 사용자 정의 오브젝트(예:
MongoDB)가 기본 제공되는 네이티브 Kubernetes 오브젝트처럼 보이고 작동합니다. - Operator는 서비스 브로커와 어떻게 다릅니까?
- 서비스 브로커는 앱의 프로그래밍 방식 검색 및 배포를 위한 단계입니다. 그러나 오래 실행되는 프로세스가 아니므로 업그레이드, 장애 조치 또는 스케일링과 같은 2일 차 작업을 실행할 수 없습니다. 튜닝할 수 있는 항목에 대한 사용자 정의 및 매개변수화는 설치 시 제공되지만 Operator는 클러스터의 현재 상태를 지속적으로 관찰합니다. 클러스터 외부 서비스는 서비스 브로커에 적합하지만 해당 서비스를 위한 Operator도 있습니다.
2.1.2. Operator 프레임워크
Operator 프레임워크는 위에서 설명한 고객 경험을 제공하는 툴 및 기능 제품군입니다. 코드를 작성하는 데 그치지 않고 Operator를 테스트, 제공, 업데이트하는 것이 중요합니다. Operator 프레임워크 구성 요소는 이러한 문제를 해결하는 오픈 소스 툴로 구성됩니다.
- Operator SDK
- Operator SDK는 Operator 작성자가 Kubernetes API 복잡성에 대한 지식이 없어도 전문 지식을 기반으로 자체 Operator를 부트스트랩, 빌드, 테스트, 패키지할 수 있도록 지원합니다.
- Operator Lifecycle Manager
- OLM(Operator Lifecycle Manager)은 클러스터에서 Operator의 설치, 업그레이드, RBAC(역할 기반 액세스 제어)를 제어합니다. 기본적으로 OpenShift Dedicated 4에 배포됩니다.
- Operator 레지스트리
- Operator 레지스트리는 CSV(클러스터 서비스 버전) 및 CRD(사용자 정의 리소스 정의)를 클러스터에 생성하기 위해 저장하고 패키지 및 채널에 대한 Operator 메타데이터를 저장합니다. 이 Operator 카탈로그 데이터를 OLM에 제공하기 위해 Kubernetes 또는 OpenShift 클러스터에서 실행됩니다.
- OperatorHub
- OperatorHub는 클러스터 관리자가 클러스터에 설치할 Operator를 검색하고 선택할 수 있는 웹 콘솔입니다. 기본적으로 OpenShift Dedicated에 배포됩니다.
이러한 툴은 구성 가능하도록 설계되어 있어 유용한 툴을 모두 사용할 수 있습니다.
2.1.3. Operator 완성 모델
Operator 내에 캡슐화된 관리 논리의 세분화 수준은 다를 수 있습니다. 이 논리는 일반적으로 Operator에서 표시하는 서비스 유형에 따라 크게 달라집니다.
그러나 대부분의 Operator에 포함될 수 있는 특정 기능 세트의 경우 캡슐화된 Operator 작업의 완성 정도를 일반화할 수 있습니다. 이를 위해 다음 Operator 완성 모델에서는 Operator의 일반적인 2일 차 작업에 대해 5단계의 완성도를 정의합니다.
그림 2.1. Operator 완성 모델
또한 위 모델은 Operator SDK의 Helm, Go, Ansible 기능을 통해 이러한 기능을 가장 잘 개발할 수 있는 방법을 보여줍니다.
