【Kuberneter】读阿里云原生实践项目考察

从下面讲到的所有项目中：项目简易难度、可行度排序，考虑动态变更容器资源限制、多集群一体化。

联邦集群

数据同步自动化

主站体系的接入同样代表着数据的互相流通 需要有一个工具保障简单快速的流程
主体：是接入主站各种服务
副产物是：数据快速流通的流程、监控问题、快速解决问题（集群打通），即监又控
体系：确立服务迁移标准
目的：打造全球一体化服务

断路器 数据同步失败 用户无法登陆 流量转移到其他集群

推动了 PaaS 层的面向终态自动化改造
通过 智能调度与 PaaS 平台，让自动迁移应用，修复不稳定因素成为了可能
应用yaml托管
云原生应用管理工具
云原生rocketmq
节点发布回滚策略
15 点 17 开始发布，17 点 30 才收到报警，18 点 15 还未能止血，直到 19 点
才通过切流 + 回滚的方式恢复。
全场景的验证

缺乏快速止血的手段，17:30 收到报警，到 18:19 都未能止血，直到 19 点 才恢复，这样的恢复速度，实在是难以接受。
恢复的方法是什么?回滚，切流，重启，隔离，新发布?

稳定性是什么?不是完全不发生问题，而是能够将问题影响降到最小。所以， 这就要求我们，所有的线上异常，都要能自动化发现，自动化处理，才能对 客户影响减少到最小。在产品研发阶段我们不仅需要适配性能，功能，我们 也需要做到可监控，充分考虑发布的场景，在研发阶段就需要考虑清楚每一 个异常应该怎样隔离。对于做不到的产品，SRE 有权拒绝上线。

如果故障处理经验丰富的人一定知道，除了回滚， 其实还有隔离，降级等多种方案。
kata 给容器提

pouch cri
Deployment 和 StatefulSet 解决了“服务节点版本一致 性”的问题
并且通过 https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/ update 实现了滚动升级，提供了基本的回滚策略

1.	AWS Fargate 

https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf

在交流过程中，我们发现 Serverless 很好地解决了客户的一些诉求:包括通 过 0-1-0 的伸缩能力来提高资源时用率，降低成本;支持代码包出发，从而让客 户无感化实现云原生，历史应用无需经过容器化改造;支持灵活的触发器配置，引 导用户对应用进行事件驱动的改造，从而适应业务的高速发展等。这些优势，使得 Serverless 在小程序开发的场景下大放异彩。
采用 Serverless 架构后，应用往往进行更细粒度的拆分，并通过事件串联。因 此用户希望平台能集成大多数通用的事件源，并支持自定义事件，使得触发机制更加 灵活。
提供了 Serverless 引擎管理、应用与服务管理、版本管理 与流控、根据业务请求或事件触发较快的 0-M-N-0 自动伸缩、计量、日志及监控 等配套能力。
SAS 提供了丰富的引擎全生命周期管理、诊断、监测等能力
性能简析:横轴为完全在同一时刻触发冷启的 Java 应用个数，纵轴为冷启应 用的平均与最小耗时。随着压力增大，50 个 Java 应用同一时刻调度加冷启平 均耗时 2.5 秒左右，100 个 Java 应用同一时刻调度冷启平均耗时 3-4 秒，最 短耗时 1.5 到 2 秒。


控制理论中常见的负反馈闭环控制系统
节点故障自愈组件用于管理业务集群 的工作节点，提供节点新增、删除、升级和故障处理能力
实现如等待日志采集 DaemonSet 部署完成才可以开启调度的需求
系统会从事件中心、监控系统中获取集群业务指标(如:Pod 创建成功率)，如 果出现异常指标，则自动熔断变更。
核心组件大量使用 Operator 面向终态设计模式
APIServer 等核心组件的日志
Service Mesh/Ingress 等接入层的日志
还提供了上层的日志分析能力，默认提供了 基于 APIServer 的审计分析能力、接入层的可观测性展现、应用层的日志分析。
HPA 是 Pod 水平伸缩的组件，除了社区支持的 Resource Metrics 和 Custom Metrics，阿里云容器服务 Kubernetes 还提供了 external-metrics-adapter，支持云服务的指标作为弹性伸缩的判断条件。目前已经支持例如:Ingress 的 QPS、RT， RMS 中应用的 GC 次数、慢 SQL 次数等等多个产品不同维度的监控指标。
Cluster-Autoscaler

通过 PTS 模拟上层产生的流量

基于 Kubemark 搭建了大规模集群模拟的平台
提前通过科学的手段预判应用需要的副本数和资源量

这个是用户最能感知到的不符合预期的了，一旦 IP 冲突就回导致服务时断时 续，如果是关键服务，还可能会造成各种故障，这是挺严重的一个异常，现有 K8S 是没有针对这种情况的检查的。

我们知道，绝大部分情况，在 Pod 创建完之后，还会有元数据同步到其他服 务上，在 Pod 交付之后，还会有外围的服务进行操作(部署、导流等等)，这 些外部服务会依赖某些元数据，一旦这些元数据未及时同步完整，会导致后续 操作的失败。
除了让人心力交瘁的混乱，系统还面临着应用容器的各种崩溃问题:内存不足导 致的 OOM，CPU quota 分配太少导致的，进程被 throttle，还有带宽不足，响应时 延大幅上升 … 甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌 等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。

