I got IT

EKS Auto Mode 본문

AWS/EKS

EKS Auto Mode

joshhoxy 2025. 3. 23. 09:55
※ 해당 글은 CloudNet@ gasida 님의 EKS 스터디 내용을 참고하여 작성하였습니다.

 

들어가며

EKS 클러스터의 컴퓨팅 타입 선정에는 다양한 옵션이 있습니다. Amazon EKS 클러스터는 EKS 자동 모드 관리형 노드, 자체 관리형 노드, Amazon EKS 관리형 노드 그룹, AWS Fargate, Amazon EKS Hybrid Nodes의 옵션을 제공하고 이를 단독으로 사용하거나 조합해서 사용하는 등 사용환경 및 요구사항에 따라 다양하게 선택이 가능합니다.

EKS 클러스터의 성능과 운영 효율성은 어떤 컴퓨팅 리소스를 선택하느냐에 크게 좌우됩니다. Managed Node Group, Fargate, Auto Mode와 같은 다양한 옵션은 각각 비용, 관리 부담, 확장성, 보안성 등 여러 측면에서 서로 다른 특성을 지니고 있어, 애플리케이션의 특성과 운영 환경에 맞는 적절한 선택이 필수적입니다.

예를 들어, Managed Node Group은 EC2 인스턴스 기반으로 고도의 커스터마이징과 세밀한 제어가 가능하지만, 인프라 관리를 위한 추가적인 운영 작업이 필요합니다. 반면, Fargate는 서버리스 환경을 제공하여 인프라 관리 부담을 크게 줄여주고 빠른 확장이 가능하지만, 특정 워크로드에서는 비용 효율성이 떨어질 수 있습니다. Auto Mode는 이 두 옵션의 장점을 결합해 상황에 따라 유연하게 리소스를 할당할 수 있도록 지원합니다.

따라서, EKS의 컴퓨팅 타입 선택은 애플리케이션의 성능 최적화와 안정적 운영을 위한 핵심 결정 요소로, 각 옵션의 특징과 장단점을 면밀히 비교하고 이해하는 것이 매우 중요합니다.

EKS 컴퓨팅 타입 비교: Managed Node Group vs Fargate vs Auto Mode

그 중에서도 가장 많이 사용하는 유형은 Managed Node Group과 Fargate 유형입니다.

다만, 아무리 EKS가 바닐라쿠버네티스를 구성하는 것보다 많은 편의를 지원한다고는 하지만 아직까지 EKS를 사용하는 것은 비전문가 입장에서 진입장벽과 러닝커브가 있습니다. 이에 대해서 최근 AWS는 거의 모든 관리를 지원하는 EKS Auto Mode를 출시하였습니다.

이 세가지 옵션에 대한 비교를 해보겠습니다.

항목 EKS Managed Node Group EKS on Fargate EKS Auto Mode
노드 관리 방식 EC2 기반 노드 그룹 (사용자가 직접 선택) 서버리스 (노드 추상화됨) AWS가 모든 인프라 자동 구성
인프라 제어 EC2 타입, AMI, 보안 설정 모두 사용자가 제어 노드 인프라 직접 접근 불가 제어 플레인 + 워커 노드 + 네트워크까지 자동
확장성 Auto Scaling 가능 (직접 구성 필요) Pod 단위 자동 확장 Karpenter 기반 자동 확장
요금 과금 기준 EC2 인스턴스 기준 Pod CPU/Memory 사용량 기준 EC2 노드 기준 (자동 관리)
네트워크 구성 사용자가 VPC/Subnet 구성 사전 정의된 서브넷에만 배포 가능 VPC/Subnet도 자동 구성
운영 복잡도 높음 (운영자가 노드 책임) 중간 (간편하지만 제약 있음) 매우 낮음 (Fully managed)

EKS Managed Node Group

특징

  • Kubernetes 워커 노드를 EC2 인스턴스로 구성하며, 노드 그룹 생성/업데이트/패치 등을 AWS가 자동으로 관리.
  • 인프라 제어는 사용자가 직접 함 (인스턴스 타입, 수, 보안 설정 등).

장점

  • 유연한 EC2 인스턴스 설정 가능 (GPU, 메모리 최적화 등).
  • Spot, On-Demand, Auto Scaling 그룹 등 다양한 활용 가능.
  • Karpenter, Cluster Autoscaler 등과 잘 연동됨.
  • 커스터마이징 영역이 가장 넓음

단점

  • EC2 리소스를 직접 관리해야 하므로 운영 복잡도가 높음.
  • 비용 최적화 및 확장 전략을 사용자가 구성해야 함.

사용 사례

  • 대규모 워크로드 운영 환경
  • GPU가 필요한 ML/AI 워크로드
  • 비용 최적화가 중요한 대규모 서비스 운영

EKS on Fargate

특징

  • Kubernetes Pod를 서버리스 환경에서 실행.
  • EC2 인프라를 직접 관리할 필요 없음.

장점

  • 완전한 서버리스 → 노드 패치, 보안, 확장 모두 자동.
  • 작은 워크로드, 이벤트 기반 작업에 적합.
  • 빠른 배포와 높은 보안성 (자원 간 격리).

단점

  • GPU, DaemonSet 등 특수 워크로드 미지원.
  • 고정 비용이 상대적으로 높음 (Pod 단위 과금).
  • Pod당 리소스 크기 제한 존재.
  • Spot 은 지원하지 않음

사용 사례

  • 이벤트 기반 서버리스 워크로드
  • Job 또는 CronJob 실행

EKS Auto Mode (신규)

특징

  • 클러스터 생성 시 제어 플레인, 노드, 네트워크까지 모두 자동 구성.
  • Karpenter 기반 노드 자동 확장 포함.
  • 초보자, 실습용, Dev 환경에 최적화.

장점

  • 클러스터 생성이 매우 간편 (VPC, 서브넷, 노드 자동 생성).
  • 운영 관리 거의 없음 → 빠르게 EKS를 시작 가능.
  • 실습/테스트 환경을 위한 가벼운 운영에 최적.
  • Karpenter 내장 → 수요 기반으로 자동 확장 및 축소.

단점

  • 세밀한 네트워크 구성 불가
  • EC2 타입 등 세부 설정 불가 (AWS가 자동 결정).
  • 엔터프라이즈 요구에 맞게 커스터마이징하기 어려움.

