启动、配置、扩容、伸缩、存储，开普勒云平台之使用指南（二）

接上文

三、应用管理

3.1 创建应用

创建一个 Java 应用

在创建应用之前，首先我们要做的是在你的 git 项目上将 Dockerfile 文件提交上去，并且生成一个 Tag 或 releases 版本。

Dockerfile 参考

FROM openjdk:latest
COPY xxxx.jar /opt/app
WORKDIR /opt/appCMD ["java", "xxx.jar"]

进入创建应用页面，填写基本信息

• 进入“创建项目”页面

• 项目英文名填写项目的“英文名称” 名称的规则: ^[]([-a-z0-9])?([]([-a-z0-9]*[a-z0-9])?)*$
  

• 填写“项目描述” 可不填

• 提交信息，进入第二步

1572507717038055262.jpeg

填写详细信息

• 选择项目语言 Java

• 项目地址：输入项目的址 kplcloud/hello 填写完后会自动获取项目的 tags 列表

• 选择版本：选择获取回来的 tags 版本

• POMFILE: pom.xml 文件的路径

• 构建路径：这是 Dockerfile 放到项目所在的路径地址

• 容器数量：启动的 Pods 数量

• 容器规格：该 Pods 的最大内存上限

• 启动方式：jar 启动或 tomcat 启动

• Args: 选择 jar 启动会自动生成简单的 启动命令，如果是 tomcat 启动则是其他命令 // 考虑去掉这个选项

• dubbo 服务: 如果是 dubbo 服务则勾选，会为其开放 20880 端口

• 如果选择了“增加端口” 会列出端口、协议填写

• 端口及协议：如果选择了则会创建 Service 进行负载，注意端口名称的格式，必须是 xxx-port，可以添加多个端口，但建议一个应用只启动一个端口。

1572507729439058696.jpeg

1572507739438090812.jpeg

提交成功之后会显示如下页面，管理就可以在审核页面进行部署。

1572507746988020229.jpeg

（创建 Golang/Python/NodeJs/静态应用的步骤请参看开源文档。）

3.2 自定义启动命令

应用服务启动可以在多个地方进行调整，以下介绍两种方案，Dockerfile 和 平台详情页调整

Dockerfile CMD 启动方式

看一下简单的例子：

FROM hub.kpaas.nsini.com/app/hello:v0.0.3
CMD ["/go/bin/hello"]

启动命令写在 CMD 这个后面，如果后面有多个参数可以以逗号隔开例如: CMD [“static-web”, “-path”, “app”, “-port”, “:8080”]

平台详情页调整

打开应用详情页：

1572507761959091009.jpeg

在详情这一选卡上找到“命令，参数”，点右边的编辑 icon，弹出对话框进行填写：

1572507772829000286.jpeg

填定启动的命令和参数，参数用逗号隔开。点提交服务会自动重启动。

注意：在平台详情页修改的命令会覆盖掉 Dockerfile 下的 CMD 命令。

3.3 日志采集

日志采集配置

在应用详情页中间有一个叫作“日志采集”的模块

1572507800629083992.jpeg

点击右边的“添加”按钮，在弹出的对话框中选择日志的路径及正则规则

1572507808980010971.jpeg

• 文件路径：你日志文件的位置

• 日志规则：如果没有特殊需求的话默认就好

提交后服务会自动重启动。

日志采集

如果配置了上面采集器，那么它会向服务所在的 Pod 注入一个 Filebeat 采集器对应用服务的业务日志进行采集。把采集到的日志入到 kafka 集群，然后 logstash 进行消息处理及格式化。

处理完后入到 ES 集群，最终我们就可以通过 kibana 查询到我们的业务日志了。

1572507817669083739.jpeg

当然 kafka、logstash、es 得您自己去搭建。

若您可把这几个服务跑在 Kubernetes 可以参考我给您生成的 yaml 直接 apply 进去就能跑。

模版配置

生成 filebeat 会用到两个模版，一个是容器的模版 FilebeatContainer，另一个是 ConfigMap 的模版 FilebeatConfigMap，您可根据自己的需求调整相应的模版文件。

