기본 콘텐츠로 건너뛰기

[Kubernetes - Operator] KUDO 설치 및 간단한 사용법 검증

How to use KUDO

당연한 것이지만 KUDO를 테스트하기 위해서는 Kubernetes Cluster가 존재해야 한다. Kind 와 Minikube를 사용할 수 있다.

참고

  • Minikube
    Minikue를 통해 KUDO를 로컬에서 개발하고 테스트하기 위해서는 적절한 양의 메모리가 필요한데 Minikube는 2G 메모리를 기준으로 하는데 Kafka의 경우는 최소 10GB를 권장하므로 로컬에서 메모리를 구성하기는 좀 힘들다. 그러나 가능한 리소스가 존재한다면 아래와 같이 기본적인 설정을 바꿔 실행이 가능하다.
    $ minikube start --cpus=4 --memory=10240 --disk-size=40g
  • Kind
    KIND를 storage operator와 같이 사용하기 위해서는 KIND v0.7.0 이상을 사용해야 한다.
  • Cert-Manager
    cert-manager 의존성을 테스트 환경에서 제외할 경우는 KUDO를 보안이 되지 않는 상황으로 자체 서명된 CA 번들을 사용하도록 초기화할 수 있다.
    $ kubectl kudo init --unsafe-self-signed-webhook-ca
    이와 관련된 개발을 위해서 Blog post를 참고하는 것이 좋다.

Install KUDO CLI

KUDO CLI는 kubectl에 KUDO 기능을 제공하는 플러그인이다.

CLI 바이너리를 Release Page에서 다운로드해서 설치가 가능하다. 맥인 경우는 brew를 통해서 설치가 가능하다.

$ brew tap kudobuilder/tap
$ brew instll kudo-cli

참고

맥 OSX에서는 명령 사용을 명시적으로 허가해야 할 수도 있으므로 Apple support site를 참고하도록 한다.

다른 방식은 kubectl 플러그인들을 위한 패키지 매니저인 krew를 이용하는 것이다. KREW란 무엇일까? 문서를 참고한다.

$ kubectl krew install kudo

그외는 최신 릴리즈에서 플랫폼과 OS에 따라서 바이너리를 다운로드하고 실행가능한 상태로 전환하고 Path에 추가하면 된다.

$ VERSION=x.y.z # look up the current stable release at https://github.com/kudobuilder/kudo/releases/latest
$ OS=$(uname | tr '[:upper:]' '[:lower:]')
$ ARCH=$(uname -m)
$ wget -O kubectl-kudo https://github.com/kudobuilder/kudo/releases/download/v${VERSION}/kubectl-kudo_${VERSION}_${OS}_${ARCH}
$ chmod +x kubectl-kudo
# add to your path
$ sudo mv kubectl-kudo /usr/local/bin/kubectl-kudo

Manage KUDO on Cluster

KUDO는 Cluster 내부에 설치되는 컴포넌트이기 떄문에 KUDO CLI를 통해서 초기화(설치) 및 관리 (Upgrade/Delete)를 할 수 있다.

Requirement

Install KUDO into Cluster

$ kubectl kudo init

자체 인증서와 시간 설정 추가


$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait


$KUDO_HOME has been configured at /home/centos/.kudo
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
✅ installed crds
✅ installed namespace
✅ installed service account
Warning: admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 MutatingWebhookConfiguration
✅ installed webhook
✅ installed kudo controller
⌛Waiting for KUDO controller to be ready in your cluster…
✅ KUDO is ready!

이 명령은 KUDO가 동작하는데 필요한 Controller 배포, Webhook 및 기타 모든 컴포넌트들을 설치한다. 만일 기존에 설치된 KUDO가 존재하는 경우는 우발적인 업그레이드가 발생하지 않도록 중단된다. KUDO 초기화에 필요한 명령의 자세한 옵션들은 init command를 참고한다.

참고

수동 설치 또는 다른 설정등의 작업을 해서 처리할 경우는 아래와 같이 처리도 가능하다.

$ kubectl kudo init --dry-run -o=yaml > kudo.yaml
$ kubectl apply -f kudo.yaml

