Kubernetes 在服务/部署级别检查 readinessProbe答案

【问题标题】：Kubernetes check readinessProbe at Service/Deployment levelKubernetes 在服务/部署级别检查 readinessProbe
【发布时间】：2020-02-11 22:46:05
【问题描述】：

有没有办法通过使用链接到部署的服务名称来请求 readinessProbe 的状态？例如在 initContainer 中？

假设我们有一个部署 X，使用一个 readinessProbe，一个服务链接到它，所以我们可以请求例如http://service-X:8080。现在我们创建一个部署 Y，在 initContainer 中我们想知道部署 X 是否准备好。有没有办法问deployment-X.ready 或service-X.ready 之类的问题？

我知道处理依赖的正确方法是让 kubernetes 为我们做这件事，但是我有一个不会崩溃的容器，我没有手...

【问题讨论】：

标签： kubernetes kubernetes-service kubernetes-deployment

【解决方案1】：

您可以在部署 Y 上添加一个 ngnix 代理 sidecar。将deploymentY.initContainer.readynessProbe 设置为nginx 上的一个端口，该端口被代理为deploymentY.readynessProbe

【讨论】：

感谢您的回答，我已经在 google 上找到了类似的东西，但我正在寻找另一个没有 sidecar 的解决方案...

【解决方案2】：

您可以只使用 InitContainer 而不是 readinessProbe。

您创建一个 pod/deployment X，创建服务 X，并创建一个正在搜索服务 X 的 initContainer。

如果他找到了 -> 他会制作豆荚。

如果他找不到 -> 他会继续寻找，直到创建服务 X。

只是一个简单的例子，我们使用kubectl apply -f nginx.yaml创建nginx deployment。

nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

然后我们创建initContainer

initContainer.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup my-nginx; do echo waiting for myapp-pod2; sleep 2; done;']

initContainer 会寻找服务 my-nginx，直到你创建它，它会处于Init:0/1 状态。

NAME                        READY   STATUS     RESTARTS   AGE
myapp-pod                   0/1     Init:0/1   0          15m

在你添加服务后，例如使用kubectl expose deployment/my-nginx，initContainer 会找到 my-nginx 服务，他会被创建。

NAME                        READY   STATUS     RESTARTS   AGE
myapp-pod                   1/1     Running    0          35m

结果：

Events:
  Type    Reason     Age        From               Message
  ----    ------     ----       ----               -------
  Normal  Scheduled  <unknown>  default-scheduler  Successfully assigned default/myapp-pod to kubeadm2
  Normal  Pulled     20s        kubelet, kubeadm2  Container image "busybox:1.28" already present on machine
  Normal  Created    20s        kubelet, kubeadm2  Created container init-myservice
  Normal  Started    20s        kubelet, kubeadm2  Started container init-myservice
  Normal  Pulled     20s        kubelet, kubeadm2  Container image "busybox:1.28" already present on machine
  Normal  Created    20s        kubelet, kubeadm2  Created container myapp-container
  Normal  Started    20s        kubelet, kubeadm2  Started container myapp-container

如果这回答了你的问题，请告诉我。

【讨论】：

您好，我认为您的回答并没有考虑到该服务已准备好至少一个 pod 以及为什么我需要使用 readinessProbe 的事实。如果我错了，请告诉我，我在 Kubernetes 上没有这样的经验。但我找到了这个链接的解决方案：blog.giantswarm.io/…
嗨@Borhink，我不知道我对你的理解是否正确，你的意思是如果服务会在这里，但不会有任何豆荚，它会起作用吗？如果您找到了解决方案，请将其添加为答案，以便社区可以看到它，如果有人有同样的想法吗？
我添加了一个答案，我们可以在其中检查是否创建了服务并准备好一个或多个 pod。感谢您的时间。抱歉，英语不是我的母语，有些地方很难解释……

【解决方案3】：

我最终通过以下链接找到了解决方案： https://blog.giantswarm.io/wait-for-it-using-readiness-probes-for-service-dependencies-in-kubernetes/

我们首先需要在 Kubernetes 中创建一个 ServiceAccount 以允许列出来自 initContainer 的端点。在此之后，我们要求提供可用的端点，如果至少有一个，则依赖项已准备好（在我的情况下）。

【讨论】：