Kubeflow – Jupyter Notebooks 살펴보기

Kubeflow 주피터 노트북 살펴보기

주피터 노트툭은 데이터 과학자 뿐만 아니라, 데이터 엔지니어에게도 중요한 도구입니다. Kubeflow의 주피터 노트북은 컨테이너 기반이라서 격리된 환경을 제공합니다. 그래서 텐서플로우(TensorFlow), 파이토치(PyTorch), MXNet 같은 머신러닝 프레임워크를 간섭없이 사용할 수 있습니다. 그리고 쿠버네티스 기반에서 작동하기 때문에 CPU와 GPU 같은 리소스를 보다 효율적으로 사용할 수 있습니다.

Kubeflow는 데이터 과학자들이나 데이터 팀 같은 사용자가 작업을 실행할 수 있는 고유한 네임스페이스를 부여 할 수 있습니다. 이 네임스페이스는 보안과 리소스를 격리하는데 사용할 수 있습니다. 쿠버네티스 리소스 할당량을 사용하여, 플랫폼 관리자는 개인이나 팀에게 사용할 수 있는 리소스 양을 제한 할 수 있습니다.

Kubeflow에서 제공하는 주피터 노트북은 클러스터에서 직접 주피터 인스턴스를 생성할 수 있습니다. 그리고 생성된 주피터 인스턴스는 인증 및 접근 제어가 잘 통합되어 있기 때문에, 허락된 사용자가 아니면 접근할 수 없습니다.

주피터 노트북 생성하기

Kubeflow가 설치되었다면, 사용자는 Kubeflow의 중앙 대시보드를 활용하여 노트북을 실행할 수 있습니다.

왼쪽 메뉴에서 “Notebook Servers”를 클릭하여, 노트북 서비스 화면으로 이동할 수 있습니다.

노트북 서비스 화면으로 이동하면, 현재 선택된 네임스페이스 안에 생성된 노트북 서버 목록을 볼 수 있습니다.

“NEW SERVER” 버튼을 클릭하면, 새로운 노트북 서버의 생성 정보를 입력할 수 있는 페이지가 나타납니다.

“Name” 필드에 원하는 노트북 서버의 이름을 입력할 수 있습니다. 이름은 문자와 숫자를 사용 할 수 있고, 공백은 사용할 수 없습니다.

“Namespace” 필드에는 현재 선택되어 있는 네임스페이스 이름이 기본적으로 입력되어 있습니다.

“Image” 필드는 노트북 서버에서 사용할 주피터 컨테이너 이미지를 선택할 수 있습니다. 미리 제공되는 기본 이미지를 사용할 수도 있고, 사용자가 만든 커스텀 이미지도 사용할 수 있습니다.

다음은 미리 제공되는 기본 이미지 화면입니다.

기본 이미지 목록에는 텐스플로우 1.15.2 버전과 2.1.0이 포함된 노트북을 제공하고 있으며, CPU 버전과 GPU 버전을 나누어서 제공하고 있습니다.

GPU 이미지 사용하려면, 두 가지 조건이 만족되어야합니다.

첫번째는 Kubeflow가 설치된 쿠버네티스 클러스터에서 GPU를 사용할 수 있어야 합니다.

다음 명령어를 실행하면 쿠버네티스 클러스터에서 사용 가능한 nvidia GPU 갯수를 조회할 수 있습니다.

kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\\.com/gpu"

사용 가능한 GPU 리소스가 있다면, 다음과 같은 응답 결과를 얻을 수 있습니다.

NAME     GPU
mortar   1

두번째는 입력 양식의 맨 아래에 있는 “GPUs” 부분에서 GPU를 할당해 주어야합니다. 당연히 사용 가능한 GPU가 있어야만 합니다.

커스텀 이미지 옵션을 선택하면, 사용할 이미지 주소를 직접 입력할 수 있습니다. 이미지 주소 형식은 “registry/image:tag” 입니다. 주피터 노트북의 커스텀 이미지를 생성하는 방법은 뒤에 나오는 “주피터 노트북 커스텀 이미지 생성하기“를 참고하시기 바랍니다.

참고로 Kubeflow에서 기본으로 제공하는 주피터 노트북 이미지는 https://console.cloud.google.com/gcr/images/kubeflow-images-public/GLOBAL 에서 조회해 볼 수 있습니다.

“CPU / RAM” 부분에서는 노트북 서버가 사용할 CPU와 메모리를 지정할 수 있습니다.

“Workspace Volume” 부분에서는 노트북 서버에서 사용할 개인 작업 공간 볼륨을 지정할 수 있습니다. Kubeflow는 쿠버네티스의 PV(영구 볼륨 : Persistent Volume) 사용하여 작업 공간 볼륨을 할당합니다. PV는 노트북 서버가 삭제되더라도 남아있기 때문에, 데이터를 유지할 수 있습니다.

“Type” 필드는 새로운 PV를 만들지, 기존에 존재하는 PV를 사용할지를 선택할 수 있게 해줍니다. “New”는 새로운 PV 생성을 의미하며, “Exsiting”은 기존 PV를 사용하다는 것을 의미합니다.

“Name” 필드는 PVC(PersistentVolumeClaim)의 이름입니다. 노트북 서버가 생성될 때, 해당 이름으로 PVC가 생성되고, 쿠버네티스의 동적 프로비저너(Dynamic Provisioner)에 의해서 PV가 생성되게 됩니다.

“Size” 필드는 볼륨의 크기입니다.

“Mode” 필드는 PV의 접근 모드(Access Mode) 입니다.

  • ReadWriteOnce : 단일 노드에서 볼륨을 읽기/쓰기로 마운트 할 수 있습니다
  • ReadOnlyMany : 복수개의 노드에서 볼륨을 읽기 전용으로 마운트 할 수 있습니다
  • ReadWriteMany : 복수개의 노드에서 볼륨을 읽기 / 쓰기로 마운트 할 수 있습니다

“Mount Point” 필드는 는 볼륨을 마운트할 경로입니다.

“Data Volumes” 부분에서는 필요에 따라, 데이터 볼륨을 추가 할 수 있습니다.

“Confiurations” 부분에서는 필요에 따라, PodDefault 라는 CR을 사용해서 추가 구성을 설정할 수 있습니다. 이 옵션을 사용하려면 PodDefault 리소스를 만들어야 합니다.

PodDefault는 환경 변수나 볼륨 등 공통 데이터를 포드(pod)에 주입하기 위해서 만들어진 Kubeflow CR 입니다.

다음은 team-secret 라는 볼륨을 마운트하는 PodeDefault 매니페스트 입니다.

apiVersion: "kubeflow.org/v1alpha1"
kind: PodDefault
metadata:
  name: add-team-secret
  namespace: admin
spec:
 selector:
  matchLabels:
    add-user-secret: "true"
 desc: "Add team credential"
 volumeMounts:
 - name: secret-volume
   mountPath: /secret/team
 volumes:
 - name: secret-volume
   secret:
    secretName: team-secret

PodDefault를 생성한 후, 노트북 서버 생성 화면을 새로 고치면 “Confiurations” 부분에서 나타는 것을 알 수 있습니다.

만약 이 “Add team credentail” 옵션을 선택해서 노트북 서버를 생성하게 되면, 노트북 서버의 포드에 아래 PodDefault에 정의한 부분이 반영됩니다.

다음은 “Add team credentail” 노트북 서버 포드의 일부분 입니다.

apiVersion: v1
kind: Pod
metadata:
  labels:
    add-user-secret: "true"
...
    volumeMounts:
    - mountPath: /secret/team
      name: secret-volume
...
  volumes:
  - name: secret-volume
    secret:
      defaultMode: 420
      secretName: team-secret
...

“GPUs” 부분에서는 노트북 서버에서 사용할 GPU 갯수를 설정할 수 있습니다.

“Miscellaneous Settings” 부분에서는 공유 메모리 활성화에 대한 설정을 변경할 수 있습니다. 기본값은 공유 메모리가 활성화 된 것입니다. PyTorch와 같은 일부 라이브러리는 멀티 프로세싱에 공유 메모리를 사용합니다. 현재 쿠버네티스에는 공유 메모리를 활성화시키는 방법이 없기 때문에, Kubeflow는 /dev/shm 라는 빈 디렉토리를 만듭니다.

맨 아래이 있는 “LAUNCH” 버튼을 클릭하면, 노트북 서버를 생성하기 시작하고, 노트북 서버 목록 페이지로 이동합니다. 목록 페이지의 “Status” 컬럼에 있는 상태 아이콘에 마우스 커서를 가져가면, 상태를 알 수 있니다.

노트북 서버를 생성하는데 몇 분이 걸릴 수 있습니다

좀 더 자세한 상태를 보고 싶으면, 포드를 이벤트를 조회해 보면 됩니다.

다음은 admin 이라는 네임스페이스의 rain 이라는 노트북 서버의 포드를 조회해 본 명령어입니다.

kubectl -n admin describe pod -l notebook-name=rain

다음과 같은 응답 결과를 얻을 수 있습니다.

...
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  6m23s  default-scheduler  Successfully assigned admin/rain-0 to mortar
  Normal  Pulled     6m22s  kubelet, mortar    Container image "gcr.io/istio-release/proxy_init:release-1.3-latest-daily" already present on machine
  Normal  Created    6m22s  kubelet, mortar    Created container istio-init
  Normal  Started    6m22s  kubelet, mortar    Started container istio-init
  Normal  Pulling    6m21s  kubelet, mortar    Pulling image "gcr.io/kubeflow-images-public/tensorflow-1.14.0-notebook-cpu:v-base-ef41372-1177829795472347138"
  Normal  Pulled     5m44s  kubelet, mortar    Successfully pulled image "gcr.io/kubeflow-images-public/tensorflow-1.14.0-notebook-cpu:v-base-ef41372-1177829795472347138"
  Normal  Created    5m43s  kubelet, mortar    Created container rain
  Normal  Started    5m43s  kubelet, mortar    Started container rain
  Normal  Pulled     5m43s  kubelet, mortar    Container image "gcr.io/istio-release/proxyv2:release-1.3-latest-daily" already present on machine
  Normal  Created    5m43s  kubelet, mortar    Created container istio-proxy
  Normal  Started    5m43s  kubelet, mortar    Started container istio-proxy

노트북 서버 생성이 완료되면, 노트북 서버 목록 페이지에서 다음과 같은 화면을 볼 수 있습니다.

생성한 노트북 서버의 상태가 녹색 체크 표시 아이콘이면 정상적으로 만들어진것 입니다. 우측에 있는 “CONNECT” 버튼을 클릭하면, 노트북 서버에 접속할 수 있습니다.

다음은 노트북 서버에 접속한 화면입니다.

주피터 노트북 삭제하기

노트북 서버를 삭제하려면 노트북 서머 목록 페이지에서, 오른쪽 끝에 있는 휴지통 모양을 아이콘을 클릭하면 됩니다.

휴지통 아이콘을 클릭하면, 정말로 노트북 서버를 삭제할 것인지 물어봅니다. “DELETE” 버튼을 클릭하면, 노트북 서버는 삭제됩니다.

쿠버네티스에서 직접 삭제하고 싶으면, kubectl 사용해서 삭제하면 됩니다.

다음은 admin 이라는 네임스페이스의 rain 이라는 노트북 서버를 삭제하는 명령어입니다.

kubectl -n admin delete notebook rain

노트북 서버를 삭제해도, 생성한 PV는 삭제되지 않습니다. 더 이상 필요없는 PV는 kubectl을 사용해서 삭제하면됩니다. 엄밀히 말하면, PVC를 삭제하면 PV가 자동으로 삭제되기 때문에 PVC를 삭제하면 됩니다. 노트북 서버를 생성할때 입력한 볼륨 이름이 PVC 이름이기 때문에, 볼륨 이름을 기억하고 있어야합니다.