KUDO init 명령은 Kubernetes에 처리할 명령을 전달하고 종료되기 때문에 실제 클러스터 내부에 필요한 리소스들이 성공적으로 실행되고 있는지를 확인하지 않는다. 따라서 --wait-timeout 옵션으로 300초 정도 지연을 걸어서 KUDO 관련 리소스들이 구성될 시간을 주는 것이 좋다.

KUDO가 정상적으로 동작하고 있는지는 kudo-controller-manager-0 파드가 정상적으로 실행되고 있는지를 확인하면 된다.

$ kubectl get -n kudo-system pod

NAME                        READY   STATUS    RESTARTS   AGE
kudo-controller-manager-0   1/1     Running   0          11m

KUDO 관련 리소스들은 아래와 같이 확인할 수 있다.

$ kubectl api-resources --api-group kudo.dev

NAME               SHORTNAMES   APIGROUP   NAMESPACED   KIND
instances                       kudo.dev   true         Instance
operators                       kudo.dev   true         Operator
operatorversions                kudo.dev   true         OperatorVersion

KUDO Upgrades

KUDO 업그레이드는 KUDO 초기화 명령을 그대로 사용하며, --upgrade 옵션을 추가하는 것이다. 기존 초기화에 사용했던 옵션들을 똑같이 지정해 줘야 한다. 그렇지 않으면 KUDO의 기존 초기화 정보를 올바르게 감지하지 못하고 업그레이드가 중단된다.

예를 들어 아래와 같이 설치를 했다면 

$ kubectl kudo init --namespace kudo-custom --service-account my-kudo-sa

업그레이드는 위의 명령에 --upgrade 옵션만 추가하는 형식이 되어야 한다.

$ kubectl kudo init --upgrade --namespace kudo-custom --service-account my-kudo-sa

주된 옵션들은 다음과 같다.

  • --namespace
  • --service-account
  • --unsafe-self-signed-ca

KUDO Uninstall

현재 Uninstall은 명령이 통합되어 있지 않기 때문에 아래와 같이 처리해야 한다.

$ kubectl kudo init --unsafe-self-signed-webhook-ca --upgrade --dry-run --output yaml | kubectl delete -f -

위 명령을 통해서 설치된 모든 KUDO CRDs 와 Deployments 등의 리소스들이 클러스터에서 삭제된다.

주의

  • init --upgrade 명령을 사용하는 것이기 때문에 init 명령에 지정한 옵션을 동일하게 지정해야 한다.
  • 이 명령은 설치된 모든 Operator들을 삭제한다. 따라서 실행 이전에 검토를 해야 한다.

How to Debug KUDO

현재 별도로 제공하는 Debugging은 없고 log 파일을 확인하는 것이 어떤 일이 발생했는지를 파악하는 가장 좋은 방법이다.

kubectl logs -n kudo-system kudo-controller-master-0

How to Create an Operator from Scratch

KUDO CLI를 이용해서 KUDO Operator 구조를 생성하고 Operator를 생성하는 단계별 내용을 확인한다.

  1. Create the Core Operator Structure

    # create operator folder
$ mkdir first-operator
$ cd first-operator

    $ kubectl kudo package new first-operator -i -w -v 100 --validate-install
    

    Operator Name: first-operator
Operator directory: operator
Operator Version: 0.1.0
m: 0.1.0
Application Version: 0.1.0
Required KUDO Version: 0.17.2
Required Kubernetes Version: 0.16.0
Project URL:
Maintainer Name: ccambo
Maintainer Email: ccambo@gmail.com

    생성된 Operator 패키지 구조는 tree . 명령으로 확인할 수 있다.

    $ tree .

    .
└── operator
├── operator.yaml
└── params.yaml
    

    1 directory, 2 files

    참고

    • -i : 사용자가 직접 입력할 수 있도록 프롬프트를 나타내는 옵션
    • -w : 이미 존재하는 디렉터리와 파일을 overwrite 하는 옵션
    • -v 100 : verbose log로 100줄 출력 옵션
    • --validate-install : 설치할 때를 가정해서 검증하는 옵션

    생성된 기본 Operator.yaml의 내용은 아래와 같다.

    apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
  name: ccambo
