基于K8S集成底座项目运维总结

数通畅联 2022-02-25

545

公司主打集成底座项目由四款产品组成，IDM统一身份5A管控平台、MDM主数据平台、ESB应用集成平台，K8S运维管理平台UMC。其中，IDM身份管理平台以统一用户管理、统一认证和单点登录为基础，让各级员工不再需要频繁进行系统切换及登录访问；MDM负责各业务系统的基础数据管理包括组织人员，客商、产品、项目、物料、BOM等；ESB企业服务总线实现信息化由单项建设和孤岛应用向集成、共享、协同转变，实现IDM/MDM数据同步、分发、业务集成；UMC是公司自主研发基于K8S的快速部署构建、DevOPS、CI/CD持续集成部署的工具平台。

本手册主要介绍MDM数据管理系统和IDM身份管理系统，ESB企业服务总线及UMC云管理平台集群环境下的运维操作。通过了解名词说明和整体的部署架构，主要说明单机服务运维、集群环境的运维以及在平台运行过程中典型问题的常见处理办法。

整体说明

运维工作直接关系到应用系统运行得是否正常稳定，但运维工作纷繁复杂，正规化、系统化工作推进起来相对比较困难。为改变这种现状，应在工作中总结经验，并制定运维规则，只有这样才能提高运维水平，保障应用系统正常稳定运行，下面是我针对集成底座所撰写的运维手册。

1背景说明

随着市场竞争日益全球化，集团企业普遍围绕产业链进行相关板块发展、拓展多元化产业渠道、利用重组整合等多种方式提高资源整合能力，集团内部管理复杂程度急剧增加。集团企业对自身的经营管理水平与业务执行效率的要求越来越高，需要对大量异构的信息系统加以有效整合，提高系统间的数据交互、信息共享水平以及业务处理效率，从而增强信息系统对企业业务与管理的服务、支持能力。

2名词解释

1.K8S：是一个开源的、用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高，Kubernetes提供了应用部署、规划、更新、维护的一种机制。本次项目整体采用K8S云平台的部署方案。

2.Master: K8S的主控组件，对应的对象是node。

3.Node：Node（节点）是K8S集群中相对于Master而言的工作主机。Node可以是一台物理主机，也可以是一台虚拟机（VM）；

4.Pod：Pod是所有业务类型的基础，也是K8S管理的最小单位级，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。

5.Deployment：是最常用的controller。deployment可以管理pod的多个副本，并确保pod按照期望的状态运行。

6.Services：K8S的 service定义了外界访问一组特定pod的方式。service有自己的IP和端口，service为pod提供了负载均衡。

7.Ingress：Ingress公开了从集群外部到集群内服务的HTTP和HTTPS路由，流量路由由 Ingress 资源上定义的规则控制。

8.nfs：网络文件系统，英文Network File System(NFS)，是由SUN公司研制的UNIX表示层协议（presentation layer protocol），能使使用者访问网络上别处的文件就像在使用自己的计算机一样。

9.私有镜像库：在本地（局域网）搭建的一个类似公共仓库的东西，搭建好之后，我们可以将镜像提交到私有仓库中。这样我们既能使用 Docker 来运行我们的项目镜像，也避免了商业项目暴露出去的风险。

10.Keepalived：Keepalived的作用是检测服务器的状态，如果有一台服务器宕机，或工作出现故障，Keepalived会将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作。

11.Nginx：Nginx是十分轻量级的HTTP服务器，是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP代理服务器。

12.Redis：Redis 是一个高性能的key-value数据库，用于构建高性能，可扩展的Web应用程序。在本项目中K8S集群内和集群外都分别使用了Redis。

13.MySQL：MySQL是一种开放源代码的关系型数据库管理系统（RDBMS），使用最常用的数据库管理语言--结构化查询语言（SQL）进行数据库管理。ESB和UMC都是部署的MySQL数据库。

3环境配置

服务器信息：

部署信息：

访问信息：

部署架构

IT架构作为整体信息化建设蓝图，不仅是应用系统、平台的构建，还有对数据架构、应用架构、技术架构的设计与规划，从数据利用层面、应用构建层面、技术支撑层面对整个IT架构的落地提供支撑。

1业务架构

1.以HR系统为源头，HR负责提供组织、岗位、人员的源头数据；

