k8s不能判断 一个的服务是否已经可用，只要pod正常启动就会判断成 可用，就导致了新的pod还没有完全启动旧pod就被停止删除，应该怎么解决

可以通过在 Kubernetes 中使用 readinessProbe 来解决这个问题。 readinessProbe 可以在 Pod 启动后检查容器是否已经准备就绪，只有当容器准备就绪时才会将该 Pod 标记为 Ready。这样，即使 Pod 已经启动，但容器还没有完全就绪，Kubernetes也不会将其视为可用的 Pod，从而防止旧 Pod 被删除。

readinessProbe 通常执行一些简单的检查，例如检查容器是否能够正确地响应 HTTP 请求，或检查容器是否能连接到需要的后端服务。如果检查失败，则 Kubernetes 将认为该 Pod 还没有准备就绪，并且将等待一段时间后再次进行检查。只有在 readinessProbe 检查成功后，Kubernetes 才会将该 Pod 标记为 Ready。

以下是一个 readinessProbe 的示例：

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

在这个示例中， readinessProbe 每 5 秒钟执行一次 HTTP GET 请求，检查容器是否能够响应 /healthz 路径，并且将在容器启动后等待 5 秒钟后开始检查。如果检查失败，则 Kubernetes 将等待另外 5 秒钟后再次进行检查。如果检查成功，则 Kubernetes 将该 Pod 标记为 Ready。

相关问题

k8s不能判断 一个的服务是否已经可用，只要pod正常启动就会判断成 可用，就导致了新的pod还没有完全启动旧pod就被停止删除，怎么处理

Kubernetes 中确实存在这样的问题，即在旧的 Pod 被删除之前，新的 Pod 可能还没有完全启动。为了解决这个问题，可以使用以下两种方法之一：

1. 使用 `rollingUpdate` 部署策略

在使用 `Deployment` 或 `StatefulSet` 部署应用程序时，可以指定 `rollingUpdate` 策略，该策略将确保新的 Pod 在完全启动之前不会替换旧的 Pod。具体来说，`rollingUpdate` 策略将确保在新的 Pod 可用之后再逐步删除旧的 Pod，以确保应用程序的可用性。

以下是一个示例配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: my-app-container
        image: my-app-image
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          timeoutSeconds: 1
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 3

在上面的示例中，`rollingUpdate` 策略将确保在新的 Pod 可用之后再逐步删除旧的 Pod。`maxUnavailable` 参数指定了同时离线的最大 Pod 数量，`maxSurge` 参数指定了同时启动的最大 Pod 数量。

2. 使用 `Readiness Probe` 确保应用程序可用

除了使用 `rollingUpdate` 部署策略之外，还可以使用 `Readiness Probe` 来确保新的 Pod 在完全启动之前不会接收流量。`Readiness Probe` 与 `Liveness Probe` 类似，但是它用于检测应用程序是否已经准备好接收流量，而不是检测应用程序是否正在运行。

以下是一个示例配置：

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      timeoutSeconds: 1
      periodSeconds: 10
      successThreshold: 1
      failureThreshold: 3

在上面的示例中，`Readiness Probe` 将确保新的 Pod 在完全启动之前不会接收流量。只有当应用程序准备好接收流量时，才会将新的 Pod 纳入到服务中。这样可以确保新的 Pod 在完全启动之前不会替换旧的 Pod。

k8s滚动更新过程中新pod还没有完全启动旧pod就被删除停止了，就会导致在新pod还没完全启动的时间里造成服务不可用，很影响使用

您说的情况是可能会发生的，如果在滚动更新期间旧 Pod 被删除了，而新 Pod 还没有完全启动，那么就会导致服务不可用。为了避免这种情况发生，可以通过增加 `spec.minReadySeconds` 参数的值来等待新 Pod 完全就绪后再停止旧 Pod。

另一种方式是使用 readiness 探针，通过在 Pod 中设置 readiness 探针，可以确保在新 Pod 完全就绪之前，该 Pod 不会接收流量，从而避免服务不可用的情况。 readiness 探针是一种用于检查容器是否已准备好接收流量的机制，可以通过发送 HTTP 请求、TCP 套接字等方式来检查容器的健康状态。只有当 readiness 探针返回成功时，Kubernetes 才会将流量发送到该容器。

下面是一个使用 readiness 探针的例子：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5

在这个例子中，我们为容器设置了一个 readiness 探针，该探针每隔 10 秒钟检查一次 `/healthz` 路径是否可用，如果探针返回成功，Kubernetes 就会将流量发送到该容器。在滚动更新期间，只有当新 Pod 的 readiness 探针返回成功后，Kubernetes 才会将流量发送到该 Pod，从而避免了服务不可用的情况。