k8s相关知识点

k8s相关知识点

零、k8s哲学

Kubernetes中的大部分概念如Node、Pod、ReplicationController、Service等都可以看作一种“资源对象”，几乎所有的资源对象都可以通过Kubernetes提供的kubectl工具（或者API编程调用）执行增、删、改、查等操作并将其保存在etcd中持久化存储。从这个角度来看，Kubernetes其实是一个高度自动化的资源控制系统，它通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

一、Master

集群控制节点，Master节点通常会占据一个独立的服务器（高可用部署建议用3台服务器），其主要原因是它太重要了，是整个集群的“首脑”，如果宕机或者不可用，那么对集群内容器应用的管理都将失效。

Master节点上运行着以下一组关键进程。
1.Kubernetes API Server（kube-apiserver）：提供了HTTPRest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程;
2.Kubernetes Controller Manager（kube-controller-man-ager）：内部包含Replication Controller、Node Controller、ResourceQuota Controller、Service Controller及Endpoint Controller等多个Controller，每种Controller都负责一种具体的控制流程。
3.Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程，相当于公交公司的“调度室”;
4.etcd服务，因为Kubernetes里的所有资源对象的数据全部是保存在etcd中的;

二、Node

除了Master，集群中的其他机器被称为Node节点，它才是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上去。

每个Node节点上都运行着以下一组关键进程。 1.kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master节点密切协作，实现集群管理的基本功能;
2.kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件;
3.Docker Engine（docker）：Docker引擎，负责本机的容器创建和管理工作;

Node节点可以在运行期间动态增加到Kubernetes集群中，前提是这个节点上已经正确安装、配置和启动了上述关键进程，在默认情况下kubelet会向Master注册自己，这也是Kuber-netes推荐的Node管理方式。一旦Node被纳入集群管理范围，kubelet进程就会定时向Master节点汇报自身的情报，例如操作系统、Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等，这样Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node超过指定时间不上报信息时，会被Master判定为“失联”，Node的状态被标记为不可用（Not Ready），随后Master会触发“工作负载大转移”的自动流程。

三、Pod

每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kuber-netes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

引入业务无关并且不易死亡的Pause容器作为Pod的根容器，以它的状态代表整个容器组的状态。

Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。

Pod的IP加上这里的容器端口（containerPort），就组成了一个新的概念—Endpoint，它代表着此Pod里的一个服务进程的对外通信地址。一个Pod也存在着具有多个Endpoint的情况，比如当我们把Tomcat定义为一个Pod时，可以对外暴露管理端口与服务端口这两个Endpoint。

每个Pod都可以对其能使用的服务器上的计算资源设置限额，当前可以设置限额的计算资源有CPU与Memory两种，其中CPU的资源单位为CPU（Core）的数量，是一个绝对值而非相对值。一个CPU的配额对于绝大多数容器来说是相当大的一个资源配额了，所以，在Kubernetes里，通常以千分之一的CPU配额为最小单位，用m来表示。通常一个容器的CPU配额被定义为100～300m，即占用0.1～0.3个CPU。由于CPU配额是一个绝对值，所以无论在拥有一个Core的机器上，还是在拥有48个Core的机器上，100m这个配额所代表的CPU的使用量都是一样的。与CPU配额类似，Memory配额也是一个绝对值，它的单位是内存字节数。在Kubernetes里，一个计算资源进行配额限定需要设定以下两个参数。 •Requests：该资源的最小申请量，系统必须满足要求。 •Limits：该资源最大允许使用的量，不能被突破，当容器试图使用超过这个量的资源时，可能会被Kubernetes Kill并重启。通常我们会把Request设置为一个比较小的数值，符合容器平时的工作负载情况下的资源需求，而把Limit设置为峰值负载情况下资源占用的最大量。

Label相当于我们熟悉的“标签”，给某个资源对象定义一个Label，就相当于给它打了一个标签，随后可以通过Label Selec-tor（标签选择器）查询和筛选拥有某些Label的资源对象，Ku-bernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。

四、Replica Set

在大多数情况下，我们通过定义一个RC实现Pod的创建过程及副本数量的自动控制。
RC里包括完整的Pod定义模板。
RC通过Label Selector机制实现对Pod副本的自动控制。
通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容功能。
通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级功能。

五、Deployment

Deployment在内部使用了Replica Set来实现目的，无论从Deployment的作用与目的、它的YAML定义，还是从它的具体命令行操作来看，我们都可以把它看作RC的一次升级，两者的相似度超过90%

