官方地址: https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/
StatefulSet 是用来管理有状态应用
的工作负载 API 对象。
无状态应用: 应用本身不存储任何数据的应用称之为无状态应用。
有状态应用: 应用本身需要存储相关数据应用称之为有状态应用。
博客: 前端vue 后端 java mysql redis es ....
数据采集: 采集程序 有状态应用
StatefulSet 用来管理某 Pod 集合的部署和扩缩, 并为这些 Pod 提供持久存储和持久标识符。
和 Deployment 类似, StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是, StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的, 但是不能相互替换:无论怎么调度,每个 Pod 都有一个永久不变的 ID。
如果希望使用存储卷为工作负载提供持久存储,可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障, 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。
StatefulSet 对于需要满足以下一个或多个需求的应用程序很有价值:
在上面描述中,“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。 如果应用程序不需要任何稳定的标识符或有序的部署、删除或扩缩, 则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序,比如 Deployment或者 ReplicaSet 可能更适用于你的无状态应用部署需要。
官网: http://kubernetes.p2hp.com/docs/concepts/architecture/controller.html
Kubernetes 通常不会直接创建 Pod, 而是通过 Controller 来管理 Pod 的。
Controller 中定义了 Pod 的部署特性,比如有几个副本、在什么样的 Node 上运行等。通俗的说可以认为 Controller 就是用来管理 Pod 一个对象。其核心作用可以通过一句话总结: 通过监控集群的公共状态,并致力于将当前状态转变为期望的状态。
通俗定义: controller 可以管理 pod 让 pod 更具有运维能力
Deployment
是最常用的 Controller。Deployment 可以管理 Pod 的多个副本,并确保 Pod 按照期望的状态运行。
Daemonset
用于每个Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的,DaemonSet 通常用于运行 daemon。
Statefuleset
能够保证 Pod 的每个副本在整个生命周期中名称是不变的,而其他Controller 不提供这个功能。当某个 Pod 发生故障需要删除并重新启动时,Pod 的名称会发生变化,同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
Job
用于运行结束就删除的应用,而其他 Controller 中的 Pod 通常是长期持续运行。
你可以约束一个 Pod 以便 限制 其只能在特定的节点上运行, 或优先在特定的节点上运行。 有几种方法可以实现这点,推荐的方法都是用 标签选择算符来进行选择。 通常这样的约束不是必须的,因为调度器将自动进行合理的放置(比如,将 Pod 分散到节点上, 而不是将 Pod 放置在可用资源不足的节点上等等)。但在某些情况下,你可能需要进一步控制 Pod 被部署到哪个节点。例如,确保 Pod 最终落在连接了 SSD 的机器上, 或者将来自两个不同的服务且有大量通信的 Pods 被放置在同一个可用区。
你可以使用下列方法中的任何一种来选择 Kubernetes 对特定 Pod 的调度:
定义: 使用节点亲和性可以把 Kubernetes Pod 分配到特定节点。
Init 容器是一种特殊容器,在Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。
init 容器与普通的容器非常像,除了如下几点:
restartPolicy
值为 "Never",并且 Pod 的 Init 容器失败, 则 Kubernetes 会将整个 Pod 状态设置为失败。lifecycle
、livenessProbe
、readinessProbe
和 startupProbe
, 因为它们必须在 Pod 就绪之前运行完成。在 Pod 的规约中与用来描述应用容器的 containers
数组平行的位置指定 Init 容器。
ymlapiVersion: v1
kind: Pod
metadata:
name: init-demo
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'echo init-myservice is running! && sleep 5']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'echo init-mydb is running! && sleep 10']
在k8s中对于容器资源限制主要分为以下两类:
请求 request memory cpu :可以使用的基础资源 100M
限制 limit memory cpu :可以使用的最大资源 200M 超过最大资源之后容器会被 kill , OOM 错误
Kubernetes Metrics Server (Kubernetes指标服务器),它是一个可扩展的、高效的容器资源度量源。Metrics Server 用于监控每个 Node 和 Pod 的负载(用于Kubernetes内置自动扩缩管道)。Metrics Server 从Kubelets 收集资源指标,并通过 Metrics API 在Kubernetes apiserver中公开,供 Horizontal Pod Autoscaler 和 Vertical Pod Autoscaler 使用。Metrics API 也可以通过 kubectl top 访问,使其更容易调试自动扩缩管道。
metrics.k8s.io
服务提供者)是否正在运行, 请键入以下命令:shellkubectl get apiservices
metrics.k8s.io
的引用。NAME v1beta1.metrics.k8s.io