陈焰的笔记本

主要内容：keycloak 开源用户中心的集群模式部署

kubernetes 知识点：网络隔离策略

Infinispan

中国的程序员，对 redis 应该都不陌生。它通过 tcp 端口提供服务，是一种中心式的用法。我们把缓存数据放到上面，之后又觉得它撑不住，加了本地缓存做二级。我们把状态数据放上面，让我们自己能无状态，又希望它有足够的可用性，然后搞了各种类型的集群。

有没有可能，这些繁琐的高成本的用法。本身就像微服务中的注册中心一样，是只有在万人大厂的组织架构下才有本钱在服务层玩出收益的。就像是，我知道微信的接口的域名是多少，我就能调用它了，不用让微信的服务注册到我的 nacos 里吧。普通人能维护得起注册中心的地方，应该是中间件内置的注册中心，一个运维人员可以把控所有注册者，中间件本身内置写死了注册者的身份、行为、能力。对比服务层的注册中心，哪个组织来把控所有的注册者，又是什么团队来评审注册者的身份设计是否合理呢。

keycloak 里使用的 Infinispan，对比 redis 是另一种完全不一样的用法。就跟上面域名对比注册中心的用法一样，这里只是拓展一下思路，看看不一样的用法，不做好坏之分，往往商业和生态对一个软件项目的影响更大。

Infinispan 可以以 jar 包的方式提供，随着 jvm 一起启动，那么它使用的是跟项目代码一起的本地内存，天生的本地缓存。分布式集群方面，依赖 JGroups 来组织集群内的节点。Infinispan 里存储的数据，在所有节点之间同步。

JGroups

JGroups 组织集群内节点的通信。它在启动时会以广播的形式，在网络内寻找节点，自动组成一个集群。（之前被要求用 docker 在三个物理节点间搭 keycloak 集群，只能配静态节点，要了老命。）

kubernetes 下 pod 之间的网络默认是通的。假如我们有两个项目，在两个命名空间下，都需要启动 keycloak，那这两个无关的 keycloak 也会组成集群。我们需要配置网络策略，按命名空间做网络隔离。

网络策略

yaml

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: keycloak-isolation
  namespace: default
spec:
  egress:
    - to:
        - namespaceSelector:
            matchExpressions:
              - key: kubernetes.io/metadata.name
                operator: In
                values:
                  - kube-system
                  - default
  ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
              - key: kubernetes.io/metadata.name
                operator: In
                values:
                  - kube-system
                  - default
  podSelector:
    matchLabels:
      k8s.kuboard.cn/name: keycloak
  policyTypes:
    - Ingress
    - Egress

网络策略都是白名单。记着白名单这个词去理解，会轻松很多。

首先需要一个选择器，选中哪些工作负载需要应用这个网络策略。kuboard 界面上创建出来的工作负载，都自带了一个 k8s.kuboard.cn/name 标签，我们可以直接用这个标签做选择器。

可以配置出/入两个方向。kuboard 这里有个bug，在界面上配置，最终得到的 yaml 会遗漏出方向的配置，最好是直接编辑 yaml 文件。

在某个方向的规则里，我们用命名空间选择器，只有指定的命名空间下的流量可以通过。

注意，除了自身所在的命名空间，还至少要加上 kube-system 这个命名空间。服务之间是通过 Service 配出的集群内域名来访问的。域名的 DNS 解析，需要 kube-system。

Infinispan ​

JGroups ​

网络策略 ​

Infinispan

JGroups

网络策略