「走进k8s」Kubernetes基本概念和组件（13）

上次通过katacoda体验了Kubernetes界面化工具，大概也了解了一些组件和概念。

（一）整体

• ①整体流程

首先从整体上看，上边这块就是Master节点，下面有两块都是worker节点，master里面部署的都是k8s的核心模块，虚线框代表的是API Server，提供了资源的核心模块，提供了认证授权和k8s的访问控制，可以通过kubectl或者自己开发的userClient，restApi的形式访问API server。从而完成整个集群的访问。

1. ControllerManager负责维护集群的状态，比如故障检测，扩缩容，滚动更新等等。
2. Scheduler负责资源的调度，按照预定的策略把pod调度到指定的node节点
3. ETCD 用做已执行存储，pod，service的集群等信息，k8s需要持久化的数据都存储在这个上边。
4. Kubelet负责维护当前节点上的容器的生命和volumes，网络。
5. 每个Node上可以运行一个kube-proxy，负责service 提供内部的服务发现和负载均衡，为service方法做个落地的功能。
6. kube-dns负责整个集群的dns服务，这个组件不是必须的，一般通过名字访问比较方便。
7. dashboard集群数据的GUI界面。

• ②全过程梳理

1. kubectl 发起一个请求，请求经过认证。
2. scheduler的策略和评分计算得到目标的node。
3. APIServer请求Node，通过kublet把这个Node运行pod起来。
4. APIServer把信息发送给ETCD保存起来。
5. pod运行起来之后，通过ControllerManager管理每个pod的状态，如果突然挂了，就想办法创建一个pod。给pod分个独立的ip地址，可以在整个集群内使用这个ip来访问它。但是pod的ip是易变的，异常重启和升级的时候，不可能关注某个pod的Ip的。
6. 下面虚线的部分表示的是一个service，service里面有3个pod，不在虚线里面的是单独存在的pod，并没有提供service的入口，完成service的具体工作的模块就是kube-proxy，在每个node上都有一个kube-proxy，然后给service分配一个ip，可以访问service里面的pod，所以kube-proxy对应的service都会有一个ip的指向，负载均衡的访问他们。
7. kube-proxy（service） 可以把端口和ip直接暴露在node上。外边的请求可以访问node上的ip就可以关联到这个service上了。
8. kube-dns 就是为了方便名字直接访问node节点。任何一个pod都可以通过名字来进行访问。

（二） k8s的设计理念

了解设计理念可以更深入的了解k8s，设计实在太好了，非常值得我们学习和借鉴。

• ①API设计原则

1. 所有的api都是声明式的（对于重复的操作是稳定的，所有的对象都是名词，不是动词，用户很容易的期望用户的样子，当前的系统是否满足需求，明确用户的目的，用系统管理的业务意图触发设计）
2. 控制机的设计原则（假定各种可能存在错误的可能，并做容错处理，出现局部错误和临时错误是很正常的事情，错误可能存在于物理故障磁盘，外部系统的故障啊，系统本身的代码问题，考虑到任何可能的错误，并且做容错处理，每个模块出现错误后，恢复处理，在系统中不可能保证每个模块始终是连接的，因此任何一个模块都要有自动修复的能力，保证连接不到其他模块而形成的自我崩溃。很多情况下可以做到优雅的降级，要求在设计的过程中，有基本功能和高级功能，同时不会导致高级功能的崩溃，影响到这个模块 的使用，更容易的引入高级功能，而会导致高级功能影响基本功能。）

• ②k8s网络

1. CNI
2. Flannel，Calico，Weave
3. Pod网络

• ③scheduler-preselect

1. NodiskConflict 挂载冲突
2. checkNodeMemMemoryPressure 内存的压力
3. Nodeselect 节点的选择器
4. FitRescoure CPU，内存的限制
5. Affinity 满足pod的连接状态的限制

• ④scheduler-optimize-select

优先规则，对node进行打分，通过优先函数进行预选规则，每个优先函数可以返回0-10的函数，分数越高，这台主机越适合，对应一个权重。

