在/opt/目录下创建kong文件夹，然后创建一个docker-compose.yml文件并编辑
在docker-compose.yml添加如下配置（20220528亲测可用）
假设使用的是本地搭建
使用浏览器访问127.0.0.1:1337
注：端口号在docker-compose.yml中指定了1337
若是使用云服务器，注意做好DNS解析以及Nginx配置
这里给出一份可用的kong.conf
使用浏览器访问kong.YOUR_DOMAIN:1337
打开界面后，是要创建一个管理员账号的，按说明填写即可
先理解一下概念：
我们现在 *** 作的可视化平台是Konga
Konga通过调用Kong的admin url，对Kong网关进行配置管理
所以这一步我们需要将Konga和Kong搭上线
在Connection页面配置要管理的Kong网关
主要填写参数说明：
Name：必填，唯一，用于备忘
Kong Admin URL：Kong网关的管理路径，默认端口是8001，在docker-compose.yml可修改对外暴露的端口号
这里有个提示很显眼：Kong's admin API should not be publicly exposed
故我们在云服务器部署时，都应该注意8001的这个端口不应随意暴露出去，以免发生黑客攻击风险
进入Service菜单，点击 ADD NEW SERVICE（添加新服务）
这里我们假设要代理某度的服务
主要填写参数说明：
Name：非必填，服务名称，用于备忘这是一个什么服务
Protocol：必填，填写http或https，指请求转发到该服务时，使用哪种协议
Host：必填，填写被代理的主机地址
Port：必填，填写被代理的主机的端口号，默认80
点击刚才创建的服务，点击进入Route管理界面
点击ADD ROUTE
主要填写参数说明：
Name：非必填，路由名称，用于备忘识别这是一个什么路由
Paths：这是重点！具体看效果就明白了，这边添加“/”和“/api/baidu”，注意要回车
访问服务的接口为8000（在docker-compose.yml已配置）
若使用的是本地搭建
使用浏览器访问
若是部署到云服务器，并做好了域名解析
使用浏览器访问
都会被解析Route，指向对应的Service，返回的是某度的页面，搭建成功
当同一个服务为分布式或存在多个域名、ip时，我们可以通过配置Upstream，将这些服务统一起来
进入Upstream页面
点击ADD UPSTREAM
主要填写参数说明：
Name：必填，名称，用于关联Service中Host字段
进入刚添加的Upstream的Detail
进入Target管理页
点击ADD TARGET
主要填写参数说明：
Target：该服务具体的域名+端口，注意这里默认端口8000，故需要手动写80
Weight：权重
添加好后是这个样子
之后我们回到Service配置
将Host填写为刚刚命名，并保存
之后我们再次访问
能发现不仅能访问某度，还能访问到某奇广告网（因为baidu1.com、baidu2.com并不是某度搜索）
至于每次访问结果都有变化，是因为Upstream做了权重的负载均衡，因此实际访问的服务是
继续上一篇的灰度发布，本文重点讲述kong网关是如何配置灰度发布规则的。一、Kong网关在灰度发布中的重要作用
1、校验用户的htttp请求是否为灰度请求；
2、灰度规则的配置，允许多个规则的拼接；
3、需要为同一个service配置两个upstream，一个是正常的，另一个是灰度的。
二、主要流程
下面以用户服务为示例，演示在kong上面的 *** 作。
1、新建UserService
2、新建两个upstream
三、配置灰度规则
支持多个规则，规则之间可以是“且”“或”的关系。
rules是一个数组结构：示例如下
passway可以是header, parameter, cookie。
paramName就是我们说的Key值。
rule_type 是表示多个规则之间的逻辑关系。
至于判断是否匹配规则，是Lua的global.lua中的load()方法。
如果请求匹配上了灰度规则，下一步要做的就是设置对应的upstream了。
默认取的upstream是ngx.ctx.balancer_data.host，如果填写的不是它，则取UserServiceGray这个对应的upstream。
最后给请求打上灰度标签。
KONG为请求多个后端服务提供了多种负载均衡方案：一种是简单的基于DNS，另一种是更加动态的环形均衡器，他在不需要DNS服务器的情况下也允许服务注册。
当使用基于DNS的负载平衡时，后端服务的注册是在Kong之外完成，而Kong只接收来自DNS服务器的更新。如果请求的API被解析为多个IP地址，则已使用包含主机名（而不是IP地址）的upstream_url定义的每个API将自动使用基于DNS的负载平衡，前提是主机名未被解析为upstream名称或你的localhosts文件中的名称。DNS记录ttl设置（生存时间）确定刷新信息的频率。当设置ttl为0时，每个请求将使用自己的dns查询进行解析。显然这会带来性能损失，但更新/更改的延迟将非常低。
A记录包含一个或多个IP地址。因此，当主机名解析为A记录时，每个后端服务都必须有自己的IP地址。因为没有 weight 信息，所有条目在负载平衡器中将被视为同样的权重，平衡器将进行直线循环。来自DNS记录的IP地址的初始选择是随机的。这是为了确保即使当ttl为0时，负载也正确分配。
SRV记录包含所有IP地址的权重和端口信息。可以通过唯一的IP端口号的组合来标识后端服务。因此，单个IP地址可以托管不同端口上相同服务的多个实例。因为权重信息可用，每个条目将在负载平衡器中获得自己的权重，并且它将执行加权循环。
类似地，任何给定的端口信息将被来自DNS服务器的端口信息覆盖。如果一个API的 upstream_url= http://myhost.com:1234/path 并且 myhost.com 被解析为 SRV 记录中的 127.0.0.1:5678，此时的API将会被代理到 http://127.0.0.1:5678/path ，之前的 1234 端口会被重写为 5678 端口。IP地址+端口组合在初始时是随机选择的，这是为了确保服务能被正确分配，即使ttl设置为0。
tip：每当刷新DNS记录时，都会生成列表以正确处理加权。建议将权重保持为彼此的倍数以保证系统的性能。
DNS解析器按顺序开始解析以下记录类型：
1. 最后一个成功的类型优先解析；
2. SRV记录
3. A记录
4. CNAME记录
所以，如果你使用的主机名称中同时含有SRV记录和A记录时，将仅解析SRV实例。如果你想使用A记录，那么你必须得把SRV记录从DNS中删除。如果你只有A记录，则SRV记录查询失败，然后自动指向到A记录，并查询A记录是否存在，依次类推。
使用环形平衡器时，后台服务的添加和删除将由Kong处理，不需要进行DNS更新。KONG将扮演服务注册的角色。可以通过单个HTTP请求添加/删除节点，并可立即启动/停止接收请求流量。
可以通过配置 upstream 和 target 属性来配置环形均衡器。
默认情况下，一个环平衡器将使用一个加权循环的方案。另一种方法是使用基于散列的算法。散列的输入可以是 none , consumer , ip , 或者 header 。当设置为none时，将使用加权循环方案，并且将禁用哈希。
有两种选择，一种主要的和一种备用方案，以防主服务器出现故障（例如，如果主服务器被设置为 consumer ，但是没有经过身份验证）
不同的散列选项:
哈希算法是基于“一致性哈希”，它确保当平衡器通过改变目标（添加、移除、失败或改变权重）来修改时，只有最小的散列损失发生。这将最大优化上游缓存的命中。
一堆原理实在不好理解，下面来几个案例研究下：
这是一个安全部署应用的方法，它通过提供两个版本的应用同时运行。为了部署一个新版本的应用，你需要将当前版本切换到新版本，然后关闭老版本。Blue-green deployment不会使应用停止服务，在必要的情况下允许你快速回滚应用到blue版本。
设置“蓝色”环境，运行版本1的地址服务：
将主机头设置为 address.mydomain.com ，就可以让那Kong代理这个请求转发到定义的两个目标；三分之二的请求将发送到 http://192.168.34.15:80/address （权重=100），1/3将转到 http://192.168.34.16:80/address （权重=50）。
设置“绿色”环境，运行版本2的地址服务：
将主机头设置为 address.mydomain.com ，现在已经给Kong设置了一个新的目标；一半的请求将被发送到 http://192.168.34.17:80/address （权重=100），另外1/2将转到 http://192.168.34.18:80/address （权重=100）。
通常，通过Kong管理API的更改是动态的，并将立即生效。不需要重新加载或重启，在进度请求中不需要删除。
使用环型平衡器，目标权重可以精确地调整，允许一个平滑的、可控的金丝雀环境。
使用一个非常简单的2个目标示例：
通过重复请求，但是每次改变权重，流量将慢慢地路由到另一个目标。例如，将其设置为10%：
同样，通过Kong管理API的更改是动态的，并将立即生效。不需要重新加载或重启，在进度请求中不需要删除。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）