Knative Serving 之路由管理和 Ingress
Knative 默认会为每一个 Service 生成一个域名,并且 Istio Gateway 要根据域名判断当前的请求应该转发给哪个 Knative Service。Knative 默认使用的主域名是 example.com,这个域名是不能作为线上服务的。本文我首先介绍一下如何修改 默认主域名,然后再深入一层介绍如何添加自定义域名以及如何根据 path 关联到不同的 Knative Service。
Knative Serving 的默认域名 example.com
首先需要部署一个 Knative Service,可以参考 Knative 初体验:Serving Hello World。如果你已经有了一个 Knative 集群,那么直接把下面的内容保存到 helloworld.yaml 文件中。然后执行一下 kubectl apply -f helloworld.yaml
即可把 hello 服务部署到 helloworld namespace 中。
--- apiVersion: v1 kind: Namespace metadata: name: helloworld --- apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: hello namespace: helloworld spec: template: metadata: labels: app: hello annotations: autoscaling.knative.dev/target: "10" spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/simple-app:132e07c14c49 env: - name: TARGET value: "World!"
现在我们来看一下 Knative Service 自动生成的域名配置:
└─# kubectl -n helloworld get ksvc NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello.helloworld.example.com hello-wsnvc hello-wsnvc True
现在使用 curl 指定 Host 就能访问服务了。
- 首先获取到 Istio Gateway IP
└─# kubectl get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}" 47.95.191.136
- 访问 hello 服务
└─# curl -H "Host: hello.helloworld.example.com" http://47.95.191.136/ Hello World!!
如果想要在浏览器中访问 hello 服务需要先做 host 绑定,把域名 hello.helloworld.example.com 指向 47.95.191.136 才行。这种方式还不能对外提供服务。
使用自定义主域名
下面我来介绍一下如何把默认的 example.com 改成我们自己的域名,假设我们自己的域名是:serverless.kuberun.com,现在执行 kubectl edit cm config-domain --namespace knative-serving
如下图所示,添加 serverless.kuberun.com 到 ConfigMap 中,然后保存退出就完成了自定义主域名的配置。
再来看一下 Knative Service 的域名, 如下所示已经生效了。
└─# kubectl -n helloworld get ksvc NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello.helloworld.serverless.kuberun.com hello-wsnvc hello-wsnvc True
泛域名解析
Knative Service 默认生成域名的规则是 servicename.namespace.use-domain 。所以不同的 namespace 会生成不同的子域名,每一个 Knative Service 也会生成一个唯一的子域名。为了保证所有的 Service 服务都能在公网上面访问到,需要做一个泛域名解析。把 *.serverless.kuberun.com
解析到 Istio Gateway 47.95.191.136 上面去。如果你是在阿里云(万网)上面购买的域名,你可以通过如下方式配置域名解析:
现在直接通过浏览器访问 http://hello.helloworld.serverless.kuberun.com/ 就可以直接看到 helloworld 服务了:
## 自定义服务域名
刚才我们给 Knative 指定了一个主域名,使得 Service 基于主域名生成自己的唯一域名。但自动生成的域名不是很友好,比如刚才部署的 helloworld 的域名 hello.helloworld.serverless.kuberun.com
对于普通用户来说意义不明显、不好记忆。
如果能通过 hello.kuberun.com
访问 hello world 服务那就完美了,接下来我来介绍实现方法:
- 先在万网上面修改域名解析,把 hello.kuberun.com 的 A 记录指向 Istio Gateway 47.95.191.136
-
hello.kuberun.com 解析到 Istio Gateway 以后 Istio Gateway 并不知道此应该转发到哪个服务,所以还需要配置 VirtualService 告知 Istio 如何转发,把下面的内容保存到
hello-ingress-route.yaml
文件:apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: hello-ingress-route namespace: knative-serving spec: gateways: - knative-ingress-gateway hosts: - hello.helloworld.serverless.kuberun.com - hello.kuberun.com http: - match: - uri: prefix: "/" rewrite: authority: hello.helloworld.svc.cluster.local retries: attempts: 3 perTryTimeout: 10m0s route: - destination: host: istio-ingressgateway.istio-system.svc.cluster.local port: number: 80 weight: 100 timeout: 10m0s websocketUpgrade: true
现在打开 http://hello.kuberun.com/ 就能看到 helloworld 服务了:
基于路径的服务转发
真实线上服务的场景可能是一个路径后端对应着一个应用,现在我们对刚才的 hello.kuberun.com 进行一下扩展。让 /blog 开头的路径映射到 blog service,其他的路径还是原样打到 hello service 上面。
把下面的内容保存到 blog.yaml
文件,然后执行: kubectl apply -f blog.yaml
即可完成 blog 服务的部署。
--- apiVersion: v1 kind: Namespace metadata: name: blog --- apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: hello-blog namespace: blog spec: template: metadata: labels: app: hello annotations: autoscaling.knative.dev/target: "10" spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/simple-app:132e07c14c49 env: - name: TARGET value: "Blog!"
查看 blog 服务的默认域名:
└─# kubectl -n blog get ksvc NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello-blog.blog.serverless.kuberun.com hello-zbm7q hello-zbm7q True
现在使用浏览器打开 http://hello-blog.blog.serverless.kuberun.com 就可以访问刚刚部署的服务了:
这是默认域名,我们的需求是想要通过 http://hello.kuberun.com/blog 访问, 所以还需要修改 Istio VirtualService 的配置。如下所示在 hello-ingress-route.yaml 增加 /blog 的配置:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: hello-ingress-route namespace: knative-serving spec: gateways: - knative-ingress-gateway hosts: - hello.helloworld.serverless.kuberun.com - hello.kuberun.com http: - match: - uri: prefix: "/blog" rewrite: authority: hello-blog.blog.svc.cluster.local retries: attempts: 3 perTryTimeout: 10m0s route: - destination: host: istio-ingressgateway.istio-system.svc.cluster.local port: number: 80 weight: 100 - match: - uri: prefix: "/" rewrite: authority: hello.helloworld.svc.cluster.local retries: attempts: 3 perTryTimeout: 10m0s route: - destination: host: istio-ingressgateway.istio-system.svc.cluster.local port: number: 80 weight: 100 timeout: 10m0s websocketUpgrade: true
现在就能在浏览器中打开 http://hello.kuberun.com/blog 如下所示:
小结
本文主要围绕 Knative Service 域名展开介绍了 Knative Service 的路由管理。您应该了解到如下内容:
- Knative Service 默认的主域名是 example.com, 所有 Knative Service 生成的独立域名都是这个主域名的子域名
- Knative Service 生成的域名规范
- 如何配置 Knative Service 使用自定义的主域名,以及如何配置公网域名解析
- 如何基于 Istio VirtualService 实现 Knative Service 的个性化 Ingress 配置,提供生产级别的服务路由
作者:冬岛
原文链接
本文为云栖社区原创内容,未经允许不得转载。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Spring Cloud与Dubbo的完美融合之手「Spring Cloud Alibaba」
很早以前,在刚开始搞Spring Cloud基础教程的时候,写过这样一篇文章:《微服务架构的基础框架选择:Spring Cloud还是Dubbo?》,可能不少读者也都看过。之后也就一直有关于这两个框架怎么选的问题出来,其实文中我有明确的提过,Spring Cloud与Dubbo的比较本身是不公平的,主要前者是一套较为完整的架构方案,而Dubbo只是服务治理与RPC实现方案。 由于Dubbo在国内有着非常大的用户群体,但是其周边设施与组件相对来说并不那么完善。很多开发者用户又很希望享受Spring Cloud的生态,因此也会有一些Spring Cloud与Dubbo一起使用的案例与方法出现,但是一直以来大部分Spring Cloud整合Dubbo的使用方案都比较别扭。这主要是由于Dubbod的注册中心采用了ZooKeeper,而开始时Spring Cloud体系中的注册中心并不支持ZooKeeper,所以很多方案是存在两个不同注册中心的,之后即使Spring Cloud支持了ZooKeeper,但是由于服务信息的粒度与存储也不一致。所以,长期以来,在服务治理层面上,这两者一直都一套完美的...
- 下一篇
移动开发中的 Web:WebView、WebKit、JSCore、Web 优化、热修复、跨平台、Native、Hybrid……
移动开发领域近年来已经逐渐告别了野蛮生长的时期,进入了相对成熟的时代。而一直以来 Native 和 Web 的争论从未停止,通过开发者孜孜不倦的努力,Web 的效率和 Native 的体验也一直在寻求着平衡。本文聚焦 iOS 开发和 Web 开发的交叉点,内容涉及到 iOS 开发中全部的 Web 知识,涵盖从基础使用到 WebKit、从 JSCore 到大前端、从 Web 优化到业务扩展等方面,希望通过简要的介绍,帮助开发者一窥 Hybrid 和大前端的构想。 iOS 中 Web 容器与加载 1. iOS 中的 Web 容器 目前 iOS 系统为开发者提供三种方式来展示 Web 内容,分别是 UIWebView、WKWebView 和 SFSafariViewController: UIWebView UIWebView 从 iOS2开始就作为 App 内展示 Web 内容的容器,但是长久以来一直遭受开发者的诟病,它存在系统级的内存泄露、极高内存峰值、较差的稳定性、Touch Delay 以及 JavaScript 的运行性能和通信限制等问题。在 iOS12 以后已经被标记为 Depr...
相关文章
文章评论
共有0条评论来说两句吧...