江苏龙网

  1. 首页 > 人文 > >

人走茶凉|「Kubernetes6」K8s：无状态应用

当一个 Pod 被创建出来 ， 不管是由你直接创建 ， 还是由其他工作负载控制器（Workload Controller）自动创建 ， 经过调度器调度以后 ， 就永久地“长”在某个节点上了 ， 直到该 Pod 被删除 ， 或者因为资源不够被驱逐 ， 抑或由于对应的节点故障导致宕机等 。 因此单独地用一个 Pod 来承载业务 ， 是没办法保证高可用、可伸缩、负载均衡等要求 ， 而且 Pod 也无法“自愈” 。
【人走茶凉|「Kubernetes6」K8s：无状态应用】这时我们就需要在 Pod 之上做一层抽象 ， 通过多个副本（Replica）来保证可用 Pod 的数量 ， 避免业务不可用 。
有状态服务 VS 无状态服务一般来说 ， 业务的服务类型可分为无状态服务和有状态服务 。 举个简单的例子 ， 像打网络游戏这类的服务 ， 就是有状态服务 ， 而正常浏览网页这类服务一般都是无状态服务 。 其实判断两种请求的关键在于 ， 两个来自相同发起者的请求在服务器端是否具备上下文关系 。
如果是有状态服务 ， 其请求是状态化的 ， 服务器端需要保存请求的相关信息 ， 这样每个请求都可以默认地使用之前的请求上下文 。
而无状态服务就不需要这样 ， 每次请求都包含了需要的所有信息 ， 每次请求都和之前的没有任何关系 。
有状态服务和无状态服务分别有各自擅长的业务类型和技术优势 ， 在 Kubernetes 中 ， 分别有不同的工作负载控制器来负责承载这两类服务 。
Kubernetes 中的无状态工作负载Kubernetes 中各个对象的 metadata 字段都有 label（标签）和 annotation（注解） 两个对象 ， 可以用来标识一些元数据信息 。
1,annotation 主要用来记录一些非识别的信息 ， 并不用于标识和选择对象 。
2,label 主要用来标识一些有意义且和对象密切相关的信息 ， 用来支持labelSelector（标签选择器）以及一些查询操作 ， 还有选择对象 。
为了让这种抽象的对象可以跟 Pod 关联起来 ， Kubernetes 使用了labelSelector来跟 label 进行选择匹配 ， 从而达到这种松耦合的关联效果 。
$ kubectl get pod -l label1=value1,label2=value2 -n my-namespace
比如 ， 我们就可以通过上述命令 ， 查询出 my-namespace 这个命名空间下面 ， 带有标签label1=value1和label2=value2的 pod 。 label 中的键值对在匹配的时候是“且”的关系 。
ReplicationControllerKubernetes 中有一系列的工作负载可以用来部署无状态服务 。 在最初 ， Kubernetes 中使用了ReplicationController来做 Pod 的副本控制 ， 即确保该服务的 Pod 数量维持在特定的数量 。 为了简洁并便于使用 ， ReplicationController通常缩写为“rc” ， 并作为 kubectl 命令的快捷方式 ， 例如：
$ kubectl get rc -n my-namespace
如果副本数少于预定的值 ， 则创建新的 Pod 。 如果副本数大于预定的值 ， 就删除多余的副本 。 因此即使你的业务应用只需要一个 Pod ， 你也可以使用 rc 来自动帮你维护和创建 Pod 。
ReplicaSet随后社区开发了下一代的 Pod 控制器 ReplicaSet（可简写为 rs） 用来替代 ReplicaController 。 虽然 ReplicaController 目前依然可以使用 ， 但是社区已经不推荐继续使用了 。 这两者的功能和目的完全相同 ， 但是 ReplicaSet 具备更强大的基于集合的标签选择器 ， 这样你可以通过一组值来进行标签匹配选择 。 目前支持三种操作符：in、notin和exists 。
例如 ， 你可以用environment in (production, qa)来匹配 label 中带有environment=production或environment=qa的 Pod 。
同样你也可以使用tier notin (frontend,backend)来匹配 label 中不带有tier=frontend或tier=backend的 Pod 。
或者你可以用 partition来匹配 label 中带有 partition 这个 key 的 Pod 。
Deployment虽然 Replicaset 可以独立使用 ， 但是为了能够更好地协调 Pod 的创建、删除以及更新等操作 ， 我们都是直接使用更高级的 Deployment来管理 Replicaset ， 社区也是一直这么定位和推荐的 。 比如一些业务升级的场景 ， 使用单一的 ReplicaController 或者 Replicaset 是无法实现滚动升级的诉求 ， 至少需要定义两个该对象才能实现 ， 而且这两个对象使用的标签选择器中的 label 至少要有一个不相同 。 通过不断地对这两个对象的副本进行增减 ， 也可以称为调和（Reconcile） ， 才可以完成滚动升级 。 这样使用起来不方便 ， 也增加了用户的使用门槛 ， 极大地降低了业务发布的效率 。


推荐阅读


上一篇：浪子归家|HashMap源码分析

下一篇：甜腻的嘴角|美国30年前用同样的手段制裁日本东芝，看看日本妥协后的代价