후기
CKA 취득 등을 통해 kubernetes에 입문한 이후, 잠시 다른 개발 업무에 전념하다가.... kubernetes 에 대해 업무상에서 좀 더 deep dive 해야되서 보게 된 책이다.
읽는 시점에는 golang 에 대해 경험이 없다보니, 책 내 Operator SDK 내 실습 소스 구조 등을 정확히 이해하지는 못했지만, 그래도 Operator가 어떤 역할을 하는지, 목적이 무엇인지, 어떻게 구현하는지 등에 대해 어느정도 이해할 수 있었던 책 인 것 같다.
주요 내용
Operator
- kubernetes 추상화 및 확장을 통해, 특정 상태가 있는 애플리케이션의 전체 라이프사이클 관리를 자동화
- kubernetes Application 에 대해 패키징과 실행 및 유지 관리하는 수단
- 클러스터에 소프트웨어를 배포하는 '일관된 방법' (애플리케이션 문제 식별하고 수정 등)
- Operator 는 'Software SRE' 이다. (즉, 오퍼레이터는 소프트웨에 '전문 관리자'의 기술을 인코딩)
Operator 작동방식
- kubernetes Control Plane 및 API 를 확장해서 동작
- 단순히 말하면 -> 'CR Resource'를 모니터링하고 유지 관리할 'Control Plane 구성요소'를 kubernetes 에 추가하는 것
Operator 범위
- (1) 네임스페이스 범위
- 대부분의 경우에 적합, 여러 팀에서 사용하는 클러스터에서 적합
- (2) 클러스터 범위
- 클러스터 전체 봐야 할때 (ex. istio, cert-manager)
- 이때 clusterrole 및 clusterRoleBinding 등 설정 부여 필요 (role, rolebinding 이 아닌)
Operator 를 만든다?
(1) CRD 를 작성하고, (2) 해당 종류의 CR을 모니터링하는 루프를 실행하는 프로그램 제공
오퍼레이터가 CR 의 변경에 따라 응답에 행하는 작업은, 오퍼레이터가 관리하는 애플리케이션에 맞춰 구성함
Operator 구축하기
일단 '최소한의 실행 가능한 제품'으로 시작하자
이후에 점차 다음 '라이프사이클 관리', '업그레이드 기능' 추가 .. 등 오퍼레이터를 확장하자
즉, 시간의 지남에 따라 애플리케이션의 '완벽하고 반복적인 자동화' 구축 (궁극적으로는 오토파일럿 수준까지!)
결론은 단순하게 시작해서 정교함 키워가기
Operator 성숙도 모델
"Operator Maturity Model"
(1단계)
- "기본 설치"
- 자동화된 애플리케이션 프로비저닝 및 구성 관리
(2단계)
- "원활한 (Seamless) 업그레이드"
- 패치 및 마이너 버전 업그레이드 지원
(3단계)
- "전체 라이프 사이클"
- 앱 라이프사이클, 스토리지 라이프 사이클 (백업, 복구, 실패)
(4단계)
- "깊은 통찰력"
- 메트릭, Alert, 로그처리, 워크로드 분석
(5단계)
- "오토파일럿"
- 수직,수평 스케일링, 자동구성 튜닝, 비정상 감지, 스케쥴 튜닝 등
Operator 구현 시 7가지 지침
(1) 오퍼레이터 자체는 1개의 Deployment(Manifest)로 실행되야 함
- (OLM Bundle 등 생성해도), OLM 은 여전히 단일 매니페스트 사용해 오퍼레이터 배포
(2) 오퍼레이터는 Cluster 에 새로운 사용자 정의 리소스(CR) 타입 정의 필요
- ex. etcd-operator => 'EtcdCluster' 정의
(3) 오퍼레이터는 가능할때마다, 적절하게 k8s 추상화 리소스 사용
- 유용하다고 알려진 오퍼레이터들의 경우 실질적으로 애플리케이션에 적합한 방식으로 '표준 리소스'들의 일부 세트 조작하는 것 이외에 거의 하지 않음
(4) 오퍼레이터 종료가 => 오퍼랜드 영향을 미쳐서는 X
- 오퍼레이터는 정지되어도, 애플리케이션(오퍼랜드)는 계속 동작되어야 함
- 단, CRD 제거 시에는 CR 인스턴스가 제거됨
(5) 오퍼레이터는 "이전 버전"에서 생성된 리소스 타입 지원 필요
- 이전 모델 구조와 역-호환 되어야 함
(6) 오퍼레이터 "애플리케이션 업그레이드" 에 대한 중재 필요
- 롤링 업그레이드 및 롤백 기능 포함해서 오퍼랜드의 업그레이드 중재 필요
- 업그레이드 자동화는 오퍼레이터의 이상적인 작업
(7) 오퍼레이터는 카오스 테스트를 포함하여 "철저한 테스트" 통과 필요
- 오퍼레이터 신뢰하기 위해서 테스트 스위트를 구축해서 철저한 테스트가 필요함
Operator SDK
오퍼레이터를 개발 및 배포 하기 위한 도구세트 (Go 언어 기반)
이외에 helm or Ansible 플레이북용 "어댑터 아키텍처"로도 지원
Adapter 기반의 Operator
Operator-SDK CLI 통해 => 오퍼레이터에서 'Helm' or 'Ansible' 같은 기술을, '실행하는데 필요한 코드' 생성할 수 있음즉, 필요한 오퍼레이터 코드를 일일히 작성할 필요 없이, Helm or Ansible 기반의 인프라를 => '오퍼레이터 모델'로 신속하게 마이그레이션 가능
GO Base Operator
Helm or Ansible Base의 Operator 의 경우, 결국에는 제약이 있음
더 복잡한 기술 등을 사용 하려면, 결국 Go 기반으로 오퍼레이터 구축 필요
구현 단계 요약
- kubernetes 연결코드, Operator 를 컨트롤러로 동작하게 필요하는 코드 생성
- 하나 이상의 CRD 작성해서, 애플리케이션 기본 비즈니스 로직을 모델로 생성 및 해당 모델과 상호작용 위한 API 제공
- 각 리소스의 라이프사이클 관리할 수 있도록, CRD 에 대한 컨트롤러 개발
- 오퍼레이터를 이미지로 만들고, "오퍼레이터와 관련 RBAC 구성요소"에 대한 배포를 위한 manifest 작성
OLM
OLM이 필요한 이유
- 오퍼레이터 개발 이후 '설치 및 관리' 는 어떻게?"
- 오퍼레이터 사용을 위한 Deployment, CRD 추가, 권한 구성 포함해서 여러 과정이 있고 -> 해당 과정 용이하게 하기 위한 "관리 계층"필요
- OLM 은 CRD 디스크립터 형태의 설치지침 및 API 힌트 포함해서,
오퍼레이터 딜리버리 하기 위한 패키징 방법과 호환 UI 에서 사용할 시각화를 위한 메타데이터 도입 등등의 기능 제공 - 관련 CRD 로 csv, catalogsource, subscription, installplan, operatorgroup 등이 있음
'Cloud > kubernetes (k8s)' 카테고리의 다른 글
| 쿠버네티스 :: GCP(VM)에 kubernetes Cluster 직접 구축하기 - 3 (23.01 수정) (3) | 2022.03.12 |
|---|---|
| 쿠버네티스 :: GCP(VM)에 kubernetes Cluster 직접 구축하기 - 2 (23.01 수정) (0) | 2022.03.12 |
| 쿠버네티스 :: GCP(VM)에 kubernetes Cluster 직접 구축하기 - 1 (1) | 2022.03.12 |