배경
클라우드 클럽에서 오픈소스 코드분석 스터디에 들어갔고, 오픈소스로 Flannel이 선정되었다. 네트워크에 대해서 깊이 있게 알지 못했는데 이런 오픈소스 분석을 할 수 있을지.. 고민도 되지만 크게 배울 수 있는 좋은 기회인 것 같다!
처음에 내가 맡은 부분은 pkg/backend/extension 부분이다. 관련 코드를 분석하고 공부한 내용을 남겨보고자 한다
파드 간 통신을 위한 CNI
Flannel은 Kubernetes 클러스터에서 네트워크를 구성하기 위한 CNI(Container Network Interface) 플러그인 중 하나이다.
코드분석부터 하기전에.. CNI라는것은 왜 필요하게 된 것일까? 이 부분에 대해 확실히 짚고 넘어가자
애플리케이션이 돌아가려면 컴퓨팅 리소스가 필요하고 쿠버네티스에서 애플리케이션이 배포되는 워크로드 단위는 파드이다. 그래서 EKS 상에서 EC2(노드)에 파드가 스케줄링 되어 애플리케이션을 실행할 수 있게 된다.
EKS는 여러 노드들로 구성되므로, 서로 다른 노드들에서 배정된 파드들끼리는 통신을 할 수 밖에 없다. 사용자 요청을 처리하는 프론트엔드 파드가 한 노드에, 데이터베이스 파드가 다른 노드에 있을 때, 프론트엔드 파드가 데이터베이스 파드에 접근하려면 네트워크를 통해 서로를 식별하고 통신해야 한다..
"네트워크를 통해 서로를 식별하고 통신한다" -> 이걸 하려면 구체적으로 어떤 것들이 필요할까?
1. 고유한 IP 주소
네트워크에서 자원을 구분하는 간단 명료한 방법은 IP를 가지는 것이다. 그래서 각 파드는 네트워크 내에서 고유한 IP 주소를 가지게 설계되었다.
그럼 이 IP는 누가 주는 것일까? EKS의 경우는 노드에 연결된 ENI가 서브넷 내 IP 주소를 파드에 제공한다. 이를 통해 파드가 AWS VPC 내에서 직접 IP 기반으로 통신할 수 있고, 클러스터 내 파드 간 네트워크 연결을 효율적으로 관리할 수 있게 된다.
2. DNS와 서비스 이름
docker에서 network내에서 컨테이너 이름으로 DNS 처리가 가능했듯이 쿠버네티스의 파드 간 통신을 더 쉽게 하려면 DNS와 서비스 이름이 필요하다. 서비스 이름을 사용하면 파드 IP가 바뀌더라도 고정된 이름을 통해 접근할 수 있기 때문이다!
3. 패킷 라우팅
파드가 여러 노드에 걸쳐 분산 배치되면, 데이터 패킷이 어느 경로를 따라 전달되어야 하는지 알아야한다.. 좀 더 구체적으로는 Linux 커널의 라우팅 테이블을 구성하는 것이다. 라우팅 테이블 항목은 목적지 IP와 그 목적지로 트래픽을 보내기 위해 사용할 인터페이스(네트워크 카드 등)를 정의한다.
네트워크 구성의 표준화 필요성
서로 다른 노드에 있는 파드끼리 통신하려면 각 노드마다 이러한 네트워크 설정을 일일이 하는 것은 지옥에 가깝고.. 무엇보다 사람마다, 조직에 따라 구성 방식이 달라질 수 있다는 문제가 있다. 그래서 이런 네트워크 구성을 표준화를 해놓은 양식을 Container Network Interface 라고 하는 것이다!
그리고 CNI를 구현하는 오픈소스들이 등장했고 그 중 하나가 Flannel 인 것 ..!
기본적으로 EKS를 구성하면 이 CNI 플러그인으로 AWS VPC CNI가 파드간 통신을 위한 네트워크 구성 요소들을 자동으로 만들어주게 된다...!
kube-system에서 aws-node 이름으로 실행중인 파드들은 파드에 IP 주소를 할당하고.. ENI(Elastic Network Interface)를 관리하고.. 노드의 라우팅 테이블 설정 하는 등의 역할을 충실히 하고 있다 !
AWS VPC CNI 플러그인을 사용하면, 각 노드에 ENI(Elastic Network Interface)가 할당되고, 이 ENI는 AWS VPC의 서브넷 내에서 IP 주소를 할당받아온다.
ENI에는 Primary IP와 Secondary IP가 있으며, AWS VPC CNI는 ENI의 Secondary IP들을 각각의 파드에 할당한다. 그래서 각 파드는 고유한 IP를 가지게 되어, VPC 내에서 다른 파드들과 IP 기반 통신이 가능하다.
