《重识云原生系列》专题索引：

第一章——不谋全局不足以谋一域
第二章计算第1节——计算虚拟化技术总述
第二章计算第2节——主流虚拟化技术之VMare ESXi
第二章计算第3节——主流虚拟化技术之Xen
第二章计算第4节——主流虚拟化技术之KVM
第二章计算第5节——商用云主机方案
第二章计算第6节——裸金属方案
第三章云存储第1节——分布式云存储总述
第三章云存储第2节——SPDK方案综述
第三章云存储第3节——Ceph统一存储方案
第三章云存储第4节——OpenStack Swift 对象存储方案
第三章云存储第5节——商用分布式云存储方案
第四章云网络第一节——云网络技术发展简述
第四章云网络4.2节——相关基础知识准备
第四章云网络4.3节——重要网络协议
第四章云网络4.3.1节——路由技术简述
第四章云网络4.3.2节——VLAN技术
第四章云网络4.3.3节——RIP协议
第四章云网络4.3.4节——OSPF协议
第四章云网络4.3.5节——EIGRP协议
第四章云网络4.3.6节——IS-IS协议
第四章云网络4.3.7节——BGP协议
第四章云网络4.3.7.2节——BGP协议概述
第四章云网络4.3.7.3节——BGP协议实现原理
第四章云网络4.3.7.4节——高级特性
第四章云网络4.3.7.5节——实操
第四章云网络4.3.7.6节——MP-BGP协议
第四章云网络4.3.8节——策略路由
第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
第四章云网络4.3.10节——VXLAN技术
第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
第四章云网络4.3.10.3节——VXLAN隧道机制
第四章云网络4.3.10.4节——VXLAN报文转发过程
第四章云网络4.3.10.5节——VXlan组网架构
第四章云网络4.3.10.6节——VXLAN应用部署方案
第四章云网络4.4节——Spine-Leaf网络架构
第四章云网络4.5节——大二层网络
第四章云网络4.6节——Underlay 和 Overlay概念
第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
第四章云网络4.7.2节——virtio网络半虚拟化简介
第四章云网络4.7.3节——Vhost-net方案
第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
第四章云网络4.7.6节——virtio-blk存储虚拟化方案
第四章云网络4.7.8节——SR-IOV方案
第四章云网络4.7.9节——NFV
第四章云网络4.8.1节——SDN总述
第四章云网络4.8.2.1节——OpenFlow概述
第四章云网络4.8.2.2节——OpenFlow协议详解
第四章云网络4.8.2.3节——OpenFlow运行机制
第四章云网络4.8.3.1节——Open vSwitch简介
第四章云网络4.8.3.2节——Open vSwitch工作原理详解
第四章云网络4.8.4节——OpenStack与SDN的集成
第四章云网络4.8.5节——OpenDayLight
第四章云网络4.8.6节——Dragonflow
第四章云网络4.9.1节——网络卸载加速技术综述
第四章云网络4.9.2节——传统网络卸载技术
第四章云网络4.9.3.1节——DPDK技术综述
第四章云网络4.9.3.2节——DPDK原理详解
第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述
第四章云网络4.9.4.2节——智能网卡实现
第六章容器6.1.1节——容器综述
第六章容器6.1.2节——容器安装部署
第六章容器6.1.3节——Docker常用命令
第六章容器6.1.4节——Docker核心技术LXC
第六章容器6.1.5节——Docker核心技术Namespace
第六章容器6.1.6节—— Docker核心技术Chroot
第六章容器6.1.7.1节——Docker核心技术cgroups综述
第六章容器6.1.7.2节——cgroups原理剖析
第六章容器6.1.7.3节——cgroups数据结构剖析
第六章容器6.1.7.4节——cgroups使用
第六章容器6.1.8节——Docker核心技术UnionFS
第六章容器6.1.9节——Docker镜像技术剖析
第六章容器6.1.10节——DockerFile解析
第六章容器6.1.11节——docker-compose容器编排
第六章容器6.1.12节——Docker网络模型设计
第六章容器6.2.1节——Kubernetes概述
第六章容器6.2.2节——K8S架构剖析
第六章容器6.3.1节——K8S核心组件总述
第六章容器6.3.2节——API Server组件
第六章容器6.3.3节——Kube-Scheduler使用篇
第六章容器6.3.4节——etcd组件
第六章容器6.3.5节——Controller Manager概述
第六章容器6.3.6节——kubelet组件
第六章容器6.3.7节——命令行工具kubectl
第六章容器6.3.8节——kube-proxy
第六章容器6.4.1节——K8S资源对象总览
第六章容器6.4.2.1节——pod详解
第六章容器6.4.2.2节——Pod使用(上)
第六章容器6.4.2.3节——Pod使用(下)
第六章容器6.4.3节——ReplicationController
第六章容器6.4.4节——ReplicaSet组件
第六章容器基础6.4.5.1节——Deployment概述
第六章容器基础6.4.5.2节——Deployment配置详细说明
第六章容器基础6.4.5.3节——Deployment实现原理解析
第六章容器基础6.4.6节——Daemonset
第六章容器基础6.4.7节——Job
第六章容器基础6.4.8节——CronJob

