Kubeadm 和在主节点上调度 Pods 的风险（Pods 始终待定）
Kubeadm and the Risks of Scheduling Pods on Master Node (Pods always Pending)
在关注 Using kubeadm to Create a Cluster 上的 kubernetes 文章时，当我尝试安装的 AddOn pods（Nginx、Tiller、Grafana、InfluxDB、Dashboard）总是停留在一个状态时，我被卡住了待定。
检查来自 kubectl describe pod tiller-deploy-df4fdf55d-jwtcz --namespace=kube-system 的消息得到以下消息：
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 51s (x15 over 3m) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
当我 运行 来自 Master Isolation 部分 kubectl taint nodes --all node-role.kubernetes.io/master- 的命令时，插件将按预期安装。
此时我只能怀疑（因为它们已经安装在主节点上）原因是我还没有将工作节点连接到集群，以便调度程序调度 pods上。
文档说明 "your cluster will not schedule pods on the master for security reasons"。我知道这是一个非生产环境，因此在这种情况下几乎没有风险，但是在生产集群中消除该污点的风险是什么？
跟进：如果这是一个风险，我如何重新添加该污点，以便我可以卸载 AddOn pods 并尝试让调度程序将它们安装在我的工作节点上？
环境详细信息：操作系统 - CentOS 7.4.1708（核心）Kubernetes 版本 - 1.10
the reason was that I hadn't connected a worker node to the cluster yet for the scheduler to schedule the pods on.
100% 正确。你肯定会需要一些工作节点，否则 "scheduling work" 的想法变得很奇怪。
but what is the risk of removing that taint in a production cluster?
我不是 kubernetes 安全专家，但务实 风险是 CPU、I/O、and/or 主机上的内存耗尽节点，这将对集群的健康产生非常严重的后果。几乎没有理由 运行 主节点上的任何工作负载，而且几乎完全是风险的增加，因此建议 "just don't do it" 是有根据的。
how can I re-add that taint so I can then uninstall the AddOn pods and try to have the scheduler install them on my Worker Node?
我不确定我是否遵循了这个问题，但我肯定会先添加一个工作节点，然后再尝试使用污点和容忍度来做复杂的事情。
在关注 Using kubeadm to Create a Cluster 上的 kubernetes 文章时，当我尝试安装的 AddOn pods（Nginx、Tiller、Grafana、InfluxDB、Dashboard）总是停留在一个状态时，我被卡住了待定。
检查来自 kubectl describe pod tiller-deploy-df4fdf55d-jwtcz --namespace=kube-system 的消息得到以下消息：
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 51s (x15 over 3m) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
当我 运行 来自 Master Isolation 部分 kubectl taint nodes --all node-role.kubernetes.io/master- 的命令时，插件将按预期安装。
此时我只能怀疑（因为它们已经安装在主节点上）原因是我还没有将工作节点连接到集群，以便调度程序调度 pods上。
文档说明 "your cluster will not schedule pods on the master for security reasons"。我知道这是一个非生产环境，因此在这种情况下几乎没有风险，但是在生产集群中消除该污点的风险是什么？
跟进：如果这是一个风险，我如何重新添加该污点，以便我可以卸载 AddOn pods 并尝试让调度程序将它们安装在我的工作节点上？
环境详细信息：操作系统 - CentOS 7.4.1708（核心）Kubernetes 版本 - 1.10
the reason was that I hadn't connected a worker node to the cluster yet for the scheduler to schedule the pods on.
100% 正确。你肯定会需要一些工作节点，否则 "scheduling work" 的想法变得很奇怪。
but what is the risk of removing that taint in a production cluster?
我不是 kubernetes 安全专家，但务实 风险是 CPU、I/O、and/or 主机上的内存耗尽节点，这将对集群的健康产生非常严重的后果。几乎没有理由 运行 主节点上的任何工作负载，而且几乎完全是风险的增加，因此建议 "just don't do it" 是有根据的。
how can I re-add that taint so I can then uninstall the AddOn pods and try to have the scheduler install them on my Worker Node?
我不确定我是否遵循了这个问题，但我肯定会先添加一个工作节点，然后再尝试使用污点和容忍度来做复杂的事情。