“它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。”

了解敏捷的朋友都知道backlog和spring是待办事项和冲刺的意思，但在使用Choerodon实践敏捷开发的时候这些敏捷术语对应的系统功能是哪些呢？为了解决大家在使用Choerodon时的困扰，整理了以下Choerodon功能与敏捷术语的对应表，以便大家进一步了解Choerodon的具体功能。

关于Choerodon猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

Choerodon全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

2020年3月13日，Choerodon猪齿鱼发布0.21版本，本次更新敏捷协作的知识库部分相较于上一版本会有较大的改动，其它功能模块也都进行了不同程度的修改和优化，如平台功能、协作、部署等，欢迎各位更新体验。

• 发布版本：0.21
• 发布时间：2020年3月13日
• 更新范围：敏捷协作、代码开发、测试管理、环境部署以及基础功能

下面就为大家带来详细的模块介绍。

敏捷协作

新增功能​

迭代计划、工作列表​

• 配置看板支持删除状态。
• 导入问题支持导入父子级关系，用户可以在导入故事或任务时同时导入子任务。
• 敏捷消息通知支持邮件方式。

知识库​

• 支持创建多个知识库。

• 支持知识库设置公开范围。

• 知识库支持设置文档模板。

• 支持基于模板创建知识库或者文档。
• 知识库支持复制文档。
• 支持从回收站恢复知识库。

缺陷修复​

迭代计划、工作列表​

• 修复故事地图全屏显示菜单栏的问题。
• 修复迭代计划工作台刷新后无数据的问题。
• 修复问题详情剩余预估时间名称显示错误的问题。
• 修复故事地图史诗特定情况无法查看评论的问题。
• 修复设置敏捷模块负责人显示undefined的问题。

知识库​

• 修复知识库全屏显示菜单栏的问题。
• 修复由于wiki迁移至知识库造成的操作历史、版本对比显示异常的问题。
• 修复删除知识库文档未删除与敏捷问题的关联的问题。

功能优化​

迭代计划、工作列表​

• 优化敏捷看板性能。
• 优化工作列表性能。
• 优化配置看板状态设置为已完成保存不生效的问题。
• 优化待办事项批量拖拽问题数量显示。
• 优化问题链接页面样式。
• 优化自定义字段页面样式。

代码开发

缺陷修复​

• 修复持续集成pipeline中，lastest分支每页都有的问题。

功能优化​

• 优化应用服务的创建过程的超时逻辑，避免了一直在处理中的情况，从而导致应用服务无法删除。
• 优化拉取共享应用服务镜像。

测试管理

新增功能​

• 测试计划支持计划日历，测试人员可规划测试用例的执行时间。

• 测试用例支持移除问题链接。
• 测试计划支持查看“我的执行”，测试人员可以只查看指派给我执行的测试用例。

缺陷修复​

• 修复测试用例步骤分页错误的问题。
• 修复导入测试用例模板字段冗余的问题。

功能优化​

• 优化测试执行历史记录。

环境部署

新增功能​

• “集群管理-组件管理”模块，新增"监控组件"卡片，支持管理监控组件（Prometheus、Grafana、AlertManager）的安装与卸载。

• 集群模块新增“集群监控”功能，在已安装监控组件的前提下，支持查看集群下所有节点的资源使用情况。

• 集群下每个节点的详情页，新增“节点监控”功能，在安装监控组件之后，支持查看各节点的资源使用详情以及该节点下所有Pods的资源使用情况。

• 集群模块新增“健康检查”功能，集成Polaris组件，支持检测出集群与环境中可能影响稳定性、可靠性、可伸缩性和安全性的配置问题。

• 实例视图-环境层新增环境“健康检查”的功能，支持检测出各个实例配置文件中可能影响稳定性、可靠性、可伸缩性和安全性的配置问题。

• 资源视图-环境层新增“提交同步情况”的显示，支持在此查看对应环境的提交同步情况与GitOps错误日志。

• 部署模块、实例视图以及资源视图新增“批量部署”的功能，支持同时将多个应用服务批量部署至同一环境的功能。

• “实例-运行详情-更多详情”中，新增“YAML格式查看”的功能，支持以YAML格式查看实例配置文件的详情。

• 流水线列表中新增了“部署环境”列，用于展示流水线中包含的部署任务对应的环境。

• PV列表中，“所属集群”栏中新增集群的状态的显示。
• PVC列表中新增了“PV类型”的显示。

缺陷修复​

• 修复实例更新失败后，不能增减Pod的问题。

功能优化​

• 优化“实例-运行详情”界面的显示问题，完善了缺失字段的显示。
• 优化创建PV的过程，允许用户直接为其分配权限至特定项目，来避免错误绑定的情况。

删除​

• 移除“资源视图-网络详情”界面中Pods的CPU与内存使用量的折线图。
• 移除“资源视图-环境层”中的内存与CPU用量排行的列表。

基础功能

新增功能​

• “个人中心”新增“重置Gitlab密码”的功能，支持在此一键重置GitLab密码。
• 平台管理模块，新增“平台概览”页面，支持查看平台中在线人数统计图、平台总人数统计图、事务执行情况、Choerodon邮件发送情况、系统公告以及平台层的操作记录。

• 平台管理-角色管理，新增完善了平台层、组织层以及项目层各个菜单下的接口权限，支持为自定义角色分配菜单下更细的操作权限。
• 组织层-管理中心，新增“组织概览”页面，支持查看组织总人数统计图、项目情况、集群情况、应用服务概览、项目部署情况、事务执行情况以及组织层的操作记录。

• 项目层运营模块，新增“事务管理”页面，支持项目人员查看项目层事务实例的运行情况。
• 项目层-通知设置中，新增敏捷消息、DevOps消息、资源删除验证的Tab页，支持在此页面统一管理项目下各类消息通知事件的发送方式及通知对象。
• 新增“添加用户角色”、“停用组织”、“重置密码”、“导入用户”等事件的消息通知。

缺陷修复​

• 修复“平台管理-角色管理”中创建项目层自定义角色后，因为未选GitLab角色标签而导致的问题。
• 修复平台层的API统计偶现无数据的问题。

功能优化​

• 优化“忘记密码”的流程，Choerodon将直接为用户的邮箱发送重置密码的链接，用户可直接通过点击链接来修改密码。
• 优化Root用户的权限，Root用户默认拥有平台中所有组织所有项目的权限。
• 优化组织管理员的权限，组织管理员默认拥有对应组织下的Root权限。
• 优化组织层与项目层导入用户的Excel模板，添加了角色编码的提示，与角色编码可选的功能。
• 优化添加角色后的消息通知对象，改为通知“角色被添加者”。
• 优化平台层的树状结构的显示，支持左右拖动增加其宽度。

社区参与

感谢以下朋友在社区论坛中提出反馈和意见，在0.21版本更新中作出贡献，感谢大家一直以来的支持。

• @Pilipupu
• @lisen2023

更加详细的内容，请参阅Release Notes和官网用户手册。

安装文档：http://choerodon.io/zh/docs/installation-configuration/steps/

升级文档：http://choerodon.io/zh/docs/installation-configuration/update/0.20-to-0.21/

欢迎各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与贡献，帮助Choerodon猪齿鱼不断成长。Choerodon会持续优化，敬请期待。

-▼-

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

