3주차는 쿠버네티스의 Storage
및 Node 관리
에 대해서 스터디 하였습니다.
2주차의 CNI와 비슷하게 CSI를 이용하여 쿠버네티스 환경에서 스토리지를 수월하게 생성/확장/삭제할 수 있었습니다.
Kubesar 도구를 이용하여 스토리지의 IOPS를 테스트할 수 있어 이를 이용하여 인프라를 최적화 할 수 있는 방안에 대해서 알게되었습니다.
분명 PKOS에서 다루었던 내용이었지만, 확실히 CKA 및 CKAD를 취득하며 쿠버네티스에 대해서 조금더 알게된 후에 다시 스터디를 하니 보다 잘 이해할 수 있었습니다.
3주차는 백지현
님과 서태호
님의 경험발표를 들을 수 있었습니다.
백지현님은 EKS 알뜰신잡이라는 주제로 경험을 공유해주셨습니다. EKS를 실제 업무에서 사용하며 알아두면 좋은 팁을 공유해주셨습니다.
서태호님은 AWS 클라우드 초기 셋업에 대해서 오랜 인프라 관련 업무 경험하며 정리한 내용에 대해서 자세하게 말씀을 해주셨습니다.
ebs-csi-controller
를 이용하여 AWS 스토리지 서비스 중 하나인 EBS를 EKS로 관리할 수 있습니다.efs-csi-controller
를 이용하여 AWS 스토리지 서비스인 EFS를 관리할 수 있습니다.이번주차에서는 oneclick.yaml
을 통해 배포하였으며, kube-ops-view
를 이용하여 파드 및 서비스가 배포되는 것을 UI를 통해 확인하였습니다.
스토리지 개요
컨테이너 환경에서 데이터는 컨테이너가 종료될 경우 사라지게 됩니다. (별도의 마운트 과정이 없을 경우) 즉, 상태가 저장되지 않는 Stateless의 형태로 동작합니다.
간혹 인프라를 운영하다 보면 DB와 같이 컨테이너가 종료되어도 데이터가 보존될 필요가 있는 요구사항이 발생하게 됩니다.
쿠버네티스에서는 이 요구사항을 달성하기위해 PV(퍼시스턴트 볼륨)의 개념을 도입하여 클러스터 단위에서 동작하는 리소스를 사용합니다.
PV는 파드와 개별적인 생명주기를 가지며, 사용자는 PVC를 통해 스토리지에 대한 사용을 요청하게 됩니다.
스토리지 소개
쿠버네티스에서 사용가능한 스토리지 중 대표적으로emptyDir, hostPath, PV/PVC
에 대해서 소개합니다.emptyDir
컨테이너 간의 데이터를 공유하기 위해 사용하는 임시 스토리지 입니다. 주로 사이드카의 형태로 로그를 수집하는 에이전트를 운영할때 사용할 수 있습니다.
파드와 라이프사이클을 같이 하므로, 파드가 재생성 될 경우 데이터가 보존 되지 않습니다.
hostPath
노드의 Path를 볼륨으로서 사용합니다.
파드가 종료되어도 데이터는 노드의 경로에 저장 되므로 데이터는 보존됩니다.
단점으로는 여러 노드를 운영하고 있는 경우 파드가 다른 노드로 재생성되는 경우 데이터의 정합성을 보장할 수 없습니다.
PV/PVC
관리자가 소유한 볼륨을 클러스터 단위의 리소스로 운영하여 사용합니다.
파드가 노드의 리소스를 사용하여 운영하는 것과 같이 PV의 리소스를 PVC를 통해 이용할 수 있습니다.
파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있습니다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있습니다.
CSI 소개
Kubernetes source code 내부에 존재하는 AWS EBS provisioner는 당연히 Kubernetes release lifecycle을 따라서 배포되므로, provisioner 신규 기능을 사용하기 위해서는 Kubernetes version을 업그레이드해야 하는 제약 사항이 있습니다.
Kubernetes 개발자는 Kubernetes 내부에 내장된 provisioner (in-tree)를 모두 삭제하고, 별도의 controller Pod을 통해 동적 provisioning을 사용할 수 있도록 만들었습니다. 이것이 바로 CSI (Container Storage Interface) driver 입니다
CSI 를 사용하면, K8S 의 공통화된 CSI 인터페이스를 통해 다양한 프로바이더를 사용할 수 있습니다.
출처 - AWS Docs
Node-specific Volume Limits
AWS EC2 Type에 따라 볼륨 최대 제한 : 25개 ~ 39개
KUBE_MAX_PD_VOLS
환경 변수의 값을 설정한 후, 스케줄러를 재시작하여 이러한 한도를 변경 가능합니다.
Practice
기본 컨테이너 환경의 임시 파일시스템 사용
파드 삭제시, 이전 기록이 보존되지 않는 것을 확인할 수 있습니다.
호스트 Path 를 사용하는 PV/PVC : local-path-provisioner 스트리지 클래스 배포 - 링크
정상적으로 데이터가 로깅 되는지 확인합니다.
노드에 지정된 경로에서 동일한 내용이 저장되는지 확인합니다.
기존 파드를 삭제하고 다시 배포하여 데이터가 보존되는지 확인합니다.
Volume (ebs-csi-controller)
: EBS CSI driver 동작 : 볼륨 생성 및 파드에 볼륨 연결 - 링크
- persistentvolume, persistentvolumeclaim의 accessModes는 ReadWriteOnce로 설정해야 합니다
- EBS스토리지 기본 설정이 동일 AZ에 있는 EC2 인스턴스(에 배포된 파드)에 연결해야 합니다
Amazon EBS CSI driver as an Amazon EKS add-on 설치
EBS의 볼륨 증가하기
명령어만으로 EBS의 볼륨을 확장할 수 있습니다.(축소는 안됨...)
Volumesnapshots 컨트롤러 설치 및 사용
스냅샷이 정상적으로 생성되는지 확인합니다.
EBS와 마찬가지로 AWS EFS도 CSI를 이용하여 관리할 수 있습니다.
EFS 파일시스템 확인 및 EFS Controller 설치
출처 - AWS
Fargate는 AWS 완전관리형 MicroVM을 이용하여 컨테이너를 운영할 수 있는 서비스입니다.
EKS(컨트롤 플레인) + Fargate(데이터 플레인)의 완전한 서버리스화(=AWS 관리형)로 인프라를 운영 할 수 있습니다.
Cluster Autoscaler 작업을 하지 않아도 되고, VM 수준의 격리 가능(VM isolation at Pod Level)으로 인해 인프라를 더욱 안전하게 사용할 수 있습니다.
파게이트는 프로파일(파드가 사용할 서브넷, 네임스페이스, 레이블 조건)을 생성하여 지정한 파드가 파게이트에서 동작하도록 설정합니다.
EKS는 스케줄러가 특정 조건을 기준으로 어느 노드에 파드를 동작시킬지 결정, 혹은 특정 설정으로 특정 노드에 파드가 동작할 수 있습니다.
Data plane
인스턴스 스토어를 이용하는 방법에 대해서 정리합니다.
인스턴스 스토어란?
인스턴스 스토어는 인스턴스에 블록 수준의 임시 스토리지를 제공합니다. 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치합니다. 인스턴스 스토어는 버퍼, 캐시, 스크래치 데이터, 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 저장에 적합합니다. 또한 로드 밸런싱된 웹 서버 풀과 같은 인스턴스 플릿 전체에 복제하는 임시 데이터를 저장하는 데 사용할 수도 있습니다.
- 신규 노드 그룹 ng2 생성하고 c5d.large 의 EC2 인스턴스 스토어(임시 블록 스토리지)를 설정합니다.
인스턴스 스토어는 EC2 스토리지(EBS) 정보에 출력되지는 않습니다.
배포된 노드의 정보를 확인합니다.
Kubestr을 이용하여 IOPS를 측정하면 읽기 기준 약 20309의 속도가 나오는 것을 확인할 수 있습니다. (엄청빠르다..!)
Kubestr & sar 모니터링 및 성능 측정 확인 (NVMe SSD)
local-path 와 NFS 등 스토리지 클래스의 IOPS 차이를 확인할 수 있습니다.
출처 - https://sogkyc.tistory.com/21
nvme 디스크 블록 Read 확인하면 약 3000 IOPS의 속도가 측정되는 것을 확인 할 수 있습니다.