본문 바로가기
DevOps

[AEWS 4기] EKS 스터디 6주차 (EKS Upgrade )

국두리 2026. 4. 27. 17:08

header

title: "EKS 1.33 Amazon Linux 2023 (AL2023) AMI 변경에 대한 영향과 대응 방안"
date: 2026-04-27
tags: [EKS, AL2023, cgroup-v2, Kubernetes, AWS]

EKS 1.33부터 AL2 기반 AMI가 더 이상 제공되지 않는다. AL2023 / Bottlerocket으로 갈아타야 하는데, 단순한 OS 교체가 아니라 cgroup v2 전환이라는 큰 숙제가 따라온다. 메모리 OOM, CPU 스로틀링, 모니터링 도구 호환성, 부트스트랩 방식 변경까지 — 업그레이드 전에 반드시 확인해야 할 포인트를 정리한다.

들어가며

EKS 1.33부터는 Amazon Linux 2 (AL2) 기반 AMI가 더 이상 제공되지 않는다. 이제는 Amazon Linux 2023 (AL2023) 또는 Bottlerocket 기반 AMI를 사용해야만 한다.

문제는 AL2 → AL2023 전환이 단순히 OS만 바꾸는 게 아니라는 점. cgroup v2 전환, 부트스트랩 방식 변경, 모니터링 도구 호환성 등 운영에 직접 영향을 주는 변화들이 함께 들어온다.

이 글에서는 AL2023으로 마이그레이션할 때 실제로 부딪히는 이슈와, 사전에 어떤 부분을 검증해야 하는지를 정리한다.

1. OS 특징 비교 — AL2 vs AL2023

먼저 두 OS의 핵심 차이부터 짚고 가자.

특징/영역 Amazon Linux 2 (AL2) Amazon Linux 2023 (AL2023)
기반 배포판 CentOS 7 기반 (RHEL 7 호환) Fedora 기반 (최신 패키지, 짧은 릴리스 주기)
릴리스 주기 단일 장기 지원 릴리스 (2018년 출시, 2026년 6월 EOL) 2년마다 새 메이저 버전, 각 버전 5년 장기 지원
업데이트 관리 yum 통한 전통적 패키지 업데이트 버전별 리포지토리 잠금 (Deterministic Upgrades)
컨트롤 그룹 cgroup v1 (하이브리드/레거시) cgroup v2 (통합 계층, 기본 활성화)
컨테이너 런타임 Docker 지원 (1.24+ containerd 전환) Docker 미지원, containerd 기본
부트스트랩 방식 /etc/eks/bootstrap.sh 스크립트 nodeadm 기반 MIME 타입 User Data (YAML)
메타데이터 서비스 IMDSv1 / IMDSv2 모두 지원 IMDSv2 기본 필수
SELinux 기본 비활성화 permissive 모드 기본, enforcing 전환 용이
OpenSSL 1.x 3
Python 2.7 / 3 Python 3만 지원
기본 JVM OpenJDK Amazon Corretto
AWS CLI v1 v2
EBS 기본 볼륨 gp2 gp3
Live Patching 특정 커널 버전에서 지원 커널 Live Patching 기본 포함
EOL 2026년 6월 30일 각 메이저 버전 출시 후 5년

📌 주목할 변화

  • cgroup v1 → cgroup v2 (가장 큰 영향)
  • bootstrap.sh → nodeadm + YAML
  • IMDSv1 → IMDSv2 강제
  • Python 2 지원 종료, OpenSSL 3, AWS CLI v2 기본

2. cgroup v2 — 가장 큰 변수

AL2023이 cgroup v2를 기본으로 사용한다는 점이 이번 마이그레이션의 핵심 리스크다.

cgroup이 뭐였더라

cgroup(Control Groups)은 Linux 커널 기능 중 하나로, 프로세스를 그룹으로 묶어 CPU·메모리·I/O 등 자원 사용량을 제한하고 격리하는 메커니즘이다. Docker, Kubernetes 같은 컨테이너 기술의 기반이 되는 요소.

cgroup v1 vs cgroup v2

