GKE 网络最佳做法


本文档概述了为 Google Kubernetes Engine (GKE) 集群配置网络选项的最佳做法。它是面向云架构师和网络工程师的架构规划指南,提供适用于大多数 GKE 集群的集群配置建议。在创建 GKE 集群之前,我们建议您查看本文档中的所有部分,了解 GKE 支持的网络选项及其影响。

您选择的网络选项会影响 GKE 集群的架构。其中一些选项在配置后但不重新创建集群的情况下无法更改。

本文档并非旨在介绍 Kubernetes 网络概念或术语,并假定您已掌握一定程度的常规网络概念和 Kubernetes 网络知识。如需了解详情,请参阅 GKE 网络概览

在查看本文档时,请考虑以下事项:

  • 您计划如何在内部向 Virtual Private Cloud (VPC) 网络、集群中的其他工作负载、其他 GKE 集群公开工作负载,或如何在外部向互联网公开工作负载。
  • 您计划如何扩缩工作负载。
  • 您希望使用哪些类型的 Google 服务。

如需查看所有最佳实践的汇总核对清单,请参阅核对清单摘要

VPC 设计

设计 VPC 网络时,请遵循 VPC 设计的最佳实践

以下部分针对 VPC 网络设计提供了一些特定于 GKE 的建议。

使用 VPC 原生集群

我们建议您使用 VPC 原生集群。VPC 原生集群使用 GKE 节点上的别名 IP 地址范围,并且是专用 GKE 集群以及在共享 VPC 上创建集群所必需的,还有其他许多其他好处。对于在 Autopilot 模式下创建的集群,VPC 原生模式始终处于开启状态,且无法关闭。

VPC 原生集群不消耗 Google Cloud 路由,比基于路由的集群更容易扩缩,因此更不易于达到路由限制。

使用 VPC 原生集群的好处别名 IP 支持密切相关。例如,网络端点组 (NEG) 只能与次要 IP 地址搭配使用,因此只有 VPC 原生集群支持网络端点组。

使用共享 VPC 网络

对于 GKE 集群,您需要谨慎地规划 IP 地址。大多数组织通常采用集中式管理结构,在该结构中,网络管理员可以为集群分配 IP 地址空间,平台管理员负责运营集群。Google Cloud 的共享 VPC 网络架构非常适合这种类型的组织结构。在共享 VPC 网络架构中,网络管理员可以创建子网并与 VPC 共享。您可以在服务项目中创建 GKE 集群,并在宿主项目中使用从共享 VPC 共享的子网。IP 地址组件保留在宿主项目中,而其他集群组件位于服务项目中。

共享 VPC 网络是一种常用架构,适用于具有集中式管理团队的大多数组织。我们建议使用共享 VPC 网络为 GKE 集群创建子网,并避免组织中的 IP 地址冲突。 您可能还需要使用共享 VPC 来治理运营功能。例如,您可以拥有一个仅负责网络组件和可靠性的网络团队,以及另一个负责 GKE 的团队。

IP 地址管理策略

所有 Kubernetes 集群(包括 GKE 集群)都要求每个 Pod 都具有唯一的 IP 地址。

如需了解详情,请参阅 GKE 网络模型

在 GKE 中,所有这些 IP 地址均可在整个 VPC 网络中路由。因此必须进行 IP 地址规划,因为地址不得与在本地或其他连接环境中使用的内部 IP 地址空间重叠。以下部分提供 GKE IP 地址管理策略的建议。

规划所需的 IP 地址配额

我们建议使用专用集群,将在网络安全部分中进一步讨论。在专用集群的情况下,仅支持 VPC 原生集群,并需要以下 IP 地址范围:

  • 控制平面 IP 地址范围:使用 RFC 1918 中包含的 IP 地址专用范围内的 /28 子网。您必须确保此子网不与 VPC 网络中的任何其他无类别域间路由 (CIDR) 重叠。
  • 节点子网:此子网具有您要为集群中的所有节点分配的主要 IP 地址范围。默认情况下,类型为 LoadBalancer 并使用 cloud.google.com/load-balancer-type: "Internal" 注解的 Service 也使用此子网。您还可以使用内部负载均衡器的专用子网
  • Pod IP 地址范围:您为集群中的所有 Pod 分配的 IP 范围。GKE 会将此范围预配为子网的别名。如需了解详情,请参阅 VPC 原生集群的 IP 地址范围
  • Service IP 地址范围:您为集群中的所有 Service 分配的 IP 地址范围。GKE 将此范围预配为子网的别名。