Choerodon平台中的开发和部署都是围绕应用服务来进行的，由此可见应用服务在DevOps实践过程中的重要性。本文旨在为大家介绍Choerodon v0.19及以上版本中的应用服务共享功能。

共享应用服务功能的背景

在详细介绍Choerodon平台中“共享应用服务”功能的使用之前，我们需要知道使用这个功能的原因是什么，以及这个功能可以解决什么问题。在说起Choerodon平台中的应用服务时，我们就不得不提微服务。正是因为微服务的出现，之前的单体应用架构带来的问题才得以解决。而下图也更为直观地指出了单体应用架构与微服务架构的区别。

通过上图，我们不难发现微服务架构中的应用服务会被分解为更小、完全独立的组件，这使得它们拥有更高的敏捷性、可伸缩性和可用性。换言之，微服务架构的基本思想就是：围绕业务领域组件来创建应用服务，让应用服务可以独立地开发、管理和交付。

通过微服务实现了组件化服务的开发和交付后，这些组件化服务按照项目需求组合起来，稍作修改，便是一个可用的产品。因此，尽管项目是暂时性的，但项目团队的交付物却能以组件的形式共享至其他项目，以此来避免重复造轮子的情况。而怎样将已有的应用服务快速地导入或部署到组织下其他项目呢？针对这个问题，共享应用服务的功能应运而生。

怎样使用共享应用服务功能？

当组织下其他项目需要用到本项目下某个应用服务时,项目所有者可以为此应用服务设置共享规则，以此来将对应版本的应用服务共享至其他项目。

以上便是Choerodon平台中共享应用服务功能的大致流程，下面我们就按照这个流程进行展开，带大家了解Choerodon中应用服务的共享功能。

共享应用服务​

• 添加共享规则

首先，选中一个目标应用服务，进入详情界面，选中“共享设置”，点击顶部的“添加共享规则”；在添加共享规则时，项目所有者可以选择将该应用服务的某一类型的所有版本全部共享出去，或者选择一个特定的应用服务版本共享至目标项目。最后选择“共享范围”，那么一条共享规则就这样添加成功了。

• 目前平台中预置可选的版本类型为以下5种，分别是：master、release、feature、bugfix和hotfix。
• 此处的版本类型是按照版本名中对应的分支类型来命名的；但可根据需求，在此填写一个自定义的版本类型。
• 若您想将该类型的所有服务版本共享出去，仅填写版本类型即可，不用再选择特定版本。

共享规则添加成功并生效之后，共享范围之内的项目便能获取到该服务对应版本的代码库与镜像，用于之后的二次开发或直接部署。

• 管理共享规则

共享规则添加成功之后，可以在之后对其进行灵活地修改或是直接删除；此处支持修改共享规则中的共享版本与共享范围；

共享规则更改后，平台将按照新的共享规则执行，但不会影响其他项目下已部署的实例。

导入共享应用服务​

应用服务的接收方，若发现已存在的应用服务并不能完全满足自己的项目需求。便可以选择“导入共享应用服务”，在已有代码库的基础上进行二次开发。

部署共享应用服务​

若共享的应用服务已经能够满足项目需求，此时部署人员便可直接在手动部署界面，将该服务对应的版本部署至本项目对应的环境。

总结​

共享应用服务的功能支持各个项目团队更方便地围绕业务来进行应用服务的组织，从而使得微服务弹性伸缩的特性可以得到充分地发挥，避免出现重复造轮子的情况。此外，以应用服务为中心进行开发和部署是Choerodon平台实践DevOps的重要步骤，所以应用服务相关的功能与体验也是我们一直都在关注的。

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

随着 Kubernetes 的广泛使用，如何保证集群稳定运行，成为了开发和运维团队关注的焦点。在集群中部署应用时，像忘记配置资源请求或忘记配置限制这样简单的事情可能就会破坏自动伸缩，甚至导致工作负载耗尽资源。这样种种的配置问题常常导致生产中断，为了避免它们我们用 Polaris 来预防。Polaris 是 Fairwinds 开发的一款开源的 Kubernetes 集群健康检查组件。通过分析集群中的部署配置，从而发现并避免影响集群稳定性、可靠性、可伸缩性和安全性的配置问题。

Choerodon 作为全场景效能平台，同样也是使用Kubernetes来部署和升级应用，如何保证集群稳定运行是十分关键的。为了满足 Choerodon 特性，Choerodon 团队借鉴了 Polaris 健康检查的实现原理，结合Choerodon的实际业务需求，在 Agent 组件中实现了一套自己的健康检查规则，用于更细粒度的检查集群，监控集群健康状态，从而保证集群稳定运行。通过对 Polaris 的实践，总结了一些对Polaris的认识和安装使用，希望对大家有所帮助。

关于Agent组件的功能,请参考Choerodon猪齿鱼 Agent——基于GitOps的云原生持续交付模型

Polaris的功能

Polaris是一款通过分析部署配置，从而发现集群中存在的问题的健康检查组件。当然，Polaris的目标可不仅仅只是发现问题，同时也提供避免问题的解决方案，确保集群处于健康状态。下面将会介绍Polaris的主要功能： Polaris 包含3个组件，分别实现了不同的功能：

• Dashboard - 以图表的形式查看当前Kubernetes workloads的工作状态和优化点。
• Webhook - 阻止在集群中安装不符合标准的应用
• CLI - 检查本地的yaml文件，可结合CI/CD使用

Dashboard​

Dashboard是polaris提供的可视化工具，可以查看Kubernetes workloads状态的概览以及优化点。也可以按类别、名称空间和工作负载查看。

概览集群状态​

• 查看集群健康评分
• 查看集群检查结果
• 查看集群版本、节点、pod、名称空间数量

按类别查看检查结果​

• Health Checks
• Images
• Networking
• Resources
• Security

按名称空间查看检查结果​

Webhook​

Polaris可以作为一个admission controller运行，作为一个validating webhook。它接受与仪表板相同的配置，并可以运行相同的验证。这个webhook将拒绝任何触发验证错误的workloads 。这表明了Polaris更大的目标，不仅仅是通过仪表板的可见性来鼓励更好的配置，而是通过这个webhook来实际执行它。Polaris不会修复workloads，只会阻止他们。

• 使用和dashboard相同的配置
• 阻止所有部署配置不通过的应用安装到集群
• 不仅仅能够查看集群当前存在的缺陷，还能预防缺陷

CLI​

在命令行上也可以使用Polaris来审计本地文件或正在运行的集群。这对于在CI/CD管道的基础设施代码上运行Polaris特别有帮助。如果Polaris给出的审计分数低于某个阈值，或者出现任何错误，可使用命令行标志来导致CI/CD失败。

• 检查本地文件或正在运行的集群
• 可以结合CI/CD,部署配置校验不通过时直接让CI/CD失败

安装与使用

如何安装polaris​

polaris支持kubectl, helm and local binary三种安装方式，本文选择最简单的安装方式，分别介绍三个组件的安装，详细的安装教程参考polaris安装

1.Dashboard安装​

Helm​

添加helm charts仓库

helm repo add reactiveops-stable https://charts.reactiveops.com/stable

更新charts仓库并安装Dashboard组件

helm upgrade --install polaris reactiveops-stable/polaris --namespace polaris

如果需要在本地查看Dashboard仪表盘，可以使用以下命令，进行本地端口转发