사용 사례

  • EKS를 처음 사용하는 사용자
  • 실습/교육/PoC 환경
  • 빠른 테스트 배포가 필요한 Dev 팀
  • 복잡한 운영 없이 빠르게 클러스터를 구성하고 싶은 경우

결론

사용자의 요구사항 및 사용사례에 따라서 알맞은 EKS 컴퓨팅 옵션을 사용해야 합니다.

프로젝트 프로토타입 및 PoC, 테스트 환경에는 Auto Mode를 사용하는 것이 좋을 듯하고, 실제 상용 서비스 운영 환경에는 Standard Mode + Managed Node Group이나 Karpenter를 고려하는 것이 좋은 선택으로 보입니다.

EKS Auto Mode 에 대해

https://www.youtube.com/watch?v=_wwu0VKy3w4

EKS Auto Mode의 출시는 2024년 12월 09일로 출시되지 얼마 되지 않은 따끈따끈한 서비스 입니다. 따라서 저 또한 이번 스터디를 통해서 EKS Auto Mode라는 것에 대해 처음 알게 되었으며 EKS Auto Mode를 주제로 이번 스터디 학습 내용을 정리해보려고 합니다.

다음 링크에서 EKS Auto Mode에 대한 자세한 정보를 참고하시기 바랍니다.

EKS Auto Mode의 가장 큰 특징은 한 마디로 제어 플레인부터 워커 노드, 네트워크 구성까지 모든 인프라를 AWS가 자동으로 관리해 준다는 점이라고 할 수 있습니다.

이는 AWS 공유책임 모델을 EKS Auto Mode에 적용한 것을 보면 확인할 수 있습니다.

EKS Auto Mode 의 제약 사항

하지만 위에서 여러 단점을 언급한 것 처럼 EKS Auto Mode에는 여러가지 제약 사항이 존재합니다. 따라서 이러한 점을 고려하여 실제 사용에 적합한지 검토해야할 필요가 있습니다.

- EKS 컨트롤 플레인 주요 컴포넌트가 파드가 아닌 노드 데몬으로 실행됨

  • kube-proxy, kubelet, eks-pod-identity-agent, eks-node-monitor-agent, eks-healthcheck, eks-ebs-csi-driver 등의 kube-system 네임스페이스의 파드가 노드에서 실행됩니다.
  • 이는 이전에 얘기한 것 처럼 사용자는 EKS 노드에 직접 접근하지 못하기 때문에 컨트롤플레인 관련한 관리와 트러블 슈팅에 한계가 있을 수 있습니다.

- 노드에 대해 불변으로 취급되는 AMI를 사용합니다.

  • SELinux 필수 액세스 제어를 활성화하며 읽기 전용 루트 파일 시스템을 제공합니다.
  • 또한 EKS Auto Mode에서 실행하는 노드의 최대 수명은 21일.
  • SELinux 강제 모드와 읽기 전용 루트 파일 시스템을 사용하여 AMI의 파일에 대한 액세스를 차단합니다.

- 자동 업그레이드

  • EKS 자동 모드는 최신 패치를 통해 Kubernetes 클러스터, 노드 및 관련 구성 요소를 최신 상태로 유지하면서 구성된 Pod Disruption Budgets(PDB) 및 NodePool Disruption Budgets(NDB)를 준수합니다.
  • 최대 21일의 수명까지 PDB 또는 기타 구성을 차단하여 업데이트를 방해하는 경우 개입이 필요할 수 있습니다.
  • 기본 14일 최대 21일로 노드의 라이프사이클이 설정되어 있습니다. 이는 변경할 수 없습니다.

- Node class: 스토리지와 파드 개수 제약. ephemeralStorage(80GiB), 노드 당 최대 파드 110개 제한

- node pool : 기본 노드풀은 활성화/비활성화 가능, budgets 로 disruption 중지 가능

- ingress class : IngressClassParams 리소스 및 API 일부 변경, 미지원 기능 확인

- StorageClss : provisioner: ebs.csi.eks.amazonaws.com , EBS 성능 프로메테우스 메트릭 접근 불가

- Update Kubernetes version : 업그레이드 시 자체 관리 Add-on 등은 사용자 담당

- 일부 VPC CNI 기능 제약

  • VPC CNI가 ENI와 IP 주소를 자동으로 할당하므로, 고밀도의 파드 환경에서는 사용자가 IP 주소 할당 정책을 미세하게 조절하기 어려워, IP 주소 고갈 문제를 사전에 충분히 고려해야 합니다.
  • 자동 모드에서는 사용자 정의 네트워킹, 커스텀 IPAM 설정 등 고급 네트워킹 기능을 활용할 수 없으므로, 특정 네트워킹 요구사항을 가진 워크로드에는 유연성이 떨어질 수 있습니다.

이외의 다양한 EKS Auto Mode 제약 사항은 공식문서를 참고 및 커뮤니티를 통해 확인해봐야할 것 같습니다. 아직까지 출시된 지 얼마 되지 않은 서비스 이기 때문에 실제 사용에 있어 어떤 불편함과 한계가 발생하는지 경험공유가 더 필요할 듯 합니다.

EKS Auto Mode의 NodePool Disruption Budgets(NDB)

EKS Automode의 NodePool Disruption Budgets(NDB)는 노드 풀에 속한 노드들이 유지보수, 업데이트, 또는 자동 스케일링 작업 등으로 인해 동시에 중단(disruption)되는 상황을 제어하기 위한 메커니즘입니다.

다음과 같은 disruption budget 설정을 통해 리소스 사용 예산을 제어 및 관리할 수 있습니다. 아래 예제를 통해 다음과 같은 설정을 적용할 수 있습니다.

  • 평일 9시 부터 8시간(근무 시간) 동안은 disruption 되지 않도록 합니다.
  • 다만, 노드에 아무 파드도 없을 경우에는 시간과 상관없이(100%) disruption 적용
  • 근무 시간 이외에는 한번에 disruption 되는 비중은 10%.

뿐만 아니라 가용성을 보장하기 위해 NDB를 활용할 수 있습니다. 자동 모드에서는 노드가 동적으로 생성되고 종료되기 때문에, 과도한 노드 교체로 인한 서비스 중단이나 성능 저하를 방지하기 위해 NDB가 활용됩니다. 즉, 노드의 업데이트나 유지보수 시에도 일정 비율 이상의 노드가 계속해서 활성 상태를 유지하도록 합니다.

EKS Auto Mode 실습

EKS Auto Mode 실습 환경 배포

Prequisite

