1. HPA VS KEDA HPA 也实现了: 自定义指标的弹性 Scale to Zero 这些与 KEDA 相比较，并不算劣势了。 真正的差别在于 HPA 只能利用监控数据进行伸缩，而 KEDA 可以利用更多数据来源进行伸缩，比如队列消息、数据库、Redis 等，当然也包括监控数据。 从 Kubernetes-based Event Driven Autoscaler (KEDA) 项目的名字就可以看出，K

1. 基于容器的 Serverless 无法支撑下一代应用的形态 如上图，我们正经历着一次运行时态的变革。 从裸金属机到虚拟机，应用不在受限于本地服务器的数量、机房稳定性，具有更好的弹性和可用性。 从虚拟机到容器，应用不再受限于操作系统、配置漂移，具有更好的可移植性和可扩

1. 受限的构建环境无法满足构建需求 Tekton 是基于 Kubernetes 集群的 CICD 引擎，相较于 Jenkins 更加云原生。说人话就是，更好开发插件、更好扩容、更好可观测性、更好玩儿。 由于代码仅能落盘公司内网，导致构建集群仅能部署于办公内网。这导致了很多受限： 硬件资源，没有弹性扩容能力 网

1. 关闭 affinity-assistant 之后 在前面的博文中，我通过关闭 affinity-assistant、使用 NFS 存储，平均每条流水线执行时间节约了近 30 秒。[1] affinity-assistant 的影响 在关闭之前，创建 Pod 的时序图如下: 由于 affinity-assistant 开启，每条流水线绑定在一个节点执行。 在关闭之后，创建 Pod 的时序图如

Istio 注入 Sidecar 的模板在 istio-sidecar-injector ConfigMap 中。通过 annotations 可以对 Sidecar 的各种参数进行自定义配置，比如 CPU 使用、proxyImage 等。下面主要整理的是 Sidecar 的注入方式。 1. 给命名空间添加标签 -> 整个命名空间生效 注入标签 1 kubectl label namespace default istio-injection=enabled --overwrite 重启应用之后，会自动注入 Sidecar 容器。此时，访问流量将通