Kubernetes 기술 개념 정리 6

36. Kubernetes 네트워크 모델 간단 설명

1.  Pod 중심의 네트워크 설계

• Pod는 독립적인 IP 주소를 가짐
  모든 Pod는 고유의 IP 주소를 가지고 있으며, Pod 간 통신은 이러한 IP를 기반으로 이루어집니다.
  이를 통해 Pod가 Node(호스트) 간에 배치되든 동일한 Node에 배치되든 상관없이 동일한 방식으로 통신할 수 있습니다.
  학습 포인트: 클러스터 내부 통신은 복잡한 네트워크 설정 없이도 이루어진다는 점.

2. Pod 내부의 네트워크 네임스페이스 공유

• Pod 내부의 모든 컨테이너는 같은 네트워크 네임스페이스를 공유합니다.
  따라서 같은 Pod 안의 컨테이너들은 localhost를 통해 서로 통신할 수 있습니다.
  이는 동일 Pod 내에서 여러 컨테이너를 사용하는 마이크로서비스 간에 네트워크 통신이 간단해짐을 의미합니다.
  학습 포인트: 같은 Pod 내의 컨테이너들은 서로 분리된 네트워크 환경을 갖지 않고, 동일한 네트워크 자원을 사용.

3. 사용자의 추가적인 네트워크 설정 부담 감소

• Node 간 네트워크 평면화 설계 덕분에 사용자는 Pod 간의 네트워크 연결을 추가로 설정할 필요가 없습니다.
  Kubernetes는 CNI(Container Network Interface) 플러그인을 통해 이를 자동화합니다.
  학습 포인트: 복잡한 네트워크 연결이나 포트 매핑 없이도 Pod 간 통신이 자연스럽게 이루어질 수 있도록 설계되어 있음.

4. 클러스터 내의 확장성과 유연성 보장

• Pod 중심의 IP 네트워킹은 동적 스케일링과 Pod 이동성을 지원하는 핵심 요소입니다.
  예를 들어, Pod가 다른 Node로 이동하거나 새 Pod가 생성되어도 네트워크 설정을 변경할 필요가 없습니다.
  학습 포인트: Kubernetes의 네트워크 모델은 대규모 클러스터 환경에서도 안정적인 통신을 보장.

 

37. Kubernetes 네트워크 정책(Network Policy)

Kubernetes는 컨테이너 간 네트워크 접근을 세밀하게 제어하기 위해  Network Policy(네트워크 정책) 를 도입했습니다.

주요 기능

• Pod 간의 네트워크 통신 제한 및 접근 제어를 수행합니다.
• 허용하거나 차단할 클라이언트 Pod 목록을 설정할 수 있습니다.

작동 원리

• Network Policy는 네트워크 정책을 정의하고,
• 이를 **Policy Controller(정책 컨트롤러)**와 함께 사용하여 정의된 정책을 실행합니다.

이를 통해 Kubernetes 환경에서 보안과 통신 제어를 더욱 강화할 수 있습니다.

 

 

 

38.  Kubernetes 네트워크 정책(Network Policy) 원리

 

1. 정책 컨트롤러(Policy Controller)의 역할
   • 정책 컨트롤러는 API Listener를 구현하여 사용자가 설정한 Network Policy 정의를 모니터링합니다.
2. 규칙 전달 및 적용
   • 정책 컨트롤러는 정의된 네트워크 접근 규칙을 각 Node의 에이전트(Node Agent)에 전달합니다.
   • 각 Node의 에이전트는 전달받은 규칙을 실제로 적용하는 역할을 수행합니다.
3. CNI 네트워크 플러그인 연동
   • 에이전트는 CNI 네트워크 플러그인을 통해 네트워크 접근 규칙을 구현합니다.
     예: Pod 간의 허용된 트래픽만 전달되도록 규칙 설정.

이 과정을 통해 Kubernetes 클러스터 내 네트워크 트래픽을 세밀하게 제어할 수 있습니다.

예제 시나리오

