kubernetes - 容器化Kubernetes主流程的优势

Question

Kubernetes HA guide和From Scratch guide都建议在容器中运行Etcd，kube-apiserver，kube-controller-manager和kube-scheduler。在Kubernetes上自托管Kubernetes的想法可以追溯很久了(请参阅K8s github上的PR 167及其链接的问题/ PR)，但我还没有找到关于为什么这种方法如此有益以至于应该成为“推荐的方式。以下是我目前看到的优缺点:

好处:

可能很容易的升级路径，仅用于更新 list 并让kubelet提取新图像。

“容器优势”:二进制环境和主机环境分离，利用他人现有的镜像等。

遵循整个Kubernetes模式，因此，一旦广泛使用该模式，就可以“适应大脑”。

缺点:

在某些情况下，增加的安装/配置复杂性。例如，如果您的Etcd集群与Kubernetes节点是分开的，那么您现在必须安装Docker(取决于Linux发行版的存储可能会发生变化)，kubelet和Etcd。如果不使用容器化的Etcd，则只需安装一个二进制文件。

在运行时增加了复杂性:随着零件的移动越来越多，Docker或kubelet中的任何错误都可能使关键组件失效。

我是Kubernetes(和容器)的新手，觉得与它引入的额外复杂性相比，我可能会失去优势(或低估了它们的值(value))。但是我也必须选择一次尝试的方法。尽管存在额外的复杂性，为什么容器化的主组件是运行Kubernetes的推荐方法？

Answer 1

最大的好处是简化了大多数人的设置。运行一些docker run命令比下载二进制文件，解压缩，微调初始化脚本(在每个发行版中都不同)，运行管理程序等要容易得多。我们有一个非常好的流程管理器-依靠它，功能强大。

我们也不建议共享etcd，因此，如果您这样做的话，您就已经偏离了常规。

总体而言，对于大多数人来说，容器化组件比替代组件要简单得多。