2.HR系统在进行新增、修改、启用、禁用等操作时进行提交，再调用技术底座的同步接口将数据以JSON的方式进行推送；

3.技术底座的同步流程接收HR系统的JSON数据后进行落地，同时自动生成数据分发的任务，并产生任务标识TaskId；

4.技术底座将TaskId推送至下游业务系统的任务接收接口；

5.下游系统接收TaskId后先调用技术底座的获取tokenId接口获取tokenId，再调用技术底座提供的数据提供接口获取任务中的JSON格式数据，并将数据写入下游业务系统中，写入后调用技术底座的日志接口进行日志回写；

6.对于数据下发，技术底座有失败重发机制，在调用下游接口失败时会进行重试，当重试达到一定阈值时，会进行邮件（微信、短信）报警。

2数据架构

1.源系统为数据库的表数据，表数据来源HR数据（HR数据，敏感数据进行处理），通过HR把源头数据传给ESB，通过ESB同步到MDM接口中；

2.MDM接收到基础数据信息之后，通过BPM调用ESB分发服务，将数据推送给IDM的同步接口；

3.IDM同步接口获取数据之后，通过BPM调用ESB账户分发服务，将账户相关信息分发到MDM系统账号表中；

4.ESB主要使用SMC管理控制台配置的应用集成场景进行服务之间的对接；

5.同时在写入MDM和ESB数据库操作服务时，服务支持新增、修改兼容处理；

6.并且数据同步分发流程要支持定时获取和手动触发两种方式进行调用；

7.由IDM进行数据分发的时候，要保证分发数据可根据情况进行调整，包括可以进行指定组织分发，以及指定属性进行分发；

8.同时针对特殊情况，人员、岗位先于组织同步，以及岗位先于人员同步的情况，进行兼容处理，保证数据可以正常写入。

3认证架构

为了还原项目中的真实情况，从三个方面进行考虑，一是正常的cas认证对接方式，二是oauth认证方式还有就是表单认证方式，通过不同的认证方式，适配现场的不同对接场景，保证IDM可以进行相应场景的认证适配，实现认证的统一管理。

本次对接认证，开发环境的ESB系统采用oauth认证方式，通过调整ESB配置文件，实现oauth认证，MDM采用表单认证方式，通过调用ESB开发的流程和IDM进行oauth认证交互，获取到账户和密码之后，进行MDM模拟表单进行登录。

而测试环境的ESB和MDM均采用cas认证方式，通过调整产品配置文件以及cas客户端jar包预置，filter文件调整和添加，实现cas认证登录。

环境操作

下面主要针对UMC环境的操作以及环境部署，Redis的配置等进行说明。

1UMC启停

目前UMC通过集群的方式部署在worker3（65）和worker4（66）两台服务器上，如果启停需要分别进行操作。以65服务器为例进行说明，66服务器参考即可。

注意：为保障生产环境的正常运行，建议调整nginx配置服务指向，逐个UMC服务器重启。

位置：

/opt/mnt/ umc/umc_server_x64_v3.5.1.20211011/bin。

启动：. startup.sh。

停止：./shutdown.sh，或者通过ps -ef|grep umc获取服务进程号，kill进程号（不推荐）。

2服务操作

由于ESB，MDM，IDM是部署在K8S集群内的，所以需要通过UMC平台进行操作，操作一般分为两种情况，一是对所有节点进行操作，二是单一节点操作。

注意：为保障生产环境的正常运行，不建议直接对所有节点进行操作，建议单一节点操作，一个节点重启后再操作下一节点。

>>>>

集中启停

1.登录UMC，打开租户配置，找到对应的环境：

2.编辑Deploy：

3.点击反创建，停止所有容器：

>>>>

节点重启

1.登录UMC，打开租户配置，找到对应的环境：

2.查看Deploy状态：

3.选择容器节点，进行重启：

>>>>

容器扩容

1.登录UMC，打开租户配置，找到对应的环境：

2.编辑Deploy：

3.点击扩容，修改容器数量、CPU、内存信息进行扩展操作：

4.注意：页面显示的CPU、内存信息为单一容器数据，总数 = 内存/CPU * 容器数。

>>>>

扩展配置

扩展配置主要是用于对ESB的产品补丁以及环境配置等操作。

1.登录UMC，打开租户配置，找到对应的环境：

2.打开扩展配置，新增或编辑：

