이 기능은 평가 및 테스트 목적으로 제공되는 실험적 기능으로, 예고 없이 변경될 수 있습니다.

기밀 컨테이너 만들기

Kata 컨테이너 또는 OpenShift 샌드박스 컨테이너라고도 하는 기밀 컨테이너를 Red Hat OpenShift on IBM Cloud 클러스터에 설치하고 사용하는 방법을 알아보세요.

기밀 컨테이너란 무엇인가요?

기밀 컨테이너는 민감한 워크로드를 위한 안전한 런타임 환경을 제공하지만 기존 워크플로 내에서 계속 작업할 수 있습니다.

기밀 컨테이너의 IBM Cloud 구현은 피어 파드를 활용하여 Red Hat OpenShift 파드의 기능을 워커 노드에서 별도의 VSI로 확장합니다. 이 확장은 기존 Kubernetes 및 OpenShift 을 뛰어넘는 신뢰할 수 있는 실행 환경을 만듭니다.

자세히 보기:

기밀 컨테이너를 사용해야 하는 이유를 검토하세요.
기밀 컨테이너는 자주 묻는 질문 에서 확인하세요.

전제조건

사용할 Red Hat OpenShift on IBM Cloud 클러스터를 만들거나 선택할 때 클러스터는 다음 요구 사항을 충족해야 합니다:
- 클러스터는 TDX 가상 서버 인스턴스(VSI)를 지원하는 지역에 있어야 합니다.
- 클러스터에 공용 인터페이스가 있거나 VPN을 통해 클러스터 환경에 연결할 수 있어야 합니다.
- 클러스터가 기밀 컨테이너로 생성된 VSI와 통신할 수 있도록 하려면 클러스터의 이름이 kube-CLUSTER_ID 인 보안 그룹을 만들어야 합니다.
필요한 경우 OperatorHub. 보안상의 이유로 클러스터에서 OperatorHub 을 비활성화하는 경우가 있습니다.

1단계: 오퍼레이터 설치

OpenShift 샌드박스가 적용된 컨테이너 운영자를 설치하여 클러스터에서 기밀 컨테이너의 수명 주기를 관리하세요.

클러스터 대시보드를 엽니다.
OpenShift 웹 콘솔 > 운영자 > OperatorHub.
OpenShift sandboxed containers Operator 을 검색하고 타일을 클릭합니다.
설치를 클릭하여 지원되고 안정적인 버전의 OpenShift 샌드박스가 적용된 컨테이너 오퍼레이터, 버전 1.10.3 을 받습니다. 지원되는 OpenShift 버전은 Red Hat 의 운영자 업데이트 정보 확인기를 참조하세요.
운영자 설치 창에서 기본 선택 사항을 그대로 유지하고 설치를 클릭할 수 있습니다.
설치가 완료될 때까지 대기하십시오. 네임스페이스에 설치된 운영자 보기 openshift-sandboxed-cont테이너-운영자 링크를 클릭하고 상태가 성공이 될 때까지 기다립니다. 기다리는 동안 다음 단계를 완료하여 CLI를 설정할 수 있습니다.

2단계: CLI 설정

시작하기 전에 다음 단계를 완료하여 CLI를 설정하거나 IBM Cloud 셸을 사용하여 명령을 실행할 수 있습니다.

IBM Cloud 명령줄을 설치합니다.
ks 및 oc CLI 도구를 설치합니다.

IBM Cloud CLI에 로그인하십시오.

ibmcloud login --apikey API_KEY -g RESOURCE_GROUP

