3주차 - EKS Storage & Nodegroup

#스터디 시작

EKS Storage와 Nodegroup은 Kubernetes 클러스터를 운영하는 데 필수적입니다. 이 두 가지를 배우면 컨테이너화된 애플리케이션을 안정적이고 효율적으로 배포 및 관리할 수 있습니다. EKS Storage는 컨테이너에서 사용하는 데이터를 저장하는 데 사용됩니다. 다양한 유형의 스토리지 옵션을 사용할 수 있으며 각 옵션에는 장단점이 있고 EKS Storage에 대해 배우면 특정 요구 사항에 맞는 최적의 스토리지 옵션을 선택할 수 있습니다.
Nodegroup은 EKS 클러스터에서 워커 노드를 구성하는 데 사용됩니다. 워커 노드는 컨테이너를 실행하는 실제 컴퓨터입니다. Nodegroup을 사용하면 워커 노드의 유형, 수 및 구성을 정의할 수 있습니다.

 

#사전준비

• Amazon EKS 윈클릭 배포 (AWS LB IRSA, EFS 생성 추가) & 기본 설정\

# YAML 파일 다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick2.yaml

# CloudFormation 스택 배포
예시) aws cloudformation deploy --template-file eks-oneclick2.yaml --stack-name myeks --parameter-overrides KeyName=kp-gasida SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32  MyIamUserAccessKeyID=AKIA5... MyIamUserSecretAccessKey='CVNa2...' ClusterBaseName=myeks --region ap-northeast-2

# CloudFormation 스택 배포 완료 후 작업용 EC2 IP 출력
aws cloudformation describe-stacks --stack-name myeks --query 'Stacks[*].Outputs[0].OutputValue' --output text

# 작업용 EC2 SSH 접속
ssh -i ~/.ssh/kp-gasida.pem ec2-user@$(aws cloudformation describe-stacks --stack-name myeks --query 'Stacks[*].Outputs[0].OutputValue' --output text)
or
ssh -i ~/.ssh/kp-gasida.pem root@$(aws cloudformation describe-stacks --stack-name myeks --query 'Stacks[*].Outputs[0].OutputValue' --output text)

 

 

- 기본 설정 및 EFS 확인

# default 네임스페이스 적용
kubectl ns default

# EFS 확인 : AWS 관리콘솔 EFS 확인해보자
echo $EfsFsId
mount -t efs -o tls $EfsFsId:/ /mnt/myefs
df -hT --type nfs4

echo "efs file test" > /mnt/myefs/memo.txt
cat /mnt/myefs/memo.txt
rm -f /mnt/myefs/memo.txt

# 스토리지클래스 및 CSI 노드 확인
kubectl get sc
kubectl get sc gp2 -o yaml | yh
kubectl get csinodes

# 노드 정보 확인
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
eksctl get iamidentitymapping --cluster myeks

# 노드 IP 확인 및 PrivateIP 변수 지정
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2b -o jsonpath={.items[0].status.addresses[0].address})
N3=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
echo "export N1=$N1" >> /etc/profile
echo "export N2=$N2" >> /etc/profile
echo "export N3=$N3" >> /etc/profile
echo $N1, $N2, $N3

# 노드 보안그룹 ID 확인
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng1* --query "SecurityGroups[*].[GroupId]" --output text)
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32

# 워커 노드 SSH 접속
for node in $N1 $N2 $N3; do ssh ec2-user@$node hostname; done

CF) Amazon EBS 볼륨 유형

https://docs.aws.amazon.com/ko_kr/ebs/latest/userguide/ebs-volume-types.html

       mount [-h|-V]

       mount [-l] [-t fstype]

       mount -a [-fFnrsvw] [-t fstype] [-O optlist]

       mount [-fnrsvw] [-o options] device|mountpoint

       mount [-fnrsvw] [-t fstype] [-o options] device mountpoint

       mount --bind|--rbind|--move olddir newdir

       mount
       --make-[shared|slave|private|unbindable|rshared|rslave|rprivate|runbindable]

