MSFL{ccambo}

Kubernetes 확장인 CRD와 CR 에 대한 개념 정리

ccambo — Fri, 19 Nov 2021 17:13:06 +0900

Kubernetes의 확장인 CRD Custom Resource Definition 와 CR Custom Resource 에 대한 개념 정리

기존에 Kubernetes 상의 Operator 나름대로 정리 라는 게시글을 작성했다.

게시글 자체는 Operator를 설명하기 위한 내용이었는데, 댓글로 문의를 주신 분들의 의문점들을 살펴보니 Operator의 관점에서 바라봤을 때 CRD와 CR에 대한 실체들에 대한 궁금점들이었기 때문에 근본적인 내용을 설명하는 것이 좋을 것 같아서 이 게시글을 작성한다.

Kubernetes의 기본적 동작 원리

Kubernetes 구성에 대한 자세한 내용은 Kubernetes Components 참고

Kubernetes는 상태관리 시스템

이다.예를 들어 Replica를 3이라고 지정하면 Kubernetes가 Deployment 요청을 받았을 때 Replica 개수를 확인하고 Pod를 3개 실행시키려고 한다. 즉, 처음 배포되면 사용자가 정의한 Replica 값이 Pod 실행 개수라는 상태 값이 된다는 것이다.
운영 중에 3개의 Pod 중에 1개 Pod가 오류로 중지되면 Kubernetes 입장에서는 3개가 유지 (Desired State) 되어야 하는 상태인데, 현재 상태는 2개 (Current State) 가 되므로 이를 다시 3개로 만들려고 액션을 취하게 된다.
아주 간단한 예는 실행될 Pod의 개수를 의미하는 Replicas 설정이라고 생각하면 된다. 보통 애플리케이션을 작성하고 컨테이너 이미지를 만들고 Kubernetes에 실행을 맡기기 위해 Deployment Spec에 애플리케이션 정보 뿐만 아니라 Replica 개수를 지정하고 kubectl 명령을 통해 실행하게 된다.
상태를 관리하는 것은 Controller의 역할

이다.간단하게 정리하면 다음과 같다.
1. Kubernetes는 Resource들의 변경을 감시하고 있다.
2. 변경이 감지되면 Kubernetes는 관련된 이벤트를 발생시킨다.
3. 발생된 이벤트는 Controller의 Reconcile 함수로 전달된다.
4. Reconcile 함수에서 전달된 이벤트 데이터에 따라 Current State를 Desired State로 맞추기 위한 작업을 진행한다.
위의 예에서 2개만 존재하는 Pod를 3개로 만들려고 액션을 취한다고 언급했는데, Kubernetes에서 상태가 변경된 것을 감지하고 상태를 맞추기 위해 실제 동작하는 것이 Controller 의 역할이다.
모든 리소스는 GVR로 식별

된다.G Group, V Version, R Resource 의 조합으로 모든 리소스를 식별한다. 아래와 같이 단순한 Deployment Spec를 보면 알 수 있다.위와 같이 Kubernetes의 모든 리소스들은 GVR 식별 구조를 가진다.
apiVersion: apps/v1 <<- Group이 apps, Version이 V1 kind: Deployment <<- Resource가 Deployment ...
Pod, Deployment, .. 모두 Kubernetes의 리소스로 Controller의 관리 대상들이다.

Kubernetes 확장을 위한 CRD 와 CR, 그리고 Operator

Kubernetes에서는 실제 애플리케이션 동작 및 운영에 필요한 Pod, Deployment, Service 등과 같이 기본적인 리소스 오브젝트만 제공하고 있다. 물론 이 정도만 있어도 사용하는데 문제가 없다.

요즘 많이 사용하고 있는 프로메테우스를 기준으로 확장을 검토해 보자.

Kubernetes 기본 오브젝트만을 기준으로 운영한다면 수집해야할 정보와 규칙들이 많아질 수록 프로메테우스의 설정이 복잡해지고, 대상 시스템에 따라서 하나 이상의 프로메테우스를 실행해서 연계 (Federation) 하거나 각각 메트릭 수집을 분리해서 운영하는 등의 작업이 필요한 상황들이 발생하게 된다.

운영자의 입장에서는 이런 작업들이 자동화되어 관리만 할 수 있는 것을 원할것이다. 그러나 Kubernetes에서는 이런 작업을 할 수 있는 방법이 없다. 이유는 Kubernetes는 상태관리 시스템이기 때문에 자동화를 위한 상태정보를 관리할 대상이 없기 때문이다.

Notes

실제 CRD, CR 구성을 위해서는 Operator Framework, KubeBuilder 등의 툴을 사용해서 개발해야 한다.

아래의 내용은 그냥 개념적인 이해를 위해 서술한 것이므로 주의해야 한다.

Kubernetes의 관점에서는 사용자정의 리소스를 의미하지만 아래의 설명에서는 개발적인 관점에서 이해하기 쉽도록 오브젝트라고 명기 또는 혼용한다.

개발 언어 (여기서는 Go) 관점에서 풀어보면 구조체 Structure 를 오브젝트 데이터 관리용으로 사용한다. 구조체에서 관리할 데이터 항목과 형식을 지정하며, 관리할 데이터를 정의한다.

type struct HelloSpec {
  Message string    `json:"message"`
  ...
}

우리가 오브젝트를 만들었다고 해도 Kubernetes는 이 오브젝트를 인식하지 못하기 때문에 GVR 형식으로 Kubernetes가 인식할 수 있도록 등록해 줘야 한다. 즉,

Kubernetes에 사용자가 정의한 오브젝트(Kubernetes에서는 리소스)에 대한 이름과 형식과 사이즈등의 데이터 관리 정보를 GVR 기준으로 정의한 것이 CRD

다.

아래의 내용은 간단하게 CRD를 구성한 매니페스트 파일이다. (hello_crd.yaml)

apiVersion: apiextensions.k8s.io/v1        # Kubernetes에서 제공하는 CRD용 Group과 Version
kind: CustomResourceDefinition                # Kubernetes에서 제공하는 Resource
metadata:
  name: hellos.examples.com              # CRD 식별명
spec:
  group: examples.com                # Group
  versions: 
    - name: v1alpha1        # Version
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                message:        # 필드명
                  type: string  # 필드 형식
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  names:
    kind: Hello                            # Resource
    plural: hellos                    # List 등으로 표현할 Resource의 복수형
  scope: Namespaced                    # Namespace 범위로 한정

이 CRD는 아래의 명령으로 실행하고 생성된 내역을 확인할 수 있다.

> kubectl apply -f hello_crd.yaml
customresourcedefinition.apiextensions.k8s.io/hellos.examples.com created

> kubectl get crd
NAME                                                  CREATED AT
...
hellos.examples.com                                   2021-11-19T04:30:20Z
...

단지 Kubernetes에 사용할 오브젝트에 대한 정보만 등록을 한 것 뿐이기 때문에 현재는 할 수 있는 것이 아무것도 없다.

Kubernetes가 상태관리 시스템이라고 했기 때문에

CRD로 Kubernetes가 인식할 수 있는 오브젝트의 정의를 등록했다면, 실제 상태 정보를 관리할 수 있는 오브젝트가 CR

이다. 개발 언어로 이해한다면 클래스가 CR 이라고 생각하면 된다. CR로 생성한 실체들이 인스턴스가 된다.

아래의 내용은 간단하게 CR을 구성한 매니페스트 파일이다. (hello_cr.yaml)

apiVersion: examples.com/v1alpha1        # CRD에서 지정한 Group/Version
kind: Hello                                                    # CRD에서 지정한 Resource Kind
metadata:
  name: my-new-hello-object                    # CR 식별명 (오브젝트 인스턴스 식별)
spec:
  message: "hi crd!!"                                # 필드에 저장할 값

이 CR은 아래의 명령으로 실행하고 생성된 내역을 확인할 수 있다.

> kubectl apply -f hello_cr.yaml
hello.examples.com/my-new-hello-object created

> kubectl get Hello        # Hello Resource Kind에 대해 생성된 인스턴스들 조회
NAME                  AGE
my-new-hello-object   33m

> kubectl describe Hello my-new-hello-object  # 인스턴스 정보 상세 조회
Name:         my-new-hello-object
Namespace:    koreobs-system
Labels:       <none>
Annotations:  <none>
API Version:  examples.com/v1alpha1
Kind:         Hello
Metadata:
  Creation Timestamp:  2021-11-19T05:00:07Z
  Generation:          1
  Managed Fields:
    API Version:  examples.com/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:kubectl.kubernetes.io/last-applied-configuration:
      f:spec:
        .:
        f:message:
    Manager:         kubectl-client-side-apply
    Operation:       Update
    Time:            2021-11-19T05:00:07Z
  Resource Version:  47889293
  Self Link:         /apis/examples.com/v1alpha1/namespaces/koreobs-system/hellos/my-new-hello-object
  UID:               89f3c291-64d7-4e77-aacb-fec1106813f8
Spec:
  Message:  hi crd!!        # 필드 값을 가지고 있다.
Events:     <none>

위의 같이 생성된 CR의 인스턴스가 상태정보를 가지는 실체가 된다. 위의 예에서 Hello은 CRD로 정의한 오브젝트고, my-new-hello-object는 생성되어 실체를 가지는 인스턴스가 된다.

단, 지금까지 작업한 것은 단지 사용자가 운영할 새로운 리소스를 생성하고 etcd에 정보를 저장하는 것 뿐이다. 아직 Kubernetes의 기본 리소스인 Pod, Deployment, Service와 같이 실행 가능한 리소스들과 연계해서 움직이는 것은 아니다.

위에서 Kubernetes의 기본 리소스들의 상태가 변경되면 이를 처리해주는 것이 Controller라고 언급했다. 따라서 여기서 생성한 Hello 의 인스턴스인 my-new-hello-object 의 상태 값이 변경되면 (예를 들어 “hi crd!!” 값을 “hi controller” 라고 변경했을 경우 등) 연결될 Controller가 없기 때문에 동작하지 않는 상태다.

따라서 사용자 리소스의 인스턴스들에 변경이 발생했을 때 Kubernetes를 통해 변경 이벤트를 받아서 처리할 사용자 정의 Controller가 필요하다.

Notes

이 부분은 Operator에 대한 샘플들을 찾아보면 된다. 여기서는 개념적인 이해를 위한 것이기 때문에 따로 설정하지 않는다.

상태 값을 출력하는 Pod를 운영한다는 가정을 하고 어떻게 운영되는지를 정리해 보도록 한다.

Hello CRD 를 구성해서 Kubernetes에 등록 : Kubernetes에서는 CRD를 인식할 수 있고, CR 인스턴스가 생성되면 상태를 저장할 수 있다.
Custom Controller 작성 및 Kubernetest에 연결 : Operator 작성 및 배포 방식에 따라서 Kubernetes에 등록, Custom Controller는 CR 인스턴스에서 변경이 발생하면 정보를 받아서 처리할 Reconcile 함수를 가지고 있다. 여기서는 전달된 CR 인스턴스를 통해 단순히 Eco 기능만 제공하는 Pod를 동작 시키는 Deployment를 구성하고 실행하는 것으로 가정한다.
사용자가 Hello 인스턴스 생성 : 생성도 상태 변경에 해당한다.
Kubernetes는 이미 등록된 CRD와 Custom Controller를 인지하고 있기 때문에 다음과 같이 처리한다.
4.1. Hello 인스턴스 생성에 따른 이벤트를 Custom Controller의 Reconcile 함수 호출 (이 부분의 연결고리는 Operator에 대해 검토해 보면 된다)
4.2. Custom Controller에서 전달된 이벤트의 Hello 인스턴스 정보를 기준으로 Echo Deployment 구성 후 반환
4.3. Kubernetes에서 반환된 Deployment를 실행해서 Pod 실행
사용자가 Hello 인스턴스의 Spec 값 변경 : 여기서는 Message ()
1. 작업 재 실행.

위의 같이 단순한 작업의 흐름으로 볼 수 있다.

지금까지 설명한

CRD 구성 및 배포, Custom Controller 연계 및 실행등을 모두 합쳐 놓은 것이 Operator

다.

실제 사례로 바라보기

이전 게시글에서 가장 문의가 많았던 프로메테우스를 기준으로 다시 한번 정리해 보도록 한다.

그림에 점선 박스는 CRD를 의미하는 내용이다. 정확하게는 “ServiceMonitor” 와 “Prometheus” 라는 사용자 정의 리소스를 의미하고 있다.
- “ServiceMonitor 1”, “ServiceMonitor 2” 는 “ServiceMonitor” 의 CR 인스턴스를 나타낸다.
  - ServiceMonitor 1 인스턴스는 Metric을 제공하는 Service 1, 2, 3 를 연계할 수 있는 Endpoint 정보를 상태 정보로 갖도록 정의되어 생성된 것이다.
  - ServiceMonitor 2 인스턴스는 Metric을 제공하는 Service 4, 5 를 연계할 수 있는 Endpoint 정보를 상태 정보로 갖도록 정의되어 생성된 것이다.
- Prometheus 라는 CR 인스턴스는 ServiceMonitor CR 인스턴스와 관련된 정보 뿐만 아니라 Prometheus Server 구동에 필요한 정보들을 상태 정보로 갖도록 정의되어 생성된 것이다.
Operator는 ServiceMonitor와 Prometheus 라는 CR의 변경에 대한 처리를 담당한 Custom Controller를 구동하는 실행 모듈이다.
Prometheus Server는 실제 동작하는 Prometheus Server다.

이런 상황에서 사용자의 액션에 따라 다음과 같이 동작한다.

사용자가 ServiceMonitor CR 인스턴스를 추가로 생성 (ServiceMonitor 3) 한 경우
- Kubernetes에서 동작하는 Operator로 변경이 감지된다.
- ServiceMonitor CR 정보를 Controller의 Reconcile 함수로 전달
- Reconcile에서 ServiceMonitor CR 정보를 기준으로 Prometheus Server에서 인식할 수 있도록 Configmap 정보 재구성
- 동작하고 있는 Prometheus 설정 (Configmap)을 재 로드하도록 처리
사용자가 Prometheus CR 인스턴스의 값을 변경한 경우
- Kubernetes에서 동작하는 Operator로 변경이 감지된다.
- Prometheus CR 정보를 Controller의 Reconcile 함수로 전달
- Reconcile에서 Prometheus CR 정보를 기준으로 Prometheus Server를 재 시동하도록 처리

정확하고 상세한 내용은 아니지만, 기존 게시글에 문의 되었던 것들이 이해될 수 있기를 바랍니다.

[kubernetes-troubleshooting] Namespace 삭제 명령에도 삭제되지 않는 Pod 삭제하기

ccambo — Tue, 15 Jun 2021 19:02:25 +0900

How to force deletion of pods on namespace

문제 상황

이전 게시글인 삭제되지 않는 네임스페이스 ^Namespace 강제로 삭제하기 를 통해 네임스페이를 삭제하는 방법을 알아 보았다.

이번 경우는 확실하게 눈으로 확인할 수 있는 파드 ^Pod 들이 남아 있고 Terminating 상태로 삭제되지 않는 문제가 발생했다. 테스트 했던 M3 오퍼레이터 ^Operator 를 장시간 유지하면서 etcd 클러스터가 응답하지 않는 상태가 발생했고, 삭제를 했지만 삭제되지 않는 문제인 상태다.

$ kubectl -n m3cluster get pods
NAME                READY   STATUS            RESTARTS   AGE
...
etcd-0            1/1     Terminating   2          16d
etcd-1            1/1     Terminating   2          16d
etcd-2            1/1     Terminating   2          16d
...

문제 원인 확인과 처리 방법

정상적으로 삭제될 수 있는 시간을 지나서도 Terminating 상태로 남아있는 상태는 대부분은 아래와 같은 원인으로 발생한다.

파드에 처리되지 않는 파이널라이저 ^Finalizer 가 연결된 경우
파드가 종료 시그널에 응답하지 않는 경우

이런 상황에서 정보를 확인해야 한다.

정보 출력
```
$ kubectl -n <namespace_name> get pod -p <pod_name> -o yml [> undeleted_pod.yaml]
```
화면에 출력을 사용하던지 아니면 화일로 출력해서 내용 중에서 status 부분과 metadata.finalizer 내용을 검토한다.
파이널라이저 확인

status 상에 별다른 문제가 없다면 출력된 정보에서 파이널라이저가 존재하는지 확인하고 아래의 명령을 사용해서 해당 파이널라이저를 제거한다.
```
$ kubectl -n <namepsace_name> patch pod <pod_name> -p '{"metadata":{"finalizers":null}}'
```
노드 상태 확인

파드가 정상적인 상태로 판단이 되면 노드를 확인해 봐야 한다. 출력물에서 spec.nodeName 을 통해서 배정된 노드 명을 확인하고 쿠버네티스 대시보드 등을 통해서 노드에 배정된 모든 파드가 Terminating 상태인지를 확인해야 한다.

이 상황이라면 쿠버네티스 마스터를 통해서 삭제 요청된 내용이 해당 노드가 응답할 수 있는 상태가 되어야 처리될 수 있으므로 노드를 재 부팅하는 등으로 처리하면 된다.
포드 강제 삭제

위의 모든 상황이 정상적이라면 종료 시그널에 응답하지 않는 상태인 것으로 일반적으로는 다음과 같은 상황일 수 있다.
- 인터럽트 신호를 허용하지 않는 사용자 공간의 루프 실행 중
- 애플리케이션 런타임의 유지 관리 프로세스 진행 중 (예를 들면 가비지 수집 등)
이런 경우라면 강제로 종료 시키는 방법을 사용할 수 있다. 그러나 이런 처리는 향후 예상치 않은 문제가 발생할 수도 있다.
```
$ kubectl -n <namespace_name> delete pod <pod_name> --grace-period=0 --force
```
하나의 파드라면 위의 명령을 사용하면 되지만 여러 개의 파드가 대상이라면 아래와 같이 일괄처리도 가능하다.
```
for p in $(kubectl -n <namespace_name> get pods | grep Terminating | awk '{print $1}'); do kubectl -n <namespace_name> delete pod $p --grace-period=0 --force; done
```
kubelet 재 시작

마지막으로 해 볼 수 있는 것은 종료 시그널이 실제 배정된 노드의 kubelet 과 연결되지 못해서 처리가 안되는 경우로 SSH를 통해 해당 노드로 접근해서 kubelet을 재 시작하는 것이다.

당연히 이를 처리하기 위한 권한이 존재해야 하고, 처리하기 전에 kubelet 로그를 확인해서 의심되는 상황이 존재하는지를 우선 검토하도록 한다.

[Kubernetes-Storage] 정상적으로 동작하던 Dynamic NFS Provisioner 오류 해결하기 (SelfLink 관련)

ccambo — Wed, 9 Jun 2021 17:07:34 +0900

정상적으로 동작하던 Dynamic NFS Provisioning에서 오류가 발생하는 문제 해결

참고

쿠버네티스 ^Kubernetes 클러스터에 동적으로 NFS ^{Network File System} Provisioning 에 대한 글은 아래 게시글 참고

[CentOS - NFS] CentOS 8에 NFS 설정 및 테스트

[Kubernetes-Storage] CentOS 8에 Dynamic NFS Client Provisioner 구성하기

상황

위의 게시글을 기준으로 NFS Provisioning 을 잘 사용하고 있었다. 추가로 쿠버네티스 클러스터를 구성해서 테스트를 해야하는 작업이 생겼고, 최신 버전의 쿠버네티스로 설치를 진행했다.

동일하게 NFS Provisioning 설정을 했고, 애플리케이션을 배포했을 때 계속 Pending 상태로 진행되지 않는 상황이 발생해서 로그 정보들을 통해서 검증하기 시작했다.

결론은 아래와 같이 nfs-client-provisioner 파드에서 오류가 발생하는 것으로 확인할 수 있었다.

2021-06-09T06:31:34.335294986Z  E0609 06:31:34.335012       1 controller.go:682] Error watching for provisioning success, can't provision for claim "default/test-web-0": events is forbidden: User "system:serviceaccount:default:nfs-provisioner" cannot list resource "events" in API group "" in the namespace "default"
2021-06-09T06:31:34.335430080Z  I0609 06:31:34.335031       1 leaderelection.go:156] attempting to acquire leader lease...
2021-06-09T06:31:34.362925534Z  I0609 06:31:34.362178       1 leaderelection.go:178] successfully acquired lease to provision for pvc default/test-web-0
2021-06-09T06:31:34.363014753Z  I0609 06:31:34.362277       1 controller.go:1068] scheduleOperation[provision-default/test-web-0[6ebb2da5-4c46-451a-ad82-f60c8e524bf8]]
2021-06-09T06:31:34.369124223Z  E0609 06:31:34.368990       1 controller.go:766] Unexpected error getting claim reference to claim "default/test-web-0": selfLink was empty, can't make reference

원인

우선 ... cannot list resource "events" in API group "" in the namespace "default” 오류는 권한과 관련된 부분이니 설정을 조정하면 되지만

selfLink was empty, can't make reference

오류는 기존에 보지 못했던 것이라 이 부분을 확인해야 한다.

해결 방법

제시하고 있는 것과 같이 SelfLink를 사용하지 않는 것이 정상이지만, 현재 구성한 NFS Provisioner에서 SelfLink를 참조해서 처리하고 있기 때문에 다음과 같이 처리해서 정상적으로 동작할 수 있도록 해야 한다.

FeatureGate 우회하는 방법 (권장하지 않음)쿠버네티스 클러스터의 마스터 노드에서 /etc/kubernetes/manifests/kube-apiserver.yaml 파일을 열고 아래와 같이 --feature-gates=RemoveSelfLink=false Command Option을 설정하고 재 시작하면 된다.
... spec: containers: - command: - kube-apiserver - --feature-gates=RemoveSelfLink=false ...
실제 SelfLink를 자동으로 해제하는 것은 FeaturGate - RemoveSelfLink 와 관련된 부분이므로 이를 해제하면 된다.
Provisioner를 교체하는 방법 (권장)아래와 같이 NFS Provisioning 관련 매니페스트 파일을 조정하고 배포하면 된다. (nfs_setup.yaml)
# ServiceAccount apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner namespace: default --- # ClusterRole kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: nfs-client-provisioner-runner rules: - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["events"] verbs: ["create", "update", "patch"] --- # ClusterRoleBinding kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: run-nfs-client-provisioner subjects: - kind: ServiceAccount name: nfs-client-provisioner namespace: default roleRef: kind: ClusterRole name: nfs-client-provisioner-runner apiGroup: rbac.authorization.k8s.io --- # leader locking Role kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: leader-locking-nfs-client-provisioner rules: - apiGroups: [""] resources: ["endpoints"] verbs: ["get", "list", "watch", "create", "update", "patch"] --- # leader locking RoleBinding apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: leader-locking-nfs-client-provisioner subjects: - kind: ServiceAccount name: nfs-client-provisioner namespace: default # provisioner가 배포될 네임스페이스 roleRef: kind: Role name: leader-locking-nfs-client-provisioner apiGroup: rbac.authorization.k8s.io --- # Deployment kind: Deployment apiVersion: apps/v1 metadata: name: nfs-client-provisioner labels: app: nfs-client-provisioner namespace: default spec: replicas: 1 strategy: type: Recreate selector: matchLabels: app: nfs-client-provisioner template: metadata: labels: app: nfs-client-provisioner spec: serviceAccount: nfs-client-provisioner containers: - name: nfs-client-provisioner image: k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2 # 이미지 교체 volumeMounts: - name: nfs-client-root mountPath: /persistentvolumes env: - name: PROVISIONER_NAME value: k8s-sigs.io/nfs-subdir-external-provisioner # Provisioner Env 변경 - name: NFS_SERVER value: <nfs server ip> - name: NFS_PATH value: <nfs server volume path> volumes: - name: nfs-client-root nfs: server: <nfs server ip> path: <nfs server volume path> --- # StorageClass kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: annotations: storageclass.kubernetes.io/is-default-class: "true" name: managed-nfs-storage provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # Provisioner 변경 parameters: archiveOnDelete: "false"
v1.21 버전에서는 완전히 SelfLink가 삭제
된다고 하니 이 방법을 사용하는 것이 좋다.

참고 자료

[Kubernetes] kubeadm 으로 ContainerD 기반 K8S Cluster를 CentOS 8 설치하기 (Docker 사용하지 않음)

ccambo — Tue, 8 Jun 2021 14:04:17 +0900

Docker를 사용하지 않고 Containerd 기반의 Kubernetes Cluster를 CentOS 8 에 kubeadm으로 설치하기

CentOS 8 버전부터 도커 ^Docker 는 레드햇의 도구인 podman, buildah 로 대체된 상태로 기본 패키지 저장소에서 제거되었고, API를 사용해서 처리되는 것이기 때문에 특정 툴에 한정될 필요가 없다.

현재 제공되고 있는 컨테이너 런타임^{Container Runtime} 은 다음과 같다.

이 문서는 containerd를 사용해서 클러스터를 구성한다.

1개의 마스터 노드와 3개의 워커 노드 모두 CentOS 8 설치
각 노드는 2G RAM, 2 CPU 를 최소 사양으로 한다.
모든 노드는 저장소에서 쿠버네티스 ^Kubernetes 및 기타 필수 패키지를 설치할 수 있도록 인터넷에 연결이 가능해야 하고, dnf 패키지 관리자를 사용할 수 있으며 원격으로 패키지를 가져올 수 있는지 검증되어야 한다.

설치환경 요약

쿠버네티스의 최소 요구 사항은 2G RAM, 2 CPU 를 기준으로 한다.

Master

CentOS 8.2.2004

monitor.master

centos

Worker

CentOS 8.2.2004

monitor.worker1, 2, 3

centos

CNI : Calico

CentOS 의 버전을 확인하는 방법은 아래와 같다.
$ cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core) 

$ cat /etc/*release*
CentOS Linux release 8.2.2004 (Core) 
Derived from Red Hat Enterprise Linux 8.2 (Source)
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="8"

CentOS Linux release 8.2.2004 (Core) 
CentOS Linux release 8.2.2004 (Core) 
cpe:/o:centos:centos:8
CentOS 8.2의 경우 일반 계정 생성 후에 sudo 권한을 줄 경우는 아래의 명령을 사용한다.
$ usermode -aG wheel <user>
CentOS 8.2에는 wheel 이라는 특별한 그룹이 존재하는데 sudo 설정에는 이 그룹에 한해 sudo 권한을 부여하고 있기 때문에 이 그룹에 사용자를 포함시키면 된다.

공통 설정

마스터와 워커 노드 모두 Static IP를 가지고 있어야 하며, 일반 계정이 존재해야 하며 sudo 권한을 가져야 한다.

관리자 권한으로 설정
sudo -s
패키지 관리자 갱신
dnf -y upgrade
Hosts 정보 설정
# 각 노드에서 각자에 맞도록 호스트 명 설정 hostnamectl set-hostname <host name> # /etc/hosts 에 각 구성 노드들의 IP와 HostName 설정 vi /etc/hosts ... <node ip> <hostname> <node ip> <hostname> ...
방화벽 설정CentOS 8에는 기본적인 방화벽이 설치되어 있기 않기 때문에 설치를 수행한다.정상적인 방화벽 설정
- 방화벽 규칙 설정
- # 공통으로 설정할 경우 $ sudo firewall-cmd --permanent --add-port=22/tcp # SSH $ sudo firewall-cmd --permanent --add-port=80/tcp # Web $ sudo firewall-cmd --permanent --add-port=443/tcp # API Requests and End-User, used by Workers $ sudo firewall-cmd --permanent --add-port=2376/tcp # Docker daemon TLS, used by all $ sudo firewall-cmd --permanent --add-port=2379-2380/tcp # ETCD Server client API, used by kueb-apiserver, etcd $ sudo firewall-cmd --permanent --add-port=6443/tcp # Kubernetes API Server, used by all $ sudo firewall-cmd --permanent --add-port=8285/udp # Flannel overlay network (UDP Backend), used by Master, Worker (if use Flannel) $ sudo firewall-cmd --permanent --add-port=8472/udp # Flannel overlay network (VxLan), used by Master, Worker (if use Flannel) $ sudo firewall-cmd --permanent --add-port=9099/tcp # Liveness/Readiness kubelet, API, used by Master, Worker $ sudo firewall-cmd --permanent --add-port=10250/tcp # kubelet API, used by self and control plane $ sudo firewall-cmd --permanent --add-port=10251/tcp # kube-scheduler, used by self $ sudo firewall-cmd --permanent --add-port=10252/tcp # kube-controller-manager, used by self $ sudo firewall-cmd --permanent --add-port=10254/tcp # Ingress $ sudo firewall-cmd --permanent --add-port=10255/tcp # Heapster, used by Worker $ sudo firewall-cmd --permanent --add-port=30000-32767/tcp # NodePort services, used by all $ sudo firewall-cmd --permanent --add-port=30000-32767/udp # NodePort services, used by all # 역할별 - ETCD 운영용 노드인 경우 $ sudo firewall-cmd --permanent --add-port=2376/tcp # Docker daemon TLS, used by all $ sudo firewall-cmd --permanent --add-port=2379-2380/tcp # ETCD Server client API, used by kueb-apiserver, etcd $ sudo firewall-cmd --permanent --add-port=8472/udp # Flannel overlay network (VxLan), used by Master, Worker (if use Flannel) $ sudo firewall-cmd --permanent --add-port=9099/tcp # Liveness/Readiness kubelet, API, used by Master, Worker $ sudo firewall-cmd --permanent --add-port=10250/tcp # kubelet API, used by self and control plane # 역할별 - 마스터 Control Plane 노드인 경우 $ sudo firewall-cmd --permanent --add-port=80/tcp # Web $ sudo firewall-cmd --permanent --add-port=443/tcp # API Requests and End-User, used by Workers $ sudo firewall-cmd --permanent --add-port=2376/tcp # Docker daemon TLS, used by all $ sudo firewall-cmd --permanent --add-port=6443/tcp # Kubernetes API Server, used by all $ sudo firewall-cmd --permanent --add-port=8285/udp # Flannel overlay network (UDP Backend), used by Master, Worker (if use Flannel) $ sudo firewall-cmd --permanent --add-port=8472/udp # Flannel overlay network (VxLan), used by Master, Worker (if use Flannel) $ sudo firewall-cmd --permanent --add-port=9099/tcp # Liveness/Readiness kubelet, API, used by Master, Worker $ sudo firewall-cmd --permanent --add-port=10250/tcp # kubelet API, used by self and control plane $ sudo firewall-cmd --permanent --add-port=10254/tcp # Ingress $ sudo firewall-cmd --permanent --add-port=30000-32767/tcp # NodePort services, used by all $ sudo firewall-cmd --permanent --add-port=30000-32767/udp # NodePort services, used by all # 역할별 - 워커 노드인 경우 $ sudo firewall-cmd --permanent --add-port=22/tcp # SSH $ sudo firewall-cmd --permanent --add-port=80/tcp # Web $ sudo firewall-cmd --permanent --add-port=443/tcp # API Requests and End-User, used by Workers $ sudo firewall-cmd --permanent --add-port=2376/tcp # Docker daemon TLS, used by all $ sudo firewall-cmd --permanent --add-port=8472/udp # Flannel overlay network (VxLan), used by Master, Worker (if use Flannel) $ sudo firewall-cmd --permanent --add-port=9099/tcp # Liveness/Readiness kubelet, API, used by Master, Worker $ sudo firewall-cmd --permanent --add-port=10250/tcp # kubelet API, used by self and control plane $ sudo firewall-cmd --permanent --add-port=10254/tcp # Ingress $ sudo firewall-cmd --permanent --add-port=30000-32767/tcp # NodePort services, used by all $ sudo firewall-cmd --permanent --add-port=30000-32767/udp # NodePort services, used by all # Calico Pod Network (마스터, 워커) $ sudo firewall-cmd --permanent --zone=public --add-port=179/tcp # Calico Networking (BGP), used by all (if use calico) $ sudo firewall-cmd --reload
# 방화벽 설치 dnf -y install firewalld # 활성화 systemctl enable firewalld systemctl start firewalld # 방화벽에 IP Masquerade 활성화 firewall-cmd --add-masquerade --permanent firewall-cmd --reload # 상태 확인 firewall-cmd --state firewall-cmd --list-all # 방화벽 끄기 systemctl stop firewalld systemctl disable firewalld
방화벽은 쿠버네티스에서 제시하는 포트들을 열어주면 사용이 가능하지만 실제 사용할 때는 쿠버네티스 공식문서에 제시되지 않은 포트들도 존재하고, 이상 동작하는 상황들도 발생하기 때문에 일반적인 테스트를 위한 실행기준으로는 방화벽을 끄고 운영하는 것을 권장한다. (당연히 프로덕션 환경이라면 필요한 포트들을 방화벽에 등록하고 정상적으로 사용해야 한다)
Container Runtime 설치
- 사전 설정
- cat > /etc/modules-load.d/containerd.conf <<EOF overlay br_netfilter EOF modprobe overlay modprobe br_netfilter # Setup required sysctl params, these persist across reboots. cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 1 EOF sysctl --system
- containerd 설치
- # Install required packages dnf install -y yum-utils device-mapper-persistent-data lvm2 iproute-tc # Add docker repository dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo # dnf update and Install containerd dnf update -y && dnf install -y containerd.io # Configure containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml # Restart containerd systemctl restart containerd # Enable containerd on boot systemctl enable containerd
CRI ^{Container Runetime Interface} 런타임으로 사용할 containerd 를 설치한다.
Kubernetes 설치 (kubeadm, kubelet, kubectl)
- 사전설정
- # Kubernetes Repository 추가 cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF
- 설치
- # Install Kubernetes (kubeadm, kubelet and kubectl) - 특정 버전을 지정할 수 있다. dnf install -y kubeadm kubelet kubectl
- 서비스 활성화
- # Enable kubelet service on boot systemctl enable kubelet # Configure kubelet echo 'KUBELET_EXTRA_ARGS="--fail-swap-on=false"' > /etc/sysconfig/kubelet # Start kubelet service systemctl start kubelet
CentOS 8에 기본적으로 쿠버네티스 리포지토리가 설치되어 있지 않기 때문에 수동으로 추가해야 한다. kubeadm 은 단일 쿠버네티스 컨트롤 플레인을 생성 및 활성화하고, 업그레이드/다운그레이드 및 부트스트랩 토큰 관리와 같은 다른 클러스터 수명주기 기능도 제공한다.

마스터 노드 설정

쿠버네티스는 통신 및 액세스를 위해 다양한 포트를 사용하기 때문에 방화벽 ^Firewall 에 제한되지 않고 쿠버네티스에 액세스할 수 있는 상태여야 한다. 아래의 방화벽 규칙을 참고하면 된다.

Protocol	Direction	Port Range	Purpose	Used By
TCP	inbound	6443	k8s API Server	all
TCP	inbound	2379 - 2380	ETCD server client API	kube-apiserver, etcd
TCP	inbound	10250	kubelet API	self, control plane
TCP	inbound	10251	kube-scheduler	self
TCP	inbound	10252	kube-controller-manager	self

kubeadm Images Pull
kubeadm config images pull
Create Control Plane with kubeadm--apiserver-cert-extra-sans 는 외부에서 접근할 수 있는 IP를 지정해서 내부와 외부에서 모두 API Server로 접근할 수 있도록 지정하고 인증서에 관련된 IP 정보를 포함시킨키는 것이다.
```
kubeadm join xxx.xxx.xxx.xxx:6443 --token ur9jpx... \        
        --discovery-token-ca-cert-hash sha256:48e4d3cca... 
```
정상적으로 실행되면 아래와 같이 워커 노드들을 클러스터에 참여시킬 수 있는 구문이 출력된다. 이 명령을 복사해 놓고 이후 워커 노드 작업에서 사용하면 된다.
kubeadm init --pod-network-cidr=10.15.0.0/16 --apiserver-cert-extra-sans=<master node ip>

kube-api 통신을 위한 환경 설정

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

쿠버네티스 마스터 명령은 모두 일반 계정으로 처리된다. 따라서 일반 계정이 kube-api 와 통신을 위해서는 아래와 같이 처리해 준다.

Pod Network 구성Calico는 쿠버네티스가 운영되는 환경에 따라 설치 과정에 차이가 있고, 같은 환경이라도 노드의 수에 따라서 설치하는 것도 다를 수 있다. 따라서 매뉴얼을 확인하고 작업할 것을 권장한다.
```
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
```
설치된 Calico 는 워커 노드가 클러스터에 참여하면 설치되어 동작하게 된다.
여기서는 On-Premise 환경이고 노드가 50개 미만이므로 아주 간단하게 적용하도록 한다.
쿠버네티스 클러스터를 구성할 때 --pod-network-cidr 옵션으로 지정한 CNI ^{Container Network Interface} 로 어떤 것을 사용할지에 따라 달라진다. 여기서는 Calico를 사용하도록 한다. 다른 CNI 들을 Installing a pod network add-on 을 참고하도록 한다.

워커 노드 설정

마스터 노드에 Control Plane이 설치되었으므로 이제 구성된 쿠버네티스 클러스터에 참여할 워커 노드들을 구성하면 된다.

Kubernetes Cluster 참여
```
kubeadm token create --print-join-command
```
위의 쿠버네티스 클러스터를 구성할 때 출력된 명령을 사용하거나 토큰이 만료된 상태라면 바로 위의 신규 토큰 생성 방법을 통해서 아래와 같이 클러스터에 참여하면 된다.
kubeadm join 10.0.1.186:6443 --token tofo13.... --discovery-token-ca-cert-hash sha256:e39c05bb474f8e6726ef...
기본적으로 마스터 노드에 쿠버네티스 클러스터를 구성하는 작업을 통해서 발행된 토큰은 24시간 존재하도록 되어 있기 때문에 나중에 워커 노드를 추가할 경우는 토큰이 없는 상태가 발생하므로 새롭게 토큰을 생성해서 참여하면 된다.

Dashboard 설치

기본으로 설치하면 Dashboard에 접근하기 위해서는 kubectl proxy 명령을 사용하고 http://localhost:8001/... 로 접근해야 한다. 그러나 실제로는 외부에서도 대시보드를 접근해서 확인하는 경우가 많기 때문에 NodePort 방식을 활용하도록 한다.

# wget이 없는 경우는 설치
dnf install -y wget

# Dashboard Manifest 파일 다운로드 (현재 버전 v2.2.0)
wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml

vi recommended.yaml
...  
  ports:  
  - nodePort: 32444     # 이 부분 추가 (생략하면 Kubernetes에서 임의로 지정하므로 중복되지 않는 값으로 설정)    
    port: 443    
    targetPort: 8443  
  selector:    
    k8s-app: kubernetes-dashboard  
  type: NodePort    # 이 부분 추가
...

# 직접 설치 
kubectl apply -f recommended.yaml

# 설치 검증
kubectl get services --all-namespaces # 또는 kubectl get services -n kubernetes-dashboard

최근 버전에서는 기존의 kube-system 네임스페이스에서 kubernetes-dashboard 네임스페이스로 이전되었으며, dashboard와 scraper 파드가 설치된다.

실제 Dashboard를 사용하기 위해서는 사용자 정보와 클러스터 역할 및 바인딩 정보를 구성해야 한다. (파일로 구성해도 되고 직접 kubectl 명령으로 생성해도 된다)

# 서비스 계정 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:  
  name: admin-user  
  namespace: kubernetes-dashboard
EOF

# 클러스터 역할 바인딩 생성
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:  
  name: admin-user
roleRef:  
  apiGroup: rbac.authorization.k8s.io  
  kind: ClusterRole  
  name: cluster-admin
subjects:
- kind: ServiceAccount  
  name: admin-user  
  namespace: kubernetes-dashboard
EOF

실제 Dashboard에 접속하기 위해서는 Bearer Token을 확인해야 한다.

kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"

결과로 추출된 Bearer Token을 https://<cluster mastaer or worker node ip>:32444 로 접근해서 Token 입력에 넣고 연결하면 대시보드를 확인할 수 있다.

Helm 3 설치

Helm은 쿠버네티스에서 동작하는 많은 애플리케이션들을 손쉽게 설치하도록 지원하는 프로그램으로 Ubuntu의 apt 나 CentOS 의 dnf 와 같은 패키지 관리자와 유사하다고 이해하면 된다.

기존 Helm 2 에서는 Tiler라는 Helm 서버가 필요했지만 Helm 3 에서는 좀 더 단순한 구조로 변경이 되었기 때문에 쉽게 설치 및 사용할 수 있다.

설치는 kubectl이 지원되는 모든 노드에서 사용 가능하다.

# 설치 스크립트를 다운로드해서 설치
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
chmod 700 get_helm.sh
./get_helm.sh

# 설치 확인 (현재 버전 v3.5.4)
helm version

# 설치는 /usr/local/bin 경로에 처리되므로 PATH 환경변수에 해당 경로가 설정되어 있어야 한다.
export PATH=/usr/local/bin:$PATH

기본 저장소를 가지고 있지 않기 때문에 설치를 진행할 수 없으므로 기본 저장소를 추가해 준다.

# Repo 검증
helm search repo

# 기본 Repo 추가 (기존의 https://kubernetes-charts.storage.googleapis.com/ 는 더이상 지원되지 않는다)
helm repo add stable https://charts.helm.sh/stable

# Repo 챠트 리스트 확인
helm search repo stable

# Repo 정보 갱신
helm repo update

설치 및 저장소 설정이 되었으므로 필요한 애플리케이션들을 저장소를 통해서 쿠버네티스 클러스터에 설치가 가능하다.

Metrics Server 설치

쿠버네티스 클러스터는 기본적으로 모니터링 정보를 알 수 있는 기능이 제공되지 않기 때문에 추가로 설치해야 한다. 기존에는 Heapster 기반으로 구성되었지만 더 이상 개발되지 않고 Metrics Server 로 대체되었다.

따라서 모니터링 기능 (실 시간 정보, 수집된 정보를 메모리에서만 관리하는)을 추가 설치해야 쿠버네티스 컴포넌트들에 대한 자원 모니터링도 가능하고 Autoscaling 에도 사용 가능해진다.

# 최신 버전 다운로드 (현재 v0.4.2)
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

메트릭스 서버가 API Server와 통신할 때 TLS 문제가 존재한다. API Server는 자체 TLS를 사용하지만 메트릭스 서버는 Public TLS를 사용하기 때문에 그냥 설치하면 문제가 발생하게 된다.

따라서 아래와 같이 다운로드한 파일에서 TLS와 hostNetwork 사용 관련된 부분을 수정해 줘야 한다. Tab 키가 아닌 Space 키로 여백을 처리해야 한다.

vi components.yaml
...
      - args:
        - --cert-dir=/tmp        
        - --secure-port=4443        
        - --kubelet-insecure-tls=true     # 이 부분 추가 (TLS 관련)        
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
...      
      hostNetwork: true              # 이 부분 추가 (Host Network 사용 관련)      
      nodeSelector:
        kubernetes.io/os: linux
...

변경한 components.yaml 파일을 쿠버네티스 클러스터에 배포한다.

# Deploy
kubectl apply -f components.yaml 

# Pods 확인
kubectl get pods -n kube-system

# Deploy 확인
kubectl get deploy -n kube-system

# Node 리소스 사용량 조회
kubectl top node

# Pod 리소스 샤용량 조회
kubectl top pod --all-namespaces

참고

Metrics Server 가 배포되어 정상적으로 동작하고 있다고 해도 즉시 데이터를 가져오는 것은 아니다. 따라서 설치 직후에는 다음과 같이 오류 메시지가 나올 수 있다.
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io)
데이터가 수집되지 않아서 처리할 수 없다는 것을 의미한다. 대략 1 ~ 3분 정보 지나서 데이터가 수집되기 시작하면 정상적으로 출력이 된다.

혹시 위의 TLS 및 hostNetwork 관련 수정과 다른 문제가 존재한다면 설정 부분을 다시 확인해야 한다. 이미 배포된 후에 Deployment 옵션을 변경할 경우는 아래의 명령을 사용한다.
kubectl edit deployments.apps -n kube-system metrics-server

참고 자료

Kubernetes Official Site

[MacOS] 특정 경로 밑의 디렉터리 일괄 삭제하기

ccambo — Thu, 28 Jan 2021 13:49:17 +0900

How to remove directories from Mac

Mac의 임시 파일들을 삭제하는 방법을 게시했던 ._xxx, .DS_Store 등 숨김파일 정리 및 .gitignore 처리하기 에서 언급했던 방식을 응용해서 Node 기반의 개발에서 사용했던 node_modules 디렉터리를 일괄 삭제하는 방법을 정리해 본다.

개발하면서 참조한 소스들, 개발한 소스들이 많기 때문에 특정 경로 이하의 모든 node_modules 들을 찾아서 삭제하는 것보다는 일괄적으로 삭제하기 위해서 find 명령을 사용하면 된다.

$ find . -name "node_modules" -type d -prune -print -exec rm -rf '{}' +

find .: 현재 경로를 루트 경로로 설정하고 검색
-name "node_modules": "node_modules"라는 이름을 지정
-type d: 지정한 이름의 디렉터리만 찾도록 지정
-prune: "node_modules"가 발견되면 그 경로 하위로 내려가지 않도록 지정
-print: 검색된 대상의 경로 출력하도록 지정
-exec rm -rf '{}' +: 일치된 결과에 대한 삭제 처리를 수행하는데, {} + 는 마지막에 선택한 이름을 추가해서 명령줄을 빌드하도록 하는 것으로 전체 발견된 "node_modules"의 수보다 적은 횟수로 호출할 수 있도록 조정하는 것으로 성능 향상을 위한 것이다.

무조건 실행되면 다시 복구할 수 없는 상태가 되므로 아래의 명령으로 실제 대상들이 제대로 검색되는지를 먼저 확인하고 진행하도록 한다.

$ find . -name "node_modules" -type d -prune -print | xargs du -chs
254M    ./K3Lab/RNDWorks/apigw/samples/etri/web/node_modules
4.0K    ./Blogs/hugo/hugoblog/node_modules
...
 14G    total

xargs: 앞의 명령에 대한 출력을 다음 명령의 입력으로 사용할 수 있도록 지정
du: "Disk Usage"를 나타내는 명령으로 디렉터리의 디스크 사용량 출력
-chs: 대상 디렉터리의 사용량 출력과 전체 총 합계 사용량을 보기 쉬운 단위 (KB, MB, GB) 로 표시하도록 지정

상기와 같이 검색된 "node_modules"의 개별 사용량과 최종 전체 사용량을 확인할 수 있다. 결과에 별다른 문제가 없다면 삭제 명령을 진행하면 된다.

[MacOS] Terminal 에서 zsh compinit: insecure directories 문구가 발생하는 경우 대처하기

ccambo — Thu, 21 Jan 2021 20:21:58 +0900

How to set compinit mode on zsh

KinD (Kubernetes in Docker)로 MacOS 상에 Multi-Nodes Kubernetes Cluster를 구성하면서 kubectl autocomplete를 설정했는데 아래와 같은 메시지가 터미널 실행 시에 계속 나타나는 문제가 발생했다.

zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]?

정보를 찾아보니 대 부분 zsh와 관련된 소유권 문제를 많이 이야기하고 있었다. 즉, 외부의 패키지나 라이브러리 등을 설치할 떄 외부의 스크립트를 사용할 경우에 /usr/local/share 폴더의 소유권과 권한이 변경되는 문제로 발생한다는 것이다.

상황을 확인해 보기 위해서 아래의 명령을 수행한다.

$ compaudit

There are insecure directories:
/usr/local/share

또는

There are insecure directories:
/usr/local/share/zsh/.site-functions
/usr/local/share/zsh

위의 같은 결과를 확인할 수 있다.

결과를 바로 소유권 및 권한 처리를 하는 방법은 다음과 같다.

# 검증 및 변경 처리
$ compaudit | xargs chmod g-w    

# 재 검증
$ compaudit

There are insecure directories:

위의 방법이 아니라 개별적으로 처리하는 경우는 다음과 같다.

/usr/local/share/zsh/.site-functions 가 나온 경우

$ cd /usr/local/share/zsh
$ sudo chown -R root:root ./site_functions

/usr/local/share 가 나온 경우

$ cd /usr/local/share/
$ sudo chmod -R 755 zsh
$ sudo chown -R root:staff zsh

원인과 해결 방식에 대한 것이 궁금한 경우는 zsh, Cygwin and Insecure Direcotries를 참고하고, 좀 더 상세한 내용은 zsh: 20 Completion System를 참고하면 된다.

참고 자료

[MacOS,Git] ._, .DS_Store 등 숨김파일 정리 및 .gitignore 처리하기

ccambo — Thu, 21 Jan 2021 19:52:03 +0900

How to remove temporary hidden files like .DS_Store / ._xxxx

Remove `._xxxx` files

MacOS에서 여러 작업을 하다보면 ._ 으로 시작하는 파일들이 생성된 것을 확인할 수 있다. (일반적으로 숨김 파일들이라 보이지 않는다) 이런 파일은 다양한 작업 중에 생성되는데 일반적인 상황은 다음과 같다.

MacOS HDD/SDD에서 외장 HDD/SDD로 복사했을 때
MacOS에서 압축했을 때

더 많은 상황이 있을 수 있지만 결국은 다른 플랫폼 (또는 다른 FileSystem)과 혼용할 경우에 아이콘을 생성하기 위해 파일을 가져오는 과정에서 메타정보 저장용으로 자동 생성된다.

이런 파일의 생성과 제거는 다음과 같은 방법들이 존재한다.

압축하는 경우라면 다른 플랫폼에서 이런 파일들이 유지되지 않도록 COPYFILE_DISABLE 설정을 하면 된다.

# 압축 명령에서 사용해서 tar가 메타 정보를 추가하지 않도록 설정
$ COPYFILE_DISABLE=1 tar -cf xxxx.tar file*

매번 이렇게 처리하는 것이 귀찮다면 아예 shell에 설정하는 것도 가능하다.
```
# ~/.zshrc 또는 ~/.bash_profile, ....
...
COPYFILE_DISABLE=1; export COPYFILE_DISABLE
...
```
이미 파일이 존재하는 경우라면 일괄 삭제할 수 있다.
```
$ find ./ -name ._\* -delete
```

Git에서 MacOS의 불필요 파일들 제외하기

위에서 설명한 것과 같이 자동 생성되는 파일들을 git 에서 제외하려면 .gitignore 파일을 사용하면 된다.

git에 포함되지 않도록 제외하는 경우

# .gitignore 파일
...
# OS Generated Files #
######################
**/.DS_Store
**/._*
...

이미 git에 포함된 경우

# git 정보 검색 및 삭제
$ find . -name .DS_Store -print0 | xargs -0 git rm -f --cached --ignore-unmatch
# 변경 commit
$ git commit -m "<commit message>"
# Push to remote repository
$ git push orgin master

참고

많은 프로젝트를 운영하는 경우라면 매번 gitignore를 처리하기 힘들 수 있으므로 이런 공통된 규칙을 전역으로 처리할 수도 있다.
# 전역으로 사용할 .gitignore 파일 생성
$ echo .DS_Store >> ~/.gitignore_global

# git에서 사용할 수 있도록 설정
$ git config --global core.excludesfile ~/.gitignore_global
단, 이 방법이 올바른 방법인지를 검증을 해 본 후에 판단해야 할 것 같다.

참고 자료

[Kubernetes-Troubleshooting] 삭제되지 않는 Namespace 강제로 삭제하기

ccambo — Sun, 17 Jan 2021 02:04:25 +0900

How to force deletion of a namespace

문제 상황

Argo Project의 Argo Events를 테스트해 보기 위해서 여러 가지 작업을 하던 중 제대로 처리가 되지 않아서 다시 시작할 겸 Namespace를 삭제해서 소속된 리소스들을 모두 삭제했다.

그런데 위의 그림처럼 Argo Events Namespace가 삭제되지 않고 Terminating 상태로 계속 유지되는 문제가 발생했다.

문제 원인

정상적으로 삭제될 수 있는 시간을 지나서도 Terminating 상태로 남아있어서 원인에 대한 부분을 찾다가 Namespace의 다른 모든 Resource들은 삭제되었는데 (정확하게는 Dashboard에도 조회가 되지 않고, kubectl get 명령으로도 보이지 않는) Namespace만 저런 상태라서 Namespace에 대한 정보를 출력해 보았다.

# Resource 정보 출력
$ kubectl get namespace argo-events -o yaml

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2021-01-13T10:40:07Z"
  deletionTimestamp: "2021-01-15T09:31:30Z"
...
spec:
  finalizers:
  - kubernetes              # Namespace에 대한 Finalizers
status:
  conditions:
  - lastTransitionTime: "2021-01-15T09:31:36Z"
    message: All resources successfully discovered
    reason: ResourcesDiscovered
    status: "False"
    type: NamespaceDeletionDiscoveryFailure
  - lastTransitionTime: "2021-01-15T09:31:36Z"
    message: All legacy kube types successfully parsed
    reason: ParsedGroupVersions
    status: "False"
    type: NamespaceDeletionGroupVersionParsingFailure
  - lastTransitionTime: "2021-01-15T09:31:36Z"
    message: All content successfully deleted, may be waiting on finalization
    reason: ContentDeleted
    status: "False"
    type: NamespaceDeletionContentFailure
  - lastTransitionTime: "2021-01-15T09:31:36Z"
    message: 'Some resources are remaining: eventbus.argoproj.io has 1 resource instances'    # 일부 리소스가 남아 있다는 상태
    reason: SomeResourcesRemain
    status: "True"
    type: NamespaceContentRemaining
  - lastTransitionTime: "2021-01-15T09:31:36Z"
    message: 'Some content in the namespace has finalizers remaining: eventbus-controller
      in 1 resource instances'                                                                # 일부 리소스의 Finalizer가 남아 있다는 상태
    reason: SomeFinalizersRemain
    status: "True"
    type: NamespaceFinalizersRemaining
  phase: Terminating

위의 결과에서 status 부분을 보면 2 가지 문제가 존재하는 것을 확인할 수 있다.

eventbus.argoproj.io 에 하나의 리소스 인스턴스가 남아 있는 상태
eventbus-controller 의 finalizer가 남아 있는 상태

유추해 보면 리소스 자체는 삭제가 되었지만 Finalizer가 제대로 처리되지 못해서 발생하는 상태로 보인다. 주로 이와 같은 상황은 아래와 같이 두 가지로 판단할 수 있을 것 같다.

Custom Finalizer가 정리되지 않는 경우이런 경우라면 finalizer와 연관된 Controller가 무엇인지를 확인하고 수정해야 한다.
Namespace의 Spec (.spec.finalizers) 내용에 kubernetes 이외의 다른 요소가 존재하는 경우는 주로 CRD (Custom Resource Definition)에 따른 Extension Cotroller가 정리되지 않는 상태로 볼 수 있다.
Kubernetes Finalizer가 정리되지 않는 경우확인 결과 모든 리소스가 삭제된 상태라면 admission webhook이나 extension api server에서 오류가 발생했을 수 있음을 의미한다. Namespace가 삭제될 때 각 리소스를 삭제하기 위해서 보내는 요청은 delete가 아니라 delete-collection 이므로 이 요청이 제대로 처리되었는지를 확인해야 한다.
Namespace의 Spec (.spec.finalizers) 내용에 kubernetes만 존재하는 경우로 기본 Finalizer이므로 Namespace내의 모든 리소스가 삭제되면 마지막으로 처리가 되는 것인데 진행되지 않고 있다는 것은 실제 모든 리소스가 삭제되었는지 확인해 봐야하는 것을 의미한다.

참고

Namespace의 .spec.finalizers 는 Sub resource기 때문에 kubectl edit, kubectl update 등의 명령으로 수정되지 않는다. 따라서 curl 또는 Postman 등으로 직접 API를 호출해서 처리해야 한다.

해당 오류를 찾아서 해결하면 되지만 Namespace를 삭제하는 과정에서 이런 문제가 발생된 것이기 때문에 이미 Namespace의 리소스들은 삭제 처리가 되어 정상적인 방법으로 처리할 수 없다. 따라서 이 상태에는 Namespace를 기준으로 강제 삭제를 해야 한다.

해결 방법

지금 발생한 상황은 위에서 설명한 두 가지 경우중 Kubernetes Finalizer가 정리되지 않는 경우에 해당하기 때문에 모든 리소스가 삭제되었는지를 먼저 확인해 보도록 한다.

$ kubectl get all

위 명령은 Category All의 의미기 때문에 실제 모든 리소스를 보여주는 것이 아니다. 따라서 아래의 명령으로 실제 api-resourrce에 namespace로 한정된 리소스들의 이름을 조회해 보아야 한다.

$ kubectl api-resources --namespaced=true -o name
...
eventbus.argoproj.io           # argo-events namespace 내의 리소스
eventsources.argoproj.io       # argo-events namespace 내의 리소스
sensors.argoproj.io            # argo-events namespace 내의 리소스
...

위 명령으로 모든 리소스들의 이름을 확인해 본 결과 위의 결과와 같이 이미 삭제되었어야 할 리소스 이름이 남아 있었다. 이들 리소슥가 삭제되지 못한 이유를 확인해야 한다. 대부분은 metadata.finalizer에 문제의 원인이 있을 가능성이 높다.

지금까지의 판단으로는 CRD를 사용했을 때 이런 문제가 많이 발생했던 것으로 유추되므로 처리하기 이전에 아래와 같이 CRD가 존재한다면 Finalizer를 미리 제거해도 된다.

# CRD 확인
$ kubectl get crd -A

# CRD의 Finalizer 제거
$ kubectl patch crd <crd name> -p '{"metadata":{"finalizers": []}}' --type=merge

위에서 설명한 것과 같이 현재는 개별 문제가 발생된 리소스에 접근할 수 있는 방법이 없기 때문에 (방법을 못 찾았을 수도 있다) Namespace를 강제 삭제하도록 한다.

삭제되지 않는 Namespace 정보를 JSON 형식으로 저장한다.
$ kubectl get namespace argo-events -o json > argo-events-namespace-for-delete.json
저장된 Namespace 정보에서 Finalizers 부분의 - kuberntes를 제거한다.
# 저장된 내용 ... spec: finalizers: - kubernetes ... # 위의 내용에서 Finalizers로 지정된 kubernetes 삭제 ... spec: finalizers: ...
Kubernetes API를 직접 호출해서 Finalize 처리 진행
# kubectl proxy를 이용해서 저장된 인증 토큰을 사용 $ kubectl proxy # 다른 터미널을 열어서 API 호출 $ curl --insecure -k -H "Content-Type: application/json" -X PUT --data-binary @argo-events-namespace-for-delete.json http://localhost:8001/api/v1/namespaces/argo-events/finalize

Namespace가 삭제되지 못하고 있는 원인인 Finalize를 직접 API 서버를 호출해서 처리하면 Namespace를 삭제할 수 있다.

주의

이 방법으로 삭제되지 않고 남아있는 Namespace는 삭제를 할 수 있지만 정말 해당 리소스들이 깨긋하게 삭제되었는지에 대한 검증을 할 수는 없었다. 이에 대한 검증이나 추가적인 문제들이 있는지는 향후 검토가 필요하다.
Update at : 2021-01-19
Namespace가 삭제된 후에 다시 한번 확인해 보면 몇 가지를 확인할 수 있다.
$ kubectl api-resource --namespaced
NAME                        SHORTNAMES   APIGROUP                    NAMESPACED   KIND
...
cronworkflows               cwf,cronwf   argoproj.io                 true         CronWorkflow
sensors                     sn           argoproj.io                 true         Sensor
workfloweventbindings       wfeb         argoproj.io                 true         WorkflowEventBinding
workflows                   wf           argoproj.io                 true         Workflow
workflowtemplates           wftmpl       argoproj.io                 true         WorkflowTemplate
...
위와 같이 Namespace가 삭제되었지만 남아있는 리소스들을 확인할 수 있다. 따라서 이 리소스들을 삭제 해 줘야 한다. 그렇지 않으면 동일한 Namespace를 생성했을 때 오 동작의 원인이 될 수 있다.

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 3: Bootstrap 삭제 및 서비스 중단 없이 Scale Up/Down 처리

ccambo — Tue, 5 Jan 2021 19:24:31 +0900

How to building real world sample step by step - Part 3

게시글 참고

이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다.

PART 1에서는 부트스트랩 노드 구성

PART 2에서는 클러스터에 노드들이 참여할 떄 사용할 서비스와 설정등을 구성하고 StatefulSet을 구성

이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 구성된 Galera Cluster의 사용하지 않는 bootstrap 정보를 제거하고, 외부 연결을 위한 서비스 생성 및 서비스의 중단없이 Scale Up/Down 할 수 있도록 나머지 부분을 적용해 본다. 이 과정까지 완료되면 프로덕션 환경에 적용할 수 있는 정도가 된다.

Cleanup bootstrap node

PART 2 에서 모든 노드들을 클러스터에 참여시켰기 때문에 더 이상은 부트스트랩 노드가 필요하지 않다.

따라서 operator.yaml에 부트스트랩 노드와 관련된 리소스를 제거하는 Step과 Task를 추가하도록 한다.

...
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          ...
          - name: cleanup    # 추가
            tasks:
              - bootstrap_cleanup
tasks:
  ...
  - name: bootstrap_cleanup      # 추가
    kind: Delete
    spec:
      resources:
        - bootstrap_deploy.yaml
        - bootstrap_service.yaml
        - bootstrap_config.yaml

추가된 bootstrap_cleanup은 삭제 작업으로 PART 1에서 만들었던 bootstrap 관련 리소스들이 대상이며 이 작업이 실행되면 resources로 지정된 *.yaml 파일에 정의된 부트스트랩 리소스들 (ConfigMap, Service, Deploy)이 모두 삭제된다.

그러나 실제 Galera 노드들에서 사용하는 ConfigMap에 부트스트랩 노드 정보 (wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc)가 남아 있기 떄문에 Galera 인스턴스가 누락된 노드를 중심으로 작동하므로 반드시 문제가 되는 것은 아닐지라도 완전성을 위해 관련된 정보도 삭제해 주는 것이 좋다.

따라서 opreator.yaml파일에 ConfigMap을 수정할 수있는 Task를 추가하고 Step에서 이 Task를 이용하는 것으로 아래와 같이 변경한다.

...
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          ...
          - name: cleanup
            tasks:
              - bootstrap_cleanup
              - config      # 추가
tasks:
  ...
  - name: bootstrap_cleanup
    kind: Delete
    spec:
      resources:
        - bootstrap_deploy.yaml
        - bootstrap_service.yaml
        - bootstrap_config.yaml
  - name: config      # 추가
    kind: Apply
    spec:
      resources:
        - galera_config.yaml

이번에는 하나의 Step에서 두 개의 Task가 동작하도록 정의했다. deploy phase의 실행 전략을 strategy: serial로 지정했으므로 두 개의 Task는 순차적으로 처리된다.

참고

여기서 주의할 것은 PART 2에서 사용했던 galera_config.yaml을 다시 사용한다는 것이다. 즉, 노드를 설치할 때와 삭제할 때 설정 기능이 다른데 하나의 리소스를 재 사용하는 상황인 것이다. 이를 해결하기 위해서 템플릿에서 .StepName 변수를 활용해서 어떤 Step에서 호출되었는지를 식별해서 처리하는 방식을 사용한다.

StepName 정보를 기준으로 내용을 구성할 수 있도록 템플릿 리소스인 templates/galera_config.yaml 파일을 아래와 같이 수정한다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Name }}-nodeconfig
  namespace: {{ .Namespace }}
data:
  galera.cnf: |
    [galera]
    wsrep_on = ON
    wsrep_provider = /usr/lib/galera/libgalera_smm.so
    wsrep_sst_method = mariabackup
    {{ if eq .StepName "firstboot_config" -}}
    wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc,{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}}
    {{ else -}}
    wsrep_cluster_address = gcomm://{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}}
    {{ end -}}
    wsrep_sst_auth = "{{ .Params.SST_USER }}:{{ .Params.SST_PASSWORD }}"
    binlog_format = ROW
  innodb.cnf: |
    [innodb]
    innodb_autoinc_lock_mode = 2
    innodb_flush_log_at_trx_commit = 0
    innodb_buffer_pool_size = 122M

wsrep_cluster_address 정보를 지정할 때 템플릿에 조건부 처리를 지정했다. 즉, firstboot_config Step일 경우는 부트스트랩 구성이 적용되고, 그 외는 클러스터에 참여할 노드 정보들만 구성되는 것이다.

{{ if eq .StepName "firstboot_config" -}}
  wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc,{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}}
{{ else -}}
  wsrep_cluster_address = gcomm://{{ $.Name }}-galera-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-galera-{{ $v }}.{{ $.Name }}-hs{{end}}
{{ end -}}

if, else, end 구문은 -}} 으로 종료시키고 있다. 이는 템플릿 엔진에게 해당 라인을 빈줄로 뇌두지 말고 삭제하도록 지정하는 것이다.

위와 같이 템플릿 내에 조건문을 사용해서 다른 여러 Task들에서 재 사용할 수 있다.

이제 Pod가 재 시작되면 post-bootstrap cluster에 대한 올바른 구성을 가지고 다시 백업을 시작할 수 있게 된다.

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-operator-instance

설치된 ConfigMap 및 Pod 확인

$ kubectl describe configmap galera-operator-instance-nodeconfig

Name:         galera-operator-instance-nodeconfig
Namespace:    default
Labels:       heritage=kudo
              kudo.dev/instance=galera-operator-instance
              kudo.dev/operator=galera-operator
Annotations:  kudo.dev/last-applied-configuration:
                {"kind":"ConfigMap","apiVersion":"v1","metadata":{"name":"galera-operator-instance-nodeconfig","namespace":"default","creationTimestamp":n...
              kudo.dev/last-plan-execution-uid: 8cd36d4b-aeb5-473e-8997-1fad6090722a
              kudo.dev/phase: deploy
              kudo.dev/plan: deploy
              kudo.dev/step: cleanup

Data
====
galera.cnf:
----
[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = mariabackup
wsrep_cluster_address = gcomm://galera-operator-instance-galera-0.galera-operator-instance-hs,galera-operator-instance-galera-1.galera-operator-instance-hs,galera-operator-instance-galera-2.galera-operator-instance-hs
wsrep_sst_auth = "root:admin"
binlog_format = ROW

innodb.cnf:
----
[innodb]
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 0
innodb_buffer_pool_size = 122M

Events:  <none>

정상적으로 ConfigMap이 조건에 따라서 wsrep_cluster_address 설정 값이 부트스트랩 정보없이 노드들의 정보만으로 구성된 것을 확인할 수 있다.

$ kubectl get pods

NAME                                         READY   STATUS    RESTARTS   AGE
galera-operator-instance-galera-operator-0   1/1     Running   0          3m28s
galera-operator-instance-galera-operator-1   1/1     Running   0          3m3s
galera-operator-instance-galera-operator-2   1/1     Running   0          2m35s
nfs-client-provisioner-b84668c6d-zxt8d       1/1     Running   0          91m

부트스트랩 노드가 제거되고 나머지 노드들만 존재하는 것을 확인할 수 있다.

KUDO 및 Operator 삭제

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

Add service for connect from client

이제 클라이언트가 Galera Cluster에 연결할 수 있는 방법이 필요하다. Galera Cluster는 다중 마스터 구조이기 때문에 어디로 연결되더라도 안전하게 읽고 쓸 수 있다. 서비스는 어떤 의존성도 갖지않기 때문에 deploy plan의 어떤 단계에서 생성하던지 상관이 없지만 이미 클러스터 내부의 서비스를 생성한 단계가 있으므로 여기에 추가하도록 한다.

operator.yaml 파일의 이미 존재하는 cluster_service Task에 아래와 같이 추가한다.

...
  - name: cluster_services
    kind: Apply
    spec:
      resources:
        - hs-service.yaml
        - cs-service.yaml   # 추가
...

이제 사용한 서비스 리소스인 templates/cs-service.yaml 파일을 생성하고 아래와 같이 구성한다.

apiVersion: v1
kind: Service
metadata:
  name: {{ .Name }}-cs
  namespace: {{ .Namespace }}
  labels:
    app: galera
    galera: {{ .Name }} 
spec:
  ports:
    - port: {{ .Params.MYSQL_PORT }}
      name: mysql
  selector:
    app: galera
    instance: {{ .Name }}

이 서비스는 mySQL 포트만 필요하고 클라이언트가 Galera Clustr에 연결할 수 있도록 load balancing된 ClusterIP를 제공한다.

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-operator-instance

설치된 Service 확인

$ kubectl get services

NAME                          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                               AGE
galera-operator-instance-cs   ClusterIP   10.104.170.201   <none>        3306/TCP                              5m3s
galera-operator-instance-hs   ClusterIP   None             <none>        3306/TCP,4444/TCP,4567/TCP,4568/TCP   5m3s

실행 중인 클러스터에 모든 서비스가 생성된 것을 확인할 수 있다. 서비스의 상세 정보를 통해서 정상적으로 생성되었는지 확인한다.

$ kubectl describe service galera-operator-instance-cs

Name:              galera-operator-instance-cs
Namespace:         default
Labels:            app=galera
                  galera=galera-operator-instance
                  heritage=kudo
                  kudo.dev/instance=galera-operator-instance
                  kudo.dev/operator=galera-operator
Annotations:       kudo.dev/last-applied-configuration:
                    {"kind":"Service","apiVersion":"v1","metadata":{"name":"galera-operator-instance-cs","namespace":"default","creationTimestamp":null,"label...
                  kudo.dev/last-plan-execution-uid: f5b71f8e-b9ef-49b0-81d1-8f82315e63d4
                  kudo.dev/phase: deploy
                  kudo.dev/plan: deploy
                  kudo.dev/step: cluster_services
Selector:          app=galera,instance=galera-operator-instance
Type:              ClusterIP
IP:                10.104.170.201
Port:              mysql  3306/TCP
TargetPort:        3306/TCP
Endpoints:         10.244.247.12:3306,10.244.84.132:3306
Session Affinity:  None
Events:
  Type     Reason                        Age    From                       Message
  ----     ------                        ----   ----                       -------
  Warning  FailedToUpdateEndpointSlices  4m37s  endpoint-slice-controller  Error updating Endpoint Slices for Service default/galera-operator-instance-cs: failed to update galera-operator-instance-cs-brmb9 EndpointSlice for Service default/galera-operator-instance-cs: Operation cannot be fulfilled on endpointslices.discovery.k8s.io "galera-operator-instance-cs-brmb9": the object has been modified; please apply your changes to the latest version and try again

클라이언트 연결 확인

생성한 서비스를 통해서 클라이언트가 Galera Cluster에 접속할 수 있다.

$ kubectl run mysql-client --image=mysql:5.7 -it --rm --restart=Never -- mysql -u root -h galera-operator-instance-cs -p

진행 중에 아래와 같은 메시지가 보이면 params.yaml에 정의했던 password를 입력하면 된다.

If you don't see a command prompt, try pressing enter.

mysql> 프롬프트가 보이면 정상적으로 연결이 된 것이다.

KUDO 및 Operator 삭제

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

Scale up/down without service interruption

KUDO는 파라미터의 값을 변경함으로써 연계된 Plan 이 구동된다. 파라미터로 정의한 NODE_COUNT를 변경하면 deploy plan이 구동될 것이기 때문에 ConfigMap을 변경하고 클러스터에 새로운 노드 수를 반영하기 위해서 StatefulSet이 재 시작될 필요가 있다.

이런 작업을 반영하기 위해 operator.yaml 파일에 새로운 plan을 아래와 같이 추가한다.

...
plans: 
  deploy:
    ...
  node_update:      # 추가
    strategy: serial
    phases:
      - name: deploy
        stratege: serial
        steps:
          - name: config
            tasks:
              - config
          - name: stateful
            tasks:
              - statefulset
...

이 Plan은 기존의 Task를 재 사용하는 것이기 때문에 별도의 Task 추가는 필요하지 않고 두 개의 Step이 순차적으로 실행되도록 정의한 것이다.

이제 NODE_COUNT 파라미터가 변경되면 위에 정의한 새로운 Plan이 구동될 수 있도록 params.yaml의 파라미터 정보를 아래와 같이 추가한다.

apiVersion: kudo.dev/v1beta1
parameters:
  ...
  - name: NODE_COUNT
    description: "Number of nodes to create in the cluster"
    default: "3"
    trigger: node_update      # 추가
  ...

PART 2 에서는 trigger 정보가 없었으며 이런 경우는 기본 값으로 deploy plan이 호출되게 된다. trigger를 지정해서 node_update plan을 호출하도록 한 것이다.

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-operator-instance

NODE_COUNT 변경 검증
```
$ kubectl kudo update --instance galera-operator-instance -p NODE_COUNT=3
```
파라미터를 통한 변경이 적용되었기 때문에 변경에 따른 처리를 확인한다.
```
$ kubectl kudo plan status --instance=galera-operator-instance
```
Pod가 재 시작되는 시간이 있기 때문에 IN_PROGRESS 상태로 나타나며, 이 작업이 진행 중인 동안에 kubectl get pods 명령을 수행하면 추가된 수 만큼 노드가 배포가 되고, 이전에 동작하던 노드들은 한번에 하나씩 재 시작되는 것을 볼 수 있다. 반대로 NODE_COUNT 파라미터의 수를 줄이면 동작하던 노드들이 제거되는 것을 확인할 수 있다.

KUDO 및 Operator 삭제

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

Process syncronization before shuting down nodes

Scale up은 상관이 없지만 down의 경우는 노드가 제거될 때 Galera Cluster의 노드가 동기화되지 않으면 클러스터의 상태에 문제가 발생할 수 있으므로 노드가 종료되기 전에 동기화를 해야할 필요가 있다.

이를 위해서 상태를 검증하는 스크립트를 추가하고 StatefulSet의 spec에 preStop check를 수정해서 처리를 수행하도록 operator.yaml 파일의 deploy plan의 Statefulset Step 이전에 적용될 수 있도록 Step과 Task를 추가한다.

...
plans:
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          ...
          - name: node_scripts    # 추가
            tasks:
              - node_scripts
          ...
          - name: statefulset
          ...
  ...
tasks:
  ...
  - name: node_scripts    # 추가
    kind: Apply
    spec:
      resources:
        - node_scripts.yaml

상태를 검증하는 스크립트를 위한 ConfigMap 리소스인 templates/node_scripts.yaml 파일을 생성하고 아래와 같이 구성한다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Name }}-node-scripts
  namespace: {{ .Namespace }}
  wait-for-sync.sh: |
    until mysql -u root -p{{ .Params.MYSQL_ROOT_PASSWORD }} -e "SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';" | grep -q Synced 
    do
        echo "Waiting for sync"
        sleep 5
    done

그리고 이 스크립트가 StatefulSet에 정상적으로 마운트될 수 있도록 templates/statefulset.yaml에 추가한다.

        volumeMounts:
        - name: {{ .Name }}-config
          mountPath: /etc/mysql/conf.d
        - name: {{ .Name }}-datadir
          mountPath: /var/lib/mysql
        - name: {{ .Name }}-node-scripts    # 추가
          mountPath: /etc/galera/wait-for-sync.sh
          subPath: wait-for-sync.sh
      volumes:
      - name: {{ .Name }}-config
        configMap:
          name: {{ .Name }}-nodeconfig
          items:
            - key: galera.cnf
              path: galera.cnf
            - key: innodb.cnf
              path: innodb.cnf
      - name: {{ .Name }}-node-scripts    # 추가
        configMap:
          name: {{ .Name }}-node-scripts
          defaultMode: 0755

ConfigMap에서 subPath로 스크립트을 직접 마운트했다. subPath를 사용할 때 제한들이 있지만 여기서는 큰 의미가 없다.

또한 Kubernetes 클러스터를 구성하는 노드들의 장애로 부터 보호하기 위해서 분리된 노드들로 배포되도록 스케줄되어 있는지에 대한 확인이 필요하다. 이 작업은 AntiAffinity (반 선호도) 규칙을 사용해서 처리가 가능하며 테스트를 위해서 이 규칙을 비활성화 시킬 수 있다. templates/statefulset.yaml 파일에 아래와 같이 조건 섹션을 구성한다.

...
spec:
  {{ if eq .Params.ANTI_AFFINITY "true" }}
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: "app"
                operator: In
                values:
                - galera
              - key: "instance"
                operator: In
                values:
                - {{ .Name }}
          topologyKey: "kubernetes.io/hostname"
  {{ end }}
...

참고

상기 예제의 Anti-Affinity는 반 선호도에 대한 Pod Selector 개념으로 topologyKey를 kubernetes.io/hostname으로 설정해서 Pod가 존재하는 동일한 Host가 아닌 다른 곳으로 배치하나는 의미가 된다.

사용된 ANTI_AFFINITY 파라미터를 params.yaml 파일에 추가한다.

...
  - name: ANTI_AFFINITY
    description: "Enforce pod anit-affinity"
    default: False
...

지금까지의 작업으로 Operator는 Node 선호도를 관리하고 안전하게 Scale up/down이 가능하고, 외부의 클라이언트가 접근할 수 있도록 구성되었다.

이 시점에서 몇 가지 벤치마크와 클러스터를 확장하고 축소하는 동시에 모든 것이 정상적으로 작동하는지를 확인해야 한다. how to measure mysql performance in kubernetes with sysbench를 이용해서 확인이 가능하다.

Conclusion

지금까지 Galera Cluster를 구성하고 운영하는 Operator를 단계별로 확인해 보았으며, 그 과정을 통해서 KUDO에서 제공하는 내장 변수들과 Sprig 템플릿 함수를 이용해서 조건부 템플릿을 적용해 리소스 파일들을 재 사용할 수 있다는 것도 확인했다.

향후에는 시간이 허락하고 관련된 작업을 진행하게 된다면 지금까지 확인한 설치관련 (Day 1 Operation) 뿐만 아니라 운영 중 (Day 2 Operation) 에 발생할 수 있는 상황들에 대한 부분을 추가로 검토해 볼 예정이다.

참고 자료

Building your first KUDO Operator - Part 3

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 2: Nodes 참여와 서비스 생성 및 StatefulSet 구성

ccambo — Tue, 5 Jan 2021 19:17:53 +0900

How to building real world sample step by step - Part 2

게시글 참고

이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다.

PART 1에서는 부트스트랩 노드 구성

PART 3에서는 사용하지 않는 부트스트랩을 제거하고, 외부 접속을 위한 서비스를 생성하며, 안전한 Scale Up/Down 처리 구성

이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 초기 구성된 Galera Cluster의 부트스트랩을 이용해서 클러스터에 노드들이 참여할 떄 사용할 서비스와 설정등을 구성하고 StatefulSet을 구성하는 방법을 정리한다.

Cluster에 참여하는 Node를 위한 초기 설정 구성

operator.yaml 파일에 아래와 같이 firstboot_config라는 Step과 Task를 추가하도록 한다.

apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
  name: ccambo
name: galera-operator
operatorVersion: 0.1.0
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: bootstrap_config
            tasks:
              - bootstrap_config
          - name: bootstrap_service
            tasks:
              - bootstrap_service
          - name: bootstrap_deploy
            tasks:
              - bootstrap_deploy
          - name: firstboot_config    # 추가
            tasks:
              - firstboot_config
tasks:
  - name: bootstrap_config
    kind: Apply
    spec:
      resources:
        - bootstrap_config.yaml
  - name: bootstrap_service
    kind: Apply
    spec:
      resources:
        - bootstrap_service.yaml
  - name: bootstrap_deploy
    kind: Apply
    spec:
      resources:
        - bootstrap_deploy.yaml
  - name: firstboot_config      # 추가
    kind: Apply
    spec:
      resources:
        - galera_config.yaml

참고

위의 예제에서는 deploy Phase에서 개별적인 여러 개의 Step들을 정의했고, 이 Step들은 KUDO에 의해서 순차적으로 실행된다.
작업한 몇 개의 Step들은 서로 결과를 공유하는 등의 의존성이 없고, 이론적으로는 하나의 Step내에 여러 개의 Task를 지정해서 처리하는 것도 가능하고 Phase 자체를 병렬로 처리하게 하는 것도 가능하다.

위의 firstboot_config Task에서 사용할 templates/galera_config.yaml 파일을 생성하고 아래와 같이 구성한다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Name }}-nodeconfig
  namespace: {{ .Namespace }}
data:
  galera.cnf: |
    [galera]
    wsrep_on = ON
    wsrep_provider = /usr/lib/galera/libgalera_smm.so
    wsrep_sst_method = mariabackup
    wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc,{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}}
    wsrep_sst_auth = "{{ .Params.SST_USER }}:{{ .Params.SST_PASSWORD }}"
    binlog_format = ROW
  innodb.cnf: |
    [innodb]
    innodb_autoinc_lock_mode = 2
    innodb_flush_log_at_trx_commit = 0
    innodb_buffer_pool_size = 122M

노드가 Galera Cluster에 참여할 때 처리되어야 하는 두 개의 설정을 포함하는 ConfigMap을 구성한 것이다.

galera.cnf: Galera Cluster와 연동을 위한 설정
innodb.cnf: Galera 사용할 시에 InnoDB Engine에 권장되는 설정

Galera Cluster에 추가될 노드는 부트스트랩 노드의 서비스 주소와 클러스터에 포함될 노드들의 주소 정보가 필요하다.

wsrep_cluster_address 설정은 KUDO에서 지원하는 Sprig 템플릿 방식을 사용해서 다음과 같이 표현된다.

wsrep_cluster_address = gcomm://{{ .Name }}-bootstrap-svc,{{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }},{{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{end}}

노드들은 StatefulSet이 될 것이기 때문에 파드의 이름을 .Name-.OperatorName-number 형식이 될 것으로 유추할 수 있다. 여기서 .Name과 .OperatorName은 KUDO에서 생성된 변수이고 번호는 인스턴스화된 StatefulSet의 Replicas의 순서에 기반해서 Kubernetes가 할당한 값이 된다.
노드들에 접속하기 위한 Headless 서비스를 만들고 유일함을 보장하기 위해 .Name-hs 형식의 이름을 가질 것이다. 뒤에서 다시 언급할 것이기는 하지만 StatefulSet의 각 노드들에 대한 DNS 항목들은 예측 가능한 .Name-OperatorName-number.Name-hs 포맷의 이름이 된다.

위와 같은 가정을 기준으로 연결 문자열을 구성할 수 있다.

우선 부트스트랩 노드의 서비스 주소를 추가하고 다음 연결 문자열을 위해 ',' 로 연계한다.

gcomm://{{ .Name }}-bootstrap-svc,

노드는 최소한 1개 이상이 존재해야 하기 때문에 0 순번의 노드가 고정되어 있는다는 것을 알기 때문에 DNS 항목을 추가할 수 있다.

gcomm://{{ .Name }}-bootstrap-svc, {{ $.Name }}-{{ $.OperatorName }}-0.{{ $.Name }}-hs

Galera Cluster에 참여할 노드들을 구성하기 위한 NODE_COUNT 파라미터를 params.yaml파일에 아래와 같이 가장 마지막에 추가한다.

apiVersion: kudo.dev/v1beta1
parameters:
  ...
  - name: NODE_COUNT
    description: "Number of nodes to create in the cluster"
    default: "3"

그 다음은 params.yaml 에 정의된 NODE_COUNT 파라미터의 값을 참고해서 나머지 노드들을 처리할 수 있다. 이를 활용하는 Sprig 템플릿은 아래와 같다.

{{ range $i, $v := untilStep 1 (int .Params.NODE_COUNT) 1 }}, {{ $.Name }}-{{ $.OperatorName }}-{{ $v }}.{{ $.Name }}-hs{{ end }}

위의 내용은 표준 Go 템플릿의 Range 함수를 사용해서 인덱스 ($i)와 값 ($v)을 제공하고 Sprig의 untilStep 함수를 사용해서 생성된 범위 값을 전달한다. 이를 통해서 1 부터 시작해서 NODE_COUNT 까지 1 단위로 증가한 정수 목록을 받아서 사용하게 된다. NODE_COUNT가 3이라면 정수 범위는 1, 2 가 된다.

주의

params.yaml 정의된 NODE_COUNT 파라미터는 문자열로 기본처리가 되므로 사용하기 전에 (int .Params.NODE_COUNT)와 같이 int 형식으로 캐스팅해 줘야 한다.

Ranage 함수가 호출되면 변수들이 함수 내로 Scope 조정이 되기 때문에 최 상위 컨텍스트를 참조하기 위해서는 $ 접두사를 이용해서 파라미터들에 접근해야 한다.

위의 템플릿 범위 함수를 통해서 ','로 분리되는 형식의 클러스터의 모든 노드들에 대한 DNS 엔트리를 구성할 수 있다.

참고

복잡한 템플릿을 작업을 하는 것은 상당히 어려울 수 있기 때문에 테스트를 수행할 수 있는 go 코드를가지고 검증하는 것이 유용할 수 있다. 따라서 Template example 과 같이 템플릿을 stdout으로 출력하는 것과 같은 코드를 잘 활용하는 것이 좋다.

구성된 KUDO Package를 kubectl kudo package verify 명령을 통해서 논리적인 오류는 검증할 수 없겠지만 구문 오류 등을 확인할 수는 있다.

KUDO CLI의 Package 관련 명령을 통해서 새로운 파라미터들과 Task들이 올바르게 정의되었는지 등의 YAML 구성에 대한 검증도 가능하다.

Package Plans 구성 검증

$ kubectl kudo package list plans ./    # Operator 상대 경로 또는 Package 명 지정 (여기서는 로컬 디렉터리를 사용하므로 ~/kudo_sample/galera-operator/operator 경로 사용)

plans
└── deploy (serial)
    └── [phase]  deploy (serial)
        ├── [step]  bootstrap_config
        │   └── bootstrap_config
        ├── [step]  bootstrap_service
        │   └── bootstrap_service
        ├── [step]  bootstrap_deploy
        │   └── bootstrap_deploy
        └── [step]  firstboot_config
            └── firstboot_config

Package Tasks 구성 검증

$ kubectl kudo package list tasks ./

Name                    Kind    Resources               
bootstrap_config        Apply   [bootstrap_config.yaml] 
bootstrap_service       Apply   [bootstrap_service.yaml]
bootstrap_deploy        Apply   [bootstrap_deploy.yaml] 
firstboot_config        Apply   [galera_config.yaml]

Package Paramters 구성 검증

$ kubectl kudo package list parameters ./

Name                    Default Required        Immutable
IST_PORT                4568    true            false    
MYSQL_PORT              3306    true            false    
MYSQL_ROOT_PASSWORD     admin   true            false    
REPLICATION_PORT        4567    true            false    
SST_PASSWORD            admin   true            false    
SST_PORT                4444    true            false    
SST_USER                root    true            false

위의 검증을 통해서 올바르게 설정된 것이 확인 되었다면 지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-operator-instance

설치된 ConfigMap 확인

새로운 Step과 Task인 firstboot_config을 통해서 템플릿을 활용한 ConfigMap이 생성되었을 것이므로 템플릿이 제대로 동작했는지를 아래와 같이 확인해 본다.

$ kubectl get configmaps

NAME                                  DATA   AGE
galera-operator-instance-bootstrap    1      27s
galera-operator-instance-nodeconfig   2      12s

$ kubectl describe configmap galera-operator-instance-nodeconfig

Name:         galera-operator-instance-nodeconfig
Namespace:    default
Labels:       heritage=kudo
              kudo.dev/instance=galera-operator-instance
              kudo.dev/operator=galera-operator
Annotations:  kudo.dev/last-applied-configuration:
                {"kind":"ConfigMap","apiVersion":"v1","metadata":{"name":"galera-operator-instance-nodeconfig","namespace":"default","creationTimestamp":n...
              kudo.dev/last-plan-execution-uid: 64db8c01-d078-404d-8344-1a6bd98733fe
              kudo.dev/phase: deploy
              kudo.dev/plan: deploy
              kudo.dev/step: firstboot_config

Data
====
innodb.cnf:
----
[innodb]
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 0
innodb_buffer_pool_size = 122M

galera.cnf:
----
[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = mariabackup
wsrep_cluster_address = gcomm://galera-operator-instance-bootstrap-svc,galera-operator-instance-galera-operator-0.galera-operator-instance-hs,galera-operator-instance-galera-operator-1.galera-operator-instance-hs,galera-operator-instance-galera-operator-2.galera-operator-instance-hs
wsrep_sst_auth = "root:admin"
binlog_format = ROW

Events:  <none>

ConfigMap이 클러스터에 배포가 되었고, wsrep_cluster_address 정보를 통해서 NODE_COUNT 수 만큼 올바른 항목들이 생성되어 있는 것을 확인할 수 있다.

KUDO 및 Operator 삭제

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

Cluster에 참여하는 Node들이 연결할 Service 구성

클러스터에 참여할 노드들을 StatefulSet에 배포할 예정이므로 이들을 연결할 방법인 서비스를 구성해야 한다.

operator.yaml 파일에 Steps, Tasks, Resources 를 아래와 같이 추가하도록 한다.

apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
  name: ccambo
name: galera-operator
operatorVersion: 0.1.0
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: bootstrap_config
            tasks:
              - bootstrap_config
          - name: bootstrap_service
            tasks:
              - bootstrap_service
          - name: bootstrap_deploy
            tasks:
              - bootstrap_deploy
          - name: firstboot_config
            tasks:
              - firstboot_config
          - name: cluster_services    # 추가
            tasks:
              - cluster_services
tasks:
  - name: bootstrap_config
    kind: Apply
    spec:
      resources:
        - bootstrap_config.yaml
  - name: bootstrap_service
    kind: Apply
    spec:
      resources:
        - bootstrap_service.yaml
  - name: bootstrap_deploy
    kind: Apply
    spec:
      resources:
        - bootstrap_deploy.yaml
  - name: firstboot_config
    kind: Apply
    spec:
      resources:
        - galera_config.yaml
  - name: cluster_services      # 추가
    kind: Apply
    spec:
      resources:
        - hs-service.yaml

cluster_services Task에서 사용할 서비스 리소스인 templates/hs-service.yaml 파일을 생성하고 아래와 같이 구성한다.

apiVersion: v1
kind: Service
metadata:
  name: {{ .Name }}-hs
  namespace: {{ .Namespace }}
  labels:
    app: galera
    galera: {{ .Name }} 
spec:
  ports:
    - port: {{ .Params.MYSQL_PORT }}
      name: mysql
    - port: {{ .Params.SST_PORT }}
      name: sst
    - port: {{ .Params.REPLICATION_PORT }}
      name: replication
    - port: {{ .Params.IST_PORT }}
      name: ist
  clusterIP: None
  selector:
    app: galera
    instance: {{ .Name }}

ClusterIP를 가지지 않는 Headless 서비스를 생성한다. params.yaml에 정의된 Galera 구성에 필요한 모든 포트들을 설정하고 각 배포의 유일함을 보장하기 위해서 app와 instance라는 레이블을 선택하고 있다.

Headless Service인 이유는 Load balancing 주소가 필요하지 않고 StatefulSet의 각 노드에 때한 DNS 항목만 필요하기 때문이다.

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-operator-instance

설치된 Service 확인

$ kubectl get services

NAME                                     TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                               AGE
galera-operator-instance-bootstrap-svc   ClusterIP   None         <none>        3306/TCP,4444/TCP,4567/TCP,4568/TCP   25s
galera-operator-instance-hs              ClusterIP   None         <none>        3306/TCP,4444/TCP,4567/TCP,4568/TCP   9s
kubernetes                               ClusterIP   10.96.0.1    <none>        443/TCP                               28d

$ kubectl describe service galera-operator-instance-hs

Name:              galera-operator-instance-hs
Namespace:         default
Labels:            app=galera
                  galera=galera-operator-instance
                  heritage=kudo
                  kudo.dev/instance=galera-operator-instance
                  kudo.dev/operator=galera-operator
Annotations:       kudo.dev/last-applied-configuration:
                    {"kind":"Service","apiVersion":"v1","metadata":{"name":"galera-operator-instance-hs","namespace":"default","creationTimestamp":null,"label...
                  kudo.dev/last-plan-execution-uid: 89dc7134-f4ae-4fee-9fbf-ecee27b5a311
                  kudo.dev/phase: deploy
                  kudo.dev/plan: deploy
                  kudo.dev/step: cluster_services
Selector:          app=galera,instance=galera-operator-instance
Type:              ClusterIP
IP:                None
Port:              mysql  3306/TCP
TargetPort:        3306/TCP
Endpoints:         <none>
Port:              sst  4444/TCP
TargetPort:        4444/TCP
Endpoints:         <none>
Port:              replication  4567/TCP
TargetPort:        4567/TCP
Endpoints:         <none>
Port:              ist  4568/TCP
TargetPort:        4568/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

서비스가 클러스터에 생성되었고, 올바른 Selector를 사용하고 있고, 역시 노드가 배포되지 않았기 때문에 Endpoints가 설정되지 않았다는 것을 확인할 수 있다.

KUDO 및 Operator 삭제

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

Cluster에 참여할 Node 구성을 위한 StatefulSet 설정

위에서 클러스터에 참여할 노드들을 위한 ConfigMap과 Service가 정의되었기 때문에 StatefulSet을 operator.yaml에 Step과 Task로 설정한다.

apiVersion: kudo.dev/v1beta1
appVersion: 0.1.0
kubernetesVersion: 0.16.0
kudoVersion: 0.17.2
maintainers:
- email: ccambo@gmail.com
  name: ccambo
name: galera-operator
operatorVersion: 0.1.0
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: bootstrap_config
            tasks:
              - bootstrap_config
          - name: bootstrap_service
            tasks:
              - bootstrap_service
          - name: bootstrap_deploy
            tasks:
              - bootstrap_deploy
          - name: firstboot_config
            tasks:
              - firstboot_config
          - name: cluster_services
            tasks:
              - cluster_services
          - name: statefulset    # 추가
            tasks:
              - statefulset
tasks:
  - name: bootstrap_config
    kind: Apply
    spec:
      resources:
        - bootstrap_config.yaml
  - name: bootstrap_service
    kind: Apply
    spec:
      resources:
        - bootstrap_service.yaml
  - name: bootstrap_deploy
    kind: Apply
    spec:
      resources:
        - bootstrap_deploy.yaml
  - name: firstboot_config
    kind: Apply
    spec:
      resources:
        - galera_config.yaml
  - name: cluster_services
    kind: Apply
    spec:
      resources:
        - hs-service.yaml
  - name: statefulset      # 추가
    kind: Apply
    spec:
      resources:
        - statefulset.yaml

주의

아래의 StatefulSet 설정은 실제 mariadb가 설치되어 동작하는 노드 컨테이너를 생성하는 것이기 때문에 Persistent Volume 구성이 필요하지만 샘플에서는 Kubernetes에 기본 생성되어 있는 Default Storage Class를 이용하는 것으로 되어 있고 Persistent Volume에 대한 언급이 없다.

Kubernetes Cluster를 구성하고 나면 (Test는 Openstack 베이스로 구성) Default Storage가 존재하지 않고, Galera Cluster에 여러 개의 Node들이 참여를 하고 각기 Persitentn Volume을 사용해야 하기 때문에 별도로 NFS (Network File System) 서버를 CentOS 8에 설치하고 Kubernetes에 Dynamic NFS Client Provisioner와 Storage Class를 구성한 것으로 적용했다.

참고 문서

CentOS 8에 NFS 서버 구성하기

Kubernetes에 NFS Client Provisioner 구성하기

이제 statefulset Task에서 사용할 리소스인 templates/statefulset.yaml 파일을 생성하고 아래와 같이 구성한다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: {{ .Name }}-{{ .OperatorName }}
  namespace: {{ .Namespace }}
  labels:
    galera: {{ .OperatorName }}
    app: galera
    instance: {{ .Name }}
  annotations:
    reloader.kudo.dev/auto: "true"
spec:
  selector:
    matchLabels:
      app: galera
      galera: {{ .OperatorName }}
      instance: {{ .Name }}
  serviceName: {{ .Name }}-hs
  replicas: {{ .Params.NODE_COUNT }}
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: galera
        galera: {{ .OperatorName }}
        instance: {{ .Name }}
    spec:
      initContainers:
      # Stop the image bootstrap script from trying to set up single master
      - name: {{ .Name }}-init
        image: busybox:1.28
        command: ['sh', '-c', 'set -x; if [ ! -d /datadir/mysql ]; then mkdir /datadir/mysql; fi']
        volumeMounts:
          - name: {{ .Name }}-datadir
            mountPath: "/datadir"
      containers:
      - name: mariadb
        image: mariadb:latest
        args:
        - "--ignore_db_dirs=lost+found"
        env:
          # Use secret in real usage
        - name: MYSQL_ROOT_PASSWORD
          value: {{ .Params.MYSQL_ROOT_PASSWORD }}
        ports:
        - containerPort: {{ .Params.MYSQL_PORT }}
          name: mysql
        - containerPort: {{ .Params.SST_PORT }}
          name: sst
        - containerPort: {{ .Params.REPLICATION_PORT }}
          name: replication
        - containerPort: {{ .Params.IST_PORT }}
          name: ist
        livenessProbe:
          exec:
            command: ["mysqladmin", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          exec:
            # Check we can execute queries over TCP (skip-networking is off).
            command: ["mysql", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
          timeoutSeconds: 1
        volumeMounts:
        - name: {{ .Name }}-config
          mountPath: /etc/mysql/conf.d
        - name: {{ .Name }}-datadir
          mountPath: /var/lib/mysql
      volumes:
      - name: {{ .Name }}-config
        configMap:
          name: {{ .Name }}-nodeconfig
          items:
            - key: galera.cnf
              path: galera.cnf
            - key: innodb.cnf
              path: innodb.cnf
  volumeClaimTemplates:
    - metadata:
        name: {{ .Name }}-datadir
      spec:
        accessModes: [ "ReadWriteOnce" ]
        resources:
          requests:
            storage: {{ .Params.VOLUME_SIZE }}

위의 StatefulSet 구성에는 몇 가지 주의해야할 부분들이 존재한다.

mySQL 데이터 디렉터리를 /var/lib/mysql 경로로 Persistent Volumes를 사용하고, /etc/mysql/conf.d에 configMap의 key/path 정보를 이용해서 설정 파일들을 시작할 때 사용할 수 있도록 마운트한다.

  volumeMounts:
  - name: {{ .Name }}-config
    mountPath: /etc/mysql/conf.d
  - name: {{ .Name }}-datadir
    mountPath: /var/lib/mysql
volumes:
- name: {{ .Name }}-config
  configMap:
    name: {{ .Name }}-nodeconfig
    items:
      - key: galera.cnf
        path: galera.cnf
      - key: innodb.cnf
        path: innodb.cnf

StatefulSet이므로 각 Replica들에 필요한 VolumeClaims들을 추가하는 VolumeClaimTemplate를 정의한다.

volumeClaimTemplates:
  - metadata:
      name: {{ .Name }}-datadir
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: {{ .Params.VOLUME_SIZE }}

MariaDB 컨테이너 이미지는 컨테이너가 처음 시작될 때 단일 노드 인스턴스를 설정하기 위한 부트스트랩 스크립트를 가지고 있다. 샘플에서는 이를 재 정의해서 /var/lib/mysql 경로를 확인해서 데이터베이스가 이미 구성되었다면 부트스트랩 과정을 생략하도록 한다.

init container를 이용해서 데이터 디렉터리를 마운트하고 스크립트가 실행되기 전에 디렉터리를 생성해서 ConfigMap에서 생성한 설정에 따라서 Galera 프로세스가 올바르게 실행되고, 클러스터에 동기화될 수 있도록 재 정의한다.

initContainers:
# Stop the image bootstrap script from trying to set up single master
- name: {{ .Name }}-init
  image: busybox:1.28
  command: ['sh', '-c', 'set -x; if [ ! -d /datadir/mysql ]; then mkdir /datadir/mysql; fi']
  volumeMounts:
    - name: {{ .Name }}-datadir
      mountPath: "/datadir"

NODE_COUNT 파라미터를 이용해서 StatefulSet내에 포함되어야할 Replica의 수를 설정했다.

replicas: {{ .Params.NODE_COUNT }}

PART 1 에서 정의했던 포트 관련 파라미터들을 사용해서 노드들의 mySQL에서 사용할 포트들을 정의했다.

ports:
  - containerPort: {{ .Params.MYSQL_PORT }}
    name: mysql
  - containerPort: {{ .Params.SST_PORT }}
    name: sst
  - containerPort: {{ .Params.REPLICATION_PORT }}
    name: replication
  - containerPort: {{ .Params.IST_PORT }}
    name: ist

새롭게 사용된 VOLUME_SIZE 라는 파라미터를 params.yaml에 추가하도록 한다.

apiVersion: kudo.dev/v1beta1
parameters:
  - name: SST_USER
    description: "User to perform SST as"
    default: "root"
  - name: SST_PASSWORD
    description: "Password for SST user"
    default: "admin"
  - name: MYSQL_PORT
    description: "MySQL port"
    default: "3306"
  - name: SST_PORT
    description: "SST port"
    default: "4444"
  - name: REPLICATION_PORT
    description: "Replication port"
    default: "4567"
  - name: IST_PORT
    description: "IST port"
    default: "4568"
  - name: MYSQL_ROOT_PASSWORD
    description: "MySQL root password"
    default: "admin"
  - name: NODE_COUNT
    description: "Number of nodes to create in the cluster"
    default: "3"
  - name: VOLUME_SIZE     # 추가
    description: "Size of persistent volume"
    default: "10M"

테스트를 위한 것이기 때문에 아주 작은 기본 크기를 추가했다.

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다. 테스트를 위한 것이기 때문에 params.yaml 파일에 정의된 NODE_COUNT 파라미터의 기본 값을 1로 변경하고 진행해도 상관없다. StatefulSet은 실제 노드 및 MariaDB도 구성하므로 시간이 오래 걸릴 수 있다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-operator-instance

설치된 Pod 확인
```
$ kubectl get pods
```
실행 중인 클러스터에 모든 인스턴스들이 생성된 것을 확인할 수 있다. 하나의 파드를 선택해서 로그 정보를 통해서 Galera가 정상적으로 동작하고 있는지를 확인한다.
```
$ kubectl logs galera-operator-instance-galera-operator-0
```

KUDO 및 Operator 삭제

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

Conclusion

지금까지의 작업으로 StatefulSet이 올바르게 설정되었고, 모든 노드가 Galera Cluster에 참여하고 있다는 것을 확인할 수 있다.

PART 3 에서는 이제 필요하지 않은 부트스트랩 노드를 제거하고, 클러스터를 외부에서 연결할 수 있도록 설정하고, 운영되는 동안 안정적으로 Scale Up/Down 할 수 있도록 기능을 추가할 것이다.

참고 자료

Building your first KUDO operator - Part 2

[Kubernetes-Storage] CentOS 8에 Dynamic NFS Client Provisioner 구성하기

ccambo — Tue, 5 Jan 2021 19:03:27 +0900

[Kubernetes - Storage] How to configure a dynamic storage provisioner for Kubernetes using a network file system on CentOS 8

참고

이 문서는 Network File System을 CentOS 8에 설치하여 NFS Server로 운영하면서 Kubernetes의 PVC (Perssistent Volume Claim) - StorageClass - NFS 로 연동되는 PV (Persistent Volume)를 자동으로 구성하는 방법을 정리한 것입니다.

CentOS 8에 설치되는 NFS를 Kubernetes의 Dynamic Storage Provisioning 으로 활용해서 PV (Persistent Volume)를 구성해 본다.

Network file system 구성

NFS 서버를 구성하는 부분은 CentOS 8에 NFS 설정 및 테스트 글을 참고해서 진행하도록 한다.

NFS 서버는 물리적인 머신으로 네트워크 상에 존재하면 되며, Network을 통해서 Kubernetes Cluster에서 NFS 서버로 접근할 수 있어야 한다.

위에서 구성한 NFS 서버를 사용할 수 있도록 처리하는 NFS Provisioner Pod가 Kubernetes Cluster에 PV를 배포할 수 있도록 하기 위해서는 필요한 권한 설정이 필요하다. 따라서 PV를 배포할 수 있도록 ClusterRole, ClusterRoleBinding, Role, RoleBinding 설정을 가지는 Service Account를 생성해 줘야 한다.

Service Account 생성

서비스 계정을 생성한다. (serviceaccount.yaml)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-provisioner

아래의 명령을 사용해서 Kubernetes에 적용한다.

$ kubectl apply -f serviceaccount.yaml

ClusterRole 생성

Cluster를 위한 역할을 생성한다. (clusterrole.yaml)

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["get"]
  - apiGroups: ["extensions"]
    resources: ["podsecuritypolicies"]
    resourceNames: ["nfs-provisioner"]
    verbs: ["use"]

아래의 명령을 사용해서 Kubernetes에 적용한다.

$ kubectl apply -f clusterrole.yaml

ClusterRoleBinding 생성

Cluster를 위한 역할 바인딩을 생성한다. (clusterbinding.yaml)

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-provisioner-runner
  apiGroup: rbac.authorization.k8s.io

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: nfs-provisioner-otherRoles
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: nfs-provisioner-otherRoles
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: default    # provisioner가 배포될 네임스페이스
roleRef:
  kind: Role
  name: nfs-provisioner-otherRoles
  apiGroup: rbac.authorization.k8s.io

아래의 명령을 사용해서 Kubernetes에 적용한다.

$ kubectl apply -f clusterbinding.yaml

NFS Client Provisioner 생성

Provisioner는 PVC와 StorageClass를 통해서 자동으로 PV를 구성해 주는 역할을 담당한다.

NFS 서버를 Dynamic Storage Provisioning으로 사용할 수 있도록 NFS Client Dynmaic Provisioner Pod를 배포하도록 구성한다. (deployment-nfs.yaml)

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccount: nfs-provisioner
      containers:
        - name: nfs-client-provisioner
          image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 10.0.1.20
            - name: NFS_PATH
              value: /data/NFS
      volumes:
        - name: nfs-client-root
          nfs:
            server: 10.0.1.20
            path: /data/NFS

아래의 명령을 사용해서 Kubernetes에 적용한다.

$ kubectl apply -f deployment-nfs.yaml

StorageClass 생성

NFS 연계를 위한 StorageClass를 생성한다. (storageclass-nfs.yaml)

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: managed-nfs-storage 
provisioner: fuseim.pri/ifs

아래의 명령을 사용해서 Kubernetes에 적용한다.

$ kubectl apply -f storageclass-nfs.yaml

Statefulset 생성 및 PV 검증

NFS 연계를 검증하기 위한 Statefulset을 생성하고 PV의 생성여부를 검증한다. (statefulset-nfs.yaml)

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx1"
  replicas: 1
  selector:
    matchLabels:
      app: nginx1
  volumeClaimTemplates:
  - metadata:
      name: test 
      annotations:
        volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 2Gi 
  template:
    metadata:
     labels:
       app: nginx1
    spec:
     serviceAccount: nfs-provisioner
     containers:
     - name: nginx1
       image: nginx:1.7.9
       volumeMounts:
       - mountPath: "/mnt"
         name: test

아래의 명령을 사용해서 Kubernetes에 적용한다.

$ kubectl apply -f statefulset-nfs.yaml

Dynamic Provisioner Pod 실행 상태 확인

$ kubectl get all
NAME                                       READY   STATUS    RESTARTS   AGE
pod/nfs-pod-provisioner-5f8686f8dd-bfkgz   1/1     Running   0          8m51s

주의

만일 어느 정도의 시간이 지나도 STATUS가 ContainerCreating 또는 Pending 이라고 나오는 경우는 NFS 설정에 따라서 오류가 발생했을 수 있다.
kubectl describe <pod name>으로 확인해 보면 오류 상황을 알 수 있다.

connection timeout: NFS 서버의 IP에 접근이 안되는 경우이므로 실제 접근 가능한 IP인지 확인해야 한다. IP가 맞다면 NFS 서버에서 /etc/exports 설정을 다시 확인해 보고 sudo exportfs -ra를 수행하고 다시 처리한다.

access denied by server: NFS 서버에는 접근을 했지만 권한이 없는 경우이므로 NFS 서버에서 sudo chmod 666 <nfs directory>를 수행하고 다시 처리한다.

wrong fs type, bad option...: NFS 관련 패키지가 설치되지 않았을 경우이므로 클러스터의 각 노드에 sudo dnf install -y nfs-utils를 수행하고 다시 처리한다.

그 이외의 오류가 발생했다면 관련된 메시지를 통해서 원인을 파악하고 해결해야 한다.

PVC (Persistent Volume Claim)를 통한 PV 생성 검증

StorageClass를 이용해서 간단한 테스트를 위한 PVC를 구성한다. (fns-pvc.yaml)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc-test
spec:
  storageClassName: managed-nfs-storage # StorageClass 명
  accessModes:
    - ReadWriteMany # 생성될 PV에 적용할 사용 모드
  resources:
    requests:
      storage: 10Mi  # 생성될 PV 크기

참고

사용할 수 있는 AccessMode는 다음과 같다.

ReadWriteOnce (RWO): 하나의 Pod에만 마운트되고 하나의 Pod에서만 읽고 쓰기 가능

ReadWriteMany (RWX): 여러 개의 Pod에 마운트 가능하고 여러 개의 Pod에서 읽고 쓰기 가능

ReadOnlyMany (ROX): 여러 개의 Pod에 마운트 가능하고 여러 개의 Pod에서 읽기는 가능하지만 쓰기는 불가능

테스트이므로 작은 크기로 설정하고 Kubernete에 적용하고 확인한다.

$ kubectl apply -f nfs-pvc.yaml
persistentvolumeclaim/nfs-pvc-test created

$ kubectl get pv,pvc
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS         REASON   AGE
persistentvolume/pvc-2dca7757-d8c1-4e80-8a21-f1d661d69b19   10Mi       RWX            Delete           Bound    default/nfs-pvc-test   managed-nfs-storage            7s

NAME                                  STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         AGE
persistentvolumeclaim/nfs-pvc-test    Bound     pvc-2dca7757-d8c1-4e80-8a21-f1d661d69b19   10Mi       RWX            managed-nfs-storage   7s

NFS 서버에서 실제 생성된 정보 확인

PVC를 통해서 생성된 PV를 확인했으므로 실제 NFS 서버에도 생성이 되었는지 확인해 보면 된다.

# NFS 서버에서 공유 디렉터리 확인
$ sudo ls /data/NFS
default-nfs-pvc-test-pvc-2dca7757-d8c1-4e80-8a21-f1d661d69b19

실제 PVC와 PV 관련된 이름으로 유추할 수 있는 디렉터리가 생성된 것을 확인할 수 있다.

Deploy된 Pod의 Volume Mount 확인

실제 사용할 애플리케이션 Pod에서도 정상적으로 동작하는지를 확인하기 위해서 간단한 샘플을 구성해 보도록 한다. (nfs-test-app.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ccambo-nfs-test
  labels:
    app: nginxnfs
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginxnfs
  template:
    metadata:
      labels:
        app: nginxnfs
    spec:
      containers:
      - name: nginxnfs
        image: nginx:latest
        ports:
        - containerPort: 80
        volumeMounts:                    
          - mountPath: /nfs
            name: nfsvolume          
      volumes:                           
      - name: nfsvolume
        persistentVolumeClaim:           
          claimName: nfs-pvc-test

위의 YAML을 Kubernetes에 적용하고 확인한다.

$ kubectl apply -f nfs-test-app.yaml
deployment.apps/ccambo-nfs-test created

# Deployment 확인
$ kubectl get deploy
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
ccambo-nfs-test           0/1   1            0           15s
nfs-client-provisioner    1/1   1            1           75m

# Pod 확인
$ kubectl get pods
NAME                                     READY   STATUS    RESTARTS   AGE
ccambo-nfs-test-9d7fc4c6c-25xr4            1/1   Running   0          39s
ccambo-nfs-test-9d7fc4c6c-js5pl            1/1   Running   0          39s
nfs-client-provisioner-775496b5bb-vpglp    1/1   Running   0          82m

생성된 두 개의 Pod 중에 하나의 Pod에 접속해서 마운트된 경로에서 테스트용 파일을 생성한다.

$ kubectl exec -it ccambo-nfs-test-9d7fc4c6c-25xr4 -- /bin/bash

# 연결된 Pod에서 마운트된 /nfs 디렉터리로 이동해서 테스트용 파일을 하나 생성한다.
> cd /nfs
> echo "This is NFS test" > /nfs/test.log
> cat /nfs/test.log
This is NFS test

다른 Pod에 연결해서 마운트된 /nfs 디렉터리에 파일이 존재하는지 확인한다.

$ kubectl exec -it ccambo-nfs-test-9d7fc4c6c-js5pl -- /bin/bash

# 연결된 Pod에서 마운트된 /nfs 디렉터리로 이동해서 테스트용 파일을 확인한다.
> ls /nfs
test.log

> cat /nfs/test.log
This is NFS test

위의 테스트와 같이 생성된 POD가 동일한 NFS를 PV로 마운트해서 사용하고 있는 것을 확인할 수 있다.

[CentOS - NFS] CentOS 8에 NFS 설정 및 테스트

ccambo — Thu, 31 Dec 2020 10:42:18 +0900

How to set up a network file system on CentOS 8

클라이언트 / 서버 파일 시스템이라고도 부르는 NFS (Network File System)는 클라이언트가 네트워크를 통해 다른 사용자와 디렉토리 및 파일을 공유하고 상호 작용할 수 있도록 마치 로컬에 마운트된 것 처럼 네트워크를 통해 로컬 파일 시스템을 내보내는데 널리 사용되는 교차 플랫폼 및 분산 파일 시스템 프로토콜이다.

두 대의 머신에 CentOS 8을 설치하고 NFS 설정을 통해서 클라이언트 / 서버간의 파일 공유를 검증해 본다.

NFS Server 구성

NFS (Network File System)는 네트워크 상의 다른 머신에서 파일 시스템으로 마운트하여 사용할 수 있도록 공유하는 방법이다.

NFS 서버 패키지 설치

# 이미 설치되어 있는 경우는 최신 버전으로 업그레이드 된다. (nfs-utils-1:2.3.3-35.el8.x86_64)
$ sudo dnf install -y nfs-utils

NFS 서버 Exports 설정

공유할 디렉터리를 구성한다.
```
$ sudo mkdir /data/NFS
```
NFS 서버의 특정 IP 호스트 접속을 허용하는 설정을 구성한다. (/etc/exports)
```
$ sudo vi /etc/exports

/data/NFS 10.0.1.*(rw,sync,no_root_squash)
```
주의
- 위의 /etc/exports 파일 내에 옵션을 설정할 때는 빈 공백이 없이 붙여서 작성해야 한다.
- 10.0.1.* 는 10.0.1.0/24 와 같은 의미로 어떤 것을 사용해도 좋다.
사용할 수 있는 옵션들은 다음과 같다.
- rw: 읽기 및 쓰기 가능
- ro: 읽기만 가능
- secure: 클라이언트 마운트 요청시 포트를 1024 이하로 지정
- noaccess: 액세스 거부
- root_squash: 클라이언트의 root 사용자가 서버의 root 권한을 획득하는 것을 방지
- no_root_squach: 클라이언트의 root 사용자와 서버의 root를 동일하게 설정
- sync: 파일 시스템이 변경되면 즉시 동기화
- all_sqash: root를 제외하고 서버와 클라이언트의 사용자를 동일한 권한으로 설정
- no_all_sqash: root를 제외하고 서버와 클라이언트의 사용자들을 하나의 권한을 가지도록 설정

NFS 실행

# NFS Server 서비스 시작
$ sudo systemctl start nfs-server.service

# NFS Server 서비스가 재 부팅시 자동으로 시작될 수 있도록 설정
$ sudo systemctl enable nfs-server.service
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-server.service → /usr/lib/systemd/system/nfs-server.service.

# NFS Server 서비스 상태 확인
$ sudo systemctl status nfs-server.service
● nfs-server.service - NFS server and services
  Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
  Drop-In: /run/systemd/generator/nfs-server.service.d
          └─order-with-mounts.conf
  Active: active (exited) since Wed 2020-12-30 10:04:37 UTC; 1min 21s ago
Main PID: 13041 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 23978)
  Memory: 0B
  CGroup: /system.slice/nfs-server.service

12월 30 10:04:37 ccambo-nfs systemd[1]: Starting NFS server and services...
12월 30 10:04:37 ccambo-nfs systemd[1]: Started NFS server and services.

위의 명령을 통해서 NFS 서버 서비스를 실행하거나 NFS 공유를 마운트하는데 필요한 다른 서비스들 (nfsd, nfs-idmapd, rpcbind, rpc.mountd, lockd, rpc.startd, rpc.rquotad, rpc.idmapd)은 자동으로 시작된다.

NFS 서버의 구성 파일들은 아래와 같다.

/etc/nfs.conf: NFS Daemon 및 도구에 대한 기본 구성 파일
/etc/nfsmount.conf: NFS 마운트 구성 파일

NFS 공유 디렉터리 정상 동작 확인

NFS로 공유할 디렉터리들이 정상적으로 동작하는지 확인은 아래와 같이 수행한다.
```
$ sudo exportfs -v
/data/NFS       10.0.1.*(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)

$ sudo exportfs -arv
exporting 10.0.1.*:/data/NFS

$ sudo exportfs -s
/data/NFS  10.0.1.*(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
```
옵션은 다음과 같다.
- a: 모든 공유 디렉터리를 내보내거나 내보내지 않는다.
- r: 모든 공유 디렉터리를 다시 내보내고, /var/lib/nfs/etab과 /etc/exports 파일, 그리고 /etc/exports.d 디렉터리 밑의 모든 파일들에 대한 동기화 한다.
- v: 자세한 출력
- s: 현재 내보내기 대상 리스트 출력
방화벽 처리

firewalld 서비스가 동작 중이라면 NFS 서버 서비스에 필요한 포트들 (mountd, nfs, rpc-bind)을 열어 주어야 한다. (CentOS 8에는 기본 설치되어 있지 않다)
```
$ sudo firewall-cmd --permanent --add-service=nfs
$ sudo firewall-cmd --permanent --add-service=rpc-bind
$ sudo firewall-cmd --permanent --add-service=mountd

$ sudo firewall-cmd --reload
```

참고

실제 여러 가지 환경에서 NFS 서버에 연결을 하다보면 (예를 들면 Kubernetes NFS Dynamic Provisiner 설정 등) 다양한 오류가 발생할 수 있다.

접근 권한 관련: sudo chmod 666 <nsf directory>로 권한을 지정해 준다.

여기까지 작업으로 NFS 서버 설정은 완료되었다. 이제 클라이언트를 구성해서 접속 여부를 검증하면 된다.

NFS 클라이언트 구성

NFS 패키지 설치

$ sudo dnf install -y nfs-utils nfs4-acl-tools

Mount 후 정상 동작 확인

아래의 명령으로 NFS 서버의 공유 가능한 정보를 확인한다.

# NFS Server에 내보내기된 목록 확인
$ showmount -e 10.0.1.20

아래의 명령으로 공유된 NFS 디렉터리를 마운트 한다.

# 로컬 마운트 경로 생성
$ sudo mkdir -p /data/mountNFS

# NFS 공유 디렉터리를 로컬 경로로 마운트
$ sudo mount -t nfs 10.0.1.20:/data/NFS /data/mountNFS

# 마운트 확인
$ mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
10.0.1.20:/data/NFS on /data/mountNFS type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.117,local_lock=none,addr=10.0.1.20)

# NFS 서버에서 파일 생성
$ sudo touch /data/NFS/file-created-on-server.txt

# 클라이언트에서 파일 생성 확인
$ ls -l /data/mountNFS
합계 0
-rw-r--r--. 1 root root 0 12월 30 10:53 file-created-on-server.txt

# 클라이언트에서 파일 생성
$ sudo touch /data/mountNFS/fil-created-on-client.txt

# NFS 서버에서 파일 생성 확인
$ ls -l /data/NFS
합계 0
-rw-r--r--. 1 root root 0 12월 30 10:55 file-create-on-client.txt
-rw-r--r--. 1 root root 0 12월 30 10:53 file-created-on-server.txt

참고

마운트를 하는 중에 mount.nfs: access denied by server while mounting 10.0.1.20:/data/NFS와 같은 오류가 발생할 수 있다.
이 오류를 확인하기 위해서는 NFS 서버에서 sudo tail -f /var/log/messages 명령을 수행하면 rpc.mountd[13025]: refused mount request from 10.0.1.117 for /data/NFS (/data/NFS): unmatched host 라는 오류를 확인할 수 있다.
이 경우는 NFS도 도메인 이름과 관련이 있기 때문에 /etc/hosts 파일에 요청한 IP에 대한 도메인 설정이 있는지를 확인하고 도메인 설정된 호스트 명을 /etc/exports 파일에 추가해 주면 된다.
도메인 이름도 없는데 동일한 오류가 계속된다면 10.0.1.* 설정을 10.0.1.0/24로 변경하고 다시 exportfs -a 명령을 수행하면 된다.

재 부팅시 마운트 설정

/etc/fstab 에 마운트에 대한 설정을 추가해서 재 부팅해도 동작할 수 있도록 설정한다.
```
# fstab 등록
$ echo "10.0.1.20:/data/NFS     /data/mountNFS  nfs     defaults 0 0">>/etc/fstab

# 등록 확인
$ cat /etc/fstab
```
Unmount 처리
```
$ unmount /data/mountNFS
```
주의

위의 명령을 /data/mountNFS 경로에서 실행하면 /data/mountNFS: device is busy라는 메시지가 출력되고 처리되지 않는다. 따라서 다른 경로로 이동해서 처리하면 된다.

참고 자료

How to set up NFS Server and Client on CentOS 8

[Git] macOS에서 현재 상태로 원격 저장소 재 구성하기

ccambo — Tue, 29 Dec 2020 02:56:55 +0900

[Git] How to initialize remote repository

주의

아래의 정리된 명령들을 수행하면 원격 저장소의 데이터가 모두 초기화되므로 미리 백업등을 해 놓고 진행해야 한다.

가장 기본적인 방법은 새로운 Repository를 만들고 다시 remote server 연결하는 것이지만, Repository에서 많은 수의 파일을 삭제하고 현재 상태로 Repository를 재 구성(초기화)해야 할 경우도 존재한다.

여기서는 기존에 계속 사용 중이던 Remote Repository를 현재 상태로 Repository를 재 구성하는 경우를 정리한다. (전체적인 과정은 초기 git 구성하는 방식과 크게 다르지 않다)

로컬에 존재하는 프로젝트 디렉터리에서 숨겨진 .git 서브 디렉터리를 삭제한다.
```
# .git 디렉터리 삭제
$ rm -rf ./.git
```
git init 을 다시 수행해서 git를 초기화 한다.
```
# git 초기화
$ git init
```

현재 상태로 commit을 진행한다.

# 현재 경로의 모든 파일/디렉터리들 추가
$ git add .

# 추가된 정보들에 대한 커밋
$ git commit -m "<commit comment>"

remote repository를 연결한다.
```
# remote repository 연결
$ git remote add origin <url>

# 연결된 remote repository 확인
$ git remote -v
```
참고

만일 github의 여러 계정을 사용하는 경우는 macOS에서 여러 개의 Github.com 계정 사용하기 글에서와 같이 SSH를 사용한다면 ssh config 파일 설정 과 사용방법을 참고해서 <url>을 맞춰줘야 한다.

현재 상태를 push한다.

$ git push --force --set-upstream origin master

참고

Branch를 새로 생성해서 push한 후에 기존 Branch를 삭제해도 된다.
branch 삭제는 Repository의 Branch 선택에서 Show all branches를 클릭해서 branch 관리 화면에서 default를 새로 생성한 branch로 변경하고 기존 branch의 휴지통 icon을 눌러서 삭제하면 된다.

참고 자료

github docs

[Git] macOS에서 여러 개의 Github.com 계정 사용하기

ccambo — Mon, 28 Dec 2020 00:29:55 +0900

[Git] How to use multiple account of github on macOS

github에 여러 개의 계정이 있고, Visual Studo Code나 터미널에서 사용하다 보면 Permission error 나 User Denied 등의 오류를 만날 수 있다.

이런 문제들을 해결하고 SSH Key를 이용해서 여러 개의 github 계정을 설정하고 사용하는 방법을 정리해 놓는다.

문제점

단일 계정만 사용할 경우라면 pull, push를 처음할 때 계정 권한을 확인하는 프롬프트가 뜨고, 계정 정보를 입력하면 키 체인에 보관되기 때문에 다음 부터는 입력하지 않아도 정상적으로 처리가 된다.

그러나 또 하나의 계정을 더 만들어서 Repository 동기화를 하려고 하면 키 체인에 저장된 정보 때문에 이전 계정의 정보를 사용하기 때문에 계속 오류가 발생하게 된다.

해결 방법

해결 방법은 간단하다. 각 계정에 대한 SSH Key 생성하고 github에 등록해서 관리하면 각 계정별 Repository에 대한 걱정 없이 편리하게 사용할 수 있다.

우선 Remote Repository를 확인해 보도록 하자.

# 현재 설정된 원격 저장소 보기
$ git remote -v

# 현재 저장소 설정 조회 (저장소 루트 폴더에 .git/config 파일에 정보가 존재한다)
$ git config --list

기존에 입력되어 있는 키 체인 정보 삭제

Spotlight 검색(F12) 등으로 키체인 접근 앱 실행

![Spotlight 검색](http://ccambo.github.io/images/content /spotlight_key_chain_access.png?featherlight=false)
키체인 접근 앱에서 로그인을 선택하고 github.com을 찾아서 삭제

참고

macOS는 SSH 키들을 ~/.ssh 디렉터리에 관리한다.

이후 작업은 모두 이 경로에서 처리하는 것을 기준으로 한다.

github는 계정당 하나의 SSH Key만 등록 가능하므로 사용할 계정만큼 생성하고 처리해 주면 된다.

이 문서에서는 ccambo와 morris라는 두 개의 계정을 사용하는 것으로 가정한다.

SSH Key 생성 및 등록

ssh key 생성

$ ssh-keygen -t rsa -b 4096 -C "ccambo@gmail.com"

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/morris/.ssh/id_rsa):   id_rsa_ccambo  # 생성할 파일 명 입력 (아니면 그냥 Enter key, 이 경우는   id_rsa라는 기본 파일로 생성됨)
Enter passphrase (empty for no passphrase): # 비밀번호 설정할 경우 입력   (아니면 Enter key)
Enter same passphrase again: # 비밀번호 설정할 경우 입력 (아니면 Enter key)
...

ssh key macOS에 등록

# ssh agent 데몬으로 동작 시키기 (이 명령은 한번만 실행)
$ eval "$(ssh-agent -s)"
Agent pid 14194

# SSH Key 추가
$ ssh-add -K ~/.ssh/id_rsa_ccambo
Identity added: /Users/<사용자 계정>/.ssh/id_rsa_ccambo (ccambo@gmail.   com)

위의 단계를 사용할 계정 갯수만큼 반복한다.

이 문서의 샘플 기준이라면 아래와 같이 네 개의 파일이 생성되어야 한다.

id_rsa_ccambo: ccambo 계정 비밀 키
id_rsa_ccambo.pub: ccambo 계정 공개 키
id_rsa_morris: morris 계정 비밀 키
id_rsa_morris.pub: morris 계정 공개 키

github에 공개키 등록

생성한 계정별 공개키 파일의 내용을 github에 등록한다.

github.com에 로그인 하면 우측 상단의 계정 이미지를 클릭하고 펼쳐진 서브 메뉴들에서 Settings 를 선택한다.

계정 Settings 화면의 좌측 메뉴에서 SSH and GPG keys 메뉴를 클릭하면 SSH Keys 화면의 우측 상단에 New SSH Key 버튼을 눌러서 다음과 같이 설정한다.

Title: 식별할 수 있는 아무 이름이든 지정한다. (여기서는 ccambo SSH)
Key: 생성된 id_rsa_ccambo.pub파일의 내용을 그대로 복사해 넣는다.

참고
기존에 사용하던 SSH Key각 존재할 수 있다. 여러 개를 생성해서 (Title까지 동일해도 상관없다) 사용할 수 있지만, 가능하면 하나의 SSH Key만 유지하는 것이 좋다. 이전에 등록한 것이 있다면 삭제하도록 한다.
공개키 파일의 내용을 복사하지 않고 처리하려면 터미널에서 아래와 같이 명령을 사용해도 된다.
$ pbcopy < ~/.ssh/id_rsa_ccambo.pub

ssh config 파일 설정

대 부분 여러 개의 SSH Key를 운영하기 때문에 매번 서버에 접속할 때마다 SSH Key를 지정하는 것도 번거롭기 때문에 설정으로 저장해 놓고 사용하는 방법을 권장한다.

~/.ssh 디렉터리에 config 파일이 존재하는지를 확인하고 없다면 새로 생성하도록 한다.

github.com에 대한 접속 정보를 아래와 같이 설정해 주면 된다.

Host github.com-ccambo    # ccambo 계정 용
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_ccambo   # 비밀 키 파일
  User ccambo             # github.com 계정 명

Host github.com-morris    # Morris 계정 용
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_morris   # 비밀 키 파일
  User morris             # github.com 계정 명

사용방법

github.com에 Repository 정보에서 Code를 클릭하면 HTTPS, Github CLI, SSH 의 세 가지 Clone 용 주소가 보인다. 이 중에서 SSH 방식을 선택하고 사용하면 된다.

SSH를 이용하는 포맷은 다음과 같다.

format : git@github.com:<account name>/<repository name>.git
Sample :  git@github.com:ccambo/ImageCDN.git

그런데 SSH Config를 구성할 때 다음과 같이 Host Name을 구성했다.

github.com-<account name>

따라서 Repository를 Clone 할 떄나 Remote Add 를 수행할 떄 Repository URL은 다음과 같이 구성되어야 한다.

format : git@<ssh config에 정의한 HOST 명>:<account name>/<repository name>.git
Sample : git@github.com-ccambo:ccambo/ImageCDN.git

신규로 Clone

$ git clone git@github.com-ccambo:ccambo/ImageCDN.git

신규로 Remote Repository 추가

$ git remote add origin git@github.com-ccambo:ccambo/ImageCDN.git

이전 Remote Repository 변경

$ git remote set-url origin git@github.com-ccambo:ccambo/ImageCDN.git

참고 자료

Generating a new SSH key and adding it to the ssh-agent

[Vue] Vue - 키포인트 이해하기

ccambo — Fri, 25 Dec 2020 21:29:33 +0900

[Vue] Keypoints of Vue

프로젝트에서 사용할 Front-End Framework을 고심하던 중에 Gregg이 Vue.js를 소개하는 공식 자료를 보고 Vue를 선택했다. 아래의 내용은 참고자료에 언급한 원문을 번역하면서 나름대로 정리한 것으로 왜 Vue가 43%의 개발자들이 vue.js를 배우려고 하는지를 알 수 있다.

참고

현재 TOP 3 (Angular, React, Vue)의 자바스크립트들에 대한 비교는 vue.js 공식문서를 참고하면 된다.

점진적인 프레임워크

Vue는 진입장벽이 낮고, 유연하고, 성능이 우수하고, 유지보수와 테스트가 편한 자바스크립트 프레임워크로 점진적인 프레임워크를 지향하고 있다. 점진적인 프레임워크라는 것은 웹 어플리케이션 전체를 한꺼번에 하나의 프레임워크 구조로 구조화하지 않아도 일정 부분만 적용 가능해서 사용자에게 더 좋은 사용자 경험을 제공할 수 있다는 것을 의미한다. 물론 전체를 처음부터 Vue로 구현할 수도 있다. Vue가 큰 규모의 어플리케이션을 개발할 수 있도록 핵심 라이브러리와 주변 생태계를 제공하고 있다.

재 사용 가능한 컴포넌트 (단일 파일 컴포넌트)

다른 프레임워크들처럼 재 사용이 가능한 컴포넌트로 웹 페이지를 구성할 수 있으며, 각 컴포넌트는 페이지 영역을 표시하는데 필요한 HTML, CSS, Script 를 가지는 단일 파일 컴포넌트 구조를 제공한다.

프로젝트로 알아보기

아주 간략하고 특징적인 Vue의 주요 컨셉을 알아볼 수 있다.

대 부분의 자바스크립트와 같이 페이지에 데이터를 표시하는 것부터 시작한다.

위의 그림에 표시된 것과 같이 "X"의 위치에 스크립트에서 설정한 "Boots"를 표시하고 싶으면 아래와 같이 구현하면 된다.

위의 내용을 좀 더 자세히 확인하면 다음과 같다.

정보를 표시할는 것은 Vue의 데이터를 바인딩할 때 사용하는 {{ ... }} 를 사용한다. 위의 예는 Vue 에서 관리하는 데이터 중에서 "product"라는 정보를 출력한다는 의미다. 물론 아직 데이터는 없다.
<script>...</script> 로 Vue 라이브러리를 포함시키고 구동 가능한 상태로 만든다.
const app = new Vue({ ... }) 코드로 Vue 인스턴스를 생성한다.
Vue 인스턴스를 생성할 떄 동작에 필요한 옵션을 지정한다.
- el : Vue 인스턴스가 DOM과 연계될 수 있도록 대상 엘리먼트를 지정한다.
- data : Vue 동작에 필요한 데이터를 JSON 형식으로 지정한다.

위의 코드를 실행하면 아래와 같이 결과를 확인할 수 있다.

위의 결과까지는 일반적인 수준이지만 정적이 아닌 동적으로 데이터가 변경될 때 Vue의 마법을 경험할 수 있다. 아래와 같이 개발자 도구의 콘솔에서 데이터를 변경하면 어떻게 데이터가 연동되는지를 확인할 수 있다.

위의 결과에서 알 수 있듯이 Vue는 데이터가 변경되면 Vue에서 알아서 변경된 내용을 처리하는 방식을 제공한다. 이 동작은 문자열뿐만 아니라 모든 유형의 데이터에 모두 적용된다. 이를 확인해 보기 위해서 위의 샘플 코드를 배열을 처리할 수 있도록 "ul" 태그와 "li" 태그 구조로 변경한다. 이때 템플릿처럼 구성하는 것이기 때문에 v-for라는 특별한 속성을 지정 (foreach 문장구조와 비슷)해야 한다. 그리고 Vue 인스턴스 생성할 떄의 data 부분을 배열구조인 products로 변경한다.

변경된 코드를 브라우저에서 실행해 보면 아래와 같은 결과를 확인할 수 있다.

좀 더 확장을 해서 서버를 호출해서 데이터를 받아온 결과를 기준으로 화면에 동적으로 출력하는 것으로 가정하면 아래와 같이 코드를 구성하면 된다.

위의 코드를 살펴보면 다음과 같은 변화가 있다.

data를 products라는 빈 배열로 초기화만 처리한다.
created 라는 vue 인스턴스의 생성시점에 호출되는 이벤트를 사용해서 API 호출 코드를 작성한다.
- fetch 메서드를 통해서 API를 호출한다.
- then 메서드를 이용해서 API 호출 결과를 Vue에서 관리하는 데이터로 변환해서 설정한다.

위의 코드에서 호출된 API의 결과는 JSON형식으로 실행된 화면은 아래와 같이 표시된다.

API에서 반환된 JSON을 그대로 출력한 것이기 떄문에 이를 좀 더 사용자에게 친숙한 형식으로 처리하기 위해서 아래와 같이 View 처리를 변경한다.

수행된 결과는 반환된 결과에서 product.quantity와 product.name 만을 출력하는 것으로 변경했기 때문에 아래와 같이 나타난다.

각 데이터 항목중에서 갯수가 0인게 있으면 사용자가 좀 더 잘 인식할 수 있도록 "<span>" 태그를 사용해서 item.quantity === 0 일 때만 "OUT OF STOCK" 텍스트가 보이도록 아래와 같이 변경한다.

위의 표현식에서는 v-if 지시자를 이용해서 조건식을 구성해서 재고 여부를 좀 더 확실하게 구분할 수 있도록 변경했다.

이제 모든 상품의 총 재고량을 목록 아래쪽에 표시하려면 totalProducts라는 computed 속성을 활용하면 된다. 만일 자바스크립트의 reduce() API가 익숙하지 않다면 그냥 재고 총합을 구하는 동작이라고 이해하면 된다.

실행을 해 보면 아래와 같이 모든 상품의 총 재고량이 계산되어 표시된다.

Vue 개발자 도구(Vue.js Chrome Extension)의 장점 중에 하나는 페이지상에 표시된 데이터를 살펴볼 수 있다는 점이다.

앞에서 보았던 데이터의 변화가 View에 동적으로 표현되는 부분을 다시 한번 확인할 겸해서 개발자 도구의 콘솔에서 2개의 product를 제거해 보면 아래와 같이 리스트뿐만 아니라 총 재고량도 변경되는 것을 확인할 수 있다.

이번에는 버튼을 사용해서 페이지에 이벤트를 추가하고 버튼을 눌렀을 때 각 상품의 재고량을 1개씩 늘리는 것으로 변경해 보도록 한다.

실행해 보면 Add 버튼을 눌렀을 때 각 상품의 재고와 총 재고량의 숫자를 증가시키는 것과 Jacket 상품에서는 OUT OF STOCK 글씨도 사라지는 것을 확인할 수 있다.

좀 더 확장해서 재고량을 직접 입력할 수 있도록 input 박스를 추가하고 v-model 지시자를 연결하고 입력되는 값은 항상 숫자인 것으로 지정하도록 변경한다.

위의 input 박스에는 양방향 바인딩을 위한 v-model 지시자를 이용해서 숫자인 데이터를 Vue에서 관리하고 있는 데이터 항목에 연동하는 설정을 한 것이다.

이제 버튼을 통한 것뿐만 아니라 사용자가 직접 숫자를 입력해서 재고를 변경할 수도 있다. 물론 0으로 숫자를 설정하는 OUT OF STOCK이 표시되는 것도, Add 버튼 처리도 모두 잘 동작하는 것을 확인할 수 있다.

지금까지 설명하고 실행해서 검증했던 소스는 JSFIDDLE에서 확인할 수 있다.

추가적인 Vue 특징

규모가 있는 어플리케이션을 구축한다면 여러 개의 컴포넌트를 조합해야 한다.
Vue는 CLI (Command Line Interface) 명령어 도구를 이용해서 쉽게 프로젝트를 생성할 수 있다. 아래의 명령으로 프로젝트를 시작하면 된다.
컴포넌트 별로 .vue 파일을 생성해서 관리할 수 있고, 각 .vue 파일에는 HTML, Javascript, CSS & SCSS 가 들어간다. (Single file component)

결론

지금까지 Vue가 할 수 있는 기능들 중에서 아주 기초적인 일부만 확인해 봤다. Vue에는 프론트엔드 화면을 개발하고, 구성하고, 빌드하기 위한 더 많은 기능들이 존재한다. 만일 Vue를 배우고 싶다면 아래의 2가지 자료를 추천한다.

VueMastery의 Vue Guide & CheatSheet : 무료 소개 과정과 계정을 만들면 CheatSheet를 받을 수 있다.
Vue.js 공식 문서

참고자료

Why 43% of Front-End Developers want to learn Vue.js

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 1: Bootstrap Node 구성

ccambo — Wed, 23 Dec 2020 20:20:24 +0900

How to building real world sample step by step - Part 1

게시글 참고

이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다.

PART 2에서는 Galera Cluster에 참여할 노드들 구성

PART 3에서는 사용하지 않는 부트스트랩을 제거하고, 외부 접속을 위한 서비스를 생성하며, 안전한 Scale Up/Down 처리 구성

이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 Galera 클러스터 구성을 위한 Bootstap Node 설정을 다룬다.

참고

이 문서는 KUDO에 대한 이해를 어느 정도 하고 있다는 것을 전제로 하며 MariaDB의 오픈 소스 클러스터링 솔루션인 Galera를 위한 Operator를 KUDO를 이용해서 만드는 과정을 정리한 것이다.

이 문서는 KUDO v0.17.0 기준으로 작성되었다.

KUDO에 관련된 정보는 이전 글들 참고

KUDO 정리 (Kubernetes Universal Declarative Operator - Kudobuilder)

KUDO 설치 및 간단한 사용법 검증

KUDO CLI 명령어 정리

환경 설정

파일 시스템 레이아웃 구성

우선 작업할 내용은 개발 및 테스트 환경을 구성하는 것이다. 이전 글들에서 언급했던 것과 같이 아래와 같은 구성이 필요하다. (KUDO-CLI 명령을 통해서 구조 및 기본 파일들을 생성할 수 있다.)

작업할 대상은 ~/kudo_sample/galera-operator 폴더를 기준으로 한다.
```
.
└── operator
    ├── operator.yaml
    ├── params.yaml
    └── templates

2 directories, 2 files
```
생성된 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: galera-operator
operatorVersion: 0.1.0
plans: {}
tasks: []
```
생성된 params.yaml 파일은 아래와 같이 구성한다.
```
apiVersion: kudo.dev/v1beta1
parameters: []
```
그리고 자동으로 생성되지 않는 templates 디렉터리도 생성해 놓는다.
배포 계획 생성

가장 먼저 작업할 내용은 모든 Operator가 반드시 가지고 있어야 할 배포 계획을 구성하는 것이다. (operator.yaml)
```
...
plans:
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
...
```
위와 같이 기본 배포 계획 구성을 추가한다.

Bootstrap Config 설정

Galera 클러스터를 배포할 때 Bootstrap을 위해 수행할 단계가 존재하기 때문에 부트스트랩 노드를 구성해야 한다. 이 부트스트랩 노드는 클러스터의 다른 노드와 구성이 다르므로 이를 배포하기 위해서 구성해야 한다.

ConfigMap 리소스를 이용해서 부트스트랩 컨테이너에 전달해야 한다. 따라서 배포 계획에 Phases와 Steps를 추가해서 이를 처리하기 위한 구성을 아래와 같이 처리한다. (operator.yaml)

...
plans:
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: bootstrap_config
            tasks:
              - bootstrap_config
tasks:
  - name: bootstrap_config
    kind: Apply
    spec:
      resources:
        - bootstrap_config.yaml
...

지금까지의 작업으로 완성한 ~/kudo_sample/galera-operator/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: galera-operator
operatorVersion: 0.1.0
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: bootstrap_config
            tasks:
              - bootstrap_config
tasks:
  - name: bootstrap_config
    kind: Apply
    spec:
      resources:
        - bootstrap_config.yaml

위에서 추가한 Step/Task 의 내용은 부트스트랩 노드를 위한 ConfigMap 리소스를 사용하겠다는 의미로 templates/bootstrap_config.yaml 파일을 생성하고 아래와 같이 구성한다. (bootstrap_config.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Name }}-bootstrap
  namespace: {{ .Namespace }}
data:
  galera.cnf: |
    [galera]
    wsrep_on = ON
    wsrep_provider = /usr/lib/galera/libgalera_smm.so
    wsrep_sst_method = mariabackup
    wsrep_cluster_address = gcomm://
    wsrep_sst_auth = "{{ .Params.SST_USER }}:{{ .Params.SST_PASSWORD }}"
    binlog_format = ROW

위의 설정 내용은 ConfigMap 리소스로 단일 데이터로 galera.cnf 파일의 내용으로 Galera 설정 내용이다.

wsrep_cluster_address = gcomm://: 이 설정을 통해서 이 노드가 부트스트랩 노드가 될 것을 지정한 것이다.
name: {{ .Name }}-bootstrap: 각 KUDO Instance에 유일한 값을 지정하는 것으로 ConfigMap도 유일한 이름으로 지정하기 위한 것이다.
namespace: {{ .Namespace }}: 네임스페이스에 속한 리소스로 한정되도록 하는 것이다.
wsrep_sst_auth = "{{ .Params.SST_USER }}:{{ .Params.SST_PASSWORD }}": 노드 간의 동기화를 위해 Galera 클러스터 내부적으로 사용할 자격 증명을 지정한 것이다.

이제 ConfigMap에서 사용하도록 지정한 파라미터들 (.Params로 시작하는)을 정의하기 위해 params.yaml을 아래와 같이 구성한다.

apiVersion: kudo.dev/v1beta1
parameters:
  - name: SST_USER
    description: "User to perform SST as"
    default: "root"
  - name: SST_PASSWORD
    description: "Password for SST user"
    default: "admin"

위의 내용은 SST_USER, SST_PASSWORD 파라미터를 정의하고 기본 값을 설정한 것이다.

주의

일반적으로 Secret 리소스에 민감한 정보를 구성하는 것을 권장한다. 위와 같이 파라미터로 설정하는 방식은 암호화되지 않고 클러스터에 저장되기 때문에 쉽게 노출될 수 있다.

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

가장 먼저 작업할 내용은 KUDO Operator 설치로 아래와 같이 수행한다.

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

$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!

Galera Operator 설치 (using install)

설치된 KUDO Operator에 작성한 Galera Operator를 설치한다. (KUDO는 Respository를 지원하지만 이번에는 로컬 디렉터리 (~/kudo_sample/galera-operator/operator)를 기준으로 설치한다.)
```
$ kubectl kudo install ./

Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
operator default/galera-operator created
operatorversion default/galera-operator-0.1.0-0.1.0 created
instance default/galera-operator-instance created
```
설치할 때 Instance 이름을 별도로 지정하지 않았기 때문에 패키지 이름을 그대로 사용한다. (galera-operator => galera-operator-instance가 된다)

설치된 Operator Instance 확인

설치된 Instance 정보는 아래와 같이 확인할 수 있다.

$ kubectl kudo plan status --instance=galera-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 "galera-operator-instance" in namespace "default":
.
└── galera-operator-instance (Operator-Version: "galera-operator-0.1.0-0.1.0" Active-Plan: "deploy")
    └── Plan deploy (serial strategy) [COMPLETE], last updated 2020-12-23 06:17:06
        └── Phase deploy (serial strategy) [COMPLETE]
            └── Step bootstrap_config [COMPLETE]

설치된 ConfigMap 확인

deploy plan의 bootstrap_config step으로 생성된 ConfigMap은 아래와 같이 확인할 수 있다.

$ kubectl get configmaps

NAME                                 DATA   AGE
galera-operator-instance-bootstrap   1      21m

생성된 ConfigMap의 내용은 아래와 같이 확인할 수 있다.

$ kubectl describe configmap galera-operator-instance-bootstrap

Name:         galera-operator-instance-bootstrap
Namespace:    default
Labels:       heritage=kudo
              kudo.dev/instance=galera-operator-instance
              kudo.dev/operator=galera-operator
Annotations:  kudo.dev/last-applied-configuration:
                {"kind":"ConfigMap","apiVersion":"v1","metadata":{"name":"galera-operator-instance-bootstrap","namespace":"default","creationTimestamp":nu...
              kudo.dev/last-plan-execution-uid: 3bb3d148-b420-47d5-83d9-baef16c4095c
              kudo.dev/phase: deploy
              kudo.dev/plan: deploy
              kudo.dev/step: bootstrap_config

Data
====
galera.cnf:
----
[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = mariabackup
wsrep_cluster_address = gcomm://
wsrep_sst_auth = "root:admin"
binlog_format = ROW

Events:  <none>

KUDO 및 Operator 삭제

지금까지 작업한 내용이 적용된 것을 확인했으므로 다음 작업을 위해서 KUDO Operator를 포함한 설치된 모든 리소스들을 삭제하도록 한다.

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

Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
customresourcedefinition.apiextensions.k8s.io "operators.kudo.dev" deleted
customresourcedefinition.apiextensions.k8s.io "operatorversions.kudo.dev" deleted
customresourcedefinition.apiextensions.k8s.io "instances.kudo.dev" deleted
namespace "kudo-system" deleted
serviceaccount "kudo-manager" deleted
clusterrolebinding.rbac.authorization.k8s.io "kudo-manager-rolebinding" deleted
Warning: admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 MutatingWebhookConfiguration
mutatingwebhookconfiguration.admissionregistration.k8s.io "kudo-manager-instance-admission-webhook-config" deleted
secret "kudo-webhook-server-secret" deleted
service "kudo-controller-manager-service" deleted
statefulset.apps "kudo-controller-manager" deleted

Bootstrap 서비스 구성

다음 작업은 부트스트랩 서비스를 정의하는 것으로, 클러스터 노드가 배포되면 부트스트랩 노드에 연결하기 때문에 이를 위한 서비스를 정의하는 과정이다.

operator.yaml 파일에 bootstrap_service step 추가
operator.yaml 파일에 bootstrap_service task 추가
task에서 사용할 bootstrap_service.yaml 설정

위의 같은 작업을 처리한 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: galera-operator
operatorVersion: 0.1.0
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: bootstrap_config
            tasks:
              - bootstrap_config
          - name: bootstrap_service
            tasks:
              - bootstrap_service
tasks:
  - name: bootstrap_config
    kind: Apply
    spec:
      resources:
        - bootstrap_config.yaml
  - name: bootstrap_service
    kind: Apply
    spec:
      resources:
        - bootstrap_service.yaml

이제 Task에 리소스로 정의한 부트스트랩 서비스 리소스 파일을 templates/bootstrap_service.yaml 파일에 아래와 같이 구성한다.

apiVersion: v1
kind: Service
metadata:
  name: {{ .Name }}-bootstrap-svc
  namespace: {{ .Namespace }}
  labels:
    app: galera-bootstrap
spec:
  ports:
    - port: {{ .Params.MYSQL_PORT }}
      name: mysql
    - port: {{ .Params.SST_PORT }}
      name: sst 
    - port: {{ .Params.REPLICATION_PORT }}
      name: replication
    - port: {{ .Params.IST_PORT }}
      name: ist 
  selector:
    app: galera-bootstrap
    instance: {{ .Name }}
  clusterIP: None

name: {{ .Name }}-bootstrap-svc: 서비스의 이름도 고유한 값으로 설정
app: galera-bootstrap: 이 서비스를 사용하는 모든 인스턴스들을 관리하는데 사용할 레이블 설정
port: {{ .Params.MYSQL_PORT }}: mySQL 사용 포트를 파라미터와 연동하도록 설정
port: {{ .Params.SST_PORT }}: SST 연계용 포트를 파라미터와 연동하도록 설정
port: {{ .Params.REPLICATION_PORT }}: Replication용 포트를 파라미터와 연동하도록 설정
port: {{ .Params.IST_PORT }}: IST용 포트를 파라미터와 연동하도록 설정
instance: {{ .Name }}: 부트스트랩 인스턴스 Selector 설정

이 특별한 서비스는 하나의 인스턴스만 사용하기 때문에 클러스터 IP는 필요하지 않고, 서비스는 Headless일 수 있으며 Kubernetes는 관련된 DNS Endpoint를 생성하게 된다.

서비스를 정의하면서 추가로 사용한 파라미터들을 params.yaml 파일에 아래와 같이 정의한다.

apiVersion: kudo.dev/v1beta1
parameters:
  - name: SST_USER
    description: "User to perform SST as"
    default: "root"
  - name: SST_PASSWORD
    description: "Password for SST user"
    default: "admin"
  - name: MYSQL_PORT
    description: "MySQL port"
    default: "3306"
  - name: SST_PORT
    description: "SST port"
    default: "4444"
  - name: REPLICATION_PORT
    description: "Replication port"
    default: "4567"
  - name: IST_PORT
    description: "IST port"
    default: "4568"

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-operator-instance

Plan(s) for "galera-operator-instance" in namespace "default":
.
└── galera-operator-instance (Operator-Version: "galera-operator-0.1.0-0.1.0" Active-Plan: "deploy")
    └── Plan deploy (serial strategy) [COMPLETE], last updated 2020-12-23 07:48:27
        └── Phase deploy (serial strategy) [COMPLETE]
            ├── Step bootstrap_config [COMPLETE]
            └── Step bootstrap_service [COMPLETE]

설치된 Service 확인

deploy plan의 bootstrap_service step으로 생성된 service는 아래와 같이 확인할 수 있다.

$ kubectl get services

NAME                                     TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                               AGE
galera-operator-instance-bootstrap-svc   ClusterIP   None         <none>        3306/TCP,4444/TCP,4567/TCP,4568/TCP   80s
kubernetes                               ClusterIP   10.96.0.1    <none>        443/TCP                               21d

생성된 서비스의 상세 정보는 아래와 같이 확인할 수 있다.

$ kubectl describe service galera-operator-instance-bootstrap-svc

Name:              galera-operator-instance-bootstrap-svc
Namespace:         default
Labels:            app=galera-bootstrap
                  heritage=kudo
                  kudo.dev/instance=galera-operator-instance
                  kudo.dev/operator=galera-operator
Annotations:       kudo.dev/last-applied-configuration:
                    {"kind":"Service","apiVersion":"v1","metadata":{"name":"galera-operator-instance-bootstrap-svc","namespace":"default","creationTimestamp":...
                  kudo.dev/last-plan-execution-uid: 7fdc50f2-86b3-4a5f-adb1-eb6c57a90c81
                  kudo.dev/phase: deploy
                  kudo.dev/plan: deploy
                  kudo.dev/step: bootstrap_service
Selector:          app=galera-bootstrap,instance=galera-operator-instance
Type:              ClusterIP
IP:                None
Port:              mysql  3306/TCP
TargetPort:        3306/TCP
Endpoints:         <none>
Port:              sst  4444/TCP
TargetPort:        4444/TCP
Endpoints:         <none>
Port:              replication  4567/TCP
TargetPort:        4567/TCP
Endpoints:         <none>
Port:              ist  4568/TCP
TargetPort:        4568/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

위의 결과와 같이 레이블과 포트 및 정의된 정보들이 제대로 설정된 것을 확인할 수 있다. 지금 시점에는 서비스를 사용할 부트스트랩 노드의 실제 인스턴스가 없기 때문에 Endpoint 정보가 없다.

KUDO 및 Operator 삭제

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

Bootstrap Node 배포

마지막 작업으로 위에서 설정한 Config, Service를 사용할 부트스트랩 노드의 실제 인스턴스를 배포하는 것이다.

operator.yaml 파일에 bootstrap_deploy step 추가
operator.yaml 파일에 bootstrap_deploy task 추가
task에서 사용할 templates/bootstrap_deploy.yaml 파일 추가

위의 같은 작업을 처리한 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: galera-operator
operatorVersion: 0.1.0
plans: 
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: bootstrap_config
            tasks:
              - bootstrap_config
          - name: bootstrap_service
            tasks:
              - bootstrap_service
          - name: bootstrap_deploy
            tasks:
              - bootstrap_deploy
tasks:
  - name: bootstrap_config
    kind: Apply
    spec:
      resources:
        - bootstrap_config.yaml
  - name: bootstrap_service
    kind: Apply
    spec:
      resources:
        - bootstrap_service.yaml
  - name: bootstrap_deploy
    kind: Apply
    spec:
      resources:
        - bootstrap_deploy.yaml

이제 Task에 리소스로 정의한 부트스트랩 배포 리소스 파일을 templates/bootstrap_deploy.yaml 파일에 아래와 같이 구성한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Name }}-bootstrap
  namespace: {{ .Namespace }}
  labels:
    app: galera-bootstrap
    instance: {{ .Name }}
spec:
  selector:
    matchLabels:
      app: galera-bootstrap
      instance: {{ .Name }}
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: galera-bootstrap
        instance: {{ .Name }}
    spec:
      containers:
      - image: mariadb:latest
        name: mariadb
        args:
        - "--ignore_db_dirs=lost+found"
        env:
          # Use secret in real usage
        - name: MYSQL_ROOT_PASSWORD
          value: {{ .Params.MYSQL_ROOT_PASSWORD }}
        ports:
        - containerPort: {{ .Params.MYSQL_PORT }}
          name: mysql
        - containerPort: {{ .Params.SST_PORT }}
          name: sst
        - containerPort: {{ .Params.REPLICATION_PORT }}
          name: replication
        - containerPort: {{ .Params.IST_PORT }}
          name: ist
        livenessProbe:
          exec:
            command: ["mysqladmin", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          exec:
            # Check we can execute queries over TCP (skip-networking is off).
            command: ["mysql", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
          timeoutSeconds: 1
        volumeMounts:
        - name: {{ .Name }}-bootstrap
          mountPath: /etc/mysql/conf.d
      volumes:
        - name: {{ .Name }}-bootstrap
          configMap:
            name: {{ .Name }}-bootstrap
            items:
            - key: galera.cnf
              path: galera.cnf

이전에 정의한 리소스들에 비해서는 복잡해 보이지만 몇 가지만 추가된 것이다. 주요한 몇 가지는 아래와 같다.

selector:
  matchLabels:
    app: galera-bootstrap
    instance: {{ .Name }}

리소스를 연결하는데 사용할 레이블과 인스턴스를 지정한 것이다.

ports:
- containerPort: {{ .Params.MYSQL_PORT }}
  name: mysql
- containerPort: {{ .Params.SST_PORT }}
  name: sst
- containerPort: {{ .Params.REPLICATION_PORT }}
  name: replication
- containerPort: {{ .Params.IST_PORT }}
  name: ist

컨테이너에서 사용할 포트들을 파라미터와 연계해서 지정한 것이다.

env:
  # Use secret in real usage
- name: MYSQL_ROOT_PASSWORD
  value: {{ .Params.MYSQL_ROOT_PASSWORD }}

env 섹션을 통해서 파라미터와 연계된 mySQL root 사용자 비밀번호를 저정한 것이다.

livenessProbe:
  exec:
    command: ["mysqladmin", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "ping"]
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
readinessProbe:
  exec:
    # Check we can execute queries over TCP (skip-networking is off).
    command: ["mysql", "-p{{ .Params.MYSQL_ROOT_PASSWORD }}", "-h", "127.0.0.1", "-e", "SELECT 1"]
  initialDelaySeconds: 5
  periodSeconds: 2
  timeoutSeconds: 1

livenessProbe와 readinessProbe를 통해서 접근이 가능한지와 사용할 수 있는지에 대한 검증 명령을 지정한 것이다.

  volumeMounts:
  - name: {{ .Name }}-bootstrap
    mountPath: /etc/mysql/conf.d
volumes:
  - name: {{ .Name }}-bootstrap
    configMap:
      name: {{ .Name }}-bootstrap
      items:
      - key: galera.cnf
        path: galera.cnf

ConfigMap이 정의된 Volume을 설정하고 컨테이너에서 사용할 수 있도록 마운트하는 것을 지정한 것이다. Volume도 유일한 이름으로 지정되어야 하고, ConfigMap에서 찾아야할 부분을 Key/Path로 지정해서 마운트될 때 /etc/mysql/conf.d 라는 이름의 파일로 처리될 수 있도록 지정한 것이다.

배포를 정의하면서 추가로 사용한 파라미터들을 params.yaml 파일에 아래와 같이 정의한다.

apiVersion: kudo.dev/v1beta1
parameters:
  - name: SST_USER
    description: "User to perform SST as"
    default: "root"
  - name: SST_PASSWORD
    description: "Password for SST user"
    default: "admin"
  - name: MYSQL_PORT
    description: "MySQL port"
    default: "3306"
  - name: SST_PORT
    description: "SST port"
    default: "4444"
  - name: REPLICATION_PORT
    description: "Replication port"
    default: "4567"
  - name: IST_PORT
    description: "IST port"
    default: "4568"
  - name: MYSQL_ROOT_PASSWORD
    description: "MySQL root password"
    default: "admin"

지금까지 작업한 것을 기준으로 정상적으로 동작하는지 테스트를 하도록 한다.

KUDO 설치 (using init)

$ kubectl kudo init --unsafe-self-signed-webhook-ca --wait  # Webhook TLS를 자체 서명한 버전으로 처리

Galera Operator 설치 (using install)
```
$ kubectl kudo install ./
```

설치된 Operator Instance 확인

$ kubectl kudo plan status --instance=galera-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 "galera-operator-instance" in namespace "default":
.
└── galera-operator-instance (Operator-Version: "galera-operator-0.1.0-0.1.0" Active-Plan: "deploy")
    └── Plan deploy (serial strategy) [IN_PROGRESS], last updated 2020-12-23 09:23:50
        └── Phase deploy (serial strategy) [IN_PROGRESS]
            ├── Step bootstrap_config [COMPLETE]
            ├── Step bootstrap_service [COMPLETE]
            └── Step bootstrap_deploy [IN_PROGRESS]

위의 Plan 정보 중에 Phase, Step 이 IN_PROGRESS로 나타나는 것은 실제 컨테이너가 구동되는 시간이 (이미지를 다운로드하고 구성하는 등의 시간) 필요하기 때문에 나타나는 것으로 시간이 지나면 정상적으로 표시된다. 만일 실패가 되면 원인을 찾아서 다시 처리해야 한다.

참고

Docker의 상용화 정책으로 인해서 Docker Repository에서 Image를 다운로드하는 부분에 Rate Limit가 설정되어 있기 때문에 오류가 발생할 수도 있다.

설치된 Bootstrap Node 확인

부트스트랩 노드 인스턴스를 배포한 것이기 때문에 Pod가 생성되어 동작하는지를 아래와 같이 확인할 수 있다.

$ kubectl get pods
NAME                                                  READY   STATUS    RESTARTS   AGE
galera-operator-instance-bootstrap-59855f6884-gz4rr   1/1     Running   0          5m7s

정상적으로 생성되어 동작하는 로그 정보는 아래와 같이 확인할 수 있다.

$ kubectl logs galera-operator-instance-bootstrap-59855f6884-gz4rr

...
2020-12-23  9:24:04 0 [Note] WSREP: Server initialized
2020-12-23  9:24:04 0 [Note] WSREP: Server status change initializing -> initialized
2020-12-23  9:24:04 0 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2020-12-23  9:24:04 2 [Note] WSREP: Bootstrapping a new cluster, setting initial position to 00000000-0000-0000-0000-000000000000:-1
2020-12-23  9:24:04 4 [Note] WSREP: Cluster table is empty, not recovering transactions
2020-12-23  9:24:04 2 [Note] WSREP: Server status change initialized -> joined
2020-12-23  9:24:04 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2020-12-23  9:24:04 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2020-12-23  9:24:04 0 [Note] Reading of all Master_info entries succeeded
2020-12-23  9:24:04 0 [Note] Added new Master_info '' to hash table
2020-12-23  9:24:04 0 [Note] mysqld: ready for connections.
...

위의 로그 결과와 같이 Galera 가 구성되었고 가입이 가능하도록 준비된 새 클러스터를 생성한 것을 확인할 수 있다.

그리고 ConfigMap이 제대로 마운트되어 실행되어 있는지는 아래와 같이 동작하는 컨테이너에 연결해서 확인할 수 있다.

$ kubectl exec -it galera-operator-instance-bootstrap-59855f6884-gz4rr /bin/bash

kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.

root@galera-operator-instance-bootstrap-59855f6884-gz4rr:/# ls /etc/mysql/conf.d/
galera.cnf

root@galera-operator-instance-bootstrap-59855f6884-gz4rr:/# cat /etc/mysql/conf.d/galera.cnf

[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = mariabackup
wsrep_cluster_address = gcomm://
wsrep_sst_auth = "root:admin"
binlog_format = ROW

그리고 bootstrap_service를 구성했을 때 지정되지 않았던 endpoint가 제대로 설정되었는지는 아래와 같이 확인할 수 있다.

$ kubectl describe service galera-operator-instance-bootstrap-svc

Name:              galera-operator-instance-bootstrap-svc
Namespace:         default
Labels:            app=galera-bootstrap
                  heritage=kudo
                  kudo.dev/instance=galera-operator-instance
                  kudo.dev/operator=galera-operator
Annotations:       kudo.dev/last-applied-configuration:
                    {"kind":"Service","apiVersion":"v1","metadata":{"name":"galera-operator-instance-bootstrap-svc","namespace":"default","creationTimestamp":...
                  kudo.dev/last-plan-execution-uid: 11aebdd4-ff44-4f5c-a166-1bd56a9213ff
                  kudo.dev/phase: deploy
                  kudo.dev/plan: deploy
                  kudo.dev/step: bootstrap_service
Selector:          app=galera-bootstrap,instance=galera-operator-instance
Type:              ClusterIP
IP:                None
Port:              mysql  3306/TCP
TargetPort:        3306/TCP
Endpoints:         10.244.84.141:3306
Port:              sst  4444/TCP
TargetPort:        4444/TCP
Endpoints:         10.244.84.141:4444
Port:              replication  4567/TCP
TargetPort:        4567/TCP
Endpoints:         10.244.84.141:4567
Port:              ist  4568/TCP
TargetPort:        4568/TCP
Endpoints:         10.244.84.141:4568
Session Affinity:  None
Events:            <none>

KUDO 및 Operator 삭제

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

Conclusion

지금까지의 작업으로 완전하게 동작하는 Galera Bootstrap Node가 구성되어 연결을 수신힐 준비가 되었다는 것을 확인해 보았다.

PART 2에서는 더 많은 Operator 기능을 구성해서 노드들을 추가하고 클러스터에 참여하도록 하는 방법을 검토해 본다.

참고 자료

Building your first KUDO Operator - Part 1

[OpenStack] CLI - 유동 IP 관련 명령 정리

ccambo — Mon, 21 Dec 2020 19:25:36 +0900

유동 (Floating) IP 관련 명령들

유동 IP 생성

오픈스택 대시보드를 통해서도 유동 IP를 생성할 수는 있지만 랜덤하게 생성되는 문제가 았기 때문에 CLI를 이용해서 연속적인 IP를 할당할 수 있다.

대시보드 유동 IP 생성
왼쪽 메뉴 트리에서 네트워크 > Floating IP 화면을 열고 상단의 프로젝트에 IP 할당 버튼을 눌러서 생성 가능

openstack floating ip create
  [--subnet <subnet>]
  [--port <port>]
  [--floating-ip-address <ip-address>]
  [--fixed-ip-address <ip-address>]
  [--description <description>]
  [--project <project> [--project-domain <project-domain>]]
  <network>

--subnet : 유동 IP (이름 또는 ID)를 만들려는 서브넷 네트워크 지정 (버전 2만)
--port : 유동 IP (이름 또는 ID)와 연결될 포트 지정 (버전 2만)
--floating-ip-address : 만들 유동 IP 지정 (버전 2만)
--fixed-ip-address : 유동 IP가 연결될 고정 IP 주소 (버전 2만)
--description : 유동 IP 설명 (버전 2만)
--project : 소유지의 프로젝트 (이름 또는 ID) (버전 2만)
--project-domain : 프로젝트가 속한 도메인 (이름 또는 ID), 프로젝트 이름이 충돌할 경우에 사용 (버전 2만)
network : 유동 IP를 할당할 네트워크 (이름 또는 ID)

유동 IP 삭제

$ openstack floating ip delete <floating-ip> [<floating-ip> ...]

floating-ip : 삭제할 유동 IP (IP 주소 또는 ID)

유동 IP 리스트

openstack floating ip list
    [--network <network>]
    [--port <port>]
    [--fixed-ip-address <ip-address>]
    [--long]
    [--status <status>]
    [--project <project> [--project-domain <project-domain>]]
    [--router <router>]

--network : 지정한 네트워크 (이름 또는 ID) 에 연계된 유동 IP (버전 2만)
--port : 지정한 포트 (이름 또는 ID) 에 연계된 유동 IP (버전 2만)
--fixed-ip-address : 지정한 고정 IP에 연계된 유동 IP (버전 2만)
--long : 출력에 추가 필드 정보 포함 (버전 2만)
--status : 지정한 상태 ('Active', 'Down' 등) 의 유동 IP (버전 2만)
--project : 지정한 프로젝트 (이름 또는 ID) 에 연계된 유동 IP (버전 2만)
--project-domain : 지정한 프로젝트가 속한 도메인 (이름 또는 ID)에 연계된 유동 IP, 프로젝트 이름이 충돌할 경우에 사용 (버전 2만)
--router : 지정한 라우터 (이름 또는 ID) 에 연계된 유동 IP (버전 2만)

유동 IP 설정

openstack floating ip set
  --port <port>
  [--fixed-ip-address <ip-address>]
  <floating-ip>

--port : 유동 IP에 연결할 포트 (이름 또는 ID)
fixed-ip-address : 유동 IP에 연결될 고정 IP 주소 (포트에 여러 IP가 있는 경우만)
floating-ip : 속성을 설정할 유동 IP (IP 주소 또는 ID)

유동 IP 상세 보기

openstack floating ip show <floating-ip>

floating-ip : 표시할 대상 유동 IP (IP 주소 또는 ID)

유동 IP 설정 해제

openstack floating ip unset
  --port
  <floating-ip>

--port : 유동 IP 에 연결된 모든 포트 해제
floating-ip : 연결 해제할 유동 IP (IP 주소 또는 ID)

참고 자료

floating IP

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

ccambo — Mon, 21 Dec 2020 18:57:38 +0900

How to use KUDO

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

Setup a Kubernetes Cluster 1.13+
Install kubectl 1.13+
Install cert-manager. KUDO는 TLS가 필요한 webhook를 사용한다.

참고
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

Kubernetes 1.15+

100m CPU, 50Mi Memory

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를 참고한다.

Deployment of KUDO CRDs : Custom Resource Definitions
Create of kudo-system namespace
Service Account
Role Binding
Instance of KUDO Controller

참고

수동 설치 또는 다른 설정등의 작업을 해서 처리할 경우는 아래와 같이 처리도 가능하다.
$ 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를 생성하는 단계별 내용을 확인한다.

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:[]

Add a Maintainer

위 단계에서 -i 옵션으로 지정했으면 처리할 필요가 없지만, 여러 사람들을 등록할 경우라면 추가할 수 있다.
```
$ kubectl kudo package add maintainer "<your name>" "<mail address>"
```

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

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

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

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는 패키지 구성에 대한 검증을 포함해서 패키지를 만들 수 있다.

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 이 제대로 생성되었는지 확인이 필요하다.
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 경로를 사용한다.

Check repository

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

NAME            URL                                              
*community      https://kudo-repository.storage.googleapis.com/v1
```
NAME 앞에 * 표시는 기본 리포지토리임을 나타낸다.

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: { name:community, url:https://kudo-repository.storage.googleapis.com/v1 }

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 기능을 사용한다.

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

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/) ...

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 명령으로 삭제하고 다시 생성해야 한다.

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

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은 삭제하지 않는다.

참고 자료

[Kubernetes - Operator] Kubernetes 상의 Operator Tools 간략 비교

ccambo — Mon, 21 Dec 2020 18:17:51 +0900

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 툴들은 위의 두 가지 유형의 애플리케이션을 비슷하게 다루기 때문에 설치한 이후의 변화를 알지 못하게 된다. 그러나 Operator는 애플리케이션이 동작하는 동안의 관리를 수행할 수 있으며 사용자 정의 리소스와 컨트롤러가 결합되어 있기 때문에 항상 애플리케이션의 정의된 상태와 현재의 상태가 일치하는지를 지속적으로 관리하게 된다.

참고

Terraform Kubernetes Provider v1.10.0 에서는 CRD와 CR에 대한 지원을 계획하고 있지만 아직 제공되지 않는 상태이며 다른 3rd Terraform Provider 에서 지원이 되는 것들이 존재한다.

Static Definition Formats

일반적인 정의 (YAML) 로 정적인 포맷은 클러스터 외부에서 정의되고 이를 다른 도구와 사용하면 애플리케이션 설치, 업그레이드, 롤백할 수는 있지만 클러스터에 설치된 애플리케이션에 대해 자동으로 요청된 상태로 유지하거나 클러스터와 상호 작용하는 매커니즘은 존재하지 않는다.

대부분은 클러스터에 추가로 설치되는 구성 요소가 없기 때문에 쉬운 설치와 사용자가 실행할 수 있는 권한만 있으면 된다. 즉 설치까지는 쉽지만 설치 이후의 제어를 할 수 없다는 것이다.

Easy installation
No installed component in the cluster
No requirements for admin permission on the cluster
Limited control over the installed application
No interaction with installed applications

Raw YAML 방식은 애플리케이션을 Kubernetes에 배포하는 가장 쉬운 방법이며 단순한 애플리케이션과 대 규모의 애플리케이션을 시작하는 측면에서는 적합하고 검증되어 있는 방식이지만 변화에 대한 처리 등에는 역시 대응하기 힘들다.

Kustomizse 방식은 구성된 YAML을 Kubernetes 클러스터에 적용하기 전에 패치, 머지, 변경이 가능하지만 단지 재 사용적인 측면이지, 이미 설치된 애플리케이션의 업그레이드와 상태 변화에 대응하는 방법은 제공되지 않는다.

Helm은 Kubernetes의 패키지 매니저로 chart 형식으로 패키지를 관리할 수 있고, 패키지의 설치, 업그레이드, 롤백과 커스터마이즈가 가능하다. Helm v2는 클러스터에 Tiller가 설치되고 클라이언트가 API 서버를 통해서 상호 작용하는 방식이며, Helm v3는 구성 요소에 의존하지 않고 클라이언트가 단독으로 처리하는 새로운 아키텍처를 사용한다. 그러나 역시 설치가 된 애플리케이션과의 상호작용이나 라이프사이클의 상태를 커버하지는 못한다.

High Level Frameworks

단순한 구성과 사용자 지정 컨틀롤러 사이의 영역에 존재하며 복잡한 Kubernetes의 내부적인 부분을 감추고 간단한 API 작업을 통해 지원하는 방식이다. 그러나 모든 상세한 것들을 다 노출해 주는 것은 아니기 떄문에 완전히 커스텀하게 컨트롤러를 작성하는 것보다는 제약이 존재한다

MetaController는 웹 후크 (Webhook)를 기반으로 커스텀 컨트롤러를 개발하는 프레임워크로 커스텀 리소스에 대한 동작을 쉽게 정의할 수 있고 기존 API에 기능을 추가할 수 있도록 한다. jsonnet이나 다른 언어들과 같은 기존 도구와 같이 작업할 수 있지만 이런 자유도는 오히려 라이프사이클 컨트롤러를 개발하는데 복잡성만 더 높이는 상황이 될 수 있다.

Custom Controllers

커스텀 컨트롤러를 개발하는 것은 애플리케이션의 라이프사이클을 관리하기 위한 코드를 작성하는 과정으로 다양하게 발생할 수 있는 상황들을 관리하기에 많은 노력이 필요하고 Kubernetes에 대한 많고 자세한 지식들이 필요하고 테스트, Kubernetes 클러스터의 업그레이드, Operator의 데이터 저장 변경과 API 변경 등에 대한 부분도 감안해야 하기 때문에 쉬운 작업이 아니다.

Full control over the cluster and deployed resources
Allows reaction to changes in the cluster, custom resources, validation
Allows any required behavior
Requires intimate knowledge of Kubernetes internals
Is an extra software to develop, test and manage

Kubernetes Client

가장 많은 자유도가 있는 방식으로 어떤 Wrapper나 Layer가 없이 직접 Low level로 Kubernetes API를 접속하는 클라이언트를 작성하는 것이며, 각종 언어들 (Go, Java, JS/Typescript, ...)의 활용이 가능하다. 개발에 어떤 제한이나 권장이 없기 때문에 알려진 여러 문제들이나 Kubernetes 영역에서 공통적으로 제시하는 가이드들이 없기 때문에 스스로 해결해야 하는 문제가 있다.

Kubebuilder

CRD를 이용해서 Kubernetes API를 구축하기 위한 프레임워크로 Go를 사용하고 새로운 컨틀롤러들을 개발하는데 controller-runtime 라이브러리를 활용한다.

Kubebuilder 접근 방식은 데이터를 CRD에 저장하고 CR들과 다른 리소스들을 감시하고 작성한 비즈니스 로직을 따르는 변경 처리를 수행하는 루프를 구현한다.

Operator SDK

controller-runtime을 중심으로 Higher level 프레임워크로 많은 Scaffolding들을 제공하고 Helm 이나 Ansible과 통합을 허용하고 많은 Feature Set들을 제공한다.

Operator 개발을 위한 툴 비교

참고

Kubernetes의 원래 초점은 애플리케이션의 오케스트레이션이기 때문에 상태가 저장되지 않는 일반적인 애플리케이션을 대상으로 했었지만, 실제 운용되는 애플리케이션들은 상태관리가 필요한 것들이 많기 때문에 쿠버네티스 1.5부터 StatefulSet을 추가해서 안정적인 네트워크와 스토리지 개념을 제공했지만, 실제 파드 내에서 어떤 일이 발생하는지를 모르기 때문에 단순히 애플리케이션의 중지/배포/시작의 단순한 처리로는 해결되지 않는 부분이 많으며, 이를 해결하기 위한 운영자의 노력과 지식을 자동화해 보자는 시도가 Operator라는 것으로 진행되고 있다.

오퍼레이터 패턴에 대해 다시 정리하면 상태 저장 애플리케이션 (상태를 근거로 하나 이상의 인스턴스가 서로 긴밀하게 연결되는)을 구성하고, 유지 관리하기 위한 사람들의 지식을 포착해서 Kubernetes상의 API 를 확장 (CRD or API Aggregation Layer)하고 자동화하는 수단을 제공하는 것이다.

대표적인 수행 작업들은 아래와 같으며, 애플리케이션이 동작하는 동안의 거의 모든 작업들을 처리할 수 있다.

백업
데이터 조정
확장
설정 변경

이와 같이 Kubernetes 만으로는 해결할 수 없는 것들을 처리히기 위한 운영자의 지식을 자동화하는 Operator는 여러 가지 방법으로 구성할 수 있다.

Operator Framework
KubeBuilder and MetaController
KUDO

1, 2 번이 SDK에 근거해서 코드를 작성하고 Kubernetes에 대한 지식을 기반으로 하는 것에 반해서 KUDO의 경우는 다형성 기반의 선언적 접근 방식이다.

Operator Development 관점의 비교

Operator Framework	Kubebuilder	Kudobuilder
Redhat / IBM Project	Kubernetes SIG API Machinery sub-project	Polymorphic
Implement using Ansible, Helm charts, or Go	Written in Go with a focus on code generation	Universal Operator
Existing implementations often don't cover the entire lifecycle	Existing implementations often don't cover the entire lifecycle	Built using community projects (Kubebuilder, Kustomize, ...)
Ansible and Helm are limited. Go requires 1,000s of lines of controller code		Write Operators as templated YAML manifests
		Provide high level CRDs that represent workloads
		Focused on higher level coordination of software lifecycles
		Day 2 Operators
		support test framework kuttl for check operator

Operator Framework Architecture

KUDO Architecture

다음에는 가장 Kubernetes의 선언적 운영 방식에 좀 더 적합한 것으로 판단되는 KUDO 정리 (Kubernetes Universal Declarative Operator - Kudobuilder) 해 보도록 한다.

참고 자료

[Kubernetes - Operator] Kubernetes상의 Operator 나름대로 정리

ccambo — Mon, 21 Dec 2020 17:21:59 +0900

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로 등록된 리소스 객체를 그대로 사용할 수 있다. (아래 샘플 참조)

단, Custom Controller 나 API Server 연계 등에 대한 자세한 Spec 등과 가이드가 충분하지 않기 때문에 직접 개발 보다는 지원되는 Framework이나 툴을 이용해서 개발하게 된다.

Operator Fraemwork by Redhat (원래는 CoreOS 지만 Redhat에 흡수됨)
KUDO : Operator를 작성 배포하기 위한 Kubernetes Addon
KubeBuilder : CRD 방식이 아닌 API Server를 확장하는 개념으로 현재는 CRD 방식으로 방향성을 잡고 있으므로 용도가 좀 다르다고 생각된다.
Webhook + MetaController : Custom Controller를 쉽게 작성 및 배포하기 위한 Kuberenetes Addon
Operator Framework : Operator를 작성 배포하기 위한 Framework

아래의 그림은 Kuberentes의 동작 흐름이다.

아래의 그림은 Operator의 동작 흐름이다.

두 그림을 비교해 보면 같은 패턴의 프로세싱 흐름을 볼 수 있다. 따라서 향후 방향성은 CRD 기반의 Operator 중심으로 Kubernetes 모듈화 가속이 될 것으로 판단된다.

Operator Framework

참고

Operattor Framework은 CoreOS에서 시작되었고, 현재는 CoreOS를 인수한 Redhat에서 리딩하고 있다.

Operator Framework은 Cloud에서 하나의 Architecture Pattern으로 분류되며 단순한 작업을 자동화하기 위해 등장한 패턴으로 보면 된다.

Kubernetes 애플리케이션을 패키징, 배포, 운영 자동화를 제공하며 다음과 같은 툴을 제공한다.

Operator SDK

SDK를 이용하면 기존의 Kubernetes client-go 라이브러리를 사용하지 않고도 추상화된 Kubernetes API 사용이 가능하다.

Operator Lifecycle Manager (OLM)

OLM은 Operator의 생애주기를 관리하는 매니저로 Operator를 설치하고, 업데이트, 백업, 스캐일링 등을 처리한다. 현재 Operator SDK를 사용하지 않고 OLM을 통해서도 Operator 생성이 가능하다고 되어 있어 애매한 상태이며 향후 통합 또는 변경될 가능성이 있다.

Operator Metering

Operator Framework을 통해서 만들어진 애플리케이션과 Operator 조합을 대상으로 한 미터링 툴로 애플리케이션의 CPU/Memory 등에 대한 시계열 데이터를 활용 (Prometheus와 연동)해서 미터링 리포트 데이터를 생성하고 제공하는 역할을 담당한다.

Operator vs. Helm

Operator는 Helm 기능을 포함하고 있다. Helm이 애플리케이션의 배포 및 업그레이드를 다룬다면, Operator는 배포 및 업그레이드를 포함해 애플리케이션의 운영까지 관리하는 것이다.

단, Operator Framework을 도입하면 Helm Chart를 대체할 수도 있지만, Operator 자체를 Helm Chart로 만들수도 있고 (이때는 OLM 사용 배체), Operator 내부에서 애플리케이션 배포를 Helm을 통해서 할 수도 있다. 따라서 현재까지는 Helm을 대체한다기 보다는 서로 다른 용도/목적이라고 생각하면 된다.

Real Sample (Prometheus Operator)

순수 Prometheus만을 사용하다보면 여러 가지 문제들이 존재한다.

점점 많아지는 Scrape, Rule Condition : 수집해야 하는 Metric 정보와 규칙들이 많아질 수록 Prometheus Configuration이 복잡해져 효율적 관리가 힘들고 CI/CD를 적용하려다 보면 Configuration 의 부분적 재 사용이 필요한 문제 -> Prometheus Configuration 을 CRD로 적용해서 결합도를 낮추고 (decoupled) 운영 효율성 높임
상황에 따른 Logical data sharding 필요 : Operator를 이용하면 N개의 Prometheus를 설치/관리할 수 있다. 위의 decoupling과 연계해서 각 Prometheus른 서로 다른 Metric을 수집할 수 있고 Federation까지 활용해서 복잡한 구조의 Metric 수집도 쉽게 해결이 가능하다.

위의 그림에서 ServiceMonitor는 동작하는 프로세스가 아니라 Configuration인 CRD에 해당한다.

그림의 점선 박스 전체가 CRD
아래의 'Operator'와 'Prometheus Server' 가 실제 동작하는 파드다.

예를 들어 운영자가 Service Monitor를 추가 생성하면 이를 Watching하고 있던 Operator가 새로 생성된 Service Monitor에 현재 동작하고 있는 Prometheus의 Configuration file을 업데이트하고 Prometheus를 재 실행 시킨다.

Kubernetes 확장

참고
Kubernetes의 확장 포인트는 다양하다. 그러나 이 문서에서는 Operator와 관련된 확장에 대해서만 다룬다.

위의 그림은 Kubernetes의 주요 구성 요소들의 관계를 표현한 것으로 Operator와 관련된 부분은 주로 c-m (controller-manager)와 api server (with Aggregation Layer) 부분과 연관성이 크다.

확장은 Kubernetes Control Plane과 상호 작용하며, 당연히 장애가 발생할 수 있는 위험성이 추가되는 형식이 된다.
- 클라이언트로 동작하는 프로그램을 작성하는 패턴을 Controller Pattern이라고 한다.
- Kubernetes가 클라이언트로 원격 서비스를 호출하는 방식을 Webhook이라고 하며 호출을 받아 처리하는 서비스를 Webhook Backend라고 한다.
Controller는 객체의 .spec (Wanted) 정보를 읽고 객체의 상태 (current state)와 비교해서 처리한 후에 .status (to ETCD)를 갱신하는 컨트롤 루프다.
CRD (Custom Resources Definition)은 API 확장의 범주에 속한다.

위의 그림은 확장 포인트에 따른 Kubernetes Control Plane과의 상호 작용을 나타내고 있다.

Operator as an extension of Kubernetes

정의

Operator는 사용자 정의 리소스 (CRD : Custom Resource Definition)를 기반으로 애플리케이션 및 컴포넌트를 관리하는 Kubernetes API 확장 개념

서비스 또는 서비스 세트를 관리하는 운영자의 주요 목표가 타겟
운영자가 주로 사용하는 작업들을 Kubernetes가 제공하는 이상으로 자동화를 하기 위한 방법
Kubernetes의 워크로드 배포, 실행 등의 자동화 및 수행 방식의 자동화
Kubernetes의 컨트롤러 개념을 기반으로 하는 CRD를 위한 컨트롤러 역할을 담당하는 API 클라이언트

What is the Custom Resource

정의

Custom Resource는 Custom Object의 모음이며 API 확장을 위한 기본 리소스로 결국은 사용할 객체를 정의하고 추상화한 구조적 데이터와 같다.

Custom Resource에서의 객체 정의는 완전히 새로운 객체가 아닌 이미 존재하는 Deployments, Services와 같은 기본 객체를 목적에 맞게 조합하고 추상화해서 새로운 이름으로 명시할 수 있다는 의미다.

Custom Resource Definition은 Costom Resource가 데이터로 어떤 항목이 정의되어야 하는지 등을 저장하는 선언적 메타데이터 객체일 뿐이다. (XML Schema 와 XML의 관게를 생각하면 이해하기 쉽다.)

Kubernetes에서는 Resource 개념이 존재하고 Resource는 Kubernetes Object들을 모아놓은 Kubernetes API의 Endpoint라고 정의하고 있다.

참고

Kubernetes API의 Endpoint라고 부르는 이유는 예를 들어 파드 리소스가 존재할 떄 이를 사용해서 작업을 하기 위해서는 파드의 CRUD 관련 API 묶음이 Kubernetes API로 등록되어야 하기 때문이라고 생각하면 편할 듯 하다.

현재는 쿠버네티스의 핵심 기능들이 커스텀 리소스를 사용해서 구축되고 있으며 쿠버네티스의 모듈화쪽으로 가고 있다.

Custom Resource는 kubectl 을 통해서 사용 가능하다.

Kubernetes의 몇 가지 용어들을 정리하면 다음과 같다.

Kubernetes Objects

"Persistent entities in the Kubernetes system" 로 정의되어 있으며 Kubernetes에 저장된 실체들 이라고 생각하면 된다.

이 객체들로 다음과 같은 정보를 나타낼 수 있다.
- 애플리케이션이 배정된 노드들
- 애플리케이션이 사용할 수 있는 리소스들
- 애플리케이션 동작에 대한 정책 (어떻게 재 시작할지, 업데이트할지 등)
Kubernetes 객체들은 생성했을 떄 생성된 실체가 존재하는 것이라기 보다는 상태를 의미 한다. 예를 들어 kubectl을 통해 파드 1개를 생성하는 요청을 보내면 Kubernetes는 1개의 파드가 필요한 상태를 기록한다. 그리고 Kubernetes는 현재의 상태와 기록된 상태를 비교해서 원하는 상태를 맞추도록 동작하게 된다.
Object Spec and Status

모든 Kubernetes 객체들은 공통적으로 두 개의 필드를 가진다.
- Spec : 객체가 가질 상태에 대한 명세 정보
- Status : 실체 클러스터에서 객체가 가진 상태 정보 (Kubernetes가 계속 검증하고 반영)
Kubernetes API

Kubernetes의 객체를 이용해서 CRUD 작업을 하기 위해서는 Kubernetes API를 통해야 한다. 즉 사용자가 kubectl을 사용해서 객체 생성 명령을 실행하면 kubectl은 Kubernetes API로 요청을 하고 Kubernetes는 해당 객체를 생성하게 된다. (물론 kubectl이 아닌 Kubernetes API 클라이언트 라이브러리를 통해서 작업도 가능)

기본 제공되는 파드 리소스의 경우도 동일하게 생각하면 파드에 대한 정의와 상태 및 오퍼레이션 으로 생각하면 될 듯 하다. 물론 커스텀 리소스는 이런 기본 제공되는 리소스 이외의 사용자가 정의한 리소스를 의미하고 Kubernetes API를 확장하는 작업에 필요한 것이다.

How to use Custom Resource on Kubernetes

Custom Resource는 CRD (Custom Resource Definition) 또는 API Aggregation 방식으로 사용하는 것이 일반적이다.

using by CRD and Operator

가장 쉽고 일반적인 방법으로 CRD를 사용하는 것으로 CRD는 이미 Kubernetes에서 제공되는 객체의 한 종류로 kubectl get crd 명령으로 목록을 확인할 수 있고 kubectl apply -f ... 명령으로 CRD를 생성할 수도 있다.

그러나 Custom Resource Definition 이라는 이름에서 알 수 있듯이 커스텀 리소스가 어떤 데이터로 구성되어 있는지를 정의하는 객체일 뿐 CRD만으로는 실제 Custom Resource를 생성하지는 않으며, 단지 커스텀 리소스의 데이터에 어떤 항목이 정의되어야 하는지 등을 저장하는 선언적 메타데이터 객체일 뿐이다. 따라서 CRD로 부터 검증되어 실질적 Custom Resource를 생성하려면 CRD에 정의된 객체의 이름, 항목 등을 명시한 YML 파일을 만들고 생성해 줘야 한다. (XML Schema와 XML 파일의 관계로 생각하면 이해하기 쉽다)

이제 이해를 위한 간략한 샘플을 보도록 한다.

STEP 1 - 리소스 스키마인 Definition 정의와 데이터에 대한 선언적 Resource 정의

"my-crd.yml" 파일로 CRD를 정의한다.

apiVersion: "apiextensions.k8s.io/v1"
kind: "CustomResourceDefinition"      # <- 객체 유형은 CRD
metadata:
  name: "ccambo.morris.com"
spec:                                 # <- 리소스 객체 정의 Spec
  group: "morris.com"
  version: "v1alpha1"
  scope: "Namespaced"
  names:
    plural: "ccambo"
    singular: "ccambo"
    kind: "Ccambo"                    # <- 객체 유형 정의
  validation:
    openAPIV3Schema:
      required: ["spec"]
      properties:
        spec:
          required: ["Pet"]           # <- 필수 정보 정의
          properties:
            Pet:                      # <- 데이터 형식 정의
              type: "string"
              minimum: 1

위의 내용은 ccambo라는 리소스에 Pet 이라는 데이터 항목이 string 형식으로 반드시 존재해야 하는 것을 명시한 것이다. 따라서 정의한 규칙을 따르는 YML 파일만 리소스를 생성할 수 있다.

위와 같이 CRD를 정의하고 CRD를 생성한다. (Definition 생성)

$ kubectl apply -f my-crd.yml

customresourcedefinition.apiextensions.k8s.io/ccambo.morris.com created

$ kubectl get crd

NAME                                                  CREATED AT
...
ccambo.morris.com                                     2020-12-03T09:42:29Z
...

규정에 맞는 실제 사용할 커스텀 리소스는 아래와 같이 "ccambo-resource.yml" 파일로 정의한다.

apiVersion: "morris.com/v1alpha1"
kind: "Ccambo"                  # <- 정의된 객체 유형
metadata:
  name: "my-custom-resource"
spec:
  Pet: "I like Hedgehog"        # <- 필수 데이터 항목 정의

위의 내용은 검증용 샘플로 CRD로 정의된 형식에 맞춰서 작성한 것으로 아래의 명령으로 생성한다. (Resource 생성)

$ kubectl apply -f ccambo-resource.yml

ccambo.morris.com/my-custom-resource created

$ kubectl get ccambo

NAME                 AGE
my-custom-resource   2m54s

간단하게 커스텀 리소스를 생성해 보았다. 그러나 이런 리소스도 결국은 ETCD에 저장되는 단순한 데이터일 뿐이고 실제 동작하는 파드나 서비스는 아니라는 것을 명심해야 한다.

커스텀 리소스는 리소스가 어떤 목적인지를 나타내는 데이터라면 이제 리소스가 실제 어떻게 동작할 것인지를 정의할 선언적 컨트롤러를 구현해야 한다.

STEP 2 - 동작을 규정하는 선언적 컨트롤러 구현

쿠버네티스의 내장 객체를 예시로 생각해 보면 Deployment 객체의 목적은 "ReplicaSet"을 만드는 것이고, ReplicaSet 객체의 목적은 Matchlabel에 맞는 "파드"를 생성하는 것이다. 따라서 커스텀 리소스가 어떻게, 무엇을 위해서 동작할 것인지를 정의하는 부분이다.

이런 선언적인 동작을 수행하도록 구현한 것이 컨트롤러 (Controller) 이며 커스텀 리소스가 가져야할 최종적인 상태를 유지하는 역할이다. 예를 들어 커스텀 리소스의 목적이 "CAT", "HEDGEHOG" 라는 두개의 파드가 실행 상태에 있어야 한다는 것이라면 컨틀롤러는 두 개의 파드를 생성하려고 시도하고 최종적으로 두 개의 파드가 실행 중인 상태를 유지한다.

이 부분부터는 Kubernetes에서 제공하는 저수준의 API를 알아야 하고 어떻게 구현해야 하는지에 대한 가이드도 별로 없기 때문에 Operator SDK를 이용해서 처리해야 한다.

지금까지 언급한 내용을 정리하면 다음과 같다.

쿠버네티스의 객체 중에 하나인 CRD를 통해서 커스텀 리소스에 대한 정의를 생성한다.
CRD로 정의된 포맷대로 커스텀 리소스를 생성한다.
커스텀 컨트롤러를 구현한다.
커스텀 컨트롤러는 쿠버네티스의 Watch API를 통해서 커스텀 리소스가 생성된 것을 식별한다.
커스텀 컨트롤러는 커스텀 리소스의 설정에 맞는 동작을 수행한다. (파드 또는 서비스 생성들...)

참고
Clound Native Infrastructure에서 자주 언급되는 단어들 중에 선언적 (Declarative) 와 명령적 (Imperative) 동작이라는 것이 있다. 쿠버네티스는 선언적 및 명령적 동작을 모두 지원하지만 가능하면 선언적 동작을 권장하고 있다.

선언적 동작 : 원하는 상태를 미리 정의하고, 현재 상태가 원하는 상태가 되도록 하는 것을 의미한다.

명령적 동작 : 지정한 상태로 만들어 버리는 것을 의미한다.

kubectl apply -f ... 는 선언적이고, kubectl create ... 는 명령적인 것을 의미한다.

using by API Aggregation

API Aggregation은 여러 개의 API 서버를 하나의 API 서버인 것처럼 사용할 수 있도록 하는 쿠버네티스의 기능을 말하는 것으로 공식 문서들이 너무 어렵게 쓰여 있지만 정리하면 그렇게 어려운 것은 아니다.

쿠버네티스는 API 서버의 기능을 직접 확장해 사용할 수 있도록 API Registration이라는 것을 제공한다. 별도로 필요한 기능이 있다면 이를 직접 별도의 서버에 구현한 뒤에 쿠버네티스에 등록하는 방식이다. 그냥 보기에는 기존 쿠버네티스 API 서버 엔드포인트와 별도로 구현한 API 서버의 엔드포인트가 각각 존재하기 때문에 각각 접속해야 할 것 같지만, 쿠버네티스는 API Aggreation이라는 기능을 통해서 여러 개의 API 서버에 접근할 수 있도록 추상화된 엔드포인트를 제공한다.

추가적인 기능을 구현한 별도의 API 서버는 apiserver-builder나 kubebuilder를 통해 구현할 수 있다. (실제 구현할 때는 sample-apiserver가 제공되고 있으므로 직접 테스트가 가능하다) 이를 통해서 구현된 API 서버를 APIService 객체를 통해 API 서버에 등록하면 직접 구현한 API 기능을 기존의 API 서버를 통해서 사용할 수 있게 된다.

정리하면 아래의 그림과 같이 기존 쿠버네티스 API 서버가 일종의 프록시 역할을 대신하는 것이라고 생각하면 된다.

확장된 API 서버 내부에서 커스텀 리소스에 대한 API를 정의한 뒤 이를 APIService 를 통해서 등록하고 사용하면 된다. 아래의 내용은 sample-apiserver 예제에서 제공하는 APIService 내용이다.

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1alpha1.wardle.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: wardle.k8s.io
  groupPriorityMinimum: 1000
  versionPriority: 15
  service:
    namespace: wardle             # 1. wardle 이라는 네임스페이스에 존재하는
    name: api                     # 2. api 라는 서비스를 통해 확장된 API 서버에 접근할 수 있다.
  version: v1alpha1

개념적으로는 간단해도 별도의 API 서버를 구축하는 작업은 만만치 않아 보인다. apiserver-builder나 kubebuilder를 이용해서 서버를 빌드해야하고 쿠버네티스 API 서버와의 인증 작업도 신경써야 하며, API Aggregation을 통해서 커스텀 리소스를 정의헀다고 해도 커스텀 컨틀로러의 구현도 직접해야 하고 별도의 API 서버를 위한 스토리지 구성등도 따로 해줘야 하는 상황이 발생할 수 밖에는 없다.

mysql-operator의 mysql-apiserver 아키텍쳐 를 만든 사람이 구성한 아래의 그림을 살펴보는 것이 좋다.

작성자는 CRD의 기능이 점차 API Aggregation의 기능을 따라잡고 있으니 이런 구조는 필요없을 것이라고 말하고 있다.

결론적으로 커스텀 리소스만을 사용할 것이라면 API Aggregation보다는 Operator를 통한 CRD를 사용하는 추세로 가는 것으로 보이고, 지금까지의 설명으로도 Operator가 더 쉽게 느껴진다. 물론 API Aggregation 기능이 커스텀 리소스에만 사용되는 것이 아니기 때문에 API Server의 확장을 위해서도 필요하므로 검토해 봐야 한다. 현재라도 CRD에서 지원하지 않는 기능은 API Aggregation을 통해서 확장하는 방법외에는 없다.

참고 자료

[Kubernetes - Operator] KUDO 정리 (Kubernetes Universal Declarative Operator - Kudobuilder)

ccambo — Mon, 21 Dec 2020 17:06:21 +0900

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로 정의된 리소스일 뿐)
- 클러스터에 다양한 Operator들을 배포하는 것이 일반적이기 때문에, 유사한 API 및 CLI / Workflow 경험을 제공
- 모든 워크로드를 CRD로 관리하여 GitOps 촉진
- 이미 존재하는 Operator들도 KUDO를 통해 관리가 가능하고, CRD, CR 및 기타 Operator들을 파악해서 다른 워크로드들의 일부로 종속성를 지원
- (향후) 엔터프라이즈 워크로드를 위한 중앙 집중식 지원, 메트릭/경고 기능 및 보안과 RBAC 기능을 제공
When?

kubectl apply -f 또는 helm install로 애플리케이션의 라이프사이클을 관리하기 힘든 경우에 사용한다.
- 상태 저장 서비스를 사용하고 백업/복원과 같은 특정 워크플로우를 자동화해야 하는 경우이거나 스케일 업/다운 시 재 구성이 필요한 일반적인 작업을 수행할 떄 추가적인 로직의 실행이 필요한 경우
- 배포 워크플로우에 순차적인 또는 병렬로 처리할 단계가 존재하는 마이크로 서비스를 관리하는 경우 (예를 들어, 동적으로 구성을 생성하거나 마이그레인션 완료를 대기해야 하는 등의 작업)
- 혼돈 및 탄력성 테스트와 같이 애플리케이션 라이프사이클 전체에 걸쳐 반복적인 작업을 자동화해야할 경우
Concepts
- Operator Package : Helm Chart 나 Homebrew formula와 같은 KUDO Operator를 정의하는 파일의 모음이며, 로컬 (folder or tarball) 또는 원격 (tarball URL)일 수도 있고, 실행할 애플리케이션에 대한 모든 Kubernetes 리소스 및 워크플로우가 정의되어 있다.
- Repository : Operator 패키지를 보관하는 곳으로 로컬 폴더 또는 원격 URL일 수 있다.
- KUDO Manager : KUDO Operator들을 이해하고 Plan들을 어떻게 실행해야 하는지를 알고 있는 Kubernetes Controller 들의 집합이다.
- Plan : Plan은 Operator의 주요 워크플로우 단위로, 정의된 순서에 따라 클러스터에 Kubernetes 리소스를 적용하거나 삭제하는 일련의 단계를 지정한다.
  
  Usage
  
  사용자가 리포지토리에서 Operator Package를 가져와서 KUDO Manager에 제출하면, KUDO Manager는 자동 또는 요구에 따라서 Operator의 Plan들을 실행하게 된다.
Operator Plans

Operator는 몇 가지 Plan들로 구성되고 KUDO를 통해 수행될수 있는 구조화된 방법으로 쓰여진 runbook (실행 책자?)로 보면 된다. 각 Plan은 몇 개의 Phase로 이뤄지고 각 Phase에는 몇 개의 Step 들이 존재한다. 모든 Operator들은 클러스터에 애플리케이션을 배포하는 기본 Plan인 Deploy Plan을 포함해야 한다. 복잡한 애플리케이션인 경우는 백업 및 복원 또는 업그레이드 Plan을 정의한다. 각 Plan의 Phase 와 Step은 순차적 또는 병렬로 동작할 수 있으며, 별도로 지정하지 않는 경우라면 기본적으로 순차 처리한다.

다양한 노드 유형 (부트스트랩, 마스터, 에이전트) 들을 순차적으로 처리하는 데이터 서비스의 추상적인 배포 플랜의 예시는 다음과 같다.
```
plan: deploy
  phase: bootstrap-node
    step: start-bootstrap-node
  phase: master-nodes
    step: start-master-nodes
  phase: agent-nodes
    step: start-agent-nodes
  phase: deploy-cleanup
    step: remove-bootstrap-node
```
순차적인 처리의 기준은 앞 phase의 진행이 성공적이어야 다음 phase로 진행되는 방식이다.
Operator Paramters

Operator들은 파라미터를 사용해서 커스터마이징이 가능하다. 이부분이 다른 비슷한 툴들과 다른 점으로 Operator Paramter는 Plan과 연계되어 있기 때문에 파라미터가 변경되면 자동으로 연계된 Plan이 실행된다. 아래의 예는 애플리케이션 노드의 수와 노드 컨테이너가 사용하는 메모리를 나타내는 것이다.
```
parameters:
  - name: NODE_COUNT
    description: "Number of application nodes"
    default: "3"
    trigger: "deploy"
  - name: NODE_MEM_MIB
    description: "Memory request (in MIB) for node container"
    default: "4096"
    trigger: "update"
```
위의 예에서 볼 수 있는 것처럼 각 파라미터는 tigger 필드를 가지고 있는데, 이 필드 값을 통해서 파라미터의 값이 변경되었을 때 실행될 Plan을 지정하게 된다. Operator는 실행 중인 애플리케이션의 안전하게 갱신되는 것을 요구하기 때문에 파라미터의 변경에 밀접하게 연계된다. 예를 들어 NODE_COUNT의 변경은 단지 deploy plan을 실행하면 되지만, NODE_MEM_MIB는 canary 또는 blue/green deploy가 실행되어 새 버전을 Rollout 하는 것이 필요하다. 만일 파라미터에 trigger가 지정되지 않으면 기본적인 deploy plan이 실행된다.

물론 파라미터와 연계되지 않고도 수동으로 Plan을 동작시킬 수도 있다.
Default Plans

특별한 목적으로 KUDO가 사용하는 세 가지 Plan이 존재하며 다음과 같다.
- deploy : (필수) 기본 배포 Plan으로 위에서 설명한 파라미터에 trigger가 지정되지 않았을 떄 실행되는 기본 Plan 이다.
- upgrade : Operator 자체를 새로운 버전으로 갱신할때 사용하는 Plan으로 이 Plan이 지정되지 않으면 deploy plan이 실행된다.
- cleanup : Operator가 삭제될 때 사용되는 plan으로 Operator가 제거될 때 graceful shutdown이나 사용한 리소스들을 해제할 수 있는 기회가 된다. 추가적인 사항은 Cleanup Plans 참고
Deep dive into the KUDO CRDs

다시 정리하면 KUDO Manager는 Operator들을 처리하고, Plan들을 호출하는 등의 작업을 수행하는 클러스터에 배포된 Kubernetes Controller 세트이며, Kubernetes CDR 들을 활용해서 Kubernetes API를 확장한다.

중요한 구성들은 다음과 같다.
- Operator : Operator CRD는 Kubernetes 클러스터에서 실행할 애플리케이션에 대한 High levle의 설명을 포함한다. Operator 자체를 의미하는 것이 아니라 단지 대상이 되는 애플리케이션의 메타 정보를 의미하는 것이고, 특정 plan이나 리소스등은 포함되지 않는다. 클러스터에 여러 버전의 애플리케이션을 설치할 수 있도록 공통된 메타정보를 관리하는 하는 그룹 개념으로 생각하면 된다.
- OperatorVersion : 애플리케이션의 특정한 버전을 의미하고, Operator에 의해서 사용되는 Kubernetes 리소스들 (deployments, services, ...) 과 Plans, Parameters 들을 모두 포함하고 있다. 따라서 인스턴스화 되어 애플리케이션으로 동작할 수 있는 클래스처럼 생각하면 된다.
- Instance : OperatorVersion의 실체화되어 배포된 애플리케이션을 의미하고, OperatorVersion을 클래스라고 한다면 실체화된 객체를 의미한다. OperatorVersion에 정의된 기본 값을 재 정의할 수도 있고, 누락된 파라미터 값을 제공해야 한다. 인스턴스의 생성은 대부분의 경우는 Phases, steps에 따라 Kubernetes 리소스들을 렌더링하고 적용하는 deploy plan을 실행하는 것을 의미한다.
정리
- 하나의 Operator는 여러 개의 OperatorVersion을 가질 수 있다. 예를 들어 요구 사항에 따라 여러 팀이 서로 다른 Kafka 버전을 사용하는 것을 생각하면 된다.
- OperatorVersion과 Instance를 분리하는 것은 동일한 클러스터에 동일한 버전의 애플리케이션을 다른 팀들이 각각 사용할 때 유용하다. 예를 들어 동일한 OperatorVersion을 통하지만 별도의 구성이나 확장이 필요한 경우라고 생각하면 된다.
- Operator나 OperatorVersion은 관리자가 설정 및 처리한다. 사용자는 이 부분을 거의 볼 수 없다. Instance부터 사용자가 처리할 수 있으며 많은 CLI 명령들이 존재한다. 예를 들면 Instance를 생성하며 이름을 지정하는 등의 작업이 가능하다.
```
$ kubectl kudo install kafka --instance dev-kafka
```
Limitations
- Cross-namespace ownership and cluster-scoped resources
  - Instance가 생성한 모든 리소스는 Instance의 소유
  - Instance가 삭제되면 연계된 모든 리소스도 삭제
  - Operator, OperatorVersion, Instance 모두 namespace 범위로 한정이므로 리소스도 동일한 namespace만 가능
  - 다른 여러 namespace에 리소스를 생성하는 것은 불가능
  - cluster-scoped 리소스는 생성가능하지만 resourceOwners 팔드가 Instance 참조로 처리되지 않기 때문에 Instance가 삭제될 때 자동으로 삭제되지 않으며, Instance의 Update/Upgrade에서 문제가 발생할 수 있다. 이 부분은 KEP-5 (cluster-Resource-for-crds)를 통해 해결될 가능성이 존재한다.
- Reconciling arbitrary resources
  - KUDO는 임의의 사용자 지정 리소스 유형을 조정할 수 없다.
  - KUDO Controller가 조정할 수 있는 것은 Operator, OperatorVersion, Instance 등의 Custom Resource들이다.
  - KUDO Controller는 다른 임의의 리소스들을 생성하도록 설정된 정해진 Spec에 따르는 Plan을 실행해서 배포될 수 있도록 한다.

Architecture

위의 그림과 같이 KUDO CRDs / KUDO Controller 가 설치되어 동작하고 있으며, 실제 Operator에 대한 정보가 KUDO로 전달되면 내부적으로 운영되는 방식이다.

Components

kube-kudo

kubectl 플러그인 명령줄 클라이언트로 kubectl kudo 와 같은 방식으로 사용한다. 이 클라이언트는 개발자들이 KUDO Operator 생성을 지원하고, 운영팀이 Kubernetes cluster 내의 Operator들을 관리하는데 사용된다.
- Operator 개발
- End to end test harness execution
- Repository 개발 및 관리
- KUDO CRDs를 통해 구현된 KUDO Controller와 상호작용
  - Operator CRD들과 Operators 설치와 제거
  - Operator Plan의 실행과 상태 조회
  - Operator들의 Upgrade / Update, backup / restore
KUDO CRDs

KUDO를 지원할 수 있도록 Kubernetes API 확장
KUDO Controller

클러스터의 kudo-system namespace에 배포된 컨트롤러의 모음으로 KUDO CRDs에 정의된 서비스를 제공하고, KUDO Operator들을 관리한다.
- Kubernetes의 KUDO Object들을 관찰하고 원하는 상태가 되도록 처리
- KUDO Operator들을 생성하고, Operator의 Plan 호출
KUDO Repository

상당한 편의성을 제공하지만 반드시 필요한 것은 아니며 Operator들이 검색될 수 있도록 URL과 연계된 색인 정보를 제공한다. Operator Repository와 Operator Layout에 대한 자세한 정보는 여기를 참고하도록 한다.

Implementation

KUDO CLI와 Controller는 Go로 작성되었고, CLI는 Repository와 HTTP 통신을 사용하고 Controller와 통신하기 위해서 Kubernetes client-go를 사용하고 있다.
KUDO Controller는 를 사용해서 구축되었고, Kubernetes와 통신하는 의존성을 가지고 있다. 모든 KUDO의 상태는 CRD에 저장되기 때문에 별도의 데이터베이스 등은 필요하지 않다.
KUDO Operator들은 모두 YAML로 작성되었다.

Developing Operators

KUDO의 주요 구성 개념들은 다음과 같다.

Operator Packages
Plans
Tasks
Parameters
Templates

간단한 샘플로 만들 Operator는 Nginx를 클러스터에 배치하는 것으로 이 정도로는 KUDO가 필요하지 않다. 단지 KUDO의 강력함 보다는 어떤 과정을 거쳐서 처리하면 되는지를 보여주기 위한 샘플이다.

first-operator 라는 이름의 폴더를 하나 생성한다. 이 폴더는 local 패키지를 구성하는 것이다. (이 부분은 뒤에 설명할 Operator Package 단위다)
operator.yaml 파일을 first-operator 폴더에 생성하고 아래와 같이 구성한다.
```
 apiVersion: kudo.dev/v1beta1
 name: "first-operator"
 operatorVersion: "0.1.0"
 appVersion: "1.7.9"
 kubernetesVersion: 1.13.0
 maintainers:
   - name: Your name
     email: <your@email.com>
 url: https://kudo.dev
 tasks:
   - name: app
     kind: Apply
     spec:
       resources:
         - deployment.yaml
 plans:
   deploy:
     strategy: serial
     phases:
       - name: main
         strategy: parallel
         steps:
           - name: everything
             tasks:
               - app
```
위의 내용은 deploy 라는 하나의 plan을 가지는 Operator로 하나의 Phase와 하나의 step으로 구성된 최소 설정이다. 이 Operator의 Instance를 클러스터에 배포하면 자동으로 deploy plan이 트리거 된다. step에 지정된 task는 app이고 해당 task는 참조하는 리소스로 deployment.yaml을 참고하고 있다. KUDO는 이 파일이 templates 폴더에 존재하는지를 검증한다.
deployment.yaml 파일을 first-operator/templates 폴더에 생성하고 아래와 같이 설정한다.
```
 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-deployment
 spec:
   selector:
     matchLabels:
       app: nginx
   replicas: {{ .Params.replicas }} # tells deployment to run 2 pods matching the template
   template:
     metadata:
       labels:
         app: nginx
     spec:
       containers:
         - name: nginx
           image: nginx:{{ .AppVersion }}
           ports:
             - containerPort: 80
```
위의 파일 내용은 일반적인 Kubernetes의 Deployment를 정의하는 YAML 파일이다. 그러나 잘 보면 KUDO의 템플릿 기능을 사용해서 {{ .Params.replicas }} 처리한 것을 볼 수 있다. .Params는 params.yaml에 정의된 파라미터 정보를 참조하는 것으로 설치를 진행하면서 지정한 파라미터를 정의한 파라미터의 값으로 재 정의해서 처리한다.
params.yaml 파일을 first-operator 폴더에 생성하고 아래와 같이 구성한다.
```
 apiVersion: kudo.dev/v1beta1
 parameters:
   - name: replicas
     description: Number of replicas that should be run as part of the deployment
     default: 2
```
여기까지해서 첫 번째 Operator를 클러스터에 설치할 수 있는 준비를 했다. 아래의 명령을 통해서 실행이 가능하다.
터미널에서 설치 명령 실행
```
 $ kubectl kudo install ./first-operator
```
위의 명령에서 ./first-operator 값은 실제 Operator Package 폴더를 상대적인 경로를 기준으로 지정하면 된다.

이 작업을 위해서는 KUDO CLI 가 설치되어 있어야 한다. 설치를 하면 KUDO에서 사용자의 Operator를 처리하는데 필요로 하는 Operator, OperatorVersion, Instasnce 와 같은 다양한 리소스들이 설치된다.
클러스터에서 아래와 같이 생성된 정보들을 확인할 수 있다.
```
 # Get instances
 $ kubectl get instances

 # or
 $ kubectl kudo get instances
```
위의 결과가 정상적이라면 아래의 명령으로 pod 정보를 확인할 수 있다.
```
 $ kubectl get pods
```

이제 KUDO에서 이야기하는 Day 2 Operating에서 Day 1에 해당하는 설치 절차를 확인해 보았다. 실제 설치한 Operator에 대한 테스트는 Test harness document룰 참고하도록 한다.

Operator Package

패키지는 Oeprator를 설명하는데 필요한 모든 파일들을 번들로 처리하며 패키지의 구조는 다음과 같다.

.
├── operator.yaml
├── params.yaml
└── templates
    ├── deployment.yaml
    └── ...

operator.yaml : Operator의 전체 라이프사이클과 메타데이터를 정의하는 메인 YAML 파일이다. Tasks와 Plans는 모두 이 파일에 정의되어 있다. Operator name, version, 유지관리자등의 정보를 제공하는 메타데이터도 여기에 설정된다.
params.yaml : Opearator에서 사용되는 파라미터들을 정의한다. 설치하는 동안 사용자에 의해서 여기에 정의된 파라미터들은 재 정의될 수 있다.
templates/ : operator.yaml에 정의된 워크플로우에 기반해서 설치가 된 후 클러스터에 적용할 모든 템플릿화된 Kubernetes objects이 존재한다.

Tasks

Task는 KUDO 워크플로우의 기본적 빌딩 블록이다. Plan, Phases, Steps 는 Task를 실행하는 제어적인 구조들이며, KUDO는 Apply, Delete, Pipe, Toggle, KudoOperator 라는 주요 Task를 제공하고 oeprator를 테스트하고 디버깅하기 위한 Dummy 형식을 제공하고 있다.

모든 Taks들은 operator.yaml 파일에 정의되고 name, kind, spec 의 세 가지 필드를 반드시 포함해야 한다.

tasks:
  - name: # Task name defined by the user
    kind: # Task kind can be: Apply, Delete, Pipe, Toggle, KudoOperator and Dummy
    spec: # Task-specific specification

Apply-Task

appy-task는 템플릿을 클러스터에 적용하는 것으로 spec.resources 필드는 존재하지 않는다면 생성하고 존재한다면 갱신할 Kubernetes 리소스 리스트 목록을 정의한다.
```
tasks:
  - name: app
    kind: Apply
    spec:
      resources:
        - deployment.yaml
```
app 라는 이름의 Task는 templates/deployment.yaml에 정의된 리소스의 deployment를 생성한다.

KUDO는 정의된 리소스 리스트를 모두 적용하고 모든 리소스가 정상화할 때까지 대기한다. 상태는 특정 리소스마다 달라지며 배포는 Spec으로 정의된 isntance 수가 모두 생성되고 실행되어야 하고 Job은 모두 정상적으로 끝나야 한다.
참고
- 현재의 구현은 Pod가 미리 생성된 ConfigMap을 마운트할 수 있도록 정의된 순서에 따라서 모든 리소스들을 적용하는 방식이다. 이 부분은 규격의 일부가 아니며 향후 모든 리소스가 동시에 적용될 수 있는 것처럼 변경될 수 있고 리소스간에 순서가 중요한 경우는 순차적인 steps를 사용해야 한다.
  
  apply-task는 KUDO 특정 라벨과 어노테이션을 통해서 배포된 자원을 강화한다. 파드를 셍성하거나 배포하는 리소스 (StatefulSets, Deployments, Daemonsets, ...)의 경우는 KUDO가 pod template spec (ConfigMaps and Secrets)에 의해서 사용되는 모든 리소스들의 hash를 pod template specdp 특정 라벨을 추가한다. 이 해시값의 효과는 ConfigMan을 변경하는 Operator parameter에 대한 갱신으로 해당 ConfigMap을 사용하는 Pod의 재 시작을 호출하게 된다.
- Pod는 단지 상위 리소스 (StatefulSet, Deployment)가 적용되는 경우에 재 시작된다. 이런 처리는 동일한 Task의 종속성이나 동일한 plan의 이후 실행되는 Task에 의해서 발생할 수 있다. 즉 ConfigMap만 수정하고 ConfigMap을 사용하는 StatefulSet이 변경되지 않는 경우라면 plan이 실행되도 Pod는 재 시작되지 않는다는 것을 의미한다.
- Pod 재 시작을 트리거하는 경우에서 ConfigMap 또는 Secret을 제외하려면 ConfigMap 또는 Secret에 임의 값과 kudo.dev/skip-hash-calculation 주석을 추가하면 된다.
Delete Task

apply-task를 사용해서 생성한 리소스들을 삭제하는 Task이다.
```
tasks:
  - name: remove
    kind: Delete
    spec:
      resources:
        - deployment.yaml
```
참고

delete-task는 실제 성공/실패 여부와 상관없이 무조건 성공으로 처리된다. KUDO 0.9.0 에서는 API 서버가 삭제 요청을 받아들이면 실제 리소스가 삭제되는 것을 기다리지 않고 Task를 종료한다. Kubernetest에서는 Pod의 종료에 기본 시간을 30초를 지정해 놓았지만 KUDO 0.9.0 버전에서는 요청이 받아들여지면 처리된 것으로 간주한다.
Toggle-Task

Operator 기능을 개발할 때 리소스를 활성/비활성 처리할 때가 존재한다. toggle-task는 파라미터의 boolean 값을 기준으로 리소스를 적용하거나 삭제한다.
```
tasks:
  - name: app-service
    kind: Toggle
    spec:
      parameter: enable-service
      resources:
        - service.yaml
```
위 작업은 enable-service 파라미터의 값을 기준으로 templates/service.yaml에 정의된 리소스를을 적용하거나 삭제하는 것이다. 당연히 사용하는 enable-service 파라미터는 params.yaml에 정의되어 있어야 한다. 만일 없다면 toggle-task는 실패하게 된다.
Pipe-Task

복잡한 Operator들을 개발하다보면 종종 한 step에서 파일들을 생성하고 다음 step에서 이를 사용하는 경우가 많다. 일반적인 예는 bootstrap step 에서 사용자 지정 certifications/dynamic 설정 파일을 생성하고, 서비스의 배포 step에서 이를 사용하는 것이다. 이런 상황에서 pipe-task가 도움이 될 수 있다. 예를 들어 index.html를 생성하고 Nginx 서버와 함께 배포할 수도 있다.
```
tasks:
  - name: genwww
    kind: Pipe
    spec:
      pod: pipe-pod.yaml
      pipe:
        - file: /tmp/index.html
          kind: ConfigMap
          key: indexHtml
```
pipe-task spec은 두 개의 필드를 가진다. pod spec은 index.html을 생성하고 저장할 파일들의 리스트를 정의한다. 생성된 /tmp/index.html 파일은 ConfigMap으로 저장될 것이다. indexHtml 이라는 키로 템플릿 리소스에서 참조가 되며 pipe-task의 spec.pod 는 core/v1 Pod 템플릿을 반드시 참조해야 한다. 그러나 한계가 존재한다. 이에 대해서는 KEP를 참고한다.
- pipe-pod.yaml은 initContainer에 파일을 생성한다.
- 파일들이 저장될 emptyDir Volume 하나를 정의하고 마운트해야 한다.
아래는 templates/pipe-pod.yaml 이다.
```
apiVersion: v1
kind: Pod
spec:
  volumes:
  - name: shared-data
    emptyDir: {}
  initContainers:
    - name: init
      image: busybox
      command: [ "/bin/sh", "-c" ]
      args:
        - wget -O /tmp/index.html 'http://cowsay.morecode.org/say?message=Good+things+come+when+you+least+expect+them&format=html'
      volumeMounts:
        - name: shared-data
          mountPath: /tmp
```
위는 온라인 cowsay-generator API를 이용해서 결과를 /temp/index.html 파일로 다운로드 한다.

위의 pipe-pod.yaml과 genwww task 사양에 따라서 KUDO는 pipe-pod를 실행하고 성공적으로 index.html 파일이 생성될 때까지 기다리고 이를 ConfigMap으로 저장한다. 이 파일은 이제 Nginx 배포 spec에서 사용될 것이다.
```
...
spec:
  containers:
    - name: nginx
      image: nginx:1.7.9
      ports:
        - containerPort: 80
      volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html/
  volumes:
    - name: www
      configMap:
        name: {{ .Pipes.indexHtml }}
```
ConfigMap으로 부터 마운트 볼륨을 생성했다. {{ .Pipes.indexHtml } } 을 이용해서 ConfigMap 이름을 지정하고, .Pipes 키워드는 pipe-artifacts를 처리할 수 있도록 하고, indexHthml은 pipe-task에서 정의한 키다.

이제 Task를 기준으로 아래와 같이 deploy plan을 구성할 수 있다.
```
...
plans:
  deploy:
    strategy: serial
    phases:
      - name: main
        strategy: serial
        steps:
          - name: genfiles
            tasks:
              - genwww
          - name: app
            tasks:
              - app
```
위에서 strategy: serial은 순차적 진행으로 genfiles step에서 파일이 생성되기를 기다리고 다음 step에서 이를 사용할 수 있도록 하는 것이다.
참고
- 파일을 생성하는 pod는 장애가 발생했을 때 여러 번 실행될 수 있기 때문에 부작용 (side-effect - 타사 API 호출처럼 컨테이너 외부에서 관측할 수 있는 부적용을 의미함)이 없어야 한다. restartPolicy: OnFailure 는 pipe-pod 에 대해서 사용할 수 있다.
- 1M 이하의 파일만 ConfigMap이나 Secret으로 저장할 수 있다. 1M 보다 큰 파일은 pipe-task가 실패한다.
- KUDO 0.9.0에서는 pipe-artifacts는 동일한 plan에서만 사용할 수 있다.
- 하나의 pipe-task에서 artifacts를 생성하고 후속 task에서 마운트해서 pipeline 처리를 할 수 있다.
KudoOperator Task

KUDO 0.15.x 기준으로 다른 Opeator들에 대한 종속성을 지정할 수 있는 KudoOperator Task를 지원한다. 종속성은 복잡한 주제지만 KudoOperator 자체는 설치 종속성에 대한 것으로 Operator Instance와 모든 종속성 (전환성 포함)를 하나의 단위로 설치하거나 제거할 수 있게 한다.

KUDO Operators는 Plans, Phases, Steps라고 부르는 설치 의존성을 순차 또는 병렬 수행 전략 기준으로 수행하는 매커니즘을 가지고 있다. 이 매커니즘은 전이적 종속성과 모든 종속성 계층을 표현하기에 이미 충분히 강력하다.

Zookeeper Operator version 0.3.0 (install Zookeeper v3.4.14)에 대한 종속성을 지정하는 간단한 샘플이다.
```
tasks:
  - name: deploy-zookeeper
    kind: KudoOperator
    spec:
      package: zookeeper
      operatorVersion: 0.3.0
```
다른 Task와 마찬가지로 KUDO도 다음 Task로 넘어가기 전에 healty 검증을 한다. 아래의 예는 deploy plan을 사전 준비와 기본인 두 개의 Phase로 구성한 것이다.
```
plans:
  deploy:
    strategy: serial
    phases:
      - name: prereqs
        strategy: parallel
        steps:
          - name: first
            tasks:
              - deploy-zookeeper
      - name: main
        strategy: parallel
        steps:
          - name: second
            tasks:
              - deploy-main
```
"Healthy"는 이 경우 deploy plan이 COMPLETE 인 것을 의미한다. KudoOperator는 appVersion (최신 버전이 기본 값)과 instanceName (KUDO에 의해서 기본적으로 생성됨)을 추가적으로 지정할 수 있는 kubectl kudo install 명령과 의미론적으로 근접하게 모방하는 것이다. 이 명령과 마찬가지로 local operator (또는 원격 tarball)를 Package field로 지정할 수 있다. (e.g package: "./child-operator") 상위 Operator가 설치되는 동안 KUDO CLI는 하위 종속성을 해결하고 Operator 구문 분석과 필요한 리소스를 생성한다.

만일 종속성이 local이고 상대 경로 (./child-operator)라면 다음과 같이 처리된다.
- 정의되어 있는 operator.yaml 에 대해 상대 경로로 판단한다.
- kudo install command처럼 ./ 또는 ../ 로 접두사를 붙여야 한다.
따라서 다음과 같은 Operator Tree가 지정된다.
```
.
├── child
│   └── operator.yaml
│
└── parent
    └── operator.yaml
```
Child Operator는 parent/operator.yaml에 아래와 같이 상대 경로 지정된다.
```
  - name: child
    kind: KudoOperator
    spec:
      package: "../child"
```
Dependency Parametrization

하위 Operator가 파라미터화 되어야할 필요성이 있다면 parameterFile 필드를 사용해서 파라미터 변수 파일을 지정할 수 있다. 예를 들어 상위와 하위 Operator가 있을 때 하위가 빈 값을 기본 값으로 하는 필수 PASSWORD 파라미터가 있다면 상위는 하위를 위해서 파라미터 파일을 지정하고 연관된 KudoOperator에서 참조할 필요가 있다.
```
tasks:
  - name: deploy-child
    kind: KudoOperator
    spec:
      package: child-operator
      parameterFile: child-params.yaml 
```
child-params.yaml은 다른 템플릿 파일과 같이 상위 Operator의 템플릿 폴더에 위치한다.
```
# parent/templates/child-params.yaml
PASSWORD: {{ .Params.CHILD_PASSWORD }}
```
하위 Oeprator에 전달될 PASSWORD 값은 상위 Operator의 파라미터로 CHILD_PASSWORD를 이용한다.
```
# parent/params.yaml
apiVersion: kudo.dev/v1beta1
parameters:
  - name: CHILD_PASSWORD
    displayName: "child password"
    description: "password for the underlying instance of child operator"
    required: true
```
따라서 사용자가 상위 Operator를 설치할 떄 평소와 같이 파라미터를 지정하면 된다.
```
$ kubectl kudo install parent -p CHILD_PASSWORD=secret
```
참고

상위 Operator가 합리적인 기본 값을 제공하거나 사용자에게 노출시키지 않기 위해서 하드 코드로 지정할 수도 있다. 전체적으로 Operator 캡슐화 방법을 제공해서 Operator 구성을 권장한다. 즉 포함된 Operator instance들의 파라미터를 사용자가 임의로 수정하도록 해서는 안된다는 말이다. 상위 Operator는 직접 연결된 하위 Operator가 필요로 하는 모든 파라미터를 정의해야 한다. 자세한 정보는 KEP-29를 참고하면 된다.
Dummy Task

Dummy-Task는 처리가 성공이나 실패할 수 있으며 KUDO Operator 워크플로우를 테스트하거나 디버깅하는데 유용하다.
```
tasks:
  - name: breakpoint
    kind: Dummy
    spec:
    wantErr: true # If true, the task will fail with a transient error
    fatal: true # If true and wantErr: true, the task will fail with a fatal error
    done: false # if true, the task will succeed immediately
```
이런 task는 Operator 워크플로우에서 중단점으로 유용하고 Operator 개발자가 임의의 step에서 실행을 일시 중지하거나 실패하도록 할 수 있다.
참고
- wantErr 은 done 보다 우선한다.
- fatal error를 원하는 경우는 wantErr과 fatal을 모두 true로 설정해야 한다.
- wantErr, fatal, doen 모두가 false인 경우는 일시 정지한다. (일반적으로 Unhealthy 상태의 자원 시뮬레이션용)

Plans

plan은 운영 과제들 (Tasks)의 개별적인 단계들 (Steps)을 파악하고 이런 업무적인 과제들을 Phases와 Steps 조합으로 구성한다. 각 Step은 실행할 과제들을 참조한다. Task를 Phases 와 Steps 로 정리하면 서비스의 복잡한 행동들을 파악할 수 있다.

Plans 와 Phases 는 전략을 가지고 동작하며 순차적 (Serial)로 동작할지 병렬 (Parallel)로 동작할지를 나타낸다.

...
tasks:
  - name: deploy-master
    kind: Apply
    spec:
      resources:
        - master-service.yaml
        - master.yaml
  - name: deploy-agent
    kind: Apply
    spec:
      resources:
        - agent-service.yaml
        - agent.yaml
plans:
  deploy:
    strategy: parallel
    phases:
      - name: deploy-master
        strategy: serial
        steps:
          - name: deploy-master
            tasks:
              - deploy-master
      - name: deploy-agent
        strategy: serial
        steps:
          - name: deploy-agent
            tasks:
              - deploy-agent

KUDO Controller는 Operator에 정의된 Plans 를 배포하며, 한번에 하나의 plan만 배포할 수 있다. KUDO는 어떤 plan을 배포할지를 결정하는 접근 방식이 다르다.

Deploy and update plans

기본적으로 KUDO는 어떤 plan도 배포되지 않은 상황이라면 deploy plan을 시작할 것이다. Instance를 갱신하는 상황이라면 KUDO는 upgrade 또는 update plan이 존재하는지를 검증하고 이를 시작하려고 한다. 만일 해당 plan이 모두 없다면 deploy plan을 시작한다.

아래 예는 service.yaml에 정의된 서비스를 생성하는 deploy plan이다. 갱신 상황이라면 서비스의 캐시를 갱신해야 하는데 update-cache.yaml은 update plan의 일부로 필요한 리소스를 제공한다.
```
...
tasks:
  - name: app
    kind: Apply
    spec:
      resources:
        - service.yaml
  - name: update
    kind: Apply
    spec:
      resources:
        - service.yaml
        - update-cache.yaml
plans:
  deploy:
    strategy: serial
    phases:
      - name: deploy-service
        strategy: serial
        steps:
          - name: deploy
            tasks:
              - app
  update:
    strategy: serial
    phases:
      - name: update-service
        strategy: serial
        steps:
          - name: update
            tasks:
              - update
```
Cleanup plans

Operator에 옵션이기는 하지만 cleanup plan이 존재한다면 이 plan은 Instance가 삭제될 때 KUDO Manager에 의해서 자동으로 실행되며 이 plan이 성공하던 실패하던 Instance는 삭제된다. 당연히 Instance의 정상적인 라이프사이클 동안에 cleanup plan을 트리거하면 오류가 발생하게 된다. 추가로 이 plan의 step은 실패할 것으로 예상해야 한다. 에를 들어 사용자가 deploy plan이 고착되어 instance를 삭제하길 원하는 상황일 수도 있으며 이런 상황이라면 cleanup plan은 리소스를 삭제하려고 시도하는데 해당 리소스가 클러스터에 존재하지 않을 수도 있기 떄문이다. 따라서 다른 plan이 동작하는 중이라도 cleanup plan은 시작된다.
```
...
tasks:
  - name: database
    kind: Apply
    spec:
      resources:
        - database.yaml
  - name: cleanup
    kind: Apply
    spec:
      resources:
        - cleanup-job.yaml
spec:
  plans:
    deploy:
      strategy: serial
      phases:
        - name: deploy-database
          strategy: serial
          steps:
            - name: deploy
              tasks:
                - database
    cleanup:
      strategy: serial
      phases:
        - name: cleanup-databse
          strategy: serial
          steps:
            - name: cleanup
              tasks:
                - cleanup
```
Instance가 삭제되면 instance에 속한 모든 리소스가 자동으로 삭제되므로 database.yaml은 삭제할 필요가 없다. 그러나 복잡한 애플리케이션의 경우는 가끔 Kubernetes 리소스로 포착되지 않는 상태를 만들기도 한다. 이런 상황이라면 Operator를 제거할 떄 이 상태를 제거할 수 있으므로 cleanup plan에서 이를 처리할 수 있다. 위의 예제에서는 연계된 Task의 cleanup-job.yaml 에서 필요한 작업을 번들로 묶어서 처리한다. 일반적으로 cleanup plan을 Instance가 삭제되기 전에 호출된다는 점을 제외하면 다른 모든 plan과 동일하다.

cleanup plan은 Finalizers를 사용해서 구현되었고 Instance의 metadata.finalizers에는 cleanup plain이 동작하는 동안 "kudo.dev.instance.cleanup" 값이 설정된다.
Parameter Trigger

파라미터는 옵션으로 tigger 속성을 가지고 있고 트리거를 통해서 plan을 지정한다. 따라서 파라미터가 변경되면 지정된 plan이 실행된다.

실행 중인 애플리케이션을 갱신하는데 필요한 작업은 어떤 파라미터가 변경되는지에 따라 달라질 수 있다. 예를 들어 BROKER_COUNT 가 변경되었다면 간단히 배포를 통해서 갱신되는 것이지만, APPLICATION_MEMORY 가 변경되는 경우는 canary 또는 blue/green 배포를 통한 새로운 버전을 Rollout 하는 갱신이 될 수도 있다는 것이다.
```
...
parameters:
- name: REPLICAS
  trigger: deploy
- name: APPLICATION_MEMORY
  trigger: canary
```
Executing Plans

KUDO Manager는 파라미터의 변경에 따라 자동적으로 연계된 plan을 실행하지만 가끔 수동으로 plan을 실행시켜야 할 때도 존재한다. 예를 들어 데이터 손상에 대비하기 위해서 주기적으로 백업 plan을 실행해야 하는 경우는 어떤 파라미터가 변경되는 것이 아니기 때문에 수동으로 처리를 해 줘야 한다. KUDO v0.11.0 에서는 이를 위해 수동으로 plan을 호출하는 명령을 제공하고 있다.
```
$ kubectl kudo plan trigger --name deploy --instance my-instance
```
위의 명령은 deploy plan을 my-instance라는 이름으로 지정된 instance에 대해서 실행하라는 의미다. 단순해 보이지만 실제 구동되는 상황을 잘 살펴봐야 한다.

Plan Life Cycle

필요에 따라서 두 개의 plan이 실행될 수 있다면 (현재는 하나만 실행 가능) 동시에 plan이 동작할 때 어떤 문제가 생길지 생각해 봐야 한다. 만일 plan이 서비스 deploy plan과 monitoring pod를 배포하는 monitoring plan 이라면 서로 연관성이 없어서 병렬로 동작해도 별 문제가 없겠지만, 두 plan이 백업 / 복구 또는 배포 / 마이그레이션 과 같이 연관성이 있는 것이라면 서로 병렬로 동작할 수 없는 상황이며 데이터의 손상을 야기할 수도 있는 문제가 존재한다.

현재는 Plan에 대한 선호도/반선호도, 재선정/비선정, 취소 등 많은 것들을 검토 중에 있다.

Admission Controllers

간단히 보면 Kubernetes admission controller는 클러스터가 어떻게 사용되어야 하는지를 제어하고 실행하는 플러그인으로 인증된 API 요청을 가로채는 GateKeeper로 생각할 수 있으며 요청 객체를 변경하거나 요청을 전면 거부할 수 있다. Kubernetes는 이미 사용자 권한 부여부터 네임스페이스의 수명주기까지 모든 것을 통제하는 등의 사전 설치된 제품을 가지고 있다.

KUDO Manager는 Instance의 변경을 관리하는 Instance admission controller를 사용해서 plan들이 간섭되지 않도록 하고 있다. 아래와 같이 요청은 처리되고 있다.

Instance admission controller는 수동으로 실행된 plan 또는 파라미터가 변경되서 실행된 plan을 통해서 instance의 갱신을 모두 관리한다. 일반적으로 새로운 plan이 시작되기 전에 모든 계획은 성공 (COMPLETE)이던 실패 (FATAL_ERROR)이던 종료된 상태여야 한다. 단 하나의 plan만 다시 시작될 수 있고 모든 plan이 재 시작될 수 있을 것으로 간주한다. 요청이 거부되면 instance controller는 명확한 거부 사유를 오류로 반환한다.

또한 파라미터의 변경으로 여러 개별적인 Plan 들이 동작하는 것을 거부한다. 물론 instance가 삭제될 떄 실행되는 cleanup plan은 예외가 된다. 단, cleanup plan은 수동으로 트리거를 할 수 없다.

KUDO 0.11.0의 경우 Instance admission controller는 선택 사항이지만 향후는 의무가 될 예정이다.

Operator Parameters

Operator Parameter는 Operator 개발자가 정의한 key-value 쌍으로 Operator 사용자는 배포할 떄 재정의해서 사용할 수 있으며, 이를 통해서 Operator의 동작을 커스터마이징할 수 있다.

참고

kubectl kudo package list parameters (operatorname) 명령을 통해서 Operator에 연관된 모든 파라미터의 리스트를 확인할 수 있다.

Declaring parameters

개발자는 params.yaml 파일에 파라미터들은 정의한다. 이 파일은 필수적이고 Operator의 root 디렉터리에 존재해야 한다. 파라미터가 필요없는 경우라면 빈 파일이라도 존재해야 한다.
```
apiVersion: kudo.dev/v1beta1
parameters:
  - name: BACKUP_FILE
    description: "Filename to save the backups to."
    default: "backup.sql"
    displayName: "BackupFile"
  - name: PASSWORD
    default: "password"
    trigger: backup
  - name: OPTIONAL_PARAM
    description: "This parameter is not required."
    required: False
  - name: REQUIRED_PARAM
    description: "This parameter is required but does not have a default value."
    required: True
  - name: ARRAY_PARAM
    description: "This parameter describes an array of values."
    default:
      - user1
      - user2
    type: array
  - name: MAP_PARAM
    description: "This parameter describes a map of values."
    default:
      label1: foo
      label2: bar
    type: map
```
파라미터는 아래와 같은 속성들로 구성된다.
- name : 필수이며 파라미터 이름이다. 대문자로 단어 단위를 '_'로 연결하는 관례를 사용한다.
- displayName : 선택적이며 파라미터의 보여질 이름이다. 다른 곳에는 사용되지 않고 KUDO UI에서 사용된다.
- description : 선택적이며 파라미터의 목적에 대한 설명이다. 다른 곳에는 사용되지 않고 KUDO UI에서 사용된다.
- type : 선택적이며 파라미터 값의 형식을 지정한다. 기본 값은 string 이고, array, map 등도 가능하며 이 경우는 YAML 포맷에 맞도록 값을 지정해야 한다.
- default : 선택적이며 파라미터의 기본 값을 지정한다. 이 속성을 생략하면 해당 파라미터는 required로 설정된다. 이를 변경하려면 required 속성 값을 지정해야 한다.
- required : 선택적이며 설치 시에 파라미터가 반드시 제공되어야 하는지 여부로 true로 설정되어 있는데 설치 시에 제공되지 않으면 설치가 실패하게 된다.
- tigger : 선택적이며 초기 설치 이후에 파라미터의 변경에 따라서 트리거될 Plan을 설정한다. 만일 지정하지 않는다면 update나 deploy plan이 실행된다.
- immutable : 선택적이며 기본 값은 false로 Instance에 대한 갱신할 떄 변경이 가능하지를 나타내는 것이다. 만일 true로 설정된다면 반드시 required 또는 default 값을 가져야 하며 Instance가 설치될 떄 파라마터 값을 설정해야 하며, 나중에는 변경할 수 없는 상태가 된다.
Overriding parameters

Operator 사용자가 CLI를 통해서 파라미터를 재 정의할 수 있다.

kubectl kudo 명령에서 install, upgrade, update 등의 명령을 수행할 때 --parameter 또는 -p 플래그를 사용해서 처리한다. 지정하는 파라미터는 PARMATER_NAME=parameter_value 형식으로 처리하고 Array의 경우는 PARAMTER_NAME=[array_value1, array_value2]로 처리하고 Map의 경우는 PARAMTER_NAME={map_key1:map_value1, map_key2:map_value2} 와 같이 처리한다.

이 플래그는 여러 파라미터를 지정할 수 있도록 여러 번 사용할 수 있다.
Tiggers

Operator 개발자가 update때 파라미터가 변경되면 실행될 plan의 이름을 지정할 수 있다. 달리 말하면 이 plan이 파라미터의 변경된 값을 Kubernetes 애플리케이션에 적용한다는 의미가 된다. 이를 지정하지 않으면 기본적으로 update plan을 호출하고 이 plan이 없다면 deploy plan을 호출하게 된다.

단, 현재 하나 이상의 plan을 트리거하도록 파라미터를 설정할 수는 없다.
Immutability

Operator는 종종 설치 시점에 설정한 파라미터를 나중에 바꿀 수 없도록 하는 경우가 존재한다. 에를 들어 KUDO Cassandra Operator는 NUM_TOKENS라는 관리되는 클러스터의 각 노드들이 관리할 토큰의 갯수를 지정하는 파라미터를 가지고 있는데, 이 파라미터의 값은 설치할 때 적용되면 Cassandra Cluster의 라이프사이클 동안 변경할 수 없고, 이 값을 변경해야 하는 경우라면 다른 파리미터의 값으로 새로운 Cluster를 구성하고 데이터를 마이그레이션 해야 한다.

이런 불변 파라미터는 기본 값을 가지거나 required로 설정되어야 한다. 즉 설치 시점에 반드시 값이 필요하다는 것이다.

보다 자세한 사항은 KEP-30를 참고한다.

Templates

KUDO는 GO 템플릿 엔진을 사용하고 스플릭 템플릿 기능을 사용할 수도 있다. 이를 통해서 사용자가 파라미터 처리된 Operator 기능을 사용할 수 있도록 하며, Operator Package의 templates 디렉터리에 있는 모든 파일에 적용되어 있다.

Vaiables

{{.Variable}} 형식으로 변수의 값을 적용할 수 있다.
- .Params : params.yaml에 정의된 instance parameter에 접근할 수 있다. 예를 들어 REPLICAS 파라미터를 사용할 경우는 {{.Params.REPLICAS}}와 같이 사용한다.
- .OperatorName : Operator 명
- .Name : 현재 Instance 명
- .Namespace : Instance가 속한 namespace 명
- .Pipes : Pipeline Parameter
- .PlanName : Instance의 활성화된 Plan 명
- .PhaseName : Instance의 활성화된 Plan의 활성화된 Phase 명
- .StepName : Instance의 활성화된 Plan의 활성화된 Phase의 활성화된 Step 명
- .AppVersion : 애플리케이션의 버전 정보
Functions

입력 값을 변수처럼 변환하고, Pipeline을 이용하면 다른 함수의 결과를 다른 함수의 입력으로 사용할 수도 있다. 이 함수 기능은 Go 템플릿과 Sprig 템플릿에서 제공된다.
- Go Template
  - Compare : eq, not, ne, lt, ... 등과 같이 Go Template의 비교 연산자 사용 가능
  - Simple Calculate : len, and, or, add, mul, ... 등과 같은 단순 연산 함수 사용 가능
  - Text manipulation : html, js, trim, wrap, ... 등과 같은 문자열 처리 함수 사용 가능
- Sprig Template : 환경 접근을 허용하는 Sprig 함수들은 비활성화된다. env, expandenv, base, dir, clean, ext, isAbs, ...
- KUDO Provide
  - toYAML : 아규먼트들을 YAML로 반환하며, | trim | indent N 등과 같이 사용한다.
Actions

Action은 템플릿에서 분기 또는 반복 처리에 사용한다. 아래의 내용은 몇 가지 예시로 보다 자세한 사항은 Go Template Actions를 참고한다.
- Perform arithmetic using parameters
  
  모든 .Params는 문자열 형식이기 떄문에 처리하기 전에 형식 변환을 먼저해야 한다. 아래의 예는 파라미터에서 1을 뺴는 것이다.
```
{{ sub (atoi .Params.NODE_COUNT) 1 }}
```
- Enable or disable features using a feature parameter
  
  .Params.ENCRYPTION 파라미터가 true/false인지에 따라서 HTTP/HTTPS로 설정한다.
```
spec:
  ports:
    {{ if eq .Params.ENCRYPTION "true" }}
    - name: https
      port: 443
    {{ else }}
    - name: http
      port: 80
    {{ end }}
...
```
- Create objects for a specific number
  
  .Params.VOLUMES 에 따라서 persistent volume claims를 생성한다.
```
{{ range $i, $v := until (int .Params.VOLUMES) }}
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim-{{ $i }}
...
{{ end }}
```
Limitations

일부 Kubernetes Object들은 템플릿으로 사용할 수 없다. 대표적인 예가 Jobs로 spec.template 필드는 변경할 수 없으며, Job이 적용된 후에는 이 필드롤 변경할 수 없다. spec.template를 템플릿화된 파라미터로 변경을 시도하면 아래와 같은 오류가 발생된다.
```
... failed to execute patch: Job.batch "xxx" is invalid: spec.template: Invalid value: core.PodTemplateSpec{...} field is immutable
```
이런 문제는 해당 Job을 삭제 (Delete Task 사용)하고 다시 생성해야 하며, 이 작업은 Operator Developer의 선택이다.

CLI Usage

Concepts

Operator
- High level description of a deployable service
- A deployable service can be anyting that you'd want to run on your cluster
- Represented as a CRD Object
- 여러 개의 OperatorVersion 정보를 가질 수 있다.
OperatorVersion
- Implementation of an Operator
- Specific version of a deployable application
- Contains parameters, objects, plans
- 여러 개의 Instance 정보를 가질 수 있다.
Instance
- Tiles application instantiation to an OperatorVersion
- Once created, renders parameters in templates such as services, pods or StatefulSets
- Can create multiple instances of an OperatorVersion within your cluster
Plan
- Orchestarate tasks through phases and steps
- A structured 'runbook' which can then be executed by software
- Typically define several plans:
  - Deploy
  - Backup
  - Restore
  - Upgrade
- Phases and steps can be run serial or parallel
CLI
- CLI extension to kubectl
- Can still use 'vanilla' kubectl

Roadmap

Dynamic CRDs : Manage the lifecycle of operator CRDs for the operator developers and users
Operator Dependencies : Ability for KUDO to support a wide range of dependencies (from existing instances and connection strings to entirely new dependencies that are KUDO managed), and for tighter control of dependency specification by operator developers
Operator Extensions : Extend from other formats such as other KUDO operators, Helm charts, or CNAB bundles without forking and operator
Something other than YAML! : Starlark or CUE like candidates
Pipe Tasks
- Generation of content which can then be 'piped' to another task
- e.g certicate generation / creation as part of bootstrap
- Just landed (https://github.com/kudobuilder/kudo/pull/1105)
Helm chart
- Import and extend
Operator Development
- Skeleton Generator
  - Also just landed (https://github.com/kudobuilder/kudo/pull/1206, https://github.com/kudobuilder/kudo/pull/1222)
- Linter
- Snippet / extension library
KUDO API
Operator Extensions

KUDO는 Dev/Ops 팀이 Operator 관리를 통해서 상태 저장 서비스를 포함해서 Kubernetes 환경에서 Day 2 Operating 관리를 할 수 있도록 설계되어 초기 배포 이상의 지원 (백업, 복구, 관찰, 업그레이드 등) 한다. 실제 발생하는 사례는 다음과 같다.

참고 자료

KUDO

[Kubernetes - Operator] KUDO CLI 명령어 정리

ccambo — Mon, 21 Dec 2020 16:48:52 +0900

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를 대상으로 하며 저장되지 않기 때문에 매번 제공해야 한다.

주의

설치에 사용한 옵션들은 update / upgrade 등에도 동일하게 지정되어야 한다.

초기화 관련 옵션
- n, --namespace <namespace> : KUDO 초기화를 위한 것으로 Default: "kudo-system" 이며, 특정한 값을 지정하면 KUDO Controller가 해당 네임스페이스로 설치된다. 지정한 사용자 정의 네임스페이스는 생성되는 것이 아니기 때문에 미리 생성되어 있어야 한다.
- -i, --kudo-image <image and/or version> : KUDO Controller image and/or Version을 지정한다.
- --version <version> : KUDO Image의 버전을 지정한다.
- --kudo-image-pull-policy <policy> : KUDO Controller Image pull 정책을 지정한다. (Default: "Always")
- --service-account <account> : 기본 서비스 계정을 지정한다. 기본적으로 "kudo-manager" 계정이 cluster-admin 권한으로 생성된다. 따라서 지정한 사용자 지정 계정도 이미 생성되어 있어야 하며, cluster-admin 권한을 가지고 있어야 한다.
- --unsafe-self-signed-webhook-ca : Webhook에 대한 테스트 목적의 자체 서명 번들을 사용하도록 지정한다. 기본적으로 KUDO는 cert-manager가 존재하는 것으로 진행하며 설치되면 여러 버전을 지원한다.
다른 작업 옵션
- --upgrade : 설치된 KUDO를 업그레이드 한다.
- --verify : 설치된 KUDO를 검증한다.
- --client-only : ~/.kudo 디렉터리와 Repository 설정을 초기화하며, Server 관련 어떤 리소스도 처리하지 않는다.
- -w --wait : KUDO Manager가 실행되고 요청을 받을 수 있는 상태일 때까지 대기한다.
- --wait-timeout int : --wait 옵션과 같이 사용하며 지정한 시간 (Default: 300초) 동안 대기한다.

get

설치된 사용자 Instances, Operators, OperatorVersions 객체를 조회한다.

kubectl kudo get [flags]

instances : 설치된 모든 사용자 Instance 정보
operators : 설치된 모든 사용자 Operators 정보
operatorversions : 설치된 모든 사용자 OperatorVersions 정보
all : 설치된 모든 사용자 KUDO 객체들 정도 (Instances + Operators + OperatorVersions)

--output yarml 옵션을 사용해서 출력을 저장할 수 있다.

search

Repository에서 지정한 검색어를 포함하는 항목을 검색한다. 기본적으로 설치된 Operator의 최신 버전만 나타나며 --all-versions를 지정하면 설치된 모든 버전이 나타난다.

kubectl kudo search <검색어> [options]

--repo <repo name> : 지정한 Repository를 기준으로 검색을 수행한다. 기본 값은 KUDO Context 상의 기본 Respository (community)를 사용한다.
-a, --all-versions : 지정한 검색어를 포함하는 모든 버전의 Operator들을 보여준다.

install

로컬 디렉터리, 공식 Repository 또는 클러스터 내의 리소스에서 KUDO Package를 설치한다.
Package name은 반드시 Repository 내의 Package 이름이거나 *.tgz 포맷의 Package를 나타내는 URL 또는 Path 이거나 --in-cluster 옵션을 통해 이미 설치된 Operator의 이름 또는 압축 해제된 패키지 디렉터리를 지정해야 한다.
로컬 경로의 Operator를 설치할 경우는 "./", "../", "/" 를 사용해야 한다. 그외는 모두 원격 Repository의 Operator name을 지정한 것으로 간주한다.

kubectl kudo install <operator name> [options]

--app-version <app version> : App 버전을 지정한다. (Default: Official Github repo기준 최신 값)
--operator-version <operator version> : Operator 버전을 지정한다. (Default: Official Github repo기준 최신 값)
--repo <repo name> : 사용할 Repository를 지정한다. (Default: Context)
--instance string : 설치할 Instance 이름을 지정한다. (Default: Operator name + "-instance", ex. first-operator => first-operator-instance)
--skip-instance : Instance를 제외하고 Operator와 OperatorVersion만 설치 (Default: false)
--create-namespace : Namespace를 생성한다. 만일 이미 존재하는 경우라면 실패처리 된다. (Default: false)
-p, --parameter <parameter-name=parameter-value> : 파라미터의 이름과 값을 "="를 이용해서 지정한다. ex. -p NODE_COUNT=3, ... 또한 배열이나 Map 형식의 경우는 YAML 포맷으로 지정이 가능하다. ex. 배열은 -p PORT="[80, 443]" 으로 Map은 -p CUSTOM_LABELS="{team: dev, owner: foo}"
-P, --parameter-file <parameter yaml format file path> : 파라미터를 지정한 YAML 포맷 파일 경로를 지정한다. 이 파일의 최상위 요소는 반드시 매핑 형식이어야 한다. 키는 파라미터 이름이고 값은 파라미터 값이다. 이 기능은 Instance의 파라미터 값을 버전 제어로 유지하려는 경우나 Command line에 지정하기 힘들게 긴 값이나 복잡한 값을 처리할 때 유용하다. 파라미터는 --paramter-file/-P 로 지정된 파일을 먼저 읽고 --parameter/-p 로 지정된 값을 읽어서 갱신하게 된다. 즉, 파라미터 파일에 정의된 파라미터 값을 지정한 파라미터 값으로 재 정의하는 경우에 유용하게 사용할 수 있다.
--wait : CLI가 설치가 완료될 때까지 대기해야 하는 경우 지정한다. (Default: false)
--wait-time <wait time seconds> : CLI가 최대 대기할 시간을 초 단위로 지정한다. (Default: 300초)
--in-cluster : 지정되면 이미 클러스터에 설치된 Operator version에서 검색한다. 이미 설치된 Operation version은 get 명령을 통해서 확인할 수 있다.

plan

Status

지정한 Instance에 대한 Plan 상태를 나타낸다.

kubectl kudo plan status --instance=<instance name> [options]

--output yaml : 결과를 YAML 포맷 파일로 출력
--wait : CLI가 모든 결과를 출력할 때까지 대기 (Default: false)

History

지정한 Instance에 대한 각 Plan의 History를 나타낸다.

kubectl kudo plan history --instance=<instance name> [options]

tigger

지정한 Instance에 대해 지정한 Plan을 실행한다.

kubectl kudo plan trigger <plan name> --instance=<instance name> [options]

--wait : CLI가 모든 결과를 출력할 때까지 대기 (Default: false)
--wait-time <wait time second> : Trigger된 Plan이 완료될 때까지 대기할 최대 시간을 초 단위로 지정 (Default: 300s)

uninstall

설치된 KUDO Package의 Instance를 제거한다. 물론 연관된 Deployments, Pods 와 같은 리소스들을 제거한다. 단, OperatorVersion이나 Operator CRD는 제거하지 않는다.

kubectl kudo uninstall --instance=<instance name> [options]

주의

이 명령은 Instance를 제거하는 것이기 때문에 데이터, 로그 파일 등의 손실이 발생하게 된다.

update

설치된 KUDO Operator Instance를 새로운 파라미터 값으로 갱신한다. 파라미터의 갱신은 파라미터 정의할 때 지정한 특정한 Plan을 실행시키게 된다.

kubectl kudo update --instance=<instance name> [options]

-p, --parameter <parameter-name=parameter-value> : 파라미터의 이름과 값을 "="를 이용해서 지정한다. ex. -p NODE_COUNT=3, ... 파라미터 옵션은 여러 번 중복 지정이 가능하다
-P, --parameter-file <parameter yaml format file path> : 파라미터를 지정한 YAML 포맷 파일 경로를 지정한다.
--wait : CLI가 모든 결과를 출력할 때까지 대기 (Default: false)
--wait-time <wait time second> : Trigger된 Plan이 완료될 때까지 대기할 최대 시간을 초 단위로 지정 (Default: 300s)

upgrade

현재 설치된 KUDO Operator Instance 버전을 새로운 버전으로 업그레이드 한다. 업그레이드하는 Operator의 이름은 Repository에 존재하는 패키지의 이름이거나 *.tgz 포맷의 경로 또는 URL 이거나 로컬의 압축 해제된 Opeartor 경로를 지정한다.

로컬 경로의 Operator를 설치할 경우는 "./", "../", "/" 를 사용해야 한다. 그외는 모두 원격 Repository의 Operator name을 지정한 것으로 간주한다.

새로운 Operator 버전에 따라서 특정한 파라미터를 지정해야 할 수도 있다.

kubectl kudo upgrade <opeator name | path | url> --instance=<instance name> [options]

--app-version <app version> : App 버전을 지정한다. (Default: Official Github repo기준 최신 값)
--operator-version <operator version> : Operator 버전을 지정한다. (Default: Official Github repo기준 최신 값)
--repo <repo name> : 사용할 Repository를 지정한다. (Default: Context)
-p, --parameter <parameter-name=parameter-value> : 파라미터의 이름과 값을 "="를 이용해서 지정한다. ex. -p NODE_COUNT=3, ... 파라미터 옵션은 여러 번 중복 지정이 가능하다
-P, --parameter-file <parameter yaml format file path> : 파라미터를 지정한 YAML 포맷 파일 경로를 지정한다.

diagnostics

진단 기능은 진단 데이터를 수집하고 분석하는 기능을 제공한다.

kubectl kudo diagnostics collect --instance=<instance name> [options]

--log-since <timeDuration> : 현재 시점을 기준으로 지정한 5s, 2m, 3h 등과 같이 지정한 구간까지의 로그들을 대상으로 한다. (Default: all logs)
-O, --output-directory <path> : 수집된 리소스들을 저장할 디렉터리 경로 지정 (Default: "diag")

Development Commands

Operator 개발자들에 유용한 명령들이다.

Package

KUDO Package와 상호 작용하는 여러 개의 서브 명령들로 구성된다.

Operator를 패키징하거나 검증하고 파라미터들을 나열하는데 사용한다. 파라미터들과 같이 작업할 때는 지정한 URL이나 이름과 버전등으로 원격 Repository의 파라미터 변수 목록을 제공할 수 있다.

add : Operator Package 파일들에 새로운 컨텐츠를 추가한다.
create : 로컬에 구성한 KUDO Operator를 tarball 형식의 패키지로 생성한다.
list : Operator Package로 부터 Parameters, Plans, Tasks 왁 같은 정보들을 출력한다.
new : 상호 작용을 통해서 새로운 Operator를 생성한다.
verify : Operator Package를 검증한다.

좀 더 자세한 사항은 해당 명령에 대한 --help 옵션을 지정해서 확인하면 된다.

Repository

KUDO Repositories와 상호 작용하는 여러 개의 서브 명령들로 구성된다.

It can be used to add, remove, list, and index kudo repositories.

add : Operator Repository를 추가한다.
context : KUDO Context에 관리되는 Repository들 중에 하나를 기본 값으로 설정한다.
index : 지정한 KUDO Operator Package들이 존재하는 디렉터리에 색인 파일 (Index.yaml)을 생성한다.
list : KUDO Context에서 관리되는 Repository 리스트를 출력한다.
remove : Remove an operator repository

좀 더 자세한 사항은 해당 명령에 대한 --help 옵션을 지정해서 확인하면 된다.

참고 자료

KUDO CLI Commands

[Container] Multi-Container Design Patterns 간략 정리

ccambo — Sun, 20 Dec 2020 22:29:01 +0900

Multi-Container Design Patterns 정리

지난 몇 년동안 컨테이너 기술은 코드를 패키징하고 배포하는 대중적인 기술로 발전했다. 여기서도 컨테이너를 통해 분산 응용 프로그램을 구축하는 방법의 변화에 대해 주목할 필요가 있다.

이번에는 마아크로 서비스 아키텍처에서 컨테이너늘 다루는데 사용할 수 있는 디자인 패턴 3가지에 대해서 정리해 본다.

Sidecar Pattern

하나의 컨테이너는 하나의 책임만 가지고 있어야 한다.

예를 들면 웹 서버와 로그 수집기가 같이 존재하는 컨테이너가 있다고 가정했을 때 다음과 같은 고민을 하게 된다.

웹 서버를 수정할 때 로그 수집기의 종속성을 고려해야 한다.
직접적인 관련은 없더라도 오류가 발생했을 때 어디서 문제가 발생했는지 빠르게 파악하지 못할 수도 있다.

위의 같이 상관이 없음에도 고려할 부분이 생길 수 있기 때문에 서로 다른 역할을 하는 서비스는 각각의 컨테이너로 분리해 주는 것이 좋으며, 이런 상황에서 활용할 수 있는 패턴이 Sidecar Pattern이다.

Pod 내의 메인 컨테이너 (위의 그림에서는 Web Server Container)를 확장하고 향상 및 개선하는 역할을 컨테이너를 Sidecar Container라고 하고, 이렇게 적용하는 패턴을 Sidecar Pattern 이라고 한다.

서로 다른 컨테이너이며 단지 Pod내에 묶여 있는 것이기 때문에 서로 간에 종속성이나 간섭의 문제가 생기지 않는다. 당연히 Web Server를 교체하더라도 로그 수집기 컨테이너는 변경이 없고 특정 기능을 활용하도록 재 사용성이 증가하는 효과를 가져오게 된다.

Ambassador Pattern

메인 컨테이너의 네트워크 연결을 전담하는 프록시 컨테이너를 두는 패턴이다.
Sidecar Pattern 이 이미 완성되고 동작하는 애플리케이션에 기능 추가를 위한 변경이 없이 보조 기능으로 추가해서 활용하는 측면을 강조한 것이라면 Ambassador Pattern은 개별 기능만을 중점적으로 처리하는 기능 모듈과 같은 패턴이다.

따라서 Sidecar Pattern 과는 달리 사용할 기능을 가진 모듈에 종속성이 존재하게 된다.

위의 그림에서와 같이 Pod 내에서 메인 어플리케이션 컨테이너는 자체 기능에 집중하고 네트워크와 관련된 부분은 Proxy Ambassador 컨테이너가 전담하는 방식이다.

Adapter Pattern

Adapter Pattern은 메인 애플리케이션의 기능을 표준화해서 다양한 기능들을 표준화에 맞춰서 연결하는 패턴을 의미한다.

위의 그림과 같이 동작하고 있는 애플리케이션에 대한 모니터링 정보를 수집하는 경우에 직접 구현하는 것이 아니라 표준화된 모니터링 데이터 I/O 를 정의해 놓고 실제 기능은 Adapter 에처 처리하는 방식으로 원하는 기능을 표준화해서 다양한 유형으로 연계하는 방식이다.

3가지 패턴의 차이점

3가지 패턴은 딱 구별하기 힘들다. 어떤 패턴을 쓰더라도 원하는 기능은 만족시킬 수가 있다. 따라서 패턴의 차이점은 목적이 무엇인지를 기준으로 차이점을 볼 수 있다.

Sidecar Pattern : 메인 컨테이너의 변경없이 기능을 확장 또는 향상 시키는 목적
Ambassador Pattern : 메인 컨테이너의 특정 기능을 전담하는 종속성을 특화 시키는 목적 (물론 다른 애플리케이션에도 사용할 수 있도록 독립적이어야 한다)
Adapter Pattern : 메인 컨테이너의 입/출력 표준화를 통한 다양한 연계 구성을 교체가능하도록 하는 목적 (ex. Databases, Files, ...)

참고 자료

[Golang] Golang으로 MongoDB 사용하기

ccambo — Sun, 20 Dec 2020 22:16:57 +0900

How to use MongoDB with Golang

이 문서에서는 아주 간단하게 Docker-compose를 이용해서 MongoDB를 구동하고 Golang을 통해서 연결하는 부분에 대해서 정리하고 있습니다.
환경은 맥북, VSCode, Golang, Docker 등이 이미 설치되어 있는 것을 기준으로 합니다.

간단한 MongoDB 정리

RDBMS와의 비교

RDBMS	MongoDB
Database	Database
Table	Collection
Tuple/Row	Document
Column	Key/Field
Table Join	Embedded Documents
Primary Key	Primary Key (_id)

특징과 장/단점

주요 특징들은 다음과 같다.

Document-Oriented Storage : Database > Collections > Documents 구조로 Document는 key-value 형태의 BSON (Binary JSON)으로 되어 있다.
Full Index Support : 다양한 인덱싱을 제공한다.
- Single Field Indexes : 기본적인 인덱스 타입
- Compound Indexes : RDBMS의 복합 인덱스 타입
- Multikey Indexes : Array에 매칭되는 값이 하나라도 있으면 인덱스에 추가하는 인덱스 타입
- Geospatial Indexes and Queries : 위치기반 인덱스와 쿼리 지원
- Text Indexes : String에 대한 인덱스 지원
- Hashed Indexes : Btree 인덱스가 아닌 Hash 타입의 인덱스도 지원
Replication & High Availablity : 간단한 설정을 통해서 데이터 복제를 지원하므로 가용성이 향상된다.
Auto-Sharding : 자동으로 데이터를 분산해서 저장하며, 하나의 컬랙션처럼 사용할 수 있도록 수평적 확장 기능을 제공한다.
Querying (Document based query) : 필터링, 수집, 정렬, 정규표현식 등의 다양한 쿼리문 지원
Fast In-Place Updates : 고성능 atomic operation 지원
Map/Reduce : 맵리듀스 지원 (map과 reduce 함수의 조합을 통해서 분산/병렬 시스템 운용 지원, 하둡처럼 MR전용 시스템에 비해서는 성능이 떨어진다)
GridFS : 분산 파일 저장을 지원하기 때문에 실제 파일이 어디 저장되는지를 알 필요가 없으며 복구도 자동으로 지원된다.
Commerical Support : 10gen에서 관리

장점

데이터를 쌓아놓고 삭제가 필요없는 경우가 가장 적합하다. (ex. 로그 데이터 등)

Flexibility : Schema-less (or Schema-Free) 라서 어떤 형태의 데이터라도 저장이 가능하다.
Performance : Read & Write 성능이 뛰어나다.캐싱이나 많은 트래픽을 감당할때 사용해도 좋다.
Scalability : 기본적으로 Scale-out 구조를 채택해서 쉽게 운용이 가능하다. Auto-Sharding 지원
Deep Query Ability : 문서 지향적 Query Language를 사용해서 SQL만큼 강력한 Query성능을 제공한다.
Conversion / Mapping : JSON 형태로 저장 (실제는 BSON) 되기 때문에 직관적이고 개발이 편리하다.

단점

정합성이 요구되어 트랜잭션 관리가 필요한 경우는 부적합하다. (ex. 금융, 회계, 회원정보 등)

Join이 없다 : JOIN이 필요없도록 데이터의 구조를 잡아야 한다.
File 기반이다 : Memroy mapped file 기반의 파일 엔진 DB이며 메모리 관리를 OS에 의존한다. 따라서 메모리 의존성이 있으며 메모리 크기가 성능을 좌우한다.
SQL을 완전히 이관할 수 없다 : SQL을 그대로 이전할 수 없으며 맞도록 변환해야 한다.
BTree 성능 이슈가 있다 : 인덱스를 BTree 기반으로 하고 있으므로 크기가 커질수록 새로운 데이터를 입력하거나 삭제할 때 성능이 저하된다. 따라서 데이터를 넣어두고 조회만 하는데 적합하다.

메모리 관련 이슈

데이터를 저장할 때 논리적으로 메모리에 먼저 저장하고 일정 주기에 따라서 메모리 블럭들을 디스크로 출력하는데 이 부분을 OS의 의존하고 있다. 실제 메모리가 작아도 OS의 가상메모리 운영 방식에 따라서 운영된다.

이런 운영 구조 때문에 메모리에서 데이터 블럭을 참조할 때 없다면 "Page Fault" 오류가 발생하고, 이 상황에서 디스크에서 해당 블록을 찾아서 메모리에 로드하여 처리하게 된다. 이 과정에서 모자라는 메모리 때문에 다른 블럭을 디스크에 쓰고 제거한 후 필요한 블럭을 메모리로 올리는 작업이 처리되기 때문에 디스크 I/O가 발생하므로 성능 저하가 발생할 수 밖에는 없다.

따라서 메모리 크기가 성능을 좌우한다는 것은 Page Fault 오류의 발생 반도에 근거하고 있다고 보면 된다. 따라서 데이터 설계를 할 때 자주 사용되는 데이터가 메모리에 상주할 수 있도록 key 설계를 하는 것이 매우 중요하다. 또한 테이블을 풀 스캔하는 작업은 무조건 Page Fault를 발생시키게 되므로 이런 경우는 Index Table (Summary Table) 등을 만들어서 운영하는 것이 성능을 위한 방법이라고 할 수 있다.

주요 용어

Document

RDBMS의 Tuple / Row와 대응되는 개념으로 Key-Value 쌍으로 구성되며, Value에는 또 다른 document가 설정될 수도 있다. 동적 스키마를 가지고 있기 때문에 같은 Collection (Table) 안에 있는 Document끼리도 다른 스키마를 가질 수 있다. (Free Schema)

{ 
  "_id": ObjectId("5099803df3f4948bd2f98391"), 
  "username": "Morris", 
  "language": { 
    Nuxt: 3,
    Go: 3,
  } 
}

Primary Key

RDBMS의 Primary Key와 대응되는 개념으로 ObjectId는 12bytes의 16진수 값으로 각 Document의 유일성을 보장하는 역할을 담당한다.

4bytes : Timestamp Data
3bytes : Machine id Data
2bytes : MongoDB 서버의 Process id Data
3bytes : Sequenctial number Data

개념적으로는 RDBMS의 auto increment와 비슷한 개념으로 생각하면 될 듯 하다.

MongoDB에서 Collection에 저장된 각 Document들은 반드시 기본 키 역할을 담당하는 "_id" 라는 필드를 가져야 한다.

Collection

RDBMS의 Table에 대응되는 개념으로 Document의 그룹이며, Document들이 Collection 내부에 위치한다.

Database

RDBMS의 Database에 대응되는 개념으로 Collection들의 물리적인 컨테이너다. 따라서 각 Database는 물리적인 파일 시스템에 여러 개의 파일로 저장된다.

MongoDB 실행하기 (docker-compose)

MongoDB 자체를 실행하는 것은 그렇게 어렵지 않다. 아래와 같이 아주 단순한 docker-compose.yml을 구성하면 바로 구동된다.

version: "3.3"
services:
  mongodb:
    image: mongo:latest     # 사용할 Docker Image
    container_name: mongdb  # Docker Container 식별 명
    restart: always
    environment:
      MONGO_INITDB_DATABASE: "사용할 데이터베이스 명 설정"    # 정보만 존재하고 실제 데이터가 처리될 때 생성됨.
      MONGO_INITDB_ROOT_USERNAME: "root 사용자 설정"          # 최초 실행되서 DB 구성할 때 사용자 생성됨.
      MONGO_INITDB_ROOT_PASSWORD: "root 사용바 비밀번호 설정" # 최초 실행되서 DB 구성할 때 사용자 생성됨.
    volumes:
      - ./data/mongodb/:/data/db  # 로컬 경로를 컨테이너의 볼륨으로 연계
    ports:
      - "27017:27017"

위와 같이 구성하고 docker-compose.yml 파일이 존재하는 경로에서 아래의 명령으로 실행하면 된다.

$ docker-compose up

# Background로 실행하는 방법
$ docker-compose up -d

# 로그 확인하는 방법
$ docker-compose logs

로그를 확인해 보면 중간에 root 계정을 생성하는 것을 확인할 수 있으며, 인증 모드로 동작하고 있는 것을 확인할 수 있다.

...
mongdb     | 2020-01-07T10:58:38.416+0000 I  INDEX    [conn2] index build: done building index user_1_db_1 on ns admin.system.users
mongdb     | Successfully added user: {
mongdb     |    "user" : "root",
mongdb     |    "roles" : [
mongdb     |            {
mongdb     |                    "role" : "root",
mongdb     |                    "db" : "admin"
mongdb     |            }
mongdb     |    ]
mongdb     | }
...
mongdb     | 2020-01-07T10:58:48.466+0000 I  CONTROL  [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=7531e03b8054
mongdb     | 2020-01-07T10:58:48.466+0000 I  CONTROL  [initandlisten] db version v4.2.2
mongdb     | 2020-01-07T10:58:48.466+0000 I  CONTROL  [initandlisten] git version: a0bbbff6ada159e19298d37946ac8dc4b497eadf
mongdb     | 2020-01-07T10:58:48.466+0000 I  CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.1  11 Sep 2018
mongdb     | 2020-01-07T10:58:48.467+0000 I  CONTROL  [initandlisten] allocator: tcmalloc
mongdb     | 2020-01-07T10:58:48.467+0000 I  CONTROL  [initandlisten] modules: none
mongdb     | 2020-01-07T10:58:48.467+0000 I  CONTROL  [initandlisten] build environment:
mongdb     | 2020-01-07T10:58:48.468+0000 I  CONTROL  [initandlisten]     distmod: ubuntu1804
mongdb     | 2020-01-07T10:58:48.468+0000 I  CONTROL  [initandlisten]     distarch: x86_64
mongdb     | 2020-01-07T10:58:48.468+0000 I  CONTROL  [initandlisten]     target_arch: x86_64
mongdb     | 2020-01-07T10:58:48.468+0000 I  CONTROL  [initandlisten] options: { net: { bindIp: "*" }, security: { authorization: "enabled" } }

좀 더 많은 구성 옵션들과 실행과 관련된 스크립트들 (예를 들어 일반 사용자 추가 등)을 더 설정할 수 있지만, 여기서는 이 정도만 구성해도 충분하다.

Golang으로 연결하기

처음 Golang으로 연결하면서 여러 가지 정보들을 확인해 봤지만 Golang 버전에 따라서 Mongo Driver 들에 따라서 다양한 글들과 방법들이 나오지만 이런저런 오류들이 발생하면서 오히려 헷갈리는 상황들이 존재한다.

이 문서에는 Golang 버전의 MongoDB Official 격이라고 판단되는 mongo-go-driver를 기준으로 한다.

import 구성

아래의 코드는 mongodb driver의 go 라이브러리를 import 하는 것이다. 두 가지 방법 중에 무엇을 사용해도 상관없지만 코드 구성 후에 자동 import 처리되는 것을 확인해 보니 go.mongodb.org로 사용되기 때문에 이를 기준으로 했다.

...
import (
  ...
  // 다른 소스들은 아래와 같이 처리하는 것도 많다.
  "github.com/mongodb/mongo-go-driver/bson"
  "github.com/mongodb/mongo-go-driver/bson/primitive"
  "github.com/mongodb/mongo-go-driver/mongo"
  "github.com/mongodb/mongo-go-driver/mongo/options"
  ...
  // 실제 코드는 CDN 격인 go.mongodb.org를 사용해서 처리했다.
  "go.mongodb.org/mongo-driver/bson"
  "go.mongodb.org/mongo-driver/bson/primitive"
  "go.mongodb.org/mongo-driver/mongo"
  "go.mongodb.org/mongo-driver/mongo/options"
)
...

클라이언트 연결과 검증 코드

구동 중인 mongodb가 authentication mode로 동작하고 있고, root 사용자만 만들어 놓은 상태기 때문에 이를 아래의 코드를 통해서 연결과 검증을 하면 된다.

...
// timeout 기반의 Context 생성
ctx, _ := context.WithTimeout(context.Background(), conf.Timeout)

// Authetication 처리를 위한 Client Option 구성 (docker-compose.yml에 구성한 port 기준)
clientOptions := options.Client().ApplyURI("mongodb://localhost:27017)
  .SetAuth(options.Credential{
    AuthSource: "",   // 지금은 필요없음
    Username: "docker-compose.yml에 지정한 사용자",
    Password: "docker-compose.yml에 지정한 사용자 비밀번호",
  })

// mongodb 연결
client, err := mongo.Connect(ctx, clientOptions)
if err != nil {
  return nil, err
}

// 연결 검증
err = client.Ping(context.Background(), nil)
if err != nil {
  return nil, err
}
...

클라이언트 옵션에 더 많은 구성들이 있지만 이 부분들은 mongodb 매뉴얼등을 검토해 보면서 적용하면 된다.

발생했던 문제점들

ApplyURI에 "mongodb://ID:PW@localhost:27017" 방식으로 구성할 때 오류

un-escaped character @ in user info 오류

위의 같은 오류 메시지는 ID나 PW에 @ 문자가 존재하는 경우에 직접 전달되면 발생하게 된다. 이를 해결하기 위해서는 "net/url" 패키지를 import 하고 아래와 같이 escape 처리를 해 줘야 한다.

option="linenos=inline,hl_lines=4 10" %}}
...
import (
  ...
  "net/url"
  ...
)
...
// getConnectionURI - Returns the connection URI from the configuration
func getConnectionURI(conf *Config) string {
    return "mongodb://" + url.QueryEscape(conf.UserName) + ":" + url.QueryEscape(conf.Password) + "@" + conf.Host + ":" + conf.Port + "/" + conf.DatabaseName
}
...

url.QueryEscape 함수를 이용해서 데이터에 존재하는 특수문자를 안전하게 인식될 수 있도록 변환해 주면 된다.

데이터 처리할 때 "(Unauthorized) command insert requires authentication" 오류

위에 언급했던 Authentication Mode로 구동되고 있는 mongodb에 인증을 처리하지 않고 Connection을 연결한 후 실제 데이터를 처리할 때 인증되지 않은 사용자로 인해서 발생하는 오류다. 이 경우는 위의 코드에서 보여진 것과 같이 인증을 한 Connection을 사용하면 오류가 해결된다.

Authentication 처리를 구성한 Client Option 사용한 연결 처리가 필요하다.

연결할 때 Authentication mechanism SCRAM-SHA-1 오류

이 오류는 mongodb의 인증 방식에 대한 문제로 위에서 보여준 연결 문자열을 사용해서 처리할 떄 발생하는 오류로 인증 방식이 맞지 않아서 발생하게 된다. 이 부분에 대해서는 MongoDB Manual - Authentication Mechanisms를 참고하면 된다.

제공되는 Authentication Mechanism은 다음과 같다.

SCRAM
X.509 Certificate Authentication
LDAP Proxy Authentication (Enterprise)
Kerberos Authentication (Enterprise)

표준 URI Connection Schema는 아래와 같다.

mongodb://[username:password@]host1[:port1][...hostN[:portN]][/[database][?options]]

위에서 보이는 것과 같이 여러 개의 host 연결 지정이 가능하고, 사용할 데이터베이스와 연결에 사용할 옵션들 지정이 가능하다.

옵션을 통해서 Authentication Mechanism을 지정할 수 있다. 자세한 내용은 Connection Options을 참고한다.

Connection String을 기준으로 각종 옵션을 적용해서 처리하는 것도 방법이지만 여러 가지 설정을 Configuration으로 처리하고 운영하기에는 Authenticated Client 를 사용하는 방식이 더 효율적인 것으로 판단된다.

참고 문서

[Yarn] Yarn 과 Npm 비교

ccambo — Sun, 20 Dec 2020 22:00:31 +0900

Yarn vs NPM 비교

node + npm이 기본이었는데, 몇 가지 npm의 문제점을 해결하기 위해 yarn이 발표되었다.

기존 NPM은 배포가 쉽고, 종속성을 쉽게 해결할 수 있지만 패키지가 중복으로 설치될 수 있고, 파일이 많은 경우에 문제가 될 수 있다. 페이스북에서는 이런 문제점들을 해결하기 위해서 yarn을 발표했다.

npm3 보다 패키지 설치 속도가 빠르다.
json 포맷을 사용하지 않는다.
offline 모드가 가능하다.

YARN 설치

설치페이지를 통해서 직접 설치가 가능하다.
맥북이라면 brew를 이용해서 설치가 가능하다.
npm을 통해서도 설치가 가능하다.

터미널에서의 설치는 다음의 명령으로 처리하면 된다.

$ npm install -g yarn   # npm 사용
$ brew install yarn     # 맥북

명령 비교

npm 명령	yarn 명령	설명
npm init	yarn init	프로젝트 초기화
npm install	yarn or yarn install	package.json 의 패키지 설치
npm install --save [package name]	yarn add [package name ]	패키지를 프로젝트 의존성 수준으로 추가 (dependencies)
npm install --save-dev [package name]	yarn add -D[or --dev] [package name]	패키지를 프로젝트 개발 의존성 수준으로 추가 (Devdependencies)
npm install --global [package name]	yarn global add [package name]	패키지를 전역 수준으로 추가
npm update --save	yarn upgrade	프로젝트의 패키지 업데이트
npm run [script name]	yarn [script name]	package.json의 scripts에 지정된 명령 실행
npm uninstall --save [package name]	yarn remove [package name]	패키지 삭제
npm cache clean	yarn cache clean	캐시 삭제

참고자료

yarn 특징과 성능

[Opencensus - Trace] Opencensus를 이용한 gRPC Global Tracing

ccambo — Sun, 20 Dec 2020 01:07:45 +0900

Opencensus를 이용한 gRPC Global Tracing

Overview

Opencensus를 사용해서 시스템의 추적 및 매트릭을 수집하고 선택한 백엔드로 내보내 분산 시스템에 대한 관찰성을 제공할 수 있다.

간단하게 gRPC 상에서 추적을 검증하기 위한 용도이므로 단순히 바이트를 포함하는 페이로드를 받아서 대문자 처리를 하는 서비스를 대상으로 검토해 보도록 한다.

Requirements

go : Download and install - The Go Programming Language 를 통해 설치
gRPC
```
$ go get -u google.golang.org/grpc
```

Protocol Buffer v3 : Quick start – gRPC 문서의 내용에 따라서 Releases · protocolbuffers/protobuf · GitHub 에서 바이너리를 받을 수 있다.

# linux apt or apt-get
$ apt install -y protobuf-compiler
$ protoc --verion # 버전 3+ 확인

# Mac Homebrew
$ brew install protobuf
$ protoc --version # 버전 3+ 확인

Go 용 protoc 플러그인

$ go get -u github.com/golang/protobuf/protoc-gen-go

Creating our gRPC Service

추적을 활성화하기 위해서는 다음과 같은 패키지가 필요하다.

Opencensus gRPC 지원 : go.opencensus.io/plugin/ocgrpc
Opencensus Trace 지원 : go.opencensus.io/trace

매트릭을 활성화하기 위해서는 다음과 같은 패키지가 필요하다.

서버 핸들러 : go.opencensus.io/plugin/ocgrpc.SserverHandler
클라이언트 핸들러 : go.opencensus.io/plugin/ocgrpc.ClientHandler
서버 gRPC 측정 항목 보기 : https://godoc.org/go.opencensus.io/plugin/ocgrpc#DefaultServerViews
클라이언트 gRPC 측정 항목 보기 : https://godoc.org/go.opencensus.io/plugin/ocgrpc#DefaultClientViews

Protobuf 정의

rpc 폴더를 생성하고 defs.proto 파일에 아래와 같이 정의를 구성한다.

syntax = "proto3";

package rpc;

message Payload {
    int32 id = 1;
    bytes data = 2;
}

service Fetch {
    rpc Capitalize(Payload) returns (Payload) {}
}

gRPC 서비스 생성

정의한 파일을 protoc로 컴파일 한다.

# protoc 
$ protoc -I rpc rpc/defs.proto --go_out=plugins=grpc:rpc

정상적으로 수행되면 defs.pb.go 파일이 생성된다.

서버 구현

server.go 파일을 생성하고 아래와 같이 구성한다.

package main

import (
    "bytes"
    "context"
    "log"
    "net"
    "google.golang.org/grpc"
    "oc.tutorials/ocgrpc/rpc"
)

type fetchIt int

// Compile time assertion that fetchIt implements FetchServer.
var _ rpc.FetchServer = (*fetchIt)(nil)

func (fi *fetchIt) Capitalize(ctx context.Context, in *rpc.Payload) (*rpc.Payload, error) {
    out :=  &rpc.Payload{
        Data: bytes.ToUpper(in.Data),
    }

    return out, nil
}

func main() {
    addr := ":9988"
    ln, err := net.Listen("tcp", addr)
    if nil != err {
        log.Fatalf("gRPC server: failed to listen: %v", err)
    }

    srv := grpc.NewServer()
    rpc.RegisterFetchServer(srv, new(fetchIt))

    log.Printf("fetchIt gRPC server serving at %q", addr)
    if err := srv.Serve(ln); nil != err {
        log.Fatalf("gRPC server: error serving: %v", err)
    }
}

이제 실행해서 클라이언트 호출에 대기한다.

$ go run server.go

클라이언트 구현

클라이언트는 gRPC 채널을 통해서 서버와 통신하며 바이트 단위로 전송하고 대문자 처리된 결과를 받게 된다.

client.go 파일을 생성하고 아래와 같이 구성한다.

package main

import (
    "bufio"
    "context"
    "fmt"
    "log"
    "os"

    "google.golang.org/grpc"
    "oc.tutorials/ocgrpc/rpc"
)

func main() {
    serverAddr := ":9988"
    cc, err := grpc.Dial(serverAddr, grpc.WithInsecure())
    if nil != err {
        log.Fatalf("fetchIt gRPC client failed to dial to server: %v", err)
    }

    fc := rpc.NewFetchClient(cc)

    fIn := bufio.NewReader(os.Stdin)
    for {
        fmt.Print("> ")
        line, _, err := fIn.ReadLine()
        if nil != err {
            log.Printf("Failed to read a line in: %v", err)
            return
        }

        ctx := context.Background()
        out, err := fc.Capitialize(ctx, &rpc.Payload{Data: line})
        if nil != err {
            log.Printf("fetchIt gRPC client got error from server: %v", err)
            continue
        }
        fmt.Printf("< %s\n\n", out.Data)
    }
}

이제 실행해서 입력한 결과를 확인할 수 있다.

$ go run client.go
> foo
< FOO

> bar
< BAR

Instrumentation

위의 예제에 추적과 매트릭에 대한 계측을 추가한다.

서버 계측

추적

추적을 측정하기 위해서는 grpc.StatsHandler에 ServerHandler를 등록해서 gRPC 측정항목을 추출하고 추적할 수 있도록 추가해 줘야 한다.

import (
  ...
  "go.opencensus.io/trace"
)

func (fi *fetchIt) Capitalize(ctx context.Context, in *rpc.Payload) (*rpc.Payload, error) {
  ctx, span := trace.StartSpan(ctx, "oc.tutorials.grpc.Capitalize")
  defer span.End()

  ...
}

func main() {
  ...
  srv := grpc.NewServer(grpc.StatsHandler(&ocgrpc.ServerHandler{}))
  ...
}

매트릭

매트릭을 측정하기 위해서는 필요한 View 정보를 추가해 줘야 한다.

import (
  ...
  "go.opencensus.io/plugin/ocgrpc"
  "go.opencensus.io/stats/view"
)

func main() {
  ...
  if err := view.Register(ocgrpc.DefaultServerViews...); nil != err {
    log.Fatalf("Failed to register ocgrpc server views: %v", err)
  }

  srv := grpc.NewServer(grpc.StatsHandler(&ocgrpc.ServerHandler{}))
  ...
}

완성된 최종 서버 코드

추출 및 수집된 데이터를 확인하기 위해서 stackdriver를 Exporter로 등록하는 정보를 추가해 줘야 한다. (Exporter는 다양하므로 선호하는 것을 활용해도 된다)

package main

import (
  "bytes"
  "context"
  "log"
  "net"

  "go.opencensus.io/plugin/ocgrpc"
  "go.opencensus.io/stats/view"
  "go.opencensus.io/trace"
  "google.golang.org/grpc"

  "oc.tutorials/ocgrpc/rpc"

  // The exporter to extract our metrics and traces
  "contrib.go.opencensus.io/exporter/stackdriver"
)

type fetchIt int

// Compile time assertion that fetchIt implements FetchServer.
var _ rpc.FetchServer = (*fetchIt)(nil)

func (fi *fetchIt) Capitalize(ctx context.Context, in *rpc.Payload) (*rpc.Payload, error) {
  ctx, span := trace.StartSpan(ctx, "oc.tutorials.grpc.Capitalize")
  defer span.End()

  out := &rpc.Payload{
    Data: bytes.ToUpper(in.Data),
  }
  return out, nil
}

func main() {
  if err := view.Register(ocgrpc.DefaultServerViews...); nil != err {
    log.Fatalf("Failed to register ocgrpc server views: %v", err)
  }

  // Create and register the exporter
  sd, err := stackdriver.NewExporter(stackdriver.Options{
    ProjectID:    "census-demos", // Insert your projectID here
    MetricPrefix: "ocgrpctutorial",
  })
  if nil != err {
    log.Fatalf("Failed to create Stackdriver exporter: %v", err)
  }
  defer sd.Flush()
  trace.RegisterExporter(sd)
  sd.StartMetricsExporter()
  defer sd.StopMetricsExporter()
  // For demo purposes let's always sample
  trace.ApplyConfig(trace.Config{DefaultSampler: trace.AlwaysSample()})

  addr := ":9988"
  ln, err := net.Listen("tcp", addr)
  if nil != err {
    log.Fatalf("gRPC server: failed to listen: %v", err)
  }
  srv := grpc.NewServer(grpc.StatsHandler(&ocgrpc.ServerHandler{}))
  rpc.RegisterFetchServer(srv, new(fetchIt))
  log.Printf("fetchIt gRPC server serving at %q", addr)
  if err := srv.Serve(ln); nil != err {
    log.Fatalf("gRPC server: error serving: %v", err)
  }
}

클라이언트 계측

추적

추적을 측정하기 위해서는 grpc.StatsHandler에 ClientHandler를 등록해서 gRPC 측정항목을 추출하고 추적할 수 있도록 추가해 줘야 한다.

import (
  ...
  "go.opencensus.io/trace"
)

func main() {
  ...
  cc, err := grpc.Dial(serverAddr, grpc.WithInsecure(), grpc.WithStatsHandler(new(ocgrpc.ClientHander)))
  ...
  ctx, span := trace.StartSpan(context.Background(), "oc.tutorials.grpc.ClientCapitalize")
  out, err := fc.Capitalize(ctx, &rpc.Payload{Data: line})
  if nil != err {
    span.SetStatus(trace.Status{Code: trace.StatusCodeInternal, Message: err.Error()})
    log.Printf("fetchIt gRPC client got error from server: %v", err)
  } else {
    fmt.Printf("< %v\n\n", out.Data)
  }
  span.End()
  ...
}

매트릭

매트릭을 측정하기 위해서는 필요한 View 정보를 추가해 줘야 한다.

import (
  ...
  "go.opencensus.io/plugin/ocgrpc"
  "go.opencensus.io/stats/view"
  "go.opencensus.io/trace"
)

func main() {
  ...
  if err := view.Register(ocgrpc.DefaultClientViews...); nil != err {
    log.Fatalf("Failed to register ocgrpc client views: %v", err)
  }
  cc, err := grpc.Dial(serverAddr, grpc.WithInsecure(), grpc.WithStatsHandler(new(ocgrpc.ClientHander)))
}

완성된 클라이언트 코드

package main

import (
  "bufio"
  "context"
  "fmt"
  "log"
  "os"

  "go.opencensus.io/plugin/ocgrpc"
  "go.opencensus.io/stats/view"
  "go.opencensus.io/trace"
  "google.golang.org/grpc"

  "oc.tutorials/ocgrpc/rpc"

  // The exporter to extract our metrics and traces
  "contrib.go.opencensus.io/exporter/stackdriver"
)

func main() {
  if err := view.Register(ocgrpc.DefaultClientViews...); nil != err {
    log.Fatalf("Failed to register ocgrpc client views: %v", err)
  }

  // Create and register the exporter
  sd, err := stackdriver.NewExporter(stackdriver.Options{
    ProjectID:    "census-demos", // Insert your projectID here
    MetricPrefix: "ocgrpctutorial",
  })
  if nil != err {
    log.Fatalf("Failed to create Stackdriver exporter: %v", err)
  }
  defer sd.Flush()
  trace.RegisterExporter(sd)
  sd.StartMetricsExporter()
  defer sd.StopMetricsExporter()
  // For demo purposes let's always sample
  trace.ApplyConfig(trace.Config{DefaultSampler: trace.AlwaysSample()})

  serverAddr := ":9988"
  cc, err := grpc.Dial(serverAddr, grpc.WithInsecure(), grpc.WithStatsHandler(new(ocgrpc.ClientHandler)))
  if nil != err {
    log.Fatalf("fetchIt gRPC client failed to dial to server: %v", err)
  }
  fc := rpc.NewFetchClient(cc)

  fIn := bufio.NewReader(os.Stdin)
  for {
    fmt.Print("> ")
    line, _, err := fIn.ReadLine()
    if nil != err {
      log.Printf("Failed to read a line in: %v", err)
      return
    }

    ctx, span := trace.StartSpan(context.Background(), "oc.tutorials.grpc.ClientCapitalize")
    out, err := fc.Capitalize(ctx, &rpc.Payload{Data: line})
    if nil != err {
      span.SetStatus(trace.Status{Code: trace.StatusCodeInternal, Message: err.Error()})
      log.Printf("fetchIt gRPC client got error from server: %v", err)
    } else {
      fmt.Printf("< %s\n\n", out.Data)
    }
    span.End()
  }
}

Example Traces

GCP와 연계를 했고 stackdriver를 선택해서 추적 정보를 Export 했다면 Goolgle Cloud Platform Trace 정보 를 통해서 처리된 작업을 확인할 수 있다.

Example Metrics

GCP와 연계를 했고 stackdriver를 선택해서 매트릭 정보를 Export 했다면 Google Cloud Platform Metrics 정보 를 통해서 처리된 작업을 확인할 수 있다.

참고 자료

OpenCensus

[Opencensus - Trace] Opencesus를 활용한 Trace 정리

ccambo — Sat, 19 Dec 2020 21:12:15 +0900

Trace 정리

Tracing (이하 트레이싱)

추적은 응용 프로그램을 구성하는 다른 서비스에 의해 처리되는 단일 사용자 요청의 진행과정을 추적하는 것이다.

진행 과정의 각 작업은 Span 으로 부르며, 각 스팬에는 단계에 소요된 시간 (대기 시간), 상태, 시간 이벤트, 속성, 링크를 포함하여 작업을 나타낼 수 있는 메타 데이터가 포함된다. 이 추적 정보를 활용해서 애플리케이션의 오류 및 대기 시간 문제를 디버깅 할 수 있다.

Trace (이하 추적)

추적은 스팬 트리로 구성된다. 즉, 작업의 흐름 경로를 보여주는 관찰 가능한 신호의 집합이다. 추적 자체는 고유한 16바이트 시퀀스로 표현되는 TraceID로 식별된다. 트레이싱을 통해서 수집된 추적 정보는 다음과 같이 표현된다.

위의 그림에서와 같이 여러 단계의 작업(스팬)이 호출된 것을 확인할 수 있다.

auth: 사용자 인증 여부 검사
cache.Get: 캐시 검증
mysql.Query: 캐시에 존재하지 않아 DB 조회
cache.Put: DB 조회결과 캐시 처리

Exporting (이하 내보내기)

수집된 추적 정보를 다양한 분석을 위해서 여러 가지 백엔드들에 대한 내보내기를 구성해서 처리할 수 있다.
다양한 내보내기 목록등은 Opencensus 를 참고하면 된다.

Span (이하 스팬)

스팬은 추적의 단일 작업을 나타낸다. 주로 HTTP 요청, RPC (원격 프로시저 호출: Remote Procedure Call), 데이터베이스 쿼리 또는 코드가 사용자 코드에서 사용하는 경로 등을 나타낸다.

스팬은 트리 구조를 이루기 때문에 상위 스팬의 존재여부에 따라서 상위 스팬과 하위 스팬으로 나뉜다.
각 스팬은 SpanID로 식별된다.
SpanID 와 옵션 바이트들을 합쳐서 Span Context라고 한다.
동일 프로세스 내에서 스팬 컨텍스트는 컨텍스트 객체로 전달된다. 프로세스 경계를 넘어서면 프로토콜 헤더로 직렬화 된다. 따라서 수신 측은 스팬 컨텍스트를 읽고 하위 스팬을 만들 수 있다.

스팬은 다음과 같은 필드 정보로 구성된다.

Name
- 작업을 설명할 수 있는 문자열, 일반적으로 통계적으로 의미가 있을 수 있는 이름을 사용하는 것이 좋다. 백엔드 및 분석 도구가 이 이름을 기준으로 보고서를 생성한다.
- 스팬 생성자에서 지정한다.
```
cox, span := trace.StartSpan(ctx, "cache.Get")
```
SpanID
- 스팬 식별자
- 무작위로 생성된 8바이트 구성이며 전역적으로 고유한 값이어야 한다.
- 하위 스팬이 존재할 경우 ParentSpanID로 지정된다. ParentSpanID 가 null인 경우는 최상위 스팬으로 판단한다.
TraceID
- 추적 식별자
- 무작위로 생성된 16바이트 구성이며 전역적으로 고유한 값이어야 한다.
- 모든 프로세스에서 동일한 추적에 속하는 모든 스팬들을 그룹화하는 기준이다.
ParentSpanID
- 현재 작업 단위 스팬의 상위 스팬 여부를 의미한다.
- null이거나 SpanID 값이 존재할 수 있다.
- 동일한 ParentSpanID를 가지는 하위 스팬들이 존재할 수 있지만, 하나의 스팬은 하나의 ParentSpanID만 가질 수 있다.
StartTime / EndTime
- StartTime은 작업이 시작된 시간을 기록하는 타임스탬프 값이다.
- EndTime은 작업이 종료된 시간을 기록하는 타임스탬프 값이다.
- 처리(지연) 시간은 EndTime과 StartTime 의 차이를 의미한다.
- 스팬의 수명은 스팬 객체에 시작 시간과 종료 시간을 기록하는 프로세스를 나타낸다.
  - 시작 시간은 스팬이 생성될 떄 기록되며, 시작 시간이 기록된 경우만 살아있다.
  - 종료 시간은 작업의 종료 시간으로 기록하며, 추적이 종료된 후에 스팬을 종료하는 것이 중요하다.

Status

특정 시점에 스팬의 필터링 가능한 상태를 나타내는 논리적 모델을 정의한다.
int32 코드로 구성된다.
상태 코드 매핑된 정보는 다음과 같다.

STATE	CODE	DESCRIPTION	HTTP STATUS CODE EQUIVALENT
OK	0	Not an error, returned on success	200 and 2XX HTTP statuses
CANCELLED	1	The operation was cancelled, typically by the caller	499
UNKNOWN	2	An unknown error raised by APIs that don’t return enough error information	500
INVALID_ARGUMENT	3	The client specified an invalid argument	400
DEADLINE_EXCEEDED	4	The deadline expired before the operation could succeed	504
NOT_FOUND	5	Content was not found or request was denied for an entire class of users	404
ALREADY_EXISTS	6	The entity attempted to be created already exists	409
PERMISSION_DENIED	7	The caller doesn’t have permission to execute the specified operation	403
RESOURCE_EXHAUSTED	8	The resource has been exhausted e.g. per-user quota exhausted, file system out of space	429
FAILED_PRECONDITION	9	The client shouldn’t retry until the system state has been explicitly handled	400
ABORTED	10	The operation was aborted	409
OUT_OF_RANGE	11	The operation was attempted past the valid range e.g. seeking past the end of a file	400
UNIMPLEMENTED	12	The operation is not implemented or is not supported/enabled for this operation	501
INTERNAL	13	Some invariants expected by the underlying system have been broken. This code is reserved for serious errors	500
UNAVAILABLE	14	The service is currently available e.g. as a transient condition	503
DATA_LOSS	15	Unrecoverable data loss or corruption	500
UNAUTHENTICATED	16	The requester doesn’t have valid authentication credentials for the operation	401

span.SetStatus(trace.Status{Code: int32(trace.StatusCodeNotFound), Message: "Cache miss"})

Time events

일정 기간 동안 특정 시점에 발생한 이벤트를 설명한다. 아래와 같은 필드 중에 하나를 사용할 수 있지만 모두 사용할 수는 없다.

주석 : 일정 기간 동안 발생한 이벤트에 대해 텍스트로 설명하는 스토리지 제공

Description: 이벤트를 설명하는 사용자 메시지

Attributes: 주석을 표현하는데 필요한 속성들

    import "go.opencensus.io/trace"
    ...
    span.Annotation([]trace.Attribute{
        trace.StringAttribute("store", "memcache"),
        trace.BoolAttribute("cache_miss", true),
        trace.Int64Attribute("age_ns", 13488999),
    }, "Cache miss durtin GC")

메시지 이벤트 : 스팬 간에 주고 받은 메시지 설명

유형 (Type)

유형	값	기술
SEND	1	이 메시지가 전송되었음을 나타냅니다.
RECEIVE	2	이 메시지가 수신되었음을 나타냅니다.
UNKNOWN	0	알 수없는 이벤트 유형 또는 기본값

신분증명 (ID) : SEND/RECEIVE 간의 메시지 이벤트 상관 관계를 위한 메시지 ID로 예를 들어 프로토콜 핸드 셰이크 또는 스트리밍 RPC간에 시퀀스/상태 번호를 일치시킬 떄 유용할 수 있다.
압축되지 않은 크기 (Uncompressed Size) : 송/수신 상에 압축되지 않은 바이트 수
압축된 크기 (Compressed Size) : 송/신 상에 압축된 바이트 수, 0 이면 압축되지 않은 바이트 수와 동일한 것으로 간주
```
// On the client
span.AddMessageReceiveEvent(seqNumber, 1024, 512)
// On the server
span.AddMessageSendEvent(seqNumber, 1024, 512)
```

시간 이벤트의 모음 이지만, 삭제 된 주석 수와 삭제된 메시지 이벤트 수에 대한 정보도 관리한다.
- 시간 이벤트 모음
- 삭제된 주석 수
- 삭제된 메시지 이벤트 수

Link

동일하거나 다른 추적에 속하는 스팬 간의 상호 관계를 설명한다. 예를 들어 서로 다른 추적 또는 서로 다른 프로세스로 구성된 일괄 작업이 수행된 경우에 한 스팬에서 다른 스팬으로의 링크는 관련 스팬들을 상호 연결하는데 도움이 될 수 있다.

다음과 같은 필드로 구성된다.

TraceID
SpanID
유형
- CHILD
- PARENT
- UNKNOWN
Attributes

# SpanA : 신뢰할 수 없는 경계 (예, 클라우드에 대한 클라이언트 요청)에서 시작됨
# SpanB : 신뢰할 수 있는 경계 (예, 서비스/클라우드 프런트엔드 서버)에서 시작됨

_, spanA := trace.StartSpan(context.Background(), "SpanA")
spanASC := spanA.SpanContext()

_, spanB := trace.StartSpan(context.Background(), "SpanB")
spanB.AddLink(trace.Link{
  TraceID: spanASC.TraceID,
  SpanID: spanASC.SpanID,
  Type: trace.LinkTypeChild,
  Attributes: map[string]interface{}{
      "reason": "client-RPC unverified source",
  }
})

SpanKind
- 스팬 간의 상/하위 관계 뿐만 아니라 추가적인 관계를 설명하는데 사용한다.
  
  유형 값 의미
  
  SERVER 1 범위는 RPC의 서버 측 처리를 다룹니다.
  
  CLIENT 2 범위는 RPC의 클라이언트 측 처리를 포함합니다.
  
  UNSPECIFIED 0 지정되지 않음
```
// Started on the client
ctx, cSpan := trace.StartSpan(ctx, "SpanStarted", trace.WithSpanKind(trace.SpanKindClient))
// Received from the server
ctx, sSpan := trace.StartSpan(ctx, "SpanStarted", trace.WithSpanKind(trace.SpanKindServer))
```
TraceOptions

TraceOptions는 각 Opencensus 스팬의 바이트로 마지막 비트는 스팬이 샘플링된 경우에 설정된다.

16 진수 상태 바이너리 상태 의미

0x00 00000000 스팬이 샘플링되지 않았습니다.

0x01 00000001 스팬이 샘플링 됨

유형	값	의미
SERVER	1	범위는 RPC의 서버 측 처리를 다룹니다.
CLIENT	2	범위는 RPC의 클라이언트 측 처리를 포함합니다.
UNSPECIFIED	0	지정되지 않음

16 진수 상태	바이너리 상태	의미
0x00	00000000	스팬이 샘플링되지 않았습니다.
0x01	00000001	스팬이 샘플링 됨

Tracestate

여러 분산 추적 그래프에서 위치 / 순서에 대한 정보를 설정하기 위한 것으로 최대 32개의 정렬된 목록 사용이 가능한 Key-Value 쌍이다.

필드	기술	제한
키	캐릭터 모음	소문자로 시작해야하며 소문자 영숫자, 대시, 별표 및 슬래시를 포함 &할 수 있습니다.
값	캐릭터 모음	인쇄 가능한 ASCII 문자 만

Sampling (이하 샘플링)

견본 추출

추적 데이터는 대량으로 생성되는 경우가 많기 때문에 수집 및 저장 비용뿐만 아니라 전송 비용도 많이 소비된다. 따라서 관찰 가능성과 비용 간의 균형을 맞춰서 추적을 샘플링하는 것이 필요하다. 즉, 전체 범위 중에 추적 대상을 정하는 범위와 내보낼지 여부를 결정하는 프로세스라고 생각하면 된다.

샘플러

Always : 모든 샘플링 결정에 true를 반환한다.

 import "go.opencensus.io/traces"

 _ = trace.AlwaysSample()

Never : 모든 샘플링 결정에 false를 반환한다.

  import "go.opencensus.io/traces"

  _ = trace.NeverSample()

Probabilistic : 동전 던지기와 같이 샘플링 결정에 true/false를 확률적으로 반환한다. (기본적으로 확률적 샘플링은 10,000분의 1이다)
```
  import "go.opencensus.io/traces"

  theSampler = trace.ProbabilitySampler(1/1000.0)
```

RateLimiting : 초당 0.1개의 추적 샘플링을 시도한다. 만일 상위 스팬이 샘플링되었다면 하위 스팬은 샘플링을 유지한다. 이와 같은 샘플링을 사용하는 이유는 아래와 같은 문제들을 해결하기 위한 용도로 사용한다.

QPS 기반 샘플링 얻기
실제 샘플링 확률 제공

최소한의 오버헤드

// 속도 제한을 달성하기 위해서 마지막 QPS 기반 샘플링 결정을 내린 시간이 원자 변수 (Atomic Variable)에 저장되고 마지막 확률적 결정을 내린 이후의 시간도 저장된다. 그리고 원하는 샘플링 QPS를 얻기 위한 확률 함수를 사용한다.

P(Z) = min(Z * X, 1)
// X : 원하는 QPS, Z : 마지막 샘플링 이후 경과된 시간 (초)

샘플러의 결정은 샘플러가 각각 true 또는 false를 반환하는 경우에 설정하거나 지워 Span.TraceOptions의 샘플링 비트 에 영향을 주게 된다.

샘플러 설정

글로벌 샘플러 : TraceConfig 설정을 통해서 전역으로 적용되는 샘플러를 말한다.

  package main

  import "go.opencensus.io/traces"

  func main() {
      // Having already created your sampler "theSampler"
      trace.ApplyConfig(trace.Config{DefaultSampler: theSampler})
  }

스팬별 샘플러 (스팬 범위) : 스팬을 생성할 때 지정해서 스팬에 적용되는 샘플러를 말한다.

  import "go.opencensus.io/traces"

  func doWork() {
      // Having already created your sampler "theSampler" and "ctx"
      ctx, span := trace.StartSpan(ctx, "DoWork", trace.WithSampler(theSampler))
  }

규칙

ParentSpan의 샘플링 결정은 추적 구성과 관련 없이 항상 모든 항목에 상속된다. 이를 통해서 추적의 연속성이 보장된다. 예를 들어 부모가 샘플링 되었는데 자식이 샘플링이 되지 않거나, 자식이 샘플링이 되었는데 부모가 샘플링이 되지 않는 경우들이 발생하는 것을 방지하기 위한 것이다.

참고자료

OpenCensus

[macOS - SSH] macOS에서 SSH Key를 이용해서 원격 Ubuntu 서버에 접속하기

ccambo — Sat, 19 Dec 2020 18:25:46 +0900

Access to remote server using ssh key with iterm2

환경

Mac OS
ssh-keygen (SSH에 사용할 키 발급)
ssh-copy-id (발급된 공개키를 서버에 전송)
원격 서버 (Ubuntu 16.04) 및 사용자

서버에 사용자가 추가되어 있다고 가정한다. 사용자 추가에 대한 부분은 많은 자료들이 존재하므로 참고하도록 한다.

ssh-copy-id 설치

ssh-copy-id는 로컬에서 발급된 공개키를 서버로 전송할 때 사용하는 패키지다.

$ brew install ssh-copy-id

SSH Key 발급

~/.ssh 폴더를 기준으로 한다.

# ssh-keygen [-t] [rsa] [-b] [2048]
# -t : dsa, ecdsa, ed25519, rsa, rsa1 중에 어떤 암호화 알고리즘을 선택할지 지정 (기본 값, rsa)
# -b : key를 생성할 때 bit 수 지정 (기본 값, 2048)
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/<현재 사용자>/.ssh/id_rsa): <<< 여기에 저장될 파일 경로 또는 파일명 입력
Enter passphrase (empty for no passphrase): <<< 비밀번호로 사용할 값
Enter same passphrase again: <<< 다시 입력
Your identification has been saved in <파일명>
Your public key has been saved in <파일명>.pub.

키 파일에 대한 권한 문제
ssh-key을 통해서 처리한 경우는 문제가 되지 않을 수 있지만 수동으로 처리한 경우는 다음과 같이 파일 권한을 설정해 줘야 한다.

공개 키 : 0644 (-rw-r--r--)

개인 키 : 0600 (-rw-------)
위와 같이 권한을 설정해 주지 않으면 원격 서버에 연결했을 떄 오류가 발생하며 접속이 허용되지 않는다.

발급된 공개 키 서버로 전송

별다른 입력이 없이 기본으로 처리했다면 ~/.ssh 폴더에 private key와 public key 파일이 생성된다.
파일명을 test라고 지정했다면 'test', 'test.pub' 파일이 존재할 것이다.

# ssh-copy-id -i [key path or name] [username in server]@[server ip]
$ ssh-copy-id -i test.pub ccambo@192.168.10.44
/usr/local/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "test.pub"
/usr/local/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/local/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
test@[IP Address]'s password:

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'test@[IP Address]'"
and check to make sure that only the key(s) you wanted were added.

실체 키 추가 여부는 지정한 서버의 사용자로 로그인을 해서 ~/.ssh/authorized_keys 파일에 지정한 키가 제대로 추가되었는지 확인하면 된다.

SSH로 접속하기

# ssh -i [private key name] [username in server]@[server id] -p [port number]
$ ssh -i test ccambo@192.168.10.44

SSH 접속 설정하기

~/.ssh/config 파일을 통해서 접속을 쉽게 처리할 수 있다.

config 파일이 경로에 없다면 생성한다.

$ cd ~/.ssh
$ touch config

config 파일을 열고 아래와 같이 설정해 주면 된다.

Host ccamboServer
    HostName [IP Address]
    User [Username]
    Port [Port Number]
    IdentityFile ~/.ssh/[private key name]

Host Name2
    HostName [IP Address]
    User [Username]
    Port [Port Number]
    IdentityFile ~/.ssh/[private key name]

설정을 통해서 SSH 접속은 다음과 같이 지정한 Host 이름을 기준으로 하면 된다.

# ssh [host name in config file]
$ ssh ccamboServer

참고 자료

Ubuntu 서버에 사용자 추가하기

[Kubernetes] Kubernetes Dashboard 설치 및 NodePort 접근설정

ccambo — Sat, 19 Dec 2020 18:16:11 +0900

How to install and access Kubernetes Dashboard

대시보드는 웹 기반 Kubernetes 사용자 인터페이스로 컨테이너화된 애플리케이션을 배포하고 문제를 해결하고, 클러스터 리소스들을 관리한다. 또한 클러스터의 쿠버네티스 리소스 상태 및 발생했을 수 있는 오류에 대한 정보도 확인할 수 있다.

Deployments
StatefulSets
DaemonSets
Jobs
Services
Ingress Deployments
Scaling
Rolling Update
Pod Management
Persistent Volume / Claim

배포 및 액세스

기본적으로 쿠버네티스에 포함되어있지 않기 때문에 별도 배포해 줘야 한다.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created

kubectl 명령줄 도구를 사용해서 대시보드에 접근할 수 있도록 프록시 처리를 해 준다. (8001 포트)

kubectl proxy

kubectl은 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/로 대시보드에 접근할 수 있도록 구성한다.

Using NodePort

권장 사항을 배포하는 것이므로 수정을 해야하는 경우라면 다음과 같이 다운로드해서 처리해 줘야 한다.

sudo dnf -y install wget

wget https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended.yaml

mv recommended.yaml kubernetes-dashboard-deployment.yml

위의 파일의 kind: Service 부분을 보면 아래와 같이 되어있다.

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  ports:
    - port: 443
      targetPort: 8443
  selector:
    k8s-app: kubernetes-dashboard

이 부분의 spec 에 type: NodePort 를 지정하고 저장한다.

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  ports:
    - port: 443
      targetPort: 8443
  selector:
    k8s-app: kubernetes-dashboard
  type: NodePort

참고
NodePort는 각 노드에 정적 포트를 서비스로 노출하며 NodePort 서비스가 라우팅하는 ClusterIP 서비스는 자동으로 생성된다.

이제 변경된 대시보드를 아래와 같이 배포한다.

kubectl apply -f kubernetes-dashboard-deployment.yml

namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created

배포된 상태는 아래의 명령으로 확인이 가능하다.

kubectl get deployments -n kubernetes-dashboard

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
dashboard-metrics-scraper   1/1     1            1           21s
kubernetes-dashboard        0/1     1            0           21s

위와 같이 두 개의 배포가 생성된 것을 확인할 수 있다.

kubectl get pod -n kubernetes-dashboard

NAME                                         READY   STATUS             RESTARTS   AGE
dashboard-metrics-scraper-79c5968bdc-fz4cl   1/1     Running            0          41s
kubernetes-dashboard-665f4c5ff-q22qg         0/1     ImagePullBackOff   0          41s

주의
위와 같이 ImagePullBackOff 상태가 나타날 수 있다. 일반적으로 도커에서 이미지 처리를 하는 과정 중에 발생할 수 있으므로 시간이 좀 지난 뒤에 확인해 보면 된다. 그러나 시간이 지나도 변화가 없이 똑같은 상태라면 오류가 발생했을 수 있으므로 아래의 명령으로 확인해 봐야 한다.
# kubectl describe pod {POD_ID} -n {namespace}

...
Events:
 Type     Reason     Age                    From               Message
 ----     ------     ----                   ----               -------
 Normal   Scheduled  5m42s                  default-scheduler  Successfully assigned kubernetes-dashboard/kubernetes-dashboard-665f4c5ff-q22qg to node-2
 Warning  Failed     5m24s                  kubelet            Failed to pull image "kubernetesui/dashboard:v2.0.4": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/kubernetesui/dashboard/manifests/v2.0.4: Get https://auth.docker.io/token?scope=repository%3Akubernetesui%2Fdashboard%3Apull&service=registry.docker.io: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
 Warning  Failed     5m24s                  kubelet            Error: ErrImagePull
 Normal   BackOff    5m23s                  kubelet            Back-off pulling image "kubernetesui/dashboard:v2.0.4"
 Warning  Failed     5m23s                  kubelet            Error: ImagePullBackOff
 Normal   Pulling    5m11s (x2 over 5m41s)  kubelet            Pulling image "kubernetesui/dashboard:v2.0.4"
 Normal   Pulled     4m24s                  kubelet            Successfully pulled image "kubernetesui/dashboard:v2.0.4" in 46.672759653s
 Normal   Created    4m23s                  kubelet            Created container kubernetes-dashboard
 Normal   Started    4m22s                  kubelet            Started container kubernetes-dashboard
위의 정보에서 실제 이미지를 제대로 받지 못해서 오류가 발생했었으나 재 시도해서 성공한 것을 확인할 수 있다.

참고로 도커의 유료화 정책에 따라서 IP 당 또는 Docker ID 당 Rate Limit 제한이 걸린다. 한번 걸리면 1시간 이상 지나야 풀리므로 Describe를 통해서 오류 원인이 뭔지 확인해야 한다.

kubectl get pod -n kubernetes-dashboard

NAME                                         READY   STATUS    RESTARTS   AGE
dashboard-metrics-scraper-79c5968bdc-fz4cl   1/1     Running   0          8m25s
kubernetes-dashboard-665f4c5ff-q22qg         1/1     Running   0          8m25s

위와 같이 두 개의 파드가 생성된 것을 확인할 수 있다.

kubectl get service -n kubernetes-dashboard

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
dashboard-metrics-scraper   ClusterIP   10.96.147.203    <none>        8000/TCP        8m55s
kubernetes-dashboard        NodePort    10.108.179.191   <none>        443:30568/TCP   8m56s

위와 같이 NodePort를 적용산 서비스가 생성된 것을 확인할 수 있다.

이제 https://localhost:30568 로 접근이 가능하다.

사용자 (관리자) 생성

클러스터 데이터를 보호하기 위해서 기본적으로 최소한의 RBAC 구성으로 배포되며 현재는 Bearer Token으로 로그인만 지원한다.

관리용 서비스 계정 만들기

서비스 계정 생성을 위해서 매니페스트부터 구성해야 한다.

# admin-sa.yml
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ccambo-admin        ## 생성할 계정이름
  namespace: kube-system

구성한 매니페스트 정보를 적용해서 쿠버네티스 클러스터에 객체를 생성한다.

kubectl apply -f admin-sa.yml

serviceaccount/ccambo-admin created

클러스터 역할 바인딩 생성

cluster-admin의 클러스터 역할 바인딩을 생성한 서비스 계정에 할당하기 위해 아래와 같이 매니페스트 파일을 구성한다.

# admin-rbac.yml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ccambo-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: ccambo-admin
    namespace: kube-system

구성한 매니페스트 정보를 적용해서 역할을 할당한다.

kubectl apply -f admin-rbac.yml

clusterrolebinding.rbac.authorization.k8s.io/ccambo-admin created

관리자 토큰 확인

생성된 서비스 계정으로 대시보드에 접근하기 위해서는 토큰 (Bearer Token)을 확인해야 한다.

# 변수에 사용사 설정
SA_NAME = "ccambo-admin"

# 토큰 확인
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep ${SA_NAME} | awk '{print $1}')

Name:         ccambo-admin-token-xdvfq
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: ccambo-admin
              kubernetes.io/service-account.uid: 1c84b3e8-caf7-4da4-8bac-bca612b7a274

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1066 bytes
namespace:  11 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6Imo0Zzc5MWoyRzE2ZUxHQk5KMExDSlEyR1I4MnhaQlRxLXQ3Sm8waVlUTjQifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW...
9MmJgFMXIrBVQtoLZ17a9nyM4oAd1Mqv6K3Gro-npeepSLO9d6hVWHdqsXjJkvhMGdYrCYtXSTf7vrDUKuRGRU-1Dv5Q

위의 결과에서 토큰 부분을 복사한다.

대시보드 액세스

만일 대시보드를 NodePort로 설정한 경우는 아래의 명령으로 포트 번호를 확인할 수 있다.

kubectl get services -n <namespace> | grep dashbaord

NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
kubernetes-dashboard   NodePort    10.111.76.69    <none>        443:32254/TCP   414d

해당 주소로 접근하면 액세스할 유형을 선택하는 화면이 나타나고 여기서 토큰 방식을 선택한 후 복사한 토큰을 입력하면 된다.

참고

Chrome등의 브라우저에서는 보안의 문제로 HTTPS 관련 인증서 문제가 발생하면 보안되지 않은 사이트로 처리되고 접근을 허용하지 않는다. 따라서 이런 상황이라면 Firefox를 설치해서 접근하면 보안 경고는 나오지만 고급 메뉴에 따라서 진입할 수는 있다.

참고 자료

[macOS] oh-my-zsh 설치 및 Item2 적용

ccambo — Sat, 19 Dec 2020 17:58:02 +0900

Set up Item2 terminal with oh-my-zsh on Mac

별다른 수정이 없었다면 기본 터미널 쉘은 `bash(Bourne Again Shell) 일 것이다.

$ echo $0
-bash

아마 맥북 최신 OS 상태라면 zsh로 나올 것이다. (macOS 10.15 Catalina 부터 GPL v3 라이센스 제한)

필수 준비 항목들

Homebrew 설치 : Mac OS 용 패키지 관리자

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
또는
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

설치 후에는 다음과 같이 패키지 명을 지정해서 다른 패키지들을 설치할 수 있다.

$ brew install [package-name]

zsh : bash를 확장한 쉘로 Mac은 bash 기반으로 zsh도 같이 설치되어 있다.
```
$ brew install zsh
$ which zsh
/usr/local/bin/zsh
$ chsh -s $(which zsh)
```
Item2 : Mac OS의 Terminal emulator, 다운로드해서 설치

Oh-my-zsh 설치 및 설정

터미널을 쉽게 사용할 수 있도록 ZSH를 확장하는 오프소스 프로그램으로 커뮤니티가 활발하게 형성되어 있다.

# curl을 이용한 설치
$ sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# wget을 이용한 설치
$ brew install wget
$ sh -c "$(wget -O- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# fetch를 이용한 설치
$ sh -c "$(fetch -o - https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

설치 중에 zsh를 기본 쉘로 사용할 것인지를 묻는데 Y를 입력하면 된다.

테마로 이동해서 마음에 드는 테마를 선택해서 설치한다. 주로 많이 사용되는 테마는 agnoster 테마, powerlevel10k 테마 이며 여기서는 powerlevel10k 테마를 사용하도록 한다.

$ git clone https://github.com/romkatv/powerlevel10k.git $ZSH/custom/themes/powerlevel10k

git 클론될 폴더는 원하는 곳으로 설정하면 된다. custom/themes를 주로 사용하고 themes 폴더도 존재한다.

이제 ZSH에서 테마를 인식할 수 있도록 $HOME/.zshrc 파일을 수정해 줘야 한다. (파일 편집은 편한 에디터를 사용하면 된다.)

아래와 같이 테마를 설정한다.

...
ZSH_THEME="powerlevel10k/powerlevel10k"
...

빈 공간에 아래와 같이 기본적인 사용자 정보를 설정한다. (기존에 사용자 정보가 출력되는 것을 방지하기 위한 것이다.)
```
...
DEFAULT_USER="morris"
...
```

위와 같이 설정하고 저장한 후에 터미널을 종료하고 다시 시작하면 된다. powerlevel10k 테마의 경우는 여러 옵션 선택하는 창이 나타나므로 원하는 선택을 하면 된다.

문제가 있거나 다시 설정할 경우는 아래의 명령으로 사용할 수 있다.

$ $ZSH/custom/themes/powerlevel10k/config

Iterm2 설정

Iterm2 Color Schemes 에서 컬러를 다운로드해서 설치한다.
Item2 Preferences 변경
- "Profiles" Tab > Default 선택 > Colors Tab > Color Presets... 콤보 선택해서 다운로드한 컬러 설정
powerline fonts 에서 사용할 폰트를 다운로드해서 설치한다.
- "Profiles" Tab > Default 선택 > Text Tab > Font 에서 사용할 폰트 선택
- D2Coding 폰트인 경우는 Powerlevel10k에서 깨지므로 Use a different font for non-ASCII text 체크를 해서 "MesloLGS NF" 로 추가 선택한다.

참고 자료

[Golang] 의존성 없이 웹으로 서비스할 정적 파일들을 Golang 바이너리에 추가하기

ccambo — Fri, 18 Dec 2020 14:11:11 +0900

[Golang] How to add static files (for Web serving) to the golang binary without dependencies

참고

go.rice

go-bindata

packr

esc

과연 이런 작업이 필요한 것일까?

특히 고객에게 전달되어야 하는 최종 산출물일 경우라면 이런 접근 방법에 대한 명확한 이유를 설명할 수 있어야 한다.

장점
- "안정성" : 바이너리에 추가된 파일은 다시 추출하기 어렵기 때문에 안정성이 있다.
- "편리" : 배포 또는 소스를 전달할 떄 웹 서비스를 위한 추가적인 폴더들을 제공할 필요가 없다.
단점
- "크기" : 추가된 만큼 바이너리 자체의 크기가 증가한다.
- "성능" : 그다지 큰 이슈가 될 것 같지는 않지만, Admin Web과 같이 정적 파일을 운영할 경우는 별도로 웹을 구성해서 서비스하는 것보다는 바이너리내의 파일을 서비스하는 개념이기 때문에 아주 약간의 성능 상 이슈가 있을 수 있다. 틱 단위의 서비스가 중요한 서비스가 아니라 내부 관리자 용이라면 이런 걱정은 하지 않아도 될만한 차이다.

가능한 원리는 무엇일까?

프로그램으로 프로그램 코드를 작성하는 "제너레이터"를 이용하는 것이다. (이전에는 "golang.org/x/tools/cmd/goyacc"를 이용했었다)

golang 1.4 부터는 이런 작업을 편하게 처리할 수 있도록 "go generate" 명령이 추가되었다. 이를 통하면 소스 상에 특수한 주석으로 명기된 명령을 검색해서 처리해주는 방식으로 운영할 수 있다.

구현해 보자.

이제 아주 간단한 실제 동작하는 샘플을 통해서 검증을 해 보자.

모듈 구성

go module을 사용하는 프로젝트 구성

# go mod init <project module path>

$ go mod init gitlab.com/ccambo/samples/golang/embedded

위의 명령으로 프로젝트 폴더에 "go.mod" 파일이 생성되었을 것이다.

빌드 구성 (makefile)

이제 makefile을 구성해 보자. (./makefile)

.PHONY: generate

generate:
    @go generate ./...
    @echo "[OK] 정적 파일들이 추가되었습니다!"

security:
    @gosec ./...
    @echo "[OK] 보안 검증이 완료되었습니다!"

build: generate security
    @go build -o ./build/server ./cmd/app/*.go
    @echo "[OK] 어플리케이션 바이너리가 생성되었습니다.!"

run:
    @./build/server

tip 팁!

코드에 GoSecurityChecker 사용을 권장한다. 이를 통해서 코드의 보안문제를 사전에 검증할 수 있다.

사용을 위한 설치는 다음과 같이 수행한다.
$ go get github.com/securego/gosec/v2/cmd/gosec

아직 동작하지 않는 상태이므로 아래의 나머지를 구성한 후에 테스트를 진행할 때 확인해 보도록 한다.

적용할 코드 구성

아래의 코드는 실제 Generate할 때 사용될 메서드들을 지정하는 것이다. 실제 사용할 코드가 아니라 정적 파일들을 추가하고 관리하는데 사용할 것이기 때문에 Box라고 패키지를 구성했다. (./internal/box.go)

//go:generate go run generator.go

// Package box - Embedded resource helper
package box

// ===== [ Constants and Variables ] =====

var (
    // 기본 Embedding Box 인스턴스 생성
    box = newEmbedBox()
)

// ===== [ Types ] =====

type (
    // Embedding 대상 파일들의 정보를 관리하기 위한 저장소 구조
    embedBox struct {
        storage map[string][]byte
    }
)

// ===== [ Implementations ] =====

// Add - Embedded Box 정보에 지정한 경로와 byte 정보 추가
func (e *embedBox) Add(file string, content []byte) {
    e.storage[file] = content
}

// Get - Embedded Box 정보에서 지정한 파일을 byte로 반환
func (e *embedBox) Get(file string) []byte {
    if f, ok := e.storage[file]; ok {
        return f
    }
    return nil
}

// Has - Embedded Box 정보내에 지정한 파일이 존재하는지 검증
func (e *embedBox) Has(file string) bool {
    if _, ok := e.storage[file]; ok {
        return true
    }
    return false
}

// ===== [ Private Functions ] =====

// newEmbedBox - Embedding할 파일들을 관라하기 위한 인스턴스 생성
func newEmbedBox() *embedBox {
    return &embedBox{storage: make(map[string][]byte)}
}

// ===== [ Public Functions ] =====

// Add - Embedded Box 정보에 지정한 경로와 byte 정보 추가
func Add(file string, content []byte) {
    box.Add(file, content)
}

// Get - Embedded Box 정보에서 지정한 파일을 byte로 반환
func Get(file string) []byte {
    return box.Get(file)
}

// Has - Embedded Box 정보내에 지정한 파일이 존재하는지 검증
func Has(file string) bool {
    return box.Has(file)
}

위의 코드에서 1번째 줄을 보면 "//go:generate go run generator.go" 주석이 있는 것이 보일 것이다.
이 주석을 통해서 다른 코드를 생성하는데 이 파일의 메서드가 사용될 수 있도록 처리하는 것이다.

즉, go build를 통해서 빌드 작업을 하는 중에 이 주석을 만나게 되면 go run generate.go가 동작하게 되며 현재 파일 (box.go)의 메서드들이 호출되어 사용된다.

BLOB 파일 템플릿 구성

이제 실제 Generate 작업을 수행하는 코드를 구성해 보자. Generating 동작이 수행될 떄의 Entry point가 된다. (./internal/generator.go)

//+build ignore

// Package main - Generator Entry point
package main

import (
    "bytes"
    "fmt"
    "go/format"
    "io/ioutil"
    "log"
    "os"
    "path/filepath"
    "strings"
    "text/template"
)

// ===== [ Constants and Variables ] =====

const (
    // 생성될 파일 명
    blobFileName string = "blob.go"
    // 처리 대상 정적 파일 경로
    embedFolder string = "../static"
)

var (
    // 템플릿 처리에서 호출할 함수 맵
    conv = map[string]interface{}{"conv": fmtByteSlice}

    // 코드 구성을 위한 템플릿
    tmpl = template.Must(template.New("").Funcs(conv).Parse(`package box
// Code generated by go generate; DO NOT EDIT.
func init() {
    {{- range $name, $file := . }}
        box.Add("{{ $name }}", []byte{ {{ conv $file }} })
    {{- end }}
}`),
    )
)

// ===== [ Types ] =====
// ===== [ Implementations ] =====
// ===== [ Private Functions ] =====

// fmtByteSlice - 지정한 []byte를 문자로 반환
func fmtByteSlice(s []byte) string {
    builder := strings.Builder{}

    for _, v := range s {
        builder.WriteString(fmt.Sprintf("%d,", int(v)))
    }

    return builder.String()
}

func main() {
    // 정적 파일 경로 확인
    if _, err := os.Stat(embedFolder); os.IsNotExist(err) {
        log.Fatal("지정한 정적 경로가 존재하지 않습니다!")
    }

    // 정적 파일들의 파일명과 파일 내용 관리용 맵 생성
    configs := make(map[string][]byte)

    // 정적 파일 경로를 기준으로 파일 검증 및 처리
    err := filepath.Walk(embedFolder, func(path string, info os.FileInfo, err error) error {
        // 축약 경로 구성
        relativePath := filepath.ToSlash(strings.TrimPrefix(path, embedFolder))

        // 폴더 여부 검증
        if info.IsDir() {
            // 현재는 폴더는 생략
            log.Println(path, "는 디렉토리이므로 현재 지원되지 않습니다.")
            return nil
        } else {
            // 파일만 처리
            log.Println(path, "는 파일이므로 추가합니다.")

            b, err := ioutil.ReadFile(path)
            if err != nil {
                // 파일 내용 오류
                log.Printf("Error reading %s: %s", path, err)
                return err
            }

            // 경로와 내용을 맵에 추가
            configs[relativePath] = b
        }

        return nil
    })
    if err != nil {
        log.Fatal("정적 폴더를 처리하는 중에 오류 발생:", err)
    }

    // 출력할 대상 파일 생성
    f, err := os.Create(blobFileName)
    if err != nil {
        log.Fatal("처리 대상 파일 생성 중에 오류 발생:", err)
    }
    defer f.Close()

    // 버퍼 구성
    builder := &bytes.Buffer{}

    // 정적 파일 정보를 기준으로 템플릿 처리
    if err = tmpl.Execute(builder, configs); err != nil {
        log.Fatal("템플릿 실행 중에 오류 발생", err)
    }

    // 생성된 코드 포맷 처리
    data, err := format.Source(builder.Bytes())
    if err != nil {
        log.Fatal("생성된 코드의 포맷 처리 중에 오류 발생", err)
    }

    // 생성된 코드 출력
    if err = ioutil.WriteFile(blobFileName, data, os.ModePerm); err != nil {
        log.Fatal("생성된 코드를 파일로 저장 중에 오류 발생", err)
    }
}

// ===== [ Public Functions ] =====

위의 코드에도 "//+build ignore" 주석이 있는 것을 확인할 수 있다. 이 주석은 모듈 프로젝트의 빌드 작업이 진행될 떄 처리할 대상이 아니라는 것을 지정한 것이다. 즉, 다른 코드를 생성하는 처리에만 필요하고 기본 빌드에는 포함될 필요가 없다는 의미다.

generator 코드를 통해서 생성된 파일을 blob.go 파일이고, 이 파일은 실제 빌드과정에 포함되어 빌드되게 된다. 나중에 테스트를 통해서 확인할 수 있지만, 생성된 파일에는 (../../static) 폴더내의 모든 파일들이 바이트 조각으로 포함되게 된다.

검증 대상 만들기 (Static Files)

이제 빌드 과정을 통해서 바이너리로 포함될 정적 파일을 구현하도록 한다. 실제 바이너리에 포함될 파일이다. (./static/index.html)

<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>{{.Title}}</title>
  </head>
  <body>
    <h1>{{.Heading}}</h1>
    <p>{{.Description}}</p>
  </body>
</html>

위의 코드는 단순하게 정보를 출력하는 HTML 파일로 위의 코드에서 볼 수 있는 것과 같이 Go Template을 사용했다.

테스트 및 검증

이제 테스트를 위한 어플리케이션 진입점을 만들도록 한다. (./cmd/app/main.go)

// Package main - Entry point of application
package main

import (
    "log"
    "net/http"
    "text/template"

    box "gitlab.com/ccambo/samples/golang/embedded/internal"
)

// ===== [ Constants and Variables ] =====
// ===== [ Types ] =====

type (
    // PageData - 정적 파일에 전달할 데이터 구조
    PageData struct {
        Title       string
        Heading     string
        Description string
    }
)

// ===== [ Implementations ] =====
// ===== [ Private Functions ] =====

func main() {
    // 바이너리로 추가했던 정적 페이지 호출 (바이너리로 포함된 축약 경로)
    index := string(box.Get("/index.html"))

    // 템플릿 처리
    tmpl := template.Must(template.New("").Parse(index))

    // 웹 액세스 핸들러 설정
    http.HandleFunc("/", func(rw http.ResponseWriter, req *http.Request) {
        data := PageData{
            Title:       "외부 의존성 없이 정적 파일을 바이너리에 포함시키기",
            Heading:     "샘플 코드",
            Description: "블로그의 샘플을 잘 보고 활용하면, 더 많은 작업들을 할 수 있다",
        }

        // 템플릿 실행
        if err := tmpl.Execute(rw, data); err != nil {
            log.Fatal(err)
        }
    })

    // 웹 서버 실행
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal(err)
    }
}

// ===== [ Public Functions ] =====

이제 간단하지만 실행 가능한 모든 소스들을 구성했으므로 빌드 작업을 진행해 보도록 하자.

$ make build
2020/09/22 16:20:00 ../static 는 디렉토리이므로 현재 지원되지 않습니다.
2020/09/22 16:20:00 ../static/index.html 는 파일이므로 추가합니다.
[OK] 정적 파일들이 추가되었습니다!
[gosec] 2020/09/22 16:20:00 Including rules: default
[gosec] 2020/09/22 16:20:00 Excluding rules: default
[gosec] 2020/09/22 16:20:00 Import directory: /Users/morris/Workspaces/Samples/Golang/modules/embedded/cmd/app
[gosec] 2020/09/22 16:20:00 Checking package: main
[gosec] 2020/09/22 16:20:00 Checking file: /Users/morris/Workspaces/Samples/Golang/modules/embedded/cmd/app/main.go
[gosec] 2020/09/22 16:20:00 Import directory: /Users/morris/Workspaces/Samples/Golang/modules/embedded/internal
[gosec] 2020/09/22 16:20:00 Checking package: box
[gosec] 2020/09/22 16:20:00 Checking file: /Users/morris/Workspaces/Samples/Golang/modules/embedded/internal/blob.go
[gosec] 2020/09/22 16:20:00 Checking file: /Users/morris/Workspaces/Samples/Golang/modules/embedded/internal/box.go
Results:


Summary:
   Files: 3
   Lines: 127
   Nosec: 0
  Issues: 0

[OK] 보안 검증이 완료되었습니다!
[OK] 어플리케이션 바이너리가 생성되었습니다.!

위와 같이 정적 파일 생성, 보안 검사, 바이너리 생성 등의 작업이 진행된 것을 볼 수 있다.

이제 생성된 정적 파일을 포함해서 생성된 소스 파일 (./internal/blob.go)을 확인해 보도록 하자.

package box

// Code generated by go generate; DO NOT EDIT.
func init() {
    box.Add("/index.html", []byte{60, 33, 68, 79, 67, 84, 89, 80, 69, 32, 104, 116, 109, 108, 62, 10, 60, 104, 116, 109, 108, 32, 108, 97, 110, 103, 61, 34, 107, 111, 34, 62, 10, 10, 60, 104, 101, 97, 100, 62, 10, 32, 32, 32, 32, 60, 109, 101, 116, 97, 32, 99, 104, 97, 114, 115, 101, 116, 61, 34, 85, 84, 70, 45, 56, 34, 32, 47, 62, 10, 32, 32, 32, 32, 60, 109, 101, 116, 97, 32, 110, 97, 109, 101, 61, 34, 118, 105, 101, 119, 112, 111, 114, 116, 34, 32, 99, 111, 110, 116, 101, 110, 116, 61, 34, 119, 105, 100, 116, 104, 61, 100, 101, 118, 105, 99, 101, 45, 119, 105, 100, 116, 104, 44, 32, 105, 110, 105, 116, 105, 97, 108, 45, 115, 99, 97, 108, 101, 61, 49, 46, 48, 34, 32, 47, 62, 10, 32, 32, 32, 32, 60, 109, 101, 116, 97, 32, 104, 116, 116, 112, 45, 101, 113, 117, 105, 118, 61, 34, 88, 45, 85, 65, 45, 67, 111, 109, 112, 97, 116, 105, 98, 108, 101, 34, 32, 99, 111, 110, 116, 101, 110, 116, 61, 34, 105, 101, 61, 101, 100, 103, 101, 34, 32, 47, 62, 10, 32, 32, 32, 32, 60, 116, 105, 116, 108, 101, 62, 123, 123, 46, 84, 105, 116, 108, 101, 125, 125, 60, 47, 116, 105, 116, 108, 101, 62, 10, 60, 47, 104, 101, 97, 100, 62, 10, 10, 60, 98, 111, 100, 121, 62, 10, 32, 32, 32, 32, 60, 104, 49, 62, 123, 123, 46, 72, 101, 97, 100, 105, 110, 103, 125, 125, 60, 47, 104, 49, 62, 10, 32, 32, 32, 32, 60, 112, 62, 123, 123, 46, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 125, 125, 60, 47, 112, 62, 10, 60, 47, 98, 111, 100, 121, 62, 10, 10, 60, 47, 104, 116, 109, 108, 62})
}

제대로 처리가 되었는지는 아래의 명령으로 실행을 검증해 보면 된다.

$ make run

정상적이라면 위와 같이 HTTP 서비스 상태가 된다. 로컬의 브라우저를 열어서 "http://localhost:8080" 으로 출력을 확인해 보면 된다.

결론

아주 간단하게 단순 파일을 바이너리에 추가하고, 이를 서비스하는 방법에 대해 정리해 보았다.

아직 실제 사용하기에는 많은 부분이 부족하다. 하지만 최소한 어떻게 접근하면 되는지에 대한 방법을 찾았기 때문에 아래의 참조 정보들을 검토해서 원하는 결과물을 생성하면 된다.

[Docker] 컨테이너 내부에서 외부의 HTTPS 호출할때 X509 오류 해결하기

ccambo — Fri, 18 Dec 2020 13:40:22 +0900

How to resolve X509 errors when invoking external HTTPS from inside the container

오류 정보

로컬 PC에서 개발할 때는 HTTP Client를 이용해서 HTTPS 사이트에 접속해서 결과를 받아오는데 문제가 없지만, Docker Image를 구성하고 컨테이너로 동작을 시키면 certificate signed by unknown authority 오류 발생

원인

TLS (이전에는 SSL) 사이트는 서버 인증을 통해서 보안이 유지되는 연결을 구성하기 위한 것이기 때문에 클라이언트가 접속하게 되면 서버 인증서를 클라이언트로 보내고 클라이언트는 인증서를 검증해서 제대로 구성된 CA 목록에 존재하는지를 확인한 후에 서버에 응답하면 통신 중에 정한 대칭키를 이용해서 보안 통신을 하게 된다.

이 과정에서 문제가 발생하여 클라이언트와 서버 간에 인증 과정을 제대로 처리하지 못하는 상태가 되면 이와 관련된 오류가 발생하게 된다. 오류 메시지의 내용을 보면 서버에서 보내온 인증서의 서명을 확인하지 못하는 것으로 판단이 된다. (물론 다른 이유도 여러 가지 있을 수 있다)

해결 방법

Docker Image를 만들 때 어떤 베이스 이미지를 사용했는지에 따라서 인증 관련 패키지가 설치되지 않았을 경우가 많다. 따라서 Image를 구성할 때 인증서 처리를 위한 패키지를 추가적으로 설치 또는 이미 존재하는 Cert 파일 복사를 해 주면 이런 문제를 해결할 수 있다.

단일 Stage 방법으로 Image를 생성하는 경우 (CA-Certificates 파일이 존재하는 경우)

FROM scrtch

ADD ca-certificates.crt /etc/ssl/certs/     # 이미 존재하는 경우 복사
ADD main /

CMD ["/main"]

Multi Stage 방법으로 Image를 생성하는 경우 (CA-Certificates 패키지 설치하는 경우)

FROM golang:alpine as build

RUN apk --no-cache add ca-certificates      # CA-Certificates 패키지 설치

WORKDIR /go/src/app

COPY . .

RUN CGO_ENABLED=0 go-wrapper install -ldflags '-extldflags "-static'

FROM scratch

COPY --from-build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/        ## CA-Certificates 인증서 복사
COPY --from-build /go/bin/app /app

ENTRYPOINT ["/app"]

결론

이미지를 만들 때 이미 존재하는 CA-Certificates 인증서 파일을 이미지에 특정 경로 (/etc/ssl/certs)에 복사
Alpine 이미지를 사용하는 경우는 CA-Certificates 패키지 설치 및 최종 이미지의 특정 경로(/etc/ssl/certs)에 복사

[macOS, GIT] Mac Book에 Git 설치

ccambo — Thu, 17 Dec 2020 10:39:08 +0900

Mac북에 Git 설치하기

패키지를 이용한 설치

[https://git-scm.com/download/mac](https://git-scm.com/download/mac) 접속
git-x.x.x-xxx.dmg 다운로드
다운로드 받은 파일 실행

Homebrew를 이용한 설치

Home-brew 가 미 설치 상태라면 참고해서 설치를 하도록 한다.

$ brew install git

설치 확인

설치 여부는 아래의 명령을 통해서 확인 가능하다.

# 설치 버전 확인
$ git --version
git version 1.7.10.3

# 설치 경로 확인
$ which git
/usr/local/git/bin/git

결론

두 가지 모두 설치는 가능하지만 맥북이라면 나중에 설치를 삭제하거나 업그레이드 등의 관리가 편하므로 Homebrew를 이용해서 설치하는 것이 좋다.

참고 정보

[CentOS 8] Python 2 / 3 설치하기

ccambo — Wed, 16 Dec 2020 19:26:37 +0900

How to install Python2 and Python3 to CentOS 8

Python은 셰계에서 가장 인기있는 프로그래밍 언어 중의 하나로 간단히 배우기 쉬운 구문을 가진기 때문에 초보자나 숙달된 개발자들에게 인기가 많다.

다른 Linux 배포판들과는 달리 CentOS 8에는 기본적으로 설치되저 있지 않기 때문에 추가 설치를 해줘야 하며, Python2 / Python3 로 양분된 버전이 존재한다. 이중에 Python 2는 2020년에 지원이 종료될 것이기 때문에 앞으로는 Python 3를 사용하는 것이 좋다.

RHEL (Red Hat Enterprise Linux) 와 CentOS 8에는 사용자를 특정 버전 Python으로 한정되지 않도록 하는 unversioned system-wide python Command가 없다. 대신에 사용자가 특정한 Python 버전을 설치 및 구성과 실행할 수 있는 옵션을 제공한다.

참고

CentOS 8에서는 yum 패키지 관리자 대신 dnf 패키지 관리자가 탑재되어 있다. 그러나 현재는 두 개 모두 사용이 가능하다. 단, 이 문서에는 dnf 를 사용하는 것으로 한다.

Install Python 3 on CentOS 8

아래의 명령으로 Python 3 버전을 설치한다. (pip 도 같이 설치가 된다)

$ sudo dnf install -y python3

아래의 명령으로 설치된 버전을 확인한다.

$ python3 --version

python은 python3로, pip는 pip3 로 명시적인 버전을 지정해야 한다. 그리고 pip는 가상환경 내에서만 사용해야 한다. Python Virtual Environment를 사용하면 Python 모듈을 글로벌하게 설치하는 것이 아니라 특정한 프로젝트의 격리된 위치에 설치할 수 있게 된다. 이를 통해 다른 Python 프로젝트 간의 영향을 걱정할 필요가 없다.

Install Python 2 on CentOS 8

아래의 명령으로 Python 2 버전을 설치한다. (pip 도 같이 설치가 된다)

$ sudo dnf install -y python2

아래의 명령으로 설치된 버전을 확인한다.

$ python2 --version

python은 python2로, pip는 pip2 로 명시적인 버전을 지정해야 한다.

Set Default Python Version (Unversioned Python Command)

시스템 경로에서 python 명령을 찾을 것으로 예상되는 애플리케이션을 가지고 작업을 해야 하는 경우는 Unversioned system-wide python command를 생성하고 기본 버전을 지정해 줘야 한다.

alternatives 유틸리티를 이용해서 다음의 명령으로 Python3를 지정할 수 있다.

$ sudo alternatives --set python /usr/bin/python3

Python2를 지정할 수도 있다.

$ sudo alternatives --set python /usr/bin/python2

alternatives 명령은 지정한 python 버전을 가르키는 symlink인 python을 생성한다.

따라서 python --version 명령을 사용하면 지정된 실제 Pythone 버전을 출력하게 된다.

다른 버전을 사용해야 할 경우는 위의 명령과 같이 다시 한번 실행하면 되고, 만일 이를 삭제할 경우는 아래의 명령으로 python symlink를 삭제하면 된다.

$ sudo alternatives --auto python

[Kubernetes - KREW] KREW란 무엇일까?

ccambo — Wed, 16 Dec 2020 13:52:30 +0900

What is the KREW

KREW는 kubectl을 확장하기 위한 플러그인 매니저로 Kubernetes SIG로 개발이 진행되고 있다.

kubectl 플러그인 검색
플러그인 설치
설치된 플러그인 최신 상태 유지

참고

kubectl v1.12 이상 버전에만 호환된다.

현재 Krew에는 127개의 kubectl 플러그인이 등록되어 있으며, macOS, linux, windows 등의 모든 플랫폼에서 작동된다.

KREW를 사용하면 플러그인을 개발하고 여러 플랫폼에 쉽게 배포하고 중앙 집중식 플러그인 저장소를 통해 검색 및 설치 및 관리가 가능하다.

Install

macOS / Linux

참고

Linux에서 shell 확인하는 방법

grep <user name> /etc/passwd 를 실행하면 해당 사용자 정보 및 사용하는 쉘 정보가 출력된다.

cat /etc/shells 를 실행하면 현재 설치되어 있는 쉘 리스트를 볼 수 있다.

git 설치하는 방법

CentOS 8에서는 sudo yum -y install git 또는 sudo dnf -y install git 를 사용

git --version 명령으로 설치 확인

bash 또는 zsh 쉘

git가 설치되어 있어야 한다.

krew 다운로드 및 설치

(
  set -x; cd "$(mktemp -d)" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew.tar.gz" &&
  tar zxvf krew.tar.gz &&
  KREW=./krew-"$(uname | tr '[:upper:]' '[:lower:]')_$(uname -m | sed -e 's/x86_64/amd64/' -e 's/arm.*$/arm/')" &&
  "$KREW" install krew
)

$HOME/.krew/bin 디렉터리를 PATH에 추가하고 아래와 같은 명령을 .bashrc 또는 .zshrc 파일에 추가하고 쉘을 재 시작한다.
```
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
```
kubectl krew 명령을 통해 정상 동작여부 확인

fish 쉘

git가 설치되어 있어야 한다.

krew 다운로드 및 설치

begin
  set -x; set temp_dir (mktemp -d); cd "$temp_dir" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew.tar.gz" &&
  tar zxvf krew.tar.gz &&
  set KREWNAME krew-(uname | tr '[:upper:]' '[:lower:]')_(uname -m | sed -e 's/x86_64/amd64/' -e 's/arm.*$/arm/') &&
  ./$KREWNAME install krew &&
  set -e KREWNAME; set -e temp_dir
end

$HOME/.krew/bin 디렉터리를 PATH에 추가하고 아래와 같은 명령을 config.fish 파일에 추가하고 쉘을 재 시작한다.
```
set -gx PATH $PATH $HOME/.krew/bin
```
kubectl krew 명령을 통해 정상 동작여부 확인

Windows

git가 설치되어 있어야 한다.
Release Page에서 krew.exe 다운로드
심볼릭 링크를 사용하므로 관리자 권한으로 cmd.exe를 실행하고 다운로드한 디렉토리로 이동
krew 설치 명령을 실행
```
krew install krew
```
%USERPROFILE%\.krew\bin 디렉터리를 PATH 환경변수에 추가
새로운 cmd.exe를 실행하고 kubectl krew 명령을 통해 정상 동작여부 확인

사용 방법

플러그인 리스트 다운로드및 검색

$ kubectl krew update   # 최신 플러그인 리스트 다운로드
$ kubectl krew search [plugin name]  # 플러그인 검색, plugin name을 생략하면 가능한 모든 플러그인 리스트 출력

플러그인 설치
```
$ kubectl krew install access-matrix
```
설치된 플러그인 사용
```
$ kubectl <installed plugin name>
```
설치된 플러그인 갱신
```
$ kubectl krew upgrade
```
설치된 플러그인 삭제
```
$ kubectl krew uninstall <plugin name>
```

[OpenStack] CentOS 8에 OpenStack Client 설치 (PIP)

ccambo — Mon, 14 Dec 2020 16:06:17 +0900

How to install Open Stack Client on CentOS 8 (PIP Installation)

OpenStack Client는 명령줄 도구로 네트워크를 통해 OpenStack 구성 요소, 즉 Compute, Identity, Image, Object Storage 및 Block Storage API를 함께 관리할 수 있다.

이 문서에서는 CentOS 8 버전에 OpenStack Client를 설치하고 구성하는 방법을 정리한다.

환경 검증

$ cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)

STEP 0. 환경 갱신

$ sudo yum update
# or
$ sudo dnf update

STEP 1. Python2 PIP 설치 (옵션)

$ sudo yum -y install python2-pip
# or
$ sudo dnf -y install python2-pip

STEP 2. Python3 PIP 설치 (권장)

$ sudo yum -y install python3-pip
# or
$ sudo dnf -y install python3-pip

Step 2. OpenStack Client 설치

아래 명령을 실행해서 OpenStack Client를 설치한다.

$ sudo pip3 install -y python-openstackclient

참고
sudo나 root 사용자로 설치를 하면 권장하지 않는다면 경고메시지가 나온다.
이 경고 메시지는 권한이 있는 경로에 설치하지 말고, 현재 사용자로 한정된 구역으로 설치하라는 의미가 된다.

WARNING: Running pip install with root privileges is generally not a good idea. Trypip3 install --userinstead.

다만 위의 경고대로 설치를 하면 /usr/local/bin에 설치가 되는 것이 아니라 ~/.local/bin으로 설치가 된다. 따라서 환경 변수의 경로부분에 추가를 해 줘야 한다.

Step 3. 확인

아래 명령을 실행해서 OpenStack CLI 설치를 확인한다.

$ which openstack
/usr/local/bin/openstack

$ openstack --version
openstack 5.4.0

환경 설정하기

OpenStack에 대한 세세한 제어를 위해서는 OpenStack CLI를 사용해야 하며, 이 명령을 사용하기 위해 아래와 같이 변수를 정의한 ~/keystonrc 파일을 생성한다.

export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin
export OS_USERNAME=<user name>
export OS_PASSWORD=<user password>
export OS_AUTH_URL=<openstack url>
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

생성한 파일의 환경 변수로 적용하고 권한을 600으로 변경한다.

$ source ~/keystonerc

$ chmod 600 ~/keystonerc

로그인 할 때 적용되도록 ~/.profile 또는 셸 프로파일 (.bash_profile, .zsh_profile, ...) 파일에 아래와 같이 설정을 추가하도록 한다.

...
# OpenStack rc file
if [ -f ~/keystonerc ]; then
  source ~/keystonerc
fi
...

정상적인 동작을 확인하기 위해 아래와 같이 명령이 실행되는지를 검증한다.

$ openstack user list

Commands

OpenStack Web Console로 대 부분 처리가 가능하지만 Client로 처리를 해야하는 것들도 존재한다. 따라서 Command관련된 내용은 작업을 진행하면서 수시로 갱신될 수 있다.

Network

Network 정보 확인
```
$ openstack network list
```

Floating IP

Floating IP 검색
```
$ openstack floating ip list
```

Floating IP 정보

$ openstack floating ip show <floating_ip>

Floating IP 생성

$ openstack floating ip create --floating-ip-address <floating-ip> <network pool>

Floating IP 삭제

$ openstack floating ip delete <floating-ip> [<floating-ip> ...]

참고 자료

[Kubernetes] kubectl 활용팁

ccambo — Wed, 17 May 2017 21:50:52 +0900

kubectl 활용 팁

Kubernetes 관련 정보들을 검색하던 중에 kubectl 툴을 좀 더 활용할 수 있는 팁 정보가 있어서 정리해 놓는다.

kubectl 은 쿠버네티스를 운영하기 위한 CLI 도구로 상당히 많은 기능들을 제공하기 때문에 기능들을 다 파악하는 것은 어렵지만 강력한 도구로 활용이 가능하다.

기본적인 사용법에 관련된 것은 Cheatsheet 를 참고하면 된다.

kubectl with Shell Completion

kubectl 은 bash 및 zsh가 내장된 쉘 완성 기능을 제공하기 때문에 명령, 플래그 및 객체를 네임스페이스 또는 파드 이름과 같이 자동 완성으로 사용하는 것이 훨씬 쉽다.

아래의 그림은 실제 자동완성 기능을 제공하도록 설정한 후의 사용법을 보여주는 것이다.

원문 에는 kubectl 바이너리 설치부터 설명이 되어 있지만 대부분은 kubernetes 설치환경일 것이므로 자동 완성만 처리하면 된다.

Notes
자동 완성 스크립트는 kubectl에 의해서 생성되므로 프로파일에 설정해서 사용하면 된다. 관련된 정보는 kubectl completion -h 를 확인하면 된다.

On linux, usnig bash

리눅스 bash 환경에서 자동완성 스크립트를 Shell 로 로드 처리는 아래의 명령을 사용하면 된다.

      $ source <(kubectl completion bash)

프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.

      $ echo "source <(kubectl completion bash)" >> ~/.bashrc

On MacOS, using bash

맥에서 bash 자동 완성을 수행하려면 아래의 명령으로 자동완성 지원 기능을 먼저 설치해야 한다.

      $ brew install bash-completion

Shell에 자동완성 스크립트 로드 처리는 아래의 명령을 사용하면 된다.

      $ source $(brew --prefix)/etc/bash_completion
      $ source <(source <(kubectl completion bash)

프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.

      $ echo "source $(brew --prefix)/etc/bash_completion" >> ~/.bash_profile
      $ echo "source <(kubectl completion bash)" >> ~/.bash_profile

Kubernetes 구성 병합

여러 쿠버네티스 클러스들과 상호 작용을 하는 경우라면 쿠버네티스 설정을 병합하는 것이 일반적인 패턴이며 병하해서 사용할 떄 특정 클러스터를 사용하도록 하는 파라미터들을 서술하기 위해 context 개념을 사용한다.

제대로 운영하기에는 복잡하기 때문에 KUBECONFIG 환경 변수를 사용해서 구성 파일을 지정하도록 병합할 수 있다.

만일 병합할 2개의 쿠버네티스 클러스터 (cluster1, cluster2) 가 있다면 각 클러스터별로 정보를 가지는 설정 파일이 다음과 같을 것이므로 이를 개별 파일로 구성하도록 한다.

클러스터 #1 설정

      $ kubectl config view --minify > cluster1-config
      apiVersion: v1
      clusters:
      - cluster:
      certificate-authority: cluster1_ca.crt
      server: https://cluster1
      name: cluster1
      contexts:
      - context:
      cluster: cluster1
      user: cluster1
      name: cluster1
      current-context: cluster1
      kind: Config
      preferences: {}
      users:
      - name: cluster1
      user:
      client-certificate: cluster1_apiserver.crt
      client-key: cluster1_apiserver.key

클러스터 #2 설정 (#1 에서와 같이 처리해서 사용할 장소에 복사하면 된다)

      $ cat cluster2-config
      apiVersion: v1
      clusters:
      - cluster:
      certificate-authority: cluster2_ca.crt
      server: https://cluster2
      name: cluster2
      contexts:
      - context:
      cluster: cluster2
      user: cluster2
      name: cluster2
      current-context: cluster2
      kind: Config
      preferences: {}
      users:
      - name: cluster2
      user:
      client-certificate: cluster2_apiserver.crt
      client-key: cluster2_apiserver.key

위의 2개 설정을 KUBECONFIG 환경 변수를 통해서 접근할 수 있도록 병합하고 context 지정을 통해서 2개의 클러스터를 동적으로 사용할 수 있다. context 는 클러스터를 인증 및 상호작용하도록 구성을 참조할 수 있는 클러스터, 사용자 및 이름을 설명하는 맴 정보라고 생각하면 된다.

이제 --kubeconfig 플래그를 이용해서 각 파일의 context 정보를 확인할 수 있다.

      $ kubectl --kubeconfig=cluster1-config config get-contexts
      CURRENT NAME CLUSTER AUTHINFO NAMESPACE
      * cluster1 cluster1 cluster1
      $ kubectl --kubeconfig=cluster2-config config get-contexts
      CURRENT NAME CLUSTER AUTHINFO NAMESPACE
      * cluster2 cluster2 cluster2

각각의 설정 파일은 하나의 context를 가지기 때문에 서로 충돌하지 않으며, 두 파일을 실제 병합하면 두 개의 Context 가 모두 표시된다.

병합을 위해서 cluster-merge 라는 새로운 파일을 만들고 아래와 같이 처리를 하면 된다.

      $ export KUBECONFIG=cluster-merge:cluster-config:cluster2-config
      $ kubectl config get-contexts
      CURRENT NAME CLUSTER AUTHINFO NAMESPACE
      * cluster1 cluster1 cluster1
      cluster2 cluster2 cluster2

병합되는 순서는 지정된 순서대로 처리되고 current-context 는 첫번째 구성 파일에서 지정한 context 가 되기 떄문에 액티브 표시 (*) 가 cluster1 context 를 가르키고 있는 것을 확인할 수 있다.

context 를 2번쨰로 변경하면 정보를 아래와 같이 보여지게 된다.

      $ kubectl config get-contexts
      CURRENT NAME CLUSTER AUTHINFO NAMESPACE
      * cluster1 cluster1 cluster1
      cluster2 cluster2 cluster2

      $ kubectl config use-context cluster2
      Switched to context "cluster2".

      $ kubectl config get-contexts
      CURRENT NAME CLUSTER AUTHINFO NAMESPACE
      cluster1 cluster1 cluster1
      * cluster2 cluster2 cluster2

병합에 사용했던 파일을 확인해 보면 아래와 같이 변경된 것을 확인할 수 있다.

      $ cat cluster-merge
      apiVersion: v1
      clusters: []
      contexts: []
      current-context: cluster2
      kind: Config
      preferences: {}
      users: []

실제 사용되는 클러스터는 항상 current-context 정보로 확인할 수 있다.

Context는 강력하고 다양한 방법으로 활용 및 병합이 가능하다. 예를 들어 모든 kubectl 명령에 적용될 수 있도록 네임 스페이스를 지정하는 Context 를 만들 수도 있다. (사실 매번 네임스페이스 지정하는 것도 귀찮은 일이다)

      $ kubectl config set-context cluster1_kube-system --cluster=cluster1 --namespace=kube-system --user=cluster1
      Context "cluster1_kube-system" set.

      $ cat cluster-merge
      apiVersion: v1
      clusters: []
      contexts:
      - context:
      cluster: cluster1
      namespace: kube-system
      user: cluster1
      name: cluster1_kube-system
      current-context: cluster2
      kind: Config
      preferences: {}
      users: []

위의 예는 cluster1 에 kube-system 이라는 네임스페이스를 모든 명령에 사용할 수 있도록 context를 구성한 것으로 아래와 같이 context를 지정해서 사용할 수 있다.

      $ kubectl config use-context cluster_kube-system
      Switched to context "cluster1_kube-system".

      $ kubectl get pods
      NAME READY STATUS RESTARTS AGE
      default-http-backend-fwx3g 1/1 Running 0 28m
      kube-addon-manager-cluster 1/1 Running 0 28m
      kube-dns-268032401-snq3h 3/3 Running 0 28m
      kubernetes-dashboard-b0thj 1/1 Running 0 28m
      nginx-ingress-controller-b15xz 1/1 Running 0 28m

context 에 네임스페이스가 지정되어 있기 때문에 각 명령 단위로 추가로 지정할 필요가 없다.

Kubernetes API 에 대한 정보 확인

Kubernetes는 API 정보 제공을 위해서 swagger UI 가 통합되어 있다. 따라서 아래의 명령으로 json 문서를 얻을 수도 있다.

      $ kubectl proxy
      $ curl -O 127.0.0.1:8001/swagger.json

아니면 직접 http://localhost:8001/api/ 페이지를 통해 정보를 확인할 수도 있다.

만일 json 문서를 활용한다면 jq 툴을 이용해서 활용할 수도 있다.

      $ cat swagger.json | jq '.paths | keys[]'      
        "/api/"
        "/api/v1/"
        "/api/v1/configmaps"
        "/api/v1/endpoints"
        "/api/v1/events"
        "/api/v1/namespaces"
        "/api/v1/nodes"
        "/api/v1/persistentvolumeclaims"
        "/api/v1/persistentvolumes"
        "/api/v1/pods"
        "/api/v1/podtemplates"
        "/api/v1/replicationcontrollers"
        "/api/v1/resourcequotas"
        "/api/v1/secrets"
        "/api/v1/serviceaccounts"
        "/api/v1/services"
        "/apis/"
        "/apis/apps/"
        "/apis/apps/v1beta1/"
        "/apis/apps/v1beta1/statefulsets"
        "/apis/autoscaling/"
        "/apis/batch/"
        "/apis/certificates.k8s.io/"
        "/apis/extensions/"
        "/apis/extensions/v1beta1/"
        "/apis/extensions/v1beta1/daemonsets"
        "/apis/extensions/v1beta1/deployments"
        "/apis/extensions/v1beta1/horizontalpodautoscalers"
        "/apis/extensions/v1beta1/ingresses"
        "/apis/extensions/v1beta1/jobs"
        "/apis/extensions/v1beta1/networkpolicies"
        "/apis/extensions/v1beta1/replicasets"
        "/apis/extensions/v1beta1/thirdpartyresources"
        "/apis/policy/"
        "/apis/policy/v1beta1/poddisruptionbudgets"
        "/apis/rbac.authorization.k8s.io/"
        "/apis/storage.k8s.io/"
        "/logs/"
        "/version/"

기타 명령

api-versions 명령은 관리자로 실행되며, RBAC가 활성화된 경우라면 다른 API 세트 정보가 표시될 수 있다.

      $ kubectl api-versions
      apps/v1beta1
      authentication.k8s.io/v1beta1
      authorization.k8s.io/v1beta1
      autoscaling/v1
      batch/v1
      batch/v2alpha1
      certificates.k8s.io/v1alpha1
      coreos.com/v1
      etcd.coreos.com/v1beta1
      extensions/v1beta1
      oidc.coreos.com/v1
      policy/v1beta1
      rbac.authorization.k8s.io/v1alpha1
      storage.k8s.io/v1beta1
      v1

explain 명령은 각 파트에 대한 이해를 위한 기능적인 도움을 제공한다.

      $ kubectl explain
      You must specify the type of resource to explain. Valid resource types include:
      * all
      * certificatesigningrequests (aka 'csr')
      * clusters (valid only for federation apiservers)
      * clusterrolebindings
      * clusterroles
      * componentstatuses (aka 'cs')
      * configmaps (aka 'cm')
      * daemonsets (aka 'ds')
      * deployments (aka 'deploy')
      * endpoints (aka 'ep')
      * events (aka 'ev')
      * horizontalpodautoscalers (aka 'hpa')
      * ingresses (aka 'ing')
      * jobs
      * limitranges (aka 'limits')
      * namespaces (aka 'ns')
      * networkpolicies
      * nodes (aka 'no')
      * persistentvolumeclaims (aka 'pvc')
      * persistentvolumes (aka 'pv')
      * pods (aka 'po')
      * poddisruptionbudgets (aka 'pdb')
      * podsecuritypolicies (aka 'psp')
      * podtemplates
      * replicasets (aka 'rs')
      * replicationcontrollers (aka 'rc')
      * resourcequotas (aka 'quota')
      * rolebindings
      * roles
      * secrets
      * serviceaccounts (aka 'sa')
      * services (aka 'svc')
      * statefulsets
      * storageclasses
      * thirdpartyresources
      error: Required resource not specified.
      See 'kubectl explain -h'
        for
        help and examples.

예를 들어 explain deploy 명령을 실행해 보고, deploy 의 좀더 세분화된 객체를 지정해서 정보를 확인할 수도 있다.

      $ kubectl explain deploy.spec.template.spec.containers.livenessProbe.exec
      RESOURCE: exec <Object>
      DESCRIPTION:
      One and only one of the following should be specified. Exec specifies the
      action to take.
      ExecAction describes a "run in container" action.
      FIELDS:
        command <[]string>
      Command is the command line to execute inside the container, the working
      directory for the command is root ('/') in the container's filesystem. The
      
      command is simply exec'd, it is not run inside a shell, so traditional shell
      instructions ('|', etc) won't work. To use a shell, you need to explicitly
      
      call out to that shell. Exit status of 0 is treated as live/healthy and
      non-zero is unhealthy.

Conclusion

다양한 기능들을 제공하기 때문에 모든 것을 알지도 못하고 정리하는 것도 쉽지는 않지만 다양한 자료들을 확인하면서 유용하다고 생각되는 기능들은 비록 발 번역 수준에 오타, 다른 이해가 있더라도 정리를 해 나갈 예정이다.

현재는 프로젝트를 쉬고 있는 중이지만, 향후 실제 기업에서 운영되는 어플리케이션들을 Containerize 처리와 Kubernetes Cluster에 배포 운영하는 프로젝트를 진행할 예정이기 때문에 좀 더 현실적이고 구체적인 사례들을 정리할 수 있을 것 같다.

References

CHEAT SHEET, CONFIGURAITON MERGE, KUBECTL, KUBERNETES, SHELL COMPLETION, 쿠버네티스

부업 - 주식으로 용돈벌기 도전

ccambo — Wed, 17 May 2017 21:26:14 +0900

부업으로 삼을 수 있을지 주식에 도전한다.

하고 싶은 것을 다 하면서 살 수 있으면 좋겠지만, 흙수저 출신인 나에게는 꿈과 같은 이야기일 뿐이고, 그렇다고 남달리 능력이 좋은 것도 아니고, 경력관리를 잘해서 주 분야가 있는 것도 아닌 일반 단순 개발자라서 시장에 부름을 받기는 힘든 상황이니 인생 후반기를 대비해야 할 무엇인가를 늦었지만 빨리 찾아야 할 상황이다.

딱히 기술이 있는 것도 아니고, 금손도 아니고, 대인 관계가 그렇게 활발한 것도 아니기 때문에 여러 가지를 고려해 볼 때 주식 투자가 적합해 보인다. 그러나 시드 머니도 없는 상태고, 관련된 지식도 없는 상태라서 아주 조금씩이라도 부업으로 가능성이 있는지를 확인하는 차원에서 용돈이라도 벌어보자는 도전을 해 보려고 한다. 물론 쉽지 않은 도전이지만 최소한 투자한 시간 대비 최저 임금 수준만 유지하면 용돈으로 쓰기에는 만족할 수준일 것 같다. 향후에는 용돈을 넘어 생활비 벌기에 도전할 수 있도록 열심히 해야할 듯 하다.

`"아무 것도 하지 않으면, 아무 일도 일어나지 않는다."`

가능성이 있는 것일지, 성공일지, 실패일지를 미리 고민할 필요는 없다. 돈을 잃는다고 해도 그만큼의 경험을 살 수 있다면 나름대로 성공한 것일거다. 물론 계속된 실패를 반복하지만 않는다면 말이다.

초기 설정

주식에 관해서는 아는 것이 별로 없다. 그냥 상식적인 수준에서 단어만 몇개 알고 있을 뿐이다.

매수/매도
챠트
유/무상 증자
배당
시간외 거래
상/하한 30%
매매 수수료, 거래세

시작은 작게 그러나 향후의 꿈은 크게 하는 것이 좋을 듯 하다.

투자금액 : 100만원
목표비율 : 최저임금 수준으로 일별 +3% 내외

20170518 보유/관심종목

주식시장에 등록된 주식수가 2,000 종목 내외라고 한다. 망할 회사가 아니라면 주가의 흐름 상으로 언젠가는 복구가 될 수 밖에는 없는 것으로 판단이 되고, 업종 / 섹터 등의 구분이 필요하지만 지금은 아무것도 모르는 상태이 그냥 여러 가지 정보 중에서 가능성이 있다고 판단되는 것을 기준으로 선별해 본다.

종목	관련 종목	정보
필룩스		장 시작 30분 이내에 전일 거래량의 100%를 넘겼다. 대형 신규사업 발주 예정 소문
에스디생명과학		공모가 이하 진행 중, 중국 한한령 풀리면 화장품/합작드라마 가능성 있음
에이디칩스	디에스티로봇, 우리기술,디피시,셀바스AI	인공지능, 로봇, 사물인터넷 핵심 초경량 CPU 코어 개발 성공, 5월 중 상용화 가능성, 삼성전자와의 연계
한신기계		적대적 M&A 가능성

아직은 뭐가 좋고 나쁜지에 대한 판단을 제대로 하지는 못하지만, 가능성 있는 종목들을 고르다 보면 좋은 결과가 있을지도 모르겠다.

매일은 아닐지 몰라도 관련된 종목과 정보들을 정리하다 보면 연관성과 시장을 바라보는 경험이 쌓일 것이라고 생각한다.

매매 종목

삼부토건 : 입찰 기대감에 대한 끝물이라고 판단해서 익절
에이디칩스 : 가능성 때문에 분할로 모아가기 및 읿부 익절
한강인터트레이드 : 상한가, 일부 익절
캠시스 : 익절
에스에프씨 : 일부 익절

첫날인 오늘은 다행하게도 목표인 +3%에 턱걸이를 했지만 내일은 또 어떨지 벌써 궁금해지고 있다. 내일도 웃을 수 있을까? ^^

Importants

매수할 때 목표 수익률과 손절률 정하고 지키기

지속 가능성이 적다면 당일로 매도해서 이익 보전 또는 손해 줄이기

장기적인 가능성이 있다면 소량씩 분할로 모아가기

10원을 벌어도 잃지 않으면 손해가 아니다

절대 욕심내지 말고 이익 또는 본절 지키기

손절은 생명을 구하는 것과 같다

느리고 답답하더라도 하나씩 자신만의 규칙을 정해가면 좋은 결과가 있을 듯 하다.

[취미] 20170511 - 하이런 6점 기록

ccambo — Fri, 12 May 2017 17:14:53 +0900

취미로 활동하던 당구 동호회 (세븐당구동호회)에서 나름대로 열심히 연습을 하면서 몇 가지 궁금한 것이 있었다.

정말 올바른 자세를 취하고 있는 것인가?
내 플레이를 제 3자의 입장에 보면 어떻게 보일까?
샷이 정상적으로 처리되고 있는 것일까?
항상 만나는 사람들이 아닌 전혀 다른 사람들과의 실력 차이는 얼마나 될까?
정말 20점 수지에 맞는 실력을 가지고 있는 것일까?

취미지만 이왕이면 제대로 확인을 해 보고 싶어서 여러 가지를 검색해 보던 중에 큐스코 시스템을 사용하는 구장들이 있다는 것을 알았다.

집에서 가장 가까운 곳을 검색해 보니 신대방 SBS 당구장이 나왔다. 유튜브에서 하이런등의 경기 영상을 많이 보던 곳인데 의외로 가까운 곳에 위치해 있어 용기(?) 내서 다녀왔다.

정액제 동호회가 아니기 때문에 전투적으로 임해야 하는 살벌한 구장이다. 대대 (10분 2,000원) 경기도 많이 해보지 않아서 많이 힘들었지만 중대에서 치는 것과는 다른 기분이다. 일단 무지하게 넓고 힘을 많이 써야할 듯 하다.

2일 동안 4게임을 진행하면서 하이런 4점과 6점을 기록했고, 20, 21, 22 점과의 대결에서 모두 승리했다. 물론 재수(뽀록)가 많이 도움이 되었지만 그래도 상대방과 비교해서 터무니없이 못치는 수준은 아니라는 것을 확인했다. 당연히 기본적인 실력은 내가 모자라다는 것을 느끼지만…

역시나 동영상으로 촬영된 내 플레이 영상을 보니 상당히 많은 문제점들이 존재했다. ㅠㅠ

라스트 샷 순간에 너무 빠르고 힘차게(?) 큐를 내미는 문제
큐선과 시선이 자주 불일치해서 두께를 제대로 유지하지 못하는 문제
어깨 부상 때문에 업샷이 자주 나오는 문제
회전을 많이 줄 때 샷 트릭이 무의식적으로 많이 들어가는 문제 (삑사리 과다)

기타 등등의 문제가 너무나 많다는 사실과 이런데 어떻게 이겼지?? 라는 의문이 든다. 쩝~

큐스코 구장을 사용했을 때의 좋은 점은 여러 가지가 있다.

제 3자의 시각에서 볼 수 있는 동영상 촬영이 기본으로 된다.
앱을 이용해서 언제든지 리플레이와 다운로드가 가능하다.
전적 기록과 엡버리지 등의 관리가 가능하다.
다양한 고수들과 대결을 할 수 있으며, 촬영된 영상을 통해서 공 선택과 자세, 샷 등의 정보를 얻을 수 있다.
엉망인 내 문제들을 확인할 수 있다.

2017년 5월 11일에 기록한 하이런 6점 영상

음, 영상을 보면서 또 하나 느낀 것은 관리되지 않은 얼굴과 몸매가 그대로 드러나는 단점이다. -_- 취미로 운동(헬쓰와 스쿼시)을 다시 시작해야할 것 같다는 불안감이다.

[OS] Windows에서 MSVCR90.dll 오류 대처하기

ccambo — Fri, 12 May 2017 12:11:21 +0900

MSVCR 관련 오류

“MSVCR (Microsoft Visual C++ Runtime)” 관련 오류는 어플리케이션을 직접 개발해서 배포하거나 아니면 다른 어플리케이션을 설치해서 사용할 때 흔히 발생하는 오류 중에 하나기 때문에 큰 문제는 없다. 그러나 조치를 취했음에도 불구하고 동일한 오류가 계속 반복되는 경우라면 상황을 잘 파악해 봐야 한다.

일반적인 발생 원인

거의 대부분은 MSVCR 라이브러리가 설치되지 않았기 떄문에 발생한다. 주로 볼 수 있는 오류 상황은 다음과 같다.

설치가 되지 않은 상황이거나 아니면 버전 또는 아키텍처와 관련되어 라이브러리를 로드할 수 없는 경우도 존재한다.

오늘 이 게시글을 작성하는 이유는 설치도 로드도 모두 잘 되었지만 사용 중에 오류가 발생하면서 어플리케이션이 종료가 되는 경우도 있기 때문이다. 이 경우는 아마도 C++ 코드 작성에서 메모리 처리를 하면서 OS 특성을 타는 부분일 것으로 예상된다.

발생한 오류는 예외 코드 0xc0000417 이며 발생한 모듈은 MSVCR90.DLL 이다. 좀 더 구체적인 상항은 덤프된 정보를 분석해 봐야하지만 일반적인 해결 방법을 적용해 보도록 한다.

해결 방법

해결 방법은 구체적인 오류 발생 정보가 없는 경우라면 아래와 같이 단순하게 적용해 볼 수 있다.

설치가 안되었거나 로드할 수 없는 경우

설치가 안된 상태이거나 설치에 문제가 있거나 아니면 다른 버전과의 문제가 있다면 프로그램 및 기능 을 통해서 기존에 설치되어 있는 것을 제거한 후에 재 부팅해서 다시 설치하는 방식을 사용하면 된다.

설치를 해서 필요로 하는 버전과 아키텍처가 맞는지를 확인해 봐야 한다. 필요하다면 다른 버전의 배포판도 검토해야 한다.

설치 및 로드 후 문제가 있는 경우

설치도 모두 되어 있고, 정상적으로 어플리케이션이 실행도 되지만 특정한 상황에서 오류로 종료되는 경우라면 작성한 개발 코드가 OS 아키텍처나 특성 상의 문제가 내포하고 있는 경우가 대 부분이다.

따라서 이런 경우는 어플리케이션에서 문제를 해결한 새 버전을 배포하지 않는 한은 어플리케이션 호환성을 설정해 주고 실행해서 문제가 없는 상황으로 어플리케이션을 실행시키는 방법을 사용해야 한다.

문제가 되는 어플리케이션의 "속성 창"을 열고 "호환성 탭"을 선택한다.

그림에서 빨간 박스로 처리한 “호환성 문제 해결사 실행” 을 누르면 "호환성 마법사"가 동작을 하는 것이고, 익히 겪어본 상황(?) 이라면 파란 박스로 처리한 부분을 직접 설정해서 사용하면 된다.

호환성 문제 해결사는 관련된 문제 요소를 검증해서 자체적인 규칙으로 호환성을 설정한 후에 선택할 수 있도록 제공한다.

권장 설정을 선택하면 해당 프로그램을 테스트 할 수 있도록 제공하므로 반드시 “프로그램 테스트…” 를 눌러서 호환성 환경에서 어플리케이션의 문제가 발생하지 않는지를 확인해야 한다.

위의 호환성 테스트 실행에 문제가 없는 것을 확인하면 다음 버튼을 눌러서 호환성 설정을 어플리케이션에 반영해야 한다. 반영된 설정으로 다음 실행부터 계속 적용이 된다.

Importants
설정이 저장되어 잘 실행된다고 해도 Windows Update 등과 같은 처리가 진행되면서 기존의 호환성 설정 정보가 적용되지 않는 경우도 심심치 않게 발생하므로 문제가 발생할 경우는 다시 호환성 설정을 처리해 줘야 한다.

결론

개발자들이 흔히 간과하는 것이 개발 환경과 실행 환경이 판이하게 다를 수 있다는 점이다. 개발 환경에서 모든 설정을 해 놓고 어플리케이션이 잘 돌아간다고 하는 것은 전혀 다른 사용자의 환경을 고려하지 않았다는 반증이다. 따라서 개발이 완료된 상태라면 블라인드 테스트와 배포 테스트를 통해서 어플리케이션의 실행에 필요한 라이브러리나 설정이 빠진 것이 없는지를 모두 검토해 봐야 한다.

Notice
간혹 msvcr90.dll 파일을 직접 복사해야할 경우가 생길 수 있는데 다음의 경로를 검토해 보면 된다.

32 bit인 경우 : C:\Windows\System32

64 bit인 경우 : C:\Windows\SysWOW64

References

[취미] 새로운(?) 당구 시스템?

ccambo — Mon, 8 May 2017 18:08:25 +0900

몇 가지 안되는 취미생활 중에 요즘 빠져있는 것이 당구다. 물론 영화 보는 것도 좋아하지만, 너무 활동량이 없어서 운동 겸해서 동호회 당구 (정액제)를 하고 있다.

작년 1월부터 다시 시작을 했고, 3구 기준으로 이제 20점이다. 물론 아직은 제대로 원리를 이해하지는 못하는 수준이지만 개발도 맨땅에 헤딩하면서 배웠듯이 당구도 지금 열심히 헤딩 중이다.

이런 저런 이론적인 것을 동호회나 카페, 유튜브 등에서 읽어보고 휴일에 당구장에서 살 듯이 연습을 해 보지만 역시나 이론과 실제는 너무나 차이가 많다는 것을 체감할 뿐이다. ㅠㅠ

예전에는 거의 4구 경기만 했었기 때문에 오늘 소개하는 것도 역시 4구에 대한 이론 (주로 세리)을 개인적으로 정립하신 정필규님의 자료다.

겨냥점이라는 것은 어려운 것이 아니다. 수구로 제 1 목적구를 맞춘 후에 제 2 목적구를 맞추기 위해서 어떤 곳을 향해서 쳐야 하는지를 정리한 것이라고 생각하면 된다.

여기서 당구의 이론과 각종 시스템을 논의하는 것도 아니고, 내가 좋아하는 취미고, 4구 이론을 3구에도 적용할 수 있을 것 같아서 소개하는 것이다.

아직은 형편없는 수준이지만 몇 가지만 기억하면서 연습하면 될 듯 하다.

타격, 힘, 과다한 회전 등은 공의 성질을 변화시킨다.
최대한 공의 자연스러운 방향과 힘을 유지할 수 있도록 해야 한다.
과다한 스트록은 오히려 독이 된다. 상황에 맞는 스트록을 적용해야 한다.
자신의 회전량을 알아야 한다.
기준이 되는 공의 흐름 또는 라인을 정하고 이에 맞춰서 스트록, 회전 등에 따른 변화를 몸에 익혀야 한다.

당구라는 것이 워낙 다양한 변수들이 조합되는 것이라서, 딱히 정답이라는 것은 없을 수 밖에 없다. 단지 고점자들이 다양한 경험을 기준으로 대략적인 방법을 만들어 놓은 것 (시스템)을 제시하는 것일 뿐이다.

몇 번 시스템을 검토해 보고 따라해 봤지만, 나는 역시 감으로 하는 당구 (무식한 감이 아니라 어느 정도 확률이 높은 나만의 라인을 찾아가고 있다)가 맞는 듯 해서 지금도 열심히 감을 키우고 있다.

목표는 2년 안에 30점을 만드는 것이다. 듣기로는 40점 이상부터 프로 선수 수준이라고 하고 대 부분 1년에 1점씩 그것도 많이 연습해서 올릴 수 있다고 하니 너무 높은 목표인 듯 하지만 그래야 열심히 할 듯 하다. 물론 항상 좌절을 느끼겠지만…

혹시 저와 같이 당구가 취미이신 분은 댓글 달아 주세요. 지역/시간 맞으면 같이 즐겨요~ ^^

지역 : 대방 (휴일) / 보라매 (휴일) / 구로디지털 (평일)

References

Hexo Plugin Series - hexo-related-popular-posts 설정하기

ccambo — Fri, 28 Apr 2017 16:20:22 +0900

이 시리즈는 Hexo 블로그를 Gitlab 페이지로 운영하면서 다양한 플러그인들을 테스트해 보고, 나름대로 설정하는 방법을 정리하는 것이다.

Overview

태그를 기반으로 관련 포스트들에 대한 링크 목록을 만들고, Google Analytics 의 페이지 뷰를 기준으로 인기 있는 (많은 페이지 뷰를 기록하는) 포스트들을 정렬된 링크 목록을 만드는 기능을 제공하는 플러그인이다.

또한 포스트의 내용에 따라서 관련된 포스트들에 대한 링크 목록을 생성할 수 있고, 다양한 Styles, Thumbnails 등을 지원하고, 다양한 부분에 사용자 정의가 가능하며, 성능과 관련해서 캐싱 기능도 포함하고 있다.

Notes

이 글에서는 _config.yml 파일에 설정을 다양하게 지정한다. 따라서 설정을 추가/변경하는 경우는 기존에 실행 중이던 Hexo Server를 재 실행해 줘야 하며 다음과 같이 처리하는 것을 권장한다.
 hexo clean            # 기존 캐시 및 Static content 삭제 (db.json)
 hexo g                # 신규 Static content 생성 (/public)
 hexo server --draft   # Draft 버전도 동일하게 서비스

Features

이 플러그인은 다음과 같은 기능을 제공한다.

연관된 포스트에 대한 링크 리스트 생성 (태그 연관성과 내용 연관성)
인기 있는 포스트에 대한 링크 리스트 생성 (페이지 뷰 수 기준 정렬)
포스트에 대한 방문자 수 (페이지 뷰) 표시

Notes

이 플러그인의 인기있는 게시글 및 페이지 뷰 처리는 Google Analytics 연계를 통해서 처리되며, 설정이 쉽지않고(?) 관련된 구글 계정이 구성되어 있어야 하므로 아래의 설정 부분을 검토하고 이 플러그인을 사용할지 여부를 결정하는 것이 좋다.

Settings

설치는 아래의 명령을 통해서 Hexo 블러그에 추가하면 된다.

$ npm install hexo-related-popular-posts --save

기본 적용

기본적인 적용 방법은 블로그에서 사용하는 테마 폴더에서 article.ejs 파일에 아래와 같은 내용을 추가하면 된다.

<%- popular_posts () %>

이제 Hexo 를 재 처리해서 결과를 확인해 보면 된다.

$ hexo clean
$ hexo server --draft

위의 처리는 해당 포스트 뷰에 태그 기준으로 연관된 다른 포스트에 대한 링크를 보여주는 것으로 실행되면 아래와 같이 생성된 결과를 볼 수 있다.

태그 연관 목록 생성 샘플

참고로 샘플에서는 article-footer 바로 위 부분에 삽입한 것이다.

여기까지는 외부의 정보 및 기타 설정 (_config.yml)이 없이 플러그인의 기본 기능을 사용하는 것이다. 따라서 어느 위치에 연관 목록을 만들지만 고민해서 적용하면 된다.

확장 적용

확장 기능은 다음과 같다.

Options of helper
Popular posts
Avanced Related posts (Morphological Analysis)
Cache (Improve generation speed)
Log
Customize HTML
Visitor Counter
Ranking Sheet

확장 적용을 위해서는 아래와 같이 블로그 설정 파일 (블로그 루트에 있는 _config.yml) 에 설정을 추가해 줘야 한다.

# More detailed settings
popularPosts:
  # (optional) Popular posts options
  googleAnalyticsAPI:
    clientId: ******.apps.googleusercontent.com
    serviceEmail: *****@developer.gserviceaccount.com
    key: /hexo-project-root/path/to/google-services.pem
    viewId: 12345678
    dateRange: 30
    expiresDate: 10
    pvMeasurementsStartDate: 2015/11/01
    rankingSheet: rankingSheet.txt
    # cache:            # (Deprecated) This options is Deprecated > v0.1.3
    #  path: hexo-related-popular-posts-ga-cached.json  # (Deprecated) This options is Deprecated > v0.1.3
    #  expiresDate: 10  # (Deprecated) This options is Deprecated > v0.1.3
  # (optional) Advanced Related posts options
  morphologicalAnalysis: 
    negativeKeywordsList: pluginSettings/hexo-rpp-negativewords.txt
    limit: 300
  # (optional) Related post's weight options
  weight:
    tagRelevancy: 1.0
    contentsRelevancy: 1.0
  # (optional) Cache options (Improve generation speed.)
  cache:
    path: cache/hexo-popular-related-posts-ga-cached.json
  # (optional) Log options
  log: true

Important

설정 항목이 모두 (optional) 처리가 되어 있다. 그러나 googleAnalyticsAPI 설정은 설정할꺼면 전부 올바른 값을 설정해야 한다. 그렇지 않으면 오류가 발생한다.

우선 각 기능에 대해서 확인을 먼저하고 나머지 설정에 대한 부분을 확인해 보도록 한다.

Options of helper

위에서 사용한 popular_posts() 에 추가 옵션을 설정하는 것으로 다음과 같은 옵션들을 지정할 수 있다.

option	description	default
maxCount	목록으로 구성할 최대 포스트 수	5
ulClass	목록에 사용할 CSS 클래스 명	‘popular-posts’
PPMixingRate	목록에 인기 포스트와 연관 포스트의 구성 비율	0.0 (= 연관 포스트만 처리)
isDate	날짜 표시 여부	false
isImage	이미지 표시 여부	false
isExcerpt	발췌 표시 여부	false
PPCategoryFilter	인기 포스트 목록에 카테고리 설정 옵션	미 정의

옵션 설정의 예제는 다음과 같다.

연관 포스트 목록에 5개를 표시하고 이미지를 구성하는 경우

<%- popular_posts_json({ maxCount: 5 , ulClass: 'popular-posts' , PPMixingRate: 0.0 , isImage: true}) %>

인기 포스트 목록에 10개를 생성하는 경우 (단, Google Analytics API 설정 필요)

<%- popular_posts_json({ maxCount: 10 , ulClass: 'popular-posts' , PPMixingRate: 1.0 }) %>

기타 옵션들은 직접 테스트를 해보는 것으로 하고, 화면에 표시되는 HTML 을 설정하고 싶은 경우는 아래의 Customize HTML 을 참고하면 된다.

여기는 Google Analytics 설정 의 페이지 뷰 데이터를 기준으로 동작하는 것이기 때문에 Google Analytics API 호출 설정이 필요하다.

Google Analytics 설정이 되었다는 전제하에 아래와 같은 정보를 블로그 루트 폴더에 있는 _config.yml 파일에 설정해 줘야 한다.

popularPosts:
  googleAnalyticsAPI:
    clientId: ******.apps.googleusercontent.com
    serviceEmail: *****@developer.gserviceaccount.com
    key: /hexo-project-root/path/to/google-services.pem
    viewId: 12345678
    dateRange: 30       # (Optional) The period you want to get by Google Analytics page view. Default = 30
    expiresDate: 10     # (optional) Expiration date of cache file. Default = 10

Google Analytics 설정 페이지를 잘 확인해서 구성한 후에 필요한 정보를 위의 설정에서 바꿔주면 된다.

우선 아래와 같은 사항에 대해서 구성할 때 검토가 필요하다.

clientId: 는 사용자 인증 정보의 OAuth 2.0 클라이언트 ID 값을 의미한다.
serviceEmail: 은 사용자 인증 정보가 아닌 Service Account 를 구성하면 생성되는 서비스 계정 ID 를 의미한다. 작성자가 데이터가 이메일 포맷이라서 용어를 그렇게 사용한 것 같다. 이 것 때문에 엄청 헤맸다. -_-
key: 는 기본 제공되는 것이 아니기 때문에 Service Account 관리 페이지에서 프로젝트를 선택하고 키를 생성해 줘야 한다. 이 부분에서도 json 과 p12 포맷이 존재하는데 json 을 이용하는 방식을 플러그인에서 제공하지 않으므로 반드시 p12 방식으로 선택해서 키를 생성하고 다운로드하도록 한다. 키 변환 명령은 아래에서 다시 설명한다.
viewId: 는 Account Expolorer 를 실행해서 표시되는 사이트 정보 밑에 Account 와 같이 표시되는 View 항목에 설정된 값을 사용하면 된다.

원문에 Google Analytics 설정 관련 참고자료 가 있기는 하지만 나중에 별도의 포스트를 작성해야 할지도 모르겠다.

위의 _config.yml 파일에 설정한 정보 중에서 몇가지는 환경변수로 처리가 가능하기 때문에 아래와 같이 환경변수와 _config.yml 혼용으로 사용해도 된다.

환경변수 설정

$ export GOOGLEAPI_CLIENTID="******.apps.googleusercontent.com"
$ export GOOGLEAPI_EMAIL="*****@developer.gserviceaccount.com"
$ export GOOGLEAPI_KEY="/path/to/google-services.pem"
$ export GOOGLEAPI_ANALYTICS_TABLE="ga:12345678"

_config.yml 설정 변경

popularPosts:
  googleAnalyticsAPI:
    dateRange: 60
    expiresDate: 10

기본적인 연관 포스트 목록은 태그 값을 기준으로 하지만, 내부의 링크나 포스트의 키워드들을 기준으로 형태소 분석(Morphological Analysis) 을 기준으로 설정할 수도 있다.

현재 지원되는 언어는 일어와 영어 딱 2개만 지원되고 있다. 개발자가 일본 사람인 듯하니 어쩔 수 없을 듯하며, 엄청 활성화되기 전에는 한글 지원은 요원해 보인다.

이를 사용하기 위해서는 _config.yml 에 관련 옵션을 설정해 줘야 한다.

popularPosts:
  morphologicalAnalysis: 
    negativeKeywordsList: hexo-rpp-negativewords.txt  # (optional) 분석 대상에서 제외할 키워드들을 지정한 파일 경로 지정
    limit: 300              # (optional) 분석에 사용할 키워드의 갯수 제한
  weight:                   # (optional)
    tagRelevancy: 1.0       # (optional) 태그 연관성 가중치 설정. 기본 값 = 1.0
    contentsRelevancy: 1.0  # (optional) 내용의 연관성 가중치 설정. 기본 값 = 1.0

제외 키워드 설정 파일은 한 라인에 하나씩 정규식으로 설정할 수 있다.

^.$
^[0-9]+$
^String to exclude from related keywords$
^関連キーワードから除外しておきたい文字列を正規表現で指定する$
^要从相关关键字排除的字符串$
...

한국어가 지원되지 않으므로 굳이 이 옵션을 사용할 이유가 없다. 그냥 태그만으로 구성해도 충분하다.

Note

예전에 Solr 검색엔진 관련해서 프로젝트를 수행할 때 한글 형태소 분석 엔진을 설정해서 사용한 적이 있다. 나중에 시간이 좀 되면 형태소 엔진을 Hexo 에 연결해서 활용할 수 있는지 검토해 볼 필요가 있을 듯 하다.

Cache (Improve generation speed)

Hexo 에서 블로그 제너레이션을 할 때 성능 향상을 위해서 캐시 설정을 할 수 있다.

popularPosts:
  cache:
    path: hexo-popular-related-posts-cached.json

캐시로 사용할 파일을 지정해 주면 된다.

Log

로그 정보 표시 여부를 설정할 수 있다.

popularPosts:
  log: true  # (Optional) true 가 되면 로그가 표시된다. 기본 값 = true

Customize HTML

직접 설정해 보면 기본으로 지정되는 HTML 이 단순 링크기 때문에 목록 리스트에 대한 HTML 변경을 할 수 밖에는 없으며 popular_posts_json() 헬퍼와 htmlGenerator 레지스터를 사용해야 한다.

아티클 템플릿 파일

<%-
    htmlGenerator( 
        popular_posts_json({ maxCount: 5 , ulClass: 'popular-posts' , PPMixingRate: 0.0 , isDate: true , isImage: true , isExcerpt: true})
    )
%>

테마에 처리를 위한 스크립트 파일을 구성해 줘야 한다.

// Examples of helper
hexo.extend.helper.register('htmlGenerator', function(args){
  if(!args || !args.json || args.json.length == 0)return "";
  var returnHTML = "";
  function generateHTML(list){
    var ret = "";
    ret += "<li class=\"" + args.class + "-item\">";
    if(list.date && list.date != ""){
        ret += '<div class="'+args.class+'-date">' + list.date + "</div>";
    }
    if(list.img && list.img != ""){
        ret += '<div class="'+args.class+'-img">' + '<img src="'+list.img+'" />' + "</div>";
    }
    ret += '<div class="'+args.class+'-title"><h3><a href="' + list.path + '" title="'+ list.title +'" rel="bookmark">'+ list.title + "</a></h3></div>";
    if(list.excerpt &&  list.excerpt != ""){
        ret += '<div class="'+args.class+'-excerpt"><p>' + list.excerpt + "</p></div>";
    }
    ret +=  "</li>";
    return ret;
  }
  for(var i=0; i<args.json.length; i++){
      returnHTML += generateHTML(args.json[i]);
  }
  if(returnHTML != "")returnHTML = "<ul class=\"" + args.class + "\">" + returnHTML + "</ul>";
  return returnHTML;
});

위의 스크립트는 기본 제공되는 HTML 에 날짜, 이미지, 타이틀, 발췌 정보 등을 살짝 추가하는 정도기 떄문에 이 스크립트를 자신이 원하는 HTML 구성으로 모두 변경해 주면 된다.

Important

스크립트가 반영될 수 있도록 실행 중인 Hexo Server를 중지하고 Clean & Generate 를 해줘야 반영된다.

위의 샘플을 응용해서 관련 포스트는 포스트 본문의 위/아래에 배치하고, 인기 포스트는 사이드바의 가장 위에 위치하도록 적용하였다.

연관/인기 포스트 생성 샘플

Visitor Counter

pvMeasurementsStartDate 옵션을 추가로 설정하면 포스트에 페이지 뷰 카운트를 설정할 수 있다. 이 부분도 역시 Google Analytics 설정 를 사용한다. 따라서 아래와 같이 기존에 설정해 놓은 부분에 추가해 주면 된다.

페이지 뷰 측정 기준일자 설정 추가

popularPosts:
  # (optional) Popular posts options
  googleAnalyticsAPI:
    clientId: ******.apps.googleusercontent.com
    serviceEmail: *****@developer.gserviceaccount.com
    key: /hexo-project-root/path/to/google-services.pem
    viewId: 12345678
    dateRange: 30
    expiresDate: 10
    pvMeasurementsStartDate: 2017/04/01

페이지 뷰 렌더링을 위한 템플릿 파일

This post's Visitor Counts is <%- popular_posts_pv() %> views.

위의 샘플을 응용해서 아래와 같이 포스트 타이틀과 작성일자 및 태그 정보 바로 아래에 위치하도록 조정했다.

포스트 페이지 뷰 카운터 샘플

Ranking Sheet

rangkingSheet 옵션을 추가로 설정하면 페이지 뷰의 랭킹 정보를 생성할 수 있다.이 부분도 역시 Google Analytics 설정 를 사용한다. 따라서 아래와 같이 기존에 설정해 놓은 부분에 추가해 주면 된다.

popularPosts:
  # (optional) Popular posts options
  googleAnalyticsAPI:
    clientId: ******.apps.googleusercontent.com
    serviceEmail: *****@developer.gserviceaccount.com
    key: /hexo-project-root/path/to/google-services.pem
    viewId: 12345678
    dateRange: 30
    expiresDate: 10
    pvMeasurementsStartDate: 2017/04/01
    rankingSheet: rankingSheet.txt

Trouble Shootings

플러그인에 UTC 시간 처리에 문제가 있어서 교체 함. (2017.04.21)

플러그인 원본 소스에 UTC 시간 처리 문제 소스를 아래와 같이 변경해야 한다.

// 원본 코드
...
if(options.isDate && list.date != ""){
    ret.date =  moment(list.date._i).format(config.date_format || "YYYY-MM-DD");
...
// 수정 코드
if(options.isDate && list.date != ""){
    ret.date = moment(list.date).format('YYYY-MM-DD');
...

위의 원본에서는 moment에 ._i 값을 기준으로 처리했는데, 이 처리는 moment가 최초 생성되는 시점의 정보를 반영하는 문제가 있는 것으로 보인다. 결과적으로 모든 일자가 동일하게 호출 일자로 반환되는 문제가 생긴다.

따라서 시간을 제외한 일자 정보만 처리하는 경우는 수정된 코드를 사용해야 게시된 일자을 정확하게 표시할 수 있다.

Conclustion

정리해서 노출시킨 글들이 어떻게 읽혀지고, 누가 읽고 있었는지 등이 궁금해서 시작을 했지만, 상업적인 솔루션이나 회사 또는 물건을 광고하는 것이 아니기 때문에 솔직히 Google Analytics 의 모든 기능을 사용하는 것은 아니다.

단지, 글들에 대한 액세스등이 궁금해서 플러그인을 설정하기는 했지만, 아직도 필요성 대비 설정이 너무 많고 모르는 것이 넘치기 때문에 이렇게까지 설정해서 사용해야 하는지에 대한 의문점이 든다.

아마도 아직은 단순 무식해서 정말 그 효과를 몰라서 그럴지도… ㅠㅠ

References
- Github - hexo-related-popular-posts
- Hexo 다양한 플러그인
- Google Analytics 설정

[Kubernetes] 설치 시점에 특정 버전 지정하기

ccambo — Mon, 17 Apr 2017 22:20:46 +0900

Notes

이 문서는 Ubuntu 에 Kubernetes 를 설치할 때 특정 버전의 바이너리를 지정해서 처리하는 방법을 설명하는 것이기 때문에 전체 설치 과정을 다루고 있지 않습니다.

설치에 관련된 문서는 iamartin 님 블로그에 kubeadm을 이용해서 아주 쉽게 Kubernetes 설치하기 에 상세하게 기술되어 있으므로 이 부분을 참고하시면 됩니다. (향후 변경된 사항이나 요청이 있다면 정리된 버전을 추가로 올릴 수도 있습니다)

참고로 Kubernetes 를 설치하는 도구들은 상당히 많이 존재하며 향후 kubeadm 으로 통합될 것으로 개인적인 예상을 하고 있기 때문에 다른 설치 도구에 대한 부분은 따로 정리하지 않고 있습니다.

Kubernetes 특정 버전으로 구성하기

이 문서를 정리한 이유는 Kubernetes가 버전 향상 작업을 수시로 진행하고 있고, 각 종 설치 도구는 latest 버전을 대상으로 운영되고 있기 때문에 솔루션 개발 중이거나 또는 다른 이유로 버전을 고정해야 할 경우가 있을 수 있기 때문입니다.

기본 설치 관련 정보

ubuntu 에서 설치는 초기에 아래와 같이 4 단계의 작업을 거치게 됩니다. 물론 kubeadm을 사용하는 경우는 다른 환경에서도 거의 유사하게 사용됩니다.

Apt Key 생성

$ curl http://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

Kubernetes Source Repository 생성 (데비안 패키지)

cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

Apt Repository 갱신
```
apt-get update
```

필수 프로그램 설치

apt-get install -y docker.io
apt-get install -y kubelet kubeadm kubectl kubernetes-cni

위의 단계를 거치고 나면 Kubernetes 설치에 필요한 기본 패키지들이 준비된 것입니다.

Notes
다운로드한 바이너리들에 대한 특정 버전을 지정하는 방법은 아래의 예와 같이 각 Component 별로 버전 식별 정보를 지정하면 됩니다.
 $ sudo apt-get -y install kubectl=1.5.3-00 kubelet=1.5.3-00 kubernetes-cni=0.3.0.1-07a8a2-00

버전 정보 확인하기

재미있는 부분은 위의 설치 2번째 작업에서 처리한 데비안 패키지의 내용을 아래의 경로에서 확인을 해 보면 최근에 릴리즈된 정보가 다 구성되어 있다는 것으로 위의 소스 리파지토리 설정 정보를 이용해서 아래와 같은 URL 로 패키지 정보 검증이 가능합니다.

Notes
지금까지 발표된 모든 Release가 아니고 최근에 발표된 버전이 기준입니다. 따라서 1.5 이전 버전을 사용해야 하는 상황이라면 이 문서에 정리된 내용은 맞지 않습니다.

$ https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages

아래의 그림은 위의 경로에서 확인한 패키지 정보를 일부 발췌한 내용입니다.

위의 그림에서 박스로 표시한 것처럼 kubelet 이 1.5.1 ~ 1.6.1 까지 구성 (위의 빨간 박스) 되어 있는 것을 볼 수 있으며, 각 구성 요소에 의존적인 다른 패키지의 버전과 관련된 Depends (위의 파란 박스) 정보가 구성된 것을 볼 수 있습니다.

따라서 처음에는 특정 릴리즈 버전의 정보만을 가져오는 것에 대해 검토를 했지만, 위의 정보를 확인하고 나서는 다운로드된 바이너리들을 어떻게 버전을 지정해서 처리하는지에 대한 것만 결정하고 설정하면 됩니다.

kubeadm 초기화할 때 버전 지정

Kubernetes Master Node 의 초기화는 아래와 같은 명령을 기본으로 사용합니다.

kubeadm init

위의 초기화 명령에 사용할 수 있는 다양한 옵션들 중에 Kuberenetes 의 바이너리 구성 버전을 지정할 수 있습니다.

--kubernetes-version: 기본 값은 lastest 로 설정되어 있으며 원하는 Kubernetes 버전을 지정하면 됩니다. 단, 이때 지정할 버전은 릴리즈 페이지 를 참고하면 됩니다.

Kubeadm 자체 버전 문제

위의 Kubernetes 패키지 (xenial main) 에는 kubeadm 1.6.1 만 존재하기 때문에 Kubernetes 1.6 버전만 처리가 가능합니다. 정확하게는 Depends 로 kubelet >= 1.6.0, kubectl >= 1.6.0 제한이 걸려 있기 때문에 1.6.0 또는 1.6.1 로만 구성이 가능합니다.

따라서 현재 상황에서 1.5.1 ~ 1.5.6 까지의 Kubernetes 버전을 구성할 수 없는 상태입니다.

Kubeadm 특정 버전 처리하기

위에서 Kubernetes의 버전 문제라기 보다는 Kubeadm 버전 문제 떄문에 Kubernetes 1.6.0 이전 설정이 안되는 문제를 확인했기 때문에 이번에는 Kubeadm 의 버전을 처리하는 방법으로 설정해야 합니다.

Notes
Kubernetest 1.6.0 을 설정하는 경우는 이 부분을 처리하지 않아도 처리가 가능합니다. Kubernetes 버전 지정으로 진행하시면 됩니다.

아래의 스크립트는 현재 버전 1.6.1 기준으로 특정한 버전 (ex. 1.5.3) 을 설정하기 위해서 kubeadm 을 재 설정하는 것입니다.

$ apt-get update && apt-get install -y apt-transport-https
$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
$ cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
$ apt-get update

# 위의 처리까지는 기존과 크게 다르지 않습니다. 아래부터는 Kubernetes 의 특정한 버전을 지정하는 부분입니다.
$ sudo apt-get -y install kubectl=1.5.3-00 kubelet=1.5.3-00 kubernetes-cni=0.3.0.1-07a8a2-00

# 아래는 Kubernetes 1.5 버전을 처리하기 위해서 kubeadm 을 설정하는 부분입니다.
$ curl -Lo /tmp/old-kubeadm.deb https://apt.k8s.io/pool/kubeadm_1.6.0-alpha.0.2074-a092d8e0f95f52-00_amd64_0206dba536f698b5777c7d210444a8ace18f48e045ab78687327631c6c694f42.deb
$ sudo dpkg -i /tmp/old-kubeadm.deb
$ sudo apt-get install -f

# 아래는 업그레이드되는 것을 방지하기 위해서 버전을 유지하기 위한 것입니다.
sudo apt-mark hold kubeadm kubectl kubelet kubernetes-cni

위의 같이 기본적인 설정 및 바이너리 다운로드는 동일하지만 kubeadm 을 이전 버전으로 다운로드하여 설정하고 버전을 고정하는 방식으로 처리하면 됩니다.

Important
현재 프로젝트를 마무리하고 나온 상태라서 위의 정리된 내용을 실제 검증한 것은 아니기 때문에 다소 내용과 실제가 맞지 않을 수 있습니다. 따라서 환경이 구성된 후에 위의 정리된 내용과 다른 부분은 갱신을 할 예정입니다.

References
- https://gist.github.com/jbeda/5e8a4ce0a23711da146e51900859c037

Written by Morris (ccambo@gmail.com - MSFL)

[VHD] 부트 시점에 VHD 자동 마운트 처리 2 - 스크립트 버전

ccambo — Wed, 12 Apr 2017 14:34:39 +0900

스크립트 방식으로 마운트 및 해제 조정하기

[이전 게시글] 에서 diskpart 를 이용한 작업 스케줄러 처리로 부트 시점에 자동 마운트 처리를 정리 했었다.

막상 실제 사용하는데 몇 가지 불만 사항이 생겨서 스크립트를 사용하는 방식으로 변경해 본다.

여러 개의 VHD 를 마운트 시킬 경우에 Task 를 여러 개 등록하는 문제 (한번에 여러 개 처리하는 방법을 못 찾음. ㅠㅠ)
특정 사용자인 경우만 처리하는 경우 (작업 스케줄러로도 처리는 가능하지만 두가지 방식 혼용이 싫음)
쉽게 추가/변경해서 재 시작 없이도 처리하고 싶음.
그냥 작업 스케줄러가 귀찮음.

위의 같은 이유로 아래와 같이 스크립트 처리를 추가했다. 기본은 diskpart를 이용하는 방식이다.

윈도우에서 스크립트를 처리할 때는 항상 관리자 권한 여부가 상당히 껄끄럽다. 이런 저런 방법들도 많다. 대략적으로는 아마 아래와 같은 형식들이 될 듯 하다.

레지스트리를 조정해서 항상 Cmd.exe 가 관리자 권한으로 실행되도록 한다.
UAC 조정 또는 로그인 사용자를 관리자인 것으로 처리한다.
사용자를 Administrator 로만 사용한다.
…

그런데 이런 저런 시스템 설정을 하기는 싫고 순수하게 스크립트에서만 이를 해결할 수는 없을까?

실행되는 스크립트를 관리자 모드인 것으로 처리하기

이런 저런 자료를 검토하고 나름대로 관리자 모드로 실행 부분을 생각해 보니 의외로 쉽게 할 수 있는 방법이 있다. 그것도 시스템을 건들이지 않고 스크립트 만으로 조정해서 가능하다.

@echo 관리자 권한 검증 >%windir%\admin.confirm

위의 명령은 %windir% (보통 C:\Windows) 경로에 “관리자 권한 검증” 이란 문자열을 출력해서 admin.confirm 이라는 파일을 생성하는 것이다. 당연히 관리자 권한이 없으면 액세스가 거부되었습니다. 라는 오류 메시지를 보게 된다.

이를 이용해서 아래와 같이 관리자 권한을 탈취(?)하는 코드를 생성하면 된다.

@echo 관리자 권한 검증 >%windir%\admin.confirm || @(
echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\admin.vbs"
echo UAC.ShellExecute "%~0", "", "", "runas", 1 >> %temp%\admin.vbs"
wscript.exe "%temp%\admin.vbs" & del "%temp%\admin.vbs" & exit
)

위의 명령은 관리자 권한이 없는 경우에 %temp% (보통 C:\Users\\appdata\local\temp) 에 admin.vbs 라는 파일을 만들고 아래와 같이 UAC 객체를 얻어서 실행하는 명령을 구성해서 wscript.exe 로 관리자 권한으로 실행하도록 하는 것이다.

Set UAC = CreateObject("Shell.Application")
UAC.ShellExecute "cmd_test", "", "", "runas", 1

따라서 관리자 권한을 탈취(?)하고 다시 실행되는 경우에 테스트를 위해서 만들었던 파일들을 삭제하고 나머지를 계속 수행하면 된다.

아래는 실제 작업을 진행한 코드를 보여주는 것이다. (multi_vhd_mount.bat)

@echo off

@title VHD Mount.
@setlocal enabledelayedexpansion

@echo 관리자 권한 확인용 >%windir%\admin.confirm || @(
echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\admin.vbs"
echo UAC.ShellExecute "%~0", "", "", "runas", 1 >> %temp%\admin.vbs"
wscript.exe "%temp%\admin.vbs" & del "%temp%\admin.vbs" & exit
)
@del %windir%\admin.confirm

set list=D:"C:\VMs\Workspace.vhd" E:"S:\VMs\Tools.vhd"

echo Start mounting.

for %%y in (%list%) do (
rem  echo Loop's Data: %%y
  for /F "tokens=1,* delims=: usebackq" %%a in ('%%y') do (
rem  echo Checking for file %%b to assign letter %%a:
    call %~dp0\mount_vhd %%b %%a
  )
)

echo Mounting complete.

@endlocal

list: “Leter:VHDPath” 포맷으로 여러 개를 지정하면 처리 함.
for %%y in (%list%) do: list 에 설정된 값 (’ ’ 값으로 분리됨 예제는 2개) 을 하나씩 %%y 변수로 할당한 루프 처리
for /F “token=1,* delims=: usebackq” %%a in (‘%%y’) do: %%y 값을 문자열 처리하는 double quote(“) 를 제거 (usebackq 옵션) 하고 분리 문자로 “:” 사용해서 분리 (delims=:) 한 결과들 중에서 첫번째와 나머지 (token=1,*) 인 두개로 반환반환하기 때문에 %%a 는 첫 번째 결과가 %%b는 선언하지 않아도 나머지가 배정된다.

당연한 말이지만 위의 call mount_vhd %%b %%a 를 call unmount_vhd %%b 로 하면 해제 처리 가능하다.

이제 관리자 권한을 탈취해서 실행되는 스크립트를 만들었으니 내부에서 호출되는 스크립트들을 확인해 보도록 하자.

마운트 스크립트 (mount_vhd.cmd)

아래 스크립트는 VHD 를 diskpart 명령을 사용해서 처리하는 스크립트다. 중간 중간에 테스트를 위해 사용한 echo 명령은 제거해도 된다. 물론 diskpart 스크립트 파일 생성을 위한 부분은 남겨둬야 한다.

@echo off

if {%1}=={} (
    echo Usage: %~nx0 [vhd full path] [letter]
    exit /b 1
)
set vhdPath=%~dpnx1
set driveLetter=%2

if {%driveLetter%}=={} (
    echo Mounting %vhdPath%
) else (
    echo Mounting %vhdPath% to %driveLetter%:
)

REM
REM create dispart script
REM
set diskPartScript=%~nx0.diskpart
echo sel vdisk file="%vhdPath%">%diskPartScript%
echo attach vdisk>>%diskPartScript%

REM assign the drive letter if requested
if not {%driveLetter%}=={} (
    echo select partition 1 >>%diskPartScript%
    echo assign letter=%driveLetter%>>%diskPartScript%
)

REM Show script
echo.
echo Running diskpart script:
type %diskPartScript%

REM
REM diskpart
REM
diskpart /s %diskPartScript%
del /q %diskPartScript%

echo Done!

%1: 첫 번째 파라미터, 없으면 사용방법 출력
%2: 두 번째 파라미터
~nx0: 실행하고 있는 cmd 파일 명
%~dpnx1: 첫 번째 파라미터의 경로를 포함한 값
%..%: set 으로 설정된 것 포함 환경변수 값

해제 스크립트 (unmount_vhd.cmd)

아래 스크립트는 마운트해서 사용한 VHD 를 연결 해제하는 스크립트다.

@echo off

if {%1}=={} (
    echo Usage: %~nx0 [vhd full path]
    exit /b 1
)
set vhdPath=%~dpnx1

echo Unmounting %vhdPath%

REM
REM create dispart script
REM

set diskPartScript=%~nx0.diskpart
echo sel vdisk file="%vhdPath%">%diskPartScript%
echo detach vdisk>>%diskPartScript%

REM
REM diskpart
REM

diskpart /s %diskPartScript%
del /q %diskPartScript%

echo Done!

자동 실행 등록

수동으로 실행을 해도 되지만, 작업 스케줄러를 이용해도 되고, 아래에서 확인해 볼 것처럼 시작 프로그램으로 등록해 놓고 사용해도 된다.

시작 프로그램 폴더 사용

개별 사용자: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup
모든 사용자: %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup

위의 폴더 중에서 원하는 위치에 작성한 스크립트를 복사해 놓으면 된다. (단, 내부에서 사용한 다른 호출 스크립트 경로를 조정해 줘야 한다)

레지스트리 기준 시작 프로그램 등록

레지스트리 편집기 (regedit)를 열고 아래의 키 들 중에 원하는 위치로 이동한다.

개별 사용자: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
모든 사용자: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

해당 키 하위로 새로운 문자열 키 를 생성하고 이름은 원하는데로 설정하고, 데이터는 실행할 배치 파일을 전체 경로를 설정하면 된다.

Conclustion

Notes

배치는 잠시지만 명령 창이 나타났다 사라진다. 차라리 길게 보이면 그럭저럭 넘길텐데, 후다닥 지나가면 뭔가 오류가 발생한 느낌이 나기 때문에 심하게 싫다.

이런 경우라면 아래와 같이 VBS 처리를 해주면 보이지 않게 된다. 아래 코드에서 <실행할 Command 파일> 를 위에서 만든 스크립트 파일 전체 경로로 바꿔야 한다.
Set WinScriptHost = CreateObject( "WScript.shell" )
WinScriptHost.Run Chr(34) & <실행할 Command 파일> & Chr(34), 0
Set WinScriptHost = Nothing
위와 같이 처리를 해서 이 VBS 파일을 위에 자동 실행 등록으로 처리하면 정신적으로 위로(?)가 된다.

역시 뭔가 자꾸 바꾸고 테스트하는 것은 스크립트를 활용하는 것이 좋다. 물론 한번 설정하고 안 바꿀 거라면 작업 스케줄러도 나쁘지는 않다. 단, 적응이 안되니 그냥 뭔가 귀찮고 싫을 뿐이다.

배치 파일, VHD 관련 정보는 고수님들이 친절하게 설명한 글이 무수하게 많으니 꼭 찾아서 읽어보는 것이 좋다.

Written by Morris (ccambo@gmail.com - MSFL)

[VHD] 부트 시점에 VHD 자동 마운트 처리 1 - Task Scheduler 버전

ccambo — Tue, 11 Apr 2017 12:36:23 +0900

How to Auto-mount a VHD at startup in Windows 8 and 10

데이터 백업과 관리는 항상 중요하다. 프로젝트의 경우는 더욱 더 중요하다. 소스관리는 Git 등을 이용해서 관리를 하면 되지만, Open source 검토나 개인적인 문서 등의 자료는 딱히 편한 방법을 찾지 못해서 Sync 툴들을 사용하던 방법을 VHD 파일 단위로 구별해서 관리하고 주기적으로 VHD 파일을 백업하는 방법을 적용해 보려하니 매 부팅마다 마운트해 주는 것이 또 답답하다.

이런 저런 관런 자료를 찾다보니 괜찮은 (쉬운?) 방법이 있어서 정리해 놓도록 한다.

General Steps

Project 등의 구별로 VHD(x) 파일을 생성한다.
마운트 처리할 Diskpart 스크립트 파일을 생성한다.
작업 스케줄러에 부트 타임 스케줄을 구성한다.
3.1. 보안 옵션에서 로그인과 상관없이 실행 선택
3.2. 트리거 생성 후 동작 옵션을 프로그램 시작으로 설정
3.3. 작업 지연 시간 1분으로 설정
3.4. 동작 새로 만들기 후 프로그램/스크립트에 diskaprt 설정
3.5. 인수 추가 옵션에 2.번에서 만든 /s 스크립트 파일 지정
3.6. 전원옵션에 AC 전원이 켜져있는 경우만 작업 시작 옵션 해제
3.7. 사용자 보안 정보 입력
PC 재 부팅으로 정상 동작 여부를 검증한다.

Detail View

diskpart에 옵션으로 지정할 스크립트 파일이므로 확장자는 상관없이 지정해도 된다.

select vdisk file="C:\test.vhd"
attach vdisk
assign letter=D

select vdisk: 실제 마운트할 VHD 파일 경로를 문자열로 지정한다.
assign: 연결할 드라이브 레터를 지정한다.

위의 스크립트를 저장한다. 이 샘플에서는 S:\VMs\Scripts\AutoMount.txt 이름으로 저장했다.

윈도우키 + R 을 눌러서 작업 스케줄러를 실행한다. (윈도우 10 이라면 Windows 검색 창에서 작업으로 검색 가능)

작업 스케줄러에서 아래와 같이 작업 만들기를 실행해서 기본 정보를 설정한다.

사용자 로그인과 상관없이 무조건 처리할 것으로 설정하면 된다.

트리거 탭으로 이동해서 작업 시간 설정을 한다.

작업 탭으로 이동해서 실제 구동될 프로그램 (diskpart) 과 위에서 저장했던 스크립트 파일을 지정한다.

만일 스크립트를 저장한 경로에 ' ' 문자가 있는 경우라면 반드시 ""로 문자열 처리를 해줘야 한다.

조건 탭으로 이동해서 기본 설정되어 있는 AC 전원 관련 옵션을 해제한다.

마지막으로 "확인" 버튼을 누르면 사용자 계정 확인을 하게 되므로 정보를 입력한다.

Conclusion

이제 부팅 시점에 VHD 를 마운트하는 작업이 등록되었으므로 실제 부팅을 통해서 작업이 잘 처리되는지를 확인하면 된다.

Notes

단, 만일 보안 상의 이유로 Bitlocker가 걸려 있거나 또는 디스크가 압축 설정이 되어 있는 경우는 VHD 를 마운트할 수 없으므로 관련된 상황을 확인해야 한다.

References

https://www.eightforums.com/tutorials/20342-vhd-auto-mount-startup-windows-8-a.html

Written by Morris (ccambo@gmail.com - MSFL)

Console 인코딩 변경하기

ccambo — Thu, 6 Apr 2017 11:15:25 +0900

Console/Cmd 에서 인코딩 변경하기

Markdown 문서를 HTML 문서로 변경을 하는데 Universal Document Converter 인 Pandoc 을 사용해서 작업 중인데 Command Console 에서 뜬금없이 모든 한글이 깨져서 나오는 증상이 발생했다.

발생 원인

문제의 발생은 모든 Markdown 문서와 코드들을 UTF-8 기준으로 작업을 했지만 Command Console 은 Windows 기본 인코딩인 949 를 사용하기 때문에 변환했을 때 문자열이 깨진다.

해결 방법

문제의 해결은 은근 간단하다.

# 영문 모드로 변경
> chcp 437
# 한글 모드로 변경
> chcp 949
# UTF-8 모드로 변경
> chcp 65001

예외 사항

만일 위의 명령을 실행했을 때 잘못된 코드 페이지 라는 메시지가 출력될 경우는 윈도우 10 버전일 경우는 제어판 > 국가 또는 지역 > 관리자 옵션 탭 에서 유니코드를 지원하지 않는 프로그램용 언어 부분에서 시스템 로캘 변경 버튼을 눌러 언어를 선택하면 된다. 만일 다른 윈도우 버전이라면 위와 유사한 메뉴가 있을 것이므로 찾아보고 처리하면 될 듯 하다.

참고 사항

Console 창의 타이틀 메뉴에서 속성을 통해서 폰트와 여러 가지 속성을 설정할 수 있다.
폰트는 다른 방식으로 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont 에서 코드 페이지 값에 맞는 키 (ex. 949, REG_SZ, 돋움)를 생성해서 사용할 폰트를 설정해도 된다.
Unix 또는 Linux 에서는 /etc/my.conf 파일에 default-character-set=utf8을 설정해서 인코딩을 변경하면 된다고 하는데 사용 환경이 아니라서 검증은 해 보지 못했다.
MYSQL 을 사용하는 경우라면 MYSQL command 창에서 set character set euckr; 명령으로 클라이언트 인코딩을 변경해서 설정할 수 있다. (기본 값은 utf-8)

Written by Morris (ccambo@gmail.com - MSFL)

[Markdown] 특수문자들을 정리해 보자!

ccambo — Wed, 5 Apr 2017 12:11:05 +0900

마크다운으로 문서를 정리할 때 가끔 또는 자주 예약된 문자 처리 때문에 난처한 경우가 발생한다.

이 내용을 정리하게 된 것도 마크다운 테이블을 구성하는데 예약어 ('|') 문자 때문이다. 일반적으로 'pipe' 또는 'vertialcal bar' 라고 표현하는 문자인데 테이블을 구성하는 예약어다.

마크다운 문법에서 설명하는 것과 같이 여러 가지 방법을 적용해 봤지만 적용되지 않는다.

해결 방법은 의외로 쉽다. 마크다운이 결국 렌더링되서 HTML 로 표현되는 것이기 때문에 아예 HTML 문자를 사용하면 된다.

아래의 표는 참조한 사이트에서 필요한 몇 가지만 발췌한 것이므로 참고 사이트에서 전체 내용을 확인하면 된다.

Symbol	HTML Number	HTML Name	Description
`!`	!		exclamation point
`"`	"	"	double quotes
`#`	#		number sign
`$`	$		dollar sign
`%`	%		percent sign
`&`	&	&	ampersand
`'`	'		single quote
`(`	(		opening parenthesis
`)`	)		closing parenthesis
`*`	*		asterisk
`+`	+		plus sign
`,`	,		comma
`-`	-		minus sign - hyphen
`.`	.		period
`/`	/		slash
`:`	:		colon
`;`	;		semicolon
`<`	<	<	less than sign
`=`	=		equal sign
`>`	>	>	greater than sign
`?`	?		question mark
`@`	@		at symbol
`[`	[		opening bracket
`\`	\		back slash
`]`	]		closing bracket
`^`	^		caret - circumflex
`_`	_		underscore
`	`		grave accent
`{`	{		opening brace
\|	\|		vertical bar - pipe
`}`	}		closing brace
`~`	~		equivalency sign - tilde
`-`	–		en dash

관련된 문자를 찾고 싶어도 용어를 몰라서 못 찾는 것은 이제 그만!!!

References

http://www.ascii.cl/htmlcodes.htm

Written by Morris (ccambo@gmail.com - MSFL)

Node.js 관련 패키지들 정리 (갱신중)

ccambo — Tue, 4 Apr 2017 19:45:37 +0900

다른 작업을 진행하다가 정말로 오랜만에 다시 Node.js 관련 오픈 소스 분석 작업을 하는데 참조하고 있는 패키지들이 많기도 하다. 아는 것보다는 모르는 것이 더 많아서 뭐가 뭔지 하나도 모르겠다.

앞으로 작업을 하면서 좀 더 다양한 패키지들을 자세하게 알아야 하지만, 당장은 제목과 기능이라도 알아야 이해를 할 수 있을 듯 하다. ㅠㅠ

Packages for NodeJS

bluebird

Full featured promise library with unmatched performance

Examples

설치
```
npm install bluebird
```
활용법
```
var Promise = require("bluebird");
```

References

bunyan

Simple and fast JSON Logging Module for node.js services

Examples

설치
```
$ npm install bunyan
```

활용법


var bunyan = require('bunyan');
var log = bunyan.createLogger({name: "myapp"});
log.info("hi");

References

https://github.com/trentm/node-bunyan

camelcase

Convert a dash/dot/underscore/space separated string to camelCase: foo-bar -> fooBar

Examples

설치
```
$ npm install --save camelcase
```

활용법


const camelCase = require('camelcase');

camelCase('foo-bar');       //=> 'fooBar'
camelCase('foo_bar');       //=> 'fooBar'
camelCase('Foo-Bar');       //=> 'fooBar'
camelCase('--foo.bar');     //=> 'fooBar'
camelCase('__foo__bar__');  //=> 'fooBar'
camelCase('foo bar');       //=> 'fooBar'
camelCase('foo', 'bar');        //=> 'fooBar'
camelCase('__foo__', '--bar');  //=> 'fooBar'

console.log(process.argv[3]);   //=> '--foo-bar'
camelCase(process.argv[3]);     //=> 'fooBar'

References

https://github.com/sindresorhus/camelcase

chai

BDD (Behavior-Driven Development) / TDD (Test-Driven Development) Assersion Library for Node

Examples

설치
```
$ npm install bunyan
```

활용법


// Should
chai.should();

foo.should.be.a('string');
foo.should.equal('bar');
foo.should.have.lengthOf(3);
tea.should.have.property('flavors').with.lengthOf(3);

// Expect
var expect = chai.expect;

expect(foo).to.be.a('string');
expect(foo).to.equal('bar');
expect(foo).to.have.lengthOf(3);
expect(tea).to.have.property('flavors').with.lengthOf(3);

// Assert
var assert = chai.assert;

assert.typeOf(foo, 'string');
assert.equal(foo, 'bar');
assert.lengthOf(foo, 3)
assert.property(tea, 'flavors');
assert.lengthOf(tea.flavors, 3);

References

http://chaijs.com/

chalk

Terminal String Styling done right

Examples

설치
```
$ npm install chalk
```

활용법


const chalk = require('chalk');
console.log(chalk.blue('Hello world!'));

References

https://github.com/chalk/chalk

chokidar

A neat wrapper around node.js fs.watch / fs.watchFile / fsevents.

Examples

설치
```
$ npm install chokidar --save
```

활용법


var chokidar = require('chokidar');

// One-liner for current directory, ignores .dotfiles
chokidar.watch('.', {ignored: /(^|[\/\\])\../}).on('all', (event, path) => {
  console.log(event, path);
});
// Example of a more typical implementation structure:

// Initialize watcher.
var watcher = chokidar.watch('file, dir, glob, or array', {
  ignored: /(^|[\/\\])\../,
  persistent: true
});

// Something to use when events are received.
var log = console.log.bind(console);
// Add event listeners.
watcher
  .on('add', path => log(`File ${path} has been added`))
  .on('change', path => log(`File ${path} has been changed`))
  .on('unlink', path => log(`File ${path} has been removed`));

// More possible events.
watcher
  .on('addDir', path => log(`Directory ${path} has been added`))
  .on('unlinkDir', path => log(`Directory ${path} has been removed`))
  .on('error', error => log(`Watcher error: ${error}`))
  .on('ready', () => log('Initial scan complete. Ready for changes'))
  .on('raw', (event, path, details) => {
    log('Raw event info:', event, path, details);
  });

// 'add', 'addDir' and 'change' events also receive stat() results as second
// argument when available: http://nodejs.org/api/fs.html#fs_class_fs_stats
watcher.on('change', (path, stats) => {
  if (stats) console.log(`File ${path} changed size to ${stats.size}`);
});

// Watch new files.
watcher.add('new-file');
watcher.add(['new-file-2', 'new-file-3', '**/other-file*']);

// Get list of actual paths being watched on the filesystem
var watchedPaths = watcher.getWatched();

// Un-watch some files.
watcher.unwatch('new-file*');

// Stop watching.
watcher.close();

// Full list of options. See below for descriptions. (do not use this example)
chokidar.watch('file', {
  persistent: true,

  ignored: '*.txt',
  ignoreInitial: false,
  followSymlinks: true,
  cwd: '.',

  usePolling: true,
  interval: 100,
  binaryInterval: 300,
  alwaysStat: false,
  depth: 99,
  awaitWriteFinish: {
    stabilityThreshold: 2000,
    pollInterval: 100
  },

  ignorePermissionErrors: false,
  atomic: true // or a custom 'atomicity delay', in milliseconds (default 100)
});

References

https://github.com/paulmillr/chokidar

escape-string-regexp

Escape RegExp Special Characters

Examples

설치


$ npm install --save escape-string-regexp

활용법


const escapeStringRegexp = require('escape-string-regexp');

const escapedString = escapeStringRegexp('how much $ for a unicorn?');
//=> 'how much \$ for a unicorn\?'

new RegExp(escapedString);

References

https://github.com/sindresorhus/escape-string-regexp

eslint

Pluggable Linting utility for JavaScript and JSX

Examples

설치
```
$ npm install eslint
```

활용법


Rule 정의 파일 구성
$ npm run eslint .

References

http://eslint.org/

graceful-fs

drop-in replacement for the fs module, making various improvements.

Examples

설치
```
$ npm install graceful-fs
```

활용법


// use just like fs
var fs = require('graceful-fs')

// now go and do stuff with it...
fs.readFileSync('some-file-or-whatever')

//
// Global Patching
//

// Make sure to read the caveat below.
var realFs = require('fs')
var gracefulFs = require('graceful-fs')
gracefulFs.gracefulify(realFs)

References

https://www.npmjs.com/package/graceful-fs

istanbul

JS Code Coverage tool written in JS

Examples

설치
```
$ npm install -g istanbul
```
활용법
```
$ istanbul cover test.js
```

References

https://github.com/gotwarlost/istanbul

jscs

Javascript Code Style Checker

Examples

설치
```
$ npm install jscs  
```
활용법
```
$ jscs file.js --preset=airbnb
```

References

http://jscs.info/

minimist

guts of optimist's argument parser without all the fanciful decoration

Examples

설치
```
$ npm install minimist
```

활용법


var argv = require('minimist')(process.argv.slice(2));
console.dir(argv);

References

https://github.com/substack/minimist

mocha

Fun, Simple, Flexible Javascript Test Framework

Examples

설치
```
$ npm install mocha
```

활용법


Assert 파일 작성
$ mocha test/index.js

References

nyc

Istanbul command line interface

Examples

설치
```
$ npm i nyc --save-dev
```

활용법

package.json script 설정


{
  "script": {
    "test": "nyc tap ./test/*.js"
  }
}

실행


$ nyc npm test
$ nyc --reporter=lcov --reporter=text-lcov npm test

References

require-dir

Node.js 지원을 위해 지정한 디렉터리 단위로 존재하는 파일들을 일괄 require() 처리

Examples

설치
```
$ npm install require-dir
```

활용법


var requireDir = require('require-dir');
var dir = requireDir('./path/to/dir');
var dir = requireDir('./path/to/dir', {recurse: true});

References

https://github.com/aseemk/requireDir

rewire

Easy monkey-patching for node.js unit tests

Examples

설치
```
$ npm install rewire
```

활용법


자세한 활용법은 아래 사이트 설명 참조

References

https://github.com/jhnns/rewire

shelljs, shelljs/shx

shelljs: Portable Unix shell commands for Node.js shelljs/shx: Portable Shell Commands for Node.js

Examples

설치


$ npm install shelljs
$ npm install shelljs/shx   # for command line

활용법 (shelljs)


var shell = require('shelljs');

if (!shell.which('git')) {
  shell.echo('Sorry, this script requires git');
  shell.exit(1);
}

// Copy files to release dir
shell.rm('-rf', 'out/Release');
shell.cp('-R', 'stuff/', 'out/Release');

// Replace macros in each .js file
shell.cd('lib');
shell.ls('*.js').forEach(function (file) {
  shell.sed('-i', 'BUILD_VERSION', 'v0.1.2', file);
  shell.sed('-i', /^.*REMOVE_THIS_LINE.*$/, '', file);
  shell.sed('-i', /.*REPLACE_LINE_WITH_MACRO.*\n/, shell.cat('macro.js'), file);
});
shell.cd('..');

// Run external tool synchronously
if (shell.exec('git commit -am "Auto-commit"').code !== 0) {
  shell.echo('Error: Git commit failed');
  shell.exit(1);
}

활용법 (shelljs/shx)


# used in command line using shx
$ shx mkdir -p foo
$ shx touch foo/bar.txt
$ shx rm -rf foo

References

sinon

Standalone test spies, stubs and mocks for Javascript. work with any unit testing framework.

Examples

설치
```
$ npm install sinon
```

활용법


자세한 활용법은 아래 사이트 설명 참조

References

http://sinonjs.org/

standard

Javascript 표준 스타일 가이드 with Linter & Automatic code fixer

Examples

설치
```
$ npm install standard --save-dev
```

활용법


$ standard
Error: Use JavaScript Standard Style
  lib/torrent.js:950:11: Expected '===' and instead saw '=='.
$ standard "src/util/**/*.js" "test/**/*.js"

References

tildify

Convert an absolute path to the tilde path: /Users/sindresorhus/dev to ~/dev

Examples

설치
```
$ npm install --save tildify
```

활용법


const tildify = require('tildify');

tildify('/Users/sindresorhus/dev');
//=> '~/dev'

References

https://github.com/sindresorhus/tildify

yargs

Yargs helps you build interactive command line tools by parsing arguments and generating an elegant user interface

Examples

설치
```
$ npm install yargs
```

활용법


#!/usr/bin/env node

require('yargs')
  .usage('$0 <cmd> [args]')
  .command('hello [name]', 'welcome ter yargs!', {
    name: {
      default: 'default name'
    }
  }, function (argv) {
    console.log('hello', argv.name, 'welcome to yargs!')
  })
  .help()
  .argv

자세한 활용법은 아래 사이트 설명 참조

References

Written by Morris (ccambo@gmail.com - MSFL)

Divide by Zero === Exception?? Really??

ccambo — Tue, 28 Mar 2017 12:29:36 +0900

Divide by Zero === Exception?? Really?

흔히 산술연산을 처리할 때 0으로 나누면 Divide by Zero Exception 이 발생한다고 알고 있다. 실제 연산 샘플을 구성해 봐도 실제 Exception 이 발생한다.

public static void main (String[] args) throws java.lang.Exception
{
    int aa = 100 / 0;
}

위의 코드는 Exception in thread "main" java.lang.ArithmeticException: / by zero 예외가 발생한다.

정말 모든 산술 연산이 이렇게 적용될까??? Really??

책이나 관련된 정보를 찾아보면 보통 정수를 0으로 나누면 이라는 전제 조건이 있다.

그럼 정수가 아닌 경우는 어떻게 될까?

0 이 아닌 부동 소수점 값을 0 으로 나누면 부호 있는 Infinity 가 되고 예외는 발생하지 않는다.
- 1.0 / 0.0 은 Positive-Infinity 가 된다.
- -1.0 / 0.0 은 Negative-Infinity 가 된다.
0 이 아닌 정수를 정수 0 으로 나누면 ArithmeticException 이 발생한다.

음!! 위와 같이 정리할 수 있다.

그런데 0.0 / 0.0 은 뭐가 나올까?

결론은 isNaN 상태가 된다. 즉, 연산 불가라고 봐야 한다.

이런 상황은 실제 변수나 VO 등에 Assign 할 경우에는 예외가 없으니 큰 문제가 없지만 JSON 으로 변환하는 등의 작업을 진행하면 뜬금없이 "Infinity", "isNaN" 과 같은 값을 만나게 된다.

어디서 저런 값이 나오는지 모르겠다.
내가 만든 코드에서는 문자열 처리한 적이 없다.
문자열이 Float, Double,.. 등의 자료형에 입력되면 오류가 발생하기 때문에 내가 만든 코드 문제가 아니다.
...

대략 이런 반응들이 나올 듯 하다. ㅠㅠ

그럼 아래과 같은 코드는 어떤 결과를 보여줄까? 예외는 발생할까?

public static void main (String[] args) throws java.lang.Exception
{
    Float aa = 100.0F / 0F;
    Double bb = 100.0D / 0D;
    int cc = (int)(100.0F / 0);
}

결과를 한번씩 확인해 보면 위에서 정리한 내용을 알 수 있고 결과 값을 보면 왜???..... 또 다른 미지의 세계로 검색을 떠나게 될 것이다. ^^

이를 기반으로 다양한 상황에 적용해서 오류 없는 코드를 만들어 보도록 하자.!!!

References

- http://www.w3resource.com/java-tutorial/java-arithmetic-operators.php

Written by Morris (ccambo@gmail.com - MSFL)

[SecureShell] Profile 리스트 정렬하기

ccambo — Sat, 4 Mar 2017 14:38:53 +0900

SecureShell Profile List 정렬하기

AWS, Azure 등의 클라우드 연결에 Chrome Extension인 ScureShell을 이용하고 있다. 이런 저런 연결을 관리하다가 보면 어느새 Profile 순서가 엉망이다. 리스트에서 찾는것도 지겹고 해서 여러 가지 키워드로 검색을 해 보니 결국 수동으로 정리를 하는 방법뿐이 없었다.

우선 간단하게 Profile id 기준으로 정렬은 다음과 같이 처리하면 된다.

(function(){
    var list = nassh_.prefs_.get('profile-ids');
    list = list.slice(0);
    var out = [];

    var doprofile = function(){
        var id = list.pop();
        console.log(id);

        if(id){
            var p = nassh_.prefs_.getProfile(id);
            out.push({k: id, v: p.prefRecords_.description.currentValue});
            doprofile();
        } else {
            out.sort(function(a,b){
                    if (a.v < b.v) return -1;
                    if (a.v > b.v) return 1;
                    return 0;
            });
            for(var i=0;i<out.length;i++){
                out[i] = out[i].k;
            }
            if(out.length){
                nassh_.prefs_.set('profile-ids', out);
                console.log('done')
            } else {
                console.log('result empty, please refresh the page and try again.');
            }
        }
    };
    doprofile();
})();

위의 스크립트 함수를 Ctrl + Shift + J 를 사용해서 스크립트 콘솔을 열고 붙여넣고 실행하면 된다.

Written by Morris (ccambo@gmail.com - MSFL)

MSFL{ccambo}

Kubernetes 확장인 CRD와 CR 에 대한 개념 정리

Kubernetes의 확장인 CRD Custom Resource Definition 와 CR Custom Resource 에 대한 개념 정리

Kubernetes의 기본적 동작 원리

Kubernetes 확장을 위한 CRD 와 CR, 그리고 Operator

실제 사례로 바라보기

[kubernetes-troubleshooting] Namespace 삭제 명령에도 삭제되지 않는 Pod 삭제하기

How to force deletion of pods on namespace

문제 상황

문제 원인 확인과 처리 방법

[Kubernetes-Storage] 정상적으로 동작하던 Dynamic NFS Provisioner 오류 해결하기 (SelfLink 관련)

정상적으로 동작하던 Dynamic NFS Provisioning에서 오류가 발생하는 문제 해결

상황

원인

해결 방법

참고 자료

[Kubernetes] kubeadm 으로 ContainerD 기반 K8S Cluster를 CentOS 8 설치하기 (Docker 사용하지 않음)

Docker를 사용하지 않고 Containerd 기반의 Kubernetes Cluster를 CentOS 8 에 kubeadm으로 설치하기

공통 설정

마스터 노드 설정

워커 노드 설정

Dashboard 설치

Helm 3 설치

Metrics Server 설치

참고 자료

[MacOS] 특정 경로 밑의 디렉터리 일괄 삭제하기

How to remove directories from Mac

[MacOS] Terminal 에서 zsh compinit: insecure directories 문구가 발생하는 경우 대처하기

How to set compinit mode on zsh

참고 자료

[MacOS,Git] ._, .DS_Store 등 숨김파일 정리 및 .gitignore 처리하기

How to remove temporary hidden files like .DS_Store / ._xxxx

Remove ._xxxx files

Git에서 MacOS의 불필요 파일들 제외하기

참고

참고 자료

[Kubernetes-Troubleshooting] 삭제되지 않는 Namespace 강제로 삭제하기

How to force deletion of a namespace

문제 상황

문제 원인

참고

해결 방법

주의

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 3: Bootstrap 삭제 및 서비스 중단 없이 Scale Up/Down 처리

How to building real world sample step by step - Part 3

게시글 참고

Cleanup bootstrap node

참고

Add service for connect from client

Scale up/down without service interruption

Process syncronization before shuting down nodes

참고

Conclusion

참고 자료

[Kubernetes - Operator] KUDO를 활용한 Galera Operator 단계별로 적용하기 - PART 2: Nodes 참여와 서비스 생성 및 StatefulSet 구성

How to building real world sample step by step - Part 2

게시글 참고

Cluster에 참여하는 Node를 위한 초기 설정 구성

참고

주의

참고

Cluster에 참여하는 Node들이 연결할 Service 구성

Cluster에 참여할 Node 구성을 위한 StatefulSet 설정

주의

Conclusion

참고 자료

[Kubernetes-Storage] CentOS 8에 Dynamic NFS Client Provisioner 구성하기

[Kubernetes - Storage] How to configure a dynamic storage provisioner for Kubernetes using a network file system on CentOS 8

참고

Network file system 구성

Service Account 생성

ClusterRole 생성

ClusterRoleBinding 생성

NFS Client Provisioner 생성

StorageClass 생성

Statefulset 생성 및 PV 검증

Dynamic Provisioner Pod 실행 상태 확인

주의

PVC (Persistent Volume Claim)를 통한 PV 생성 검증

참고

Remove `._xxxx` files