对于专用集群,您必须定义节点子网、Pod IP 地址范围和 Service IP 地址范围。

如果要更高效地使用 IP 地址空间,请参阅减少 GKE 中的内部 IP 地址用量

控制层面 IP 地址范围专用于 GKE 管理的控制层面,该控制层面位于与 VPC 对等互连的 Google 管理的租户项目中。此 IP 地址范围不应与 VPC 对等互连组中的任何 IP 地址重叠,因为 GKE 会将此路由导入您的项目中。这意味着,如果您的项目中有任何指向同一 CIDR 的路由,您可能会遇到路由问题。

创建集群时,子网具有集群节点的主要范围,并且应该在集群创建之前就已存在。子网应容纳您预期的集群中的节点数上限以及使用子网的集群中的内部负载均衡器 IP 地址。

您可以使用集群自动扩缩器来限制节点数上限。

pod 和服务 IP 地址范围表示为子网的不同次要范围,在 VPC 原生集群中作为别名 IP 地址实现。

请选择足够宽泛的 IP 地址范围,以便容纳集群的所有节点、Pod 和 Service

请考虑以下限制:

使用更多专用 RFC 1918 IP 地址

对于某些环境,大型连续 CIDR 块中的 RFC 1918 空间可能已在组织中分配。您可以将非 RFC 1918 空间用于 GKE 集群的其他 CIDR,只要它们不与 Google 拥有的公共 IP 地址重叠即可。我们建议您使用 RFC 地址空间的 100.64.0.0/10 部分,因为 E 类地址空间可能会与本地硬件存在互操作性问题。您可以使用以非公开方式重复使用的公共 IP (PUPI)。

请谨慎使用以非公开方式重复使用的公共 IP 地址,并且在选择此选项时,考虑控制本地网络中到互联网的路由通告。

您不应在具有 Pod 到 Pod 流量和 Pod 到 Service 流量的集群中使用来源网络地址转换 (SNAT)。这会破坏 Kubernetes 网络模型

Kubernetes 假定所有非 RFC 1918 IP 地址都是以非公开方式重复使用的公共 IP 地址,并对来自这些地址的所有流量使用 SNAT。

如果您的 GKE 集群使用非 RFC 1918 IP 地址,对于标准集群,您需要显式停用 SNAT 或配置配置 IP 伪装代理代理,以从 SNAT 中排除集群的 Pod IP 地址和 Service 的次要 IP 地址范围。对于 Autopilot 集群,无需执行任何额外步骤。

使用自定义子网模式

设置网络时,您还需要选择子网模式:auto(默认)或 custom(推荐)。如果使用 auto 模式,Google 会负责子网分配,如果您没有规划 IP 地址,这是一个不错的入门选项。但是,我们建议您选择 custom 模式,因为该模式允许您选择不会与环境中的其他范围重叠的 IP 地址范围。如果您使用的是共享 VPC,组织管理员或网络管理员可以选择此模式。

以下示例创建了一个名为 my-net-1 且具有自定义子网模式的网络:

gcloud compute networks create my-net-1 --subnet-mode custom

规划每个节点的 pod 密度

默认情况下,Standard 集群会在子网中的 Pod 地址空间以外,为每个节点预留 /24 范围,每个节点最多允许 110 个 Pod。不过,您可以将标准集群配置为支持每个节点最多 256 个 Pod,并为每个节点预留 /23 范围。根据节点大小和 Pod 的应用配置文件,您在每个节点上运行的 Pod 数量可能会远少于此。

如果您预计每个节点运行的 pod 不超过 64 个,我们建议您调整每个节点的最大 pod 数量,以保留 pod 子网的 IP 地址空间。

如果您预计在每个节点上运行的 Pod 数会超过默认值 (110),则可以将每个节点的 Pod 数量上限增加到 256 个,并为每个节点预留 /23 范围。使用这种高 Pod 密度的配置时,我们建议您使用具有不少于 16 个 CPU 核心的实例,以确保集群的可伸缩性和性能。

对于 Autopilot 集群,每个节点的 pod 数量上限设置为 32,为每个节点预留一个 /26 范围。此设置在 Autopilot 集群中不可配置。

避免与其他环境中使用的 IP 地址重叠

