삶은 개발

한국어 카테고리

AWS EC2 Kubernetes WordPress hosting – 포기

공식 홈페이지 자료 – https://kubernetes.io/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

WordPress는 mysql 데이터베이스를 사용하고 해당 정보는 영속성이 있는 공간에 저장이 되어야 한다.
Kubenetes가 제공하는 영속성 공간을 파악하고 활용한다.

#1. Kubernetes PersistentVolume 과 PersistentVolumeClaim 의 관계

영속적 저장소를 사용하는 것은 좋으나, 이 부분을 활용하여 백업이나, 재활용을 해야한다는 생각이 먼저 들었다. 하지만 그런 기능을 위한 static 하거나 직접적인 PV(PersistentVolume)와 PVC(PersistentVolumeClaim)의 관계 설정 방법은 존재하지 않는다.

영속성을 활용하긴 하지만 운영적인 설정을 추구하진 않도록 한다.
오히려 서비스에서 백업을 해서 복원하는 방법으로 이전한다고 보는 것이 낫다.

그렇게 결론이 난다면 적절한 PV를 잘 만들어두고 알아서 kube가 사용할 수 있도록 배려한다.

#2. 다음은 PV(PersistentVolume)와 PVC(PersistentVolumeClaim)의 관계를 설명한 내용이다.

1. 관계 설정

Kubernetes에서 PersistentVolume (PV)과 PersistentVolumeClaim (PVC)은 데이터를 영구적으로 저장하고 사용하기 위한 중요한 개념입니다.

  1. PersistentVolume (PV):
    • PersistentVolume은 클러스터에서 사용 가능한 스토리지 볼륨을 나타냅니다. 이는 네트워크 스토리지 (NFS, iSCSI 등) 또는 클러스터 내부 스토리지 (호스트 경로, 로컬 디스크 등)일 수 있습니다.
    • PV는 클러스터 관리자에 의해 생성되고 관리됩니다. 스토리지 클래스, 용량, 액세스 모드 등의 세부 정보가 정의됩니다.
    • PV는 클러스터 전체에서 공유되며, 여러 PVC가 동시에 동일한 PV를 요청할 수 있습니다.
  2. PersistentVolumeClaim (PVC):
    • PersistentVolumeClaim은 Pod가 사용할 PV를 요청하는 방법입니다. PVC는 Pod가 사용할 스토리지의 크기와 액세스 모드 등을 지정합니다.
    • PVC는 일반적으로 네임스페이스 내에서 생성되고 관리됩니다. 이는 해당 네임스페이스의 Pod에서만 사용할 수 있는 PV를 요청할 수 있음을 의미합니다.
    • PVC를 사용하면 Pod는 스토리지에 대한 세부 사항을 알 필요 없이 클러스터 관리자가 정의한 스토리지 클래스에 대한 액세스를 요청할 수 있습니다.

PV와 PVC의 관계는 다음과 같습니다:

  • PVC는 PV를 요청하고 사용합니다. PVC를 생성하면 Kubernetes는 PVC의 요구 사항과 일치하는 PV를 찾습니다. 이러한 일치하는 PV가 없으면 PVC가 보류 상태가 됩니다.
  • PV는 여러 PVC가 요청할 수 있지만, PVC는 오직 하나의 PV만을 요청할 수 있습니다. PV는 한 번에 한 PVC에만 바인딩될 수 있습니다.
  • PVC와 PV 사이의 바인딩은 정적 또는 동적일 수 있습니다. 정적 바인딩은 클러스터 관리자가 수동으로 PVC와 PV를 직접 매핑하는 것이고, 동적 바인딩은 StorageClass를 사용하여 PVC가 요청한 스토리지 클래스에 맞는 PV를 동적으로 할당하는 것입니다.

PVC를 사용하는 방법은 다음과 같습니다:

  1. PVC 정의 작성: PVC를 정의하는 YAML 파일을 작성합니다. 이 파일에는 요청하는 스토리지의 크기, 액세스 모드, 스토리지 클래스 등이 포함됩니다.
  2. PVC 생성: kubectl apply 명령을 사용하여 PVC를 생성합니다. 이를 통해 Kubernetes는 요청된 스토리지에 대한 PV를 찾거나 할당합니다.
  3. PVC 사용: Pod의 볼륨 섹션에 PVC를 지정하여 Pod가 PVC로 정의된 스토리지에 액세스할 수 있도록 합니다.

이러한 과정을 통해 PVC를 사용하여 Pod가 지속적인 스토리지에 액세스할 수 있습니다.

2. 선택 방법

Kubernetes는 동일한 스펙으로 여러 개의 PersistentVolume (PV)가 있는 경우, PersistentVolumeClaim (PVC)이 이전에 사용한 PV를 선정할 수 있도록 합니다. 이는 PVC가 요청한 스토리지 클래스와 요구 사항이 일치하는 PV를 찾을 때까지 동작합니다.

