Datablau产品之Kubernetes（K8S）部署

Kubernetes，简称 K8S，是用 8 代替中间 8 个字符 “ubernete” 而成的缩写，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes（K8S）的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes（K8S）提供了应用部署，规划，更新，维护的一种机制。

K8S 的三个基本特点：

可移植：支持公有云，私有云，混合云，多重云（multi-cloud）
可扩展：模块化，插件化，可挂载，可组合
自动化：自动部署，自动重启，自动复制，自动伸缩/扩展

Kubernetes（K8S）是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

在Kubernetes（K8S）中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

数据资产管理平台应用在Kubernetes

随着数据资产管理平台在企业中越来越重要，企业需要周期性采集元数据、进行数据核标和数据质量验核。数据资产的数据量级常常有数千万，每周产生一个采集版本，需要对数千万元数据进行核标。同样，数据质量核验极端情况下也会跑出数亿条问题数据。数据计算量很大，通过容器化编排，进行自动部署和扩展可以灵活调整数据资产管理平台的集群性能，保障数据资产管理平台运行顺畅。

Datablau的DAM，DDM最新版支持部署在Kubernetes（K8S）。容器通过为应用程序打包和部署提供轻量级、不可变的基础结构来解决应用程序移动到其他环境就无法正常运行的问题，将应用程序或服务、其依赖项及其配置打包为容器映像。容器技术为开发人员和IT专业人员只需做出少量修改，甚至不需要进行任何修改，即可跨环境部署应用程序。

Kubernetes部署方案

一、部署前准备

Dockerfile
Kubernetes（K8S）的Yaml文件
Redis、 Elasticsearch、 Neo4j、 DB的存储卷
Kubernetes（K8S）环境

二、 Dockerfile

考虑到DAM产品架构和容器化部署的特点，在创建Dockerfile的时候并没有指定JAVA的内存大小，而是在Kubernetes（K8S）的YAML中指定程序运行占有容器内存的比例。

下面是eureka注册中心的Dockerfile

三、 Kubernetes（K8S）的存储卷

为了保证数据的持久性，必须保证数据在外部存储；在docker容器中，为了实现数据的持久性存储，在宿主机和容器内做映射，可以保证在容器的生命周期结束，数据依旧可以实现持久性存储。但是在Kubernetes（K8S）中，由于pod分布在各个不同的节点之上，并不能实现不同节点之间持久性数据的共享，并且，在节点故障时，可能会导致数据的永久性丢失。为此， K8S就引入了外部存储卷的功能。

k8s的存储卷类型：ConfigMap、 Secret、 emptyDir、 hostPath等属于临时性存储，当pod被调度到某个节点上时，它们随pod的创建而创建，临时占用节点存储资源，当pod离开节点时，存储资源被交还给节点，pod一旦离开它们就失效，不具备持久化存储数据的能力。与此相反，持久化存储拥有独立的生命周期，具备持久化存储能力，其后端一般是独立的存储系统如NFS、 iSCSI、 cephfs、 glusterfs等。

因为我司使用的后台组件都是需要持久化的服务，所以需要使用存储卷实现持久性。

在使用POD中指定Storage Class Name从而实现PVC的动态供给。当用户创建PVC需要用到PV时，可以向存储类申请对应的存储空间，存储类会按照需求创建对应的存储空间，这就是PV的动态供给。

四、 Kubernetes（K8S）的YAML文件

ConfigMap

ConfigMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。

ConfigMap 将环境配置信息和容器镜像解耦，便于应用配置的修改。当需要储存机密信息时可以使用 Secret 对象。

为了实现在生产、测试环境中配置文件的变更，我司将一些非敏感配置放在了ConfigMap中，将密码配置信息放在了配置中心。避免了因配置变更而重复打包镜像的现象。

在实现Elasticsearch三节点集群模式的ConfigMapYaml：

Deployment

Deployment在Pod和ReplicaSet之上，提供了一个声明式定义（declarative）方法，用来替代以前的ReplicationController来方便的管理应用。你只需要在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态。

Deployment是用来管理无状态应用的。所以我司的程序主要是使用Deployment来管理POD的升级和更新策略的。我司的更新策略使用的是spec.strategy.type=RollingUpdate的滚动式更新策略。

在YAML文件中指定了使用容器的内存，并指定MaxRAMPercentage

可以根据服务使用的侧重点进行调整申请的内存和CPU的大小。

并且为了实现高可用的部署，服务在注入到eureka注册中心时，使用了status.podIP进行注入。

StatefulSet

RC、 Deployment、 DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的，而StatefulSet是什么？顾名思义，有状态的集合，管理所有有状态的服务，比如MySQL、 Redis集群等。

StatefulSet本质上是Deployment的一种变体，在v1.9版本中已成为GA版本，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识 (hostname) ，还必须要用到共享存储。

在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service， headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。

除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名，这个域名的格式为：

在我司所使用的组件中主要有DB、 Redis、 Elasticsearch、 Neo4j使用到了StatefulSet，其中 Elasticsearch使用了三节点的部署模式， Redis使用的为三主三从的六节点的使用模式。

在Kubernetes中IP并非为固定的，所以这就给Redis集群，造成了当POD-IP改变的时候无法识别到新节点，所以在Redis初始化的时候需要将nodes.conf文件进行刷新，如果POD因为某些故障或者其他原因导致shutdown的话，在重启的时候会将新的POD-IP，重新刷新到新启动的nodes.conf中

从而实现了POD重启后， Redis集群也可以正常使用。