乐趣区

关于kubernetes:记一次Kubernetes部署应用过程

jiezi

前言

前文曾经部署了高可用的 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 的概念差不太多，目前我只是映射了日志目录。

退出移动版