您可以通过 Cloud VPNCloud Interconnect 将您的 VPC 网络连接到本地环境或其他云服务提供商。这些环境可以共享路由,使得本地 IP 地址管理方案对于 GKE 的 IP 地址规划非常重要。我们建议确保 IP 地址不与其他环境中使用的 IP 地址重叠。

创建负载均衡器子网

创建一个单独的负载均衡器子网,以使用内部 TCP/UDP 负载均衡公开服务。如果不使用单独的负载均衡器子网,这些服务使用节点子网中的 IP 地址公开,这可能导致过早使用该子网中的所有已分配空间,并使 GKE 集群无法扩缩到预期的节点数。

使用单独的负载均衡器子网还意味着,您可以将进出 GKE 节点的流量单独过滤到由内部 TCP/UDP 负载均衡公开的服务,从而设置更严格的安全边界。

为集群自动扩缩器预留足够的 IP 地址空间

您可以使用集群自动扩缩器在集群中动态添加和移除节点,以便控制费用并提高利用率。但是,在使用集群自动扩缩器时,请确保 IP 地址规划考虑了所有节点池的大小上限。每个节点都需要有自己的节点 IP 地址,以及基于各节点配置的 pod 的可分配 pod IP 地址集。每个节点配置的 pod 数量可以与在集群级别上配置的数量不同。创建集群或节点池后,您无法更改每个节点的 pod 数量。您应该考虑您的工作负载类型,并将其分配给不同的节点池,以实现最佳 IP 地址分配。

考虑将节点自动预配与集群自动扩缩器搭配使用,尤其是在使用 VPC 原生集群时。如需了解详情,请参阅节点限制范围

在集群之间共享 IP 地址

如果您有管理集群基础架构的集中式团队,则可能需要在集群之间共享 IP 地址。如需在 GKE 集群之间共享 IP 地址,请参阅在 GKE 集群之间共享 IP 地址范围。您可以为 Pod、Service 和节点创建三个范围,并重复使用或共享这些范围(尤其是在共享 VPC 模型中),从而减少 IP 耗尽。此设置由于不需要网络管理员为每个集群创建特定子网,因而还能够更轻松地管理 IP 地址。

请考虑以下事项:

  • 最佳实践是对所有集群使用单独的子网和 IP 地址范围。
  • 您可以共享次要 Pod IP 地址范围,但不建议这样做,因为一个集群可能会使用所有 IP 地址。
  • 您可以共享次要 Service IP 地址范围,但此功能不适用于 VPC 范围的 Cloud DNS for GKE

如果 IP 地址耗尽,您可以使用连续的多 Pod CIDR 创建其他 Pod IP 地址范围。

共享内部 LoadBalancer Service 的 IP 地址

您最多可以与使用不同端口的 50 个后端共享单个 IP 地址。这样可以减少内部 LoadBalancer Service 所需的 IP 地址数量。

如需了解详情,请参阅共享 IP

网络安全选项

本部分简要介绍集群隔离的几个关键建议。GKE 集群的网络安全是 Google 与您的集群管理员共担的责任。

使用 GKE Dataplane V2

GKE Dataplane V2 基于 eBPF,可提供集成式网络安全与可见性体验。使用 GKE Dataplane V2 创建集群时,您无需明确启用网络政策,因为 GKE Dataplane V2 会管理服务路由、网络政策实施和日志记录。创建集群时,使用 Google Cloud CLI --enable-dataplane-v2 选项启用新的 Dataplane。配置网络政策后,可将默认的 NetworkLogging CRD 对象配置为记录允许和拒绝的网络连接。我们建议使用 GKE Dataplane V2 创建集群,以充分利用网络政策日志记录等内置功能。

选择专用集群类型

公共集群的节点具有专用和公共 IP 地址,而控制平面节点只有公共端点。专用集群的节点只有内部 IP 地址,而控制平面节点具有专用或公共端点,从而提供更强的隔离性(控制平面节点可以进一步隔离,具体请参阅尽量缩小集群控制平面公开范围部分)。在专用集群中,您仍然可以通过专用 Google 访问通道访问 Google API。我们建议选择专用集群。

在专用集群中,pod 与入站和出站通信(集群边界)是隔离的。您可以使用负载均衡和 Cloud NAT 公开服务,从而控制这些有方向的流量,具体请参阅本文档的集群连接部分。下图展示了这种设置:

图 1:专用集群通信

下图展示了专用集群的通信方式。本地客户端可以使用 kubectl 客户端连接到集群。可以通过专用 Google 访问通道访问 Google 服务,并且只能使用 Cloud NAT 与互联网进行通信。