네임스페이스: default
대상 Pod: app=frontend 라벨이 붙은 Pod
허용 조건:
동일 네임스페이스에서 app=backend 라벨이 붙은 Pod만 접근 가능.
다른 모든 Pod의 접근은 차단.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-frontend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: frontend # 대상 Pod 선택 (app=frontend 라벨)
  policyTypes:
  - Ingress # Ingress(들어오는 트래픽) 제어
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend # 접근을 허용할 Pod (app=backend 라벨)

정책 설명

1. 정책 대상: app=frontend 라벨이 붙은 모든 Pod에 적용됩니다.
2. 정책 유형: Ingress 정책: 외부에서 들어오는 트래픽을 제어.
3. 허용된 트래픽: app=backend 라벨이 붙은 Pod에서 들어오는 요청만 허용됩니다.
4. 기본 동작: 정책에 명시되지 않은 트래픽(예: 다른 라벨의 Pod)은 기본적으로 차단됩니다.

39.  Kubernetes 공유 스토리지 및 역할

Kubernetes에서 공유 스토리지는 다음과 같은 경우에 중요합니다:

1. 상태가 있는 컨테이너 애플리케이션 지원
   • 상태 정보를 유지해야 하는 애플리케이션(예: 데이터베이스)에서 중요한 데이터를 저장하기 위해 필요합니다.
2. 데이터 영속성 보장
   • 컨테이너가 삭제되거나 재배치되더라도, 이전 데이터를 보존하여 새 컨테이너에서도 동일한 데이터를 사용할 수 있습니다.
3. 공유 데이터 관리
   • 여러 Pod가 동일한 데이터를 공유하고 접근할 수 있도록 지원합니다.
     예: 분산 애플리케이션, 로그 수집 시스템 등.

공유 스토리지는 Kubernetes에서 Persistent Volume(PV) 와 Persistent Volume Claim(PVC) 을 통해 구현됩니다. 이를 통해 애플리케이션의 데이터가 안정적으로 저장되고, 컨테이너 재배치 시에도 데이터가 유지되며, 손실 없이 애플리케이션을 실행할 수 있습니다.

 

40. Kubernetes 데이터 영속화 방식

Kubernetes는 중요한 데이터를 영구적으로 저장하기 위해 다양한 데이터 영속화 방식을 제공합니다. 주요 방식은 다음과 같습니다.

1. EmptyDir (빈 디렉토리)

• Pod 내부의 빈 디렉토리를 호스트 머신의 파일 시스템에 매핑하여 사용.
• 사용 사례:
  • 데이터가 임시로 디스크에 저장되어야 할 때(예: 정렬/병합 알고리즘).
  • 같은 Pod 내 여러 컨테이너가 데이터를 공유해야 할 때.
• 특성:
  • 같은 Pod 내 컨테이너는 같은 디렉토리를 공유.
  • Pod가 삭제되면 EmptyDir의 데이터도 함께 삭제.
  • 데이터 수명은 Pod의 수명과 동일하며, 일반적으로 임시 저장소로 사용.

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-example
spec:
  containers:
  - name: app-container
    image: nginx
    volumeMounts:
    - mountPath: /data
      name: temp-storage
  volumes:
  - name: temp-storage
    emptyDir: {}
    
    
설명: emptyDir로 /data 경로를 빈 디렉토리로 마운트.
Pod 삭제 시 데이터도 삭제됩니다.

2. HostPath

• 호스트 머신의 기존 디렉토리나 파일을 컨테이너 내부에 마운트.
  • Docker의 바인드 마운트(bind mount) 방식과 유사.
• 특성:
  • Pod와 호스트 노드 간 높은 의존성을 가짐.
  • 특정 노드에 바인딩되어 실행되는 애플리케이션에 적합.

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-example
spec:
  containers:
  - name: app-container
    image: nginx
    volumeMounts:
    - mountPath: /host-data
      name: host-storage
  volumes:
  - name: host-storage
    hostPath:
      path: /data/host-path
      type: Directory
      
      
설명: 호스트의 /data/host-path 디렉토리를 컨테이너의 /host-data에 마운트.
Pod 삭제 후에도 데이터는 호스트에 남아 있습니다.

3. PersistentVolume (PV)

