网站建设推广渠道,小程序开发需求方案,wix如何做网站,oa系统运维系列文章
Nomad 系列文章
概述
Nomad 的网络和 Docker 的也有很大不同, 和 K8s 的有很大不同. 另外, Nomad 不同版本(Nomad 1.3 版本前后)或是否集成 Consul 及 CNI 等不同组件也会导致网络模式各不相同. 本文详细梳理一下 Nomad 的主要几种网络模式
在Nomad 1.3发布之前它自身并不支持发现集群中运行的其他应用程序。在集群中调度任务时这是一个非常基本的要求。Nomad依赖于Consul来发现其他“服务”并为注册和获取服务记录提供一流的支持这使得事情变得更容易。Consul通过各种机制提供记录例如REST APIDNS和Consul模板这些模板在可以注入到应用程序中的Go模板中呈现服务的确切IP/端口。
学习 Nomad 的一个难点在于, Nomad 往往和 Consul 一起运行, 那么对于这种情况来说一个主要的学习曲线是我们必须首先了解Consul是如何工作的部署一个Consul集群, 同时要融会贯通 2 个软件就很难了。Nomad 1.3 解决了这个问题的一部分即不需要运行Consul就可以进行基本的服务发现非常适合刚刚开始使用基于Nomad的网络。
场景一: 在主机上公开应用 从最简单的用例开始你有一个 redis 容器你想把它暴露给主机。 相当于我们想要做的docker run是
docker run --rm -p6379 redis
此命令公开主机上的动态端口。要查看端口号到底是什么您可以执行 docker ps 并在 PORTS 下找到类似于 0.0.0.0:49153-6379/tcp 的输出。
$ redis-cli -p 49153
127.0.0.1:49153 ping
PONG
那么, 在 Nomad 中相同的操作如何实现?
job redis {type servicegroup redis {network {mode hostport redis {to 6379}}task redis {driver dockerconfig {image redisports [redis]}}}
}
在几行配置中我们有一个正在运行的Docker容器它公开了一个动态端口 30627: 我们可以通过主机上的 redis-cli 连接到它
$ redis-cli -p 30627
127.0.0.1:30627 ping
PONG Warning 在 task.config 部分中有 ports 很重要。Nomad将此信息传递给主机上运行的 docker 守护进程。因此除非您指定在容器中通告哪些端口否则它不会知道是否要公开6379。 暴露静态端口
一种不太常见的情况是将应用程序绑定到主机上的静态端口, 只需在 port 块中添加一个 static 行 network {port redis {static 6379}} 当我们再次部署相同的文件时我们可以看到端口分配已经从动态端口更改为我们分配的静态端口。但是注意需要确保没有其他应用程序侦听同一接口和端口否则必然会导致冲突。
静态端口典型的使用场景就是: Ingress. 比如 Traefik 可以使用静态端口监听 80 和 443.
场景二: 与同一 Group 内的 Redis 通信
对于这个场景我们假设有一个应用程序需要与Redis通信。在这个场景中Redis用途是临时缓存所以可以将它们部署在同一个 Group 中。
一个 Group 可以包含多个 Task。这里需要知道的重要一点是同一 Group 将始终具有自己的共享网络命名空间(类似K8s中Pod中的多个Container具有共享网络命名空间)。这意味着如果您在组中有2个 Task则它们都可以访问相同的网络命名空间。这允许两个 Task 在同一网络接口上相互通信。
job hello {type servicegroup app {network {mode hostport app {static 8080}port redis {static 6379}}task redis {driver dockerconfig {network_mode hostimage redisports [redis]}}task app {driver dockerenv {DEMO_REDIS_ADDR ${NOMAD_ADDR_redis}}config {network_mode hostimage mrkaran/hello-app:1.0.0ports [app]}}}
}
详细说明如下:
您可以看到我们在同一 Group 下定义了 task app 和task redis 。这意味着Nomad将在同一客户端上共同定位这两个Task因为它们不仅倾向于共享相同的网络命名空间而且还共享公共分配目录-这使得跨任务共享文件变得非常容易。我们使用 NOMAD_ADDR_redis 来获取 redis task 的 IP:Port 组合。这在运行时由Nomad注入。您可以在这里找到运行时环境变量的列表。这是快速测试/开发设置的理想选择因为您不希望服务发现等问题并且希望以最小的代价连接到您的应用程序。
如果您要从基于 docker-compose 的环境迁移以上配置非常适合(但是实现还是不同, Nomad利用了主机网络)您可以将此模板用于您的服务。这种方法的最大限制是它使用主机网络。
场景三: 跨不同的 Group 进行通信
如上所述, 如果您有相关的 Task如init task您希望在 task 开始前获取文件同一个 Group 很有用(类似K8s Pod 的 init container)。但是使用 group 的缺点是您不能独立地扩展 task。在上面的例子中我们将Redis和App放在同一个 Group 中但这意味着如果你增加同一个 Group 的 count 来扩展 app你最终也会扩展Redis容器。这是不可取的因为Redis可能不需要与应用程序成比例地扩展。
创建多个 Group 的方法是将任务拆分到各自的组中
job hello {type servicegroup app {count 1network {mode hostport app {static 8080}}task app {driver dockerenv {DEMO_REDIS_ADDR localhost:6379}config {image mrkaran/hello-app:1.0.0ports [app]}}}group redis {count 1network {mode hostport redis {static 6379}}task redis {driver dockerconfig {image redisports [redis]}}}
}
提交此 Job 后您将获得2个分配ID每个 Group 会创建一个 alloc 。这里的关键点是这两个 Group 都有自己的网络命名空间。因此我们实际上没有任何方法可以访问其他应用程序我们不能向上面这样依赖主机网络因为无法保证这两个 Group 都部署在同一个节点上。
现在由于组是分开的 app 容器不知道 redis 反之亦然
env | grep NOMAD
NOMAD_REGIONglobal
NOMAD_CPU_LIMIT4700
NOMAD_IP_app127.0.0.1
NOMAD_JOB_IDhello
NOMAD_TASK_NAMEapp
NOMAD_SECRETS_DIR/secrets
NOMAD_CPU_CORES1
NOMAD_NAMESPACEdefault
NOMAD_ALLOC_INDEX0
NOMAD_ALLOC_DIR/alloc
NOMAD_JOB_NAMEhello
NOMAD_HOST_IP_app127.0.0.1
NOMAD_SHORT_ALLOC_IDa9da72dc
NOMAD_DCdc1
NOMAD_ALLOC_NAMEhello.app[0]
NOMAD_PORT_app8080
NOMAD_GROUP_NAMEapp
NOMAD_PARENT_CGROUPnomad.slice
NOMAD_TASK_DIR/local
NOMAD_HOST_PORT_app8080
NOMAD_MEMORY_LIMIT512
NOMAD_ADDR_app127.0.0.1:8080
NOMAD_ALLOC_PORT_app8080
NOMAD_ALLOC_IDa9da72dc-94fc-6315-bb37-63cbeef153b9
NOMAD_HOST_ADDR_app127.0.0.1:8080
服务发现
app Group 需要在连接到 redis 之前发现它。有多种方法可以做到这一点但我们将介绍两种更常见的标准方法。
使用 Nomad Native Service Discovery 这是在Nomad 1.3中推出的功能。在这次发布之前Nomad 不得不依靠 Consul 来完成这一任务。但是有了Nomad中内置的原生服务发现事情就简单多了。让我们对作业文件进行以下更改。在每个 Group 中我们将添加一个 service 定义 group app {count 1network {mode hostport app {to 8080}}service {name appprovider nomadport app}// task is the same}group redis {count 1network {mode hostport redis {to 6379}}service {name redisprovider nomadport redis}// task is the same}
如上我们添加了一个新的 service 块并删除了 static 端口。当我们使用服务发现时不需要绑定到静态端口。
提交作业后我们可以使用 nomad service list 命令确保服务已注册到Nomad。
nomad service list
Service Name Tags
app []
redis []
要了解特定服务的详细信息我们可以使用 nomad service info
$ nomad service info app
Job ID Address Tags Node ID Alloc ID
hello 127.0.0.1:29948 [] d92224a5 5f2ac51f
$ nomad service info redis
Job ID Address Tags Node ID Alloc ID
hello 127.0.0.1:22300 [] d92224a5 8078c9a6
如上, 我们可以看到每个服务中的动态端口分配。要在我们的应用程序中使用此配置我们将其模板化 task app {driver dockertemplate {data EOH
{{ range nomadService redis }}
DEMO_REDIS_ADDR{{ .Address }}:{{ .Port }}
{{ end }}
EOHdestination secrets/config.envenv true}config {image mrkaran/hello-app:1.0.0ports [app]}}
我们添加了 template 节它将在容器中插入环境变量。我们遍历 nomadService 并获取 redis 服务的地址和端口。这使得其他节点上的任务可以方便地发现彼此。
使用 Consul 服务发现 只需调整 service 块中的 provider 我们就可以使用Consul代理进行服务发现。 service {name appprovider consulport app}task app {driver dockertemplate {data EOH
{{ range service redis }}
DEMO_REDIS_ADDR{{ .Address }}:{{ .Port }}
{{ end }}
EOH Warning: 注意 range nomadService 也改为了 range service 前提是要确保正在运行Consul并已将Nomad连接到它。具体请参阅该文档。
其余的事情几乎保持不变。只用两行代码就可以在Nomad/Consul之间切换来发现服务。
另外, 使用Consul会有更多的优势
可以使用DNS查询服务的地址
doggo redis.service.consul tcp://127.0.0.1:8600
NAME TYPE CLASS TTL ADDRESS NAMESERVER
redis.service.consul. A IN 0s 172.20.10.3 127.0.0.1:8600
可由Nomad以外的应用程序访问。如果 consul 被Nomad集群外的其他应用程序使用它们仍然可以获得对应的地址使用DNS或REST API
当然Nomad Native Service Discovery 非常适合本地/边缘环境设置甚至是生产中的较小用例因为它不再需要 Consul
场景四: 限制对某些 Namespace 的访问 在上述所有场景中我们发现服务会暴露给本地Nomad客户端。如果您在集群上运行多个 Namespace您可能希望根本不公开它们。此外您可能希望表达应用程序可以访问特定服务的细粒度控制。所有这些都可以通过服务网格实现。Nomad提供了一种通过Consul Connect建立“服务网格”的方法。Consul Connect可以进行mTLS和服务授权。在引擎盖下它是一个与您的应用程序一起运行的Envoy代理或sidecar。 Consul 代理为您配置Envoy配置因此这一切都非常无缝。
要做到这一点我们首先需要的是 bridge 网络模式。此网络模式实际上是一个CNI插件需要在 /opt/cni/bin 中单独安装。按照这里提到的步骤: network {mode bridgeport redis {to 6379}}
Redis 中的服务被 Consul Connect Ingress 所调用 service {name redisprovider consulport 6379connect {sidecar_service {}}}
这是一个空块因为我们不需要在这里定义任何上游。其余值将为默认值。
接下来我们为 app 创建一个服务这是一个Consul Connect Egress service {name appprovider consulport appconnect {sidecar_service {proxy {upstreams {destination_name redislocal_bind_port 6379}}}}}
这里我们为 redis 定义一个上游。在这里当 app 想要与redis通信时它会与 localhost:6379 对话这是Envoy sidecar正在监听的本地端口。我们可以使用 netstat 来验证
$ netstat -tulpvn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.2:19001 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:23237 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN -
tcp6 0 0 :::8080 :::* LISTEN 1/./hello.bin
流量从这个端口发送到它通告的端口上的另一个Envoy代理并且Consul自动配置。该Envoy代理进一步将流量发送到端口6379上的 redis 容器。代理流量通过mTLS进行安全加密并授权通过Consul Intentions -本文不做介绍。
场景五: 向最终用户公开服务 在第一个场景中我们讨论了如何使用静态端口。事实证明如果你想定义一个Traffic Ingress服务它非常有用。与K8s不同的是Nomad没有任何Ingress Controller所以最好的方法是将这些Web代理作为 system job 部署在每个节点上这意味着它可以确保在每个客户端节点上运行并将它们绑定到静态端口比如443/80。然后配置 LB 并将所有Nomad节点注册为 Target IP其端口将是您定义的静态端口。这些Ingress代理比如Traefik/Nginx可以通过上面提到的任何模式与您的应用程序通信。 Notes: 在上一篇文章中, 我们并没有配置 LB 后面对接所有 Traefik. 相反, 我们直接访问某一个特定节点的 Traefik 的 80/443 端口. 通常您希望为入口代理使用“基于主机”的路由模式来做出路由决策。
例如如果您有一个指向ALB的 a.example.org DNS记录。现在当请求到达ALB时它会转发到任何一个Traefik/NGINX。为了使 NGINX 正确地将流量路由到a service您可以使用“Host”报头。
总结
这些是我所知道的一些常见的网络模式。由于其中一些概念并不是非常简单我希望解释有助于带来一些清晰。
关于这个主题还有很多比如 Consul Gateway 和多种CNI它们可以调整集群中的网络的底层细节但这些都是一些非常高级的主题超出了本文的范围。后续有机会可以再做展开.
️参考文档
Understanding Nomad Networking Patterns - YouTubeUnderstanding Networking in Nomad | Karan Sharma (mrkaran.dev) 三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.