계정에 클러스터를 나열하고 다음 단계에 사용할 클러스터의 ID를 복사합니다.
```
ibmcloud ks cluster ls
```
config 명령을 실행하십시오.
```
ibmcloud ks cluster config --cluster CLUSTER_ID --admin --endpoint link
```
홈 디렉터리에 .kube 폴더가 만들어지고 해당 클러스터와의 통신을 위한 정보가 저장됩니다.
클러스터에서 작업자 노드의 세부 정보를 확인하여 oc 명령이 제대로 실행되는지 확인합니다.
```
oc get nodes
```
이후 명령에 네임스페이스를 포함할 필요가 없도록 네임스페이스 프로젝트를 설정합니다.
```
oc project openshift-sandboxed-containers-operator
```
선택 사항입니다: 네임스페이스를 탐색합니다.
```
oc get all
```
예를 들어, 파드 목록에서 pod/controller-manager-<id> 이라는 이름의 컨트롤러 관리자는 운영자 내의 마이크로서비스를 관리합니다.
is CLI 도구를 설치합니다.

3단계: 피어 포드 이미지 가져오기

OpenShift 샌드박스가 적용된 컨테이너 오퍼레이터는 피어 포드 내에서 특수 운영 체제를 시작하며, 이 운영 체제를 IBM Cloud 계정으로 가져와야 합니다. 이 운영 체제는 기밀 컨테이너에 워크로드를 배포하는 데 필요합니다.

피어 포드 이미지에는 CVM(기밀 가상 머신)에서 컨테이너를 인스턴스화하는 데 필요한 소프트웨어가 포함된 전체 Red Hat Enterprise Linux (RHEL) 9.6 운영 체제가 포함되어 있습니다.

운영 체제의 모든 구성 및 설치된 패키지는 기본 Red Hat 값을 유지합니다. 그러나 IBM Cloud VSI는 작동하기 위해 cloud init 필요합니다. 스크립트에서 cloud init 은 소스 이미지와 중요한 차이점인 podvm 의 빌드가 완료되면 제거되지 않도록 합니다.

시작하기 전에:

버전 호환성을 확인합니다. 이 이미지는 다음 버전에서 지원됩니다.

OpenShift 샌드박스 컨테이너 운영자 버전 1.10.3
OpenShift 버전 4.19, 4.18, 4.17, 4.16 클러스터

피어 포드 이미지를 가져오려면 다음과 같이 하세요:

명령을 image-create 실행하십시오.

# Note IMAGE_NAME is a placeholder variable. Image names do not support capitalization.
ibmcloud is image-create "IMAGE_NAME" --file cos://us-south/podvm-image/rhel9-podvm-latest.qcow2  --os-name red-9-amd64

컴퓨팅 이미지를 엽니다.
생성 + 아이콘을 클릭하고, TDX 지원 VSI가 있는 리전을 선택한 후 필수 항목을 입력하세요.

a. 이미지 소스의 경우 Cloud Object Storage.

b. 이미지 파일로 찾기 URL 탭을 선택하고 이미지 URL 에 cos://us-south/podvm-image/rhel9-podvm-latest.qcow2 를 입력합니다.

c. 운영 체제의 경우 Red Hat Enterprise Linux > red-9-amd64.

d. 선택 사항입니다: 나중에 동일한 세부 정보를 사용하여 API에서 다른 비공개 컨테이너를 만들려면 샘플 API 호출 가져오기 버튼을 클릭하고 Curl 명령을 복사합니다.

e. '사용자 지정 이미지 만들기 '를 클릭합니다.
이미지가 이미지 목록에 추가되면 이미지 이름을 클릭하고 ID 탭을 선택합니다. 그런 다음 나중에 사용할 이미지 ID 를 기록해 두십시오.
이미지의 상태가 사용 가능으로 바뀔 때까지 기다립니다.
```
ibmcloud is image IMAGE_NAME
```
새 버전의 이미지를 사용할 수 있으면 이 단계를 반복합니다.

4단계: API 키 또는 신뢰할 수 있는 프로필 만들기

기밀 컨테이너는 보안 워크로드가 시작될 때 kata-remote 을 통해 피어 파드를 인스턴스화하기 위해 자격 증명이 필요합니다. 이 자격 증명은 유효한 API 키이거나 계정에서 VSI를 만들 수 있는 권한이 있는 신뢰할 수 있는 프로필이어야 합니다.

