K8S 快速入门（四）Pod原理、核心组件工作原理

福尔摩斯媛5个月前发布

1990

一、Pod核心原理

1. Pod是什么？

Pod的特点：封装docker容器的容器

1、有自己的IP地址
2、有自己的hostname

Pod实际上也相当于是一个独立的容器（虚拟机器），而这个pod容器内部封装的是由docker引擎所创建的容器，可以理解为pod就是一个虚拟化分组，pod内部可以存储一个或者多个容器。

2. Pod作用

Pod内部封装的是容器，容器内部运行是开发的应用程序。Pod管理上线的运行的应用程序
定义：在通常情况下，在服务上线部署的时候，pod通常被用来部署一组相关的服务。（什么一组相关的服务？）

C：container，容器
Fluentd：日志

一组相关服务：在一个请求链路上的服务，叫做一组相关服务。通常情况下，这一组相关的服务在调用链路上处于上下游的关系。

经验来说：（可维护的角度）
建议一个pod内部只允许部署一个容器（一个服务）。

日志收集的容器例外

3. 服务集群

问题：服务集群该如何部署？？？？（pod内部运行就是容器，容器中运行的就是服务）

使用kubernetes构建服务集群，只需要创建多个部署了相同服务的pod即可。也就是说k8s可以实现一键式部署，一键式扩容

4. Pod原理

Pod底层核心原理：

1、数据存储
2、网络

POD容器内有一个基础容器 pause容器，它是和pod容器一起创建的
pause容器会构建一个虚拟网卡、挂载一个数据卷
POD中所有容器和pause容器会共享这个虚拟网卡、和数据卷

在使用了pause容器创建共享网卡后，pod内部容器之间访问就使用localhost访问，就相当于本地访问一样，因此性能非常高。

注意：一个pod不能分裂存储在多个node节点，但是多个pod副本可以随机分配到不同的node节点进行存储。

二、核心组件原理

1. RC[控制器]

ReplicationController — 副本控制器

用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代，而如果异常多出的容器也会自动回收。

在新版本的 Kubernetes 中建议使用ReplicaSet 来取代ReplicationController

副本控制器作用：永远保证服务数量和预期的数量保持一致。也就是说服务永远不会宕机，服务永不停机，服务永远处于高可用状态。

如果pod全部宕机：全部重新创建

注意：在新版本的 Kubernetes 中建议使用ReplicaSet 来取代ReplicationController

2. RS[控制器]

ReplicaSet

RS 控制器和pod控制架构—副本控制器是如何控制pod副本的？？

RS 和 RC 副本控制器到底有和区别？？为什么要是有RS，不使用RC呢？？

1、RC只支持单个标签的选择器
2、RS不仅支持单个标签选择器，还支持复合选择器。

Labels：标签，是用来唯一标识一个组件的，k8s中所有的资源对象都可以被标签类进行标识。通过标签标识后，方便，灵活的查询到这个组件。

查询一组相同业务pod：
app = MyAPP 此标签可以查询出下面4个pod.这4个pod是一组相关副本的pod. 标签相同，说明是同一个服务部署了多个副本。

标签选择器：

根据标签 key=value 查询与之对应的匹配的资源对象（pod，rs, deployment……）
标签选择器 – 标签 – 选择资源对象（唯一定位一个资源对象）

复合选择器：支持多个标签选择器
Selector:
app = MyApp
release = stable

注意：如果单独使用rs，就不支持滚动更新。（在企业中，产品经理不停提出新的需求，项目版本不停的迭代…如何实现不停机更新？？）

虽然ReplicaSet可以独立使用，但一般还是建议使用Deployment来自动管理ReplicaSet,这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持 rolling-update 但 Deployment支持）

3. Deployment

Deployment为Pod和ReplicaSet 提供了一个声明式定义方法，用来替代以前的 ReplicationController 来方便的管理应用。

典型的应用场景：

1、定义Deployment 来创建 Pod 和 ReplicaSet
2、滚动升级和回滚应用
3、扩容和索容
4、暂停和继续 Deployment

Deployment不仅仅可以滚动更新，而且可以进行回滚，如果发现升级到V2版本后，发现服务不可用，可以回滚到V1版本。

Deployment和rs结合使用，支持滚动更新。（发新版，不停机更新）

Deployment管理着RS，RS控制着Pod

滚动更新：新创建的RS，每创建一个新版本的pod会将原来旧的pod删除（更新过程中新旧pod会维持一个比例，最终会全部更新完），最终全更新完后，旧的RS也是不会删除的，可以用来回滚操作！！旧版本的镜像还是在的。

RS之间的感知，由Deployment控制

资源对象组成关系：

