Kubernetes (6)

쿠버네티스 주요 구성요소 - Service, Volume, API 접근 관리

---

Service

쿠버네티스에서는 다양한 상황에서 활용하기 위해 클러스터 내 DNS 서버를 제공한다. 이 DNS 서버는 Service의 도메인 이름과 IP를 저장하고 있어 Pod가 Service의 도메인을 질의하면 해당 IP를 알려준다. 이를 통해 동적으로 변하는 Pod의 IP에 대응할 수 있다.

Headless

Headless Service는 Pod 간 직접 통신이 필요할 때 사용하는 방식이다. 일반적인 Service는 ClusterIP를 통해 여러 Pod에 로드밸런싱을 제공하지만, Headless Service는 각 Pod에 직접 접근해야 할 때 유용하다.

• ClusterIP 속성에 None 지정: Service의 IP를 생성하지 않는다.
• Pod 속성에 hostname과 subdomain 지정: 도메인 이름과 Service 이름을 연결한다.

apiVersion: v1
kind: Service
metadata:
  name: headless-service
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

Pod 설정 예시

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    app: my-app
spec:
  hostname: pod1-host
  subdomain: headless-service
  containers:
  - name: container
    image: my-image

Headless Service를 사용하면 DNS Server에 Service의 IP가 없으므로 Service 이름을 호출하면 연결된 모든 Pod의 IP가 반환된다. 또한 pod-hostname.service-name 형식으로 특정 Pod에 접근할 수 있다.

Headless Service 동작 구조 (텍스트 시각화)

[Pod1]---\
[Pod2]----> [Headless Service (DNS Only)]  [StorageClass] ---> [동적 PV 생성] ---> [외부 스토리지]

Status & ReclaimPolicy

PV는 상황에 따라 여러 상태(Status)를 가진다. 대표적인 상태는 다음과 같다.

• Available: 사용 가능한 상태
• Bound: PVC와 연결된 상태
• Released: PVC가 삭제된 상태
• Failed: 볼륨 연결 실패 상태

ReclaimPolicy는 PVC가 삭제되었을 때 PV의 상태 변화를 위한 정책이다. 세 가지 주요 옵션이 있다.

1. Retain(보존)

   • PVC가 삭제되면 PV의 상태가 Released로 변경된다.
   • 볼륨 데이터는 유지되지만 다른 PVC에 재연결할 수 없다.
   • 관리자가 수동으로 PV를 삭제해야 한다.

2. Delete(삭제)

   • PVC가 삭제되면 PV도 함께 삭제된다.
   • StorageClass로 생성된 PV의 기본 정책이다.
   • 볼륨 종류에 따라 실제 데이터가 삭제되거나 유지될 수 있다.

3. Recycle(재활용)

   • PVC가 삭제되어도 PV 상태가 Available로 변경되어 재사용 가능하다.
   • 실제 데이터는 삭제된다.
   • 현재는 사용이 권장되지 않는 deprecated 상태이다.

ReclaimPolicy를 변경하려면 다음 명령을 사용할 수 있다.

kubectl patch pv  -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

---

Accessing API

쿠버네티스 API에 접근하기 위한 인증(Authentication)과 권한 부여(Authorization) 메커니즘을 제공한다.

Authentication

인증은 사용자나 서비스가 쿠버네티스 API 서버에 접근할 때 신원을 확인하는 과정이다.

• X509 Client Certs

  • TLS 인증서를 사용한 인증 방식이다.
  • 클라이언트가 API 서버에 접근할 때 인증서를 제시하고 API 서버는 이를 검증한다.
  • 주로 클러스터 내부 컴포넌트 간 통신에 사용된다.

• kubectl

  • 쿠버네티스 클러스터를 관리하기 위한 명령줄 도구이다.
  • $HOME/.kube/config 파일에 저장된 인증 정보를 사용한다.
  • 인증서, 토큰, 기본 인증 등 다양한 인증 방식을 지원한다.

• Service Account

  • Pod가 API 서버와 통신할 때 사용하는 계정이다.
  • 네임스페이스마다 default ServiceAccount가 자동 생성된다.
  • Kubernetes 1.24 버전 이후부터는 ServiceAccount 생성 시 자동으로 Token이 생성되지 않는다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

Authorization

인증 후 사용자가 어떤 리소스에 어떤 작업을 수행할 수 있는지 결정하는 과정이다.

• RBAC (Role-Based Access Control)

  • 쿠버네티스 클러스터 내 자원에 대한 접근 권한을 제어하는 보안 메커니즘이다.
  • rbac.authorization.k8s.io API 그룹을 사용해 권한을 설정한다.
  • 사용자, 서비스 계정, 그룹에 권한을 부여하거나 제한할 수 있다.

• Role

  • 특정 네임스페이스 내의 리소스에 대한 접근 권한을 정의한다.
  • API 그룹, 리소스 종류, 허용 동작(verbs) 등을 지정할 수 있다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "watch", "list"]

• RoleBinding
  • Role을 사용자, 그룹 또는 ServiceAccount에 연결한다.
  • 누가 어떤 역할을 수행할 수 있는지 결정한다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

또한 ClusterRole과 ClusterRoleBinding을 통해 네임스페이스에 국한되지 않는 클러스터 전체 권한을 관리할 수 있다.