영역 cgroup v1 cgroup v2
계층 구조 분리된 계층 (Disjoint Hierarchies) — 각 서브시스템 독립적 단일 통합 계층 (Unified Hierarchy)
리소스 관리 각 컨트롤러가 독립적으로 작동 모든 컨트롤러가 단일 계층에서 협력
컨테이너 인식 제한적, 서브시스템별 상이 향상된 컨테이너 인식 — 메모리 보고 방식 변경
하위 그룹 위임 복잡, 제한적 더 안전하고 유연한 하위 트리 위임
메트릭 보고 서브시스템 파일별 개별 보고 memory.current, memory.stat 단일 파일 통합 보고 (페이지 캐시 포함)
호환성 레거시 시스템 광범위 지원 AL2023, Ubuntu 20.04+, RHEL 8+ 기본
주요 장점 광범위한 채택 정확한 리소스 제어, Pressure Stall Information 등 신기능

이 차이가 실제 워크로드에 어떤 영향을 미치는지가 진짜 문제다. 크게 세 가지로 나눠볼 수 있다.

3. 영향 ① 메모리 사용량 증가 및 OOM 발생 가능성

🚨 가장 빈번하게 보고되는 이슈

cgroup v1에서 잘 돌던 워크로드가 v2로 가면서 더 많은 메모리를 쓰는 것처럼 보고되거나, 실제로 더 많이 소비해서 OOMKilled로 Pod가 죽는 현상이 발생한다.
특히 .NET, 구버전 Java 같은 특정 런타임 기반 애플리케이션에서 빈번하게 보고됨.

왜 이런 일이 생기나

핵심은 메모리 보고 방식의 차이다.

  • cgroup v1: 페이지 캐시(file 메모리)가 컨테이너 메모리 한도에 덜 엄격하게 적용됨
  • cgroup v2: memory.stat에서 anon(익명 페이지)과 file(페이지 캐시 포함)을 더 통합적으로 보고 → 페이지 캐시가 컨테이너 메모리 사용량에 명확히 포함됨

❌ 결과

애플리케이션의 실제 메모리 사용량은 그대로인데, 보고되는 사용량이 증가하는 것처럼 보인다.
그러다 memory.limit에 더 빨리 도달 → OOM Killer가 컨테이너를 종료시킨다.

대응 방법 — 런타임 버전 확인

cgroup 파일 시스템을 직접 이용하는 애플리케이션은 cgroup v2를 지원하는 최신 버전으로 업그레이드해야 정상 동작한다.

런타임 cgroup v2 지원 최소 버전
OpenJDK / HotSpot jdk8u372, 11.0.16, 15 이상
IBM Semeru Runtimes 8.0.382.0, 11.0.20.0, 17.0.8.0
IBM Java 8.0.8.6 이상
Node.js 20.3.0 이상
.NET 5.0 이상

실제 고객 사례

❌ OpenJDK 11.0.8 사용 고객사 — EKS 1.32 → 1.33 업그레이드 후 발생한 일

  • 7월 15일 업그레이드 직후부터 메모리 사용량이 전체적으로 증가
  • 일부 Pod에서 지속적으로 OOMKilled 발생
  • 원인: OpenJDK 11.0.8은 cgroup v2 미지원 (11.0.16 이상 필요)

OpenJDK 11.0.16 미만 버전을 쓰고 있다면 반드시 업그레이드 필요. 업그레이드 전 개발/검증 환경에서 메모리 사용량 추이를 미리 확인하는 게 안전하다.

4. 영향 ② CPU 스로틀링 증가

cgroup v2는 CPU 리소스 관리 방식도 v1과 다르다. 이 때문에 기존에는 발생하지 않던 CPU 스로틀링이 발생해서 애플리케이션 성능이 저하될 수 있다.

💡 체크 포인트

  • container_cpu_cfs_throttled_seconds_total 메트릭으로 스로틀링 발생량 모니터링
  • CPU requests/limits 설정값 재검토 — v1 기준으로 빠듯하게 잡았다면 여유를 두는 방향으로 조정 검토
  • JVM의 경우 컨테이너 인식 옵션(-XX:+UseContainerSupport) 동작 차이 확인

5. 영향 ③ 모니터링 도구 호환성

