测验：认证、授权、准入、API 弃用

TokenRequest API 로 발급되어 파드에 projected 볼륨으로 들어가는 서비스 어카운트 토큰의 성질은?

• 만료되지 않으며 파드가 지워져도 계속 유효하다
• 네임스페이스 전체에 공유되어 같은 네임스페이스의 어느 파드든 쓸 수 있다
• kubelet 이 아니라 애플리케이션이 직접 API 서버에 요청해 받아야 한다
• 기본 1시간의 수명을 갖고 그 파드에 바인딩되며 kubelet 이 만료 전에 갱신한다

서비스 어카운트 토큰의 서명과 검증에 쓰이는 키가 있는 곳을 바르게 짝지은 것은?

• 각 노드의 kubelet 이 자기 노드 인증서의 키로 서명하고, etcd 가 저장 시점에 서명을 검증한다
• kube-controller-manager 의 개인 키(--service-account-private-key-file)로 서명하고, kube-apiserver 의 공개 키(--service-account-key-file)로 검증한다
• kube-apiserver 가 클러스터 CA(kubernetes-ca)의 개인 키로 서명하고, 각 노드의 kube-proxy 가 요청마다 검증한다
• ServiceAccount 오브젝트의 secrets 필드에 키 쌍이 들어 있어 각 파드가 시작할 때 스스로 토큰을 서명한다

RBAC 의 규칙과 바인딩에 대해 문서가 명시한 것은?

• 권한은 순수하게 더해지며 거부 규칙이 없고, RoleBinding 은 네임스페이스 안에서 권한을 붙인다
• Role 에 deny 규칙을 넣어 ClusterRole 이 준 권한을 네임스페이스에서 뺄 수 있다
• ClusterRole 은 네임스페이스에 속한 리소스이므로 RoleBinding 으로만 붙일 수 있다
• RoleBinding 하나로 모든 네임스페이스에 같은 권한을 한 번에 붙일 수 있다

어드미션 컨트롤러의 실행 순서와 적용 범위를 바르게 설명한 것은?

• validating 단계가 먼저 돌고 통과한 요청만 mutating 단계에서 바뀐다
• mutating 과 validating 이 동시에 병렬로 돌고 다수결로 결정한다
• mutating 단계가 먼저 돌아 데이터를 바꾸고 그다음 validating 단계가 검사하며, 읽기 요청은 어드미션을 거치지 않는다
• 모든 요청이 어드미션을 거치며 get·list·watch 도 정책 위반이면 거부된다

API 폐기 정책의 규칙 4a 에 따른 beta API 버전의 수명은?

• 예고 없이 어느 릴리스에서든 제거될 수 있다
• 폐기 표시는 될 수 있어도 메이저 버전 안에서는 제거되지 않는다
• 도입 뒤 정확히 1년이 지나면 자동으로 GA 로 승격된다
• 도입 뒤 9개월 또는 3 minor 중 긴 쪽 안에 폐기되고, 폐기 뒤 9개월 또는 3 minor 중 긴 쪽 뒤에 서비스가 중단된다

폐기된 API 버전으로 쓰인 YAML 매니페스트를 새 버전으로 옮길 때 이전 안내 문서가 제시한 도구와 그 성질은?

• kubectl convert -f <파일> --output-version <그룹>/<버전> — 기본 설치에 없는 플러그인이며 이상적이지 않은 기본값을 넣을 수 있다
• kubectl apply --force — 서버가 자동으로 최신 버전으로 변환해 저장한다
• kubectl edit — 편집기를 열면 apiVersion 이 자동으로 최신 값으로 바뀐다
• kubeadm upgrade apply — 클러스터 업그레이드 시 모든 매니페스트 파일을 함께 변환한다