标签 容器 下的文章

构建Kubernetes集群 – 选择工作节点大小

近期learnk8s网站上发布了一些关于k8s的好文章,这里搬运并翻译了一些,供大家参考。

本文翻译自《Architecting Kubernetes clusters — choosing a worker node size》

img{512x368}

当您创建Kubernetes集群时,冒出的第一个问题之一是:“我应该使用哪种类型的工作节点以及需要多少个这样的节点”。

如果您正在构建在内部部署的k8s集群,是应该订购一些最近一代的新服务器,还是使用数据中心内的十几台旧机器?

或者,如果您使用Google Kubernetes Engine(GKE)等托管Kubernetes服务,您是否应该使用八个n1-standard-1或两个n1-standard-4实例来实现所需的计算能力呢?

集群容量

通常,Kubernetes集群可以被视为将一组单个节点抽象为一个大的“超级节点”。

该超级节点的总计算容量(就CPU和内存而言)是所有组成节点容量的总和。

有多种方法可以实现集群的所需目标容量。

例如,假设您需要一个总容量为8个CPU内核和32 GB RAM的集群。

例如,因为要在集群上运行的应用程序集需要如此数量的资源。

以下是设计集群的两种可能方法:

img{512x368}

这两个选项都会产生具有相同容量的集群 – 但左侧选项使用4个较小的节点,而右侧选项使用2个较大的节点。

哪个更好?

为了解决这个问题,让我们来看看“少数大节点”和“许多小节点”这两个相反方向思路的优缺点。

请注意,本文中的“节点”始终指的是工作节点(worker node)。master节点的数量和大小的选择是完全不同的话题。

使用少量大节点

这方面最极端的情况是仅使用一个可以提供整个所需集群容量的工作节点。

如果要满足上面的示例中容量的需求,这将是一个具有16个CPU内核和16 GB RAM的单个工作节点。

让我们来看看这种方法可能具有的优势。

1. 减少管理成本

简单地说,管理少量机器比管理大量机器要更省力。

更新和补丁可以更快地应用,机器可以更容易保持同步。

此外,对于机器数量少而言,预期故障的绝对数量要小于机器数量多的情况。

但请注意,这主要适用于裸机服务器而不适用于云实例。

如果您使用云实例(作为托管Kubernetes服务的一部分或您在云基础架构上安装的Kubernetes),则将底层机器的管理外包给云提供商。

因此,管理云中的10个节点并不比管理云中的单个节点成本多得多。

2. 每个节点的成本更低

虽然更强大的机器比低端机器更昂贵,但价格上涨不一定是线性的。

换句话说,具有10个CPU内核和10 GB RAM的单台机器可能比具有1个CPU内核和1 GB RAM的10台机器便宜。

但请注意,如果您使用云实例,这可能同样不适用。

在主要云提供商Amazon Web Services,Google Cloud Platform和Microsoft Azure的当前定价方案中,实例价格是随容量线性增加的。

例如,在Google Cloud Platform上,64个n1-standard-1实例的成本与单个n1-standard-64实例完全相同- 两个选项都为您提供64个CPU内核和240 GB内存。

因此,在云中,您通常无法通过使用更大的机器来节省成本。

3. 允许运行资源消耗较大的应用程序

拥有大型节点可能只是您要在集群中运行一类应用程序的要求。

例如,如果您有一台需要8 GB内存的机器学习应用程序,你无法在仅具有1 GB内存的节点的集群上运行它。

但是,您可以在具有10 GB内存节点的群集上运行它。

看过优势后,让我们再来看看其弊端又是什么。

1. 每个节点有大量的pod

在较少的节点上运行相同的工作负载自然意味着在每个节点上运行更多的pod。

这可能成为一个问题。

原因是每个pod都会在节点上运行的Kubernetes代理上引入一些开销 – 例如容器运行时(例如Docker),kubelet和cAdvisor。

例如,kubelet对节点上的每个容器执行常规活动和就绪探测 – 更多容器意味着在每次迭代中kubelet需要做更多的工作。

cAdvisor收集节点上所有容器的资源使用统计信息,并且kubelet定期查询此信息并通过其API发布它 – 再次,这意味着每次迭代中cAdvisor和kubelet的工作量都会增加。

如果pod的数量变大,这些东西可能会开始减慢系统速度,甚至使系统变得不可靠。

img{512x368}

issue称节点因常规的kubelet运行状况检查花费了太长时间来迭代节点上的所有容器而导致节点处于非就绪状态。

出于这些原因,Kubernetes 建议每个节点最多110个pod

针对这个数字,Kubernetes已经做过测试,结果证明是可以在通常节点类型上可靠地工作的。

根据节点的性能,您可能能够成功地为每个节点运行更多的pod – 但这依然很难预测事情是否会顺利运行,又或您将遇到问题。

大多数托管Kubernetes服务甚至对每个节点的pod数量施加了严格的限制:

  • 在Amazon Elastic Kubernetes Service(EKS)上,每个节点的最大pod数取决于节点类型,范围从4到737。
  • 在Google Kubernetes Engine(GKE)上,无论节点类型如何,每个节点的限制为100个pod。
  • 在Azure Kubernetes服务(AKS)上,默认限制是每个节点30个pod,但最多可以增加到250个。

因此,如果您计划为每个节点运行大量pod,则应该事先测试事情是否能按预期工作。

2. 有限的复制

少量节点可能会限制应用程序的有效复制程度。

例如,如果您有一个由5个副本组成的高可用性应用程序,但您只有2个节点,那么应用程序的有效复制程度将减少到2。