1572507828170066357.jpeg

3.4 查询构建应用日志

构建应用的流程是通过创建应用提交一些信息进行处理

• 从 git 仓库获取 tags 列表

• 调用 jenkins API 将应用的相关参数及版本信息传给它并进行构建

• Jenkins Job 执行 Shell 命令 执行 docker build 并上传致 Docker 仓库

• 平台监听到 job 已经执行完成并成功了，调用 kubernetes API 更新应用的 Image 地址

• 监听升级情况

• 发送通知

以上是构建应用的后端流程，而前端就变得比较简单了。只需要在应用详情页点击"Build"按钮，在弹出的对话框中选择相应用的 tags 版本并提交就行了，如下图：

1572507838440030732.jpeg

查询构建日志

点击详情页的 build 日志选项卡，会显示最近的构建记录，点击左侧相应的版本可以查看该版本的构建情况，也可以对正在松建的应用进行中断，如下图：

1572507847889020444.jpeg

3.5 切换服务模式

服务模式切换比较麻烦，需要您的 Kubernetes 支持，目前我们使用的是 istio 的方案，也就是说您需要在你的 kubernetes 上安装 istio 的相关服务，并且在我们的模版管理将 istio 所需要的几个模版配置上。才能开启此功能。

如果您没有安装 Istio，可跳过此章。

依赖

在"模版管理"菜单找到 Gateway、VritualService、InitContainer、IstioProxy 这几个模版，根据自己环境的情况进行调整。

• Gateway: 本平台设计的模式是一个 Namespace 所对应一个 Gateway，多个 Namespace 空间就会有多个 Gateway，VirtualService 选择的是本 Namespace 下的 Gateway。

• VirtualService: 在生成应用的对外访问入口时与 Ingress 一起生成。

使用过 Istio 的同学应该都知道，要实现 Istio 所提供的相关功能需要在 Pods 里注入两个容器，一个是 proxy_init，另一个是 proxyv2

• InitContainer: 模版是是初始化设置的 yaml，比如将流量通过 iptables 的方式转发给 proxy

• IstioProxy: 模版就是将 pods 的所有流量代理的 yaml

流程

下图是我们架构流量进入到我们容器所图：

1572507858550053384.jpeg

• DNS 将域名解析到 VIP

• VIP 将 80 的流量转发边缘节点的 31380 端口（这个是 IstioIngressGateway 控制器的 Service 的 NodePort）

• 前面我们所说过每个 Namespace 都会有至少一个对应的 Gateway，Gateway 的 hosts 就是 xxx.{namespace}.xxx.com

• VirtualService 里的 destination.host 就是 Service 的名称。 以上是 kplcloud 平台的流程，如果您有需要调整的，只需要修改模版就好，不需要调整代码。

一键切换

如下图，在应用详情页面选择“模式”按钮，在弹出的对话框中选择"Service Mesh"选项目，后点击提交后 Pods 会自动重起。

1572507868030012636.jpeg

你需要在 app.cfg 文件开起 ServiceMesh 功能

[server]service_mesh = true

3.6 扩容

扩容是对 Pods 的使用资源进行扩容，例如最大使用的 CPU 及内存资源。

在应用的详情页面，在右上角找到“扩容”按钮，并点开。

在弹出的对话框中拖动 CPU 和内存，可对其设置一个基础值及一个最大值，如下图：

1572507878820039594.jpeg

选择好相应的值后点击“保存”按钮后，会重起该应用的所有 POD。重启后的 POD 可使用的最大 CPU 及内存资源就是您刚刚设置的值。

所对应用以 deployment 的 yaml 参数：

requests:    limits:        cpu: 1        memory: 128Mi    requests:        cpu: 500m        memory: 64Mi

3.7 伸缩

伸缩是对该应用所启动的 pods 数量进行一个控制。

同样进入应用的详情页页，在右上角找到“伸缩”按钮并点开。

在弹出来的对话框中选择启动的 POD 数量，如下图：