3.输入编码、名称、文件类型，内部路径：esb_server内的文件存储相对路径，外部路径：/opt/mnt/volumes/方案编码/环境编码/esb/files/内部路径；

4.保存后，选择上传功能上传文件：

5.选择扩展配置文件上传即可；

6.上传成功后，编辑Deploy，反创建-编辑-保存-创建：

注意：

1)上传文件时要保证上传的文件名和内外部路径中的文件名一致；

2)增加扩展配置，反创建后一定要编辑、保存，确认yaml文件中已经引入扩展配置文件。

3产品操作

UMC采用传统的部署方式，所以升级UMC需要重新在服务器上部署一套UMC产品，具体部署方式参考UMC产品使用手册。

>>>>

UMC升级

UMC采用传统的部署方式，所以升级UMC需要重新在服务器上部署一套UMC产品，具体部署方式参考UMC产品使用手册。

>>>>

产品升级

由于产品是通过云平台部署的，所以升级产品也是在云平台操作，通过UMC平台进行操作。

1.打开UMC集群配置，切换到镜像信息标签：

2.新增一个镜像，选择产品、镜像仓库——上传——构造镜像——推送镜像：

3.在租户配置中编辑Deploy，升级产品镜像：

4
Redis集群

Redis集群分为内部Redis和外部Redis，通过K8S集群区分，K8S集群外的Redis部署在Master1(192.168.1.100)、Master2(192.168.1.101)、Master3(192.168.1.103)三台服务器上，主要通过操作服务器进行启动；而K8S集群内的Redis需要在UMC平台进行操作。

>>>>

外部Redis

下面介绍外部Redis的启动方式以及集群的配置。

1.启动Redis实例

启用第一台机器上Redis节点，以下命令：

启用第二台机器上Redis节点，以下命令：

启用第三台机器上Redis节点，以下命令：

2.启动Redis集群

位置：/usr/local/redis-5.0.4

名称：redis-5.0.4

使用场景：3台redis服务器全部宕机或同时重启后，redis集群已经停掉或集群开启但实例主从关系错乱，使用此命令快速重启集群。

注意事项：

1.启动redis集群过程中，正确启动会提示输入“yes”，需手动输入完成redis的集群启动。如提示其中一个节点报错，请先检查该服务器上redis节点是否开启，确保redis正常启动；

2.建议每次重新构建集群，先关闭UMC服务器，再重新运行脚本。

示例：以Master服务器上Redis集群为例，在Master1（62）上执行Redis集群启动脚本redis_cluster_start_5.0.4_pwd.sh，脚本内容如下：

其中脚本执行过程中会出现节点错误提示，忽略即可。

输入 yes，说明集群启动成功。

>>>>

内部Redis

下面介绍内部Redis的启动方式以及配置产品Redis。

1.启动Redis集群

K8S内部的Redis通过UMC平台进行配置和操作。

1.登录UMC，打开租户配置，找到对应的环境：

2.打开组件配置：

3.可以新增Redis集群，也可以修改Redis；

4.新增直接点击新增按钮，设置Redis实例个数，集群的初始化和启动参考修改步骤；

5.选择Redis组件进行修改：

6.先点击重置按钮，如果还未进行初始化（没有重置按钮）可跳过：

7.重置后，从下至上分别对Service、StatefulSet、ConfigMap、PV进行反创建操作：

8.全部反创建后可以对集群节点等信息进行修改：

9.修改后启动集群，从PV开始创建，顺序是PV、ConfigMap、StatefulSet、Service：

10.创建完成后，点击初始化，初始化Redis集群：

11.初始化完成后，点击集群状态和测试连接进行集群测试：

注意：

1)启停Redis集群的顺序，启动：PV、ConfigMap、StatefulSet、Service，停止：Service、StatefulSet、ConfigMap、PV，如果操作顺序不对可能导致Redis集群异常，无法启动或停止；

2)在创建ConfigMap注意修改密码，提高密码强度：

2.配置产品Redis

1.配置参数：

1)hosts：Redis集群的连接串：

2)password：Redis集群密码：

3)maxIdle、maxTotal：Redis连接参数，默认即可，通过调整可以对Redis进行优化。

2.编辑Deploy，选择Redis标签，启动ESB产品集群，参考4.2.1集中启停。

5资源同步

通过ESB设计器连接UMC云平台进行工程和服务部署时，默认是部署在UMC的开发环境中：