kubectl port-forward --namespace polaris svc/polaris-dashboard 8080:80

2.Webhook安装​

在集群中安装Webhook组件后，将会阻止不符合标准的应用部署在集群中。

Helm​

添加helm charts仓库

helm repo add reactiveops-stable https://charts.reactiveops.com/stable

更新charts仓库并安装Webhook组件

helm upgrade --install polaris reactiveops-stable/polaris --namespace polaris \
  --set webhook.enable=true --set dashboard.enable=false

3.CLI安装​

如果需要在本地测试polaris,可以下载二进制文件安装 releases page，也可以使用 Homebrew安装:

brew tap reactiveops/tap
brew install reactiveops/tap/polaris
polaris --version

使用CLI检查本地配置文件

polaris --audit --audit-path ./deploy/

可以将扫描结果保存到yaml文件中

polaris --audit --output-format yaml > report.yaml

如何使用Polaris​

上面简单的介绍了，polaris的安装与基本使用。但是，如果要根据我们项目的实际情况来结合polaris，使用默认配置就不能满足需求了。所以我们还需要知道如何定义polaris检查规则的配置文件，实现自定义配置。 在自定义配置polaris之前，我们需要先了解一下polaris检查的等级以及支持的检查类型。 polaris检查的严重等级分为error 、warning和ignore ，polaris不会检查ignore等级的配置项。 polaris支持的检查类型有：Health Checks、Images、Networking、Resources、Security,下面我们将一一介绍：

健康检查(Health Checks)

Polaris 支持校验pods中是否存在readiness和liveiness探针。

镜像(Images) | key | default | description | | ---------------------------- | -------- | ----------------------------------------- | | images.tagNotSpecified | error | 没有为镜像指定tag或者指定 latest时失败. | | images.pullPolicyNotAlways | ignore | 当镜像拉取策略不是 always时失败. | 网络(Networking)

资源(Resources)

polaris支持校验内存、cpu使用限制是否配置

确保相关配置存在:​

key	default	description
resources.cpuRequestsMissing	error	没有配置 resources.requests.cpu 时失败.
resources.memoryRequestsMissing	error	没有配置 resources.requests.memory 时失败.
resources.cpuLimitsMissing	error	没有配置 resources.limits.cpu 时失败.
resources.memoryLimitsMissing	error	没有配置 resources.limits.memory 时失败.

对于内存、cpu等资源配置，还可以配置范围检查。只有当配置在指定区间内才可以通过检查。

limits:
  type: object
  required:
  - memory
  - cpu
    properties:
    memory:
      type: string
      resourceMinimum: 100M
      resourceMaximum: 6G
    cpu:
      type: string
      resourceMinimum: 100m
      resourceMaximum: "2"

Copy

安全(Security)

根据上文的介绍，我们已经可以根据项目的实际情况，定义自己的扫描配置。如果觉得polaris提供的检查规则不满足需求的话，我们还可以自定义检查规则。 比如：我们可以自定义规则检查镜像来源，当镜像来自quay.io抛出警告

checks:
  imageRegistry: warning
customChecks:
  imageRegistry:
    successMessage: Image comes from allowed registries
    failureMessage: Image should not be from disallowed registry
    category: Images
    target: Container # target can be "Container" or "Pod"
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          not:
            pattern: ^quay.io

还可以配置集群中的检查白名单，比如跳过检查dns-controller是否设置hostNetwork

exemptions:
  - controllerNames:
      - dns-controller
    rules:
      - hostNetworkSet

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

在进行团队敏捷开发的过程中，会听到大家各种各样的疑惑：“我们项目的燃尽图怎么显示不出来？”，“燃尽图反映不了当前迭代真实的情况，没什么作用呀？”，“燃尽图有线条，但是具体是什么意思呢？”等等这一类的问题。造成了更多的时候，团队把燃尽图当成一个摆设，有它没它都一样。为了解决大家的这些疑问并且把燃尽图正确的使用起来，本文专门针对燃尽图的概念以及在Choerodon中燃尽图的运用进行介绍，帮助大家在敏捷路上不迷路。

什么是燃尽图

燃尽图用于表示一个敏捷迭代剩余工作量的工作图表，由横轴（X）和纵轴（Y）组成，横轴表示时间，纵轴表示工作量。可以实时、客观、直观展示当前冲刺任务的完成情况，达到预测项目当前迭代工作进展，并且提前预测出当前迭代有超前完成或者延期完成的情况。它是由项目中的所有团队成员共同维护的数据信息，提供的是实时客观的任务完成情况数据。维护好燃尽图的数据，可以实时提供准确的进度信息，提高了整个团队、项目的透明度。懂得运用燃尽图，可以更早的预测团队当前迭代开发的进度风险，让团队可以尽快消除风险。

如何维护Choerodon燃尽图的数据？

Choerodon燃尽图提供了三个维度的进度反馈：问题计数、故事点、剩余时间。

(1)问题计数​

根据当天的剩余问题个数来渲染图表，这里的问题包括故事、任务、子任务以及缺陷。

(2)故事点​

根据当天剩余的故事点来渲染图表。故事点需要在进行Sprint计划会议时由团队共同来估算，并且同步记录到Choerodon平台。

(3)剩余时间​

根据当天的剩余的预估时间来渲染图表。这个时间需要团队的迭代过程中实时更新工作记录。在Sprint计划会议上，每个问题的经办人需根据自身的工作速率，估算出完成问题需要的大致时间，并且同步记录到Choerodon平台。剩余时间的数据需要各个经办人在问题详情页面维护工作日志才能得到，更新工作日志后，剩余预估时间会自动调整。工作日志如下图所示：

通过维护工作日志，得到以下剩余时间维度的燃尽图：

此外，团队成员需在每日站会前或者问题状态变更后，及时在敏捷看板拖动卡片改变问题状态，燃尽图会实时显示当前迭代看板的剩余任务情况，也就是未燃尽的部分，直到迭代的问题彻底解决，也就是当前迭代的任务全部燃尽了。

Choerodon燃尽图上线条表示的意义？

Choerodon燃尽图提供一条特殊的参考线：期望值。这条线为团队的开发速率提供了一个较为标准、开发速率正常的参考线。团队成员可以通过实际剩余值线条和预期值线条来对比，了解当前开发的进度是否正常。 例如：

（1）如果剩余值低于期望值​

那说明该时间节点开发速率快，有提前完工的可能性。如果整个迭代内长期处于这种情况，那么就需要考虑当前迭代在规划时工作量是否饱和的问题了，接下来的迭代可以参考此次的速率进行规划，以及考虑是否提前结束当前迭代。

（2）如果剩余值高于期望值​

那说明该时间节点开发速率比预期较慢，有延迟迭代的可能性。如果长期存在这种情况，需要考虑当前迭代规划时是否有工作过饱和的情况，在接下来的迭代中吸取经验，并且考虑适当延期当前冲刺。如下图的冲刺就有延期的风险，需要PO或者敏捷教练及时了解情况消除风险。

Choerodon燃尽图在敏捷迭代各个历程如何使用？

(1)Sprint计划会议：当次迭代的工作量规划可依据历史冲刺的燃尽情况、燃尽速率进行更加合理的规划。

