Kubernetes 기술 개념 정리 2

9.  Kubernetes 클러스터 관련 구성요소

Kubernetes Master는 클러스터 전체 시스템을 관리하고 조정하는 제어 컴포넌트로, 다음과 같은 구성요소를 포함합니다.

 

1. Kubernetes API Server

• Kubernetes 시스템의 진입점 역할을 하며, 핵심 객체의 생성, 삭제, 수정, 조회 기능을 제공.
• RESTful API 방식으로 외부 클라이언트와 내부 컴포넌트 호출에 사용.
• 클러스터 내 모든 기능 모듈 간 데이터 교환과 통신의 중심 허브.

2. Kubernetes Scheduler

• 새롭게 생성된 Pod에 적절한 노드(Node)를 선택 및 할당.
• 클러스터 자원의 스케줄링을 담당.

3. Kubernetes Controller

다양한 컨트롤러를 실행하여 Kubernetes 시스템의 정상 작동을 보장한다.

 

세부 컨트롤러 목록:

• Replication Controller:
  • Replication Controller와 Pod를 연결 및 관리.
  • 정의된 복제본 수와 실제 실행 중인 Pod 수가 일치하도록 유지.
• Node Controller:
  • Node를 관리 및 유지.
  • 주기적으로 Node 상태를 점검하여 유효/비유효 노드를 식별.
• Namespace Controller:
  • Namespace를 관리 및 유지.
  • 주기적으로 유효하지 않은 Namespace와 해당 API 객체(Pod, Service 등)를 정리.
• Service Controller:
  • Service를 관리 및 유지.
  • 로드 밸런싱과 서비스 프록시를 제공.
• EndPoints Controller:
  • Endpoints를 관리 및 유지.
  • Service와 Pod를 연결하며, Pod 변경 시 Endpoints를 실시간으로 업데이트.
• Service Account Controller:
  • Service Account를 관리 및 유지.
  • 각 Namespace에 기본 Service Account와 Service Account Secret을 생성.
• Persistent Volume Controller:
  • Persistent Volume 및 Persistent Volume Claim을 관리.
  • 새 Persistent Volume Claim에 적절한 Persistent Volume을 할당 및 바인딩.
  • 해제된 Persistent Volume에 대한 정리 작업 수행.
• Daemon Set Controller:
  • Daemon Set을 관리 및 유지.
  • 지정된 Node에서 Daemon Pod가 정상적으로 실행되도록 보장.
• Deployment Controller:
  • Deployment와 Replication Controller를 연결하여 Pod 수를 유지.
  • Deployment 업데이트 시 Replication Controller와 Pod를 갱신.
• Job Controller:
  • Job을 관리 및 유지.
  • 단일 실행 작업 Pod를 생성하여 Job에서 지정한 작업 수를 완료.
• Pod Autoscaler Controller:
  • Pod의 자동 스케일링 구현.
  • 주기적으로 모니터링 데이터를 수집하고 정책을 매칭하여 조건을 충족하면 Pod 스케일링 수행.

10. Kubernetes RC의 메커니즘

Replication Controller(RC) 는 Pod의 복제본을 관리하여 클러스터 내에 지정된 수의 Pod 복제본이 존재하도록 보장합니다.
RC가 정의되고 Kubernetes 클러스터에 제출되면, Master 노드의 Controller Manager 구성 요소가 이를 인지합니다.
Controller Manager는 시스템 내에서 현재 실행 중인 대상 Pod를 주기적으로 점검하며, 대상 Pod의 인스턴스 수가 RC의 기대값과 정확히 일치하도록 유지합니다.

• Pod 복제본이 너무 많을 경우, 시스템은 일부 Pod를 중지시킵니다.
• 반대로 Pod 복제본이 부족할 경우, 시스템은 자동으로 추가 Pod를 생성합니다.

11. Kubernetes Replica Set과 Replication Controller의 차이점

Replica Set(RS) 와 Replication Controller(RC)는 모두 특정 시점에 지정된 수의 Pod 복제본이 실행되도록 보장하는 역할을 합니다.
하지만 두 구성 요소에는 다음과 같은 차이점이 있습니다:

