강의

멘토링

로드맵

인프런 커뮤니티 질문&답변

devops님의 프로필 이미지
devops

작성한 질문수

CloudNet@ - Amazon EKS 기본 강의

[실습] 기본 네트워크 환경 확인 - 1

AWS VPC CNI의 ENI에서 질문이 있습니다.

작성

·

444

2

안녕하세요 강의 잘 음미하고 있습니다.

" Core DNS파드 배포시에 ENI slot에 Secondary IP가 전부 차 있는 것을 확인하고(실제로 파드가 사용은 안하고 있지만 L-IPAM의 warm pool에서 할당만 받은 상태) 이후 slot이 가득 차 있으므로 새로운 ENI를 생성한다. 따라서 2개의 ENI가 생긴다. " 라고 말씀해 주셨습니다.

그래서 노드 셀렉터걸어서 Core DNS 있는 노드에 배포해 봤는데, 첫 파드 생성 시에만 저 규칙(ENI 생성)이 적용되고, 계속해서 규칙대로 ENI가 생성되는 것은 아니고 기존 ENI 2개에 있는 Secondary IP를 가져다 쓰더라구요.

 

당연히 계속 ENI를 생성하는 건 비용 측면이나 네트워크 측면이나 비효율적이니 그러려니 싶겠는데, 노드에 첫 파드 생성 시에(aws-node, kube-proxy 제외)는 왜 항상 ENI가 1개는 추가로 생성되면서 시작하게 되는건가요? 그냥 ENI에 남은 IP가 있는데 쓰면 되지 않을까요?

 

감사합니다. 수업 내용이 꽤나 딥다이브해서 이게 이거구나 할 때가 많아서 좋습니다. ㅎㅎ

 

퀴즈

Amazon VPC CNI 환경에서 일반적인 애플리케이션 파드가 IP 주소를 할당받는 방식은 무엇일까요?

노드의 공인 IP를 공유해서 사용한다.

VPC 대역에서 할당된 고유한 사설 IP를 사용한다.

오버레이 네트워크를 통해 별도의 IP 대역에서 할당받는다.

호스트 네트워크 네임스페이스를 공유하며 노드 IP를 사용한다.

답변 2

0

안녕하세요. 강의 잘 듣고 있습니다.

저도 Secondary ENI가 최초 파드 생성 시에 생기고 이후 파드 생성 시에는 생기지 않는 점이 의문인 가운데 이 질문을 봤습니다.

 

제 생각에는 모든 slot이 유휴 상태인 ENI가 예비 목적으로 1개는 항상 남아있도록 하는 것이 원칙으로 적용되는 것 아닌가 싶습니다.

아래는 제가 참조한 문서입니다.

https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html

이 문서 상단의 The CNI plugin manages Elastic Network Interfaces (ENI) on the node. 로 시작하는 단락 내에서 아래 문장에 주목했습니다.

When a slot on an ENI has been assigned, the CNI may attach additional ENIs with warm pool of slots to the nodes.

The CNI also pre-allocates "warm" ENIs and slots for faster Pod startup.

slot이 할당될 때 추가적인 ENI를 만들 수도 있다는 점, 그리고 파드의 빠른 기동을 위해 warm ENI를 사전에 할당한다는 점을 알 수 있는데, 여기서 말하는 warm ENI가 단 한개의 slot도 할당되지 않은 예비 성격의 ENI이라는 생각이 들었습니다.

 

실제로 강의 eks 환경(t3.medium)에서 nginx deployment를 배포하고 replicas를 3씩 늘려봤는데, 한 노드에 6번째 파드가 생성될 때(aws-node, kube-proxy 제외) eth2가 추가 생성되었습니다.

그리고 aws 네트워크 인터페이스 창에서 확인결과 이 때 만들어진 네트워크 인터페이스의 Secondary IP는 어디에도 할당되지 않았습니다.

 

그래서 할당된 slot이 없는 ENI 1개를 유지하는 것이 원칙이라는 생각이 들었습니다.

제 생각이 잘못된 정보라면 언제든 말씀, 지적 부탁드립니다.

 

이 강의 덕분에 네트워크 공부도 되고 EKS에 대해서 자세히 알게 되어 좋습니다. 감사합니다.

Ongja_CloudNet@님의 프로필 이미지
Ongja_CloudNet@
지식공유자

안녕하세요. CloudNet@ 팀입니다.

 

먼저 강의 잘 들어주셔서 감사합니다.

 

최초 파드 생성 시 Secondary ENI가 생성되는 부분에 대해 작성하신 글 잘 보았습니다.

말씀대로 빠르게 ENI를 구성하기 위해 WARM ENI를 사전할당하는 부분은 맞는 것 같습니다.

ENI를 구성하는데 약 10초 정도의 시간이 필요하다고 하며 예비 성격으로 ENI를 미리 구성하는 것으로 보입니다.

 

실제 해당 값을 관장하는 vpc-cni의 파라미터가 있어 소개드립니다. (WARM_ENI_TARGET)

해당 파라미터는 기본 값으로 1로 설정되어 있습니다. 즉 최초 파드 생성 시 예비 성격의 ENI를 구성하고 유지하는 것이죠.

kubectl describe ds aws-node -n kube-system | grep WARM_ENI
---
      WARM_ENI_TARGET:                        1

 

테스트를 위해 해당 값을 0으로 변경해 보았는데요.

kubectl set env ds aws-node -n kube-system WARM_ENI_TARGET=0
---
daemonset.apps/aws-node env updated

 

최초 파드가 구성되어도 추가적인 Secondary ENI가 생성되지 않네요.

 

 

결론적으로 기본 값으로 WARM_ENI_TARGET이 1로 구성되어 최초 파드가 생성될 때 WARM ENI가 추가로 생성되는데... 이는 노드에서 ENI를 추가하는 딜레이를 애초에 해소하기 위해 미리 구성하는 것으로 보여집니다.

 

좋은 정보와 의견 감사합니다.

답변주신 내용을 읽고 파라미터가 있다는 것을 알고 나니, 제가 작성한 위 답변에서 ENI 1개유지 원칙이 아니라 WARM_ENI_TARGET 값만큼 예비 ENI를 만들어두는 것 같습니다.

해당 값을 1에서 2로 바꿔보았는데, 각 노드에 ENI가 추가로 생성되었습니다.

저의 글에 대해 자문자답할 겸 답글 남깁니다.

 

좋은 답변 감사드립니다.

devops님의 프로필 이미지
devops
질문자

잘 봤습니다 공부할 적 잘 몰라 넘어갔던 내용인데, 이렇게 해결해주셔서 감사드립니다.
다시 보니 또 재밌네요,,! 일하며 EKS를 만질 일은 없어 아쉽지만,,하하

0

Ongja_CloudNet@님의 프로필 이미지
Ongja_CloudNet@
지식공유자

안녕하세요. CloudNet@ 팀입니다.
먼저 강의 음미해 주셔서 감사드립니다!

저도 예전에 동일한 의문에 여러 루트로 알아보았지만 결국 답을 얻지는 못했네요..
제풀에 지쳐 결국 VPC CNI의 기본 설계라고 이해하고 넘어갔습니다.🥲

 

그래도 개인적으로 이유를 생각해보자면..
애초에 네트워킹 측면의 확장을 위해 Secondary ENI 추가를 원했고.. 최초 파드 생성 시 그러한 행위를 하도록 설계한 것일까?? 생각이 듭니다.
뭐 그냥 개인 생각입니다;;

감사합니다.

devops님의 프로필 이미지
devops

작성한 질문수

질문하기