볼륨 이름이 기억나지 않는다면, 노트북 서버 목록 페이지의 볼륨 컬럼에서 확인할 수 있습니다. 볼륨 컬럼을 클릭하면, 볼륨 목록이 화면에 나타납니다.

다음은 기본값으로 생성한 rain 이라는 노트북 서버의 볼륨 목록입니다.

“workspace-rain”이라는 볼륨과 “dshm” 이라는 볼륨이 보입니다. “dshm”는 공유 메모리 때문에 사용하는 볼륨이기 때문에 따로 삭제하지 않아도 됩니다.

다음은 admin 이라는 네임스페이스의 workspace-rain 이라는 PVC를 삭제하는 명령어입니다.

kubectl -n admin delete pvc workspace-rain

PVC는 노트북 서버를 먼저 삭제한 후 삭제하는 것이 좋습니다. PVC를 사용하고 있는 노트북 서버가 있을 경우 삭제가 안되기 때문입니다. 정확히 말하면 “Terminating”에서 더이상 진행되지 않습니다. 만약 이런 경우가 발생하면, 해당 PVC를 사용하는 노트북 서버를 삭제하면 됩니다.

주피터 노트북에서 쿠버네티스 사용하기

Kubeflow의 Profile 을 이용해서 네임스페이스를 생성한 경우, 네임스페이스에는 default-editordefault-viewer 라는 두 개의 서비스 계정(ServiceAccount)이 만들어집니다. 이중에서 default-editor 라는 서비스 계정은 주피터 노트북 포드를 실행할 때 서비스 계정으로 사용됩니다. 이 서비스 계정은 kubeflow-edit 라는 클러스터롤(ClusterRole)이 바인딩되어 있으며, 여기에는 Pods, Deployments, Services, Jobs, TfJobs, PyTorchJobs 등의 많은 쿠버네티스 권한이 존재하고 있습니다.

다음은 kubeflow-edit 라는 클라서트롤이 가지고 있는 권한을 보는 명령어입니다.

kubectl describe clusterrole kubeflow-edit

그리고 Kubeflow에서 제공하는 기본 주피터 이미지에는 kubectl 이 포함되어 있습니다.

그래서 주피터 노트북에서 쿠버네티스 리소스를 사용할 수 있는 것입니다.

주피터에서 노트북을 하나 생성한 후, 노트북 셀에 다음 명령어를 실행해서 쿠버네티스 포드 목록을 조회할 수 있습니다.

!kubectl get pod

명령어를 입력한 후 shift + enter 를 누르면 셀을 실행 할 수 있습니다.

Kubeflow 소개

Kubeflow 살펴보기

Kubeflow는 머신 러닝을 위한 클라우드 네이티브(Cloud Native) 플랫폼입니다. 구글 내부에서 사용하던 머신 러닝 파이이프 라인을 기반으로 해서 만들어졌습니다. Kubeflow는 쿠버네티스(Kubernetes) 위에서 작동합니다. 그래서 자원 관리, 확장 등의 쿠버네티스의 장점을 그대로 이용할 수 있습니다.