(2)每日站会：站会除了可以通过看板来了解各个问题的进展，也可以通过燃尽图来了解总体的进度。团队成员可根据燃尽图线条及时的了解工作进度，预测并提醒迭代可能面临的风险，及时的沟通消除这些隐患。

(3)回顾会：在迭代末，燃尽图就是当前迭代进行情况的很好的图表数据反馈。参照燃尽图的不同节点，团队可以更好的总结经验教训，在以后的迭代周期扬长避短。

Choerodon燃尽图为什么要使用多种维度来展示进度？

(1)问题计数的维度​

是以当前迭代的问题卡片数量为衡量单位。相对剩余时间粒度较粗，相对故事点较为独立。这种维度不需要成员维护过多的数据，直接以个数来评估。

(2)以剩余时间的维度​

通过团队录入实际的剩余工时，可以得到比较准确的进度信息。团队成员每个工作时刻都在完成任务，努力把问题到达done的状态，使实际的剩余值更加靠近期望值，使得燃尽图的线条在更小的粒度范围跌宕起伏。以剩余时间的维度查看燃尽图虽然能够反映出团队成员工作的状况，但却不能更加明晰的表示出功能完成的进度。

(3)以故事点的维度​

故事点的完成标志着一个story到了done的状态，也就是这个用户故事通过设计、开发、测试、完成的所有阶段，故事下的各个子任务也完成，用户故事已经验收通过了。站在客户的立场就是这个需求点可以交付了。也就是说完成一个用户故事，就是实现了一些故事点的价值交付。所以在敏捷开发过程中，掌握使用故事点燃尽图来维护进度的能力后，团队应对变化、快速交付价值的能力也会得到极大的提高。

这三个维度在不同情况下适当的结合运用，可以得到更加准确、客观、直观的迭代进度展示。

总结

燃尽图作为敏捷开发过程中一个重要的图表，能提供迭代或者项目进度和最新任务状态的报告，并对故事点、任务变化、工时变化这些迭代过程的重要数据指标进行直观的展示，确保团队中每个成员都能统一进度。此外，将燃尽图展示在团队成员面前，能够很好的激励团队成员积极参与项目，高效的完成迭代任务，提前处理开发可能遇到的风险。

关于团队的敏捷实践的其他相关信息，可以参考以下文章：

• 使用Choerodon平台进行敏捷需求管理可参考Choerodon猪齿鱼敏捷管理实践（一）:需求管理

• 结合Choerodon平台敏捷管理模块进行冲刺管理可参考Choerodon猪齿鱼敏捷管理实践（二）：冲刺管理。

• 组织Sprint计划会议、每日站立会议、评审会、回顾会等敏捷会议可参考Choerodon猪齿鱼敏捷管理实践（三）：敏捷会议

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

近几年，很多公司都在使用敏捷，最开始时候，是从3-9人的小团队开始尝试的，scrum就是在小团队中实施的敏捷，实践起来比较简单。如果是多个业务团队和开发团队一起协作，人数达到上百人，该如何管理产品开发进度呢？又如何让产品及时顺应市场需求呢？SAFe就可以解决这些问题。本文通过介绍什么是大规模敏捷框架SAFe以及Choerodon猪齿鱼如何聚焦SAFe框架理念进行大规模敏捷实践，带大家了解面向企业的大规模敏捷。

什么是大规模敏捷框架SAFe​

• SAFe 是一个企业级的大规模敏捷框架，它基于精益和敏捷的最佳实践。大规模敏捷主要针对系统较大，团队较多，业务复杂的项目。
• SAFe 的理论基础包括精益-敏捷原则、敏捷核心价值、精益-敏捷领导、精益-敏捷思维、敏捷实践社区、敏捷的实施经验。
• SAFe 可以处理大规模复杂的应用开发，使用 SAFe 可以获得以下好处：
  • 生产效率提升 20-50%
  • 质量提升大于 50%
  • 产品发布缩短 30-75%
  • 员工满意度和忠诚度提升

SAFe框架​

SAFe 的一个核心概念可以概括为分层，可以分解为团队层、项目群层、价值流层、投资组合层。

团队层​

敏捷团队是由5-11人组成的跨职能小组，包括所有必要的角色。它是确保在每一次迭代中定义、构建、测试并且交付增值。为了降低沟通成本及文档成本，通常敏捷团队的规模较小。

在团队级的SAFe中，这个框架使用Scrum和看板，冲刺采用至少2周一个迭代周期，并且交付有价值的、测试完备的、可工作的系统。团队工作的用户故事（开发特性所需的小块功能）列表来自项目群的产品列表。

没有敏捷团队，就不可能有火车。他们为敏捷发布火车（ART）乃至整个企业提供动力。ART负责提供更大的解决方案价值。火车上的所有团队都与其他团队合作，为“愿景”和“路线图”做出贡献， 并参加ART活动。此外，他们主要负责构建持续交付管道和DevOps功能。

项目群层​

由敏捷团队、主要利益相关者及其他资源组成的一个项目群结构，被称为“敏捷发布火车（ART）”。 敏捷发布火车（ART）是典型的虚拟组织，它包含定义和交付价值所需要的所有人员； 具有定义、实现、测试、部署、发布和操作解决⽅案所需的所有能力(包括：软件、硬件、固件等其他能力)。ART的目的是通过⼀个明确的愿景、路线图和项目群待办事项列表，使管理层、团队和利益相关者向⼀个共同的使命保持协调⼀致。敏捷发布火车交付的是⼀个持续的价值流，如下图长期存在的敏捷发布火车：

在项目群层，敏捷发布火车（ART）采用10-12周为一个发布周期。敏捷发布火车由多个冲刺组成，这一系列冲刺发布一个或多个程序增量（PI）。ART可在每个PI迭代末设置一个特殊的IP冲刺，各团队可以提出PI过程中产生的问题、分析问题产生的原因，提出解决问题的方案，确定是否可放在接下来的PI计划中，以及为接下来的PI进行预计划。

程序增量（PI）提供了⼀个更⼤的、更具有战略意义的PDCA时间盒，用来收集和评估系统级的绩效表现。它还为整列火车的跨领域计划、集成、演示、检视和调整(I&A)提供了节奏。PI的时间盒是固定的。敏捷发布火车上的所有团队都同步相同的PI长度(通常是8 - 12周)，并且有共同的迭代开始/结束⽇期和持续时间。PI最常见的模式是四个开发迭代，加⼀个创新和计划（IP）迭代。

PI是针对ART的，而迭代是针对敏捷团队的。这是⼀个固定的时间段，用于构建和验证整个系统增量，所有敏捷团队保持同一开发进度，每个迭代都必须产出对迭代任务有价值的内容，在较短的周期内防止实现和迭代任务的偏离。一旦发现偏离，可以及时纠正。每个PI将节奏和同步应用于：

1. 方便规划 ；
2. 限制在制品（WIP）；
3. 总结具有价值的反馈；
4. 确保前后⼀致的ART回顾。

价值流层​

价值流层可以应对更大更复杂的产品，一个敏捷火车已经不能满足开发工作，需要多个敏捷火车协同工作，由多个角色、组件和事件来帮组协调和集成各ART。

价值流层的增加是因为产品复杂度的增加造成。它需要完成定义解决方案，生成解决方案。这里的方案是一个高层面的解决方案，比如需要软件A，软件B,第三方软件，硬件系统A，硬件系统B,系统之间如何集成等。