name: first-operator
operatorVersion: 0.1.0
plans:
  deploy:
    phases:
    - name: deploy
      steps:
      - name: deploy
        tasks:
        - deploy
      strategy: serial
    strategy: serial
tasks:
- kind: Apply
  name: deploy
  spec: {}

참고

기본적으로 deploy plan 과 Apply 형식의 deploy task 가 기본 생성되어 있다. 이 부분이 아래의 내용을 처리하면서 기존에 존재하는 것을 갱신하는 명령이 없기 때문에 충돌 문제를 발생시키므로 처음에 삭제를 하고 시작하는 것이 좋다. (현재 CLI 버전과 문서의 내용이 일치하지 않는다)
따라서 아래와 같이 operator/operator.yaml 파일의 내용을 다음과 같이 처리하도록 한다.

apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
  name: ccambo
name: first-operator
operatorVersion: 0.1.0
plans:{}
tasks:[]

  1. Add a Maintainer

    위 단계에서 -i 옵션으로 지정했으면 처리할 필요가 없지만, 여러 사람들을 등록할 경우라면 추가할 수 있다.

    $ kubectl kudo package add maintainer "" ""

  2. Add a Task

    이 명령은 Operator의 실제 작업 단위인 Task를 추가하는 것이다.

    kubectl kudo package add task -i -v 100 --validate-install
folder walking through directory operator
folder walking through directory templates
Task Name: app
✔ Apply
Task Resource: deployment
✗ Add another Resource: 
folder walking through directory operator
folder walking through directory templates

  3. Add a Plan

    이 명령은 Operator가 처리될 떄 작업할 Plan을 추가하는 것이다.

    $ kubectl kudo package add plan -i -v 100 --validate-install
folder walking through directory operator
folder walking through directory templates
folder walking through directory operator
folder walking through directory templates
Plan Name: deploy
✔ serial
Phase 1 name: main
✔ parallel
Step 1 name: everything
✔ app
✗ Add another Task: 
✗ Add another Step: 
✗ Add another Phase: 
folder walking through directory operator
folder walking through directory templates

    Plan > Phase > Step > Task 순으로 지정되며, Task, Step, Phase는 여러 개를 지정할 수 있고, Plan, Phase는 순차처리 (Serial) 또는 병행처리 (Parallel) 를 선택해서 지정할 수 있다.
    여기서는 app Task를 deploy plan > main phase > everyting step 에 설정하는 단순한 샘플로 처리한 것이다.

    여기까지 구성된 전체 Operator.yaml의 내용은 다음과 같다.

    apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
  name: ccambo
name: first-operator
operatorVersion: 0.1.0
plans:
  deploy:
    phases:
    - name: main
      steps:
      - name: everything
        tasks:
        - app
      strategy: parallel
    strategy: serial
tasks:
- kind: Apply
  name: app
  spec:
    resources:
    - deployment.yaml

  4. Add a Parameter

    이 명령은 Operator가 동작할 때 제공할 Parameter 정보를 지정하는 것으로 정의는 operator/params.yaml 로 저장되고, 이 파라미터를 사용하는 곳은 operator/tempates/ 디렉터리 밑에 추가할 리소스 파일에서 사용하는 방식이다.

    $ kubectl kudo package add parameter -i -v 100 --validate-install
folder walking through directory operator
folder walking through directory templates
folder walking through directory operator
folder walking through directory templates
Parameter Name: replicas
Default Value: 2
Display Name: Replicas
✔ Display Name: Replicas
✔ Description: Number of replicas that should be run as part of the deployment
✔ false
✗ Add Trigger Plan (defaults to deploy): 
folder walking through directory operator
folder walking through directory templates

    Add Trigger Plan (defaults to deploy)는 파라미터가 변경되었을 때 호출된 plan을 지정하는 것으로 설정하지 않아도 기본적으로 deploy plan이 동작한다는 의미이며, 다른 plan을 지정할 경우는 plan 이름을 명기하면 된다.

    실제 파라미터 정보는 아래와 같이 operator/params.yaml 파일에 추가된다.

    apiVersion: kudo.dev/v1beta1
