MSFL :: 모리스 소프트웨어 공작소

How to use Operator tools on Kubernetes 지난 게시글인 Kubernetes상의 Operator 나름대로 정리 에 이어서 Operator 구현하는 툴들에 대해 정리한다. Kubernetes를 Operators 관점에서 보면... Orchestrate stateful applications using K8s API Extend API using Custom Resource Definitions Encode domain specific operational knowledge Upgrades Failure and Recovery Scenarios Scaling up / down Purpose built per application Kubernetes is an Operations API 여러 상황들 검토 Kubernetes에 애플리케이션을 배포하는 것은 다양한 형태로 제공된다. 배치 패러다임, YAML 템플릿처리, IaC (Instrastructure as Code) Tooling (ansible, terraform), Controller 등에 대해서 검토한다. IaC IaC 툴들은 애플리케이션과 클라우드 인프라를 관리하는데 도움이 된다. 개발자는 이 툴들을 통해서 Kubernetes의 리소스들을 관리할 수 있다. 사용자는 이 툴들을 설치 및 유지보수 도구로 활용할 수 있다. 대표적인 것이 Ansible 과 Terraform 등이며, 다른 툴들도 많이 존재한다. 이 툴들은 가상머신이나 애플리케이션을 배포하는데 종종 사용되며 이런 자원들을 설명하는데 cattle (소 떼) vs. Pets (반려동물) 패턴을 사용한다. 소 떼는 교체가 쉽고 상태가 중요하지 않은 구성 요소들을 의미하고 주로 웹 서비스, APIs, Jobs 등을 의미한다. 반려동물은 데이터베이스를 포함해 교체나 갱신이 어려운 구성 요소들을 의미한다. IaC 툴들은 위의 두 가지 유형의 애플리케이션을 비슷하게 다루기 때문에 설치한 이후의

What is the Operator on Kubernetes 기본 전제 및 용어 정리 Kubernetes는 선언적 상태관리 시스템이다. Operator란 Kubernetes 애플리케이션을 패키징, 배포, 관리하는 방법론이다. (운영자 관점) Operator Pattern은 Kuberentes에서 Operator 방법론을 적용해서 확장하는 패턴이다. (확장 개발 관점) Oeprator Framework은 Kubernetes에서 Operator를 실제 구현과 관리를 지원하는 Framework이다. (실 구현 관점) CRD (Custom Resource Definition)은 Operator로 사용할 상태 관리용 객체들의 Spec을 정의한다. (Schema 관점) CR (Custom Resource)은 CRD의 Spec을 지키는 객체들의 실제 상태 데이터 조합이다. (Desired State 관점) CC (Custom Controller)는 CR의 상태를 기준으로 현재의 상태를 규정한 상태로 처리하기 위한 컨트롤 루프다. (Current State 관점) Let's take a look at the conclusion. Operator는 운영자 주로 하는 작업들을 묶어서 자동화하는 것이 목표 이며 다음과 같이 동작하게 된다. 운영자의 입장에서 관리할 대상에 대한 규정 (Spec)을 정의하고 Kubernetes에 등록한다. (Kubernetes의 CRD로 생성) 관리할 대상이 유지해야 할 상태 정보를 규정에 맞도록 지정하고 Kubernetes에 등록한다. (Kubernetes의 CR 객체로 생성 - 상태 데이터로서 ETCD에 저장관리) 상태 유지를 위한 컨트롤러를 구성해서 Kuberentes에 등록 (Kubernetes의 CC로 생성 - 원하는 상태 유지 작업) CRD 방식을 사용하면 일반적인 Kubernetes 사용법 (kubectl - API Server)으로 운용이 가능하며 CRD로 등록된 리소스 객체를 그대로 사용

What is KUDO (Kubernetes Universal Declarative Operator - Kudobuilder) 정의 KUDO는 Operator를 위한 Oeprator 선언적 접근 방식을 제공해 애플리케이션의 전체 라이프사이클을 커버하는 범용 오퍼레이터 대부분의 경우는 YAML 만을 사용할 수 있는 정도로 쉽게 Kubernetes Operator를 만들 수 있는 툴 킷 + 런타임 라이프사이클 Operator들 간의 공통화 및 재 사용성 복잡한 상태 저장 애플리케이션에 최적화 Operator 구축시 개발자의 생산성 향상 서비스 운영시 운영자의 생산성 향상 기본 제공되는 리파지토리의 여러 Operator들 중 에서 고르거나 쉽게 커스터마이징이 가능하다. 표준화된 방식으로 Operatators가 동작할 수 있도록 한다. KUDO는 범용적이고 선언적인 접근 방식 (UD - Universal and Declarative) 을 취하기 때문에 어떠한 코드를 사용하지 않고 오퍼레이터를 구성할 수 있도록 지원한다. Developer 측면 개념적으로 "runbooks"와 유사하게 Kubernetes 객체들과 "Plans"를 이용해서 라이프사이클 운영 시퀀스에 대한 추상화 제공 라이프사이클 작업들 간의 공통성과 재 사용성 작업들 간의 코드 중복과 재사용 가능한 Boilerplate 감소 사용자 환경에 맞춤화를 위한 기본 Operator의 "Flavor"를 생성하는 매커님즘 제공 소프트웨어와 Day 2 운영 모범사례를 제공할 수 있는 도구들을 ISV들에 제공 Kubernetes 리소스의 TDD 활성화를 위한 테스트 툴 제공 User 측면 워크로드들을 배포하고, 관리하고 디버깅할 수 있는 kubectl kudo 플러그인 제공 KUDO는 작은 Kubernetes로 kubectl 사용 지원 - KUDO is Kubernets! (단, KUDO 역시 CRD로 정의

How to use KUDO CLI Commands KUDO 및 Package 관리를 위한 KUDO CLI를 정리한다. Global Flags Global Flags : 전체 명령들에 사용할 수 있는 전역 옵션들 --home <path> : Kudo 설정이 있는 Home Directory 지정 (Default: "~/.kudo") --kubeconfig <path> : Kubernetes 설정이 있는 Home Directory 지정 (Default: "~/.kube/config") -n, --namespace <namespace> : 객체를 처리할 대상 Namespace (Default: "Default") --request-timeout <seconds> : 요청 시간 제한을 초단위로 지정 (Default: 0 - 무제한) -v <line count>, --v : 상세 로그 수준을 라인단위로 지정 --validate-install : 명령을 실행하기 전에 KUDO 설치 여부 검증 (Default: true) Semi-Global Flags : 전체 명령들은 아니지만 많은 명령들에 사용할 수 있는 옵션들 --help : 모든 명령에 지정 가능하며, 해당 명령의 상세 정보 출력 -o, --output : 많은 명령들이 지원하며, "Yaml" 또는 "Json" 방식으로 출력 가능 --dry-run : 실제 실행하지는 않고, 점검과 준비만 처리하며, --output 옵션으로 대상 리소스에 대한 출력물 생성 init KUDO Server와 Client 컴포넌트의 초기화 및 업그레이드 처리 kubectl kudo init [options] 옵션들은 설치 및 업그레이드에 대한 변경을 위한 것으로 주로 Server를 대상으로 하며 저장되지 않기 때문에 매번 제공해야