微服务动态路由实现：OpenResty+K8s
微服务动态路由实现：OpenResty+K8s
& 16:43:13&&&&&
转载本文需注明出处：EAII企业架构创新研究院，违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复公众号：“EAII企业架构创新研究院”。（微信号：eaworld）
K8s Service能够提供很强大的功能，通过提供ClusterIP可以作为Pod的对外访问接口，并提供软负载均衡。但是Service的ClusterIP地址只能在集群内部访问，如何让集群外部的用户访问Service呢，如果选择了NodePort方式对外暴露服务，会造成用户对端口敏感，端口的变化会对用户造成不便，如何既能享受到Service的好处，又不让用户需要敏感内部实现呢？
大家好，我是王文斌，很荣幸有这次机会和大家分享交流，今天向各位分享的主题是《微服务的路由实现: OpenResty+K8s》，介绍在新一代平台中如何将OpenResty与Kubernetes结合使用的经验，有些理解不对或者使用不对的地方还请大家指正。
本次分享分为：
介绍OpenResty是什么，以及通过一个hello
world简单了解下OpenResty
为什么需要OpenResty，主要解决哪些问题？
如何在K8s上部署OpenResty，如何使用ConfigMap，DaemonSet
新的选择：Ingress
先来看下OpenResty是什么
OpenResty是一个基于 Nginx 与Lua的高性能 Web 平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。主要有章亦春维护。
OpenResty通过汇聚各种设计精良的 Nginx 模块（主要由OpenResty团队自主开发），从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。右边的列表中的组件被用于构建OpenResty。
先通过一个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，想用它解决什么问题？
先来看看遇到的问题，大家都知道K8s Service能够提供很强大的功能，通过提供ClusterIP可以作为Pod的对外访问接口，并提供软负载均衡。
但是Service的ClusterIP地址只能在集群内部访问，如果是集群外部的用户要如何访问Service呢？Kubernetes通过两种方式来实现上述需求，一个是“NodePort”，另一个是“LoadBalancer”。
我们现在用的是NodePort的方式来使得Service可以被外部用户访问，这样带来的问题是：
外部访问服务时需要带NodePort
每次部署服务后，NodePort端口会改变
对于这2个问题，我们选择的是使用Nginx做反向代理，给服务暴露的http的端口起一个端口名(如web)，通过“http://web. svc01.tenant01.cluster01.devops.tp”来代替“http://
svc01.tenant01.cluster01.devops.tp:35089”去访问服务，这样对于用户就屏蔽NodePort，多次部署后用户也不需要知道新的NodePort。
前面介绍了遇到的问题：需要屏蔽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则会抛出相应的http status code(500,400)。
前面介绍了OpenResty如何利用Redis中的数据做动态路由，那么Redis中的数据是在何时写进去的？
因为使用了Reids，服务信息维护也相对简单，只需要在服务有变更时去操作Redis的主结点进行信息的增／删即可。
现在在新一代里在以下几个时机会去操作Redis中的数据：
?&&&&& 服务创建：在服务创建后，如果服务的端口名带有web，则会向Redis写入服务的域名（key）以及对应的clusterip:port（value）。
?&&&&& 服务销毁：在服务删除前，删除Redis中相应的服务的域名。
?&&&&& 租户拉黑：查找租户相应的所有环境［开发、测试、…..］，把这些环境里的所有服务在Redis里的key加上“$_.”前缀。
?&&&&& 租户恢复：将租户拉黑时修改的key，去掉“$_.”的前缀。
?&&&&& 租户销毁：查找租户相应的所有环境［开发、测试、…..］，把这些环境里的所有服务在Redis里的key删除。
前面介绍完大致思路，接下来就进入实际操作阶段，第一步就是制作镜像。
使用到的镜像为：
OpenResty1.9.15.1
Redis 3.2.1
phpRedisAdminmaster
镜像制作完成后提交到镜像私库供后续使用。
镜像制作时需要考虑镜像的配置可以通过配置文件，命令行参数和环境变量的组合配置来完成。这些配置应该从image内容中解耦，以此来保持容器化应用程序的便携性。
所以我们在制作镜像时将配置文件和启动脚本可以从外部mount，这样在调试时方便修改，不需要每次重新打镜像。
这里插播一下K8s ConfigMap，前面说了镜像制作时需要配置和镜像分离，那么在真正使用时，就需要将配置注入容器，这时候使用的就是K8s ConfigMap特性。
ConfigMap提供了将配置数据注入容器的方式，同时保持容器是不知道Kubernetes的。ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制大对象。
ConfigMap使用键－值对配置数据，这个数据可以在pods里使用。data 一栏包括了配置数据。就如同看到的那样，ConfigMap可以被用来保存单个属性，也可以用来保存一个配置文件。
配置数据可以通过很多种方式在Pods里被使用。ConfigMaps可以被用来：
?&&&&& 设置环境变量的值
?&&&&& 在容器里设置命令行参数
?&&&&& 在数据卷里面创建config文件
在OpenResty部署中我们使用的是在数据卷里面创建config文件
先创建一个configmap目录，在configmap目录里有2个文件：
· redis.conf：保存的是reids的配置。
· run.sh：保存的是redis的启动脚本，根据环境变量来确定按那种模式启动redis。
通过使用”kubectl --namespace=euler-system create
configmapsem-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的内容变成文件挂载到容器内。
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停止后自动重启）。
步骤和创建Redis的ConfigMap一样，先创建一个configmap目录，在configmap目录里有2个文件：
· nginx.conf：保存的是nginx的配置。
· run.sh：保存的是nginx的启动脚本。
通过使用”kubectl --namespace=euler-system create
configmapsem-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
这里先介绍一下K8s Daemon Set，因为OpenResty的部署用到了Daemon Set，而不是Deployment。Daemon Set可确保所有的节点运行一个Pod。有新的节点添加到群集时，Pod会被被添加到其中。当节点从群集中移除，Pod会被删除。
Daemon Set的一些典型的用途是︰
·&&&&&&&&
在每个节点上运行群集存储守护进程，如 glusterd，ceph。
·&&&&&&&&
在每个节点上运行日志收集守护进程，如 fluentd ，logstash。
·&&&&&&&&
在每个节点上运行监控守护进程，如collectd，gmond。
可以看到主要用途是在每个节点上装一些守护进程，而我们的需求正好是在每个节点上都装一个OpenResty，这样经过前端DNS解析后可以转到任意一个节点的OpenResty。
本来打算是在每个节点上通过systemd管理这些服务，然后发现不是很方便，而K8s正好提供了Daemon Set，就用了Daemon Set。
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的配置。这样就能正常启动。
到了这里OpenResty就部署完成了，可以看到在整个K8s集群中的每个monion节点上都部署了一个OpenResty的Pod，并在集群里部署了1个Redis master 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只能用于GCE/GKE环境，经我司春龙、潇男提醒，也可以用于本地环境。
一个Ingress(入口)是一系列允许访问集群服务的连接规则. 它可以为服务配置一个外部访问 url，负载均衡，SSL，以及提供基于名称的虚拟主机等。用户通过将入口资源发布到 API 服务器请求入口。进入控制器(Ingress Controller)负责履行入口，通常与一个负载均衡器一起工作。
与本文相关的实践案例&
与本文相关的媒体文章&Sponsered by
Nginx 静态文件服务
我们先来看看最简单的本地静态文件服务配置示例：
charset utf-8;
index.html index.
就这些？恩，就这些！如果只是提供简单的对外静态文件，它真的就可以用了。可是他不完美，远远没有发挥 Nginx 的半成功力，为什么这么说呢，看看下面的配置吧，为了大家看着方便，我们把每一项的作用都做了注释。
# 这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，
# 建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。
open_file_cache max=204800 inactive=20s;
# open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，
# 如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个
# 文件在inactive 时间内一次没被使用，它将被移除。
open_file_cache_min_uses 1;
# 这个是指多长时间检查一次缓存的有效信息
open_file_cache_valid 30s;
# 默认情况下，Nginx的gzip压缩是关闭的， gzip压缩功能就是可以让你节省不
# 少带宽，但是会增加服务器CPU的开销哦，Nginx默认只对text/html进行压缩 ，
# 如果要对html之外的内容进行压缩传输，我们需要手动来设置。
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/
charset utf-8;
index.html index.
我们都知道，应用程序和网站一样，其性能关乎生存。但如何使你的应用程序或者网站性能更好，并没有一个明确的答案。代码质量和架构是其中的一个原因，但是在很多例子中我们看到，你可以通过关注一些十分基础的应用内容分发技术（basic application delivery techniques），来提高终端用户的体验。其中一个例子就是实现和调整应用栈（application stack）的缓存。
文件缓存漫谈
一个 web 缓存坐落于客户端和原始服务器（origin server）中间，它保留了所有可见内容的拷贝。如果一个客户端请求的内容在缓存中存储，则可以直接在缓存中获得该内容而不需要与服务器通信。这样一来，由于 web 缓存距离客户端“更近”，就可以提高响应性能，并更有效率的使用应用服务器，因为服务器不用每次请求都进行页面生成工作。
在浏览器和应用服务器之间，存在多种潜在缓存，如：客户端浏览器缓存、中间缓存、内容分发网络（CDN）和服务器上的负载平衡和反向代理。缓存，仅在反向代理和负载均衡的层面，就对性能提高有很大的帮助。
举个例子说明，去年，我接手了一项任务，这项任务的内容是对一个加载缓慢的网站进行性能优化。首先引起我注意的事情是，这个网站差不多花费了超过 1 秒钟才生成了主页。经过一系列调试，我发现加载缓慢的原因在于页面被标记为不可缓存，即为了响应每一个请求，页面都是动态生成的。由于页面本身并不需要经常性的变更，并且不涉及个性化，那么这样做其实并没有必要。为了验证一下我的结论，我将页面标记为每 5 秒缓存一次，仅仅做了这一个调整，就能明显的感受到性能的提升。第一个字节到达的时间降低到几毫秒，同时页面的加载明显要更快。
并不是只有大规模的内容分发网络（CDN）可以在使用缓存中受益——缓存还可以提高负载平衡器、反向代理和应用服务器前端 web 服务的性能。通过上面的例子，我们看到，缓存内容结果，可以更高效的使用应用服务器，因为不需要每次都去做重复的页面生成工作。此外，Web 缓存还可以用来提高网站可靠性。当服务器宕机或者繁忙时，比起返回错误信息给用户，不如通过配置 Nginx 将已经缓存下来的内容发送给用户。这意味着，网站在应用服务器或者数据库故障的情况下，可以保持部分甚至全部的功能运转。
下面讨论如何安装和配置 Nginx 的基础缓存（Basic Caching）。
如何安装和配置基础缓存
我们只需要两个命令就可以启用基础缓存： 和 。proxy_cache_path 用来设置缓存的路径和配置，proxy_cache 用来启用缓存。
proxy_cache_path/path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m
use_temp_path=
location / {
proxy_cache my_
proxy_pass http://my_
proxy_cache_path 命令中的参数及对应配置说明如下：
用于缓存的本地磁盘目录是 /path/to/cache/
levels 在 /path/to/cache/ 设置了一个两级层次结构的目录。将大量的文件放置在单个目录中会导致文件访问缓慢，所以针对大多数部署，我们推荐使用两级目录层次结构。如果 levels 参数没有配置，则 Nginx 会将所有的文件放到同一个目录中。
keys_zone 设置一个共享内存区，该内存区用于存储缓存键和元数据，有些类似计时器的用途。将键的拷贝放入内存可以使 Nginx 在不检索磁盘的情况下快速决定一个请求是 HIT 还是 MISS，这样大大提高了检索速度。一个 1MB 的内存空间可以存储大约 8000 个 key，那么上面配置的 10MB 内存空间可以存储差不多 80000 个 key。
max_size 设置了缓存的上限（在上面的例子中是 10G）。这是一个可选项；如果不指定具体值，那就是允许缓存不断增长，占用所有可用的磁盘空间。当缓存达到这个上线，处理器便调用 cache manager 来移除最近最少被使用的文件，这样把缓存的空间降低至这个限制之下。
inactive 指定了项目在不被访问的情况下能够在内存中保持的时间。在上面的例子中，如果一个文件在 60 分钟之内没有被请求，则缓存管理将会自动将其在内存中删除，不管该文件是否过期。该参数默认值为 10 分钟（10m）。注意，非活动内容有别于过期内容。Nginx 不会自动删除由缓存控制头部指定的过期内容（本例中 Cache-Control:max-age=120）。过期内容只有在 inactive 指定时间内没有被访问的情况下才会被删除。如果过期内容被访问了，那么 Nginx 就会将其从原服务器上刷新，并更新对应的 inactive 计时器。
Nginx 最初会将注定写入缓存的文件先放入一个临时存储区域，use_temp_path=off 命令指示 Nginx 将在缓存这些文件时将它们写入同一个目录下。我们强烈建议你将参数设置为 off 来避免在文件系统中不必要的数据拷贝。use_temp_path 在 Nginx 1.7 版本和 Nginx Plus R6 中有所介绍。
最终，proxy_cache 命令启动缓存那些 URL 与 location 部分匹配的内容（本例中，为 /）。你同样可以将 proxy_cache 命令添加到 server 部分，这将会将缓存应用到所有的那些 location 中未指定自己的 proxy_cache 命令的服务中。
陈旧总比没有强
Nginx 内容缓存的一个非常强大的特性是：当无法从原始服务器获取最新的内容时，Nginx 可以分发缓存中的陈旧（stale，编者注：即过期内容）内容。这种情况一般发生在关联缓存内容的原始服务器宕机或者繁忙时。比起对客户端传达错误信息，Nginx 可发送在其内存中的陈旧的文件。Nginx 的这种代理方式，为服务器提供额外级别的容错能力，并确保了在服务器故障或流量峰值的情况下的正常运行。为了开启该功能，只需要添加
命令即可：
location / {
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
按照上面例子中的配置，当 Nginx 收到服务器返回的 error，timeout 或者其他指定的 5xx 错误，并且在其缓存中有请求文件的陈旧版本，则会将这些陈旧版本的文件而不是错误信息发送给客户端。
Nginx 提供了丰富的可选项配置用于缓存性能的微调。下面是使用了几个配置的例子：
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m
use_temp_path=
location / {
proxy_cache my_
proxy_cache_
proxy_cache_min_uses 3;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_
proxy_pass http://my_
这些命令配置了下列的行为：
指示 Nginx 在刷新来自服务器的内容时使用 GET 请求。如果客户端的请求项已经被缓存过了，但是在缓存控制头部中定义为过期，那么 Nginx 就会在 GET 请求中包含 If-Modified-Since 字段，发送至服务器端。这项配置可以节约带宽，因为对于 Nginx 已经缓存过的文件，服务器只会在该文件请求头中 Last-Modified 记录的时间内被修改时才将全部文件一起发送。
该指令设置同一链接请求达到几次即被缓存，默认值为 1 。当缓存不断被填满时，这项设置便十分有用，因为这确保了只有那些被经常访问的内容会被缓存。
中的 updating 参数告知 Nginx 在客户端请求的项目的更新正在原服务器中下载时发送旧内容，而不是向服务器转发重复的请求。第一个请求陈旧文件的用户不得不等待文件在原服务器中更新完毕。陈旧的文件会返回给随后的请求直到更新后的文件被全部下载。
被启用时，当多个客户端请求一个缓存中不存在的文件（或称之为一个 MISS），只有这些请求中的第一个被允许发送至服务器。其他请求在第一个请求得到满意结果之后在缓存中得到文件。如果不启用 proxy_cache_lock，则所有在缓存中找不到文件的请求都会直接与服务器通信。
跨多硬盘分割缓存
使用 Nginx 不需要建立一个 RAID（磁盘阵列）。如果有多个硬盘，Nginx 可以用来在多个硬盘之间分割缓存。下面是一个基于请求 URI 跨越两个硬盘之间均分缓存的例子：
proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m max_size=10g
inactive=60m use_temp_path=
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m max_size=10g inactive=60m use_temp_path=
split_clients $request_uri $my_cache {
50% "my_cache_hdd1";
50% "my_cache_hdd2";
location / {
proxy_cache $my_
proxy_pass http://my_