[AWS]Fargate网络

Task Networking in AWS Fargate

本章节内容编译自这篇官方博客。

跑Fargate的第一步是定义ECS Task. Task是一个Logical Group，由一或多个Docker container组成，根据特定配置进行部署。当跑Fargate Task时，需要考虑两种类型的网络：

• Container (local) networking
• External networking

Container Networking

通常用于tightly coupled application components.比方服务静态内容同时需要生成动态页面的应用，把web tier和 api tier放一起，用local networking，这样web tier可以从api tier拿信息。单机下，web tier application process可以和API process在同一机器内通过local loopback interface交互。local loopback interface有一个特殊的IP 127.0.0.1和hostname of localhost。通过向这个local interface发送networking requests, 它bypass了network interface的硬件，由OS把network call由一个process直接route至另一个process，高效且近乎无延迟。

在Fargate中，当你把多容器放入同一个Task发布时，容器之间也可以通过local loopback interface通信。Fargate采用了awsvpc的网络模式，给了所有同任务内的容器一个共享的elastic network interface（ENI）用以通信。

如果你定义了task中每个容器的port mapping, 那容器们可借由那个端口进行通信，比如下面的task definition:

---
family: myapp
containerDefinitions:
- name: web
  image: my web image url
  portMappings:
  - containerPort: 80
  memory: 500
  cpu: 10
  esssential: true
- name: api
  image: my api image url
  portMappings:
  - containerPort: 8080
  cpu: 10
  memory: 500
  essential: true

ECS Fargate可以由此definition部署两个容器，每个bounded to ENI上特定的static port

因为每个Fargate Task有自己独立的网络stack，所以无需像其他网络模式那样通过dynamic ports来避免端口冲突。Static port让容器间通信更加方便，比如下面的web container通过已知端口向api container发送如下request:

curl 127.0.0.1:8080/my-endpoint

这个命令发送local network请求，直接经由local loopback ingerface到另一个容器，没有遍历网络，实现在紧密耦合容器间的快速高效通信。

External Networking

要谈外部网络得先从VPC说起：

When setting up a VPC, you create one or more subnets, which are logical groups that your resources can be placed into. Each subnet has an Availability Zone and its own route table, which defines rules about how network traffic operates for that subnet. There are two main types of subnets: public and private.

Public subnet：

在Public subnet里的Fargate task会被同时分配Private和Public IP。

• 浏览器/客户端可以经由internet gateway，通过ENI的Public IP向task发送信息。
• Task可以向其他互联网服务器发送请求，因为一切traffic都由internet gateway路由。
• 如果Task需要彼此通信，可以用彼此的Private IP, 这样traffic在subnet内部，不需要出去internet gaway再绕回来。

Private subnet：

Private subnet没有直接的internet access。此内的Fargate task没有Public IP只有Private IP。不同于连接了Internet Gateway, NAT Gateway被attached在了subnet。
互联网外部服务器和客户端无法直接连接到你的tasks,因为连地址和direct route都没有。这可以保护敏感数据，免受任何inbound traffic。
在此配置下，task还是可以通过NAT Gateway和互联网通信。如果你在private subnet里跑task， 必须加上NAT Gateway, 不然甚至无法联系到ECR下载容器镜像，或者和Cloudwatch输送容器metrics。

Load balancers

如果private subnet容器需要承接internet content，需要能实现public到各容器的traffic。通常由ALB或者NLB完成。

ECS和LB紧密整合，自动配置service-linked LB给容器发送network traffic。当task发动时，它ENI的IP address会被添加至LB的配置。

如果用LB让internet traffic达到容器，LB要放置在public subnet。ECS配置LB把traffic传递至private subnet的容器任务，如下图。

另一种情况则是内部通信，比方微服务中内外网的通信。可以通过在private subnet里放internal LB来实现，如下图。

拓展阅读

1. Task Networking with the awsvpc Network Mode
   这部分官方文档介绍了ECS的awsvpc Network Mode和使用考量和细节，翻译总结如下：

• 跑awsvpc模式的Task和Services需要ECS service-linked role。这个role在创建集群时自动生成。
• 如果所在VPC上enableDnsHostnames和enableDnsSupport选项被开启，那ECS Task的hostname会由Amazon提供的（内部）DNS hostname生成；反之随机生成。
• 目前只有Amazon ECS-optimized AMI的Linux变种，或者带有ecs-initpackage的Amazon Linux变种支持task networking
• Fargate tasks可以接受public IP address
• 目前跑awsvpc模式的task和任务有16个subnet和5个security group的上限。
• 由ECS生成和attach的ENI无法人工detach或修改，主要是为了防止误删导致task停跑。
• (一个实现细节)当使用awsvpc网络模式启动task时，ECS container agent会在启动任务定义中的container之前为每个task创建一个额外的pausecontainer。它通过执行amazon-ecs-cni-plugins CNI插件来配置pausecontainer的namespace。然后agent再启动任务中的其余container，以便它们共享pausecontainer的network stack。这意味着任务中的所有容器均可通过ENI的IP地址进行寻址，并且它们可以通过localhost interface相互通信。
• Task是awsvpc模式的service只支持ALB和NLB，不支持Classic。并且，当为服务创建target group时，必须选择ip作为target type, 而不是instance，因为在awsvpc模式跑的tasks是和ENI associate起来的，而不是和EC2。
• 如果VPC更新，比方更改了DHCP options set, 要让task pick up这些更改，需要停了老的task部署新的。

2. NetworkMode from ECS TaskDefinition Properties
   这段是Cloudformation里ECS TaskDefinition属性里的网络模式部分，对照参考

   The Docker networking mode to use for the containers in the task. The valid values are none, bridge, awsvpc, and host.
   The default Docker network mode is bridge.

   • If you are using the Fargate launch type, the awsvpc network mode is required.
   • If you are using the EC2 launch type, any network mode can be used.
   • If the network mode is set to none, you cannot specify port mappings in your container definitions, and the tasks containers do not have external connectivity.

   The host and awsvpc network modes offer the highest networking performance for containers because they use the EC2 network stack instead of the virtualized network stack provided by the bridge mode.

   With the host and awsvpc network modes, exposed container ports are mapped directly to the corresponding host port (for the host network mode) or the attached elastic network interface port (for the awsvpc network mode), so you cannot take advantage of dynamic host port mappings.

   If the network mode is awsvpc, the task is allocated an elastic network interface, and you must specify a NetworkConfiguration value when you create a service or run a task with the task definition. For more information, see Task Networking in the Amazon Elastic Container Service Developer Guide.

   Note
   Currently, only Amazon ECS-optimized AMIs, other Amazon Linux variants with the ecs-init package, or AWS Fargate infrastructure support the awsvpc network mode.

   If the network mode is host, you cannot run multiple instantiations of the same task on a single container instance when port mappings are used.

   Docker for Windows uses different network modes than Docker for Linux. When you register a task definition with Windows containers, you must not specify a network mode. If you use the console to register a task definition with Windows containers, you must choose the network mode object.

   For more information, see Network settings in the Docker run reference.

   Required: No

   Type: String

   Allowed Values: awsvpc | bridge | host | none

   Update requires: Replacement

References:
https://aws.amazon.com/blogs/compute/task-networking-in-aws-fargate/