成为 Kubernetes 奥德赛的关键任务患者护理用例

停机可能会导致严重的后果。

相对于大多数其他行业，这些话对于医疗技术领域的公司来说更为真实——在他们的案例中，“严重后果”可能确实包括死亡。 最近，我们有机会剖析一家公司的技术堆栈，该公司正试图将医疗记录保存方式从纸笔形式转变为可在世界任何时间、任何地点访问的安全数字数据。 这些数据包括患者信息、护理指示、生物标记、医疗分析、历史记录以及医疗团队之间共享的所有其他信息。

从一开始，该公司就试图解决一个看似简单的问题： “我们如何帮助护理人员轻松地实时记录数据？” 然而，随着公司的发展，扩大规模和持续提供数据的需求使得解决这一挑战变得越来越复杂。 在这里，我们描述了公司的技术历程如何促使他们采用Kubernetes和NGINX Ingress Controller 。

技术栈一览

• 操作系统 — Linux
• 容器编排 – Microsoft Azure Kubernetes 服务
• 网络 - Kubernetes 、基于NGINX Plus 的NGINX Ingress Controller
• 软件开发语言/框架 – .Net 
• 监控、可观察性和警报 – Prometheus
• 监控仪表板 – Grafana
• 日志记录 – Grafana Loki
• 数据库 – Azure SQL 服务
• application服务器 - Azure App Service ，.Net
• 消息传递和流式传输- Azure 事件中心
• 缓存——Redis
• 安全——NGINX App Protect
• 位置和基础设施 - 两个可用区、2 个 Kubernetes 集群、15-20 个节点、60-100 个 Pod 
• DevOps – Azure DevOps 服务

下面我们来看看 NGINX 在其架构中的位置：

纸张的问题

定期获取患者状态和护理信息是医护人员的一项核心职责。 传统上，他们在纸上记录患者信息，或者最近在笔记本电脑或平板电脑上记录。 有几个严重的缺点：

• 医护人员每天可能会与数十名患者接触，因此在提供护理时写详细的记录通常是不切实际的。 因此，工人们必须在轮班结束时写下笔记。 此时，精神和身体的疲劳会让人忍不住只记录一般性的评论。
• 工作人员还必须依靠他们对患者行为细节的记忆。 如果长期记录正确且一致，不准确的信息可能会掩盖有助于诊断更大健康问题的模式。
• 纸质记录无法轻易在单个部门内的各个部门之间共享，更不用说与其他实体（如紧急医疗技术人员、急诊室工作人员和保险公司）共享了。 如果笔记本电脑或平板电脑没有连接到中央数据存储或云端，情况也不会好多少。

为了应对这些挑战，该公司创建了一个简化的数据记录系统，为访问患者信息和记录配药等常见事件提供了快捷方式。 这种易于访问和使用的特性使得实时记录患者之间的互动成为可能。

所有数据都存储在公司维护的云系统中，该应用程序与其他电子病历系统集成，提供居民行为的全面纵向视图。 这有助于护理人员提供更好的连续护理，创建安全的历史记录，并且可以轻松地与其他医疗保健软件系统共享。

医生和其他专家在接收患者或与患者进行其他接触时也会使用该平台。 有一份随患者前往任何设施的偏好和个人需求的记录。 这些可以用来帮助患者在新环境中感到舒适，从而改善恢复时间等结果。

对于公司必须存储患者数据的时间长度，有严格的法律要求。 该公司的开发人员已构建该软件以提供极高的可用性，并且正常运行时间 SLA 远远优于通用云应用。 因为无法加载病人的文件而让救护车等待并不是一个可行的选择。

从车库到云端再到 Kubernetes 的旅程

