共计 2597 个字符,预计需要花费 7 分钟才能阅读完成。
前言
前文曾经部署了高可用的 Kubernetes 集群以及 Rancher 集群,这两天正好须要提前部署 seata-server,推敲着正好趁这个危险不大的机会试验一下 Kubernetes,特此记录下。
架构形容
在正式部署之前,我有必要形容下现有架构的现状。现有架构次要是基于 SpringCloud 框架搭建的微服务体系,配置核心和服务注册核心应用的都是阿里的 Nacos 组件。
从架构转型角度来说,全面切换至 Kubernetes 为根底的微服务体系必定不够事实,从现有支流的计划来说,个别是应用 Kubernetes 做根底措施,利用其做服务编排调度,软件层面还是基于 SpringCloud 的开发方式,这也是比拟事实的逐渐切换的计划。
那么目前就架构来说,seata-server 会部署在 Kuberetes 上治理,seata 客户端利用应用 Docker 容器部署,Nacos 服务是二进制形式物理装置。seata-server 因为没有治理后盾,所以并不需要对外裸露服务,只须要 seata 客户端利用可能进行服务间调用即可。
部署过程
本次过程形容重点并不是怎么部署能力使 seata-server 可能应用,而是通过 Kubernetes 部署利用的过程。
Seata 官网文档反对 Kubernetes 的部署形式,并提供了 YAML 格局的资源文件(因为应用了 Nacos 形式,应用了自定义文件):
apiVersion: apps/v1
kind: Deployment
metadata:
name: seata-server
namespace: default
labels:
k8s-app: seata-server
spec:
replicas: 1
selector:
matchLabels:
k8s-app: seata-server
template:
metadata:
labels:
k8s-app: seata-server
spec:
containers:
- name: seata-server
image: docker.io/seataio/seata-server:latest
imagePullPolicy: IfNotPresent
env:
- name: SEATA_CONFIG_NAME
value: file:/root/seata-config/registry
ports:
- name: http
containerPort: 8091
protocol: TCP
volumeMounts:
- name: seata-config
mountPath: /root/seata-config
volumes:
- name: seata-config
configMap:
name: seata-server-config
---
apiVersion: v1
kind: ConfigMap
metadata:
name: seata-server-config
data:
registry.conf: |
registry {
type = "nacos"
nacos {
application = "seata-server" #依据须要配置 nacos 信息
serverAddr = "192.168.199.2"
}
}
config {
type = "nacos"
nacos {
serverAddr = "192.168.199.2"
group = "SEATA_GROUP"
}
}
能够通过以下命令提交资源:
kubectl apply -f seata-server.yaml
当然,也能够通过 Rancher 界面来创立:
这个过程很迅速,就能够看到 2 个 Pod 启动胜利。
Pod 内部拜访形式
seata-server 作为服务注册至 Nacos 上,为了满足服务间调用的须要,对应的 Pod 须要可能被集群内部拜访到,这就牵扯到 Kubernetes 裸露服务的几种形式(粗略说一下):
-
间接定义 Pod 网络
hostNetwork: true 和 hostPort,这两种办法是间接配置 Pod 的网络,前者相当于间接应用宿主机网络,后者是做容器端口和主机节点端口映射。这种形式的毛病不言而喻,因为 Pod 的调度,必须明确晓得以后 Pod 所在节点的 IP 能力拜访,而且因为指定端口,所以 Pod 数量不能超过总的集群节点数量。然而在咱们这次的应用场景里不会呈现这样的问题,seata 客户端通过 Nacos 获取 seata-server 服务的地址进行调用,即便 Pod 的 IP 变动也没有关系,惟一须要留神的就是 Pod 数量不能超过集群总节点数量。
-
通过 service
NodePort 和 LoadBalancer,前者在任何状况下都不倡议采纳,后者是裸露服务到公网的规范形式,具体的这里就不多说了。
-
Ingress
Ingress 可能是裸露服务的最弱小形式, 但同时也是最简单的。好吧有这句话曾经够了,前面再独自钻研。
通过以上篇幅其实答案曾经有了,在这个场景下,我抉择 HostPort 的形式,具体实现很简略,配置 Pod,减少 HostPort 属性:
如果是 Rancher
IP 问题
seata-server 尽管部署胜利,然而注册到 Nacos 上的 IP 是 Kubernetes 外部集群 IP:
如此的话,seata 客户端利用是无法访问到 seata-server 服务的,除非 nacos 和 seata 客户端利用也部署在 Kubernetes 集群外部,但显然目前无奈进行这么大的改革。所以解决问题的办法就是让 seata-server 的注册 IP 是宿主机 IP,查阅了 seata 官网文档,是反对相干配置的:
又查阅了 Kubernetes 相干的文档:用 Pod 字段作为环境变量的值
依据文档,批改 YAML,如下:
应用 Rancher 配置如下
端口问题
实践上来说,应用 Kubernetes 部署利用应该无需关怀 IP 和端口的问题,调度的过程应该是无条件的。然而因为咱们应用的内部 Nacos 做服务注册,导致服务间调用必须明确晓得服务的 IP 和端口号,无形中也给 Pod 的调度加上了条件:
(1)服务数量不能超过集群节点数
(2)端口号不能抵触,每个集群节点上只能部署一个服务
这也是目前架构带来的缺点,后续如果集成 springcloud-kubernetes 倒是能够解决。端口问题也是抉择 HostPort 形式的理由之一,Kubernetes 获取 Pod 信息时无奈获取端口号,也就无奈想 Nacos 注册正确的端口号。
数据卷配置
数据卷就不细说了,跟 Dokcer 的概念差不太多,目前我只是映射了日志目录。