기밀 컨테이너를 테스트하는 경우 API 키를 사용할 수 있습니다. Secrets Manager 을 사용하는 경우 신뢰할 수 있는 프로필을 설정해야 합니다.

UI에서 생성한 API 키
1. IBM Cloud 대시보드에서 관리 > 액세스(IAM) > API 키를 클릭합니다.
2. 작성을 클릭하십시오.
3. 이 키는 나중에 이 페이지에서 검색할 수 없으므로 안전하게 저장하세요.
CLI에서 API 키.

다음 명령을 실행하고, 출력 결과를 저장하십시오.
```
ibmcloud iam api-key-create KEY_NAME
```
신뢰할 수 있는 프로파일
1. 신뢰할 수 있는 프로필 대시보드를 엽니다.
2. 신뢰할 수 있는 프로필을 만들고 OpenShift 에서 가상 서버를 만드는 데 필요한 권한을 프로필에 부여합니다.
  
  a. 신뢰할 수 있는 프로파일을 작성하십시오.
```
ibmcloud iam trusted-profile-create <NAME> [--description <DESCRIPTION>]
```
  b. openshift-sandboxed-containers-operator 의 리소스가 신뢰할 수 있는 프로필을 사용하도록 허용합니다.
```
ibmcloud iam trusted-profile-rule-create PROFILE_NAME_OR_ID --name RULE_NAME --type Profile-CR --conditions claim:namespace,operator:EQUALS,value:openshift-sandboxed-containers-operator --cr-type ROKS_SA
```
  c. VPC 인프라 서비스(is)에 대한 액세스를 허용합니다.
  
  계정의 모든 리소스에 대한 액세스를 허용합니다:
```
ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile>  --roles Editor,Writer --service-name is
```
  특정 리소스 그룹에 대한 액세스를 허용하려면:
```
ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile> --roles Viewer [--resource-group-id <resource group>]
```

5단계: SSH 키 만들기(선택 사항)

테스트 클러스터에서는 시작되지 않는 문제를 해결하고 로그를 볼 수 있도록 SSH 키를 준비해 두는 것이 도움이 될 수 있습니다. 프로덕션 클러스터에서는 SSH 기능을 사용하지 않을 수도 있습니다.

인프라 > 컴퓨팅 > SSH 키를 클릭합니다.
SSH 키를 생성하고 SSH 키 ID를 기록해 둡니다.

6단계: 기밀 컨테이너 구성

운영자가 설치된 후 ConfigMaps 을 생성하여 IBM Cloud 계정에서 Kata가 워크로드를 처리할 수 있도록 합니다.

파일을 저장할 디렉터리를 생성하십시오.
```
mkdir <directory-name>
```
디렉토리로 전환합니다.
```
cd <directory-name>
```
API 키, 신뢰할 수 있는 프로필 ID, 클러스터 이름, PodVM 이미지 ID, SSH 키 ID 및 VPC ID(선택 사항)에 대한 다음 환경 변수를 복사합니다.

선택 사항: 새 디렉터리의 셸 스크립트에 저장하여 나중에 다시 설정할 수 있습니다. 예: <directory-name>/env-vars.sh