cgroup v2는 리소스 통계 정보를 제공하는 방식이 다르다. 이 때문에:

  1. 기존 모니터링 도구(Prometheus, Grafana 등)가 cgroup v2 환경에서 데이터를 정확히 수집하지 못하거나, 추가 설정이 필요할 수 있다
  2. kubectl top node 결과도 다르게 보일 수 있다
  3. 구형 Metric Server는 cgroup v2의 새 인터페이스/포맷을 인식하지 못해 메트릭을 못 가져오거나 부정확하게 가져올 수 있다

⚠️ 반드시 확인할 것

  • Metrics Server — cgroup v2 지원 버전으로 업그레이드 (v0.6.x 이상)
  • Prometheus / cAdvisor — 최신 버전으로 업그레이드
  • node-exporter, kube-state-metrics 등도 함께 점검
  • 업그레이드 후 kubectl top 명령과 Grafana 대시보드 메트릭 정상 출력 여부 확인

6. 부트스트랩 방식 변경 — bootstrap.sh → nodeadm

AL2 시절엔 /etc/eks/bootstrap.sh 스크립트로 노드를 부트스트랩했다. AL2023에서는 nodeadm 기반의 MIME 타입 파일 형태 User Data를 사용한다.

즉, 기존 Launch Template을 업데이트해야 한다.

nodeadm User Data 예시

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: <YOUR_CLUSTER_NAME>                    # 예: my-eks-cluster
    apiServerEndpoint: <YOUR_API_SERVER_ENDPOINT> # 예: https://xxxx.eks.ap-northeast-2.amazonaws.com
    certificateAuthority: <YOUR_BASE64_ENCODED_CA> # 클러스터 CA (base64 인코딩)
    cidr: <YOUR_SERVICE_CIDR>                    # 예: 10.100.0.0/16 (서비스 CIDR)
  # 추가적인 kubelet 설정 등을 이곳에 추가
  # kubelet:
  #   extraArgs:
  #     '--kube-reserved=cpu=50m,memory=512Mi'
  #     '--system-reserved=cpu=50m,memory=512Mi'
  #   nodeLabels:
  #     'custom-label': 'true'
  #   nodeTaints:
  #     'app=test:NoSchedule'
--BOUNDARY--

💡 Tip

기존 bootstrap.sh에서 넘기던 --kubelet-extra-args 같은 옵션들은 위 YAML의 kubelet.extraArgs로 옮겨야 한다.
nodeLabels, nodeTaints도 YAML 선언적 형식으로 작성한다.

7. 결론 — 업그레이드 전 체크리스트

EKS 1.33 (AL2023 AMI) 업그레이드는 개발계, 검증계에서 충분한 테스트가 필요하다. 단순 버전 업그레이드가 아니라 OS 베이스가 바뀌는 변경이라는 점을 잊지 말 것.

📌 핵심 대응 사항 3가지

  1. 애플리케이션 런타임 버전 확인 — Java(11.0.16+), Node.js(20.3.0+), .NET(5.0+) 등 cgroup v2 호환 여부
  2. 모니터링 도구 버전 확인 — Metrics Server, Prometheus, cAdvisor 등 cgroup v2 호환 버전으로 업그레이드
  3. 시작 템플릿(Launch Template) User Data 변환 — bootstrap.sh → nodeadm YAML

🔥 S중공업 관점에서 추가 점검 포인트

  • 현재 운영 중인 노드/파드의 JVM 버전 일괄 인벤토리 확보 (구버전 Java 사용 워크로드 식별)
  • 메모리 request/limit 여유분 재산정 — v1 환경 기준으로 빠듯하게 잡혀있다면 OOM 위험
  • 검증계에서 24시간 이상 부하 테스트 후 메모리/CPU 추이 비교
  • 모니터링 도구 사이드카 / DaemonSet 호환성 확인

참고 문서

EKS 클러스터 버전 업그레이드 회고록 (v1.32 → v1.33)

목차

  1. 정보
  2. 사전 작업
  3. 본 작업
  4. 서비스 경과 확인
  5. 이벤트 내용 확인 방법
  6. 내부 보안 HIDS Agent 설치 (AL2023 신규 노드)

