学习K8S的第一步，当然是了解它基本概念了（说实话很多）。本文总结自《kubernetes权威指南》，个人学习笔记。
Kubernetes简称K8S
K8S是一个基于容器技术的分布式架构解决方案，提供了完善的管理工具，涵盖了开发、部署、动态扩容、滚动升级、运维监控等多个方面。相比于Docker，K8S是容器的管理者，协调者，监控者（一个全局把控的角色），而Docker则在这个平台中充当运行时。
Docker生态也有类似于K8S概念的东西-Docker Swarm，但功能上并没有K8S强大，毕竟K8S是Google在多年实践的产物。目前主流的还是K8S+Docker运行时
Kubernetes基本概念和术语
在kubernetes中Node、Pod、RC、Service等都被看作是一种 资源对象 ，几乎所有的资源对象都由K8S提供的 kubectl 工具（或者通过API调用），执行增删该查的操作，并将其保存到 etcd 中持久存储。
通常使用 yaml 或 json 文件来声明一个 资源对象 （每个资源对象都有自己特定的属性和语法结构），需要重点注意的是 apiVersion 属性。K8S平台采用了“核心+外围扩展”的设计思路（在保持平台核心稳定的同时持续推进升级优势），大部分的 资源对象 都是属于 v1 这个 核心API（apiVersion: v1）。K8S升级过程中，这些资源对象会有一些新的属性，K8S的处理方式是，一开始，将它存储到一个很长的备注字段里面（作为一种扩展属性），等到成熟后，修改数据库结构（增改表列）形成正式版。
Master（第一个讲的肯定很重要）
集群控制节点（通常单独占据一台服务器，高可用建议部署3台）。K8S集群都需要一个Master来负责管理和控制，基本上K8S伤感所有控制命令都发给它，它负责具体的执行过程。如果Master炸了，那集群内容器应用管理也都会失效。另外，Master上通常还需要部署etcd服务，因为K8S所有的资源对象的数据都存储在etcd中
关键进程：
- Kubernetes API Server(kube-apiserver)：提供HTTP Rest接口，能力就是对所有资源进行过增、删、改、查。
- Kubernetes Controller Manager（kube-controller-manager）：Kubernetes里所有资源对象的自动化控制中心，理解成资源对象的“大主管”。
- Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程，相当于公交公司“调度室”。
Node
除Master之外，其他的机器被称为Node（较早版本为Minion），是K8S集群中工作负载节点，每个Node节点会被Master分配一些工作负载（其实就是Docker容器）。当Node宕机时，它的工作负载会被Master指派给其他的Node。
关键进程：
- kubelet：负责Pod对应容器的创建，启停等任务，同时和Master密切协作，实现集群的管理。
- kube-proxy：实现Kubernetes Service的通信和负载均衡机制的重要组件。
- Docker Engine：Docker引擎，负责提供容器创建和管理工作。
==待补充==：Node相关命令和详细属性信息解释
Pod（最重要的基本概念）
每一个Pod都包含一个被称为“根容器”的Pause容器和一个或者多个密切相关的用户业务容器。它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。 Pod 表示集群上正在运行的进程。
为什么Pod是这样的一个结构组成（为什么有Pause容器）？
- 在一组容器作为一个单元的情况下，很难简单的对“整体”进行判断。例如一个容器死亡了，此时算整体死亡吗？还是说超过N/M的死亡率才算是死亡。引入一个与业务无关的且不容易死亡的Pause容器作为Pod的根容器，以它的状态代表整个容器状态，很简单，巧妙的解决了这个问题。
- Pod里的多个业务容器共享Pause容器的Ip和挂在的Volume。简化了业务容器之间的通信问题，和他们之间的文件共享问题。
Pod其实有两种类型，普通的Pod和静态的Pod（Static Pod）。后者比较特殊，并没有存储到K8S的etcd存储里，而是存储在具体Node上的一个具体文件中，并且只能在此Node上启动运行。而普通的Pod，一旦创建；就会被放入到etcd中存储，后被K8S Master调度到具体的某个Node上并进行（Binding），之后该Node上的kubelet进程实例化成一组相关的Docker容器并运行。如果Pod所在的Node宕机，就会将这个Node上所有Pod重新调度到其他节点上。
Kubernetes为每个Pod都分配了唯一的IP地址，称之为Pod IP。一个Pod里多个容器共享Pod IP地址。Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信（这通常使用虚拟二层网络技术来实现）。牢记一点：在Kubernetes里，一个Pod里的容器与另外主机伤感的Pod容器能够直接通信。。Pod的IP加上这里的容器端口（containerPort），组成一个新的概念EndPoint，它代表Pod里的一个服务进程的对外通信地址，一个Pod存在多个Endpoint的情况。
对于绝大多数的容器来说，一个CPU的资源配额相当大，所以K8S通常以千分之一CPU配额为最小单位，用m来表示。一般一个容器的CPU配额为100～300m（占0.1～0.3个CPU）。和CPU配额类型，Memory配额也是个绝对值，它的单位是内存字节。一般需要配置两个参数
-Requests：该资源的最小申请资源量，系统必须满足要求。
-Limits：该资源最大使用量，突破后容器可能会被杀死。
Docker Volume在K8S里面对应Pod Volume，但做了一些扩展比如说可以使用分布式文件系统GlusterFS实现后端存储功能，Pod Volume被定义在Pod上，然后被各个容器挂在到自己的文件系统中。
还有一个Kubernetes Event的概念，Event是一个事件记录，记录了事件最早产生事件，最后重现时间，重试次数，发起者，类型以及导致此事件的原因信息。是排查故障的重要参考信息。Node的描述信息有Event的描述，Pod的也有。
kubectl describe pod xxx 来查看描述信息
==待补充==：Pod相关命令和属性定义解释
Label
标签，一个Label是一个key=value的键值对，其中key与value由用户自己指定，Lable可以附加到各种资源对象上（Node，Pod，Service，RC）。Lable和资源对象是多对多关系，通常在定义资源对象时确定，也可以在创建后进行动态的添加或者删除。通过Label我们可以很方便对资源进行过筛选，以便进行资源分配，调度，配置，部署管理。
常用Label:
- 版本标签："release":"stable","release":"canary"
- 环境标签："environment":"dev","environment":"qa","environment":"production"
- 架构标签："tier":"frontend","tier":"backend","tier":"middleware"
- 分区标签："partition":"customerA"
- 质量管控标签："track":"daily","track":"weeklyss"
当给特定的资源打上标签后，可以通过Label Selector（标签选择器）查询和筛选拥有某些Lable的资源对象。当前有两种Lable Selector表达式。
1.基于等式（Equality-base）
- name=redis：匹配所有具有标签name=redis的资源对象
- env!=prod：匹配所有不具有标签env=prod的资源对象
2.基于集合（Set-based）
- name in (redis,mysql)：具有括号内任何一个的
- name not in (redis,mysql)：不包含括号内任何一个
可以通过多个Lable Selector表达式组合实现复杂的条件选择，多个表达式之间用“,”隔开，几个条件之间是AND的关系。如name=redis,env!=prod。
管理对象RC和Service可以通过Selector字段设置需要关联的Pod的Label。如下：
spec:
selector:
app:web
其他管理对象Deployment，ReplicaSet，DaemonSet和Job则可以在Selector中使用基于集合的筛选条件定义。如下：
selector:
matchLables:
app:web
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
- {key: enviroment, operator: NotIn, values: [dev]}
matchLabels用来定义一组Label，matchExpressions用来定义一组基于集合的筛选条件，可用的条件运算符包括，In，NotIn，Exists和DoesNotExists.如果同时使用了两者，则他们的关系为AND。
Label Selctor在Kubernetes中的重要使用场景如下：
- kube-controller进程通过资源对象RC上定义的Label Selector来筛选出副本的数量，使Pod的数量始终符合预期定义的全自动控制流程。
- kube-proxy进程通过Service的Lable Selector来选择对应的Pod，自动建立每个Service到对应的Pod的请求转发路由表，实现Service的智能负载均衡。
- 通过Node定义的Lable，并且Pod定义文件中使用Node Selector这种标签调度策略，kube-scheduler进程可以实现Pod定向调度的特性。
Replication Controller
简称RC，RC定义了一个期望的场景，即声明某种Pod的副本数量在任何时刻都符合耨个预期值，一个RC的定义包含如下几个部分。
- Pod期望的副本数量
- 用来筛选目标Pod的Label Selector
- 当Pod的副本数量小于预期数量时，用来创建新的Pod的Pod模版（template）。
在我们定义一个RC并将其提交到Kubernetes集群中后，Master上的Controller Manager组件就得到通知，定期检查系统中当前存活的Pod，并确保Pod实例的数量刚好等于RC的期望值（通过停掉或者创建）。并且运行期间我们可以通过修改RC的副本数量，来实现Pod的动态缩放（Scaling）。
kubectl scale rc redis-slave --replicas=3
在运行期间，删除RC并不会影响已经创建好的Pod。另外kubectl提供了stop和delete命令，一次性删除RC和RC控制的Pod。借助RC可以很容易的实现滚动升级，例如说有10个Pod，应用升级时，可以停掉一个久的应用，那么为了满足期望，就会重新启动一个新的，等启动好了之后，在搞掉一个旧的，重复这个步骤直到所有的容器都是新的版本。
Replication Controller由于和K8S代码中的模块Replication Controller同名，同时RC无法准确表达本意，所以在K8S1.2中，升级为一个新的概念Replia Sets 支持基于集合的Label Selector（Set-based selector），而RC仅支持等式的Label Selector（equality-based selector）。kubectl命令工具适用于RC的绝大部分命令同样适用于Replica Set。但是当前我们很少使用Replica Set 它主要被Deployment这个更高层的资源对象所使用，从而形成一整套Pod创建删除更新的编排机制。
总结RC（Replica Set）的特性和作用
- 在大多数情况下，我们通过定义一个RC实现Pod的创建及副本数量的自动控制。
- 在RC里包括了完整的Pod定义模版。
- RC通过Label Selector机制实现对Pod副本的自动控制。
- 通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容。
- 通过改变RC里Pod模版中的景象版本，可以实现Pod的滚动升级。
==待补充==：RC相关命令和属性定义解释
Deployment
Deployment是K8S在1.2版本中引入的新概念，用来跟好解决Pod的编排，Deployment在内部使用了Replica Set来实现目的，可以把它看作是对RC的一次升级，两者相似度超过90%。Deployment相对于RC的一个最大升级是我们可以随时知道当前Pod部署的进度（就是能够看到这个过程中的状态变化）。
Deployment的典型使用场景
- 创建一个Deployment对象来生成对应的Replica Set 并完成Pod副本的创建。
- 检查Deployment的状态，来看部署动作是否完成，（Pod副本数量是否达到预期的值）
- 更新Deployment以创建新的Pod（比如镜像升级）。
- 如果当前Deployment不稳定，则回滚到一个个早先的Deployment版本。
- 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment，进行新的发布。
- 扩展Deployment以应对高负载。
- 查看Deployment的状态，以此作为发布是否成功的指标。
- 清理不再需要的旧版本ReplicatSets
Pod的管理对象，包括RC、ReplicatSet，Deployment、DaemonSet、StatefulSet、Job等。它们用于不同的应用场景中。
==待补充==：Deployment相关命令和属性定义解释
...未完待续