概要
openshift在有多个node节点时可以做到应用的多活负载,并且在部分node节点丢失时保障应用的高可用和自动迁移至其他健康node节点。
测试
我在自己的环境上部署了一个应用pod,当我关闭pod所在node节点时,等待pod重新在其他健康的node节点上创建耗费了很长一段时间,主要包括两个时间:1、node丢失时间。2、pod驱逐重新调度时间。
node丢失时间
node丢失时间的设置参数为:node-monitor-grace-period,默认是40s,在40s内判断都是不健康就会把这个node标记为不健康。
以下是配置文件的路径和位置:
- /etc/origin/master/master-config.yaml
kubernetesMasterConfig:
controllerArguments:
node-monitor-grace-period:
- "40s"
- K8S官方解释
Amount of time which we allow running Node to be unresponsive before marking it unhealthy. Must be N times more than kubelet's nodeStatusUpdateFrequency, where N means number of retries allowed for kubelet to post node status.
pod驱逐重新调度时间
在openshift判断node节点丢失时,会判断所在node节点的pod状态信息,如果在5分钟内都丢失的node节点没有恢复健康,就会把所在的pod给驱逐到其他健康的node节点上。
以下是配置文件的路径和位置:
- /etc/origin/master/master-config.yaml
kubernetesMasterConfig:
podEvictionTimeout: 5m
- 官方解释
Controls grace period for deleting pods on failed nodes. It takes valid time duration string. If empty, you get the default pod eviction timeout.
node上报自身状态时间
node节点会上报自身状态,配置参数为:nodeStatusUpdateFrequency,默认10s。
- /etc/origin/node/node-config.yamlfile:
kubeletArguments:
node-status-update-frequency:
- "10s"
- 官方解释
The node continues to report node status updates at the frequency specified by the node-status-update-frequency argument, which defaults to 10s (ten seconds).
重启服务
在修改完配置文件后,要记得重启相应的master和node服务才能生效,如果是多节点,要修改多个。
参考链接
-
node-status-update-frequency
https://docs.openshift.com/container-platform/3.11/admin_guide/out_of_resource_handling.html#out-of-resource-eviction-thresholds -
PodEvictionTimeout
https://docs.openshift.com/container-platform/3.11/install_config/master_node_configuration.html#node-config-pod-and-node-config -
node-monitor-grace-period
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager
https://access.redhat.com/solutions/2899061
网友评论