这是因为5个副本只能分布在2个节点上,如果其中一个失败,它可能会同时删除多个副本。

另一方面,如果您有至少5个节点,则理想情况下每个副本可以在单独的节点上运行,并且单个节点的故障最多只会删除一个副本。

因此,如果您具有高可用性要求,则可能需要对集群中的最小节点数提出要求。

3. 更大的爆破半径

如果您只有几个节点,那么失败节点的影响比您有许多节点的影响要大。

例如,如果您只有两个节点,并且其中一个节点出现故障,那么大约一半的节点会消失。

Kubernetes可以将失败节点的工作负载重新安排到其他节点。

但是,如果您只有几个节点,则风险更高,因为剩余节点上没有足够的备用容量来容纳故障节点的所有工作负载。

结果是,部分应用程序将永久停机,直到再次启动故障节点。

因此,如果您想减少硬件故障的影响,您可能希望选择更多的节点。

4. 大比例增量

Kubernetes 为云基础架构提供了一个Cluster Autoscaler,允许根据当前需求自动添加或删除节点。

如果使用大型节点,则会有大的缩放增量,这会使缩放更加笨重。

例如,如果您只有2个节点,则添加其他节点意味着将群集容量增加50%。

这可能比您实际需要的多得多,这意味着您需要为未使用的资源付费。

因此,如果您计划使用集群自动缩放,则较小的节点允许更流畅且经济高效的缩放行为。

在讨论了使用”很少几个大节点”的方案的优缺点之后,让我们转向”许多小节点”的场景。

使用大量小节点

这种方法包括从许多小节点而不是几个大节点中形成集群。

这种方法的优点和缺点是什么?

使用许多小节点的优点主要对应于使用少量大节点的缺点。

1. 较小的爆破半径

如果您有更多节点,则每个节点上的pod自然会更少。

例如,如果您有100个pod和10个节点,则每个节点平均只包含10个pod。

因此,如果其中一个节点发生故障,则影响仅限于总工作负载的较小比例。

有可能只有一些应用程序受到影响,并且可能只有少量副本,因此整个应用程序都会保持运行状态。

此外,剩余节点上的备用资源很可能足以容纳故障节点的工作负载,因此Kubernetes可以重新安排所有pod,并且您的应用程序可以相对快速地返回到完全正常运行的状态。

2. 允许高可复制性

如果您有高可用性需求的应用程序和足够的可用节点,Kubernetes调度程序可以将每个副本分配给不同的节点。

您可以通过节点亲缘关系pod亲和力/反亲和力以及taint和tolerations来影响调度程序对pod放置位置的选择。

这意味着如果某个节点出现故障,则最多只有一个副本受影响且您的应用程序仍然可用。

看到使用许多小节点的优点,那它有什么缺点呢?

1. 节点数量大

如果使用容量较小的节点,则自然需要更多节点来实现给定的集群容量。

但是大量节点对Kubernetes控制平面来说可能是一个挑战。

例如,每个节点都需要能够与每个其他节点通信,这使得可能的通信路径数量以节点数量的平方的量级增长 – 所有节点都必须由控制平面管理。

Kubernetes控制器管理器中的节点控制器定期遍历集群中的所有节点以运行运行状况检查 – 更多节点意味着节点控制器的负载更多。

更多节点意味着etcd数据库上的负载也更多 – 每个kubelet和kube-proxy都会导致etcd的观察者(watch)客户端(通过API服务器),etcd必须广播对象更新。

通常,每个工作节点都会给主节点上的系统组件增加一些开销。

img{512x368}

据官方统计,Kubernetes声称支持最多5000个节点的集群

然而,在实践中,500个节点可能已经构成了较大的挑战

通过使用性能更高的主节点,可以减轻大量工作节点的影响。

这就是在实践中所做的 – 这里是kube-up在云基础架构上使用的主节点大小

  • Google云端平台
    • 5个工作节点→ n1-standard-1主节点
    • 500个工作节点→ n1-standard-32主节点
  • 亚马逊网络服务
    • 5个工作节点→ m3.medium主节点
    • 500个工作节点→ c4.8xlarge主节点

如您所见,对于500个工作节点,使用的主节点分别具有32和36个CPU核心以及120 GB和60 GB内存。

这些都是相当大的机器!

因此,如果您打算使用大量小节点,则需要记住两件事:

  • 您拥有的工作节点越多,您需要的性能就越高
  • 如果您计划使用超过500个节点,则可能会遇到一些需要付出一些努力才能解决的性能瓶颈

Virtual Kubelet这样的新项目允许绕过这些限制,并允许具有大量工作节点的集群。

2. 更多系统开销

Kubernetes在每个工作节点上运行一组系统守护进程 – 包括容器运行时(例如Docker),kube-proxy和包含cAdvisor的kubelet。

cAdvisor包含在kubelet二进制文件中。

所有这些守护进程一起消耗固定数量的资源。

如果使用许多小节点,则这些系统组件使用的资源部分比例会更大。

例如,假设单个节点的所有系统守护程序一起使用0.1个CPU内核和0.1 GB内存。

如果您拥有10个CPU核心和10 GB内存的单个节点,那么守护程序将占用集群容量的1%。

另一方面,如果您有1个CPU核心和1 GB内存的10个节点,则后台程序将占用集群容量的10%。

因此,在第二种情况下,10%的账单用于运行系统,而在第一种情况下,它只有1%。

因此,如果您希望最大化基础架构支出的回报,那么您可能更喜欢更少的节点。

3. 降低资源利用率

