web-dev-qa-db-ja.com

KubeadmとマスターでのポッドのスケジューリングのリスクNode（ポッドは常に保留中）

kubeadmを使用してクラスターを作成する に関するkubernetesの記事に従いながら、インストールしようとしたAddOnポッド（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-からコマンドを実行すると、アドオンは期待どおりにインストールされました。

この時点では、（マスターノードに既にインストールされているため）スケジューラーがポッドをスケジュールするためにワーカーノードをクラスターにまだ接続していないことが疑われます。

ドキュメントには、「クラスターはセキュリティ上の理由でマスター上のポッドをスケジュールしない」と記載されています。これは非実稼働環境であることを知っているので、この状況ではほとんどリスクはありませんが、実稼働クラスターでその汚染を除去するリスクは何ですか？

フォローアップ：これがリスクである場合、AddOnポッドをアンインストールしてスケジューラーにワーカーノードにインストールさせるために、その汚染を再度追加するにはどうすればよいですか？

環境の詳細：オペレーティングシステム-CentOS 7.4.1708（コア）Kubernetesバージョン-1.10

kubernetescentos7kubeadm
8
Flea

その理由は、スケジューラがポッドをスケジュールするためにワーカーノードをまだクラスターに接続していないからです。

100％正しい。確かにいくつかのワーカーノードが必要になります。そうしないと、「作業のスケジュール」という考え方が非常に奇妙になります。

しかし、実稼働クラスターでその汚染を除去するリスクは何ですか？

私はkubernetesセキュリティの専門家ではありませんが、pragmaticリスクはマスターノードでのCPU、I/O、および/またはメモリ枯渇であり、クラスターの健全性に非常に深刻な影響を及ぼします。マスターノードでワークロードを実行する理由はほとんどありません。また、ほぼ完全にリスクが増加するため、「やらないでください」というアドバイスは十分に確立されています。

どうすればその汚染を再び追加して、AddOnポッドをアンインストールし、スケジューラーにワーカーノードにインストールさせることができますか？

私はその質問に従うかどうかはわかりませんが、確実に、汚染と許容で複雑なことをしようとする前に、ワーカーノードを追加することから始めます。

8
mdaniel