本文发布时间超过一年。较旧的文章可能包含过时的内容。请检查页面上的信息自发布以来是否已变得不正确。

每周 Kubernetes 社区交流会记录 - 2015 年 7 月 17 日

每周，Kubernetes 贡献者社区都会通过 Google Hangouts 进行虚拟会议。我们希望任何对此感兴趣的人都知道这个论坛中讨论的内容。

以下是今天会议的记录

  • Eric Paris：用 ansible 替换 salt（如果需要）

    • 在 contrib 中，有一个用 ansible 编写的配置工具

    • 重写的目的是尽可能消除云提供商的东西

    • salt 设置在脚本中进行大量设置，然后使用 salt 设置环境

      • 这意味着在 GCE/AWS/Vagrant 上生成证书等操作是不同的

    • 对于 ansible，所有操作都必须在 ansible 中完成

    • ansible 的背景

      • 没有客户端
      • 配置器通过 SSH 进入机器并在机器上运行脚本
      • 您定义希望集群的外观，运行脚本，它会一次性设置所有内容
      • 如果在配置文件中进行一项更改，ansible 会重新运行所有内容（这并不总是理想的）
      • 使用 jinja2 模板

    • 创建具有最少软件的机器，然后使用 ansible 将该机器置于可运行状态

      • 设置所有附加组件

    • 消除配置器 shell 脚本

    • 完整的集群设置目前大约需要 6 分钟

      • 带有某些软件包的 CentOS
      • 重新部署到集群需要 25 秒

    • 给 Eric 的问题

      • 特定于提供商的配置放在哪里？

        • ansible 配置所做的唯一网络设置是 flannel；您可以将其关闭

      • 关于 init 与 systemd？

        • 应该能够在代码中支持而不会有任何问题（尚未实现）

    • 讨论

      • 为什么不将设置工作推送到容器或 Kubernetes 配置中？

        • 为了引导集群，请删除 kubelet 和清单

      • 运行 kubelet 并配置网络应该是唯一需要的。我们可以切割一个预配置的机器镜像，减去数据包（证书等）

        • 如果未安装 kubelet 和 docker，则 ansible 脚本会安装它们

      • 每个操作系统（RedHat、Debian、Ubuntu）都可以有不同的镜像。我们可以将其视为构建过程的一部分，而不是安装过程。

      • 还需要针对裸机的解决方案。

      • 支持总体目标 -- 减少 salt 配置中的特殊配置

      • 除了 kubelet 之外的所有内容都应该在容器内运行（最终 kubelet 也应该如此）

        • 在容器中运行并不能减少我们目前拥有的复杂性
        • 但它更清楚地定义了代码期望的接口

      • 这些工具（Chef、Puppet、Ansible）将二进制分发与配置混淆了

        • 容器更清楚地分离了这些问题

      • mesos 部署尚未完全自动化，但 mesos 部署完全不同：kubelet 被放置在现有的 mesos 集群之上

        • bash 脚本允许 mesos 开发人员查看每个云提供商在做什么，并重用相关部分
        • 存在一个很大的逆向工程曲线，但 bash 至少是可读的，而不是 salt

      • Openstack 也使用不同的部署

      • 我们需要一个记录完善的步骤列表（例如，创建证书），这些步骤是启动集群所必需的

        • 这将使我们能够跨云提供商进行比较
        • 我们应尽可能减少步骤
        • Ansible 有 241 个步骤来启动集群

  • 1.0 代码冻结

    • 我们如何摆脱代码冻结？

    • 这是下周的主题，但预览是我们将缓慢移动，而不是完全打开消防水管

      • 我们希望在保持 HEAD 和 1.0 分支稳定性的同时，尽快清除积压
      • 积压了近 300 个 PR，但也有在冻结期间开发的各种并行功能分支

    • 今天将发布 cherry pick 版本（1.0.1），修复一些问题

    • 下周我们将讨论补丁发布的节奏