本文从命名规范、容器平台与各种类型存储适配场景、容器平台对存储的容量和性能管理、存储系统如何备份、如何保证数据安全以及多类型存储的统一管理等角度进行阐述。文中分享到的建议与实践亦可以运用到其他开源的容器管理平台中。

　　【作者】王洋 金融企业系统架构师

　　一、命名规范

　　对于K8S平台上运行的各种类型POD，每个公司都应该有其命名规范，一般常见的命名规范是“名字空间-应用编码”，其中应用编码可以与CMDB中应用编码保持一致，但是该命名方式不能很好的识别出该POD是否存在持久化需求以及使用的是何种类型的存储。因此我们建议可以将上述命名规范优化为“名字空间-应用编码-stroage-p/t-mn”。

　　其中带有stroage标识表明该POD是需要使用存储的，p代表持久化存储，即需要使用PVC的，t代表临时存储，即临时卷（EmptyDir）或内存卷（HostPath），mn可以是一组编码（01/02或者ab等），用来代表该POD使用的是何种类型的存储。例如，prod01-app01-stroage-p-01代表prod01这个命名空间下，有个名为app01的POD，使用的是01类型存储提供的持久化服务，这里的存储类型包括但不限于：本地卷、外接（集中式/分布式）块存储、外接（集中式/分布式）文件存储和外接（集中式/分布式）对象存储等。该“名字空间-应用编码-stroage-p/t-mn”命名方式的思路除了可以应用在有持久化需求POD命名中，还可以将stroage替换为其他描述类型上，例如更换为Internet代表该POD为互联网访问需求。通过对POD进行规范的命名方式，不但可以更好的识别出每个POD的类型，同时也为后续进行POD的运营分析提供了一个筛选维度。

　　二、各类型存储适配场景

　　一般而言，容器平台使用的存储分类如下：

　　容器平台上承载了各种类型的业务，每种不同的业务类型对存储的需求是不同的，下面本文将做详细的分析。

　　场景一，应用类非结构化数据使用需求的POD，可能会使用数据的临时存储，即使用临时卷（EmptyDir）或内存卷（HostPath）的POD，由于其对数据的持久化没有要求，存放的都是一些临时数据，优先使用成本最低的本地存储即可。

　　场景二，数据库类的POD，该类型属于对于有持久化存储需求，同时对IO要求比较高的业务场景。此场景下应该使用全闪存配置的快存储块存储。另外从扩展性的角度考虑，优先考虑扩展性更好的外部存储，至于是选择集中式还是分布式没有严格的要求，需要结合实际测试结果、商务价格以及本公司的技术路线决定。

　　场景三，应用类有非结构化数据使用需求的POD，对于这类POD其对数据存储的量可能随业务的增长而变化。因此优先考虑扩展性更好的外部存储，最终是选用文件存储还是对象存储，可以参考一下表格中的建议：

　　至于是选择集中式还是分布式没有严格的要求，需要结合实际测试结果、商务价格以及本公司的技术路线决定。

　　三、存储的容量和性能规划

　　在K8S中如果经过前面的步骤，已经确认了该POD要使用持久化存储，那么就需要考虑PVC的容量大小要如何设置，本文认为应该从以下两个方面来进行规划：

　　一是应用程序侧需求，需要分析应用程序所需的数据量、增长速率，确保为PVC分配足够的存储空间来满足应用程序的需求。对于应用侧所需数据量的估算，可以采用以下方式分析，通过分析应用程序的历史数据，确定数据的平均大小和增长速率，并基于这些数据估算存储需求，进行负载测试。通过进行负载测试，模拟真实场景下的数据生成量，从而反推验证估算的需求量是否符合预期。

　　二是存储集群的资源情况，由于PVC分配的数据最终是需要底层的存储集群提供的，那么在分配PVC的时候就需要考虑存储集群当前容量情况是否健康，是否能满足POD在一段时间内的数据需求（结合第一点），从而选取不同的存储集群或者是存储集群内的不同逻辑存储单元。

　　另外，由于运行在K8S集群上的业务类型繁多，这就带来了一个问题，不同业务类型对数据存储使用的频率是不同的，这就要求存储在进行容量管理时，需要加上数据冷热程度这个因素。对于热数据要同时关注存储的性能和容量指标，对于冷数据可以将更多精力放在关注存储的容量指标上。此外，对于某些行业，例如金融，有数据离线保存的要求，这就要求存储平台能够对接备份存储、带库等设备，满足数据的离线保存。