다음은 Kubeflow 사이트(https://www.kubeflow.org/docs/about/kubeflow/)에 나와 있는 소개글을 번역한 내용입니다.

Kubeflow 프로젝트는 쿠버네티스에서 머신 러닝 워크 플로를 간단하고 이식 가능하며 확장 가능하게 구축하는 데 전념하고 있습니다. 우리의 목표는 다른 서비스를 재창조하는 것이 아니라 ML을위한 동급 최강의 오픈 소스 시스템을 다양한 인프라에 배포하는 간단한 방법을 제공하는 것입니다. 쿠버네티스를 실행하는 모든 곳에서 Kubeflow를 실행할 수 있어야합니다.

Kubeflow가 있다면, 주피터를 사용하여 모델을 개발할 수 있습니다. 그리고 페어링(fairing)과 같은 Kubeflow 도구를 사용하여, 컨테이너 이미지를 만들고, 쿠버네티스 자원을 활용하여 모델을 학습할 수 있습니다. 모델이 만들어지면 KFServing 같은 것을 사용하여 추론(inference)을 위한 서버를 만들고 배포할 수 있습니다.

이 글은 Kubeflow를 사용하여, 머신 러닝 관련 작업을 간단하고 효율적으로 사용하는 방법에 대해서 설명하고자 합니다.

머신 러닝 플랫폼

Hidden Technical Debt in Machine Learning Systems (https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf) 라는 논문에 아래와 같은 그림이 있습니다.

대부분의 사람들은 머신 러닝에 대해서 생각할때, 모델 코드를 만드는 것에 많은 시간을 보낸다고 생각하고 있습니다. 위의 그림에서 알 수 있듯이, 머신 러닝 시스템에서 모델 코드가 차지하는 비중은 얼마되지 않습니다.

실제로 머신 러닝 모델을 만들어서 서비스에 적용시키는 일은, 모델을 만드는 시간보다 데이터 수집과 분석 그리고 모델을 튜닝하는 등의 반복적인 작업이 더 많이 소모됩니다. 그래서 이러한 일련의 과정을 묶어서 파이프라인으로 구축하게됩니다. 하지만, 서비스가 많아지고, 파이프라인이 많아지면 시스템이 복잡해져서 유지보수가 힘들어지기 시작합니다. 이러한 이유로 머신 러닝 플랫폼이 필요하게 되는 것입니다.

Kubeflow를 사용하는 이유

Kubeflow는 쿠버네티스에서 머신 러닝 워크 플로를 실행하기 위해서 만들어졌습니다. 일반적으로 다음과 같은 이유로 사용할 수 있습니다.

  • 이미 쿠버네티스 기반의 인프라가 있거나, 새로운 머신 러닝 플랫폼을 만들려는 경우
  • 다양한 환경(예 : 로컬, 온 프레미스 및 클라우드)에서 머신 러닝 모델을 학습하거나 서비스하려는 경우
  • 자원(예 : CPU 또는 GPU)를 할당하여 작업을 하려는 경우
  • Jupyter 노트북을 사용하여 머신 러닝 작업을 하려는 경우

Kubeflow를 사용하면 데이터 과학자에게 인프라가 아닌 모델링에만 집중할 수 있는 환경을 제공해 줄 수 있습니다. 그리고 컨테이너 기반의 독립된 환경에서 연구를 할 수 있기 때문에, TensorFlow, PyTorch, MXNet 등 다양한 프레임워크를 사용할 수 있습니다. GPU 같은 자원을 이용해서 모델을 분산 학습 시킬 수 도 있습니다.

또한 Hyper parameter tuning 과정을 쉽게 자동화할 수 있는 기능도 제공하고 있으며, 만든 모델을 실제 서비스에 배포할 수 있는 서빙 도구들도 제공하고 있습니다.

Kubeflow 컴포넌트(Component)

Kubeflow의 대표적인 컴포넌트는 다음과 같습니다.

  • Kubeflow’s UI – Central Dashboard
  • Jupyter Notebooks
  • Metadata
  • Frameworks for Training
  • Hyperparameter Tuning : Katib
  • Pipelines
  • Tools for Serving
  • Profile

Central Dashboard

Kubeflow의 UI 화면으로서, Kubeflow의 구성 요소를 쉽게 접근할 수 있는 대시보드가 포함되어 있습니다.

대시보드에는 다음과 같은 기능이 포함되어 있습니다.

특정 작업에 대한 바로 가기, 최근 노트북 목록 및 파이프 라인 목록을 한 번에 볼 수 있습니다.

파이프라인, 노트북, Katib 등 클러스터에서 실행중인 컴포넌트 목록을 볼 수 있습니다.

Kubeflow UIs

대시보드에서 볼 수 있는 컴포넌트 목록은 다음과 같습니다.

  • Home : Kubeflow 대시보드로 이동합니다.
  • Pipelines : Kubeflow 파이프라인 대시보드로 이동합니다.
  • Notebook Servers : 주피터 노트북 목록 화면으로 이동합니다.
    • Katib : 하이퍼파라메터 튜닝을 하는 Katb 화면으로 이동합니다.
  • Artifact Store : 아티펙트 저장소 호면으로 이동합니다.
  • Manage Contributors : 쿠버네티스 네임스페이스에 접근할 수 있는 사용자를 관리할 수 있는 화면으로 이동합니다.

메타데이터 (Metadata)

Kubeflow에서 실행하는 머신 러닝 워크 플로우의 메타 데이터를 추적 및 관리하는데 사용합니다.

메타데이터 컴포넌트는 Kubeflow 사용자가 머신 러닝 워크 플로에서 생성하는 메타 데이터를 추적하고 관리함으로써, 머신 러닝 워크 플로를 이해하고 관리 할 수 ​​있도록 도와 줍니다.

Kubeflow v1.0 버전에 포함된 메타데이터 컴포넌트는 beta 상태입니다.

Jupyter Notebooks

Kubeflow에서 주피터 노트북을 사용할 수 있도록 도와줍니다.

주피터 노트북을 생성하고 관리 할 수 있는 기능을 제공합니다.

Frameworks for Training

Kubeflow에서 머신 러닝 모델을 학습할 수 있도록 도와줍니다.

Kubeflow에서 제공하는 학습 프레임워크는 다음과 같습니다.

  • Chainer Training
  • MPI Training
  • MXNet Training
  • PyTorch Training
  • TensorFlow Training (TFJob)

Hyperparameter Tuning : Katib

Kubeflow에서 머신 러닝 모델의 하이퍼 파라미터 튜닝을 할 수 있도록 도와줍니다.

Katib는 머신 러닝 모델의 하이퍼 파라미터 및 뉴럴 아키텍처(Neural Architecture)를 자동으로 튜닝할 수 있는 기능을 제공합니다. Katib는 TensorFlow, PyTorch, Apache MXNet, XGBoost 등 다양한 머신 러닝 프레임 워크를 지원합니다.

Kubeflow v1.0 버전에 포함된 메타데이터 컴포넌트는 beta 상태입니다.

Pipelines

Kubeflow 파이프라인은 컨테이너를 기반으로 확장 가능한 ent-to end 머신 러닝 워크 플로를 구축하기 위한 플랫폼입니다.

머신 러닝 파이프라인을 관리하는 기능을 제공하여 ent-to end 오케스트레이션을 지원합니다. 그리고 수 많은 아이디어와 기술을 시도할 수 있도록 시험(trials)과 실험(experiments)을 관리할 수 있는 기능도 제공합니다.

Tools for Serving

Kubeflow는 두 가지 모델 서빙 시스템인 KFServing과 Seldon Core를 사용할 수 있습니다. KFServing과 Seldon Core는 다중 프레임워크 모델 서빙을 지원합니다. 그리고 TensorFlow Serving와 NVIDIA TensorRT Inference Server 같은 독립형 모델 제공 시스템을 사용할 수 있습니다.

  • KFServing
  • Seldon Serving
  • NVIDIA TensorRT Inference Server
  • TensorFlow Serving

수치 미분의 결과인 접선을 그래프로 그리기

다음과 같은 함수가 있습니다.

$$ f(x) = x^2 + x $$

위 함수를 코드로 정의하면 다음과 같습니다.

def function_1(x):
    return x**2 + x

수치 미분의 오차를 줄이기 위해서, 중앙차분 방법을 사용합니다.

def numerical_diff(f, x):
    h = 1e-4 # 0.0001
    return (f(x+h) - f(x-h)) / (2*h)

미분의 결과인 접선을 표현하는 함수는 다음과 같습니다.

def tangent_line(f, x):
    d = numerical_diff(f, x)

    y = f(x) - d*x
    return lambda t: d*t + y

x = 5 일때의 접선을 그려보면 다음과 같습니다.

import numpy as np
import matplotlib.pylab as plt

x = np.arange(0.0, 20.0, 0.1)
y = function_1(x)
plt.xlabel("x")
plt.ylabel("f(x)")

tf = tangent_line(function_1, 5)
y2 = tf(x)
plt.plot(x, y)
plt.plot(x, y2)

plt.show()

PC에 kubeflow 설치하기 – 3부 kubeflow 설치하기

Service Account Token Volume Projection 활성화

kubeflow에서는 인증/권한 기능을 위해서 istio 를 사용합니다. 그래서 istio-system 이라는 네임스페이스에 istio 관련 컴포넌트가 설치됩니다. 그 중에 하나인 istio-ingressgateway 포드의 내용을 보면 다음과 같은 부분을 발견할 수 있습니다.

...
  volumes:
  - name: istio-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: istio-ca
          expirationSeconds: 43200
          path: istio-token
...

바로 Service Account Token Volume Projection 이라는 것입니다. 이 기능은 쿠버네티스 1.15에서 비활성화 되어 있습니다. 그래서 해당 기능을 사용하기 위해서는 활성화 해줘야 합니다.

기능을 활성화 하기 위해서는, 다음과 같이 kube-apiserver 매니페스트에 몇 가지 플래그를 추가해야합니다. 매니페스트 파일은 /etc/kubernetes/manifests/kube-apiserver.yaml에 위치합니다.

$ sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
...
        - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
        - --service-account-issuer=api
        - --service-account-api-audiences=api,vault

매니페스트 파일을 수정하고, kube-apiserver 포드가 자동으로 다시 시작됩니다.

dynamic volume provisioner 설치

kubeflow를 쉽게 설치하기 위해서는 동적 볼륨 프로비져너(dynamic volume provisioner)가 필요합니다. 이 글에는 로컬 디렉토리를 이용하는 Local Path Provisioner 를 사용하겠습니다.

다음은 Local Path Provisioner 를 설치하는 명령어입니다.

$ kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

namespace/local-path-storage created
serviceaccount/local-path-provisioner-service-account created
clusterrole.rbac.authorization.k8s.io/local-path-provisioner-role created
clusterrolebinding.rbac.authorization.k8s.io/local-path-provisioner-bind created
deployment.apps/local-path-provisioner created
storageclass.storage.k8s.io/local-path created
configmap/local-path-config created

스토리지 클래스(storage class)를 조회해 보겠습니다.

$ kubectl get storageclass
NAME         PROVISIONER             AGE
local-path   rancher.io/local-path   63s

kubeflow는 기본 스토리지 클래스를 사용하기 때문에, local-path 스토리지 클래스를 기본 클래스로 설정해야합니다..

다음은 기본 스토리지 클래스를 설정하는 명령어입니다.

$ kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

storageclass.storage.k8s.io/local-path patched

다시 스토리지 클래스를 조회해 보면, 기본 클래스가 설정된 것을 확인할 수 있습니다.

$ kubectl get sc
NAME                   PROVISIONER             AGE
local-path (default)   rancher.io/local-path   11m

kubeflow 설치하기

kubeflow를 설치하기 위해서, kftctl 릴리즈 페이지에서 다운로드 합니다. 이 글을 쓰는 시점에서는 v1.0버전이 최신이므로, v1.0 버전을 기준으로 설명하겠습니다.

$ mkdir ~/kubeflow
$ cd ~/kubeflow

$ curl -L -O https://github.com/kubeflow/kfctl/releases/download/v1.0/kfctl_v1.0-0-g94c35cf_linux.tar.gz

다운 받은 tar ball 을 풉니다.

$ tar -xvf kfctl_v1.0-0-g94c35cf_linux.tar.gz

kubflow 배포를 쉽게 하기 위해서, 다음과 같은 환경 변수들을 생성합니다. 환경 변수들의 자세한 내용은 해당 페이지를 확인 하시기 바랍니다.

export PATH=$PATH:"/home/kangwoo/kubeflow"

export CONFIG_URI="https://raw.githubusercontent.com/kubeflow/manifests/v1.0-branch/kfdef/kfctl_istio_dex.v1.0.1.yaml"


export KF_NAME=kf-test

export BASE_DIR=/home/kangwoo/kubeflow
export KF_DIR=${BASE_DIR}/${KF_NAME}

kfctl_existing_arrikto.yaml 설정 파일을 가지고, kubeflow를 배포하겠습니다. 해당 파일에는 다중 유저와 권한/인증 기능을 지원하는 부분이 정의 되어 있습니다.

mkdir -p ${KF_DIR}
cd ${KF_DIR}

# Download the config file and change the default login credentials.
wget -O kfctl_istio_dex.yaml $CONFIG_URI
export CONFIG_FILE=${KF_DIR}/kfctl_istio_dex.yaml

kfctl apply -V -f ${CONFIG_FILE}

kfctl apply 명령어를 실행하면, kubeflow가 설치되기 시작합니다.

다음은 kubeflow 네임스페이스와, istio-system 네임스페이스의 포드를 조회해 본 것입니다.

$ kubectl -n kubeflow get pod
NAME                                                           READY   STATUS      RESTARTS   AGE
admission-webhook-deployment-7b7888fc9b-9dlj9                  1/1     Running     0          2d23h
application-controller-stateful-set-0                          1/1     Running     0          2d23h
argo-ui-7ffb9b6577-xqcxc                                       1/1     Running     0          2d23h
centraldashboard-6944c87dd5-sfqc7                              1/1     Running     0          2d23h
jupyter-web-app-deployment-679d5f5dc4-6278n                    1/1     Running     0          2d23h
katib-controller-7f58569f7d-62pgx                              1/1     Running     1          2d23h
katib-db-manager-54b66f9f9d-wsxv5                              1/1     Running     5          2d23h
katib-mysql-dcf7dcbd5-4fpmj                                    1/1     Running     0          2d23h
katib-ui-6f97756598-dk8fz                                      1/1     Running     0          2d23h
metadata-db-65fb5b695d-b92zm                                   1/1     Running     0          2d23h
metadata-deployment-65ccddfd4c-242t7                           1/1     Running     1          2d23h
metadata-envoy-deployment-7754f56bff-6vftm                     1/1     Running     0          2d23h
metadata-grpc-deployment-7557fdc6bb-n7jd7                      1/1     Running     7          2d23h
metadata-ui-7c85545947-wwkh9                                   1/1     Running     0          2d23h
minio-69b4676bb7-zglc6                                         1/1     Running     0          2d23h
ml-pipeline-5cddb75848-tjbh9                                   1/1     Running     1          2d23h
ml-pipeline-ml-pipeline-visualizationserver-7f6fcb68c8-pw529   1/1     Running     0          2d23h
ml-pipeline-persistenceagent-6ff9fb86dc-ghj74                  1/1     Running     3          2d23h
ml-pipeline-scheduledworkflow-7f84b54646-mztnf                 1/1     Running     0          2d23h
ml-pipeline-ui-6758f58868-qc72b                                1/1     Running     0          2d23h
ml-pipeline-viewer-controller-deployment-745dbb444d-2xwdn      1/1     Running     0          2d23h
mysql-6bcbfbb6b8-6qb6p                                         1/1     Running     0          2d23h
notebook-controller-deployment-54f455c5c9-rpv8s                1/1     Running     0          2d23h
profiles-deployment-6fcb86d54c-9pdrs                           2/2     Running     0          2d23h
pytorch-operator-cf8c5c497-lntsm                               1/1     Running     0          2d23h
seldon-controller-manager-6b4b969447-b4gcj                     1/1     Running     0          2d23h
spark-operatorcrd-cleanup-knfpw                                0/2     Completed   0          2d23h
spark-operatorsparkoperator-76dd5f5688-2689x                   1/1     Running     0          2d23h
spartakus-volunteer-5dc96f4447-6ss4g                           1/1     Running     0          2d23h
tensorboard-5f685f9d79-7d8kp                                   1/1     Running     0          2d23h
tf-job-operator-5fb85c5fb7-vxkgv                               1/1     Running     0          2d23h
workflow-controller-689d6c8846-lmmdz                           1/1     Running     0          2d23h
k -n istio-system get pod
NAME                                                         READY   STATUS      RESTARTS   AGE
authservice-0                                                1/1     Running     0          2d23h
istio-citadel-79b5b568b-kqjw9                                1/1     Running     0          3d
istio-galley-756f5f45c4-kxkhr                                1/1     Running     0          3d
istio-ingressgateway-77f74c944c-z5frv                        1/1     Running     0          3d
istio-nodeagent-478g7                                        1/1     Running     0          3d
istio-nodeagent-rmbc5                                        1/1     Running     0          3d
istio-nodeagent-z49bb                                        1/1     Running     0          3d
istio-pilot-55f7f6f6df-k5mdm                                 2/2     Running     0          3d
istio-policy-76dbd68445-vskkp                                2/2     Running     0          3d
istio-security-post-install-release-1.3-latest-daily-2j5tr   0/1     Completed   0          3d
istio-sidecar-injector-5d9f474dcb-l5qjj                      1/1     Running     0          3d
istio-telemetry-697c8fd794-9hz9q                             2/2     Running     0          3d
prometheus-b845cc6fc-d7cq6                                   1/1     Running     0          3d

kubeflow 접속하기

kubeflow GUI에 접속해 보겠습니다. istio-ingressgateway 를 통해서 접속합니다. 여기서는 편의를 위해서 노드 포트(NodePort)를 사용하겠습니다.

다음은 istio-ingressgateway 서비스를 조회해 본 결과입니다.

$ kubectl -n istio-system get service istio-ingressgateway
NAME                   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                                                                      AGE
istio-ingressgateway   NodePort   172.30.86.239   <none>        15020:30113/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:31134/TCP,15030:31251/TCP,15031:32398/TCP,15032:30455/TCP,15443:32764/TCP   3d

서비스 타입이 NodePort 이고, 80번 포트가 31380이라는 노드 포트로 열려있습니다. 브라우저를 실행하고, 해당 포트로 접속해보겠습니다.

기본 설정을 바꾸지 않았다면, 사용자 이름은 admin@kubeflow.org 이고, 비밀번호는 12341234 입니다.

로그인이 성공적으로 되면, 다음과 같이 사용할 네임스페이스를 생성하는 화면이 나옵니다. 원하는 이름을 입력하시면 됩니다. 기본값을 admin 으로 되어있습니다.

네임스페이스가 생성되면, kubeflow 대시보드 화면을 볼 수 있습니다.

참고

PC에 kubeflow 설치하기 – 2부 kubernetes, nvidia device-plugin 설치하기

swap 비활성화 하기

쿠버네티스(kubernetes)를 설치 하기 위해서 swap을 비활성화 합니다.

$ sudo swapoff -a

그리고 재부팅 하였을때 swap이 다시 활성화되는 것을 막기 위해서, /etc/fstab 에 있는 swap 관련 부분을 주석 처리하거나, 제거해 줍니다.

$ sudo vi /etc/fstab
 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=D21A-9B89  /boot/efi       vfat    umask=0077      0       1
# /dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

iptables 설치하기

iptables을 설치하고, 필요에 따라서 iptables tooling을 legacy 모드로 변경합니다.

# ensure legacy binaries are installed
$ sudo apt-get install -y iptables arptables ebtables

# switch to legacy versions
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
sudo update-alternatives --set arptables /usr/sbin/arptables-legacy
sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy

kubelet, kubeadm, kubectl 설치하기

쿠버네티스 설치에 필요한 kubelet, kubeadm, kubectl을 설치합니다. 버전을 명시해 주지 않으면, 최선 버전으로 설치됩니다. kubeflow 문서에 따르면 현재 권장하는 쿠버네티스 버전은 1.14 입니다. 1.15 버전도 호환이 되기 때문에, 이 글에서는 1.15.10-00 버전으로 설치 하였습니다.

$ sudo apt-get update && sudo apt-get install -y apt-transport-https curl
$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
$ cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
$ sudo apt-get update
$ sudo apt-get install -y kubelet=1.15.10-00 kubeadm=1.15.10-00 kubectl=1.15.10-00
$ sudo apt-mark hold kubelet kubeadm kubectl

쿠버네티스 설치하기

kubeadm을 사용해서 쿠버네티스를 설치합니다. 포드 네트워크 애드온을 cilium을 사용할 것이기 때문에 --pod-network-cidr=10.217.0.0/16 옵션을 사용하겠습니다.

다음 명령어를 실행해서 쿠버네티스를 설치합니다.

$ sudo kubeadm init --pod-network-cidr=10.217.0.0/16

설치가 완료되면, kubectl을 사용하기 위해서 관리자 설정 파일을 유저 디렉토리로 복사합니다.

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

쿠버네티스 접속을 테스트 하기 위해서, 다음 명령어를 실행합니다.

$ kubectl cluster-info
Kubernetes master is running at https://192.168.21.36:6443
KubeDNS is running at https://192.168.21.36:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

이제 Cilium을 쿠버네티스에 설치합니다.

$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml

cilim 포드의 READY가 1/1이 되면, 쿠버네티스 클러스터를 사용할 수 있습니다.

$ kubectl get pods -n kube-system --selector=k8s-app=cilium
NAME           READY   STATUS    RESTARTS   AGE
cilium-k4l5b   1/1     Running   0          70s

Control plane 노드 격리 해제하기

기본적으로 쿠버네티스 클러스터의 컨트롤 플레인(control-plane) 노드에는 보안상의 이유로 노드가 격리되어 있어서, 포드가 스케줄링되지 않습니다. 이 문서에는 1대의 머신만을 사용하기 때문에 노드 격리를 해제하겠습니다.

다음 명령어로 노드 격리를 해제 시킵니다.

$ kubectl taint nodes --all node-role.kubernetes.io/master-
node/mortar untainted

nvidia plugin 설치하기

쿠버네티스에서 GPU를 사용하기 위해서, nvidia k8s-device-plugin 을 설치합니다. 이 문서를 작성하는 시점에서는 1.12가 최신버전이라서 1.12로 설치하겠습니다.

$ kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.12/nvidia-device-plugin.yml

daemonset.extensions/nvidia-device-plugin-daemonset-1.12 created

참고로, 쿠버네티스 1.15 버전을 설치했을 경우에는 문제가 없을 건데, 1.16 버전 이상을 설치 했을 경우, 다음과 같은 에러가 발생할 것입니다. 자세한 사항은 해당 페이지를 참고 바랍니다.

error: unable to recognize "https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.12/nvidia-device-plugin.yml": no matches for kind "DaemonSet" in version "extensions/v1beta1"

쿠버네티스 버전이 올라가면서, Daemonsetextensions/v1beta1 버전을 더 이상 지원하지 않아서 입니다. 버전을 apps/v1 으로 변경하고 selector를 추가한 후, k8s-device-plugin 을 다시 설치합니다.

다음은 변경한 1.17 버전에 맞게 변경한 메니페스트 파일입니다.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin-daemonset-1.12
  namespace: kube-system
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      name: nvidia-device-plugin-ds
  template:
    metadata:
      # Mark this pod as a critical add-on; when enabled, the critical add-on scheduler
      # reserves resources for critical add-on pods so that they can be rescheduled after
      # a failure.  This annotation works in tandem with the toleration below.
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ""
      labels:
        name: nvidia-device-plugin-ds
    spec:
      tolerations:
      # Allow this pod to be rescheduled while the node is in "critical add-ons only" mode.
      # This, along with the annotation above marks this pod as a critical add-on.
      - key: CriticalAddonsOnly
        operator: Exists
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
      containers:
      - image: nvidia/k8s-device-plugin:1.11
        name: nvidia-device-plugin-ctr
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        volumeMounts:
          - name: device-plugin
            mountPath: /var/lib/kubelet/device-plugins
      volumes:
        - name: device-plugin
          hostPath:
            path: /var/lib/kubelet/device-plugins
EOF

device-plugin 포드가 정상적으로 작동했는지 확인해 봅니다.

$ kubectl -n kube-system get pod -l name=nvidia-device-plugin-ds
NAME                                        READY   STATUS    RESTARTS   AGE
nvidia-device-plugin-daemonset-1.12-4kt95   1/1     Running   0          24s

$ kubectl -n kube-system logs  -l name=nvidia-device-plugin-ds
2020/02/09 09:05:10 Loading NVML
2020/02/09 09:05:10 Fetching devices.
2020/02/09 09:05:10 Starting FS watcher.
2020/02/09 09:05:10 Starting OS watcher.
2020/02/09 09:05:10 Starting to serve on /var/lib/kubelet/device-plugins/nvidia.sock
2020/02/09 09:05:10 Registered device plugin with Kubelet

GPU 테스트 하기

다음은 텐서플로를 이용해서, GPU를 테스트 해 보는 예제입니다. 단순한 테스트이기 때문에 무시하고 넘어가도 됩니다.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: tf-gpu-jupyter
  name: tf-gpu-jupyter
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tf-gpu-jupyter
  template:
    metadata:
      labels:
        app: tf-gpu-jupyter
    spec:
      containers:
      - image: tensorflow/tensorflow:2.1.0-gpu-py3-jupyter
        imagePullPolicy: IfNotPresent
        name: tf-gpu-jupyter
        ports:
        - containerPort: 8888
          protocol: TCP
        resources:
          limits:
            nvidia.com/gpu: "1"
EOF

tf-gpu-jupyter 라는 이름을 가진 GPU를 사용할 수 있는 텐서플로 주피터(jupyter)를 생성하였습니다. 포드가 정상적으로 작동했는지 확인해 봅니다.

$ kubectl get pod -l app=tf-gpu-jupyter
NAME                              READY   STATUS    RESTARTS   AGE
tf-gpu-jupyter-66f89b64cd-vrllc   1/1     Running   0          5m58s

주피터 접속에 필요한 토큰 정보를 얻기 위해서 로그를 조회해 보겠습니다.

$ kubectl logs -l app=tf-gpu-jupyter
[I 09:15:25.009 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 09:15:25.012 NotebookApp] 
    
    To access the notebook, open this file in a browser:
        file:///root/.local/share/jupyter/runtime/nbserver-1-open.html
    Or copy and paste one of these URLs:
        http://tf-gpu-jupyter-66f89b64cd-vrllc:8888/?token=6527214998b8d895f6f14a8901a39ba6d8420c43e68f6919
     or http://127.0.0.1:8888/?token=6527214998b8d895f6f14a8901a39ba6d8420c43e68f6919
[I 09:17:20.916 NotebookApp] 302 GET / (127.0.0.1) 0.53ms
[I 09:17:20.926 NotebookApp] 302 GET /tree? (127.0.0.1) 0.65ms

포드에 접속하기 위해서 port-forward를 사용하겠습니다.

$ kubectl port-forward pod/tf-gpu-jupyter-66f89b64cd-vrllc 8888:8888
Forwarding from 127.0.0.1:8888 -> 8888
Forwarding from [::1]:8888 -> 8888

kubectl delete deployment tf-gpu-jupyter
deployment.apps "tf-gpu-jupyter" deleted

포트 포워드가 활성화 되면, 브라우저에서 주피터 주소를 입력합니다. 포드 로그에서 봤던 주소를 입력하면 됩니다. 이 예제에서 주소는 http://127.0.0.1:8888/?token=6527214998b8d895f6f14a8901a39ba6d8420c43e68f6919 입니다.

정상적으로 접속이 되면, 다음과 같은 화면을 보실 수 있습니다.

사용 가능한 GPU 갯수를 확인하겠습니다. 파이썬3 노트북을 생성한 후, 다음 코드를 입력합니다.

from __future__ import absolute_import, division, print_function, unicode_literals

import tensorflow as tf
print("Num GPUs Available: ", len(tf.config.experimental.list_physical_devices('GPU')))

코드를 실행하면 다음과 같이 사용 가능한 GPU 개수가 출력될 것입니다.

확인을 다 했으면, 브라우저를 종료하고, 자원 낭비를 막기 위해서 디플로이먼트를 삭제하도록 하겠습니다. 우리의 GPU는 소중하니까요.

$ kubectl delete deploy tf-gpu-jupyter

참고

  • https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
  • https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/
  • https://github.com/NVIDIA/k8s-device-plugin
  • https://hub.docker.com/r/tensorflow/tensorflow/
  • https://www.tensorflow.org/guide/gpu

PC에 kubeflow 설치하기 – 1부 nvidia 드라이버, docker 설치하기

이 글은 지적 유희를 위해서 작성하였습니다. kubeflow 자체가 목적이신 분들은, miniKFGCP를 사용하시길 추천드립니다.

시스템 사항

다음은 이 글에서 사용한 PC의 사양입니다. kubeflow를 원활하게 설치하기 위해서는 램이 16GB 이상, CPU는 4코어 이상을 추천합니다. GPU를 사용하기 위해서 nvidia 그래픽 카드도 필요합니다.

프로세서amd 라이젠 5 3600
RAM32GB
그래픽 카드RTX-2060
스토리지 공간 다다익선

설치 목록

  • ubuntu 18.04 LTS
  • nvidia driver 435
  • docker CE 18.9
  • nvidia-docker2
  • kubernetes 1.15.10
  • cilium 1.6
  • nvidia-device-plugin-daemonset 1.12
  • kubeflow 1.0RC4 with istio 1.3

전체 목록

우분투 설치하기

우분투는 데스크탑 18.04 LTS 버전을 사용합니다. 설치 방법은 다른곳에 많이 나와있기 때문에 생략합니다. 다만 nvidia 그래픽 카드를 사용할 경우 문제가 생기기 때문에, 그 부분만 다루겠습니다.

nvidia driver 설치하기

우분투 18.04 환경에서 RTX-2060을 사용할 경우 nouveau 문제가 있습니다. RTX-2060가 장착되어 있는 장비에서 우분투를 설치할 경우 nouveau로 자동 설정되기 때문이다. 그래서 nouveau 를 제거하는 작업이 필요합니다.

우분투 설치 화면이 깨져서 보이지 않는다면, 설치 전에 nomodset 옵션을 추가해줘야 정상적인 화면을 볼 수 있습니다.

우분투를 설치 하기 전 GRUB 메뉴 화면에서 e 키를 누룹니다.

e 키를 누르면, 다음과 같이 파라메터를 편집할 수 있는 화면이 나옵니다.

quiet splash 뒤에 nomodeset 을 추가해 줍니다. 그리고 F10 키를 눌러서 부팅 합니다.

정상적으로 화면이 보일 것입니다. 우분투를 설치하는 나머지 과정은 생략하겠습니다.

nouveau 설치 확인 하기

우분투가 정상적으로 설치되었다면, 재부팅 후 nouveau 확인 작업을 합니다. 시스템이 다시 시작되면, 앞서 한 것과 동일한 방법으로, nomodset 옵션을 추가해줘야 정상적인 화면을 볼 수 있을것입니다.

부팅이 완료되면 터미널을 열어서 작업을 시작합니다.

터미널에서 다음 명령어를 실행한 후, 결과가 보이면 nouveau가 설치되어 있는 것입니다. nvidia 드라이버 설치를 위해서 제거해야 합니다.

$ lsmod | grep nouveau
nouveau              1863680  0
mxm_wmi                16384  1 nouveau
video                  49152  1 nouveau
i2c_algo_bit           16384  1 nouveau
ttm                   102400  1 nouveau
drm_kms_helper        180224  1 nouveau
drm                   479232  3 drm_kms_helper,ttm,nouveau
wmi                    28672  3 wmi_bmof,mxm_wmi,nouveau

/etc/modprobe.d/ 경로에 blacklist 파일을 생성합니다.

$ sudo vi /etc/modprobe.d/blacklist-nouveau.conf

blacklist nouveau
options nouveau modset=0

다음 명령어를 실행 한 후, 재부팅 합니다.

$ sudo update-initramfs -u
$ sudo service gdm stop

Nvidia 드라이버 설치하기

컨테이너(Container)를 이용해서 GPU를 사용할 예정이기 때문에, Nvidia 드라이버가 설치합니다.

$ sudo add-apt-repository ppa:graphics-drivers/ppa
$ sudo apt-get update

$ sudo apt-get install nvidia-driver-435
$ sudo reboot

재부팅 후, nvidia-smi 명령어를 실행해서, 드라이버가 정상적으로 설치되어 있는지 확인해 볼 수 있습니다.

$ nvidia-smi
Sun Feb 16 17:26:22 2020       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 435.21       Driver Version: 435.21       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce RTX 2060    Off  | 00000000:26:00.0  On |                  N/A |
| 32%   45C    P8     9W / 190W |    189MiB /  5931MiB |      1%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0       975      G   /usr/lib/xorg/Xorg                            96MiB |
|    0      1123      G   /usr/bin/gnome-shell                          91MiB |
+-----------------------------------------------------------------------------+

docker 설치하기

apthttps저장소를 사용할 수 있도록 패키지를 추가합니다.

$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

도커의 GPG 키를 추가합니다.

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

저장소를 추가합니다

$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

apt 패키지의 인덱스를 업데이트합니다.

$ sudo apt-get update

이 문서를 작성할 당시(2020-02-08)에 도커의 최선 버전은 19.03이였습니다. 19.03 버전 부터 GPU 관련한 내용이 변경되었습니다. 쿠버네티스상에서 GPU 관련 작업을 하라면, k8s-device-plugin이 필요한데, 아직 19.03 버전을 지원하지 않는 것 같습니다. 그래서 18.9 버전을 설치하였습니다.

도커 엔진 18.9 버전을 설치합니다.

$ sudo apt-get install docker-ce=5:18.09.9~3-0~ubuntu-bionic docker-ce-cli=5:18.09.9~3-0~ubuntu-bionic containerd.io

$ sudo apt-mark hold docker-ce docker-ce-cli

설치 가능한 도커 버전을 보려면 다음 명령어를 실행하면 됩니다.

$ apt-cache madison docker-ce
 docker-ce | 5:19.03.5~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:19.03.4~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:19.03.3~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:19.03.2~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:19.03.1~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:19.03.0~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:18.09.9~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:18.09.8~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:18.09.7~3-0~ubuntu-bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
...

도커가 정상적으로 설치되었는지 확인해 보기 위해서 hello-world 이미지를 실행합니다.

$ sudo docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete 
Digest: sha256:9572f7cdcee8591948c2963463447a53466950b3fc15a247fcad1917ca215a2f
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

nvidia-docker2 설치하기

컨테이너에서 GPU를 사용하기 위해서 nvidia-docker2 을 설치합니다. 그리고 도커를 재시작 합니다.

# Add the package repositories
$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
$ curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
$ curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list

$ sudo apt-get update
$ sudo apt-get install nvidia-docker2
$ sudo systemctl restart docker

nvidia-docker2 가 정상적으로 설치되었는지 확인해 보기 위해서, 다음 명령어를 실행합니다.

$ sudo docker run --runtime nvidia nvidia/cuda:10.0-base nvidia-smi
Sat Feb  8 11:19:15 2020       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 435.21       Driver Version: 435.21       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce RTX 2060    Off  | 00000000:26:00.0  On |                  N/A |
| 29%   40C    P8     9W / 190W |    229MiB /  5931MiB |      1%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
+-----------------------------------------------------------------------------+

도커의 기본 런타임을 변경해 줍니다. /etc/docker/daemon.json 파일이 생성되었을 것입니다. 해당 파일을 열여서 "default-runtime": "nvidia"을 추가해주면 됩니다.

$ sudo vi /etc/docker/daemon.json

    {
      "default-runtime": "nvidia", 
      "runtimes": {
        "nvidia": {
          "path": "nvidia-container-runtime",
          "runtimeArgs": []
        }
      }
    }

파일을 수정한 후, 도커를 재시작합니다.

$ sudo systemctl restart docker

참고

  • https://docs.docker.com/install/linux/docker-ce/ubuntu/
  • https://github.com/NVIDIA/nvidia-docker

Service Account Token Volume Projection

쿠버네티스(kubernetes)에는 서비스 계정(service account)이라는 것이 있습니다. 서비스 계정은 롤(role)과 클러스터롤(clusterrole)을 바인딩하여 권한을 부여하고, 쿠버네티스 api를 호출하는데 사용합니다.

서비스 계정은 토큰(token)이라는 것을 가지고 있고, 이 토큰을 통해서 자격 증명을 얻습니다. 쿠버네티스 api를 호출할 때, 토큰을 같이 전송합니다. api 서버에서는 토큰값이 유효한지 판단한 다음, 서비스 계정 이름을 얻어내어, 부여된 권한들 검사하며, 요청한 api에 권한이 있는지 없는지 판단합니다.

그렇다면, 서비스 계정 토큰을 이용해서 서비스와 서비스, 즉 포드(pod)와 포드(pod)의 호출에서 자격 증명으로 사용할 수 있을까요? 불행히도 기본 서비스 계정 토큰으로는 사용하기에 부족함이 있습니다. 토큰을 사용하는 대상(audience), 유효 기간 등 토큰의 속성을 지정할 필요가 있기 때문입니다. Service Account Token Volume Projection 기능을 사용하면 이러한 부족한 점들을 해결할 수 있습니다.

Service Account Token Volume Projection 기능은 쿠버네티스 1.10에서 알파 버전으로 도입 되었습니다. 1.12에서 베타 상태로 전환 되었고, 현재 최신 버전인 1.17에서도 베타 상태입니다.

기능 활성화

이 기능을 사용하기 위해서는, 아래와 같이 kube-apiserver 매니페스트에 몇 가지 플래그를 추가해야합니다. 일반적으로 매니페스트 파일은 /etc/kubernetes/manifests/kube-apiserver.yaml에 위치합니다.

    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-account-issuer=api
    - --service-account-api-audiences=api,vault

매니페스트 파일에 추가되는 플래그를 살펴 보겠습니다.

  • service-account-signing-key-file : 서비스 계정 토큰 발급자(issuer)의 개인키 파일 경로입니다. 발급자늘 이 개인키로 토큰을 서명합니다.
  • service-account-issuer : 서비스 계정 토큰 발급자의 식별자입니다. 이 값은 문자열이나 URI를 사용할 수 있습니다.
  • service-account-api-audiences : 토큰이 사용되는 대상을 나타냅니다. 토큰을 사용할때 정의된 대상 중에 속해있는지 확인합니다.

TokenRequest API 와 TokenReview API

전체적인 흐름을 파악하기 위해서, TokenRequest API와, TokenReview API에 대해서 알아보도록 하겠습니다.

다음 그림은 전체 흐름을 표현한 것입니다.

  1. 포드 A 에서 TokenRequest API를 호출해서 토큰을 생성을 요청합니다.
  2. 요청을 받은 kube-api-server는 토큰을 생성해서 포드 A에게 돌려줍니다.
  3. 포드 A 는 포드 B로 API 호출을 합니다. 이때 생성된 토큰을 요청에 포함시킵니다.
  4. 요청을 받은 포드 B는 토큰 정보를 추출하고, TokenReview API를 호출합니다.
  5. kube-api-server는 토큰의 유효성 같은 속성 정보를 포드 B에게 돌려줍니다.
  6. 토큰에 문제가 없다면 API 호출에 대한 응답을 합니다.

서비스 계정 생성과 권한 부여

TokenRequest API와 TokenReview API를 직접 사용해 보도록 하겠습니다. 해당 API들을 사용하기 위해서는 특정 리소스 권한이 필요합니다. 예제에서는 편의를 위해서 cluster-admin 클러스터롤을 부여하도록 하겠습니다.

테스트를 위해서 token-admin 네임스페이스를 생성하고, token-admin 서비스 계정을 생성합니다.

$ kubectl create namespace token-test
namespace/token-test created

$ kubectl -n token-test create serviceaccount token-admin
serviceaccount/token-admin created

token-admin 서비스계정에 `cluster-admin` 클러스터롤을 부여합니다.

$ kubectl create clusterrolebinding token-admin --clusterrole=cluster-admin --serviceaccount=token-test:token-admin

clusterrolebinding.rbac.authorization.k8s.io/token-admin created

생성한 서비스 계정의 토큰 정보를 조회합니다.

$ kubectl -n token-test describe secret $(kubectl -n token-test get sa token-admin -o json | jq -r '.secrets[].name')
Name:         token-admin-token-r6h8z
Namespace:    token-test
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: token-admin
              kubernetes.io/service-account.uid: 1357fefc-59a4-474c-bbfa-b7567b87b50f

Type:  kubernetes.io/service-account-token

Data
====
namespace:  10 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0b2tlbi10ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWN...
ca.crt:     1143 bytes

eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9. 로 시작하는 부분이 토큰 입니다. 서비스 계정의 기본 토큰입니다. JWT이기 때문에 jwt.io에서 토큰 페이로드를 조회해 볼 수 있습니다.

TokenRequest API를 호출해서 토큰 생성하기

TokenRequest API를 이용해서, 포드 B를 호출할 때 넘겨 줄 토큰을 생성해보겠습니다. 위 그림에서 1, 2 단계에 해당됩니다.

다음은 TokenRequest API를 호출하는 curl 템플릿입니다.

$ curl -k -X "POST" "https://{KUB_API_SERVER}/api/v1/namespaces/{NAMESPACE}/serviceaccounts/{SERVICEACCOUNT}/token" \
     -H 'Authorization: Bearer {TOKEN}' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{}'
  • {KUB_API_SERVER} : 쿠버네티스 API 서버의 주소입니다. 자신의 쿠버네티스 주소를 입력합니다.
  • {NAMESPACE} : 네임스페이스입니다. 예제에서는 token-test 입니다.
  • {SERVICEACCOUNT} : 서비스 계정입니다. 예제에서는 token-admin 입니다.
  • {TOKEN} : 서비스 계정의 기본 토큰입니다. 앞서 secret에서 조회한 토큰을 입력합니다.

다음과 같이 TokenRequest API를 호출해 보겠습니다.

$ curl -k -X "POST" "https://192.168.21.31:6443/api/v1/namespaces/token-test/serviceaccounts/token-admin/token" \
     -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0b2tlbi10ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWN...' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{}'

정상적으로 호출 되었다면, 다음과 같은 응답을 얻을 수 있습니다.

{
  "kind": "TokenRequest",
  "apiVersion": "authentication.k8s.io/v1",
  "metadata": {
    "selfLink": "/api/v1/namespaces/token-test/serviceaccounts/token-admin/token",
    "creationTimestamp": null
  },
  "spec": {
    "audiences": [
      "api",
      "vault"
    ],
    "expirationSeconds": 3600,
    "boundObjectRef": null
  },
  "status": {
    "token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJhdWQiOlsiYXBpIiwidmF1bHQiLCJ...",
    "expirationTimestamp": "2020-02-12T13:55:51Z"
  }
}

eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJhdWQiOlsiYXBpIiwidmF1bHQiLCJ… 라고 적혀 있는 부분이 바로 새로 생성된 토큰입니다. 기존 토큰과 구별하기 위해서 BOUND-TOKEN 이라고 부르겠습니다. 포드 A가 포드 B를 호출할 때 BOUND-TOKEN 토큰을 사용하게 됩니다.

TokenReview API를 호출해서 토큰 확인하기

TokenReview API를 호출하여, 토큰을 확인해 보겠습니다. 위 그림에서 4, 5 단계에 해당됩니다.

다음은 TokenRequest API를 호출하는 curl 템플릿입니다.

curl -X "POST" "https://{KUB_API_SERVER}/apis/authentication.k8s.io/v1/tokenreviews" \
     -H 'Authorization: Bearer {TOKEN}' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "kind": "TokenReview",
  "apiVersion": "authentication.k8s.io/v1",
  "spec": {
    "token": "{BOUND-TOKEN}"
  }
}'
  • {KUB_API_SERVER} : 쿠버네티스 API 서버의 주소입니다. 자신의 쿠버네티스 주소를 입력합니다.
  • {TOKEN} : 서비스 계정의 기본 토큰입니다. 앞서 secret에서 조회한 토큰을 입력합니다.
  • {BOUND-TOKEN} : TokenRequest API를 호출해서 생성한 토큰입니다.

