我创建了一个具有 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的同一个问题中重复使用了这个示例,可以通过更改
kubelet
和kubeapi-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/