资源不足就势必造成整个应用服务稳定性下降的问题。例如上图的场景:虽然是 同一种应用的副本，或许是由于负载均衡不够强大，或者是由于应用自身的原因，甚 至是由于机器本身是异构的，相同数值的资源，可能对于同一种应用的不同副本并具 有相等的价值和意义。在数值上他们看似分配了相同的资源，然而在实际负载工作 时，极有可能出现的现象是肥瘦不均的。
而在资源 overcommit 的场景下，应用在整个节点资源不足，或是在所在的 CPU share pool 资源不足时，也会出现严重的资源竞争关系。资源竞争是对应用稳 定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。

在预防维度，我们可以进行全链路的压 力测试，并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预 算资源，那就只采用冗余分配资源的方式了。在兜底维度，我们可以在大规模访问流 量抵达后，对不紧要的业务做服务降级并同时对主要应用进行临时扩容。但是对于陡 然增加几分钟的突增流量，这么多组合拳的花费不菲，似乎有些不划算。或许我们可 以提出一些解决方案，达到我们的预期。



其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求;command center 根据实时的容器画像和物 理机本身的负载以及资源使用情况，作出 Pod 资源调整的决策。Executor 再根据 command center 的决策，对容器的资源限制进行调整。同时，executor 也把每次 调整的 revision info 持久化，以便发生故障时可以回滚。
同时在测试中探索在时 分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性;在 未来我们将支持对容器的网络和磁盘 IO 的动态调整。
熔断异常服务
各种资源调整策略通过 Daemonset 部署，可以自动地、智能地在节点上运行，减少人工干预，降低了运维的人力成本。

我们在开源社区基础之上，优化集成了阿里云的其他服务。大家知道 Istio 社 区版本中自带的一些开源组件在生产环境中直接使用并不可靠，譬如分布式 跟踪组件 Jaeger 社区版本中并没有整合数据存储部分，Prometheus 的数 据存储等，而 ACK Istio 中通过优化整合阿里云服务，提供了更加稳定易用 的服务能力。

通过 Istio 将多集群下的应用服务实现互联互通和统一管理。

基于 0 虚拟化开销的神龙裸金属，通过使用行业标 准的容器与调度、编排、管理技术，推动经济体云原生技术全面升级。容器性能提升 10%、神龙节点可 调度率达到 99% 以上、容器稳定性与在线率全面提升

在 Kubernetes 中通过容器的命令以及生命周期钩子，可以将 PaaS 启动应用以及检查应用启动状态 的流程内置在了 pod 中;另外，通过创建 service 对象，可以将容器和对应的服务发现机制关联起 来，从而实现容器、应用、服务生命周期的统一。容器平台不再仅仅生产资源，而是交付可以直接为业 务使用的服务。这极大地简化了上云之后故障自愈以及自动弹性扩缩容能力的建设， 真正地发挥了云的 弹性能力。

事实上呢，绝大 多数核心的业务应用都维护着一定的冗余容量

在 Kubernetes 中可以通过 PodDisruptionBudget 来定量地描述对应用的可迁移量，例如可以设置对应用进行驱逐的并发数量 或者比例。这个值可以参考发布时的每批数量占比来设置。假如应用发布一般分 10 批，那么可以设置 PodDisruptionBudget 中的 maxUnavailable 为 10%(对于比例，如果应用只有 10 个以内的实 例，Kubernetes 还是认为可以驱逐 1 个实例)。万一应用真的一个实例都不允许驱逐呢，那么对不 起，这样的应用是需要改造之后才能享受上云的收益的。一般应用可以通过改造自身架构，或者通过 operator 来自动化应用的运维操作，从而允许实例的迁移。

通过 operator 来自动化应用的运维操作，从而允许实例的迁移。

开始把系统容器中除业务应用外的其他组件都拆分到独立的 sidecar 容器，我们称之为轻量化容器改造。改造后，一个 pod 内会包括一个运行业务的主容器的， 一个运行着各种基础设施 agent 的运维容器，以及服务网格等的 sidecar。轻量化容器之后， 业务的 主容器就能以比较低的开销运行业务服务，从而为更方便进行 serverless 的相关改造。

集群安全合规:分布在不同的地域和环境的 Kubernetes 集群，需要遵循不同的合规性要求。比如欧 洲的 Kubernetes 集群需要遵循欧盟的 GDPR 法案，在中国的金融业和政务云需要有额外的等级保护 等要求;

我们通过持续总结迭代过程中的经验，形成了内部的最佳实践原则，以帮助业务更好的设计 Operator

1. CRD 在定义时需要明确未来的最大数量，大量 CR 业务最好采用 aggregate-apiserver 进行扩展; CRD 必须
2. Namespaced scope，以控制影响范围;
3. MutatingWebhook + 资源 Update操作会给运行时环境带来不可控破坏，尽量避免使用这种组合;
4. 任何 controllers 都应该使用informers，并且对写操作配置合理限流; DaemonSet 非常高阶，尽量不要采用这类设计，如果必需请在 Kubernetes专家的辅导下使用

优化容器镜像大小，降低镜像传输成本
制作基础镜像，将使用频繁的应用或环境制作成基础镜像复用，尽可能减少镜像的层数，控制每次 变更层数 采用多阶段镜像构建，将镜像制作过程中的中间产物与最终产物分离，形成最精简的应用镜像

优化服务端处理性能，提高请求响应速率
服务端通过识别热点镜像，采用热点数据缓存等多种方式应对大规模镜像 Manifest 并发拉取

最后，Service Mesh 给探索面向未来的异地多活、应用永远在线的整体技术解决方案打开了一扇大 门。