六、StatefulSet

现实中有很多服务是有状态的，特别是一些复杂的中间件集群，例如MySQL集群、MongoDB集群、Akka集群、ZooKeeper集群等，这些应用集群有以下一些共同点。 1.每个节点都有固定的身份ID，通过这个ID，集群中的成员可以相互发现并且通信;
2.集群的规模是比较固定的，集群规模不能随意变动;
3.集群里的每个节点都是有状态的，通常会持久化数据到永久存储中;
4.如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损

StatefulSet从本质上来说，可以看作Deployment/RC的一个特殊变种，它有如下一些特性。
1.StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名字叫kafka,，那么第1个Pod叫kafka-0，第2个叫kafk-1，以此类推;
2.StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态;
3.StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）。

七、Service

Pod的Endpoint地址会随着Pod的销毁和重新创建而发生改变，因为新Pod的IP地址与之前旧Pod的不同。而Service一旦被创建，Kubernetes就会自动为它分配一个可用的Cluster IP，而且在Service的整个生命周期内，它的ClusterIP不会发生改变。于是，服务发现这个棘手的问题在Kubernetes的架构里也得以轻松解决：只要用Service的Name与Service的Cluster IP地址做一个DNS域名映射即可完美解决问题。

targetPort属性用来确定提供该服务的容器所暴露（EXPOSE）的端口号，即具体业务进程在容器内的targetPort上提供TCP/IP接入；而port属性则定义了Service的虚端口。前面我们定义Tomcat服务时，没有指定target-Port，则默认targetPort与port相同。

三大端口：
1.port：service暴露在clusterIp上的端口，clusterIp:port 是提供给集群内部客户访问service的入口。

2.nodePort：是k8s提供给集群外部客户访问service入口的一种方式，nodeIp:nodePort 是提供给集群外部客户访问service的入口。

3.targetPort：是pod上的端口，从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器。

总的来说，port和nodePort都是service的端口，前者暴露给集群内客户访问服务，后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod，从而到达pod上的容器内。

Service Controller与Endpoint Controller

Endpoints表示了一个Service对应的所有Pod副本的访问地址，而endpoints controller就是负责生成和维护所有Endpoints对象的控制器。负责监听Service和对应的pod副本的变化，如果Service被删除，删除和该Service同名的Endpoints对象。如果新的Service被创建或者修改，根据该Service信息获得相关的pod列表，然后创建或者更新Service对应的Endpoints对象。如果监测到pod的事件，则更新它所对应的Service的Endpoints对象

每个Node上的kube-proxy进程获取每个Service的Endpoints，实现Service的负载均衡。

八、Volume

Kuber-netes的Volume概念、用途和目的与Docker的Volume比较类似，但两者不能等价。首先，Kubernetes中的Volume定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下；其次，Kubernetes中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失。

Kubernetes提供了非常丰富的Volume类型，下面逐一进行说明。

1. emptyDir一个emptyDir Volume是在Pod分配到Node时创建的。从它的名称就可以看出，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为这是Kubernetes自动分配的一个目录，当Pod从Node上移除时，emptyDir中的数据也会被永久删除。

2. hostPathhostPath为在Pod上挂载宿主机上的文件或目录，它通常可以用于以下几方面。 •容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统进行存储。

九、Persistent Volume

PV可以理解成Kubernetes集群中的某个网络存储中对应的一块存储，它与Volume很类似，但有以下区别。
1.PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。
2.PV并不是定义在Pod上的，而是独立于Pod之外定义。

比较重要的是PV的accessModes属性，目前有以下类型。
1.ReadWriteOnce：读写权限、并且只能被单个Node挂载;
2.ReadOnlyMany：只读权限、允许被多个Node挂载;
3.ReadWriteMany：读写权限、允许被多个Node挂载。

如果某个Pod想申请某种类型的PV，则首先需要定义一个PersistentVolumeClaim（PVC）对象。然后，在Pod的Volume定义中引用上述PVC即可

十、Annotation

Annotation与Label类似，也使用key/value键值对的形式进行定义。不同的是Label具有严格的命名规则，它定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selec-tor。而Annotation则是用户任意定义的“附加”信息，以便于外部工具进行查找，很多时候，Kubernetes的模块自身会通过Annotation的方式标记资源对象的一些特殊信息。

十一、Namespace

Namespace在很多情况下用于实现多租户的资源隔离，通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

如果不特别指明Namespace，则都指向名为default的Namespace