1. 정보

  • PVC, PV 존재 없음 → 관련 영향도 없음
  • PDB 사용 없음

2. 사전 작업

2.1 (Bonus) 사전 점검

클러스터 업그레이드 전 호환성 점검 도구로 kubent를 활용합니다.

설치

sh -c "$(curl -sSL https://git.io/install-kubent)"

주요 옵션 정리

옵션 설명 활용 포인트
-t, --target-version <ver> 타겟 Kubernetes 버전 명시 (예: 1.33.0) 업그레이드 대상 버전별 호환성 차이 확인
-c, --context <name> 특정 kubeconfig 컨텍스트 지정 멀티 클러스터 환경에서 dev/stg/prod 한꺼번에 점검
--kubeconfig <path> kubeconfig 파일 경로 지정 CI/CD 파이프라인이나 Bastion에서 여러 클러스터 검사 시 유용
-o, --output <json|yaml|wide> 출력 형식 지정 -
--ignore-regex <regex> 특정 리소스 무시 (네임스페이스/이름 정규식) kube-system/monitoring 같은 운영 리소스 제외
--skip-collectors <Cluster,Helm> Collector 스킵 Helm 차트가 많아 느릴 때 Helm Collector 스킵
--helm-release <name> 특정 Helm 릴리스만 검사 대규모 클러스터에서 특정 앱만 점검
--helm-ns <namespace> 특정 네임스페이스의 Helm 릴리스만 검사 앱별로 분리 배포 시 유용
--helm-version <version> Helm 버전 강제 지정 (기본 v3) 구버전 Helm 차트 환경
--no-headers 출력에서 테이블 헤더 숨김 JSON 파이프라인 처리 시 깔끔하게

사용 예시

kubent -t 1.33.0

2.2 보안 그룹 생성

기존 노드 그룹에서 사용하던 보안 그룹을 복제하여, 신규 시작 템플릿에서 사용할 보안 그룹을 생성합니다.

절차

  1. [VPC/EC2] → Security Groups 에서 기존 remoteAccess 보안 그룹 선택
  2. 우측 상단 Actions → Copy to new security group 클릭

Basic details

항목 값
Security group name eks-remoteAccess-al2023
Description eks-remoteAccess-al2023
VPC 기존 클러스터 VPC 선택
  • 기존 보안 그룹: eks-remoteAccess-<cluster-id> (원본 SG)
  • 복제된 보안 그룹: eks-remoteAccess-al2023 (신규 SG)

2.3 보안 그룹 참조 정보 변경

❗고객사에서 보안그룹을 업그레이드와 함께 통합하여 재생성 하는 요구사항이 있었습니다.
보안 그룹 규칙에서 Source/Destination에 보안 그룹을 참조하고 있으면, 해당 보안 그룹도 함께 확인이 필요합니다.

2.3.1 신규 보안 그룹 (eks-remoteAccess-al2023) 규칙 변경

기존의 자기 참조 ID(원본 SG ID)를 모두 새로 만든 보안 그룹 ID로 변경합니다.

방향 Port Source/Destination
Inbound 53/tcp 신규 SG
Inbound 53/udp 신규 SG
Outbound All Traffic 신규 SG

2.3.2 신규 SG의 Inbound 규칙에서 참조하는 보안 그룹에 Outbound 규칙 추가

EKS Manager 보안 그룹 (SG-*-PRIVATE-EKSMGR)

방향 Port Destination
Outbound 22/tcp 신규 SG

EKS Cluster 보안 그룹 (eks-cluster-sg-*)

방향 Port Destination
Outbound 443/tcp 신규 SG
Outbound 10250/tcp 신규 SG

2.3.3 신규 SG의 Outbound 규칙에서 참조하는 보안 그룹에 Inbound 규칙 추가

DB 보안 그룹 (SG-*-PRIVATE-DB)

방향 Port Source
Inbound 3306/tcp 신규 SG

Endpoint 보안 그룹 (SG-*-PRIVATE-ENDPOINT)

방향 Port Source
Inbound 443/tcp 신규 SG

Redis 보안 그룹 (SG-*-PRIVATE-REDIS)

