본문으로 건너뛰기

추론 준비 EKS 클러스터

추론 준비 EKS 클러스터는 AI/ML 추론 워크로드를 위해 특별히 설계된 사전 구성된 인프라 솔루션입니다. 이 솔루션은 AI on EKS inference charts 또는 자체 배포 및 모델을 사용하여 추론 서비스를 배포하고 실행하는 데 필요한 모든 구성 요소가 포함된 Kubernetes 클러스터를 제공합니다.

인프라에 대해 자세히 설명하는 확장된 Readme가 있습니다. 이 페이지에서는 이 아키텍처의 핵심 구성 요소와 이유를 강조합니다.

왜?​

이 추론 준비 EKS 클러스터는 여정의 어느 단계에 있든 누구나 추론을 위해 EKS를 사용할 수 있도록 만들어졌습니다. LLM은 배포하기 어려울 수 있습니다: 모델 크기, 아키텍처, 기능 및 요구 사항에 따라 모델을 적절히 배포, 실행 및 확장하기 위해 다양한 도구가 필요합니다. 또한 텍스트 -> 이미지 확산 모델이나 더 전통적인 머신 러닝 모델과 같이 LLM만이 아닌 모델을 실행하고 싶을 수도 있습니다.

이 인프라는 첫 번째 지원 계층입니다. 이 리포지토리에서 찾을 수 있는 Inference Charts 및 가이던스와 함께 AI on EKS는 원하는 추론을 실행할 수 있는 모든 도구와 지식을 갖추도록 목표로 합니다.

사용 사례​

  • 단일 모델 테스트: 모델을 배포하고 테스트하여 무엇을 하는지 또는 얼마나 잘 수행하는지 확인하고 싶은 경우.
  • 다중 노드 분산 추론: 모델이 너무 커서 단일 노드에 맞지 않는 경우.
  • 모델 오토스케일링: 들어오는 요청과 큐 길이에 따라 실행 중인 모델 수를 동적으로 조정해야 하는 경우.
  • 모델 벤치마킹: 다양한 트래픽 패턴으로 주어진 데이터셋에서 모델이 어떻게 수행되는지 이해하고 싶은 경우. 이를 통해 서비스 수준 목표(SLO)를 충족하도록 모델 파라미터와 복제본을 조정할 수 있습니다.
  • 다중 모델 아키텍처: LLM과 텍스트->이미지 확산 모델을 모두 테스트하고 싶은 경우.

소개​

이 인프라는 다음과 같은 주요 기능을 갖춘 AI/ML 추론 워크로드에 최적화된 Amazon EKS 클러스터를 생성합니다:

  • KubeRay Operator: 확장 가능한 추론을 위한 분산 Ray 워크로드 활성화
  • LeaderWorkerSet: 다중 노드 분산 추론 활성화
  • AIBrix 스택: 고급 추론 최적화 및 관리 기능
  • GPU/Neuron 지원: NVIDIA GPU 및 AWS Neuron(Inferentia/Trainium) 워크로드 모두 준비
  • AI/ML 관측성 스택: ML 워크로드를 위한 포괄적인 모니터링 및 관측성
  • 오토스케일링: 비용 최적화를 위한 Karpenter 기반 노드 오토스케일링

클러스터는 AI on EKS Inference Charts와 원활하게 작동하도록 특별히 설계되어 추론 워크로드 배포를 위한 완전한 엔드투엔드 솔루션을 제공합니다.

리소스​

이 인프라는 다음 AWS 리소스를 배포합니다:

핵심 인프라​

  • 여러 AZ에 걸쳐 퍼블릭 및 프라이빗 서브넷이 있는 Amazon VPC
  • Amazon EKS Cluster (기본적으로 v1.33)
  • EKS Managed Node Groups: EKS 컴퓨팅 노드로 사용되는 EC2 인스턴스의 오토 스케일링 그룹.
  • 프라이빗 서브넷 인터넷 액세스를 위한 NAT 게이트웨이
  • 퍼블릭 서브넷 액세스를 위한 인터넷 게이트웨이
  • 적절한 인그레스/이그레스 규칙이 있는 보안 그룹