如需了解详情,请参阅专用集群的要求、限制和局限性

尽量缩小集群控制层面公开范围

在专用集群中,GKE API 服务器可以公开为公共端点或专用端点。您可以在创建集群时决定要使用的端点。如果公共和专用端点均默认允许 pod 与集群中的节点 IP 地址之间的通信,您可以使用授权网络来控制访问权限。如需在创建集群时启用专用端点,请使用 --enable-private-endpoint 标志。

授权访问控制层面

授权网络可帮助控制哪些 IP 地址子网可以访问 GKE 控制层面节点。启用这些网络后,您可以限制对特定来源 IP 地址范围的访问。如果停用公共端点,这些来源 IP 地址范围应该是专用 IP 地址范围。如果启用公共端点,您可以允许公共或内部 IP 地址范围。配置自定义路由通告以允许从本地环境访问集群控制层面的专用端点。您可以在创建集群时使用 --enable-master-global-access 选项,使专用 GKE API 端点可在全球范围内访问。

下图显示了使用授权网络的典型控制层面连接:

图 2:使用授权网络的控制控制层面连接

上图显示了可信用户能够通过公共端点与 GKE 控制层面通信,因为它们是授权网络的一部分,而不受信任用户的访问则被阻止。与 GKE 集群的通信通过控制层面的专用端点进行。

允许控制层面连接

每个工作器节点上的特定系统 pod 都需要访问 Kubernetes API 服务器 (kube-apiserver)、Google API 或元数据服务器等服务。kube-apiserver 还需要与一些系统 pod(例如 event-exporter)通信。这种通信是默认允许的。如果您在项目中部署 VPC 防火墙规则(有关详情请参阅“限制集群流量”部分),请确保这些 pod 能够继续与 kube-apiserver 以及 Google API 通信。

部署代理以从对等互连的网络访问控制层面

要访问专用 GKE 集群控制层面,需要通过 VPC 网络对等互连。VPC 网络对等互连不具有传递性,因此您无法从另一个对等互连网络访问集群的控制层面。

使用中心辐射型架构时,如果您希望从其他对等互连网络或从本地直接访问,请为控制平面流量部署代理。

使用网络政策限制集群流量

对于可以合并的集群工作负载,可以实施多个级别的网络安全措施:VPC 防火墙规则、分层防火墙政策和 Kubernetes 网络政策。VPC 防火墙规则和分层防火墙政策应用于虚拟机级别,即 GKE 集群的 pod 所在的工作器节点。Kubernetes 网络政策应用于 Pod 级别,用于强制执行 Pod 到 Pod 的流量路径。

如果您实施 VPC 防火墙,可能会中断默认的必需控制平面通信,例如与控制平面的 kubelet 通信。GKE 会默认创建必需的防火墙规则,但这些规则可以被覆盖。某些部署可能需要控制层面访问服务的集群。您可以使用 VPC 防火墙来配置允许访问服务的入站政策。

GKE 网络政策通过 Kubernetes Network Policy API 进行配置,以强制执行集群的 Pod 通信。您可以在创建集群时使用 gcloud container clusters create 选项 --enable-network-policy 来启用网络政策。要使用网络政策限制流量,您可以遵循 Anthos 限制流量蓝图实施指南

为 Ingress 启用 Google Cloud Armor 安全政策

借助 Google Cloud Armor 安全政策,您可以通过在网络边缘阻止 DDoS 攻击和其他网络攻击流量来保护使用外部应用负载均衡器的应用免遭此类攻击。在 GKE 中,如需为应用启用 Google Cloud Armor 安全政策,请使用适用于外部应用负载均衡器的 Ingress向附加到 Ingress 对象的 BackendConfig 添加安全政策

使用 Identity-Aware Proxy 为拥有 IAM 用户的应用提供身份验证

如果您想部署只有组织内用户可以访问的服务,并且无需通过公司网络也可访问,则可以使用 Identity-Aware Proxy 为这些应用创建验证层。如需为 GKE 启用 Identity-Aware Proxy,请按照配置步骤操作,在服务 Ingress 的 BackendConfig 中添加 Identity-Aware Proxy。Identity-Aware Proxy 可与 Google Cloud Armor 结合使用。

使用组织政策限制条件进一步增强安全性

通过组织政策限制条件,您可以设置政策以进一步增强安全状况。例如,您可以使用限制条件来将负载均衡器创建限制为特定类型,例如仅限内部负载均衡器。

