背景
knative 0.14.0 实际修改可能与贴出来的代码不符，贴出来的代码只是为了方便快速实现功能
最近在搭建公司级的serverless平台，需要用到域名来访问内部服务，采取的是通过PATH来区分不同的服务
问题
申请完域名后，分别通过域名和IP:PORT形式访问已部署的helloworld服务
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | curl -v -H "Host: api-test.sls.intra.kaku.com" http://api-test.sls.intra.kaku.com/ * Trying 10.88.128.112... * TCP_NODELAY set * Connected to api-test.sls.intra.kaku.com (10.88.128.112) port 80 (#0) > GET / HTTP/1.1 > Host: api-test.sls.intra.kaku.com > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 426 Upgrade Required < Date: Thu, 09 Jul 2020 11:59:20 GMT < Content-Length: 0 < Connection: keep-alive < server: istio-envoy < * Connection #0 to host api-test.sls.intra.kaku.com left intact # 10.190.16.26 为 knative-ingress-gateway的容器IP curl -v -H "Host:api-test.sls.intra.kaku.com" http://10.190.16.26/ * Trying 10.190.16.26... * TCP_NODELAY set * Connected to 10.190.16.26 (10.190.16.26) port 80 (#0) > GET / HTTP/1.1 > Host:api-test.sls.intra.kaku.com > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 404 Not Found < date: Thu, 09 Jul 2020 12:03:05 GMT < server: istio-envoy < content-length: 0 < * Connection #0 to host 10.190.16.26 left intact |
|---|
可以看到都无法正常返回，通过域名访问的时候返回了426，通过IP:PORT访问的时候返回了404。
排查
426 Upgrade Required
这个问题直接google一搜就出来答案了，参考 这里，其实这是envoy的能力，只要在envoy运行的容器中设置ISTIO_META_HTTP10环境变量为"1"问题就解决了，即**ISTIO_META_HTTP10: '"1"'**
404 Not Found
这个问题就涉及到VirtualService了，简称vs，在介绍vs之前我们先大致过一下knative创建集群的流程
假设我们通过kubectl操作，此时我们通过kubectl create -f helloworld.yaml的方式创建ksvc服务，如果集群各组件正常工作，且ksvc内容正确，那么稍微过一会就可以在集群中看到我们的服务了，我们需要做的仅仅是执行一条命令而已。可以看到knative封装的太好了，极大的简化了用户操作，对于对集群没有高级需求的用户非常友好，同时也有利于我们快速入门，否则，如果要执行一堆命令的话，就真的可以从入门到放弃了
但是我们毕竟是管理员，还是要对自己提高要求的，一定要搞清楚里面的原理，各组件之间的交互，否则系统对于我们来说就完全是个黑盒，不出问题还好，出问题就傻眼了。了解源码也是必须的，说到源码，只能感叹knative的源码要比k8s的源码封装的好太多了，其中一个原因也使得益于k8s提供的丰富的扩展机制：crd、operator、informer、webhook等。knative的源码真应该也值得拿出来一起分享，仔细研读。
回到正题，网路路由能力我们选择的是istio，我们大致分两种类型的资源进行介绍，和网络有关的 vs 和网络无关的
和网络无关的资源创建流程
ksvc --> configuration --> revision --> deployment
和网络有关的资源创建流程
ksvc --> route --> king--> virtualservice
我们的问题是和网络有关的，所以重点关注下面这个流程，最终对接istio的是vs，于是我们直接去看vs的配置，发现和域名相关的有两个地方，spec.hosts 和 spec.http.match.authority，于是想到的最简单的修改方式就是把我们的域名加入到spec.hosts中，去掉spec.http.match.authority，通过看代码发现这两处并没有可以修改的机制，于是想到利用MutatingWebhook来实现修改
控制这两个属性的地方都在net-istio的controller中，webhook对应的是net-istio的webhook，按照上面的分析，我们需要在webhook中添加对应的代码，主要改动两个地方，如下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | // 注册virtualservice类型，表示要对其进行mutate的操作，我们只需要在此注册即可，controller会自动修改对应的MutatingWebhookConfiguration，添加对应的资源和操作 var types = map[schema.GroupVersionKind]resourcesemantics.GenericCRD{ appsv1.SchemeGroupVersion.WithKind("Deployment"): &defaults.IstioDeployment{}, v1alpha3.SchemeGroupVersion.WithKind("VirtualService"): &defaults.IstioVirtualService{}, } // pkg/defaults/virtualservice_default.go，以去掉match.authority举例 package defaults import ( "context" "istio.io/client-go/pkg/apis/networking/v1alpha3" "knative.dev/pkg/apis" ) type IstioVirtualService struct { v1alpha3.VirtualService `json:",inline"` } func (vs *IstioVirtualService) Validate(context.Context) *apis.FieldError { return nil } func (vs *IstioVirtualService) SetDefaults(ctx context.Context) { for _, http := range vs.Spec.Http { for _, match := range http.Match { match.Authority = nil } } } |
|---|
可以看到整体修改很少，修改完之后重新编译，制作镜像，修改线上Pod的Image，触发原地重启，然后删除掉原有的vs，新的vs自动生成，查看新的vs，wtf？ 居然和之前一样，没有实现我们的效果，查kube-apiserver日志没有看到在创建vs时调用webhook，查看webhook的日志，也没有发现调用，但是在创建deployment时却会调用，然后查看webhook的配置，发现资源里也已经加上了，查了好久还是没有找到原因，不知道是哪个姿势不对了，由于时间关系暂时换另一种方式实现。
因为vs是由king创建的，所以在创建king的地方修改，这样在king创建vs的时候会自动带上我们自定义的domains，如下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | // 通过annotation的方式，把需要添加到hosts中的域名放到annotation中 // MakeIngressSpec creates a new IngressSpec func MakeIngressSpec( ctx context.Context, r *servingv1.Route, tls []v1alpha1.IngressTLS, targets map[string]traffic.RevisionTargets, visibility map[string]netv1alpha1.IngressVisibility, acmeChallenges ...v1alpha1.HTTP01Challenge, ) (v1alpha1.IngressSpec, error) { ... // add custom external domains customHostStr := r.Annotations["serverless.kakuchuxing.com/domains"] sort.Sort(sort.Reverse(sort.StringSlice(names))) if len(customHostStr) > 0 { customHosts := strings.Split(customHostStr, ";") for _, name := range names { if name != "default" { visibility := netv1alpha1.IngressVisibilityExternalIP rule := *makeIngressRule(customHosts, r.Namespace, visibility, name, targets[name]) // If this is a public rule, we need to configure ACME challenge paths. rule.HTTP.Paths = append( makeACMEIngressPaths(challengeHosts, customHosts), rule.HTTP.Paths...) rules = append(rules, rule) } } } ... } |
|---|
首先修改ksvc，添加对应的annotaiton，然后继续之前的操作进行编译，打镜像，原地升级，删除vs，新的vs自送生成，此时可以看到已经使我们期望的效果了，然后用域名访问，HelloWorld终于可以正常访问了。
总结
问题是解决了，但是为什么通过webhook的方式不生效，现象看起来是没调用webhook，还需要再去看下k8s有关webhook调用的部分的代码，很可能又是一个知识盲区。
knative中很多类型的属性并没有在上层暴露，导致无法直接使用ksvc进行管理，要么改源码，要么自己负责管理原本由ksvc统一管理的组件，虽然更加灵活，但是使用成本也更高，违背ksvc设计的初衷
通过此次问题排查，学习到了knative整个流程、原理，理清了各组件的交互，对后续问题排查有很大的帮助
