在Kubernetes中，处于``不健康''状态的具有``准备就绪检查''的Pod是否无法从其他Pod变为就绪状态而解决？

Question

我已经将虚拟服务定义为在DNS中注册Pod的一种方法，因为群集IP目前不适用于我的应用程序。

apiVersion: v1
kind: Service
metadata:
  name: company
spec:
  selector:
    app: company_application
  clusterIP: None

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: company-master-deployment
  labels:
    app: company_application
    role: master
spec:
  selector:
    matchLabels:
      app: company_application
      role: master
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: company_application
        role: master
    spec:
      hostname: master
      subdomain: company

我正在使用master.company.default.svc.cluster.local的DNS条目从另一个Pod连接到该Pod。

在以下情况下，我注意到Kubernetes的行为非常烦人：

• 我有一个ReadinessCheck定义为“不健康”的豆荚
• 我有另一个Pod，其应用程序希望在该Pod上进行DNS查找
• DNS查找失败，直到“不健康”的容器变得健康为止。

Kubernetes应该是这样工作的吗？除了删除准备情况检查以外，还有什么方法可以确保DNS继续解析？

Answer 1

是的，只有在Pod通过就绪检查之前，它们才会添加到服务端点。您可以通过运行以下命令来确认这一点：

kubectl get endpoints company -n <your_namespace>

直到

，您都看不到任何端点

  

readinessProbe

失败。