扩缩集群连接

本部分介绍 DNS 和从集群到互联网和 Google 服务的出站连接的扩缩选项。

使用 Cloud DNS for GKE

您可以使用 Cloud DNS for GKE 通过代管式 DNS 提供 Pod 和 Service DNS 解析,而无需集群托管的 DNS 提供商。Cloud DNS 消除了管理集群托管的 DNS 服务器的开销,并且无需扩缩、监控或管理 DNS 实例,因为它是托管的 Google 服务。

启用 NodeLocal DNSCache

GKE 使用 kube-dns 将集群的本地 DNS 服务作为默认集群插件提供。kube-dns 作为集群中的核心和节点总数的函数复制到整个集群中。

您可以使用 NodeLocal DNSCache 提升 DNS 性能。NodeLocal DNSCache 是一个作为 DaemonSet 部署的插件,不需要对 pod 配置进行任何更改。本地 Pod 服务的 DNS 查找不会创建需要在节点上跟踪的打开连接,从而能够实现更大的扩缩性。外部主机名查找会转发到 Cloud DNS,而所有其他 DNS 查询则转到 kube-dns。

启用 NodeLocal DNSCache,以获得更加一致的 DNS 查询查找时间和更强的集群扩缩能力。对于 Autopilot 集群,NodeLocal DNSCache 默认启用且不能覆盖。

以下 Google Cloud CLI 选项会在创建集群时启用 NodeLocal DNSCache:--addons NodeLocalDNS.

如果您可以控制应用要解析的名称,则可以改善 DNS 扩缩。例如,使用 FQDN(主机名以英文句点结尾),或通过 Pod.dnsConfig 清单选项停用搜索路径扩展。

使用 Cloud NAT 允许专用集群访问互联网

默认情况下,专用集群无法访问互联网。如需允许 pod 连接到互联网,请为每个区域启用 Cloud NAT。您应至少为 GKE 子网中的主要和次要范围启用 Cloud NAT。请确保为 Cloud NAT 分配足够的 IP 地址并为每个虚拟机分配足够的端口

将 Cloud NAT 用于专用集群时,请遵循以下 Cloud NAT 网关配置最佳实践:

  • 创建 Cloud NAT 网关时,仅为集群使用的子网范围启用该网关。通过计算所有集群中的所有节点,您可以确定您在项目中拥有的 NAT 使用方虚拟机数量。
  • 使用动态端口分配,根据虚拟机的使用量为每个虚拟机分配不同数量的端口。最小端口数为 64,最大端口数为 2048。

  • 如果您需要管理与同一目标 3 元组的多个并发连接,请将 TCP TIME_WAIT 超时从默认值 120s 降低到 5s。如需了解详情,请参阅为 NAT 指定不同的超时

  • 启用 Cloud NAT 错误日志记录以检查相关日志。

  • 配置网关后,检查 Cloud NAT 网关日志。为了减少分配状态中断问题,您可能需要提高每个虚拟机的端口数上限。

您应该避免对 Pod 流量重复进行 SNAT(首先在 GKE 节点上执行 SNAT,然后再使用 Cloud NAT 进行 SNAT)。除非您需要 SNAT 将 Pod IP 地址隐藏到由 Cloud VPN 或 Cloud Interconnect 连接的本地网络,否则请 disable-default-snat 并将 SNAT 跟踪卸载到 Cloud NAT,以实现可伸缩性。此解决方案适用于所有主要和次要子网 IP 范围。启用 Cloud NAT 后,您可以使用网络政策限制外部流量。访问 Google 服务不需要 Cloud NAT。

使用专用 Google 访问通道访问 Google 服务

在专用集群中,Pod 没有公共 IP 地址,因此无法访问公共服务(包括 Google API 和服务)。专用 Google 访问通道可让专用 Google Cloud 资源访问 Google 服务。

专用 Google 访问通道在专用集群中默认处于启用状态,但共享 VPC 集群除外。

提供应用

创建组织可从外部或内部访问的应用时,请确保使用正确的负载均衡器类型和选项。本部分提供关于使用 Cloud Load Balancing 公开和扩缩应用的建议。

使用容器原生负载均衡

使用 HTTP(S) 在外部公开服务时,使用容器原生负载均衡。容器原生负载均衡可实现更少的网络跃点、更低的延迟和更精确的流量分配。它还可提高往返时间的可见性,并可让您使用 Google Cloud Armor 等负载均衡功能。