a. 다음 변수의 값을 수집하고 스크립트에서 값을 업데이트합니다.
- CLUSTER_NAME 의 경우 클러스터 목록에서 클러스터 에 대한 세부 정보를 열고 이름을 복사합니다.
- 선택 사항입니다: VPC_ID 의 경우 같은 페이지의 클러스터 세부 정보 섹션에서 vpc 이름을 클릭하여 VPC에 대한 세부 정보를 열고 VPC ID 필드를 복사할 수 있습니다.
- PODVM_IMAGE_ID 의 경우 피어 포드 이미지에 저장한 이미지 ID를 사용합니다.
- API 키를 사용하는 경우 IBMCLOUD_TRUSTED_PROFILE_ID 줄을 제거할 수 있습니다.
- 신뢰할 수 있는 프로필을 사용하는 경우 IBMCLOUD_API_KEY 줄을 제거할 수 있습니다.
- SSH 키를 설정하지 않은 경우 SSH_KEY_ID 줄을 제거할 수 있습니다.
```
export IBMCLOUD_API_KEY=<your API key>
export IBMCLOUD_TRUSTED_PROFILE_ID="<your Trusted Profile ID>"
export CLUSTER_NAME=<cluster-name-region-flavor>
export PODVM_IMAGE_ID=<PodVM image ID provided by IBM or a custom-built image>
export SSH_KEY_ID=<SSH key ID to be used by the peer pod VSI>
export VPC_ID=<Optional: the VPC that your Openshift cluster is in>
```
b. 변수를 셸 스크립트에 저장한 경우 실행합니다. 예:
```
sh env-vars.sh
```

명령을 실행하여 feature-gates.yaml ConfigMap.

cat > feature-gates.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: osc-feature-gates
  namespace: openshift-sandboxed-containers-operator
data:
  deploymentMode: "DaemonSetFallback" # or DaemonSet to force it
  confidential: "true"
  layeredImageDeployment: "false"
EOF

ConfigMap 을 적용하십시오.
```
oc apply -f feature-gates.yaml
```

명령을 실행하여 peer-pods-secret.yaml 을 생성합니다. stringData 섹션에서 필요한 선택적 환경 변수를 모두 제거합니다.

cat > peer-pods-secret.yaml <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: peer-pods-secret
  namespace: openshift-sandboxed-containers-operator
type: Opaque
stringData:
  # either IBMCLOUD_API_KEY or IBMCLOUD_IAM_PROFILE_ID must be set
  # if you specify both the IBMCLOUD_API_KEY will be used
  # IBMCLOUD_IAM_ENDPOINT is optional
  IBMCLOUD_API_KEY: "$IBMCLOUD_API_KEY"
  IBMCLOUD_IAM_ENDPOINT: "https://iam.cloud.ibm.com/identity/token"
  IBMCLOUD_IAM_PROFILE_ID: "$IBMCLOUD_TRUSTED_PROFILE_ID"
EOF

클러스터에 해당 비밀을 적용하십시오.
```
oc apply -f peer-pods-secret.yaml
```

명령을 실행하여 peer-pods-cm.yaml ConfigMap. data 섹션에서 설정하지 않은 선택적 환경 변수를 모두 제거합니다.

cat > peer-pods-cm.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: peer-pods-cm
  namespace: openshift-sandboxed-containers-operator
data:
  CLOUD_PROVIDER: "ibmcloud"
  IBMCLOUD_PODVM_IMAGE_ID: "$PODVM_IMAGE_ID"
  IBMCLOUD_PODVM_INSTANCE_PROFILE_LIST: "bx3dc-2x10"
  IBMCLOUD_PODVM_INSTANCE_PROFILE_NAME: "bx3dc-2x10"
  IBMCLOUD_RESOURCE_GROUP_ID: "$(ibmcloud is vpc "$VPC_ID" -json | jq -r .resource_group.id)"
  IBMCLOUD_SSH_KEY_ID: "$SSH_KEY_ID"
  IBMCLOUD_VPC_ID: "$VPC_ID"
  IBMCLOUD_VPC_SG_ID: "$(ibmcloud ks security-group ls --cluster $CLUSTER_NAME -json | jq -r '.[] | select(.type == "cluster") | .id')"
  CLOUD_CONFIG_VERIFY: "false"
  CRI_RUNTIME_ENDPOINT: "/run/cri-runtime/containerd.sock"
  ENABLE_CLOUD_PROVIDER_EXTERNAL_PLUGIN: "false"
  VXLAN_PORT: ""
  TUNNEL_TYPE: ""
  INITDATA: ""
  PEERPODS_LIMIT_PER_NODE: "10"