• 마운트는 리눅스 시스템에서 파일 시스템을 특정 디렉토리에 연결하는 작업입니다. 마치 드라이브를 컴퓨터에 연결하거나 폴더를 다른 폴더에 삽입하는 것과 비슷합니다.
  • /etc/fstab 파일은 시스템 부팅 시 자동으로 마운트되는 파일 시스템을 설정하는 데 사용됩니다.
  • mount 명령의 -h 옵션을 사용하면 사용 가능한 옵션 목록을 볼 수 있습니다.
  • man mount 명령을 사용하면 마운트 명령에 대한 자세한 정보를 볼 수 있습니다.

 

#EKS Storage

Kubernetes에는 임시 스토리지와 영구 스토리지라는 두 가지 유형의 스토리지가 있습니다. 임시 스토리지는 수명이 짧으며 이를 사용하는 포드가 종료되면 삭제됩니다. 임시 스토리지의 예로는 컨테이너의 루트 파일 시스템 또는 emptyDir 볼륨 유형이 있습니다. 임시 스토리지는 일반적으로 인프라 제공자에게만 국한되지 않습니다.

이름에서 알 수 있듯이 영구 스토리지는 수명이 길다. 일반적으로 이를 사용하는 포드보다 수명이 길고 일반적으로 명시적으로 삭제될 때까지 지속됩니다. Kubernetes에서 영구 스토리지는 일반적으로 persistVolumeClaim 볼륨 유형과 연결되지만 때로는 호스트 경로 일 수도 있습니다 . 영구 스토리지 볼륨은 인프라 제공자(hostPath 제외)와 밀접하게 연결되어 있으므로 이 기사에서는 이에 대해 중점적으로 다룰 것입니다.

EKS의 경우 영구 스토리지 볼륨에 대한 옵션은 세 가지뿐입니다.

• 컨테이너에 직접 연결된 하드 드라이브와 유사한 EBS(Elastic Block Store)
• EFS(Elastic File System)는 수십 년 동안 UNIX 세계에서 광범위하게 사용되어 온 NFS(Network File System)를 기반으로 하는 네트워크 파일 시스템입니다.
• FSx , Windows 운영 체제 전용 네트워크 파일 시스템(따라서 Windows를 실행하는 컨테이너에만 사용할 수 있음)

본격적으로 시작하기 전에 포드와 컨테이너의 차이점을 명확히 해보겠습니다. 본질적으로 컨테이너는 포드의 구성 요소입니다. 포드는 하나 이상의 컨테이너를 실행할 수 있습니다. 일반적으로 단일 Pod 내에서 두 개 이상의 컨테이너가 실행되는 경우 하나는 일반적으로 "앱" 컨테이너이고 다른 컨테이너는 일부 지원 소프트웨어(예: 네트워크 프록시 또는 로깅용)를 실행하며 일반적으로 "사이드카"라고 합니다.

 

Kubernetes 영구 볼륨(PV)은  Pod가 Kubernetes StorageClass를 통해 정의된 저장 장치의 영구 저장소에 액세스할 수 있도록 허용하는 객체입니다. 본질적으로 일시적인 일반 볼륨과 달리 PV는 지속적이므로 상태 저장 애플리케이션 사용 사례를 지원합니다. PV는 이를 사용하는 포드가 삭제된 후에도 계속 존재하는 Kubernetes 클러스터의 리소스 개체입니다.

PV는 스토리지 요청인 지속적 볼륨 클레임(PVC)을 통해 요청해야 합니다. PVC는 기본적으로 특정 요구 사항을 충족하는 PV를 포드에 탑재하라는 요청입니다. PVC는 특정 PV를 지정하지 않고 대신 포드에 필요한 StorageClass를 지정합니다. 관리자는 성능, 서비스 수준, 백엔드 정책 등 저장 장치의 속성을 나타내는 StorageClass를 정의할 수 있습니다.

 

