该博客的目的是帮助开发人员，架构师和商业从业人员了解采用Kubernetes环境时使用Spinnaker的重要性。您将了解：
- Spinnaker在Kubernetes环境中的作用
- 在Kubernetes环境中使用Spinnaker
- 了解Spinnaker的架构
- 使用Spinnaker设计持续交付管道
- 解释Spinnaker管道工作流程
- 使用Spinnaker设计持续交付管道的最佳实践
Spinnaker在Kubernetes环境中的作用
由于其在管理多容器环境中的简便性，各种组织都采用Kubernetes。但是，Kubernetes不是像Jenkins或Spinnaker这样的持续交付或部署工具。早期，Kubernetes生态系统缺少一个简单的持续交付工具来自动构建Kubernetes清单，测试这些工件并部署这些工件。Jenkins支持在Kubernetes集群上持续交付应用程序，但是增加了复杂性。
Spinnaker支持在Kubernetes集群上部署应用程序。它简化了此过程，并帮助组织在Kubernetes集群上部署了生产级的构建工件。
Spinnaker还通过其图形用户界面（GUI）用于管理Kubernetes集群上部署的应用程序。可以编辑和更新Kubernetes清单文件，以提供动态编辑Kubernetes特定属性的功能。借助Spinnaker GUI，您还可以监控Kubernetes对象的运行状况。
在Kubernetes环境中使用Spinnaker
Spinnaker得到了各种云提供商的支持，例如App Engine，Amazon Web Services（AWS），Azure，Google Cloud Platform（GCP），Cloud Foundry，Oracle和Kubernetes。在云上将Spinnaker与Kubernetes一起安装时，它将提供Kubernetes本机，基于清单的部署。Spinnaker使用一个帐户对Kubernetes集群进行身份验证。
在Kubernetes环境中Spinnaker的关键功能是应用程序管理和应用程序部署。应用程序管理功能有助于管理和查看Kubernetes集群对象。可以使用Spinnaker在Kubernetes对象上执行各种操作，例如扩展，缩小，回滚和前进。Spinnaker的此功能有助于从单个点（即Spinnaker GUI）管理多个Kubernetes集群。
Spinnaker的应用程序部署功能用于在Kubernetes集群中部署各种对象。Spinnaker在Kubernetes集群中部署应用程序时支持各种部署策略，例如Blue/Green，滚动更新，canary部署等。要执行应用程序部署，Spinnaker使用管道和阶段。借助Spinnaker管道，您可以创建持续的交付流程，以将代码从源代码管理工具自动部署到Kubernetes集群。您还可以使用Spinnaker阶段在将任何内容部署到生产Kubernetes集群上之前执行代码验证。
了解Spinnaker的架构
Spinnaker由独立的微服务组件组成。下面提到其中一些组件：
- Deck：提供与Spinnaker工具交互的用户界面。
- Gate：充当API网关。它将所有API请求传递给服务。
- Orca：处理各种临时操作并管理管道及其阶段。
- Clouddriver：云提供商。充当Spinnaker与云提供商之间的集成点。
- Front50：保留应用程序，管道和项目的元数据。
- Rosco：烘焙映像，然后将其部署在各种云提供商上。
- Igor：通过诸如Jenkins和Travis CI的持续集成平台触发管道。
- Echo：通过电子邮件，短信和Slack发送通知。它还负责传入的Webhooks，例如Github Webhooks和Jenkins Webhooks。
- Fiat：充当Spinnaker的授权服务。
- Kayenta：为Spinnaker提供自动化的金丝雀分析。
- Halyard：一种配置服务，用于安装，更新和配置Spinnaker。
使用Spinnaker设计持续交付管道
创建了一个持续交付管道，以在两个不同的Kubernetes命名空间（即DEV和UAT）上部署Kubernetes清单和应用程序构建（docker镜像）。要创建一个持续交付管道，您需要一个Helm Charts作为Kubernetes清单文件的模板，Spinnaker正在使用该清单创建最终可部署的Kubernetes清单工件。
您可以创建五个单独的Spinnaker管道，如下所述：
- DEV-Kubernetes集群的YAML文件更改部署流水线：此管道用于在Kubernetes集群的DEV名称空间上部署，触发条件是Kubernetes清单文件发生了更改(dev.yaml)。
- UAT-Kubernetes集群的YAML文件更改部署流水线：此管道用于在Kubernetes集群的UAT名称空间上部署，触发条件是Kubernetes清单文件发生了更改（uat.yaml）。
- DEV – Docker镜像–应用程序部署流水线：此管道用于代码更改后构建Docker镜像并部署在Kubernetes集群的DEV名称空间上。
- UAT – Docker镜像–应用程序部署流水线：此管道用于代码更改后构建Docker镜像并部署在Kubernetes集群的UAT名称空间上。
- UAT-Jenkins手动Docker镜像部署流水线：此管道用于代码更改后构建Docker镜像并手动部署在Kubernetes集群的UAT命名空间上。它使用户可以在UAT名称空间上手动部署所需的应用程序代码（Docker镜像）。上面提到的两个Spinnaker管道分别在DEV和UAT名称空间上自动部署代码。它使用户可以控制在UAT名称空间上部署的应用程序代码（Docker镜像）。
解释Spinnaker管道的工作流程
计划部署的Kubernetes清单文件和应用程序代码（Docker镜像）现在应该推送到GitHub存储库。
- 在GitHub上配置Webhook，自动将更改通知推送到Jenkins，Jenkins配置有作业以自动检测GitHub中的应用程序代码更改。
- Jenkins作业获取最新的应用程序代码更改并构建Docker镜像。使用Docker插件或者是原生的dockerCLI指令，Jenkins将新创建的镜像推送到Docker Hub。
- 相应的Spinnaker管道在自动触发器的帮助下持续监视Docker Hub注册表。
- 在Docker Hub注册表中获取到最新的Docker镜像后，您可以执行Spinnaker管道触发器并将相应的应用程序代码（Docker镜像）部署在Kubernetes集群的DEV/UAT名称空间上。
让我们详细讨论每个管道。
用于DEV和UAT的Kubernetes集群管道的YAML文件更改部署流水线
该Spinnaker管道包括四个阶段-配置、Jenkins、Bake（清单）和Deploy（清单）。
- 配置阶段是一个自动触发器，配置为检测dev.yml 或者 uat.yml文件中的提交更改。如果这些文件中有更改，则将开始执行此管道。
- Jenkins阶段向Jenkins作业发送触发器，该作业在现有的Kubernetes集群上执行一组Linux命令（构建镜像指令），以检测最近部署的Docker镜像标签。此阶段确保不使用latest的Docker镜像标记和更新现有的Docker镜像。之后，Jenkins阶段将现有的Docker映像标签记录在一个文本文件中（例如，build_uat_yml.properties）。
稍后，文本文件将传递到下一个Spinnaker阶段，即Bake（清单）。
- 此阶段配置有一个模板，该模板包含镜像标签的变量为“ {{.Values.image.tag}}”。spinnaker用build_uat_yml.properties/ build_dev_yml.properties文件中存在的键值替换此变量值。
然后，Spinnaker创建一个最终的构建工件，其中包含清单值和Jenkins作业记录的Docker镜像标签值。
- 部署（清单）阶段使用此最终工件，并将此清单构建工件部署在DEV/UAT名称空间上，而无需更新现有Docker镜像标签。
DEV – Docker镜像-应用程序部署管道
此Spinnaker管道包括三个阶段：配置，烘焙（清单）和部署（清单）。
- Configure阶段配置有自动触发器，以在Docker Hub注册表中检测新推送的Docker映像。
- Bake（Manifest）阶段用于根据现有的Helm模板和已定义的dev.yml值文件创建Kubernetes清单文件。最终工件是使用带有“最新”标签的Docker镜像创建的。
- 部署（清单）阶段使用最终工件，并将其部署在已配置的Kubernetes集群的DEV名称空间中。
UAT – Docker镜像-应用程序部署管道
该管道使用与上述相同的流程从现有的Helm模板和已定义的uat.yml值文件创建最终工件。唯一的区别是，在此阶段，将自动触发器配置为“ DEV – Docker镜像–应用程序部署”管道的执行结果。“ DEV – Docker镜像–应用程序部署”管道的成功执行/完成将开始管道的执行。如果“ DEV-Docker镜像-应用程序部署”管道的执行进入失败状态，则该管道将永远不会开始执行，这将防止在Kubernetes集群的UAT名称空间中部署失败的工件。
UAT-Jenkins手动Docker镜像部署管道
该管道可帮助用户根据需要在UAT名称空间中部署旧的Docker镜像工件。用户提供所需的Docker镜像标签，该标签将通过参数化的Jenkins作业进行部署，该作业会创建文本文件（例如build.properties），并将用户提供的Docker镜像作为内容。例如– IMAGE_TAG = v15。这里，v15是用户提供的镜像标签。
将build.properties文件作为输入传递到Spinnaker管道。
- 烘烤（清单）阶段配置有一个模板，该模板包含镜像标签的变量为“ {{.Values.image.tag}}”。Spinnaker将该变量值替换为build-properties文件中存在的键值。然后，Spinnaker将创建最终的构建工件，其中包含清单值和用户传递的Docker镜像标签值。
- 部署（清单）阶段使用此最终工件，并通过使用提到的标签拉出相应的Docker镜像，将该清单构建工件部署在UAT名称空间上。
使用Spinnaker设计持续交付管道的最佳实践
- Spinnaker提供的GUI允许用户执行应用程序管理，例如通过GUI直接编辑Kubernetes对象YAML定义文件。但是大多数时候，源代码管理工具用于存储和版本化Kubernetes对象YAML定义文件。在这种情况下，通过Spinnaker GUI完成的任何YAML文件更改都将在下一次管道部署期间被覆盖。因此，强烈建议对存储在源代码管理工具中的YAML文件进行更改，而不是直接通过Spinnaker GUI编辑YAML文件。
- 使用Docker镜像推送而不是GitHub推送触发器或Jenkins作业触发器配置Spinnaker管道触发器。这种做法避免了构建和验证系统的重组。
- 不要在Docker镜像中烘焙Secrets。应在运行时使用云提供商的密钥管理服务加载机密。
- 使用审核日志来确定已执行的操作，执行的时间以及执行的人。最佳实践是通过将Spinnaker与GCP Stackdriver和AWS CloudWatch等云监控服务集成来生成Spinnaker审核日志。
- 通过Kubernetes对象YAML文件在Kubernetes集群上部署Docker镜像。在YAML文件中定义Docker镜像有两种方法，即通过定义镜像标签或定义镜像摘要。最佳实践是通过摘要在YAML文件中定义Docker镜像。这种方法将确保部署的Docker镜像始终指向相同的内容。
Spinnaker是一个强大的持续交付工具，用于自动在Kubernetes集群上部署应用程序。Spinnaker管道也可以配置为在执行实际部署之前对构建工件执行单元测试和功能测试。因此，Spinnaker可以帮助组织更快地将代码获取到生产环境。
