EKS to CloudWatch 모니터링 환경 구성

# EKS에서 생성되는 Log들의 모니터링을 위해 EKS의 Log내용을 CloudWatch에서 수집하여 사용자에게 제공하는 방법에 대해 구성하고자 한다.

* 사전 준비사항

새로운 작업을 할 때 가장 고려해야 할 사항은 보안과 권한 문제이다.

EKS 자원을 CloudWatch에서 모니터링하기 위해서는 모니터링 대상이 CloudWatch에 접근할 수 있는 권한이 존재해야 한다. 여기서는 Node Group 인스턴스가 될 것이다.

Node Group의 IAM 권한을 확인한다. EC2 인스턴스로 접근하여 IAM 권한을 확인하면 아래와 같다.

해당 IAM으로 접근하여 우측 상단에 권한 추가 → 정책 연결을 클릭하여 CloudWatchAgentServerPolicy 권한을 아래와 같이 부여한다.

여기까지 완료가 되었다면, 아래의 작업을 진행하면 된다.

1. CloudWatch NameSpace 구성

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cloudwatch-namespace.yaml

위의 명령어를 적용하면 아래와 같이 NameSpace가 생성이 되었다는 문구가 생성된다.

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cloudwatch-namespace.yaml
namespace/amazon-cloudwatch created

2. Kubernetes에서 매트릭 수집 후 CloudWatch로 전송할 Role을 가진 Account를 생성

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cwagent-kubernetes-monitoring/cwagent-serviceaccount.yaml

위의 명령어를 적용하면 아래와 같이 클러스터 롤이 적용되었다는 메시지가 나온다.

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cwagent-kubernetes-monitoring/cwagent-serviceaccount.yaml
serviceaccount/cloudwatch-agent created
clusterrole.rbac.authorization.k8s.io/cloudwatch-agent-role created
clusterrolebinding.rbac.authorization.k8s.io/cloudwatch-agent-role-binding created

3. EKS 매트릭을 수집 시 어떤 형태로 수집할 것인지 설정하는 config 파일을 다운로드하고 수정한다.

curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cwagent-kubernetes-monitoring/cwagent-configmap.yaml

위의 명령어를 실행하면 아래와 같이 설정 파일이 정상적으로 다운이 된 것을 확인할 수 있다.

다운로드한 파일을 수정한다. 파일 내용은 아래와 같다.

리전과 클러스터 이름 그리고 통신을 위한 포트 등을 입력하고 저장한다.

apiVersion: v1
data:
  # Configuration is in Json format. No matter what configure change you make,
  # please keep the Json blob valid.
  cwagentconfig.json: |
    {
        "agent": {
            "region": "ap-northeast-2"
        },
        "logs": {
            "metrics_collected": {
                "kubernetes": {
                    "cluster_name": "EKS-SEUNG-SEUNG-CLUSTER",
                    "metrics_collection_interval": 60
                }
            },
            "force_flush_interval": 5,
            "endpoint_override": "logs.ap-northeast-2.amazonaws.com"
        },
        "metrics": {
            "metrics_collected": {
                "statsd": {
                    "service_address": ":8125"
                }
            }
        }
    }
kind: ConfigMap
metadata:
  name: cwagentconfig
  namespace: amazon-cloudwatch

* 주의 사항

아래에서 다른 부분을 수정하실 때는 다음과 같은 부분들을 주의해야 한다.
metrics_collection_interval: kubernetes 섹션에서 에이전트가 지표를 수집하는 간격을 지정할 수 있다. 기본값은 60초이다. Kubelet의 기본 cadvisor 수집 간격은 15초이기 때문에 이 값을 15초 미만으로 설정해서는 안된다.
endpoint_override–기본 엔드포인트를 재정의하려면 logs 섹션에서 CloudWatch Logs 엔드포인트를 지정할 수 있다. VPC의 클러스터에서 게시 중인 데이터를 VPC 종단점으로 이동시키고 싶은 경우에 재정의를 원할 수 있다.
force_flush_interval– logs 섹션에서 CloudWatch Logs에 게시되기 전에 로그 이벤트를 배치화하는 간격을 지정할 수 있다. 기본값은 5초이다.

4. 수정된 파일을 배포합니다.

kubectl apply -f cwagent-configmap.yaml

위의 명령어가 정상적으로 실행되었다면 아래와 같이 출력이 됩니다.

kubectl apply -f cwagent-configmap.yaml
configmap/cwagentconfig created

생성된 pod가 정상적으로 실행이 되고 있는지 확인합니다.

kubectl get configmap -n amazon-cloudwatch

kubectl get configmap -n amazon-cloudwatch
NAME               DATA   AGE
cwagentconfig      1      3m46s
kube-root-ca.crt   1      21m

생성된 Configmap 내용 확인

kubectl describe configmap cwagentconfig -n amazon-cloudwatch

kubectl describe configmap cwagentconfig -n amazon-cloudwatch
Name:         cwagentconfig
Namespace:    amazon-cloudwatch
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"v1","data":{"cwagentconfig.json":"{\n    \"agent\": {\n        \"region\": \"ap-northeast-2\"\n    },\n    \"logs\": {\n   ...

Data
====
cwagentconfig.json:
----
{
    "agent": {
        "region": "ap-northeast-2"
    },
    "logs": {
        "metrics_collected": {
            "kubernetes": {
                "cluster_name": "EKS-SEUNG-SEUNG-CLUSTER",
                "metrics_collection_interval": 60
            }
        },
        "force_flush_interval": 5,
        "endpoint_override": "logs.ap-northeast-2.amazonaws.com"
    },
    "metrics": {
        "metrics_collected": {
            "statsd": {
                "service_address": ":8125"
            }
        }
    }
}

Events:  <none>

5. 데몬 셋을 통해 배포하기

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cwagent-kubernetes-monitoring/cwagent-daemonset.yaml

위의 명령어가 정상적으로 실행되면 아래와 같이 생성된다.

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/master/k8s-yaml-templates/cwagent-kubernetes-monitoring/cwagent-daemonset.yaml
daemonset.apps/cloudwatch-agent created

6. 생성한 pod 확인 및 서비스 정상수 집 확인

kubectl get pod -n amazon-cloudwatch 명령어를 통해 생성된 pod 확인

kubectl get pod -n amazon-cloudwatch
NAME                     READY   STATUS    RESTARTS   AGE
cloudwatch-agent-j4wnq   1/1     Running   0          5m7s
cloudwatch-agent-rfxph   1/1     Running   0          5m7s

AWS CloudWacth 서비스로 이동하여 정상적으로 수집이 진행되고 있는지 확인

AWS CloudWatch 서비스로 이동 → 왼쪽 메뉴 모든 지표 클릭 → ContainerInsights 클릭

아래의 지표는 샘플 지표로 nginx라는 pod가 현재 어느 정도의 CPU 자원과 Memory 자원을 사용하고 있는지 CloudWatch에서 확인하는 샘플이다.

지금까지 EKS자원을 CloudWatch에서 모니터링하는 과정을 진행했다.

추가로 EKS 자원의 CPU 사용률이나 메모리 사용률이 임계치를 넘었을 때 관리자 및 사용자에게 메일 및 문자가 전달되는 과정도 추가로 진행해보면 될 것 같다.

 

- 끝 -