EKS Auto Mode 배포는 Terraform 을 사용하여 배포합니다.

테라폼 코드는 AWS 공식 깃헙 샘플을 사용합니다. 🔗

아키텍처

EKS Auto Mode Terraform 배포

배포 하기전에 깃헙에서 코드를 받아와서 확인합니다.

git clone https://github.com/aws-samples/sample-aws-eks-auto-mode.git
cd sample-aws-eks-auto-mode/terraform

IDE 를 열어서 코드를 확인합니다.

terraform 디렉토리에서 코드를 살펴보면 별도의 Add on 코드가 없는 것을 확인할 수 있습니다. 이는 Auto Mode로 프로비저닝 하면 알아서 Add on을 설치해주기 때문입니다.

해당 테라폼 모듈의 EKS 클러스터 설정에서 bootstrap_self_managed_addons 설정에서 false로 설정되어 있으며 이를 true로 변경하고 Auto Mode를 배포할시 apply 에러가 발생하게 됩니다.

cluster_compute_config 는 테라폼에서 EKS Auto Mode를 설정하는 내용입니다. 자세한 내용은 테라폼 EKS Module 공식 문서를 살펴보시길 바랍니다. 🔗

Variables.tf 파일 수정

클러스터 IP 대역 및 리전 설정을 사용자에 맞게 변경합니다. ap-northeat-2, 10,20.0.0/16 으로 변경합니다.

Terraform 실행

테라폼을 init 하고 apply 까지 진행합니다.

terraform init
terraform plan
**terraform apply -auto-approve**

테라폼 apply 하면 다음과 같이 노드풀에 대한 yaml 파일이 자동으로 생성 됩니다. EKS Auto Mode는 카펜터를 활용하는 데 이 때 카펜터 프로비저너에 사용될 노드풀과 노드클래스를 정의하는 템플릿을 자동으로 생성합니다.

이는 setup.tf 에 코드로 작성되어 있습니다.

약 10분 정도가 지나자 EKS Auto Mode 클러스터가 생성되었습니다.

EKS Auto Mode 클러스터 확인

테라폼을 통해 EKS 클러스터가 잘 생성 되었는지 리소스를 확인합니다. 우선 클러스터 관리를 위해 kubectl 설정을 해줍니다.

kubeconfig 설정

$(terraform output -raw configure_kubectl)

테라폼 아웃풋에 다음과 같이 kube config를 구성하는 명령어가 설정되어 있습니다.

kubectl context 변경

기본 context 변경 및 설정을 해줍니다.

kubectl ctx
**kubectl config rename-context "arn:aws:eks:ap-northeast-2:$(aws sts get-caller-identity --query 'Account' --output text):cluster/automode-cluster" "automode-lab"**
kubectl ns default

kubectl get pod -A 를 해보면 아무런 리소스를 찾을 수 없다고 나옵니다. 이는 kube-system 네임 스페이스로 관리되던 기본 컨트롤플레인 파드들이 노드의 데몬으로 돌아가고 있기 때문에 사용자는 자신이 생성한 파드외에는 확인할 수 없기 때문입니다.

EKS 클러스터 확인(웹콘솔)

생성된 EKS 클러스터를 웹콘솔에서 살펴봅니다.

ENI를 살펴보면 위와 같이 EKS Owned ENI가 확인 가능합니다.

Cluster IAM Role, Node IAM Role, Auto Mode 설정을 확인합니다.

컴퓨팅 탭에서는 내장된 노드 풀이라는 general-purpose의 노드풀이 생성된 것을 확인할 수 있습니다.

액세스 탭에서는 클러스터롤과 관리형 서비스의 동작을 위한 서비스롤이 생성된 것을 확인할 수 있습니다.

추가기능 즉 애드온 탭을 확인해 보면 아무것도 없는 것을 볼 수 있습니다. 이는 실제로는 Add-on이 동작하고 있으나 유저에게는 보여지지 않는 것으로 AWS에서 알아서 관리하겠다는 강력한 의지를 보여주는 것 아닐까 싶습니다(?)

지금 까지 살펴본 바, AWS Auto Mode는 기존의 MGN , Fargate 을 사용해 생성한 클러스터와 매우 다른 것을 확인할 수 있습니다. 이는 대부분이 AWS 자체에서 관리되기 때문에 직접확인할 수 없는 블랙박스 영역이기 때문입니다.

그럼에도 kubectl 을 통해 어떠한 방식으로 AWS가 EKS Auto Mode 클러스터를 관리하고 어떻게 동작하는지 정도는 유추해볼 수 있습니다.

K8S 커스텀 리소스 확인

kubectl get crd

어떠한 리소스를 사용하는지 확인

kubectl api-resources | grep -i node

nodediagnostics

EKS Auto Mode에서는 노드에 Access가 불가능하니, 이를 분석 가능하도록 지원하는 CRD를 제공합니다.

kubectl explain nodediagnostics

nodeclass 확인

kubectl get nodeclasses.eks.amazonaws.com
kubectl get nodeclasses.eks.amazonaws.com -o yaml

nodepools 확인

kubectl get nodepools
kubectl get nodepools -o yaml

EKS Auto Mode 사용 해보기

EKS Auto Mode가 어떻게 동작하는 지 살펴보기 위해 실습을 진행합니다. 노드 및 파드의 확인을 위해 Kube-ops-view를 설치해줍니다.

kube-ops-view 설치

eks node viewer를 통해 kube-ops-viewer 설치 시 과정을 모니터링 합니다.

eks-node-viewer --node-sort=eks-node-viewer/node-cpu-usage=dsc --extra-labels eks-node-viewer/node-age
watch -d kubectl get node,pod -A

kube-ops-viewer를 helm 으로 배포합니다.

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

# events . 를 조회하여 설치과정 로그를 확인합니다.
kubectl get events -w --sort-by '.lastTimestamp'

kube-ops-viewer를 배포하자 다음과 같이 파드와 동시에 노드가 한 대씩 증설된걸 확인할 수 있습니다.

nodeclaim, node 확인

노드 클레임을 통해 노드 증설 요청이력을 확인할 수 있습니다.

kubectl get nodeclaims
kubectl get node -owide

AMI가 지정되어 있기 때문에 OS는 bottlerocket을 사용하고 container 런타임은 containerd를 사용하는 것을 확인할 수 있습니다.

※ 생성된 노드 접근해보기

웹콘솔 EC2 페이지에 가보면 노드가 생성된 것을 확인할 수 있습니다.