EKS 애드온​

  • 인그레스 관리를 위한 AWS Load Balancer Controller
  • 영구 스토리지를 위한 EBS CSI Driver
  • 파드 네트워킹을 위한 VPC CNI
  • 서비스 검색을 위한 CoreDNS
  • 서비스 네트워킹을 위한 Kube-proxy
  • 리소스 메트릭을 위한 Metrics Server
  • 로깅 및 모니터링을 위한 Amazon CloudWatch Observability

AI/ML 관련 구성 요소​

  • 분산 Ray 워크로드를 위한 KubeRay Operator
  • 다중 노드 분산 추론을 위한 LeaderWorkerSet
  • GPU 리소스 관리를 위한 NVIDIA Device Plugin
  • Inferentia/Trainium 지원을 위한 AWS Neuron Device Plugin
  • 지능형 노드 오토스케일링을 위한 Karpenter

관측성 스택​

  • 메트릭 수집을 위한 Prometheus
  • 시각화 및 대시보드를 위한 Grafana
  • 알림을 위한 AlertManager
  • 노드 수준 메트릭을 위한 Node Exporter
  • GPU 메트릭을 위한 DCGM Exporter (GPU 노드가 있을 때)

AIBrix 구성 요소​

  • 추론 최적화를 위한 AIBrix Core
  • 트래픽 관리를 위한 게이트웨이 및 라우팅
  • 성능 모니터링 및 최적화 도구

배포​

아키텍처 다이어그램​

architecture

사전 요구 사항​

  1. 적절한 권한으로 구성된 AWS CLI
  2. Terraform (>= 1.0)
  3. 클러스터 관리를 위한 kubectl
  4. 차트 배포를 위한 Helm (>= 3.0)

0단계: 복제 및 이동​

git clone https://github.com/awslabs/ai-on-eks.git
cd infra/solutions/inference-ready-cluster

1단계: (선택 사항) 변수 구성​

배포를 사용자 지정하려면 terraform/blueprint.tfvars 파일을 편집합니다:

name                             = "my-inference-cluster"
region = "us-west-2"
enable_kuberay_operator = true
enable_ai_ml_observability_stack = true
enable_aibrix_stack = true
enable_leader_worker_set = true
availability_zones_count = 4

모든 변수는 variables.tf 파일에서 찾을 수 있습니다

2단계: 인프라 배포​

# 설치 스크립트 실행
./install.sh

설치 스크립트는 자동으로 다음을 수행합니다:

  1. 기본 Terraform 구성 복사
  2. Terraform 초기화
  3. 인프라 계획 및 적용
  4. kubectl 컨텍스트 구성

3단계: VPC​

지정된 구성에 따라 Amazon Virtual Private Network(VPC)가 프로비저닝되고 구성됩니다. 안정성에 대한 모범 사례에 따라 노드 획득 및 고가용성의 최상의 기회를 제공하기 위해 4개의 가용 영역(AZ)이 구성됩니다. 토폴로지 인식은 기본적으로 성능/비용을 위해 AI/ML 워크로드를 동일한 AZ에 유지하지만 가용성을 위해 구성할 수 있습니다.

4단계: EKS​

Amazon Elastic Kubernetes Service(EKS) 클러스터는 컴퓨팅 노드에서 중요한 클러스터 애드온(CoreDNS, AWS Load Balancer Controller 및 Karpenter)을 실행하는 Managed Nodes Group(MNG)으로 프로비저닝됩니다. Karpenter는 구성에 따라 가장 비용 효율적인 인스턴스를 우선시하면서 다른 EKS 애드온 및 사용자가 배포할 추론 애플리케이션에 대한 컴퓨팅 용량을 관리합니다.

5단계: EKS 애드온​

환경별 Terraform 구성 파일에 정의된 구성에 따라 다른 중요한 EKS 애드온(LWS, KubeRay 등)이 배포됩니다(위의 1단계 참조)

6단계: 관측성​

