애드온
    2025년 3월 31일 AWS 블로그에 “Amazon EKS, 새로운 커뮤니티 애드온 카탈로그 도입” 이라는 글이 게시되었습니다. 이제 AWS EKS에서 새로운 커뮤니티 애드온 카탈로그로 metrics-server, kube-state-metrics, cert-manager, prometheus-node-exporter, external-dns를 제공하며 사용자는 오픈소스 애드온을 손쉽게 찾고, 선택하고, 구성하고, 관리할 수 있게 됩니다.
Kubernetes 클러스터를 운영할 때 Prometheus, metric-server, CNI 등 다양한 운영 도구를 사용해본 경험이 있으실 겁니다. AWS는 이러한 소프트웨어를 사용자가 손쉽게 구성할 수 있도록 애드온을 제공하고 있습니다. 현재 애드온의 종류는 목적에 따라 크게 세 가지로 분류 됩니다.
AWS에서 직접 관리하고 유지보수하는 공식 애드온입니다. 안정성과 보안 업데이트가 자동으로 제공되며, AWS CLI 또는 콘솔에서 쉽게 설치 및 버전 관리가 가능합니다.
인기 있는 커뮤니티 애드온을 기본 AWS 관리를 통해 통합하여 클러스터 운영을 간소화하고, 사용자가 Amazon EKS 콘솔 , AWS 소프트웨어 개발 키트(SDK) , AWS 명령줄 인터페이스(AWS CLI) 또는 AWS CloudFormation과 같은 IaC(Infrastructure as Code) 도구를 사용하여 클러스터에 직접 설치할 수 있는 애드온 입니다.
AWS Marketplace에 등록된 상용 소프트웨어 기반 애드온입니다. 서드파티 기업이 제공하며, 라이선스 기반으로 운영되는 경우가 많습니다. 보안, 운영 자동화, APM 등 기업 수준의 기능 제공에 강점이 있습니다.
AWS EKS 콜솔 에서는 EKS > 클러스터 > 추가기능 탭에서 [추가 기능 가져오기]를 통해 커뮤니티 애드온을 설치할 수 있습니다.

그림 1과 같이 커뮤니티 추가 기능 부분에서 설치를 희망하는 애드온을 선택하고 생성하면 EKS 클러스터에 해당 애드온을 설치할 수 있습니다. 그러나 일부 애드온은 IRSA 또는 Pod Identity를 구성하여 적절한 권한을 부여해야 할 필요가 있습니다. 자세한 내용은 아래 각 애드온 별 구성 방안을 참고해 주시기 바랍니다.
쿠버네티스 노드와 파드의 CPU 및 메모리 사용량을 수집합니다. 수평 파드 자동 확장(HPA) 및 "kubectl top" 명령어와 같은 기능을 지원합니다. 리소스 최적화 및 성능 모니터링에 필수적입니다.
아래 그림을 참고해 Metrics-Server(지표 서버)를 선택하여 애드온을 설치해 주세요.

Metrics-Server의 경우 별도 IRSA 또는 Pod Identity 구성 없이 설치 가능합니다.
해당 애드온이 성공적으로 설치되면 아래와 같이 kubectl get pod,svc -n kube-system 명령을 통해 관련 리소스들이 생성된 것을 확인할 수 있습니다.

또한 kubectl top node <node-name>, kubectl top pod <pod-name>과 같은 명령어로 노드 혹은 Pod의 리소스 사용량을 확인할 수 있게 되며, HPA를 구성할 경우 해당 메트릭을 참고하여 Scale-In, or out을 진행하게 됩니다.

deployment, node, pod 등 쿠버네티스 객체의 상태에 대한 메트릭을 생성합니다. 클러스터 상태 및 운영 상태에 대한 필수 관측 데이터를 제공합니다. 포괄적인 모니터링 솔루션, 용량 계획 및 클러스터 상태 변경 기반 알림에 사용됩니다. Amazon Managed Service for Prometheus 와 통합되어 확장 가능한 관리형 메트릭 저장 및 쿼리를 지원합니다.
아래 그림을 참고해 Kube State Metrics를 선택하여 애드온을 설치해 주세요. 별도 IRSA, Pod Identity의 설정은 필요하지 않습니다.