1 StatefulSet概述

1.1 StatefulSet作用

StatefulSet 是用来管理有状态应用的工作负载 API 对象。

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

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

1.2 statefulset和deployment的区别

1.3 使用场景

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

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

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

1.4 限制

给定 Pod 的存储必须由 PersistentVolume Provisioner 基于所请求的 storage class 来制备，或者由管理员预先制备。
删除或者扩缩 StatefulSet 并不会删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
StatefulSet 当前需要无头服务来负责 Pod 的网络标识。你需要负责创建此服务。
当删除一个 StatefulSet 时，该 StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序且体面地终止，可以在删除之前将 StatefulSet 缩容到 0。
在默认 Pod 管理策略(OrderedReady) 时使用滚动更新，可能进入需要人工干预才能修复的损坏状态。

2 StatefulSet使用

2.1 yaml使用示例

下面的示例演示了 StatefulSet 的组件。

apiVersion: v1
kind: Service
metadata: name: nginx labels: app: nginx
spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx ---
apiVersion: apps/v1
kind: StatefulSet
metadata: name: web
spec: selector: matchLabels: app: nginx # 必须匹配 .spec.template.metadata.labels serviceName: "nginx" replicas: 3 # 默认值是 1 minReadySeconds: 10 # 默认值是 0
template: metadata: labels: app: nginx # 必须匹配 .spec.selector.matchLabels spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html
volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "my-storage-class" resources: requests: storage: 1Gi

上述例子中：

名为 nginx 的 Headless Service 用来控制网络域名。
名为 web 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
volumeClaimTemplates 将通过 PersistentVolume 制备程序所准备的 PersistentVolumes 来提供稳定的存储。

StatefulSet 的命名需要遵循 DNS 子域名规范。

2.2 关键字段说明

2.2.1 Pod 选择算符

你必须设置 StatefulSet 的 .spec.selector 字段，使之匹配其在 .spec.template.metadata.labels 中设置的标签。未指定匹配的 Pod 选择算符将在创建 StatefulSet 期间导致验证错误。

2.2.2 卷申领模板

你可以设置 .spec.volumeClaimTemplates，它可以使用 PersistentVolume 制备程序所准备的 PersistentVolumes 来提供稳定的存储。

2.2.3 最短就绪秒数特性状态：

Kubernetes v1.25 [stable]

.spec.minReadySeconds 是一个可选字段。它指定新创建的 Pod 应该在没有任何容器崩溃的情况下运行并准备就绪，才能被认为是可用的。这用于在使用滚动更新策略时检查滚动的进度。该字段默认为 0（Pod 准备就绪后将被视为可用）。要了解有关何时认为 Pod 准备就绪的更多信息，请参阅容器探针。

2.3 Pod 标识

StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，与该 Pod 调度到哪个节点上无关。

2.3.1 有序索引

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

2.3.2 稳定的网络 ID

StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。组合主机名的格式为$(StatefulSet 名称)-$(序号)。上例将会创建三个名称分别为 web-0、web-1、web-2 的 Pod。 StatefulSet 可以使用 Headless Service控制它的 Pod 的网络域。管理域的这个服务的格式为： $(服务名称).$(名字空间).svc.cluster.local，其中 cluster.local 是集群域。一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为： $(pod 名称).$(所属服务的 DNS 域名)，其中所属服务由 StatefulSet 的 serviceName 域来设定。

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

如果需要在 Pod 被创建之后及时发现它们，可使用以下选项：

直接查询 Kubernetes API（比如，利用 watch 机制）而不是依赖于 DNS 查询
缩短 Kubernetes DNS 驱动的缓存时长（通常这意味着修改 CoreDNS 的 ConfigMap，目前缓存时长为 30 秒）

正如限制中所述，你需要负责创建 Headless Service以便为 Pod 提供网络标识。

下面给出一些选择集群域、服务名、StatefulSet 名、及其怎样影响 StatefulSet 的 Pod 上的 DNS 名称的示例：

集群域名	服务（名字空间/名字）	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}

说明：集群域会被设置为cluster.local，除非有其他配置。

2.3.3 稳定的存储

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

2.3.4 Pod 名称标签

当 StatefulSet 控制器（Controller）创建 Pod 时，它会添加一个标签 statefulset.kubernetes.io/pod-name，该标签值设置为 Pod 名称。这个标签允许你给 StatefulSet 中的特定 Pod 绑定一个 Service。

2.4 部署和扩缩保证

对于包含 N 个副本的 StatefulSet，当部署 Pod 时，它们是依次创建的，顺序为 0..N-1。
当删除 Pod 时，它们是逆序终止的，顺序为 N-1..0。
在将扩缩操作应用到 Pod 之前，它前面的所有 Pod 必须是 Running 和 Ready 状态。
在一个 Pod 终止之前，所有的继任者必须完全关闭。

StatefulSet 不应将 pod.Spec.TerminationGracePeriodSeconds 设置为 0。这种做法是不安全的，要强烈阻止。更多的解释请参考强制删除 StatefulSet Pod。

在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。在 web-0 进入 Running 和 Ready 状态前不会部署 web-1。在 web-1 进入 Running 和 Ready 状态前不会部署 web-2。如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了 web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和 Ready 状态后，才会部署 web-2。

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

2.4.1 Pod 管理策略

StatefulSet 允许你放宽其排序保证，同时通过它的 .spec.podManagementPolicy 域保持其唯一性和身份保证。

2.4.2 OrderedReady Pod 管理

OrderedReady Pod 管理是 StatefulSet 的默认设置。它实现了上面描述的功能。

2.4.3 并行 Pod 管理

Parallel Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod，启动或者终止其他 Pod 前，无需等待 Pod 进入 Running 和 ready 或者完全停止状态。这个选项只会影响扩缩操作的行为，更新则不会被影响。

2.5 更新策略

StatefulSet 的 .spec.updateStrategy 字段让你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。有两个允许的值：

OnDelete

当 StatefulSet 的 .spec.updateStrategy.type 设置为 OnDelete 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 .spec.template 的变动作出反应。

RollingUpdate

RollingUpdate 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。这是默认的更新策略。

2.6 滚动更新

当 StatefulSet 的 .spec.updateStrategy.type 被设置为 RollingUpdate 时， StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。

Kubernetes 控制平面会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。如果你设置了 .spec.minReadySeconds（查看最短就绪秒数），控制平面在 Pod 就绪后会额外等待一定的时间再执行下一步。

2.6.1 分区滚动更新

通过声明 .spec.updateStrategy.rollingUpdate.partition 的方式，RollingUpdate 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 .spec.template 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使它们被删除也会依据之前的版本进行重建。如果 StatefulSet的 .spec.updateStrategy.rollingUpdate.partition 大于它的 .spec.replicas，则对它的 .spec.template 的更新将不会传递到它的 Pod。在大多数情况下，你不需要使用分区，但如果你希望进行阶段更新、执行金丝雀或执行分阶段上线，则这些分区会非常有用。

2.6.2 最大不可用 Pod特性状态：

