2024. 4. 7. 08:40ㆍEKS@CloudNet
- CloudNet에서 주관하는 EKS 스터디 2기 내용입니다
- 매번 좋은 스터디를 진행해 주시는 CloudNet 팀 감사드립니다
Autoscaling이란?
개인적으로 오토스케일링이 클라우드 컴퓨팅의 가장 큰 존재 이유라고 생각해서 이번 세션이 기다려졌다.
오토스케일링은 시스템 리소스의 메트릭을 모니터링하여 서버를 자동으로 증설/감설하는 서비스이다. 따라서 평시에는 리소스를 적게 유지할 수 있으므로 경제적이면서도 수요 증가에도 안정적으로 대응할 수 있다는 장점이 있다.
서버 증설에는 scale up과 scale out 두 가지 방법이 있다.
- scale up: 인스턴스 스펙을 업그레이드해서 더 좋은 인스턴스를 사용
예시: intel i3 -> intel i7로 교체
장점: 구현이 쉽다
단점: 비용이 많이 든다
- scale out: 인스턴스의 갯수를 업그레이드해서 더 많은 인스턴스를 사용
예시: intel i3 -> intel i3 *3개로 증설
장점: 경제적이다
단점: 구현이 상대적으로 어렵고 통신 오버헤드가 발생한다
- 클라우드의 오토스케일링은 scale up/out 모두를 적용할 수 있지만, 주로 scale out을 다룬다.
- 이번 세션에서는 다양한 오토스케일러의 사용을 실습해본다.
0. Setup
- 기존과 비슷하게 가시다님이 배포해주신 원클릭 배포 파일을 사용한다.
- 지난번 observability 세션에서는 xlarge 인스턴스를 사용했는데, 이번에는 autoscaling을 보기 위해서인 만큼 t3.medium 인스턴스를 배포한다.
- 배포 코드: 지난 포스팅에 트러블슈팅 과정이 자세히 있다.
# cloudformation yaml file 다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick4.yaml
# default 네임스페이스 적용
kubectl ns default
# 노드 정보 확인 : t3.medium
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
# ExternalDNS
MyDomain=<자신의 도메인>
echo "export MyDomain=<자신의 도메인>" >> /etc/profile
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"
# 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
# gp3 스토리지 클래스 생성
kubectl apply -f https://raw.githubusercontent.com/gasida/PKOS/main/aews/gp3-sc.yaml
# 노드 보안그룹 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
- 모니터링을 위한 프로메테우스 & 그라파나 설치 및 배포
지난주에 애먹였던 CERT_ARN 인증서에 주의한다.
# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN
# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
# 파라미터 파일 생성 : PV/PVC(AWS EBS) 삭제에 불편하니, 4주차 실습과 다르게 PV/PVC 미사용
cat <<EOT > monitor-values.yaml
prometheus:
prometheusSpec:
podMonitorSelectorNilUsesHelmValues: false
serviceMonitorSelectorNilUsesHelmValues: false
retention: 5d
retentionSize: "10GiB"
verticalPodAutoscaler:
enabled: true
ingress:
enabled: true
ingressClassName: alb
hosts:
- prometheus.$MyDomain
paths:
- /*
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
grafana:
defaultDashboardsTimezone: Asia/Seoul
adminPassword: prom-operator
defaultDashboardsEnabled: false
ingress:
enabled: true
ingressClassName: alb
hosts:
- grafana.$MyDomain
paths:
- /*
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
kube-state-metrics:
rbac:
extraRules:
- apiGroups: ["autoscaling.k8s.io"]
resources: ["verticalpodautoscalers"]
verbs: ["list", "watch"]
prometheus:
monitor:
enabled: true
customResourceState:
enabled: true
config:
kind: CustomResourceStateMetrics
spec:
resources:
- groupVersionKind:
group: autoscaling.k8s.io
kind: "VerticalPodAutoscaler"
version: "v1"
labelsFromPath:
verticalpodautoscaler: [metadata, name]
namespace: [metadata, namespace]
target_api_version: [apiVersion]
target_kind: [spec, targetRef, kind]
target_name: [spec, targetRef, name]
metrics:
- name: "vpa_containerrecommendations_target"
help: "VPA container recommendations for memory."
each:
type: Gauge
gauge:
path: [status, recommendation, containerRecommendations]
valueFrom: [target, memory]
labelsFromPath:
container: [containerName]
commonLabels:
resource: "memory"
unit: "byte"
- name: "vpa_containerrecommendations_target"
help: "VPA container recommendations for cpu."
each:
type: Gauge
gauge:
path: [status, recommendation, containerRecommendations]
valueFrom: [target, cpu]
labelsFromPath:
container: [containerName]
commonLabels:
resource: "cpu"
unit: "core"
selfMonitor:
enabled: true
alertmanager:
enabled: false
EOT
cat monitor-values.yaml | yh
# 배포
kubectl create ns monitoring
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 57.2.0 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring
# Metrics-server 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 프로메테우스 ingress 도메인으로 웹 접속
echo -e "Prometheus Web URL = https://prometheus.$MyDomain"
# 그라파나 웹 접속 : 기본 계정 - admin / prom-operator
echo -e "Grafana Web URL = https://grafana.$MyDomain"
+DEBUG: DNS_PROBE_FINISHED_NXDOMAIN 에러
ingress로 Kube-ops-view, prometheus, grafana를 배포한 직후 접속했더니 위 에러가 뜨면서 접속이 안 되었다. 아직 동기화가 안 되었다고 생각하고 기다렸으나 5분이 지나고도 안 들어가져서 당황했는데, 크롬브라우저 캐시 때문에 그런 상황이 발생할 수 있다고 한다.
아래 사진은 동시에 같은 주소의 프로메테우스에 접속했는데 왼쪽 일반 창에서는 접속 실패시의 캐시가 남아 계속 에러가 뜨고, 캐시 영향 없는 시크릿모드에서는 정상적으로 접근되는 모습을 보여준다.
당황하지 말고 캐시 삭제 or 시크릿모드 접속을 시도해보자. 그러고도 안되면... 다른 이유일 것이다.
1. HPA(Horizontal Pod Autoscaler)
- Pod의 갯수를 증감시키면서 스케일을 조정하는 방식이다. scale out 에 해당한다.
실습
- hpa 정책을 생성한다.
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
kubectl describe hpa
- 정책을 확인했을 때, maxReplicas=10, minReplicas:1 인 것을 확인할 수 있다
- 오토스케일러 실습이니만큼 부하를 주기 위한 서비스를 배포한다. php-apache.yaml pod은 백만번의 덧셈연산을 강요해서 scale out 요건을 발동시킨다.
# Run and expose php-apache server
curl -s -O https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/php-apache.yaml
cat php-apache.yaml | yh
kubectl apply -f php-apache.yaml
# 확인
kubectl exec -it deploy/php-apache -- cat /var/www/html/index.php
# 테스트용 서비스 실행
while true;do curl -s $PODIP; sleep 0.5; done
- 부하가 가해지기 전 모습이다. Pod 26개가 작동하고 있으며 cpu 이용률에도 특이사항 없다.
(최근에 Pod이 증가한 것은 오토스케일러 실습용 서비스를 배포해서이다)
- 부하가 가해지고 나서 모습이다. pod 갯수가 26 -> 27개로 증가했으며, 우측 상단에 TARGET의 cpu활용률이 상승하는 것을 확인.
-kube-ops-view에서도 Pod가 추가된 것을 확인할 수 있다.
- 17125번 기반으로 1.28버전에 맞게 가시다님이 커스텀해주신 그라파나 대시보드에서도 replica가 1->2개로 증가했다.
- 부하 주기를 정지하고 5분이 지나니 다시 replica가 2->1개로 감소한다.
- 다음 실습을 위해 리소스를 삭제한다
kubectl delete deploy,svc,hpa,pod --all
2. VPA(Vertical Pod Autoscaler)
- 리소스 사용량에 맞게 Pod에 적정한 resource request를 조정하는 방식이다. 이때 인스턴스가 교체되면 Pod이 내려갔다가 다시 올라온다. scale up 에 해당한다.
- (1. 의 HPA와 정반대 개념이기 때문에) 같이 사용할 수 없다.
실습
- kubernates autoscaler github을 클론한다
git clone https://github.com/kubernetes/autoscaler.git
cd ~/autoscaler/vertical-pod-autoscaler/
tree hack
- OpenSSL 버전이 1.1.1 이상인지 확인하고 아니라면 업그레이드한다.
# openssl 버전 확인
openssl version
# 업그레이드 설치
yum install openssl11 -y
# 스크립트 파일 수정
sed -i 's/openssl/openssl11/g' ~/autoscaler/vertical-pod-autoscaler/pkg/admission-controller/gencerts.sh
- 다운로드받은 vpa를 실행 하고 실행상태를 확인한다.
# vpa 실행
./hack/vpa-up.sh
# 실행 확인
kubectl get crd | grep autoscaling
# 모니터링
watch -d "kubectl top pod;echo "----------------------";kubectl describe pod | grep Requests: -A2"
- 공식 예제를 배포한다.
cd ~/autoscaler/vertical-pod-autoscaler/
cat examples/hamster.yaml | yh
kubectl apply -f examples/hamster.yaml && kubectl get vpa -w
- 위에서 걸어놓은 모니터링에 request가 등록된 것을 확인 할 수 있다.
- 실행 약 3분 후 request가 100m -> 500m로 업데이트 된 것을 확인할 수 있다.
- 발생한 이벤트를 조회하면, VPA에 의해 기존 파드가 삭제되고 새로 실행되었다는 것을 알 수 있다.
kubectl get events --sort-by=".metadata.creationTimestamp" | grep VPA
그라파나 대시보드 추천: 14588
배포 전/배포 후
- 다음 실습을 위해 리소스를 삭제한다
kubectl delete -f examples/hamster.yaml && cd ~/autoscaler/vertical-pod-autoscaler/ && **./hack/vpa-down.sh**
3. Karpenter
- karpenter는 k8s native한 노드 수명 주기 관리 솔루션(오토스케일러) 이다. 기존 오토스케일러들은 리소스 요구사항 반영에 시간이 꽤 걸렸는데 (위의 vpa만 해도 2-3분) 이것을 단 몇 초로 줄여주어서 획기적이라는 평가를 받고 널리 사용되고 있다.
- 모니터링 기반으로 Provisioner의 개념을 사용한다.
Provisioning: 모니터링하다가 스케줄링되지 않은 Pod을 발견하면 스펙을 평가하고 생성한다.
Deprovisioning: 모니터링하다가 비어있는 Node를 발견하면 제거한다.
실습
- cloudformation으로 실습 환경을 새로 배포한다
# CloudFormation link
https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/karpenter-preconfig.yaml
- EKS node viewer 을 설치한다. 설치에 약 5분 정도 소요되었다.
wget https://go.dev/dl/go1.22.1.linux-amd64.tar.gz
tar -C /usr/local -xzf go1.22.1.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go install github.com/awslabs/eks-node-viewer/cmd/eks-node-viewer@latest
- EKS를 배포하기 위한 변수 설정 및 IAM policy, Role을 생성한다.
# 변수 정보 확인
export | egrep 'ACCOUNT|AWS_' | egrep -v 'SECRET|KEY'
# 변수 설정
export KARPENTER_NAMESPACE="kube-system"
export K8S_VERSION="1.29"
export KARPENTER_VERSION="0.35.2"
export TEMPOUT=$(mktemp)
export ARM_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-arm64/recommended/image_id --query Parameter.Value --output text)"
export AMD_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2/recommended/image_id --query Parameter.Value --output text)"
export GPU_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-gpu/recommended/image_id --query Parameter.Value --output text)"
export AWS_PARTITION="aws"
export CLUSTER_NAME="${USER}-karpenter-demo"
echo "export CLUSTER_NAME=$CLUSTER_NAME" >> /etc/profile
echo $KARPENTER_VERSION $CLUSTER_NAME $AWS_DEFAULT_REGION $AWS_ACCOUNT_ID $TEMPOUT $ARM_AMI_ID $AMD_AMI_ID $GPU_AMI_ID
# CloudFormation 스택으로 IAM Policy, Role(KarpenterNodeRole-myeks2) 생성 : 3분 정도 소요
curl -fsSL https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > "${TEMPOUT}" \
&& aws cloudformation deploy \
--stack-name "Karpenter-${CLUSTER_NAME}" \
--template-file "${TEMPOUT}" \
--capabilities CAPABILITY_NAMED_IAM \
--parameter-overrides "ClusterName=${CLUSTER_NAME}"
- EKS 클러스터를 생성한다. 20분 정도 맘 편하게 기다려준다.
eksctl create cluster -f - <<EOF
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: ${CLUSTER_NAME}
region: ${AWS_DEFAULT_REGION}
version: "${K8S_VERSION}"
tags:
karpenter.sh/discovery: ${CLUSTER_NAME}
iam:
withOIDC: true
serviceAccounts:
- metadata:
name: karpenter
namespace: "${KARPENTER_NAMESPACE}"
roleName: ${CLUSTER_NAME}-karpenter
attachPolicyARNs:
- arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}
roleOnly: true
iamIdentityMappings:
- arn: "arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}"
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
managedNodeGroups:
- instanceType: m5.large
amiFamily: AmazonLinux2
name: ${CLUSTER_NAME}-ng
desiredCapacity: 2
minSize: 1
maxSize: 10
iam:
withAddonPolicies:
externalDNS: true
EOF
- 배포를 확인하고 위에서 설치한 eks-node-viewer을 실행한다
# eks 배포 확인
eksctl get cluster
eksctl get nodegroup --cluster $CLUSTER_NAME
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
eksctl get iamserviceaccount --cluster $CLUSTER_NAME
eksctl get addon --cluster $CLUSTER_NAME
# node 정보 확인
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
# set default NS
kubectl ns default
# EKS node viewer 실행
cd ~/go/bin && ./eks-node-viewer --resources cpu,memory
지금까지는 실습에서 주로 t3 시리즈 인스턴스를 사용했는데 m5 시리즈 인스턴스를 사용한다.
- kube-ops-view 사용을 위해 ExternalDNS를 설정해주고 kube-ops-view를 다시 띄운다.
(코드는 위에 있으니 생략! )
- Karpenter를 설치한다
# 변수 설정
export CLUSTER_ENDPOINT="$(aws eks describe-cluster --name "${CLUSTER_NAME}" --query "cluster.endpoint" --output text)"
export KARPENTER_IAM_ROLE_ARN="arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}-karpenter"
echo "${CLUSTER_ENDPOINT} ${KARPENTER_IAM_ROLE_ARN}"
# karpenter 설치
helm install karpenter oci://public.ecr.aws/karpenter/karpenter --version "${KARPENTER_VERSION}" --namespace "${KARPENTER_NAMESPACE}" --create-namespace \
--set "serviceAccount.annotations.eks\.amazonaws\.com/role-arn=${KARPENTER_IAM_ROLE_ARN}" \
--set "settings.clusterName=${CLUSTER_NAME}" \
--set "settings.interruptionQueue=${CLUSTER_NAME}" \
--set controller.resources.requests.cpu=1 \
--set controller.resources.requests.memory=1Gi \
--set controller.resources.limits.cpu=1 \
--set controller.resources.limits.memory=1Gi \
--wait
# 확인
kubectl get-all -n $KARPENTER_NAMESPACE
kubectl get all -n $KARPENTER_NAMESPACE
kubectl get crd | grep karpenter
# APi 변경
v1alpha5/Provisioner → v1beta1/NodePool
v1alpha1/AWSNodeTemplate → v1beta1/EC2NodeClass
v1alpha5/Machine → v1beta1/NodeClaim
설치가 잘 되었고 kube-ops-view에서도 Pod이 하나씩 추가되었다.
Karpenter 을 띄운 것 만으로도 cpu 사용량이 많이 증가했다.
- NodePool 을 생성한다. NodePool은 label, taint, 노드 스펙, 삭제 조건을 설정한다.
cat <<EOF | envsubst | kubectl apply -f -
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
- key: kubernetes.io/os
operator: In
values: ["linux"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"]
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["c", "m", "r"]
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values: ["2"]
nodeClassRef:
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
name: default
limits:
cpu: 1000
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h # 30 * 24h = 720h
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2 # Amazon Linux 2
role: "KarpenterNodeRole-${CLUSTER_NAME}" # replace with your cluster name
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: "${CLUSTER_NAME}" # replace with your cluster name
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: "${CLUSTER_NAME}" # replace with your cluster name
amiSelectorTerms:
- id: "${ARM_AMI_ID}"
- id: "${AMD_AMI_ID}"
# - id: "${GPU_AMI_ID}" # <- GPU Optimized AMD AMI
# - name: "amazon-eks-node-${K8S_VERSION}-*" # <- automatically upgrade when a new AL2 EKS Optimized AMI is released. This is unsafe for production workloads. Validate AMIs in lower environments before deploying them to production.
EOF
# 확인
kubectl get nodepool,ec2nodeclass
- scale up deployment: Pause된 Pod 하나에 최소 1개의 cpu가 할당되는 것을 보장하게 하는 inflate deployment를 배포한다.
# deployment.yaml
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 0
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
EOF
- 이 Deployment를 이용해 pod 갯수를 증가시킨다
kubectl scale deployment inflate --replicas 5
- kube-ops-view와 터미널에서 5개의 pod가 추가된 것을 볼 수 있다.
- scale down deployment
이번엔 반대로 deployment를 삭제해보았다.
pod의 삭제에 따른 scale down이 정상적으로 이뤄진 걸 kube-ops-view에서 볼 수 있다. 굉장히 빨리 반영된다!!
잊지 말아요 자원 삭제
우리의 지갑은 소중하니까요
- HPA, VPA 실습 리소스 삭제
eksctl delete cluster --name $CLUSTER_NAME && aws cloudformation delete-stack --stack-name $CLUSTER_NAME
- Karpenter 실습 리소스 삭제
# Karpenter IAM Role 생성한 CloudFormation 삭제
aws cloudformation delete-stack --stack-name "Karpenter-${CLUSTER_NAME}"
# EC2 Launch Template 삭제
aws ec2 describe-launch-templates --filters "Name=tag:karpenter.k8s.aws/cluster,Values=${CLUSTER_NAME}" |
jq -r ".LaunchTemplates[].LaunchTemplateName" |
xargs -I{} aws ec2 delete-launch-template --launch-template-name {}
# 클러스터 삭제
eksctl delete cluster --name "${CLUSTER_NAME}"
# 위 삭제 완료 후 아래 삭제
aws cloudformation delete-stack --stack-name myeks2
'EKS@CloudNet' 카테고리의 다른 글
| [EKS@CloudNet] EKS CI/CD (0) | 2024.04.21 |
|---|---|
| [EKS@CloudNet] EKS Security (0) | 2024.04.14 |
| [EKS@CloudNet] EKS Observability: Prometheus & Grafana (0) | 2024.03.31 |
| [EKS@CloudNet] EKS Storage & Nodegroup (1) | 2024.03.23 |
| [EKS@CloudNet] EKS Networking (3) | 2024.03.17 |