하지만 연결을 시도해보면 모두 막혀있어 접근할 수 없습니다.

또한 EC2를 임의로 중지하려해도 실패하는 것을 확인할 수 있습니다.

이는 워커노드 또한 AWS가 관리하는 EKS Auto Mode의 특징 때문입니다.

kube-ops-view 접근

kubectl port-forward deployment/kube-ops-view -n kube-system 8080:8080 &
# 접속 주소 확인 : 각각 1배, 1.5배, 3배 크기
echo -e "KUBE-OPS-VIEW URL = http://localhost:8080"
echo -e "KUBE-OPS-VIEW URL = http://localhost:8080/#scale=1.5"
echo -e "KUBE-OPS-VIEW URL = http://localhost:8080/#scale=3"

open "http://127.0.0.1:8080/#scale=1.5" # macOS

EKS Auto Mode Autoscale

EKS Auto Mode의 오토스케일 확인을 위해 cpu 1core 를 필요로 하는 데모용 애플리케이션을 배포합니다.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      nodeSelector:
        eks.amazonaws.com/compute-type: auto
      securityContext:
        runAsUser: 1000
        runAsGroup: 3000
        fsGroup: 2000
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: 1
          securityContext:
            allowPrivilegeEscalation: false
EOF

**kubectl get events -w --sort-by '.lastTimestamp'**
kubectl get nodes

파드가 새로 추가된 것을 볼 수 있습니다.

이후 replica를 늘리고 줄이면서 테스트 해봅니다.

eks-node-viewer --node-sort=eks-node-viewer/node-cpu-usage=dsc --extra-labels eks-node-viewer/node-age
watch -d kubectl get node,pod -A

# 
kubectl scale deployment inflate --replicas **100** && **kubectl get events -w --sort-by '.lastTimestamp'**

# 
kubectl scale deployment inflate --replicas **200** && **kubectl get events -w --sort-by '.lastTimestamp'**

#
kubectl scale deployment inflate --replicas **50** && **kubectl get events -w --sort-by '.lastTimestamp'**

# 실습 확인 후 삭제
**kubectl delete deployment inflate** && kubectl get events -w --sort-by '.lastTimestamp'

replicas 100 으로 늘리기

레플리카를 100개로 늘리자 파드 요청의 queue가 엄청나게 쌓인것을 확인 가능합니다.

이후 노드가 새로 assign 되었다는 이벤트 로그와 함께 이가 노드가 새로 생성된 것을 확인 가능합니다.

시간이 조금 지나자 노드가 한 대 더 생성된 것을 확인할 수 있습니다.

이후 스케줄링이 안정화 되면 다음과 같이 노드가 2대로 정리된 것을 확인할 수 있습니다.

파드와 노드가 스케줄링 되는 동안에 최초에 생성됬던 노드가 삭제되어 그 위에서 실행중이던 파드가 종료되어 kube-ops-viewer 페이지가 작동하지 않는 것을 확인하셨을 것입니다. 다음 명령어를 통해 해당 파드의 포트포워딩을 다시 실행해줍니다.

kubectl port-forward deployment/kube-ops-view -n kube-system 8080:8080 &

최초에 생성된 노드는 100개의 파드를 유지하기에 다소 부족한 스펙이었으므로 EKS Auto Mode 스케줄링 알고리즘에 의해 종료되고 새로운 사양의 노드가 생성된 것을 확인 가능합니다.

replicas 50 으로 줄이기

replicas를 50으로 줄이자 파드 eviction,kill 등의 로그가 발생하고 node를 종료하는 이벤트가 발생되는 것을 확인할 수 있습니다.

이후 노드 r5b.metal 타입의 노드 한대에서 deployment가 배포되는 것을 확인할 수 있습니다.

실습 자원 삭제하기

위 과정을 통해 EKS Auto Mode의 오토스케일 동작을 확인해 보았으면 반드시 실습 자원을 삭제하여 줍니다.

kubectl delete deployment inflate && kubectl get events -w --sort-by '.lastTimestamp'

데모 애플리케이션 자원을 삭제하자 다음과 같은 순서로 auto scale이 작동하는 것을 확인할 수 있습니다.

Deployment 삭제 → 노드 스케줄러 작동 → Over provisioning 확인 → Consolidation 작동 → 적절한 크기의 노드 생성 → 해당 노드로 파드 이동 → 기존 노드 종료

EKS Auto Mode Network

Graviton Workloads 를 사용하여 2048 game을 배포 하는 실습을 해봅니다. 네트워크 특징으로는 ingress(ALB)를 사용하고, *arm cpu 아키텍처 사용을 위해 custom nodeclass/pool 을 사용합니다.

* general-purpose 노드 클래스의 경우에는 arm cpu 계열을 지원하지 않기 때문

해당 custom node pool은 소스코드에 정의 되어있습니다.

ls ../nodepools
cat ../nodepools/graviton-nodepool.yaml

Node pool 생성

해당 Nodepool을 생성합니다.

kubectl apply -f ../nodepools/graviton-nodepool.yaml

관련된 Nodeclass를 확인합니다.

kubectl get nodeclass

2048 게임 배포

이제 위에서 생성한 Node pool에서 실행될 파드들을 배포합니다.

ls ../examples/graviton
cat ../examples/graviton/game-2048.yaml

nodeSelector로 arm64 가 지정된 노드에만 배포되도록 파드 구성이 설정되어있습니다.

해당 Deployment를 배포합니다.

kubectl apply -f ../examples/graviton/game-2048.yaml

디플로이먼트를 배포하자 nodeclaim이 새로 생성된 것을 확인할 수 있습니다. 이는 arm64 를 사용하기 위한 custom nodepool 에서의 새로운 노드를 생성하기 위한 것 입니다.

파드가 새로 생성된 것을 확인 가능하고 적절한 노드에 스케줄링 하기 위해 대기 상태에 놓입니다.

⚠️ deployment, pod, nodeclaim 이 생성 안됨

실습을 진행하는 도중에 해당 리소스가 아무리 기다려도 생성이 안되고 kubectl logs 명령어를 사용하여도 어떠한 로그를 확인할 수 없었습니다.

노드클레임은 계속해서 Unknown 상태를 유지하였습니다.

✅ EC2 Spot service-linked-role 생성

kubectl get nodeclaims graviton-nodepool-mg852 -oyaml 명령어를 통해 살펴보자 다음과 같은 메세지가 출력되었습니다.

