每周 Kubernetes 社区环聊笔记 - 2015 年 7 月 10 日

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

以下是今天会议的笔记

• Eric Paris：用 ansible 替换 salt（如果我们想的话）
  • 在 contrib 中，有一个用 ansible 编写的 provisioning 工具
  • 重写的目的是尽可能消除云提供商相关的部分
  • salt 设置在脚本中完成大量设置，然后使用 salt 设置环境
    • 这意味着生成证书等操作在 GCE/AWS/Vagrant 上是不同的
  • 对于 ansible，所有操作都必须在 ansible 中完成
  • ansible 背景
    • 没有客户端
    • provisioner 通过 ssh 登录机器并在机器上运行脚本
    • 您定义集群的所需状态，运行脚本，然后它一次性设置所有内容
    • 如果您更改配置文件中的一处，ansible 会重新运行所有内容（这并非总是理想的）
    • 使用 jinja2 模板
  • 创建最小软件的机器，然后使用 ansible 使该机器进入可运行状态
    • 设置所有附加组件
  • 消除了 provisioning 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 部署完全不同：kubelets 部署在现有 mesos 集群之上
      • bash 脚本允许 mesos 开发人员查看每个云提供商正在做什么并重用相关部分
      • 有一个很大的逆向工程曲线，但 bash 至少是可读的，而 salt 则不是
    • Openstack 也使用不同的部署方式
    • 我们需要一个详细的步骤列表（例如创建证书），这些步骤对于建立集群是必要的
      • 这将使我们能够跨云提供商进行比较
      • 我们应该尽可能减少步骤的数量
      • Ansible 有 241 个步骤来启动一个集群
• 1.0 代码冻结
  • 我们如何解除代码冻结？
  • 这是下周的话题，但初步设想是我们将缓慢推进，而不是完全放开
    • 我们希望尽快清除积压，同时保持 HEAD 和 1.0 分支的稳定性
    • 积压了近 300 个 PR，但代码冻结期间也开发了各种并行功能分支
  • 今天发布一个 cherry pick 版本 (1.0.1) 来修复一些问题
  • 下周我们将讨论补丁发布的节奏

• ←上一篇
• 下一篇→