VMware Cloud 네이티브 스토리지 시작 - VMware vSphere 6 · " VMware Cloud 네이티브 스토리지 시작" 설명서는 vSphere 환경에서 VMware® Cloud 네이티브

VMware Cloud 네이티브스토리지 시작

업데이트 32019년 8월 13일VMware vSphere 6.7vCenter Server 6.7VMware ESXi 6.7

다음 VMware 웹 사이트에서 최신 기술 문서를 확인할 수 있습니다.

https://docs.vmware.com/kr/

본 문서에 대한 의견이 있으시면 다음 주소로 피드백을 보내주십시오.

[email protected]

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

VMware 코리아서울시 강남구영동대로 517아셈타워 13층(우) 06164전화:+82 2 3016 6500팩스: +82 2 3016 6501www.vmware.com/kr

Copyright © 2019 VMware, Inc. All rights reserved. 저작권 및 상표 정보

VMware Cloud 네이티브 스토리지 시작

VMware, Inc. 2

https://docs.vmware.com/kr/

mailto:[email protected]

http://pubs.vmware.com/copyright-trademark.html

목차

VMware Cloud 네이티브 스토리지 시작 5

1 클라우드 네이티브 스토리지 이해 6클라우드 네이티브 스토리지 개념 및 용어 6

클라우드 네이티브 스토리지 사용자 및 도구 7

클라우드 네이티브 스토리지 구성 요소 8

클라우드 네이티브 스토리지에 대한 요구 사항 10

클라우드 네이티브 스토리지 역할 및 권한 11

2 Kubernetes 클러스터 설정 13Kubernetes 클러스터 가상 시스템 구성 13

노드 가상 시스템에 Kubernetes 구성 요소 설정 14

master 노드 초기화 15

worker 노드 초기화 17

vSphere Cloud Controller Manager 설치 18

vSphere Container Storage Interface 드라이버 설치 22

인증서를 사용하여 vCenter Server 연결 보호 33

클러스터 설정 확인 36

CCM 및 CSI 드라이버 설치 후 Kubernetes 노드 추가 37

3 상태 저장 애플리케이션 배포 39스토리지 정책 생성 40

스토리지 클래스 생성 41

애플리케이션용 Kubernetes 서비스 정의 및 배포 43

상태 저장 집합 생성 및 배포 43

컨테이너 볼륨 VMDK 검토 46

4 컨테이너 볼륨 관리 47Kubernetes 클러스터 전체에서 컨테이너 볼륨 모니터링 47

컨테이너화된 애플리케이션 확장 48

5 여러 데이터 센터나 클러스터가 있는 환경에서 CCM과 CSI 배포 50vSphere CNS 환경에서 영역 설정 50

vSphere 태그를 사용하여 영역 생성 51

CCM과 CSI 드라이버에 영역 사용 52

영역을 사용하여 워크로드 배포 54

Kubernetes에서 토폴로지 인식 볼륨 프로비저닝 사용 56

Kubernetes 노드 VM을 다른 영역이나 지역으로 마이그레이션 60

VMware, Inc. 3

6 vSphere 클라우드 네이티브 스토리지 문제 해결 61CNS 로그 파일 사용 61

로그 수준 수정 62


VMware, Inc. 4


" VMware Cloud 네이티브 스토리지 시작" 설명서는 vSphere 환경에서 VMware® Cloud 네이티브

스토리지를 설정 및 사용하는 방법에 대한 정보를 제공합니다.

이 정보에는 Cloud 네이티브 스토리지 개념 및 구성 요소에 대한 간략한 개요와 Kubernetes 클러스

터를 생성하고 컨테이너화된 애플리케이션을 배포하는 방법을 보여 주는 워크스루가 포함되어 있습니

다.

대상 사용자

이 정보는 Kubernetes에 대한 기본 지식이 있고 컨테이너 배포 개념에 익숙한 개발자 및 vSphere 관

리자를 대상으로 합니다.

VMware 기술 자료 용어집

VMware 기술 자료 사이트에서는 새로운 용어를 정리한 용어집을 제공하고 있습니다. VMware 기술

설명서에 사용된 용어에 대한 정의를 보려면 http://www.vmware.com/support/pubs를 참조하십

시오.

VMware, Inc. 5

http://www.vmware.com/support/pubs

클라우드 네이티브 스토리지 이해 1클라우드 네이티브 스토리지는 상태 저장 애플리케이션에 대한 종합적인 데이터 관리를 제공하는 솔루

션입니다. 클라우드 네이티브 스토리지를 사용하는 경우 다시 시작 및 중단을 지원하는 컨테이너화된

상태 저장 애플리케이션을 생성할 수 있습니다. 상태 저장 컨테이너는 표준 볼륨, 영구 볼륨 및 동적 프

로비저닝과 같은 기본 사항을 사용하는 동안 vSphere에서 노출되는 스토리지를 활용합니다.

클라우드 네이티브 스토리지를 사용하면 가상 시스템 및 컨테이너 수명주기와 독립적으로 영구 컨테이

너 볼륨을 생성할 수 있습니다. vSphere 스토리지는 볼륨을 지원하며, 스토리지 정책을 볼륨에 직접

설정할 수 있습니다. 볼륨을 생성한 후에는 vSphere Client에서 해당 볼륨과 이를 지원하는 가상 디스

크를 검토하고 스토리지 정책 규정 준수를 모니터링할 수 있습니다.

본 장은 다음 항목을 포함합니다.

n 클라우드 네이티브 스토리지 개념 및 용어

n 클라우드 네이티브 스토리지 사용자 및 도구

n 클라우드 네이티브 스토리지 구성 요소

n 클라우드 네이티브 스토리지에 대한 요구 사항

n 클라우드 네이티브 스토리지 역할 및 권한

클라우드 네이티브 스토리지 개념 및 용어

vSphere 클라우드 네이티브 스토리지 환경에 필수적인 몇 가지 개념을 숙지해야 합니다.

Kubernetes 클러스터 Kubernetes worker 및 worker 서비스가 실행되는 VM의 클러스터입니

다. 컨테이너화된 애플리케이션은 Kubernetes 클러스터 위에 배포합니

다. 애플리케이션은 상태 정보를 저장하거나 저장하지 않을 수 있습니다.

포드 포드는 스토리지 및 네트워크와 같은 리소스를 공유하는 하나 이상의 컨

테이너 그룹입니다. 포드 내부의 컨테이너는 그룹으로 시작되고, 중지되

고, 복제됩니다.

컨테이너

Orchestrator

호스트 클러스터 전반의 컨테이너화된 애플리케이션의 배포, 크기 조정

및 관리를 위한 오픈 소스 플랫폼(예: Kubernetes)입니다. 이 플랫폼은

컨테이너 중심의 인프라를 제공합니다.

상태 저장 애플리케이션 컨테이너화 애플리케이션이 상태 비저장에서 상태 저장으로 발전하면 영

구 스토리지가 필요합니다. 세션 간에 데이터를 저장하지 않는 상태 비저

장 애플리케이션과 달리 상태 저장 애플리케이션은 데이터를 영구 스토리

지에 저장합니다. 보존된 데이터를 애플리케이션의 상태라고 합니다. 나

VMware, Inc. 6

중에 데이터를 검색하여 다음 세션에서 사용할 수 있습니다. 대부분의 애

플리케이션은 상태 저장 애플리케이션입니다. 데이터베이스는 상태 저장

애플리케이션의 일례입니다.

영구 볼륨 상태 저장 애플리케이션은 영구 볼륨을 사용하여 데이터를 저장합니다.

영구 볼륨은 상태와 데이터를 유지할 수 있는 Kubernetes 볼륨입니다.

이는 포드와 독립적이며 포드를 삭제하거나 재구성해도 계속 존재할 수

있습니다. vSphere 환경에서 영구 볼륨 개체는 가상 디스크(VMDK)를

백업 스토리지로 사용합니다.

영구 볼륨 할당 일반적으로 영구 볼륨이나 이를 지원하는 VMDK를 미리 생성할 필요가

없습니다. 대신 애플리케이션은 영구 볼륨 할당을 통해 영구 스토리지를

요청할 수 있습니다. 영구 볼륨 할당은 영구 볼륨에 대한 액세스 모드, 스

토리지 용량 및 기타 매개 변수를 지정하는 스토리지 요청입니다. 이 요청

은 해당하는 영구 볼륨 개체와 지원 VMDK를 동적으로 프로비저닝합니

다.

할당이 생성되면 영구 볼륨이 할당에 자동으로 바인딩됩니다. 포드는 할

당을 사용하여 영구 볼륨을 마운트하고 스토리지에 액세스합니다.

할당을 삭제하면 해당하는 영구 볼륨 개체와 프로비저닝된 VMDK가 삭제

됩니다.

스토리지 클래스 스토리지 클래스는 영구 볼륨을 지원하는 스토리지에 대한 요구 사항을

설명하는 데 사용됩니다. 스토리지 클래스 생성를 참조하십시오.

상태 저장 집합 상태 저장 집합은 상태 저장 애플리케이션의 배포 및 확장을 관리합니다.

상태 저장 집합은 안정적인 식별자나 안정적인 영구 스토리지가 필요한

애플리케이션에 유용합니다. 영구 볼륨 할당 개체를 자동으로 생성하는

볼륨 할당 템플릿 항목을 포함하도록 상태 저장 집합을 구성할 수 있습니

다. 상태 저장 집합 생성 및 배포를 참조하십시오.

클라우드 네이티브 스토리지 사용자 및 도구

vSphere 클라우드 네이티브 스토리지 환경에서 Kubernetes 볼륨을 생성하고 모니터링하는 프로세스

와 관련된 사용자의 유형은 일반적으로 Kubernetes 사용자 및 vSphere 사용자라는 두 가지 범주로

나뉩니다. 두 가지 유형의 사용자는 서로 다른 도구에 액세스하여 서로 다른 작업을 수행합니다.

Kubernetes 사용자

Kubernetes 사용자는 Kubernetes 개발자 및 애플리케이션 소유자, Kubernetes 관리자이거나 두

기능을 모두 결합한 것일 수 있습니다. Kubernetes 사용자가 클라우드 네이티브 스토리지 환경에서

수행하는 작업은 다음과 같습니다.

n 상태 저장 애플리케이션을 배포하고 관리합니다.

n 영구 볼륨에 대한 수명주기 작업을 수행합니다.

n 스토리지 클래스에 대한 수명주기 작업을 수행합니다.


VMware, Inc. 7

일반적으로 Kubernetes 사용자는 다음과 같은 도구에 액세스할 수 있습니다.

kubectl Kubernetes 클러스터에 대한 명령줄 액세스를 제공하는 Kubernetes

인터페이스입니다. 클러스터와 통신하려면 kubectl 구성 파일에서

master 노드의 IP 주소를 사용하면 됩니다. kubectl에 대한 자세한 내용

은 Kubernetes 설명서에서 "kubectl 개요" 를 참조하십시오.

구성 파일 워크로드를 배포할 때 Kubernetes 사용자는 구성 파일에 Kubernetes

정보를 제공합니다. 대개, YAML 파일이 사용됩니다. kubectl은 API 요

청을 수행할 때 정보를 JSON으로 변환합니다.

참고 YAML 파일에 포함하는 Kubernetes 리소스의 이름은

Kubernetes 규칙을 따라야 합니다. 자세한 내용은 Kubernetes 설명서

에서 이름을 참조하십시오.

Kubernetes 대시보드 Kubernetes 대시보드를 사용하면 Kubernetes 클러스터에 대한 노드,

네임스페이스, 배포 및 기타 세부 정보를 볼 수 있습니다.

vSphere 사용자

vSphere 사용자는 vSphere Client에 액세스하여 다음 작업을 수행할 수 있습니다.

n VM 스토리지 정책에 대한 수명주기 작업을 수행합니다. 예를 들면, Kubernetes 스토리지 클래스

에 사용할 VM 스토리지 정책을 생성하고 이 이름을 Kubernetes 사용자에게 전달합니다.

n vSphere Client의 클라우드 네이티브 스토리지 섹션을 사용하여 Kubernetes 클러스터 전체에서

컨테이너 볼륨의 상태 및 스토리지 정책 규정 준수를 모니터링할 수 있습니다.

클라우드 네이티브 스토리지 구성 요소

클라우드 네이티브 스토리지는 몇 가지 구성 요소를 사용하여 vSphere 스토리지와 통합합니다.

다음 그림에서는 이러한 구성 요소가 상호 작용하는 방식을 보여줍니다.


VMware, Inc. 8

https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

CSI 플러그인SPBM

FCD

vSphere vSAN

CNS 제어부

Kubernetes 노드

VMFS NFS

정책 관리및 규정 준수

CacheDBKubernetes메타데이터

집계

블록 볼륨 관리

Kubernetes 클러스터 클라우드 네이티브 스토리지 환경에서 Kubernetes 클러스터는

vSphere에 배포된 가상 시스템 또는 노드의 클러스터입니다.

Kubernetes 사용자는 이 클러스터 위에 상태 저장 애플리케이션을 배포

할 때 클러스터와 직접 상호 작용합니다.

vSphere

CSI(Container

Storage Interface)

vSphere CSI는 Kubernetes와 같은 컨테이너 Orchestrator의 컨테이

너화된 워크로드에 vSphere 스토리지를 노출하는 인터페이스입니다.

vSAN 및 기타 유형의 vSphere 스토리지를 사용하도록 설정합니다.

Kubernetes에서 CSI 드라이버는 트리 외부 vSphere CCM(Cloud

Controller Manager)과 함께 사용됩니다.

Container Storage Interface는 컨테이너 볼륨의 동적 프로비저닝을 지

원합니다.

이 인터페이스는 다음과 같은 기능을 지원합니다.

n vSphere First Class Disk 기능

n Kubernetes 영역

n 기존 및 원시 마운트

n 여러 vCenter Server와 데이터 센터에 배포된 Kubernetes 클러스

터

n 여러 데이터스토어 또는 데이터스토어 클러스터에서 프로비저닝

클라우드 네이티브 스토

리지 서버 구성 요소

CNS 서버 구성 요소는 vCenter Server에 상주합니다. 이것은 컨테이너

볼륨에 대한 수명주기 작업과 프로비저닝을 구현하는 vCenter Server 관

리의 확장입니다.


VMware, Inc. 9

컨테이너 볼륨을 프로비저닝하는 경우, First Class Disk 기능과 상호 작

용하여 볼륨을 지원하는 가상 디스크를 생성합니다. 또한 CNS 서버 구성

요소는 스토리지 정책 기반 관리와 통신하여 디스크에 필요한 서비스 수

준을 보장합니다.

CNS는 vCenter Server를 통해 컨테이너 볼륨 및 이를 지원하는 가상

디스크를 관리하고 모니터링할 수 있는 쿼리 작업도 수행합니다.

First Class

Disk(FCD)

향상된 가상 디스크라고도 합니다. VM과 연결되지 않은 명명된 가상 디

스크입니다. 이러한 디스크는 VMFS, NFS 또는 vSAN 데이터스토어 및

백 컨테이너 볼륨에 상주합니다.

스토리지 정책 기반 관리 스토리지 정책 기반 관리는 지정된 스토리지 요구 사항에 따라 영구 볼륨

의 프로비저닝을 지원하는 vCenter Server 서비스입니다. 프로비저닝 후

에 서비스는 필요한 정책 특성으로 볼륨의 규정 준수를 모니터링합니다.