1、deployment部署资源对象，管理rs ,支持滚动更新，更新模式就是新创建一个新的rs,然后由rs创建新的版本的pod.
2、rs副本控制器，控制pod的数量与预期的数量保持一致，rs副本控制器就是来管理pod.

注意：RS是怎么知道哪几个pod受它控制？rs通过标签选择器选择受rs所管理的资源对象。

4. HPA

HPA(HorizontalPodAutoScale) — 自动扩容

Horizontal Pod Autoscaling 仅适用于 Deployment 和 ReplicaSet,在V1版本中仅支持根据Pod的CPU利用率扩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩缩容

HPA也是一个资源对象

5. StatefullSet

Deployment ,StatefulSet都是用来部署服务的。

1、但是deployment被用来部署无状态服务，不适合部署有状态服务。
2、statefulset是用来部署有状态服务的。

StatefullSet 是为了解决有状态服务的问题（对应Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括：

1、稳定的持久化存储，即Pod重新调度后还是能访问的相同持久化数据，基于PVC来实现
2、稳定的网络标志，及Pod重新调度后其 PodName 和 HostName 不变，基于Headlesss Service（即没有 Cluster IP 的 Service）来实现。
3、有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从 0 到 N-1,在下一个Pod运行之前所有之前的Pod必须都是Running 和 Ready 状态），基于 init containers 来实现。
4、有序收缩，有序删除（即从N-1 到 0）

无状态：

1、没有实时的数据需要存储
2、在服务集群网络中，把其中一个服务抽离出去，过一段时间在加入进来，对服务集群没有任何影响。

例如一些业务逻辑服务：

有状态：

1、有实时数据需要存储
2、在服务集群网络中，把其中一个服务抽离出去，过一段时间在加入进来，对服务集群有影响。

ES/MYSQL/Mongodb/……………等都是有状态服务

为什么有状态服务的pod，必须使用statefulSet来进行部署？？？？

前提(本质原因)：副本创建，滚动更新，扩容，都是创建一个新的pod。当一个pod宕机后，会重新创建一个新的pod.这个新的pod如何共享之前数据？如果不做任何处理，此时这个新的pod就会丢失之前的数据，对于有状态服务来说，就是灾难。

每个pod都对应一个自己的volum，数据卷
有状态的pod挂了，新创建的pod，它还能找到原来挂掉的pod的数据卷

Statefulset部署有状态服务网络拓扑结构：

Statefulset模式下，pod的数据卷就不是volume，而是两个持久化存储资源对象PVC和PV，PVC下面挂载PV
PV挂载了一个文件服务器，例如nfs文件服务器

即数据是挂载在网络存储上的，当然本地也能存储但是不推荐
PersistentVolumeClaim（持久化卷申明/存储）
PersistentVolume（持久化数据卷）

Statefulset保证数据不丢失根据pod的名称来挂载数据的，也就是说可以让pod的名称永远保持不变，在pod宕机，重新创建后，根据名称找回数据。

6. DaemonSet

DaemonSet确保全部（或者一些 [ node打上污点（可以想象成一个标签）,pod如果不定义容忍这个污点，那么pod就不会被调度器分配到这个node ]）Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除他创建的所有Pod,使用DaemonSet 的一些典型用法：

1、运行集群存储daemon,例如在每个Node上运行glustered,ceph
2、在每个Node上运行日志收集Daemon,例如：fluentd、logstash.
3、在每个Node上运行监控Daemon,例如：Prometheus Node Exporter

Daemonset就是让每一个node节点都运行一个相同的pod.

例如：

7. Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

Cron Job管理基于时间Job,即：

在给定时间点只运行一次
周期性地在给定时间点运行

8. Volume

数据卷，共享Pod中容器使用的数据。

9. Label

标签用于区分对象（比如Pod、Service），键/值对存在；每个对象可以有多个标签，通过标签关联对象。

Kubernetes中任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key于value由用户自己指定。

Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。

Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。

我们可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置等管理工作。

一些常用的Label如下：（规范，也可以随意定义）

版本标签：“release”:“stable”,“release”:“canary”…
环境标签：“environment”:“dev”,“environment”:“qa”,“environment”:“production”
架构标签：“tier”:“frontend”,“tier”:“backend”,“tier”:“middleware”
分区标签：“partition”:“customerA”,“partition”:“customerB”
质量管控标签：“track”:“daily”,“track”:“weekly”

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

Label Selector在Kubernetes中重要使用场景如下:

kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现副本数量始终符合预期设定的全自动控制流程;
kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡;
通过对某些Node定义特定的Label，并且在Pod定义文件中使用Nodeselector这种标签调度策略，kuber-scheduler进程可以实现Pod”定向调度“的特性;