• NFS(Network File System)나 GFS(Google File System)와 같은 외부 스토리지 서비스를 기반으로 한 영속적인 스토리지.
• 특성:
  • 데이터의 중앙 집중화 및 통합 관리를 가능하게 함.
  • Pod의 삭제와 관계없이 데이터는 유지되며, 재사용 가능.
  • StatefulSet, Deployment 등 데이터 영속성이 필요한 애플리케이션에 적합.

PersistentVolume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  nfs:
    path: /nfs-storage
    server: 192.168.1.100

 

PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

 

Pod에서 PVC 사용

apiVersion: v1
kind: Pod
metadata:
  name: pvc-example-pod
spec:
  containers:
  - name: app-container
    image: nginx
    volumeMounts:
    - mountPath: /persistent-data
      name: persistent-storage
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: pvc-example

 

 

설명:

• PV는 NFS 서버의 /nfs-storage 디렉토리를 정의.
• PVC는 1Gi 스토리지를 요청.
• Pod는 /persistent-data 경로에 PVC를 마운트해 데이터를 사용.

Kubernetes의 데이터 영속화 방식은 애플리케이션의 요구사항에 따라 선택할 수 있으며, EmptyDir과 HostPath는 주로 임시 및 단기적인 데이터 저장소로, PersistentVolume은 데이터 영속성이 중요한 경우에 사용됩니다.

 

41.  Kubernetes PV와 PVC 간단 설명

• PV(PersistentVolume):
  하위 네트워크 공유 스토리지에 대한 추상화로, 공유 스토리지를 하나의 "리소스"로 정의합니다.
• PVC(PersistentVolumeClaim):
  사용자가 스토리지 리소스를 요청하는 하나의  "신청" 입니다.

 

42.  Kubernetes PV의 생애 주기 단계 

PV는 생애 주기 동안 다음 4가지 단계(Phases) 중 하나에 있을 수 있습니다:

1. Available (사용 가능):
   • PV가 아직 특정 PVC와 바인딩되지 않은 상태.
2. Bound (바인딩됨):
   • PV가 특정 PVC와 바인딩된 상태.
3. Released (해제됨):
   • 바인딩된 PVC가 삭제되어 리소스가 해제되었으나, 아직 클러스터에서 회수되지 않은 상태.
4. Failed (실패):
   • 자동으로 리소스를 회수하는 작업이 실패한 상태.

회수??:

"회수"란 PVC가 삭제된 후 PV에 할당되었던 스토리지를 어떻게 처리할지 결정하는 과정을 말합니다.

• 회수하지 않으면(PV 상태: Released): 클러스터는 해당 스토리지를 더 이상 활용하지 못하고, 관리자가 직접 처리해야 합니다.
• 올바르게 회수하면: 스토리지가 자동으로 초기화되거나 삭제되어 자원을 재활용하거나 클러스터의 다른 PVC에 다시 할당될 수 있습니다.

예제: PV의 Reclaim Policy 설정

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete  # 회수 정책: 삭제
  hostPath:
    path: /data/example

 

 

• Delete: PVC 삭제 시 /data/example 디렉토리도 삭제.
• Retain: PVC 삭제 후 /data/example에 데이터가 남아 있어 관리자가 수동으로 처리해야 함.

 

43. Kubernetes가 지원하는 스토리지 프로비저닝 방식

Kubernetes는 두 가지 스토리지 프로비저닝 방식을 지원합니다: 정적 프로비저닝(Static)과 동적 프로비저닝(Dynamic).

1. 정적 프로비저닝 (Static):
   • 클러스터 관리자가 직접 PV를 생성하고, PV 정의 시 스토리지의 특성을 설정해야 합니다.
2. 동적 프로비저닝 (Dynamic):
   • 클러스터 관리자가 PV를 수동으로 생성하지 않아도 됩니다.
   • 대신, StorageClass를 통해 백엔드 스토리지를 설정하고 유형을 지정합니다.
   • 사용자가 PVC에 원하는 스토리지 유형을 선언하면, 시스템이 자동으로 PV를 생성하고 PVC와 바인딩합니다.