在阿里云上试用 Knative

在今年的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

这个过程分为两步：

1. 安装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

2. 安装 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 -w

Build

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

1. apiVersion: v1

2. kind: Secret

3. metadata:

4.  name: docker-user-pass

5.  annotations:

6.    build.knative.dev/docker-0: https://index.docker.io/v1/

7. type: kubernetes.io/basic-auth

8. stringData:

9.  username: <docker username in plain text>

10.  password: <docker password in plain text>

把这里的username和password换成你自己的帐号信息，然后保存。 kubectl apply-f secret.yaml vim service-account.yaml

1. apiVersion: v1

2. kind: ServiceAccount

3. metadata:

4.  name: build-bot

5. secrets:

6.  - name: docker-user-pass

保存后执行： kubectl apply-f service-account.yaml

然后我们创建Kubernetes manifest vim build.yaml：

1. apiVersion: build.knative.dev/v1alpha1

2. kind: Build

3. metadata:

4.  name: docker-build

5. spec:

6.  serviceAccountName: build-bot #service account created above

7.  source:

8.    git:

9.      revision: master

10.      url: "https://github.com/szihai/hello-go.git"

11.  steps:

12.    -

13.      args:

14.        - "--dockerfile=/workspace/Dockerfile"

15.        - "--destination=docker.io/xxx/helloworld-go"

16.      image: "gcr.io/kaniko-project/executor:v0.1.0"

17.      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。用 kubectlgetpods 找到一个 docker-build-xxxx 的pod。然后运行： kubectl-ndefaultlogs docker-build-xxxx-c build-step-build-and-push 来观察build的情况。

我们也可以直接查看Kubetnetes build objects: kubectl describe builds。要找的信息是：

当然，最直接的方法是去自己的Docker hub上找到这个Image。

Serving

这个部分与普通的Kubetnetes服务发布差别不大。先定义一个服务： vim service.yaml

1. apiVersion: serving.knative.dev/v1alpha1

2. kind: Service

3. metadata:

4.  name: helloworld-go

5.  namespace: default

6. spec:

7.  runLatest:

8.    configuration:

9.      revisionTemplate:

10.        spec:

11.          container:

12.            image: docker.io/{username}/helloworld-go

13.            env:

14.            - name: TARGET

15.              value: "Go Sample v1"

运行 kubectl apply-f service.yaml。需要注意的是这里我们用了serving.knative.dev 的API。所以与其它部署有所不同：不需要deployment.yaml。这可理解为deployment被knative给包办了。如果运行 kubectlgetdeployments,就可以看到 helloworld-go-xxxx-deployment。

下一个问题就是，如何访问这个服务呢？这时候，Istio就出场了。平时我们要自己创建Ingress 或LB，现在knative通过 Istio帮我们做了。首先我们得到Ingress Gateway的IP地址： kubectlgetsvc knative-ingressgateway-n istio-system

这里找到 EXTERNAL-IP。然后我们找到Domain name:

1. kubectl get service.serving.knative.dev helloworld-go  -o=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain

接着运行：

1. curl -H "Host: {DOMAIN}" http://{EXTERNAL-IP}

结果应该是： HelloWorld:GoSamplev1!如果有一段时间没访问该服务，就会发现运行 kubectlgetpods 的时候，这几个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。先把它们装上：

1. kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release-clusterbus-stub.yaml

2. kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release-source-k8sevents.yaml

在生成flow之前，有一个小问题：K8 event是Kubernetes内部产生的，要接收的话，必须要通过一个Service Account 来授权。这是Kubernetes的要求，不是本文重点，如前面一样，保存后执行：

1. apiVersion: v1

2. kind: ServiceAccount

3. metadata:

4.  name: feed-sa

5.  namespace: default

6. ---

7. apiVersion: rbac.authorization.k8s.io/v1

8. kind: Role

9. metadata:

10.  name: create-deployment

11.  namespace: default

12. rules:

13. - apiGroups: ["apps"]

14.  resources: ["deployments"]

15.  verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]

16. ---

17. # This enables the feed-sa to deploy the receive adapter.

18. apiVersion: rbac.authorization.k8s.io/v1

19. kind: RoleBinding

20. metadata:

21.  name: feed-sa-deploy

22.  namespace: default

23. subjects:

24.  - kind: ServiceAccount

25.    name: feed-sa

26.    namespace: default

27. roleRef:

28.  kind: Role

29.  name: create-deployment

30.  apiGroup: rbac.authorization.k8s.io

31. ---

32. # This enables reading k8s events from all namespaces.

33. apiVersion: rbac.authorization.k8s.io/v1

34. kind: ClusterRoleBinding

35. metadata:

36.  name: feed-admin

37. subjects:

38.  - kind: ServiceAccount

39.    name: feed-sa

40.    namespace: default

41. roleRef:

42.  kind: ClusterRole

43.  name: view

44.  apiGroup: rbac.authorization.k8s.io

接下来是主要的一步，创建flow： vim flow.yaml :

1. apiVersion: flows.knative.dev/v1alpha1

2. kind: Flow

3. metadata:

4.  name: k8s-event-flow

5.  namespace: default

6. spec:

7.  serviceAccountName: feed-sa

8.  trigger:

9.    eventType: dev.knative.k8s.event

10.    resource: k8sevents/dev.knative.k8s.event

11.    service: k8sevents

12.    parameters:

13.      namespace: default

14.  action:

15.    target:

16.      kind: Route

17.      apiVersion: serving.knative.dev/v1alpha1

18.      name: helloworld-go

接着运行 kubectl apply-f flow.yaml就可以了。

我们来看一下是不是真的运行了呢？过一会儿运行： kubectlgetpods会看到k8s-event-flow-xxx的job运行完了。然后helloworld-go的pod都启动了。我们看一下日志： kubectl logs helloworld-go-xxxxx user-container，就会看到如下的结果：

1. Hello world received a request.

2. Hello world received a request.

3. Hello world received a request.

4. Hello world received a request.

5. ...

这说明这条链路是起作用的。那么，这个flow的定义说了什么呢？首先是用了刚刚定义的service account。然后在 trigger中定义什么样的event可以符合条件，这里我们说所有在 default namespace 的k8events 都符合。在action中我们定义有什么样的处理方式，本例中就直接调用了helloworld-go service。

结论

Knative是今年最新的云计算演进方向之一。阿里云支持Kubernetes，可以成功运行Knative和Istio等应用，大家也可以到阿里云上自己体验一番。

当然，作为一个新的备受瞩目的项目，Knative也会经历其成长的烦恼。我们会持续跟进，并提供和Knative相关、但不限于实践的分享，敬请期待。

关联阅读

»  阿里巴巴Service Mesh 专家解读 Istio1.0 发布