一、Kubernetes 是什么？
1.Kubernetes 定义：
Kubernetes 是一个全新的基于容器技术的分布式建构领先方案，他是基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化~
2.Kubernetes 特点：
• 遵循Kubernetes的设计思想，我们只需要关注我们的业务模块，那些和业务不相干的底层代码和功能模块，都可以不用关注，比如我们可以不用费心去部署负载均衡器，不用考虑自己搭建一个复杂的服务之力框架，不用再去操心服务的监控和故障处理模块~Kubernetes提供的一整套解决方案，可以让开发者将精力集中于业务本身，Kubernetes本身也提供了强大的自动化机制，大大减少了运维成本。
• Kubernetes是一个开放的平台，不局限于任何一种语言，所以你可以把Java ,Go 又或者是C++映射成Kubernetes的Service，并通过标准的TCP协议进行交互。而且，对于现有的系统我们也可以很容易改造并升级到Kubernetes平台上。
• Kubernetes是一个完备的分布式系统支撑平台，Kubernetes 具有完备的集群管理能力，包括多层次的安全防护和准入机制，多租户应用支撑能力，透明的服务注册和服务发现机制，内建智能负载均衡器，强大的故障发现和自我修复能力，服务滚动升级和在线扩容能力等等。
3.为什么用Kubernetes ：
我们知道，Docker的出现，很好的解决了环境不一致的问题，但是对于日益普及的微服务架构，我们可能需要部署的服务器成百上千，我们无法做到手动启用和维护这些服务器，因此，容器编排就显得尤为重要，简单的说，容器编排的目的就是告诉服务器集群要使用哪些机器来运行当前的服务。
• 加强团队协作，采用Kubernetes解决方案之后，我们只需要一名架构师专注于系统中“服务组件”的提炼，几名开发工程师专注于业务开发，一名系统兼运维工程师负责Kubernetes的部署和运维。
• Kubernetes 全面拥抱微服务，微服务的核心就是将一个巨大的单体应用分解为很多小的互相关联的微服务，一个微服务背后可能有多个实例副本支撑，副本的数量可能随着系统的负荷变化而调整，我们有内嵌的负载均衡器来实现这样的功能。
• Kubernetes 可随时迁移到公有云上，以及基于OpenStack的私有云上。
• Kubernetes系统架构具备了超强的横向扩容能力，不用修改代码，一个Kubernetes集群即可从只包含几个Node的小集群平滑扩展到拥有上百个Node的大规模集群。
二、Kubernetes 基本概念和术语
Kubernetes有三种主要访问入口：API 、UI 、CLI。
Kubernetes中的大部分概念如Node、Pod、Replication Controller、Service等都可以看做一种“资源对象”，几乎所有的资源对象都可以通过kubetcl工具执行crud的操作并使用etcd做持久化存储。我们首先来了解下两个重要的管理角色：Master & Node
1.Master：
Kubernetes 里面的Master指的是集群控制节点，每个Kubernetes的集群里面需要有一个Master节点来负责整个集群的管理和控制，基本所有的Kubernetes所有控制指令都发给他，他来负责具体的执行过程。Master节点通常会占领一个独立的服务器，甚至我们需要3台左右来做高可用，毕竟他是整个集群的首脑，一旦宕机，整个集群就会处于瘫痪状态。
Master节点有如下几个关键模块：
• Kubernetes API Server （K8S自有模块）: 提供了Http Rest接口的关键服务进程，是Kubernetes集群里面所有资源的crud（接收客户端请求）的唯一操作入口，并验证客户请求是都符合规范，也是集群控制的入口进程。
• Kubernetes Controller Manager（K8S自有模块）： Kubernetes 所有资源对象自动化控制中心。申明式的（用户不关心是怎么创建出来的）资源创建，并确保创建出来的资源完全满足要求，并且处于健康的运行状态（Controller Loop管理）。一旦用户有请求过来，Controller模块会watch到需要的变更，
• Kubernetes Scheduler（K8S自有模块） ： 负责资源调度（Pod调度）的进程，当我们通过API 、UI 、CLI向Master申请创建一个容器，这个容器到底要运行在哪个Node上，那么Schedule就是主要用来评估哪个Node节点是最佳的，然后将我们要起的Pod在哪个Node上运行
• Kubernetes etcd： Kubernetes 持久化存储，etcd本不属于Master，是由CoreOS公司开发的一款持久化存储
2.Node:
除了Master节点，Kubernetes 集群中的其他节点被称为Node节点，他可以是物理机也可以是虚拟机，Node节点是整个集群中的工作负载，每个Node都会被Master分配一些工作负载（Docker Container），当某个Node宕机时，他的工作负载会被转移到其他的节点上去。
每个Node节点上都会运行下一组关键进程：
• kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master节点密切合作，实现集群管理的基本功能
• kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件
• Docker Engine：Docker引擎，负责本机的容器的创建和管理
Node节点可以在运行期间动态增加到Kubernetes集群中去，前提是这个节点上已经正确安装、配置和启动了上述的所有关键进程，默认情况下kubelet会向Master注册自己。一旦Node被纳入集群管理范围，kubelet会定时向Master节点汇报自身的情况，如操作系统、Docker版本、机器的CPU和memory使用情况。当某个Node超过指定的时间不上报信息的时候，会被Master判定为失联，Node状态会被标记为不可用，随后会将该Node的工作负载转移到其他Node。
3.Pod：
Pod是一组容器的组合，每个Pod都包含一个Pause容器以及若干个业务相关的容器
为什么Kubernetes会设计出Pod这样一个概念，并且有这样的组成结构呢？
• 原因1：在一组容器作为一个单元的情况下，我们很难根据一台机器的状态来判断整体的状态，因此我们引入与业务无关并且不容易死亡的Pause容器作为Pod的根容器，他来代表整个容器组的状态
• 原因2：Pod里多个业务容器共享Pause容器的IP，共享Pause容器的Volume，这样既简化了密切关联的业务容器之间的通信问题，也解决了他们之间的文件共享问题
我们用一张图来表示Node Pod和Container之间的关系：
普通的Pod一旦被创建，会被放到etcd中存储，随后会被Master调度到某个具体的Node上并进行绑定，随后该Pod被对应Node上的kubelet进程实例化程一组相关的Docker容器并启动起来。
4.Label：
Lable是Kubernetes系统中另外一个核心概念，一个Label是一个key=value的键值对，key和value由用户自己定义，Label可以附加到各种资源对象上，例如Node，Pod，Service，RC等等，一个资源对象可以定义任意数量的Label，同一个Label也能被添加到任意数量的资源对像上去。例如：
• 版本标签："release" : "stable"
• 环境标签："Environment" : "DEV"
• 分区标签 :＂partition＂ : "customerA"
我们可以用Label Selector查询和筛选拥有某些Label的资源对象。我们查询方式有两种：
• name = redis-slave : 匹配所有具有标签name = redis-slave 的资源对象
• name in (redis-master , redis-slave):匹配素有具有标签name = redis-master和name = redis-slave的资源对象
我们的label标签主要有以下几种使用场景：
• kube-controller : 通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本数量实在符合预期设定的全自动控制流程。
• kube-proxy : 通过Service的Label Selector来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
总之，使用Label可以给对象创建多组标签，Label和Label Selector共同构成了Kubernetes 系统中最核心的应用模型，使得被管理对象能够被精细的分组管理，同时实现整个集群的高可用性。
5.Replication Controller：
RC是Kubernetes 核心概念之一，他定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻符合某个预期值，了解云平台的小伙伴都知道，类似于AutoScaling所定义的虚机数目，可以设置在任意时刻必须要有N台机器处于运行状态。RC定义包括：
• Pod期待的副本数（replicas）
• 用于筛选目标Pod的Label Selector
• 当副本数小于预期数时，用于创建新的Pod的Pod模板（template）
当我们定义好一个RC并提交到Kubernetes 集群后，Master节点上的Controller Manager组件就得到通知，定期巡检系统中当前存活的目标Pod，并且确保目标Pod实例的数量刚好等于此RC的期望值，如果有过多的Pod在运行，系统就会停掉一些Pod，否则系统会在创建一些Pod。
假如我们在RC里定义redis-slave这个Pod需要2个副本，那么系统会在其中两个Node上保持两个Pod。如下图：
此外，在运行时，我们可以通过修改RC的副本数量，来实现Pod的动态缩放：
kubectl scale rc redis-slave --replicas=3
我们需要注意的是，删除RC不会删除已经创建好的Pod，如果需要删除所有符合条件的Pod，可以设置replicas的值为0，然后更新RC即可。
在Kubernetes 1.2中我们升级成另一个概念：Replica Set。功能方面，Repica Set支持Set-based selector.
最后我们来看下RC（Replica Set）的特性：
• 我们通过定义一个RC来实现Pod的创建过程以及副本数量的控制
• RC中包括完整的Pod定义模板
• RC通过Label Selector机制实现对Pod副本的自动控制
• 通过改变RC里的Pod数量，可以实现Pod的扩容
• 通过改变RC中的Pod模板的镜像版本，可以实现Pod的滚动升级功能
6.Deployment：
Deployment是Kubernetes 1.2引入的新概念，引入的目的是为了更好的解决Pod的编排问题。Deployment在内部使用的是Replica Set来实现目的，因此他可以看做是R
3.C的一次升级。
Deployment相对于RC最大的一个升级是可以随时知道当前Pod的部署进度，实际上由于一个Pod的创建、调度、绑定节点以及在目标Node上启动对应容器这一完整过程需要一定时间，所以我们期待系统启动N个Pod副本的目标状态，其实是一个连续的过程。
Deployment使用场景有如下几个：
• 创建一个Deployment对象来生成对应的Replica Set 并完成Pod副本的创建过程
• 检查Deployment的状态来看部署动作是否完成
• 更新Deployment以创建新的Pod
• 如果当前的Deployment不稳定，则回滚到早先的Deployment版本
• 查看Deployment状态，一次作为发布是否成功的目标
7.Service:
Kubernetes中的每个服务其实就是微服务，之前的Pod RC等等，都是为Service服务的：
• Service定义了一个服务的访问入口地址
• 前端应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例。
• Service与其后端Pod副本集群之间是通过Label Selector来实现无缝对接的
• RC保证Service的服务能力和服务质量始终处于预期标准
运行在每个Node上的Kube-proxy进程其实就是一个只能的负载均衡器，他负责把对Service的请求转发到后端的某个Pod上，并在内部实现服务的负载均衡与会话保持机制。Service不是共用一个负载均衡器的IP地址，而是每个Service分配了一个全局的IP地址，这个虚拟IP称为Cluster IP。
外部系统访问Service的问题：
在Kubernetes中我们有三种IP：
• Node IP： Node节点的IP地址，是集群中每个节点的物理网卡的IP地址，是一个真实存在的物理网络
• Pod IP： Pod的IP地址，是Docker Enginne根据docker()网桥的IP地址段进行分配的，通常是一个虚拟的二层网络
• Cluster IP ：Service的IP地址，是一种虚拟IP，仅仅作用于Kubernetes Service这个对象，并且由Kubernetes管理和分配IP地址，他是无法被ping到的，因为他是一个虚拟的对象
小结：Service的Cluster IP属于Kubernetes集群内部的地址，无法在集群外部直接使用这个地址，如果需要提供给外部用户使用，可以采用NodePort解决
8.Volume
Volume是Pod中能够被多个容器访问的共享目录
如何使用：在Pod上声明一个Volume，然后在容器里引用该Volume并Mount到容器的某个目录上
我们来看下Kubernetes提供的Volume类型：
• emptyDir：在Pod分配到Node时创建的临时空间，初始内容为空，并且无需指定宿主机上对应的目录文件，因为这个是Kubernetes自动分配的一个目录，当Pod从Node上移除时，emptyDir中的数据也会被永久删除。
• hostPath：在Pod上挂在宿主机上的文件或目录，可以用于以下几个方面：
1.容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高度文件系统进行存储
2.需要访问宿主机上的Docker引擎内部数据结构的容器应用时，可以通过定义hostPath为宿主机/var/lib/docker目录，使得容器内部应用可以直接访问Docker的文件系统。
• Persistent Volume：前面两种是定义在Pod上的计算资源，而网络存储是相对独立于计算资源的一种实体资源，例如AWSElasticBlockStore,AzureFile等~
9.NameSpace
在Kubernetes中，NameSpace在很多情况下用于资源隔离，NameSpace通过将集群内部的资源对象分配到不同的NameSpace中，形成逻辑上的不同分组，便于不同分组在共享使用整个集群的资源的同时还能被分别管理。
Kubernetes集群子启动后，会创建一个default的NameSpace。一旦创建了NameSpace我们在定义资源的时候就可以指定这个资源属于哪个NameSpace。
当我们在给每个用户创建NameSpace来实现多个用户资源隔离时，还可以结合Kubernetes的资源配额管理，限定不同用户能占用的资源，比如CPU、内存等等~
10.Anotation
Annotation与Label类似，也是使用Key/Value的形式定义，但是Label有严格的命名规则，当天定义的是Kubernetes对象元素（Metadata）,并且勇于Label Selector；Annotation则是用户定义的附加信息，以便于外部工具进行查找，比如，Annotation可以定义如下信息：
build信息，release信息，Docker镜像信息等。
小结
上述这些组件是Kubernetes系统的核心组件，他们共同构成了Kubernetes系统的框架和计算模型。通过对他们进行灵活组合，用户可以快速、方便的对容器和集群进行配置、创建和管理。
下面我们会对各个模块最详细的阐述。