EOF

PEERPODS_LIMIT_PER_NODE 설정은 워커 노드당 예약할 수 있는 피어 파드 VSI의 최대 수를 제어합니다. 기본값은 10입니다. 워커 노드 용량에 따라 이 값을 늘릴 수 있지만 Kubernetes 포드 제한( 16x64 워커의 경우 노드당 110개 포드) 및 워커 노드에서 사용 가능한 CPU 리소스의 제약을 받는다는 점에 유의하세요. 각 피어 파드는 실제 워크로드가 별도의 VSI에서 실행되더라도 Kubernetes 포드 구성의 작업자 노드에서 약 250m CPU와 120Mi 메모리를 소비합니다. 자세한 정보는 FAQ를 참조하십시오.

ConfigMap 을 적용하십시오.
```
oc apply -f peer-pods-cm.yaml
```

명령을 실행하여 kata-runtime-settings.yaml KataConfig.

cat > kata-runtime-settings.yaml <<EOF
apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: kata-runtime-settings
  namespace: openshift-sandboxed-containers-operator
spec:
  enablePeerPods: true
  logLevel: info
 #checkNodeEligibility: true
 #kataConfigPoolSelector:
 #  matchLabels:
 #    <label_key>: '<label_value>'
EOF

KataConfig 을 적용하십시오.
```
oc apply -f kata-runtime-settings.yaml
```

카타가 설치되고 데몬 세트가 시작되면 진행 상황을 모니터링할 수 있습니다.

