如第 1.1 节所述，参考平台是一个容器编排和管理平台。在现代应用环境中，平台是物理（裸机）或虚拟化（如虚拟机、容器）基础设施上的一个抽象层。在实施 DevSecOps 原语之前，平台只是包含了应用代码，其中包含了应用逻辑和服务网状代码，而服务网状代码又提供应用服务。本节将考虑以下内容：
- 一个容器编排和资源管理平台，容纳了应用程序代码和大部分的服务网格代码
- 服务网格的软件架构
2.1 容器编排和资源管理平台
由于微服务通常是以容器的形式实现的，因此容器编排和资源管理平台被用于服务的部署、运维和维护。
一个典型的协调和资源管理平台由各种逻辑（形成抽象层）和物理工件组成，用于部署容器。例如，在 Kubernetes 中，容器在最小的部署单元内运行，称为 Pod。一个 Pod 理论上可以承载一组容器，但通常情况下，一个 Pod 内只运行一个容器。一组 Pod 被定义在所谓的节点内，节点可以是物理机或虚拟机（VM）。一组节点构成了一个集群。通常情况下，需要单个微服务的多个实例来分配工作负载，以达到预期的性能水平。集群是一个资源池（节点），用于分配微服务的工作负载。使用的技术之一是横向扩展，即访问频率较高的微服务被分配更多的实例或分配到具有更多资源（如 CPU 和 / 或内存）的节点。
2.2 服务网格架构
在看了基于微服务的应用所需的各种应用服务后，考虑一下提供这些服务的服务网格的架构。服务网格由两个主要部分组成：控制平面和数据平面。
2.2.1 控制平面
控制平面有几个组件。虽然服务网格的数据面主要由作为容器运行在与应用容器相同的 Pod 中的代理组成，但控制面组件在它们自己的 Pod、节点和相关集群中运行。以下是控制平面的 各种功能：
- Envoy sidecar 代理的服务发现和配置
- 自动化的密钥和证书管理
- 用于策略定义和收集遥测数据的 API
- 服务网格组件的配置摄取
- 管理一个到服务网格的入站连接（入站网关）
- 管理来自服务网格的出站连接（出口网关）
- 将 sidecar 代理注入那些托管应用程序微服务容器的 Pod、节点或命名空间中
总的来说，控制平面帮助管理员用配置数据填充数据平面组件，这些数据是由控制平面的策略产生的。上述功能 3 的策略可能包括网络路由策略、负载均衡策略、蓝绿部署的策略、金丝雀部署、超时、重试和断路能力。这后三项被统称为网络基础设施服务的弹性能力的特殊名称。最后要说的是与安全相关的策略（例如，认证和授权策略、TLS 建立策略等）。这些策略规则由一个模块解析，该模块将其转换为配置参数，供执行这些策略的数据平面代理中的可执行程序使用。
2.2.2 数据平面
数据平面组件执行三种不同的功能：
- 安全的网络功能
- 策略执行功能
- 可观测性功能
执行上述三种功能的数据平面的主要组件被称为 sidecar 代理。这个七层代理运行在与它执行代理功能的微服务相同的网络命名空间（在这个平台上，就是同一个 Pod）。每个微服务都有一个代理，以确保来自微服务的请求不会绕过其相关的代理，每个代理都作为容器运行在与应用微服务相同的 Pod 中。两个容器都有相同的 IP 地址，并共享相同的 IP 表规则。这使得代理完全控制了 Pod，并 处理所有通过它的流量。
第一类功能（安全网络）包括与微服务之间的实际路由或消息通信有关的所有功能。属于这一类的功能是服务发现、建立安全（TLS）会话、为每个微服务及其相关请求建立网络路径和路由规则、验证每个请求（来自服务或用户）以及授权请求。
以建立双向 TLS 会话为例，发起通信会话的代理将与服务网格的控制平面中的模块进行交互，以检查是否需要通过链加密流量并与后端或目标 Pod 建立双向 TLS。使用双向 TLS 启用这个功能需要每个 Pod 有一个证书（即有效的凭证）。由于一个规模较大的微服务应用程序（由许多微服务组成）可能需要数百个 Pod（即使没有通过多个实例对单个微服务进行横向扩展），这可能涉及到管理数百个生命周期短暂的证书。这反过来又要求每个微服务有一个强大的身份，服务网格要有一个访问管理器、一个证书存储和一个证书验证能力。此外，为了支持认证策略，还需要识别和认证两个通信的 Pod 的机制。
其他类型的代理包括拦截客户端调用到应用程序的第一个入口点（第一个被调用的微服务）的 入口代理 和处理微服务对驻扎在平台集群外的应用模块的请求的出口代理。
数据平面执行的第二类功能是通过代理中的配置参数执行控制平面中定义的策略（策略执行服务）。一个例子是使用作为微服务请求一部分的 JWT 令牌中的信息来验证调用服务。另一个例子是使用驻留在代理本身的代码或通过连接到外部授权服务，为每个请求执行访问控制策略。
服务代理与应用服务容器联合执行的第三类功能是收集遥测数据，这有助于监测服务的健康和状态，将与服务相关的日志传输到控制平面中的日志聚合模块，并将必要的数据附加到应用请求头，以方便追踪与特定应用事务相关的所有请求。应用响应由代理机构以返回代码、响应描述或检索数据的形式传达给其相关的调用服务。
服务网格是容器编排平台感知的，与 API 服务器互动，该服务器为安装在各种平台工件（如 Pod、节点、命名空间）中的应用服务提供一个窗口，监测它是否有新的微服务，并自动将 sidecar 容器注入包含这些新微服务的 Pod。一旦服务网格插入 sidecar 代理容器，运维和安全团队就可以对流量执行策略，并帮助保护和运维应用程序。这些团队还可以配置对微服务应用的监控，而不干扰应用的运作。
基础设施、策略执行和可观测性服务的配置可以使用作为 DevSecOps 管道一部分的声明性代码来自动化。虽然开发团队应该全面了解其代码部署的安全和管理细节，但上述服务的自动化为他们提供了更多的时间来集中精力进行高效的开发范式，如代码模块化和结构化。