# Container Insights와 함께 CloudWatch 에이전트를 사용하고 관찰 기능 활성화
CloudWatch 에이전트를 사용하여 Amazon EKS 클러스터 또는 Kubernetes 클러스터에 Container Insights를 설정하려면 다음 섹션 중 하나의 지침을 따르세요. 빠른 시작 지침은 Amazon EKS 버전 1.24 이상에서만 지원됩니다.
**참고**
다음 섹션 중 하나의 지침에 따라 Container Insights를 설치할 수 있습니다. 세 가지 지침을 모두 따를 필요는 없습니다.
**Topics**
+ [Amazon CloudWatch Observability EKS 추가 기능 빠른 시작](Container-Insights-setup-EKS-addon.md)
+ [Amazon EKS 및 Kubernetes에서 Container Insights의 빠른 시작 설정](Container-Insights-setup-EKS-quickstart.md)
+ [클러스터 지표를 수집하도록 CloudWatch 에이전트 설정](Container-Insights-setup-metrics.md)
# Amazon CloudWatch Observability EKS 추가 기능 빠른 시작
Amazon EKS 추가 기능을 사용하여 Amazon EKS의 관찰 기능이 향상된 Container Insights를 설치할 수 있습니다. 추가 기능은 CloudWatch 에이전트를 설치하여 클러스터에서 인프라 지표를 전송하고, Fluent Bit를 설치하여 컨테이너 로그를 전송하고, CloudWatch [Application Signals](CloudWatch-Application-Monitoring-Sections.md)를 활성화하여 애플리케이션 성능 텔레메트리를 전송합니다.
Amazon EKS 추가 기능 버전 1.5.0 이상을 사용하는 경우 클러스터의 Linux 및 Windows 워커 노드 모두에서 Container Insights가 활성화됩니다. Windows에서는 Amazon EKS에서 Application Signals가 지원되지 않습니다.
Amazon EKS 추가 기능은 Amazon EKS 대신 Kubernetes를 실행하는 클러스터에서는 지원되지 않습니다.
Amazon CloudWatch Observability EKS 추가 기능에 대한 자세한 내용은 [Amazon CloudWatch Observability EKS 추가 기능 또는 헬름 차트를 사용하여 CloudWatch 에이전트 설치](install-CloudWatch-Observability-EKS-addon.md) 섹션을 참조하세요.
추가 기능의 버전 3.1.0 이상을 사용하는 경우 EKS Pod Identity를 사용하여 추가 기능에 필요한 권한을 부여할 수 있습니다. EKS Pod Identity는 권장 옵션이며 최소 권한, 자격 증명 교체 및 감사 가능성과 같은 이점을 제공합니다. 또한 EKS Pod Identity를 사용하면 클러스터 생성 중에 EKS 추가 기능을 설치할 수 있습니다.
**Amazon CloudWatch Observability EKS 추가 기능 설치**
1. [EKS Pod Identity 연결](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/) 단계에 따라 IAM 역할을 생성하고 EKS Pod Identity 에이전트를 설정하세요.
1. 역할에 필요한 권한을 부여하는 IAM 정책을 연결하세요. *my-role*을 이전 단계의 IAM 역할 이름으로 바꾸세요.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn=arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. 이전 단계에서 생성한 IAM 역할을 함께 사용하여 다음 명령을 입력하세요.
```
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
```
# Amazon EKS 및 Kubernetes에서 Container Insights의 빠른 시작 설정
**중요**
Amazon EKS 클러스터에 Container Insights를 설치하는 경우 이 섹션의 지침을 따르는 대신 Amazon CloudWatch Observability EKS 추가 기능을 사용하여 설치하는 것이 좋습니다. 또한 가속화된 컴퓨팅 네트워크를 검색하려면 Amazon CloudWatch Observability EKS 추가 기능을 사용해야 합니다. 자세한 정보와 지침은 [Amazon CloudWatch Observability EKS 추가 기능 빠른 시작](Container-Insights-setup-EKS-addon.md) 섹션을 참조하십시오.
Container Insights 설정을 완료하려면 이 단원의 빠른 시작 지침을 따르세요. Amazon EKS 클러스터에 설치하고 2023년 11월 6일 또는 그 이후에 이 섹션의 지침을 사용하는 경우 Amazon EKS의 관찰 기능이 향상된 Container Insights를 클러스터에 설치합니다.
**중요**
이 단원의 단계를 완료하기 전에 먼저, IAM 권한을 포함한 사전 조건을 확인해야 합니다. 자세한 내용은 [CloudWatch에서 Container Insights에 대한 사전 요구 사항 확인](Container-Insights-prerequisites.md) 섹션을 참조하세요.
또는 [클러스터 지표를 수집하도록 CloudWatch 에이전트 설정](Container-Insights-setup-metrics.md) 및 [CloudWatch Logs에 로그 전송](Container-Insights-EKS-logs.md) 단원의 지침을 따를 수 있습니다. 이러한 단원에서는 CloudWatch 에이전트가 Amazon EKS 및 Kubernetes와 작동하는 방식에 대한 추가 구성 세부 정보를 제공하지만, 추가 설치 단계를 수행해야 합니다.
Container Insights의 원래 버전에서는 수집된 지표와 로그가 사용자 지정 지표로 청구됩니다. Amazon EKS의 향상된 관찰 기능을 갖춘 Container Insights를 사용하면 Container Insights 지표 및 로그는 저장된 지표나 수집된 로그별로 요금이 부과되는 대신 관찰당 요금이 부과됩니다. CloudWatch 요금에 대한 자세한 내용은 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/)을 참조하세요.
**참고**
Amazon은 이제 Container Insights의 기본 로그 솔루션으로 상당한 성능 향상을 제공하는 Fluent Bit를 출시했습니다. 따라서 Fluentd 대신 Fluent Bit를 사용하는 것이 좋습니다.
## CloudWatch 에이전트 운영자 및 Fluent Bit를 사용한 빠른 시작
Fluent Bit에는 두 가지 구성, 즉 최적화된 버전 및 Fluentd와 더 유사한 환경을 제공하는 버전이 있습니다. 빠른 시작 구성은 최적화된 버전을 사용합니다. Fluentd 호환 구성에 대한 자세한 내용은 [Fluent Bit를 DaemonSet로 설정하여 CloudWatch Logs에 로그 전송](Container-Insights-setup-logs-FluentBit.md) 섹션을 참조하세요.
CloudWatch 에이전트 운영자는 Amazon EKS 클러스터에 설치되는 추가 컨테이너입니다. OpenTelemetry Operator for Kubernetes를 따라 모델링됩니다. 운영자는 클러스터에서 Kubernetes 리소스의 수명 주기를 관리합니다. Amazon EKS 클러스터에 CloudWatch 에이전트, DCGM Exporter(NVIDIA), AWS Neuron Monitor를 설치하고 관리합니다. Fluent Bit와 Windows용 CloudWatch 에이전트는 운영자가 관리하지 않아도 Amazon EKS 클러스터에 직접 설치됩니다.
보다 안전하고 기능이 풍부한 인증 기관 솔루션을 위해 CloudWatch 에이전트 운영자는 cert-manager를 요구하는데, 이는 Kubernetes에서의 TLS 인증서 관리를 위해 널리 채택되고 있는 솔루션입니다. cert-manager를 사용하면 이러한 인증서를 획득, 갱신, 관리 및 사용하는 프로세스가 간소화됩니다. 인증서가 유효하고 최신 상태인지 확인하고 만료되기 전에 구성된 시간에 인증서 갱신을 시도합니다. cert-manager는 또한 AWS Certificate Manager Private Certificate Authority를 포함하여 지원되는 다양한 소스에서 인증서 발급을 용이하게 합니다.
**빠른 시작을 사용하여 Container Insights 배포**
1. 클러스터에 아직 설치되지 않은 경우 cert-manager를 설치합니다. 자세한 내용은 [cert-manager Installation](https://cert-manager.io/docs/installation/)을 참조하세요.
1. 다음 명령을 입력하여 사용자 지정 리소스 정의(CRD)를 설치합니다.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl apply --server-side -f -
```
1. 다음 명령을 입력하여 운영자를 설치합니다. *my-cluster-name*을 Amazon EKS 또는 Kubernetes 클러스터의 이름으로 바꾸고, *my-cluster-region*을 로그가 게시되는 리전의 이름으로 바꿉니다. AWS 아웃바운드 데이터 전송 비용을 줄이기 위해 클러스터가 배포되는 리전과 동일한 리전을 사용하는 것이 좋습니다.
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
예를 들어 `MyCluster`라는 클러스터에서 Container Insights를 배포하고 로그 및 지표를 미국 서부(오리건)에 게시하려면 다음 명령을 입력합니다.
```
ClusterName='MyCluster'
RegionName='us-west-2'
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
**Container Insights에서 마이그레이션**
Amazon EKS 클러스터에 Container Insights가 이미 구성되어 있고 Amazon EKS의 향상된 관찰 기능을 갖춘 Container Insights로 마이그레이션하려는 경우 [CloudWatch에서 Amazon EKS에 대한 향상된 관찰성을 갖춘 Container Insights로 업그레이드](Container-Insights-upgrade-enhanced.md) 섹션을 참조하세요.
**Container Insights 삭제**
빠른 시작 설정을 사용한 후 Container Insights를 제거하려면 다음 명령을 입력합니다.
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl delete -f -
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl delete -f -
```
# 클러스터 지표를 수집하도록 CloudWatch 에이전트 설정
**중요**
Amazon EKS 클러스터에 Container Insights를 설치하는 경우 이 섹션의 지침을 따르는 대신 Amazon CloudWatch Observability EKS 추가 기능을 사용하여 설치하는 것이 좋습니다. 자세한 정보와 지침은 [Amazon CloudWatch Observability EKS 추가 기능 빠른 시작](Container-Insights-setup-EKS-addon.md) 섹션을 참조하십시오.
Container Insights를 설정하여 지표를 수집하려면 [Amazon EKS 및 Kubernetes에서 Container Insights의 빠른 시작 설정](Container-Insights-setup-EKS-quickstart.md)의 절차를 따르거나 이 단원의 절차를 따르면 됩니다. 다음 단계에서는 클러스터에서 지표를 수집할 수 있도록 CloudWatch 에이전트를 설정합니다.
Amazon EKS 클러스터에 설치하고 2023년 11월 6일 또는 그 이후에 이 섹션의 지침을 사용하는 경우 Amazon EKS의 관찰 기능이 향상된 Container Insights를 클러스터에 설치합니다.
## 1단계: CloudWatch의 네임스페이스 생성
다음 단계를 통해 CloudWatch에 대해 `amazon-cloudwatch`라는 Kubernetes 네임스페이스를 생성합니다. 이 네임스페이스를 이미 생성했다면 이 단계를 건너뛸 수 있습니다.
**CloudWatch의 네임스페이스를 생성하려면**
+ 다음 명령을 입력합니다.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml
```
## 2단계: 클러스터에서 서비스 계정 생성
아직 서비스 계정이 없다면 다음 방법 중 하나를 사용하여 CloudWatch 에이전트의 서비스 계정을 생성합니다.
+ `kubectl` 사용
+ `kubeconfig` 파일 사용
### 인증에 `kubectl` 사용
**`kubectl`을 사용하여 CloudWatch 에이전트의 서비스 계정을 생성하려면**
+ 다음 명령을 입력합니다.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-serviceaccount.yaml
```
이전 단계를 따르지 않았지만 사용하려는 CloudWatch 에이전트에 대한 서비스 계정이 이미 있는 경우에는 다음 규칙이 있는지 확인해야 합니다. 뿐만 아니라 Container Insights 설치를 위한 나머지 단계에서 `cloudwatch-agent` 대신 이 서비스 계정의 이름을 사용해야 합니다.
```
rules:
- apiGroups: [""]
resources: ["pods", "nodes", "endpoints"]
verbs: ["list", "watch"]
- apiGroups: [ "" ]
resources: [ "services" ]
verbs: [ "list", "watch" ]
- apiGroups: ["apps"]
resources: ["replicasets", "daemonsets", "deployments", "statefulsets"]
verbs: ["list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["list", "watch"]
- apiGroups: [""]
resources: ["nodes/proxy"]
verbs: ["get"]
- apiGroups: [""]
resources: ["nodes/stats", "configmaps", "events"]
verbs: ["create", "get"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cwagent-clusterleader"]
verbs: ["get","update"]
- nonResourceURLs: ["/metrics"]
verbs: ["get", "list", "watch"]
- apiGroups: [ "discovery.k8s.io" ]
resources: [ "endpointslices" ]
verbs: [ "list", "watch", "get" ]
```
### 인증에 `kubeconfig` 사용
또는 `kubeconfig` 파일을 인증에 사용할 수 있습니다. 이 방법을 사용하면 CloudWatch 에이전트 구성에서 `kubeconfig` 경로를 직접 지정하여 서비스 계정에 대한 필요성을 우회할 수 있습니다. 또한 인증을 위한 Kubernetes 컨트롤 플레인 API에 대한 종속성을 제거하여 설정을 간소화하고 kubeconfig 파일을 통해 인증을 관리함으로써 보안을 강화할 수 있습니다.
이 방법을 사용하려면 다음 예와 같이 CloudWatch 에이전트 구성 파일을 업데이트하여 `kubeconfig` 파일 경로를 지정합니다.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "YOUR_CLUSTER_NAME",
"enhanced_container_insights": false,
"accelerated_compute_metrics": false,
"tag_service": false,
"kube_config_path": "/path/to/your/kubeconfig"
"host_ip": "HOSTIP"
}
}
}
}
```
`kubeconfig` 파일을 생성하려면 `system:masters` Kubernetes 역할을 가진 `admin/{create_your_own_user}` 사용자에 대한 인증서 서명 요청(CSR)을 생성합니다. 그런 다음 Kubernetes 클러스터의 인증 기관(CA)에 서명하고 `kubeconfig` 파일을 생성합니다.
## 3단계: CloudWatch 에이전트에 대한 ConfigMap 생성
다음 단계를 통해 CloudWatch 에이전트에 대한 ConfigMap을 생성합니다.
**CloudWatch 에이전트에 대한 ConfigMap을 생성하려면**
1. 다음 명령을 실행하여 `kubectl` 클라이언트 호스트로 ConfigMap YAML을 다운로드합니다.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-configmap-enhanced.yaml
```
1. 다운로드한 YAML 파일을 다음과 같이 편집합니다.
+ **cluster\$1name** – `kubernetes` 섹션에서 `{{cluster_name}}`을 클러스터 이름으로 바꿉니다. `{{}}` 문자를 제거합니다. 또는 Amazon EKS 클러스터를 사용하는 경우 `"cluster_name"` 필드 및 값을 삭제할 수 있습니다. 그렇게 하면 CloudWatch 에이전트가 Amazon EC2 태그에서 클러스터 이름을 감지합니다.
1. (선택 사항) 다음과 같이 모니터링 요구사항에 따라 ConfigMap을 추가로 변경합니다.
+ **metrics\$1collection\$1interval** – `kubernetes` 섹션에서 에이전트가 지표를 수집하는 빈도를 지정할 수 있습니다. 기본값은 60초입니다. Kubelet의 기본 cadvisor 수집 간격은 15초이기 때문에 이 값을 15초 미만으로 설정해서는 안 됩니다.
+ **endpoint\$1override** – `logs` 섹션에서 기본 엔드포인트를 재정의하려는 경우 CloudWatch Logs 엔드포인트를 지정할 수 있습니다. VPC의 클러스터에서 게시 중인 데이터를 VPC 종단점으로 이동시키고 싶은 경우에 재정의를 원할 수 있습니다.
+ **force\$1flush\$1interval** – `logs` 섹션에서 로그 이벤트를 CloudWatch Logs에 게시하기 전에 배치 처리하는 간격을 지정할 수 있습니다. 기본값은 5초입니다.
+ **region** – 기본적으로 에이전트는 작업자 노드가 있는 리전에 지표를 게시합니다. 이를 재정의하기 위해 `"region":"us-west-2"`처럼 `agent` 섹션에서 `region` 필드를 추가할 수 있습니다.
+ **statsd** 섹션 - CloudWatch Logs 에이전트가 클러스터의 각 작업자 노드에서 StatsD 리스너로도 실행되도록 하려는 경우 다음 예와 같이 `statsd` 섹션을 `metrics` 섹션에 추가할 수 있습니다. 이 섹션의 다른 StatsD 옵션에 대한 자세한 내용은 [StatsD를 사용하여 사용자 지정 지표 검색](CloudWatch-Agent-custom-metrics-statsd.md) 단원을 참조하세요.
```
"metrics": {
"metrics_collected": {
"statsd": {
"service_address":":8125"
}
}
}
```
JSON 섹션에 대한 전체 예는 다음과 같습니다. 인증에 `kubeconfig` 파일을 사용하는 경우, `kube_config_path` 파라미터를 추가하여 kubeconfig 파일의 경로를 지정합니다.
```
{
"agent": {
"region": "us-east-1"
},
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "MyCluster",
"metrics_collection_interval": 60,
"kube_config_path": "/path/to/your/kubeconfig" //if using kubeconfig for authentication
}
},
"force_flush_interval": 5,
"endpoint_override": "logs.us-east-1.amazonaws.com"
},
"metrics": {
"metrics_collected": {
"statsd": {
"service_address": ":8125"
}
}
}
}
```
1. 다음 명령을 실행하여 클러스터에서 ConfigMap을 생성합니다.
```
kubectl apply -f cwagent-configmap-enhanced.yaml
```
## 4단계: DaemonSet로 CloudWatch 에이전트 배포
CloudWatch 에이전트의 설치를 완료하고 컨테이너 지표 수집을 시작하려면 다음 단계를 따르세요.
**CloudWatch 에이전트를 DaemonSet로 배포하려면**
1.
+ 클러스터에서 StatsD를 사용하려면 다음 명령을 입력하세요.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
```
+ StatsD를 사용하지 않으려면 다음 절차를 따르세요.
1. 다음 명령을 실행하여 `kubectl` 클라이언트 호스트에 DaemonSet YAML을 다운로드합니다.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
```
1. 다음과 같이 `cwagent-daemonset.yaml` 파일에서 `port` 섹션의 주석 처리를 해제합니다.
```
ports:
- containerPort: 8125
hostPort: 8125
protocol: UDP
```
1. 다음 명령을 실행하여 클러스터에서 CloudWatch 에이전트를 배포합니다.
```
kubectl apply -f cwagent-daemonset.yaml
```
1. 다음 명령을 실행하여 클러스터의 Windows 노드에서 CloudWatch 에이전트를 배포합니다. StatsD 리스너는 Windows의 CloudWatch 에이전트에서 지원되지 않습니다.
```
kubectl apply -f cwagent-daemonset-windows.yaml
```
1. 다음 명령을 실행하여 에이전트가 배포되었는지 확인합니다.
```
kubectl get pods -n amazon-cloudwatch
```
완료되면 CloudWatch 에이전트는 `/aws/containerinsights/Cluster_Name/performance`라는 로그 그룹을 생성하고 이 로그 그룹에 성능 로그 이벤트를 전송합니다. 또한 StatsD 리스너로서 에이전트를 설정하는 경우, 에이전트는 애플리케이션 Pod가 예약된 노드의 IP 주소를 통해 포트 8125에서 StatsD 지표를 수신합니다.
### 문제 해결
에이전트에서 배포가 올바르게 되지 않으면 다음을 수행해 보세요.
+ 다음 명령을 실행하여 Pod 목록을 가져옵니다.
```
kubectl get pods -n amazon-cloudwatch
```
+ 다음 명령을 실행하고 출력 하단에서 이벤트를 확인합니다.
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
+ 다음 명령을 실행하여 로그를 확인합니다.
```
kubectl logs pod-name -n amazon-cloudwatch
```