与许多初创公司一样，该公司最初通过在联合创始人家中的服务器上运行第一个概念验证应用来节省资金。 在明确了这个想法后，该公司就将其基础设施迁移到云端，而不是在数据中心管理硬件。 作为一家微软商店，他们选择了 Azure。 初始架构在 Azure App Service 中的传统虚拟机 (VM) 上运行应用，Azure App Service 是一种运行 Microsoft 的 IIS Web 服务器的托管应用交付服务。 对于数据存储和检索，该公司选择使用在虚拟机中运行的 Microsoft SQL Server 作为托管应用。

在云端运行数年后，该公司发展迅速，也经历了扩展的阵痛。 它需要无限扩展，并且是水平扩展而不是垂直扩展，因为后者使用虚拟机速度慢且成本高昂。这一要求自然而然地导致了容器化和 Kubernetes 成为可能的解决方案。 支持容器化的另一个观点是，公司的开发人员需要频繁地向应用和基础设施发送更新，而不能冒中断的风险。 由于患者记录在多个时区不断添加，因此不存在自然停机时间来推动生产变更，而不会有客户立即受到故障影响的风险。

该公司的合理起点是微软的托管 Kubernetes 产品 Azure Kubernetes 服务 (AKS)。 该团队研究了 Kubernetes 的最佳实践，并意识到他们需要在 Kubernetes 集群前运行一个Ingress 控制器，以有效管理 AKS 上节点和 pod 中运行的流量和应用。

交通路线必须灵活而精确

该团队测试了 AKS 的默认 Ingress 控制器，但发现其流量路由功能根本无法按照要求的方式向公司的客户提供更新。 当涉及到病人护理时，不允许出现模棱两可或相互矛盾的信息——例如，对于同一事件，一个护理人员看到橙色旗帜，而另一个护理人员看到红色旗帜，这是不可接受的。 因此，给定组织中的所有用户都必须使用相同版本的应用程序。这给升级带来了巨大挑战。 没有自然的时间将客户转换到新版本，因此公司需要一种方法来在服务器和网络级别使用规则将不同的客户路由到不同的应用程序版本。

为实现这一目标，公司为组织内的所有用户运行相同的后端平台，并且不提供在组织内基础设施层进行分段的多租户。 使用 Kubernetes，可以使用虚拟网络路由和浏览器上的 cookie 以及详细的流量规则来分割流量。 然而，该公司技术团队发现，AKS 的默认 Ingress 控制器只能按百分比分割流量，而不能按照需要在客户组织或个人用户级别运行的规则。

基于 NGINX Open Source 的 NGINX Ingress Controller 在基本配置上也存在同样的限制，因此公司决定转向基于 NGINX Plus（一款支持细粒度流量控制的企业级产品）的更先进的 NGINX Ingress Controller。 基于高度的灵活性和控制力，微软和 Kubernetes 社区的 NGINX Ingress Controller 的建议有助于巩固这一选择。 该配置更好地支持了公司对 pod 管理的需求（而不是传统的流量管理），确保 pod 在适当的区域中运行并且流量被路由到这些服务。 有时流量会在内部路由，但在大多数用例中，出于可观察性的原因，它会通过 NGINX Ingress Controller 路由回来。

这里有龙： 监控、可观察性和application性能

通过 NGINX Ingress Controller，技术团队可以完全控制开发人员和最终用户的体验。 一旦用户登录并建立会话，他们就可以立即被路由到新版本或恢复到旧版本。 补丁可以同时且几乎即时地推送给组织内的所有用户。 该软件不依赖于 DNS 传播或跨云平台的网络更新。

NGINX Ingress Controller 还满足了公司对细粒度和持续监控的要求。 application性能在医疗保健领域极其重要。 延迟或停机可能会妨碍成功的临床护理，特别是在生死攸关的情况下。 迁移到 Kubernetes 后，客户开始报告公司未注意到的停机情况。 公司很快发现了问题的根源： Azure 应用服务依赖于采样数据。 抽样对于平均值和总体趋势来说很好，但它完全忽略了诸如被拒绝的请求和丢失的资源之类的事情。 它也没有显示护理人员签到和记录患者数据时每半小时通常出现的使用高峰。 该公司仅获得了有关延迟、错误源、错误请求和不可用服务的不完整信息。