다음과 같이 TokenReview API를 호출해 보겠습니다.

curl -k -X "POST" "https://192.168.21.31:6443/apis/authentication.k8s.io/v1/tokenreviews" \
     -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0b2tlbi10ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWN...' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "kind": "TokenReview",
  "apiVersion": "authentication.k8s.io/v1",
  "spec": {
    "token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJhdWQiOlsiYXBpIiwidmF1bHQiLCJ..."
  }
}'

정상적으로 호출 되었다면, 다음과 같은 응답을 얻을 수 있습니다.

{
  "kind": "TokenReview",
  "apiVersion": "authentication.k8s.io/v1",
  "metadata": {
    "creationTimestamp": null
  },
  "spec": {
    "token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJhdWQiOlsiYXBpIiwidmF1bHQiLCJ..."
  },
  "status": {
    "authenticated": true,
    "user": {
      "username": "system:serviceaccount:token-test:token-client",
      "uid": "b5132c47-041a-4d18-984a-02865edc1b1b",
      "groups": [
        "system:serviceaccounts",
        "system:serviceaccounts:token-test",
        "system:authenticated"
      ]
    },
    "audiences": [
      "api",
      "vault"
    ]
  }
}

포드 B 에서는 응답 결과의 status 위치에 있는 여러 값들로, 토큰이 유효한지 확인 할 수 있습니다. status.authenticated 키는 인증된 토큰인지를 확인시켜줍니다. 그리고 status.audiences 는 토큰이 사용 될 수 있는 대상이 나열되어 있습니다. 토큰의 사용 대상이 맞는지 여부를 확인하는 것은 개발자의 몫입니다.

