K8sService能够提供很强大的功能，通过提供ClusterIP可以作为Pod的对外访问接口，并提供软负载均衡。但是Service的ClusterIP地址只能在集群内部访问，如何让集群外部的用户访问Service呢，如果选择了NodePort方式对外暴露服务，会造成用户对端口敏感，端口的变化会对用户造成不便，如何既能享受到Service的好处，又不让用户需要敏感内部实现呢？
大家好，今天向各位分享的主题是《微服务的路由实现: OpenResty+K8s》，介绍在新一代平台中如何将OpenResty与Kubernetes结合使用的经验，有些理解不对或者使用不对的地方还请大家指正。
本次分享分为：
1.介绍OpenResty是什么，以及通过一个hello world简单了解下OpenResty
2.为什么需要OpenResty，主要解决哪些问题？
3.如何在K8s上部署OpenResty，如何使用ConfigMap，DaemonSet
4.新的选择：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
http://xxx.xxx.xxx.xxx通过这个例子大概可以看到OpenResty能做些什么事，可以直接在nginx.conf中通过编写Lua脚本，实现一些需要编写代码来完成的功能。后面我们会继续介绍如何使用OpenResty。
第二部分：为什么要需要OpenResty
先来看看遇到的问题，大家都知道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。
前面介绍了遇到的问题：需要屏蔽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)。
前面介绍了OpenResty如何利用Redis中的数据做动态路由，那么Redis中的数据是在何时写进去的？
因为使用了Reids，服务信息维护也相对简单，只需要在服务有变更时去操作Redis的主结点进行信息的增／删即可。
现在在新一代里在以下几个时机会去操作Redis中的数据：
服务创建：在服务创建后，如果服务的端口名带有web，则会向Redis写入服务的域名（key）以及对应的clusterip:port（value）。
服务销毁：在服务删除前，删除Redis中相应的服务的域名。
租户拉黑：查找租户相应的所有环境［开发、测试、…..］，把这些环境里的所有服务在Redis里的key加上“$_.”前缀。
租户恢复：将租户拉黑时修改的key，去掉“$_.”的前缀。
租户销毁：查找租户相应的所有环境［开发、测试、…..］，把这些环境里的所有服务在Redis里的key删除。
第三部分：如何在K8s上部署OpenResty
前面介绍完大致思路，接下来就进入实际操作阶段，第一步就是制作镜像。
使用到的镜像为：
OpenResty1.9.15.1
Redis3.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 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的内容变成文件挂载到容器内。
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 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
这里先介绍一下K8s Daemon Set，因为OpenResty的部署用到了Daemon Set，而不是Deployment。Daemon Set可确保所有的节点运行一个Pod。有新的节点添加到群集时，Pod会被被添加到其中。当节点从群集中移除，Pod会被删除。
DaemonSet的一些典型的用途是