<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Dan Baskette | 伪架构师</title>
    <link>/authors/dan-baskette/</link>
      <atom:link href="/authors/dan-baskette/index.xml" rel="self" type="application/rss+xml" />
    <description>Dan Baskette</description>
    <generator>Source Themes Academic (https://sourcethemes.com/academic/)</generator><language>zh</language><lastBuildDate>Thu, 20 Sep 2018 17:13:03 +0800</lastBuildDate>
    <image>
      <url>/img/logo-wide.png</url>
      <title>Dan Baskette</title>
      <link>/authors/dan-baskette/</link>
    </image>
    
    <item>
      <title>Knative：在 Kubernetes 上构建可移植 Serverless 平台</title>
      <link>/post/knative-enables-portable-serverless/</link>
      <pubDate>Thu, 20 Sep 2018 17:13:03 +0800</pubDate>
      <guid>/post/knative-enables-portable-serverless/</guid>
      <description>

&lt;p&gt;原文：&lt;a href=&#34;https://thenewstack.io/knative-enables-portable-serverless-platforms-on-kubernetes-for-any-cloud/&#34; target=&#34;_blank&#34;&gt;Knative Enables Portable Serverless Platforms on Kubernetes, for Any Cloud&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;作者：&lt;a href=&#34;https://thenewstack.io/author/dan-baskette/&#34; target=&#34;_blank&#34;&gt;Dan Baskette&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&#34;https://kubernetes.io/&#34; target=&#34;_blank&#34;&gt;Kubernetes&lt;/a&gt; 目前如日中天，这一项目不仅在容器编排方面独占鳌头，还给基础设施自动化进程提供了可实践的原语。&lt;/p&gt;

&lt;p&gt;但是我们注意到，开发团队在进行基于 Kubernetes 的应用部署时常有困扰。Kubernetes 毕竟只会推送容器——要想推送应用代码或者 Function，很明显就不是 Kubernetes 的能力所在了。&lt;/p&gt;

&lt;p&gt;这样一来，就有不少厂商以 K8S 作为基础设施，展开了高级抽象方面的竞争。这也是 &lt;a href=&#34;http://github.com/knative&#34; target=&#34;_blank&#34;&gt;Knative&lt;/a&gt; 的着眼点。&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;a href=&#34;https://twitter.com/kelseyhightower&#34; target=&#34;_blank&#34;&gt;Kelsey Hightower&lt;/a&gt;：Kubernetes 是一个用来构建平台的平台。它是起跑线，不是目的地。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;h2 id=&#34;function-是值得注意的下一次抽象&#34;&gt;Function 是值得注意的下一次抽象&lt;/h2&gt;

&lt;p&gt;读者可能已经注意到分布式系统世界的新晋成员：FaaS（Functions/Serverless）。Function 是一种新的抽象方式，让开发人员能够轻松的运行部署代码片段，并具备根据事件进行伸缩的能力。&lt;/p&gt;

&lt;p&gt;这对开发人员来说是非常有吸引力的。为什么？把所有的基础设施和应用启动之前的事件处理都抽象之后，开发人员能够完全专注于解决如何使用 Function 的代码处理事件的问题。&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://storage.googleapis.com/cdn.thenewstack.io/media/2018/07/26b7e88b-danb1.png&#34; alt=&#34;抽象策略&#34; /&gt;&lt;/p&gt;

&lt;p&gt;天下自然是没有免费的午餐了，FaaS 的问题在哪里呢？&lt;/p&gt;

&lt;p&gt;市场上有很多 FaaS 方案，每个都是独一无二的，他们有自己的 Function 触发方式，自己的可接受事件格式范围，独特的伸缩功能以及从各自角度触发，为开发人员作出的各种抽象。&lt;/p&gt;

&lt;p&gt;如果有要用到的抽象，可以寄希望于云供应商将其打包并为你提供服务。Azure Functions、Lambda 以及 Google Cloud Function 就是这样工作的：根据事件运行 Function 代码，按需伸缩。这类产品按照用量进行计费——根据调用量收取费用。&lt;/p&gt;

&lt;p&gt;开源社区的开发者们也加入了 FaaS 的盛宴，OpenFaaS、Fission、Kubeless 以及 Project Riff 这些项目都是构建在 Kubernetes 之上的 FaaS。这一共同的基础，也有了大同小异的产品。&lt;/p&gt;

&lt;p&gt;在三个核心领域，每个项目都有些许差异：&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;都有自己的构建服务，也就是把 Function 进行容器式构建和部署的功能。&lt;/li&gt;
&lt;li&gt;都有一种按调用需要进行扩容（或者缩容）的实现。&lt;/li&gt;
&lt;li&gt;都提供了根据事件调用 Function 的能力，事件可能是 HTTP 或者是事件中间件的发布、订阅方式。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;这些细微差异会造成平台采用的巨大障碍。在企业开发者眼里，这一领域功能破碎，竞品众多。所以只能静观其变。&lt;/p&gt;

&lt;h2 id=&#34;knative-适时出现&#34;&gt;Knative 适时出现&lt;/h2&gt;

&lt;p&gt;Google 看到这种碎片化的现状，也注意到了开发人员在 Kubernetes 上进行 Function 开发的过程中对通用工具集的需求。&lt;a href=&#34;http://pivotal.io/knative&#34; target=&#34;_blank&#34;&gt;Knative&lt;/a&gt; 就是基于这种需求产生的。&lt;/p&gt;

&lt;p&gt;Knative 是一个开源软件层，帮助云服务供应商和企业平台在任意云上为开发者提供 Serverless 体验。&lt;/p&gt;

&lt;p&gt;Pivotal 也身在其中，不但向 Knative 贡献了来自 &lt;a href=&#34;https://projectriff.io/&#34; target=&#34;_blank&#34;&gt;riff&lt;/a&gt; 项目的事件模型，还和 Google 一起，在其它方面贡献了开发人员和代码。我们为这一项目的未来欢欣鼓舞，将 riff 和 Knative 结合在一起，酝酿成我们的新项目 &lt;a href=&#34;https://pivotal.io/platform/pivotal-function-service&#34; target=&#34;_blank&#34;&gt;Pivotal Function Service&lt;/a&gt;。&lt;/p&gt;

&lt;p&gt;所以对于 Knative 来说，还需要知道点什么呢？这个项目使用 Kubernetes 作为容器编排层。它使用大家熟知的 Kubernetes 对象（Pod、Replica Set 以及 Deployment）构建应用。Istio？是的，Knative 使用 Istio 来进行网格内的路由以及 Ingress 入口管理。&lt;/p&gt;

&lt;p&gt;但是仅仅有 Kubernetes 和 Istio 还是不够的。因此 Knative 同时还引入了三个松耦合的组件，协同对外提供一个完整的 Serverless 平台：Build、Eventing 以及 Serving。&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Build：提供了一个可插入模型，用于从源码构建容器。&lt;/li&gt;
&lt;li&gt;Eventing：让应用或者 Function 发布到或订阅事件流，事件流包括 Google Cloud Pub/Sub 以及 Apache Kafka。&lt;/li&gt;
&lt;li&gt;Serving：为应用或 Function 提供运行和扩容以及缩容至 0 的能力。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;上述元素融合形成的 Knative 又有何神通？它提供了一种较为简化的部署和运行 function 的方式，包括这些模式：&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;从源码构建应用和 Function。&lt;/li&gt;
&lt;li&gt;包含多种构建方法（Cloud Foundry Buildpacks、Bazel、Kaniko、Dockerfiles，并可以扩展支持其他方式）。&lt;/li&gt;
&lt;li&gt;开发者能够轻松部署新的（可路由的）应用和 Function。&lt;/li&gt;
&lt;li&gt;允许应用的不间断升级。&lt;/li&gt;
&lt;li&gt;应用实例的自动伸缩。&lt;/li&gt;
&lt;li&gt;把事件绑定到 Function、应用或者容器上。&lt;/li&gt;
&lt;li&gt;当发生 HTTP 请求时触发 Function。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;稍微深入一点看看这几个组件。&lt;/p&gt;

&lt;h2 id=&#34;build-源码到容器的弹性和可扩展过程&#34;&gt;Build：源码到容器的弹性和可扩展过程&lt;/h2&gt;

&lt;p&gt;开发人员编写源码。Kubernetes 操作容器。如何完成联动？Cloud Foundry 使用 buildpack 来完成这一场景。Knative 提供一个插件模型来完成从代码到容器的构建过程。这一模型通过 CRD 实现，也就是一组 Kubernetes API 对象。这种方式提供了一个构建块，能够作为一个 CI/CD 之类的更大系统的一部分，完成源码的构建。&lt;/p&gt;

&lt;p&gt;Knative 的 Build 组件包含 4 个主要组成部分。&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;描述如何获取待构建的源码。位置在 &lt;code&gt;/workspace&lt;/code&gt; 卷中存储，这个内容会在后面的步骤中沿用。通常情况下，源码会保存在 git gcs 之类的版本控制系统中，也可以用自定义容器来访问源码。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;步骤或模板&lt;/strong&gt;：这是构建容器的实际工作。这个过程简单说来就是根据 Build 规范完成一系列步骤。换句话说，这一过程由一组可插接构建器组成，被设计用来从源码构建容器，目前这个模型支持五种构建模板，提供了可共享的构建过程：&lt;a href=&#34;https://docs.cloudfoundry.org/buildpacks/&#34; target=&#34;_blank&#34;&gt;Cloud Foundry Buildpacks&lt;/a&gt;、&lt;a href=&#34;https://cloud.google.com/container-builder/docs/&#34; target=&#34;_blank&#34;&gt;Google Container Builder&lt;/a&gt;、Bazel、Kaniko 以及 Jib。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Service Account&lt;/strong&gt;：用来运行构建过程的账号。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;存储卷&lt;/strong&gt;：可以定义多个卷，来提供对构建步骤的支持。这些卷可以有很多用途，例如共享 Secret 或者在多个步骤间提供缓存。&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;serving-按需伸缩以及版本为基础的高级运维&#34;&gt;Serving：按需伸缩以及版本为基础的高级运维&lt;/h2&gt;

&lt;p&gt;自动化升级了开发者的工作流。Serving 的自动化范围覆盖了从容器到运行中的 Function 部分。它还提供了容器的快速部署，以及根据进入请求完成扩容到 N 或缩容到 0 的能力支持。Istio 在版本之间进行路由，这使得不间断升级、蓝绿部署、金丝雀测试以及回滚都成为了可能。&lt;/p&gt;

&lt;p&gt;Serving 包含了四个 CRD：&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;管理应用和 Function 的生命周期以及提供控制点。它可以处理对象的生成，来保障应用或者 Function 的任何版本更新都具备网络路由、配置以及版本支持。&lt;/li&gt;
&lt;li&gt;代码和配置的固定快照。一个版本会引用一个容器以及创建这个容器所需的内容。历史中可以包含多个版本，这样就能够支持一些蓝绿部署或者回退之类的高级运维工作。&lt;/li&gt;
&lt;li&gt;网络端点到一或多个应用版本的映射。&lt;/li&gt;
&lt;li&gt;定义了部署的最新版本以及各版本的状态。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;img src=&#34;images/7346ed16-danb2.png&#34; alt=&#34;serving&#34; /&gt;&lt;/p&gt;

&lt;h2 id=&#34;eventing-把订阅-发布操作进行抽象-简化开发人员工作&#34;&gt;Eventing：把订阅/发布操作进行抽象，简化开发人员工作&lt;/h2&gt;

&lt;p&gt;Function 的基本存在价值就是用来响应事件。FaaS 项目和受管服务的区别就是事件的接收以及消费方式。Knative Eventing 组件用来对事件系统的后端进行抽象，从而解放开发人员。开发人员无需了解消息平台、不用关注数据复制等问题。&lt;/p&gt;

&lt;p&gt;Knative 提供了 CRD 用于事件的生产和消费。Eventing 组件由两类 CRD 组成：&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Channel&lt;/strong&gt;

&lt;ul&gt;
&lt;li&gt;发布/订阅模型中发布者发送消息的目标。一般来说，Channel 是一组位置用于获取或存储事件。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Bus&lt;/strong&gt;：Channel 的后端。这是为事件提供消息平台支持的底层，可以是 Google Cloud PubSub、Apache Kafka 以及 RabbitMQ 等。&lt;/li&gt;
&lt;li&gt;这些结合起来告知 Knative 服务，特定 Channel 的消息会被哪个应用或者 Function 消费。这是应用和 Function 的入口地址。&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Feeds&lt;/strong&gt;：事件携带的附件。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;img src=&#34;images/88636989-danb3.png&#34; alt=&#34;eventing&#34; /&gt;&lt;/p&gt;

&lt;h2 id=&#34;试用你能掌控的最高级抽象&#34;&gt;试用你能掌控的最高级抽象&lt;/h2&gt;

&lt;p&gt;Knative 是一个全新事物，但是已经有了很多资源可供学习和参考。企业开发软件数量暴涨，意味着典型情况下，公司都会谋求试用应用平台、容器编排以及 Function。Pivotal 希望在所有不同抽象中驱动开源软件的发展。Cloud Foundry、Kubernetes 以及 Knative 会成为大公司的软件构建和运行过程中的主要推手。&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/knative/docs&#34; target=&#34;_blank&#34;&gt;Knative 文档&lt;/a&gt;是该项目的主要信息源。每个组件都在仓库中有自己的一席之地，让用户可以跟进最新进展。&lt;/li&gt;
&lt;li&gt;可以阅读 &lt;a href=&#34;https://content.pivotal.io/blog&#34; target=&#34;_blank&#34;&gt;Pivotal 博客&lt;/a&gt;，Ryan Morgan 在其中发布了关于 Pivotal 在 Knative 项目中贡献的相关内容，会涉及企业应用 Serverless 的更多案例。&lt;/li&gt;
&lt;li&gt;在 Google Cloud 也有很多资料：

&lt;ul&gt;
&lt;li&gt;Knative &lt;a href=&#34;https://cloud.google.com/knative&#34; target=&#34;_blank&#34;&gt;概览页面&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Knative &lt;a href=&#34;https://cloudplatform.googleblog.com/2018/07/bringing-the-best-of-serverless-to-you.html&#34; target=&#34;_blank&#34;&gt;博客&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;如果想要知道 &lt;a href=&#34;https://projectriff.io/&#34; target=&#34;_blank&#34;&gt;riff 项目&lt;/a&gt; 的信息，官方网站是最好的起步地点。其中包含了所有的文档和对 &lt;a href=&#34;https://github.com/projectriff/riff&#34; target=&#34;_blank&#34;&gt;riff 仓库&lt;/a&gt;的引用。&lt;/li&gt;
&lt;li&gt;想要了解更多？&lt;a href=&#34;https://springoneplatform.io/2018/sessions&#34; target=&#34;_blank&#34;&gt;SpringOne 平台有一套 Serverless 课程&lt;/a&gt;。&lt;/li&gt;
&lt;/ul&gt;
</description>
    </item>
    
  </channel>
</rss>
