阿里云分布式应用服务 + 关注
手机版

在阿里云上试用 Knative

  1. 云栖社区>
  2. 阿里云分布式应用服务>
  3. 博客>
  4. 正文

在阿里云上试用 Knative

中间件小哥 发布时间:2018-10-05 11:57:39 浏览3721 评论0

摘要: 在今年的Google Cloud Next大会上,Google发布了Knative, 这是由Google、Pivotal、Redhat和IBM等云厂商共同推出的Serverless开源工具组件,它与Istio,Kubernetes一起,形成了开源Serverless服务的三驾马车。

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

knativedi.svg | center | 681x450

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

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.yaml
vim 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。要找的信息是:

Screen Shot 2018-09-10 at 3.36.23 PM.png | center | 618x67

当然,最直接的方法是去自己的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个主要的概念:

  1. Source: 就是事件发生的起源,可以理解为与其它系统的接口,目前支持的包括K8seventsGitHubGCP PubSub
  2. Buses: 事件传输的途径,目前支持的有StubKafkaGCP PubSub
  3. 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相关、但不限于实践的分享,敬请期待。

相关阅读:阿里巴巴中间件硅谷 Istio 专家解读Istio 1.0 发布

【云栖快讯】云栖专辑 | 阿里开发者们的第20个感悟:好的工程师为人写代码,而不仅是为编译器  详情请点击

网友评论