我正在试验集群或 生产环境 集群上的6个节点(在两个节点池中)测试集群中进行GKE集群升级 . 升级时,我只有12个副本nginx部署,nginx入口控制器和cert-manager(作为helm图表)安装每个节点池需要10分钟(3个节点) . 我很满意 . 我决定再试一次看起来更像我们设置的东西 . 我删除了nginx部署并添加了2个node.js部署,以下是头盔图:mongodb-0.4.27,mcrouter-0.1.0(作为statefulset),redis-ha-2.0.0,以及我自己的www-redirect- 0.0.1图表(进行重定向的简单nginx) . 问题似乎与mcrouter有关 . 节点开始耗尽后,该节点的状态将更改为 Ready,SchedulingDisabled
(这似乎正常),但仍保留以下窗格:
-
mcrouter-memcached-0
-
fluentd-gcp-v2.0.9-4f87t
-
kube-proxy-gke-test-upgrade-cluster-default-pool-74f8edac-wblf
我不知道为什么这两个kube系统吊舱仍然存在,但那个mcrouter是我的,并且它不会足够快 . 如果我等待足够长的时间(1小时),那么它最终会起作用,我不知道为什么 . 当前节点池(3个节点)在2h46分钟前开始升级,2个节点升级,第3个节点仍在升级,但没有任何动态......我认为它将在接下来的1-2个小时内完成...我试过了使用 --ignore-daemonsets --force
运行排水命令,但它告诉我它已经耗尽了 . 我试图删除pod,但他们只是回来了,升级不会更快 . 有什么想法吗?
更新#1
mcrouter helm图表安装如下:
helm install stable/mcrouter --name mcrouter --set controller=statefulset
它为mcrouter部分创建的状态集是:
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
labels:
app: mcrouter-mcrouter
chart: mcrouter-0.1.0
heritage: Tiller
release: mcrouter
name: mcrouter-mcrouter
spec:
podManagementPolicy: OrderedReady
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: mcrouter-mcrouter
chart: mcrouter-0.1.0
heritage: Tiller
release: mcrouter
serviceName: mcrouter-mcrouter
template:
metadata:
labels:
app: mcrouter-mcrouter
chart: mcrouter-0.1.0
heritage: Tiller
release: mcrouter
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: mcrouter-mcrouter
release: mcrouter
topologyKey: kubernetes.io/hostname
containers:
- args:
- -p 5000
- --config-file=/etc/mcrouter/config.json
command:
- mcrouter
image: jphalip/mcrouter:0.36.0
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: mcrouter-port
timeoutSeconds: 5
name: mcrouter-mcrouter
ports:
- containerPort: 5000
name: mcrouter-port
protocol: TCP
readinessProbe:
failureThreshold: 3
initialDelaySeconds: 5
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: mcrouter-port
timeoutSeconds: 1
resources:
limits:
cpu: 256m
memory: 512Mi
requests:
cpu: 100m
memory: 128Mi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /etc/mcrouter
name: config
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
volumes:
- configMap:
defaultMode: 420
name: mcrouter-mcrouter
name: config
updateStrategy:
type: OnDelete
这是memcached statefulset:
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
labels:
app: mcrouter-memcached
chart: memcached-1.2.1
heritage: Tiller
release: mcrouter
name: mcrouter-memcached
spec:
podManagementPolicy: OrderedReady
replicas: 5
revisionHistoryLimit: 10
selector:
matchLabels:
app: mcrouter-memcached
chart: memcached-1.2.1
heritage: Tiller
release: mcrouter
serviceName: mcrouter-memcached
template:
metadata:
labels:
app: mcrouter-memcached
chart: memcached-1.2.1
heritage: Tiller
release: mcrouter
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: mcrouter-memcached
release: mcrouter
topologyKey: kubernetes.io/hostname
containers:
- command:
- memcached
- -m 64
- -o
- modern
- -v
image: memcached:1.4.36-alpine
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: memcache
timeoutSeconds: 5
name: mcrouter-memcached
ports:
- containerPort: 11211
name: memcache
protocol: TCP
readinessProbe:
failureThreshold: 3
initialDelaySeconds: 5
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: memcache
timeoutSeconds: 1
resources:
requests:
cpu: 50m
memory: 64Mi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
updateStrategy:
type: OnDelete
status:
replicas: 0
2 回答
这是一个有点复杂的问题,我绝对不确定这是我的想法,但是......让我们试着去了解发生了什么 .
您有一个升级过程,并在群集中有6个节点 . 系统将使用Drain逐个升级它以从pod中删除所有工作负载 .
排水过程本身尊重您的设置和副本数量 desired state 工作负载 higher priority 比节点本身的排放量多 .
在排水过程中,Kubernetes将尝试在可用调度的资源上安排所有工作负载 . 要禁用系统要排空的节点,您可以在其状态中查看它 -
Ready,SchedulingDisabled
.因此,Kubernetes调度程序试图在所有可用节点上为您的工作负载找到合适的位置 . 只要需要将您描述的所有内容放在群集配置中,它就会等待 .
现在最重要的是 . 您为
mcrouter-memcached
设置了replicas: 5
. 由于podAntiAffinity
,它不能为每个节点运行多个副本,并且运行它的节点应该具有足够的资源,这是使用resources:
块ReplicaSet
计算的 .因此,我认为,您的群集没有足够的资源来在剩余的5个节点上运行
mcrouter-memcached
的新副本 . 例如,在其副本仍未运行的最后一个节点上,由于其他工作负载,您的内存不足 .我想如果你将
mcrouter-memcached
为mcrouter-memcached
设置为4,它将解决一个问题 . 或者您可以尝试为该工作负载使用更强大的实例,或者向群集添加一个以上的节点,它也应该有所帮助 .希望我对我的逻辑给出足够的解释,问我是否有不清楚的事情 . 但首先请尝试通过提供的解决方案解决问题:)
问题是来自PodDisruptionBudget的minAvailable值(它是memcached helm图表的一部分,它是mcrouter helm图表的依赖关系)和memcached复制集的replicas值的组合 . 两者都被设置为5,因此在排水期间没有一个被删除 . 我尝试将minAvailable更改为4但PDB are immutable at this time . 我做的是删除头盔图并替换它 .
完成后,我就可以让集群正常升级 .
我应该做的(但之后只考虑它)是将副本值更改为6,这样我就不需要删除和替换整个图表 .
谢谢@AntonKostenko试图帮我找到这个问题 . 这个issue也帮助了我 . 感谢Slack@Kubernetes中的人们,特别是巴黎人,他们试图让我的问题更具知名度,并且Kubernetes Office Hours的志愿者(恰好是yesterday,幸运的)我!)也看看 . 最后,感谢来自Kubernetes Canada的psycotica0也给了我一些指示 .