我创建了一个具有 liveness 和就绪性探针的部署,并且初始延迟运行良好。如果我想用启动探针替换初始延迟,则使用startupProbe创建时kubectl apply key 及其嵌套元素永远不会包含在部署描述符中,并在保存后从GKE部署编辑器中的部署yaml中删除。

一个例子:

apiVersion: v1
kind: Namespace
metadata:
  name: "test"
---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-sleep
  namespace: test
spec:
  selector:
    matchLabels:
      app: postgres-sleep
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 50%
  template:
    metadata:
      labels:
        app: postgres-sleep
    spec:
      containers:
        - name: postgres-sleep
          image: krichter/microk8s-startup-probe-ignored:latest
          ports:
            - name: postgres
              containerPort: 5432
          readinessProbe:
            tcpSocket:
              port: 5432
            periodSeconds: 3
          livenessProbe:
            tcpSocket:
              port: 5432
            periodSeconds: 3
          startupProbe:
            tcpSocket:
              port: 5432
            failureThreshold: 60
            periodSeconds: 10
---

apiVersion: v1
kind: Service
metadata:
  name: postgres-sleep
  namespace: test
spec:
  selector:
    app: httpd
  ports:
    - protocol: TCP
      port: 5432
      targetPort: 5432
---

krichter/microk8s-startup-probe-ignored:latest
FROM postgres:11
CMD sleep 30 && postgres

我在microk8s的同一个问题中重复使用了这个示例,可以通过更改kubeletkubeapi-server配置文件来解决此问题(如果您有兴趣,请参阅https://github.com/ubuntu/microk8s/issues/770)。我认为这对于GKE群集是不可能的,因为它们不会公开这些文件,这可能是有充分理由的。

我认为该功能需要启用,因为它位于功能门的后面。如何在版本大于等于1.16的Google Kubernetes Engine(GKE)集群上启用它?目前,我正在使用常规 channel 1.16.8-gke.15中的默认值。

最佳答案

正如我在评论中提到的那样,我能够在测试环境中重现相同的行为,经过一些研究后,我找到了原因。

在GKE中,仅当您使用Alpha群集时才允许要素门。您可以看到功能门here的完整列表

我创建了一个alpha集群并应用了相同的Yaml,它对我有用,startupProbe就在那儿。

因此,您将只能在GKE Alpha群集中使用startupProbe,请按照此documentation创建一个新的。

请注意alpha群集中的限制:



另外,Google不建议将其用于生产工作负载:

关于kubernetes - 如何在GKE 1.16上启用启动探针?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/61918062/

10-10 09:57