投资组合层​

投资组合层，从价值流的角度来分析史诗级的需求。史诗可以以价值流的角度分解成能力层、产品特性、用户故事等，然后由敏捷团队来实现用户故事。 Choerodon猪齿鱼的大规模敏捷实践。

在Choerodon猪齿鱼大规模敏捷管理中，主要应用了SAFe的团队层和项目群层概念进行大规模敏捷实践。我们将多个敏捷团队组建成一个项目群，由项目群的所有者统一管理并规划。制定开发节奏（迭代周期）、开发内容等，项目群中的任何项目都在同一个节奏上进行，从而提升产品开发交付周期。

如上图，在Choerodon猪齿鱼大规模敏捷管理的PI过程中，首先需要制定PI目标，即各个团队制定他们基本的业务目标，然后就接下来的开发目标达成⼀致。接着需要制定出特性，特性是满足利益相关⽅需要的服务。每个功能均包括收益假设和接受标准，并按需要进行大小调整或拆分，以由单个敏捷发布火车（ART）在程序增量（PI）中交付。当特性使能规划完毕后，就要把制定好的特性-PI，特性-史诗，规划PI关联起来了，并使用项目群公告板查看当前PI的各个子项目/冲刺/特性之间的关联，查看当前PI的各个子项目的冲刺周期，以及各个冲刺所要完成的特性。

以上的这些都可以体现在Choerodon猪齿鱼大规模敏捷管理的看板中，通过移动看板泳道中的特性卡片，来体现团队任务状态的变化，同时体现整个ART所有特性的状态流转。

总 结​

通过上述对 SAFe相关理论的介绍，以及Choerodon猪齿鱼实践经验的分享，大家对SAFe 的概念和实施方式有一个基本的了解。SAFe适用于大型团队的合作开发，帮助团队提高协作性，降低团队管理的复杂性，为Choerodon猪齿鱼大规模敏捷的开发奠定了坚实的理论基础。

参考资料：

• https://www.scaledagileframework.com/

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

Choerodon猪齿鱼全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

2019年12月30日，Choerodon猪齿鱼发布0.20版本，本次更新测试模块相较于上一版本会有较大的改动，其它功能模块都进行了不同程度的修改和优化，如平台功能、协作、部署等，欢迎各位更新体验。

• 发布版本：0.20
• 发布时间：2019年12月30日
• 更新范围：协作、开发、部署、测试以及平台管理功能

下面就为大家带来详细的模块介绍。

新增功能

协作​

迭代计划、工作列表​

• 支持通过点击待办事项上的经办人筛选问题。
• 故事地图支持在需求池按无版本筛选。
• 筛选问题支持选择历史版本和历史冲刺。

知识库​

• 支持查看最近的知识活动。
• 支持回收站功能。

开发​

• 应用服务模块新增删除停用状态应用服务的功能，支持删除停用后的应用服务。
• 代码管理模块选择应用服务的下拉框中新增“最近使用”的快捷方式。
• “代码管理”模块复制仓库地址，新增支持复制仓库的SSH地址。
• 资源模块“实例视图-环境层”中新增部署配置的Tab页，支持有环境权限的人员在此处创建与管理部署配置。
• 流水线列表中新增查看该条流水线所有执行记录的快速入口。
• 项目层-通知设置中，新增敏捷消息、DevOps消息、资源删除验证的Tab页，支持在此页面统一管理项目下各类消息通知事件的发送方式及通知对象。

测试​

此次发布的新版本相较于上一版本会有较大的改动，本次更新对其结构和功能进行了大幅度的调整和优化：

• 计划和执行合并，便于测试人员更加直观的进行测试计划管理。
• 新版测试计划支持自动同步用例，便于用户快速同步用例到计划的执行。
• 测试计划支持根据自己的需要从用例更新内容到测试计划。
• 测试计划添加测试总览，以便于测试人员快速了解计划的测试状态。
• 移除自动化测试和用例的关联。
• 移除用例与版本的强关联。
• 去除用例文件夹的层级约束，用户可以创建无限层级的用例文件夹，使用户可以更加灵活的划分用例。

部署​

• 集群模块新增“组件管理”功能，支持管理CertManager组件的安装与卸载。

• 集群模块新增PV管理的功能，支持在集群中创建与管理NFS与HostPath类型的PV。

• 手动部署界面新增资源配置模块，支持在部署时就为对应的实例创建好关联的网络和域名。

• 资源模块新增PVC管理的功能，支持在环境中创建与管理PVC。

• 资源模块实例层中Pod详情页新增删除Pod的功能，支持删除实例中的某个Pod。
• 资源模块实例层中查看实例事件时新增全屏查看的功能。

平台管理功能​

• 项目层添加webhook设置功能，项目管理员可以自定义hook配置。

• 平台层添加webhook日志功能，记录webhook的发送记录，方便管理员审计。

• 平台层消息服务添加配置webhook发送设置，包括是否启用webhook发送方式设置、webhook模板内容定义。
• 平台层消息服务添加消息类型的类别划分。
• 平台层任务管理支持查看可执行程序，开发者可以直接查看平台层的可执行程序及其参数信息。
• 组织层任务管理支持查看可执行程序，组织管理员可以直接查看组织层的可执行程序及其参数信息。
• 平台层添加LOV配置，以便于开发人员能快速进行LOV选择框的配置。
• 平台层添加快码维护，以便于开发人员能够快速进行下拉选择框的配置。
• 平台层添加描述维护，以便于开发人员能够快速进行多语言维护，目前仅支持中文和英文。
• 组织层用户管理新增LDAP同步设置的功能，支持手动同步与自动同步LDAP用户的操作，且能在此查看手动同步与自动同步的记录。

• 项目层新增通知设置，统一管理项目下各类消息通知事件的发送方式及通知对象，包括敏捷消息、DevOps消息、资源删除验证。

缺陷修复

协作​

迭代计划、工作列表​

• 修复了问题详情知识链接跳转问题。
• 修复了问题列表的优先级字段缺失。
• 修复了问题详情快速创建子任务多次点击会重复创建。
• 修复了项目群公告板未关联子项目报错。

知识库​

• 修复了问题详情知识链接跳转问题。
• 修复了知识库部分白页的情况。

开发​

• 修复了导入应用服务时服务编码、名称长度限制问题。
• 修复了权限分配界面为特定成员分配权限时必选一个成员的问题。

部署​

• 修复了密文在环境库中为明文存储的问题。
• 修复了导入共享服务所属项目数据不一致的问题。
• 修复了人工触发流水线中，第一个阶段为空时，执行失败的问题。
• 修复了人工触发中。

平台管理功能​

• 修复了Chrome79.0.3945.79版本浏览器兼容性问题。

功能优化

协作​

迭代计划、工作列表​

• 优化了任务中的子任务，支持关联知识。
• 优化了看板默认泳道配置调整为经办人。
• 优化了配置看板在无冲刺时也可以配置。
• 优化了侧栏顶部，去除文字说明。
• 优化了字段解释icon、说明，统一样式。
• 优化了字体颜色以及字号大小，统一样式。

知识库​

• 优化了侧栏顶部，去除文字说明。
• 优化了字段解释icon、说明，统一样式。
• 优化了字体颜色以及字号大小，统一样式。

开发​