따라서 다음 명령어를 통해 ec2 spot의 서비스 링크드 역할을 생성하여 해결하였습니다.

aws iam create-service-linked-role --aws-service-name spot.amazonaws.com

이후 game-2048이 배포된 것을 확인 가능했습니다.

kubectl로 생성된 리소스를 확인합니다.

kubectl get deploy,pod -n game-2048 -owide

웹 콘솔에서도 확인해 봅니다.

해당 EC2는 AWS 에서 관리되고 있다는 것을 cloudtrail에서도 확인이 가능합니다.

ALB (Ingress) 배포

AWS EKS Auto Mode에서의 Ingress yaml 은 기존의 방식과 조금 차이가 있습니다.

cat ../examples/graviton/2048-ingress.yaml

EKS Auto Mode 에서 Ingress 생성의 방법은 다음과 같습니다.

  • SSL/TLS 및 VPC 서브넷에 사용할 인증서와 같은 AWS 특정 구성 값을 지정하는 IngressClassParams 리소스를 생성합니다.
  • IngressClass 리소스를 생성하여 EKS Auto Mode가 리소스의 컨트롤러가 되도록 지정합니다.
  • HTTP 경로와 포트를 클러스터 워크로드와 연결하는 Ingress 리소스를 생성합니다.
  • EKS 자동 모드는 IngressClassParams 리소스에 지정된 로드 밸런서 구성을 사용하여 Ingress 리소스에 지정된 워크로드를 가리키는 애플리케이션 로드 밸런서를 생성합니다.

※ 마이그레이션 미지원 되는 리소스

ALB 를 비롯하여 BlockStorage, Compute 리소스의 apiVersion 이 다른 부분에서 차이가 있으므로 마이그레이션 고려시 다음과 같은 사항을 반드시 확인하여야 합니다.

Capability
 
Resource
 
Field
 
Self Managed
 
EKS Auto Mode
Block Storage
 
StorageClass
 
provisioner
 
kubernetes.io/aws-ebs
 
ebs.csi.eks.amazonaws.com
Load Balancing
 
Service
 
loadBalancerClass
 
service.k8s.aws/nlb
 
eks.amazonaws.com/nlb
Load Balancing
 
IngressClass
 
controller
 
ingress.k8s.aws/alb
 
eks.amazonaws.com/alb
Load Balancing
 
IngressClassParams
 
apiversion
 
elbv2.k8s.aws/v1beta1
 
eks.amazonaws.com/v1
Load Balancing
 
TargetGroupBinding
 
apiversion
 
elbv2.k8s.aws/v1beta1
 
eks.amazonaws.com/v1
Compute
 
NodeClass
 
apiVersion
 
karpenter.sh/v1alpha5
 
eks.amazonaws.com/v1

따라서 마이그레이션을 하는 것보다는 신규로 생성하는 것이 정신건강에 좋을 것 같습니다.

Ingress 명세에 있어서 주요 차이점을 살펴봤습니다. 이제 해당 Ingress 를 배포합니다.

kubectl apply -f ../examples/graviton/2048-ingress.yaml

생성된 하위 리소스를 살펴봅니다.

kubectl get ingressclass,ingressclassparams,ingress,svc,ep -n game-2048

웹콘솔에서 리소스가 잘 생성되었는지 확인합니다.

이 때 리소스가 매핑은 잘 되었지만 Request timeout이 발생하는 것을 볼 수 있습니다. 본디 Ingress 생성 시 관련된 네트워크 설정(리스너, SG, 라우팅) 등이 자동으로 설정되어야 하지만 보안그룹 규칙이 생성되지 않아서 헬스체크에 실패한 것을 확인할 수 있습니다.

클러스터의 보안그룹에서 ALB 보안그룹의 인바운드를 허용하는 규칙을 추가해줍니다.