방향 Port Source
Inbound 6379/tcp 신규 SG

EKS Cluster 보안 그룹 (eks-cluster-sg-*)

방향 Port Source
Inbound All Traffic 신규 SG

2.4 EKS v1.33 버전 Node Group Launch Template 생성

Amazon EC2 → Launch templates → Create launch template

Launch template name and description

항목 값
Launch template Name eks-<project>-nodegroup-al2023
Template version description eks-<project>-nodegroup-al2023

Launch template contents

Application and OS Images (AMI)

  • My AMIs → Shared with me
  • AMI: ami-xxxxxxxxxxxxxxxxx (Seoul region)
  • amazon-eks-node-al2023-x86_64-standard-1.33-v20250904

Instance type

  • m7i.xlarge (환경에 맞게 조정)

Key pair

  • 기존 클러스터에서 사용하던 Key pair 선택

Network settings (Security groups)

  • eks-cluster-sg-<cluster-name>-* (클러스터 기본 SG)
  • eks-remoteAccess-al2023 (2.2에서 새로 복제 생성한 SG)

Storage (Volumes)

항목 값
Size 100 GB
Volume type gp3

나머지 항목은 Default 유지

Resource tags

Key Value
service <service-name>
environment prd
Name <project>-eks-node

Advanced details

항목 값
Metadata version v2
Metadata response hop limit 1

User data

AL2023 노드는 NodeConfig 형식의 user data를 사용합니다.

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"

--//
Content-Type: application/node.eks.aws

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    apiServerEndpoint: https://<CLUSTER_API_ENDPOINT>.gr7.ap-northeast-2.eks.amazonaws.com
    certificateAuthority: <BASE64_ENCODED_CA>
    cidr: <SERVICE_CIDR>
    name: <CLUSTER_NAME>
--//--

apiServerEndpoint, certificateAuthority, cidr, name 은 EKS 클러스터 상세 정보에서 확인하여 입력합니다.

3. 본 작업

3.1 클러스터 k8s 버전 업그레이드

[EKS] → [Clusters] → [<cluster-name>] → [버전 업그레이드 v1.32 → v1.33]

3.2 Addons 버전 업데이트

[EKS] → [Clusters] → [<cluster-name>] → [추가 기능] → [버전 업데이트]

EKS v1.33 Default 버전으로 업데이트합니다.

  • kube-proxy
  • ebs-csi-driver plugin

3.3 Amazon EKS Pod Identity 에이전트 플러그인 설치

[EKS] → [Clusters] → [<cluster-name>] → [추가 기능] → [추가 기능 가져오기]
→ Amazon EKS Pod Identity 에이전트 선택 후 설치

3.4 생성된 시작 템플릿으로 AL2023 노드 그룹 생성

[EKS] → [<cluster-name>] → [Compute] → [Node groups] → [Add]

Configure node group

항목 값
Name <project>-eks-node-group-al2023-v133
Node IAM role 기존 worker node role 선택
Launch Template 2.4에서 생성한 템플릿 선택

Node group scaling configuration

항목 값
Desired size 4
Minimum size 4
Maximum size 4

Specify networking

  • 기존 클러스터와 동일한 Private 서브넷 선택 (AZ-A, AZ-C)

Create 클릭

3.5 노드 작업

노드 확인

kubectl get nodes

신규 노드(v1.33)와 기존 노드(v1.32)가 함께 표시됩니다.

NAME                                               STATUS   ROLES    AGE   VERSION
ip-10-x-x-x.ap-northeast-2.compute.internal       Ready    <none>   18s   v1.33.4-eks-99d6cc0   # 신규
ip-10-x-x-x.ap-northeast-2.compute.internal       Ready    <none>   41d   v1.32.1-eks-5d632ec   # 기존
...

기존 노드 cordon

스케줄링을 중단하여 신규 파드가 기존 노드에 배치되지 않도록 합니다.

kubectl cordon <old-node-1>
kubectl cordon <old-node-2>
kubectl cordon <old-node-3>
kubectl cordon <old-node-4>

기존 노드 drain

기존 노드의 파드를 신규 노드로 이동시킵니다.

