news

原文链接:https://medium.com/corda/combining-corda-and-kubernetes-4e2ba54494c7

译者:Kenneth Tu

Kubernetes是功能强大的容器编排和资源管理工具。
Corda是专为商业设计的开源区块链专案。
 
看到本文,您可能想问一个问题 – 他们可以一起工作吗?简单回答是肯定的。但需要比一般的应用程序更多的关注和考虑。Corda平台是多状态(state)并依赖网络,比起一般Kubernetes经常看到的无状态工作服务部署相比,需要有更多的调整。然而,有很多Corda的部署方法可从Kubernetes中受益。
 
在生产上线中运用容器时,随着时间进行,您很快就会有很高数量的容器。维持对这些容器的操作,部署,升级和运行状况的控制,需要一组专门的团队。相同地,如您要管理成千上万的Corda节点,则肯定需要合适的人员与工具以确保正常。鉴于Kubernetes在实际运作上取得相当地成果,您肯定可从中学习到一两件事。
 
在Corda部署中运用Kubernetes时需要考虑几个重要因素:
 
水平扩展与垂直扩展 –
Kubernetes最著名的功能之一是容器集(Pod)层的水平扩展。这意味着,当您的服务收到更多流量,更多的instance产生,更多或缩减跨机器的需求时。目前,Corda支持垂直扩展:Corda透过增加单一机器中更多的功率而非负载分散到多机器上进行扩展。在此,有个长期的水平扩展计划,将涉及Corda的工作流(Flow Worker)组件分拆为单独的JVM线程,并根据更高的需求增加线程数量。
 
然而,根据内部及外部的分析均显示,目前的Corda具有高吞吐量能力,因此很少用例需要吞吐率,以需要额外的水平扩展。
 
尽管Corda目前不支持水平扩展,但您仍可从Kubernetes的强大功能使Corda操作获得益处
 
自动垂直扩展 –
如果节点运行的机器已达到全部容量,则该节点必须迁移到规格更高的机器。
 
此过程即使是自动化,也可能会很耗时间,费力且容易出错。
 
Kubernetes在Pod层支持自动垂直扩展。这意味着您的丛集(cluster)可设置为Pod增加或减少的扩展机器,以更准确地满足Corda预期能量的服务需求。例如,通过正确的使用分析,如预期某些关键节点的子集在关键时刻的流量会出现高峰,您可预先安排机器数量时间,进而节省成本并优化性能。这对日常的核心网络服务作业可能过于强大,如公证服务,但可能会对多节点组成的丛集(node cluster)受益。

从理论上,这听起来不错,但需要进行实验以理解自我修复和连接性保证的时间线,以确保前面节点过程的各种因素及形式已经停止。也请与我们所有人分享您的发现。
 
连接性 –
Corda每个节点都一定有个IP地址,以便在网络地图服务上可被找到它。可部署IP负载平衡服务,以确保在公开互联网和丛集中都可访问Corda节点。所有流量都将指向到该IP地址将被转到您的服务指定的端口上。
 
不同云端商之间的内定设置有所不一,但大多数支持标准的TCP和HTTP连接。根据Corda的状态,您将可能需要为每个节点部署提供负载平衡器服务,以及针对RPC的单独服务,如下所示。
 
入口控制器是种特殊类型的负载均衡器,通常内定以NGINX HTTP用于Corda客户端的服务。
 
机密和设置管理 –
Corda节点不仅限于Corda jar档案。它必须与持久性(persistence)设定,应用程序和凭证配对。无庸置疑,这些信息越受保护越好。
 
Corda Obfuscator是高于VM层级的丛集管理,可能会对Kubernetes造成挑战,因为它使用机器的MAC地址来解密节点所需的信息,当k8s Pods可在丛集中任何随机的机器上生成时,显然所有这些(机器)都具有不同的MAC地址,将会有许多问题。
 
话虽如此,Kubernetes可通过额外的安全机密例如在Pod或容器上使用编码功能和存储在node.conf和certificate目录内。但是,这方法仍然存在一些风险:假如你通过清单(JSON或YAML)文件设置机密,该列表的机密数据编码为base64。Base64编码不是一种加密方法,通常被认为与纯文本相同。可访问设置的人就可能会译码机密相关。请注意不要记录,登入或将这些内容给任何人。
 
