지원콘솔개발자평가판 시작연락처

7.4. 예상된 볼륨을 사용하여 볼륨 매핑

예상 볼륨은 여러 개의 기존 볼륨 소스를 동일한 디렉터리에 매핑합니다.

다음 유형의 볼륨 소스를 예상할 수 있습니다.

  • 보안
  • Config Map
  • Downward API
참고

모든 소스는 Pod와 동일한 네임스페이스에 있어야 합니다.

7.4.1. 예상 볼륨 이해

예상 볼륨은 해당 볼륨 소스의 조합을 단일 디렉터리에 매핑할 수 있어 사용자는 다음을 수행할 수 있습니다.

  • 여러 보안의 키, 구성 맵, Downward API 정보를 사용하여 단일 볼륨을 자동으로 채워 단일 디렉터리를 다양한 정보 소스와 합성할 수 있습니다.
  • 여러 보안의 키, 구성 맵, Downward API 정보를 사용하여 단일 볼륨을 채우고 각 항목의 경로를 명시적으로 지정하여 해당 볼륨의 콘텐츠를 완전히 제어할 수 있습니다.
중요

Linux 기반 Pod의 보안 컨텍스트에서 RunAsUser 권한이 설정된 경우 예상된 파일에는 컨테이너 사용자 소유권을 포함하여 올바른 권한이 설정됩니다. 그러나 Windows Pod에 해당하는 Windows 동등한 RunAsUsername 권한이 설정된 경우 kubelet은 예상 볼륨의 파일에 대한 소유권을 올바르게 설정할 수 없습니다.

따라서 Windows Pod의 보안 컨텍스트에서 설정된 RunAsUsername 권한은 OpenShift Container Platform에서 실행되는 Windows 예상 볼륨에 대해 지원되지 않습니다.

다음 일반 시나리오에서는 예상 볼륨을 사용하는 방법을 보여줍니다.

구성 맵, 보안, 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에서 애플리케이션을 사용하여 암호화된 전송을 사용하지 않고도 네임스페이스 정보를 안전하게 전달할 수 있습니다.

7.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를 명시적으로 설정할 수 있습니다.

7.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 생성 후 업데이트된 리소스 포함).
하나의 경로는 명시적이고 다른 경로는 자동으로 예상될 때의 충돌
사용자가 지정한 경로가 자동 예상 데이터와 일치하여 충돌이 발생하는 경우 위에서와 마찬가지로 자동 예상 데이터가 이전의 모든 리소스를 덮어씁니다.

7.4.2. Pod의 예상 볼륨 구성

예상 볼륨을 생성할 때는 예상 볼륨 이해에 설명된 볼륨 파일 경로 상황을 고려하십시오.

다음 예제에서는 예상 볼륨을 사용하여 기존 보안 볼륨 소스를 마운트하는 방법을 보여줍니다. 이 단계를 사용하여 로컬 파일에서 사용자 이름 및 암호 보안을 생성할 수 있습니다. 그런 다음 예상 볼륨을 사용하여 하나의 컨테이너를 실행하는 Pod를 생성하여 동일한 공유 디렉터리에 보안을 마운트합니다.

사용자 이름 및 암호 값은 base64 로 인코딩된 유효한 문자열일 수 있습니다.

다음 예제에서는 admin을 base64 형식으로 보여줍니다. 

$ echo -n "admin" | base64

출력 예

YWRtaW4=

다음 예제에서는 암호 1f2d1e2e67df 를 base64로 보여줍니다. 

$ echo -n "1f2d1e2e67df" | base64

출력 예

MWYyZDFlMmU2N2Rm

프로세스

예상 볼륨을 사용하여 기존 보안 볼륨 소스를 마운트합니다.

  1. 시크릿을 생성합니다.

    1. 다음과 유사한 YAML 파일을 생성하고 암호 및 사용자 정보를 적절하게 교체합니다. 

      apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  pass: MWYyZDFlMmU2N2Rm
  user: YWRtaW4=

    2. 다음 명령을 사용하여 보안을 생성합니다. 

      $ oc create -f <secrets-filename>

      예를 들면 다음과 같습니다. 

      $ oc create -f secret.yaml

      출력 예

      secret "mysecret" created

    3. 다음 명령을 사용하여 보안이 생성되었는지 확인할 수 있습니다. 

      $ 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

  2. 예상 볼륨이 포함된 Pod를 생성합니다.

    1. volumes 섹션을 포함하여 다음과 유사한 YAML 파일을 생성합니다. 

      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
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret 1
      1
      생성한 보안의 이름입니다.

    2. 구성 파일에서 Pod를 생성합니다. 

      $ oc create -f <your_yaml_file>.yaml

      예를 들면 다음과 같습니다. 

      $ oc create -f secret-pod.yaml

      출력 예

      pod "test-projected-volume" created

  3. 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

  4. 다른 터미널에서 oc exec 명령을 사용하여 실행 중인 컨테이너에 쉘을 엽니다. 

    $ oc exec -it <pod> <command>

    예를 들면 다음과 같습니다. 

    $ oc exec -it test-projected-volume -- /bin/sh

  5. 쉘에서 projected-volumes 디렉터리에 예상 소스가 포함되어 있는지 확인합니다. 

    / # ls

    출력 예

    bin               home              root              tmp
dev               proc              run               usr
etc               projected-volume  sys               var

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.