Service Account Token Volume Projection 사용하기

TokenRequest API를 직접 사용하지 않고, Service Account Token Volume Projection 을 사용하겠습니다. 예제에 사용한 매니페스트와 애플리케이션 소스는 https://github.com/kangwoo/projected-svc-token 에서 확인할 수 있습니다.

token-client 서비스 계정을 만듭니다.

$ kubectl -n token-test create serviceaccount token-client
serviceaccount/token-client created

token-client 애플리케이션을 실행하는 포드 리소스를 생성합니다. Service Account Token Volume Projection 을 사용기 위해서 spec.volumes 부분에 projected를 사용하였습니다. 이 부분 때문에 토큰이 자동으로 생성됩니다.

다음은 token-client 포드 매니페스트 입니다.

apiVersion: v1
kind: Pod
metadata:
  name: token-client
spec:
  containers:
  - image: kangwoo/token-client
    name: token-client
    ports:
    - containerPort: 8090
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: token-client
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

token-client 포드를 생성했다면, 다음과 같이 서비스 계정 볼륨 프로젝션이 작동하는지 확인 할 수 있습니다.

$ kubectl -n kube-test  exec -it token-client cat /var/run/secrets/tokens/vault-token

토큰을 사용하는 token-server 를 설치하겠습니다. token-server 도 서비스 계정이 필요합니다. 그리고 TokenReview API에 접근할 수 있도록 롤을 바인딩해줘야합니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: token-server
  namespace: token-test

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: tokenreview-binding-token-server
  namespace: token-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - kind: ServiceAccount
    name: token-server
    namespace: token-test