你可以通过指定 .spec.updateStrategy.rollingUpdate.maxUnavailable 字段来控制更新期间不可用的 Pod 的最大数量。该值可以是绝对值（例如，“5”）或者是期望 Pod 个数的百分比（例如，10%）。绝对值是根据百分比值四舍五入计算的。该字段不能为 0。默认设置为 1。

该字段适用于 0 到 replicas - 1 范围内的所有 Pod。如果在 0 到 replicas - 1 范围内存在不可用 Pod，这类 Pod 将被计入 maxUnavailable 值。

说明：maxUnavailable字段处于Alpha阶段，仅当API服务器启用了MaxUnavailableStatefulSet特性门控时才起作用。

2.6.3 强制回滚

在默认 Pod 管理策略(OrderedReady) 下使用滚动更新，可能进入需要人工干预才能修复的损坏状态。

如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。

在这种状态下，仅将 Pod 模板还原为正确的配置是不够的。由于已知问题，StatefulSet 将继续等待损坏状态的 Pod 准备就绪（永远不会发生），然后再尝试将其恢复为正常工作配置。

恢复模板后，还必须删除 StatefulSet 尝试使用错误的配置来运行的 Pod。这样， StatefulSet 才会开始使用被还原的模板来重新创建 Pod。

2.7 PersistentVolumeClaim 保留特性状态：

在 StatefulSet 的生命周期中，可选字段 .spec.persistentVolumeClaimRetentionPolicy 控制是否删除以及如何删除 PVC。使用该字段，你必须启用 StatefulSetAutoDeletePVC 特性门控。启用后，你可以为每个 StatefulSet 配置两个策略：

whenDeleted

配置删除 StatefulSet 时应用的卷保留行为。

whenScaled

配置当 StatefulSet 的副本数减少时应用的卷保留行为；例如，缩小集合时。

对于你可以配置的每个策略，你可以将值设置为 Delete 或 Retain。

Delete

对于受策略影响的每个 Pod，基于 StatefulSet 的 volumeClaimTemplate 字段创建的 PVC 都会被删除。使用 whenDeleted 策略，所有来自 volumeClaimTemplate 的 PVC 在其 Pod 被删除后都会被删除。使用 whenScaled 策略，只有与被缩减的 Pod 副本对应的 PVC 在其 Pod 被删除后才会被删除。

Retain（默认）

来自 volumeClaimTemplate 的 PVC 在 Pod 被删除时不受影响。这是此新功能之前的行为。

请记住，这些策略仅适用于由于 StatefulSet 被删除或被缩小而被删除的 Pod。例如，如果与 StatefulSet 关联的 Pod 由于节点故障而失败，并且控制平面创建了替换 Pod，则 StatefulSet 保留现有的 PVC。现有卷不受影响，集群会将其附加到新 Pod 即将启动的节点上。

策略的默认值为 Retain，与此新功能之前的 StatefulSet 行为相匹配。

这是一个示例策略。

apiVersion: apps/v1
kind: StatefulSet
...
spec: persistentVolumeClaimRetentionPolicy: whenDeleted: Retain whenScaled: Delete
...

StatefulSet 控制器为其 PVC 添加了属主引用，这些 PVC 在 Pod 终止后被垃圾回收器删除。这使 Pod 能够在删除 PVC 之前（以及在删除后备 PV 和卷之前，取决于保留策略）干净地卸载所有卷。当你设置 whenDeleted 删除策略，对 StatefulSet 实例的属主引用放置在与该 StatefulSet 关联的所有 PVC 上。

whenScaled 策略必须仅在 Pod 缩减时删除 PVC，而不是在 Pod 因其他原因被删除时删除。执行协调操作时，StatefulSet 控制器将其所需的副本数与集群上实际存在的 Pod 进行比较。对于 StatefulSet 中的所有 Pod 而言，如果其 ID 大于副本数，则将被废弃并标记为需要删除。如果 whenScaled 策略是 Delete，则在删除 Pod 之前，首先将已销毁的 Pod 设置为与 StatefulSet 模板对应的 PVC 的属主。这会导致 PVC 仅在已废弃的 Pod 终止后被垃圾收集。