如果您使用较小的节点,那么最终可能会有大量资源片段太小而无法分配给任何工作负载,因此保持未使用状态。

例如,假设您的所有pod都需要0.75 GB的内存。

如果你有10个1 GB内存的节点,那么你可以运行10个这些pod – 你最终会在每个节点上有一块0.25 GB的内存,你不能再使用它了。

这意味着,集群总内存的25%被浪费了。

另一方面,如果您使用具有10 GB内存的单个节点,那么您可以运行13个这样的pod – 而只有0.25 GB的单块内存剩下无法使用。

在这种情况下,您只会浪费2.5%的内存。

因此,如果您想最大限度地减少资源浪费,使用更大的节点可能会提供更好的结果。

4. 小节点上的Pod限制

在某些云基础架构上,小节点上允许的最大pod数量比您预期的要限制得多。

Amazon Elastic Kubernetes Service(EKS)就是这种情况,其中每个节点的最大pod数取决于实例类型。

例如,对于一个t2.medium实例,pod的最大数量是17,因为t2.small它是11,而t2.micro它是4。

这些都是非常小的数字!

任何超出这些限制的pod都无法由Kubernetes调度程序安排,这些pod会一直保持在Pending状态。

如果您不了解这些限制,则可能导致难以发现的错误。

因此,如果您计划在Amazon EKS上使用小节点,请检查相应的每节点pods数,并多算几次计算节点是否可以容纳所有pod。

结论

那么,您应该在集群中使用少量大型节点还是许多小型节点?

一如既往,没有明确的答案。

您要部署到集群的应用程序类型可能会指导您的决策。

例如,如果您的应用程序需要10 GB内存,则可能不应使用小节点 – 集群中的节点应至少具有10 GB内存。

或者,如果您的应用程序需要10倍的复制性以实现高可用性,那么您可能不应该只使用2个节点 – 您的集群应该至少有10个节点。

对于中间的所有场景,它取决于您的具体要求。

以上哪项优缺点与您相关?哪个不是?

话虽如此,没有规则规定所有节点必须具有相同的大小。

没有什么能阻止您在集群中使用不同大小节点混合在一起的方案。

Kubernetes集群的工作节点可以是完全异构的。

这可能会让您权衡两种方法的优缺点。

最后,证明布丁好坏就在于吃 – 最好的方法是试验并找到最适合你的组合!


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

使用nomad在weave网络中部署工作负载

当初Kubernetes网络的设计目标是使得开发者使用pod时在网络这一层面可以像使用传统物理主机或虚拟机一样。具体的基本要求如下:

  • 所有pod间均应可以在无需NAT的情况下直接通信;
  • 所有集群节点与所有集群的Pod之间均应可以在无需NAT的情况下直接通信;
  • 容器自身的地址和其他pod看到的它的地址是同一个地址;

按照这样的要求,集群中的每个pod都在一个平坦的、共享网络命名空间中,并且每个Pod都拥有一个IP,通信时无需端口映射。 用户也需要额外考虑如何建立Pod之间的连接,也不需要考虑将容器端口映射到主机端口等问题。基于这些要求而实现的k8s pod网络模型,将具有向后兼容的特性,可以使得Pod从某些角度上可以被看成是一个传统的物理主机或vm来对待。

《使用nomad实现集群管理和微服务部署调度》一文中,我们看到nomad部署调度的driver为docker的服务实例都是通过主机和容器间的端口映射来对外提供服务的。服务实例多的时候,大量服务端口出现在眼前,我们很难用端口判断这是什么服务。并且通过映射端口暴露服务有局限,对于那些需要映射到主机固定端口的服务来说,很可能存在与其他服务的端口冲突而导致部署失败。除此之外,这种端口映射的方式还缺少隔离的作用,所有实例暴露的端口在同一个全局网络空间。

nomad是否可以像k8s一样将服务实例部署到overlay网络中从而实现每个服务实例所在container可以被看成一个独立的vm;并且我们还可以通过划分overlay的网段来隔离,实现某种意义上的“多租户”呢?在本篇文章中,我们来试验一下上述想法是否可行。

一、搭建试验环境

我们这次在一个VirtualBox搭建的三节点环境中进行验证。如果小伙伴对这段很熟悉,或者有现成的环境可用,那么可以跳过这一小节。另外这节不是重点,我不会对这个过程用过多文字做解释。

1. 创建虚机,组建网络

我们在一台ubuntu 18.04 desktop版本主机上搭建环境,所使用的软件版本信息如下:

  • VirtualBox: 5.2.18

  • Guest OS: Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)

组件环境的虚拟机和网络拓扑示意图如下:

img{512x368}

如上图所示:三个vm 通过连入host-only网络(vboxnet0)实现内网通;通过连入NAT网络(NatNetwork)实现外网通。(怪异:在windows上的virtualbox实际上通过natnetwork即可实现全通的,无需host-only network,但是在ubuntu下居然不行)。

每个vm中网络配置如下:

# cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp0s3
iface enp0s3 inet dhcp

auto enp0s8
iface enp0s8 inet dhcp

保存后,执行/etc/init.d/networking restart生效。

另外每个vm上安装了openssh-server(apt install openssh-server)并设置root可登陆。三个vm的主机名分为为u1、u2和u3(可通过hostnamectl –static set-hostname u1设置。并在/etc/hosts中添加主机名和内网IP的对应关系)。

每台主机上安装了docker引擎(通过apt install docker.io安装),docker版本信息如下:

# docker version
Client:
 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.4
 Git commit:        6247962
 Built:             Tue Feb 26 23:56:24 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.4
  Git commit:       6247962
  Built:            Tue Feb 12 22:47:29 2019
  OS/Arch:          linux/amd64
  Experimental:     false

二、使用weave创建跨节点的overlay network

我们选择weave作为overlay network的实现。

1. 安装weave

我们在每个vm节点上安装目前最新版本的weave,以一个节点为例:

# curl -L git.io/weave -o /usr/local/bin/weave
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
100   595    0   595    0     0     62      0 --:--:--  0:00:09 --:--:--   137
100 52227  100 52227    0     0   4106      0  0:00:12  0:00:12 --:--:-- 21187

# chmod a+x /usr/local/bin/weave

# weave version
weave script 2.5.1

... ...

通过weave setup预先将weave相关的容器Image下载到各个节点,为后面的weave launch所使用。

# weave setup

2.5.1: Pulling from weaveworks/weave
... ...
c458f7a37ca6: Pull complete
Digest: sha256:a170dd93fa7e678cc37919ffd65601d1015da6c3f10878534ac237381ea0db19
Status: Downloaded newer image for weaveworks/weave:2.5.1
2.5.1: Pulling from weaveworks/weaveexec
... ...
c11f30d06b58: Pull complete
Digest: sha256:ad53aaabf648548ec26cceac3ab49394778322e1623f0d184a2b74ad06338087
Status: Downloaded newer image for weaveworks/weaveexec:2.5.1
latest: Pulling from weaveworks/weavedb
9b0681f946a1: Pull complete
Digest: sha256:c280cf4e7208f4ca0d2514539e0f476dd12db70beacdc368793b7736de023d8d
Status: Downloaded newer image for weaveworks/weavedb:latest

2. 启动跨多节点(peer) weave network

weave的一个优点是建立跨节点overlay network时并不需要一个外部的存储(比如etcd),位于多个节点上的weave进程会自动同步相关信息。而且weave支持动态向weave overlay network中添加节点。

我们来初始化这个由三个vm节点构成的weave overlay network:

root@u1:~# weave launch --no-dns 192.168.56.4 192.168.56.5
78f459a4a8acc07d46c1f86a15a519b91978c809876452b9d9c1294e760394a9

root@u2:~# weave launch --no-dns 192.168.56.3 192.168.56.5
1f379e50f3917e05bd133589f75594d7b2da20a680bb1e5e7172e37a18abe3ff

root@u3:~# weave launch --no-dns 192.168.56.3 192.168.56.4
aa600bfad8db8711e2cbc5f8e127022460ca3738226dd7aa33bb5b9b049f8cee

执行完上面命令后,在任意一个vm节点上执行下面命令,查看节点weave之间的连接状态:

root@u1:~# weave status connections
<- 192.168.56.4:54715    established fastdp 8e:d8:ad:a8:32:eb(u2) mtu=1376
<- 192.168.56.5:51504    established fastdp f6:58:43:5c:68:d7(u3) mtu=1376

我们看到u1节点已经和u2、u3节点成功建立了连接,weave的工作模式是fastdp(fast data path),mtu为默认的1376(适当调节weave mtu可以提升weave overlay network的网络性能)。
我们也可以通过weave status命令查看一下weave网络的整体状态:

# weave status

        Version: 2.5.1 (up to date; next check at 2019/04/18 12:35:41)

        Service: router
       Protocol: weave 1..2
           Name: f6:58:43:5c:68:d7(u3)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 3
    Connections: 3 (2 established, 1 failed)
          Peers: 3 (with 6 established connections)
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: 10.32.0.0/12
  DefaultSubnet: 10.32.0.0/12

        Service: dns
         Domain: weave.local.
       Upstream: 10.0.3.3
            TTL: 1
        Entries: 0

        Service: proxy
        Address: unix:///var/run/weave/weave.sock

        Service: plugin (legacy)
     DriverName: weave

3. 在weave overlay network中创建container并测试overlay网内container的互通性

我们通过为docker指定net driver为weave的方式让docker在weave overlay network中创建container:

root@u1:~# docker run -ti --net=weave busybox /bin/sh

root@u2:~# docker run -ti --net=weave busybox /bin/sh

root@u3:~# docker run -ti --net=weave busybox /bin/sh

我们在u1上启动的容器内去ping位于其他两个vm上启动的新容器:

/ # ping -c 3 10.32.0.1
PING 10.32.0.1 (10.32.0.1): 56 data bytes
64 bytes from 10.32.0.1: seq=0 ttl=64 time=1.540 ms
64 bytes from 10.32.0.1: seq=1 ttl=64 time=1.548 ms
64 bytes from 10.32.0.1: seq=2 ttl=64 time=1.434 ms

--- 10.32.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.434/1.507/1.548 ms

/ # ping -c 3 10.46.0.0
PING 10.46.0.0 (10.46.0.0): 56 data bytes
64 bytes from 10.46.0.0: seq=0 ttl=64 time=5.118 ms
64 bytes from 10.46.0.0: seq=1 ttl=64 time=1.608 ms
64 bytes from 10.46.0.0: seq=2 ttl=64 time=1.837 ms

--- 10.46.0.0 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.608/2.854/5.118 ms

我们看到位于weave overlay network中的三个容器是连通的。

4. 测试host到weave overlay网络中容器的连通性

考虑到后续host上的consul会对部署在weave overlay network中的container中的服务做health check,因此需要在host上能连通位于overlay network中的container。

我们来测试一下:

root@u1:~# docker run -ti --net=weave busybox /bin/sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
29: ethwe0@if30: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1376 qdisc noqueue
    link/ether aa:8f:45:8f:5f:d6 brd ff:ff:ff:ff:ff:ff
    inet 10.40.0.0/12 brd 10.47.255.255 scope global ethwe0
       valid_lft forever preferred_lft forever
31: eth0@if32: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.2/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever

root@u1:~# ping 10.40.0.0
PING 10.40.0.0 (10.40.0.0) 56(84) bytes of data.

^C
--- 10.40.0.0 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3024ms

从测试结果来看,在host无法ping通位于weave network上的container。这个问题实则也显而易见,因为当前host上的路由表中没有以weave网络range: 10.32.0.0/12为目的地址的路由,并且weave网络设备也并未启用ip地址:

root@u1:~# ip route
default via 10.0.3.2 dev enp0s8
10.0.3.0/24 dev enp0s8  proto kernel  scope link  src 10.0.3.15
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
172.18.0.0/16 dev docker_gwbridge  proto kernel  scope link  src 172.18.0.1
192.168.56.0/24 dev enp0s3  proto kernel  scope link  src 192.168.56.3

关于这个问题,weave官方给出了答案:我们可以通过weave expose命令自动为主机上的weave设备分配ip地址,添加到10.32.0.0/12的路由。

root@u1:~# weave expose
10.40.0.1

root@u1:~# ip a

.... ...

7: weave: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UP group default qlen 1000
    link/ether b2:97:b5:7b:0f:a9 brd ff:ff:ff:ff:ff:ff
    inet 10.40.0.1/12 brd 10.47.255.255 scope global weave
       valid_lft forever preferred_lft forever
    inet6 fe80::b097:b5ff:fe7b:fa9/64 scope link
       valid_lft forever preferred_lft forever

.... ...

root@u1:~# ip route
default via 10.0.3.2 dev enp0s8
10.0.3.0/24 dev enp0s8  proto kernel  scope link  src 10.0.3.15
10.32.0.0/12 dev weave  proto kernel  scope link  src 10.40.0.1
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
172.18.0.0/16 dev docker_gwbridge  proto kernel  scope link  src 172.18.0.1
192.168.56.0/24 dev enp0s3  proto kernel  scope link  src 192.168.56.3

我们看到在u1节点上执行完expose之后,weave设备拥有了自己的ip地址,并且主机路由表中也增加了10.32.0.0/12网络的路由。我们再来测试一下u1上主机到container是否通了:

root@u1:~# ping 10.40.0.0
PING 10.40.0.0 (10.40.0.0) 56(84) bytes of data.
64 bytes from 10.40.0.0: icmp_seq=1 ttl=64 time=4.42 ms

64 bytes from 10.40.0.0: icmp_seq=2 ttl=64 time=1.04 ms
64 bytes from 10.40.0.0: icmp_seq=3 ttl=64 time=1.21 ms
^C
--- 10.40.0.0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.048/2.228/4.425/1.554 ms

网络已经打通。我们继续在u2、u3两个节点上执行weave expose,这样三台主机都可以通过网络reach到位于任何一台主机上的、weave network中的container。

而从container到host,原本就可以访问,以u1上的container为例:

/ # ping 192.168.56.3
PING 192.168.56.3 (192.168.56.3): 56 data bytes
64 bytes from 192.168.56.3: seq=0 ttl=64 time=0.345 ms
^C
--- 192.168.56.3 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.345/0.345/0.345 ms

/ # ping 192.168.56.4
PING 192.168.56.4 (192.168.56.4): 56 data bytes
64 bytes from 192.168.56.4: seq=0 ttl=63 time=1.277 ms
^C
--- 192.168.56.4 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.277/1.277/1.277 ms

三、安装consul和nomad集群

《使用nomad实现集群管理和微服务部署调度》一文中,我们已经详细说过consul和nomad的安装配置过程,这里仅列出步骤,不再详细说明。已经有环境的朋友可以略过该步骤!

1. 安装consul

在每个节点上执行下面步骤安装:

# wget -c https://releases.hashicorp.com/consul/1.4.4/consul_1.4.4_linux_amd64.zip
# unzip consul_1.4.4_linux_amd64.zip
# mv consul /usr/local/bin

# mkdir -p ~/consul-install/consul-data

启动consul集群:

u1:

# nohup consul agent -server -ui -dns-port=53 -bootstrap-expect=3 -data-dir=/root/consul-install/consul-data -node=consul-1 -client=0.0.0.0 -bind=192.168.56.3 -datacenter=dc1 > consul-1.log & 2>&1

u2:

# nohup consul agent -server -ui -dns-port=53 -bootstrap-expect=3 -data-dir=/root/consul-install/consul-data -node=consul-2 -client=0.0.0.0 -bind=192.168.56.4 -datacenter=dc1 -join 192.168.56.3 > consul-2.log & 2>&1

u3:

nohup consul agent -server -ui -dns-port=53  -bootstrap-expect=3 -data-dir=/root/consul-install/consul-data -node=consul-3 -client=0.0.0.0 -bind=192.168.56.5 -datacenter=dc1 -join 192.168.56.3 > consul-3.log & 2>&1

查看启动状态:

#  consul operator raft list-peers
Node      ID                                    Address            State     Voter  RaftProtocol
consul-1  db838e7c-2b02-949b-763b-a6646ee51981  192.168.56.3:8300  leader    true   3
consul-2  33c81139-5054-7e76-f320-7d28d7528cc8  192.168.56.4:8300  follower  true   3
consul-3  4eda7d24-3fe2-45f5-f4ad-b95fa39f13c1  192.168.56.5:8300  follower  true   3

