书名：Knative快速入门与实践
ISBN：978-7-115-56286-9
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [美] 伯尔·萨特 (Burr Sutter)
[印度] 卡梅什·桑帕斯 (Kamesh Sampath)
译 杨云锋 赵吉壮
责任编辑 武晓燕
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © 2020 by O’Reilly Media. All rights reserved.
Simplified Chinese Edition, jointly published by O’Reilly Media, Inc. and Posts & Telecom Press.,Ltd, 2020. Authorized translation of the English edition, 2020 O’Reilly Media, Inc., the owner of all rights to publish and sell the same.
All rights reserved including the rights of reproduction in whole or in part in any form.
本书中文简体版由 O’Reilly Media, Inc. 授权人民邮电出版社有限公司出版。未经出版者书面许可，对本书的任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。
Knative是由谷歌发起的，它的目标是基于Kubernetes为整个开发生命周期提供帮助。
本书介绍了如何在实际的企业应用程序开发过程中使用Knative。本书首先介绍了如何有效地构建、部署和管理现代Serverless工作负载；然后讲解了在实际的企业场景中应用Knative（包括高级事件）的方法；接着介绍了如何有效监控Knative Serverless应用程序；之后介绍了将Knative与CI/CD原则集成的方法，例如使用channel（管道）进行更快、更成功的生产部署。本书共有7章，从多个方面介绍了Knative在Kubernetes中的应用。
本书适合对Kubernetes核心概念有深入了解并希望通过Knative构建实际应用程序的架构师和开发人员阅读。
O’Reilly以“分享创新知识、改变世界”为己任。40多年来我们一直向企业、个人提供成功所必需之技能及思想，激励他们创新并做得更好。
O’Reilly业务的核心是独特的专家及创新者网络，众多专家及创新者通过我们分享知识。我们的在线学习（Online Learning）平台提供独家的直播培训、图书及视频，使客户更容易获取业务成功所需的专业知识。几十年来，O’Reilly图书一直被视为学习开创未来之技术的权威资料。我们每年举办的诸多会议是活跃的技术聚会场所，来自各领域的专业人士在此建立联系，讨论最佳实践并发现可能影响技术行业未来的新趋势。
我们的客户渴望做出推动世界前进的创新之举，我们希望能助他们一臂之力。
“O’Reilly Radar博客有口皆碑。”
——Wired
“O’Reilly凭借一系列非凡想法（真希望当初我也想到了）建立了数百万美元的业务。”
——Business 2.0
“O’Reilly Conference是聚集关键思想领袖的绝对典范。”
——CRN
“一本O’Reilly的书就代表一个有用、有前途、需要学习的主题。”
——Irish Times
“Tim是位特立独行的商人，他不光放眼于最长远、最广阔的领域，并且切实地按照Yogi Berra的建议去做了:‘如果你在路上遇到岔路口，那就走小路。’回顾过去，Tim似乎每一次都选择了小路，而且有几次都是一闪即逝的机会，尽管大路也不错。”
——Linux Journal
早在2009年，UC Berkeley实验室就对云计算的未来做过一次预测，预测未来云计算将会快速增长，现在来看这些预测一一得到了验证。对于云计算的第二个阶段，UC Berkeley实验室也做了预测与解读，在2020年的预测中就提到，“Serverless计算是云计算的下一个阶段，Serverless最重要的三个特征：隐藏了服务器的复杂概念、按需付费和弹性伸缩。届时，Serverless将会改变我们对于计算机的看法。Serverless带来的转变就像租车到打车一样。”
对于Serverless的探索，最早源于AWS的Lambda。国外的Serverless生态比较好，不少公司一开始就是基于Lambda来创业的，然后国内一些大厂开始陆续使用Serverless平台和工具，不过大部分公司处于观望状态。当前Serverless领域存在的问题也比较明显：现在还没有统一的Serverless标准，各大厂都在建设自己的Serverless平台，这也导致了厂商锁定的问题，业务代码不能平滑地迁移到其他平台。
对于厂商锁定的问题，比较通用的解决方案是借助标准的Serverless平台。基于标准化平台开发的函数可以方便地发到各个云计算平台，Knative应运而生。
Knative是谷歌发起的基于Kubernetes平台的Serverless开源项目，致力于将Serverless标准化。Knative是当今云原生生态领域发展最快的开源项目之一，谷歌内部的Google Cloud Run就是基于Knative研发的。相对于Kubernetes入门门槛高的问题，Knative正好可以解决“开发人员希望专注于开发应用程序，而不是解决部署和操作”的问题。
本书可以算是Knative的“入门与实践”，书中包含了大量的示例，每个示例都由问题、解决方案和带有详细解释的讨论三部分构成。如果你是一名架构师或者开发人员，对Kubernetes核心内容有一定的理解，并且希望用Knative构建真实的应用，那么这本书是适合你的。
我要感谢我的好朋友杨云锋，杨老师对于技术的热情深深打动了我，没有杨老师的鼎力协助、共同翻译，就不会有本书的出版。还要感谢人民邮电出版社的编辑武晓燕，她对于本书的编辑与审核做了很多的工作。
本书在翻译过程中难免会有一些错误和问题，还希望各位读者批评指正。如果您觉得翻译有任何错误和问题，请您及时反馈给我或出版社，以便及时进行修订。
希望本书能对那些想了解、学习和研究Knative以及Serverless平台的人有所帮助。
赵吉壮 2021年2月于浙江杭州
在云原生应用部署中，Serverless 架构正受到越来越多的关注。企业开始关注到Serverless应用给它们带来的价值，比如敏捷开发、快速部署和资源消耗的优化。和其他新技术一样，Serverless技术有多种实现方法，比如函数即服务（Function as a Service，FaaS）和后端即服务（Backend as a Service，BaaS）。这些实现方法都运行在临时容器中，并且有自动扩缩容的能力。
创建Knative的初始目标非常简单，即通过它在Kubernetes原生平台上构建、部署和管理Serverless工作负载。Kubernetes解决了很多云原生应用的问题，但它本身还比较复杂，尤其在部署应用时。使用Kubernetes部署简单的服务，开发者不得不写两个YAML文件（比如Deployment和Service），然后还需要其他必要的操作才能向外界暴露服务。这些复杂度往往会导致应用开发人员花费更多的精力去构建YAML文件和其他运维操作，而不是关注业务本身。
Knative通过更简单的部署模型来提供所有必要的原生中间件，以解决Kubernetes部署问题。在Knative中，我们可以部署任何常用的应用负载，比如单体应用、微服务，甚至小型函数。我们可以在任何有Kubernetes的云平台上运行Knative。在企业运行Serverless工作负载时，使用Knative能够避免云厂商的锁定，Knative的使用也会更加灵活、方便。
事实上，Serverless有许多种实现方法，这也使开发者十分困惑。我们可以思考如下几个问题：
在开始探索Serverless技术时，我们遇到了同样的问题。对这些问题和挑战的研究，促使我们写了本书。本书提供详细的示例，它可以作为实践指导来帮助读者解决这些难题。
本书被称为“入门与实践”，是因为我们在书中构建了大量的示例，每个示例由问题、解决方案和讨论 3 个部分构成。目前我们提供的示例不太可能覆盖所有的Serverless方法，因此我们决定选用BaaS。Knative作为原生Kubernetes平台支持的组件，可以帮助我们用BaaS的方式来运行服务。
如果你是一名架构师或者是开发人员，对Kubernetes核心内容有一定的理解，并且希望使用Knative来构建真实的应用，那么这本书是你的不二之选。
该图标表示提示或者建议。
该图标表示一般注解。
该图标表示警告或者注意事项。
本书配套的源代码可以从GitHub上下载，也可以直接下载ZIP压缩文件，还可以在本地使用git命令来复制这个项目，如下所示：
$ git clone -b knative-cookbook
***://github. ***/ redhat-developer-demos /knative-tutorial原书中使用的Knative版本是0.12，本书撰写时Knative的最新版本是0.18。$BOOK_HOME是用户本地计算机上指向包含代码例子源代码目录的环境变量。
如果在使用代码例子过程中遇到相关技术问题，请发送邮件到bookquestions@oreilly.com。
本书的目的是帮助读者完成工作。一般而言，你可以在你的程序和文档中使用本书中的代码，而且也没有必要取得我们的许可。但是，如果你要复制的是核心代码，则需要和我们打个招呼。例如，你可以在无须获取我们许可的情况下，在程序中使用本书中的多个代码块。但是，销售或分发O’Reilly图书中的代码则需要取得我们的许可。通过引用本书中的示例代码来回答问题时，不需要事先获得我们的许可。但是，如果你的产品文档中融合了本书中的大量示例代码，则需要取得我们的许可。
在引用本书中的代码示例时，如果能列出本书英文原书的属性信息是最好不过（但不是必需的）。属性信息通常包括书名、作者、出版社和ISBN。例如：“Knative Cookbook by Burr Sutter and Kamesh Sampath (O’Reilly). Copyright 2020 O’Reilly Media Inc., 978-1-492-06119-9.”
在使用书中的代码时，如果不确定是否属于正常使用，或是否超出了我们的许可，请通过permissions@oreilly.com与我们联系。
如果你的代码示例使用超出了惯例或者以上许可，欢迎使用电子邮件permissions@oreilly.com联系我们。
尽管我们已经尽力在本书中使用Knative最新版本，但Knative目前更新速度非常快。为了跟上Knative最新技术的发展，我们建议你关注Knative社区和Red Hat维护更新的Knative Tutorial。
我们还为本书建立了一个网页（官方网站），其中包含了勘误表、示例和其他额外的信息。
关于本书的技术性问题或建议，请发邮件到：bookquestions@oreilly.com。
欢迎登录我们的网站，查看更多我们的图书、课程、会议和最新动态等信息。
非常感谢我们的审稿人！他们提供了有价值的反馈、建议，以及一些场景下的备用解决方法。他们还指出我们忽略的问题，从而大大提高了本书的质量。本书出现任何错误或者疏漏都是我们造成的，而不是审稿人。表现他们聪明才智的很好的例子就是正确地观察“那句话不知道是该删除还是保留”。
感谢罗兰·赫斯（Roland Huss）、马西亚斯·韦森多夫（Matthias Wessendorf）、妮古拉·费拉罗（Nicola Ferraro）和文森特·德梅斯泰（Vincent Demeester）。特别感谢红帽工程师团队的本·布朗宁（Ben Browning）、马库斯·托默森（Markus Thömmes）和威廉·马尔基特（William Markito）。
感谢O'Reilly整个团队，没有他们，这本书就不会顺利出版。非常感谢我们的编辑杰夫·布莱尔（Jeff Bleiel）和萨拉·格雷（Sarah Grey）为本书的出版所付出的努力。
• 伯尔·萨特
首先，我要感谢卡梅什·桑帕斯（本书的绝大部分工作由他完成），感谢他提供的广泛的技术知识和洞察力，感谢他在研究、调试、使用和记录像Knative这样的新技术时付出的不懈努力和决心。他的付出也使得开发者可以以更简单的方式从社区中获取新技术。
感谢我每天都在参加的那些不可思议的全球开发者社区，其中有许多人为获取知识和机会做出了巨大的努力。毫无疑问，这些人会继续成为真正的数字英雄、影响者、变革推动者、时代创造者和重新定义未来世界的人。他们的努力提醒我，想要变得伟大和对未来有影响，不仅要有才能，还要有坚定的决心和对学习、想象、创造和掌控的渴望。作为一名开发人员，有机会为云原生的未来做出贡献，是我此生之幸。
• 卡梅什·桑帕斯
感谢该项目中的另外一名成员，也是我的导师、经理和合著者伯尔·萨特。他的经验和指导不仅帮助这本书成形，并让我能够从不同的角度获得提高。
感谢Red Hat和Red Hat Developer给我编写本书的机会。
感谢我的妻子对我的大力支持，没有她，我将不会完成此书。另外，我也需要借此机会感谢我的儿子。他不理解我在写什么，但他对此充满了好奇：“爸爸，您的书在哪儿能看到？”或“这本书快写完了吗？”他用特定的笑容给我鼓励。
最后，我想感谢所有阅读本书的开发人员。没有读者和“开发者社区”，我们永远不会想到写这本书。
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
本书提供如下资源：
要获得以上配套资源，请在异步社区本书页面中单击
，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入信息，单击“提交”按钮即可。本书的作者和编辑会对您提交的错误信息进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近40年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
将应用程序部署为Serverless正成为一种流行的架构体系。很多组织认为函数即服务（FaaS）就是Serverless。作者认为下面这个说法可能更准确：FaaS是构建Serverless的一种方法，但不是唯一的方法。对于拥有微服务或者庞大单体应用的企业来说，这引出了一个十分严峻的问题：部署Serverless应用程序最简单的方法是什么？
答案是拥有一个能运行Serverless工作负载的平台，这个平台能够配置、构建、部署并运行应用程序。在理想情况下，该平台最好支持容器化部署（例如Docker）。本章将介绍这样一个平台：Knative。该平台可以帮助用户以Kubernetes原生的方式来运行Serverless工作负载。
Kubernetes集群不会预装Knative及其依赖组件，因此本章的示例会详细介绍如何在Kubernetes集群中安装Knative及其依赖组件。这些示例也会帮助读者搭建本地的开发环境，本书所有的示例都基于此开发环境。
搭建本地开发环境来部署和运行基于Kubernetes的Serverless应用程序。
macOS、Fedora系统和Windows操作系统需要安装的常用开源工具包括：
dnf install docker；brew install stern；brew install httpie，Fedora系统上的安装代码为dnf install httpie；brew install watch，Fedora系统上的安装代码为dnf install procps-ng；brew install kubectx。
在学习接下来的内容前，请确保已经把上述所列的工具添加到$PATH中。
下面列出了需要安装的开源工具的最低版本和推荐版本。
以下所列的版本是本书撰写时测试通过的版本。更高版本的组件理应与本书中使用的示例保持向前兼容性。
Git
Git是目前主流的版本控制工具：
$ git version
git version 2.21.0Docker
运行Linux容器的客户端：
$ docker --version
Docker version 19.03.5, build 633a0eaKubectl
Knative要求Kubernetes的最低版本为1.15，本书推荐使用Kubernetes v1.15.0。想检查Kubectl版本，可以运行：
$ kubectl version --short
Client Version: v1.15.0
Server Version: v1.15.0Helm
Helm是常用的定义、安装和升级Kubernetes应用程序的包管理工具：
$ helm version
version.BuildInfo{Version："v3.0.2"...}Stern
在Kubernetes上查看多个Pod信息以及Pod中的多个容器：
$ stern --version
stern version 1.11.0yq
一个轻量级的、易用的命令行级YAML处理工具：
$ yq --version
ya version 2.4.1HTTPie
一个很好用的HTTP命令行客户端：
$ http --version
1.0.3hey
一个轻量级的Web性能压测工具。
hey没有版本选项，可以通过hey --help来验证是否已经成功安装到$PATH中。
watch
watch定期执行程序，并且可以全屏展示输出：
$ watch --version
watch from procps-ng 3.3.15kubectx
kubectx可以在集群和命名空间之间快速地切换。
kubectx没有版本选项，可以使用kubectx --help验证它是否在$PATH中。
kubens随kubectx一起安装，可以使用kubens --help验证它是否在$PATH中。
在本地开发环境中搭建Kubernetes集群。
可使用minikube作为本地的Kubernetes集群开发环境。minikube提供了单节点的Kubernetes集群，这也是最适合做本地开发的工具。下载minikube并将其添加到$PATH中。
本书中的所有示例均在minikube v1.7.2和Kubernetes CLI（kubectl）v1.15.0中测试通过。
$BOOK_HOME/bin/start-minikube.sh脚本可帮助用户以正确的配置启动minikube。
minikube环境变量列表及其默认值如下。
PROFILE_NAME
minikube配置文件的名称，默认是knativecookbook。
MEMORY
分配给minikube虚拟机（VM）的内存，默认为8GB。
CPUS
分配给minikube虚拟机的CPU数量，默认为4。
VM_DRIVER
使用的虚拟机驱动程序：
virtualbox；kmv2；hyper–v。VM_DRIVER是必需的环境变量，如果不设置，那么start-minikube.sh脚本会启动失败：
$ $BOOK_HOME/bin/start-minikube.sh
profile "knativecookbook" not found
Created a new profile : knativecookbook
minikube profile was successfully set to knativecookbook
[knativecookbook] minikube v1.6.2 on Darwin 10.15.2
Selecting virtualbox driver from user configuration (alternates: [hyperkit])
Creating virtualbox VM (CPUs=4, Memory=8192MB, Disk=50000MB) ...
Preparing Kubernetes v1.15.0 on Docker 19.03.5 ...
▪ apiserver.enable-admission-plugins=LimitRanger,NamespaceExists,
NamespaceLifecycle,ResourceQuota,ServiceAccount,DefaultStorageClass,
MutatingAdmissionWebhook
Pulling images ...
Launching Kubernetes ...
Waiting for cluster to come online ...
Done! kubectl is now configured to use "knativecookbook"安装私有镜像仓库以便于从镜像仓库推送和拉取容器镜像。
运行下面的指令，在minikube内搭建私有镜像仓库：
$ minikube addons enable registry启用仓库需要几分钟的时间，观察kube-system命名空间下的Pod状态来查看安装进度。
如果镜像仓库启用成功，那么就可以在 kube-system 命名空间中看到两个新的处于运行状态的Pod了：
$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
registry-7c5hg 1/1 Running 0 29m
registry-proxy-cj6dj 1/1 Running 0 29m
...使用自定义域名从私有镜像仓库推送和拉取容器镜像。
本书中的一部分示例要求读者与本地私有镜像仓库进行交互。为了更方便地推送和拉取镜像，本书提供了一个脚本，调用该脚本可以使用一些通用的名称（例如，dev.local和example.*）作为私有镜像仓库的别名。进入帮助程序文件目录并运行以下命令：
$ cd $BOOK_HOME/apps/minikube-registry-helperDaemonSet用于在Kubernetes集群的所有节点中运行Pod的相同副本。运行以下命令以部署注册表帮助程序DaemonSet和ConfigMap，这些配置会被仓库别名脚本使用：
$ kubectl apply -n kube-system -f registry-aliases-config.yaml
$ kubectl apply -n kube-system -f node-etc-hosts-update.yaml
在进行下一步操作之前，我们需要先等待DaemonSet开始运行。读者可以使用命令kubectl get pods -n kube-system – w来监听DaemonSet的状态，并且可以使用Ctrl+C组合键来停止监听。
想查看Docker仓库的域名是否已经加入minikube节点的/etc/hosts文件中，请执行下面的命令：
watch minikube ssh -- sudo cat /etc/hostsDaemonSet成功执行后，会更新minikube节点的/etc/hosts文件。更新后的文件如下：
127.0.0.1 localhost
127.0.1.1 demo
10.111.151.121 dev.local
10.111.151.121 example.***
dev.local和example.*的IP与私有镜像仓库的CLUSTER-IP是一致的。可以运行以下命令来验证这一点：
$ kubectl get svc registry -n kube-system
NAME TYPE CLUSTER-IP PORT(S) AGE
registry ClusterIP 10.111.151.121 80/TCP 178m配置私有镜像仓库的最后一步是修改CoreDNS的ConfigMap，以便集群可以解析以dev.local和example.*开头的容器镜像（例如，dev.local/rhdevelopers/foo:v1.0.0）。运行以下命令来执行脚本：
$ ./patch-coredns.sh要验证脚本是否执行成功，可以执行以下命令来获取kube-system命名空间下名为coredns的ConfigMap的内容：
$ kubectl get cm -n kube-system coredns -o yaml更新成功后coredns的内容如下：
apiVersion: v1
data:
Corefile: |-
.:53 {
errors
health
rewrite name dev.local registry.kube-system.svc.cluster.local ❶
rewrite name example.com registry.kube-system.svc.cluster.local
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
proxy . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
kind: ConfigMap
metadata:
name: coredns❶ rewrite规则会将dev.local解析为私有仓库地址registry.kube-system. svc.cluster.local。
读者可能会有为私有镜像仓库设置其他自定义域名的需求。设置自定义域名的具体方法是：修改名为registry-aliases-config.yaml的ConfigMap，并根据需要添加其他域名。每个域名都需要位于单独的一行中。例如，下面的代码片段显示了如何给注册程序的ConfigMap添加一个名为test.*的自定义域名：
apiVersion: v1
data:
# Add additional hosts separated by new-line
registryAliases: >-
dev.local
example.***
test.***
# default registry address in minikube when enabled
# via minikube addons enable registry
registrySvc: registry.kube-system.svc.cluster.local
kind: ConfigMap
metadata:
name: registry-aliases
namespace: kube-system上述ConfigMap更新后，读者还需要删除kube-system命名空间中的DaemonSet的Pod来重新启动DaemonSet。DaemonSet重新启动时，会从registry-aliases这个ConfigMap中获取新的registryAliases，并将其配置为域名别名。DaemonSet成功重新启动后，请重新运行脚本patch-coredns.sh来更新CoreDNS。
部署入口网关（Ingress Gateway）以调用Knative服务。
Knative 服务模块（Serving）需要部署入口网关，入口网关会将请求路由到Knative服务模块对应的服务。当前，它支持以下基于Envoy的入口网关：
本书示例都会使用Istio作为入口网关。在Istio的各组件中，仅入口网关是Knative服务模块需要的，因此可以使用以下脚本来搭建最小规模的Istio（istio lean）：
$ $BOOK_HOME/bin/install-istio.sh安装Istio组件会花费一些时间，但需要确保Istio相关Pod已成功运行，之后再安装Knative组件。在安装并运行了所有必需的Istio组件和自定义资源（Custom Resource Definition，CRD）之后，安装脚本会自动停止。
Istio的所有CRD资源（具体如下）都在API组中：
要查看CRD资源是否可用，可通过以下命令查询API组中的api-resources来进行验证：
$ kubectl api-resources --api-group=networking.istio.io
NAME APIGROUP NAMESPACED KIND
destinationrules networking.istio.io true DestinationRule
envoyfilters networking.istio.io true EnvoyFilter
gateways networking.istio.io true Gateway
serviceentries networking.istio.io true ServiceEntry
sidecars networking.istio.io true Sidecar
virtualservices networking.istio.io true VirtualService
$ kubectl api-resources --api-group=config.istio.io
NAME APIGROUP NAMESPACED KIND
adapters config.istio.io true adapter
attributemanifests config.istio.io true attributemanifest
handlers config.istio.io true handler
httpapispecbindings config.istio.io true HTTPAPISpecBinding
httpapispecs config.istio.io true HTTPAPISpec
instances config.istio.io true instance
quotaspecbindings config.istio.io true QuotaSpecBinding
quotaspecs config.istio.io true QuotaSpec
rules config.istio.io true rule
templates config.istio.io true template
$ kubectl api-resources --api-group=authentication.istio.io
NAME APIGROUP NAMESPACED KIND
meshpolicies authentication.istio.io false MeshPolicy
policies authentication.istio.io true Policy
$ kubectl api-resources --api-group=rbac.istio.io
NAME APIGROUP NAMESPACED KIND
authorizationpolicies rbac.istio.io true AuthorizationPolicy
clusterrbacconfigs rbac.istio.io false ClusterRbacConfig
rbacconfigs rbac.istio.io true RbacConfig
servicerolebindings rbac.istio.io true ServiceRoleBinding
serviceroles rbac.istio.io true ServiceRoleKnative有两个关键的模块，具体如下。
Knative服务模块提供了简化的部署语法来使服务在Kubernetes集群中运行，并且这些服务具备根据HTTP负载自动扩容或者缩容到零的能力。
Knative事件模块可以将Knative Service和其他的事件流系统（如Apache Kafka主题等）通过非HTTP的方式联系起来。
Knative的安装可以分为三步：
下面会介绍如何安装上述模块。
安装Knative CRD、Knative服务模块和Knative事件模块。
Knative服务模块和Knative事件模块都定义了相关的Kubernetes CRD。读者需要先在Kubernetes集群中安装与Knative服务模块和Knative事件模块相关的CRD。可以运行以下命令来部署：
$ kubectl apply --selector knative.dev/crd-install=true \
--filename "***://github.***/knative/serving/releases/\
download/v0.12.0/serving.yaml" \
--filename "***://github.***/knative/eventing/releases/\
download/v0.12.0/eventing.yaml"现在，Knative服务模块和Knative事件模块的CRD已经成功安装，可以通过查询api-resources来验证CRD，具体如下。
所有Knative服务模块的CRD都在名为serving.knative.dev的API组下面：
$ kubectl api-resources --api-group=serving.knative.dev
NAME SHORTNAMES APIGROUP NAMESPACED KIND
configurations config,cfg serving.knative.dev true Configuration
revisions rev serving.knative.dev true Revision
routes rt serving.knative.dev true Route
services kservice,ksvc serving.knative.dev true Service所有Knative事件模块的CRD都在以下所列的API组中：
messaging.knative.dev；eventing.knative.dev；sources.eventing.knative.dev；sources.knative.dev。$ kubectl api-resources --api-group=messaging.knative.dev
NAME SHORTNAMES APIGROUP NAMESPACED KIND
channels ch messaging.knative.dev true Channel
inmemorychannels imc messaging.knative.dev true InMemoryChannel
parallels messaging.knative.dev true Parallel
sequences messaging.knative.dev true Sequence
subscriptions sub messaging.knative.dev true Subscription
$ kubectl api-resources --api-group=eventing.knative.dev
NAME SHORTNAMES APIGROUP NAMESPACED KIND
brokers eventing.knative.dev true Broker
eventtypes eventing.knative.dev true EventType
triggers eventing.knative.dev true Trigger
$ kubectl api-resources --api-group=sources.eventing.knative.dev
NAME APIGROUP NAMESPACED KIND
apiserversources sources.eventing.knative.dev true ApiServerSource
containersources sources.eventing.knative.dev true ContainerSource
cronjobsources sources.eventing.knative.dev true CronJobSource
sinkbindings sources.eventing.knative.dev true SinkBinding
$ kubectl api-resources --api-group=sources.knative.dev
NAME APIGROUP NAMESPACED KIND
apiserversources sources.knative.dev true ApiServerSource
sinkbindings sources.knative.dev true SinkBindingKnative有两个主要的基础架构组件：控制器（controller）和网络钩子（webhook）。这些组件可以将以YAML文件编写的Knative CRD转换为Kubernetes对象，例如Deployment和Service。除了控制器（controller）和网络钩子（webhook），Knative服务模块和Knative事件模块还安装了各自的功能组件，这些功能组件将在接下来的章节中介绍。
运行以下命令来部署Knative服务模块的基础架构组件：
$ kubectl apply \
--selector \
networking.knative.dev/certificate-provider!=cert-manager \
--filename \
***://github.***/knative/serving/releases/download/v0.12.0/serving.yamlKnative服务模块Pod的安装和运行需要几分钟的时间。读者可以使用以下命令来查看knative-serving命名空间下Pod的状态，从而监视Knative服务模块的部署进度：
$ watch kubectl get pods -n knative-serving
NAME READY STATUS RESTARTS AGE
activator-5dd6dc95bc-k9lg9 1/1 Running 0 86s
autoscaler-b56799cdf-55h5k 1/1 Running 0 86s
autoscaler-hpa-6f5c5cf986-b8lvg 1/1 Running 0 86s
controller-f8b98d964-qjxff 1/1 Running 0 85s
networking-istio-bb44d8c87-s2lbg 1/1 Running 0 85s
webhook-78dcbf4d94-dczd6 1/1 Running 0 85s运行以下命令来部署Knative事件模块相关的基础架构组件：
$ kubectl apply \
--selector \
networking.knative.dev/certificate-provider!=cert-manager \
--filename \
***//github/knative/eventing/releases/download/v0.12.0/eventing.yamlKnative 事件模块相关 Pod 的运行同样会花费几分钟。使用以下命令来查看knative-eventing命名空间下Pod的状态，以确保Knative事件模块安装完成：
$ watch kubectl get pods -n knative-eventing
NAME READY STATUS RESTARTS AGE
eventing-controller-77b4f76d56-d4fzf 1/1 Running 0 2m39s
eventing-webhook-f5d57b487-hbgps 1/1 Running 0 2m39s
imc-controller-65bb5ddf-kld5l 1/1 Running 0 2m39s
imc-dispatcher-dd84879d7-qt2qn 1/1 Running 0 2m39s
in-memory-channel-controller-6f74d5c8c8-vm44b 1/1 Running 0 2m39s
in-memory-channel-dispatcher-8db675949-mqmfk 1/1 Running 0 2m39s
sources-controller-79c4bf8b86-lxbjf 1/1 Running 0 2m39s确保正确配置了minikube和Docker的运行环境。
minikube提供了配置文件和docker-env命令，它们用于设置配置文件和配置Docker环境。本书通过下面的指令来设置配置文件和Docker环境：
$ minikube profile knativecookbook
$ eval $(minikube docker-env)执行以下命令以列出minikube内部使用的Docker镜像（下面的输出省略了不重要的内容）：
$ docker images --format {{.Repository}}
gcr.io/knative-releases/knative.dev/serving/cmd/activator
gcr.io/knative-releases/knative.dev/serving/cmd/webhook
gcr.io/knative-releases/knative.dev/serving/cmd/controller
gcr.io/knative-releases/knative.dev/serving/cmd/autoscaler-hpa
gcr.io/knative-releases/knative.dev/serving/cmd/networking/istio
k8s.gcr.io/kube-addon-manager
istio/proxyv2
istio/pilot本书每章中的示例都会部署在单独的命名空间中。每一章也会引导读者切换到对应的命名空间下。运行以下命令为本书创建所需的命名空间：
$ kubectl create namespace chapter-2
$ kubectl create namespace chapter-3
$ kubectl create namespace chapter-4
$ kubectl create namespace chapter-5
$ kubectl create namespace chapter-6
$ kubectl create namespace chapter-7Kubernetes会默认创建default命名空间。执行Kubernetes相关命令时，通过指定--namespace或-n选项来控制访问不同命名空间下的资源。切换到对应章节的命名空间后，创建Kubernetes资源时就不必每次都指定--namespace或-n来选择相应的命名空间了。
使用kubectl切换到对应的命名空间。以下命令展示如何使用kubectl切换到名为Chapter-1的命名空间：
$ kubectl config set-context --current --namespace=chapter-1或者可以使用kubens来将当前的命名空间设置为chapter-1：
$ kubens chapter-1
用kubens设置当前的命名空间，意味着就不用每次执行kubectl命令时都要带上选项--namespace或者-n了。
不过在执行kubectl命令时，最好继续带上--namespace或者-n；使用namespace选项可以确保在正确的命名空间下创建Kubernetes资源。
想确保已经在终端中进入正确的工作目录，可以执行以下命令：
$ cd $BOOK_HOME在以下展示的示例以及本书的其他很多地方，读者都会被引导查看Kubernetes的资源。
命令kubectl get <resource> -w大家应该都比较熟悉吧。你可以在使用kubectl命令时带上w选项。但是在本书中，我们更推荐使用watch命令，因为watch命令输出的结果更加简洁明了。下面用一个例子来解释这两种方式的区别。
下面分别通过两种方式来查看istio-system命名空间下正在运行的Pod：
$ kubectl -n istio-system get pods –w
NAME READY STATUS RESTARTS AGE
cluster-local-gateway-7588cdfbc7-8f5s8 0/1 ContainerCreating 0 3s
istio-ingressgateway-5c87b8d6c7-dzwx8 0/1 ContainerCreating 0 4s
istio-pilot-7c555cf995-j9tpv 0/1 ContainerCreating 0 4s
NAME READY STATUS RESTARTS AGE
istio-pilot-7c555cf995-j9tpv 0/1 Running 0 16s
istio-ingressgateway-5c87b8d6c7-dzwx8 0/1 Running 0 27s
cluster-local-gateway-7588cdfbc7-8f5s8 0/1 Running 0 29s
istio-pilot-7c555cf995-j9tpv 1/1 Running 0 36s
cluster-local-gateway-7588cdfbc7-8f5s8 1/1 Running 0 37s
istio-ingressgateway-5c87b8d6c7-dzwx8 1/1 Running 0 44s
$ watch kubectl -n istio-system get pods
NAME READY STATUS RESTARTS AGE
cluster-local-gateway-7588cdfbc7-vgwgw 1/1 Running 0 8s
istio-ingressgateway-5c87b8d6c7-tbj6g 1/1 Running 0 8s
istio-pilot-7c555cf995-6ggvv 1/1 Running 0 8s比较这两个命令的输出。虽然这两个命令的输出内容差不多，不过可以看到watch kubectl -n istio-system get pods比kubectl -n istio-system get pods -w的输出更简洁清晰。当使用watch命令时，命令kubectl -n istio- system get pods会每两秒刷新输出，结果也更加简洁明了。与之相对的是，当资源有变化时，kubectl的w选项的输出会一直追加。
在本书中，在监听Kubernetes资源时，推荐使用watch <kubectl command>。当然，每个示例的命令和相关命令的选项都会有所区别。
现在读者应该已经了解了Knative是什么，如何安装Knative及其依赖项，并且知道如何安装相关的开源工具，这些工具将有助于在Kubernetes上开发应用。
通过本章的学习，部署Serverless工作负载的准备工作已基本完成。为了让读者理解得更加深入，第2章会继续介绍有关Knative服务模块的相关技术。
