kubernets/kubernetes-MD/kubernetes工作负载资源StatefulSet.md

9.7 KiB
Raw Blame History

kubernetes工作负载资源StatefulSet


StatefulSet

StatefulSet 是用来管理有状态应用的工作负载 API 对象StatefulSet 用来管理某 Pod 集合的部署和扩缩, 并为这些 Pod 提供持久存储和持久标识符;和 Deployment 类似, StatefulSet 管理基于相同容器规约的一组 Pod。但不同的是 StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的, 但是不能相互替换:无论怎么调度,每个 Pod 都有一个永久不变的 ID。

使用存储卷为工作负载提供持久存储,可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障, 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。

1.特点

StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值:

稳定的、唯一的网络标识符

稳定的、持久的存储

有序的、优雅的部署和缩放

有序的、自动的滚动更新

稳定的意味着 Pod 调度或重调度的整个过程是有持久性的。 如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩,则应该使用 由一组无状态的副本控制器提供的工作负载来部署应用程序比如Deployment或者ReplicaSet 可能更适用于你的无状态应用部署需要。

2.限制

给定 Pod 的存储必须由 PersistentVolume 驱动 基于所请求的 storage class 来提供,或者由管理员预先提供

删除或者收缩 StatefulSet 并不会删除它关联的存储卷。 这样做是为了保证数据安全

StatefulSet 当前需要无头服务来负责 Pod 的网络标识。你需要负责创建此服务

当删除 StatefulSets 时StatefulSet 不提供任何终止 Pod 的保证

为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止,可以在删除之前将 StatefulSet 缩放为 0

注意:

无头服务Headless Services

有时不需要或不想要负载均衡,以及单独的 Service IP。 遇到这种情况,可以通过指定 Cluster IPspec.clusterIP)的值为 "None" 来创建 Headless Service。

使用无头 Service 与其他服务发现机制进行接口,而不必与 Kubernetes 的实现捆绑在一起

无头 Service 并不会分配 Cluster IPkube-proxy 不会处理它们, 而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置,依赖于 Service 是否定义了选择算符。

3.创建StatefulSet

[root@master xingdian]# cat Statefulset.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    name: web
    targetPort: 80
    nodePort: 30010
  selector:
    app: nginx
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: xingdian
provisioner: example.com/external-nfs
parameters:
  server: 10.0.0.230
  path: /kubernetes-1
  readOnly: "false"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: xingdian-1
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: xingdian
  nfs:
    path: /kubernetes-1
    server: 10.0.0.230
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: xingdian-2
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: xingdian
  nfs:
    path: /kubernetes-1
    server: 10.0.0.230
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx:1.20.1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "xingdian"
      resources:
        requests:
          storage: 1Gi

名为 nginx 的 Headless Service 用来控制网络域名

名为 web 的 StatefulSet 有一个 Spec它表明将在独立的2个 Pod 副本中启动 nginx 容器

volumeClaimTemplates 将通过 PersistentVolumes 驱动提供的 PersistentVolumes 来提供稳定的存储

4.Pod 选择算符

你必须设置 StatefulSet 的 .spec.selector 字段,使之匹配其在 .spec.template.metadata.labels 中设置的标签。在 Kubernetes 1.8 版本之前, 被忽略 .spec.selector 字段会获得默认设置值。 在 1.8 和以后的版本中,未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。

5.Pod 标识

StatefulSet Pod 具有唯一的标识,该标识包括顺序标识、稳定的网络标识和稳定的存储。 该标识和 Pod 是绑定的,不管它被调度在哪个节点上。

6.有序索引

对于具有 N 个副本的 StatefulSetStatefulSet 中的每个 Pod 将被分配一个整数序号, 从 0 到 N-1该序号在 StatefulSet 上是唯一的。

7.稳定的网络 ID

StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。 组合主机名的格式为$(StatefulSet 名称)-$(序号)。 上例将会创建三个名称分别为 web-0、web-1、web-2 的 Pod。

StatefulSet 可以使用无头服务 控制它的 Pod 的网络域。管理域的这个服务的格式为: $(服务名称).$(命名空间).svc.cluster.local,其中 cluster.local 是集群域。 一旦每个 Pod 创建成功,就会得到一个匹配的 DNS 子域,格式为: $(pod 名称).$(所属服务的 DNS 域名),其中所属服务由 StatefulSet 的 serviceName 域来设定。

$(pod name).$(service name).$(namespace).svc.cluster.local

取决于集群域内部 DNS 的配置,有可能无法查询一个刚刚启动的 Pod 的 DNS 命名。 当集群内其他客户端在 Pod 创建完成前发出 Pod 主机名查询时,就会发生这种情况。 负缓存 (在 DNS 中较为常见) 意味着之前失败的查询结果会被记录和重用至少若干秒钟, 即使 Pod 已经正常运行了也是如此。

如果需要在 Pod 被创建之后及时发现它们,有以下选项:

直接查询 Kubernetes API比如利用 watch 机制)而不是依赖于 DNS 查询

缩短 Kubernetes DNS 驱动的缓存时长(通常这意味着修改 CoreDNS 的 ConfigMap目前缓存时长为 30 秒)

集群域名 服务(名字空间/名字) StatefulSet名字空间/名字) StatefulSet 域名 Pod DNS Pod 主机名
cluster.local default/nginx default/web nginx.default.svc.cluster.local web-{0..N-1}.nginx.default.svc.cluster.local web-{0..N-1}
cluster.local foo/nginx foo/web nginx.foo.svc.cluster.local web-{0..N-1}.nginx.foo.svc.cluster.local web-{0..N-1}
kube.local foo/nginx foo/web nginx.foo.svc.kube.local web-{0..N-1}.nginx.foo.svc.kube.local web-{0..N-1}

8.稳定的存储

对于 StatefulSet 中定义的每个 VolumeClaimTemplate每个 Pod 接收到一个 PersistentVolumeClaim。在上面的 nginx 示例中,每个 Pod 将会得到基于 StorageClass my-storage-class 提供的 1 Gib 的 PersistentVolume。 如果没有声明 StorageClass就会使用默认的 StorageClass。 当一个 Pod 被调度(重新调度)到节点上时,它的 volumeMounts 会挂载与其 PersistentVolumeClaims 相关联的 PersistentVolume。 请注意,当 Pod 或者 StatefulSet 被删除时,与 PersistentVolumeClaims 相关联的 PersistentVolume 并不会被删除。要删除它必须通过手动方式来完成。

9.部署和扩缩保证

对于包含 N 个 副本的 StatefulSet当部署 Pod 时,它们是依次创建的,顺序为 0..N-1

当删除 Pod 时,它们是逆序终止的,顺序为 N-1..0

在将缩放操作应用到 Pod 之前,它前面的所有 Pod 必须是 Running 和 Ready 状态

在 Pod 终止之前,所有的继任者必须完全关闭

注意:

StatefulSet 不应将 pod.Spec.TerminationGracePeriodSeconds 设置为 0;参数指定Kubernetes在强制终止pod之前等待pod正常终止的时间。 这种做法是不安全的,要强烈阻止。

在上面的 nginx 示例被创建后,会按照 web-0、web-1 的顺序部署2个 Pod。 在 web-0 进入Running 和 Ready状态前不会部署 web-1。要等到 web-0 部署完成并进入 Running 和 Ready 状态后,才会部署 web-1。

如果用户想将示例中的 StatefulSet 收缩为 replicas=1,首先被终止的是 web-1。 在 web-1没有被完全停止和删除前如果在此期间发生 web-0 运行失败, 那么就不会终止 web-1必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。