[AWES] 3주차 - EKS Storage & Node 관리

AWES[1기](Amzaon EKS Study)

[AWES] 3주차 - EKS Storage & Node 관리

Joon0464 2023. 5. 10. 21:36

1. 실습환경 배포

기존과 달라진 점은 "EFS 생성"이 추가된 cloudformation stack을 사용해야한다.
-> https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick2.yaml

기타 파라미터 값은 이전 1주차, 2주차와 동일하기 때문에 생략하도록 하겠습니다.

기본 설정 및 EFS 확인

EFS를 마운트하고 정상적으로 마운트 되었는지(파일 생성 및 삭제 등) 확인합니다.

노드 Private IP 변수 설정 및 보안그룹 설정은 기존 1주차, 2주차와 동일합니다.

AWS LB/ExternalDNS, kube-ops-view 설치

확인한 도메인 주소를 MyDomain 변수로 설정하고 External DNS를 배포합니다.

ExternalDNS를 배포 후 Route53을 다시 확인하면 다음과 같이 3개의 레코드가 추가됩니다.

2. 쿠버네티스에서의 파드 스토리지

- 쿠버네티스에서 파드가 terminating되면 컨테이너 내부 데이터는 모두 삭제됩니다.(Stateless)
- 따라서 Stateful 한 방식의 파드 스토리지 관리가 필요합니다.(e.g. DB 파드)

출처 :&nbsp; https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/

- 이를 위해 쿠버네티스에서는 PV & PVC를 통해 구현
- PV : 관리자가 프로비저닝하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 클러스터 스토리지
- PVC : PVC은 파드에 PV를 할당하기 위한 스토리지에 대한 요청
- 동적 프로비저닝(Dynamic Provisioning) : 파드가 생성될 때 자동으로 볼륨을 마운트하여 파드에 연결하는 기능

출처 : https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/

Reclaim Policy

Reclaim Policy는 Kubernetes에서 PV(Persistent Volume) 자원을 삭제할 때 PV와 관련된 스토리지 볼륨의 처리 방법을 의미합니다.

Retain(보존)
- PV에서 볼륨과의 연결을 삭제하더라도 스토리지 자체는 보존
- 이후 PV 볼륨이 새로운 클레임 요청을 받게되면 기존 볼륨을 재사용
- 데이터가 보존되어야하거나 데이터를 안전하게 보관하는 데 사용
Delete(삭제)
- PV를 삭제하면 PV와 연결된 스토리지 볼륨도 함께 삭제 (EBS 볼륨도 제거)
- 자원을 효율적으로 관리할 수 있지만, 데이터는 완전히 삭제 -> 복구 불가능
Recycle(Kubernetes v1.14 Deprecated)
- PV 내의 데이터를 삭제

스토리지 소개

1. EmptyDir

Pod 간에 임시 데이터를 공유하기 위해 사용되는 볼륨 유형
EmptyDir은 Pod의 라이프사이클 동안만 데이터를 저장 -> Pod가 삭제되면 데이터도 함께 삭제

2. HostPath

호스트 노드의 파일 시스템 경로를 Pod에 마운트하는 방식 -> 호스트 노드의 파일 시스템에 접근 가능
클러스터 노드의 파일이나 디렉터리에 액세스해야 하는 경우 사용
클러스터 내의 다른 노드에서는 동일한 경로가 존재하지 않을 수 있습니다

3. PV/PVC (Persistent Volume / Persistent Volume Claim):

PV와 PVC는 Kubernetes에서 영구적인 데이터 저장을 위해 사용되는 볼륨 관리 시스템
PV는 클러스터 내의 스토리지 리소스를 나타내며, 실제 물리적인 스토리지나 네트워크 리소스를 대표
PVC는 애플리케이션이 PV를 요청하는 방식으로 사용되며, PVC는 PV와 바인딩되어 애플리케이션에 지속적인 데이터 스토리지를 제공
PV와 PVC를 사용하면 애플리케이션과 스토리지의 결합도를 낮출 수 있으며, PV는 클러스터 전체에서 공유될 수 있습니다.

출처 :&nbsp;https://kubetm.github.io/k8s/03-beginner-basic-resource/volume/

CSI (Contaier Storage Interface)

CSI 드라이버는 Kubernetes 클러스터에서 별도의 컨트롤러 Pod을 통해 동적 프로비저닝을 지원합니다.
CSI가 탄생하게 된 배경을 소개하면 다음과 같습니다.

CSI Driver 배경

Kubernetes 소스 코드 내에 내장된 AWS EBS provisioner는 Kubernetes release lifecycle 따라 배포
provisioner의 새로운 기능을 사용하려면 Kubernetes 버전을 업그레이드해야 하는 제약 사항 발생
이를 극복하기 위해 Kubernetes 개발자들은 Kubernetes 내부에 내장된 provisioner (in-tree)를 완전히 제거
대신, 동적 프로비저닝을 위해 별도의 컨트롤러 Pod을 사용할 수 있도록 설정
이러한 목적으로 도입된 것이 바로 CSI (Container Storage Interface) 드라이버

이를 통해 Kubernetes 버전 업그레이드 없이도 새로운 기능을 사용할 수 있게 되었습니다.

Node-specific Volume Limits
- AWS EC2 Type에 따라 볼륨 최대 개수 제한 : 25개 ~ 39개
- KUBE_MAX_PD_VOLS 환경 변수의 값을 설정 후 스케줄러를 재시작하여 한도 변경 가능

기본 컨테이너 환경의 임시 파일시스템 사용 테스트

