我有一个应用程序在kubernetes上运行，在几个pod上。我正在努力改善我们的部署体验(我们正在使用滚动部署)，这目前正在造成痛苦。
我想要实现的:
- 每个pod首先没有准备好，所以它没有得到更多的流量
- 则它将完成当前正在处理的请求
- 则可以删除
这应该都是可能的，并且可以正常工作——您创建了一个包含就绪探测和活动探测的部署。负载平衡器将拾取这些并相应地路由流量。然而，当我测试我的部署时，我发现即使切换到not ready状态，pod也会收到请求。具体来说，当大量流量进入时，负载平衡器似乎不会更新。我可以看到豆荚"还没准备好"当我给它们发信号时——如果它们在切换状态时没有收到流量，那么它们之后也不会收到流量。但如果它们在切换时获得流量，负载均衡器就会忽略状态变化。
我开始想知道如何处理这个问题，因为我看不出我错过了什么-它必须有可能在kubernetes上托管一个高流量的应用程序，pods正在"未准备好";而不会丢失大量的请求
我的配置
部署apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: my-service
name: my-service
namespace: mine
spec:
replicas: 2
selector:
matchLabels:
app: my-service
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
labels:
app: my-service
env: production
spec:
containers:
- name: my-service
image: IMAGE ID
imagePullPolicy: Always
volumeMounts:
- name: credentials
mountPath: "/run/credentials"
readOnly: true
securityContext:
privileged: true
ports:
- containerPort: 8080
protocol: TCP
lifecycle:
preStop:
exec:
command: ["/opt/app/bin/graceful-shutdown.sh"]
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 1
initialDelaySeconds: 5
failureThreshold: 1
livenessProbe:
httpGet:
path: /alive
port: 8080
periodSeconds: 1
failureThreshold: 2
initialDelaySeconds: 60
resources:
requests:
memory: "500M"
cpu: "250m"
dnsPolicy: ClusterFirst
restartPolicy: Always
terminationGracePeriodSeconds: 60
nodeSelector:
cloud.google.com/gke-nodepool: stateful
服务/loadbalance
apiVersion: v1
kind: Service
metadata:
name: stock-service-loadbalancer
namespace: stock
spec:
selector:
app: stock-service
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: LoadBalancer
这被证明是持久连接的影响，而不是流量的影响。原因似乎是负载均衡器不会关闭打开的连接——对于我们的服务，我们使用了一个使用长时间运行连接池的测试设置。因此，负载均衡器正在更新它的路由，但现有的连接继续向终止pod发送数据。
结果是这种零停机策略确实有效:
- 使用preStop钩子使你的pod失败的准备探针
- 确保等待几秒钟
- 然后让您的pod通过SIGTERM 优雅地终止
- 确保你的terminationGracePeriodSeconds足够大，以包含预停止和实际终止时间