本文作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心

在容器云平台的测试和实施过程中，我们遇到了日志采集配置等一系列问题，这也让我们考虑是不是可以通过容器云平台的全局性配置或动态设置来达到修改平台配置或节点配置等目的而不用一台台的修改配置。比如日志采集方式可能需要变更，从采集日志文件改为采集标准输出中的日志信息。这可能需要修改docker daemon的配置。目前基本上都是靠管理员手工来修改，如果节点数比较多，要么编写实现scripts，但无法做到按需修改；要么一台一台的修改，这不是很便利。另外有些配置可能只想修改容器云平台某个节点或某几个节点，使用标签策略限定范围；甚至只想修改某个容器的配置，比如调整容器资源配置和限额。我们在应用部署过程中也发现的一个问题，如果初始分配给容器的资源过小（例如Memory占用了100%），再设置自动弹性伸缩（Memory > 90%扩展），就可能导致容器实例持续的扩展，最终导致平台资源耗尽。这是因为扩展的每个实例分配的资源跟第一个是一样的，其Memory依然不够，依然被占用100%，进入死循环，最终导致平台崩溃。这很可能因为一个不小心或失误就会导致的问题，一方面除了加强监控和告警，另一方面也需要考虑弹性伸缩时资源的伸缩，不仅仅是实例数的伸缩。如果能在容器云平台提供这样的配置更改机制，实现自动化按需配置更改，自动生效，那对管理员日常运维来说将会非常的便利。

随着容器云平台使用和理解的深入，我们对这块的需求也逐步清晰，基于不同层级设置变更的需求以及需要从平台管理员和租户角度来看待这个问题，所以容器云平台设置我们考虑分为平台级设置、集群级设置、节点级设置、容器级设置等层级，也可考虑划分为更细粒度的层级。其和我们以前文章谈到的应用服务的配置中心是彼此独立的。一个是技术层面平台的参数设置，一个是业务层面业务服务的参数配置。

一、平台设置

容器云平台可能管理多集群，我们一开始也只考虑一个集群足矣，但众口难调，有团队宁愿自己麻烦，要求有个独立的集群。那倒是没问题，但所有的集群需要统一通过容器云平台来管理，每个集群设置独立的集群管理员，隶属平台管理，直接利用权限中心的设计，支持平台的权限管理需求。

但作为整个平台来说，一些基础的配置需要保持规则一致。比如与平台集成的认证中心、证书中心、权限中心等地址设置，整个平台使用统一的认证、证书和权限管理体系。还有域名规则设置等基本的信息设置。也可能会有一些平台全局通用基本信息的设置等。比如平台logo文件的路径配置等。

二、集群设置

每个集群会涉及到很多项的设置，仅一个Docker daemon就有五六十项之多，还有Kubernetes、etcd等众多组件都可能需要暴露设置项。当然不是所有这些设置项都需要暴露出来，这可能需要在使用过程中逐步的迭代实现。但理论上说，只要提供set api的都应该提供配置选项。在容器云平台提供相应的更改或设置入口，对于平台管理员来说将会更友好、更便利、更安全。特别是那些需要在多个地方同时更改的设置项，更需要提供一个统一的更改入口，然后自动更新同步所有的用到的地方。

（一）功能菜单配置

我们其实希望实现平台或集群菜单动态可变调整。最简单的，从产品角度来说，不同客户可能需要的功能会有差别，同一个功能项，有需要的，有不需要的，如果为每一个客户都改一遍，发布一个小版本，最后版本管理会失控；但是如果通过配置就能实现，是不是就简单很多？通过配置每个菜单项也可前后次序调整，甚至可以做的更多。

这项功能只面向平台或集群管理员，租户应该是不可见的。根据需求，产品的一些功能可能需要隐藏，那么在平台初始化时就可以设置某些菜单项不可见，对终端用户不可见；或根据需要进行次序调整。在运维时，也可以设置暂时不可用，关闭菜单入口，运维完成后打开入口。

这前提是在我们设计容器云平台时，其菜单是通过配置自动生成的，不是写死在代码中的。这就为我们提供了极大的灵活性。

（二）Kube配置

Kube-APIServer、Kube-Controller-manager、Kube-Scheduler等组件都有很多配置选项，习惯上都使用yaml或json配置文件，大部分选项是不需要调整的 ，也有一些可能需要在运行时调整，这些可能需要调整的选项目前基本上都是通过命令行操作。那直接提供UI修改配置文件是不是更简单些？例如更改APIServer 的API groups和resources。DaemonSets, Deployments, HorizontalPodAutoscalers, Ingress, Jobs 和ReplicaSets默认设置是可用的，可以修改配置使之不可用。也可以用来配置其他扩展资源。比如设置extensions/v1beta1/jobs=false。修改groups 或 resources后，自动重启apiserver 和 controller-manager 来使新设置生效。

Kubernetes配置最佳实践有一条最简单最小配置原则，不必要的配置选项避免设置默认值，这样可以最少的产生错误。所以这些项的选择也不是越多越好，根据实际的需要来确定。厂商可以收集不同用户的具体需求，最后选择暴露合适的设置选项。

（三）Etcd配置

容器云平台非常非常重要的一个组件是etcd，etcd的配置也可能需要调整，比如data-dir，security配置等，所以其配置也是需要通过平台UI提供更改入口。至于应该暴露哪些选项，可以详细的讨论确定。

（四）Docker Daemon设置