프로젝트에서 OperatorHub openshift-sandboxed-containers-operator 프로젝트에서 KataConfig 가 진행 중임을 확인할 수 있습니다.
다음 명령을 실행하여 레이블이 현재 설치 상태로 업데이트되는 것을 확인할 수 있습니다.

    oc get nodes --output yaml|egrep "kata-ds-rpm-install|ibm-cloud.kubernetes.io/worker-id"
    ```
    가능한 상태:

    - `waiting_to_install`: Kata 설치가 노드에서 대기열에 대기 중입니다.
    - `installing`: Kata 설치가 진행 중입니다.
    - `installed`: Kata가 노드에 성공적으로 설치되었습니다.
    - `waiting_for_reboot`: 설치 또는 제거를 완료하려면 노드를 재부팅해야 합니다.
    - `waiting_to_uninstall`: Kata 제거가 노드에서 대기열에 대기 중입니다.
    - `uninstalling`: Kata 제거가 진행 중입니다.
    - `uninstalled`: Kata가 노드에서 성공적으로 제거되었습니다.

레이블이 업데이트되고 waiting_for_reboot 상태가 되면 각 작업자 노드를 한 번에 하나씩 재부팅합니다.

oc get nodes 을 실행하고 각 워커 노드가 installed 상태가 되면 설치가 완료된 것입니다.

피어 포드 제한 모니터링 및 조정하기

설치 후 피어 포드 용량을 모니터링하고 필요한 경우 PEERPODS_LIMIT_PER_NODE 설정을 조정할 수 있습니다.

모든 워커 노드에서 현재 피어 파드 제한을 확인합니다:

oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'

각 워커 노드에 할당된 리소스를 확인합니다:

for n in $(oc get nodes -o name); do
  echo "=== $n ==="
  oc describe "$n" | sed -n '/Allocated resources:/,/Events:/p'
done

현재 실행 중인 피어 파드의 수를 계산합니다:

oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l

설치 후 PEERPODS_LIMIT_PER_NODE 값을 늘리려면:

a. ConfigMap 를 업데이트하십시오.

oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
  --type merge \
  -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}'

b. 클라우드 API 어댑터 데몬 세트를 다시 시작합니다.

oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds

c. 새 한도가 적용되었는지 확인합니다.

oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'

7단계: 신뢰 기관 구성

증명은 기밀 컨테이너에서 매우 중요한 부분입니다. 컨테이너에서 실행 중인 코드가 수정되지 않았는지 공급망 코드 보안을 확인해야 합니다. 인텔 TDX 칩과 key-broker-service 프로토콜을 활용할 수 있습니다. podvm 이미지에는 이미 작동하는 TDX 드라이버 코드와 kbs_client 이 포함되어 있습니다. 하지만 수탁자 세부 정보로 초기 데이터를 구성해야 합니다.

수탁자를 선택합니다. 기밀 컨테이너의 수탁자에는 여러 가지 옵션이 있습니다.
- 개발 목적으로 VM 트러스티를 시작할 수 있습니다.
- 프로덕션 수준 서비스의 경우 인텔 트러스트 오소리티를 사용할 수 있습니다.
개발 목적으로 수탁자로 VM 을 선택한 경우 다음 구성 단계를 완료합니다.

a. 다음 스크립트에 수탁자 IP 주소를 삽입하고 실행하여 INITDATA 변수를 설정합니다.
```
export KBS_SERVICE_ENDPOINT="https://REPLACE_WITH_TRUSTEE_IP:8080"
export INITDATA=$(cat <<EOF | gzip | base64 -w0
algorithm = "sha256"
version = "0.1.0"
[data]
"aa.toml" = '''
[token_configs]
[token_configs.coco_as]
url = "$KBS_SERVICE_ENDPOINT"
[token_configs.kbs]
url = "$KBS_SERVICE_ENDPOINT"
'''
"cdh.toml"  = '''
socket = 'unix:///run/confidential-containers/cdh.sock'
credentials = []
[kbc]
name = "cc_kbc"
url = "$KBS_SERVICE_ENDPOINT"
'''
EOF
)
```
b. $INITDATA 환경 변수를 확인하십시오.
```
echo $INITDATA
```
c. openshift-sandboxed-containers-operator 네임스페이스의 peer-pods-cm.yaml ConfigMap 에 변수 값을 추가합니다.

d. openshift-sandboxed-containers-operator 네임스페이스에서 osc-caa-ds 데몬셋을 다시 시작합니다. 이 클라우드 API 어댑터 데몬셋은 IBM Cloud 와 통신하는 데 사용됩니다.
```
oc rollout restart daemonset.apps/osc-caa-ds
```
e. 포드를 확인하려면 다음 명령어를 실행하세요. 각 osc-caa-ds-<id> 파드에 대해 각 파드의 나이를 확인하여 파드가 다시 시작되었는지 확인합니다.
```
oc get pods
```
파드가 다시 시작되지 않으면 파드를 삭제하여 다시 생성하세요.
```
oc delete pod/osc-caa-ds-<id>
```
포드를 다시 봅니다.
```
oc get pods
```
f. INITDATA 의 각 워크로드 항목에 대해 이 단계를 반복합니다.

g. INITDATA 값은 개별 컨테이너에 어노테이션으로 적용할 수 있으며, 시작되는 컨테이너는 트러스티를 사용하도록 구성됩니다. 이 주석은 새 수탁자를 테스트하거나 INITDATA 의 변경 사항이 기밀 컨테이너를 손상시키지 않는지 확인할 때 유용할 수 있습니다.

주석 예시:
```
apiVersion: v1
kind: Pod
  metadata:
    name: mypod
    annotations:
      io.katacontainers.config.runtime.cc_init_data: $INITDATA
spec:
  runtimeClassName: kata-remote
