标签：serving service oc Kvative knative greeter pod OpenShift Knative
一、Knative网络流量分析创建项目：
oc new-project knativetutorial
git clone https://github.com/redhat-developer-demos/knative-tutorial &&\ export TUTORIAL_HOME="$(pwd)/knative-tutorial"
我们分析应用配置文件：cd $TUTORIAL_HOME/basics。该文件使用quay.io/rhdevelopers/knative-tutorial-greeter:quarkus镜像创建应knative service：
应用配置：
oc apply -n knativetutorial -f service.yaml
接下来，我们查看knativetutorial项目中被创建了什么资源：
产生了一个K8S层面的deployments：
产生了三个K8S的service：
产生了一个knative的service，greeter。
利用oc get rt -n knativetutorial查看knative route：
利用oc get route -n knativetutorial查看OCP route，未发现：
查看pod，未发现：
接下来，我们查看knative路由指向：100%指向了knative service：greeter：
# oc get rt greeter -o yaml -n knativetutorial
我们查看knative service greeter 的内容：其中包含了指向revision的流量信息。
# kn service list greeter -o yaml
接下来，我们从OCP的角度，查看svc：greeter。
从下面图内容我们可以得知：greeter的svc的外部地址是：kourier-internal.knative-serving-ingress.svc.cluster.local，也就是说与knative-serving-ingress项目中的service：kourier-internal关联起来了。
# oc get svc greeter -o yaml -n knativetutorial
我们查看knative-serving-ingress项目中service：kourier-internal的内容，它指向了knative-serving-ingress项目中的ingress pod：
# oc get svc kourier-internal -o yaml -n knative-serving-ingress
接下来，我们查看knative-serving-ingress项目中的资源：
项目中没有knative route:
有OCP route：route-db15f484-546d-46b9-8e31-2fad2527ed5c-356631366663
查看这条OCP route的指向,指向service：kourier
# oc get route route-db15f484-546d-46b9-8e31-2fad2527ed5c-356631366663 -o yaml -n knative-serving-ingress
继续分析，发现这条OCP路由与haproxy的关系：
查看service：kourier的内容，指向了ingress pod：
kourier和kourier-internal的区别是：前者是
External Load Balancer，Ingress point(s) of load balancer后者是Accessible within the cluster only。这两个service其实指向相同的pod。类型不同。第一种通常和lb结合使用，比如云厂商的lb，可以对内也可以对外。第二种是对内，完全是k8s管理的。
从上面一系列图我们可以得出OCP上Kvative网络流量图（这是大魏理解的图，仅供参考）：
二、测试应用
使用http调用我们部署的greeter应用：
[root@lb.weixinyucluster ~]# export SVC_URL=`oc get rt greeter -o yaml | yq read - 'sta.url'` && \
> http $SVC_URL
调用反馈结果是：Hi greeter => '9861675f8845' : 1
此时查看pod：
在没有新的请求时，pod会自动删除：
我们查看configuration：
oc --namespace knativetutorial get configurations.serving.knative.dev greeter
oc --namespace knativetutorial get rev \
--selector=serving.knative.dev/service=greeter \
--sort-by="{.metadata.creationTimestamp}"
接下来，我们部署version2的应用，我们查看配置文件，版本2的应用被注入了MESSAGE_PREFIX：Namaste
应用配置：
我们查看revision信息：
oc --namespace knativetutorial get rev \ --selector=serving.knative.dev/service=greeter \ --sort-by="{.metadata.creationTimestamp}"
此时OCP也创新了新的K8S SVC：
我们再用http访问应用：
export SVC_URL=`oc get rt greeter -o yaml | yq read - 'sta.url'` && \
> http $SVC_URL
我们看到此次访问结果增加了MESSAGE_PREFIX：Namaste。
我们可以动态调整到两个revision的流量百分比。使用OCP的UI较为方便:
进行修改：
命令行双重确认，调整成功：
三、scale-to-zero
假设已经部署了Greeter服务，一旦看到没有更多流量进入该服务，我们希望将该服务缩减为零个副本。这就是所谓的scale-to-zero.。
scale-to-zero.是使Knative成为无服务器平台的主要特性之一。在定义的空闲时间（所谓的稳定窗口）之后，revisions被视为无效。现在，所有指向当前无效revisions的路由都将指向所谓的activator。网络的重新编程本质上是异步的，因此从零到零的宽限期应该提供足够的松弛时间来实现。一旦scale-to-zero宽限期结束，revisions将最终缩放到零副本。
如果另一个请求试图到达revision，则activator将获取它，指示autoscaler尽快为该revision建新的容器，并缓冲该请求，直到创建了这些新容器。
默认情况下，scale-to-zero宽限期为30秒，稳定窗口为60秒。向greeter 服务发出请求将调出pod（如果已终止，如上所述）（如果已被终止）以处理该请求。保留它而没有任何其他请求将自动导致它在大约60-70秒内缩放为零。pod开始终止后到完全终止之前，至少需要20秒。
四、弹性伸缩
默认情况下，Knative Serving允许将100个并发请求放入pod中。这是由knative-serving名称空间中configmap config-autoscaler中的container-concurrency-target-default设置定义的。让我们使我们的服务仅处理10个并发请求。一旦我们针对revision并行运行10个以上的请求，这将导致Knative自动缩放器扩展到更多的Pod。
创建一个新的项目：
# oc new-project knativetutorial
[root@lb.weixinyucluster ~/knative-tutorial/basics]# cat service-10.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: prime-generator
spec:
template:
metadata:
annotations:
# Target 10 in-flight-requests per pod.
autoscaling.knative.dev/target: "10"
spec:
containers:
- image: quay.io/rhdevelopers/prime-generator:v27-quarkus
livenessProbe:
httpGet:
path: /healthz
readinessProbe:
httpGet:
path: /healthz
[root@lb.weixinyucluster ~/knative-tutorial/basics]# oc apply -f service-10.yaml
service.serving.knative.dev/prime-generator created
export SVC_URL=`oc get rt prime-generator -o yaml | yq read - 'status.url'`
hey -c 50 -z 10s \ "${SVC_URL}/?sleep=3&upto=10000&memload=100"
在现实世界中，您的服务可能需要处理突然的请求高峰。Knative使用默认的1个副本启动每个服务。如上所述，最终将如上所述将其缩放为零。如果您的应用在任何情况下都需要保持特别的响应速度和/或启动时间较长，那么始终保持最少数量的Pod可能是有益的。这可以通过注释autoscaling.knative.dev/minScale完成。
以下示例显示了如何使Knative创建以2的副本数开始并且永远不会扩展到其以下的服务。
[root@lb.weixinyucluster ~/knative-tutorial/basics]# cat service-min-max-scale.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: prime-generator
spec:
template:
metadata:
annotations:
# the minimum number of pods to scale down to
autoscaling.knative.dev/minScale: "2"
# Target 10 in-flight-requests per pod.
autoscaling.knative.dev/target: "10"
spec:
containers:
- image: quay.io/rhdevelopers/prime-generator:v27-quarkus
livenessProbe:
httpGet:
path: /healthz
readinessProbe:
httpGet:
path: /healthz
[root@lb.weixinyucluster ~/knative-tutorial/basics]# oc apply -f service-min-max-scale.yaml
service.serving.knative.dev/prime-generator created
在没有外部请求时，pod的数量也是两个：
发起峰值压力后，pod的数量会增加：
标签：serving,service,oc,Kvative,knative,greeter,pod,OpenShift,Knative 来源： https://blog.51cto.com/u_15127570/2711253
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。