EKS 버전 업그레이드 (1.28 -> 1.31) 후에 대표 관리자를 제외한 부 관리자들이 EKS 모니터링 실행에 실패하는 현상이 나타났고, 실패 로그는 아래와 같았다.

Proxy request for clusterId="11115f91f1f9e3f0c97e4c3692f41111" to url="/apis/metrics.eks.amazonaws.com/v1" has statusCode=401
Proxy request for clusterId="11115f91f1f9e3f0c97e4c3692f41111" to url="/apis/metrics.eks.amazonaws.com/v1" failed with UNAUTHORIZED

aws-auth ConfigMap 에는 기존 버전 그대로 해당 사용자들의 권한이 명시되어 있었다.

  mapUsers: |
    - groups:
      - system:masters
      userarn: arn:aws:iam::111151101111:user/honggildong

다른 모든 api 권한은 문제가 없는데, 제어 플레인 (control plane) 메트릭 가져오는 api 만 인증되지 않았다는게 당최 어디서 설정을 해야 하는건지...

그렇게 찾다보니, EKS 액세스 관리 제어에 관련된 AWS 기술 블로그를 찾았다.
https://aws.amazon.com/ko/blogs/tech/a-deep-dive-into-simplified-amazon-eks-access-management-controls/

기존의 액세스 권한 부여 방식이 복잡했기 때문에, 액세스 관리 제어 기능을 통해 AuthN(인증) / AuthZ(권한) 부분을 간소화 하였다는 내용이다.

EKS 관리 제어에 두가지 용어가 추가됐다.
- 액세스 항목(access entries) : IAM 사용자나 역할에 연결되어 EKS 클러스터를 인증 (AuthN)
- 액세스 정책(access policy) : 특정 클러스터 작업에 대한 EKS 만의 권한 부여 (AuthZ)

액세스 항목 + 액세스 정책 대신 기존의 RBAC(Role-Based Access Control: 역할 기반 액세스 제어) 의 권한 부여(ClusterRoleBinding) 와 결합하는 것도 가능하다.

특정 클러스터에의 사용자에게 권한을 주려면 액세스 항목에 IAM 사용자나 역할로 생성하고, 정책을 할당하여 특정 권한을 부여하는 프로세스 이다. (기존에는 위 예제처럼 ConfigMap 에 IAM 정보와 권한을 부여할 group 을 설정했었다.) 이 기능이 2024년 7월 경 오픈되었고 이 날 이후에 업그레이드된 클러스터에서는 인증/권한 설정에 대해 기존의 CONFIG_MAP, 새로운 API, 두가지 모두 사용 가능한 API_AND_CONFIG_MAP 모드를 선택하게 됐다. 이 문서에서는 기존 클러스터를 API_AND_CONFIG_MAP 인증 모드로 설정하고, 기존의 aws-auth configMap 에서 사용된 동일한 ID / 그룹을 지정하여 동등한 액세스 항목을 생성할 것을 권장하고 있다. access_entries / aws-auth 모두 설정되어 있을 경우, 우선순위는 액세스 항목 > ConfigMap 순이다. 또한 클러스터 뿐아닌 네임스페이스 레벨의 권한도 설정이 가능하다.

명령) 특정 클러스터에 IAM ARN 인증 및 권한 설정

$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks associate-access-policy --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
  --access-scope type=cluster

하지만 다 필요없고, EKS 대시보드에서 아주 간편하게 액세스 관리 제어를 설정할 수 있다...

EKS 액세스 항목에 부 관리자 IAM 설정하고, 정책(AmazonEKSClusterAdminPolicy) 연결해서 문제는 해결됐다. 하지만 위의 오류가 발생했던 이유는, 지금도 잘 모르겠다. 버전 업데이트 후에 액세스 관리 제어 설정이 안되어 있어서 configMap 에만 의존하고 있었을 것이고, ConfigMap 에 설정된 system:masters 권한이라면 기존과 동일하게 api 권한의 문제는 없었어야 했는데, 다른 api 는 다 되고 metric api 만 거부됐다는게...

