我们正在运行一个具有5个主节点和20个工作节点的kubernetes（1.9.4）集群。我们正在集群中其他Pod中运行一个带有复制3的statefulset Pod。最初，有状态集Pod被分配到3个节点。但是，由于节点2上的磁盘压力，节点2上的pod-2被逐出。但是，将pod-2逐出后，它会转到node-1，其中pod-1已经在运行，而node-1已经在承受节点压力。根据我们的理解，kubernetes-scheduler不应将pod（非关键）调度到已经存在磁盘压力的节点上。这是在磁盘压力下不将Pod调度到某个节点的默认行为，还是允许这样做。原因是，我们同时观察到，节点0没有任何磁盘问题。因此，我们希望理想情况下，节点2上逐出的Pod应该位于节点0上，而不是受到磁盘压力的节点1上。
我们的另一个观察结果是，当驱逐节点2上的pod-2时，我们看到成功调度了同一pod，并在节点1中产生并移到了运行状态。但是，对于被逐出的同一pod-2，我们仍然在节点2中多次看到“无法接受pod”错误。这是kube-scheduler的问题吗？
答案 0 :(得分：0)
是的，Scheduler不应将新的pod分配给具有DiskPressure条件的节点。
但是，我认为您可以从几个不同的角度来解决这个问题。
查看调度程序的配置：
@CompileStatic
@Configuration
@EnableWebSocketMessageBroker
class MainWebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {
@Override
void configureMessageBroker(MessageBrokerRegistry messageBrokerRegistry) {
messageBrokerRegistry.enableSimpleBroker "/queue", "/topic"
messageBrokerRegistry.setApplicationDestinationPrefixes("/app");
}
@Override
void registerStompEndpoints(StompEndpointRegistry stompEndpointRegistry) {
stompEndpointRegistry.addEndpoint("/stomp").setAllowedOrigins("*").withSockJS()
}
}
// GetStatus() IS NOT BEING CALLED FOR SOME REASON:
@Controller
public class ReceivedMsgController {
SimpMessagingTemplate brokerMessagingTemplate
@MessageMapping("/getstatus")
public String GetStatus(String msg) {
println('GetStatus() ' + msg)
brokerMessagingTemplate.convertAndSend('/topic/sometopic', "Your message was: " + msg)
}
}
并检查是否需要任何调整。您可以找到有关kube-scheduler here的其他选项的信息：
您还可以根据需要配置附加计划程序。可以找到相关的教程here
检查日志：
./kube-scheduler --write-config-to kube-config.yaml：kube-scheduler事件日志kubeclt logs：kubelet日志journalctl -u kubelet（在主服务器上）更仔细地查看Kubelet的驱逐阈值（软阈值和硬阈值）以及设置了多少节点内存容量。
请记住：
请查看我的建议，并让他们知道是否有帮助。