本次云平台建立有环境：开发、测试、生产等环境，各个环境彼此隔离，实际生产运行使用的是生产环境，所以在ESB服务开发完成并部署到开发环境后，需要通过资源同步推送至测试和生产环境。

资源同步的操作主要是在UMC云平台执行，有两种方式：一是由开发环境推送测试环境，测试环境再推送生产环境，二是由生产环境从测试环境拉取，测试环境从开发环境拉取，操作基本相同。

1.打开UMC的租户配置，找到开发环境：

2.打开扩展配置，点击推送资源：

3.在弹出页面中选择ESB工程，点击同步：

也可以有生产环境拉取，选择生产环境，操作和推送相同：

4.日志监控

日志监控主要是用于监控产品运行的实时输出信息，用于监控产品的运行情况、报错信息等，ESB环境共涉及UMC和ESB两个产品，一般主要是在开发ESB服务时查看ESB的日志信息。

运行环境

下面针对UMC，ESB等运行环境，以及日志的介绍。

1资源监控

我们可以在实例监控里查看容器的性能如下所示：

2UMC日志

服务器：*************、*************

位置：

/opt/mnt/ umc/umc_server_x64_v3.5.1.20211011。

名称：tail -f logs/catalina.out。

3
ESB日志

可以在SMC平台上查看流程日志如下所示：

报警日志：

4运行日志

ESB的日志监控主要用途：日常服务运行监控、ESB服务开发监控、ESB服务异常查询（IDM，MDM同理）。

1.打开UMC的实例监视，选择对应的环境：

2.选择容器，点击运行日志：

3.实时查看运行信息：

4.如果需要查看历史日志，点击下载日志：

5.选择对应的日志文件进行查看或下载，查看是直接通过浏览器查看，下载会下载到本地：

常见问题

通过上文的介绍，大家应该已经了解了jmeter工具，本次主要对监控预警功能进行一次压测，对认证监控进行一次检验，认证监控主要配置是对失败次数报警策略、一段时间内多次登录报警策略，我们的认证入口分别是Oauth认证和SSO单点认证入口。

1防火墙处理

以MySQL为例。

1.开启防火墙端口：

2.加载设置：

3.查看端口是否开启：

这样通过外部也能够链接Mysql。

2服务日志监控

1.Nginx

监控nginx后台日志，位置如下：

/usr/local/nginx-1.6/logs。

查看日志命令：

tail -f error.log。

2.Java进程：

使用jps命令：

使用jstack 进程号，如上图为4052。

3账户认证失败

如果提示账户密码不正确时，先去人员管理页面看看人员是否存在，在人员管理页面点击过滤进行筛选。

如果没有的情况下去禁用人员看看这个人员是否被禁用了。

如果人员没有被禁用去数据库看看这个人员密码是否正确。

心得总结

在企业看来，运维工作的作用其实就帮企业节省成本；在团队分工上来看，运维工作可以帮助程序人员将主要精力用于编码和解决问题，而不必花费大量精力在环境部署及发布上。运维人员还可以通过监控、测试，向开发人员反馈以暴露程序问题。

1综合技能

运维人员掌握技术之后，还需要从不同方面提升自己的综合能力，要清楚不是技术水平提高，就能出色完美地完成工作。还要保持良好、积极的心态，主动向领导汇报工作进度，懂得资源搭配与协调等，这些都是一个合格的运维人员必须掌握的技能。

2积极心态

基于好的心态、乐观、阳光，积累个人能力，促进事物的发展，提升自身是保证自身稳步提升的基础。在工作中取得领导、同事的认可，在生活中获得朋友、家人的尊重，一步一步踏实努力，稳扎稳打不断更新自我，完善自身的能力模型，能力提升形成正循环。

3心得体会

无论在现场还是公司，不要小看任何一个人，每个人都有你值得学习的优点，要善于发现别人的优点。所谓“三人行，必有我师”，无论客户、还是同事，都会有比你优秀的一面，要善于总结、善于发现、善于学习，只有这样，才能让自己真正得到提高。

要始终保持一颗向上的心，对于知识的渴求和热情要保持火热，并且不断学习新的知识、完善知识体系、积累知识内容、分享知识心得，只有这样，才能搭建良好的知识体系，既得益于自己，也能帮助他人。

基于K8S集成底座项目运维总结

评论