• 优化了应用服务名称的字符限制，将其放宽至40个字符。

部署​

• 资源模块实例层中，优化了实例状态与其对应的Command状态的逻辑。

• 优化了项目层的Harbor库默认置为私有。
• 优化了手动部署后的页面跳转。
• 优化了分支列表中的排序问题。
• 优化了环境配置中的状态及其对应的操作，支持删除停用与未连接状态的环境。

• 优化了资源模块中配置映射与密文的状态显示。

平台管理功能​

• 优化了平台层优化消息服务页面，以树形结构展示使操作更加便捷，移除多余的消息模板，一种消息类型的不同发送方式分别只对应一个模板。

• 优化了管理中心与项目设置中通用模块的结构，仓库配置作为单独维护模块，使用户的操作更加便捷。
• 根据消息通知的结构变化，同步优化了“个人中心-接收设置”的结构与消息类型。

社区参与

感谢以下朋友在社区论坛中提出反馈和意见，在0.20版本更新中作出贡献，感谢大家一直以来的支持。

• @lisen2023

更加详细的内容，请参阅Release Notes和官网。

欢迎各位朋友通过 Choerodon 的GitHub和猪齿鱼社区进行反馈与贡献，帮助 Choerodon 猪齿鱼不断成长。Choerodon 会持续优化，敬请期待

-▼-

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

猪齿鱼此次发布的新版本相较于上一版本会有较大的改动。其界面显示和菜单层级结构等都进行了不同程度的修改和优化。为帮助您更好地使用新版本，猪齿鱼特此作出以下版本界面变动说明，希望您仔细阅读。

此说明将以0.18版本作为对照，按照原有功能模块：敏捷管理、应用管理、开发流水线、部署流水线、测试管理、知识管理、项目设置一一进行界面变动说明。

首页

登录成功后，您会直接进入项目首页（工作列表页），可以通过顶部导航栏项目入口进入项目列表页切换项目。

左侧为功能菜单，0.19版本依据应用开发流程设置菜单结构，一级菜单为协作、开发、测试、部署和设置。

敏捷管理功能界面变动

敏捷管理中的待办事项、问题管理和发布版本合并移动至协作模块中的工作列表；项目群和故事地图移动至协作模块下同名功能；活跃冲刺移动至开发模块中，并更名为迭代规划；报告工作台不再使用。

应用管理界面变动

应用管理中的应用移动至开发模块下的应用服务，应用版本和发布同步移动至应用服务，点击列表中的应用服务即可浏览。

开发流水线界面变动

开发流水线中的代码仓库、分支、标记、合并请求、持续集成、代码质量移动至开发模块下的代码管理，开发控制台不再使用。

部署流水线界面变动

部署流水线中的环境管理和部署配置移动至部署模块中的环境配置；应用部署移动至新版应用部署下的部署页面；实例、资源移动至应用部署下的资源页面；流水线移动至应用部署下的同名页面。

测试管理界面变动

测试管理中，测试用例移动至测试模块中的用例库；测试计划移动至计划；测试执行移动至执行；自动化测试移动至自动化。

知识管理界面变动

知识管理中的文档管理更名为知识库，组织知识库入口在顶部导航栏，项目知识库入口在协作模块。

设置相关界面变动

0.19版本将所有设置相关操作整合到了一起，包含通用、页面、测试和问题。

原项目信息移动至设置中的通用；字段和页面设置移动至设置中的页面；测试相关设置移动至设置中的测试；敏捷管理问题设置（模块管理、快速筛选、通知设置和问题链接）移动至设置中的问题。原项目角色分配整合至协作模块下的团队成员。

原组织设置更名为管理中心，入口移动至顶部导航栏右侧。

关于猪齿鱼​

Choerodon 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

Choerodon猪齿鱼全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

2019年10月28日，Choerodon猪齿鱼发布0.19版本，此版本相较于上一版本有较大改动，其界面显示和菜单层级结构等都进行了不同程度的修改和优化，本更新公告将为您介绍新版协作、开发、测试、部署等功能模块。

• 发布版本：0.19
• 发布时间：2019年10月28日
• 更新范围：全局

下面就为大家带来详细的模块介绍。

协作

结合精益敏捷对业务需求、工作任务进行管理，打造高效协作生态。

迭代计划​

原敏捷管理模块下的活动冲刺，通过看板展示了您的团队目前正在进行的一次迭代周期，您可以在此了解每个问题的进行情况，以及每个人的任务情况，通过直接拖拽问题至不同的列可以更改问题的状态。

工作列表​

集合了待办事项、问题列表和版本列表，您可以在此创建问题、划分版本、分配史诗、规划冲刺，通过多选排列来整理大量待办事项，并通过拖动事务对用户故事和缺陷进行排序。您还可以使用灵活搜索功能进行过滤，以查找特定的用户故事或缺陷。

故事地图​

用户故事地图从史诗的维度来展示待办事项，有利于产品管理者以及团队成员将产品待办问题清单转化为可视化的过程，确保团队以“客户至上”的心态来建立他们的产品，快速且实时地传递价值。

知识库​

原知识管理，在线自定义内容编辑平台，集中管理开发过程中用户需求分析、产品设计等知识文档，项目成员实时共享，协作编辑。

注意：Choerodon猪齿鱼在0.19版本正式取消Wiki管理功能，所有文档内容管理相关操作请大家在知识库中进行。

Wiki管理和知识管理在0.18版本中是并行状态，方便用户进行数据迁移。如您在Wiki空间中还有新的增改，可点击知识管理菜单栏上方“Wiki迁移”进行手动二次迁移，0.19版本不可再进行迁移操作。

团队成员​

项目团队成员管理工具，在此进行权限划分和角色分配，帮助更好地规划团队。

开发

提供迭代规划和持续集成的流水线，帮助简化应用开发，实现快速迭代。

应用服务​

管理应用下某项具体服务，包括创建、导入、删改、共享和权限分配等操作，关注应用具体的业务模块。

代码管理​

整合梳理了开发应用服务需要用到的所有操作、流程与功能，用于支持团队的协作开发与持续集成，包括：代码仓库、分支管理、合并请求、持续集成、标记、代码质量管理。

测试

原测试管理功能，为用户提供敏捷化的持续测试工具，包括用例库、计划、执行、自动化测试，可以有效地提高软件测试的效率和质量，提高测试的灵活性和可视化水平，最终减少测试时间，让用户将主要精力放到软件功能构建上。

部署

应用启停，状态监控，容器管理，实现流水线式多环境一键部署。

应用部署​

提供了可视化与一键式的手动部署方式，并支持创建CD流水线来预置多个部署任务或人工卡点任务，从而实现了部署流程的自动化。

环境配置​

支持灵活配置项目下所有的环境，可以查看GitOps日志、管理部署配置、分配权限和设置资源安全。

集群​

用于运行K8S的托管群组，帮助用户在此统一调配资源和管理环境。

运营

整合了敏捷报表、测试报表和DevOps报表，从多维度直观地记录和展示您项目、迭代、版本、进度等汇总情况，以及各个应用的代码提交情况、应用构建情况以及应用的部署情况。

设置

0.19版本设置整合了原敏捷管理、测试管理、项目设置，您可以在此进行项目通用信息设置、问题、页面和测试状态相关设置。

社区参与

