[쿠버네티스] CKA 기출 자료_1 [RBAC, Node] | 데인트리 라이브러리

 

 

이 페이지에서는 CKA 문제를 풀기위한 여러 쿠버네티스 기술을 다룬다.

 

 

 

*해당 포스트는 컨테이너의 개념과 쿠버네티스의 리소스에 대한 사전 지식이 필요합니다.

 

 

 CKA 시험은 직접 쿠버네티스 플랫폼을 다뤄야 하는 실기 시험이기 때문에 다른 객관식형 자격시험보다 난이도가 더 높다. 문제만 외워서 풀지 못하고 응용력이 있어야 하기 때문이다. 다행히 시험 중 문서를 확인할 수 있기 때문에 다양한 문제 유형을 풀어보며 이해도를 높이면 새로운 유형의 문제도 쉽게 풀 수 있을 것이다. 이번 글에서는 문제를 직접 소개하는 것보다 문제를 풀기 위해 어떤 방법을 적용했는지 소개하고, 관련 문서를 읽어볼 것이다. 최대한 간략하게 설명할 것이며, 추후 별도의 섹션을 통해 상세하게 다를 예정이다.

 

1. 서비스어카운트

서비스 어카운트: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

 

 서비스 어카운트는 파드가 쿠버네티스 API와 통신하기 위해 파드에 할당되는 하나의 ID이다. 파드 생성 시 서비스 어카운트를 할당하고, 해당 서비스 어카운트에 적절한 권한을 부여하여 쿠버네티스 API서버와 통신할 수 있다.

 

1) 서비스 어카운트 생성

#YAML
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader

#CLI
kubectl create serviceaccount pod-reader

 

2) 서비스 어카운트 조회

kubectl get serviceaccounts/pod-reader -o yaml

#출력:
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2015-06-16T00:12:59Z
  name: pod-reader
  namespace: default
  resourceVersion: "272500"
  uid: 721ab723-13bc-11e5-aec2-42010af0021e
secrets:
- name: pod-reader-token-bvbk5

서비스어카운트와 매칭되는 시크릿이 함께 생성된 것을 볼 수 있다. 시크릿은 암호화된 데이터를 저장하는 리소스이며 이 경우 서비스어카운트의 토큰을 저장한다.

 

서비스어카운트를 생성하는 것은 매우 간단하다. 다음으로 이 서비스어카운트에 적절한 역할을 부여해야 한다.

 

 

2. RBAC(Role-Based Access Control)

RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

 

쿠버네티스는 역할 기반으로 API 접근을 관리한다. 역할을 부여하기 위한 대상으로 앞서 서비스어카운트를 만들었고, 실제 역할을 만들어 서비스어카운트에 할당하는 것을 바인딩(Binding)이라고 한다.

 

역할은 Role, ClusterRole 두 가지로 분류된다. Role은 특정 네임스페이스에 속하게 되며, ClusterRole은 전체 클러스터에 고유한 역할이 된다. 역할을 서비스어카운트와 바인딩하는 것도 RoleBinding, ClusterRoleBinding 두 가지 방법이 있다. RoleBinding을 통해 바인딩한 Role과 ClusterRole은 특정 네임스페이스에서만 유효하며, ClusterRoleBinding으로 바인딩 시 모든 네임스페이스에 공통적으로 적용된다.

 

1) Role 생성

#YAML파일
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-read-role
rules:
- apiGroups: [""] 
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  
#CLI
kubectl create role pod-read-role --verb=get --verb=list --verb=watch --resource=pods

default 네임스페이스에 Role을 생성했다. 해당 롤은 pods 리소스에 get, watch, list 권한을 부여하는 Role이다. 

 

2) RoleBinding 생성

#YAML 파일
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-read-role-to-pod-reader
  namespace: default
subjects:
- kind: ServiceAccount
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-read-role
  apiGroup: rbac.authorization.k8s.io
  
#CLI
kubectl create rolebinding pod-read-role-to-pod-reader \
  --role=pod-read-role --serviceaccount=pod-reader --namespace=default

 