일반적으로 PVC는 스토리지 클래스와 용량 등을 지정하여 PV를 요청합니다. 이 정보를 바탕으로 Kubernetes는 PVC가 요청한 스펙과 일치하는 PV를 선택합니다. 만약 동일한 스펙으로 여러 PV가 존재하면, Kubernetes는 다음과 같은 방법으로 PV를 선정합니다:

  1. 매칭되는 PV 선택: PVC가 요청한 스펙과 일치하는 PV가 여러 개인 경우, Kubernetes는 최선의 매칭을 찾습니다. 이는 PVC가 요청한 용량과 액세스 모드 등이 PV와 정확히 일치하는 경우입니다.
  2. 매칭되는 PV 중 최근에 사용한 PV 선택: PVC가 요청한 스펙과 일치하는 PV가 여러 개이고, 모든 PV가 동등한 경우에는 Kubernetes는 이전에 해당 PVC가 바인딩된 PV를 선택합니다. 이는 PVC가 이미 사용한 PV를 유지하고자 할 때 유용합니다.

이전에 사용한 PV를 선택하려면 다음과 같은 방법을 사용할 수 있습니다:

  • PVC를 삭제하지 않고 동일한 PVC를 재생성합니다. 이 경우 Kubernetes는 이전에 사용한 PV를 선정하여 바인딩합니다.
  • PVC의 라벨 또는 주석 등을 사용하여 특정 PV에 대한 매칭을 유도할 수 있습니다. 이를 통해 Kubernetes가 특정 PV를 선호하도록 할 수 있습니다.

요약하자면, Kubernetes는 동일한 스펙으로 여러 PV가 있는 경우에도 PVC가 이전에 사용한 PV를 선정할 수 있도록 지원합니다.

3. 삭제 후 복구 안됨

PV가 삭제되면 해당 PV를 요청한 PVC는 다시 PV를 할당받을 수 없습니다. PV가 삭제되면 Kubernetes는 해당 PV와 바인딩된 PVC를 해제하고 PVC는 보류 상태가 됩니다. 따라서 PVC가 다시 PV를 할당받으려면 새로운 PV를 생성하거나 기존에 존재하는 다른 PV를 사용해야 합니다.

PV를 새로 생성하여 PVC에 할당하는 방법은 다음과 같습니다:

  1. 새로운 PV 생성: 새로운 PV를 생성하여 이전에 삭제된 PV와 동일한 스펙을 가지도록 설정합니다. 이를 위해 PV의 스토리지 클래스, 용량, 액세스 모드 등을 이전에 삭제된 PV와 동일하게 지정해야 합니다.
  2. PVC 수정: PVC의 YAML 파일을 수정하여 새로운 PV를 참조하도록 설정합니다. PVC의 spec.volumeName 필드를 새로운 PV의 이름으로 업데이트하거나, 새로운 PV에 매칭되는 라벨 셀렉터를 사용하여 PVC를 다시 생성합니다.
  3. PVC 재생성: PVC를 재생성하여 새로운 PV를 할당받도록 합니다. PVC를 삭제하고 이전에 설정한 스펙으로 새로운 PVC를 생성합니다. Kubernetes는 새로운 PV를 할당하여 PVC를 바인딩할 것입니다.

이렇게 하면 PVC가 다시 새로운 PV를 할당받을 수 있습니다. 하지만 이전에 사용한 PV를 다시 할당받기 위해서는 삭제된 PV를 되돌리거나 복원하는 것이 아니라 새로운 PV를 생성하고 PVC를 수정하거나 재생성해야 합니다.

#3. PV 설정

apiVersion: v1
kind: PersistentVolume
metadata:
  name: wp-pv-com
  labels:
    type: local
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/wordpress/data-com/pv0001"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-com
  labels:
    type: local
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/wordpress/data-com/pv0002"

#4. 설정 다 만들어서 해봤는데. 급종료하는 느낌이지만 이틀 시간을 썼다….

기본적으로 kubelet standalone으로 service loadbalancer와 deployment 등등의 서비스를 띄울 수는 없었다. pod는 잘 떴다.

일단 스크립트의 문제점을 파악하기 위해서 로컬 맥에서 minukube로 yaml 파일의 문제점을 검증헀으나 문제없었다.

Kubelet standalone의 문제같아서
Ec2 cluster 구축해서도 했다.
6443 connection refused 도 풀어야 되고, worker 배정도 해야되고 할게 많다.

이런식으로 풀면 EC2를 2개이상 사용하므로 비용을 아끼는 부분도 어렵고,
시간도 이미 많이 들었다.

딴데서는 다 된다고 하는데 내 결론은 이렇다.

Kubelet standalone 은 pod 만 돈다.
Persistent Volume 같은거 안돈다. 포기 하겠다.

여기까지만 하고 포기
kube가 문제라면 docker compose를 해보자….

다음 블로그는 docker compose로 구성이다.
aws-ec2-ubuntu-에서-mariadb-설치

오늘은 여기까지

추가: 결국 프리티어 1기가램 으로는 kubernetes 2기가램 요구사항을 만족 못한다.
이 부분은 kubelet standalone으로 사용하더라도 같이 사용하는 docker 의 요구사항에도 버겁다.

포기

전체 과정 블로그 /aws-ec2-mariadb-환경-설정