성공적으로 설치가 완료 되었다면 아래와 같이 kubectl get all -n kube-state-metrics 명령을 통해 관련 리소스들이 생성된 것을 확인할 수 있습니다.

위 사진과 같이 AWS 콘솔 상에서 커뮤니티 애드온을 추가했을 뿐인데 kube-state-metrics 관련 리소스들이 생성된 것을 확인할 수 있습니다.
앞서 설명 드린 바와 같이 kube-state-metrics는 deployment, node, pod 등 kubernetes의 객체에 대한 정보를 제공하는데요, 위 그림의 service/kube-state-metrics의 PORT로 보아 8080 포트로 서비스 중이고 공식 Github 레포를 가보면 HTTP Endpoint /metrics 를 통해 export 하고 있음을 알 수 있습니다.
kubectl port-forward -n kube-state-metrics svc/kube-state-metrics 8080:8080 명령을 통해 로컬 환경에서 kube-state-metrics 서비스에 접근할 수 있도록 구성합니다.


CPU, 메모리, 디스크, 네트워크 통계 등 기본 호스트 시스템에 대한 자세한 지표를 수집합니다. 포괄적인 클러스터 모니터링을 위한 기본 구성 요소로, 노드 성능 및 상태에 대한 심층적인 통찰력을 제공합니다. Amazon Managed Service for Prometheus를 사용하면 Prometheus 인프라를 관리하지 않고도 자동 스크래핑 및 장기 지표 보관을 구현할 수 있습니다.
아래 그림을 참고해 Prometheus-node-exporter를 선택하여 애드온을 설치해 주세요. 별도 IRSA, Pod Identity의 설정은 필요하지 않습니다.

성공적으로 설치가 완료 되었다면 아래와 같이 kubectl get all -n prometheus-node-exporter 명령을 통해 관련 리소스들이 생성된 것을 확인할 수 있습니다.

kube-state-metrics와 유사하게 kubectl port-forward -n prometheus-node-exporter svc/prometheus-node-exporter 9100:9100 명령을 통해 로컬에서 접근할 수 있도록 포트포워딩을 적용합니다.
웹 브라우저에서 http://localhost:9100/metrics URL에 접근합니다. 아래와 같이 데이터플레인 노드의 리소스 관련 메트릭을 확인할 수 있습니다.

노출된 쿠버네티스 서비스 및 인그레스를 외부 DNS 제공자와 동기화합니다. DNS 레코드 관리를 자동화하여 수동 DNS 구성을 제거합니다. 외부 애플리케이션의 서비스 검색 및 라우팅을 용이하게 하며, 이는 특히 동적 환경에서 유용합니다.
External-DNS 애드온을 사용해 EKS에서 편리하게 도메인과 인증서를 포함하여 Service(LoadBalancer)를 배포해 보도록 하겠습니다.
External-DNS의 경우 Route53을 사용할 예정으로, Public 유형의 호스팅 영역이 존재해야 합니다.
아래 그림을 참고해 커뮤니티 추가 기능에서 External DNS를 선택하고 [다음]을 클릭합니다.

External DNS 애드온은 Route53 레코드 업데이트를 수행해야 하므로 적절한 권한이 필요합니다. “추가 기능 액세스”에서 [권장 역할 생성] 클릭 후 AmazonRoute53FullAccess 정책을 사용하는 새로운 역할을 생성한 뒤 해당 역할을 사용하는 Pod Identity를 구성해 주세요.

정상적으로 배포가 완료되면 kubectl get pod -n external-dns 명령을 통해 해당 애드온이 정상 설치 됐는지 확인합니다.

