主要概念

• 命名空间：命名空间是将集群划分为多个虚拟子集群的合乎逻辑的方式。

• Pods：Pod 是Kubernetes对象模型中可以创建或部署的最小单位。Pod 代表集群中运行进程的单个实例，可包含一个或多个容器。

• 节点：节点是集群中在容器中运行应用的物理或虚拟计算机。每个节点都由 Kubernetes 控制平面管理。

• 服务：服务定义了一组逻辑 Pod 和访问它们的策略。服务可实现依赖 Pod 之间的松散耦合，从而更容易管理微服务架构。

• Sidecar 容器：Kubernetes 中的 Sidecar 容器是与同一 Pod 中的主应用容器一起运行的额外容器。此设置允许 Sidecar 容器与主容器共享网络、存储和生命周期，使它们能够紧密协作。

• 服务网格：Kubernetes 中的服务网格管理微服务通信，通过高级流量管理和监控功能提高安全性、可靠性和可观察性。

控制窗格组件

您可以通过 UI 来访问 Kubernetes 控制面板，也可以使用命令 Kubectl 从 CLI 进行访问。

• API 服务器：API 服务器是公开 Kubernetes API 的中央管理实体，负责处理所有内部和外部请求，并充当控制平面的前端。

• 计划程序：计划程序负责根据资源需求、限制和可用性将 Pod 分配给节点。

• 控制器-管理器：运行各种调节集群状态的控制器，确保集群的理想状态与实际状态一致。

• etcd：etcd 是一种分布式键值存储，Kubernetes 使用它来满足所有集群数据存储需求

节点组件

• kubelet：kubelet 是每个节点上的代理，可确保 Pod 中的容器正常运行，并向控制平面报告容器状态。

• kube-proxy：kube-proxy 是每个节点上的网络代理，负责管理网络规则和平衡流量，确保服务可访问，连接可到达正确的 Pod。

• 容器运行时：容器运行时是负责运行容器的软件。

Cisco Secure Workload 中的 Kubernetes/OpenShift 部署

部署包含四个主要组件：

1. 控制或管理窗格，位于本地 Cisco Secure Workload 集群或 SaaS 上托管的 Cisco Secure Workload 租户上

2. 在管理平面内建立的 Cisco Secure Workload Orchestrator 或 Connector 与适用于 EKS、AKS、GKE、OpenShift 或非托管 Kubernetes 的 Kubernetes 集群 API 进行交互。此交互可增强对 Pod 和服务元数据的可视性，提供 Pod ID、注释或标签等详细信息。有关详细信息，请参阅 Kubernetes/OpenShift。

3. Kubernetes 后台守护程序集部署到用于安全措施的 Kubernetes 或 OpenShift 集群。后台守护程序集可确保 Cisco Secure Workload 代理或 Pod 在每个 Kubernetes 或 OpenShift 节点上持续运行。有关详细信息，请参阅安装 Kubernetes 或 OpenShift 代理以实现深度可视性和执行。

4. 激活漏洞扫描程序会在 Kubernetes 节点中的一个 Pod 上启动扫描。此扫描程序可监控 Kubernetes 或 OpenShift 集群中的每个容器映像，将识别出的 CVE 报告给控制或管理平面。

操作系统支持信息可在代理 OS 支持矩阵 (Agent OS support matrix)中找到。

要求

• 安装脚本需要 Kubernetes 或 OpenShift 管理员凭证，以便在集群节点上启动特权代理 Pod。

• Cisco Secure Workload 实体在 tetration 命名空间中创建。

• 节点或 Pod 安全策略必须允许特权模式 Pod。

• busybox:1.33 映像必须预安装或可从 Docker Hub 下载。

• 对于容器化的行时，如果未设置 config_path，请修改 config.toml（默认位置：/etc/containerd/config.toml），如下所示：

  
  ```
      [plugins."io.containerd.grpc.v1.cri".registry]
      config_path = "/etc/containerd/certs.d"
   ```

  重启 containerd 后台守护程序。

• 要在 Kubernetes 或 OpenShift 控制平面节点上运行，–toleration 标志可用于传入 Cisco Secure Workload Pod 的容差。通常通过的容差是 NoSchedule 容差，通常会阻止 Pod 在控制平面节点上运行。

• 对于 Windows 工作节点：

  • 支持的 Windows 工作节点容器运行时：ContainerD。

  • ContainerD 配置：配置以下 containerd 更改。

    
    ```
        [plugins."io.containerd.grpc.v1.cri".registry]
        config_path = "/etc/containerd/certs.d"
     ```

    删除 registry.mirrors下的配置。默认配置文件位置为 C:\Program Files\containerd\config.toml。

    在配置更改后，重启 containerd 后台守护程序。

  • 映像 mcr.microsoft.com/oss/kubernetes/windows-host-process-containers-base-image:v1.0.0 必须在 Windows 工作节点上预安装或可下载。

  • 正在升级到较新版本的现有 Kubernetes 代理会自动包含 Windows 守护进程集代理。但是，前一个脚本不会卸载 Windows 守护进程集代理。下载最新的安装程序脚本，以便卸载 Windows 守护进程集代理。

  • 支持的型号：

    • Microsoft Windows Server 2022

    • Windows Server 2019

    • Kubernetes 1.27 及更高版本

策略执行要求

OpenShift 不支持基于 IPVS 的 kube-proxy 模式。

这些代理应配置为启用保留规则选项。有关更多信息，请参阅创建代理配置文件。

为使执行正常运行，任何已安装的 CNI 插件都必须：

• 在所有节点和 Pod 之间提供平面地址空间（IP 网络）。不支持伪装源 Pod IP 以进行集群内通信的网络插件。

• 不干扰 Cisco Secure Workload 执行代理使用的 Linux iptables 规则或标记（标记位 21 和 20 用于允许和拒绝 NodePort 服务的流量）

以下 CNI 插件经过测试，可满足上述要求：

• Calico (3.13) 与以下 Felic 配置：(ChainInsertMode: Append, Ipta- blesRefreshInterval: 0) 或 (ChainInsertMode: Insert, IptablesFilterAllowAction: Return, IptablesMangleAllowAction: Return, IptablesRefreshInterval: 0)。所有其他选项均使用各自的默认值。

有关设置这些选项的详细信息，请参阅 Felex 配置参考。

服务网格边车代理

服务网格通过与应用容器一同部署的边车代理，拦截并管理网络流量。边车代理与应用共享同一网络命名空间，中转所有入站和出站网络通信。

流量执行

• 为启用服务网格的应用执行分段策略时，需考虑边车代理使用的额外端口。这些端口对应用网络流量的管理与安全防护至关重要。

• 为保障服务网格正常运行，分段策略中需明确包含边车代理所用端口的规则。

边车代理支持的端口与协议。

为启用服务网格的应用执行分段策略时，需包含以下端口。

Note	以上端口为 Istio 中 Envoy 边车代理通信的默认端口。若在 Istio 全局服务网格配置中更新了端口，应用需使用更新后的端口。

服务网格控制平面支持的端口与协议

对控制平面执行分段时，使用以下端口与协议。