6.4. 예상된 볼륨을 사용하여 볼륨 매핑
예상 볼륨은 여러 개의 기존 볼륨 소스를 동일한 디렉터리에 매핑합니다.
다음 유형의 볼륨 소스를 예상할 수 있습니다.
- 보안
- Config Map
- Downward API
모든 소스는 Pod와 동일한 네임스페이스에 있어야 합니다.
6.4.1. 예상 볼륨 이해
예상 볼륨은 해당 볼륨 소스의 조합을 단일 디렉터리에 매핑할 수 있어 사용자는 다음을 수행할 수 있습니다.
- 여러 보안의 키, 구성 맵, Downward API 정보를 사용하여 단일 볼륨을 자동으로 채워 단일 디렉터리를 다양한 정보 소스와 합성할 수 있습니다.
- 여러 보안의 키, 구성 맵, Downward API 정보를 사용하여 단일 볼륨을 채우고 각 항목의 경로를 명시적으로 지정하여 해당 볼륨의 콘텐츠를 완전히 제어할 수 있습니다.
Linux 기반 포드의 보안 컨텍스트에 RunAsUser 권한이 설정된 경우 예상 파일에는 컨테이너 사용자 소유권을 포함하여 올바른 권한이 설정되어 있습니다. 그러나 Windows와 동등한 RunAsUsername 권한이 Windows Pod에 설정된 경우 kubelet에서 예상 볼륨의 파일에 대한 소유권을 올바르게 설정할 수 없습니다.
따라서 OpenShift Container Platform에서 실행되는 Windows 예상 볼륨에는 Windows Pod의 보안 컨텍스트에 설정된 RunAsUsername 권한이 적용되지 않습니다.
다음 일반 시나리오에서는 예상 볼륨을 사용하는 방법을 보여줍니다.
- 구성 맵, 보안, Downward API
-
예상 볼륨을 사용하여 암호가 포함된 구성 데이터가 있는 컨테이너를 배포할 수 있습니다. 이러한 리소스를 사용하는 애플리케이션은 Kubernetes에 RHOSP(Red Hat OpenStack Platform)를 배포할 수 있습니다. 서비스를 프로덕션 또는 테스트에 사용하는지에 따라 구성 데이터를 다르게 어셈블해야 할 수 있습니다. Pod에 프로덕션 또는 테스트로 라벨이 지정되면 Downward API 선택기
metadata.labels를 사용하여 올바른 RHOSP 구성을 생성할 수 있습니다. - 구성 맵 + 보안
- 예상 볼륨을 사용하면 구성 데이터 및 암호와 관련된 컨테이너를 배포할 수 있습니다. 예를 들면 Vault 암호 파일을 사용하여 암호를 해독하는 몇 가지 민감한 암호화된 작업에서 구성 맵을 실행할 수 있습니다.
- 구성 맵 + Downward API
-
예상 볼륨을 사용하면 Pod 이름(
metadata.name선택기를 통해 제공)을 포함하여 구성을 생성할 수 있습니다. 그러면 이 애플리케이션에서 IP 추적을 사용하지 않고 소스를 쉽게 확인할 수 있도록 요청과 함께 Pod 이름을 전달할 수 있습니다. - 보안 + Downward API
-
예상 볼륨을 사용하면 보안을 공개키로 사용하여 Pod의 네임스페이스(
metadata.namespace선택기를 통해 제공)를 암호화할 수 있습니다. 이 예제를 사용하면 Operator에서 애플리케이션을 사용하여 암호화된 전송을 사용하지 않고도 네임스페이스 정보를 안전하게 전달할 수 있습니다.
6.4.1.1. Pod 사양의 예
다음은 예상되는 볼륨을 생성하는 Pod 사양의 예입니다.
보안, Downward API, 구성 맵이 있는 Pod
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox
volumeMounts: 1
- name: all-in-one
mountPath: "/projected-volume"2
readOnly: true 3
volumes: 4
- name: all-in-one 5
projected:
defaultMode: 0400 6
sources:
- secret:
name: mysecret 7
items:
- key: username
path: my-group/my-username 8
- downwardAPI: 9
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "cpu_limit"
resourceFieldRef:
containerName: container-test
resource: limits.cpu
- configMap: 10
name: myconfigmap
items:
- key: config
path: my-group/my-config
mode: 0777 11
- 1
- 보안이 필요한 각 컨테이너에
volumeMounts섹션을 추가합니다. - 2
- 보안이 표시될 미사용 디렉터리의 경로를 지정합니다.
- 3
readOnly를true로 설정합니다.- 4
volumes블록을 추가하여 각 예상 볼륨 소스를 나열합니다.- 5
- 볼륨에 이름을 지정합니다.
- 6
- 파일에 대한 실행 권한을 설정합니다.
- 7
- 보안을 추가합니다. 보안 오브젝트의 이름을 입력합니다. 사용하려는 모든 시크릿을 나열해야 합니다.
- 8
mountPath아래에 보안 파일의 경로를 지정합니다. 여기에서 보안 파일은 /projected-volume/my-group/my-username에 있습니다.- 9
- Downward API 소스를 추가합니다.
- 10
- 구성 맵 소스를 추가합니다.
- 11
- 특정 예상에 대한 모드 설정
Pod에 컨테이너가 여러 개 있는 경우 각 컨테이너에 volumeMounts 섹션이 있어야 하지만 volumes 섹션은 하나만 있으면 됩니다.
기본이 아닌 권한 모드가 설정된 보안이 여러 개인 Pod
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
defaultMode: 0755
sources:
- secret:
name: mysecret
items:
- key: username
path: my-group/my-username
- secret:
name: mysecret2
items:
- key: password
path: my-group/my-password
mode: 511
defaultMode는 각 볼륨 소스가 아닌 예상 수준에서만 지정할 수 없습니다. 하지만 위에서 설명한 대로 개별 예상마다 mode를 명시적으로 설정할 수 있습니다.
6.4.1.2. 경로 지정 고려 사항
- 구성된 경로가 동일할 때 키 간 충돌
동일한 경로를 사용하여 여러 개의 키를 구성하면 Pod 사양이 유효한 것으로 승인되지 않습니다. 다음 예제에서
mysecret및myconfigmap에 지정된 경로는 동일합니다.apiVersion: v1 kind: Pod metadata: name: volume-test spec: containers: - name: container-test image: busybox volumeMounts: - name: all-in-one mountPath: "/projected-volume" readOnly: true volumes: - name: all-in-one projected: sources: - secret: name: mysecret items: - key: username path: my-group/data - configMap: name: myconfigmap items: - key: config path: my-group/data
볼륨 파일 경로와 관련된 다음 상황을 고려하십시오.
- 구성된 경로가 없는 키 간 충돌
- 발생할 수 있는 유일한 런타임 검증은 Pod 생성 시 모든 경로가 알려진 경우이며 위의 시나리오와 유사합니다. 이 경우에 해당하지 않으면 충돌이 발생할 때 최근 지정된 리소스가 이전의 모든 리소스를 덮어씁니다(Pod 생성 후 업데이트된 리소스 포함).
- 하나의 경로는 명시적이고 다른 경로는 자동으로 예상될 때의 충돌
- 사용자가 지정한 경로가 자동 예상 데이터와 일치하여 충돌이 발생하는 경우 위에서와 마찬가지로 자동 예상 데이터가 이전의 모든 리소스를 덮어씁니다.
6.4.2. Pod의 예상 볼륨 구성
예상 볼륨을 생성할 때는 예상 볼륨 이해에 설명된 볼륨 파일 경로 상황을 고려하십시오.
다음 예제에서는 예상 볼륨을 사용하여 기존 보안 볼륨 소스를 마운트하는 방법을 보여줍니다. 이 단계를 사용하여 로컬 파일에서 사용자 이름 및 암호 보안을 생성할 수 있습니다. 그런 다음 예상 볼륨을 사용하여 하나의 컨테이너를 실행하는 Pod를 생성하여 동일한 공유 디렉터리에 보안을 마운트합니다.
프로세스
예상 볼륨을 사용하여 기존 보안 볼륨 소스를 마운트합니다.
다음을 입력하고 암호 및 사용자 정보를 적절하게 교체하여 보안이 포함된 파일을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: pass: MWYyZDFlMmU2N2Rm user: YWRtaW4=
user및pass값은 base64로 인코딩된 유효한 문자열일 수 있습니다.다음 예제에서는
admin을 base64 형식으로 보여줍니다.$ echo -n "admin" | base64
출력 예
YWRtaW4=
다음 예제에서는 암호
1f2d1e2e67df를 base64 형식으로 보여줍니다.$ echo -n "1f2d1e2e67df" | base64
출력 예
MWYyZDFlMmU2N2Rm
다음 명령을 사용하여 보안을 생성합니다.
$ oc create -f <secrets-filename>
예를 들면 다음과 같습니다.
$ oc create -f secret.yaml
출력 예
secret "mysecret" created
다음 명령을 사용하여 보안이 생성되었는지 확인할 수 있습니다.
$ oc get secret <secret-name>
예를 들면 다음과 같습니다.
$ oc get secret mysecret
출력 예
NAME TYPE DATA AGE mysecret Opaque 2 17h
$ oc get secret <secret-name> -o yaml
예를 들면 다음과 같습니다.
$ oc get secret mysecret -o yaml
apiVersion: v1 data: pass: MWYyZDFlMmU2N2Rm user: YWRtaW4= kind: Secret metadata: creationTimestamp: 2017-05-30T20:21:38Z name: mysecret namespace: default resourceVersion: "2107" selfLink: /api/v1/namespaces/default/secrets/mysecret uid: 959e0424-4575-11e7-9f97-fa163e4bd54c type: Opaque
volumes섹션이 포함된 다음과 유사한 Pod 구성 파일을 생성합니다.apiVersion: v1 kind: Pod metadata: name: test-projected-volume spec: containers: - name: test-projected-volume image: busybox args: - sleep - "86400" volumeMounts: - name: all-in-one mountPath: "/projected-volume" readOnly: true volumes: - name: all-in-one projected: sources: - secret: 1 name: user - secret: 2 name: pass구성 파일에서 Pod를 생성합니다.
$ oc create -f <your_yaml_file>.yaml
예를 들면 다음과 같습니다.
$ oc create -f secret-pod.yaml
출력 예
pod "test-projected-volume" created
Pod 컨테이너가 실행 중인지 확인한 후 Pod 변경 사항을 확인합니다.
$ oc get pod <name>
예를 들면 다음과 같습니다.
$ oc get pod test-projected-volume
출력은 다음과 유사합니다.
출력 예
NAME READY STATUS RESTARTS AGE test-projected-volume 1/1 Running 0 14s
다른 터미널에서
oc exec명령을 사용하여 실행 중인 컨테이너에 쉘을 엽니다.$ oc exec -it <pod> <command>
예를 들면 다음과 같습니다.
$ oc exec -it test-projected-volume -- /bin/sh
쉘에서
projected-volumes디렉터리에 예상 소스가 포함되어 있는지 확인합니다./ # ls
출력 예
bin home root tmp dev proc run usr etc projected-volume sys var