parameters:
- default: "2"
  description: Number of replicas that should be run as part of the deployment
  displayName: Replicas
  name: replicas

  5. Add Resource Templates

    지금까지의 작업을 통해서 첫 번째 Operator를 생성했다. 하지만 실제 사용할 Deploy Task에 지정된 deployment 리소스를 구성해야 하는 작업이 남았다. templates/deployment.yaml 파일을 생성하고 아래와 같이 실제 작업을 지정해 줘야 한다.

    cat << EOF > operator/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: {{ .Params.replicas }}
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80
EOF

    위의 내용에서 보이는 {{ .Params.replicas }} 는 .Params 는 실제 operator/params.yaml 파일의 내용을 의미하고, .replicas는 정의된 파라미터를 의미하는 것이다.

지금까지의 작업으로 완전히 동작할 수 있는 아주 간단한 첫 번쨰 Operator를 구성했다.

How to Package a KUDO Operator

KUDO를 통해서 (정확히는 KUDO Operator) Operator 패키지를 배포하기 위해서는 tarball로 패키징을 해야 한다. KUDO CLI는 패키지 구성에 대한 검증을 포함해서 패키지를 만들 수 있다.

  1. Packing operator

    이 작업은 구성한 Operator를 실제 KUDO에 설치하기 위한 Package로 생성하는 부분으로 Local Repository Directory를 구성하고 Tarball을 생성하는 작업이다.

    $ rm -rf ~/kudo_sample/repo
$ mkdir -p ~/kudo_sample/repo

    상대적인 경로를 사용한다. 이 명령은 first-operator 디렉터리에서 실행한 것이다.
    

    $ kubectl kudo package create ~/kudo_sample/first-operator/operator/ --destination=~/kudo_sample/repo -w -v 100 --validate-install
