Kubernetes 社区每周Hangouts笔记-2015年4月10日

每周,Kubernetes贡献社区几乎都会通过Google Hangouts开会。我们希望任何有兴趣的人都知道本论坛讨论的内容。

议程:

  • kubectl工具,滚动更新,部署,命令式命令。
  • 向下的API /环境替代,可能还有前提条件/依赖关系。

会议记录:

1. kubectl的改进

  • 使它更易于使用,完成滚动更新,更高级别的部署概念。

  • 滚动更新

    • 今天

      • 可以用文件指定的另一个rc替换一个rc。

      • 没有明确支持回滚,可以通过滚动更新到旧版本来完成。

      • 我们在rcs上保留注释,以跟踪所需的#个实例;对于回滚情况b / c不对称将不起作用。

    • 需要不可变的图片ID;当前没有对应于图片版本的uuid,因此如果有人将其顶到顶部,您将重新拉动它;在API服务器中,我们应该将图像转换为uuid(尽可能靠近边缘)。

    • 自动生成新的rc而不是让用户更新它会很好(例如,当更改容器的图片标签等时;当前需要更改rc名称和标签值;可以自动生成新的rc)。

    • 将rcs视为宠物还是牛。

    • “将我从v1滚动到v2”(或从v2滚动到v1)-对大多数人来说足够好。不在乎过去发生的记录。

    • 我们提供ansible可以调用的模块以使某些事情发生。

    • 您如何跟踪多个模板;今天,我们使用多个RC。

    • 如果我们有部署控制器;部署配置生成运行滚动更新的pos;触发器是图像存储库的基于级别的更新。

    • 替代性的短期建议:创建新的rc作为旧副本的副本,将具有计数的futz创建为旧副本和vv,将先前命名的一个(pet)降低为零,并使用新模板将其备份(这非常类似于Borg的工作更新)。

      • 如果我们还是想进行部署,那值得吗?是的,我们已经有了很多概念;需要简化。
    • Deployment Controller跟踪多个模板,这是滚动更新和Canary所需的。

    • 新事物的唯一原因是将进程移入服务器而不是客户端?

    • 可能不需要使其成为API对象;应该提供的经验不是API对象,而仅仅是客户端。

    • 现在需要经验,因此需要在客户端中进行,因为对象不会在1.0之前降落。

    • 为只想使用RC的人提供了简化的体验。

    • 回滚如何工作:ctrl-c,推出v2 v1。回滚模式可以在人的脑海中。 2种回滚:我处于稳定状态并想返回,并且我已经进行了Canary部署并按ctrl-c来摆脱Canary部署(例如new失败)。 ctrl-c可能不起作用。删除金丝雀控制器及其吊舱。希望有一个命令也可以删除pod(有-kbectl stop)。不重用名称的论点:当您移动fwd时,您可以停止新的操作,并且没问题,vs。如果您替换旧的并且创建了一个副本(如果您按ctrl-c键,则表示您没有任何内容)可以停下来但是您可以等到将名称翻转到末尾,使用命名约定,这样才能弄清楚发生了什么,等等。

    • two different experiences: (1) i'm using version control, have version history of last week rollout this week, 滚动更新 with two files -> create v2, ??? v1, don't have a pet - moved into world of version control where have cumulative history and; (1) imperative kubectl v1 v2 where sys takes care of details, that's where we use the snapshot pattern.

  • 其他命令性命令

    • run-container(或刚刚运行):命令行上的spec命令,使其与docker run更相似;但不是多容器吊舱。

    • --forever vs.not(通过简单的命令执行一次)。

    • 希望它是交互式的-运行-并在群集中运行,但是您的进程具有交互式终端。

    • 命令行参数如何工作。可以多次说--image。眼镜蛇会支持吗?在openshift中,我们有巧妙的语法将参数分组在一起。不适用于真正的结构化参数。

    • 替代方法:创建广告连播;添加容器添加容器...;运行pod-建立并在``运行pod''之前不运行对象。

      • -分隔容器参数。

      • 创建一个pod,在运行它之前先对其进行突变-类似于初始化程序模式。

  • 种类发现

    • 如果我们运行了,有时创建了一个rc,有时却没有,那么如果用户想删除他们用run创建的内容,用户如何知道要删除的内容。

    • bburns有建议,如果您执行诸如stop,delete之类的命令,则不要指定种类;让kubectl弄清楚。

    • 替代方法:允许您从名称到资源类型集定义别名,例如。删除所有跟随该别名的内容(所有内容可能意味着某个名称空间中的所有内容,或者没有作用域的名称,等等)-有人明确地向集合中添加了某些内容,而意外显示为节点。

    • 希望看到扩展允许工具指定自己的别名(而不仅仅是用户);例如调整大小可以说我可以处理RC,删除可以说我可以处理所有内容,等等,因此我们可以自动执行这些操作,而无需用户指定内容。但机制正确。

    • resourcebuilder has concept of doing that kind of expansion depending on how we fit in targeted commands. for instance if you want to add a volume to pods and rcs, you need something to go find the pod template and change it. there's the search part of it (delete nginx -> you have to figure out what object they are referring to) and then command can say i got a pod i know what to do with a pod.

    • alternative heuristic: what if default target of all commands was deployments. kubectl run -> deployment. too much work, easier to clean up existing CLI. leave door open for that. macro objects OK but a lot more work to make that work. eventually will want index to make these efficient. could rely more on swagger to tell us types.