환경에서 메트릭과 로그를 수집하기 위해 FluentBit, Prometheus 및 Grafana를 포함한 관측성 스택이 배포됩니다. AI/ML 관련 워크로드를 모니터링하고 메트릭을 수집하기 위해 Service 및 Pod Monitor가 배포됩니다. Grafana 대시보드는 메트릭과 로그를 나란히 자동으로 시각화하도록 구성됩니다.

7단계: 클러스터 준비 완료​

사용자는 EKS API에 액세스하고 AWS Network Load Balancer(NLB) 엔드포인트와 상호 작용하여 Kubernetes CLI를 사용하여 AI on EKS inference charts 또는 다른 리포지토리를 통해 컨테이너화된 AI/ML 추론 워크로드를 배포할 수 있습니다.

8단계: 배포 확인​

모든 것이 제대로 배포되었는지 확인하려면 다음을 실행할 수 있습니다

kubectl get svc,pod,deployment -A

다음 출력이 표시되어야 합니다(섹션을 확장하여 출력 확인)

Details
    NAMESPACE              NAME                                                             TYPE           CLUSTER-IP       EXTERNAL-IP                                                                     PORT(S)                                        AGE
aibrix-system service/aibrix-controller-manager-metrics-service ClusterIP 172.20.218.39 <none> 8080/TCP 13d
aibrix-system service/aibrix-gateway-plugins ClusterIP 172.20.142.245 <none> 50052/TCP 13d
aibrix-system service/aibrix-gpu-optimizer ClusterIP 172.20.14.220 <none> 8080/TCP 13d
aibrix-system service/aibrix-kuberay-operator ClusterIP 172.20.240.255 <none> 8080/TCP 13d
aibrix-system service/aibrix-metadata-service ClusterIP 172.20.252.24 <none> 8090/TCP 13d
aibrix-system service/aibrix-redis-master ClusterIP 172.20.155.43 <none> 6379/TCP 13d
argocd service/argocd-applicationset-controller ClusterIP 172.20.139.94 <none> 7000/TCP 13d
argocd service/argocd-dex-server ClusterIP 172.20.127.60 <none> 5556/TCP,5557/TCP 13d
argocd service/argocd-redis ClusterIP 172.20.48.202 <none> 6379/TCP 13d
argocd service/argocd-repo-server ClusterIP 172.20.232.147 <none> 8081/TCP 13d
argocd service/argocd-server ClusterIP 172.20.233.191 <none> 80/TCP,443/TCP 13d
default service/etcd-client ClusterIP 172.20.47.224 <none> 2379/TCP 12d
default service/etcd-server ClusterIP 172.20.69.95 <none> 2379/TCP,2380/TCP 12d
default service/kubernetes ClusterIP 172.20.0.1 <none> 443/TCP 13d
envoy-gateway-system service/envoy-aibrix-system-aibrix-eg-903790dc ClusterIP 172.20.249.100 <none> 80/TCP 13d
envoy-gateway-system service/envoy-gateway ClusterIP 172.20.113.229 <none> 18000/TCP,18001/TCP,18002/TCP,19001/TCP 13d
ingress-nginx service/ingress-nginx-controller LoadBalancer 172.20.27.209 k8s-ingressn-ingressn-ffa534dcb1-b4b54bcc24eaeddd.elb.us-west-2.amazonaws.com 80:31646/TCP,443:32024/TCP 13d
ingress-nginx service/ingress-nginx-controller-admission ClusterIP 172.20.249.118 <none> 443/TCP 13d
karpenter service/karpenter ClusterIP 172.20.149.70 <none> 8080/TCP 13d
kube-system service/aws-load-balancer-webhook-service ClusterIP 172.20.83.104 <none> 443/TCP 13d
kube-system service/eks-extension-metrics-api ClusterIP 172.20.87.142 <none> 443/TCP 13d
kube-system service/k8s-neuron-scheduler ClusterIP 172.20.248.128 <none> 12345/TCP 13d
kube-system service/kube-dns ClusterIP 172.20.0.10 <none> 53/UDP,53/TCP,9153/TCP 13d
kube-system service/kube-prometheus-stack-kubelet ClusterIP None <none> 10250/TCP,10255/TCP,4194/TCP 13d
kuberay-operator service/kuberay-operator ClusterIP 172.20.117.159 <none> 8080/TCP 13d
lws-system service/lws-controller-manager-metrics-service ClusterIP 172.20.17.186 <none> 8443/TCP 13d
lws-system service/lws-webhook-service ClusterIP 172.20.173.201 <none> 443/TCP 13d
monitoring service/alertmanager-operated ClusterIP None <none> 9093/TCP,9094/TCP,9094/UDP 13d
monitoring service/dcgm-exporter ClusterIP 172.20.79.5 <none> 9400/TCP 13d
monitoring service/fluent-bit ClusterIP 172.20.111.213 <none> 2020/TCP 13d
monitoring service/kube-prometheus-stack-alertmanager ClusterIP 172.20.45.163 <none> 9093/TCP,8080/TCP 13d
monitoring service/kube-prometheus-stack-coredns ClusterIP None <none> 9153/TCP 13d
monitoring service/kube-prometheus-stack-grafana ClusterIP 172.20.251.144 <none> 80/TCP 13d
monitoring service/kube-prometheus-stack-kube-controller-manager ClusterIP None <none> 10257/TCP 13d
monitoring service/kube-prometheus-stack-kube-etcd ClusterIP None <none> 2381/TCP 13d
monitoring service/kube-prometheus-stack-kube-proxy ClusterIP None <none> 10249/TCP 13d
monitoring service/kube-prometheus-stack-kube-scheduler ClusterIP None <none> 10259/TCP 13d
monitoring service/kube-prometheus-stack-kube-state-metrics ClusterIP 172.20.81.57 <none> 8080/TCP 13d
monitoring service/kube-prometheus-stack-operator ClusterIP 172.20.163.90 <none> 443/TCP 13d
monitoring service/kube-prometheus-stack-prometheus ClusterIP 172.20.1.251 <none> 9090/TCP,8080/TCP 13d
monitoring service/kube-prometheus-stack-prometheus-node-exporter ClusterIP 172.20.88.160 <none> 9100/TCP 13d
monitoring service/my-cluster ClusterIP 172.20.54.44 <none> 9200/TCP,9300/TCP,9600/TCP,9650/TCP 13d
monitoring service/my-cluster-dashboards ClusterIP 172.20.161.35 <none> 5601/TCP 13d
monitoring service/my-cluster-masters ClusterIP None <none> 9200/TCP,9300/TCP 13d
monitoring service/opencost ClusterIP 172.20.162.78 <none> 9003/TCP,9090/TCP 13d
monitoring service/opensearch-discovery ClusterIP None <none> 9300/TCP 13d
monitoring service/opensearch-operator-controller-manager-metrics-service ClusterIP 172.20.183.236 <none> 8443/TCP 13d
monitoring service/prometheus-operated ClusterIP None <none> 9090/TCP 13d