问题并未就此结束。 默认情况下，Azure App Service 仅保留存储的数据一个月——远远低于许多国家法律规定的几十年。  根据长期保存的需要来扩展数据存储的成本过于昂贵。 此外，Azure 解决方案无法看到 Kubernetes 网络堆栈内部。 NGINX Ingress Controller 可以处理第 4 层和第 7 层流量，从而监控基础设施和应用参数。

为了实现性能监控和可观察性，该公司选择了连接到 Grafana 可视化引擎和仪表板的 Prometheus 时间序列数据库。 Prometheus 和 Grafana 的集成已预先融入 NGINX 数据和控制平面；技术团队只需进行少量配置更改即可将所有流量引导通过 Prometheus 和 Grafana 服务器。 该信息还被路由到 Grafana Loki 日志数据库，以便更轻松地分析日志并让软件团队随着时间的推移更好地控制数据。 

这种配置还可以防止因故障排除和修复错误而需要极其频繁和大量数据采样的事件。 使用大多数大型云公司提供的应用监控系统来解决这些类型的事件可能会花费不菲，但在这个用例中，Prometheus、Grafana 和 Loki 的成本和开销很小。 这三款产品都是稳定的开源产品，通常只需在初始调整后进行修补即可。

坚持到底： 关注高可用性和安全性

该公司始终注重双重重点：一是安全性，以保护最敏感的数据类型之一；二是高可用性，以确保应用程序在需要时可用。 在转向 Kubernetes 的过程中，他们做出了一些改变来增强这两种能力。

为了实现最高的可用性，技术团队部署了主动-主动、多区域和多地理分布式基础设施设计，以实现完全冗余，没有单点故障。 该团队在两个不同的地理位置维护具有双 Kubernetes 集群的 N+2 主动-主动基础设施。 在每个地区，该软件覆盖多个数据中心以降低停机风险，并在基础设施任何层发生故障时提供覆盖。 亲和性和反亲和性规则可以立即将用户和流量重新路由到正在运行的 pod，以防止服务中断。 

为了安全起见，该团队部署了Web应用防火墙(WAF) 来防御不良请求和恶意行为者。 大多数 WAF 都提供针对OWASP Top 10 的防护。 在创建应用程序时，该团队研究了许多 WAF，包括原生 Azure WAF 和 ModSecurity。 最后，该团队选择了具有内联 WAF 和分布式拒绝服务(DDoS) 保护功能的 NGINX App Protect。

NGINX App Protect 的一大优势是它与 NGINX Ingress Controller 共置，既消除了冗余点，又减少了延迟。 其他 WAF 必须放置在 Kubernetes 环境之外，这会导致延迟和成本。 即使是极小的延迟（比如每个请求额外增加 1 毫秒）也会随着时间的推移而迅速累积。

惊喜支线任务： 开发人员无需停机

该公司已完成向 AKS 的大部分应用和网络基础设施的过渡，同时还实现了开发人员体验（DevEx）的显著改善。 现在，开发人员几乎总是能在客户自己注意到问题之前发现问题。 自转换以来，有关错误的支持电话数量下降了约 80％！

该公司的安全和应用程序性能团队拥有详细的 Grafana 仪表板和统一警报，无需检查多个系统或实施来自不同流程的警告文本和呼叫的触发器。 开发和 DevOps 团队现在可以每天甚至每天多次发送代码和基础设施更新，并使用极其精细的蓝绿模式。 以前，他们每周发布一到两次更新，并且必须在使用率较低的时间段内安排时间，这是一个令人紧张的任务。 现在，代码在准备就绪时就会交付，开发人员可以通过观察应用行为直接监控其影响。

总体而言，结果是积极的——软件开发速度提高了，开发人员的士气提高了，并且挽救了更多生命。