• Replica Set: 집합 기반 선택자(Collection-based Selector)를 사용합니다.
• Replication Controller: 권한 기반 선택자(Equality-based Selector)를 사용합니다.

Replication Controller (RC) 예제:

• RC는 정확히 같은 조건을 가진 Pod만 관리합니다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: my-app-rc
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.20

 

• Selector는 app=nginx 조건에 딱 맞는 Pod만 찾습니다.
• 따라서, app=nginx가 아닌 Pod는 RC에서 관리하지 않습니다.

Replica Set (RS) 예제:

• RS는 더 다양한 조건으로 Pod를 관리할 수 있습니다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-app-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
    matchExpressions:
      - key: tier
        operator: In
        values:
          - frontend
          - backend
  template:
    metadata:
      labels:
        app: nginx
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.20

 

 

Selector가 훨씬 유연합니다:

• app=nginx이고 tier가 frontend 또는 backend인 Pod도 관리.
• 여러 조건을 추가해서 복잡한 Pod 관리가 가능합니다.

12.  kube-proxy의 역할

kube-proxy는 모든 노드에서 실행되며, api server[Kubernetes API Server]의 Service와 Endpoint 변경 사항을 모니터링합니다.
이 정보를 바탕으로 라우팅 규칙을 생성하여 서비스 IP와 로드 밸런싱 기능을 제공합니다.

간단히 말해, kube-proxy는 Service의 투명한 프록시 역할을 하며 동시에 로드 밸런서 역할도 합니다.
주요 기능은 특정 Service로 들어오는 요청을 백엔드의 여러 Pod 인스턴스로 전달하는 것입니다.

 

13. Kubernetes에서 Service, Endpoint 란?

Service란?

• Pod의 네트워크 접근을 위한 추상화된 객체입니다.
• Pod는 동적으로 생성되고 삭제되기 때문에 IP 주소가 계속 바뀝니다. Service는 이러한 Pod들에 대해 안정적인 접근 경로(고정된 IP와 DNS 이름)를 제공합니다.
• 클라이언트는 Service를 통해 여러 Pod에 접근할 수 있고, 로드 밸런싱도 가능합니다.

 

Service의 주요 역할

• Pod를 묶어서 하나의 네트워크 엔드포인트로 노출.
• 클러스터 내부 혹은 외부에서 Pod에 안정적으로 접근.
• 로드 밸런싱 기능 제공.

Endpoint란?

• Service에 연결된 Pod들의 IP 주소와 포트 정보를 나타냅니다.
• Service는 Endpoint를 참조해 어떤 Pod로 트래픽을 라우팅할지 결정합니다.

즉, Service는 클라이언트 입장에서의 접근 경로이고, Endpoint는 Service가 실제로 연결하는 Pod의 정보입니다.

Service와 Endpoint의 관계

• Service가 생성되면, Kubernetes는 Service와 매칭되는 Pod를 기반으로 Endpoint 객체를 자동으로 생성합니다.
• Endpoint에는 Service에 연결된 Pod들의 실제 IP와 Port 목록이 저장됩니다.

예제: Service와 Endpoint

 

1. Deployment 정의 (Pod 생성)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.20
        ports:
        - containerPort: 80

 

my-app이라는 Deployment로 3개의 Pod가 생성됩니다.

 

2. Service 정의 (Pod에 접근 경로 제공)

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

 

• my-service라는 이름의 Service가 생성됩니다.
• 클라이언트는 my-service를 통해 Pod에 접근합니다.
• Selector(app: my-app)로 Service는 해당 레이블을 가진 Pod를 찾습니다.

3. Endpoint 자동 생성

위 Service가 생성되면 Kubernetes는 자동으로 Endpoint를 만듭니다.
만약 my-app이라는 Deployment로 생성된 Pod들이 다음과 같은 IP를 가진다면:

• Pod 1: 10.244.0.10
• Pod 2: 10.244.0.11
• Pod 3: 10.244.0.12

Endpoint는 아래와 같이 생성됩니다:

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 10.244.0.10
      - ip: 10.244.0.11
      - ip: 10.244.0.12
    ports:
      - port: 80

 

 

정리:

 

• Service: Pod의 접근 경로를 제공하는 네트워크 객체.
  • 예: 클라이언트 → my-service (고정된 IP)
