前言

前文曾经部署了高可用的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/v1kind: Deploymentmetadata:  name: seata-server  namespace: default  labels:    k8s-app: seata-serverspec:  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: v1kind: ConfigMapmetadata:  name: seata-server-configdata:  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的概念差不太多，目前我只是映射了日志目录。