选择正确的 GKE 资源来公开应用

根据客户端的范围(内部、外部,或甚至集群内部)、应用的区域以及使用的协议,您可以选择使用不同的 GKE 资源来公开应用。服务网络概览介绍了这些选项,并可帮助您使用 Google Cloud 负载均衡选项选择用于公开应用的各个部分的最佳资源。

根据 BackendConfig 创建健康检查

如果您使用 Ingress 来公开服务,请使用 BackendConfig CRD 中的健康检查配置,以使用外部应用负载均衡器的健康检查功能。您可以将健康检查定向到相应的端点,并设置自己的阈值。如果没有 BackendConfig CRD,将根据就绪性探测参数推断健康检查或使用默认参数。

使用本地流量政策来保留原始 IP 地址

当您将内部直通式网络负载均衡器与 GKE 配合使用时,请将 externalTrafficPolicy 选项设置为 Local 以保留请求的来源 IP 地址。如果应用需要原始的来源 IP 地址,请使用此选项。但是,externalTrafficPolicy local 选项可能会导致无法获得最佳的负载分布,因此请仅在必要时使用此功能。对于 HTTP(S) 服务,您可以使用 Ingress 控制器,通过读取 HTTP 请求中的 X-Forwarded-For 标头来获取原始 IP 地址。

使用 Private Service Connect

您可以使用 Private Service Connect 在其他 VPC 网络之间共享内部直通式网络负载均衡器 Service。这对于托管在 GKE 集群上但为不同项目和不同 VPC 中运行的客户提供服务的 Service 非常有用。

您可以在具有重叠 IP 地址的 VPC 之间提供,使用 Private Service Connect 减少 IP 地址消耗。

运营和管理

以下各部分包含运营最佳做法,可帮助您确保为工作负载设置精细的授权选项。为避免创建手动防火墙规则,请遵循本部分中的运营最佳做法。本部分还包括分布工作负载以及在 GKE 中进行监控和日志记录的建议。

使用 IAM for GKE 权限控制共享 VPC 网络中的政策

使用共享 VPC 网络时,系统会在宿主项目中自动创建负载均衡器的防火墙规则。

为避免需要手动创建防火墙规则,请在名为 service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com 的宿主项目中为 GKE 服务账号分配最小权限自定义角色。

HOST_PROJECT_NUMBER 替换为共享 VPC 的宿主项目的编号。

您创建的自定义角色应具有以下权限:

  • compute.firewalls.create
  • compute.firewalls.get
  • compute.firewalls.list
  • compute.firewalls.delete

此外,GKE 创建的防火墙规则的默认优先级始终为 1000,您可以通过创建优先级更高的防火墙规则来阻止特定流量传输。

如果要限制创建某些负载均衡器类型,请使用组织政策来限制负载均衡器创建

使用区域级集群并分布工作负载以实现高可用性

区域级集群可以提高集群中应用的可用性,因为集群控制层面和节点分布在多个可用区。

但是,如需在发生可用区故障时提供最佳用户体验,请使用集群自动扩缩器,以确保集群能够随时处理所需的负载。

您还可以使用 Pod 反亲和性以确保给定服务的 Pod 被安排在多个可用区中。

如需详细了解如何配置这些设置以实现高可用性和费用优化,请参阅高可用性 GKE 集群的最佳实践

使用 Cloud Logging 和 Cloud Monitoring 并启用网络政策日志记录功能

虽然每个组织对可见性和审核有不同的要求,但我们建议启用网络政策日志记录。只有 GKE Dataplane V2 提供此功能。通过网络政策日志记录,您能够了解政策实施和 pod 流量模式。请注意,网络政策日志记录会产生费用。

对于使用 1.14 版或更高版本的 GKE 集群,Logging 和 Monitoring 默认处于启用状态。Monitoring 为您的 GKE 集群提供了一个信息中心。Logging 还为 VPC 流日志启用 GKE 注释。默认情况下,Logging 会收集部署到集群的所有工作负载的日志,但也有“仅系统”选项。使用 GKE 信息中心观察并设置提醒。对于在 Autopilot 模式下创建的集群,监控和日志记录功能会自动启用且不可配置。

请注意,Google Cloud Observability 会产生费用。

核对清单摘要

面积图 练习
VPC 设计
IP 地址管理策略
网络安全选项
扩缩
提供应用
运营和管理

后续步骤