开发人员必须学习新语言 ， 努力将运维工具整合到工作流程中 。 社区成员聚集在一起 ， 提出创造性的解决方案、检测问题并提高系统自动化和可观察性等 。 单独来看 ， 他们提出的所有这些工具和项目都很优秀 ， 可惜并没有形成标准 。

那么该如何改进呢？要如何再一次实现飞跃 ， 构建出更伟大、更优秀的产品？答：处于云原生时代下 ， 自然要利用容器化和容器编排 ， 以此实现狭义的打包（容器映像）与运行时（Kubernetes Pod）的标准化 。 为便于理解 ， 本文将以Crossplane为例 ， 说明基础设施即代码变革中缺失的一环该如何补齐 。
补齐基础设施即代码变革中的缺失
开源云原生控制平面项目Crossplane在2021年9月由CNCF技术监督委员会（TOC）投票决定将其提升为CNCF的孵化项目 ， 是Upbound在2018年开发的混合云环境下通用控制平面项目 ， 于2020年7月成为CNCF沙箱项目 。 Crossplane用于跨环境、集群、区域和云来管理云原生应用程序和基础设施 ， 其强大之处在于 ， 它采用了云原生开放标准和最流行的工具 ， 方便开发人员（应 用程序团队）和运维人员（平台团队）展开协同工作 ， 同时又无须相互依赖（见图3）

文章图片

图3 利用Crossplane之后 ， 开发和运维团队的工作方式
在我看来 ， Crossplane具备以下特点：
其一 ， 建立在Kubernetes之上 ， 而Kubernetes的真正力量在于其强大的API模型和控制平面逻辑（控制循环） ， 因此Crossplane通过Kubernetes的控制平面将应用程序团队和平台团队串到了一起 ， 可实现无缝协作 ， 这是最大的优点 。 其二 ， 实现了从基础设施即代码到基础设施即数据的转变 。 这两者之间的区别在于 ， 基础设施即代码需要编写代码来描述应用程序的配置 ， 而基础设施即数据则可以编写纯数据文件（Kubernetes的YAML） ， 并提交给控制组件（Kubernetes的操作器）进行封装和执行配置逻辑 。
图4为Crossplane的组件模型及其基本交互 。

文章图片

图4 Crossplane组件模型及其基本交互
要想补齐基础设施即代码变革中缺失的一环 ， Crossplane的组合功能尤为合适：使用Crossplane的组合功能有助于将基础设施的复杂性抽象出来 ， 转移给平台团队 ， 从而减轻开发人员的负担 。 具体实操如下 。
首先 ， 需要AWS ， 并在本地机器上配置CLI（注：如果想要了解部署组件以及Kubernetes资源模型 ， 需要具备AWS的基本知识） 。 本地需安装VS Code以及远程容器插件devcontainer ， 如果使用Windows系统 ， 则还需要WSL2（具体安装设置可参照Crossplane官网说明[1]） 。
安装工作完成后 ， 可部署一个RDS实例——一种由AWS托管的Kubernetes资源 ， 类似于Pod、服务和副本集等 ， 可通过Octant或命令行工具查看部署的进度 。
随后 ， 再部署EKS集群 ， 需要创建很多组件 ， 如VPC、子网、IAM角色、节点池、路由表、网关等 。 这一过程可能有些麻烦 ， 不是理想的开发者体验 ， 但正所谓“磨刀不误砍柴工” 。
除却创建必要组件这一步不可省略 ， 开发者在部署EKS集群时的其他工作都极大减轻了 。

• 无须全面掌握庞大且复杂的EKS整体架构 ， 仅需了解其中部分组成（见图5） ， 将复杂易错的工作交给专门从事Kubernetes和云提供商的平台团队管理 。

图5 开发人员需了解的部分EKS架构

• 在相关准备工作完成后 ， 部署EKS集群变得非常简单 ， 仅需一条命令：kubectl create -f ./aws（若成功部署 ， 可见图6状态）
  • 上一页
  • 1
  • 2
  • 3
  • 下一页

  特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。