健康度 –
Kubernetes提供一些功能可检查您的服务状态和准备情况。这些可在部署YAML中设置,在您的Pods容器正在运行的端口完成。您可指定在服务无法启动,无法正常运行或意外退出时的处理方式。Corda还没有对这些特殊状况的支持,但是您现在可通过TCP协议端口完成(*图二 A)。

架构 –
考虑到上述状况,下面是您可采用的一些架构。
 

  1. Corda + RPC客户端
    当以Corda创建企业级系统时,通常会将Corda与RPC客户端配对使用。可根据您您熟悉的方式提供现有业务逻辑来定义和公开API。为确保更好地关注点分离(separation of concerns),我们最好将Corda及其客户端在不同的Pod中运行。这可将Corda服务与客户端故障隔离,反之亦然。理想情况下,我们不希望Corda的RPC端口对大众公开,因此为客户端使用一个单独的RPC服务。
     
    没有Pod到Pod的直接通讯,因此要允许客户端通过RPC连接到Corda节点,您应该将Corda Pod连接到另一个服务(*图二 B)。
     
  2. Corda企业网络管理员
    在Kubernetes上部署Corda网络服务是完全可能的。Kubernetes的主要优势是通过动态监控以防止内存不足的资源停机。
     
    如果您还没听说过Corda Enterprise Network Manager(Corda企业网络管理员,简称CENM),那么这是个学习史诗级技术的好机会。我希望对Kubernetes上的Corda企业网络管理员也另外写一篇博客文章。
     
    这里的主要内容是某些组件(即签名服务[CA])具有很高的安全性,因此必须与互联网隔离。此外,每个组件都必须可被其他核心网络组件访问。目前,如果设置正确,它们将通过SSL进行通信,因此您应该部署单独的服务以更安全地使用这些通信。可通过入口控制器公开HTTP的服务。架构可能如下所示(图三):   3.全部一起监控 将所有这些组件放在一起,就可进行绝妙的部署。有人可能会认为较好地关注点分离,应将CENM核心组件和参与单位服务放在不同的命名空间(图四)。

云端平台 –
利用对Kubernetes的云端原生支持是很合理并且可能有必要的。我说的是Azure AKS,Amazon EKS和OpenShifts。当使用这些服务最现代化版本时,您遇到的问题应该更少,对这些平台的某些较旧版本而言,它们的细节非常浅显,这可能会使Corda部署更具挑战性。例如,根据我的经验:
 

在开放运算计划(OCP)的较早版本中,每个Pod允许的最多开放端口数目仅为1;对于需要RPC,P2P和SSH的服务来说是个坏消息。
AWS上的较旧版本的OCP不能将非HTTP流量公开给Pods,除非使用特殊的云端插件,否则可能会造成生产工作负载的支持阻碍。
某些部署最多只允许每个AWS区域最多20个ELB(负载平衡器)。虽然不是主要的阻碍,但是仍然是阻碍。这可以通过直接与云端商合作来解决。
 
结论就是关键在于细节。并非所有人有能力为Corda部署丛集。我敢说,很大一部分将脱离现有丛集角落。无论如何,请确保和您的容器平台专家合作,以确实满足Corda的需求。
 
结论:我应该使用它吗?-
对于分布式系统而言,Corda相对容易部署,而Kubernetes的学习曲线却非常陡峭。如果您没有一组团队愿意解决Kubernetes带来的挑战并尝试克服这些挑战,那么在Kubernetes上运行Corda可能会很困难。
 
如果您计划运行节点即服务,代理其他公司单位运行许多节点,那么与手动编写脚本的部署相比,Kubernetes可帮助您管理和降低成本。别忘了,如果您是个单一节点操作员,那么没有理由Systemd及其周边的工具会无法满足您的多数需求。
 
Corda的首席平台工程师Mike Hearn同时也用Corda和Kubernetes写了一些有用的东西 ( https://groups.io/g/corda-dev/topic/kubernetes_deployments/27868703?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,27868703 ) 。

发表评论