在今年的Google Cloud Next大会上，Google发布了Knative, 这是由Google、Pivotal、Redhat和IBM等云厂商共同推出的Serverless开源工具组件，它与Istio，Kubernetes一起，形成了开源Serverless服务的三驾马车。
本文来自阿里巴巴中间件事业部美国团队高级技术专家 Andy在 Knative的实践，Andy长期关注Service Mesh技术领域，在Cloud Foundry，Kubernetes，Envoy上等有着丰富的实践和开发经验。加入Service Mesh开发者群，微信添加“zjjxg2018”，并备注公司-城市信息。
有意思的是：上述几家公司是相互竞争的，但却能把各自擅长的技术贡献给同一个开源项目。另一个有意思的地方是对Serverless定义的转变。以前说到Serverless，大家就等同于FaaS，就感觉只要把function代码提交，然后定义event trigger就好了。现在Knative把Serverless这个概念转变成了免运维：用户还是要有server的，只是运维上比管理一个Kubernetes cluster更省心，而且不用的时候并不需要为server资源支付费用。除此之外，FaaS的应用场景很小，只有很小很快的函数才能比较容易部署。Knative以自助的方式实现部署，应用场景更广，且一般的应用都可以部署成Serverless。
根据Knative提供的文档介绍，一个完整的Serverless分为__Build__，__Serve__和__Eventing__三个部分。在本文中，我们将在阿里云上按照Knative github的安装指南，逐步操作，以实现一个Knative应用。
准备
创建 Kubernetes cluster
在阿里云上创建一个Kubernetes cluster，用系统默认的设置就行，但要保证你有Admin权限。如果你用已有的 cluster，请确认Kubernetes的版本是1.10以上。
安装 Knative
这个过程分为两步：
- 安装Istio:
Knative的Istio有一些自己定义的资源，所以不要用Istio网站的缺省安装。但是Knative现有指南未更新，还是0.8,有些旧。我所用的是1.0:
`curl https://raw.githubusercontent.com/knative/serving/master/third_party/istio-1.0.0/istio.yaml`
这个安装需要一点时间，但是是必须的。因为Knative依赖Istio来联接Serverless，而不是直接通过Kubernetes。等到所有的安装完成后，我们要开启Istio 自动injection：
kubectl label namespace default istio-injection=enabled安装 Knative组件：
执行下面的命令：
kubectl apply -f https://github.com/knative/serving/releases/download/v0.1.1/release.yaml 安装后等待一会并确认：kubectl get pods -n knative-serving -w
kubectl get pods -n knative-build -w细心的同学会发现这里只安装了两部分：Build 和 Serving，那么Eventing呢？是需要单独安装的。
kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release.yaml同样的，运行这个命令来确认：
kubectl get pods -n knative-eventing -wBuild
Build是目前Knative项目中内容最丰富的部分。因为Pivotal拿出了压箱宝build packs加入Knative。而Google之前多年做app engine，也在这方面累计了很多经验。
在实现上，Build是一个Kubernetes Custom Resource Definition (CRD)。如同其它的Kubernetes CRD，定义的方式是通过YAML，调用的方式是API。用户可以选择不同的build template，比如Google的kaniko，Pivotal的build pack等。在本文中，我们选择kaniko build。
先安装Kaniko Build Template:kubectl apply -f https://raw.githubusercontent.com/knative/build-templates/master/kaniko/kaniko.yaml
Kaniko build template和Docker build template最大的不同在于用户不需要本地安装Docker engine, Kaniko把代码搬到云上生成Image。源代码可以在远程的服务器上，还要指定相应的Dockerfile。
但是，这样做有个问题：Kaniko怎么访问用户的docker account呢？因此，我们需要创建一个secret，把用户的docker username和password存在里面。然后，还需要一个service account来绑定这个secret。vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: docker-user-pass
annotations:
build.knative.dev/docker-0: https://index.docker.io/v1/
type: kubernetes.io/basic-auth
stringData:
username: <docker username in plain text>
password: <docker password in plain text>把这里的username和password换成你自己的帐号信息，然后保存。kubectl apply -f secret.yamlvim service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: build-bot
secrets:
- name: docker-user-pass保存后执行：kubectl apply -f service-account.yaml
然后我们创建Kubernetes manifest vim build.yaml：
apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
name: docker-build
spec:
serviceAccountName: build-bot #service account created above
source:
git:
revision: master
url: "https://github.com/szihai/hello-go.git"
steps:
-
args:
- "--dockerfile=/workspace/Dockerfile"
- "--destination=docker.io/xxx/helloworld-go"
image: "gcr.io/kaniko-project/executor:v0.1.0"
name: build-and-push
本文所用的sample app是从Knative repo 上fork的。（例子）
在这里，我们指定了template用Kaniko。然后可以看到我们引用了前面的ServiceAccount 来访问secret。用这个之前把里面的destination换成你自己的docker id，保存后用kubectl apply -f build.yaml 来执行。
那么，如何知道远程的Kaniko到底做好了没有呢？Kubernetes 会为kind: Build 创建一个job。用kubectl get pods 找到一个 docker-build-xxxx 的pod。然后运行：kubectl -n default logs docker-build-xxxx -c build-step-build-and-push 来观察build的情况。
我们也可以直接查看Kubetnetes build objects: kubectl describe builds。要找的信息是：
当然，最直接的方法是去自己的Docker hub上找到这个Image。
Serving
这个部分与普通的Kubetnetes服务发布差别不大。先定义一个服务：vim service.yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: docker.io/{username}/helloworld-go
env:
- name: TARGET
value: "Go Sample v1"运行kubectl apply -f service.yaml。需要注意的是这里我们用了serving.knative.dev 的API。所以与其它部署有所不同：不需要deployment.yaml。这可理解为deployment被knative给包办了。如果运行kubectl get deployments,就可以看到helloworld-go-xxxx-deployment。
下一个问题就是，如何访问这个服务呢？这时候，Istio就出场了。平时我们要自己创建Ingress 或LB，现在knative通过 Istio帮我们做了。首先我们得到Ingress Gateway的IP地址：kubectl get svc knative-ingressgateway -n istio-system
这里找到EXTERNAL-IP。然后我们找到Domain name:
kubectl get service.serving.knative.dev helloworld-go -o=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain接着运行：
curl -H "Host: {DOMAIN}" http://{EXTERNAL-IP}结果应该是：Hello World: Go Sample v1!
如果有一段时间没访问该服务，就会发现运行kubectl get pods 的时候，这几个helloworld-go pod不见了。那是knative把replica数降为0。
Eventing
对于FaaS的来说，Eventing就是触发这个function的机制。上面我们用curl去访问服务，其实是为了测试而已。在真实的部署过程中，这个function应该是有事件触发的。
Eventing是传统的FaaS的主要功能，也是除源代码外唯一与开发者真正相关的部分。正因为如此，其它FaaS，如Lambda, Openshift等，都可以通过这一层与Knative接口。
Knative设计的Eventing包括3个主要的概念：
- Source: 就是事件发生的起源，可以理解为与其它系统的接口，目前支持的包括K8sevents，GitHub和GCP PubSub 。
- Buses: 事件传输的途径，目前支持的有Stub，Kafka和GCP PubSub。
- Flows: 定义对事件的反应。这可以是连锁的反应而不是单一的。
所以，我们要做的事就是，选一个Source，选一个Bus， 然后定义一个Flow，就可以啦。
本文中，我们选用K8events和Stub ClusterBus。先把它们装上：
kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release-clusterbus-stub.yaml
kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release-source-k8sevents.yaml在生成flow之前，有一个小问题：K8 event是Kubernetes内部产生的，要接收的话，必须要通过一个Service Account 来授权。这是Kubernetes的要求，不是本文重点，如前面一样，保存后执行：
apiVersion: v1
kind: ServiceAccount
metadata:
name: feed-sa
namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: create-deployment
namespace: default
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
---
# This enables the feed-sa to deploy the receive adapter.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: feed-sa-deploy
namespace: default
subjects:
- kind: ServiceAccount
name: feed-sa
namespace: default
roleRef:
kind: Role
name: create-deployment
apiGroup: rbac.authorization.k8s.io
---
# This enables reading k8s events from all namespaces.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: feed-admin
subjects:
- kind: ServiceAccount
name: feed-sa
namespace: default
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io接下来是主要的一步，创建flow：vim flow.yaml :
apiVersion: flows.knative.dev/v1alpha1
kind: Flow
metadata:
name: k8s-event-flow
namespace: default
spec:
serviceAccountName: feed-sa
trigger:
eventType: dev.knative.k8s.event
resource: k8sevents/dev.knative.k8s.event
service: k8sevents
parameters:
namespace: default
action:
target:
kind: Route
apiVersion: serving.knative.dev/v1alpha1
name: helloworld-go
接着运行kubectl apply -f flow.yaml就可以了。
我们来看一下是不是真的运行了呢？过一会儿运行：kubectl get pods 会看到k8s-event-flow-xxx的job运行完了。然后helloworld-go的pod都启动了。我们看一下日志： kubectl logs helloworld-go-xxxxx user-container，就会看到如下的结果：
Hello world received a request.
Hello world received a request.
Hello world received a request.
Hello world received a request.
...这说明这条链路是起作用的。那么，这个flow的定义说了什么呢？首先是用了刚刚定义的service account。然后在trigger中定义什么样的event可以符合条件，这里我们说所有在 default namespace 的k8events 都符合。在action中我们定义有什么样的处理方式，本例中就直接调用了helloworld-go service。
结论
Knative是今年最新的云计算演进方向之一。阿里云支持Kubernetes，可以成功运行Knative和Istio等应用，大家也可以到阿里云上自己体验一番！
当然，作为一个新的备受瞩目的项目，Knative也会经历其成长的烦恼。我们会持续跟进，并提供和Knative相关、但不限于实践的分享，敬请期待。