그리고 디플로이먼트(deployment) 매니페스트와, 서비스(service) 매니페스트를 이용해서 token-server 애플리케이션을 구동합니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: token-server
  name: token-server
  namespace: token-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: token-server
  strategy:
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: token-server
    spec:
      serviceAccountName: token-server
      containers:
        - image: kangwoo/token-server:0.0.1
          name: token-server
          ports:
            - containerPort: 8090
          resources:
            limits:
              cpu: 100m
              memory: 64Mi
            requests:
              cpu: 100m
              memory: 64Mi


---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: token-server
  name: token-server
  namespace: token-test
spec:
  ports:
    - name: http
      port: 8090
  selector:
    app: token-server

token-client와 token-server의 설치가 완료되었으면, token-client를 호출해 봅니다.

$ curl http://localhost:8090

정상적으로 작동 한다면, 다음과 같은 메시지를 볼 수 있습니다.

Hello, This is token-server

curltoken-client를 호출하면, token-client/var/run/secrets/tokens/vault-token 에서 토큰을 읽어옵니다. 그리고 해당 토큰을 헤더에 넣어서 token-server에게 요청을 보냅니다.

다음 token-client 애플리케이션 코드의 일부입니다.

package main

import (
	"io/ioutil"
	"log"
	"net/http"
	"os"
)


func readToken() []byte {
	file, err := os.Open("/var/run/secrets/tokens/vault-token")
	if err != nil {
		log.Fatal(err)
	}
	defer file.Close()

	bytes, err := ioutil.ReadAll(file)
	if err != nil {
		log.Fatal(err)
	}
	return bytes
}

func requestWithToken(w http.ResponseWriter, r *http.Request) {
	token := readToken()

	client := &http.Client{}
	req, _ := http.NewRequest("GET", "http://token-server:8090", nil)
	req.Header.Set("X-Auth-Token", string(token))
	resp, err := client.Do(req)
	if err != nil {
		log.Fatal(err)
	}
	defer resp.Body.Close()

	if resp.StatusCode == http.StatusForbidden {
		w.Write([]byte("403 : StatusForbidden"))
		return
	} else if resp.StatusCode == http.StatusOK {
		body, _ := ioutil.ReadAll(resp.Body)
		w.Write(body)
	}

}

func main()  {
	log.Println("Starting token-client")

	http.HandleFunc("/", requestWithToken)

	http.ListenAndServe(":8090", nil)
}

token-sever는 요청을 받아서, 헤더값을 토큰을 추출합니다. 그리고 TokenReview API를 이용해서 토큰의 유효성을 체크하고, 문제가 없다면 “Hello, This is token-server” 라는 메시지를 응답으로 보내줍니다.

다음은 token-server 애플리케이션 코드의 일부입니다.

package main

import (
	"bytes"
	"crypto/tls"
	"encoding/json"
	"io/ioutil"
	"log"
	"net/http"
	"os"
)


const audience = "vault"

func readServiceAccountToken() []byte {
	file, err := os.Open("/run/secrets/kubernetes.io/serviceaccount/token")
	if err != nil {
		log.Fatal(err)
	}
	defer file.Close()

	byes, err := ioutil.ReadAll(file)
	if err != nil {
		log.Fatal(err)
	}
	return byes
}

func validateToken(boundToken, serviceAccountTOken string) bool {

	reviewPayload := []byte(`{"kind": "TokenReview","apiVersion": "authentication.k8s.io/v1","spec": {"token": "` + serviceAccountTOken + `"}}`)
	body := bytes.NewBuffer(reviewPayload)

	tr := &http.Transport{
		TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
	}
	client := &http.Client{Transport: tr}

	req, err := http.NewRequest("POST", "https://kubernetes.default:443/apis/authentication.k8s.io/v1/tokenreviews", body)

	req.Header.Add("Authorization", "Bearer " +boundToken)
	req.Header.Add("Content-Type", "application/json; charset=utf-8")

	resp, err := client.Do(req)
	if err != nil {
		log.Printf("Failure : %s", err)
	}
	defer resp.Body.Close()

	respBody, _ := ioutil.ReadAll(resp.Body)

	var respData map[string]interface{}
	if err := json.Unmarshal(respBody, &respData); err != nil {
		log.Printf("Error unmarshaling response %s", err)
	}

	if respData["status"].(map[string]interface{})["authenticated"] == true {

		if validateAudiences(respData["status"].(map[string]interface{})["audiences"].([]interface{})) {
			return true
		} else {
			log.Printf("Audience validation failed.")
		}

	} else {
		log.Printf("Authenticated failed.")
	}

	return false
}

func validateAudiences(audiences []interface{}) bool {
	for _, v := range audiences {
		if v == audience {
			return true
		}
		continue
	}

	return false
}

func requestHandler(w http.ResponseWriter, r *http.Request) {
	svcAcctToken := readServiceAccountToken()
	if validateToken(string(svcAcctToken), r.Header.Get("X-Auth-Token")) != true {
		w.WriteHeader(403)
		return
	}

	w.Write([]byte("Hello, This is token-server"))

}