这意味着如果控制器崩溃并重新启动，在其属主引用更新到适合策略的 Pod 之前，不会删除任何 Pod。如果在控制器关闭时强制删除了已废弃的 Pod，则属主引用可能已被设置，也可能未被设置，具体取决于控制器何时崩溃。更新属主引用可能需要几个协调循环，因此一些已废弃的 Pod 可能已经被设置了属主引用，而其他可能没有。出于这个原因，我们建议等待控制器恢复，控制器将在终止 Pod 之前验证属主引用。如果这不可行，则操作员应验证 PVC 上的属主引用，以确保在强制删除 Pod 时删除预期的对象。

2.8 副本数

.spec.replicas 是一个可选字段，用于指定所需 Pod 的数量。它的默认值为 1。

如果你手动扩缩已部署的负载，例如通过 kubectl scale statefulset statefulset --replicas=X，然后根据清单更新 StatefulSet（例如：通过运行 kubectl apply -f statefulset.yaml），那么应用该清单的操作会覆盖你之前所做的手动扩缩。

如果 HorizontalPodAutoscaler （或任何类似的水平扩缩 API）正在管理 StatefulSet 的扩缩，请不要设置 .spec.replicas。相反，允许 Kubernetes 控制平面自动管理 .spec.replicas 字段。

参考链接

StatefulSet | Kubernetes

StatefulSet · Kubernetes指南

K8S之statefuleSet

StatefulSet 基础 | Kubernetes

示例：使用 StatefulSet 部署 Cassandra | Kubernetes

Statefulset详细解析 - 不懂123 - 博客园

k8s中statefulset资源类型的深入理解

十，StatefulSet简介及简单使用 - 戴红领巾的少年 - 博客园

k8s之StatefulSet详解_最美dee时光的博客-CSDN博客_statefulset

Kubernetes学习笔记 —— 7. StatefulSet - 知乎

容器化部署实战（五）｜控制器 StatefulSet 的原理

K8s StatefulSet

【重识云原生】第六章容器基础6.4.10.1节——StatefulSet概述相关推荐

【重识云原生】第六章容器基础6.4.5.1节——Deployment概述
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域第二章计算第1节--计算虚拟化技术总述第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
【重识云原生】第六章容器基础6.4.9.2节——使用 Service 连接到应用
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域第二章计算第1节--计算虚拟化技术总述第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
【重识云原生】第一章——不谋全局不足以谋一域
云原生体系知识地图大纲: 锲子云原生概念这几年非常火爆,本人因有幸参与公司云原生转型项目调研,开始接触这一庞大技术体系,再通过与同业.各大头部云厂商超过150场的密集研讨交流,方得初窥全貌.同时 ...
【重识云原生】第二章计算第一节——计算虚拟化技术总述
云平台计算领域知识地图: 楔子:计算虚拟化技术算是云计算技术的擎天之柱,其前两代技术的演进一直引领着云计算的发展,即便到了云原生时代,其作用依然举足轻重. 一.计算虚拟化技术总述 1.1 虚拟化技 ...
【重识云原生】第六章容器基础6.4.7.1节——K8S Job组件
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域第二章计算第1节--计算虚拟化技术总述第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
【重识云原生】第六章容器基础6.4.5.2节——Deployment配置详细说明
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域第二章计算第1节--计算虚拟化技术总述第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
【重识云原生】第六章容器基础6.4.5.3节——Deployment实现原理解析
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域第二章计算第1节--计算虚拟化技术总述第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
【重识云原生】第六章容器基础6.4.9.6节——Service 与 Pod 的DNS
1 Service 与 Pod 的 DNS Kubernetes 为 Service 和 Pod 创建 DNS 记录. 你可以使用一致的 DNS 名称而非 IP 地址访问 Service. Kuber ...
【重识云原生】第六章容器6.3.5节——Controller Manager概述
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域第二章计算第1节--计算虚拟化技术总述第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
【重识云原生】第三章云存储3.5节——商用分布式云存储方案
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域第二章计算第1节--计算虚拟化技术总述第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...

【重识云原生】第六章容器基础6.4.10.1节——StatefulSet概述