kubectl drain <old-node-1> --ignore-daemonsets --delete-emptydir-data --force --grace-period=30 --timeout=5m
kubectl drain <old-node-2> --ignore-daemonsets --delete-emptydir-data --force --grace-period=30 --timeout=5m
kubectl drain <old-node-3> --ignore-daemonsets --delete-emptydir-data --force --grace-period=30 --timeout=5m
kubectl drain <old-node-4> --ignore-daemonsets --delete-emptydir-data --force --grace-period=30 --timeout=5m

노드의 파드 내용 검토

drain 후 기존 노드에 남아있는 파드가 없는지 확인합니다.

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<old-node-1>
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<old-node-2>
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<old-node-3>
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<old-node-4>

신규 노드들의 파드 상태 확인

신규 노드에 파드가 정상적으로 배치되었는지 확인합니다.

kubectl get pods --all-namespaces --field-selector spec.nodeName=<new-node-1>
kubectl get pods --all-namespaces --field-selector spec.nodeName=<new-node-2>
kubectl get pods --all-namespaces --field-selector spec.nodeName=<new-node-3>
kubectl get pods --all-namespaces --field-selector spec.nodeName=<new-node-4>

3.6 CoreDNS Addons 업데이트

⚠️ CoreDNS가 커스텀되어 있는 경우 업그레이드가 실패할 수 있습니다.
외부 통신 timeout이 의심될 경우 노드 그룹 아웃바운드 ALL 포트를 임시 개방하여 진행합니다.

버전 확인

aws eks describe-addon-versions \
  --addon-name coredns \
  --kubernetes-version 1.33 \
  --query 'addons[0].addonVersions[?compatibilities[?defaultVersion==true]].addonVersion' \
  --output text

CoreDNS 업그레이드

aws eks update-addon \
  --cluster-name <cluster-name> \
  --addon-name coredns \
  --addon-version v1.12.3-eksbuild.1 \
  --resolve-conflicts PRESERVE

검증

# Addon 상태 확인
eksctl get addon --cluster <cluster-name> --name coredns

# Deployment 확인
kubectl -n kube-system get deploy coredns -o wide

# Pod 상태 확인
kubectl -n kube-system get pods -l k8s-app=kube-dns -o wide

정상 출력 예시

NAME      READY   UP-TO-DATE   AVAILABLE   AGE    CONTAINERS   IMAGES
coredns   4/4     4            4           433d   coredns      .../eks/coredns:v1.12.4-eksbuild.1
NAME                       READY   STATUS    RESTARTS   AGE
coredns-xxxxxxxxxx-xxxxx   1/1     Running   0          27s
coredns-xxxxxxxxxx-xxxxx   1/1     Running   0          27s
coredns-xxxxxxxxxx-xxxxx   1/1     Running   0          25s
coredns-xxxxxxxxxx-xxxxx   1/1     Running   0          25s

3.7 기존 노드 제거

(관리형 노드인 경우) 기존 노드의 보안 그룹 참조 제거

기존 노드의 보안 그룹을 참조하고 있는 보안 그룹과의 연결을 먼저 제거합니다.

⚠️ 이 작업을 먼저 하지 않으면 노드 그룹 삭제 시 deleting 상태에서 멈추는 현상이 발생합니다.
기존 노드의 보안 그룹을 참조하는 보안 그룹이 존재하면 삭제가 실패합니다.

기존 노드 그룹 스케일 다운

EKS → <cluster-name> → Compute → Node groups → <old-node-group> → Edit
항목 값
Desired size 0
Minimum size 0
Maximum size 1

Save changes 클릭

기존 노드 그룹 제거

노드 축소 확인 후 기존 노드 그룹을 삭제합니다.

EKS → <cluster-name> → Compute → Node groups → <old-node-group> → Delete

4. 서비스 경과 확인

EKS 연관 지표 확인 및 애플리케이션 상태 점검

  • CloudWatch / Prometheus 등에서 노드/파드 메트릭 이상 여부 확인
  • 애플리케이션 헬스체크 엔드포인트 정상 응답 확인
  • 에러 로그 모니터링

5. 이벤트 내용 확인 방법

