如果你的服务器资源紧张，pod可能只能是单副本了，这时在进行平滑的滚动部署时，应该如何配置呢？总不能在部署期间503吧，这是不能接受的！

maxUnavailable来配置不可用数量

我们可以在spec.strategy.strategy.rollingUpdate中，将不可用数maxUnavailable改成0即可实现平滑部署，配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: keycloak-deployment
  namespace: kc
spec:
  replicas: 1
  #滚动升级策略
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0 #当副本为1时，我们采用这个配置，即不允许有多余的pod

如果是多个副本，你也可以通过rollingUpdate中的maxSurge来控制可用节点数，maxUnavailable来控制不可用数，如下面的配置，在副本为3个时，可用数至少为1个，不可用也是0个，相当于1个1个的副本去启动，整个deployment对外始终是3个可用的pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: keycloak-deployment
  namespace: kc
spec:
  replicas: 3
  #滚动升级策略
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

部署过程如图，1个副本时，在发布期间，也始终有1个是可用的

k8s如何探测pod启动了

readinessProbe 是 Kubernetes 中用来检查容器是否准备好接收流量的机制。通过配置 readinessProbe，Kubernetes 可以确保只有在容器完全就绪并能够处理请求时才会将流量引导到该容器。以下是关于 readinessProbe 的总结：

作用：readinessProbe 用于确定容器是否已经准备好接收流量。如果容器的 readinessProbe 失败，Kubernetes 将不会将流量路由到该容器。
配置方式：readinessProbe 可以通过 HTTP、TCP 或执行命令的方式进行配置。你可以指定一个 HTTP 请求路径、端口号或自定义命令，并设置相应的超时时间和周期。
成功条件：readinessProbe 根据配置的方式来判断容器的就绪状态。例如，对于 HTTP 探测，返回状态码在200-399之间表示成功；对于 TCP 探测，连接成功即为成功；对于执行命令探测，返回值为0表示成功。
失败处理：当 readinessProbe 失败时，Kubernetes 不会将流量路由到该容器。容器可能会被标记为 Unready 状态，并从 Service 的负载均衡中剔除。
重试策略：如果 readinessProbe 失败，Kubernetes 将按照配置的间隔时间进行重试。只有当连续多次探测失败后，容器才会被认定为不可用。
应用场景：适用于需要一段时间来启动服务或加载数据的应用程序，以确保在容器完全就绪之前不接收流量。

常见配置：示例配置如下，包括 HTTP 探测、TCP 探测和执行命令探测：

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

通过合理配置 readinessProbe，可以提高容器的稳定性和可靠性，确保应用程序在容器就绪后再接收流量，避免因为服务未完全启动而导致的请求失败。希望这个总结对你有所帮助。如果还有其他问题，请随时告诉我。