func main()  {
	log.Println("Starting token-server")

	http.HandleFunc("/", requestHandler)

	http.ListenAndServe(":8090", nil)

정리

Service Account Token Volume Projection 을 사용하면, 포드를 띄울때, 서비스 계정의 토큰을 자동으로 생성할 수 있습니다. 이 토큰은 서비스 계정의 기본 토큰과는 다르게 여러가지 속성 정보를 가지고 있습니다. 이 때 생성한 토큰을 포드와 포드의 호출에서 자격증명으로 사용할 수 있습니다.

참고

쿠버네티스 이벤트를 이용해서 오퍼레이터의 오류를 출력하기

흔히 오퍼레이터(Operator)라고 많이 부르는, 컨트롤러(Controller)에서 오류를 효과적으로 출력하는 방법에 대해서 알아보겠습니다. 이 글에서는 오퍼레이터(Operator)라는 용어로 통일해서 사용하겠습니다.

쿠버네티스에서 CR(Custom Resource)을 생성하면, 해당 CR을 담당하는 오퍼레이터가 , 원하는 목적을 이루기 위해서 여러가지 작업을 실행합니다. CR을 생성한 사용자의 실수나, 시스템의 오류 등의 여러 이유 때문에 이러한 작업이 실패할 수 있습니다. 작업이 실패할 경우 사용자에게 오류의 이유를 알려줘야지, 사용자가 무슨 문제인지 인식 할 수 있을 것입니다.

오류를 알려줄 수 있는 가장 쉬운 방법은 로그를 남기는 것입니다. 간단히 생각하면, 오퍼레이터의 로그에 오류 내용을 출력하면 되는것입니다. 하지만, 이 방법은 한 가지 문제를 가지고 있습니다. 바로 권한 문제입니다. CR을 생성한 사용자가, 오퍼레이터의 로그를 볼 권한을 가지고 있다고는 볼 수가 없기 때문입니다. 일반적으로 CR을 생성하는 권한과, 오퍼레이터를 관리하는 권한은 별도로 분리가 되어 있기 때문에, CR 사용자는 오퍼레이터의 로그를 볼 수가 없는 것입니다.

로그를 볼 수 없는 CR 사용자는, 어떤 이유 때문에 문제가 발생했는지를 알 수 없게 되어서, 작업을 진행하는데 심각한 어려움을 겪게 될 것입니다. 물론 오퍼레이터 관리자가 문제를 찾아서, CR 사용자 한테 전달해 줄 수는 있지만, 이 과정은 상당한 병목 현상을 발생시킬 것입니다. CR 사용자에게 어떤 부분에서 오류가 발생했는지를, 다른 사람의 개입없이 알아낼 수 있게, 정보를 제공해 주는 것이 최선의 방법일것입니다.

Kubernetes Events 는 이러한 오류에 대한 정보를 CR 사용자에게 전달하는데 효과적입니다. 포드(pod)의 이벤트 스트림에 오류 정보를 출력하게 되면, 사용자는 kubectl describe 명령어를 통해서 오류를 조회해 볼 수 있습니다.

다음은 kubectl describe pod을 실행해본 결과입니다. 해당 포드의 이벤트가 출력되는 것을 볼 수 있습니다.

$ kubectl describe pod jupyter-elsa
Name:           jupyter-elsa
Namespace:      snow
...
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age   From                      Message
  ----    ------     ----  ----                      -------
  Normal  Scheduled  16s   default-scheduler         Successfully assigned snow/jupyter-elsa to aries
  Normal  Pulled     11s   kubelet, aries            Container image "docker.io/istio/proxy_init:1.2.9" already present on machine
  Normal  Created    11s   kubelet, aries            Created container istio-init
  Normal  Started    11s   kubelet, aries            Started container istio-init
  Normal  Pulling    9s    kubelet, aries            Pulling image "tensorflow/tensorflow:2.1.0-py3-jupyter"
  Normal  Pulled     9s    kubelet, aries            Successfully pulled image "tensorflow/tensorflow:2.1.0-py3-jupyter"
  Normal  Created    9s    kubelet, aries            Created container jupyter
  Normal  Started    8s    kubelet, aries            Started container jupyter
  Normal  Pulled     8s    kubelet, aries            Container image "docker.io/istio/proxyv2:1.2.9" already present on machine
  Normal  Created    8s    kubelet, aries            Created container istio-proxy
  Normal  Started    8s    kubelet, aries            Started container istio-proxy

이벤트 기록하기

이벤트를 기록하기 위해서는, EventRecorder 를 생성해야합니다. EventRecordercontroller-runtimemanager를 이용해서 쉽게 생성할 수 있습니다.

https://github.com/kubernetes-sigs/controller-runtime/blob/v0.4.0/pkg/manager/manager.go#L86

// Manager initializes shared dependencies such as Caches and Clients, and provides them to Runnables.
// A Manager is required to create Controllers.
type Manager interface {
...
	// GetEventRecorderFor returns a new EventRecorder for the provided name
	GetEventRecorderFor(name string) record.EventRecorder
...

다음은 EventRecorder의 코드입니다.

// EventRecorder knows how to record events on behalf of an EventSource.
type EventRecorder interface {
	// Event constructs an event from the given information and puts it in the queue for sending.
	// 'object' is the object this event is about. Event will make a reference-- or you may also
	// pass a reference to the object directly.
	// 'type' of this event, and can be one of Normal, Warning. New types could be added in future
	// 'reason' is the reason this event is generated. 'reason' should be short and unique; it
	// should be in UpperCamelCase format (starting with a capital letter). "reason" will be used
	// to automate handling of events, so imagine people writing switch statements to handle them.
	// You want to make that easy.
	// 'message' is intended to be human readable.
	//
	// The resulting event will be created in the same namespace as the reference object.
	Event(object runtime.Object, eventtype, reason, message string)

	// Eventf is just like Event, but with Sprintf for the message field.
	Eventf(object runtime.Object, eventtype, reason, messageFmt string, args ...interface{})

	// PastEventf is just like Eventf, but with an option to specify the event's 'timestamp' field.
	PastEventf(object runtime.Object, timestamp metav1.Time, eventtype, reason, messageFmt string, args ...interface{})

	// AnnotatedEventf is just like eventf, but with annotations attached
	AnnotatedEventf(object runtime.Object, annotations map[string]string, eventtype, reason, messageFmt string, args ...interface{})
}

그럼 operator-sdk로 생성한 controller에서 Kubernetes Events를 사용하는 방법을 간단히 살펴 보도록 하겠습니다.

커스텀 리소스의 이름이 Jupyter 라고 가정하겠습니다. 먼저 jupyter_controller.go 파일을 열어서, ReconcileJupyterrecorder record.EventRecorder 을 추가합니다.

// ReconcileJupyter reconciles a Jupyter object
type ReconcileJupyter struct {
	// This client, initialized using mgr.Client() above, is a split client
	// that reads objects from the cache and writes to the apiserver
	client client.Client
	scheme *runtime.Scheme
	recorder record.EventRecorder
}

그런 다음 func newReconcilerEventRecorder 를 생성해서 넘겨줍니다.

// newReconciler returns a new reconcile.Reconciler
func newReconciler(mgr manager.Manager) reconcile.Reconciler {
	return &ReconcileJupyter{client: mgr.GetClient(), scheme: mgr.GetScheme(), recorder: mgr.GetEventRecorderFor("jupyter-controller")}
}

그리고, 필요한 곳에서 EventRecorder를 사용해서, 이벤트를 기록합니다.

import corev1 "k8s.io/api/core/v1"

// Pod event reason list
const (
	CreatedPod				= "CreatedPod"
	FailedToCreatePod			= "FailedToCreatePod"
)

r.recorder.Eventf(jupyter, corev1.EventTypeNormal, CreatedPod, "Created pod : %s", pod.Name)
r.recorder.Eventf(jupyter, corev1.EventTypeWarning, FailedToCreatePod, err.Error())

앞서 설명한 바와 같이, 이벤트를 기록한 후, Jupyer 라는 커스텀 리소스에 대해 세부 내용을 출력해보면, 다음과 같은 결과를 얻을 수 있습니다.

$ kubectl describe elsa
Name:         elsa
Namespace:    snow
...
Events:
  Type    Reason      Age    From                Message
  ----    ------      ----   ----                -------
  Normal  CreatedPod  3s     jupyter-controller  Created pod : jupyter-elsa

지금까지 Kubernetes Events를 사용 방법에 대해 알아봤습니다. 오류 내용을 CR 사용자에게 제공하여 문제를 해결하는데 많은 도움이 될것입니다.

참고

EventRecorder를 직접 생성하는 코드입니다.

import (
	"fmt"
	"github.com/go-logr/logr"
	corev1 "k8s.io/api/core/v1"
	"k8s.io/apimachinery/pkg/runtime"
	"k8s.io/client-go/kubernetes"
	typedcorev1 "k8s.io/client-go/kubernetes/typed/core/v1"
	"k8s.io/client-go/rest"
	"k8s.io/client-go/tools/record"
)


func NewEventRecorder(config *rest.Config, scheme *runtime.Scheme, logger logr.Logger, name string) (record.EventRecorder, error) {
	clientSet, err := kubernetes.NewForConfig(config)
	if err != nil {
		return nil, fmt.Errorf("failed to init clientSet: %v", err)
	}

	broadcaster := record.NewBroadcaster()
	broadcaster.StartRecordingToSink(&typedcorev1.EventSinkImpl{Interface: clientSet.CoreV1().Events("")})
	broadcaster.StartEventWatcher(
		func(e *corev1.Event) {
			logger.V(1).Info(e.Type, "object", e.InvolvedObject, "reason", e.Reason, "message", e.Message)
		})

	recorder := broadcaster.NewRecorder(scheme, corev1.EventSource{Component: name})
	return recorder, nil
}

활성화 함수 (Activation Function)

step function (계단 함수)

$$ h(x) = \begin{cases} 1 & (x > 0) \\ 0 & (x \leqq 0) \end{cases} $$

import numpy as np

def step_function(x):
    return np.array(x > 0, dtype=np.int)

계단 함수의 그래프

import matplotlib.pylab as plt

x = np.arange(-5.0, 5.0, 0.1)
y = step_function(x)
plt.plot(x, y)
plt.ylim(-0.1, 1.1)
plt.show()

sigmoid (시그모이드)

d

$$ h(x) = \frac{1}{1 + e^{-x}} $$

def sigmoid(x):
    return 1 / (1 + np.exp(-x))
x = np.arange(-5.0, 5.0, 0.1)
y = sigmoid(x)
plt.plot(x, y)
plt.ylim(-0.1, 1.1)
plt.show()

dd

ReLU (Rectified Linear Unit, 렐루)

$$ h(x) = \begin{cases} x & (x > 0) \\ 0 & (x \leqq 0) \end{cases} $$

def relu(x):
    return np.maximum(0, x)
x = np.arange(-5.0, 5.0, 0.1)
y = relu(x)
plt.plot(x, y)
plt.ylim(-1.0, 5.0)
plt.show()

Sealed Secretes

Secrets in Kubernetes

쿠버네티스를 사용하다 보면, 수 많은 YAML 파일들을 만들어 낼 것입니다. 그리고 이 YAML 파일들을 잘 관리하기 위해서 저장소를 찾게 됩니다. 일반적으로는 평소 즐겨 사용하던 git 을 저장소로 많이 사용합니다.

YAML 파일을 git 저장소에 올리는 것 자체는 별로 어렵지 않습니다. 하지만 파일에 정의된 쿠버네티스 리소스들을 하나씩 하나씩 관심있게 살펴보게 되면, 과연 이 리소스를 올리는게 맞는지 의문을 가지게 만드는 리소스가 있습니다. 바로 Secret 리소스 입니다.

쿠버네티스의 Secret 리소스는 키(key)-값(value)의 쌍으로 이루어져 있으며, 메타 데이터를 가지고 있습니다.

ConfigMap과 비슷하게 생겼지만, Secret에는 민감한 데이터를 저장하기 때문에 보호받아야하는 차이점이 존재합니다.

아래 예제는 Secret 를 YAML로 표현한것입니다.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
data:
  username: YWRtaW4=
  password: aGVsbG8td3JvbGQ=

usernamepassword 라는 키가 있고, Base64 로 인코딩된 값들이 저장되어 있습니다. 문제는 Base64 인코딩이 암호화가 아니라는 점입니다. 단순히 64진수로 변환된것 뿐이라서, 아주 쉽게 디코딩을 할 수 있습니다.

예제에 나와 있는 password의 값을 단순히 디코딩하면, 원래 값을 알 수가 있는 것입니다.

$ echo aGVsbG8td3JvbGQ= | base64 --decode
hello-world

이러한 Secret 을 git에 그냥 올리게 되면, 위험한 상황에 빠질 수도 있게 되는 것입니다.

그러면 어떻게 해야 할까요?

그것은 Secret 을 암호화 해서 git에 저장하는 것입니다. 다행히도 이러한 기능을 하는 도구들이 이미 나와 있습니다. 바로 Sealed SecretsKamus 입니다.

이 문서에는 Sealed Secrets 에 대해 간단히 다룰 것입니다.

Sealed Secrets

Sealed Secrets 는 두 개의 부분으로 이루어져 있습니다. 쿠버네티스 클러스터에 설치할 sealed-secrets-controller 와 암호화 유틸리티인 kubeseal입니다.

Sealed SecretsSealedSecret라는 CR(Custom Resource) 사용해서 Secrets 을 보호합니다. 사용자는 Secrets 리소스를 직접 생성하지 않고, SealedSecret 라는 커스텀 리소스를 생성합니다. 이 SealedSecret 리소스에는 중요한 값들이 암호화 되어 저장됩니다. 이러한 중요한 값들을 암호화 할 때 사용하는 도구가 kubeseal 입니다. SealedSecret 리소스가 클러스터에 등록되면, sealed-secrets-controller 가 해당 리소스의 암호화된 값들을 복호하해서 Secrets 리소스를 생성해 주는 것입니다.

설치하기

Controller 설치

SealedSecret 이라는 CRD를 생성하고, Controller를 설치하면 됩니다.

아래 예제는 CRD를 생성하고, kube-system 네임스페이스에 Controller를 설치하는 방법입니다.

$ kubectl apply -f <https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.9.6/controller.yaml>

controller.yaml

---
apiVersion: v1
kind: Service
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-controller
  name: sealed-secrets-controller
  namespace: kube-system
spec:
  ports:
  - port: 8080
    targetPort: 8080
  selector:
    name: sealed-secrets-controller
  type: ClusterIP
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-service-proxier
  name: sealed-secrets-service-proxier
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sealed-secrets-service-proxier
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-key-admin
  name: sealed-secrets-key-admin
  namespace: kube-system
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - create
  - list
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-controller
  name: sealed-secrets-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: secrets-unsealer
subjects:
- kind: ServiceAccount
  name: sealed-secrets-controller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  annotations: {}
  labels:
    name: secrets-unsealer
  name: secrets-unsealer
rules:
- apiGroups:
  - bitnami.com
  resources:
  - sealedsecrets
  verbs:
  - get
  - list
  - watch
  - update
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - create
  - update
  - delete
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
---
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-controller
  name: sealed-secrets-controller
  namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-controller
  name: sealed-secrets-controller
  namespace: kube-system
spec:
  minReadySeconds: 30
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      name: sealed-secrets-controller
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      annotations: {}
      labels:
        name: sealed-secrets-controller
    spec:
      containers:
      - args: []
        command:
        - controller
        env: []
        image: quay.io/bitnami/sealed-secrets-controller:v0.9.6
        imagePullPolicy: Always
        livenessProbe:
          httpGet:
            path: /healthz
            port: http
        name: sealed-secrets-controller
        ports:
        - containerPort: 8080
          name: http
        readinessProbe:
          httpGet:
            path: /healthz
            port: http
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1001
        stdin: false
        tty: false
        volumeMounts:
        - mountPath: /tmp
          name: tmp
      imagePullSecrets: []
      initContainers: []
      serviceAccountName: sealed-secrets-controller
      terminationGracePeriodSeconds: 30
      volumes:
      - emptyDir: {}
        name: tmp
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: sealedsecrets.bitnami.com
spec:
  group: bitnami.com
  names:
    kind: SealedSecret
    listKind: SealedSecretList
    plural: sealedsecrets
    singular: sealedsecret
  scope: Namespaced
  version: v1alpha1
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-service-proxier
  name: sealed-secrets-service-proxier
  namespace: kube-system
rules:
- apiGroups:
  - ""
  resourceNames:
  - 'http:sealed-secrets-controller:'
  - sealed-secrets-controller
  resources:
  - services/proxy
  verbs:
  - create
  - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  annotations: {}
  labels:
    name: sealed-secrets-controller
  name: sealed-secrets-controller
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sealed-secrets-key-admin
subjects:
- kind: ServiceAccount
  name: sealed-secrets-controller
  namespace: kube-system

kubeseal 설치

MacOS

brew install kubeseal

Linux x86-64

wget <https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.9.6/kubeseal-linux-amd64> -O kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

SealedSecret 생성하기

우선 kubectl--dry-run을 사용해서 my-secret.yaml 파일을 생성합니다.

kubectl -n default create secret generic my-secret \\
  --from-literal=username=admin \\
  --from-literal=password=hello-wrold \\
  --dry-run \\
  -o yaml > my-secret.yaml

생성한 my-secret.yaml 파일의 내용은 다음과 같습니다.

apiVersion: v1
data:
  password: aGVsbG8td3JvbGQ=
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: null
  name: my-secret
  namespace: default

kubeseal을 실행해서, my-secret.yaml 파일을 my-sealed-secret.yaml 파일로 변환합니다. my-sealed-secret.yaml 파일이 생성될때, 값들은 암호화되어 저장됩니다.

kubeseal --format=yaml < my-secret.yaml > my-sealed-secret.yaml

생성한 my-sealed-secret.yaml 파일의 내용은 다음과 같습니다.

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: my-secret
  namespace: default
spec:
  encryptedData:
    password: AgAkqnrtawbZwPiOuleW5VDHTy8DtnSRqpW8xfV+um6qtqpFVOurbEXAmGWZUhv0MhvppXdHokccRDyS/iaODZGTDXALqrpfS2KMbsX3ARhUXPM5/4G8x9MrjZYGGZNYEJnY78ZvzxlMv7EWsDHTa+9UnWPAorNXd/KDjBhXujohdzs7rPmrAFQWznLovcdqSSXkBMQyf4J19wKPit9H8wBIfHkB4kftI8106NOU6NK+y9s0T9mXIGalS0h5B8KbntvnGmR1/QmxEDJeD7pRSWjAx2m8eRFUsDxRif9uJP2tkwKtQlLJrmsW9YWeDWzeszjAkcniNZtRDkak2mHs3LQZl/vq/otj3V/JuRxVYbukFkyjkvQghbfQek8CTJ7s4kZzozEEwtKWugtSxW2dh7JCewvy18W+IYjxqNDok7sA67bGTycRRBY3+db9mirdE5PxhoHQAkvDu9cUUAgM/+SR2FkpJQ9lGPKWkRiEi3Nx4ZhIJ/4PE+3swZj95BBFLK50gI32YAPnop7SO99Gt9yU7oPK7zoV9r9TNDNvZinB37r7Y26ti3ASrKYH5AY0jAqNcnK2KuzSk44NBRmQ6Hmo0/NZiONBtSckhuzpSw0jmr8KTjp3eZPjk4KLUIW/lEYdAl3kfx3Kd8+QZz6ygALLJWxPPheZm3sd1VHV7F+Bnpo4zLC8pDh9uW0spMCMYQD5adRK+FkXEgnuTw==
    username: AgBbJRLu/+ke7Ze5EgZIRbQHNgwFP/oOz8w2XlkU3oyZczvK6AqkCFUZpHAO3r02LOPpNmiKzRZKOts508LtAFcYNawDeWOS2S29x+m8DQHiYuiKQ0UDBkoSquaEAiUXBBPJomOMS2uDuOLRq2vC4KaQ7N27eQgw1JFR/GvTH0ZPf3hTZ0if0PFMOPcbm4UmCI1Qeoo0ToiOhvgOcpdy6xbcEOyOFX5L+663P5GsZJmZ3F6IoMcSI7QN/iFQXytifW/9GXKSyv4un+dtIZAmjX+sxeUr22nsrBwSJxXy8jKfnO4tNG/XzlPk91ZVu37A5nYJj2+iNVaW0j+1fu80Kcto02rFaC3eFZ+D6q/RTD0cyhJlsNDKFk93il9K7hoAJ7nkyEW4vQ+hpVBsRvRWy2yGYXs/S5tjMtBbgWPYVwlFwR1zoWAd6/t4o+u3xNcJB/LWgBOhuW+Z7TPHGffMxPe3yqgqsLy16iDytjdjsZ83v8t/Fl1OBhWH4ssSHSMu1GA830wDPeCnCQL/JZHWOpqEeTpG+/FPGpzlt+n+oJ8jHdWeErSal3JfMSOLubKkGWVB7pdAYgzl8Pn47Q/GA5QehBqJiaOME/iL93ONhOmJFyI9ErQ9sqCT6YRsvRqxKy0BZgdud2Et1/W8oVZnR6Ev0e5hG/UbJ3SCiocYusWyKwFcmO0xEydxQA85miCvu78DeaJ1aA==
  template:
    metadata:
      creationTimestamp: null
      name: my-secret
      namespace: default
status: {}

SealedSecret 를 클러스터에 등록하기

생성한 SealedSecret 리소스를 클러스터에 등록해 보겠습니다. 네임스페이스는 default입니다.

kubectl일 실행해서 secretssealedsecrets을 조회해 보면 나오지 않습니다.

$ kubectl -n default get secrets
NAME                  TYPE                                  DATA   AGE
default-token-pz9rt   kubernetes.io/service-account-token   3      20d
istio.default         istio.io/key-and-cert                 3      20d

$ kubectl -n default get sealedsecrets
No resources found in default namespace.

생성한 SealedSecret 리소스를 등록합니다.

$ kubectl apply -f my-sealed-secret.yaml
sealedsecret.bitnami.com/my-secret created

다시 secretssealedsecrets을 조회해 보면 등록한 my-secret가 보이는 것을 알 수 있습니다.

$ kubectl -n default get secrets
NAME                  TYPE                                  DATA   AGE
default-token-pz9rt   kubernetes.io/service-account-token   3      20d
istio.default         istio.io/key-and-cert                 3      20d
my-secret             Opaque                                2      4s

$ kubectl -n default get sealedsecrets
NAME        AGE
my-secret   9s

자동으로 생성된 secret의 내용을 확인해 보겠습니다.

$ kubectl -n default get secrets my-secret -o yaml
apiVersion: v1
data:
  password: aGVsbG8td3JvbGQ=
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: "2020-01-25T06:37:42Z"
  name: my-secret
  namespace: default
  ownerReferences:
  - apiVersion: bitnami.com/v1alpha1
    controller: true
    kind: SealedSecret
    name: my-secret
    uid: 8ed4ea13-4f89-46e2-9149-b80fe01b46d2
  resourceVersion: "6472553"
  selfLink: /api/v1/namespaces/default/secrets/my-secret
  uid: 466f7e72-9dc0-401b-9e2f-b073d08b5540
type: Opaque

정상적으로 복호화 되어 있는 것을 확인 할 수 있습니다.

기타

인증서를 별도로 사용하기

kubeseal 은 비대칭키 암호화 알고리즘을 사용해서 값들을 암호화 합니다. 별 다른 옵션을 주지 않으면 기본 설정 파일(~/.kube/config)을 이용해서 인증서를 가져온 후, 암호화 작업을 합니다. 상황이 여의치 않는 경우에는 이 인증서 정보를 파일로 저장한 후 직접 사용하실 수 있습니다.

kubeseal --fetch-cert > pub-cert.pem

혹시라도 컨트롤러를 설치한 네임스페이스가 다르거나, 이름이 다른 경우 다음과 같은 옵션을 사용할 수도 있습니다.

kubeseal --fetch-cert \\
  --controller-namespace=kube-system \\
  --controller-name=sealed-secrets-controller \\
> pub-cert.pem

그리고 SealedSecret 리소스를 생성할때 --cert=pub-cert.pem 플래그로 인증서를 지정해 줄 수 있습니다.

kubeseal --format=yaml --cert=pub-cert.pem  < my-secret.yaml > my-sealed-secret.yaml

비대칭키 암호화 알고리즘을 사용하기 때문에, 복호화를 위해서 개인키를 사용합니다. 이 개인키를 잃어버리면, 복호화를 할 수가 없습니다. 그래서 이 개인키를 안전하게 잘 보관해야 합니다.

백업하기

kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml >master.key

복구하기

$ kubectl apply -f master.key
$ kubectl delete pod -n kube-system -l name=sealed-secrets-controller