#EKS Storage 실습

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

# AWS LB Controller
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

# ExternalDNS
MyDomain=julki.link
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId

curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"

 

-helm

Helm은 원래 DeisLabs 가 타사 유틸리티 로 만든 오픈 소스 졸업 CNCF 프로젝트 로 현재는 Kubernetes용 패키지 관리자 로 알려져 있으며 간단하고 일관된 방식으로 Kubernetes 애플리케이션 수명 주기를 자동화하는 데 중점을 두고 있습니다. 패키지 관리자로서 Helm의 목적은 Kubernetes 애플리케이션용 패키지를 쉽고 자동으로 관리(설치, 업데이트 또는 제거)하고 몇 가지 명령만으로 패키지를 배포하는 것입니다.

참고: https://blog.bespinglobal.com/post/aws-route53%EC%97%90%EC%84%9C-dns-%EA%B5%AC%EC%9E%85%ED%95%98%EA%B8%B0-vs-%EB%8B%A4%EB%A5%B8-%EA%B3%B3%EC%97%90%EC%84%9C-%EA%B5%AC%EB%A7%A4%ED%95%9C-%EB%8F%84%EB%A9%94%EC%9D%B8-route53%EC%97%90/

 

 

- 설치 정보 확인

# 이미지 정보 확인
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c

# eksctl 설치/업데이트 addon 확인
eksctl get addon --cluster $CLUSTER_NAME

# IRSA 확인
eksctl get iamserviceaccount --cluster $CLUSTER_NAME

 

2. 도전과제 - Deploying WordPress and MySQL with Persistent Volumes : PVC/PV를 사용하여 워드프레스 배포

 

MySQL과 Wordpress는 각각 데이터를 저장하기 위해 PertantVolume이 필요합니다. PertantVolumeClaim은 배포 단계에서 생성됩니다. 많은 클러스터 환경에는 기본 StorageClass가 설치되어 있습니다. PertantVolumeClaim에 StorageClass가 지정되지 않은 경우 클러스터의 기본 StorageClass가 대신 사용됩니다. PertantVolumeClaim이 생성되면 PertantVolume은 StorageClass 구성에 따라 동적으로 프로비저닝됩니다.

• MySQL 및 WordPress 배포 구성 파일을 다운로드합니다.

• kustomization.yaml을 추가하고, 여기 kustomization.yaml에는 WordPress 사이트 및 MySQL 데이터베이스를 배포하기 위한 모든 리소스가 포함되어 있습니다. 다음을 통해 디렉토리를 적용할 수 있습니다.

• Secret 및 PertantVolume이 동적으로 프로비저닝되었는지 확인

• 파드가 실행중인지 확인

• 로드밸런서가 생성되었는 지 확인

•  WordPress 설정 페이지가 표시

 

5. 실습 완료 후 리소스 삭제

eksctl delete cluster --name $CLUSTER_NAME && aws cloudformation delete-stack --stack-name $CLUSTER_NAME

 

삭제 소요시간은 대략 20분정도 걸리며, 아래와 같이 삭제된 것을 확인가능함.

#스터디 후기

EKS 실습을하면서 스토리지를 다루는 방법을 배웠습니다. 실습에서는 EBS, EFS 등 AWS에서 사용하는 스토리지를 PV,PVC 와 연결하고 다양한 스토리지 옵션을 배울 수 있었습니다. 하지만, 실습하면서  이해하기 어려운 부분도 있었습니다. EKS Storage 실습을 통해 배운 내용을 바탕으로 실무에서 EKS를 사용할 때, 스토리지를 효율적으로 관리할 수 있을 것 같습니다. 실습을 진행하면서 어려웠던 부분이나 궁금한 점을 정리하고, 이를 해결하는 과정에서 EKS에 대한 이해도를 높여야겠습니다.