1. selectorSpreadPriority
2. LeastRequestedPriority
3. AffinityPriority

• ⑤pod内部通讯

• ⑥同一个node上的不同pod通讯

通过pod的Ip来进行访问

• ⑦不同的node，不同的pod通讯

满足pod，ip不能冲突

（三） k8s的服务发现

• ①kube-proxy（ClusterIp）

每个服务，所有的pod给虚拟Ip，虚拟Ip只能在内部访问

• ②kube-proxy（NodePort）

服务暴露到节点，外部的可以通过NodeIp 访问pod

• ③kube-DNS

负责集群内部的dns解析，内部之间可以通过名称访问pod。

（三）基本概念

玩k8s，玩的就是集群

• ①master（类似swarm 中的manager）

kubernetes里的Master指的是集群控制节点。每个kubernetes集群里都需要一个Master节点来负责整个集群的管理和控制，基本上kubernetes所有的控制命令都是发给它，它来负责具体的执行过程，我们后面所有的执行的命令基本上都是在Master节点上运行的。Master节点通常会占据一个独立的服务器或虚拟机，就是它的重要性体现，一个集群的大脑，如果它宕机，那么整个集群将无法响应控制命令。

1. Kubernetes API Server（kube-apiserver）：提供了HTTP rest接口的关进服务进程，是Kubernetes里所有资源增删改查等操作的唯一入口，也是集群管理的入口进程。
2. Kubernetes Controller Manage（kube-controller-manage）：Kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。
3. Kubernetes Scheduler（kube-scheduler）：负责资源的调度（Pod调度）的进程。

• ②node （类似swarm 中的worker）

同样的它也是一台物理机或是虚拟机。Node节点才是Kubernetes集群中工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机之后，其上的工作负载会被Master自动转移到其它节点上面去。

1. kubelet：负责pod对应的同期创建、启动停止等任务，同时与Master节点密切协作，实现集群管理的基本功能。
2. kube-proxy：实现Kubernetes Service的通信与负载均衡的重要组件。
3. Docker-Engine（docker）：docker引擎，负责本机容器的创建和管理工作。

• ③Pod

Kubernetes 最基本的部署调度单元。每个 Pod 可以由一个或多个业务容器和一个根容器(Pause 容器)组成。一个 Pod 表示某个应用的一个实例。 每个pod由一个根容器的pause容器，其他是业务容器。

k8s为每个pod分配了唯一的IP地址，一个pod里的多个容器共享pod IP。 pod其实有两种类型：普通的pod和静态pod，后者比较特殊，它并不存放在etcd存储中，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动运行。而普通的pod一旦被创建，就会被放入etcd中存储。随后被master调度到某个具体的Node上并进行绑定，随后该pod被对应的Node上的kubelet进程实例化成一组相关的docker容器并启动起来。 每个pod都可以对其使用的服务器上的计算资源设置限额，当前可以设置限额的源有CPU和memory两种。其中CPU的资源单位为CPU的数量。 一般而言，一个CPU的配额已经算是相当大的一个资源配额，所以在k8s中，通常以千分之一的CPU配额为最小单位，以m来表示，通常一个容器的CPU配额为100-300m，即占用0.1-0.3个CPU。这个配额是个绝对值，不是占比。 在k8s中，一个计算资源进行配额限定需要设定两个参数： requests，资源的最小申请量，系统必须满足要求 limits，资源最大允许使用的量。

pod的状态

Pending

挂起，这时pod已经被k8s集群接受，但有一个或多个容器镜像尚未创建，等待时间包括调度pod的时间和通过网络下载容器镜像的时间。

Running

此时pod已经被绑定到某一个节点上，pod中所有的容器都被创建并且至少有一个容器正在运行或者处于启动或重启状态。

Succeed

此时pod中的所有容器都被成功终止并且不会重启。

Failed

pod中的所有容器都已经被终止，并且至少有一个容器因为失败而终止（容器以非0状态退出）。