folder walking through directory operator
folder walking through directory templates
package is valid
folder walking through directory operator
folder walking through directory templates
Package created: /home/centos/kudo_sample/repo/first-operator-0.1.0_0.1.0.tgz

    주의

    실제 Packaging 되는 대상은 operator 디렉토리에 있는 operator.yaml, params.yaml, templates/* 만 등록되어야 한다. 따라서 Operator 대상 폴더를 잘 지정해 줘야 한다.
    현재 경로를 기준으로 ./operator/ 로 지정하면 이상하게 operator/operator.yaml, operator/params.yaml, operator/templates/* 로 처리되어 Package에 대한 index를 생성할 때 Invalid 오류가 발생하게 된다.
    생성된 후에 vim을 이용해서 tarball 이 제대로 생성되었는지 확인이 필요하다.

  2. Check the builted package

    로컬 repo 디렉터리인 ~/kudo_sample/repo를 확인하면 생성된 패키지를 볼 수 있다.

    $ ls ~/kudo_sample/repo
first-operator-0.1.0_0.1.0.tgz

How to Add an Operator to a Repository

리포지토리에 Operator를 추가하는 아주 간단한 방법을 살펴본다. 예제로는 Community라는 리포지토리를 사용하며 관리 권한이 있어야 한다.

  • 리포지토리를 서비스할 수 있는 read/write 권한을 가지는 웹 기반 서버가 필요하다.
  • 위에서 만든 first-operator가 존재하는 로컬 ~/kudo_sample/repo 경로를 사용한다.

  1. Check repository

    설치된 KUDO가 기본적으로 바라보고 있는 리포지토리를 확인한다.

    $ kubectl kudo repo list

    NAME            URL
    
*community      https://kudo-repository.storage.googleapis.com/v1

    NAME 앞에 * 표시는 기본 리포지토리임을 나타낸다.

  2. Build an index file

    $ kubectl kudo repo index --merge-repo community --url-repo community -w -v 100 --validate-install ~/kudo_sample/repo 
repo configs: { name:community, url:https://kudo-repository.storage.googleapis.com/v1 }

    WARNING: operator: /home/centos/kudo_sample/repo/first-operator-0.1.0_0.1.0.tgz is invalid     ### 이 경우가 제대로 폴더구조가 생성되지 않았을 떄 발생하는 오류 indexing 처리되지 않는다.
repo configs:
    

    index /home/centos/kudo_sample/repo/index.yaml created.

    참고

    Operator Invalid 상태가 되면 대 부분 tarball의 내용이 잘 못되어 있기 때문에 Package를 create될 때는 처리 상의 문제가 없으면 valid 상태로 나타난다. 생성된 index.yaml을 열어 보면 누락된 것을 확인할 수 잆다.

위의 작업은 KUDO 가 바라보고 있는 Community 리포지토리에서 index.yaml 파일을 다운로드해서 ~/kudo_sample/repo 폴더에 존재하는 Operator들을 Index.yaml 파일에 추가(머지)하는 것이다. 이때 사용할 URL은 Community URL을 그대로 사용하고 있는 것을 확인할 수 있다.

이제 ~/kudo_sample/repo의 모든 내용을 Community 리포지토리에 upload 하면 된다. 그러나 Community URL에 우리가 작성한 Operator를 등록할 수는 없으니 다음 내용과 같이 웹 서버로 구성된 곳의 URL을 사용하는 것으로 처리하면 된다.

How to host an Operator in a Local Repository

참고

이 글은 테스트용으로 정리된 것이기 때문에 실제 호스팅 가능한 웹 서버를 구축한 것이 아니고, 단순히 ~/kudo_sample/repo 디렉터리를 올려서 테스트하기 위한 용도로 python3의 http server 기능을 사용한다.

  1. local repository 폴더에 index 파일 생성

    이 작업은 작성한 Operator에 대한 index.yaml 파일을 생성해서 설치할 때 Operator를 식별하는 인덱스처럼 활용하기 위한 것이다.

    현재 작업은 http://localhost:8090으로 할 것이기 때문에 이 옵션을 줘야 한다. (생략하면 http://localhost:80 인 것으로 설정된다.)

    $ kubectl kudo repo index -w -v 100 --validate-install --url http://localhost:8090 ~/kudo_sample/repo 
WARNING: operator: /home/centos/kudo_sample/repo/first-operator-0.1.0_0.1.0.tgz is invalid   ### 이 경우가 제대로 폴더구조가 생성되지 않았을 떄 발생하는 오류 indexing 처리되지 않는다.
index /home/centos/kudo_sample/repo/index.yaml created.

    주의

    Opeartor Invalid 오류가 발생하면 Packaging 처리부터 경로를 잘 지정하고 다시 작업해야 한다.

    index.yaml 파일에 생성된 결과는 다음과 같다. 

    apiVersion: v1
entries:
  first-operator:
  - appVersion: 0.1.0
    digest: 3360ca9dd47d885982aac2972b170e576eeb54aa82f46302c1b409602475fa50
    maintainers:
    - email: ccambo@gmail.com
      name: ccambo
    name: first-operator
    operatorVersion: 0.1.0
    urls:
    - http://localhost/first-operator-0.1.0_0.1.0.tgz

  2. HTTP Server 실행

    $ cd ~/kudo_sample/repo

    $ python3 -m http.server 8090
    
Serving HTTP on 0.0.0.0 port 8090 (http://0.0.0.0:8090/) …

  3. local repository를 kudo client에 등록

    이 작업은 내부에서 운영 중인 (이 문서에서는 로컬 머신에서 운영되는) http server를 KUDO Client에 등록해서 인식시키는 작업이다.

    $ kubectl kudo repo add -v 10 --validate-install local http://localhost:8090
repo configs: { name:community, url:https://kudo-repository.storage.googleapis.com/v1 }

    “local” has been added to your repositories

    설치가 제대로 되었는지는 아래의 명령으로 확인 가능하다.

    $ kubectl kudo repo list
NAME            URL                                              
*community      https://kudo-repository.storage.googleapis.com/v1
local           http://localhost:8090

    참고

    이미 생성된 Repository를 갱신하는 기능은 없다. 따라서 kubectl kudo repo remove -v 10 --validate-install local 명령으로 삭제하고 다시 생성해야 한다.

  4. local repository를 kudo context의 기본 repository로 설정

    $ kubectl kudo repo context local

    $ kubectl kudo repo list
NAME            URL
    
community       https://kudo-repository.storage.googleapis.com/v1
*local          http://localhost:8090

  5. local repository를 기준으로 설치 검증

    상세 출력을 해주는 -v 옵션을 사용하면 Operator가 설치되는 위치에서 추적이 가능해 진다.

    $ kubectl kudo install --wait -v 50 --validate-install first-operator
repo configs: { name:community, url:https://kudo-repository.storage.googleapis.com/v1 },{ name:local, url:http://localhost:8090 }

    repository used { name:local, url:http://localhost:8090 }
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
acquiring kudo client
getting operator package
no local operator discovered, looking for http
no http discovered, looking for repository
getting package reader for first-operator, _
repository using: { name:local, url:http://localhost:8090 }
attempt to retrieve package from url: http://localhost:8090/first-operator-0.1.0_0.1.0.tgz
first-operator is a repository package from { name:local, url:http://localhost:8090 }
Preparing default/first-operator:0.1.0 for installation
parameters in use: map[]
operator.kudo.dev default/first-operator does not exist
    

    operator default/first-operator created
operatorversion default/first-operator-0.1.0-0.1.0 created
instance first-operator-instance created in namespace default
instance default/first-operator-instance created
plan status for instance “first-operator-instance” is not available
    

    instance plan “deploy” is not not finished running: true, term: false, finished: false
…
instance plan “deploy” is not not finished running: true, term: false, finished: false
plan status for “first-operator-instance” is finished
    

    instance default/first-operator-instance ready

    참고

    Operator install 에는 상당히 많은 옵션들이 존재한다. kubectl kudo install --help를 통해서 옵션들을 확인하고 적절하게 사용하면 된다.

    위와 같이 명령어의 출력을 통해서 설치를 확인할 수도 있으며, 실행되고 있는 로컬 웹 서버의 출력을 통해서도 확인이 가능하다.

    $ python3 -m http.server 8090   
Serving HTTP on 0.0.0.0 port 8090 (http://0.0.0.0:8090/) ...
127.0.0.1 - - [17/Dec/2020 08:14:06] "GET /index.yaml HTTP/1.1" 200 -
127.0.0.1 - - [17/Dec/2020 08:14:06] "GET /first-operator-0.1.0_0.1.0.tgz HTTP/1.1" 200 -

    이제 설치된 정보들을 확인해 봐야 한다.

    # deploy plan으로 생성된 Pod 확인 (replicas 파라미터의 기본 값 2 적용)
$ kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-77cfbb848f-4tgss   1/1     Running   0          3m17s
nginx-deployment-77cfbb848f-dngpl   1/1     Running   0          3m17s

    parameter를 변경해서 적용되는지 검증 (replicas 파라미터를 4로 변경 검증)
    

    $ kubectl kudo update --wait -v 10 --validate-install --parameter replicas=4 --instance first-operator-instance
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
instance plan “deploy” is not not finished running: true, term: false, finished: false
instance plan “deploy” is not not finished running: true, term: false, finished: false
instance plan “deploy” is not not finished running: true, term: false, finished: false
plan status for “first-operator-instance” is finished
    

    Instance first-operator-instance was updated.
    

    변경된 내용 검증
    

    $ kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-77cfbb848f-2bgjg   1/1     Running   0          50s
nginx-deployment-77cfbb848f-4tgss   1/1     Running   0          19m
nginx-deployment-77cfbb848f-dngpl   1/1     Running   0          19m
nginx-deployment-77cfbb848f-kqh5f   1/1     Running   0          50s
    

    설치된 Custom Opserator 정보 확인
    

    $ kubectl kudo get all
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
List of current installed operators including versions and instances in namespace “default”:
.
└── first-operator                     # Opserator
└── first-operator-0.1.0-0.1.0     # OperatorVersion
└── first-operator-instance    # OpseratorInstance
    

    OperatorInstance 의 Plan 상태 확인
    

    $ kubectl kudo plan status --instance=first-operator-instance
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
Plan(s) for “first-operator-instance” in namespace “default”:
.
└── first-operator-instance (Operator-Version: “first-operator-0.1.0-0.1.0” Active-Plan: “deploy”)
└── Plan deploy (serial strategy) [COMPLETE], last updated 2020-12-17 08:54:59
└── Phase main (parallel strategy) [COMPLETE]
└── Step everything [COMPLETE]
    

    진단
    

    $ kubectl kudo diagnostics collect --instance=first-operator-instance
Collect ResourceGroup for 3 collectors
Collect Logs for 4 pods
Collect Logs for 1 pods
    

    위의 명령은 수집된 데이터를 현재 경로의 diag 폴더에 생성한다. KUDO와 설치된 Operator에 대한 각종 리소스들과 로그들을 확인할 수 있다.
    

    Operator 삭제
    

    $ kubectl kudo uninstall --instance=first-operator-instance
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
instance.kudo.dev/v1beta1/first-operator-instance deleted
    

    이 명령은 실제 구동되는 대상인 OperatorInstance와 연계된 리소스들 (Deployments, Pods, …)을 제거하지만, Operator와 OperatorVersion은 삭제하지 않는다.

참고 자료

라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

OData 에 대해서 알아보자.

얼마 전에 어떤 회사에 인터뷰를 하러 간 적이 있었다. 당시 그 회사는 자체 솔루션을 개발할 기술인력을 찾고 있었고 내부적으로 OData를 사용한다고 했다. 좀 창피한 이야기일 수도 있지만 나름 기술적인 부분에서는 많은 정보를 가지고 있다고 했던 것이 무색하게 OData란 단어를 그 회사 사장님에게서 처음 들었다. 작고, 단순한 사이트들만을 계속해서 작업을 하다 보니 어느덧 큰 줄기들을 잃어버린 것을 느끼기 시작했다. 명색이 개발이 좋고, 기술적인 기반을 만들려고 하는 인간이 단어조차도 모른다는 것은 있을 수 없는 것이라서 다시 새로운 단어들과 개념들을 알아보는 시간을 가지려고 한다. OData (Open Data Protocol) 란? 간단히 정리하면 웹 상에서 손쉽게 데이터를 조회하거나 수정할 수 있도록 주고 받는 웹(프로토콜)을 말한다. 서비스 제공자 입장에서는 웹으로 데이터를 제공하는 방식으로 각 포탈 사이트들이 제공하는 OPEN API 포맷을 독자적인 형식이 아니라 오픈된 공통규약으로 제공 가능하며, 개발자는 이 정보를 다양한 언어의 클라이언트 라이브러리로 어플리케이션에서 소비할 수 있도록 사용하면 된다. 공식 사이트는 www.odata.org 이며 많은 언어들을 지원하고 있다. 좀더 상세하게 정의를 해 보면 OData는 Atom Publishing Protocol  (RFC4287) 의 확장 형식이고 REST (REpresentational State Transfer) Protocol 이다. 따라서 웹 브라우저에서 OData 서비스로 노출된 데이터를 볼 수 있다. 그리고 AtomPub 의 확장이라고 했듯이 데이터의 조회만으로 한정되는 것이 아니라 CRUD 작업이 모두 가능하다. Example 웹 브라우저에서 http://services.odata.org/website/odata.svc 를 열어 보도록 하자. This XML file does not appear to have any style in...
댓글 6개
자세한 내용 보기

C# 에서 Timer 사용할 때 주의할 점.

예전에 알고 지내시던 분의 질문을 받았다. Windows Forms 개발을 하는데, 주기적 (대략 1분)으로 데이터 요청을 하는 프로그램을 작성하기 위해서 Timer 를 사용하는데, 어떤 기능을 처리해야 하기 때문에 Sleep 을 같이 사용했다고 한다. 여기서 발생하는 문제는 Sleep 5초를 주었더니, Timer 까지 5초 동안 멈춘다는 것이다. Timer 라는 것은 기본적으로 시간의 흐름을 측정하는 기능이기 때문에 Sleep 을 했다고 해서 Timer 가 멈추는 일은 생겨서는 안된다. 그러나 실제 샘플을 만들어 보면 ... Timer 가 Sleep 만큼 동작이 멈추는 것을 확인할 수 있다. Windows Forms 는 UI Thread 를 사용하는 것으로 최적화 되어 있으며 여기서 Timer 를 쓰면 UI Thread 에 최적화된 System.Windows.Forms.Timer 가 사용된다. 여기서 문제의 발생이 시작되는 것이다. Sleep 을 사용하게 되면 UI Thread 가 Sleep 이 걸리기 때문에 여기에 속한 Timer 까지도 멈추는 것이다. 이런 문제를 해결하기 위해서는 System.Threading.Timer 를 사용해야 한다. 이 Timer 는 별도의 Thread 에서 동작하기 때문에 Sleep 의 영향을 받지 않는다. 언뜻 보면 쉬운 해결 방법인 것 같지만 Thread 가 분리되었기 때문에 Timer 가 돌아가는 Thread 에서 UI Thread 의 메서드나 컨트롤에 접근하기 위해서는 별도의 명령을 사용해야 하는 문제가 존재한다. 자~ 그럼 여기서 Timer 에 대해서 다시 한번 정리해 보도록 하자. .NET 에서 제공하는 Timer 들 .NET 에서는 기본적으로 3가지 Timer를 제공하고 있다. (MSDN) System.Windows.Forms.Timer - 사용자가 지정한 간격마다 이벤트를 발생시키며 Windows Forms 응용 프로그램에서 사용할 수 있도록 최적화 되어 있다. System...
댓글 7개
자세한 내용 보기

[Logging] NLog 사용법 정리...

SCSF 에는 기본적으로 Enterprise Library가 사용된다. 예전에도 그랬지만 기능은 훌륭하고 많은 부분에서 최적화(?)된 것일지도 모르지만, 역시나 사용하기에는 뭔가 모르게 무겁고, 사용하지 않는 기능이 더 많다라는 느낌을 지울수가 없다. 이번 프로젝트도 SCSF를 기반으로 하고 있지만, Enterprise Library를 걷어내고 각 부분에 전문화된 오픈 소스를 사용하기로 하였다. 예전에는 Log4Net을 사용했지만, 대량 사용자 환경에서는 메모리 누수와 기타 문제점이 존재한다는 MS 컨설턴트(?)의 전해진 말을 들은 후로는 사용하지 않는다. 대안으로 사용하는 것이 NLog 이다. 조금 후에는 3.0 버전도 나온다고 홈 페이지에 기재되어 있지만, 그 때가 되면 프로젝트는 끝나기 때문에 현재 2.1.0 버전을 사용하기로 했다. [원본 출처] http://cloverink.net/most-useful-nlog-configurations-closed/ 위의 참조 자료에는 다양한 정보들이 존재하므로 꼭 링크를 통해서 관련된 정보를 확인하고 이해하는 것이 좋을 듯 하다. 여기서는 당장 필요한 부분만을 정리하도록 한다. [ Logger 찾기 ] 기본적으로 Logger가 존재하는 클래스를 기반으로 Logger 정보를 구성한다. Logger logger = LogManager.GetCurrentClassLogger(); 주로 Namespace 기반으로 Logger를 설정하는 경우에 유연하게 사용할 수 있다. 또 다른 방법으로는 지정한 문자열로 특정 Logger를 직접 선택하는 방법도 제공된다. 이를 혼용해서 Namespace와 직접 지정 방식을 같이 사용할 수도 있다. 물론 Logger 환경 설정에서 Wildcard (*)를 지정할 수도 있다. Logger logger = LogManager.GetLogger("Database.Connect"); Logger logger = LogManager.Get...
댓글 1개
자세한 내용 보기