Statefulset的拓扑状态

Statefulset:

实例之间有不对等关系,以及实例对外部数据有依赖关系的应用,就被称为“有状态应用”(Stateful Application)。

StatefulSet 的设计其实非常容易理解。它把真实世界里的应用状态,抽象为了两种情况:

拓扑状态。这种情况意味着,应用的多个实例之间不是完全对等的关系。这些应用实例,必须按照某些顺序启动,比如应用的主节点 A 要先于从节点 B 启动。而如果你把 A 和 B 两个 Pod 删除掉,它们再次被创建出来时也必须严格按照这个顺序才行。并且,新创建出来的 Pod,必须和原来 Pod 的网络标识一样,这样原先的访问者才能使用同样的方法,访问到这个新 Pod。

存储状态。这种情况意味着,应用的多个实例分别绑定了不同的存储数据。对于这些应用实例来说,Pod A 第一次读取到的数据,和隔了十分钟之后再次读取到的数据,应该是同一份,哪怕在此期间 Pod A 被重新创建过。这种情况最典型的例子,就是一个数据库应用的多个存储实例。

StatefulSet 的核心功能,就是通过某种方式记录这些状态,然后在 Pod 被重新创建时,能够为新 Pod 恢复这些状态。

Headless Service:
 
Service 是 Kubernetes 项目中用来将一组 Pod 暴露给外界访问的一种机制
 
这个 Service 又是如何被访问的呢?
 
第一种方式,是以 Service 的 VIP(Virtual IP,即:虚拟 IP)方式。比如:当我访问 10.0.23.1 这个 Service 的 IP 地址时,10.0.23.1 其实就是一个 VIP,它会把请求转发到该 Service 所代理的某一个 Pod 上。这里的具体原理,我会在后续的 Service 章节中进行详细介绍。
 
第二种方式,就是以 Service 的 DNS 方式。比如:这时候,只要我访问“my-svc.my-namespace.svc.cluster.local”这条 DNS 记录,就可以访问到名叫 my-svc 的 Service 所代理的某一个 Pod。
 
而在第二种 Service DNS 的方式下,具体还可以分为两种处理方法:
 
第一种处理方法,是 Normal Service。这种情况下,你访问“my-svc.my-namespace.svc.cluster.local”解析到的,正是 my-svc 这个 Service 的 VIP,后面的流程就跟 VIP 方式一致了
 
而第二种处理方法,正是 Headless Service。这种情况下,你访问“my-svc.my-namespace.svc.cluster.local”解析到的,直接就是 my-svc 代理的某一个 Pod 的 IP 地址。可以看到,这里的区别在于,Headless Service 不需要分配一个 VIP,而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址

下面是一个标准的 Headless Service 对应的 YAML 文件:
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
 
可以看到,所谓的 Headless Service,其实仍是一个标准 Service 的 YAML 文件。只不过,它的 clusterIP 字段的值是:None,即:这个 Service,没有一个 VIP 作为“头”。这也就是 Headless 的含义。所以,这个 Service 被创建后并不会被分配一个 VIP,而是会以 DNS 记录的方式暴露出它所代理的 Pod。


创建statefulste的yaml文件:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.1
        ports:
        - containerPort: 80
          name: web

原文地址:https://www.cnblogs.com/fuyuteng/p/10676079.html

时间: 2024-10-08 21:17:21

Statefulset的拓扑状态的相关文章

k8s的StatefulSet(有状态服务)实现

StatefulSet介绍 遇到的问题: 使用Deployment创建的Pod是无状态的,当挂在Volume之后,如果该Pod挂了,Replication Controller会再run一个来保证可用性,但是由于是无状态的,Pod挂了的时候与之前的Volume的关系就已经断开了,新起来的Pod无法找到之前的Pod.但是对于用户而言,他们对底层的Pod挂了没有感知,但是当Pod挂了之后就无法再使用之前挂载的磁盘了. StatefulSet: 是一种给Pod提供唯一标志的控制器,它可以保证部署和扩展

Kubernetes进阶之StatefulSet有状态部署