2.保罗/向下API:环境替代

  • 创建类似于字符串的临时环境变量,例如k8s_pod_name会被系统中的对象所取代。
  • 允许人们创建环境变量,该环境变量从其容器内部引用k8s对象的字段而无需查询api;在某些情况下,可以从其容器中启用查询api(例如,传递obj名称,名称空间);例如sidecar容器需要此容器才能从api服务器中提取内容。
  • 另一个类似的建议:代替类名称的env var,而使用类似JSON路径的语法来引用对象字段名称;例如$。 元数据名称 引用当前对象的名称,可能具有一些语法来引用相关对象,例如吊舱所在的节点。类似于JSON路径的语法的优点是它不那么特别。缺点是您只能引用属于对象字段的事物。
  • 对于这两种方法,如果填充env vars,则存在缺点,即仅在创建容器时才设置字段。但耦合度最低-容器即用型,容器不需要知道如何与k8s API通讯。将k8s概念保留在控制平面中。
  • 我们正在集中在JSON之类的方法上。但需要原型或至少更深入的建议进行演示。
  • 保罗:除了值字段具有不同的来源之外,还有一种用于环境变量的变量,您可以在其中插入例如用于描述对象字段的语法;另一个来源将是描述有关主机的信息的来源。有部分原型。图像和控制平面之间的清晰分隔。可以将源创意用于批量插件。
  • 用例:为Sidecar容器提供信息以联系API服务器。
  • 用例:传递唯一标识符或使用UID作为唯一标识符之类的东西。
  • clayton:针对火箭或gce元数据服务可用于每个吊舱,用于处理更复杂的事情;大多数容器都想找到服务的终点。

3.前提条件/依赖关系

  • 当您创建与服务对话的Pod时,仅当您以正确的顺序创建obj时,才会填充服务环境变量。如果您使用dns,则问题不大,但某些应用程序很脆弱。如果它们所依赖的svc不存在,可能会崩溃,可能需要很长时间才能重新启动。建议具有阻止启动Pod的先决条件,直到它们依赖的obj存在。
  • 如果我们要求人们声明他们想要哪个环境变量,或者在pod或rc或obj级别具有dep mech来自动推断,则表明该obj在其他东西存在之前不会变为活动状态。
  • 可以使用事件钩子吗?只有应用程序所有者知道他们的依赖关系或服务准备就绪的时间。
  • 一种建议是使用启动前挂钩。另一个是前提探测器-预启动挂钩可以进行探测。当我按下此svc地址或ip时,没有任何响应,然后探测失败。可以在启动前挂钩中实现。比启动后有用。是rkt规范的一部分。现在有阶段0、1、2。今天在docker中很难做,在火箭中很容易。
  • 容器中的pre-start钩子:将如何影响就绪探测器,因为如果使用prestart钩子实现,容器可能会锁定直到满足某些任意条件。如果您有钩子,那么当kubelet运行就绪/活动探测器时,必须进行一些补偿。 Systemd在进程生命周期的各个阶段都有超时。
  • 如果我们转到容器的黑匣子模型,则预启动是有意义的;如果容器规范变得对systemd之类的流程模型更具描述性,那么kubelet是否需要更多地了解流程模型才能做正确的事情。
  • 理想情况下,从容器内部味精说我已经完成了所有预启动操作。 sdnotify for systemd这样做。您告诉systemd您已完成操作,它将与您还活着的其他部门进行沟通。
  • 但是...某人可以在其容器中实现前置条件。无需更改图片即可轻松适应应用。另一种选择是只有一种模式,他们如何自己做,但我们不为他们做。