Kubernetes 是一个自动化的容器编排平台，它负责应用的部署、应用的弹性以及应用的管理，这些都是基于容器的。
容器部署时代
容器类似于VM，但是具有被放宽的隔离属性，可以在应用程序之间共享操作系统，因此容器被认为是轻量级的隔离。容器与VM类似，具有自己的文件系统、CPU、内存、进程空间等，由于它们与基础架构分离，因此可以跨云和OS发行版本进行移植。
随着微服务、容器化等技术的发展，解决了资源利用率不高的问题，但是随之而来却是如何进行容器管理，过多的容器使得运维工作也成为了一种负担，因此容器编排对于大型依托于容器化部署的分布式系统至关重要。在容器编排方面，Kubernetes所扮演的角色如下图所示：
kubernetes相关概念
使用Kubernetes，需要对pods、services等概念了然于心。
基本对象
Pod
Pod是最小部署单元，一个Pod由一个或多个容器组成，Pod中容器共享存储和网络，在同一台Docker主机上运行。每个Pod都会包含一个 “根容器”，还会包含一个或者多个紧密相连的业务容器。
Service
Service一个应用服务抽象，定义了Pod逻辑集合和访问这个Pod集合的策略。
Service代理Pod集合对外表现是为一个访问入口，分配一个集群IP地址，来自这个IP的请求将负载均衡转发后端Pod中的容器。
在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。
“Service微服务”，kubernetes中的核心。通过分析、识别并建模系统中的所有服务为微服务，最终系统有多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IP进行通信。每个Pod都会被分配一个单独的IP地址，而且每个Pod都提供了一个独立的Endpoint以被客户端访问。
客户端想要访问到Pod中的服务需要 部署负载均衡器，为Pod开启对外服务端口，将Pod的Endpoint列表加入转发列表中，客户端通过负载均衡器的对外IP+Port来访问此服务。每个Service都有一个全局唯一的虚拟ClusterIP，这样每个服务就变成了具备唯一IP地址的“通信节点”，服务调用就变成了最基础的TCP网络通信问题。
Volume
数据卷，是Pod中能够被多个容器访问的共享目录。定义在Pod之上，被一个Pod里的多个容器挂载到具体的文件目录之下；与Pod生命周期相同。
Namespace
命名空间将对象逻辑上分配到不同Namespace，可以是不同的项目、用户等区分管理，并设定控制策略，从而实现多租户。命名空间也称为虚拟集群。
设计架构
kubernetes中包含了很多新的概念，但是这些新的概念都不是凭空产生的，对应应用部署发展过程，几乎每个组 件或者流程都有传统方式中的步骤或工具与之对应，kubernetes通过整合资源，提供了一套便于应用部署的方案及实现，极大减少了系统运维的工作量。参考官方架构设计图：
kubernetes通常是集群化部署，一个Kubernetes集群由一组被称作节点(Node)的机器组成，一个节点可以理解为一台服务器，这些节点上运行Kubernetes所管理的容器化应用。集群具有至少一个控制节点(MasterNode)和若干工作节点(WorkNode)，节点可以是物理机或者虚拟机。
控制节点包含了控制平面(Contro Plane)，控制平面中的组件用来管理整个集群，工作节点用来托管对应的工作负载Pod。一般来说节点上都会包含kubelet、kube-proxy等组件以及容器运行时。
Kubernetes中包含了众多组件，通过watch的机制进行每个组件的协作，每个组件之间的设计实现了解耦其工作流程如下图所示：
以创建Pod为例：
- 集群管理员或者开发人员通过kubectl或者客户端等构建REST请求，经由apiserver进行鉴权认证(使用kubeconfig文件)，验证准入信息后将请求数据(metadata)写入etcd中；
- ControllerManager(控制器组件)通过watch机制发现创建Pod的信息，并将整合信息通过apiservre写入etcd中，此时Pod处于可调度状态
- Scheduler(调度器组件)基于watch机制获取可调度Pod列表信息，通过调度算法(过滤或打分)为待调度Pod选择最适合的节点，并将创建Pod信息写入etcd中，创建请求发送给节点上的kubelet；
- kubelet收到Pod创建请求后，调用CNI接口为Pod创建网络环境，调用CRI接口创建Pod内部容器，调用CSI接口对Pod进行存储卷的挂载；
- 等待Pod内部运行环境创建完成，基于探针或者健康检查监测业务运行容器启动状态，启动完成后Pod处于Running状态，Pod进入运行阶段。
说明：在整个集群交互过程中，组件之间无法直接通信，通过apiserver进行请求调用。
CRD的意义
Kubernetes 1.7之后，提供了CRD（CustomResourceDefinitions）自定义资源的二次开发能力来扩展kubernetes API，通过此扩展可以向kubernetes API中增加新的资源类型，会比修改kubernetes apiserver的源代码或创建自定义的apiserver来的更加的简洁和容易