如果输出类似上面的日志,则说明consul集群启动成功!

接下来为了利用consul内嵌的DNS server,我们修改一下各个node的DNS配置 /etc/resolvconf/resolv.conf.d/base:

//  /etc/resolvconf/resolv.conf.d/base

nameserver 192.168.56.3
nameserver 192.168.56.4

options timeout:2 attempts:3 rotate single-request-reopen

# /etc/init.d/resolvconf restart

[ ok ] Restarting resolvconf (via systemctl): resolvconf.service.

2. 安装nomad并启动nomad集群

下面是在每个node上安装nomad的步骤:

# wget -c https://releases.hashicorp.com/nomad/0.8.7/nomad_0.8.7_linux_amd64.zip

# mkdir nomad-install

# unzip nomad_0.8.7_linux_amd64.zip

# mv nomad /usr/local/bin

# nomad version
Nomad v0.8.7 (21a2d93eecf018ad2209a5eab6aae6c359267933+CHANGES)

在每个node上创建agent.hcl文件,放到nomad-install下面:

// agent.hcl

data_dir = "/root/nomad-install/nomad.d"

bind_addr = "192.168.56.3" //node 内网ip,这里以u1 host为例

server {
  enabled = true
  bootstrap_expect = 3
}

client {
  enabled = true
}

启动集群(基于consul):

u1:

# nohup nomad agent -config=/root/nomad-install/agent.hcl  > nomad-1.log & 2>&1

u2:

# nohup nomad agent -config=/root/nomad-install/agent.hcl  > nomad-2.log & 2>&1

u3:

# nohup nomad agent -config=/root/nomad-install/agent.hcl  > nomad-3.log & 2>&1

查看nomad集群状态:

# nomad server members -address="http://192.168.56.3:4646"
Name       Address       Port  Status  Leader  Protocol  Build  Datacenter  Region
u1.global  192.168.56.3  4648  alive   false   2         0.8.7  dc1         global
u2.global  192.168.56.4  4648  alive   true    2         0.8.7  dc1         global
u3.global  192.168.56.5  4648  alive   false   2         0.8.7  dc1         global

# nomad operator raft list-peers -address="http://192.168.56.3:4646"
Node       ID                 Address            State     Voter  RaftProtocol
u3.global  192.168.56.5:4647  192.168.56.5:4647  follower  true   2
u2.global  192.168.56.4:4647  192.168.56.4:4647  leader    true   2
u1.global  192.168.56.3:4647  192.168.56.3:4647  follower  true   2

nomad集群启动成功!

四. nomad实现在weave overlay network中的job部署

1. 创建位于weave overlay network中的nomad task service实例

我们定义如下nomad job的配置文件:

//httpbackend.nomad

job "httpbackend" {
  datacenters = ["dc1"]
  type = "service"

  group "httpbackend" {
    count = 3

    task "httpbackend" {
      driver = "docker"
      config {
        image = "bigwhite/httpbackendservice:v1.0.0"
        dns_servers =  ["192.168.56.3", "192.168.56.4", "192.168.56.5"]
        network_mode = "weave"
        logging {
          type = "json-file"
        }
      }

      resources {
        network {
          mbits = 10
        }
      }

      service {
        name = "httpbackend"
      }
    }
  }
}

与之前文章中job的配置文件不同的是,该job配置在task的config中增加了:

  • dns_servers:由于docker 18.09在-net=weave下,container没有继承host的/etc/resolv.conf文件,我们为了能在container中通过服务的domain查询到其真实ip地址,我们在docker的执行参数中加入dns_servers,我们将u1,u2,u3都作为dns server提供了。

  • network_node:我们希望nomad调度负载、创建docker容器时将docker container创建在weave network中,因此我们在network_node中传入”weave”,这就相当于在执行docker时执行:docker run … –net=weave … …

我们来创建一下该job:

# nomad job run -address=http://192.168.56.3:4646 httpbackend.nomad

==> Monitoring evaluation "806eaecf"
    Evaluation triggered by job "httpbackend"
    Allocation "6e06be74" created: node "11212ed9", group "httpbackend"
    Allocation "e7ed8569" created: node "aa5a06fe", group "httpbackend"
    Allocation "fd6c6a05" created: node "fe7a7e9c", group "httpbackend"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "806eaecf" finished with status "complete"

# nomad job status -address=http://192.168.56.3:4646  httpbackend
ID            = httpbackend
Name          = httpbackend
Submit Date   = 2019-04-19T13:18:21+08:00
Type          = service
Priority      = 50
Datacenters   = dc1
Status        = running
Periodic      = false
Parameterized = false

Summary
Task Group   Queued  Starting  Running  Failed  Complete  Lost
httpbackend  0       0         3        0       0         0

Allocations
ID        Node ID   Task Group   Version  Desired  Status   Created  Modified
6e06be74  11212ed9  httpbackend  0        run      running  54s ago  7s ago
e7ed8569  aa5a06fe  httpbackend  0        run      running  54s ago  6s ago
fd6c6a05  fe7a7e9c  httpbackend  0        run      running  54s ago  12s ago

我们查看一下u1节点上的httpbackend负载的状态和ip:

root@u1:~/nomad-install/jobs# docker ps
CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS              PORTS               NAMES
2e2229cf8f64        c196c122feea             "/root/httpbackendse…"   49 seconds ago      Up 48 seconds                           httpbackend-e7ed8569-fdde-537b-91b3-84583d1ea238
912ac43350f7        weaveworks/weave:2.5.1   "/home/weave/weaver …"   22 hours ago        Up 22 hours                             weave

