[EKS/Access Configuration] Managed Node Group > Karpenter Migration 시 aws-auth 문제 해결

 

 

# 이슈 발생

원래 Managed EC2 Node Group으로 EKS를 구성해 두었다가, Karpenter PoC를 마치고 모두 넘어가려고 준비중이었다.

따라서 Managed Node Group (이하 node group) & Karpenter가 모두 떠 있었고, node group은 노드를 0으로만 유지중이었다.

 

이제 모든 클러스터가 카펜터로 잘 동작중이기 때문에, node group은 이제 지워야지! 하고 dev 클러스터부터 전부 지움.

그러자 ... 갑자기 카펜터로 뜬 노드들이 전부 죽기 시작했다.

ㅠㅠ

 

# 뭔지 모르겠지만 일단 롤백

아무리 생각해도 node group이랑 카펜터에 연관 관계가 있을 것 같지 않았다.

근데 롤백하니까 (node group 살리니까) 카펜터 노드들도 다시 살아나기 시작했다.

대체 뭐지..?

 

# 원인 파악

첫 번째 가설은, 내가 만든 테라폼 모듈에서 node group에 의존성이 있는 무언가가 카펜터를 방해한 것이다!

(eks와 노드그룹, 카펜터는 모두 직접 만든 테라폼 모듈로 관리중이다)

그러나 아무리 이슈 상황을 재현하도록 테라폼 플랜을 돌려봐도, 그저 노드그룹과 런치템플릿만 지워질 뿐이었다.

 

그렇게 테라폼으로 이것저것 해보다가 발견한게...

node group을 모두 지운 후 다시 plan을 돌리면 aws-auth configmap이 수정되려고 하고 있었다.

더 자세하게는, 

노드의 롤에 대한 권한 부분이 real resource(실제 configmap)에서 빠져있었다.

나는 aws-auth도 테라폼으로 관리중이었기 때문에 플랜을 다시 돌리면 해당 변경 사항이 감지된 것.

 

즉, node group을 모두 삭제 시 aws-auth에서 노드 롤에 대한 권한이 빠져버렸고, 

그 때문에 같은 role을 쓰고 있던 카펜터가 권한이 없어 ec2들을 노드로 조인시키지 못했던 것.

 

왜지? ec2 node group을 지우는데 왜 aws-auth가 수정되지? 하고 찾아보니

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/delete-managed-node-group.html

관리형 노드 그룹 삭제 - Amazon EKS

 

 

아..관리형 노드 그룹은 지울 때 aws-auth configmap까지 지우는게 맞았다. (관리를 너무 잘해도 문제다)

 

# 그래서 어떻게 지워?

노드그룹들을 모두 지운게 처음이라 이런 이슈도 처음 마주치게 되었는데,

이래서 기존 노드그룹을 어떻게 지워야 하는거지? 그냥 카펜터 롤을 다른거로 바꿔야 하나? 하고 고민을 하게 되었다.

 

일단 다행인 건, aws-auth에서 role이 지워져도, 실제로 노드가 지워지기까지는 시간이 꽤 걸렸다.

최소 3-5분정도는 걸린 것 같았다. 그 사이에 aws-auth를 수동으로 (또는 테라폼으로) 채워주면 아무 이슈 없이 ec2 node group만 삭제하는 것이 가능. (이 방법으로 dev, stage는 선작업했다.)

 

그러나 이런 살짝 불안한 방법을 production에도 적용할 수 없었기에…우선 aws support ticket을 올려보았다.

-> aws 답변을 요약하자면 아래와 같다.

• IAM Role mapping이 제거되면 그때부터 새로 생성되는 Node가 클러스터에 조인될 수 없습니다. 그리고 기존의 노드에 대해서는 약 5분 뒤에 'NotReady' 상태로 변경됩니다.
  • 즉, 내 말대로 aws-auth 수정이 일어나더라도 5분 내로 잽싸게 수정해버리면 문제가 없을거라는 것.
• EKS Authentication Mode에서 EKS API를 허용해주는 방법
  • EKS API로 노드 롤을 허용해주고 있으면 aws-auth에서 사라져도 권한이 유지될거라는 것.

 

오!! EKS API 버전의 Authentication Mode 기능이 생긴 것은 진작 알고 있었지만, 테라폼 모듈 고치기 귀찮아서 안보고 있었다.

 

요약하자면, 기존에는 k8s 권한을 aws iam이 갖기 위해 k8s의 aws-auth라는 configmap을 직접 수정해 주었다면, 이제 eks api로 해당 access control을 할 수 있게 된 것.

 

다행히도 기존 confgmap방식과 eks api 방식을 동시 허용해주는 옵션을 제공해주기 때문에 좀 더 안정적으로 auth 방식을 마이그레이션할 수 있다.

 

 

매우 쉽다.

- eks의 access configuration을 eks api & configmap으로 설정하고,

- node role을 EC2 Linux Type의 access entity로 등록시켜 두었다.

- 그리고 해당 클러스터의 aws-auth configmap에서 해당 롤을 지워보았다.

 

이렇게 설정해두니, aws-auth에서 node role이 사라지더라도 카펜터 노드들은 영향을 받지 않았다.

 

EKS API 방식 auth는 직접 해보니까 생각보다 훠어어어어얼씬 쉬웠다. 이제 얼른 다 갈아타야겠다.

 

끝!