Kubernetes是Google于2014年开源的一个容器编排工具，使用Google自己的go语言编写，由Borg衍生而来。Borg是Google内部已经运行近十年的容器编排工具，由于docker的横空出世，导致Google原本准备作为秘密武器的容器技术胎死腹中。计划被打乱，容器层面已经痛失良机，慢人一步，只有在编排工具层面下手了，Google当机立断，基于Brog的逻辑编写了Kubernetes，开源并捐给了CNCF（云远程计算基金会），由于Google近十年的使用经验，所以Kubernetes一出世就横扫了其它编排工具，时至今日，地位依然稳固。

Kubernetes源于希腊语，有“舵”或“飞行员”的意思。k8s，是由Kubernetes中间的八个字母缩写为数字8得来的。Google采用这个名字的深意就是：既然你docker把自己定位成驮着集装箱在大海上遨游的鲸鱼，那么我就以Kubernetes掌舵大航海时代的话语权，鲸鱼必须按照我设定的路线巡游。

Kubernetes是Google实验室开发的一种容器管理技术，用于在不同类型的环境（例如物理机，虚拟机和云基础架构）中管理容器化的应用程序。可帮助创建和管理应用程序的容器化。

Kubernetes具有跨集群自动部署、扩展应用程序和操作应用程序容器的能力。它能够创建以容器为中心的基础设施。

Kubernetes的特征：

以下是Kubernetes的一些重要特征。

• 持续开发、集成和部署
• 容器化基础设施
• 以应用程序为中心的管理
• 可自动扩展的基础架构
• 跨开发测试和生产的环境一致性
• 松散耦合的基础设施，其中每个组件可以作为单独的单元
• 资源利用密度高
• 可预测的基础设施

Kubernetes的架构：

如下图所示，Kubernetes遵循客户机-服务器体系结构。其中，master安装在一台机器上，节点安装在不同的Linux机器上。

Master和Node的关键组件介绍。

Master主机组件介绍：

etcd

分布式键值存储系统，用于保存集群状态数据；

API Server

提供Restful API接口的功能调用 ；

Controller Manager

负责收集节点的状态和执行任务，关键的控制有replication controller, endpoint controller, namespace controller；

Scheduler

负责集群负载的调度，根据调度算法为新创建的pod选择一个Node节点。

Node节点中组件的介绍：

Docker

Docker 是一个必须的环境，运行封装好的应用；

Kubelet服务
kubelet 是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器，Pod挂载数据卷，下载secret，获取容器和节点状态等工作，kubelet 将每个Pod转换成一组容器；

Kubernetes Proxy服务

请求分发、负载均衡，在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。实现让Pod节点（一个或者多个容器）对外提供服务。

Kubernetes核心概念介绍：

对象模型

Pod

? 最小部署单元

? 一组容器的集合

? 一个Pod中的容器共享网络命名空间

? Pod是短暂的

Controllers

? ReplicaSet ：确保预期的Pod副本数量

? Deployment ：无状态应用部署

? StatefulSet ：有状态应用部署

? DaemonSet ：确保所有Node运行同一个Pod

? Job ：一次性任务

? Cronjob ：定时任务

更高级层次对象，部署和管理Pod

Service

? 防止Pod失联

? 定义一组Pod的访问策略

Label ：标签，附加到某个资源上，用于关联对象、查询和筛选；

Namespaces ：命名空间，将对象逻辑上隔离；

Volume：数据卷，共享Pod中使用的数据；

Ingress：给Service提供外部访问功能；

Annotations ：注释。

除了上面Master和Node的几个核心组件，还有下面一些扩展插件，其中有些插件是非必须的。

• Coredns：维护Service与cluster ip之间的对应关系
• CNI：容器网络接口。k8s的网络模型需要借助插件才能实现，比如flannel，calico等，flannel插件就是用来维护Pod网络的。
• Web UI（Dashboard）：图形界面，并非必须。
• Fluentd：为集群提供日志采集、存储和查询。
• Traefik：Ingress Controller的软件实现，为pod中服务提供外网访问。
• Dashboard：管理k8s的图形化界面。

相关概念：

无状态服务 VS 有状态服务

先上图,了解一下利用Cookie、Session技术实现HTTP会话（有状态）。

对服务器程序来说，究竟是有状态服务，还是无状态服务，其判断依旧——两个来自相同发起者的请求在服务器端是否具备上下文关系（HTTP 通过Cookie 、Session建立上下文关系）。

状态化请求，服务器端一般都要保存请求的相关信息（服务器存储Session信息），每个请求可以默认地使用以前的请求信息（可以使用SessionId 区分请求）。

无状态请求，服务器端所能够处理的过程必须全部来自于请求所携带的信息，以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息（HTTP无状态请求静态页，根据URL返回HTML页面内容）。

下图分层了解更多：

有状态的应用列举：

总结 有状态服务可以比较容易地实现事务，在不需要考虑水平扩展时，是比较好的选择 无状态服务的优势在于可以很方便地水平伸缩，但是在实现事务时，需要做一些额外的动作。

Kubernetes微服务对照表：

Kubernetes最佳实践：