1572507890430039054.jpeg

提交之后若数量大于之前的数量，则会启动缺少的 POD 数量，若小于之前的值，将会逐步减少应用的 POD。

目前给的最大值是 8 个 pod，资源可使用的内存是 16G，若您的应用超过我们所设定的最大值。想办法优化吧，64 核 128G 内存都不够用，这种级别的应用不适合用 Docker。

这种级别的应用最好是拆了吧。

3.8 挂载持久化存储卷

本平台是通过 storageclass 来动态创建 PV。也就是说咱们依赖于 storageclass，如果您的 Kubernetes 不支持相应的存储试，将无法非常方便的进行挂载。

目前暂不支持挂载多个 PVC，或许以后会更新吧。

这里演示的是用的 NFS 进行演示，实际使用时可根据自己的需求配置相应的 provisioner，其他配置是一样的不需要调整，只需要在“模版管理” 调整 StorageClass 和 PersistentVolumeClaim 模版。

创建持久化存储卷声明

在菜单找到“配置与存储”->“持久化存储卷声明”。

选择应用的空间，并点击“创建”按钮

1572507902010016481.jpeg

在弹出的对话框中会有几个选项目：

• 名称：存储卷的名称（规则: ^[]([-a-z0-9])?([]([-a-z0-9]*[a-z0-9])?)*$）
  

• 容量：可以使用的存储区大小，最小单位 Mi，最大 Ti

• 访问模式：

• ReadWriteOnce——该卷可以被单个节点以读/写模式挂载

• ReadOnlyMany——该卷可以被多个节点以只读模式挂载

• ReadWriteMany——该卷可以被多个节点以读/写模式挂载

• 存储类：如果没有存储类请查看创建存储类

1572507910981090764.jpeg

挂载到应用目录

当存储卷创建好之后就可以在应用进行挂载了。

同样的进入应用详情页面，找到“持久化存储”选项卡，如图：

1572507920561098159.jpeg

点击“添加”按钮，在弹出来的对话框加输入相关信息：

1572507931122025845.jpeg

• 持久化存储路径：该路径为容器里的挂载路径

• 持久化存储卷声明：这里会列出您可以使用的存储卷

填写好路径及选择好存储卷后点击提交，改应用的所有 POD 的逐步重启动。

挂载完成之后可以看到所挂载的相关信息：

1572507941992076359.jpeg

最终生成的 yaml 结果：

volumes:- name: soup-hello-pvc  persistentVolumeClaim:    claimName: test-datacontainers:- volumeMounts:   - name: "soup-hello-pvc"    mountPath: "/soupzhang"

四、应用审核部署

如果配置了邮箱，用户提交审核之后会给管理员发送邮件，邮件里带有审核地址。

或者您也可以在应用列表里找到未审核的应用进入。

1572507955922071271.jpeg

4.1 审核应用

提交的基础信息

1572507964572096785.jpeg

生成的 kubernetes yaml

1572507975044082670.jpeg

代码库中的 Dockerfile 文件

1572507990092085250.jpeg

驳回

1572508000492025297.jpeg

如果管理员觉得提交的有问题，可以进行驳回，驳回填定理由会发送至提交者的邮箱。

若没有啥问题，可以点击“开始部署”按钮。

开始部署之后应用会自动在 jenkins 上创建一个 job，并自动进行 build。

五、调整容器时间

在我们项目维护过程中，可能会遇到需要修改服务器时间，平台的工具集功能就可以满足您的需求了~

在这需要注意，此功能依赖 faketime，请在宿主机编译 faketime 扩展。路径在 /usr/local/lib/libfaketime.so.1

调整服务时间（菜单栏：工具集->调整时间）

在项目列表中筛选您要修改的项目，点击 修改时间，确认之后会重启服务生效。

1572508013113061993.jpeg

1572508028803077937.jpeg

开源地址：

• Github: https://github.com/kplcloud/kplcloud
  

• Document: https://docs.nsini.com
  

• Demo: https://kplcloud.nsini.com
  

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/317