本帖最后由 Gerald.Zhang 于 2024-4-7 17:54 编辑
上一篇中，我们已经成功完成了活字格服务的安装，接下来，让我们来看一下在 k8s 上，负载均衡是如何表现的。
当我们成功安装后， 活字格服务对应的 deployment：forguncy-pod当中，默认只有一个 pod，我们可以通过 kubectl 命令查看具体的 pod 情况：
从输出可以看到，当前在 k8s 的default 命名空间中，稳定运行着 3 个 pod，分散在咱们给定的两个节点上，在 k8s-worker1 中运行着 influxDB 的一个 pod，在 k8s-worker2 中运行着活字格的 pod 和 redis 的 pod。
开启负载均衡
在单 pod 的前提下，我们登录到活字格服务器管理控制台中，开启负载均衡。
对应的负载均衡入口没有发生变化，仍处于设置列表中。当开启负载均衡后，需要将用户信息数据库配置到外联数据库中。此外，redis 的服务也同样需要配置。需要注意，考虑到 k8s 的特性，每次 pod 的创建与销毁，其 IP 都会发生变化，所以这里 redis 服务应当配置为 service 的名称，而不是特定的 IP。
ps：默认安装的 redis 服务是没有密码的。
测试连接成功后，点击保存，会重启活字格的服务，会重新生成新的 forguncy-pod。
此时，为了确保后续应用与节点的正常访问，请确保您的活字格集群已经激活 k8s 对应的授权。
动态扩容
当我们开启负载均衡并重启成功后，活字格侧的操作就完成了。后续所有的扩容、自愈行为都依赖于 k8s 本身的行为策略进行执行。
目前活字格的服务只有一个 pod ，现在可以根据咱们实际需要去动态的扩展节点了。 - # 将 pod 的节点升级到 6 个
- kubectl scale deployment fgc-chart-test-forguncy-pod --replicas=6
该命令为 kubectl 自带的动态扩容命令，k8s 会基于您设定的 replicas 值去动态的创建包含服务的 pod 并自动负载。可以通过 kubectl get pod 查看当前的 pod 状态。也可以在扩容的时候通过参数 —watch 查看 pod 的变化过程。
如果您希望查看请求被指向了哪个节点，可以通过修改对应的配置项开关来实现。对应的配置路径位于：
- /fgc-k8s-lbroot/ForguncySites/SettingsFolder/ForguncyRouterConfig.json
将其中的 ShowXUpstream 的值设置为 true 即可。重置 pod 数量后，可以通过 cookie 查看被指向的 pod 节点名称。
应用发布与路由
现在您可以向集群发布应用了。当应用发布成功后，应用的设置域名会自动配置为 http://{publishserver}/{appname}，例如： http://198.19.249.12:32666/stock-management，其中：
- {Publishserver} 198.19.249.12:32666是您在设计器中配置发布的服务器。
- {Appname} stock-management是您在设计器中发布的应用程序名称。
需要注意，由于咱们的应用服务是基于集群的，所以必须使用 外联库，使用内建库的应用会访问异常。
当然，在实际的运维场景中，我们可以需要对应用服务进行路由。对于活字格的一些服务来说也需要会话保持功能，所以我们需要开启 k8s 中 Ingress 和 Service 的会话保持配置（Service已在安装脚本中默认配置，Ingress需要手动添加）。 Ingress 可为 Service 提供外部可访问的 URL、对其流量作负载均衡、 终止 SSL/TLS，以及基于名称的虚拟托管等能力。当然，您也可以自己使用 nginx 的 ip_hash来模拟类似的效果。
如 Ingress 增加基于 Cokkie 的注解： - nginx.ingress.kubernetes.io/affinity: "cookie"
至此，k8s 的初体验分享到此结束，让我们期待新版本的到来把！
| 
陕公网安备：61019002000258 |
隐私政策 |
网站地图
