쿠버네티스에서 ServiceAccount는 파드(Pod)가 쿠버네티스 API 서버와 통신할 때 사용되는 신원(identity)입니다.
이는 사용자가 자신의 신원을 인증하는 방식과 유사하게, 파드가 쿠버네티스 클러스터 내에서 API 작업을 수행할 수 있도록 해주는 계정 역할을 합니다.
ServiceAccount의 핵심 개념
- 자동 할당: 쿠버네티스에서 생성되는 모든 파드에는 별도로 지정하지 않아도 default라는 이름의 ServiceAccount가 자동으로 할당됩니다.
- 네임스페이스 종속성: ServiceAccount는 특정 네임스페이스에 종속됩니다. 다른 네임스페이스의 ServiceAccount는 사용할 수 없습니다.
- 토큰: 각 ServiceAccount에는 시크릿(Secret)에 저장된 토큰이 연결됩니다. 이 토큰은 파드가 API 서버로 요청을 보낼 때 bearer token으로 사용됩니다.
- 인가(Authorization): ServiceAccount는 역할 기반 접근 제어(RBAC, Role-Based Access Control)와 함께 사용되어 특정 리소스에 대한 접근 권한을 정의합니다. Role 또는 ClusterRole이 정의한 권한을 RoleBinding 또는 ClusterRoleBinding을 통해 ServiceAccount에 부여하는 방식입니다.
ServiceAccount 작동 방식
- ServiceAccount 생성: 사용자가 kubectl create serviceaccount my-sa와 같이 ServiceAccount를 생성합니다.
- 토큰 시크릿 생성: 쿠버네티스 컨트롤러는 이 ServiceAccount를 위해 자동으로 API 서버와 통신할 수 있는 토큰이 포함된 시크릿을 생성합니다. (v1.24 이후부터는 토큰 자동 마운트가 기본적으로 비활성화되어 있어, 명시적으로 토큰을 생성하고 파드에 마운트해야 합니다.)
- 파드에 할당: 파드 YAML 파일의 spec.serviceAccountName 필드에 생성한 ServiceAccount의 이름을 지정합니다.
- 토큰 마운트: 파드가 생성될 때, 쿠버네티스는 자동으로 해당 ServiceAccount의 토큰 시크릿을 파드 내부의 /var/run/secrets/kubernetes.io/serviceaccount 경로에 볼륨(volume)으로 마운트합니다.
- API 통신: 파드 내부에서 실행되는 애플리케이션은 마운트된 토큰을 사용하여 API 서버에 인증된 요청을 보냅니다.
사용 예시
아래 예시는 my-service-account라는 ServiceAccount를 생성하고, 이 계정을 사용하는 파드를 배포하는 과정입니다.
1. ServiceAccount 생성
먼저 my-sa.yaml 파일을 생성합니다.
YAML
# my-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
namespace: default
생성합니다. kubectl apply -f my-sa.yaml
2. ServiceAccount에 권한 부여
이제 이 ServiceAccount가 특정 작업을 수행할 수 있도록 RBAC 권한을 부여합니다. 예를 들어, default 네임스페이스의 deployments 리소스를 list하고 get할 수 있는 권한을 부여해 봅시다.
# my-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: default
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list"]
---
# my-rolebinding.yaml
apiVersion: rbac.authorization.k8s.sio/v1
kind: RoleBinding
metadata:
name: read-deployments-binding
namespace: default
subjects:
- kind: ServiceAccount
name: my-service-account
namespace: default
roleRef:
kind: Role
name: deployment-reader
apiGroup: rbac.authorization.k8s.io
생성합니다. kubectl apply -f my-role.yaml
3. 파드에 ServiceAccount 할당
마지막으로, 생성한 ServiceAccount를 사용하는 파드를 배포합니다.
# my-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
namespace: default
spec:
serviceAccountName: my-service-account
containers:
- name: my-container
image: busybox
command: ["sh", "-c", "sleep 3600"]
kubectl apply -f my-pod.yaml 명령어를 실행하면 my-pod가 my-service-account의 신원으로 실행됩니다. 파드 내의 컨테이너는 이제 deployments 리소스를 조회할 수 있는 권한을 갖게 됩니다.
주요 사용 사례
- 배포 자동화 도구: 파드 내에서 실행되는 CI/CD(지속적 통합/지속적 배포) 파이프라인이 새로운 버전을 배포하기 위해 Deployment를 생성하거나 업데이트해야 할 때 사용합니다. 예를 들어, Jenkins 에이전트 파드가 새로운 커밋을 감지하고, API 서버에 요청하여 특정 Deployment의 이미지를 변경할 수 있습니다.
- 컨트롤러/오퍼레이터: 쿠버네티스의 기본 기능 외에 새로운 기능을 추가하는 애플리케이션인 컨트롤러(Controller)나 오퍼레이터(Operator)는 ServiceAccount를 사용하여 클러스터 리소스를 지속적으로 감시하고 필요한 작업을 수행합니다. 예를 들어, 데이터베이스 오퍼레이터는 Database라는 사용자 정의 리소스를 감시하다가, 새로운 데이터베이스가 생성되면 이에 맞춰 StatefulSet과 Service를 자동으로 배포합니다.
- 모니터링 및 로깅 에이전트: 클러스터 내의 상태를 수집하는 모니터링 에이전트나 로깅 에이전트가 있습니다. 이 파드들은 ServiceAccount를 사용하여 클러스터의 모든 파드나 노드 상태를 읽고, 해당 정보를 중앙 모니터링 시스템으로 전송합니다.
- 자체 구성 애플리케이션: 외부 설정 파일 없이, 자신이 속한 클러스터의 정보를 직접 조회하여 스스로를 구성하는 애플리케이션이 있습니다. 예를 들어, 여러 개의 마이크로서비스로 구성된 애플리케이션이 서로를 찾기 위해 Service 리소스를 조회하는 데 ServiceAccount를 사용할 수 있습니다.
# app.py
from kubernetes import client, config
def list_deployments():
"""
파드 내부에서 ServiceAccount를 사용하여 Deployment 목록을 조회합니다.
"""
try:
# 파드 내부에서 API 서버 설정을 로드합니다.
# ServiceAccount 토큰과 환경 변수를 자동으로 사용합니다.
config.load_incluster_config()
v1_apps = client.AppsV1Api()
print("default 네임스페이스의 Deployment 목록:")
# API 서버에 GET 요청을 보냅니다.
deployments = v1_apps.list_namespaced_deployment(namespace="default")
for deploy in deployments.items:
print(f"- {deploy.metadata.name}")
except client.ApiException as e:
print(f"API 호출 중 오류 발생: {e}")
if __name__ == '__main__':
list_deployments()
'Kubernetes > K8s' 카테고리의 다른 글
클러스터가 파드를 제어하는 방식 (0) | 2025.08.26 |
---|---|
[K8s] 가상 IP 및 서비스 프록시 (1) | 2025.06.18 |
[K8s] Controler-node ip가 변경될 경우 (0) | 2025.06.18 |
install kubenetes (0) | 2025.03.04 |
쿠버네티스 스토리지 (0) | 2024.02.26 |