📚 课程目录第2章 Kubernetes核心概念回顾

2. Kubernetes 核心概念回顾：Pod、Deployment、Service、Ingress、Namespace、ConfigMap、Secret

在深入 Istio 流量管理之前，必须牢固掌握 Kubernetes 的 7 个核心原语。这些原语构成了应用部署、网络暴露和配置管理的基石，也是 Istio 进行流量拦截与策略注入的操作对象。本章以“发布流水线”为视角，逐一回顾每个概念在生产中的角色与交互关系。

2.1 概念全景：从 Pod 到 Ingress 的流量路径

下图展示了从内部 Pod 到外部 Ingress 的完整流量路径，以及 ConfigMap/Secret 如何为这些工作负载提供配置与敏感数据。

2.2 核心原语详解

2.2.1 Pod：最小调度单元

Pod 是 Kubernetes 中可创建和部署的最小计算单元，由一个或多个容器组成。在 Istio 环境中，每个 Pod 会被注入一个 Envoy sidecar 代理容器，所有进出流量都经过该代理。

共享网络栈：Pod 内的容器共享 IP 地址和端口空间。
生命周期短暂：Pod 本身不提供自愈能力，通常由 Deployment 管理。
Istio 注入：通过标签 sidecar.istio.io/inject: "true" 自动注入 Envoy 代理。

2.2.2 Deployment：声明式更新与副本管理

Deployment 是 Pod 的控制器，负责维护期望的副本数、滚动更新和回滚。在发布流水线中，Deployment 是版本更新的直接操作对象。

字段	说明	发布流水线中的典型值
`replicas`	期望的 Pod 副本数	3（生产环境）
`strategy.type`	更新策略：RollingUpdate / Recreate	RollingUpdate
`strategy.rollingUpdate.maxSurge`	更新期间允许超出期望副本数的最大值	25%
`strategy.rollingUpdate.maxUnavailable`	更新期间允许不可用的最大 Pod 数	25%
`template.metadata.labels`	Pod 标签，Service 通过此标签选择	`app: myapp, version: v2`

💡 发布流水线提示：CI/CD 工具（如 Jenkins、GitLab CI）通常通过 kubectl set image 或修改 Deployment YAML 中的 image 字段来触发更新。Istio 的灰度发布则依赖 version 标签区分不同版本的 Deployment。

2.2.3 Service：稳定的网络访问入口

Service 为一组 Pod 提供稳定的虚拟 IP（ClusterIP）和 DNS 名称，实现负载均衡和服务发现。Istio 的流量路由规则正是作用于 Service 层面。

ClusterIP：默认类型，仅在集群内部可访问。
NodePort：在每个节点上开放一个静态端口。
LoadBalancer：云厂商提供的外部负载均衡器。
Headless Service：不分配 ClusterIP，直接返回 Pod IP 列表，用于 StatefulSet。

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

2.2.4 Ingress：外部流量入口

Ingress 将外部 HTTP/HTTPS 流量路由到集群内部的 Service。在 Istio 场景中，通常使用 Istio Gateway 替代传统 Ingress Controller，以获得更精细的流量管理能力。

特性	K8s Ingress	Istio Gateway
协议支持	HTTP/HTTPS	HTTP/HTTPS/TCP/gRPC
流量分割	有限（通过 annotation）	原生支持权重路由、请求头匹配
故障注入	不支持	原生支持
TLS 管理	通过 Secret	通过 Secret + 自动 mTLS

2.2.5 Namespace：虚拟集群边界

Namespace 将集群划分为多个虚拟集群，用于多环境（dev/staging/prod）或多团队隔离。Istio 的访问控制策略（AuthorizationPolicy）和 Sidecar 注入范围通常按 Namespace 配置。

资源隔离：同一 Namespace 内的资源名称必须唯一。
网络策略：默认允许跨 Namespace 通信，可通过 NetworkPolicy 限制。
Istio 注入：通过 Namespace 标签 istio-injection: enabled 实现全局注入。

2.2.6 ConfigMap 与 Secret：配置与敏感数据管理

ConfigMap 用于存储非敏感配置（如配置文件、环境变量），Secret 用于存储敏感数据（如密码、TLS 证书）。两者都可以通过环境变量或卷挂载的方式注入到 Pod 中。

特性	ConfigMap	Secret
数据存储	明文	Base64 编码（etcd 中建议加密）
典型用途	应用配置文件、命令行参数	数据库密码、、TLS 证书
更新方式	直接修改，Pod 需重启或热加载	直接修改，Pod 需重启或热加载
大小限制	1MB（etcd 限制）	1MB（etcd 限制）

# ConfigMap 示例
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.properties: |
    log.level=INFO
    cache.ttl=300

# Secret 示例
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=   # base64 编码的 "admin"
  password: cGFzc3dvcmQ= # base64 编码的 "password"

2.3 概念对比：发布流水线中的角色差异

下表总结了 7 个核心概念在发布流水线中的不同职责与交互对象：

概念	发布流水线中的角色	与 Istio 的交互点
Pod	运行应用容器的实例	Envoy sidecar 注入目标
Deployment	版本更新的操作对象	通过 `version` 标签区分灰度组
Service	稳定的服务访问入口	VirtualService 路由的目标
Ingress	外部流量入口	通常被 Istio Gateway 替代
Namespace	环境隔离边界	Sidecar 注入范围、策略作用域
ConfigMap	非敏感配置注入	Envoy 配置可引用（较少见）
Secret	敏感数据注入	TLS 证书、mTLS 密钥来源

2.4 实践：在发布流水线中操作这些资源

以下是一个典型的 CI/CD 流水线中操作 K8s 资源的步骤序列：

构建镜像：CI 阶段生成新版本的容器镜像并推送到镜像仓库。
更新 ConfigMap/Secret：如果配置有变化，先更新 ConfigMap 或 Secret。
更新 Deployment：修改 Deployment 的镜像版本，触发滚动更新。
验证 Service 可达性：通过 Service 的 ClusterIP 或 DNS 验证新版本 Pod 是否正常响应。
配置 Ingress/Gateway：如果需要暴露新版本，更新 Ingress 规则或 Istio VirtualService。
监控与回滚：观察 Pod 状态和日志，必要时执行 kubectl rollout undo。

⚠️ 常见陷阱：在更新 Deployment 时，如果 Service 的 selector 没有匹配新 Pod 的标签，流量将无法到达新版本。确保 spec.selector.matchLabels 与 Service 的 spec.selector 一致。

2.5 本章小结

Pod、Deployment、Service、Ingress、Namespace、ConfigMap 和 Secret 是 Kubernetes 应用管理的 7 个核心原语。在 Istio 流量管理实践中，这些原语构成了服务网格的基础操作对象：Deployment 管理版本，Service 提供稳定入口，Namespace 划定边界，ConfigMap/Secret 注入配置。掌握这些概念是后续学习 Istio 流量路由、灰度发布和故障注入的前提。