다음으로 아래 Yaml을 배포해 Nginx 웹서비스를 구동합니다. 이 때 svc의 annotation을 사용하여 동적으로 Route53 레코드가 업데이트 되도록 합니다. (kubectl apply -f deploy.yaml)
# deploy.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    external-dns.alpha.kubernetes.io/hostname: web.nnnnnnn.wnut.co.kr
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  type: LoadBalancerRoute53 호스팅 영역을 확인해 보면 위 Yaml에서 지정한 external-dns.alpha.kubernetes.io/hostname: web.nnnnnn.wnut.co.kr 과 동일한 web.nnnnnn.wntu.co.kr 과 동일한 레코드가 생성되어 있는 모습을 확인할 수 있습니다.

실제로 http://web.nnnnnn.wnut.co.kr 에 접속 시 정상적으로 Nginx 기본 페이지가 조회되는 모습을 확인할 수 있습니다.

kubectl logs -n external-dns deployments/external-dns 를 통해 external-dns Pod에서 성공적으로 Route53에 레코드를 등록했음을 추가로 확인해볼 수 있습니다.

쿠버네티스 클러스터에서 TLS 인증서 관리 및 발급을 자동화합니다. 다양한 인증 기관과 통합되어 인증서 요청 및 해지를 처리합니다. 프로덕션 환경에서 안전한 통신을 유지하고 적절한 TLS 종료를 구현하는 데 필수적입니다.
Cert-manager + ingress nginx controller 조합으로 인증서를 적용한 웹 사이트 배포를 진행 하겠습니다. 우선 아래 그림을 참고해 커뮤니티 추가 기능에서 Cert-manager를 설치합니다.

kubectl get all -n cert-manager를 통해 관련 리소스들이 설치된 것을 확인할 수 있습니다.

공식 문서를 참고하며 Ingress Nginx를 구성합니다.
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.0/deploy/static/provider/cloud/deploy.yaml웹 서비스를 배포합니다. (kubectl apply -f application.yaml)
---
apiVersion: v1
kind: Namespace
metadata:
  name: sandbox
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  namespace: sandbox
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: sandbox
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: public.ecr.aws/nginx/nginx:latest
          ports:
            - name: tcp
              containerPort: 80ingress를 배포합니다. external-dns 사용을 위한 annotaion과, tls 사용을 위해 spec.tls.hosts 설정을 적용합니다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: sandbox
  annotations:
    external-dns.alpha.kubernetes.io/hostname: nginx.nnnnnn.wnut.co.kr
    cert-manager.io/issuer: nginx-issuer
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: nginx.nnnnnn.wntu.co.kr
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
            service:
              name: nginx-service
              port:
                number: 80
  tls:
    - hosts:
      - nginx.nnnnnn.wnut.co.kr
      secretName: nginx-app-tls-secret위와 같이 ingress 배포 시 cert-manager.io/issuer: nginx-issuer 를 적용했기에 관련 인증서 리소스(Certificate, Secret, CertificateRequest)가 생성되게 됩니다. 다음 단계로 생성된 인증서 리소스의 인증 과정을 위해 Issuer를 생성합니다.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: nginx-issuer
  namespace: sandbox
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: nnnnnnnnn@gmail.com
    privateKeySecretRef:
      name: nginx-app-private-key
    solvers:
      - http01:
          ingress:
            ingressClassName: nginxkubectl get order -A --watch 명령으로 Issuer 검증 과정을 확인합니다.

검증이 완료된 뒤 http://nginx.nnnnnn.wnut.co.kr 로 접근해 인증서가 적용된 웹 사이트로 접속 가능한지 확인 합니다.

Amazon EKS의 커뮤니티 애드온 기능은 사용자 친화적인 운영에 기여하고 있습니다. 기존에는 Helm 차트나 YAML 매니페스트를 통해 수동으로 구성해야 했던 다양한 오픈소스 컴포넌트를, 이제는 AWS 콘솔 또는 CLI를 통해 몇 번의 클릭만으로 설치하고 관리할 수 있게 되었습니다.
Announcing Amazon EKS community Add-ons catalog | Amazon Web Services
Amazon EKS, 새로운 커뮤니티 애드온 카탈로그 도입 - AWS
Amazon EKS 클러스터를 위한 cert-manager를 통한 인증서 발급 및 TLS 지원