　　K8S平台与存储集群的对接，除了容量方面的规划外，还需要关注一些性能指标，主要涉及延迟、IOPS、吞吐量。对于响应时间有严格要求的应用，应该更加关注延迟指标，对于数据库类应该更加关注IOPS，对于大数据和数据分析类应用应该更加关注吞吐量指标。

　　对于容量和性能而言，除了需要事先定义各种使用规范和要求外，还需要搭配相应的监控措施，对存储集群的容量指标和性能指标进行监控，对PVC的使用情况进行监控，对容量的增长趋势进行监控。另外，对于K8S平台而言，用好NodeAffinity机制，将POD运行在期望的节点上，在容量保障以及性能保障方面会收到更优的效果，并且还会带来业务系统应用稳定性的提升。

　　四、容器平台和存储的备份

　　K8S平台目前有一些主流的备份工具，例如Velero、stash、Kasten K10、Arkade等，这些工具基本上都能够实现K8S集群的备份，具体使用哪个工具需要结合本公司的具体情况来选择使用某个工具。但是笔者认为，K8S自身的高可用应该尽可能依赖K8S提供的高可用方案去落地，例如联邦集群等，应用侧应该更多的将应用程序部署为无状态服务，并配合一些自动化运维工具，这样在某个K8S集群出问题的时候可以快速进行恢复。

　　在存储的备份方面，应该从以下方面进行考量：

　　一是对于重要的K8S集群数据，即不允许有数据丢失的场景，建议其存储最好能够支持同城双活和异地异步灾备，这样就可以最大程度的保护重要数据不丢失；

　　二是对于K8S集群中重要数据与非重要数据并存的场景，可以从存储卷的角度进行差异化配置，对于重要的数据存储卷配置同城双活和异地异步灾备，对于非重要数据可以参考第三条；

　　三是对于K8S集群中的非重要数据，从降低成本的角度出发，可以考虑使用定期备份的方式，将数据备份到指定的备份空间；

　　四是定期验证，对于离线备份走的数据，需要定期验证其可用性以及准确性，这样当真正需要使用该部分数据时，才能真的敢用。

　　五、容器平台数据安全

　　容器平台数据安全需要主要从以下几个维度进行管理：

　　一是访问控制。（1）身份验证和授权，用户必须提供有效的凭证来验证其身份，系统会根据用户的权限级别授予相应的访问权限；（2）具备角色机制，角色基础的访问控制RBAC模型基于用户的角色或职责来控制访问权限。管理员可以分配不同的角色给用户，每个角色具有不同的权限，从而限制用户对数据的访问和操作；（3）权限控制列表，ACL模型在数据存储中为每个对象分配访问权限，管理员可以明确指定哪些用户或组可以访问特定的数据对象，并可控制他们的权限级别。

　　二是数据加密。目前业界主流的数据加密方式是应用程序在向数据库写数据的时候调用加密函数，数据被加密后存到后端存储上，应用程序在读取数据时进行解密。该方式对于应用程序不友好，需要应用程序端做改造，开发同事较为抵制。目前业界有一种新的加密方式，该方式直接替换应用程序对接数据库的驱动程序，这样对于开发而言则无需修改应用程序端代码，实现透明加解密，笔者也是较为推荐第二种方式。

　　三是审计和日志记录。数据存储系统需要记录用户访问和操作数据的详细日志，以便后续审计和追踪用户操作行为。

　　六、多类型存储统一管理

　　若K8S集群使用了多种类型的存储，从提升管理便捷性的角度考量，需要使用一个统一的存储管理平台对多种类型的存储进行管理。目前的开源存储方案都有自带的管理平台并且这些平台都提供API接口，基于这些API接口，使用方可以自行封装一套满足自身需求的存储统一管理平台，在该平台上实现对各种类型存储的新建、扩容、权限设置等一系列操作，并且在二次封装后可以和已有的自动化运维平台、容量管理平台、告警平台等进行联动，从而能够在更加宏观的层面对存储资源进行管理。

　　(作者:王洋 金融企业系统架构师)