发生了什么？
使用 podManagementPolicy: Parallel 和 minReadySeconds: 15 部署了一个有状态集(statefulset),并等待所有 pods 就绪。然后，对 sts 发起了滚动重启操作。
你期望会发生什么？
期望滚动更新的过程与 podManagementPolicy: OrderedReady 相同，即最后一个 pod 被终止，然后重启，等待就绪，再等待额外的 minReadySeconds 通过，然后移动到下一个 pod。然而，一旦 pod 就绪，滚动更新过程立即移动到下一个 pod,忽略了 minReadySeconds 设置。
我们如何尽可能最小精确地重现它？
应用以下 sts:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  minReadySeconds: 10
  podManagementPolicy: Parallel
  replicas: 5
  selector:
    matchLabels:
      application: web
  serviceName: web
  template:
    metadata:
      labels:
        application: web
    spec:
      containers:
      - image: nginx
        name: web
  updateStrategy:
    type: RollingUpdate

等待所有 pod 就绪。然后，发起滚动重启操作：

$ kubectl rollout restart sts web

然后观察到，一旦一个 pod 进入就绪状态，升级过程就会移动到下一个 pod,忽略 minReadySeconds 值。
如果 sts 是使用默认的 podManagementPolicy 创建的，更新过程将按预期工作。
我们需要了解其他什么信息吗？

• 无响应*

Kubernetes 版本：

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.3", GitCommit:"25b4e43193bcda6c7328a6d147b1fb73a33f1598", GitTreeState:"clean", BuildDate:"2023-06-14T09:53:42Z", GoVersion:"go1.20.5", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.3", GitCommit:"25b4e43193bcda6c7328a6d147b1fb73a33f1598", GitTreeState:"clean", BuildDate:"2023-06-15T00:36:28Z", GoVersion:"go1.20.5", Compiler:"gc", Platform:"linux/amd64"}

云提供商：
OS 版本：

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$ uname -a
Linux k-desktop 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux

安装工具：
kind
容器运行时(CRI)和版本(如适用)
相关插件(CNI、CSI 等)和版本(如适用)