소개
Orchard Market에는 매장 및 배송 애플리케이션을 위한 작은 상태 보드가 필요합니다. 보드 프로그램은 준비되어 있지만 현재 Kubernetes 실행 신원으로는 해당 Deployment를 읽을 수 없습니다. 보드에 전용 신원과 실제 원하는 복제본 수, 사용 가능한 복제본 수, 템플릿 이미지를 표시하는 데 필요한 권한만 부여하세요. 직원 네임스페이스, Secret, 워크로드 변경은 접근 범위 밖에 유지하세요.
결과물은 사용할 수 있는 보드와 CSV 다운로드, 그리고 실행 신원, 두 네임스페이스 권한 부여, 워크로드의 신원 선택을 설명하는 저장된 매니페스트 네 개입니다. 보드는 준비된 클러스터에 실제 HTTPS 요청을 보냅니다. 접근이 실패했을 때 대체할 정적인 성공 데이터는 없습니다.
기본 터미널 경로, 간단한 YAML, 네임스페이스, Pod, Deployment, Service, 레이블을 이미 알고 있어야 합니다. 이 실습에서는 ServiceAccount, Role, RoleBinding, 제공된 클라이언트를 사용 전에 설명합니다. 실제 단일 노드 Kubernetes 클러스터, 보드, 합성 애플리케이션 데이터, 진단 도구가 준비되어 있습니다. 클러스터를 설치하거나, 이미지를 빌드하거나, 클라이언트를 프로그래밍하거나, 토큰을 복사하지 않습니다. 시간은 읽기와 일반적인 실수에 필요한 시간을 포함한 저자의 예상치이며, 초보자의 완료 시간을 측정한 결과가 아닙니다.
보드 전용 실행 신원 만들기
이 단계에서는 보드의 실제 시작 신원을 읽고, 아직 애플리케이션 접근을 허용하지 않은 채 전용 ServiceAccount를 저장합니다.
Board 탭에서 시작하세요. Orchard Market에는 A clear view of the working day., Market stalls 및 Market delivery 그룹, 그리고 두 그룹 모두 Access denied · API 403이 표시되어야 합니다. 이것이 예상된 초기 문제입니다. 완성된 결과에는 catalogue가 원하는 복제본 2개/사용 가능 2개, checkout이 1개/1개, pickup이 1개/1개, receipts가 0개/0개로 표시됩니다. 네 Deployment 모두 준비된 python:3.12-alpine 템플릿 이미지를 사용합니다. 영수증 아카이브는 의도적으로 복제본 수를 0으로 설정했습니다.
주요 필드 세 개는 서로 다른 질문에 답합니다. Desired replicas는 Deployment에 선언된 수입니다. Available replicas는 readiness 검사와 최소 준비 시간을 거친 뒤 컨트롤러가 집계한 수입니다. Template image는 Deployment 템플릿이 요청한 이미지입니다. 업데이트 중에는 기존의 모든 Pod가 이미 그 이미지를 사용한다는 증거가 아닙니다. What these fields mean을 펼쳐 읽은 뒤 다시 접으세요. 이는 컨트롤러 관찰이며 고객 웹사이트의 가동 시간 검사가 아닙니다.
Access details를 선택하세요. Read as 값은 API에서 오며, 처음에는 market-board:default로 끝납니다. 표는 의도한 권한 범위를 나타내며, 이미 접근이 허용되었다고 주장하는 것은 아닙니다. Back to status board를 사용한 뒤 Workspace로 전환하세요.
터미널은 /home/labex/project/status-board에서 시작합니다. pwd는 작업 디렉터리를 출력하고, ls는 그 안의 항목을 나열하며, 절대 경로를 사용한 cd는 디렉터리를 바꾼 경우 이곳으로 돌아옵니다.
pwd
ls
cd /home/labex/project/status-board
scope.json, starter, tools가 있어야 합니다. cat은 준비된 작업 범위 파일을 표시합니다. 이 파일은 이름이 있는 값과 목록으로 구성된 텍스트 형식인 JSON(JavaScript Object Notation)을 사용하여 실제 네임스페이스, 실행 신원, 애플리케이션 이름을 기록합니다.
cat scope.json
보드는 market-board에서 실행되고, 승인된 애플리케이션 데이터는 market-stalls와 market-delivery에 있습니다. market-office는 제외됩니다. --context=labex-v135는 준비된 클러스터를 선택하고, -n은 네임스페이스를 선택합니다. Workspace의 기존 운영자 자격 증명은 이 과정의 객체를 조사하고 구성할 수 있습니다. 보드의 자격 증명과는 다릅니다. 해당 운영자로 실제 대상 Deployment를 조사하세요.
kubectl --context=labex-v135 get deployments -n market-stalls
kubectl --context=labex-v135 get deployments -n market-delivery
원하는 수가 0인 영수증 아카이브를 포함하여 이름과 원하는/사용 가능한 복제본 결과를 읽으세요. 보드가 읽을 수 없어도 실제 객체는 존재합니다. 이 운영자 터미널에서 성공했다고 해서 보드 Pod 안의 프로세스에 접근 권한이 있다는 뜻은 아닙니다.
ServiceAccount는 네임스페이스에 속하는 워크로드용 Kubernetes API 신원이며, Linux 사용자나 브라우저 방문자가 아닙니다. 준비된 보드 Deployment는 처음에 default ServiceAccount를 선택합니다. describe는 객체 구성을 읽기 쉬운 구역으로 보여 줍니다.
kubectl --context=labex-v135 describe deployment status-board -n market-board
Pod 템플릿에서 선택된 ServiceAccount를 찾으세요. Pod에는 해당 계정의 projected 자격 증명이 제공됩니다. 준비된 클라이언트는 이를 내부에서 읽고 제공된 인증 기관을 사용하여 API 서버 인증서를 검증합니다. 자격 증명을 출력하거나 운영자의 kubeconfig를 사용하지 않습니다. 여러분은 자격 증명 처리를 구현하는 대신 신원과 권한을 구성합니다.
제공된 ./tools/board-test는 현재 보드 Pod 안에서 해당 클라이언트를 실행합니다. 앞의 ./는 도구가 이 작업 디렉터리에 있다는 뜻입니다. 첫 번째 인수는 실습에서 다루는 진단 작업을 선택합니다. identity는 이 실제 자격 증명이 어떻게 인증되었는지 API에 묻습니다.
./tools/board-test identity
username은 system:serviceaccount:market-board:default이며 현재 pod_uid도 있어야 합니다. http_status 값 201은 API가 이 자기 신원 검토에 응답했다는 뜻입니다. 이 검토는 영구 저장되는 클러스터 객체가 아니며, 권한을 변경하거나 Deployment를 생성하지 않습니다. 토큰은 표시되지 않습니다. 보드 프로세스가 준비되어 있고 신원이 확인되어도 애플리케이션 데이터 접근 권한은 여전히 없을 수 있습니다.
릴리스 디렉터리를 만드세요. mkdir -p는 필요하면 만들고 기존 디렉터리는 보존합니다. 다음 명령의 >는 출력을 편집 가능한 파일로 리디렉션합니다. 따옴표로 감싼 YAML 표시는 한 줄에 단독으로 놓인 마지막 표시까지 텍스트를 문자 그대로 유지합니다. 명령을 반복하면 해당 릴리스 파일만 덮어씁니다.
mkdir -p release
cat > release/identity.yaml <<'YAML'
apiVersion: v1
kind: ServiceAccount
metadata:
name: market-reader
namespace: market-board
YAML
파일을 읽고 적용하세요. apply -f는 이름으로 지정한 매니페스트를 읽고 해당 객체를 생성하거나 업데이트합니다.
cat release/identity.yaml
kubectl --context=labex-v135 apply -f release/identity.yaml
kubectl --context=labex-v135 get serviceaccount market-reader -n market-board
이제 전용 신원이 존재합니다. 수명이 긴 토큰 Secret이 반드시 필요한 것은 아닙니다. Kubernetes는 Pod가 그 신원을 사용할 때 Pod에 바인딩된 자격 증명을 투영합니다. ServiceAccount를 만드는 것만으로 Deployment 접근 권한이 생기거나 실행 중인 보드의 신원이 바뀌지는 않습니다. 원래 default 계정은 변경하지 마세요.
경로를 잘못 입력했다면 이미 본 pwd, ls, 절대 경로 cd를 사용한 뒤 실패한 작업을 반복하세요. YAML 오류는 편집 가능한 파일을 읽고 전체 예제와 들여쓰기를 비교한 뒤 다시 작성하여 적용하세요. scope.json, starter, 도구, 원래 네임스페이스, 애플리케이션, 데이터는 변경하지 마세요. 편집하는 대상은 지정된 릴리스 매니페스트와 해당 이름의 신원/RBAC 객체, 그리고 보드 Deployment에서 선택한 ServiceAccount뿐입니다.
첫 번째 네임스페이스 연결하기
이 단계에서는 매장 네임스페이스에서 읽기 작업 두 개를 허용한 뒤, 새 보드 Pod가 실제로 전용 신원을 사용하도록 합니다.
Workspace의 /home/labex/project/status-board에서 시작하세요. Kubernetes RBAC는 역할 기반 접근 제어를 뜻합니다. Role은 한 네임스페이스 안의 권한을 정의합니다. RoleBinding은 해당 네임스페이스의 Role을 신원에 연결합니다. 이름이 일치하는 것만으로 이 연결이 만들어지지는 않습니다.
보드는 Deployment 컬렉션을 읽기 위해 list가, 개별 Deployment를 열기 위해 get이 필요합니다. Deployment는 apps API 그룹에 속합니다. 규칙에서는 apps를 사용하고 /v1은 붙이지 않습니다. watch는 변경 스트림을 요청하는 동작이며 이 보드는 사용하지 않습니다. 쓰기 동사나 Secret 접근은 필요하지 않습니다. 승인된 각 네임스페이스의 모든 Deployment에 두 읽기 동사를 모두 허용하세요. 이름을 지정한 리소스로 권한을 제한하는 선택적 규칙 필드인 resourceNames는 생략합니다. 바인딩의 roleRef.apiGroup은 RBAC API인 rbac.authorization.k8s.io를 식별합니다. Role이 허용하는 Deployment가 속한 apps 그룹과는 다릅니다.
하나의 매니페스트에 Role과 바인딩을 저장하세요. --- 구분자는 두 번째 YAML 문서를 시작합니다. 바인딩의 metadata.namespace는 권한이 적용되는 위치이고, subjects.namespace는 ServiceAccount가 존재하는 위치입니다. 여기서는 의도적으로 서로 다릅니다.
cat > release/first-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-stalls
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-stalls
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
두 객체를 읽고 적용한 뒤 해석된 연결을 조사하세요.
cat release/first-access.yaml
kubectl --context=labex-v135 apply -f release/first-access.yaml
kubectl --context=labex-v135 describe role deployment-reader -n market-stalls
kubectl --context=labex-v135 describe rolebinding board-reader -n market-stalls
Deployment에 대한 get과 list만 있어야 합니다. roleRef를 따라 market-stalls의 Role을 확인하고, subject를 따라 market-reader를 확인하세요. 이 계정은 market-board에 있습니다. 바인딩은 대상 네임스페이스에 두 번째 ServiceAccount를 생성하지 않습니다.
실행 중인 보드는 여전히 default를 사용합니다. 진단 도구의 list 작업은 해당 Pod의 현재 자격 증명으로 실제 Deployment 컬렉션을 요청합니다. 금지된 읽기는 http_status: 403과 0이 아닌 명령 종료 상태를 반환합니다. 워크로드 신원을 전환하기 전에는 예상된 결과입니다.
./tools/board-test list market-stalls
새 권한은 market-reader에 속하며 default에는 부여되지 않았습니다. default 계정에 접근을 허용하여 해결하지 마세요. 준비된 보드 Deployment의 저장된 복사본에서 전용 계정을 선택하세요.
먼저 starter 전체를 읽으세요. 보존해야 하는 기존 이미지, 마운트된 소스, 상태 검사, 복제본 수, 기타 설정이 들어 있습니다.
cat starter/board.yaml
kubectl set serviceaccount는 선택된 신원을 변경합니다. --local은 클러스터에 적용하지 않고 이 입력 파일을 변환합니다. -f는 입력을 지정하고, -o yaml은 YAML 매니페스트를 표준 출력으로 쓰며, 이미 배운 >는 이를 편집 가능한 릴리스 파일로 저장합니다.
kubectl --context=labex-v135 set serviceaccount --local -f starter/board.yaml market-reader -o yaml > release/board.yaml
결과를 읽고 spec.template.spec.serviceAccountName이 market-reader인지 확인하세요. 다른 모든 애플리케이션 설정은 유지합니다.
cat release/board.yaml
kubectl --context=labex-v135 apply -f release/board.yaml
기존 Pod의 ServiceAccount는 제자리에서 변경할 수 없습니다. Deployment의 Pod 템플릿을 업데이트하면 새 Pod가 생성됩니다. rollout status는 새 워크로드를 기다리고, --timeout=120s는 대기 시간을 제한합니다.
kubectl --context=labex-v135 rollout status deployment/status-board -n market-board --timeout=120s
kubectl --context=labex-v135 get pods -n market-board
현재 보드 Pod 하나가 준비 상태여야 합니다. 이 보드 Pod를 교체하는 것은 필요하지만 대상 애플리케이션 Pod는 변경되지 않습니다. 실제 인증된 신원을 다시 읽으세요.
./tools/board-test identity
system:serviceaccount:market-board:market-reader와 원래 default 신원 Pod와는 다른 pod_uid가 예상됩니다. 이는 단순히 가장한 신원을 평가하는 것이 아니라 프로세스 자격 증명을 확인합니다.
Deployment 컬렉션과 상세 결과에는 Deployment의 원하는 상태 버전인 generation, 컨트롤러가 마지막으로 처리한 버전인 observed_generation도 포함됩니다. 상세 페이지의 레이블은 Deployment generation과 Observed generation입니다. 컨트롤러는 원하는 변경보다 잠시 뒤처질 수 있습니다. 이 필드들은 고객 요청 수를 세거나 웹사이트 가용성을 입증하지 않습니다.
매장 컬렉션과 개별 Deployment를 읽으세요. get은 네임스페이스 다음에 Deployment 이름을 받습니다.
./tools/board-test list market-stalls
./tools/board-test get market-stalls catalogue
http_status: 200, 컬렉션의 원래 매장 Deployment 두 개, 개별 결과에서 원하는 복제본 2개/사용 가능 2개의 catalogue가 예상됩니다. uid는 원래 객체를 식별합니다. 템플릿 이미지는 python:3.12-alpine으로 유지됩니다. 네임스페이스 Role은 배송 네임스페이스까지 확장되지 않습니다.
./tools/board-test list market-delivery
마지막 명령은 API 403과 0이 아닌 명령 상태가 예상됩니다. Board로 전환하여 Refresh view를 사용하고, Inspect catalogue를 열어 원하는/사용 가능한 복제본 수와 Template image를 읽으세요. Back to status board를 사용하세요. 매장 카드는 작동하지만 배송 그룹에는 여전히 Access denied · API 403이 표시되어야 합니다. 이 부분 결과는 네임스페이스 경계의 유용한 증거입니다.
롤아웃 직후 Read as에 이전 신원이 계속 표시되면 Refresh view를 다시 사용하세요. 현재 Pod를 확인하려면 Workspace로 전환하여 ./tools/board-test identity를 반복한 뒤 Board로 돌아와 새로고침하세요. Service 라우팅이 롤아웃을 따라잡는 데 잠시 걸릴 수 있습니다. 전환을 감추려고 이전 신원에 접근을 허용하지 마세요.
이 실행 예제에서 실제 읽기 신원, 성공한 매장 카드, 여전히 거부된 배송 그룹을 비교하세요.
롤아웃 시간이 초과되면 Workspace로 돌아와 이미 본 describe와 get 명령으로 같은 Deployment와 Pod를 조사하세요. 읽기가 예상과 달리 거부된다면 Role, RoleBinding의 subject 네임스페이스, 선택된 워크로드 신원을 비교하세요. 릴리스 파일만 수정하고 적용한 뒤 해당 롤아웃이나 요청을 반복하세요. 운영자 자격 증명을 복사하거나 애플리케이션을 변경하거나 VM을 재시작하지 마세요.
RoleBinding의 roleRef는 변경할 수 없습니다. 이전 오타로 이 과정에서 새로 만든 board-reader 바인딩에 잘못된 Role 참조가 들어갔다면 Kubernetes는 그 참조를 제자리에서 바꾸는 것을 거부합니다. 조사하고 release/first-access.yaml을 수정한 뒤, 자신이 만든 해당 이름의 바인딩만 다시 생성하고 수정된 저장 파일을 적용하세요.
kubectl --context=labex-v135 delete rolebinding board-reader -n market-stalls
kubectl --context=labex-v135 apply -f release/first-access.yaml
이는 조건부 복구 명령이며 정상 성공 경로에서 필수로 삭제하는 작업이 아닙니다. default나 플랫폼 바인딩을 삭제하지 말고, 원래 보드 Deployment나 대상 워크로드도 삭제하지 마세요.
읽기 범위를 유지하면서 보드 확장하기
이 단계에서는 같은 신원에 배송 네임스페이스의 동일한 읽기 작업 두 개를 허용한 뒤, 유용한 출력과 보호 경계를 검증합니다.
Workspace의 /home/labex/project/status-board에서 시작하세요. 두 번째 네임스페이스에는 자체 Role과 RoleBinding이 필요합니다. 해당 위치에서 Role 이름을 재사용하되 subject는 market-board에 유지하세요. 신원이 이동한 것은 아닙니다.
cat > release/second-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-delivery
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-delivery
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
cat release/second-access.yaml
kubectl --context=labex-v135 apply -f release/second-access.yaml
kubectl --context=labex-v135 describe rolebinding board-reader -n market-delivery
바인딩은 이 대상 Role을 기존 보드 신원에 부여합니다. 현재 Pod가 이미 그 신원을 사용하므로 추가 보드 롤아웃은 필요하지 않습니다. RBAC 권한 부여는 서로 합쳐집니다. 파일 순서를 바꿔도 거부 규칙이 생기거나 관련 없는 권한 부여가 제거되지 않습니다.
실제 보드 자격 증명으로 승인된 두 컬렉션과 배송 상세 하나를 읽으세요.
./tools/board-test list market-stalls
./tools/board-test list market-delivery
./tools/board-test get market-delivery pickup
원래 객체와 이미지가 포함된 API 200이 예상됩니다. 배송 컬렉션에는 원하는 복제본 1개/사용 가능 1개의 pickup과 0/0의 receipts가 있습니다. 원하는 수가 0인 Deployment는 실행 중인 Pod가 없어도 실제 객체로 남아 있습니다. 이 선언된 설정을 보존하세요.
이제 제외된 데이터를 확인하세요. Kubernetes Secret은 이름이 있는 데이터 값을 저장합니다. 준비된 staff-note는 합성 실습 자료이며 보드가 이를 읽을 이유는 없습니다. 운영자는 값을 표시하지 않고도 해당 객체가 존재함을 확인할 수 있습니다.
kubectl --context=labex-v135 get secret staff-note -n market-stalls
보드 자체 자격 증명은 세 번째 네임스페이스와 이 Secret에 대해 여전히 API 403을 받아야 합니다. 다음 두 명령은 모두 0이 아닌 상태로 끝나는 것이 예상됩니다.
./tools/board-test list market-office
./tools/board-test secret market-stalls staff-note
없는 객체, 연결 실패, 오류 스크린샷은 이 실제 권한 거부와 같지 않습니다. 같은 클라이언트가 승인된 대상을 성공적으로 읽는 동안 기존의 제외 대상 객체는 온전히 유지됩니다. projected 자격 증명 파일이 있다고 해서 Secret API 접근이 허용되지는 않습니다.
도구의 permission 작업은 이 실제 자격 증명으로 어떤 작업을 할 수 있는지 API에 묻습니다. 그 작업을 수행하지는 않습니다. 인수는 네임스페이스, 동사, 그리고 해당되는 경우 Deployment 이름입니다. 영구 저장되지 않는 검토는 금지된 각 작업에 대해 http_status: 201과 allowed: false를 반환합니다. 도구는 해당 거부에 0이 아닌 상태를 반환합니다.
./tools/board-test permission market-stalls patch catalogue
./tools/board-test permission market-delivery delete pickup
./tools/board-test permission market-stalls create
보드에는 get과 list만 필요합니다. watch 스트림이나 워크로드 변경은 허용되지 않습니다. default 신원과 원래 플랫폼 RBAC는 변경하지 마세요. ClusterRole, ClusterRoleBinding, 와일드카드, 추가 subject, 다른 리소스 권한을 추가하지 마세요.
Board로 전환하여 Refresh view를 사용하세요. 이제 두 그룹에 원래 Deployment가 표시됩니다. Inspect pickup을 열어 수와 이미지를 읽고 Back to status board를 사용하세요. receipts 카드를 읽으세요. Scaled to zero, 사용 가능 0개, 원하는 수 0개입니다. 이는 실패한 요청을 빈 값으로 대체한 것이 아닙니다.
이 완성 예제에서 실제 읽기 신원, Deployment 카드 네 개 전체, 원하는 수가 0으로 표시되는 아카이브를 비교하세요.
Download CSV를 선택하고 실제 다운로드한 orchard-market-deployments.csv를 여세요. 영수증 아카이브를 포함하여 원래 Deployment마다 하나씩 데이터 행 네 개가 있습니다. 네임스페이스, Deployment 이름, 원하는/사용 가능한 수, 템플릿 이미지, API 상태를 페이지와 맞춰 보세요. 이는 저장된 성공 샘플이 아니라 새 API 내보내기입니다. 브라우저 다운로드와 터미널 작업 공간은 서로 다른 위치이며, 다운로드를 작업 공간에 복사할 필요는 없습니다.
Access details를 선택하여 실제 Read as 값과 두 의도된 네임스페이스 범위를 확인한 뒤 Back to status board를 사용하세요. 모든 원래 대상 Deployment, Pod/컨테이너 식별 정보, 소스, 이미지, 데이터, 네임스페이스 레이블을 유지하세요. 원래 보드 Deployment와 Service를 보존하고 선택된 ServiceAccount만 바꿉니다. 재사용 가능한 릴리스에는 identity.yaml, first-access.yaml, second-access.yaml, board.yaml이 포함되며, 실제 신원과 실행 중인 권한에 일치합니다.
두 번째 네임스페이스가 계속 거부되면 Workspace로 돌아와 제시된 describe 명령으로 바인딩을 조사하세요. subject 네임스페이스와 Role 참조를 비교하고 저장된 파일을 수정하여 다시 적용하세요. 변경할 수 없는 잘못된 roleRef라면 앞서 배운 것과 같은 좁은 범위의 복구를 사용하되, 이제 자신이 새로 만든 배송 바인딩만 대상으로 하세요.
kubectl --context=labex-v135 delete rolebinding board-reader -n market-delivery
kubectl --context=labex-v135 apply -f release/second-access.yaml
이 특정 복구에만 실행하세요. 제외된 접근이 예상과 달리 성공하면 저장된 Role 두 개와 해당 바인딩을 조사하여 그 객체 안의 의도하지 않은 권한을 제거하고 다시 적용하세요. 넓은 권한 부여는 다른 좁은 Role로 덮어써지지 않습니다. 실수를 감추려고 플랫폼 권한이나 애플리케이션을 편집하지 마세요. 경로 및 YAML 오류는 VM을 초기화하지 않고 이전에 배운 복구를 사용합니다.
완성된 도구는 준비된 이 단일 노드 클러스터에서 컨트롤러가 보고한 Deployment 상태를 읽습니다. 보드 방문자를 인증하거나, Pod 로그나 메트릭을 읽거나, 프로덕션 가동 시간을 입증하지 않습니다. readiness 엔드포인트는 보드 프로세스가 응답할 수 있음만 확인하며, 애플리케이션 데이터에 접근할 수 있는지는 실제 API 결과로 입증됩니다.
요약
클러스터 내부의 실제 소비자에 전용 ServiceAccount를 부여하고, 네임스페이스 범위의 Role과 RoleBinding을 연결했으며, 새 Pod가 실제로 그 신원을 사용하도록 했습니다. 이어 제외된 데이터나 워크로드 변경 권한을 부여하지 않고 같은 읽기 작업을 두 번째 승인된 네임스페이스로 확장했습니다.
사용할 수 있는 보드, 현재 CSV, 저장된 매니페스트는 신원, 권한, 실제 API 출력을 연결합니다. 원하는 복제본 수, 컨트롤러가 보고한 가용성, 템플릿 이미지는 서로 다른 관찰로 유지됩니다. API 거부는 사용 불가로 남고, 의도적으로 원하는 수가 0인 Deployment는 실제 객체로 계속 표시됩니다.
