微服务动态路由实现:OpenResty+K8s

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介: 本文讲的是微服务动态路由实现:OpenResty+K8s,OpenResty是一个基于 Nginx 与Lua的高性能 Web 平台,其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。

第一部分:OpenResty是什么

image

本文讲的是微服务动态路由实现:OpenResty+K8s,OpenResty是一个基于 Nginx 与Lua的高性能 Web 平台,其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web 应用、Web 服务和动态网关。主要有章亦春维护。

OpenResty通过汇聚各种设计精良的 Nginx 模块(主要由OpenResty团队自主开发),从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。右边的列表中的组件被用于构建OpenResty。

image

先通过一个hello world的例子,来对OpenResty有个大概了解。

编写一个nginx.conf,在nginx.conf使用了content_by_lua,主要是ngx.say(“

hello,world

”),然后使用该配置文件启动nginx。当浏览器访问 http://xxx.xxx.xxx.xxx时,会看到页面显示的是 hello,world。

通过这个例子大概可以看到OpenResty能做些什么事,可以直接在nginx.conf中通过编写Lua脚本,实现一些需要编写代码来完成的功能。后面我们会继续介绍如何使用OpenResty。

第二部分:为什么要需要OpenResty

image

先来看看遇到的问题,大家都知道K8s Service能够提供很强大的功能,通过提供ClusterIP可以作为Pod的对外访问接口,并提供软负载均衡。

但是Service的ClusterIP地址只能在集群内部访问,如果是集群外部的用户要如何访问Service呢?Kubernetes通过两种方式来实现上述需求,一个是“NodePort”,另一个是“LoadBalancer”。

我们现在用的是NodePort的方式来使得Service可以被外部用户访问,这样带来的问题是:
1.外部访问服务时需要带NodePort
2.每次部署服务后,NodePort端口会改变

对于这2个问题,我们选择的是使用Nginx做反向代理,给服务暴露的http的端口起一个端口名(如web),通过“http://web. svc01.tenant01.cluster01.devops.tp”来代替“http:// svc01.tenant01.cluster01.devops.tp:35089”去访问服务,这样对于用户就屏蔽NodePort,多次部署后用户也不需要知道新的NodePort。
image

前面介绍了遇到的问题:需要屏蔽NodePort,这里介绍下为什么需要OpenResty,引入了OpenResty后如何做动态路由。

按照设想希望用户通过输入“http://web.svc01.tenant01.cluster01.devops.tp”地址来访问服务,这样就可以对用户屏蔽NodePort。这样就需要一层host转换来实现动态路由,如果直接使用nginx,就需要动态的修改nginx.conf,这样带来的问题就是需要能够动态的对nginx.conf做内容增减(添加/删除服务时),以及需要同时修改多个nginx.conf。这个听起来好像也不算方便。

使用OpenResty的话,可以和Redis结合。Redis里保存了service的host和clusterip:port的映射,当用户访问“http://web.svc01.tenant01.cluster01.devops.tp”时请求会被OpenResty拦截,OpenResty根据请求的host到redis里查询对应的service的clusterip:port,根据clusterip:port再做一次upstream去访问K8s Service。如果没有找到host对应的value则会抛出相应的httpstatus code(500,400)。

image

前面介绍了OpenResty如何利用Redis中的数据做动态路由,那么Redis中的数据是在何时写进去的?
因为使用了Reids,服务信息维护也相对简单,只需要在服务有变更时去操作Redis的主结点进行信息的增/删即可。

现在在新一代里在以下几个时机会去操作Redis中的数据:

• 服务创建:在服务创建后,如果服务的端口名带有web,则会向Redis写入服务的域名(key)以及对应的clusterip:port(value)。
• 服务销毁:在服务删除前,删除Redis中相应的服务的域名。
• 租户拉黑:查找租户相应的所有环境[开发、测试、…..],把这些环境里的所有服务在Redis里的key加上“$_.”前缀。
• 租户恢复:将租户拉黑时修改的key,去掉“$_.”的前缀。
• 租户销毁:查找租户相应的所有环境[开发、测试、…..],把这些环境里的所有服务在Redis里的key删除。

第三部分:如何在K8s上部署OpenResty

image

前面介绍完大致思路,接下来就进入实际操作阶段,第一步就是制作镜像。

使用到的镜像为:
OpenResty1.9.15.1
Redis3.2.1
phpRedisAdminmaster
镜像制作完成后提交到镜像私库供后续使用。

镜像制作时需要考虑镜像的配置可以通过配置文件,命令行参数和环境变量的组合配置来完成。这些配置应该从image内容中解耦,以此来保持容器化应用程序的便携性。

所以我们在制作镜像时将配置文件和启动脚本可以从外部mount,这样在调试时方便修改,不需要每次重新打镜像。

image

这里插播一下K8s ConfigMap,前面说了镜像制作时需要配置和镜像分离,那么在真正使用时,就需要将配置注入容器,这时候使用的就是K8s ConfigMap特性。

