Kubernetes学习(二)你不得不了解的K8s核心组件

这里是weihubeats,觉得文章不错可以关注公众号小奏技术，文章首发。拒绝营销号，拒绝标题党

Master

Kubernetes里的Master指的是集群控制节点,简单理解为一台机器。在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，他负责具体的执行过程。相当于整个Kubernetes集群的大脑，非常重要，所以一般我们部署Master节点都是独立的一台服务器(高可用最少三台)
在Master节点上有如下核心进程

• Kubernetes API Server(kube-apiserver): 提供了HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程
• Kubernetes Controller Manager(kube-controller-manager): Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”
• Kubernetes Scheduler(kube-scheduler): 负责资源调度（Pod调度）的进程，相当于公交公司的“调度室”,负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。
• etcd: 所有资源对象的数据都被保存在etcd中，etcd是一款kv内存数据库,简单理解和redis有些类似，但又有所不同

本质上Master也是一个Node

Node

Kubernetes中除了Master，其他机器就被称为Node.Node可以是物理机，也可以是虚拟机。每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上。
Node上的核心进程:

• kubelet: 负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能
• kube-proxy: 实现Kubernetes Service的通信与负载均衡机制的重要组件.集群内部或外部的网络通信都是由kube-proxy维护的
• Container Runtime: 容器运行环境,比如我们常见的Docker，当然也有其他容器运行环境: containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现

Pod

Pod是Kubernetes最重要的基本概念,Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。我们可以理解pod就是一个容器，也可以理解为一个pod就是相当于一台独立主机，里面可以装多个容器，容器内部网络通信都是通过localhost来访问.
Pod是运行在Node上面的，每个Pod中都一个特殊的根容器(Pause),Pause的镜像属于Kubernetes平台的一部分.
Pause让一个Pod里面的容器共享网络，共享存储

Pod分类

Kubernetes中的Pod有两种类型

• 普通的Pod: 创建完就会存放在etcd中,然后由Kubernetes Master调度到某个具体的Node上并进行绑定(Binding),然后该Pod就会被Node上的kubelet进厂进行实例化将Pod上相关的Docker容器启动并运行。如果Pod的某个容器停止(挂掉),Kubernetes会自动检测到这个问题并且重新启动这个Pod(重启Pod里的所有容器)，如果Pod所在的Node宕机，就会将这个Node上的所有Pod重新调度到其他节点上
• 静态Pod(Static Pod): Static Pod并没有被存放在etcd中，而是被放在某个具体的Node上的一个具体文件中，且只在这个Node上启动、运行

Label

label就是标签，标签的作用显而易见就是为了筛选区分，标签是一个Key，Value键值对。标签可以附加到各种资源对象上比如:

1. Nodo
2. Pod
3. Service
4. RC(Replication Controller)

Replication Controller

RC是Kubernetes系统中的核心概念之一。简单来说就是定义了某个Pod的期望副本数。
最简单的比如我们一个Pod部署了一个Spring Boot应用，我们希望部署三个节点，所以我们期望的副本数量就是3,在我们定义完成后。Master上的Controller Manager组件收到了我们的期望通知，会去定期巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，如果有过多的Pod副本在运行，系统就会停掉一些Pod，否则系统会再自动创建一些Pod。通过RC我们可以很方便的实现自动故障恢复，动态扩容

这里总结下RC的作用

1. 创建Pod并自动控制Pod的数量
2. 调整Pod中的镜像版本，实现版本回退，滚动更新
3. RC通过Label Selector实现对Pod副本的自动控制

不过Replication Controller后续由Replica Set与Deployment代替RC的作用

Replica Set

Replica Set 官方解释是下一代RC(Replication Controller)
不过目前Replica Set与RC唯一的区别就是
ReplicaSet 可以使用标签选择器进行单选和复合选择
而 ReplicationController只支持单选操作
简单解释就是一个Pod有两个标签

1. app = web
2. label = dev

Replication Controller只能选择app = web标签的pod，而Replica Set则可以选择包含app = web或label = dev这个两个标签的pod

Deployment

Deployment是Kubernetes在1.2版本中引入的新概念，用于更好地解决Pod的编排问题.Deployment在内部使用了Replica Set来实现目的。总的来说关系如下

我们这里可以看一个简单的Deployment定义

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

在改实例中定义如下

1. 创建名为 nginx-deployment（由 .metadata.name 字段标明）的 Deployment
2. 该 Deployment 创建三个（由 replicas 字段标明）Pod 副本
3. selector 字段定义 Deployment 如何查找要管理的 Pods。 在这里，你选择在 Pod 模板中定义的标签（app: nginx）。 不过，更复杂的选择规则是也可能的，只要 Pod 模板本身满足所给规则即可

StatefulSet

在Kubernetes系统中，Pod的管理对象RC、Deployment、DaemonSet和Job都面向无状态的服务。但现实中有很多服务是有状态的，特别是一些复杂的中间件集群，例如MySQL集群、MongoDB集群、Reids集群、ZooKeeper集群等，这些应用集群有4个共同点

1. 每个节点都有固定的身份ID，通过这个ID，集群中的成员可以相互发现并通信
2. 集群的规模是比较固定的，集群规模不能随意变动
3. 集群中的每个节点都是有状态的，通常会持久化数据到永久存储中
4. 如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损

如果通过RC或者Deployment控制的Pod的名称和IP都是随机变换的，无法实现上面的部署
为此Kubernetes在1.4版本引入了StatefulSet,StatefulSet可以看成特殊的Deployment/RC
它有如下特性:

1. StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员
2. StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态
3. StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）

Service

Service和微服务中的服务差不多类似。
我们在部署多节点的时候，会部署多个Pod，每个Pod都会有独立的IP地址，也提供一个独立的Endpoint（Pod IP+ContainerPort）以被客户端访问。并且Pod的每次重新部署IP都会变换，那么一个多Pod的集群要如何提供服务负载均衡，选用哪个Pod去服务呢？正常我们会有一个负载均衡器去处理这个事情。
而Service就是干这个的，Service的访问地址一旦确认就不会再变

Job

Job可以理解为定时任务，和我们常用的xxl-job类似
Job和RC、Deployment、ReplicaSet、DaemonSet类似，也是控制Pod容器的
Job的特点

1. 控制的Pod是短暂的，每个Docker容器仅运行一次
2. Job所控制的Pod运行完成，Job结束
3. 可通过CronJob设置反复定时执行的定时任务

Volume

• Volume: 存储卷，能被Pod中多个容器共享访问的共享目录
  特点：

1. Volume定义在Pod上的，而不是某个容器
2. Volume生命周期与Pod相关，与当个容器无关

Persistent Volume

Volume是定义在Pod上的，而Persistent Volume是独立于Pod之外的定义。Persistent Volume 只是网络存储，不属于任何Node，但可以再任何Node上访问

Namespace

• Namespace: 命名空间
  Namespace主要用于多租户之间的资源隔离，类似多个集群。

ConfigMap

Kubernetes中的配置中心，主要用于配置文件参数在运行期的设置修改。ConfigMap提供一个Key、Value的方式配置，存储在Etcd中

参考

• kubernetes
• kubernetes权威指南