클라우드 네이티브 스토리지에 대한 요구 사항

Kubernetes 클러스터에 참여하는 클라우드 네이티브 스토리지 환경과 가상 시스템은 몇 가지 요구 사

항을 충족해야 합니다.

클라우드 네이티브 스토리지 요구 사항

n vSphere 6.7 업데이트 3 이상.

n Kubernetes 버전 1.14 이상.

n 가상 시스템에 하나의 master 노드와 여러 worker 노드가 배포되어 있는 Kubernetes 클러스터.

노드를 여러 데이터 센터 및 클러스터에 배포할 수 있습니다.

Kubernetes 클러스터 가상 시스템에 대한 요구 사항

n 하드웨어 버전 15 이상의 가상 시스템. 각 노드 가상 시스템에 VMware Tools를 설치합니다.

n 권장되는 게스트 운영 체제:

n Ubuntu 18.04.1 LTS(Bionic Beaver) 64비트 PC(AMD64) 서버. 자세한 내용은 http://

partnerweb.vmware.com/GOSIG/Ubuntu_18_04_LTS.html 항목을 참조하십시오.

n 가상 시스템 하드웨어 권장 사항:

n 워크로드 요구 사항에 따라 적절하게 CPU 및 메모리를 설정합니다.

n 노드 VM의 기본 디스크에 대해 VMware 반가상화 SCSI 컨트롤러를 사용합니다.

n 모든 가상 시스템은 vSAN과 같은 공유 데이터스토어에 액세스할 수 있어야 합니다.

n 각 노드 VM에서 disk.EnableUUID 매개 변수를 설정합니다. Kubernetes 클러스터 가상 시스템 구

성를 참조하십시오.

n 오류와 예측할 수 없는 동작을 방지하려면 CNS 노드 VM의 스냅샷을 생성하지 마십시오.


VMware, Inc. 10

http://partnerweb.vmware.com/GOSIG/Ubuntu_18_04_LTS.html

http://partnerweb.vmware.com/GOSIG/Ubuntu_18_04_LTS.html

Docker 이미지

VMware는 다음과 같은 이미지를 배포하고 권장합니다.

n vmware/vsphere-block-csi-driver:v1.0.0

n vmware/volume-metadata-syncer:v1.0.0

n gcr.io/cloud-provider-vsphere/vsphere-cloud-controller-manager:latest

또한 다음과 같은 이미지나 CSI 배포에 적합한 오픈 소스 또는 상업적으로 사용 가능한 컨테이너 이미

지를 사용할 수 있습니다.

n quay.io/k8scsi/csi-provisioner:v1.2.0

n quay.io/k8scsi/csi-attacher:v1.1.1

n quay.io/k8scsi/csi-node-driver-registrar:v1.1.0

n quay.io/k8scsi/livenessprobe:v1.1.0

n k8s.gcr.io/kube-apiserver:v1.14.2

n k8s.gcr.io/kube-controller-manager:v1.14.2

n k8s.gcr.io/kube-scheduler:v1.14.2

n k8s.gcr.io/kube-proxy:v1.14.2

n k8s.gcr.io/pause:3.1

n k8s.gcr.io/etcd:3.3.10

n k8s.gcr.io/coredns:1.5.0

클라우드 네이티브 스토리지 역할 및 권한

클라우드 네이티브 스토리지와 관련된 작업을 수행하려면 vSphere 사용자에게 특정 권한이 있어야 합

니다.

몇 가지 역할을 생성하여 클라우드 네이티브 스토리지 환경에 참여하는 개체에 대한 일련의 사용 권한

을 할당할 수 있습니다.

vSphere의 역할 및 사용 권한과 역할을 생성하는 방법에 대한 자세한 내용은 "vSphere 보안" 설명서

를 참조하십시오.

역할 이름 권한 이름 설명 필요한 위치

CNS-SPBM Profile-Driven Storage > Profile-Driven

Storage 업데이트

VM 스토리지 정책을 변경할

수 있습니다(예: 스토리지

VM 스토리지 정책 생성 및

업데이트).

루트 vCenter Server

Profile-Driven Storage > Profile-Driven

Storage 보기

정의된 스토리지 정책을 볼

수 있습니다.

CNS-VM 가상 시스템 > 구성 > 기존 디스크 추가 가상 시스템에 기존 가상 디

스크를 추가할 수 있습니다.

모든 클러스터 노드 VM


VMware, Inc. 11

역할 이름 권한 이름 설명 필요한 위치

가상 시스템 > 구성 > 디바이스 추가 또는 제

거

디스크가 아닌 디바이스를 추

가하거나 제거할 수 있습니

다.

CNS-

Datastore

데이터스토어 > 하위 수준 파일 작업 데이터스토어 브라우저에서

읽기, 쓰기, 삭제 및 이름 변

경 작업을 수행할 수 있습니

다.

영구 볼륨이 상주하는 공유 데

이터스토어

읽기 전용 기본 역할 개체에 대해 읽기 전용 역할

을 가진 사용자는 개체의 상

태 및 개체에 대한 세부 정보

를 볼 수 있습니다. 예를 들

어 이 역할을 가진 사용자는

모든 노드 VM에서 액세스할

수 있는 공유 데이터스토어를

찾을 수 있습니다.

영역 및 토폴로지 인식 환경

의 경우, 노드 VM의 모든 상

위 항목(예: 호스트, 클러스

터 및 데이터 센터)에는 CSI

드라이버와 CCM을 사용하도

록 구성된 vSphere 사용자

에 대한 읽기 전용 역할 설정

이 있어야 합니다. 노드 토폴

로지를 준비하기 위해 태그와

범주를 읽도록 허용하는 데

필요합니다.

노드 VM이 상주하는 모든 호

스트

데이터 센터

CNS UI privilege.Cns.label >

privilege.Cns.Searchable.label

스토리지 관리자가 CNS UI

를 볼 수 있습니다.


VMware, Inc. 12

Kubernetes 클러스터 설정 2영구 스토리지를 사용하는 상태 저장 애플리케이션은 Kubernetes 클러스터에서 실행됩니다.

Kubernetes 클러스터는 vSphere에서 관리되는 가상 시스템 위에 배포합니다. 클러스터에는 하나 이

상의 master 노드 VM과 여러 worker 노드가 포함됩니다.

Kubernetes 클러스터를 생성하기 전에 노드 가상 시스템을 구성해야 합니다.

그런 다음, 필요한 모든 Kubernetes 구성 요소와 컨테이너 런타임을 설치하고 vSphere Container

Storage Interface를 구성하고 클러스터를 부트스트랩합니다.


n Kubernetes 클러스터 가상 시스템 구성

n 노드 가상 시스템에 Kubernetes 구성 요소 설정

n master 노드 초기화

n worker 노드 초기화

n vSphere Cloud Controller Manager 설치

n vSphere Container Storage Interface 드라이버 설치

n 클러스터 설정 확인

n CCM 및 CSI 드라이버 설치 후 Kubernetes 노드 추가

Kubernetes 클러스터 가상 시스템 구성

각 노드 VM에서 VM이 가상 디스크를 성공적으로 마운트할 수 있도록 disk.EnableUUID 매개 변수를

사용하도록 설정합니다.

클러스터에 참여하는 각 VM 노드에 대해 다음 단계를 수행합니다.

사전 요구 사항

n Kubernetes 클러스터에 대해 VM을 여러 개 생성합니다. VM에 대해 k8s-master, k8s-node1,

k8s-nodeX 등과 같은 이름을 사용할 수 있습니다. VM 요구 사항은 클라우드 네이티브 스토리지

에 대한 요구 사항.

n 필요한 권한: 가상 시스템. 구성. 설정.

참고 오류와 예측할 수 없는 동작을 방지하려면 CNS 노드 VM의 스냅샷을 생성하지 마십시오.

VMware, Inc. 13

절차

1 vSphere Client에서 가상 시스템을 마우스 오른쪽 버튼으로 클릭하고 설정 편집을 선택합니다.

2 VM 옵션 탭을 클릭하고 고급 메뉴를 확장합니다.

3 구성 매개 변수 옆의 구성 편집을 클릭합니다.

4 disk.EnableUUID 매개 변수를 구성합니다.

매개 변수가 있으면 해당 값이 True로 설정되어 있는지 확인합니다. 매개 변수가 없으면 추가하고

해당 값을 True로 설정합니다.

이름 값

disk.EnableUUID True

노드 가상 시스템에 Kubernetes 구성 요소 설정

노드 VM에 컨테이너 런타임과 기타 Kubernetes 구성 요소를 설치합니다.

이 작업에서는 Ubuntu에 Docker CE를 설치하는 방법을 보여줍니다. 다음 구성 요소를 설치하는 방

법도 보여줍니다.

n kubeadm은 클러스터를 부트스트랩하는 명령입니다. master 및 모든 worker 노드에서 실행됩니다.

n kubelet은 클러스터의 모든 노드에서 실행되며 포드 및 컨테이너 시작과 같은 작업을 수행하는 구

성 요소입니다.

n kubectl은 클러스터와 통신하는 명령줄 유틸리티입니다. master 노드에서만 실행됩니다.


root 권한으로 모든 설치 및 구성 명령을 실행합니다. sudo su 명령을 사용하여 루트 환경으로 전환할

수 있습니다.

절차

1 모든 클러스터 노드에서 스왑를 사용하지 않도록 설정합니다.

# swapoff -a

# vi /etc/fstab # remove any swap entries from this file


VMware, Inc. 14

2 모든 클러스터 노드에 Docker를 설치합니다.

a Docker CE를 설치합니다.

특정 버전을 설치하려면 버전 문자열을 버전 번호(예: 18.06.0~ce~3-0~ubuntu)로 바꿉니다.

# apt update

# apt install apt-transport-https ca-certificates curl software-properties-common

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

# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"

# apt-get update

# apt-get install docker-ce=버전_문자열

b 데몬을 설정합니다.

cat > /etc/docker/daemon.json <<EOF

{

"exec-opts": ["native.cgroupdriver=systemd"],

"log-driver": "json-file",

"log-opts": {

"max-size": "100m"

},

"storage-driver": "overlay2"

}

EOF

mkdir -p /etc/systemd/system/docker.service.d

c Docker를 다시 시작합니다.

# systemctl daemon-reload

# systemctl restart docker

3 모든 노드에 kubeadm, kubelet 및 kubectl을 설치합니다.

적절한 버전의 패키지를 설치해야 합니다. 이 예제에서는 Ubuntu 버전 1.14.2-00이 사용되었습

니다.

# 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 https://apt.kubernetes.io/ kubernetes-xenial main

EOF

# apt-get update

# apt-get install -qy kubeadm=1.14.2-00 kubelet=1.14.2-00 kubectl=1.14.2-00

master 노드 초기화

VM 클러스터의 master 노드를 설정합니다.


VMware, Inc. 15

절차

1 master 노드에 대한 kubeadm init 구성 파일을 생성합니다.

파일에 대한 토큰을 생성하는 관한 자세한 정보는 Kubernetes 설명서를 참조하십시오.

cloud-provider를 external로 지정합니다.

# tee /etc/kubernetes/kubeadminitmaster.yaml >/dev/null <<EOF

apiVersion: kubeadm.k8s.io/v1beta1

kind: InitConfiguration

bootstrapTokens:

- groups:

- system:bootstrappers:kubeadm:default-node-token

token: y7yaev.9dvwxx6ny4ef8vlq

ttl: 0s

usages:

- signing

- authentication

nodeRegistration:

kubeletExtraArgs:

cloud-provider: external

---


kind: ClusterConfiguration

useHyperKubeImage: false

kubernetesVersion: v1.14.2

networking:

serviceSubnet: "10.96.0.0/12"

podSubnet: "10.244.0.0/16"

etcd:

local:

imageRepository: "k8s.gcr.io"

imageTag: "3.3.10"

dns:

type: "CoreDNS"

imageRepository: "k8s.gcr.io"

imageTag: "1.5.0"

EOF

2 Kubernetes master 노드를 부트스트랩합니다.

앞서 생성한 kubeadm init 구성 파일을 사용하여 kubeadm init 명령을 실행합니다.

# kubeadm init --config /etc/kubernetes/kubeadminitmaster.yaml

...

Your Kubernetes master has initilized successfully!

...

You should now deploy a pod network to the cluster.

Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:

https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node

as root:

kubeadm join [IP of your Kubernetes master]:6443 --token y7yaev.9dvwxx6ny4ef8vlq --discovery-token-ca

-cert-hash sha256:[sha sum from output above]


VMware, Inc. 16

https://kubernetes.io/docs/home/

3 다음 명령을 실행하여 클러스터 사용을 시작합니다.

# mkdir -p $HOME/.kube

# cp /etc/kubernetes/admin.conf $HOME/.kube/config

이 단계에서 coredns 포드는 FailedScheduling 상태에서 보류 상태로 유지됩니다. 이 문제는

coredns 포드가 허용할 수 없는 taint가 노드에 있기 때문에 발생합니다. kubelet이 cloud-

provider: external 설정으로 시작되었기 때문에 이런 동작이 예상됩니다. vSphere Cloud

Controller Manager가 설치되고 노드가 초기화되면 taint가 노드에서 제거되고 coredns 포드에

대한 스케줄링이 진행됩니다.

# kubectl get pods --namespace=kube-system

NAME READY STATUS RESTARTS AGE

coredns-fb8b8dccf-q57f9 0/1 Pending 0 87s

coredns-fb8b8dccf-scgp2 0/1 Pending 0 87s

etcd-k8s-master 1/1 Running 0 54s

kube-apiserver-k8s-master 1/1 Running 0 39s

kube-controller-manager-k8s-master 1/1 Running 0 54s

kube-proxy-rljk8 1/1 Running 0 87s

kube-scheduler-k8s-master 1/1 Running 0 37s

# kubectl describe pod coredns-fb8b8dccf-q57f9 --namespace=kube-system

.

.

Events:

Type Reason Age From Message

---- ------ ---- ---- -------

Warning FailedScheduling 7s (x21 over 2m1s) default-scheduler 0/1 nodes are available: 1 node(s) had

taints that the pod didn't tolerate.

4 포드가 서로 통신할 수 있도록 Flannel 포드 오버레이 네트워킹을 설치합니다.

Flannel이 아닌 포드 네트워크를 설치하려면 의 지침을 따르십시오.

# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/

Documentation/kube-flannel.yml

5 worker 노드에 제공할 master 노드 구성을 내보냅니다.

# kubectl -n kube-public get configmap cluster-info -o jsonpath='{.data.kubeconfig}' > discovery.yaml

6 discovery.yaml 파일을 로컬에서 복사한 다음 worker 노드의 /etc/kubernetes/discovery.yaml에

업로드합니다.

worker 노드 초기화

VM 클러스터 worker 노드를 초기화하여 클러스터에 추가합니다.

worker 노드에서 이 작업을 수행합니다.


VMware, Inc. 17

https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network

절차

1 worker 노드에 대한 kubeadm join 구성 파일을 생성합니다.

이 파일은 discovery.yaml 파일을 마스터 검색의 입력으로 사용합니다. 토큰은 마스터

kubeadminitmaster.yaml 구성에 사용한 것과 동일합니다. 작업자의 경우 클라우드 제공자를

external로 지정합니다.

# tee /etc/kubernetes/kubeadminitworker.yaml >/dev/null <<EOF


caCertPath: /etc/kubernetes/pki/ca.crt

discovery:

file:

kubeConfigPath: /etc/kubernetes/discovery.yaml

timeout: 5m0s

tlsBootstrapToken: y7yaev.9dvwxx6ny4ef8vlq

kind: JoinConfiguration

nodeRegistration:

criSocket: /var/run/dockershim.sock

kubeletExtraArgs:


EOF

2 작업자를 클러스터에 추가합니다.

# kubeadm join --config /etc/kubernetes/kubeadminitworker.yaml

vSphere Cloud Controller Manager 설치

vSphere Cloud Controller Manager를 사용하여 실행할 노드 VM을 구성합니다.

참고 배포에서 영역을 사용하려면 장 5 여러 데이터 센터나 클러스터가 있는 환경에서 CCM과 CSI

배포 항목을 참조하십시오.


클라우드 네이티브 스토리지에 대한 요구 사항의 요구 사항을 준수합니다.


VMware, Inc. 18

절차

1 master 노드에서 vSphere 구성의 configmap cloud-config를 생성합니다.

다음 예에서는 vsphere.conf 파일에 vCenter Server 자격 증명을 저장하는 방법을 보여줍니다.

참고 Cloud Controller Manager에 대한 vCenter Server 자격 증명을 Kubernetes 암호에 저

장할 수 있습니다. https://github.com/kubernetes/cloud-provider-vsphere/blob/master/

docs/book/tutorials/deploying_cloud_provider_vsphere_with_rbac.md#3-optional-but-

recommended-storing-vcenter-credentials-in-a-kubernetes-secret의 지침을 따르십시오.

a configmap cloud-config vsphere.conf 파일을 정의합니다.

구성 파일은 kubelet, controller-manager 및 API 서버에서 액세스할 수 있는 공유 디렉토리

에 배치해야 합니다. 파일에서 다음과 같은 vCenter Server 세부 정보를 지정합니다.

옵션 설명

insecure-flag CCM이 vCenter Server에서 SSL 인증서를 확인할 필요가 없으면 true로

설정합니다.

user vSphere 클라우드 제공자에 대해 vCenter Server 사용자 이름을 사용합니

다.

password 적절한 vCenter Server 사용자 암호를 사용합니다.

port vCenter Server 포트를 사용합니다. 기본 포트는 443입니다.

datacenters Kubernetes 노드 VM이 있는 데이터 센터를 쉼표로 구분하여 나열합니다.

public-network 노드 VM에서 공개적으로 액세스할 수 있는 네트워크 인터페이스의 네트워크

스위치 이름으로 설정합니다.

tee /etc/kubernetes/vsphere.conf >/dev/null <<EOF

[Global]

insecure-flag = "true"

[VirtualCenter "vCenter Server IP address"]

user = "user"

password = "password"

port = "443"

datacenters = "datacenter"

[Network]

public-network = "VM Network"

EOF

b 설정의 configmap cloud-config를 생성합니다.

# cd /etc/kubernetes

kubectl create configmap cloud-config --from-file=vsphere.conf --namespace=kube-system


VMware, Inc. 19

https://github.com/kubernetes/cloud-provider-vsphere/blob/master/docs/book/tutorials/deploying_cloud_provider_vsphere_with_rbac.md#3-optional-but-recommended-storing-vcenter-credentials-in-a-kubernetes-secret



c configmap cloud-config가 kube-system 네임스페이스에 성공적으로 생성되었는지 확인합니

다.

# kubectl get configmap cloud-config --namespace=kube-system

NAME DATA AGE

cloud-config 1 82s

d /etc/kubernetes/에 생성된 vsphere.conf 파일을 제거합니다.

# rm -rf /etc/kubernetes/vsphere.conf

2 vSphere Cloud Controller Manager를 설치합니다.

a 모든 노드가 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule로 taint되었

는지 확인합니다.

kubelet이 외부 클라우드 공급자를 통해 시작되면 이 taint가 노드에 설정되어 사용할 수 없는

것으로 표시됩니다. Cloud Controller Manager의 컨트롤러가 이 노드를 초기화하면 kubelet

이 taint를 제거합니다.

# kubectl describe nodes | egrep "Taints:|Name:"

Name: k8s-master

Taints: node-role.kubernetes.io/master:NoSchedule

Name: k8s-node1

Taints: node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

Name: k8s-node2


Name: k8s-node3


Name: k8s-node4


b vSphere Cloud Controller Manager를 설치합니다.

다음 예는 RBAC 역할 및 RBCA 바인딩을 Kubernetes 클러스터에 적용하는 방법을 보여줍

니다. DaemonSet에 Cloud Controller Manager를 배포하는 방법도 보여줍니다.

# kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/

controller-manager/cloud-controller-manager-roles.yaml

clusterrole.rbac.authorization.k8s.io/system:cloud-controller-manager created

# kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/

controller-manager/cloud-controller-manager-role-bindings.yaml

clusterrolebinding.rbac.authorization.k8s.io/system:cloud-controller-manager created

# kubectl apply -f https://github.com/kubernetes/cloud-provider-vsphere/raw/master/manifests/controller-

manager/vsphere-cloud-controller-manager-ds.yaml

serviceaccount/cloud-controller-manager created

daemonset.extensions/vsphere-cloud-controller-manager created

service/vsphere-cloud-controller-manager created


VMware, Inc. 20

https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-roles.yaml

https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-roles.yaml

https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml

https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml

https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/vsphere-cloud-controller-manager-ds.yaml

https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/vsphere-cloud-controller-manager-ds.yaml

3 vSphere Cloud Controller Manager가 성공적으로 설치되었는지 확인합니다.

a vSphere Cloud Controller Manager와 다른 모든 시스템 포드가 작동 중인지 확인합니다.



coredns-fb8b8dccf-bq7qq 1/1 Running 0 71m

coredns-fb8b8dccf-r47q2 1/1 Running 0 71m

etcd-k8s-master 1/1 Running 0 69m

kube-apiserver-k8s-master 1/1 Running 0 70m

kube-controller-manager-k8s-master 1/1 Running 0 69m

kube-flannel-ds-amd64-7kmk9 1/1 Running 0 38m

kube-flannel-ds-amd64-dtvbg 1/1 Running 0 63m

kube-flannel-ds-amd64-hq57c 1/1 Running 0 30m

kube-flannel-ds-amd64-j7g4s 1/1 Running 0 22m

kube-flannel-ds-amd64-q4zsn 1/1 Running 0 21m

kube-proxy-6jcng 1/1 Running 0 30m

kube-proxy-bh8kh 1/1 Running 0 21m

kube-proxy-rb9xp 1/1 Running 0 22m

kube-proxy-srhpj 1/1 Running 0 71m

kube-proxy-vh4lg 1/1 Running 0 38m

kube-scheduler-k8s-master 1/1 Running 0 70m

vsphere-cloud-controller-manager-549hb 1/1 Running 0 25s

b 등록된 모든 노드에 ProviderID가 설정되어 있는지 확인합니다.

# kubectl describe nodes | grep ProviderID

ProviderID: vsphere://421f0831-7a05-fe2d-b5ea-78e27585b508

ProviderID: vsphere://421f802f-87f8-aec9-0d07-b5f16de582ed

ProviderID: vsphere://421f1563-a7c0-4569-d5ce-7e93c4d29d1c

ProviderID: vsphere://421ff393-fe0c-577f-8a08-1d52184e5a1c

ProviderID: vsphere://421fb2db-467b-b994-c5ca-bd1788f544ec

c node.cloudprovider.kubernetes.io/uninitialized 매개 변수가 모든 노드에서 제거되었는지

확인합니다.

# kubectl describe nodes | egrep "Taints:|Name:"

Name: k8s-master

Taints: node-role.kubernetes.io/master:NoSchedule

Name: k8s-node1

Taints: <none>

Name: k8s-node2

Taints: <none>

Name: k8s-node3

Taints: <none>

Name: k8s-node4

Taints: <none>


VMware, Inc. 21

vSphere Container Storage Interface 드라이버 설치

vSphere CSI(Container Storage Interface) 드라이버를 구성하고 설치합니다.

참고 배포에서 영역을 사용하려면 장 5 여러 데이터 센터나 클러스터가 있는 환경에서 CCM과 CSI

배포 항목을 참조하십시오.


master 노드가 node-role.kubernetes.io/master=:NoSchedule로 taint되었는지 확인합니다.

kubectl taint nodes k8s-master node-role.kubernetes.io/master=:NoSchedule

master 노드에서 vsphere-csi-node daemonset에 대한 노드 플러그인 포드의 스케줄링을 방지하려

면 master 노드에 taint가 있어야 합니다.


VMware, Inc. 22

절차

1 master 노드에서 CSI 드라이버에 대한 자격 증명 암호를 생성합니다.

일반 텍스트로 된 사용자 이름과 암호 대신 인증서와 개인 키를 사용하는 방법에 대한 자세한 내용

은 인증서를 사용하여 vCenter Server 연결 보호 항목을 참조하십시오.

a 자격 증명 암호 vsphere.conf 파일을 정의합니다.

파일에서 다음과 같은 vCenter Server 세부 정보를 지정합니다.

옵션 설명

cluster-id 고유한 클러스터 식별자를 지정합니다.

참고 vCenter Server에 배포된 각 Kubernetes 클러스터에는 고유한 클러

스터 ID가 있어야 합니다. 그렇지 않으면 클러스터에 예기치 않은 문제가 발

생할 수 있습니다.

클러스터 이름과 UUID를 조합하면 Kubernetes 클러스터를 식별하고 고유성

을 보장하는 데 유용합니다. 예:

ProductionTestDev-7f1f6573-6de2-4349-a489-676a4100fde2 또는

StagingTestDev-9e819595-59e9-43a5-85e9-1d0cc179651d 등.

insecure-flag CSI 드라이버가 vCenter Server에서 SSL 인증서를 확인할 필요가 없으면

true로 설정합니다.

CSI 드라이버가 vCenter Server에서 SSL 인증서를 확인해야 하는 경우에는

false로 설정합니다. 자세한 내용은 인증서를 사용하여 vCenter Server 연결

보호 항목을 참조하십시오.

user vSphere 클라우드 제공자에 대해 vCenter Server 사용자 이름을 사용합니

다.

또는 사용자 이름을 인증서로 지정할 수 있습니다. 자세한 내용은 인증서를

사용하여 vCenter Server 연결 보호 항목을 참조하십시오.

password 적절한 vCenter Server 사용자 암호를 사용하거나 개인 키로 지정합니다. 자

세한 내용은 인증서를 사용하여 vCenter Server 연결 보호 항목을 참조하십

시오.

port vCenter Server 포트를 사용합니다. 기본 포트는 443입니다.

datacenters Kubernetes 노드 VM이 있는 데이터 센터를 쉼표로 구분하여 나열합니다.

# tee /etc/kubernetes/csi-vsphere.conf >/dev/null <<EOF

[Global]

cluster-id = "cluster-id"

[VirtualCenter "vCenter Server IP address"]


user = "user"


VMware, Inc. 23

password = "password"

port = "443"


EOF

b 자격 증명 암호를 생성합니다.

# kubectl create secret generic vsphere-config-secret --from-file=csi-vsphere.conf --namespace=kube-

system

c 자격 증명 암호가 kube-system 네임스페이스에 성공적으로 생성되었는지 확인합니다.

# kubectl get secret vsphere-config-secret --namespace=kube-system

NAME TYPE DATA AGE

vsphere-config-secret Opaque 1 43s

d /etc/kubernetes/에 생성된 csi-vsphere.conf 파일을 제거합니다.

# rm -rf /etc/kubernetes/csi-vsphere.conf

2 vSphere CSI 드라이버에 필요한 모든 구성 요소를 배포합니다.

tee csi-driver-rbac.yaml >/dev/null <<EOF

kind: ServiceAccount

apiVersion: v1

metadata:

name: vsphere-csi-controller

namespace: kube-system

---

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

name: vsphere-csi-controller-role

rules:

- apiGroups: [""]

resources: ["secrets"]

verbs: ["get", "list", "watch"]

- apiGroups: ["storage.k8s.io"]

resources: ["csidrivers"]

verbs: ["create", "delete"]

- apiGroups: [""]

resources: ["nodes"]


- apiGroups: [""]

resources: ["persistentvolumes"]

verbs: ["get", "list", "watch", "update", "create", "delete"]


resources: ["csinodes"]



resources: ["volumeattachments"]

verbs: ["get", "list", "watch", "update"]

- apiGroups: [""]

resources: ["persistentvolumeclaims"]


VMware, Inc. 24

verbs: ["get", "list", "watch", "update"]


resources: ["storageclasses"]


- apiGroups: [""]

resources: ["events"]

verbs: ["list", "watch", "create", "update", "patch"]

- apiGroups: ["snapshot.storage.k8s.io"]

resources: ["volumesnapshots"]

verbs: ["get", "list"]

- apiGroups: ["snapshot.storage.k8s.io"]

resources: ["volumesnapshotcontents"]

verbs: ["get", "list"]

- apiGroups: [""]

resources: ["pods"]


---

kind: ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

name: vsphere-csi-controller-binding

subjects:

- kind: ServiceAccount



roleRef:

kind: ClusterRole

name: vsphere-csi-controller-role

apiGroup: rbac.authorization.k8s.io

---

EOF

# kubectl create -f csi-driver-rbac.yaml

serviceaccount/vsphere-csi-controller created

clusterrole.rbac.authorization.k8s.io/vsphere-csi-controller-role created

clusterrolebinding.rbac.authorization.k8s.io/vsphere-csi-controller-binding created

3 vSphere CSI 드라이버를 설치합니다.

tee csi-driver-deploy.yaml >/dev/null <<'EOF'

kind: StatefulSet

apiVersion: apps/v1

metadata:



spec:

serviceName: vsphere-csi-controller

replicas: 1

updateStrategy:

type: "RollingUpdate"

selector:

matchLabels:

app: vsphere-csi-controller


VMware, Inc. 25

template:

metadata:

labels:

app: vsphere-csi-controller

role: vsphere-csi

spec:

serviceAccountName: vsphere-csi-controller

nodeSelector:

node-role.kubernetes.io/master: ""

tolerations:

- operator: "Exists"

key: node-role.kubernetes.io/master

effect: NoSchedule

hostNetwork: true

containers:

- name: csi-attacher

image: quay.io/k8scsi/csi-attacher:v1.1.1

args:

- "--v=4"

- "--timeout=60s"

- "--csi-address=$(ADDRESS)"

env:

- name: ADDRESS

value: /csi/csi.sock

volumeMounts:

- mountPath: /csi

name: socket-dir

- name: vsphere-csi-controller

image: vmware/vsphere-block-csi-driver:v1.0.0

lifecycle:

preStop:

exec:

command: ["/bin/sh", "-c", "rm -rf /var/lib/csi/sockets/pluginproxy/

block.vsphere.csi.vmware.com"]

args:

- "--v=4"

imagePullPolicy: "Always"

env:

- name: CSI_ENDPOINT

value: unix:///var/lib/csi/sockets/pluginproxy/csi.sock

- name: X_CSI_MODE

value: "controller"

- name: X_CSI_VSPHERE_CLOUD_CONFIG

value: "/etc/cloud/csi-vsphere.conf"

volumeMounts:

- mountPath: /etc/cloud

name: vsphere-config-volume

readOnly: true

- mountPath: /var/lib/csi/sockets/pluginproxy/

name: socket-dir

- name: liveness-probe

image: quay.io/k8scsi/livenessprobe:v1.1.0

args:


env:


VMware, Inc. 26

- name: ADDRESS

value: /var/lib/csi/sockets/pluginproxy/csi.sock

volumeMounts:

- mountPath: /var/lib/csi/sockets/pluginproxy/

name: socket-dir

- name: vsphere-syncer

image: vmware/volume-metadata-syncer:v1.0.0

args:

- "--v=2"


env:

- name: X_CSI_FULL_SYNC_INTERVAL_MINUTES

value: "30"



volumeMounts:

- mountPath: /etc/cloud

name: vsphere-config-volume

readOnly: true

- name: csi-provisioner

image: quay.io/k8scsi/csi-provisioner:v1.2.1

args:

- "--v=4"

- "--timeout=60s"


- "--feature-gates=Topology=true"

- "--strict-topology"

env:

- name: ADDRESS


volumeMounts:

- mountPath: /csi

name: socket-dir

volumes:

- name: vsphere-config-volume

secret:

secretName: vsphere-config-secret

- name: socket-dir

hostPath:

path: /var/lib/csi/sockets/pluginproxy/block.vsphere.csi.vmware.com

type: DirectoryOrCreate

---

apiVersion: storage.k8s.io/v1beta1

kind: CSIDriver

metadata:

name: block.vsphere.csi.vmware.com

spec:

attachRequired: true

podInfoOnMount: false

---

kind: DaemonSet

apiVersion: apps/v1

metadata:

name: vsphere-csi-node



VMware, Inc. 27

spec:

selector:

matchLabels:

app: vsphere-csi-node

updateStrategy:

type: "RollingUpdate"

template:

metadata:

labels:

app: vsphere-csi-node

role: vsphere-csi

spec:

hostNetwork: true

containers:

- name: node-driver-registrar

image: quay.io/k8scsi/csi-node-driver-registrar:v1.1.0

lifecycle:

preStop:

exec:

command: ["/bin/sh", "-c", "rm -rf /registration/block.vsphere.csi.vmware.com /var/lib/

kubelet/plugins_registry/block.vsphere.csi.vmware.com /var/lib/kubelet/plugins_registry/

block.vsphere.csi.vmware.com-reg.sock"]

args:

- "--v=4"


- "--kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)"

env:

- name: ADDRESS


- name: DRIVER_REG_SOCK_PATH

value: /var/lib/kubelet/plugins_registry/block.vsphere.csi.vmware.com/csi.sock

securityContext:

privileged: true

volumeMounts:

- name: plugin-dir

mountPath: /csi

- name: registration-dir

mountPath: /registration

- name: vsphere-csi-node

image: vmware/vsphere-block-csi-driver:v1.0.0


env:

- name: CSI_ENDPOINT

value: unix:///csi/csi.sock

- name: X_CSI_MODE

value: "node"

- name: X_CSI_SPEC_REQ_VALIDATION

value: "false"



args:

- "--v=4"

securityContext:

privileged: true

capabilities:


VMware, Inc. 28

add: ["SYS_ADMIN"]

allowPrivilegeEscalation: true

volumeMounts:


mountPath: /etc/cloud

- name: plugin-dir

mountPath: /csi

- name: pods-mount-dir

mountPath: /var/lib/kubelet

# needed so that any mounts setup inside this container are

# propagated back to the host machine.

mountPropagation: "Bidirectional"

- name: device-dir

mountPath: /dev

- name: liveness-probe

image: quay.io/k8scsi/livenessprobe:v1.1.0

args:


env:

- name: ADDRESS


volumeMounts:

- name: plugin-dir

mountPath: /csi

volumes:


secret:

secretName: vsphere-config-secret

- name: registration-dir

hostPath:

path: /var/lib/kubelet/plugins_registry


- name: plugin-dir

hostPath:

path: /var/lib/kubelet/plugins_registry/block.vsphere.csi.vmware.com


- name: pods-mount-dir

hostPath:

path: /var/lib/kubelet

type: Directory

- name: device-dir

hostPath:

path: /dev

---

EOF

# kubectl create -f csi-driver-deploy.yaml

statefulset.apps/vsphere-csi-controller created

csidriver.storage.k8s.io/block.vsphere.csi.vmware.com created

daemonset.apps/vsphere-csi-node created


VMware, Inc. 29

4 vSphere CSI 드라이버 설치를 확인합니다.

드라이버와 해당 구성 요소가 설치되어 있는지 확인합니다.

a vsphere-csi-node가 모든 노드에서 실행 중인지 확인합니다.

# kubectl get statefulset --namespace=kube-system

NAME READY AGE

vsphere-csi-controller 1/1 2m58s

# kubectl get daemonsets vsphere-csi-node --namespace=kube-system

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE

vsphere-csi-node 4 4 4 4 4 <none> 3m51s



coredns-fb8b8dccf-bq7qq 1/1 Running 0 3h

coredns-fb8b8dccf-r47q2 1/1 Running 0 3h




kube-flannel-ds-amd64-7kmk9 1/1 Running 0 147m

kube-flannel-ds-amd64-dtvbg 1/1 Running 0 173m

kube-flannel-ds-amd64-hq57c 1/1 Running 0 140m

kube-flannel-ds-amd64-j7g4s 1/1 Running 0 131m

kube-flannel-ds-amd64-q4zsn 1/1 Running 0 131m

kube-proxy-6jcng 1/1 Running 0 140m

kube-proxy-bh8kh 1/1 Running 0 131m

kube-proxy-rb9xp 1/1 Running 0 131m

kube-proxy-srhpj 1/1 Running 0 3h

kube-proxy-vh4lg 1/1 Running 0 147m


vsphere-cloud-controller-manager-549hb 1/1 Running 0 110m

vsphere-csi-controller-0 5/5 Running 0 4m18s

vsphere-csi-node-m4kj8 3/3 Running 0 4m18s

vsphere-csi-node-mhzzj 3/3 Running 0 4m18s

vsphere-csi-node-tgs7p 3/3 Running 0 4m18s

vsphere-csi-node-zll7c 3/3 Running 0 4m18s

b CSI 드라이버가 성공적으로 배포되었는지 확인합니다.

# kubectl get CSINode

NAME CREATED AT

k8s-node1 2019-06-01T00:50:26Z

k8s-node2 2019-06-01T00:50:38Z

k8s-node3 2019-06-01T00:50:26Z

k8s-node4 2019-06-01T00:50:25Z

# kubectl describe CSINode

Name: k8s-node1

Namespace:

Labels: <none>

Annotations: <none>


VMware, Inc. 30

API Version: storage.k8s.io/v1beta1

Kind: CSINode

Metadata:

Creation Timestamp: 2019-06-01T00:50:26Z

Owner References:

API Version: v1

Kind: Node

Name: k8s-node1

UID: 31fc47ad-83f3-11e9-91d9-0050569f50b7

Resource Version: 20765

Self Link: /apis/storage.k8s.io/v1beta1/csinodes/k8s-node1

UID: 3eb6cfcb-8407-11e9-91d9-0050569f50b7

Spec:

Drivers:

Name: block.vsphere.csi.vmware.com

Node ID: k8s-node1

Topology Keys: <nil>

Events: <none>

Name: k8s-node2

Namespace:

Labels: <none>

Annotations: <none>


Kind: CSINode

Metadata:


Owner References:

API Version: v1

Kind: Node

Name: k8s-node2

UID: 2efcb8e9-83f4-11e9-91d9-0050569f50b7



UID: 461d3184-8407-11e9-91d9-0050569f50b7

Spec:

Drivers:


Node ID: k8s-node2


Events: <none>

Name: k8s-node3

Namespace:

Labels: <none>

Annotations: <none>


Kind: CSINode

Metadata:


Owner References:

API Version: v1

Kind: Node


VMware, Inc. 31

Name: k8s-node3

UID: 6c7ddc6b-83f5-11e9-91d9-0050569f50b7



UID: 3e85c4ca-8407-11e9-91d9-0050569f50b7

Spec:

Drivers:


Node ID: k8s-node3


Events: <none>

Name: k8s-node4

Namespace:

Labels: <none>

Annotations: <none>


Kind: CSINode

Metadata:


Owner References:

API Version: v1

Kind: Node

Name: k8s-node4

UID: 7b45e01c-83f5-11e9-91d9-0050569f50b7



UID: 3e0324c9-8407-11e9-91d9-0050569f50b7

Spec:

Drivers:


Node ID: k8s-node4


Events: <none>

# kubectl get csidrivers

NAME CREATED AT

block.vsphere.csi.vmware.com 2019-06-01T00:50:14Z

# kubectl describe csidrivers


Namespace:

Labels: <none>

Annotations: <none>


Kind: CSIDriver

Metadata:



Self Link: /apis/storage.k8s.io/v1beta1/csidrivers/block.vsphere.csi.vmware.com

UID: 37c52534-8407-11e9-91d9-0050569f50b7


VMware, Inc. 32

Spec:

Attach Required: true

Pod Info On Mount: false

Events: <none

인증서를 사용하여 vCenter Server 연결 보호

vSphere CSI 드라이버에 대한 암호를 생성할 때 vCenter Server 자격 증명을 제공해야 CSI 드라이

버가 vCenter Server에 대한 연결을 설정할 수 있습니다. 일반 텍스트로 된 자격 증명을 사용하지 않

으려면 인증서와 개인 키를 사용하면 됩니다.

자격 증명 암호 생성에 대한 자세한 내용은 vSphere Container Storage Interface 드라이버 설치

항목을 참조하십시오.

다음 예에서는 vCenter Server와 CSI 드라이버 포드 간에 연결을 설정하기 위해 vpxd 사용자 인증서

와 개인 키를 설정하는 방법을 보여줍니다. vpxd 사용자 대신 필요한 권한이 있는 새 사용자를 생성하

고 해당 인증서와 키를 사용할 수 있습니다.

절차

1 vCenter Server에 SSH를 실행하고 vpxd 사용자 인증서 및 개인 키를 가져옵니다.

$ /usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store vpxd --alias vpxd --output vpxd.crt

$ /usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store vpxd --alias vpxd --output vpxd.key

2 다음 예제와 같이 인증서 및 키 파일의 줄 바꿈을 \n으로 바꿉니다. 검색된 문자열을 사용자 이름

및 암호로 사용합니다.

$ # awk '{printf "%s\\n", $0}' vpxd.crt

-----BEGIN CERTIFICATE-----\nMIIEjzCCA3egAwIBAgIJANc4yqDsTx+zMA0GCSqGSIb3DQEBCwUAMIGuMQswCQYD

\nVQQDDAJDQTEXMBUGCgmSJomT8ixkARkWB3ZzcGhlcmUxFTATBgoJkiaJk/IsZAEZ

\nFgVsb2NhbDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExMDAuBgNV

\nBAoMJ3NjLXJkb3BzLXZtMDMtZGhjcC05MC0yMi5lbmcudm13YXJlLmNvbTEbMBkG

\nA1UECwwSVk13YXJlIEVuZ2luZWVyaW5nMB4XDTE5MDcxNzAwMTYwMVoXDTI5MDcx

\nMTAwMjUxMVowfzENMAsGA1UEAwwEdnB4ZDEXMBUGCgmSJomT8ixkARkWB3ZzcGhl\ncmUxFTATBgoJkiaJk/

IsZAEZFgVsb2NhbDELMAkGA1UEBhMCVVMxMTAvBgNVBAsM

\nKG1JRC05Y2IxNjk5Ny1mODQzLTQxYmEtYTUzYy1kYTUzZGE3YTQyNzkwggEiMA0G

\nCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAFG6piTTVxG/mu5quzglDaAPElQwS\nauDn9DLRF/

rDUqrBqn01MgZJvojX6HPNBvzTqo/ik/j9mEu5opzEMUFG8jD39sK0\nd0BF/WK7U59SEw7z7/Bdim6tQHYFvqcbruf72u9FE2/

R8SdghAr9ZiYpFn/GgYbG\n961vkUBmdUhVEzTHcxZV++nmn2AnJ3xxDjHcv0vkqgk3QlpDLp5CjKnNc9AYK6pB\n6cYQCIDHaRjmTFv/

Ugoy1qrQfLnYR7YUHlzobxIdqdIlVNtjhipbJ+59IMOhbkpT\nN5iQAtD8zLgSbM6VeKUFU98IynhLZa28K79KpDJLM5m/efKS6oLGl

+xZAgMBAAGj\ngd0wgdowCwYDVR0PBAQDAgXgMDIGA1UdEQQrMCmCJ3NjLXJkb3BzLXZtMDMtZGhj

\ncC05MC0yMi5lbmcudm13YXJlLmNvbTAdBgNVHQ4EFgQURlLfiEhmgWPgS93/mUBK\nMnFZenEwHwYDVR0jBBgwFoAUg/kOFBRc

+2Ahi60D5e7ExYguA84wVwYIKwYBBQUH

\nAQEESzBJMEcGCCsGAQUFBzAChjtodHRwczovL3NjLXJkb3BzLXZtMDMtZGhjcC05\nMC0yMi5lbmcudm13YXJlLmNvbS9hZmQvdmVjcy9jY

TANBgkqhkiG9w0BAQsFAAOC\nAQEAnoTu2XwNUEPqJLAkYQkBogKeEN3+ZF/VTNfWSQl7CQsQNbA+LQPDIl/mLf90\nWaok+CmuzKKakD5/

bCT3cPgGdVTZXyG43BpfSitBJavf4WycCzRc+rgtj+7eNNwr\ntQ443ABnOGvKK5jfOXPpqFDHBsM5QmVfiLoFw2oCjA5amJU3/MapP/

IzhJ2A87mx\nxjZ6BW/S94MV6ynmHT6TBnAJhpW9aQ5gp/zQvxqGH7e6kXOvNEC7Ku0DQmTW4bjD\nu7GMk+OuacuO+nVTlc9poZeLBb7rkbk

+/ZwLYRRJaNjMUxWb4P59Ozi0Y5xFooXv\nqQR7IsEC2R/6/BBX+AR6WL3Xfw==\n-----END CERTIFICATE-----\n\n

$ # awk '{printf "%s\\n", $0}' vpxd.key

-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDAFG6piTTVxG/m

\nu5quzglDaAPElQwSauDn9DLRF/rDUqrBqn01MgZJvojX6HPNBvzTqo/ik/j9mEu5\nopzEMUFG8jD39sK0d0BF/WK7U59SEw7z7/


VMware, Inc. 33

Bdim6tQHYFvqcbruf72u9FE2/R8Sdg\nhAr9ZiYpFn/GgYbG961vkUBmdUhVEzTHcxZV++nmn2AnJ3xxDjHcv0vkqgk3QlpD

\nLp5CjKnNc9AYK6pB6cYQCIDHaRjmTFv/Ugoy1qrQfLnYR7YUHlzobxIdqdIlVNtj\nhipbJ

+59IMOhbkpTN5iQAtD8zLgSbM6VeKUFU98IynhLZa28K79KpDJLM5m/efKS\n6oLGl+xZAgMBAAECggEAD1fSeyJloQm

+8oxbz8jPfp3pZyOMwk/dRUoBYShsNHv+\n/ddThxNG408f+TctQNxlB7dhJPUy93bZ3as6oIVatIMWHEiOxwGblbumzlXgrRqu

\noBezeJVdP+OdSdov2QtApqKXaEokLX346kHB6vnk5HVSoZWpIW2ZYgcVQNnvfDQY

\nGmqe1vKXrWgn1MqAzRpXtS6Ht1OXZtVnEX0XGvZWqn6bEz6CChxOkoP8kg1Az8db\nynvaWbe8G3FVZB/X72e0K5LRb1FhD9/

XZXlW5TVhQ2wHz31Vj+oIDnE+FHizUR1/\n29AFt2YVlymd3s4PnSYbZsbvEJMyqG/ydbbXMT7gcQKBgQDk7s2xZ9keIG8L0SZE

\n3Nfo6doGigOCn1RQwjDiw1fgKHbkfD1tB7X49seoH3Zum68Y8zkkG4fLp8Co5npq\nQfUZ0V+qpgtLgbTeBHT4Sc6a2ua4iEU8IIona5f

+Up1zUqWsf93baumVYlXLY4yO\nqG9pDKH4HWvNSBDjdR6HtRlRzQKBgQDWyi9IyLR+BUexWXXeDzFOZnBBG07PPZG3\nNS+VQNW9uHyGle

+kuMqtnVuwaHtzIP2egEGLTT4O4OBogUSQd3dg9JXJEXkMeHMV\ntX1ABt7anKM4KP9XABWOEZ/bCnuQwFMjx9tcVhv/

KTVlJXewWoKOoadgMwyLAUiL\nZFje8hiovQKBgHV2Ob/ewr38cj2j8HjAv19YLW/RfH+W9JIDMUYIaJww5t/RB0tb\n

+3hkVojiq8eQxcSNdzIZlhFeXzHKH+FJOlMm5GkQjRcO1BhePQ3wALvfuSXRdYSm\nRXx4biIljXfQXgUmDlU4g

+UL8W1MBKBlt9Q0kR5XKirH4TJzs1h6CSW5AoGAbFBv\nQdv8sSRGgBfmCYJN0gR0jVCREI8y4VnP0gts/gx/t3r6621Iv/5/k1lND8TOQNTa

\nuL3OEsCySeEOS3ADYoBU3J2UFobTOlpYfCY60bF12cdK5HulYwxeOZ5yq49hHcUW

\nSN0fpzAHvicD0YoDFpxMhIWZyKtwAuMqsdsSNl0CgYAtxabwN0qL+eNI7aWnGtFE\no1tHW5a4JRZo977y4ZC4pGd6LUepdZzSlM/

qTLLL8DufsCzIAutp6slCxMUs95B0\nn7c43jVp8qF9xzSc7vxSvXYk7Cj6NVL26iwZ0V9+ppDUX2PATvcfjzx7yIwasQBc

\nUELbogDdpMBBIknwLCjrQA==\n-----END PRIVATE KEY-----\n\n

3 csi-vsphere.conf 파일에서 인증서를 사용자 이름으로, 키를 암호로 지정합니다.

참고 연결이 안전하지 않은 경우 insecure-flag를 true로 설정합니다.

[Global]

cluster-id = "클러스터-id"

[VirtualCenter "vCenter Server IP주소"]


user = "-----BEGIN CERTIFICATE-----\nMIIEjzCCA3egAwIBAgIJANc4yqDsTx+zMA0GCSqGSIb3DQEBCwUAMIGuMQswCQYD

\nVQQDDAJDQTEXMBUGCgmSJomT8ixkARkWB3ZzcGhlcmUxFTATBgoJkiaJk/IsZAEZ

\nFgVsb2NhbDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExMDAuBgNV

\nBAoMJ3NjLXJkb3BzLXZtMDMtZGhjcC05MC0yMi5lbmcudm13YXJlLmNvbTEbMBkG

\nA1UECwwSVk13YXJlIEVuZ2luZWVyaW5nMB4XDTE5MDcxNzAwMTYwMVoXDTI5MDcx

\nMTAwMjUxMVowfzENMAsGA1UEAwwEdnB4ZDEXMBUGCgmSJomT8ixkARkWB3ZzcGhl\ncmUxFTATBgoJkiaJk/

IsZAEZFgVsb2NhbDELMAkGA1UEBhMCVVMxMTAvBgNVBAsM

\nKG1JRC05Y2IxNjk5Ny1mODQzLTQxYmEtYTUzYy1kYTUzZGE3YTQyNzkwggEiMA0G

\nCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAFG6piTTVxG/mu5quzglDaAPElQwS\nauDn9DLRF/

rDUqrBqn01MgZJvojX6HPNBvzTqo/ik/j9mEu5opzEMUFG8jD39sK0\nd0BF/WK7U59SEw7z7/Bdim6tQHYFvqcbruf72u9FE2/

R8SdghAr9ZiYpFn/GgYbG\n961vkUBmdUhVEzTHcxZV++nmn2AnJ3xxDjHcv0vkqgk3QlpDLp5CjKnNc9AYK6pB\n6cYQCIDHaRjmTFv/

Ugoy1qrQfLnYR7YUHlzobxIdqdIlVNtjhipbJ+59IMOhbkpT\nN5iQAtD8zLgSbM6VeKUFU98IynhLZa28K79KpDJLM5m/efKS6oLGl

+xZAgMBAAGj\ngd0wgdowCwYDVR0PBAQDAgXgMDIGA1UdEQQrMCmCJ3NjLXJkb3BzLXZtMDMtZGhj

\ncC05MC0yMi5lbmcudm13YXJlLmNvbTAdBgNVHQ4EFgQURlLfiEhmgWPgS93/mUBK\nMnFZenEwHwYDVR0jBBgwFoAUg/kOFBRc

+2Ahi60D5e7ExYguA84wVwYIKwYBBQUH

\nAQEESzBJMEcGCCsGAQUFBzAChjtodHRwczovL3NjLXJkb3BzLXZtMDMtZGhjcC05\nMC0yMi5lbmcudm13YXJlLmNvbS9hZmQvdmVjcy9jY

TANBgkqhkiG9w0BAQsFAAOC\nAQEAnoTu2XwNUEPqJLAkYQkBogKeEN3+ZF/VTNfWSQl7CQsQNbA+LQPDIl/mLf90\nWaok+CmuzKKakD5/

bCT3cPgGdVTZXyG43BpfSitBJavf4WycCzRc+rgtj+7eNNwr\ntQ443ABnOGvKK5jfOXPpqFDHBsM5QmVfiLoFw2oCjA5amJU3/MapP/

IzhJ2A87mx\nxjZ6BW/S94MV6ynmHT6TBnAJhpW9aQ5gp/zQvxqGH7e6kXOvNEC7Ku0DQmTW4bjD\nu7GMk+OuacuO+nVTlc9poZeLBb7rkbk

+/ZwLYRRJaNjMUxWb4P59Ozi0Y5xFooXv\nqQR7IsEC2R/6/BBX+AR6WL3Xfw==\n-----END CERTIFICATE-----\n\n"

password = "-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDAFG6piTTVxG/m

\nu5quzglDaAPElQwSauDn9DLRF/rDUqrBqn01MgZJvojX6HPNBvzTqo/ik/j9mEu5\nopzEMUFG8jD39sK0d0BF/WK7U59SEw7z7/

Bdim6tQHYFvqcbruf72u9FE2/R8Sdg\nhAr9ZiYpFn/GgYbG961vkUBmdUhVEzTHcxZV++nmn2AnJ3xxDjHcv0vkqgk3QlpD

\nLp5CjKnNc9AYK6pB6cYQCIDHaRjmTFv/Ugoy1qrQfLnYR7YUHlzobxIdqdIlVNtj\nhipbJ

+59IMOhbkpTN5iQAtD8zLgSbM6VeKUFU98IynhLZa28K79KpDJLM5m/efKS\n6oLGl+xZAgMBAAECggEAD1fSeyJloQm

+8oxbz8jPfp3pZyOMwk/dRUoBYShsNHv+\n/ddThxNG408f+TctQNxlB7dhJPUy93bZ3as6oIVatIMWHEiOxwGblbumzlXgrRqu


VMware, Inc. 34

\noBezeJVdP+OdSdov2QtApqKXaEokLX346kHB6vnk5HVSoZWpIW2ZYgcVQNnvfDQY

\nGmqe1vKXrWgn1MqAzRpXtS6Ht1OXZtVnEX0XGvZWqn6bEz6CChxOkoP8kg1Az8db\nynvaWbe8G3FVZB/X72e0K5LRb1FhD9/

XZXlW5TVhQ2wHz31Vj+oIDnE+FHizUR1/\n29AFt2YVlymd3s4PnSYbZsbvEJMyqG/ydbbXMT7gcQKBgQDk7s2xZ9keIG8L0SZE

\n3Nfo6doGigOCn1RQwjDiw1fgKHbkfD1tB7X49seoH3Zum68Y8zkkG4fLp8Co5npq\nQfUZ0V+qpgtLgbTeBHT4Sc6a2ua4iEU8IIona5f

+Up1zUqWsf93baumVYlXLY4yO\nqG9pDKH4HWvNSBDjdR6HtRlRzQKBgQDWyi9IyLR+BUexWXXeDzFOZnBBG07PPZG3\nNS+VQNW9uHyGle

+kuMqtnVuwaHtzIP2egEGLTT4O4OBogUSQd3dg9JXJEXkMeHMV\ntX1ABt7anKM4KP9XABWOEZ/bCnuQwFMjx9tcVhv/

KTVlJXewWoKOoadgMwyLAUiL\nZFje8hiovQKBgHV2Ob/ewr38cj2j8HjAv19YLW/RfH+W9JIDMUYIaJww5t/RB0tb\n

+3hkVojiq8eQxcSNdzIZlhFeXzHKH+FJOlMm5GkQjRcO1BhePQ3wALvfuSXRdYSm\nRXx4biIljXfQXgUmDlU4g

+UL8W1MBKBlt9Q0kR5XKirH4TJzs1h6CSW5AoGAbFBv\nQdv8sSRGgBfmCYJN0gR0jVCREI8y4VnP0gts/gx/t3r6621Iv/5/k1lND8TOQNTa

\nuL3OEsCySeEOS3ADYoBU3J2UFobTOlpYfCY60bF12cdK5HulYwxeOZ5yq49hHcUW

\nSN0fpzAHvicD0YoDFpxMhIWZyKtwAuMqsdsSNl0CgYAtxabwN0qL+eNI7aWnGtFE\no1tHW5a4JRZo977y4ZC4pGd6LUepdZzSlM/

qTLLL8DufsCzIAutp6slCxMUs95B0\nn7c43jVp8qF9xzSc7vxSvXYk7Cj6NVL26iwZ0V9+ppDUX2PATvcfjzx7yIwasQBc

\nUELbogDdpMBBIknwLCjrQA==\n-----END PRIVATE KEY-----\n\n"

port = "443"


4 보안 연결을 설정하려면 insecure-flag를 false로 설정하고 다음 추가 단계를 수행합니다.

a vCenter Server의 https://<vCenter-IP-Address>/certs/download.zip에서 신뢰할 수 있는 루

트 CA 인증서를 다운로드하여 인증서가 포함된 download.zip 파일을 추출한 후 certs/lin 디

렉토리의 인증서를 사용하여 config-map을 생성합니다.

$ cd /etc/kubernetes/

$ curl -LO https://<vCenter-FQDN>/certs/download.zip

$ unzip download.zip

$ tree certs/

certs/

├── lin

│ ├── ad102b28.0

│ └── ad102b28.r0

├── mac

│ ├── ad102b28.0

│ └── ad102b28.r0

└── win

├── ad102b28.0.crt

└── ad102b28.r0.crl

b root-ca 인증서에 대한 config-map을 생성합니다.

$ cd /etc/kubernetes/certs/lin

$ kubectl create configmap vc-root-ca-cert --from-file=ad102b28.0 --namespace=kube-system

configmap/vc-root-ca-cert created


VMware, Inc. 35

c vc-root-ca-cert configmap을 vsphere-csi-controller-0 포드에서 컨테이너 vsphere-syncer

및 vsphere-csi-controller의 CA 루트 위치에 볼륨으로 마운트합니다.

containers:

- name: vsphere-csi-controller

volumeMounts:

- mountPath: /etc/ssl/certs/ad102b28.0

subPath: ad102b28.0

name: vc-root-ca-cert

- name: vsphere-syncer

volumeMounts:


subPath: ad102b28.0


volumes:

- name: vc-root-ca-cert

configMap:


d 토폴로지 인식 볼륨 프로비저닝 및 영역 설정 기능이 사용되도록 설정되면 vsphere-csi-node

daemonset로 생성된 모든 포드에 vc-root-ca-cert configmap을 마운트합니다.

다음 예와 같이 vsphere-csi-node daemonset를 배포하기 위해 배포 YAML 파일에

volumeMount 및 볼륨을 추가합니다.

containers:

- name: vsphere-csi-node

volumeMounts:


subPath: ad102b28.0


volumes:

- name: vc-root-ca-cert

configMap:


클러스터 설정 확인

master 노드에서, 모든 노드가 클러스터에 가입되어 있고 제공자 ID가 올바르게 설정되어 있는지 확인

합니다.

절차

1 모든 worker 노드가 master 노드에 가입되어 있고 준비되었는지 확인합니다.

# kubectl get nodes

NAME STATUS ROLES AGE VERSION

k8s-master Ready master 5m13s v1.14.2


VMware, Inc. 36

k8s-node1 Ready <none> 23s v1.14.2




2 모든 노드에 ProviderID가 설정되어 있는지 확인합니다.

# kubectl describe nodes | grep "ProviderID"

ProviderID: vsphere://4204a018-f286-cf3c-7f2d-c512d9f7d90d

ProviderID: vsphere://42040e14-690a-af11-0b8e-96b09570d8a3

ProviderID: vsphere://4204bf92-3a32-5e50-d2c1-74e446f4f741

ProviderID: vsphere://4204eaf5-883c-23c7-50a8-868988cc0ae0

ProviderID: vsphere://42049175-beac-93eb-b6cb-5a827184f1e3

CCM 및 CSI 드라이버 설치 후 Kubernetes 노드 추가

CCM 및 CSI 드라이버를 설치한 후 다음 단계에 따라 Kubernetes 클러스터에 노드를 추가합니다.

절차

1 새 노드에서 kubelet 클라우드 제공자 플래그를 외부로 설정합니다.

2 다음 명령을 사용하여 kubelet을 다시 시작합니다.

root@k8s-node3:~# systemctl daemon-reload

root@k8s-node3:~# systemctl restart kubelet

참고 새 노드에 taint가 설정되어 있는지 확인합니다. 이 taint는 CCM에서 새 노드에 ProviderID

를 설정하는 데 필요합니다. taint가 설정되지 않은 경우 master 노드에서 다음 명령을 실행하여

taint를 적용합니다.

root@k8s-master:~# kubectl taint nodes k8s-node2

node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

3 master 노드의 discovery.yaml 파일을 /etc/kubernetes/discovery.yaml의 새 노드로 복사합니다.

4 다른 노드와 마찬가지로 kubeadm join 명령을 실행합니다.

# tee /etc/kubernetes/kubeadminitworker.yaml >/dev/null <<EOF


caCertPath: /etc/kubernetes/pki/ca.crt

discovery:

file:

kubeConfigPath: /etc/kubernetes/discovery.yaml

timeout: 5m0s

tlsBootstrapToken: y7yaev.9dvwxx6ny4ef8vlq

kind: JoinConfiguration

nodeRegistration:


VMware, Inc. 37

criSocket: /var/run/dockershim.sock

kubeletExtraArgs:


EOF

# kubeadm join --config /etc/kubernetes/kubeadminitworker.yaml

5 master 노드에서 새 노드에 대해 ProviderID가 설정되었는지 확인합니다.

root@k8s-master:~# kubectl describe nodes | egrep "ProviderID:|Name:"

Name: k8s-master

ProviderID: vsphere://422fce18-ab8a-484f-6278-f6c0f37ecd82

Name: k8s-node1

ProviderID: vsphere://422f1805-f210-2f9b-edbf-487dc77c8969

Name: k8s-node2

ProviderID: vsphere://422f98b8-cfcd-dede-6da2-988a7022c4b8

Name: k8s-node3

ProviderID: vsphere://422f4c6e-2843-9c78-288a-27f6d5b5d6ae

6 새 노드에 대해 노드 데몬 집합이 실행 중인지 확인합니다.



coredns-6557d7f7d6-59psv 1/1 Running 0 18m

coredns-6557d7f7d6-xklr5 1/1 Running 0 18m




kube-flannel-ds-amd64-5czhc 1/1 Running 0 17m

kube-flannel-ds-amd64-5f468 1/1 Running 0 18m

kube-flannel-ds-amd64-h4k4q 1/1 Running 0 75s

kube-flannel-ds-amd64-nzrzh 1/1 Running 0 16m

kube-proxy-cpx55 1/1 Running 0 17m

kube-proxy-m7xmg 1/1 Running 0 16m

kube-proxy-nc647 1/1 Running 0 75s

kube-proxy-tpvhg 1/1 Running 0 18m


vsphere-cloud-controller-manager-glk95 1/1 Running 0 11m

vsphere-csi-controller-0 5/5 Running 0 9m38s

vsphere-csi-node-qrwbt 3/3 Running 0 7m29s

vsphere-csi-node-v5bqn 3/3 Running 0 7m29s

vsphere-csi-node-xfnd9 3/3 Running 0 55s


VMware, Inc. 38

상태 저장 애플리케이션 배포 3컨테이너화된 상태 저장 애플리케이션을 생성하고 vSphere Client를 사용하여 애플리케이션을 지원하

는 볼륨에 액세스합니다.

다음 샘플 워크플로는 하나의 복제를 사용하여 MongoDB 애플리케이션을 배포하는 방법을 보여줍니

다.

워크플로 작업을 수행하는 동안 vSphere 사용자 및 Kubernetes 사용자의 역할을 대체합니다. 작업

에는 다음 항목이 사용됩니다.

n 스토리지 클래스 YAML 파일.

n MongoDB 서비스 YAML 파일.

n 상태 저장 집합 YAML 파일.

절차

1 스토리지 정책 생성

컨테이너화된 애플리케이션을 지원할 VMDK(가상 디스크)는 특정 스토리지 요구 사항을 충족해

야 합니다. vSphere 사용자는 Kubernetes 사용자가 제공한 요구 사항을 기반으로 VM 스토리

지 정책을 생성합니다.

2 스토리지 클래스 생성

Kubernetes 사용자는 이전에 생성된 VM 스토리지 정책을 참조하는 스토리지 클래스를 정의하고

배포합니다.

3 애플리케이션용 Kubernetes 서비스 정의 및 배포

Kubernetes 사용자로, Kubernetes 서비스를 정의하고 배포합니다. 이 서비스는 애플리케이션

에 대한 네트워킹 끝점을 제공합니다.

4 상태 저장 집합 생성 및 배포

Kubernetes 사용자는 애플리케이션에 사용될 복제본의 수를 지정하는 상태 저장 집합을 정의하

고 배포합니다.

5 컨테이너 볼륨 VMDK 검토

애플리케이션이 배포된 후에는 해당 상태가 지정된 스토리지 정책과 연결된 VMDK 파일에 의해

지원됩니다. vSphere 관리자는 컨테이너 볼륨에 대해 생성된 VMDK를 검토할 수 있습니다.

VMware, Inc. 39

스토리지 정책 생성

컨테이너화된 애플리케이션을 지원할 VMDK(가상 디스크)는 특정 스토리지 요구 사항을 충족해야 합

니다. vSphere 사용자는 Kubernetes 사용자가 제공한 요구 사항을 기반으로 VM 스토리지 정책을

생성합니다.

스토리지 정책은 애플리케이션을 지원하는 VMDK와 연결됩니다.

환경에 vCenter Server 인스턴스가 여러 개 있는 경우에는 VM 스토리지 정책을 각 인스턴스에 생성

합니다. 모든 인스턴스에서 동일한 정책 이름을 사용하십시오.


n Kubernetes 사용자는 컨테이너화된 상태 저장 애플리케이션이 배포될 Kubernetes 클러스터를

식별합니다.

n Kubernetes 사용자는 컨테이너화된 애플리케이션에 대한 스토리지 요구 사항을 수집하여

vSphere 사용자에 게 전달합니다.

n 필요한 권한: VM 스토리지 정책. 업데이트 및 VM 스토리지 정책. 보기.

절차

1 vSphere Client에서 VM 스토리지 정책 생성 마법사를 엽니다.

a 메뉴 > 정책 및 프로파일을 클릭합니다.

b 정책 및 프로파일에서 VM 스토리지 정책을 클릭합니다.

c VM 스토리지 정책 생성을 클릭합니다.

2 정책 이름과 설명을 입력하고 다음을 클릭합니다.

옵션 작업

vCenter Server vCenter Server 인스턴스를 선택합니다.

이름 스토리지 정책의 이름(예: 공간 효율적)을 입력합니다.

설명 스토리지 정책에 대한 설명을 입력합니다.

3 정책 구조 페이지의 데이터스토어별 규칙 아래에서 vSAN 스토리지에 대한 규칙 사용을 선택하고

다음을 클릭합니다.

4 vSAN 페이지에서 정책 규칙 집합을 정의하고 다음을 클릭합니다.

a 가용성 탭에서 사이트 재해 허용 오차 및 허용되는 장애를 정의합니다.

b 고급 정책 규칙 탭에서 개체 및 Flash Read Cache 예약당 디스크 스트라이프 수와 같은 고

급 정책 규칙을 정의합니다.

5 스토리지 호환성 페이지에서 이 정책과 일치하는 vSAN 데이터스토어 목록을 검토하고 다음을 클

릭합니다.


VMware, Inc. 40

6 검토 및 완료 페이지에서 정책 설정을 검토하고 마침을 클릭합니다.

다음에 수행할 작업

이제 Kubernetes 사용자에게 스토리지 정책 이름을 알릴 수 있습니다. 생성한 VM 스토리지 정책은

동적 볼륨 프로비저닝을 위한 스토리지 클래스 정의의 일부로 사용됩니다.

스토리지 클래스 생성

Kubernetes 사용자는 이전에 생성된 VM 스토리지 정책을 참조하는 스토리지 클래스를 정의하고 배

포합니다.

kubectl을 사용하여 다음 단계를 수행합니다. 일반적으로 kubectl에 대한 정보는 YAML 파일에 제공합

니다. kubectl은 API 요청을 수행할 때 정보를 JSON으로 변환합니다.


VMware, Inc. 41

절차

1 컨테이너에 대한 스토리지 요구 사항을 설명하고 사용할 VM 스토리지 정책을 참조하는 스토리지

클래스 YAML 파일을 생성합니다.

YAML 파일을 생성할 때 다음 항목을 포함할 수 있습니다.

매개 변수 설명

storagepolicyname 적용할 VM 스토리지 정책의 이름을 포함합니다. 생성한 영구 볼륨 VMDK에는

VM 스토리지 정책이 연결됩니다.

fstype 마운트할 파일 시스템 유형을 지정합니다. 예: ext4, ext3 또는 기타 파일 시스

템.

DatastoreURL 컨테이너 볼륨을 프로비저닝해야 하는 데이터스토어의 URL을 지정합니다.

다음 샘플 YAML 파일에는 이전에 vSphere Client를 사용하여 생성한 공간 효율적 스토리지 정책

이 포함되어 있습니다. 생성된 영구 볼륨 VMDK는 공간 효율적 스토리지 정책 요구 사항을 충족하

는 사용 가능한 최대 공간이 있는 호환되는 데이터스토어에 배치됩니다.

$ cat mongodb-storageclass.yaml

kind: StorageClass

apiVersion: storage.k8s.io/v1

metadata:

name: mongodb-sc

annotations:

storageclass.kubernetes.io/is-default-class: "false"

provisioner: block.vsphere.csi.vmware.com

parameters:

storagepolicyname: "Space-Efficient"

fstype: ext4

2 kubectl을 사용하여 스토리지 클래스를 배포합니다.

$ kubectl create -f mongodb-storageclass.yaml

출력은 다음과 유사합니다.

storageclass.storage.k8s.io/mongodb-sc created

3 스토리지 클래스가 생성되었는지 확인합니다.

$ kubectl get storageclass mongodb-sc

다음과 유사한 출력이 표시됩니다.

NAME PROVISIONER AGE

mongodb-sc block.vsphere.csi.vmware.com 5s


VMware, Inc. 42

애플리케이션용 Kubernetes 서비스 정의 및 배포

Kubernetes 사용자로, Kubernetes 서비스를 정의하고 배포합니다. 이 서비스는 애플리케이션에 대

한 네트워킹 끝점을 제공합니다.

절차

1 서비스를 정의하는 YAML 파일을 생성합니다.

다음은 MongoDB 애플리케이션에 대한 서비스를 정의하는 샘플 YAML 파일입니다.

$ cat mongodb-service.yaml

apiVersion: v1

kind: Service

metadata:

name: mongodb-service

labels:

name: mongodb-service

spec:

ports:

- port: 27017

targetPort: 27017

clusterIP: None

selector:

role: mongo

2 kubectl을 사용하여 서비스를 배포합니다.

$ kubectl create -f mongodb-service.yaml

service/mongodb-service created

상태 저장 집합 생성 및 배포

Kubernetes 사용자는 애플리케이션에 사용될 복제본의 수를 지정하는 상태 저장 집합을 정의하고 배

포합니다.

절차

1 키 파일에 대한 암호를 생성합니다. MongoDB는 이 키를 사용하여 내부 클러스터와 통신합니다.

$ openssl rand -base64 741 > key.txt

$ kubectl create secret generic shared-bootstrap-data --from-file=internal-auth-mongodb-keyfile=key.txt

secret/shared-bootstrap-data created


VMware, Inc. 43

2 컨테이너화된 애플리케이션에 대한 규격은 상태 저장 집합 YAML 파일에 정의합니다.

다음 샘플 규격은 MongoDB 애플리케이션 인스턴스를 하나 요청하고, 사용할 외부 이미지를 지정

하며, 이전에 생성한 mongodb-sc 스토리지 클래스를 참조합니다. 이 스토리지 클래스는 앞서

vSphere Client 측에서 정의한 공간 효율적 VM 스토리지 정책에 매핑됩니다.

$ cat mongodb-statefulset.yaml

apiVersion: apps/v1

kind: StatefulSet

metadata:

name: mongod

spec:

serviceName: mongodb-service

replicas: 3

selector:

matchLabels:

role: mongo

environment: test

replicaset: MainRepSet

template:

metadata:

labels:

role: mongo

environment: test

replicaset: MainRepSet

spec:

containers:

- name: mongod-container

image: mongo:3.4

command:

- "numactl"

- "--interleave=all"

- "mongod"

- "--bind_ip"

- "0.0.0.0"

- "--replSet"

- "MainRepSet"

- "--auth"

- "--clusterAuthMode"

- "keyFile"

- "--keyFile"

- "/etc/secrets-volume/internal-auth-mongodb-keyfile"

- "--setParameter"

- "authenticationMechanisms=SCRAM-SHA-1"

resources:

requests:

cpu: 0.2

memory: 200Mi

ports:

- containerPort: 27017

volumeMounts:

- name: secrets-volume

readOnly: true

mountPath: /etc/secrets-volume


VMware, Inc. 44

- name: mongodb-persistent-storage-claim

mountPath: /data/db

volumes:

- name: secrets-volume

secret:

secretName: shared-bootstrap-data

defaultMode: 256

volumeClaimTemplates:

- metadata:

name: mongodb-persistent-storage-claim

annotations:

volume.beta.kubernetes.io/storage-class: "mongodb-sc"

spec:

accessModes: [ "ReadWriteOnce" ]

resources:

requests:

storage: 1Gi

3 kubectl을 사용하여 상태 저장 집합을 배포합니다.

$ kubectl create -f mongodb-statefulset.yaml

다음과 유사한 출력이 표시됩니다.

statefulset.apps/mongo created

4 MongoDB가 생성되었는지 확인합니다.

포드가 실행되기 시작하고 각 복제본에 대해 PVC가 생성될 때까지 기다립니다.

$ kubectl get statefulset mongod

NAME READY AGE

mongod 3/3 96s

$ kubectl get pod -l role=mongo


mongod-0 1/1 Running 0 13h



$ kubectl get pvc

NAME STATUS VOLUME CAPACITY

ACCESS MODES STORAGECLASS AGE

mongodb-persistent-storage-claim-mongod-0 Bound pvc-ea98b22a-b8cf-11e9-b1d3-005056a0e4f0 1Gi

RWO mongodb-sc 13h

mongodb-persistent-storage-claim-mongod-1 Bound pvc-0267fa7d-b8d0-11e9-b1d3-005056a0e4f0 1Gi

RWO mongodb-sc 13h

mongodb-persistent-storage-claim-mongod-2 Bound pvc-24d86a37-b8d0-11e9-b1d3-005056a0e4f0 1Gi

RWO mongodb-sc 13h

5 복제 세트 구성을 설정합니다.

mongod컨테이너 프로세스 중 하나에 연결하여 복제 세트를 구성합니다.


VMware, Inc. 45

다음 명령을 실행하여 첫 번째 컨테이너에 연결합니다. 셸에서 복제 세트를 시작합니다.

StatefulSet를 사용했기 때문에 호스트 이름을 동일하게 사용할 수 있습니다.

$ kubectl exec -it mongod-0 -c mongod-container bash

root@mongod-0:/# mongo

> rs.initiate({_id: "MainRepSet", version: 1, members: [

... { _id: 0, host : "mongod-0.mongodb-service.default.svc.cluster.local:27017" },

... { _id: 1, host : "mongod-1.mongodb-service.default.svc.cluster.local:27017" },

... { _id: 2, host : "mongod-2.mongodb-service.default.svc.cluster.local:27017" }

... ]});

{ "ok" : 1 }

mongodb-0은 기본 노드가 되고 다른 두 노드는 보조 노드입니다.

클라우드 네이티브 스토리지는 애플리케이션 스토리지 요구 사항을 충족하는 VMDK를 생성하여 클러

스터의 Kubernetes 노드 중 하나에 동적으로 연결합니다.

다음에 수행할 작업

이제 vSphere Client에서 볼륨을 확인할 수 있습니다.

컨테이너 볼륨 VMDK 검토

애플리케이션이 배포된 후에는 해당 상태가 지정된 스토리지 정책과 연결된 VMDK 파일에 의해 지원

됩니다. vSphere 관리자는 컨테이너 볼륨에 대해 생성된 VMDK를 검토할 수 있습니다.

참고 Kubernetes CNS 서버에 오류가 발생하면 전체 동기화가 수행될 때까지 vSphere Client의

CN 개체가 올바르게 표시되지 않을 수 있습니다.

절차

1 vSphere Client에서 적절한 노드 VM으로 이동합니다.

2 요약 탭을 클릭하고 새로 생성된 하드 디스크를 검토합니다.

3 vCenter Server 인스턴스, 데이터 센터 또는 데이터스토어로 이동합니다.

4 모니터 탭을 클릭하고 클라우드 네이티브 스토리지에서 컨테이너 볼륨을 클릭합니다.

5 환경에 사용할 수 있는 컨테이너 볼륨을 관찰하고 스토리지 정책 규정 준수 상태를 모니터링합니

다.


VMware, Inc. 46

컨테이너 볼륨 관리 4컨테이너화된 애플리케이션을 배포한 후에는 vSphere Client를 사용하여 컨테이너 볼륨을 모니터링할

수 있습니다. 또한 컨테이너화된 애플리케이션에 대한 복제본 수를 늘리는 것과 같은 관리 작업을 수행

할 수 있습니다.


n Kubernetes 클러스터 전체에서 컨테이너 볼륨 모니터링

n 컨테이너화된 애플리케이션 확장

Kubernetes 클러스터 전체에서 컨테이너 볼륨 모니터링

환경의 컨테이너 볼륨을 표시하고 스토리지 정책 규정 준수 상태를 모니터링합니다.

절차

1 vCenter Server 인스턴스, 데이터 센터 또는 데이터스토어로 이동합니다.

2 모니터 탭을 클릭하고 클라우드 네이티브 스토리지에서 컨테이너 볼륨을 클릭합니다.

3 환경에 사용할 수 있는 컨테이너 볼륨을 관찰하고 스토리지 정책 규정 준수 상태를 모니터링합니

다.

4 [레이블] 열의 모두 표시 링크를 클릭하여 추가 세부 정보를 확인합니다.

5 [볼륨 이름] 열의 링크를 클릭하여 배치, 규정 준수 및 스토리지 정책과 같은 세부 정보를 검토합니

다.

참고 이 보기는 기본 데이터스토어가 vSAN인 경우에만 사용할 수 있습니다.

VMware, Inc. 47

컨테이너화된 애플리케이션 확장

Kubernetes 상태 저장 집합을 사용하여 컨테이너화된 애플리케이션에 대한 복제본 수를 늘립니다.

kubectl을 사용하여 컨테이너화된 애플리케이션을 확장할 수 있습니다. 이 샘플 작업을 수행하여

MongoDB 복제본 수를 3개에서 5개 늘립니다.

절차

1 다음 명령을 실행하여 복제본의 수를 확인합니다.

$ kubectl get statefulset

NAME READY AGE

mongod 3/3 13h

2 다음 명령을 실행하여 복제본 수를 5로 늘립니다.

$ kubectl scale statefulset mongod --replicas=5

statefulset.apps/mongod scaled

ESXi가 새 가상 디스크 개체를 생성합니다.


VMware, Inc. 48

3 새 복제본이 생성되었는지 확인합니다.

a 모든 복제본을 표시합니다.

$ kubectl get pod


busybox 1/1 Running 13 13h




mongod-3 1/1 Running 0 85s

mongod-4 1/1 Running 0 41s

$ kubectl get pvc

NAME STATUS VOLUME

CAPACITY ACCESS MODES STORAGECLASS AGE

mongodb-persistent-storage-claim-mongod-0 Bound pvc-ea98b22a-b8cf-11e9-b1d3-005056a0e4f0

1Gi RWO mongodb-sc 13h

mongodb-persistent-storage-claim-mongod-1 Bound pvc-0267fa7d-b8d0-11e9-b1d3-005056a0e4f0


mongodb-persistent-storage-claim-mongod-2 Bound pvc-24d86a37-b8d0-11e9-b1d3-005056a0e4f0


mongodb-persistent-storage-claim-mongod-3 Bound pvc-14cf008f-b944-11e9-b1d3-005056a0e4f0

1Gi RWO mongodb-sc 91s

mongodb-persistent-storage-claim-mongod-4 Bound pvc-2ec9e6d0-b944-11e9-b1d3-005056a0e4f0

1Gi RWO mongodb-sc 47

b 상태 저장 집합에 대한 설명을 가져옵니다.


출력의 복제본 수가 5로 변경되었습니다.

NAME READY AGE

mongod 5/5 13h

4 vSphere Client에서 컨테이너 볼륨을 표시합니다.

a vCenter Server 인스턴스, 데이터 센터 또는 데이터스토어로 이동합니다.

b 모니터 탭을 클릭하고 클라우드 네이티브 스토리지에서 컨테이너 볼륨을 클릭합니다.

이제 목록에서 2개의 새로 추가된 컨테이너 볼륨을 볼 수 있습니다.


VMware, Inc. 49

여러 데이터 센터나 클러스터가 있는 환경에서 CCM과 CSI 배포 5여러 데이터 센터나 호스트 클러스터가 포함된 vSphere 환경에서 CCM과 CSI를 배포하는 경우에는

영역 설정을 사용할 수 있습니다.

영역 설정을 사용하면 Kubernetes와 같은 오케스트레이션 시스템을 모든 노드에서 동일하게 사용할

수 없는 vSphere 스토리지 리소스와 통합할 수 있습니다. 따라서, 오케스트레이션 시스템은 볼륨을

동적으로 프로비저닝할 때 지능적인 결정을 내릴 수 있으며 필요한 스토리지 리소스에 액세스할 수 없

어서 포드를 시작하지 못하는 상황을 피할 수 있습니다.


n vSphere CNS 환경에서 영역 설정

n 영역을 사용하여 워크로드 배포

n Kubernetes에서 토폴로지 인식 볼륨 프로비저닝 사용

n Kubernetes 노드 VM을 다른 영역이나 지역으로 마이그레이션

vSphere CNS 환경에서 영역 설정

vSphere 스토리지 환경에 따라 영역마다 다른 배포 시나리오를 사용할 수 있습니다. 예를 들어, 호스

트 클러스터별 영역이나 데이터 센터별 영역을 생성하거나 둘 모두를 조합한 영역을 생성할 수 있습니

다.

다음 예에서 vCenter Server 환경에는 세 개의 클러스터가 포함되어 있고 세 개의 클러스터 모두에

노드 VM이 있습니다.

VMware, Inc. 50

샘플 워크플로는 클러스터별 영역과 데이터 센터별 영역을 생성합니다.

절차

1 vSphere 태그를 사용하여 영역 생성

vSphere 태그를 사용하여 vSphere 환경에서 영역에 레이블을 지정할 수 있습니다.

2 CCM과 CSI 드라이버에 영역 사용

zone과 region 항목을 사용하여 CCM과 CSI 드라이버를 설치합니다.

vSphere 태그를 사용하여 영역 생성

vSphere 태그를 사용하여 vSphere 환경에서 영역에 레이블을 지정할 수 있습니다.

이 작업에서는 vCenter Server 환경에 3개의 클러스터(cluster1, cluster2 및 cluster3)가 있고, 3

개 클러스터 모두에 노드 VM이 있다고 가정합니다. 이 작업에서는 k8s-zone과 k8s-region이라는 두

가지 태그 범주를 생성합니다. 클러스터에 zone-a, zone-b, zone-c라는 3가지 영역으로 태그를 지정하

고 데이터 센터를 region-1이라는 영역으로 표시합니다.


태그 작업 기능을 제어하는 적절한 태그 지정 권한이 있는지 확인합니다. "vSphere 보안" 설명서에서

"vSphere 태그 지정 권한" 을 참조하십시오.

참고 호스트, 클러스터 및 데이터 센터와 같은 노드 VM의 상위 항목에는 CSI 드라이버와 CCM을 사

용하도록 구성된 vSphere 사용자에 대한 읽기 전용 역할 설정이 있어야 합니다. 노드 토폴로지를 준

비하기 위해 태그와 범주를 읽도록 허용하는 데 필요합니다.


VMware, Inc. 51

절차

1 vSphere Client에서 k8s-zone과 k8s-region이라는 2가지 태그 범주를 생성합니다.

자세한 내용은 "vCenter Server 및 호스트 관리" 설명서에서 "태그 범주 생성, 편집 또는 삭제" 를

참조하십시오.

2 각 범주에서 적절한 영역 태그를 생성합니다.

태그 생성에 대한 자세한 내용은 "vCenter Server 및 호스트 관리" 설명서에서 "태그 생성, 편집

또는 삭제" 를 참조하십시오.

범주 태그

k8s-zone zone-a

zone-b

zone-c

k8s-region region-1

3 표에 표시된 대로 데이터 센터와 클러스터에 해당 태그를 적용합니다.

자세한 내용은 "vCenter Server 및 호스트 관리" 설명서에서 "태그 할당 또는 제거" 를 참조하십

시오.

vSphere 개체 태그

datacenter region-1

cluster1 zone-a

cluster2 zone-b

cluster3 zone-c

CCM과 CSI 드라이버에 영역 사용

zone과 region 항목을 사용하여 CCM과 CSI 드라이버를 설치합니다.

절차

1 CCM을 설치합니다.

configmap cloud-config 파일의 값 필드에서 region과 zone을 지정합니다.

vSphere에서 정의한 범주 이름(예: k8s-region 및 k8s-zone)을 추가해야 합니다.

[Global]


[VirtualCenter "vCenter Server IP 주소"]

user = "사용자"

password = "암호"

port = "443"


[Network]


VMware, Inc. 52

public-network = "VM Network"

[Labels]

region = k8s-region

zone = k8s-zone

cd /etc/kubernetes

kubectl create configmap cloud-config --from-file=vsphere.conf --namespace=kube-system

kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/

controller-manager/cloud-controller-manager-roles.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/

controller-manager/cloud-controller-manager-role-bindings.yaml

kubectl apply -f https://github.com/kubernetes/cloud-provider-vsphere/raw/master/manifests/controller-

manager/vsphere-cloud-controller-manager-ds.yaml

2 CCM 설치가 성공했는지 확인합니다.

설치 후 failure-domain.beta.kubernetes.io/region 및 failure-domain.beta.kubernetes.io/zone

레이블이 모든 노드에 적용됩니다.

kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region

NAME STATUS ROLES AGE VERSION ZONE REGION

k8s-master Ready master 32m v1.14.2 zone-a region-1

k8s-node1 Ready <none> 18m v1.14.2 zone-a region-1

k8s-node2 Ready <none> 18m v1.14.2 zone-b region-1

k8s-node3 Ready <none> 18m v1.14.2 zone-b region-1

k8s-node4 Ready <none> 18m v1.14.2 zone-c region-1

k8s-node5 Ready <none> 18m v1.14.2 zone-c region-1

3 CSI 드라이버를 설치합니다.

다음과 같은 인수로 외부 provisioner를 배치해야 합니다.

- "--feature-gates=Topology=true"

자격 증명 비밀 파일에서 region과 zone에 대한 항목을 추가합니다.

[Global]

cluster-id = "클러스터-id"

[VirtualCenter "vCenter Server IP주소"]


user = "사용자 "

password = "암호"

port = "443"


[Labels]

region = k8s-region

zone = k8s-zone

cd /etc/kubernetes

kubectl create secret generic vsphere-config-secret --from-file=vsphere.conf --namespace=kube-system


VMware, Inc. 53

4 CSI 드라이버 설치가 성공했는지 확인합니다.

# kubectl get csinodes -o jsonpath='{range .items[*]}{.metadata.name} {.spec}{"\n"}{end}'

k8s-node1 map[drivers:[map[name:block.vsphere.csi.vmware.com nodeID:k8s-node1 topologyKeys:[failure-

domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone]]]]









영역을 사용하여 워크로드 배포

영역을 통해 Kubernetes 워크로드를 특정 지역이나 영역에 배포할 수 있습니다.

샘플 워크플로를 사용하여 워크로드를 프로비저닝하고 확인합니다.

절차

1 영역과 지역 매핑을 정의하는 스토리지 클래스를 생성합니다.

스토리지 클래스 YAML 파일의 allowedTopologies 필드에 zone-a와 region-1을 추가합니다.

tee example-zone-sc.yaml >/dev/null <<'EOF'

kind: StorageClass


metadata:

name: example-vanilla-block-zone-sc


allowedTopologies:

- matchLabelExpressions:

- key: failure-domain.beta.kubernetes.io/zone

values:

- zone-a

- key: failure-domain.beta.kubernetes.io/region

values:

- region-1

# kubectl create -f example-zone-sc.yaml

storageclass.storage.k8s.io/example-vanilla-block-zone-sc created

2 영구 볼륨 할당을 생성합니다.

tee example-zone-pvc.yaml >/dev/null <<'EOF'

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: example-vanilla-block-zone-pvc

spec:


VMware, Inc. 54

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 5Gi

storageClassName: example-vanilla-block-zone-sc

# kubectl create -f example-zone-pvc.yaml

persistentvolumeclaim/example-vanilla-block-zone-pvc created

3 영구 볼륨 할당에 대한 볼륨이 생성되었는지 확인합니다.

# kubectl get pvc example-vanilla-block-zone-pvc

NAME STATUS VOLUME CAPACITY ACCESS

MODES STORAGECLASS AGE

example-vanilla-block-zone-pvc Bound pvc-5b340a9b-a990-11e9-b26e-005056a04307 5Gi

RWO example-vanilla-block-zone-sc 58s

# kubectl get pvc example-vanilla-block-zone-pvc

NAME STATUS VOLUME CAPACITY ACCESS

MODES STORAGECLASS AGE

example-vanilla-block-zone-pvc Bound pvc-5b340a9b-a990-11e9-b26e-005056a04307 5Gi

RWO example-vanilla-block-zone-sc 91s

4 영구 볼륨이 스토리지 클래스에 지정된 영역과 지역이 포함된 노드 선호도 규칙을 통해 프로비저닝

되었는지 확인합니다.

# kubectl describe pv pvc-5b340a9b-a990-11e9-b26e-005056a04307

Name: pvc-5b340a9b-a990-11e9-b26e-005056a04307

Labels: <none>

Annotations: pv.kubernetes.io/provisioned-by: block.vsphere.csi.vmware.com

Finalizers: [kubernetes.io/pv-protection]

StorageClass: example-vanilla-block-zone-sc

Status: Bound

Claim: default/example-vanilla-block-zone-pvc

Reclaim Policy: Delete

Access Modes: RWO

VolumeMode: Filesystem

Capacity: 5Gi

Node Affinity:

Required Terms:

Term 0: failure-domain.beta.kubernetes.io/zone in [zone-a]

failure-domain.beta.kubernetes.io/region in [region-1]

Message:

Source:

Type: CSI (a Container Storage Interface (CSI) volume source)

Driver: block.vsphere.csi.vmware.com

VolumeHandle: 8f1f5e44-fafa-4404-91f7-d7a9bfd30e16

ReadOnly: false

VolumeAttributes: fstype=


VMware, Inc. 55

storage.kubernetes.io/csiProvisionerIdentity=1563472725085-8081-

block.vsphere.csi.vmware.com

type=vSphere CNS Block Volume

Events: <none>

5 포드를 생성합니다.

tee example-zone-pod.yaml >/dev/null <<'EOF'

apiVersion: v1

kind: Pod

metadata:

name: example-vanilla-block-zone-pod

spec:

containers:

- name: test-container

image: gcr.io/google_containers/busybox:1.24

command: ["/bin/sh", "-c", "echo

'hello' > /mnt/volume1/index.html && chmod o+rX /mnt

/mnt/volume1/index.html && while true ; do sleep 2 ; done"]

volumeMounts:

- name: test-volume

mountPath: /mnt/volume1

restartPolicy: Never

volumes:

- name: test-volume

persistentVolumeClaim:

claimName: example-vanilla-block-zone-pvc

# kubectl create -f example-zone-pod.yaml

pod/example-vanilla-block-zone-pod created

6 zone-a와 region-1에 속하는 k8s-node1 노드에서 포드가 예약되어 있는지 확인합니다.

# kubectl describe pod example-vanilla-block-zone-pod | egrep "Node:"

Node: k8s-node1/10.160.78.255

Kubernetes에서 토폴로지 인식 볼륨 프로비저닝 사용

vSphere CSI 드라이버는 토폴로지 인식 볼륨 프로비저닝을 지원합니다. 토폴로지 인식 프로비저닝을

통해 Kubernetes는 지능적인 결정을 내리고 포드의 볼륨을 동적으로 프로비저닝할 수 있는 최적의 위

치를 찾을 수 있습니다. 다중 영역 클러스터의 경우, 포드를 실행할 수 있는 적절한 영역에 볼륨이 프로

비저닝되기 때문에, 장애 도메인 전체에서 상태 저장 워크로드를 쉽게 배포하고 확장하여 고가용성과

Fault Tolerance를 제공할 수 있습니다.


외부 provisioner는 --strict-topology 인수와 함께 배포해야 합니다.


VMware, Inc. 56

이 인수는 바인딩이 지연되는 경우 CreateVolumeRequest.AccessibilityRequirements에 전달할 토폴로

지 정보를 제어합니다. 이 옵션을 통해 결과가 변경되는 방식에 대한 자세한 내용은 https://

github.com/kubernetes-csi/external-provisioner#topology-support의 표를 참조하십시오. 토

폴로지 기능이 사용되지 않거나 즉시 볼륨 바인딩 모드가 사용되는 경우에는 이 옵션이 적용되지 않습

니다.

절차

1 토폴로지 기능을 사용하도록 설정합니다.

volumeBindingMode 매개 변수가 WaitForFirstConsumer로 설정된 스토리지 클래스를 생성합니다.

tee topology-aware-standard.yaml >/dev/null <<'EOF'

apiVersion: v1

kind: StorageClass


metadata:

name: topology-aware-standard


volumeBindingMode: WaitForFirstConsumer

# kubectl create -f topology-aware-standard.yaml

storageclass.storage.k8s.io/topology-aware-standard created

이 새로운 설정은 볼륨을 즉시 생성하는 대신 볼륨 provisioner에게 연결된 PVC를 사용하는 포드

가 스케줄링을 실행할 때까지 기다리도록 지시합니다. 이전 스토리지 클래스의 경우, failure-

domain.beta.kubernetes.io/zone과 failure-domain.beta.kubernetes.io/region이

allowedTopologies 항목에 지정되었습니다. 이제는 볼륨 프로비저닝에 사용할 영역이 포드 정책을

통해 결정되기 때문에 다시 지정할 필요가 없습니다.

2 이전에 생성된 스토리지 클래스를 사용하여 포드 및 PVC를 생성합니다.

다음 예에서는 여러 포드 제약 조건 및 스케줄링 정책을 보여줍니다.

tee topology-aware-statefulset.yaml >/dev/null <<'EOF'

---

apiVersion: apps/v1

kind: StatefulSet

metadata:

name: web

spec:

replicas: 2

selector:

matchLabels:

app: nginx

serviceName: nginx

template:

metadata:

labels:

app: nginx

spec:

affinity:

nodeAffinity:


VMware, Inc. 57

https://github.com/kubernetes-csi/external-provisioner#topology-support

https://github.com/kubernetes-csi/external-provisioner#topology-support

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

-

matchExpressions:

-

key: failure-domain.beta.kubernetes.io/zone

operator: In

values:

- zone-a

- zone-b

podAntiAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

-

labelSelector:

matchExpressions:

-

key: app

operator: In

values:

- nginx

topologyKey: failure-domain.beta.kubernetes.io/zone

containers:

- name: nginx

image: gcr.io/google_containers/nginx-slim:0.8

ports:

- containerPort: 80

name: web

volumeMounts:

- name: www

mountPath: /usr/share/nginx/html

- name: logs

mountPath: /logs

volumeClaimTemplates:

- metadata:

name: www

spec:


storageClassName: topology-aware-standard

resources:

requests:

storage: 5Gi

- metadata:

name: logs

spec:


storageClassName: topology-aware-standard

resources:

requests:

storage: 1Gi

EOF

# kubectl create -f topology-aware-statefulset.yaml

statefulset.apps/web created


VMware, Inc. 58

3 상태 저장 집합이 실행 중인지 확인합니다.


NAME READY AGE

web 2/2 5m1s

4 포드와 노드를 검토합니다.

포드는 nodeAffinity 항목에 지정된 zone-a와 zone-b에 생성됩니다. web-0은 zone-b에 속하는 node

k8s-node3에서 예약됩니다. web-1은 zone-a에 속하는 node k8s-node1에서 예약됩니다.

$ kubectl get pods -o json | egrep "hostname|nodeName|claimName"

"hostname": "web-0",

"nodeName": "k8s-node3",

"claimName": "www-web-0"

"claimName": "logs-web-0"

"hostname": "web-1",

"nodeName": "k8s-node1",

"claimName": "www-web-1"

"claimName": "logs-web-1"

$ kubectl get nodes k8s-node3 k8s-node1 -L failure-domain.beta.kubernetes.io/zone -L failure-

domain.beta.kubernetes.io/region --no-headers

k8s-node3 Ready <none> 25h v1.14.2 zone-b region-1

k8s-node1 Ready <none> 25h v1.14.2 zone-a region-1

5 포드에서 설정한 정책에 따라 볼륨이 영역에 프로비저닝되어 있는지 확인합니다.

포드 예약된 위치에 따라 연결된 볼륨도 동일한 영역에서 프로비저닝됩니다.

$ kubectl describe pvc www-web-0 | egrep "volume.kubernetes.io/selected-node"

volume.kubernetes.io/selected-node: k8s-node3

$ kubectl describe pvc logs-web-0 | egrep "volume.kubernetes.io/selected-node"


$ kubectl describe pvc www-web-1 | egrep "volume.kubernetes.io/selected-node"


$ kubectl describe pvc logs-web-1 | egrep "volume.kubernetes.io/selected-node"


$ kubectl get pv -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.claimRef.name}{"\t"}

{.spec.nodeAffinity}{"\n"}{end}'

pvc-2253dc52-a9ed-11e9-b26e-005056a04307 www-web-0 map[required:map[nodeSelectorTerms:

[map[matchExpressions:[map[key:failure-domain.beta.kubernetes.io/region operator:In values:[region-1]]

map[operator:In values:[zone-b] key:failure-domain.beta.kubernetes.io/zone]]]]]]

pvc-22575240-a9ed-11e9-b26e-005056a04307 logs-web-0 map[required:map[nodeSelectorTerms:

[map[matchExpressions:[map[key:failure-domain.beta.kubernetes.io/zone operator:In values:[zone-b]]

map[key:failure-domain.beta.kubernetes.io/region operator:In values:[region-1]]]]]]]

pvc-3c963150-a9ed-11e9-b26e-005056a04307 www-web-1 map[required:map[nodeSelectorTerms:

[map[matchExpressions:[map[key:failure-domain.beta.kubernetes.io/zone operator:In values:[zone-a]]


VMware, Inc. 59

map[operator:In values:[region-1] key:failure-domain.beta.kubernetes.io/region]]]]]]

pvc-3c98978f-a9ed-11e9-b26e-005056a04307 logs-web-1 map[required:map[nodeSelectorTerms:

[map[matchExpressions:[map[key:failure-domain.beta.kubernetes.io/zone operator:In values:[zone-a]]

map[key:failure-domain.beta.kubernetes.io/region operator:In values:[region-1]]]]]]]

6 필요한 경우 allowedTopologies를 지정합니다.

클러스터 연산자가 WaitForFirstConsumer 볼륨 바인딩 모드를 지정하는 경우, 대부분의 상황에서

더 이상 특정 토폴로지로 프로비저닝을 제한할 필요가 없습니다. 단, 필요한 경우에는

allowedTopologies를 지정할 수 있습니다.

다음 예에서는 토폴로지를 특정 영역으로 제한하는 방법을 보여줍니다.

kind: StorageClass


metadata:

name: example-vanilla-block-sc


volumeBindingMode: WaitForFirstConsumer

allowedTopologies:

- matchLabelExpressions:

- key: failure-domain.beta.kubernetes.io/zone

values:

- zone-b

- key: failure-domain.beta.kubernetes.io/region

values:

- region-1

Kubernetes 노드 VM을 다른 영역이나 지역으로 마이그레이션

Kubernetes 노드 VM의 영역과 지역 배치를 정의한 후에는 기존 영역 및 지역 레이블을 바꿔서 할당

을 변경할 수 있습니다.

절차

1 노드의 기존 레이블을 대상 영역이나 지역으로 바꿉니다.

$ kubectl label nodes k8s-node1 failure-domain.beta.kubernetes.io/zone=zone-b --overwrite=true

node/k8s-node1 labeled

2 Kubernetes 노드와 연결된 csinode CRD를 삭제합니다.

$ kubectl delete csinode k8s-node1

3 노드를 새 영역이나 지역으로 마이그레이션합니다.

4 노드에서 실행 중인 vsphere-csi-node daemonset 포드를 삭제합니다.

업데이트된 토폴로지로 포드가 다시 생성되고 csinode CRD가 다시 생성됩니다.


VMware, Inc. 60

vSphere 클라우드 네이티브 스토리지 문제 해결 6로그 파일을 사용하여 클라우드 네이티브 스토리지 환경의 문제를 해결할 수 있습니다.

Kuberenetes 클러스터 배포 관련 문제를 해결하려면 Kubernetes 설명서를 참조하십시오.


n CNS 로그 파일 사용

n 로그 수준 수정

CNS 로그 파일 사용

볼륨 또는 포드를 생성하거나 삭제할 때 발생하는 문제를 해결해야 하는 경우에는 vsphere-csi-

controller-0 포드와 관련된 로그 파일을 사용합니다.

vsphere-csi-controller-0 포드는 csi-attacher, vsphere-csi-controller, liveness-probe, vsphere-

syncer 및 csi-provisioner 컨테이너를 실행합니다.

n 볼륨을 생성하거나 삭제하는 동안 문제가 발생하면 csi-provisioner와 vsphere-csi-controller의

로그를 검사합니다.

n 포드를 생성하거나 삭제하는 동안 문제가 발생하면 csi-attacher와 vsphere-csi-controller의 로

그를 검사합니다.

로그 파일은 kubectl logs 명령을 사용하여 가져올 수 있습니다. 예를 들어,

$ kubectl logs vsphere-csi-controller-0 --namespace=kube-system -c csi-provisioner

$ kubectl logs vsphere-csi-controller-0 --namespace=kube-system -c vsphere-csi-controller

포드가 예약된 master 노드의 로그 파일을 확인할 수도 있습니다. 이 파일은 master 노드

의 /var/log/containers에 있습니다. vsphere-csi-controller-0 접두사가 있는 파일을 찾습니다. 예를

들어,

$ pwd

/var/log/containers

$ ls -la | grep "vsphere-csi-controller-0"

lrwxrwxrwx 1 root root 106 Jul 25 17:07 vsphere-csi-controller-0_kube-system_csi-

attacher-37dbb7c510a8e441dd4c3de567336d36b45d1eff7e4a52ebe3b56745dab59ff1.log -> /var/log/pods/kube-

system_vsphere-csi-controller-0_5a203037-af39-11e9-b26e-005056a04307/csi-attacher/0.log

lrwxrwxrwx 1 root root 109 Jul 25 17:07 vsphere-csi-controller-0_kube-system_csi-

provisioner-3355757fa31283cd01cbe85ab3d4780f7c5a80ef0f5712374eff0991e0d9d1ad.log -> /var/log/pods/kube-

system_vsphere-csi-controller-0_5a203037-af39-11e9-b26e-005056a04307/csi-provisioner/0.log

VMware, Inc. 61

lrwxrwxrwx 1 root root 108 Jul 25 17:07 vsphere-csi-controller-0_kube-system_liveness-

probe-0ea1802644a959a46f0d871f3d03b2c2422678a2f2ac551bcf352094eec8ad26.log -> /var/log/pods/kube-system_vsphere-

csi-controller-0_5a203037-af39-11e9-b26e-005056a04307/liveness-probe/0.log

lrwxrwxrwx 1 root root 116 Jul 25 17:07 vsphere-csi-controller-0_kube-system_vsphere-csi-controller-

d82966b97372338818b657892918d061f964cdc8c7898f84d8737367e19c670e.log -> /var/log/pods/kube-system_vsphere-csi-

controller-0_5a203037-af39-11e9-b26e-005056a04307/vsphere-csi-controller/0.log

lrwxrwxrwx 1 root root 108 Jul 25 17:07 vsphere-csi-controller-0_kube-system_vsphere-syncer-

fb45ae5d4e0ca7ce595ff767ef449d1c087b920031e48863431e1671071fe079.log -> /var/log/pods/kube-system_vsphere-csi-

controller-0_5a203037-af39-11e9-b26e-005056a04307/vsphere-syncer/0.log

vCenter Server 측의 로그를 확인하려면 다음 위치에서 cns 접두사가 있는 로그를 검색합니다.

n 프로비저닝 워크플로와 관련된 로그를 확인하려면 vCenter Server에서 /var/log/vmware/vsan-

health/vsanvcmgmtd.log 파일을 사용합니다.

n 인증 및 사용 권한 문제와 관련된 로그를 확인하려면 vCenter Server에서 /var/log/vmware/vsan-

health/vmware-vsan-health-service.log 파일을 사용합니다.

로그 수준 수정

CNS 환경과 관련된 문제를 검사할 수 있으려면 vSphere CSI 드라이버 및 vCenter Server 측의 로

그 수준을 늘립니다.

절차

1 vSphere CSI 드라이버 관련 문제를 검사하려면 csi-attacher, vsphere-csi-controller,

liveness-probe, vsphere-syncer 및 csi-provisioner 컨테이너에 대한 로그 수준을 늘립니다.

a vSphere CSI 드라이버 배포에 사용되는 YAML 파일을 열고 컨테이너의 인수에서 --v 옵션을

찾습니다.

b 이 옵션의 값을 4로 늘립니다.

c kubectl apply 명령을 실행하여 새 구성으로 포드를 다시 로드합니다.

$ kubectl apply -f csi-driver-deploy.yaml

statefulset.apps/vsphere-csi-controller configured

csidriver.storage.k8s.io/block.vsphere.csi.vmware.com unchanged

daemonset.apps/vsphere-csi-node configured

2 vCenter Server에서 기본 로그 수준을 verbose로 변경합니다.

a vCenter Server에 SSH를 실행합니다.

b /usr/lib/vmware-vpx/vsan-health/VsanVcMgmtConfig.xml을 엽니다.


VMware, Inc. 62

c 기본 로그 수준 verbose에 대한 주석 처리를 제거합니다.





d vsan-health 서비스를 다시 시작합니다.

vmon-cli --restart vsan-health


VMware, Inc. 63

Documents

VMware Cloud 네이티브 스토리지 시작 - VMware vSphere 6 · " VMware Cloud 네이티브 스토리지 시작" 설명서는 vSphere 환경에서 VMware® Cloud 네이티브