ConfigMap提供了将配置数据注入容器的方式,同时保持容器是不知道Kubernetes的。ConfigMap可以被用来保存单个属性,也可以用来保存整个配置文件或者JSON二进制大对象。

ConfigMap使用键-值对配置数据,这个数据可以在pods里使用。data 一栏包括了配置数据。就如同看到的那样,ConfigMap可以被用来保存单个属性,也可以用来保存一个配置文件。

配置数据可以通过很多种方式在Pods里被使用。ConfigMaps可以被用来:
• 设置环境变量的值
• 在容器里设置命令行参数
• 在数据卷里面创建config文件

在OpenResty部署中我们使用的是在数据卷里面创建config文件
image

先创建一个configmap目录,在configmap目录里有2个文件:
• redis.conf:保存的是reids的配置。
• run.sh:保存的是redis的启动脚本,根据环境变量来确定按那种模式启动redis。

通过使用”kubectl --namespace=euler-system createconfigmapsem-redis-configmap --from-file redis/configmap”可以将目录创建为ConfigMap。

ConfigMap里会有2个key,一个是”redis.conf”,一个是”run.sh”。 value分别对应的是文件内容。

创建完成后可以执行” kubectl --namespace=euler-system get configmapsem-redis-configmap-o yaml”查看ConfigMap的内容。

在部署时可以通过volume将ConfigMap的内容变成文件挂载到容器内。

image

Redis是按主从方式部署,主结点上还会安装phpRedisAdmin方便查看维护Redis的信息。从结点部署时需要指定需要关联主结点的服务名和端口号。

使用时需要注意volumes和volumeMounts。无论主从在部署时,都需要将ConfigMap作为一个volume,并且要将ConfigMap的key对应的内容保存成指定的文件名,如key=“redis.conf”,path=“redis.conf”表示将ConfigMap中key=”redis.conf”的内容保存到path=“redis.conf”的文件。

这个ConfigMap的volume会mount到容器内的一个目录”/app/configmap”。因为前面制作的镜像就会在/app/configmap目录下查找run.sh的启动脚本,并且脚本在启动时也使用到了/app/configmap/redis.conf的配置。这样就能正常启动。

这里没有使用Redis的sentinel,而是使用了K8s的RS来保证Redis主结点的可用性(Master停止后自动重启)。

image

步骤和创建Redis的ConfigMap一样,先创建一个configmap目录,在configmap目录里有2个文件:
• nginx.conf:保存的是nginx的配置。
• run.sh:保存的是nginx的启动脚本。

通过使用”kubectl --namespace=euler-system createconfigmapsem-openresty-configmap --from-file openresty/configmap”可以将目录创建为ConfigMap。

需要注意的是nginx.conf中的%resolver%,%redis_slave_svc_host%,%redis_slave_svc_port%
• resolver:是告诉nginx用哪个dns server去解析域名。在这里使用的是K8s集群里的skydns的地址。
• redis_slave_svc_host:指定需要连接到redis的slave的host地址。
• redis_slave_svc_port:指定需要连接到redis的slave的port。

这3个变量在容器启动时会由run.sh先进行变量替换,再启动ngixn
image

这里先介绍一下K8s Daemon Set,因为OpenResty的部署用到了Daemon Set,而不是Deployment。Daemon Set可确保所有的节点运行一个Pod。有新的节点添加到群集时,Pod会被被添加到其中。当节点从群集中移除,Pod会被删除。

DaemonSet的一些典型的用途是︰
• 在每个节点上运行群集存储守护进程,如 glusterd,ceph。
• 在每个节点上运行日志收集守护进程,如 fluentd ,logstash。
• 在每个节点上运行监控守护进程,如collectd,gmond。

可以看到主要用途是在每个节点上装一些守护进程,而我们的需求正好是在每个节点上都装一个OpenResty,这样经过前端DNS解析后可以转到任意一个节点的OpenResty。

本来打算是在每个节点上通过systemd管理这些服务,然后发现不是很方便,而K8s正好提供了Daemon Set,就用了Daemon Set。

image

OpenResty是按DaemonSet方式部署,注意kind是DaemonSet,然后需要设置REDIS_HOST和REDIS_PORT,告诉OpenResty需要连接哪的Redis。

需要注意volumes和volumeMounts。将ConfigMap作为一个volume,并且将ConfigMap的key对应的内容保存成指定的文件名,如key=“nginx.conf”,path=“nginx.conf”表示将ConfigMap中key=”nginx.conf”的内容保存到path=“ngixn.conf”的文件。

这个ConfigMap的volume会mount到容器内的一个目录”/app/configmap”。
因为前面制作的镜像就会在/app/configmap目录下查找run.sh的启动脚本,并且脚本在启动时也使用到了/app/configmap/nginx.conf的配置。这样就能正常启动。
image

到了这里OpenResty就部署完成了,可以看到在整个K8s集群中的每个monion节点上都部署了一个OpenResty的Pod,并在集群里部署了1个Redismaster Pod,2个Redis slave Pod。可以执行kubectl --namespace=euler-system get pod 查看namespace下的所有Pod。