NAMESPACE NAME READY STATUS RESTARTS AGE
aibrix-system pod/aibrix-controller-manager-5948f8f8b7-qjm7z 1/1 Running 0 13d
aibrix-system pod/aibrix-gateway-plugins-5978d98445-qj2jw 1/1 Running 0 13d
aibrix-system pod/aibrix-gpu-optimizer-64c978ddd8-bw7hk 1/1 Running 0 13d
aibrix-system pod/aibrix-kuberay-operator-8b65d7cc4-xrcm6 1/1 Running 0 13d
aibrix-system pod/aibrix-metadata-service-5499dc64b7-69tzc 1/1 Running 0 13d
aibrix-system pod/aibrix-redis-master-576767646c-w9lhl 1/1 Running 0 13d
...

EKS에서의 추론​

EKS는 AI/ML 추론을 실행하기 위한 강력한 플랫폼입니다. EKS에서의 많은 추론 가능성에 대한 자세한 내용은 추론 섹션을 확인하세요.

Inference Charts 통합​

이 인프라는 AI on EKS Inference Charts와 함께 작동하도록 특별히 설계되었습니다. 클러스터는 추론 워크로드의 원활한 배포를 위한 모든 필요한 구성 요소와 구성을 제공합니다.

Inference Charts 사전 요구 사항​

