为了确保使用容器服务的业务稳定，阿里在具体实践中遵循了哪几个原则？

1）信任最小化 俗话说，"常在河边走，哪有不湿鞋"。为了确保频繁进行集群运维工作的同学不因为疏忽而犯错，就要保证业务可操作的权限最小化，对于授权的写和删除操作，还要增加额外的保护。近一步来讲，为了防止容器服务用户的误操作，我们对 Namespace、CRD 和 Workload 的资源都增加了级联删除的保护，避免用户因为误删除还在运行 Pod 的 Namespace、CRD 和 Workload 而引发灾难性的后果。另外，对于业务运行依赖的如日志上传、微服务调用、安全审计等基础设功能，需要进行资源的隔离。因此，阿里在对应用进行大量的轻量化容器改造过程中，采取了把基础设 施功能从应用的富容器中剥离到 Sidecar 或者 Daemonset 中的方式，并对 Sidecar 或者 Daemon 的容器进行资源的隔离， 保证即使基础设施功能发生内存泄露等异常也不会直接影响业务的正常运行。 2）默认稳定性 指保证所有应用都具备基本的稳定性保障配置，包括默认的调度打散策略、Pod 中断 预算、应用负载发布最大不可用数量，让稳定性成为像水、电、煤一样的基础设施。这样能够避免应用因为宿主机故障、运维操作、应用发布操作导致服务的完全不可用。保障可以通过 webhook 或者通过全局的应用交付模板来实现，应用 PaaS 也可以根据业务的实际 要求来定制。 3）规范化应用 在进行云原生改造时，需要制定启停脚本、可用和探活探针规范，帮助业务把自愈能力内置到应用中去。这包括推动应用配置相应的存活探针，保证应用在异常退出后能够被自动拉起；保证应用启动和退出时执行优雅上下线的操作等。配合这些规范，还需要设置相关探针的准入、监测机制，防止业务研发同学在对 K8s 机制不完全了解的情况下编写错误的探针。我们常常见到很多研发同学直接复用已有的健康检查脚本来作为探活探针，但是这些脚 本往往存在调用开销大（例如执行了解压缩）、存在副作用（例如会修改业务流量开启状态）、以及执行不稳定（例如调用涉及下游服务）的问题，这些对业务的正常运行都会产生非常大的干扰，甚至引发故障。 4）集中化处理 对于探活失败的自动重启、问题节点的驱逐操作，阿里云容器服务把 Kubelet 自主执行的自愈操作，改为了中心控制器集中触发，从而可以利用应用级别的可用度数据实现限流、熔断等安全防护措施。这样，即使发生了业务错配探活脚本或者运维误操作执行批量驱逐等操作状况，业务同样能得到保护；而在大促峰值等特殊的业务场景下，可以针对具体需求设计相应的预案，关闭相应探活、重启、驱逐等操作，避免在业务峰值时因为探活等活动引起应用资源使用的波动，保证业务短期的极致确定性要求。 5）变更三板斧 首先，要保证容器服务自身的变更可观测、可灰度、可回滚。 对于 Controller 和 Webhook 这类的中心管控组件，一般可以通过集群来进行灰度，但如果涉及的改动风险过大，甚至还需要进行 Namespace 级别细粒度的灰度；由于阿里部分容器服务是在节点上或者 Pod 的 Sidecar 中运行的，而官方 K8s 中欠缺对于节点上 Pod 和 Sidecar 中容器的灰度发布支持，因此阿里使用了 OpenKruise 中的 Advance Daemonset 和 Sidecarset 来执行相关的发布。

答复内容摘自《云原生大规模应用落地指南》，这本电子书收录开发者藏经阁 下载连接：https://developer.aliyun.com/topic/download?id=1055