使用Knative的服务管理组件管理应用
在部署一个Knative Service之前，先了解一下它的部署模型和对应的Kubernetes资源。
如下所示，在部署Knative Serving Service的过程中，Knative Serving控制器将创建configuration、Revision和Route三个资源对象。
Knative Serving的资源对象
配置（configuration）：Knative configuration维护了部署的目标状态，提供了一个干净的代码和配置分离、遵循12要素开发原则的机制。基于目标状态，Knative configuration控制器为应用创建了一个新的Kubernetes部署应用。并且configuration的变更会体现在一个新的Kubernetes部署应用中。
修订版（Revision）：Knative configuration遵循12要素开发原则，每次应用的变更将会创建一个新的Knative Revision。Revision类似于版本控制中的标签。Revision一旦创建，是不可改变的。每个Revision都有一个对应的Kubernetes Deployment。它允许将应用程序回滚到任何正确的最新配置。
路由（Route）：Knative Route是访问Knative Service的URL。
1 部署一个Knative Service
以Go语言编写的程序代码为例，创建一个简单的Web服务。该服务接收到HTTP GET请求时，会根据环境变量Target传递的内容向Response输出Hello$TATGET！内容。
1）创建一个文件名为helloworld.go的文件。
package main
import (
"fmt"
"log"
"net/http"
"os"
)
func handler(w http.ResponseWriter, r *http.Request) {
log.Print("helloworld: received a request")
target := os.Getenv("TARGET")
if target == "" {
target = "World"
}
fmt.Fprintf(w, "Hello %s!\n", target)
}
func main() {
log.Print("helloworld: starting server...")
http.HandleFunc("/", handler)
port := os.Getenv("PORT")
if port == "" {
port = "8080"
}
log.Printf("helloworld: listening on port %s", port)
log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
}
2）使用Dockerfile构建源码并生成容器：
# Use the official Golang image to create a build artifact.
# This is based on Debian and sets the GOPATH to /go.
# https://hub.docker.com/_/golang
FROM golang:1.13 as builder
# Create and change to the app directory.
WORKDIR /app
# Retrieve application dependencies using go modules.
# Allows container builds to reuse downloaded dependencies.
COPY go.* ./
RUN go mod download
# Copy local code to the container image.
COPY . ./
# Build the binary.
#-mod=readonly ensures immutable go.mod and go.sum in container builds.
RUN CGO_ENABLED=0 GOOS=linux go build-mod=readonly-v-o server
# Use the official Alpine image for a lean production container.
# https://hub.docker.com/_/alpine
# https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-
stage-builds
FROM alpine:3
RUN apk add--no-cache ca-certificates
# Copy the binary to the production image from the builder stage.
COPY--from=builder /app/server /server
# Run the web service on container startup.
CMD ["/server"]
# 在本地主机构建容器。{username}替换为自己在dockerhub的用户名
docker build-t {username}/helloworld-go .
# 将容器Push到Docker容器镜像仓库。{username}替换为你自己在dockerhub的用户名
docker push {username}/helloworld-go
3）部署Knative Service。
Knative Service和其他Kubernetes资源类似，可以通过一个yaml文件进行定义和部署。接下来，使用上一步构建的容器来部署Knative Service服务。service.yaml配置文件如下：
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go # Service名称
namespace: default
spec:
template:
metadata:
name: helloworld-go-v1 # Knative Revision名称，如果未设置系统将会自动生成
spec:
containers:
- image: {username}/helloworld-go
env:
- name: TARGET
value: "Go Sample v1"
livenessProbe:
httpGet:
path: /
readinessProbe:
httpGet:
path: /
运行以下命令部署helloworld-go Knative Service：
# kubectl apply-f service.yaml
在该yaml配置文件中，Knative Service的kind值是Service。为了避免与Kubernetes内置的Service混淆，apiVersion的值需要设置为serving.knative.dev/v1。
配置文件中的spec区块与Kubernetes PodSpec的定义几乎一样，只是删除了以下属性：
· InitContainers
· RestartPolicy
· TerminationGracePeriodSeconds
· ActiveDeadlineSeconds
· DNSPolicy
· NodeSelector
· AutomountServiceAccountToken
· NodeName
· HostNetwork
· HostPID
· HostIPC
· ShareProcessNamespace
· SecurityContext
· Hostname
· Subdomain
· Affinity
· SchedulerName
· Tolerations
· HostAliases
· PriorityClassName
· Priority
· DNSConfig
· ReadinessGates
· RuntimeClassName
spec.template.metadata.name定义了Knative Revision的名称，这个名称是可选的。如果其被省略，系统会自动生成。
Knative Service的liveness探针与标准Kubernetes探针有微小区别。Knative Service探针定义中没有port属性定义。Knative Serving控制器在Service部署阶段能够自动确定port值。readiness探针也遵循同样的规则。
4）检查部署结果并验证服务：
# kubectl get ksvc helloworld-go
NAME URL LATESTCREATED LATESTREADY READY REASON
helloworld-go http://helloworld-go. helloworld-go-v1 helloworld-go-v1 True
default.example.com
通过curl命令访问helloworld-go服务：
##获取集群任一节点的IP地址和nodePort端口
# IP_ADDRESS="$(kubectl get nodes-o 'jsonpath={.items[0].status.addresses[0].
address}'):$(kubectl get svc istio-ingressgateway--namespace istio-system--
output 'jsonpath={.spec.ports[?(@.port==80)].nodePort}')"
# curl-H "Host:helloworld-go.default.example.com" http://$IP_ADDRESS
Hello Go Sample v1!
上述脚本为了获取访问helloworld-go服务的IP地址以及端口号，选取了集群任一节点的IP地址、istio-ingressgateway服务的nodePort端口号。使用带有Service URL的主机名的头信息（例如Host：helloworld-go.default.example.com）即可访问helloworld-go服务。
当CURL访问到服务后，Knative Serving则自动创建一个Pod副本来提供服务。当一段时间没有访问服务，Pod副本将会被销毁。我们可以通过watch kubectl get pods来监控Pod的生命周期。
2 更新Knative Service configuration
在部署完一个Knative Service后，因为应用版本的升级、配置的变更等需要更新现有服务的configuration。Knative服务还提供了一种机制实现回滚变更。
12要素应用设计原则规定，应用程序与配置的变更应被视为一个新的修订版。修订版是不可变更的应用和配置的状态集合。它可以让你回滚到任何一个有效的修订版状态。
应用的更新包括容器镜像的更新、健康检查探针的调整、环境变量的变更。这些变更会导致Knative生成新的修订版。每一个新修订版将创建一个新的Kubernetes Deployment对象。
接下来，通过一个更新服务配置的示例来演示配置的变更。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go # Service名称
namespace: default
spec:
template:
metadata:
name: helloworld-go-v2 # Knative Revision名称
spec:
containers:
- image: cnlab/helloworld-go
env:
- name: TARGET
value: "Go Sample v2"
livenessProbe:
httpGet:
path: /
readinessProbe:
httpGet:
path: /
配置文件（service.yaml）的变更如下。
1）更新修订版的名称（.spec.template.metadata.name）为helloworld-go-v2，区别于上一个修订版名称helloworld-go-v1。
2）更新环境变量TARFET（.spec.template.spec.containers[0].env[0].value）的值为Go Sample v2。
将配置更新到Knative：
# kubectl apply-f service.yaml
检查部署结果：
# kubectl get ksvc helloworld-go
NAME URL LATESTCREATED LATESTREADY READY REASON
helloworld-go http://helloworld-go. helloworld-go-v2 helloworld-go-v2 True
default.example.com
通过curl命令访问helloworld-go服务：
##获取集群任一节点的IP地址和nodePort端口
# IP_ADDRESS="$(kubectl get nodes-o 'jsonpath={.items[0].status.addresses[0].
address}'):$(kubectl get svc istio-ingressgateway--namespace istio-system
--output 'jsonpath={.spec.ports[?(@.port==80)].nodePort}')"
# curl-H "Host:helloworld-go.default.example.com" http://$IP_ADDRESS
Hello Go Sample v2!
查看部署后生成的Kubernetes Deployment：
# kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
helloworld-go-v1-deployment 0/0 0 0 2m52s
helloworld-go-v2-deployment 1/1 1 1 2m19s
查看部署后生成的Kubernetes Pod：
# kubectl get pods
NAME READY STATUS RESTARTS AGE
helloworld-go-v2-deployment-589c5f7ff9-czpj2 3/3 Running 0 12s
helloworld-go对应的部署如果在扩缩容时间窗口期（默认60s）内没有请求，Knative将自动将对应的部署缩容为零。
查看部署后生成的Revision：
# kubectl get revision
NAME CONFIG NAME K8S SERVICE NAME GENERATION READY REASON
helloworld-go-v1 helloworld-go helloworld-go-v1 1 True
helloworld-go-v2 helloworld-go helloworld-go-v2 2 True
可以看到helloworld-go的配置有两个修订版，分别是helloworld-go-v1和helloworld-go-v2。配置的变更产生了新的修订版，然而并没有产生新的路由、服务和配置对象。我们可以通过下面的命令来验证这些资源对象的状态。
·获取服务的路由信息的命令：kubectl get routes。
·获取Knative服务的状态信息的命令：kubectl get ksvc。
·获取Knative服务的配置信息的命令：kubectl get configurations。
Knative默认路由策略是将所有流量转发给最新的修订版。
3 流量分发到不同版本
在典型的微服务部署中，实现流量在不同版本中分发是实现金丝雀或蓝绿部署方式的基础。Knative提供了这种流量分发方式的支持。
在Knative Service的yaml文件配置中，traffic区块描述了如何在多个版本之间进行流量分发。配置范例如下：
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go # Service名称
namespace: default
spec:
template:
metadata:
name: helloworld-go-v2 # Knative Revision名称
spec:
containers:
- image: cnlab/helloworld-go
env:
- name: TARGET
value: "Go Sample v2"
livenessProbe:
httpGet:
path: /
readinessProbe:
httpGet:
path: /
traffic:
- tag: v1
revisionName: helloworld-go-v1 # Revision的名称
percent: 50 #流量切分的百分比的数字值
- tag: v2
revisionName: helloworld-go-v2 # Revision的名称
percent: 50 #流量切分的百分比的数字值
traffic区块中可以有一个或多个条目。每个条目中带有如下属性。
·tag：流量分配的标识符。此标记将在路由中充当前缀，以便将流量分发到特定修订版。
·revisionName：参与流量分配的Knative服务修订版本的名称。
·percent：对应修订版被分配的流量百分比。这个值在0～100之间。在上述例子中，Knative分配给修订版helloworld-go-v1和helloworld-go-v2各50%的流量。
Knative Serving会为每个Tag创建独特的URL。可以通过下面的命令查看：
# kubectl get ksvc helloworld-go-o jsonpath='{.status.traffic[*].url}'
http://v1-helloworld-go.default.example.com
http://v2-helloworld-go.default.example.com
通过访问URL可以直接访问到对应的修订版。
4 蓝绿部署与灰度发布
一般情况下，升级服务端应用需要先停掉老版本服务，再启动新版服务。但是这种简单的发布方式存在两个问题，一方面在新版本升级过程中，服务是暂时中断的；另一方面，如果新版本升级失败，回滚起来非常麻烦，容易造成更长时间的服务不可用。
1.蓝绿部署
所谓蓝绿部署，是指同时运行两个版本的应用，即部署的时候，并不停掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上，如下所示。但是蓝绿部署要求服务端在升级过程中同时运行两套程序，对硬件资源的要求是日常所需的2倍。
蓝绿部署
Knative提供了一个简单的切换流量的方法，可将流量快速从Revison1切换到Revision 2。如果Revision2发生错误，服务可以快速回滚变更到Revison1。
接下来，将通过helloworld-go这个Knative服务来应用蓝绿色部署模式。已经部署了拥有两个修订版的helloworld-go服务，名称分别为helloworld-go-v1和helloworld-go-v2。通过部署helloworld-go-v2，可以看到Knative自动将100%的流量路由到helloworld-go-v2。现在，假设出于某些原因，需要将helloworld-go-v2回滚到helloworld-go-v1。
以下示例中Knative Service与先前部署的helloworld-go相同，只是添加了traffic部分以指示将100%的流量路由到helloworld-go-v1。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go # Service名称
namespace: default
spec:
template:
metadata:
name: helloworld-go-v2 # Knative Revision名称
spec:
containers:
- image: cnlab/helloworld-go
env:
- name: TARGET
value: "Go Sample v2"
livenessProbe:
httpGet:
path: /
readinessProbe:
httpGet:
path: /
traffic:
- tag: v1
revisionName: helloworld-go-v1 # Revision的名称
percent: 100 # 流量切分的百分比值
- tag: v2
revisionName: helloworld-go-v2 # Revision的名称
percent: 0 # 流量切分的百分比值
- tag: latest # 默认最新的Revision
latestRevision: true
percent: 0 # 关闭默认流量分配
2.灰度发布
灰度发布也叫金丝雀发布。如下所示，在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试。启动的这个新版本应用，就是金丝雀。如果测试没有问题，可以将少量的流量导入新版本，然后再对新版本做运行状态观察，收集各种运行时数据。如果此时对新旧版本做数据对比，就是所谓的A/B测试。
灰度发布
当确认新版本运行良好后，再逐步将更多的流量导入新版本。在此期间，还可以不断地调整新旧两个版本运行的服务器副本数量，使得新版本能够承受更大的流量压力，直到将100%的流量切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。
如果在灰度发布过程中（灰度期）发现新版本有问题，应该立即将流量切回老版本，这样就会将负面影响控制在最小范围内。
以下示例通过不断变更helloworld-go-v1和helloworld-go-v2的流量比例来实现helloworld-go服务新版本的灰度发布。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go # Service名称
namespace: default
spec:
template:
metadata:
name: helloworld-go-v2 # Knative Revision名称
spec:
containers:
- image: cnlab/helloworld-go
env:
- name: TARGET
value: "Go Sample v2"
livenessProbe:
httpGet:
path: /
readinessProbe:
httpGet:
path: /
traffic:
- tag: v1
revisionName: helloworld-go-v1 # Revision的名称
percent: 80 # 流量切分的百分比值
- tag: v2
revisionName: helloworld-go-v2 # Revision的名称
percent: 20 # 流量切分的百分比值
- tag: latest # 默认最新的Revision
latestRevision: true
percent: 0 # 关闭默认流量分配
5 Knative Service的弹性伸缩配置
无服务器计算不仅能够终止未使用的服务，还可以按需扩展计算规模。Knative Serving支持这种弹性伸缩能力。
为了让Knative的Autoscaler更好地调度服务，需要根据实际情况在服务中添加相应的扩缩容配置项。下面以helloworld-go.yaml范例来演示扩缩容相关配置。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go # Service名称
namespace: default
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"
# Autoscaler的实现方式,可选值有"kpa.autoscaling.knative.dev" 或
"hpa.autoscaling.knative.dev"
autoscaling.knative.dev/metric: "concurrency" # 设置度量指标为Concurrency
（默认值），还可以根据业务情
况选择RPS或CPU
autoscaling.knative.dev/target: "10" # 设置单个Pod最大并发数为10，默认值为100
autoscaling.knative.dev/minScale: "1" # minScale表示最小保留实例数为1
autoscaling.knative.dev/maxScale: "100" # maxScale表示最大扩容实例数为3
spec:
containerConcurrency: 10 # 并发请求数的硬性限制
containers:
- image: cnlab/helloworld-go
在上述配置中，revision中配置了修订版的弹性伸缩策略。各个属性代表的意义如下。
·autoscaling.knative.dev/class：表示Autoscaler的实现方式，这个属性的可选值有kpa.autoscaling.knative.dev或hpa.autoscaling.knative.dev。KPA支持缩容到零，HPA支持基于CPU的扩展机制。
·autoscaling.knative.dev/metric：度量指标默认为并发数，该属性还可以根据业务情况选择每秒请求数或CPU使用率。
·autoscaling.knative.dev/target：自动缩放的目标值是Autoscaler维护应用的每个副本度量指标的目标值。
·autoscaling.knative.dev/minScale：表示每个修订版副本需要保留的最小数量。在任何时间点，副本不会少于这个数量。通过该设置，我们可以有效地减少服务的冷启动时间。
·autoscaling.knative.dev/maxScale：表示每个修订版副本所能达到的最大数量。在任何时间点，副本都不会超过指定的最大值，从而避免资源被过度使用。
·containerConcurrency：限制容器在给定时间允许的并发请求的数量的硬性限制。只有当应用程序需要强制的并发约束时，才会使用到该属性。
部署helloworld-go服务并配置到Knative集群：
# kubectl apply-f helloworld-go.yaml
验证部署结果：
#IP_ADDRESS="$(kubectl get nodes-o 'jsonpath={.items[0].status.addresses[0].
address}'):$(kubectl get svc istio-ingressgateway--namespace istio-system--
output 'jsonpath={.spec.ports[?(@.port==80)].nodePort}')"
# curl-H "Host:helloworld-go.default.example.com" $IP_ADDRESS
Hello World!
压力测试：
# hey-c 50-z 30s-host "helloworld-go.default.knative.k8s.arch.dapp.com"
"http://$IP_ADDRESS"
通过hey工具发起50个并发请求，持续30秒对hellowrold-go服务进行压测。
查看压测期间Pod的副本数量：
# kubectl get pod -l serving.knative.dev/service=helloworld-go
NAME READY STATUS RESTARTS AGE
helloworld-go-7t7sg-deployment-6bfbdb84fd-5l5gc 3/3 Running 0 42s
helloworld-go-7t7sg-deployment-6bfbdb84fd-99cdr 3/3 Running 0 42s
helloworld-go-7t7sg-deployment-6bfbdb84fd-ls4ks 3/3 Running 0 44s
helloworld-go-7t7sg-deployment-6bfbdb84fd-n4s4k 3/3 Running 0 44s
helloworld-go-7t7sg-deployment-6bfbdb84fd-q9kr8 3/3 Running 0 40s
helloworld-go-7t7sg-deployment-6bfbdb84fd-r77tt 3/3 Running 0 22m
通过上面的命令，可以看到集群中产生了6个Pod副本。那么问题来了，发起的并发请求数是50个，服务自动缩放的目标值是10，按照“副本数=并发数/目标值”算法，Pod副本数应该是5个才对呀。这是由于Knative Serving还有一个控制参数叫目标使用率，一旦并发数达到预设目标的70%（默认值），Autoscaler就会继续扩容。引入目标使用率的主要目的是在扩容时减小由Pod启动时间带来的延迟，使负载到达前就将Pod实例启动起来。
