有关Kubernetes是什么，网上很常见的一种介绍是：Kubernetes是Google开源的容器集群管理系统，其提供应用部署、维护、扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。
由此可见，K8s是构建在容器（Docker）技术之上的。
为什么需要容器集群管理？
单机的Docker引擎和单一的容器镜像只能解决单一服务的打包和测试问题。而要运行生产级的企业级应用，就需要容器调度管理系统。在这里面，Docker技术就仿佛运送系统零件的集装箱，把云原生应用的各个标准化零件交付到各个企业的不同码头，而容器调度管理系统就是企业应用的运行车间，把不同的零件组装、运行、维护起来。Kubernetes即是为生产环境而设计的容器调度管理系统。

Kubernetes系统架构

一个K8s集群是由分布式存储（etcd）、服务节点（Minion）和控制节点（Master）构成的。现在Minion改名为Node。
下图为集群架构图，典型的master/slave模型。

• Master节点：运行集群的管理控制模块；
• Node节点：真正运行应用容器的主机节点，每个Node上都会运行一个Kubelet代理，控制该节点上的容器、镜像和存储卷等；
• etcd：保存集群状态。

Kubernetes核心概念

Kubernetes以RESTful形式开放接口，用户可操作的REST对象/资源有三个：Pod，service和replication controller。API Server组件提供了一套对它们按照RESTful格式的增、删、改、查和监控接口。

1. Pod

在Kubernetes中能够被创建、调度和管理的最小部署单元，是一组（一个或多个）容器。一个Pod中的所有容器会被调度到同一个node上。

Pod 中的容器共享：

• 网络 NET namespace。由于容器之间共享 NET namespace，所以它们使用同一个 IP 地址，可以通过 localhost 互相通信。不同 pod 之间可以通过IP地址访问。
• PID（同一个pod内的应用容器能够看到对方容器进程），IPC（同一个pod内的应用容器能使用System V IPC或POSIX消息队列进行通信），UTS（同一个pod内的应用容器共享主机名） 等 Linux namespace。
• 存储卷（volume），方便pod内的容器之间共享数据以及在容器重启过程中避免数据丢失。实现持久化存储，volume作为pod的一部分挂载到容器上。

Pod的技术概念是K8s区别于其它容器编排调度工具的显著特性，带来的优势为资源通信和共享，数据共享和管理。具体来说，同一个Pod里的容器有如下两个特性：

• 通过K8s volume机制，在容器之间共享存储；
• 可以通过 localhost直接访问另一个容器。

一旦某个pod被分配到指定的工作节点（minion）上，该pod会在这个工作节点上一直运行直到生命周期结束，中途不会被调度到其它工作节点再次运行。

当一个工作节点下线时，其上的pod也随之删除。

当系统中运行的Pod数量很多时，如何有效地分类和组织Pod？
解决方案：label。
每个pod都有一个属性“labels”，即一组键值对，形如：

“labels”：{
     “key1”：“value1”，
     “key2”：“value2”
}

列举所有匹配标签{‘name’：“nginx”}的pod：$ kubectl get pods -l name=nginx

labels属性一般不直接作为系统内部唯一标识kubernetes对象的依据，因为不同于对象名和UUID，labels并不保证唯一性。

Pod贴标签，是为方便管理和维护，比如按以下情况打标签：release（版本），environment（应用运行环境），tier（复杂分布式应用的若干层级），partition（不同用户），track（更新周期）等。

label selector：Kubernetes核心的分组机制，客户端/用户能够识别一组有共同特征或属性的Kubernetes对象。

注意：尽量不要在单个pod中运行同一个应用的多个实例，因为pod设计的目的就是用于不同应用程序之间的协同。

2. replication controller

设计目标：保证本身状态为running且容器一切正常的pod数量永远跟预设的数目一致。
决定一个pod有多少同时运行的副本，并保证这些副本的期望状态与当前状态一致。
一般推荐，创建一个pod的同时创建一个replication controller，让这个controller一直守护pod，直到pod被删除。
pod的状态值（podStatus）：pending，running，succeeded，failed。

3. service

作用：
pod在Kubernetes中的IP地址不固定，service作为代理来确保需要使用pod的应用不需要知晓pod的真实IP地址；
当replication controller创建了多个pod副本时，需要service作为代理来为这些pod做负载均衡。
在service被创建的时候，便被分配一个独一无二的IP地址，该IP地址与service的生命周期相同且不再更改。

综合上述，可以看到，K8s中每个API对象都有三大类属性：
- 元数据metadata：标识API对象。每个对象至少有三个元数据：namespace，name和uuid；除此之外，还有labels用来标识和匹配不同对象。
- 规范spec：描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State）。
K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的，其好处是稳定。
- 状态status：描述了系统实际当前达到的状态（Status）。

Kubernetes核心组件

Master节点：

• API Server：负责对外提供K8s API服务，支持对K8s资源的增、删、改、查和监测。
  只有API Server与存储通信，其他模块通过API Server访问集群状态。
• Scheduler：根据特定的调度算法将pod调度到指定的minion上（绑定）。
• Controller manager：基于pod API上的一个独立服务，重点实现service endpoint（服务端点）的动态更新，管理K8s集群中的各种控制器

Minion节点：

• Kubelet：负责管理和维护这台主机上运行的所有容器。
• kube-proxy：负责为pod提供代理。

---

参考文献：

• 《K8s与云原生应用》之K8s的系统架构与设计理念
• Kubernetes初探