Kubernetes 기술 개념 정리 5

33.  Kubernetes kubelet이 Worker 노드의 리소스를 모니터링할 때 구성 요소

Kubernetes의 kubelet은 cAdvisor를 사용하여 워커 노드의 리소스를 모니터링합니다. Kubernetes 시스템에서 cAdvisor는 kubelet 구성 요소에 기본적으로 통합되어 있으며, kubelet 서비스가 시작되면 cAdvisor 서비스도 자동으로 시작됩니다. cAdvisor는 실행 중인 노드와 해당 노드에서 동작하는 컨테이너의 성능 지표를 실시간으로 수집합니다.

 

34.  쿠버네티스(Kubernetes) 승인(Admission) 메커니즘 간략 설명

클러스터에 요청을 보낼 때, 각 승인 컨트롤 코드가 특정 순서에 따라 실행됩니다. 만약 하나의 승인 컨트롤이 해당 요청을 거부하면, 요청 처리는 즉시 중단되며 사용자에게 적절한 오류 메시지가 반환됩니다.
승인 컨트롤(Admission Control):
승인 컨트롤은 본질적으로 승인 코드로, Kubernetes API 요청 처리 과정에서 인증 & 권한 부여를 거친 후 승인 작업을 실행하고 마지막으로 대상 객체에 대한 작업을 수행하는 순서로 진행됩니다.

주요 승인 컨트롤 코드:

1. AlwaysAdmit: 모든 요청을 허용합니다.
2. AlwaysDeny: 모든 요청을 거부합니다(주로 테스트 환경에서 사용).
3. ServiceAccount:
   • ServiceAccount의 자동화를 구현합니다.
   • 만약 Pod에 serviceAccount 속성이 없으면 기본값으로 default를 추가하며, Pod의 ServiceAccount가 항상 존재하도록 보장합니다.
4. LimitRanger:
   • 모든 요청을 관찰하며, 네임스페이스 내에 정의된 LimitRange 객체의 제약 조건을 위반하지 않도록 확인합니다.
5. NamespaceExists:
   • 모든 요청을 관찰하며, 존재하지 않는 네임스페이스를 생성하려는 요청이 있을 경우 이를 거부합니다.

이러한 메커니즘은 Kubernetes API 요청을 보다 안전하고 일관성 있게 관리하기 위해 중요한 역할을 합니다

 

35.  쿠버네티스(Kubernetes) RBAC 및 그 특징(장점) 간략 설명

RBAC(Role-Based Access Control)
RBAC는 역할 기반 접근 제어로, 개별 사용자에게 부여된 역할에 따라 컴퓨터 또는 네트워크 리소스에 대한 접근 권한을 관리하는 방법입니다.

쿠버네티스 RBAC의 API 객체 기반 완전 통합 예제

1. Role과 RoleBinding

Role은 특정 네임스페이스 내에서 리소스 접근 권한을 정의합니다. RoleBinding은 이 Role을 사용자, 그룹, 또는 ServiceAccount에 연결합니다.

Role 정의:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]               # ""는 코어 API 그룹을 의미
  resources: ["pods"]           # pods 리소스에 대한 권한
  verbs: ["get", "list", "watch"]  # 허용되는 동작

 

RoleBinding 정의:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: User                    # User, Group, 또는 ServiceAccount 가능
  name: alice                   # 권한을 부여받을 사용자 이름
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                    # Role 또는 ClusterRole
  name: pod-reader              # 연결할 Role 이름
  apiGroup: rbac.authorization.k8s.io

 

결과: 사용자 alice는 default 네임스페이스에서 Pod을 읽을 수 있는 권한(get, list, watch)을 가집니다.

 

2. ClusterRole과 ClusterRoleBinding

ClusterRole은 클러스터 전역에서 리소스 또는 비리소스에 대한 권한을 정의하며, ClusterRoleBinding을 통해 사용자 또는 그룹에 연결됩니다.

 

ClusterRole 정의

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-admin
rules:
- apiGroups: [""]               # ""는 코어 API 그룹
  resources: ["nodes"]          # 클러스터 수준의 노드 리소스
  verbs: ["get", "list", "watch", "delete"]  # 허용된 동작

 

ClusterRoleBinding 정의

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-all-nodes
subjects:
- kind: User
  name: bob                    # 권한을 부여받을 사용자
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-admin             # 연결할 ClusterRole 이름
  apiGroup: rbac.authorization.k8s.io

 

결과: 사용자 bob은 클러스터 전역에서 노드(Node)에 대한 읽기(get, list, watch) 및 삭제(delete) 권한을 가집니다.

 

3. kubectl 명령어로 Role 및 RoleBinding 생성 방법

RBAC 객체는 kubectl 명령어를 사용해 바로 생성할 수도 있습니다.

 

Role 생성:

kubectl create role pod-reader \
  --verb=get --verb=list --verb=watch \
  --resource=pods \
  -n default

 

RoleBinding 생성:

kubectl create rolebinding read-pods-binding \
  --role=pod-reader \
  --user=alice \
  -n default

 

RBAC 권한 확인

특정 사용자 권한 확인:

kubectl auth can-i list pods --as=alice -n default // yes 또는 no 출력.

 

ClusterRole 확인:

kubectl get clusterrole node-admin -o yaml

 

36. Kubernetes Secret의 역할

Secret 객체는 비밀번호, OAuth 토큰, SSH 키와 같은 민감한 데이터를 안전하게 관리하고 저장하기 위해 사용됩니다. Secret을 활용하면 이러한 정보를 Pod의 설정 파일이나 Docker 이미지에 직접 포함시키는 것보다 더 안전하고 사용 및 배포가 용이합니다.

37. Kubernetes Secret 사용 방식

Service Account를 통해 Secret 자동 사용

 

Secret 생성

Service Account와 연동될 Secret을 생성합니다.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  token: bXlzZWNyZXR0b2tlbg==  # Base64로 인코딩된 값

 

Service Account 생성

Secret을 연결한 Service Account를 생성합니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
secrets:
  - name: my-secret

 

Pod 생성

Service Account를 지정하여 Secret을 자동으로 사용합니다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-service-account  # Service Account 지정
  containers:
    - name: my-container
      image: nginx

 

2. Pod에 Secret을 마운트하여 사용

 

Secret 생성

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: dXNlcg==         # 'user'의 Base64 인코딩 값
  password: cGFzc3dvcmQ=     # 'password'의 Base64 인코딩 값

 

Pod 생성 (Secret을 Volume으로 마운트)

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
      volumeMounts:
        - name: secret-volume
          mountPath: /etc/secret        # 컨테이너 내부 경로
          readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: my-secret           # 마운트할 Secret 이름

컨테이너 내부에서 사용

마운트된 경로(/etc/secret/username, /etc/secret/password)에서 Secret 데이터를 파일로 읽을 수 있습니다.