# 노드 그룹 상태 확인
aws eks describe-nodegroup \
  --cluster-name <cluster-name> \
  --nodegroup-name <nodegroup-name> \
  --query 'nodegroup.{Status:status, Issues:health.issues, Resources:resources, LT:launchTemplate}'

# 업데이트 이벤트 확인
aws eks describe-update \
  --name <cluster-name> \
  --update-id <update-id> \
  --query "update.{status:status, type:type, errors:errors}"

6. 내부 보안 HIDS Agent 설치 (AL2023 신규 노드)

AL2023 버전 노드에는 기존 AL2용 스크립트가 동작하지 않으므로 신규 스크립트를 사용해야 합니다.

⚠️ 설치 시 보안관제센터와 실시간 소통이 필요합니다.
PRD 환경에서만 설치가 필요합니다.

설치 스크립트

wget "https://<SECURITY_MANAGER_IP>:<PORT>/ssmp-agent/lin_install_info.sh" \
  --timeout=15 --tries=2 --no-check-certificate
bash lin_install_info.sh <SERVICE_NAME> <OPERATION> <CLOUD_TYPE> <AGENT_TYPE>

파라미터 설명

파라미터 설명 예시
SERVICE_NAME 서비스명 MyService
OPERATION 환경 구분 PRD / STG / DEV
CLOUD_TYPE 클라우드 구분 CloudD
AGENT_TYPE 에이전트 종류 H (HIDS only) / W (Webshell only) / B (Both)
  • WEB 서버: B 사용
  • WAS 서버: W 사용

EKS 노드 신규 생성 시 자동화 스크립트 예시

#!/usr/bin/env bash

svcNm=<SERVICE_NAME>
svcType=PRD
instFile=/tmp/installagent.sh

wget "https://<SECURITY_MANAGER_IP>:<PORT>/ssmp-agent/lin_install_info.sh" \
  --timeout=15 --tries=2 --no-check-certificate

bash lin_install_info.sh ${svcNm} ${svcType} CloudD H

sed -i 's/New/'"$svcNm"'/' $instFile
sed -i 's/PRD/'"$svcType"'/' $instFile
chmod a+x $instFile
bash $instFile

6.1 기존 스크립트 실패 원인 및 조치

실패 메시지

Agent installer's target platform is Amazon Linux 2 which does not match
the host platform Amazon Linux 2023. Installation is blocked!
error: %prein(ds_agent-20.0.2-17500.amzn2.x86_64) scriptlet failed, exit status 1
error: ds_agent-20.0.2-17500.amzn2.x86_64: install failed

원인

  • 기존 스크립트는 AL2 전용 패키지를 설치하므로 AL2023에서 동작하지 않음
  • 보안 매니저 서버 IP가 변경되어 아웃바운드 정책 업데이트 필요

조치 내역

  1. 아웃바운드 규칙에 신규 매니저 서버 IP 추가
    • Port: 4119, 4120, 4122
  2. AL2023 호환 신규 설치 스크립트로 교체

신규 매니저 서버 방화벽 오픈 정보

Type IP Port Direction
H-IDS <HIDS_MANAGER_IP> 4119, 4120, 4122 Outbound
WebShell <WEBSHELL_MANAGER_IP> 7778 Outbound

대표적인 설치 에러 원인

  • root 권한으로 미실행
  • wget 패키지 미존재
  • libnsl.so.1 라이브러리 미존재
  • 방화벽 정책 미개방
저작자표시 (새창열림)

'DevOps' 카테고리의 다른 글

[AEWS 4기] EKS 스터디 5주차 (EKS SaaS GitOps 워크샵)  (0) 2026.04.25
[AEWS 4기] EKS 스터디 5주차 [ Gitops와 Platform Engineering ]  (0) 2026.04.24
[AEWS 4기] EKS 스터디 5주차 [ EKS 트러블슈팅 ]  (0) 2026.04.17
[AEWS 4기] EKS 스터디 4주차 [ EKS 인증/인가] 암호학 (2)  (0) 2026.04.11
[AEWS 4기] EKS 스터디 4주차 [ EKS 인증/인가] 암호학 (1)  (1) 2026.04.11

'DevOps' Related Articles

티스토리툴바