root@u1:~/nomad-install/jobs# docker exec 2e2229cf8f64 ip a
... ...
49: ethwe0@if50: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1376 qdisc noqueue
    link/ether a2:f1:ef:d7:89:ee brd ff:ff:ff:ff:ff:ff
    inet 10.40.0.0/12 brd 10.47.255.255 scope global ethwe0
       valid_lft forever preferred_lft forever
.... ...

我们看到新创建的container的ip为10.40.0.0,是weave network subnet range中的一个地址。

我们访问一下该服务:

# curl http://10.40.0.0:8081
this is httpbackendservice, version: v1.0.0

我们看到了预期返回的结果。通过consul的域名访问也同样ok:

# curl httpbackend.service.dc1.consul:8081
this is httpbackendservice, version: v1.0.0

我们从一个位于weave network中的container中去访问httpbackend服务,依然会得到正确的应答结果:

# docker run -ti --net=weave --dns=192.168.56.3 --dns=8.8.8.8 ubuntu /bin/bash

root@3fe76a39b66f:/# curl httpbackend.service.dc1.consul:8081
this is httpbackendservice, version: v1.0.0

五、 应用隔离

有些时候我们需要将部署的应用之间做隔离,让彼此无法互相访问。weave overlay network是支持这样做的,我们一起来看一下。

1.重建weave网络

我们首先需要重新创建weave网络,使之能支持划分不同subnet。

先在每个node上执行下面命令,将原有的weave网络清理干净:

# weave reset

执行后,发现weave网络设备、weave相关容器、路由表中有关weave的路由都不见了。

我们重新建立三节点的weave网络,在这个10.32.0.0/16的大网中,我们划分若干subnet,默认的subnet为10.32.0.0/24。

u1:

# weave launch --no-dns --ipalloc-range 10.32.0.0/16 --ipalloc-default-subnet 10.32.0.0/24 192.168.56.4 192.168.56.5

# weave expose

u2:

# weave launch --no-dns --ipalloc-range 10.32.0.0/16 --ipalloc-default-subnet 10.32.0.0/24 192.168.56.3 192.168.56.5

# weave expose

u3:

# weave launch --no-dns --ipalloc-range 10.32.0.0/16 --ipalloc-default-subnet 10.32.0.0/24 192.168.56.3 192.168.56.4

# weave expose

接下来我们在不同的subnet下分别建立两个container:

首先在u1上,在default subnet下建立两个container a1和a2:

#docker run -ti --net=weave --dns=192.168.56.3 --dns=8.8.8.8 --name a1 busybox /bin/sh

#docker run -ti --net=weave --dns=192.168.56.3 --dns=8.8.8.8 --name a2 busybox /bin/sh

再在u2上在subnet 10.32.1.0/24下建立两个container:b1和b2

u2上:

# docker run -ti --net=weave --dns=192.168.56.3 --dns=8.8.8.8 -e WEAVE_CIDR=net:10.32.1.0/24 --name b1 busybox /bin/sh

# docker run -ti --net=weave --dns=192.168.56.3 --dns=8.8.8.8 -e WEAVE_CIDR=net:10.32.1.0/24 --name b2 busybox /bin/sh

我们经过测试发现:a1与a2、a1与b1都是可以ping通的,这与我们的预期a1与b1、b2不通不符。我们发现b1(10.32.0.2)、b2(10.32.0.3)两个容器的ip地址居然依然在default subnet内,似乎通过环境变量WEAVE_CIDR传递的subnet信息没有生效。
在weave的一个issue中,有开发者提到:WEAVE_CIDR仅用于weave proxy模式,在weave作为plugin模式工作时,docker不会将该环境变量信息传递给weave。也就是说即便上面在u2上创建b1、b2时设置了环境变量WEAVE_CIDR,weave插件也无法得到该信息,于是依旧在默认subnet范围为b1、b2分配了ip。

2. 让docker使用weave proxy模式

weave proxy是位于docker client与docker engine(docker daemon)之间的代理服务:

docker client --> weave proxy ---> docker engine/daemon

默认情况下,/var/run/docker.sock是docker client和docker engine之间的通信“媒介”,Docker daemon默认监听的Unix域套接字(Unix domain socket):/var/run/docker.sock,docker client以及容器中的进程可以通过它与Docker daemon进行通信。

我们可通过docker -H xxx.sock或通过设置 DOCKER_HOST环境变量的方式让docker client与传入的unix socket通信。这样我们就可以将weave proxy的套接字unix:///var/run/weave/weave.sock(通过weave env查看到)传给docker client了。我们来测试一下:

u1:

# docker -H unix:///var/run/weave/weave.sock run -ti --dns=192.168.56.3 --dns=8.8.8.8 --name a1 busybox /bin/sh

# docker -H unix:///var/run/weave/weave.sock run -ti --dns=192.168.56.3 --dns=8.8.8.8 --name a2 busybox /bin/sh

u2:

# docker -H unix:///var/run/weave/weave.sock  run -ti --dns=192.168.56.3 --dns=8.8.8.8 -e WEAVE_CIDR=net:10.32.1.0/24 --name b1 busybox /bin/sh

#docker -H unix:///var/run/weave/weave.sock run -ti --dns=192.168.56.3 --dns=8.8.8.8 -e WEAVE_CIDR=net:10.32.1.0/24 --name b2 busybox /bin/sh