• ④ReplicaSet

Pod 副本的抽象，用于解决 Pod 的扩容和伸缩。

• ⑤Deployment

Deployment 表示部署，在内部使用ReplicaSet 来实现。可以通过 Deployment 来生成相应的 ReplicaSet 完成 Pod 副本的创建。

• ⑥Service

Service 是 Kubernetes 最重要的资源对象。Kubernetes 中的 Service 对象可以对应微服务架构中的微服务。Service 定义了服务的访问入口，服务的调用者通过这个地址访问 Service 后端的 Pod 副本实例。Service 通过 Label Selector 同后端的 Pod 副本建立关系，Deployment 保证后端Pod 副本的数量，也就是保证服务的伸缩性。

（四）组件

• ①API Server

K8S对外的唯一接口，提供HTTP/HTTPS RESTful API，即kubernetes API。所有的请求都需要经过这个接口进行通信。主要负责接收、校验并响应所有的REST请求，结果状态被持久存储在etcd当中，所有资源增删改查的唯一入口。（大脑中央控制器）

• ②etcd

负责保存k8s 集群的配置信息和各种资源的状态信息，当数据发生变化时，etcd会快速地通知k8s相关组件。etcd是一个独立的服务组件，并不隶属于K8S集群。生产环境当中etcd应该以集群方式运行，以确保服务的可用性。（数据库）

etcd不仅仅用于提供键值数据存储，而且还为其提供了监听（watch）机制，用于监听和推送变更。在K8S集群系统中，etcd的键值发生变化会通知到API Server，并由其通过watch API向客户端输出。

• ③Controller Manager （反应器，是跳，还是跑）

负责管理集群各种资源，保证资源处于预期的状态。Controller Manager由多种controller组成，包括replication controller、endpoints controller、namespace controller、serviceaccounts controller等 。由控制器完成的主要功能主要包括生命周期功能和API业务逻辑，具体如下：

• 生命周期功能：包括Namespace创建和生命周期、Event垃圾回收、Pod终止相关的垃圾回收、级联垃圾回收及Node垃圾回收等。
• API业务逻辑：例如，由ReplicaSet执行的Pod扩展等。
• ④调度器（Schedule）

资源调度，负责决定将Pod放到哪个Node上运行。Scheduler在调度时会对集群的结构进行分析，当前各个节点的负载，以及应用对高可用、性能等方面的需求。

• ⑤Kubelet

kubelet是node的agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet会根据这些信息创建和运行容器，并向master报告运行状态。

• ⑥Container Runtime

每个Node都需要提供一个容器运行时（Container Runtime）环境，它负责下载镜像并运行容器。目前K8S支持的容器运行环境至少包括Docker、RKT、cri-o、Fraki等。

• ⑦Kube-proxy

service在逻辑上代表了后端的多个Pod，外界通过service访问Pod。service接收到请求就需要kube-proxy完成转发到Pod的。每个Node都会运行kube-proxy服务，负责将访问的service的TCP/UDP数据流转发到后端的容器，如果有多个副本，kube-proxy会实现负载均衡，有2种方式：LVS或者Iptables

K8S集群还依赖一组附件组件，通常是由第三方提供的特定应用程序。

• ⑧KubeDNS

在K8S集群中调度并运行提供DNS服务的Pod，同一集群内的其他Pod可以使用该DNS服务来解决主机名。K8S自1.11版本开始默认使用CoreDNS项目来为集群提供服务注册和服务发现的动态名称解析服务。

• ⑨Dashboard

K8S集群的全部功能都要基于Web的UI，来管理集群中的应用和集群自身。

• ⑩Heapster

容器和节点的性能监控与分析系统，它收集并解析多种指标数据，如资源利用率、生命周期时间，在最新的版本当中，其主要功能逐渐由Prometheus结合其他的组件进行代替。

（五）最典型的创建 Pod 的流程

PS：k8s主要明白基本概念有哪些，基本组件有哪些，了解他的概念，下一步咱们一起搭建k8s集群。