프로필사진

Go, Vantage point

가까운 곳을 걷지 않고 서는 먼 곳을 갈 수 없다.


Github | https://github.com/overnew/

Blog | https://everenew.tistory.com/





티스토리 뷰

반응형

 

 

ECS의 태스크를 정의할 때 네트워크 모드를 선택하게 된다.

AWS에서는 특별한 이유가 없다면 awsvpc를 권장하는데, 네트워크 모드마다 어떤 식으로 차이점이 있는지 살펴보자.

 

 

 

1. awsvpc 모드

awsvpc는 EC2와 동일한 네트워크 속성을 사용한다. 각 태스크에 ENI를 통해 private IPv4 주소가 부여되기 때문에, EC2에서 사용하던 방식대로 ECS의 각 태스크를 사용할 수 있게 된다.

단, 태스크의 ENI는 조작할 수 없고 태스크 중지 시 자동으로 분리/삭제된다.

 

 

이때 ECS 컨테이너 에이전트가 각 태스크에 대한 pause 컨테이너를 생성하기 때문에, 같은 태스크의 컨테이너들은  pasuse 컨테이너를 통해 네트워크 네임스페이스를 공유한다.

따라서 같은 태스크 내의 컨테이너는 동일한 ENI의 IP를 사용할 수 있다.

 

 

pasue 컨테이너에 대해서의 아래의 게시글을 참조하자.

 

https://everenew.tistory.com/382

 

Kubernetes Namespaces VS Linux Namespaces (Pause 컨테이너)

쿠버네티스 네임스페이스 네임스페이스는 쿠버네티스에서 용도에 따라서 리소스를 논리적으로 구분하기 위해 사용하는 오브젝트이다. 리눅스의 네임스페이스와 같은 이름이기 때문에 동일한

everenew.tistory.com

 

 

결과적으로 각 태스크별 ENI가 할당되므로 보안그룹을 통한 네트워크 제한이 편리하다.

또한 아래의 모드 설명을 보면 알 수 있겠지만, Host EC2의 접근이 없도록 Fargate에서는 awsvpc만을 사용할 수 있다.

 

 

단, EC2의 유형별로 연결 가능한 ENI 개수에 한계가 있다.

이를 고려하기 싫다면 Fargate를 사용할 수 있지만, 비용 자체는 EC2를 호스트로 ECS를 제공하는 것보다는 비싸다.

 

 

 

2. host 모드

 

host 모드는 호스트인 EC2 인스턴스와 컨테이너가 연결되어 사용하는 네트워크 모드이다.

 

host모드를 사용하면 아래의 그림처럼, EC2의 ENI의 IP로 컨테이너가 트래픽을 수신할 수 있다.

아래의 그림에서는 3000번 포트로의 수신된 EC2 트래픽은 포트 바인딩을 통해 해당 컨테이너에게 전달된다. 

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-host.html

 

 

단, host 모드를 사용하면 같은 Instance의 컨테이너 간에는 포트 바인딩이 달라야만 한다.

또한 포트 충돌을 관리해주지 않기 때문에 수동으로 관리해야 한다.

 

컨테이너가 같은 IP를 가지기 때문에 127.0.0.1과 같은 로컬 호스트로 통신할 수 있기 때문에, 네트워크 격리가 이루어지지 않아 보안적으로도 문제가 있다고 한다.

 

 

이처럼 호스트 EC2 인스턴스에 대한 접근이 진행되므로 Fargate에서는 사용할 수 없다.

 

 

 

 

3. bridge 모드 

bridge 모드에서는 가상 네트워크 브리지를 통해 중간 계층을 만들어, host 모드에서 발생하는 포트 충돌 문제를 해결할 수 있다.

 

bridge 모드에서 정적으로 포트를 매핑하면, 이제는 3000번 포트로 수신하는 컨테이너에게 80번 포트에서 listening 하여 트래픽을 전달할 수 있다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-bridge.html

 

 

 

 

동적 포트 매핑을 사용하면, 임의로 할당된 호스트의 포트를 사용해 컨테이너에게 전달할 수 있다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-bridge.html

 

이를 통해 host 모드에서 발생하는 포트 충돌 문제를 해결할 수 있다.

 

포트가 임의로 정해지는 경우, ELB로 트래픽 전달을 일일이 세팅하기 힘들 수 있다.

따라서 ELB의 대상그룹에 자동으로 P 주소 및 포트 목록을 업데이트하도록 서비스를 지원하고 있다.

 

단, 임의의 포트 범위를 사용하므로 포트를 통한 네트워크 제한이 어렵다.

이런 이유로 NACL도 결국 넓은 포트 범위를 열어줘야 하기 때문에 실무에서도 NACL의 세팅하기 어렵다고 한다.

 

 

Birdge도 동일하게 EC2 host까지의 세팅이므로 Fargate에서는 사용할 수 없다.

 

 

 

 

 

정리

 

기본적으로 docker는 bridge모드를 통해 네트워크를 제공하므로, docker를 사용해 보았다면 가장 익숙한 모드이다.

host 모드는 이러한 docker의 기본 가상 네트워크 우회해서 제공된다.

 

결국에는 awsvpc가 AWS의 네트워크 설계에 따라 보안그룹과 같은 서비스를 제대로 활용할 수 있기 때문에, 관리측면에서는 awsvpc를 권장되는 듯하다.

 

 

 

 

 

 

참조

AWS 공식 문서

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/task-networking-awsvpc.html

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-host.html

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-bridge.html

 

 

반응형
댓글
반응형
인기글
Total
Today
Yesterday
«   2024/10   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
글 보관함