K8s有状态应用部署目录:分为两类1.Headless Service2.StatefulSet ? 部署有状态应用 ? 解决Pod独立生命周期,保持Pod启动顺序和唯一性 稳定,唯一的网络标识符,持久存储 有序,优雅的部署和扩展.删除和终止 有序,滚动更新 应用场景:数据库 说在前面的话,像我们的Mysql或者Redis了,Zookerper等等这些适不适合部署在K8s中,其实呢不是太适合,但部署在里面也可以,比如部署一个Mysql来讲吧,部署到k8s中还是很容易的就一个Mysql实例,就像部

Kubernetes 通过statefulset部署redis cluster集群

Kubernetes 通过statefulset部署redis cluster集群 作者: 张首富 时间: 2019-02-19 个人博客地址: https://www.zhangshoufu.com QQ群: 895291458 需要有redis基础 Redis集群架构图 每个Mater 都可以拥有多个slave.当Master掉线后,redis cluster集群会从多个Slave中选举出来一个新的Matser作为代替,而旧的Master重新上线后变成 Master 的Slave. 部署re

Statefulset详细解析

StatefulSet实现Pod的拓扑状态 StatefulSet的核心功能就是通过某种方式记录这些状态,然后在Pod被重新创建时能够为新Pod恢复这些状态 只要知道一个Pod的名字以及它对应的Service的名字,就可以通过这条DNS记录访问到Pod的IP地址(pod的名称.service名称) -> Pod的IP 定义Stateful的对象中有一个serviceName字段来告诉Stateful控制器使用具体的service来解析它所管理的Pod的IP地址 Pod的名称由StatfulSet

kubernetes statefulset

概述 在应用程序中我们有两类,一种是有状态一种是无状态.此前一直演示的是deployment管理的应用,比如nginx或者我们自己定义的myapp它们都属于无状态应用. 而对于有状态应用,比如redis,mysql,还有etcd,还有zookeeper等等需要存数据的都属于有状态.它们不光有所谓的节点之分,每一个对应的pod还有角色之分,有的是主节点,有的是从节点.而后,从节点不光有所谓的从之分可能还有先后次序之分,我们不同的分布式系统它们的运维管理,逻辑和运维操作过程是不相同的,因此没有办法把

k8s之StatefulSet

StatefulSet(状态集) 1,什么是StatefulSet ?StatefulSet又叫PetSet(之前的名称),它和RS,RC,Deployment等一样,都是pod控制器.StatefulSet是为了解决有状态服务的问题(对应于deoloyment和RS,RC,ReplicaSet都是为无状态服务而设计的). 什么是无状态服务?在生产环境中,pod的名称是随机的,扩缩容的是时候没有规律,每一个pod都可以被新生成的pod代替. 2,StatefulSet的应用场景包括: 稳定的持久

亲历者说:Kubernetes API 与 Operator,不为人知的开发者战争

如果我问你,如何把一个 etcd 集群部署在 Google Cloud 或者阿里云上,你一定会不假思索的给出答案:当然是用 etcd Operator! 实际上,几乎在一夜之间,Kubernetes Operator 这个新生事物,就成了开发和部署分布式应用的一项事实标准.时至今日,无论是 etcd.TiDB.Redis,还是 Kafka.RocketMQ.Spark.TensorFlow,几乎每一个你能叫上名字来的分布式项目,都由官方维护着各自的 Kubernetes Operator.而 O

kubernetes 实现redis-statefulset集群

Kubernetes 通过statefulset部署redis cluster集群 部署redis集群方式的选择 Statefulset Service&depolyment 对于redis,mysql这种有状态的服务,我们使用statefulset方式为首选.我们这边主要就是介绍statefulset这种方式 ps: statefulset 的设计原理模型: 拓扑状态.应用的多个实例之间不是完全对等的关系,这个应用实例的启动必须按照某些顺序启动,比如应用的 主节点 A 要先于从节点 B 启动.

网桥的自学习算法原理

网桥:在数据链路层可以用网桥设备来扩展以太网.网桥工作在数据链路层,它根据MAC 帧的目的地址对收到的帧进行存储转发和过滤.当网桥收到一个数据帧时,并不是向所有的接口转发这个数据帧,而是会进行有条件的转发(网桥会丢弃CRC检验有差错的帧以及帧长过短和过长的无效帧)再根据此帧的目的MAC地址,然后查找转发表(网桥会自己维护转发表,转发表中每一条目都记录了到达某个目的MAC地址的数据帧可以从那个接口进行转发)根据转发表中的条目逐步匹配看该从那个接口转发或是否需要丢弃该数据帧.最简单的网桥只有两个接口