感谢以下这些朋友在社区论坛中提出反馈和意见，在0.19版本更新中作出贡献，感谢大家一直以来的支持。

@mq2xyz @Bory

更加详细的内容，请参阅Release Notes和官网用户手册。

欢迎各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与贡献，帮助Choerodon猪齿鱼不断成长。Choerodon会持续优化，敬请期待。

-▼-

Choerodon猪齿鱼已开通官方微信交流群，欢迎大家添加猪齿鱼微信（ID:choerodon-c7n）入群。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon
• 微信公众号：Choerodon猪齿鱼
• 微博：Choerodon猪齿鱼

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

Kubernetes 的安全是一个相当广泛的主题，涉及很多高度相关的内容。和探讨大部分安全性相关的问题一样，首先需要考虑威胁模型——谁可能攻击你的系统，以及他们如何做到这一点。这可以帮你确定安全工作的优先级。对于大多数 Kubernetes 应用有三类主要的攻击者：

1. 外部攻击者：当你在内部或云上部署应用时，你可能面临来自集群外的攻击。这类攻击者没有系统权限，所以会专注于公开的服务，会尝试获取访问权限并提升权限。
2. 泄露的容器：Kubernetes 集群通常运行着各种工作负载。攻击者也可能利用集群中运行的容器的漏洞进行攻击，在这种时候，要最大程度降低漏洞攻击影响到整个集群的风险。攻击者可以访问单个容器的资源，因此限制容器权限至关重要。
3. 恶意用户：Kubernetes 是一个多用户系统。攻击者可能拥有某用户的账户，并企图获得更多权限，这种情况比较复杂，要具体分析，需要限制不同用户的访问权限。

围绕云原生基础概念构建的模型可以帮你建立对 Kubernetes 安全的总体认识。下图将安全划分为四个层级，被称为云原生安全的4C模型。管理员将在不同的层次上应对三类攻击者。

4C 指的是云（Cloud）、集群（Cluster），容器（Containers）和代码（Code）

正如你在图中所看见的，4C 模型中每部分的安全性都是相互包含的。只依靠增强代码层次安全来预防云、集群和容器中安全漏洞是几乎不可能的。适当提高其他层的安全能力，就已经为你的代码提供强大的基础安全保障。下面将详细介绍这四部分内容。

Cloud

大多数情况下，云为 Kubernetes 集群提供可信的计算资源。如果云的基础设置是不可靠的（或以易受到攻击的方式配置），那就没有办法保证在这个基础上构建的 Kubernetes 集群的安全性。每一个云服务提供商都向他们的客户提供大量如何在其环境安全运行负载的建议。下面提供常用云服务厂商的安全文档链接，并且提供了构建安全 Kubernetes 集群的建议。

云服务提供商安全文档列表​

如果你运行在自己的硬件上或者其他云服务提供商，请查阅文档获取最佳安全实践。

通用的安全建议​

• 理想情况下，不开放 Kubernetes Master 节点公网访问，并且限制能够访问集群 Master 节点的 IP 地址。

• 通过网络安全组等配置工作节点只接受 Master 节点上指定端口的连接，并且接受 Kubernetes 中服务类型为 NodePort 和 LoadBalancer 的连接。如果可能，这些节点也不应该暴露在公网中。

• Kubernetes 访问云服务提供商的 API，每一个云服务提供商都赋予 Kubernetes 的 Master 和 Node 不同的权限。该访问权限遵循其管理资源所需资源的最小权限原则。

• 访问 etcd， 只有在 master 节点中通过 TLS 可以访问 etcd。

• 在所有可能情况下，对停用状态的的驱动设备加密。ectd 拥有整个集群的状态（包括密钥信息），因此对其磁盘要在其停用的时候加密。

Cluster

Kubernetes 是一个复杂的系统，下图展示了一个集群不同的组成部分，为了保证集群整体的安全，需要仔细保护每一个组件。

将需要注意保护的集群组件划分成两个部分：

1. 保护组成集群的可配置组件
2. 保护运行在集群中的应用

集群的组件​

1. 控制对 Kubernetes API 的访问

   使用 TLS 进行安全通讯。Kubernetes 期望默认情况下使用 TLS 对集群中所有 API 通信进行加密，大多数安装方式都会创建必要的证书并分发给集群组件。

   API 认证。在安装集群时，为API服务器选择与通用访问模式匹配的身份验证机制。例如，小型单用户集群可能希望使用简单的证书或静态Bearer令牌方法。较大的群集可能希望集成现有的OIDC或LDAP服务器，以将用户细分为多个组。更多有信息请参考认证。

   API 授权。一旦通过身份验证，每个API调用也都有望通过授权检查。Kubernetes 附带了一个集成的基于角色的访问控制（RBAC）组件，该组件将传入的用户或组与捆绑到角色中的一组权限进行匹配。这些权限将动词（get，create，delete）与资源（pods，service，nodes）结合在一起，并且可以是命名空间或集群作用域。提供了一组现成的角色，这些角色根据客户端可能要执行的操作提供合理的默认责任分离。更多有关信息请参考授权

2. 控制对 Kubelet 的访问。

   Kubelet 在端口10250和10255上提供小型 REST API。端口10250是读/写端口，而10255是具有API端点子集的只读端口。这些端点授予对节点和容器的强大控制权。默认情况下，Kubelets允许未经身份验证对此API进行访问。生产集群应启用 Kubelet 身份验证和授权，可以通过设置 --read-only-port=0 来禁用只读端口，但是10250 端口用于系统指标收集和其他重要功能，所以开发者必须仔细控制对此端口的访问。更多有关信息请参考Kubelet身份验证/授权

3. 保护集群组件不受损坏

   • 限制对 etcd 的访问。对API的etcd后端的写入访问权等同于在整个集群上获得root权限，而读取访问权也可以获取集群信息。管理员应始终使用从API服务器到etcd服务器的强凭据，例如通过TLS客户端证书的相互身份验证，通常建议 etcd服务器隔离在仅API服务器可以访问的防火墙后面。
   • 限制对Alpha或Beta功能的访问。Alpha和Beta Kubernetes功能正在积极开发中，并且可能会存在限制或错误，从而导致安全漏洞。始终评估Alpha或Beta功能可能提供的价值，以防对您的安全状况造成潜在风险。如有疑问，请禁用不使用的功能。
   • 启用审核日志记录。审核记录器是一项Beta版功能，可记录API的行为，在出现问题后提供分析依据。
   • 经常轮换基础设施凭证。密钥和凭证生存周期越短，就越难被攻击者利用。
   • 在启用第三方集成之前，请先进行审查。
   • 停用时加密 ectd。etcd数据库将包含可通过Kubernetes API访问的所有信息，可能使攻击者深入了解群集的状态。
   • 接收有关安全更新和报告漏洞的警报。

集群中的应用​

根据应用程序受到的攻击，关注安全的特定方面。例如，运行中的服务 A 对于其他应用非常重要，而服务 B 容易受到资源耗尽攻击，如果不设置服务 B 的资源限制，就会因为服务 B 耗尽资源导致服务 A 不可用。所以需要注意下面几个常见安全措施：