인프라는 자동으로 다음을 제공합니다:

  1. KubeRay Operator - Ray-vLLM 배포에 필요
  2. GPU/Neuron Device Plugins - 하드웨어 리소스 관리용
  3. 관측성 스택 - 모니터링을 위한 Prometheus 및 Grafana
  4. AIBrix 통합 - 추론 최적화 및 관리용

지원되는 추론 패턴​

클러스터는 inference charts에서 제공하는 모든 추론 패턴을 지원합니다:

vLLM 배포​
  • Kubernetes Deployment를 사용한 직접 vLLM 배포
  • 단일 노드 추론 워크로드에 적합
  • GPU 및 Neuron 가속기 모두 지원
Ray-vLLM 배포​
  • Ray Serve의 분산 vLLM
  • 워크로드 수요에 따른 자동 확장
  • Prometheus/Grafana 통합을 통한 고급 관측성
  • 최적의 성능을 위한 토폴로지 인식 스케줄링
AIBrix 배포​
  • AIBrix 지원 LLM 배포
  • 여러 복제본에 대한 효율적인 LLM 라우팅
  • 혼합 GPU 및 Neuron 가속기 지원

예제 배포​

클러스터가 준비되면 추론 워크로드를 배포할 수 있습니다:

# Hugging Face 토큰 시크릿 생성
kubectl create secret generic hf-token --from-literal=token=your_hf_token

# vLLM으로 GPU Qwen 3 1.7B 모델 배포
helm repo add ai-on-eks https://awslabs.github.io/ai-on-eks-charts/
helm repo update

helm install qwen3-1-7b ai-on-eks/inference-charts -f https://raw.githubusercontent.com/awslabs/ai-on-eks-charts/refs/heads/main/charts/inference-charts/values-qwen3-1.7b-vllm.yaml

사용 가능한 항목에 대한 자세한 내용은 inference charts 섹션을 확인하세요.

관측성 통합​

인프라는 추론 워크로드를 위한 포괄적인 관측성을 제공합니다:

  • Prometheus Metrics: 추론 메트릭의 자동 수집
  • Grafana Dashboards: Ray 및 vLLM용 사전 구성된 대시보드
  • Log Aggregation: Fluent Bit을 사용한 중앙 집중식 로깅
  • GPU/Neuron 모니터링: 하드웨어 사용률 메트릭

Grafana 대시보드 액세스:

kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

관측성 기능 사용에 대한 자세한 내용은 관측성을 참조하세요.

비용 최적화​

클러스터에는 여러 비용 최적화 기능이 포함되어 있습니다:

  1. Karpenter 오토스케일링: 자동 노드 프로비저닝 및 디프로비저닝
  2. 스팟 인스턴스 지원: 스팟 인스턴스를 사용하도록 노드 그룹 구성
  3. 토폴로지 인식: AZ 전반에 걸쳐 효율적인 리소스 활용
  4. 리소스 제한: 워크로드에 대한 적절한 리소스 요청 및 제한

문제 해결​

이 섹션에서는 추론 준비 EKS 클러스터를 배포하고 운영할 때 발생할 수 있는 일반적인 문제와 자세한 해결 방법 및 진단 단계를 다룹니다.

배포 문제​

1. Terraform Apply 실패​

증상:

  • terraform apply 중 리소스 생성 오류로 Terraform 실패
  • 순차 배포 중 모듈별 실패

일반적인 원인 및 해결 방법:

AWS 권한 부족:

# AWS 자격 증명 및 권한 확인
aws sts get-caller-identity
aws iam get-user

# 필요한 권한 포함:
# - EKS 클러스터 생성 및 관리
# - EC2 인스턴스 관리
# - VPC 및 네트워킹 리소스
# - IAM 역할 생성 및 연결
# - KMS 키 관리