当有K8s的Service被创建后,SEM会向Redis Master注册服务域名和clusterip:port的键值对。

这样用户就可以通过如“http://web.svc01.tenant01.cluster01.devops.tp”的url访问到服务了。

第四部分:新的选择Ingress

image

说是新的选择,不是指它是个新特性,是我自己知道的比较晚,原本以为ingress只能用于GCE/GKE环境,经我司春龙、潇男提醒,也可以用于本地环境。

一个Ingress(入口)是一系列允许访问集群服务的连接规则. 它可以为服务配置一个外部访问 url,负载均衡,SSL,以及提供基于名称的虚拟主机等。用户通过将入口资源发布到 API 服务器请求入口。进入控制器(Ingress Controller)负责履行入口,通常与一个负载均衡器一起工作。如在GoogleGCE上的Http Load Balancer,或者本地的Nginx。

IngressController 的大概工作流程是监控Ingress的变化,并将变化写Load Balancer的配置。在Nginx的Ingress Controller实现中会监听Ingress、Service、Endpoints、Secret对象的变化,并将变化写入nginx.conf文件,并重新加载nginx.conf。

上面的示例就是创建了一个Ingress,按照hostname和path可以将请求路由到K8s Service对应的Pod上。

image

今天的分享就到这里,谢谢大家。

原文发布时间为:2016-08-18
本文作者: 王文斌
本文来自云栖社区合作伙伴EAWorld,了解相关信息可以关注EAWorld。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
2月前
|
Kubernetes 负载均衡 微服务
Kubernetes 生态系统中的微服务治理
【8月更文第29天】随着微服务架构的普及,管理分布式系统的复杂性也随之增加。Kubernetes 作为容器编排的事实标准,为微服务架构提供了强大的支持。结合像 Istio 这样的服务网格工具,Kubernetes 能够有效地解决微服务治理中的诸多挑战,如服务发现、负载均衡、流量管理和安全策略等。
34 1
|
2月前
|
Kubernetes 监控 中间件
微服务从代码到k8s部署应有尽有系列全集
微服务从代码到k8s部署应有尽有系列全集
|
2天前
|
Kubernetes Docker 微服务
微服务实践k8s&dapr开发部署实验(1)服务调用(一)
微服务实践k8s&dapr开发部署实验(1)服务调用(一)
20 2
|
2天前
|
Kubernetes Cloud Native 微服务
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
15 1
|
3天前
|
Kubernetes Cloud Native 云计算
云原生时代的技术演进:Kubernetes与微服务架构的完美融合
随着云计算技术的飞速发展,云原生概念逐渐深入人心。本文将深入探讨云原生技术的核心——Kubernetes,以及它如何与微服务架构相结合,共同推动现代软件架构的创新与发展。文章不仅剖析了Kubernetes的基本工作原理,还通过实际案例展示了其在微服务部署和管理中的应用,为读者提供了一条清晰的云原生技术应用路径。
12 2
|
1天前
|
Kubernetes Docker 微服务
微服务实践k8s&dapr开发部署实验(1)服务调用(二)
微服务实践k8s&dapr开发部署实验(1)服务调用(二)
19 0
|
28天前
|
Kubernetes Docker 微服务
构建高效的微服务架构:基于Docker和Kubernetes的最佳实践
在现代软件开发中,微服务架构因其灵活性和可扩展性而受到广泛青睐。本文探讨了如何利用Docker和Kubernetes来构建高效的微服务架构。我们将深入分析Docker容器的优势、Kubernetes的编排能力,以及它们如何结合实现高可用性、自动扩展和持续部署。通过具体的最佳实践和实际案例,读者将能够理解如何优化微服务的管理和部署过程,从而提高开发效率和系统稳定性。
|
2月前
|
Kubernetes 监控 Docker
微服务与容器化:Kubernetes 实践
【8月更文第29天】随着云计算的发展,越来越多的企业选择采用微服务架构来构建他们的应用程序。微服务架构允许将复杂的大型应用程序拆分成一系列小型、独立的服务,这些服务可以独立部署、扩展和维护。然而,这种架构也带来了新的挑战,特别是在服务的部署、监控和扩展方面。容器化技术,尤其是 Kubernetes,已经成为解决这些挑战的关键工具。
56 0
|
存储 Kubernetes Ubuntu
kubernetes Spring Cloud 微服务架构— (2)Kubernetes spring cloud 微服务-Docker 镜像
在上章节对 Docker 有了初步的了解之后,在本章将学习容器镜像的加载流程,镜像的基本 操作以及与系统存储技术 OverlayFS 的关系。 第 2 章 Docker 镜像
630 0
|
存储 域名解析 Kubernetes
kubernetes Spring Cloud 微服务架构— (3)Kubernetes spring cloud 微服务-Docker 镜像存储机制
第 3 章 Docker 镜像存储机制 本章节是对上章节Docker镜像原理理解的巩固,从Linux系统运行基础到OverlayFS存储机制去了解与分析;在底层,镜像是怎样实现存储的;并且会详细说明存储文件的作用。
159 0