Kubernetes集群上线运行，所有权归属仍可能存在缺口
内容提要
Kubernetes上线后，集群健康不代表应用正常。HPE专家指出，需明确平台团队与使用团队的职责分工，在云环境和集群层面制定访问控制、网络、备份、版本升级等标准。升级应分阶段进行，以应用关键路径正常、服务目标达标为完成标准。团队应提前在实验环境测试责任模型，跟踪运维指标，确保变更有人审批、故障有人响应。
延伸解读
上线只是起点：集群健康不等于应用正常
文章指出，Kubernetes部署第一天集群就绪、网络打通、容器运行，常被视作里程碑，但第二天就会暴露更棘手的现实：集群健康时应用未必正常。因此，上线后的运维责任划分比部署本身更关键。团队需要明确平台团队与使用团队各自负责什么，避免出现“集群没问题但业务已受损”却无人负责的缺口。
责任分层：云环境与集群两级标准
平台团队可在两个层面制定标准：云环境层面包括访问与RBAC策略、网络与准入要求、备份恢复目标、Terraform等基础设施即代码标准及服务级指标；集群层面则包括Kubernetes版本支持节奏、命名与标签规范、多租户命名空间模型以及Pod间网络策略。两级标准结合，才能让职责落地而非停留在口头。
升级完成的标准不是节点就绪
文章强调，升级不应以节点恢复Ready为终点，而应以应用关键路径正常、服务目标仍在容忍范围内、团队清楚何时暂停或回滚为完成标准。升级应分阶段进行以限制应用中断。这意味着团队需要提前定义好暂停与回滚的触发条件，否则升级过程容易在“看起来成功”后留下隐患。
用演练和指标验证责任模型
Subramanian建议团队在实验环境提前测试责任模型，并跟踪运维指标，以判断上线后运维是否成功。实际检验标准是：能否明确谁审批变更、故障时谁响应、以及用什么证据证明应用仍在正常工作。若这些问题无法回答，说明所有权归属仍存在缺口，需要在上线后持续补全。
Q&A
Kubernetes集群上线后，为什么说集群健康不代表应用正常？
因为集群健康只反映基础设施状态，应用可能因配置、网络或依赖问题而无法正常工作。文章指出，Day 2 会暴露更严峻的现实：集群可以健康，但应用不一定正常。
Kubernetes上线后，平台团队和使用团队应该如何划分职责？
文章强调需要在构建平台和消费平台的团队之间明确职责分工。这些是功能职责，即使一个人负责多项，随着团队扩大，为每项功能指定负责人可以澄清交接和访问决策。
平台团队可以在哪些层面制定Kubernetes标准？具体包括什么？
平台团队可以在两个层面制定标准：云环境层面和单个Kubernetes集群层面。云层面包括访问和RBAC策略、网络和准入要求、备份恢复目标、基础设施即代码标准（如Terraform）以及环境服务级别指标。集群层面包括Kubernetes版本支持节奏（如维护两到三个活跃次要版本）、命名约定、资源标签、多租户命名空间模型以及Pod间通信的集群特定网络策略。
Kubernetes集群升级应该怎样进行？何时才算完成？
升级应分阶段进行，以限制应用中断。升级完成的标准不是节点恢复就绪，而是应用关键路径正常工作、服务目标保持在容忍范围内，并且团队知道什么情况会触发暂停或回滚。
如何确保Kubernetes上线后变更有人审批、故障有人响应？
团队应将具体任务映射到负责的负责人和所需的审批关口，以消除操作生命周期事件中的模糊性。文章建议在实验环境中测试责任模型，并跟踪运维指标，从而确保变更有人审批、故障有人响应。
HPE Morpheus Software如何帮助平台团队管理Kubernetes？
HPE Morpheus Software使平台团队能够连接云资源、Kubernetes供应、蓝图、工作流和基于角色的访问控制。团队可以配置目录访问、配额、预算和审批策略，包括与IT服务管理系统的集成。平台团队仍然决定哪些请求需要审批以及谁可以做出更改。对于通过该软件管理的Kubernetes集群，支持的版本可以通过集群布局交付，客户可以通过界面或API查看可用升级。
