Kubernetes 全景解析 (5)：安全体系与可观测性全景
· 阅读需 20 分钟
前言
当你的 Kubernetes 集群从开发环境走向生产环境，有两个话题再也无法回避——安全与可观测性。安全是底线，确保只有正确的主体才能访问正确的资源；可观测性是生命线，让你在问题发生时能快速定位、快速恢复。
本文将从 K8s 安全的 4C 模型出发，深入 RBAC 权限控制、Pod 安全标准与服务账户管理；随后转向可观测性的三大支柱——指标、日志与链路追踪，构建一套完整的监控与诊断体系。
一、K8s 安全架构概览
1.1 4C 安全模型
Kubernetes 社区提出了经典的 4C 安全模型，将安全分为四个层次，从外到内逐层收紧：
| 层次 | 名称 | 关注点 | 示例 |
|---|---|---|---|
| 第 1 层 | Cloud（云） | 云平台自身的安全配置 | IAM 策略、VPC、防火墙规则 |
| 第 2 层 | Cluster（集群） | 集群组件的访问控制 | RBAC、网络策略、审计日志 |
| 第 3 层 | Container（容器） | 容器运行时安全 | 镜像签名、只读根文件系统、非 root 运行 |
| 第 4 层 | Code（代码） | 应用代码自身的安全 | 输入校验、依赖漏洞、密钥管理 |
核心原则
4C 模型的关键思想是纵深防御（Defense in Depth）——任何单一层次的安全措施都不足以应对所有威胁，只有层层设防，才能构建真正可靠的安全体系。内层的安全措施不应依赖外层，每一层都应独立提供保护。
1.2 安全最佳实践总览
| 领域 | 最佳实践 |
|---|---|
| 认证 | 启用 TLS 双向认证，禁用匿名访问 |
| 授权 | 最小权限原则，使用 RBAC 精细控制 |
| Pod 安全 | 强制非 root 运行，只读根文件系统 |
| 网络 | 默认拒绝，按需开放 NetworkPolicy |
| 镜像 | 使用可信仓库，启用镜像签名验证 |
| 密钥 | 使用外部密钥管理（Vault/AWS KMS），避免明文存储 |
| 审计 | 启用 API Server 审计日志，记录所有变更 |
二、RBAC：基于角色的访问控制
2.1 核心概念
RBAC（Role-Based Access Control）是 K8s 授权机制中最常用、最推荐的方式。它通过四个核心对象实现权限管理：
| 对象 | 作用范围 | 说明 |
|---|---|---|
| Role | 命名空间级别 | 定义在某个命名空间内的权限规则 |
| ClusterRole | 集群级别 | 定义集群范围的权限规则 |
| RoleBinding | 命名空间级别 | 将 Role 绑定到用户/组/服务账户 |
| ClusterRoleBinding | 集群级别 | 将 ClusterRole 绑定到用户/组/服务账户 |
Role vs ClusterRole 的关键区别
Role只能管理同一个命名空间内的资源ClusterRole可以管理所有命名空间以及非命名空间资源（如 Node、PersistentVolume、Namespace）
2.2 RBAC 权限模型
2.3 完整 YAML 示例
Role —— 命名空间管理员
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: namespace-admin
namespace: production
rules:
- apiGroups: ["", "apps", "batch"]
resources:
- pods
- pods/log
- deployments
- services
- configmaps
- secrets
- jobs
- cronjobs
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
ClusterRole —— 只读查看者
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-readonly
rules:
- apiGroups: ["", "apps", "batch", "extensions"]
resources: ["*"]
verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/healthz", "/version", "/metrics"]
verbs: ["get"]
RoleBinding —— 将角色绑定到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: bind-namespace-admin
namespace: production
subjects:
- kind: User
name: alice@example.com
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: dev-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: namespace-admin
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding —— 将只读角色绑定到服务账户
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: bind-readonly-to-monitor
subjects:
- kind: ServiceAccount
name: prometheus
namespace: monitoring
roleRef:
kind: ClusterRole
name: cluster-readonly
apiGroup: rbac.authorization.k8s.io
2.4 常见 RBAC 模式
| 模式 | 适用场景 | 实现方式 |
|---|---|---|
| 命名空间管理员 | 团队负责人管理自己的命名空间 | Role + RoleBinding |
| 只读查看者 | 开发/测试人员查看集群状态 | ClusterRole + ClusterRoleBinding |
| 开发人员 | 开发者在指定命名空间部署应用 | Role（限制 verbs） + RoleBinding |
| 运维人员 | 运维管理节点、PV 等集群级资源 | ClusterRole（节点/PV 权限） + ClusterRoleBinding |
| 聚合角色 | 将多个 ClusterRole 合并为一个统一角色 | ClusterRole + aggregationRule |
ClusterRole 聚合（Aggregated ClusterRoles）
Kubernetes 支持通过 aggregationRule 将多个 ClusterRole 聚合为一个组合角色。控制平面会自动监视匹配标签选择器的 ClusterRole，并将其规则合并到聚合角色的 rules 字段中。默认的用户角色（如 admin、edit、view）就是通过聚合机制实现的，允许集群管理员通过添加匹配标签的 ClusterRole 来扩展默认角色的权限。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 控制平面自动填充规则
注意事项
roleRef一旦创建不可修改，如需变更必须删除重建 Binding- 避免使用
verbs: ["*"]和resources: ["*"]的通配符，遵循最小权限原则 - 定期审计集群中的 RoleBinding 和 ClusterRoleBinding，清理不再需要的权限
三、Pod 安全标准
3.1 从 PSP 到 PSS
Kubernetes 在 v1.21 中废弃了 PodSecurityPolicy（PSP），并在 v1.25 中完全移除。取而代之的是 Pod Security Standards（PSS） + Pod Security Admission（PSA） 机制。
| 特性 | PSP（已废弃） | PSS + PSA（推荐） |
|---|---|---|
| 实现方式 | 准入控制器（Admission Controller） | 内置准入插件 |
| 配置粒度 | 每个 Pod 可绑定不同策略 | 按命名空间统一标签 |
| 策略继承 | 支持 | 不支持（需借助第三方 Gatekeeper） |
| 状态 | v1.25 已移除 | v1.23+ 内置可用 |
3.2 三种策略级别
| 级别 | 说明 | 典型控制 |
|---|---|---|
| Privileged | 无限制，完全开放 | 无任何控制 |
| Baseline | 最低限度的安全防护 | 禁止特权容器、禁止挂载宿主机路径、限制 hostNetwork、限制 SELinux 类型、禁止探针/生命周期钩子中的 host 字段（v1.34+）、限制 AppArmor 配置文件、限制安全 sysctl |
| Restricted | 高度安全，生产推荐 | 强制非 root、只读根文件系统、限制 Capabilities（仅允许 NET_BIND_SERVICE）、禁止 seccomp profile=unconfined、要求显式设置 seccomp |
Baseline 策略的完整控制列表（基于 v1.34 官方文档）
根据 Pod Security Standards 官方文档，Baseline 策略包含以下控制：
| 控制项 | 说明 |
|---|---|
| HostProcess | 禁止 Windows HostProcess 容器 |
| Host Namespaces | 禁止共享 hostNetwork/hostPID/hostIPC |
| Privileged Containers | 禁止特权容器 |
| Capabilities | 限制可添加的 Capabilities（如 AUDIT_WRITE、CHOWN、NET_BIND_SERVICE 等） |
| HostPath Volumes | 禁止 hostPath 卷 |
| Host Ports | 禁止或限制 hostPort |
| Host Probes / Lifecycle Hooks（v1.34+） | 禁止探针和生命周期钩子中的 host 字段 |
| AppArmor | 限制 AppArmor 配置文件类型（RuntimeDefault/Localhost） |
| SELinux | 限制 SELinux 类型（container_t/container_init_t/container_kvm_t/container_engine_t），禁止自定义 user/role |
| /proc Mount Type | 要求使用默认 /proc 掩码 |
| Seccomp | 禁止显式设置为 Unconfined |
| Sysctls | 仅允许安全 sysctl 子集 |
3.3 Pod Security Admission 配置
PSA 通过在命名空间上打标签来生效，支持三种执行模式：
# 在命名空间上配置 PSA 标签
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
# enforce: 违反策略的 Pod 将被拒绝
pod-security.kubernetes.io/enforce: restricted
# audit: 违反策略的 Pod 会记录审计日志
pod-security.kubernetes.io/audit: restricted
# warn: 违反策略的 Pod 会触发用户警告
pod-security.kubernetes.io/warn: restricted
# 指定策略版本
pod-security.kubernetes.io/enforce-version: latest
3.4 v1.34 新增安全控制详解
Kubernetes v1.34 在 Pod Security Standards 中引入了多项重要安全控制更新：
3.4.1 Host Probes / Lifecycle Hooks（v1.34+）
这是 v1.34 中 Baseline 策略新增的控制项，禁止在探针和生命周期钩子中使用 host 字段，防止容器通过 HTTP/TCP 探针访问宿主机网络。
受限字段包括：
livenessProbe.httpGet.host/readinessProbe.httpGet.host/startupProbe.httpGet.hostlivenessProbe.tcpSocket.host/readinessProbe.tcpSocket.host/startupProbe.tcpSocket.hostlifecycle.postStart.httpGet.host/lifecycle.preStop.httpGet.hostlifecycle.postStart.tcpSocket.host/lifecycle.preStop.tcpSocket.host
允许值：Undefined/nil 或空字符串 ""
这意味着在 Baseline 策略下，探针和生命周期钩子不能再指向宿主机的 IP 地址或主机名，有效防止了通过探针机制进行的 SSRF（服务端请求伪造）攻击。
3.4.2 SELinux 类型扩展
SELinux 控制在 Baseline 策略中进一步收紧：
- 允许的 SELinux 类型：
container_t、container_init_t、container_kvm_t、container_engine_t（自 Kubernetes 1.31起新增） - 禁止：自定义 SELinux
user和role选项（允许值仅为Undefined/""）
container_engine_t 类型适用于需要与容器引擎交互的特殊工作负载场景。
3.4.3 安全 Sysctls 扩展
自 Kubernetes 1.29 起，Baseline 策略允许的安全 sysctl 列表新增了以下 TCP keepalive 相关参数：
| Sysctl 名称 | 说明 | 新增版本 |
|---|---|---|
net.ipv4.tcp_keepalive_time | TCP keepalive 探测间隔 | since 1.29 |
net.ipv4.tcp_fin_timeout | TCP FIN 超时时间 | since 1.29 |
net.ipv4.tcp_keepalive_intvl | TCP keepalive 探测间隔 | since 1.29 |
net.ipv4.tcp_keepalive_probes | TCP keepalive 探测次数 | since 1.29 |
完整的安全 sysctl 列表还包括：kernel.shm_rmid_forced、net.ipv4.ip_local_port_range、net.ipv4.ip_unprivileged_port_start、net.ipv4.tcp_syncookies、net.ipv4.ping_group_range、net.ipv4.ip_local_reserved_ports（since 1.27）。
3.4.4 AppArmor 控制
Baseline 策略对 AppArmor 配置文件的控制：
- 允许的类型：
RuntimeDefault、Localhost，或通过注解container.apparmor.security.beta.kubernetes.io/*设置runtime/default、localhost/* - 目的：防止禁用或绕过默认的 AppArmor 安全配置文件
3.5 SecurityContext 配置
SecurityContext 是 Pod 安全的核心配置点，可以在 Pod 级别和容器级别分别设置：
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
namespace: production
spec:
securityContext:
# Pod 级别：所有容器共享
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: nginx:1.25
securityContext:
# 容器级别：仅对当前容器生效
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
seccompProfile:
type: RuntimeDefault
volumeMounts:
- name: tmp
mountPath: /tmp
- name: cache
mountPath: /var/cache/nginx
volumes:
- name: tmp
emptyDir: {}
- name: cache
emptyDir: {}
为什么需要 emptyDir 挂载？
当设置 readOnlyRootFilesystem: true 时，Nginx 等应用需要写入 /tmp 和缓存目录。通过 emptyDir 提供临时可写目录，既满足了应用需求，又保持了根文件系统的只读安全。
四、服务账户与 Token 管理
4.1 ServiceAccount 概念
Kubernetes 中每个 Pod 都关联一个服务账户（ServiceAccount），用于标识 Pod 的身份。当 Pod 需要访问 API Server 时，使用的就是 ServiceAccount 的凭证。
# 创建专用服务账户
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-service-account
namespace: production
automountServiceAccountToken: false
4.2 自动挂载 Token 的风险
默认情况下，K8s 会将 ServiceAccount Token 自动挂载到每个 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录。这意味着：
- 任何能进入容器的人都能获取 Token
- 如果容器被攻破，攻击者可以利用 Token 访问 API Server
- 对于不需要访问 API Server 的 Pod，这是不必要的安全暴露
# 方式一：在 Pod 规范中禁用自动挂载
apiVersion: v1
kind: Pod
metadata:
name: app-no-token
spec:
serviceAccountName: app-service-account
automountServiceAccountToken: false
containers:
- name: app
image: myapp:latest
# 方式二：在 ServiceAccount 上全局禁用
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-service-account
namespace: production
automountServiceAccountToken: false
4.3 外部 Token 供应
对于需要更精细控制 Token 生命周期（如短时效 Token、Token 轮换）的场景，可以使用 TokenRequest API 获取面向 Pod 的绑定 Token：
# 使用 projected volume 注入短时效 Token
apiVersion: v1
kind: Pod
metadata:
name: app-with-projected-token
spec:
containers:
- name: app
image: myapp:latest
volumeMounts:
- name: token
mountPath: /var/run/secrets/tokens
volumes:
- name: token
projected:
sources:
- serviceAccountToken:
path: token
expirationSeconds: 3600 # Token 有效期 1 小时
audience: api
最佳实践
- 不需要访问 API Server 的 Pod：设置
automountServiceAccountToken: false - 需要访问 API Server 的 Pod：创建专用的 ServiceAccount，配合最小权限的 RBAC
- 高安全要求场景：使用 projected volume + 短时效 Token，实现自动轮换
五、可观测性体系概览
5.1 三大支柱
可观测性（Observability）的三大支柱构成了完整的系统诊断能力：
| 支柱 | 回答的问题 | 典型工具 | 数据特征 |
|---|---|---|---|
| Metrics（指标） | 系统现在是什么状态？ | Prometheus、Thanos | 结构化数值，适合聚合与告警 |
| Logs（日志） | 系统发生了什么？ | Fluent Bit、Loki、ELK | 非结构化文本，适合问题排查 |
| Traces（链路追踪） | 请求经过了哪些路径？ | Jaeger、Zipkin、Tempo | 结构化事件流，适合性能分析与故障定位 |
为什么需要三大支柱？
单一支柱无法回答所有问题。指标告诉你"CPU 使用率 90%"，但不能告诉你"是哪个请求导致的"；日志告诉你"请求超时了"，但不能告诉你"请求在哪个服务卡住了"。只有三者结合，才能快速、准确地定位问题。
六、Prometheus + Grafana：指标监控
6.1 Prometheus 在 K8s 中的部署
在生产环境中，推荐使用 kube-prometheus-stack（基于 Prometheus Operator）一键部署完整的监控栈：
# 通过 Helm 安装 kube-prometheus-stack
# helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
# helm install prometheus prometheus-community/kube-prometheus-stack \
# --namespace monitoring --create-namespace
Prometheus Operator 引入了四个自定义资源（CRD）来声明式管理监控配置：
| CRD | 作用 |
|---|---|
| Prometheus | 管理 Prometheus 实例的生命周期 |
| ServiceMonitor | 基于 Service 选择器自动发现监控目标 |
| PodMonitor | 基于 Pod 标签直接发现监控目标 |
| PrometheusRule | 声明式定义告警规则和录制规则 |
6.2 核心监控指标
| 级别 | 关键指标 | 说明 |
|---|---|---|
| 容器级 | container_cpu_usage_seconds_total | 容器 CPU 使用量 |
container_memory_working_set_bytes | 容器实际内存使用（含 Page Cache） | |
container_fs_usage_bytes | 容器文件系统使用量 | |
| Pod 级 | kube_pod_status_phase | Pod 当前阶段（Pending/Running/Succeeded/Failed） |
kube_pod_container_status_restarts_total | Pod 重启次数 | |
kube_pod_container_status_waiting_reason | 容器等待原因（ImagePullBackOff 等） | |
| Node 级 | node_cpu_seconds_total | 节点 CPU 使用量 |
node_memory_MemAvailable_bytes | 节点可用内存 | |
kube_node_status_condition | 节点状态（Ready/NotReady） |
6.3 ServiceMonitor 示例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: app-service-monitor
namespace: monitoring
labels:
release: prometheus # 匹配 Prometheus 实例的选择器
spec:
selector:
matchLabels:
app: my-application # 匹配目标 Service 的标签
namespaceSelector:
names:
- production # 监控 production 命名空间中的 Service
endpoints:
- port: http # Service 中的端口名
path: /metrics # 指标暴露路径
interval: 30s # 采集间隔
scrapeTimeout: 10s # 采集超时
6.4 告警规则示例
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: app-alerting-rules
namespace: monitoring
labels:
release: prometheus
spec:
groups:
- name: app-alerts
rules:
- alert: PodCrashLooping
expr: rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
for: 15m
labels:
severity: critical
annotations:
summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 处于 CrashLoopBackOff"
description: "容器 {{ $labels.container }} 在过去 15 分钟内重启超过 5 次"
- alert: HighMemoryUsage
expr: |
(container_memory_working_set_bytes / container_spec_memory_limit_bytes) > 0.9
and container_spec_memory_limit_bytes > 0
for: 5m
labels:
severity: warning
annotations:
summary: "容器 {{ $labels.container }} 内存使用率超过 90%"
description: "当前使用 {{ $value | humanizePercentage }}，限制 {{ $labels.container }}"
- alert: NodeNotReady
expr: kube_node_status_condition{condition="Ready",status="true"} == 0
for: 5m
labels:
severity: critical
annotations:
summary: "节点 {{ $labels.node }} 处于 NotReady 状态"
告警设计原则
- Critical 告警：需要立即响应（如节点宕机、Pod CrashLoop）
- Warning 告警：需要关注但不必立即处理（如磁盘使用率 > 80%）
- 设置合理的
for持续时间，避免瞬时抖动触发误报 - 告警信息要包含足够的上下文，让值班人员无需额外查询即可判断影响范围
七、日志收集体系
7.1 日志收集模式对比
| 模式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| Sidecar | 每个 Pod 注入一个日志采集容器 | 隔离性好，可按应用定制 | 资源开销大，管理复杂 |
| DaemonSet | 每个 Node 运行一个采集 Agent | 资源开销低，管理简单 | 需要共享日志卷 |
| 直连 | 应用直接推送日志到后端 | 无需额外组件 | 与后端强耦合，侵入应用 |
7.2 常见方案对比
| 方案 | 组合 | 特点 | 适用场景 |
|---|---|---|---|
| PLG Stack | Promtail + Loki + Grafana | 轻量，与 Grafana 深度集成 | 已有 Grafana 的团队 |
| EFK Stack | Fluentd/Fluent Bit + Elasticsearch + Kibana | 功能强大，全文搜索 | 大规模日志分析 |
| Fluent Bit + Loki | Fluent Bit + Loki + Grafana | 极低资源消耗 | 资源敏感的环境 |
7.3 Fluent Bit DaemonSet 配置
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit
namespace: logging
labels:
app: fluent-bit
spec:
selector:
matchLabels:
app: fluent-bit
template:
metadata:
labels:
app: fluent-bit
spec:
serviceAccountName: fluent-bit
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
containers:
- name: fluent-bit
image: fluent/fluent-bit:3.0.0
volumeMounts:
- name: varlog
mountPath: /var/log
readOnly: true
- name: containers
mountPath: /var/lib/docker/containers
readOnly: true
- name: config
mountPath: /fluent-bit/etc/fluent-bit.conf
subPath: fluent-bit.conf
volumes:
- name: varlog
hostPath:
path: /var/log
- name: containers
hostPath:
path: /var/lib/docker/containers
- name: config
configMap:
name: fluent-bit-config
八、链路追踪
8.1 OpenTelemetry 在 K8s 中的集成
OpenTelemetry（OTel） 是 CNCF 的可观测性标准框架，统一了指标、日志和链路追踪的数据采集。在 K8s 中，通常部署 OpenTelemetry Collector 作为数据的统一入口：
apiVersion: apps/v1
kind: Deployment
metadata:
name: otel-collector
namespace: observability
spec:
replicas: 2
selector:
matchLabels:
app: otel-collector
template:
metadata:
labels:
app: otel-collector
spec:
containers:
- name: otel-collector
image: otel/opentelemetry-collector-contrib:0.96.0
args:
- --config=/etc/otelcol/config.yaml
ports:
- containerPort: 4317 # OTLP gRPC
- containerPort: 4318 # OTLP HTTP
- containerPort: 8889 # Prometheus metrics
volumeMounts:
- name: config
mountPath: /etc/otelcol
volumes:
- name: config
configMap:
name: otel-collector-config
8.2 分布式追踪最佳实践
| 实践 | 说明 |
|---|---|
| 统一 SDK 接入 | 所有服务使用 OpenTelemetry SDK，自动注入 Trace Context |
| 合理的采样策略 | 生产环境使用尾部采样（Tail Sampling），基于错误率/延迟/状态码决定是否保留 |
| 上下文传播 | 确保跨服务调用时 TraceID 正确传播（HTTP Header、gRPC Metadata） |
| 关联日志与追踪 | 在日志中注入 TraceID，实现日志与追踪的联动查询 |
| 设置合理的 Span 层级 | 避免过深的 Span 嵌套，关注关键路径和外部调用 |
TraceID 与日志联动
在应用日志中添加 TraceID 字段，可以在 Grafana 中实现从告警到日志再到追踪的完整排查链路：
# 应用日志示例
2026-04-09 10:23:45 INFO [trace_id=abc123 span_id=def456] Processing order request from user_1234
2026-04-09 10:23:46 ERROR [trace_id=abc123 span_id=def456] Failed to call payment service: timeout
九、本章小结
本文从安全与可观测性两个维度，系统梳理了 Kubernetes 生产环境中的关键能力：
安全体系方面，我们覆盖了从 4C 安全模型到具体实践的完整链路：
- RBAC 提供了精细的权限控制，通过 Role/ClusterRole 和 Binding 的组合，实现最小权限原则。ClusterRole 还支持
aggregationRule聚合机制，便于扩展默认角色权限。 - Pod Security Standards 替代了已废弃的 PSP，通过 PSA 标签为命名空间设置安全基线。v1.34 中 Baseline 策略新增了 Host Probes/Lifecycle Hooks 控制，SELinux 新增
container_engine_t类型，安全 sysctl 列表也进一步扩展。 - ServiceAccount Token 管理 教会我们如何控制 Pod 的 API Server 访问权限，避免不必要的凭证暴露。
可观测性体系方面，我们构建了三大支柱的完整图景：
- Prometheus + Grafana 负责指标采集、可视化与告警，是监控体系的核心
- Fluent Bit + Loki 提供轻量高效的日志收集与查询能力
- OpenTelemetry + Jaeger 实现了分布式链路追踪，让跨服务调用路径一目了然
安全与可观测性不是孤立的话题——良好的可观测性是安全事件响应的基础，而安全策略本身也需要被持续监控。在下一篇文章中，我们将深入 Kubernetes 的调度策略与资源管理，探讨如何让集群的每一份资源都物尽其用。
十、官方文档参考
本文内容基于 Kubernetes v1.34 官方文档校验，以下是相关官方文档链接：
安全相关
- Pod Security Standards - PSS 三种策略级别与完整控制列表
- Pod Security Admission - PSA 准入控制器配置
- Using RBAC Authorization - RBAC 授权机制与聚合角色
- Configure Security Context for a Pod or Container - SecurityContext 配置
- [Service Accounts](https://kubernetes.io/docs concepts/service-accounts/) - 服务账户管理
- Migrate from PodSecurityPolicy to Pod Security Admission - PSP 迁移指南
可观测性相关
- Prometheus Operator - Prometheus Operator CRD
- OpenTelemetry - 可观测性标准框架
系列导航
章节 主题 状态 0 架构设计与核心概念 ✅ 已发布 1 工作负载与 Pod 生命周期深度解析 ✅ 已发布 2 网络模型与服务发现全链路解析 ✅ 已发布 3 存储体系与配置管理深度剖析 ✅ 已发布 4 调度器、资源管理与弹性伸缩 ✅ 已发布 5 安全体系与可观测性全景 ✅ 已发布 6 生产级微服务架构实战 ✅ 已发布 7 有状态应用与 Operator 模式实战 ✅ 已发布