• 定义资源限制

  默认情况下，Kubernetes 集群中对所有资源没有对 CPU 、内存和磁盘的使用限制。可以通过创建资源配额策略，并附加到 namespace 中来限制资源的使用。

  下面的例子将限制命名空间中Pod 的数量为4个，CPU使用在1和2之间，内存使用在1GB 和 2GB 之间。

  # compute-resources.yaml
  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: compute-resources
  spec:
    hard:
      pods: "4"
      requests.cpu: "1"
      requests.memory: 1Gi
      limits.cpu: "2"
      limits.memory: 2Gi
      requests.nvidia.com/gpu: 4
  

  Copy

  分配资源配额到命名空间：

  kubectl create -f ./compute-resources.yaml --namespace=myspace
  

  Copy

  查看 namespace 资源使用情况：

  [root@localhost ~]# kubectl describe quota compute-resources --namespace=myspace
  Name:                    compute-resources
  Namespace:               myspace
  Resource                 Used  Hard
  --------                 ----  ----
  limits.cpu               0     2
  limits.memory            0     2Gi
  pods                     0     4
  requests.cpu             0     1
  requests.memory          0     1Gi
  requests.nvidia.com/gpu  0     4
  

  Copy

  也可以为 Pod 添加资源限制，设置内存请求为 256MiB，内存限制为512MiB

  apiVersion: v1
  kind: Pod
  metadata:
    name: default-mem-demo
  spec:
    containers:
    - name: default-mem-demo-ctr
      image: nginx
      resources:
        limits:
          memory: 512Mi
        requests:
          memory: 256Mi
  

  Copy

• Pod 安全策略

  作为 Pod 的组成部分，容器通常配置有非常实用的安全默认值，这些默认值适用于大多数情况。但是，有时 Pod 可能需要其他权限才能执行其预期任务，在这种情况下，我们需要增强 Pod 的默认权限。安全上下文定义了 Pod 或容器的特权和访问控制，安全上下文设置有：

  1. 委托访问：基于用户ID 和用户组ID 权限去访问资源对象（如文件）。

  2. SELinux：为对象分配安全标签

  3. 以特权或非特权用户运行

  4. Linux 功能：为进程提供一些特权，而不去赋予它root用户的所有特权

  5. AppArmor：使用程序配置文件来限制单个程序的功能。

  6. Seccomp：过滤进程的系统调用

  7. 允许提升权限（AllowPrivilegeEscalation）：子进程能否获得父进程更多的权限。这个布尔值直接控制是否在容器进程上设置了 no_new_privs 标志。在以下情况下 AllowPrivilegeEscalation 始终为 true——一是，以特权OR运行；二是，具有 CAP_SYS_ADMIN。

     在 securityContext 字段下配置安全策略，在 Pod 中指定的安全策略将被应用于所有容器，容器中指定的安全策略应用于单个容器，当它们重复时，容器级会覆盖 Pod 级的的安全策略。

     apiVersion: v1
     kind: Pod
     metadata:
       name: security-context-demo
     spec:
       securityContext:
         runAsUser: 1000
         runAsGroup: 3000
         fsGroup: 2000
       volumes:
     

     Copy

  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false
  

  Copy

  
  更多有关信息请参考[Pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
  
  

  Copy

• 网络规则

  Kubernetes允许来自集群中任何容器的所有网络流量发送到集群中的任何其他容器并由其接收。当尝试隔离工作负载时，这种开放式方法没有帮助，因此需要应用网络策略来帮助开发者实现所需的隔离。Kubernetes NetworkPolicy API使开发者能够将入口和出口规则应用于选定的Pod，用于第3层和第4层流量，并依赖于实现容器网络接口（CNI）的兼容网络插件的部署。

  网络策略是 namespace 作用域，并根据匹配标签（例如，tier：backend）的选择应用于Pod。当NetworkPolicy对象的Pod选择器与Pod匹配时，根据策略中定义的入口和出口规则来管理进出Pod的流量。 所有来自或发往该Pod的流量都会被拒绝，除非有允许它的规则。

  要在Kubernetes集群中正确隔离网络和传输层的应用程序，网络策略应以“拒绝所有”的默认前提开始。然后，应将每个应用程序组件及其所需源和目标的规则逐个列入白名单，并进行测试以确保流量模式按预期工作。

• 密钥管理

  Kubernetes 使用 Secrets 保护应用程序需要访问敏感信息——密码、X.509证书、SSH密钥或OAuth令牌等。它通过卷装入，对它的访问严格限于那些需要使用它的实体（用户和Pod），且当存储在磁盘上时（静止状态）它是不可访问或只读的。

需要考虑的全部安全问题如下：

Contanier

为了在 Kunernetes 中运行软件，必须将它打包成容器。需要考虑下面的注意事项，来保证容器符合 Kubernetes 安全配置。

• 最小化镜像

  理想情况下，使用应用程序二进制文件和二进制文件所依赖的的任何相关项来创建镜像。事实上，没有什么阻止开发者将 scratch 作为基础镜像，并将静态链接的二进制文件复制到镜像中。它没有其他依赖，镜像中包含单个文件，以及一些描述容器如何运行的元数据。最小化镜像加快镜像的分发速度，并且显著减少容器内部的受攻击面。

• 基础镜像

  但是这并不总是可行的，因此需要慎重选择基础镜像。最佳的方法是使用操作系统供应商支持的镜像，或者是 docker hub 上官方支持的镜像。不要盲目使用之前未经过审查的不受信任来源的镜像，尤其是在生产环境中。

• 镜像扫描

  镜像扫描对于保障容器应用的安全至关重要，确保您的镜像定期通过信誉良好的工具进行扫描，可以使用 CoreOS 的 Clair 之类的工具扫描容器中的已知漏洞，它是容器镜像的静态漏洞分析器。

• 镜像的签名和执行

  使用 CNCF 项目的的 TUF 和 Notary 对容器进行签名，在执行前验证签名，确保镜像的正确没有被篡改。

• 禁止特权用户

  在构建镜像时，创建最低操作系统权限的用户完成容器的运行。

Code

最后是代码级别，这是程序员能掌控的被攻击面，但不在 Kubernetes 的安全保护范围，提供如下建议：

• 仅通过 TLS 访问

  如果您的代码需要通过TCP进行通信，则理想情况下，它将提前与客户端执行TLS握手。除少数情况外，默认行为应是对传输中的所有内容进行加密。

• 限制通信范围

  无论什么情况下，程序只应该公开必要的端口。

• 第三方依赖安全性

  确保第三方依赖是安全的。

• 静态代码分析

  大多数语言都提供了静态代码分析，可以分析代码中是否存在潜在的不安全编码实践。

• 动态探测攻击

  自动化工具可以针对您的服务尝试会破坏服务的攻击。这些包括SQL注入，CSRF和XSS。最受欢迎的动态分析工具之一是OWASP Zed Attack代理。

更多关于Kubernetes系列的文章欢迎阅读：​

• 从0开始使用Kubernets系列（七）：网络
• 从0到1使用Kubernetes系列（六）：数据持久化实战
• 从0到1使用Kubernetes系列（五）：Kubernetes Scheduling
• 从0到1使用Kubernetes系列（四）：搭建第一个应用程序
• 从0到1使用Kubernetes系列（三）：使用Ansible安装Kubernetes集群
• 从0到1使用Kubernetes系列（二）——安装工具介绍
• 从0到1使用Kubernetes系列——Kubernetes入门

关于猪齿鱼​

Choerodon 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon