作者 | 张晓宇 阿里云云原生应用平台技术专家，
曾凡松 阿里云云原生应用平台高级技术专家，
张皓余 阿里云云原生应用平台技术专家
责编 | 屠敏
在“促增长、调结构、建生态”的策略指引下，在更好地实现云原生应用平台三年“服务 20 万客户、贡献 40 亿GAAP、覆盖 100 万开发者”目标的同时，支撑集团业务仍然是必须坚守的大本营。
在过去的2019年天猫双11大促活动中，阿里云上下一心用最稳定的系统状态、最流畅的产品体验、最饱满的服务热情，创造了"每秒订单峰值达到54.4万笔"的记录" ，征服了全球最大流量洪峰，实现了阿里巴巴核心系统100%上云等一系列目标。这些里程碑既是奇迹，也是对于我们集腋成裘工作的验收。
作为容器&节点团队的一个前线工作人员，我们用自己的策略和方式让运行百万容器的巨兽们保持稳定，成为完成这一目标下的一名合格的船员(Kubernetes crew)。
概要
“兵来将挡水来土掩”的case by case处理问题方式只会让我们疲于奔命于各种问题的处理中。非系统化的工作不仅收效微小而且极易引入更多不确定因素。因为我们需要一个体系去应对绝大多数问题。一个好的体系应该是怎样的呢？请允许我一一解说。
《孙子兵法·军争篇》有云：疾如风，其徐如林，侵掠如火，不动如山。
容器&节点在稳定性的系统性建设工作在以下4个方面践行遵循这一原则。
疾如风
按语: 进攻则迅疾如风，撤退则去无影踪
LivenessProbe中心管控系统
对于大规模部署并且 7x24 小时运行的服务，因为自身的缺陷或者外部环境的变化，在运行过程中可能会遇到各种各样的异常（相信大家都有遇到过），这些异常在绝大多数情况下可以通过“重启”来修复（重启大法）。而对于成千甚至上万实例的应用而言，我们无法人工的去监视应用的运行状态，必须要一个自动化的机制。LivenessProbe正是Kubernetes提供给应用的一种自动修复机制：用户编写一个检查服务是否健康的“脚本”，并配置其执行的规则，Kubernetes按照规则定期执行该脚本，如果其返回服务处于不健康的状态且满足配置的阈值，通过重启容器的方式尝试恢复。在双11等大促阶段，任何重启容器的动作都是危险的。使用LivenessProbe管控的Kubernetes集群，在当容器LivenessProbe检查失败时，单机层面不会对容器自行做重启处理，而是由中心端统一按照配置的参数对容器重启做管控处理。
当前我们已经完成：
- kubelet会探测”liveness健康“脚本，若出现探测失败，这会上报conditions。
- 现有livenessprobe控制器watch到这个状态，根据Configmap配置的策略，容器重启工作可以受控执行。
后续将继续完成：
- 支持prometheus指标采集，待运行一段时间后，根据数据统计分析出现问题的大类。
- 支持精细化的流控重启策略，区分应用分组维度，和宿主机维度。目的是尽量避免同应用分组的副本在被同时大量重启。每次发生重启行为能尽可能分散在不同宿主机上等等更加精细化的策略。
- 和周边组件打通，例如NPD和调度器等。
其徐如林
按语: 像树林一样整齐，徐徐而行，无懈可击。
DaemonSet部署及灰度增强。
目前DaemonSet已经在很多场景下被采用或者即将被采用，主要包括：
- 运维agent 类：一般是整个集群的 node 上都会部署（无差异性）
- plugin 类：在指定机器上部署的，如CSI Plugin，device Plugin等
- 用户自行开发的业务应用。（差异性大，需要准入机制）
然而社区原生的DaemonSet在升级和部署方面很难满足我们的实际生产需求:
- DaemonSet不具备暂停和等待恢复能力。尤其是在大规模集群场景下，为了维护集群的高可用和版本确定性，用户在发布部分副本时，希望在灰度中，暂停当前版本的发布，等待和确认版本安全符合预期后再继续灰度发布。
- 批量部署能力缺失。对于一个成熟的系统，灰度发布能力是一项必备能力，然后社区版本在这里却没有做任何增强。目前基于原生版本的DaemonSet，用户只能采用最原始的一把嗦发布策略。
- 热升级能力缺失。DaemonSet热升级即DaemonSet的副本先创建，再删除旧的副本。对于某些提供基础服务的组件而言，服务不可中断非常重要和敏感。例如单机上DNS解析服务容器，这项单机服务一旦服务中断就可能导致LivenessProbe或者readnessProbe检查失败，或者某些敏感业务应用连接不上服务端出现各种异常报警，进而间接导致业务容器重启以及服务中断。
因此，我们需要提供一揽子解决方案使原生的DaemonSet在灰度能力上得到增强，以适应当前阿里巴巴经济体需求以及推广到社区增强影响力的需要。
节点团队已经在原生DaemonSet workload这个基础上完成的一些增强：
- 新增了升级暂停和恢复能力
- 对于RollingUpdate策略，新增分组控制能力，增加partition和selector。
- 新增SurgingRollingUpdate策略，提供热升级能力，即创建新版本pod，再删除旧pod。
接下来我们还将让DaemonSet提供更多能力，让部署和升级变更更加顺滑：
- 制定DaemonSet的评审和准入标准。
- 分批部署能力。
- 提供DaemonSet可部署节点和已部署节点的字段。 DaemonSet维度显示部署节点和Pod信息等细节。
- 提供当前批次 部署/升级 的进度。 Partition和Selector下，显示最近一个批次的Pod，Node状态。
- 预先拉取镜像问题 发布或者升级时选择parttion模式，预先让所有符合条件的node先拉取镜像。
- 升级策略增加 inplacement升级 该升级策略会校验本次升级的字段，在此策略下，仅允许修改image字段，如果修改了其他字段拒绝掉。 该升级策略实现Pod不重建，容器重建。
- SurgingRollingUpdate中增加MaxUnavailable字段 当DS的副本不可用数达到MaxUnavailabl时候，停止更新DaemonSet
- Daemonset在灰度时候遇到Node节点变化时。 节点增多，更新成旧版本的Pod。 节点减少，如果涉及Partition或者Selector选中的节点，自动订正Selector或者Partition的范围。
- DaemonSet中的Pod Template中新增允许策略Never，达到Broadcast job的功能。所有节点上的Pod状态为completed后，DaemonSet状态也是Completed。
侵掠如火
按语: 冲锋陷阵，如烈火燎原，锐不可当
defender系统
defender是站在整个k8s集群的视角，针对用户发起的或者系统自动发起的有风险的操作进行防护（流控、熔断、校验）和审计的风控系统。
之所以做defender，主要从以下几个方面考虑:
- 类似kubelet/controller这样的组件，在一个集群中存在多个进程，任一单一进程都无法看到全局的视图，无法进行准确的限流。
- 从运维视角，分散在各个组件中的限速规则难以配置与审计，当部分操作因为限流原因失败时，排查链路过长影响问题定位的效率。
- k8s面向终态的分布式设计，每个组件都有决策的能力，那么就需要一个集中的服务对那些危险决策进行风控。
defender的框架图如下所示：
- defender server是k8s集群级的服务，可以部署多个，其中一个active，其余standby
- 用户可以通过kubectl配置风控规则
- k8s中的组件，例如controller，kubelet，extension-controller等，都可以通过defender sdk接入defender（改动很小），在进行危险操作前请求defender进行风控，根据风控结果决定是否继续该危险操作。 defender作为一个集群级的风控防护中心，为k8s集群的整体稳定性进行保驾护航。
不动如山
按语: 即便敌人攻到他脚底下，也不会起身，自有身边卫士去厮杀
Node Problem Detection & Auto Healer节点故障检测与自愈
1. 为了实现全网集群的节点可调度率 > 99.5%，ASI需要更加突出自动化和智能化的节点故障探测，上报，处理，愈合能力。
2. 实现约定时间内自动恢复Node可调度可使用能力，满足1-5-10故障处理的需求。
目前现状：
目前集团内部检测节点监控状况有两个独立的流程：
1. pouchcollector，它的主要功能是定时执行20多个检测检测任务。然后这些检测结果上报给Promethues。
2. sigma-host-doctor，它是中心端在宿主机上运行巡检脚本，再将异常展示出来。通过人工或者Cron任务去做修复工作。
接下来，我们将整合大团队的整个能力，做出兼容并蓄的体系，它将具备：
- 利用开源软件NPD，并做适当优化扩展，让NPD具备热插拔Plugin的能力。
- 容器平台的同事根据故障类型维护不同NPD Custom plugin。
- NPD将采集数据部分export给Promethues，部分export给APIServer。
- 上层Controller根据汇总的数据结果，匹配合适的自愈策略，通过和宿主机的通道，下发故障自愈的命令。
- ...
总结
Case by case，人工干预的各种稳定性工作曾经发挥过很多救火员的作用。我们由衷对于过去的自己表示感谢。但是随着稳定性体系化建设的推进，我们将会研发并引入更多的技术解决方案。这一过程虽然历经坎坷，也会弯路重重，但是方向对了，就不怕路远。在现在，在不远的未来，我们会发现：
- 处理线上紧急突发问题时拥有更多智能化，自动化的工具。
- 线上各种人工手动干预操作大量减少。所有操作均有章可循，手忙脚乱和心有余悸的线上变更会尘封历史。
- 借助于自动修复策略的不断收集和优化，疲于奔命地处理各类散落在各个集群的问题的情况会越来越少。程序员也可以相对愉快地享受工作。
- 通过技术让工程师将更多的精力投入在体系化建设和技术深度上。日常投入更少的时间和精力，但是更好地服务集团业务。用技术实现释放红利的正向循环。
这种组合拳的方案会解放更多生产力，给节点乃至系统稳定性建设和团队工作氛围建设带来立竿见影的效果。
容器平台的稳定性，未来已来。
更多「问底中国IT技术演进」专题精彩文章：