四个container启动后,我们发现b1、b2的ip地址都在WEAVE_CIDR指定的空间内,a1、a2间互通;b1、b2间互通,但a1、a2与b1、b2间是不通的。这样就与预期相符了。

3. nomad与weave proxy模式集成实现应用工作负载的隔离

接下来,我们来看看如何将nomad和weave的proxy模式集成在一起,实现工作负载分配在不同subnet。

这里我们就无法仅仅通过在job配置文件中传入参数的方式来实现了,我们需要修改一下agent.hcl并重启nomad集群。以u1节点上的agent.hcl为例,我们需要改为下面这样:

data_dir = "/root/nomad-install/nomad.d"

bind_addr = "192.168.56.5"

server {
  enabled = true
  bootstrap_expect = 3
}

client {
  enabled = true
  "options":{
     "docker.endpoint":"unix://var/run/weave/weave.sock"
  }
}

我们在client配置block中增加一个options,设置了docker.endpoint为weave proxy监听的weave.sock。重启集群:

u1:

# nohup nomad agent -config=/root/nomad-install/agent.hcl  > nomad-1.log & 2>&1

u2:

# nohup nomad agent -config=/root/nomad-install/agent.hcl  > nomad-2.log & 2>&1

u3:

# nohup nomad agent -config=/root/nomad-install/agent.hcl  > nomad-3.log & 2>&1

接下来,我们重建一个httpbackend-another-subnet.nomad,内容如下:

//httpbackend-another-subnet.nomad

job "httpbackend" {
  datacenters = ["dc1"]
  type = "service"

  group "httpbackend" {
    count = 3

    task "httpbackend" {
      driver = "docker"
      config {
        image = "bigwhite/httpbackendservice:v1.0.0"
        dns_servers =  ["192.168.56.3", "192.168.56.4", "192.168.56.5"]
        logging {
          type = "json-file"
        }
      }

      env {
        WEAVE_CIDR="net:10.32.1.0/24"
      }

      resources {
        network {
          mbits = 10
        }
      }

      service {
        name = "httpbackend"
      }
    }
  }
}

我们去掉了network_mode = “weave”,增加了一个env:WEAVE_CIDR=”net:10.32.1.0/24″。run这个job:

# nomad job run -address=http://192.168.56.3:4646 httpbackend-another-subnet.nomad
==> Monitoring evaluation "e94bdd00"
    Evaluation triggered by job "httpbackend"
    Allocation "3f5032b5" created: node "11212ed9", group "httpbackend"
    Allocation "40d75ae8" created: node "aa5a06fe", group "httpbackend"
    Allocation "627fe1e7" created: node "fe7a7e9c", group "httpbackend"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "e94bdd00" finished with status "complete"

# docker ps
CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS              PORTS               NAMES
700bbea7c89e        c196c122feea             "/w/w /root/httpback…"   17 seconds ago      Up 16 seconds                           httpbackend-40d75ae8-fe75-c560-b87b-c1272db4850c
8b7e29522b8b        weaveworks/weave:2.5.1   "/home/weave/weaver …"   10 hours ago        Up 10 hours                             weave
root@u1:~/nomad-install/jobs# docker exec 700bbea7c89e ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
142: eth0@if143: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
144: ethwe@if145: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1376 qdisc noqueue
    link/ether f2:55:9d:26:72:56 brd ff:ff:ff:ff:ff:ff
    inet 10.32.1.192/24 brd 10.32.1.255 scope global ethwe
       valid_lft forever preferred_lft forever

我们看到新创建的httpbackend container的ip已经分配到10.32.1.0/24 subnet下面了。这种方式使得我们可以任意安排我们的job放入哪个subnet。

4. 遗留问题

我们通过consul go api试图从consul中获取service: httpbackend的ip信息,我们得到了如下的输出:

#  ./services
10.0.3.15 : 0
10.0.3.15 : 0
10.0.3.15 : 0
[]

如果在httpbackend的service配置中使用如下配置:

 service {
        name = "httpbackend"
        address_mode = "driver"
      }

那么,我们得到的是下面结果:

# ./services
172.17.0.3 : 0
172.17.0.2 : 0
172.17.0.2 : 0
[]

也就是说nomad在consul中记录的container的advertise ip不是我们想要的weave subnet网段的ip信息,这样就会导致我们通过consul的DNS服务或者通过consul api获取的服务ip信息有误,导致无法通过这两种方式访问到服务实例。在nomad的最新版v0.9.0中该问题依然存在。

综上,“隔离”的目的得到了部分满足,期待后续nomad的改进。

六、参考资料

  • https://www.weave.works/docs/net/latest/install/installing-weave/

  • https://www.weave.works/docs/net/latest/install/using-weave/#peer-connections

  • https://www.weave.works/docs/net/latest/install/plugin/plugin/#launching

  • https://www.weave.works/docs/net/latest/tasks/manage/host-network-integration/

  • https://docs.docker.com/v17.09/engine/userguide/networking/configure-dns/

  • https://www.nomadproject.io/docs/drivers/docker.html#client-requirements

  • https://www.weave.works/docs/net/latest/tasks/manage/application-isolation/

  • https://www.weave.works/docs/net/latest/tasks/weave-docker-api/weave-docker-api/

  • https://www.nomadproject.io/docs/drivers/docker.html

  • https://www.nomadproject.io/docs/configuration/client.html

  • https://www.nomadproject.io/docs/job-specification/service.html#using-driver-address-mode

  • https://success.docker.com/article/networking

本文涉及到的配置文件和源码,参见这里


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats