这篇教程不会关注 kubernetes 的部署、架构、实现方式等内部原理，而是完全从一个使用 kubernetes 的开发人员的视角去介绍kubernetes是什么，从而帮助了解如何更好的去利用 kubernetes 的特性。

基本介绍

对于kubernetes是什么，一个比较官方的定义，Kubernetes是一个开源容器编排平台，管理大规模分布式容器化软件应用，简称为k8s.

通俗一些来讲，k8s 的核心理念是以应用为中心，向下屏蔽基础设施的差异，向上通过容器镜像实现应用的标准化，帮助开发人员在仅需关注应用本身，无需考虑部署、容灾、伸缩等运维细节的情况下，开发出大规模、可靠的分布式应用。

优势

如上所述，k8s的核心优势就是降低运维成本，让应用开发人员能够专注于应用本身。具体来讲，包括如下几点：

• 便捷的部署流程和大规模的复制分发能力：应用提供标准化的容器镜像，之后的部署发布流程都可以做到自动化；应用也无需再做更多的事情就可以实现跨平台、跨区域的部署。
• 服务自愈能力：自动摘除不健康的节点并做恢复。
• 敏捷的自动伸缩：根据设定的系统负载，做快速的自动伸缩，实现系统处理能力和成本之间的平衡。

主要概念及实现方式介绍

这篇kubernetes教程的剩余部分会从应用开发人员视角，介绍需要了解的k8s概念，主要包括以下几类：

• Pod, service, deployment等基本概念
• spec+controller这套基本实现原理
• k8s提供给应用的扩展点

spec+controller

这是k8s内部大部分逻辑的实现方式，了解这个逻辑，可以帮助开发人员更好的理解某些特定情况下k8s的行为。

如果翻看k8s的yaml配置，就会发现k8s的大部分组件中都有一个或若干个spec字段，它的含义很好理解，就是对于某个属性的期望值，比如一个服务节点数量的期望值。

controller的作用就是持续监测期望值和实际指标是否一致，不一致时就进行相应的操作进行处理，比如发现节点数不够了，就会启动对应数量的新节点。

这样，无论是上线、扩缩容、还是故障恢复，我们会发现这些逻辑都变得非常清晰，都是触发一下对容器数期望值或实际值的调整，然后让controller去增删节点就可以了。

这套机制是k8s里广泛使用的一个底层设计原则，作用是解开监控和操作逻辑之间的耦合。举个例子，我们在很多情况下都需要触发启动新的节点，包括要做扩容时、部分节点挂了时、要上线时，等等。这些完全没关联的场景如何去触发相同的操作，代码要如何保持整洁呢？k8s的做法就是用一个期望值的概念做中间层，将操作的触发时机和操作本身拆分成独立的逻辑。

了解了这个逻辑，我们可以更容易的理解k8s是怎么工作的。 比如基于HPA做自动扩容，就是根据当前的CPU使用情况，和期望的CPU使用量，决定是增加还是减少节点。

Deployment

Deployment 用于指示 k8s 如何创建和更新应用程序，我们通常理解的一个“服务”、“应用”大体上就对应在deployment这一层上。 像镜像、内存cpu使用限制、节点数、环境变量等各种配置，都是在deployment上。

Pod

pod比较好理解，就是我们通常理解的一个节点。pod是 k8s 中最小可管理单元。

Service

Service是一个需要着重了解的概念，它是一个抽象层，它选择具备某些特征的 Pod（容器组）并为它们定义一个访问方式。 通常的应用场景下，deployment和service是一一对应的，但实际上deployment和service之间并没有必然的联系。

一个请求恰好可以打到某个deployment关联的所有pod上，看起来是一件非常正常的事情。而事实上，这件事情的发生不是由于这些pod通过一个deployment产生，而是因为deployment上配置了一个标签，通过这个deployment生成的pod都获得了这个标签; 同时，另外存在一个service, 设置通过这个标签选择pod, 请求进入的是通过service选择出的一批pod.

探针(probe)和钩子(hook)

k8s提供了一些用于应用扩展的接口，其中就包括probe和hook, 可以帮助应用更好的利用k8s的能力。

k8s提供了 liveness和 readiness 探针，顾名思义，liveness probe的作用是判断应用是否存活，readiness probe的作用是判断应用是否已经启动完毕。

应用可以用http接口等不同形式提供探针，k8s则负责在探测到不同状态时做不同的操作。比如说探测到liveness probe返回状态异常，则可以认为此节点已经丢失，对此节点做删除处理。

hook则支持应用在一些特定阶段插入一些行为，比如preStop hook, 运行应用关闭之前先做一些操作，可以用来做graceful shutdown.

实践思考

通过对本篇kubernetes教程上文列出的概念的了解，相信大家可以从应用开发人员的视角完全理解kubernetes是什么, 也可以大致想象出应用方使用k8s的基本思路： 构建标准镜像，暴露出必要的监控数据，剩下的事情都交给k8s来做。

在准确的数据下，k8s可以帮我们做好系统的自愈、扩缩容等操作，而我们要做的是，结合应用场景，尽量给出更加准确的监控数据。

举一些例子，比如说应用提供的liveness探针，如何能尽量确保准确的展示系统的健康状态，某个接口可以访问，某个端口可以调通，能否等价的说明这个应用是否健康。

比如说k8s以cpu、内存等指标来判断系统负载时，这些机器指标能否真实的展现出应用的真实负载，是否有可能连接池、IO等其他瓶颈会在cpu、内存等瓶颈到来之前就达到。

这些都是需要应用方结合应用的实际情况精心设计的。

此外，k8s的设计理念决定了在k8s环境下，“重启”会是一件非常稀松平常的事，像硬件故障、小概率的死循环、不健康的gc, 等不同类型的问题，都可以在k8s的自主重启下实现自愈； 自动的扩缩容扩充中，也会经常性的有节点启停。 所以说，应用需要让自己的启动流程顺畅一些，避免大量耗时或大量资源消耗。