Kubernetes 社区每周 Hangout 会议纪要 - 2015 年 7 月 17 日

每周 Kubernetes 贡献者社区都会通过 Google Hangouts 进行线上会议。我们希望所有感兴趣的人都能了解这个论坛的讨论内容。

以下是今日会议纪要

• Eric Paris：用 ansible 替换 salt（如果我们愿意）

  • 在 contrib 中，有一个用 ansible 编写的供给工具

  • 重写的目的是尽可能消除与云提供商相关的内容

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

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

  • 对于 ansible，所有事情都必须在 ansible 中完成

  • ansible 背景介绍

    • 没有客户端
    • Provisioner 通过 ssh 连接到机器并在机器上运行脚本
    • 你定义你希望集群看起来是什么样子，运行脚本，它会一次性设置所有东西
    • 如果你在一个配置文件中做了一个更改，ansible 会重新运行所有东西（这并不总是合意的）
    • 使用 jinja2 模板

  • 创建只有最少软件的机器，然后使用 ansible 使机器进入可运行状态

    • 设置所有附加组件

  • 消除了 provisioner shell 脚本

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

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

  • 提问 Eric

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

      • ansible 配置中唯一的网络设置是 flannel；你可以关闭它

    • init 和 systemd 呢？

      • 应该可以在代码中无障碍支持（尚未实现）

  • 讨论

    • 为什么不将设置工作推入容器或 kubernetes 配置中？

      • 引导一个集群只需放入一个 kubelet 和一个 manifest

    • 运行一个 kubelet 并配置网络应该是唯一需要做的事情。我们可以制作一个预配置好的机器镜像，只需添加数据包（证书等）

      • ansible 脚本会安装 kubelet & docker，如果它们尚未安装

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

    • 裸金属环境也需要解决方案。

    • 赞成总体目标 -- 减少 salt 配置中的特殊配置

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

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

    • 这些工具（Chef, Puppet, Ansible）将二进制分发与配置混为一谈

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

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

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

    • Openstack 也使用了不同的部署方式

    • 我们需要一份文档齐全的步骤列表（例如生成证书），这些步骤是启动一个集群所必需的

      • 这将使我们能够在不同的云提供商之间进行比较
      • 我们应该尽可能减少步骤数量
      • Ansible 启动一个集群有 241 个步骤

• 1.0 代码冻结

  • 我们如何解除代码冻结？

  • 这是下周的议题，但预告是我们将缓慢推进，而不是完全打开洪水闸门

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

  • 今天发布一个 cherry pick 版本 (1.0.1)，修复了一些问题

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

• ←上一页
• 下一页→