```

8단계: 기밀 컨테이너 워크로드 실행하기

모든 레이블이 installed 로 업데이트된 후 pod.yaml 파일에 kata-remote 런타임 클래스 이름을 사용하여 워크로드를 배포합니다. Hello World 예제를 기밀 컨테이너에서 테스트 워크로드로 사용할 수 있습니다.

pod.yaml 파일을 작성하십시오.

oc apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: helloworld
    version: v1
  name: helloworld
spec:
  containers:
  - name: helloworld
    image: docker.io/istio/examples-helloworld-v1:1.0
    ports:
    - containerPort: 5000
  runtimeClassName: kata-remote
EOF

Virtual Servers 목록에서 배포를 모니터링합니다. VSI가 생성되면 실행 중 상태가 표시됩니다. VSI가 시작 상태에서 멈춘 것처럼 보이면 로그에서 문제가 있는지 확인하세요.

a. 팟(Pod) 이름을 가져오십시오.
```
oc get pods
```
b. 클라우드 API 어댑터 포드 중 하나에 대한 로그를 가져와 오류를 찾아보세요.
```
oc logs osc-caa-ds-<id>
```
다음 명령어를 실행하여 포드를 확인하십시오.
```
oc describe pod/helloworld
```
증명을 확인하려면 다음 명령을 실행하여 컨테이너에 실행합니다.
```
oc exec -it helloworld -- bash
```
그런 다음 다음 curl 명령을 실행하여 수탁자로부터 정보를 얻습니다.
```
curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1
```
작업을 마치면 컨테이너를 종료할 수 있습니다.
```
exit
```

문제가 있는 경우 openshift-sandboxed-containers-operator 네임스페이스에서 로그를 검토하세요.

컨트롤러가 관리하는 포드 로그:

    oc logs pod/controller-manager-<UNIQUE_ID>
    ```
- Cloud API 어댑터 포드 로그:

```sh {: pre}
    oc logs pod/osc-caa-ds-<UNIQUE_ID>
    ```
- 애플리케이션 로그: 지정된 위치에 따라 다릅니다.

이제 기밀 컨테이너 설정이 완료되었습니다! 추가 지원이 필요하십니까? 문제 해결 방법을 확인하세요.

워크로드 및 도구 제거

이러한 단계를 잘못된 순서로 완료하면 VSI와 같이 청구되는 리소스가 남을 수 있습니다.

워크로드 제거

클러스터에서 기밀 컨테이너를 사용하는 워크로드를 삭제합니다.

a. 모든 포드 표시.
```
oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"'
```
b. 파드를 삭제하면 해당 파드에 배포된 VSI가 삭제됩니다.
```
oc delete -f pod.yaml
```
이전의 ConfigMaps 설정을 잘못된 구성으로 변경했거나 인증 정보가 삭제된 경우, 소프트웨어가 리소스 제거를 위한 API 호출을 완료할 수 없으므로 수동으로 제거해야 합니다. 이 시나리오에서는 수동 제거만 사용해야 합니다. 새 OpenShift 클러스터를 생성하거나 워커 노드를 교체해야 할 수 있기 때문입니다.
Kata 구성을 삭제합니다. kata-runtime-settings.yaml 에서 작업자에서 카타를 제거하면 레이블이 업데이트되는 것을 볼 수 있습니다.

a. 노드 레이블이 waiting_for_reboot 상태가 될 때까지 모니터링합니다.

b. 워커를 한 번에 하나씩 재부팅하여 워커 노드에서 Kata 제거를 완료합니다.

c. 이 클러스터에서 다른 워크로드가 실행 중인 경우 해당 워커를 종료한 다음 다시 시작하세요.

d. 재부팅 후 kata-runtime-settings.yaml 삭제가 완료될 때까지 기다렸다가 다음 단계로 넘어갑니다. 재부팅 후 제거를 완료해야 하는 프로세스가 있습니다.

kata-runtime-settings.yaml 리소스 삭제에 실패하면 계속하지 마세요.
ConfigMaps 를 삭제하십시오.

운영자 제거하기

워크로드를 제거한 후 OpenShift 샌드박스가 적용된 컨테이너 오퍼레이터를 제거할 수 있습니다.

OperatorHub, 에서 운영자를 제거합니다.
openshift-sandboxed-containers-operator 네임스페이스에 남은 리소스가 없는지 확인합니다.
네임스페이스를 삭제하십시오.