# Get security group IDs 
ALB_SG=$(aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[?contains(DNSName, `game2048`)].SecurityGroups[0]' \
  --output text)

EKS_SG=$(aws eks describe-cluster \
  --name automode-cluster \
  --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId' \
  --output text)

echo $ALB_SG **$EKS_SG** # 해당 보안그룹을 관리콘솔에서 정책 설정 먼저 확인해보자

# Allow ALB to communicate with EKS cluster : ***실습 환경 삭제 때, 미리 $EKS_SG에 추가된 규칙만 제거해둘것.***
aws ec2 **authorize-security-group-ingress** \
  --group-id $EKS_SG \
  --**source-group** $ALB_SG \
  --protocol tcp \
  --port 80

# 아래 웹 주소로 http 접속!
**kubectl get ingress ingress-2048 \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' \
  -n game-2048**
*k8s-game2048-ingress2-db993ba6ac-782663732.ap-northeast-2.elb.amazonaws.com*

해당 룰을 추가하자 정상적으로 통신이 되는 것을 확인할 수 있습니다.

이제 해당 ALB의 퍼블릭 도메인을 통해 접근하면 다음과 같이 게임 실행화면이 나타납니다.

실습 자원 삭제하기

❗반드시 위에서 추가한 보안그룹 규칙 먼저 제거 후에 delete를 실행하여 줍니다. 전체 실습완료 후 테라폼 destroy 명령 실행 시 위 리소스를 인식하지 못해 자원 삭제에 실패하기 때문입니다.

Ingress, svc, deployment 순으로 리소스를 삭제해줍니다.

# Remove application components
kubectl delete **ingress** -n game-2048 ingress-2048 ***# 먼저 $EKS_SG에 추가된 규칙만 제거할것!!!***
kubectl delete **svc** -n game-2048 service-2048
kubectl delete **deploy** -n game-2048 deployment-2048

# 생성된 노드가 삭제 후에 노드 풀 제거 할 것 : Remove Graviton node pool
**kubectl delete -f ../nodepools/graviton-nodepool.yaml**

EKS Auto Mode EBS(Storage)

EKS Auto Mode는 사용자를 위해 StorageClass를 생성하지 않습니다.

EKS Auto Mode의 스토리지 기능을 사용하려면, 반드시 ebs.csi.eks.amazonaws.com을 참조하는 StorageClass를 생성해야 합니

EKS Auto Mode에서는 EBS Controller는 기본적으로 설치가 되어있습니다. 별도의 설치 구성및 과정이 필요없습니다. 단순히 Storage class와 pvc 생성을 통해 ebs를 바인딩할 수 있습니다.

스토리지 클래스 생성

cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: auto-ebs-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com  # Uses EKS Auto Mode
volumeBindingMode: WaitForFirstConsumer  # Delays volume creation until a pod needs it
parameters:
  type: gp3
  encrypted: "true" 
EOF
  • 프로비저너 EKS AutoMode 전용의 프로비저너를 지정해주어야 합니다.

PVC 생성

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: auto-ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: auto-ebs-sc
  resources:
    requests:
      storage: 8Gi
EOF

애플리케이션 생성

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-stateful
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inflate-stateful
  template:
    metadata:
      labels:
        app: inflate-stateful
    spec:
      terminationGracePeriodSeconds: 0
      nodeSelector:
        eks.amazonaws.com/compute-type: auto
      containers:
        - name: bash
          image: public.ecr.aws/docker/library/bash:4.4
          command: ["/usr/local/bin/bash"]
          args: ["-c", "while true; do echo \$(date -u) >> /data/out.txt; sleep 60; done"]
          resources:
            requests:
              cpu: "1"
          volumeMounts:
            - name: persistent-storage
              mountPath: /data
      volumes:
        - name: persistent-storage
          persistentVolumeClaim:
            claimName: auto-ebs-claim
EOF
  • Deployment는 지속적 볼륨에 타임스탬프를 기록하는 컨테이너를 실행합니다.
  • 파일에 타임스탬프를 기록하는 간단한 bash 컨테이너 입니다.
  • PVC를 /data에 마운트합니다.
  • 1개의 CPU 코어를 요청합니다.
  • EKS 관리 노드를 위한 노드 셀렉터를 사용합니다.

볼륨 확인

애플리케이션 배포와 함께 PV가 새로 생성된 것을 확인할 수 있습니다.

해당 볼륨은 웹콘솔 볼륨 메뉴에서 확인할 수 있습니다.

아래 명령어를 통해 터미널에서 PV 상세정보를 확인합니다.

PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
## Describe the EBS volume
aws ec2 describe-volumes \
  --filters Name=tag:CSIVolumeName,Values=${PV_NAME}

애플리케이션이 PV에 데이터를 저장하고 있는 지 확인합니다.

kubectl exec "$(kubectl get pods -l app=inflate-stateful \
  -o=jsonpath='{.items[0].metadata.name}')" -- \
  cat /data/out.txt

실습 자원 삭제하기

다음 명령어를 실행하여 실습자원을 한번에 삭제합니다.

**kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc**

EKS Auto Mode 운영 해보기

노드 콘솔 출력 정보 확인

EKS Auto Mode는 노드에 직접적으로 접근하는 것이 불가하기 때문에 다양한 방법을 통해 노드의 상태를 살펴보아야 합니다.

이 때 한가지 방법으로, awscli 명령어를 사용하여 노드의 콘솔로그를 확인할 수 있습니다.

get-console-output 명령어 실행

kubectl get node
NODEID=<각자 자신의 노드ID>
NODEID=i-0b12733f9b75cd835

# Use the EC2 instance ID to retrieve the console output.
**aws ec2 get-console-output --instance-id $**NODEID **--latest --output text**

위와 같이 EC2 콘솔로그 및 커널 로그가 출력이 되지만 사실 이것만 가지고는 운영 시 노드를 관리하고 장애에 대응하기에는 턱없이 부족한 정보입니다.

노드 특정 프로세스 로그 실시간 확인

get-console-output 으로는 분석할 수 있는 정보가 너무 모자랍니다. 따라서 노드에 디버그용 컨테이너를 따로 사이드카 처럼 띄워서 프로세스로그를 실시간으로 확인할 수 있도록 하는 방법을 사용합니다.

이러한 디버그 컨테이너를 kubectl debug node라는 명령어를 사용하여 쉽게 접근할 수 있도록 EKS Auto Mode 에서 기능을 지원해 줍니다.

# 노드 인스턴스 ID 확인
kubectl get node
NODEID=<각자 자신의 노드ID>
NODEID=i-0b12733f9b75cd835

# 디버그 컨테이너를 실행합니다. 다음 명령어는 노드의 인스턴스 ID에 i-01234567890123456을 사용하며, 
# 대화형 사용을 위해 tty와 stdin을 할당하고 kubeconfig 파일의 sysadmin 프로필을 사용합니다.
## Create an interactive debugging session on a node and immediately attach to it.
## The container will **run** in the **host namespaces** and the **host's filesystem** will be mounted at **/host**
## --**profile**='legacy': Options are "legacy", "general", "baseline", "netadmin", "restricted" or "**sysadmin**"
kubectl **debug -h**
kubectl **debug node**/$NODEID -it **--profile=sysadmin** --image=public.ecr.aws/amazonlinux/**amazonlinux:2023**
-------------------------------------------------
**bash-5.2# whoami**

이는 실제로 debug 파드를 하나 띄위서 파드의 쉘에 진입하도록 하는 과정이 생략되어 있습니다.

kube-ops-viewer를 살펴보면 실제 디버그파드가 생성된 것을 확인할 수 있습니다.

쉘에서 이제 nsenter 명령을 제공하는 util-linux-core를 설치할 수 있습니다.
nsenter를 사용하여 호스트에서 PID 1의 마운트 네임스페이스(init)를 입력하고 journalctl 명령을 실행하여 큐블릿에서 로그를 스트리밍합니다:

yum install -y util-linux-core htop
nsenter -t 1 -m journalctl -f -u kubelet

해당 파드는 호스트 네임스페이스를 공유하기 때문에 이와같은 명령어가 가능합니다. 이는 kubelet 데몬의 로그를 실시간으로 출력하도록 합니다.

또한 htop 명령어를 사용해봅니다.

htop # 해당 노드(인스턴스) CPU,Memory 크기 확인

 

이외에 다양한 호스트(노드)의 정보를 nsenter 명령어를 통해 조회해봅니다.

nsenter -t 1 -m ip addr
nsenter -t 1 -m ps -ef
nsenter -t 1 -m ls -l /proc
nsenter -t 1 -m df -hT

 

nsenter ctr 명령어를 통해 컨테이너 정보를 조회합니다.

nsenter -t 1 -m ctr
nsenter -t 1 -m ctr ns ls
nsenter -t 1 -m ctr -n k8s.io containers ls

현재 실행중인 kube-ops-viewer 컨테이너와 디버그 컨테이너가 실행되고 있는 것을 확인 가능합니다.

디버그 컨테이너를 삭제합니다.

kubectl delete pod <node-debugger-#>

 

호스트 네임스페이스를 공유하는 파드 탈옥(?) 를 통해 호스트 정보 획득 시도 - Blog

get-console-output 명령어, 디버그 컨테이너 를 통해서도 모자란 갈증을 파드 탈옥을 통해 노드 접근을 해소해봅니다. 하지만 이 방법은 언제 막힐지 모르겠습니다. 또한 chroot로 호스트 루트 권한 탈취까지는 되지 않습니다.

호스트 네임스페이스를 공유하는 파드 실행

kubectl apply -f - <<EOF
apiVersion: v1
kind: **Pod**
metadata:
  name: **root-shell**
  namespace: kube-system
spec:
  containers:
  - command:
    - /bin/cat
    image: **alpine:3**
    name: root-shell
    **securityContext:
      privileged: true**
    tty: true
    stdin: true
    volumeMounts:
    - mountPath: /host
      name: hostroot
  **hostNetwork: true
  hostPID: true
  hostIPC: true**
  tolerations:
  - effect: NoSchedule
    operator: Exists
  - effect: NoExecute
    operator: Exists
  **volumes:
  - hostPath:
      path: /
    name: hostroot**
EOF

해당 파드를 확인합니다.

kubectl get pod -n kube-system root-shell
kubectl get node,pod -A -owide

 

/host 경로에 rw로 마운트 되었는지 확인해봅니다.

kubectl describe pod -n kube-system root-shell

 

파드 내 shell 진입 후 확인

위에서 생성한 root-shell 파드에 진입하여 (exec --sh) 여러 정보를 조회해봅니다.

kubectl -n kube-system exec -it root-shell -- sh
------------------------------------------------
whoami
pwd

# 네트워크 정보 확인 : 호스트와 같다 (**hostNetwork: true**)
ip link
ip addr # eth0, pod-id-link0, coredns

netstat -tnlp
netstat -unlp

# 프로세스 정보 확인 : 호스트와 같다 (**hostPID: true**)
top -d 1

ps aux
ps -ef

pstree
pstree -p

apk add htop
htop

 

host 파일시스템을 직접 조회해봅니다.

# 마운트 정보 : 데이터 EBS (80GiB)
df -hT | grep -v host
Filesystem           Type            Size      Used Available Use% Mounted on
overlay              overlay        **79.9G**      1.9G     78.0G   2% /
...

df -hT | grep host
/dev/root            ext4            2.1G      1.1G    901.5M  55% /host
...

cat /etc/hostname

 

호스트패스 : 파드에 /host 경로에 rw로 마운트 확인

ls -l /host 
cat /host/usr/share/kube-proxy/kube-proxy-config
cat /host/etc/coredns/Corefile
cat /host/etc/kubernetes/ipamd/kubeconfig
cat /host/etc/kubernetes/eks-node-monitoring-agent/kubeconfig

 

❗루트볼륨에 파일 생성은 실패합니다.

echo "hello" > /host/home/1.txt

이는 아무리 해당 파드가 r/w 로 마운트되었다고 하더라도 대상 파일시스템은 read-only 이기때문에 탈취는 불가능합니다.

 

자원 삭제하기

kubectl delete pod -n kube-system root-shell

 

노드 로그 수집 by S3 : Node monitoring agent  (NodeDiagnostic)

  • EKS 자동 모드에는 Amazon EKS 노드 모니터링 에이전트가 포함되어 있습니다.
  • 이 에이전트를 사용하여 노드에 대한 문제 해결 및 디버깅 정보를 볼 수 있습니다.
  • 노드 모니터링 에이전트는 Kubernetes 이벤트와 노드 상태를 게시합니다.
  • 자세한 내용은 노드 자동 복구 활성화 및 노드 상태 조사를 참조하십시오 - Docs
  • NodeDiagnostic리소스를 사용하여 노드 모니터링 에이전트를 사용하여 노드 로그를 검색합니다.

전체 과정: nodeDiagnostic을 이용하여 노드 로그를 버킷에 전송합니다.

 

s3 생성

BUCKETNAME=josh-aews-study
aws s3api create-bucket --bucket $BUCKETNAME --create-bucket-configuration LocationConstraint=ap-northeast-2 --region ap-northeast-2
aws s3 ls

 

S3 pre-sign url 생성

nodeDiagnostic이 s3에 노드로그를 업로드 하기위해서는 일회용 s3 url인 S3 pre-sign url 을 필요로 합니다.

해당 url은 sdk 혹은 aws api 를 통해서만 생성이 되기 때문에 관련 작업 환경이 구성되어있는 클라우드쉘에서 생성해봅니다.

클라우드 쉘을 활성화 합니다.

 

presign-upload.py 파일 예시

import boto3; print(boto3.client('s3').generate_presigned_url(
   ClientMethod='put_object',
   Params={'Bucket': '<bucket-name>', 'Key': '<key>'},
   ExpiresIn=10000
))

Params 항목에 각자 버킷과 키를 지정하여 줍니다.

 

presign-upload.py 파일 작성

cat << EOF > **presign-upload.py**
import boto3; print(boto3.client('s3').generate_presigned_url(
   ClientMethod='put_object',
   Params={'Bucket': '**josh-aews-study**', 'Key': '**2025-03-22/logs1.tar.gz**'},
   ExpiresIn=1000
))
EOF
**cat presign-upload.py**

 

presign url 생성 (파이썬 파일 실행)

python presign-upload.py

 

다시 로컬 터미널로 돌아옵니다. 커스텀리소스를 조회해보면 diagonstic이 생성되어있는 것을 확인할 수 있습니다.

kubectl get crd

여기에 이제 로그를 조회할 노드 정보를 추가해 주어야 합니다. node ec2 id 를 조회하여 아래 코드에 대체합니다.

 

logCapture destination에 위에서 생성한 presign url을 입력하여 줍니다.

cat <<EOF | kubectl apply -f -
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
  name: i-05baaa5f583d399c1
spec:
  logCapture:
    destination: https://josh-aews-study.s3.amazonaws.com/2025-03-22/logs1.tar.gz?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIA4WXKK5RUJFO3ITFY%2F20250323%2Fap-northeast-2%2Fs3%2Faws4_request&X-Amz-Date=20250323T000951Z&X-Amz-Expires=100000&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEHAaDmFwLW5vcnRoZWFzdC0yIkgwRgIhAIq9FYPe3j%2FUuzhGMph5a4PbT%2BtaSHyz0Orp08b2jfRvAiEAxnbHsRZlB7AeMOntjouyN5X0AJXeCdkZK%2FMhtMA%2BeRAqoAMIyf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARACGgw4NzM0NDM1NTIzNjAiDACApJYtmH9uErnR0yr0AkefldmGvKQuzJpU7xPXMH82VVEBRK23W7rIjRp0atiWPf8yDYrbkWnN5TcCPx31TBVV44KUvlATFDPRDeNMefzCUCHOfU9TwGnklt6byDIOhQIRoYNlAX0TKf3yxe6a8ITK1FpqPy3ehTyQSg8O%2BYFB3jwW%2FgeSH1UwyGHtIzVQp3lIUIEN0zAKtAfBShvSxMIiJyFGdlMtsehxYqD7n4oMFM%2BYHf9Q4PW8eFSGQ9WQ%2Fe0c%2FrF7wNb1CFJWQDypBVeHYi64nEyQQAA3v4dUXGKmJP2RzSnLvR2hT4aIPuL1qmNASHLtFs3MxHFrCQMWJjsZrDdl8e9EA9kJzvK6%2FCOW5t0QUihT8ppBR2YeN4hIm56kImmnneH8cErRL5oCOXarKxV%2FMvbYrMQdcLuQQWFT%2BKZpWP%2Fetbsc03N5RPlq1%2BH%2BWbXweHvk7h5dB0hZHB8PxlUtDBl6RMSuRMYG8KSeCJX9VY6bg8Cup39D%2FIQAJGAhwTC8mfu%2BBjqyAtEcz0TeSma%2FFThyZQGdeBc4B3AhYXOIGyiQNVCcxhxyowayEOgsG%2BA3iDRB%2B3RsHNNlyCl1ohbvYPw3gi9RDsCJLO7I%2Ba0yt%2FkrMrwtadSc%2BApeezDWA2kO31ij9Cmj81z%2B5nN7nGknz6z1A0HmwAyNFy3pVM31jNQ%2BymcMBMjaGHaehVGVdscLPxkg1xjnsVeN3X09W6x46l7rtfmTHeVwTJfj7CwwVCAjQr%2F%2FMRsIbcAODxW965cqHfHEq9I5G2DP%2FaIHCk2h8AZXRxgZ%2FxkUYlBwuoQYe4wfIxcY%2BS0zv6KvXM36gP7HOfUdPN6l0ZipMcq5jNyEttFUPZeEDoo5gRkiyNwPep6Wdz%2BYavdLM1VHqzy2I%2FZuh%2BIfWS570p36XjY8A98zCHmvFAeNEp8K6w%3D%3D&X-Amz-Signature=2a4a150f198333391f31673daafc0f871f6ee90ef85a5a544d365800d746f0fd
EOF

 

생성된 nodediagonistc을 확인합니다.

kubectl get nodediagnostic
kubectl describe nodediagnostic

nodediagnostic 상태메시지가 다음과 같이 출력이 됩니다. fatal error during log upload process. 이에 대한 자세한 이유는 아직까지 찾지 못했습니다. 혹시 해결한 분이 계시다면 공유해주시면 감사하겠습니다.

또한 다음 클래스메소드 포스팅을 참조 바랍니다. 🔗

만일 성공 시 지정한 버킷으로 해당 로그가 업로드 되고 로그는 압축파일로 저장되는데 저장된 로그 파일은 다음과 같다고 합니다.

% tree .
.
├── bottlerocket
│   └── application-inventory.json
├── cni
│   └── 10-aws.conflist
├── containerd
│   ├── containerd-config.txt
│   ├── containerd-containers.txt
│   ├── containerd-images.txt
│   ├── containerd-log.txt
│   ├── containerd-namespaces.txt
│   ├── containerd-plugins.txt
│   ├── containerd-tasks.txt
│   └── containerd-version.txt
├── ipamd
│   ├── ipam.json
│   └── metrics.json
├── kernel
│   ├── dmesg.current
│   ├── dmesg.human.current
│   └── uname.txt
├── kubelet
│   ├── config.json
│   ├── kubeconfig.yaml
│   ├── kubelet.log
│   └── kubelet_service.txt
├── log-capture-errors.log
├── networking
│   ├── configure-multicard-interfaces.txt
│   ├── conntrack.txt
│   ├── conntrack6.txt
│   ├── ethtool.txt
│   ├── get_api_server.txt
│   ├── ip6route.txt
│   ├── ip6rule.txt
│   ├── ip6tables-filter.txt
│   ├── ip6tables-mangle.txt
│   ├── ip6tables-nat.txt
│   ├── ip6tables-save.txt
│   ├── ip6tables.txt
│   ├── iproute.txt
│   ├── iprule.txt
│   ├── iptables-filter.txt
│   ├── iptables-mangle.txt
│   ├── iptables-nat.txt
│   ├── iptables-save.txt
│   ├── iptables.txt
│   └── resolv.conf
├── nodeadm
│   ├── nodeadm-config.log
│   └── nodeadm-run.log
├── sandbox-image
│   └── sandbox-image-log.txt
├── storage
│   ├── inodes.txt
│   ├── lsblk.txt
│   ├── mounts.txt
│   ├── pod_local_storage.txt
│   └── xfs.txt
├── sysctls
│   └── sysctl_all.txt
├── system
│   ├── allprocstat.txt
│   ├── availability-zone.txt
│   ├── cpu_throttling.txt
│   ├── instance-id.txt
│   ├── io_throttling.txt
│   ├── procstat.txt
│   ├── ps-threads.txt
│   ├── ps.txt
│   ├── region.txt
│   ├── services.txt
│   └── top.txt
└── var_log
    └── aws-routed-eni
        ├── ebpf-sdk.log
        ├── ipamd.log
        ├── network-policy-agent.log
        └── plugin.log

15 directories, 64 files

'AWS > EKS' 카테고리의 다른 글

K8S 환경에서 CI/CD 구축하기 - 2  (0) 2025.03.30
K8S 환경에서 CI/CD 구축하기 - 1  (5) 2025.03.30
EKS Security - OPA 로 정책 적용하기  (0) 2025.03.16
EKS Security - ECR Enhanced Scanning  (0) 2025.03.16
EKS Autoscaling - 3 (Karpenter)  (0) 2025.03.09
'AWS/EKS' Related Articles more