• Endpoint: Service가 참조하는 Pod들의 실제 IP와 Port 정보.
  • 예: my-service → Pod 1(10.244.0.10:80), Pod 2(10.244.0.11:80), Pod 3(10.244.0.12:80)

 

14. Kubernetes에서 Static Pod란?

Static Pod(정적 Pod)는 특정 Node에서만 실행되며, kubelet에 의해 직접 관리되는 Pod입니다.
Static Pod는 다음과 같은 특징이 있습니다:

 

 

API Server에서 관리되지 않습니다.

• 다른 일반 Pod처럼 kubectl 명령어로 관리하거나 조회할 수 없습니다.

ReplicationController, Deployment, DaemonSet과 연동되지 않습니다.

• Static Pod는 이러한 Kubernetes 오브젝트와는 별개로 동작합니다.

kubelet이 직접 생성하고 관리합니다.

• Static Pod는 항상 kubelet이 실행되는 Node에서만 동작합니다.
• kubelet은 Static Pod의 상태를 지속적으로 모니터링하지만, 일반 Pod처럼 **헬스체크(Health Check)**는 하지 않습니다.

특정 Node에 고정적으로 존재합니다.

• 다른 Node로 이동하지 않으며, 오직 kubelet 설정 파일에 따라 정의된 Node에서만 실행됩니다.

 

15. Kubernetes에서 Pod가 가질 수 있는 상태

Pending

• Pod가 생성되었지만, 아직 하나 이상의 컨테이너가 실행되지 않은 상태입니다.
• 컨테이너 이미지가 다운로드 중이거나, 네트워크 및 리소스 준비가 완료되지 않았을 때 발생합니다.

Running

• Pod 안의 모든 컨테이너가 생성되었고, 최소 하나 이상의 컨테이너가 다음 상태 중 (실행 중, 시작 중, 재시작 중) 하나에 해당합니다.

Succeeded

• Pod 안의 모든 컨테이너가 성공적으로 실행을 종료한 상태입니다.
• 컨테이너는 더 이상 재시작되지 않습니다.

Failed

• Pod 안의 모든 컨테이너가 종료되었지만, 최소 하나 이상의 컨테이너가 실패 상태로 종료된 경우입니다.

Unknown

• Pod의 상태를 알 수 없는 경우입니다.
• 주로 네트워크 문제로 인해 Pod 상태 정보를 가져올 수 없을 때 발생합니다.

16. Kubernetes에서 Pod 생성 주요 흐름

Kubernetes에서 Pod를 생성하는 과정은 여러 컴포넌트 간의 협력을 통해 이루어지며, 주요 단계는 다음과 같습니다:

1. 클라이언트 요청

• 사용자가 Pod의 설정 정보를 kube-apiserver에 제출합니다. (예: YAML 파일 형식의 정의)

2. API Server 처리

• kube-apiserver는 클라이언트 요청을 수신한 후, 해당 요청을 처리하고 controller-manager에게 리소스 객체를 생성하도록 알립니다.

3. Controller Manager 작업

• controller-manager는 API Server를 통해 Pod 설정 정보를 etcd 데이터 저장소에 저장합니다.

4. Scheduler 스케줄링

• kube-scheduler는 새로 생성된 Pod 정보를 감지합니다.
• 스케줄링 단계:
  • 프리필터링: Pod의 요구 사항에 맞지 않는 노드를 필터링합니다.
  • 최적화: Pod 실행에 가장 적합한 노드를 선택합니다.
• 스케줄링이 완료되면 Pod 리소스 구성을 해당 노드의 kubelet에 전달합니다.

5. Kubelet 실행

• 노드의 kubelet은 스케줄러로부터 받은 리소스 구성에 따라 Pod를 실행합니다.
• Pod 실행 후, kubelet은 실행 상태를 scheduler에게 보고합니다.

6. Pod 상태 저장

• 스케줄러는 kubelet로부터 받은 Pod 상태 정보를 다시 etcd 데이터 저장소에 업데이트합니다.

플로우:

클라이언트 → kube-apiserver → controller-manager → etcd → kube-scheduler → kubelet → Pod 실행.

 

 

•