10.1 “以应用为中心”的设计思想
回顾过去十几年的技术架构演进，精彩纷呈！
从单体应用到分布式架构，能力大幅提升，但也引入了更多的不确定性。例如，节点故障、磁盘损坏、网络延迟、消息消费等问题变得不可预测。为了解决这些不确定性，业界提出了诸多的分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统稳定运行。
进入微服务时代，这些理论推动基础设施能力开始演进，这些能力（服务发现、负载均衡、故障转移、动态扩容）从业务逻辑中抽象出来，以 SDK（中间件）方式提供给应用开发者。中间件的出现其实体现了一种朴素的“关注点分离”的思想，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力！
不过，基础设施能力的演进，也伴随着云计算和开源社区的发展，带来了全新的升级。这个变化，正是从云原生技术改变中间件格局开始。更确切地说，原先通过中间件提供和封装的各种基础设施能力，现在全部被 kubernetes 从应用层拽到基础设施层。比如，Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实把构建分布式应用最迫切的需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中，也就是 kubernetes 中。
值得注意的是，kubernetes 不直接提供这些能力，它的角色定位是通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。从这一点讲，Kubernetes 从来就不是一个简单的容器平台或者资源管理项目，它是一个分量十足的“接入层”，是云原生时代真正意义上的“操作系统”！
所以说，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，而无需关注底层基础设施的配置和实现细节。
这种设计理念，以一言蔽之，就是以应用中心。正是因为以应用为中心，整个云原生技术体系无限强调基础设施更好地服务于应用，以更高效的方式为应用提供基础设施能力，而不是反其道行之。而相应的，Kubernetes 也好、Docker 也好、Istio 也好，这些在云原生生态中起到了关键作用的开源项目，就是让这种思想落地的技术手段。