如果我有一个kubernetes节点，但是在kubernetes上下文之外，我将容器(docker)引擎用于其他工作，那么kubernetes调度会发生什么。
例如，如果我手动SSH到相应的节点，然后执行docker run。 kubernetes调度是否会考虑到该节点正在忙于运行其他内容的事实，并且它现在可能无法托管任何其他容器？
在以下情况下会发生什么:
带有8 GB RAM的
docker run一个5 GB的容器附言请跳过“为什么要去直接在该节点上运行
docker run”问题。我不想，但是有原因。
最佳答案
我很确定Kubernetes的调度仅考虑(a)它知道的pod而不考虑其他资源，以及(b)仅考虑其资源请求。
在您描述的情况下，只要利用资源，一切都会很好。可以在节点上调度Pod，因为使用它的总资源请求为8 GB中的2 GB。总内存使用量也不会超过物理内存大小，因此您可以。
假设广告连播分配了更多的内存。现在，整个系统已超出其物理内存容量，因此Linux内核将任意杀死某些东西。这通常是最大的事情。无论在哪个系统管理下，您通常都会看到退出代码137(与SIGKILL匹配)。
即使您在DaemonSet之类的环境中运行辅助作业，此行为也相同。它需要2 GB的RAM，因此两个Pod都可以安装在同一节点[4 GB / 8 GB]上，但是如果它的资源限制为6 GB RAM，则某些内容将被杀死。
如果您可以预测内存使用率高，则情况会有所不同。假设您的Pod要求3 GB /限制6 GB的RAM，那么您的辅助进程也将使用6 GB。如果仅使用docker run，则肯定会杀死OOM。如果您将其作为DaemonSet运行并声明6 GB的内存请求，Kubernetes调度程序将知道该Pod不合适，并且不会将其放置在其中(如果无法在任何地方进行调度，它可能会陷入“待处理”状态)。
关于docker - 在k8s中使用k8s节点资源，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59487324/