몰라몰라~~

이제 aws-auth ConfigMap 에서 사용자 권한을 편집할 필요가 없어졌다. 추후 EKS 에서 ConfigMap 이 제거된다고 하니 액세스 관리 제어의 사용은 필수...

간만에 ingress 하나 생성하려는데 태클이...

$ kubectl describe ingress my_ingress -n my_namespace

  Type     Reason             Age    From     Message
  ----     ------             ----   ----     -------
  Warning  FailedDeployModel  3m41s  ingress  Failed deploy model due to AccessDenied: User: arn:aws:sts::110111011101:assumed-role/myEKSLoadBalancerControllerRole/1234561234561234561 is not authorized to perform: elasticloadbalancing:AddTags on ause no identity-based policy allows the elasticloadbalancing:AddTags action

구글에서는 위 에러 메시지와 관련된 내용은 찾기 어려웠다. AWS 문서 뒤적이며 loadBalancerController 생성하는 부분을 찾아보니, iam_policy.json 파일이 v2.3.0 에서 v.2.5.4 로 업데이트 되어 있었고, 아래 정책이 추가된 것을 확인했다.

        ...
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:AddTags"
            ],
            "Resource": [
                "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*",
                "arn:aws:elasticloadbalancing:*:*:loadbalancer/net/*/*",
                "arn:aws:elasticloadbalancing:*:*:loadbalancer/app/*/*"
            ],
            "Condition": {
                "StringEquals": {
                    "elasticloadbalancing:CreateAction": [
                        "CreateTargetGroup",
                        "CreateLoadBalancer"
                    ]
                },
                "Null": {
                    "aws:RequestTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        ...

AWS 콘솔에서 myEKSLoadBalancerControllerRole 을 찾아 연결된 정책 AWSLoadBalancerControllerIAMPolicy 에 위 스니펫을 삽입하여 해결...

내용은 대충 TargetGroup / LoadBalancer 생성할 때 리소스에 태그지정하는 권한 같은데... 참 쓰잘데기 없다. 아니 매년 이렇게 미친듯이 강제로 업데이트 하는게 맞는거야? 

(참고) https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html

약 1년 정도 EKS fargate + grafana 로 모니터링과 알람을 사용했다. 이왕 설치했으니까, 나름 피곤한 세팅 해가면서, 이쁘게 커스텀 잘 해왔는데, 보안 점검때마다 EKS 와 plugin 을 최신버전으로 올리는 바람에 그 때마다 Node 날아가고 전부 새로 설치+세팅 해야 한다는 점... 한번은 그냥 기분 좋게 했었는데, 두번은 못하겠다. 이게 다 fargate 를 사용해서...? AWS 의 EKS 인 만큼, AWS 안에서 모니터링과 알람을 만드는 것이 옳다고 생각하고 방법을 찾아봤다.

CPU / MEM / Traffic 모니터링은 기본이고, 배포시(혹은 장애시) 슬랙 알림 전송이 목표이며, 유일하게 AWS CloudWatch Container Insights 를 찾았다.

Container Insights 는 ECS/EKS 의 EC2/Fargate 에서 컨테이너 어플리케이션의 지표 및 로그를 수집하고 집계할 수 있다. 일반적으로 워커노드의 kubelet 이 /metrics/cadvisor 엔드포인트에서 CPU, 메모리, 디스크, 네트워크 사용량 등의 리소스 지표를 노출하는데, EKS Fargate 네트워킹 구조상 이 kubelet 에 접근이 안되기 때문에 프록시 역할을 할 ADOT(AWS Distro for OpenTelemetry 수집기를 사용하여, 워커노드의 지표 및 로그(CPU, 메모리, 트래픽) 들을 CloudWatch 로 전달한다. 그럼에도 CloudWatch 의 [향상된 관찰 기능] 은 지원되지 않는다.

ADOT Pod 생성

1. fargate profile 생성

$ kubectl create namespace fargate-container-insights
namespace/fargate-container-insights created

2. 서비스 계정 생성

ADOT 수집기에는 성능 로그 이벤트를 CloudWatch로 보내려면 IAM 권한이 필요하다. AWS 관리형 정책 CloudWatchAgentServerPolicy 와 연결할 역할(EKS-Fargate-ADOT-ServiceAccount-Role)을 만들고, EKS 의 서비스계정(adot-collector) 을 생성하여 연결하는 스크립트이다. YOUR-EKS-CLUSTER-NAME 과 YOUR-EKS-CLUSTER-REGION 을 적절히 수정한다.

$ ##!/bin/bash
CLUSTER_NAME=YOUR-EKS-CLUSTER-NAME
REGION=YOUR-EKS-CLUSTER-REGION
SERVICE_ACCOUNT_NAMESPACE=fargate-container-insights
SERVICE_ACCOUNT_NAME=adot-collector
SERVICE_ACCOUNT_IAM_ROLE=EKS-Fargate-ADOT-ServiceAccount-Role
SERVICE_ACCOUNT_IAM_POLICY=arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

$ eksctl utils associate-iam-oidc-provider \
--cluster=$CLUSTER_NAME \
--approve

$ eksctl create iamserviceaccount \
--cluster=$CLUSTER_NAME \
--region=$REGION \
--name=$SERVICE_ACCOUNT_NAME \
--namespace=$SERVICE_ACCOUNT_NAMESPACE \
--role-name=$SERVICE_ACCOUNT_IAM_ROLE \
--attach-policy-arn=$SERVICE_ACCOUNT_IAM_POLICY \
--approve

2023-11-27 22:09:08 [ℹ]  eksctl version 0.75.0
2023-11-27 22:09:08 [ℹ]  using region ap-northeast-2
2023-11-27 22:09:09 [ℹ]  1 iamserviceaccount (fargate-container-insights/adot-collector) was included (based on the include/exclude rules)
2023-11-27 22:09:09 [!]  serviceaccounts that exist in Kubernetes will be excluded, use --override-existing-serviceaccounts to override
2023-11-27 22:09:09 [ℹ]  1 task: {
    2 sequential sub-tasks: {
        create IAM role for serviceaccount "fargate-container-insights/adot-collector",
        create serviceaccount "fargate-container-insights/adot-collector",
    } }2023-11-27 22:09:09 [ℹ]  building iamserviceaccount stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:10 [ℹ]  deploying stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:10 [ℹ]  waiting for CloudFormation stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:26 [ℹ]  waiting for CloudFormation stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:43 [ℹ]  waiting for CloudFormation stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:43 [ℹ]  created serviceaccount "fargate-container-insights/adot-collector"

3. ADOT StatefulSet 배포

https://github.com/aws-observability/aws-otel-collector/blob/main/deployment-template/eks/otel-fargate-container-insights.yaml

파일을 다운받아, YOUR-EKS-CLUSTER-NAME 과 region=us-east-1 을 적절히 수정하여 배포한다.

$ kubectl apply -f eks-fargate-container-insights.yaml
clusterrole.rbac.authorization.k8s.io/adotcol-admin-role created
clusterrolebinding.rbac.authorization.k8s.io/adotcol-admin-role-binding created
configmap/adot-collector-config created
service/adot-collector-service created
statefulset.apps/adot-collector created

4. CloudWatch Log Group 확인

몇 분이 지나면 CloudWatch 로그 그룹에 로그가 쌓이는 것을 확인할 수 있다.
/aws/containerinsights/CLUSTER_NAME/performance

5. CloudWatch 대시보드 생성

Metrics > ContainerInsights 지표를 활용하여 CPU, 메모리, 트래픽 정도의 대시보드를 구현할 수 있다.
(배포 알림은 ContainerInsights 가 아닌 ALB target-group 의 HealthyHostCount 로 측정하였음. PromQL 가 없으니 잇몸으로...)

* AWS Email 전문

2023년 2월 15일부터 Amazon EKS는 Kubernetes 1.21 버전을 더 이상 지원하지 않습니다. 또한 그 이후, 더 이상 새 1.21버전의 클러스터를 생성할 수 없으며 Kubernetes 1.21 버전을 사용중인 모든 EKS 클러스터는 최신 플랫폼 버전의 Kubernetes 버전 1.22로 업데이트될 예정입니다.
...
1.21 버전의 클러스터를 Kubernetes 1.22 버전 이상으로 업데이트하는 것을 권장드립니다. 클러스터를 바로 가장 최신 Kubernetes 버전인 1.24 버전으로 업데이트하여, 버전 업데이트를 수행해야 하는 빈도를 최소화할 수 있습니다.

일단 EKS 버전 업데이트가 처음인데다가, 현재 운영중인 클러스터라 다운타임이 발생하면 회사에 치명적, 내 수명에도 치명적... 다른일 처리하다가 미루고 미루다 보니 내일 모레가 듀 데이트... 다행히 개발/운영 클러스터를 각각 사용하고 있어서 개발 클러스터로 다운타임이 발생하지 않는지 확인할 수 있었다. 결론부터 말하면 fargate 사용시 다운타임은 발생하지 않았다.

이왕 손댔을 때, 메일에 쓰인대로 1.21 버전에서 1.24 버전으로 올리면 좋겠지만 한번에 하나의 마이너버전 업데이트만 가능하다. 일단 업데이트 전 버전별 업데이트 주의사항들을 확인해 봤다.

https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html

요약하자면,

• kubectl client/server 버전 동기화
• 사라지는 v1beta API 들 체크하여, 기존 YAML 파일 변경
• AWS Load Balancer Controller 2.4.1 이상으로 업데이트

이 정도인 것 같다. kubectl 은 로컬에 lens, docker 등에서도 설치가 되어 최신버전이 표시되게 설정이 필요하다. kubectl 버전은 EKS 클러스터 API 버전을 기준으로 마이너버전 +-1 만 사용이 가능하다. 예를 들어 1.23 kubectl Client 는 Kubernetes 1.22, 1.23, 1.24 클러스터에서 사용이 가능하다... 고는 하는데, kubectl client 1.24 과 server 1.21 을 사용할 때 큰 이슈는 없었다... 아무튼 최신버전(1.25+)에서는 제약이 있는 듯. yaml 파일 수정은 rbac.authorization.k8s.io/v1beta1 하나 했고, ALB Controller 는 업데이트 하지 않았더니 무한 restart...ㅎ

EKS v1.22 업데이트 순서

(현재 프로젝트용 fargate 와 모니터링용 node-group 을 사용중이다.)

1. 클러스터 버전 업데이트

$ eksctl upgrade cluster \
--name my-cluster \
--version 1.24 \
--approve

2. 노드 그룹 버전 업데이트 (옵션)

$ eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.24

노드 그룹의 경우 볼륨 수대로 파드가 생성되서 에러인줄 알고 깜놀했는데, 10여분정도 뒤에 업데이트가 끝나면 알아서 다 정리된다. 프로메테우스는 재설치 했다..;

3. Custom Resources 업데이트

$ helm repo update
$ kubectl apply -k "github.com/aws/eks-charts/stable/aws-load-balancer-controller/crds?ref=master"
customresourcedefinition.apiextensions.k8s.io/ingressclassparams.elbv2.k8s.aws configured
customresourcedefinition.apiextensions.k8s.io/targetgroupbindings.elbv2.k8s.aws configured

4. AWS Load Balancer Controller 2.4.1 이상으로 업데이트

$ helm upgrade aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=my-cluster \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set region=my-region \
--set vpcId=vpc-1234567890 \
--set image.repository=my-region-id.dkr.ecr.my-region.amazonaws.com/amazon/aws-load-balancer-controller

5. EKS 대시보드의 [추가기능] 업데이트

• Amazon VPC CNI
• CoreDNS
• kube-proxy

업데이트시, 충돌 옵션을 선택하지 않으면 아래와 같은 에러가 발생한다. 옵션에서 [재정의] 를 선택하면 된다.

Conflicts found when trying to apply. Will not continue due to resolve conflicts mode. Conflicts: ConfigMap kube-proxy-config - .data.config DaemonSet.apps kube-proxy - .spec.template.spec.containers[name="kube-proxy"].image DaemonSet.apps kube-proxy - .spec.template.spec.containers[name="kube-proxy"].image

6. 프로젝트 deployment 각각 restart (업데이트 버전의 노드 확인)

$ kubectl rollout restart -n my-namespace deployment/my-project
...

EKS v1.23 업데이트

v1.23 에서는 노드그룹(EC2) 를 사용한다면, EBS CSI driver 설치를 해주어야 한다. EKS 대시보드의 [추가기능] 에서 생성. 생성시 필요한 IAM 역할 생성은 아래 사이트 참고.

https://docs.aws.amazon.com/eks/latest/userguide/csi-iam-role.html

EBS CSI driver 가 정상적인 권한으로 설치되지 않으면 Volumes mount 가 실패하고 에러가 발생한다.

failed to provision volume with StorageClass "gp2": rpc error: code = Internal desc = Could not create volume "pvc-c1234a61-1234-4321-1234-12347d4f1234": could not create volume in EC2: NoCredentialProviders: no valid providers in chain caused by: EnvAccessKeyNotFound: failed to find credentials in the environment. SharedCredsLoad: failed to load profile, . EC2RoleRequestError: no EC2 instance role found caused by: RequestError: send request failed caused by: Get "http://111.111.111.111/latest/meta-data/iam/security-credentials/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

EKS v1.24 업데이트

v1.24 에서는 따로 설정을 변경한 것은 없었지만, PSP(PodSecurityPolicy) 가 v1.25에서는 제거될 예정이라 PSS(PodSecurityStandards) 로 대체할 수 있다. PSS 설치 내용이 너무 길어서; v1.25 언제 쓸지도 모르는데 일단 그때까지 보류하는걸로

https://aws.amazon.com/ko/blogs/containers/implementing-pod-security-standards-in-amazon-eks/

그저 단순 업데이트처럼 보이지만 참으로 살떨리는 작업이었다...ㅋ

일반적으로 EKS cluster 를 생성한 계정 이외에 다른 IAM 사용자나 role 을 세분화하여 추가할 수 있으며, 심플한 사용자 추가를 진행해 보았다. 예전에 뭣 때문에 eksctl 을 설치했는지는 모르겠다만 땡큐~

eksctl 이 설치되어 있지 않다면... https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eksctl.html

eksctl 을 이용하면 간단히 cluster 정보와 추가할 iam 계정의 arn, ClusterRoleBinding group 을 지정한다.

$ eksctl create iamidentitymapping \
    --cluster cluster-name \
    --region=ap-northeast-2 \
    --arn arn:aws:iam::111122223333:user/ggamzzak \
    --group system:masters \
    --profile my-profile

2022-08-02 17:25:32 [ℹ]  eksctl version 0.75.0
2022-08-02 17:25:32 [ℹ]  using region ap-northeast-2
2022-08-02 17:25:32 [ℹ]  adding identity "arn:aws:iam::111122223333:user/ggamzzak" to auth ConfigMap

"system:masters" 그룹의 자격 증명을 사용하면 cluster-admin 슈퍼유저의 역할을 바인딩하여 모든 작업을 수행할 수 있다.

configmap/aws-auth 를 확인하면 다음과 같이 추가되어 있다.

$ kubectl describe configmap -n kube-system aws-auth
Name:         aws-auth
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Data
====
mapUsers:
----
- groups:
  - system:masters
  userarn: arn:aws:iam::111122223333:user/ggamzzak 

mapRoles:
...

또는,

$ eksctl get iamidentitymapping --cluster my-cluster --region=ap-northeast-2 --profile my-profile
2022-08-02 20:52:23 [ℹ]  eksctl version 0.75.0
2022-08-02 20:52:23 [ℹ]  using region ap-northeast-2
ARN                                                             USERNAME                        GROUPS                                                                          ACCOUNT
...
arn:aws:iam::111122223333:user/ggamzzak                                                         system:masters

추가된 IAM 계정으로 테스트 ㄱㄱ~