Docker daemon的设置可能需要区分是整个平台的设置更改还是某个节点或部分节点的更改。和用户权限体系关联起来我们还没有验证过，只是有此想法，理论上实现是没问题的，用户可以更新其权限许可更改的配置，把平台配置作为权限管理的一部分， 比如我的权限范围是某个节点，那么我只能更改此节点暴露的配置选项。在此也抛砖引玉，大家共同探讨。

我们容器云平台所有业务服务的日志都打印到标准输出，这样我们就不再为每个Pods去mount存储卷，仅使用filebeat来采集标准输出的日志信息就行。容器日志输出方式是在Docker Daemon中设置的，目前是标准输出方式，也许过段时间会改成log4j，或者使用graylog了，或者其他driver。那么配置就需要修改，虽然不是经常变动，但如果有UI提供更改支持，相对来说可能更方便，运维的难度也降低了很多。

另外可能会希望控制日志文件的大小，以避免日志文件无限增长导致磁盘空间耗尽。这可能需要提供设置文件大小和最大文件数，设置文件覆盖模式等入口。

（五）Beats设置

Docker Daemon中的logging-deriver设置更改之后，理论上filebeat设置也是需要关联修改的，比如采集目录配置，可以考虑在一个区域完成这两项更改，保存后分别写入到不同的配置文件。

Beats家族有filebeat、Metricbeat、Packetbeat、Auditbeat、Heartbeat等，这是采集数据和监控数据的重要渠道。这些配置可能需要经常的调整，在容器云平台支持这些工具并提供常用的配置选项会极大的提高效率。

三、节点设置

我们也发现厂商把节点、集群的用户名、密码明文的格式保存于配置文件中，先不说是否安全，我们公司要求的安全策略用户名密码至少3个月修改一次，一旦口令修改，就可能导致容器云平台无法工作，可能不得不去一个个的修改配置文件，这是一个比较严重的问题。首先系统口令不能明文存放于配置文件，其次在平台界面应该提供口令修改的入口，一个比较理想的方案是结合统一认证设计和域用户机制，用户/口令统一存放于认证中心，由认证中心来统一维护平台的节点用户/口令。

（一）Docker Daemon设置

对于某个节点的Docker Daemon设置，可以应用到特定的节点上，这样就不影响其他节点。比如修改某个节点配置以确认是否是期望的结果，就可以分步来做。先选一个节点测试确认符合预期，然后再应用于其他节点。我们一个潜在的需求是不同的子集群使用不同的日志采集方式，这就要求在不同的节点上可能需要采用不同的配置。

（二）Filebeat设置

这也是单节点的更改设置，比如某一节点上的filebeat采集数据吐到ES改为Kafka，中间做一层数据处理，其他节点则不变。

（三）预留资源设置

某些节点也可能需要预留一些资源，比如预留4G的内存资源，20%的CPU资源，需要修改Kubelet配置。过段时间之后预留的资源可能就不需要了。目前这些工作都需要通过命令行重新登录到节点机器上修改，不但慢，也容易出错。作为运维人员可能更喜欢在平台界面直接操作，直观、而且不容易出错，也不用学习那么多K8s命令什么的。

四、Pods或容器设置

Pods或容器的设置可能是调度策略相关或更多是资源相关，或者Pods优先级设置等。比如虚拟化一层后，为避免同一个服务的多个实例都落入一台物理机的虚拟机节点之上，可能需要在Pods调度时以物理机的标签来实现反亲和性调度。也可能需要对某些pods的最大占用资源进行限制，或者实例数进行限制等。这些配置都需要在UI界面上实现。目前大部分容器云产品已经实现了部分能力，比如资源限额等。

五、镜像仓库配置

项目实施过程中，我们也发现一个看似小却影响大的问题。 镜像仓库域名竟然是abc*，更让我们崩溃的是，竟然很难修改，完全写死在了容器云平台里，而且很多地方都是这样。改个名字意味着代价高昂，这是我们始料不及的。虽然我们一直在很努力的去把控整个平台的细节设计，但是、但是、但是还是让我们有点欲哭无泪，难以想像容器云项目都是怎么做的。我们office培训老师在讲课时，一再告诫我们，做Excel 设计时，尽可能是用变量，一辈子只做一个表格。道理是相通的。我们设计软件时，也需要这样的思维，一次设计，全场通用。避免一个常数到处使用，而尽可能使用可配置变量。你可以虽然只修改一次，所有用到的地方实时更新。

六、区分设置选项

容器云平台有这么多设置项，不是所有人租户或用户都可以操作的，需要根据设置参数的实际影响或作用域做一下区分、分类。有些参数是禁止修改的，这些参数不对外暴露。有些参数是影响整个平台的，只有平台管理可以修改的；有些参数是集群管理员可以修改的，有些参数只影响到某个组件或只影响到某个容器，作用域不同，隔离规则不同，影响不同，所以可能需要对这些参数进行划分和分类、分级。另外容器云平台支持多租户，区分平台管理员和租户，也可能需要跟租户内的用户权限配置关联，这样就是一个完整的平台配置功能。

七、结语

关于容器云之平台设置我们和厂商也交流过多次，厂商还是有点不知所措，国内的容器云平台用户还没有这方面的需求，厂商也不知道该怎么去实现。我们的想法其实在设计时可以考虑模型化，只要能提炼出模型，不管需求怎么变，模型保持一致，只是修改数据而已，呈现结果就不一样。这也会简化产品维护的成本，减少产品研发的工作量。