ClusterRole과 ClusterRoleBinding은 위의 사례와 거의 동일하기 때문에 생략하겠다. 실제 시험에서는 pods뿐 아니라 다른 리소스에도 권한을 적용해야 하는데 리소스 별로 API그룹이 다르다. 이를 확인하려면 문서에 API Reference Docs를 검색하여 아래의 링크로 들어간다.

(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/)

 

각 API그룹과 그룹의 버전을 확인할 수 있다. 예를 들어 Deployment에 대한 리소스를 조회하려면, 왼쪽 아래의 Deployment v1 apps라는 API명을 통해 apps그룹의 v1버전에 속한 리소스라는 것을 확인할 수 있다. {그룹명}/{버전} 으로 API그룹을 표기하며, Deployment의 경우 그룹명은 apps/v1이다.

 

아래는 Deployment의 목록을 조회할 수 있는 Role이다. apiGroups 필드에 apps/v1를 기재해야 한다.

#YAML파일
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: deployment-list-role
rules:
- apiGroups: ["apps/v1"] 
  resources: ["deployment"]
  verbs: ["list"]

 

맨 위의 pod-reader 예시에서는 apiGroups가 비어있는 것을 알 수 있다. 파드는 core/v1 그룹에 속해있는데, 해당 그룹은 생략 가능하기 때문에 apiGroups: [""]로 되어있다.

 

3. 노드

노드는 쿠버네티스 클러스터를 구성하는 하나의 VM또는 하드웨어이다. 

 

1) 노드가 NotReady 상태로 나올 때

쿠버네티스의 각 노드에는 kubelet이 실행된다. 이 kubelet은 노드 내에서 실제 컨테이너를 수행하는 역할을 하는데, 해당 프로세스가 제대로 실행되지 않으면 NotReady 상태로 조회되게 된다. 아래의 명령을 통해 ssh로 노드에 직접 접속한 후 kubelet을 재실행시킨다.

#node2가 NotReady 로 조회됨
kubectl get node

#node2로 접속
ssh node2

#kubelet 상태 조회 <- stop 상태로 조회됨
systemctl status kubelet

#kubelet 재시작 
systemctl restart kubelet
exit

#일정 시간 이후 정상 상태 확인
kubectl get node

 

2) 테인트(Taints)가 적용된 노드 확인하기

테인트,톨러레이션: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/

 

테인트는 톨러레이션(Tolerations)와 함께 사용된다. 테인트는 노드에 할당되고, 톨러레이션은 파드에 할당된다. 파드가 스케줄링될 때 어떤 노드에서 실행될지는 중요한 문제인데, 테인트를 통해 이를 컨트롤할 수 있다. 테인트는 일종의 검문소 역할을 하고, 톨러레이션은 해당 검문소를 통과하는 출입증과 같은 역할을 한다. 파드가 스케줄링 될 때 노드의 테인트(검문소)에 대한 톨러레이션(출입증)이 없는 경우, 그 노드에는 스케줄링되지 않는다.

 

테인트가 적용된 노드는 describe 명령을 통해 확인할 수 있다.

#테인트가 적용된 노드의 수 확인
kubectl describe nodes | grep -i taint 

#노드 갯수를 파일 형태로 기록
echo {노드갯수} > {파일경로}

 

 

 

CKA 자격증 정보 및 문제 풀이 연관 글

[쿠버네티스] CKA 자격 시험 접수 및 후기 (202105) | 데인트리 라이브러리

[쿠버네티스] CKA 기출 자료_1 [RBAC, Node] | 데인트리 라이브러리

[쿠버네티스] CKA 기출 자료_2 [클러스터 업그레이드, 백업] | 데인트리 라이브러리

[쿠버네티스] CKA 기출 자료_3 [파드, 디플로이먼트] | 데인트리 라이브러리

[쿠버네티스] CKA 기출 자료_4 [PV, PVC] | 데인트리 라이브러리

[쿠버네티스] CKA 기출 자료_5 [네트워킹] | 데인트리 라이브러리

 

 

내용에 오류가 있거나 질문이 있으면 댓글로 소통해주세요

언제나 환영합니다