10초 간격으로 /home/pod-out.txt 파일에 저장하는 파드 배포

tail로 파일 내용을 확인해보면 기존 내용은 찾아볼 수 없습니다. 즉 이전에 삭제한 파드의 데이터는 모두 제거된 것입니다.

hostpath 테스트

- 호스트 Path 를 사용하는 PV/PVC : local-path-provisioner 스트리지 클래스 배포

- PV/PVC 를 사용하는 파드 생성

파드를 제거 후에도 이전과 다르게 파일이 그대로 남아있음을 볼 수 있습니다.

3. AWS EBS Controller 실습

출처 :&nbsp;https://malwareanalysis.tistory.com/598

AWS CSI -> 쿠버네티스 CSI 인터페이스에 맞춰 개발된 AWS 의 CSI
AWS CSI를 이용하여 EBS, EFS를 쉽게 사용 가능
CSI-Controller -> AWS API를 호출하면서 AWS 스토리지를 관리
CSI-Node -> kubelet과 상호작용하면서 AWS스토리지를 pod에 마운트
CSI-Conroller와 CSI-Node는 pod로 생성되어 동작

설치

ISRA 설정 : AWS관리형 정책 AmazonEBSCSIDriverPolicy 사용

EBS CSI드라이버가 AWS API를 사용해야 하므로 CSI-controller pod에 IAM policy를 부여하기 위해 IRSA를 사용합니다.

Amazon EBS CSI driver addon 추가 및 확인 / ebs-csi-controller 파드에 6개 컨테이너 확인 /&nbsp;csinodes 확인

테스트 PV/PVC 와 Pod 생성

모니터링 결과 attaching -> attached로 상태가 변하는 것을 볼 수 있다. gp3로 제대로 붙었다.

볼륨 증가 테스트

용량이 10기가로 증가된 것을 볼 수 있다. 각 명령어의 수치 반영까지 조금 시간이 소요되는 편이다. aws cli 로 확인하는 것이 가장 빠르게 수치가 적용되어 확인할 수 있었다.

볼륨의 크기는 늘릴 수 있지만 줄일 수 없으니 주의해야한다.

4. AWS Volume SnapShots Controller

- Amazon Elastic Block Store (EBS) 볼륨의 스냅샷 생성과 관리를 자동화하는 서비스
- Kubernetes 클러스터에서 Persistent Volume Claim(PVC)을 생성하면 해당 PVC에 대한 EBS 스냅샷이 자동으로 생성
- 스냅샷을 기반으로 새로운 PVC를 생성하거나, 스냅샷을 복원하여 이전 상태로 롤백하는 등의 작업을 수행 가능

Volumesnapshots 컨트롤러 설치

테스트 PVC/파드 생성

스냅샷으로 복원 테스트

파드 생성 후 파일 내용 저장 확인 -> 파드 삭제 전에 기록된 데이터가 남아 있다.

AWS EFS Controller

Amazon Elastic File System (EFS)를 Kubernetes 클러스터와 통합하여 사용할 수 있도록 도와주는 서비스
EFS는 AWS 클라우드에서 관리형 파일 스토리지 서비스로, 여러 가용 영역에서 확장성과 내결함성을 제공
다수의 컨테이너에서 동시에 파일을 공유하고 액세스 가능 -> EKS 클러스터에서 사용하기에 적합
AWS EFS Controller를 사용하면 클러스터 내에서 EFS 파일 시스템을 동적으로 프로비저닝하고 관리 가능

EFS 파일시스템 확인 및 EFS Controller 설치

ISRA 설정 : 고객관리형 정책 AmazonEKS_EFS_CSI_Driver_Policy 사용 -> ISRA 생성 확인

AWS &rarr; EFS &rarr; 파일 시스템 : 네트워크 &rarr; 탑재 대상 ID 를 확인할 수 있다.

EFS 파일시스템을 다수의 파드가 사용하게 설정

파드 생성 및 연동 -> 파드의 /data 데이터는 EFS를 사용하도록 설정됨

파드 내의 /data/out1.txt와 작업용 ec2의 /mnt/myefs/out1.txt는 같은 파일임을 알 수 있다.

EFS 파일시스템을 다수의 파드가 사용하게 설정 ()Dynamic provisioning using EFS)

-> 현재 fargate node에서는 미지원이라고 한다.

3주차 후기

예상은 했지만 스터디양이 엄청나다. 추후에 반드시 복습이 필요하다고 느끼고 있다... 이제 절반 3주차가 지났는데 6주차까지 학습이 끝나면 시간적 여유를 가지고 다시 한 번 학습해보고자 한다.😂

'AWES[1기](Amzaon EKS Study)' 카테고리의 다른 글

[AWES] 6주차 - EKS Security (0)	2023.06.01
[AWES] 5주차 - EKS Autoscaling (0)	2023.05.25
[AWES] 4주차 - EKS Observability (0)	2023.05.18
[AWES] 2주차 - EKS Networking (0)	2023.05.03
[AWES] 1주차 - Amzaon EKS 설치 및 기본 사용 (4)	2023.04.27

현재글[AWES] 3주차 - EKS Storage & Node 관리

리눅스, linuxsecurity, secomp프로필, AWS, centos7, 리눅스보안, Kubernetes, Linux, 도커, seccompprofile, K8S, 카파빌리티, 리눅스카파빌리티, docker, security, Git, 쿠버네티스, 보안, 접근제어목록, lambda,

Today :
Yesterday :

Cumulus(송현준)