서비스 할당량 제한:

# EC2 서비스 할당량 확인
aws service-quotas get-service-quota --service-code ec2 --quota-code L-1216C47A # Running On-Demand instances
aws service-quotas get-service-quota --service-code ec2 --quota-code L-34B43A08 # Running On-Demand G instances
aws service-quotas get-service-quota --service-code ec2 --quota-code L-6E869C2A # Running On-Demand Inf instances

# 필요한 경우 할당량 증가 요청
aws service-quotas request-service-quota-increase --service-code ec2 --quota-code L-34B43A08 --desired-value 32

리전 가용성:

# 리전에서 인스턴스 유형이 사용 가능한지 확인
aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=instance-type,Values=g5.xlarge,inf2.xlarge

2. EKS 클러스터 생성 문제​

증상:

  • EKS 클러스터 생성 실패 또는 "CREATING" 상태에서 멈춤
  • 노드 그룹이 클러스터에 조인 실패

진단 단계:

# 클러스터 상태 확인
aws eks describe-cluster --name inference-cluster --region us-west-2

일반적인 해결 방법:

  • VPC에 4개의 가용 영역에 걸쳐 충분한 IP 주소가 있는지 확인
  • 퍼블릭 서브넷에서 NAT 게이트웨이 생성 확인
  • 보안 그룹 구성이 필요한 EKS 통신을 허용하는지 확인

노드 및 파드 문제​

3. Pending 상태에서 멈춘 파드​

증상:

  • 추론 워크로드가 "Pending" 상태로 유지
  • Karpenter가 노드를 프로비저닝하지 않음

진단 명령:

# 파드 이벤트 및 리소스 요청 확인
kubectl describe pod <pod-name> -n <namespace>

# Karpenter 로그 확인
kubectl logs -n karpenter deployment/karpenter

# 사용 가능한 노드 및 용량 확인
kubectl get nodes -o wide
kubectl describe nodes

일반적인 원인 및 해결 방법:

GPU/Neuron 할당량 부족:

# Karpenter NodePool 구성 확인
kubectl get nodepool -o yaml

4. GPU 감지 및 Device Plugin 문제​

증상:

  • GPU 노드에 0개의 할당 가능한 GPU 표시
  • NVIDIA device plugin이 실행되지 않음

진단 단계:

# 노드에서 GPU 가시성 확인
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, gpus: .status.allocatable["nvidia.com/gpu"]}'

# 노드 레이블 확인
kubectl get nodes --show-labels | grep gpu

해결 방법:

# 필요한 경우 NVIDIA device plugin 재시작
kubectl delete pods -n nvidia-device-plugin -l app.kubernetes.io/name=nvidia-device-plugin

5. AWS Neuron 설정 문제​

증상:

  • inf2/trn1 인스턴스에서 Neuron 장치가 감지되지 않음
  • Neuron device plugin 실패

진단 명령:

# Neuron device plugin 확인
kubectl get pods -n kube-system | grep neuron

# Neuron 장치 확인
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, neuron: .status.allocatable["aws.amazon.com/neuron"]}'

# Neuron 스케줄러 확인
kubectl get pods -n kube-system | grep my-scheduler

해결 방법:

# Neuron 런타임 설치 확인
kubectl describe node <inf2-node> | grep neuron

# Neuron device plugin 로그 확인
kubectl logs -n kube-system <neuron-device-plugin-pod>

모델 배포 문제​

6. 모델 다운로드 실패​

증상:

  • 이미지 풀 또는 모델 다운로드 오류로 파드 시작 실패
  • Hugging Face 인증 실패

진단 단계:

# 다운로드 오류에 대한 파드 로그 확인
kubectl logs <pod-name> -n <namespace>

# Hugging Face 토큰 시크릿 확인
kubectl get secret hf-token -o yaml
kubectl get secret hf-token -o jsonpath='{.data.token}' | base64 -d

해결 방법:

# Hugging Face 토큰 시크릿 재생성
kubectl delete secret hf-token
kubectl create secret generic hf-token --from-literal=token=<your-hf-token>

# 파드에서 인터넷 연결 확인
kubectl run test-pod --image=curlimages/curl -it --rm -- curl -I https://huggingface.co

7. 메모리 부족(OOM) 문제​

증상:

  • OOMKilled 상태로 파드가 종료됨
  • 모델이 완전히 로드되지 않음

진단 명령:

# 파드 리소스 사용량 확인
kubectl top pods -n <namespace>

# 노드 메모리 사용량 확인
kubectl top nodes

# OOM 종료에 대한 파드 이벤트 검토
kubectl get events --field-selector reason=OOMKilling

해결 방법:

# 더 큰 GPU를 얻기 위해 인스턴스 유형 증가
# 더 큰 인스턴스 유형 또는 모델 샤딩 사용 고려

네트워킹 및 로드 밸런서 문제​

8. 서비스 연결 문제​

증상:

  • 추론 엔드포인트에 액세스할 수 없음
  • 로드 밸런서가 프로비저닝되지 않음

진단 단계:

# 서비스 상태 확인
kubectl get svc -A

# AWS Load Balancer Controller 확인
kubectl logs -n kube-system deployment/aws-load-balancer-controller

# 보안 그룹 및 NACL 확인
aws ec2 describe-security-groups --filters "Name=group-name,Values=*inference-cluster*"

해결 방법:

# AWS Load Balancer Controller 재시작
kubectl rollout restart deployment/aws-load-balancer-controller -n kube-system

# 인그레스 주석 및 구성 확인
kubectl describe ingress <ingress-name>

모니터링 및 관측성 문제​

9. Prometheus/Grafana 작동 안 함​

증상:

  • 모니터링 대시보드에 액세스할 수 없음
  • 메트릭이 수집되지 않음

진단 명령:

# 모니터링 스택 파드 확인
kubectl get pods -n monitoring

# Prometheus 대상 확인
kubectl port-forward -n monitoring svc/kube-prometheus-stack-prometheus 9090:9090
# http://localhost:9090/targets로 이동

# Grafana 액세스 확인
kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80
# http://localhost:3000으로 이동

해결 방법:

# 모니터링 구성 요소 재시작
kubectl rollout restart deployment/kube-prometheus-stack-grafana -n monitoring

# 서비스 모니터 확인
kubectl get servicemonitor -A

성능 및 확장 문제​

10. 느린 모델 추론​

증상:

  • 모델 응답에서 높은 지연 시간
  • 낮은 처리량 성능

진단 단계:

# 리소스 사용률 확인
kubectl top pods -n <namespace> --containers

# GPU 사용률 모니터링 (GPU를 사용하는 경우)
kubectl exec -it <pod-name> -- nvidia-smi

해결 방법:

  • 모델이 적절한 하드웨어 가속을 사용하고 있는지 확인
  • 여러 모델이 리소스를 놓고 경쟁하는지 확인
  • 지연 시간에 맞게 모델 파라미터 최적화
  • 모델을 확장하고 로드 밸런싱 사용

일반 디버깅 명령​

# 클러스터 정보 가져오기
kubectl cluster-info
kubectl get nodes -o wide

# 모든 시스템 파드 확인
kubectl get pods -A | grep -v Running

# 최근 이벤트 보기
kubectl get events --sort-by='.lastTimestamp' -A

# Karpenter 프로비저닝 확인
kubectl logs -n karpenter deployment/karpenter --tail=100

# EKS 애드온 확인
aws eks describe-addon --cluster-name inference-cluster --addon-name vpc-cni

추가 도움 받기​

문제가 계속되는 경우:

  1. AWS 서비스 상태 확인: AWS Service Health Dashboard 방문
  2. CloudWatch 로그 검토: CloudWatch에서 EKS 컨트롤 플레인 로그 확인
  3. 문서 참조: EKS 문제 해결 가이드 참조
  4. 커뮤니티 지원: AI on EKS GitHub Issues에 질문 게시