Kubernetes 学习指南-极简笔记

第一章：Kubernetes 是什么

Kubernetes（简称 K8s）是 Google 于 2014 年开源的容器编排平台，目前由云原生计算基金会（CNCF）维护。它的核心目标是让你能够自动化地部署、扩缩容和管理容器化的应用。

简单来说，当你有一组微服务需要运行在多个容器里、分布在多台机器上时，Kubernetes 帮你解决以下问题：这个容器该跑在哪台机器上？挂了怎么办？流量怎么分配？怎么在不中断服务的情况下升级？

Kubernetes 之所以成为事实标准，是因为它经过了 Google 内部十余年大规模生产验证（前身是 Borg 系统），并拥有极其活跃的社区生态。截至 2026 年，几乎所有主流云厂商（AWS EKS、Azure AKS、Google GKE、阿里云 ACK、腾讯云 TKE 等）都提供了托管的 Kubernetes 服务。

1.1 核心架构概览

一个 Kubernetes 集群由**控制平面（Control Plane）和一组工作节点（Worker Nodes）**组成。

┌─────────────────────────────────────────────────────┐
│                  Control Plane                       │
│  ┌─────────────┐ ┌──────────┐ ┌──────────────────┐  │
│  │ API Server  │ │ etcd     │ │ Scheduler        │  │
│  │ (入口)      │ │ (状态库) │ │ (调度决策)       │  │
│  └─────────────┘ └──────────┘ └──────────────────┘  │
│  ┌───────────────────┐                               │
│  │ Controller Manager│                               │
│  │ (控制器集合)      │                               │
│  └───────────────────┘                               │
└─────────────────────────────────────────────────────┘
         │                    │                    │
    ┌────┴────┐         ┌────┴────┐         ┌────┴────┐
    │ Node 1  │         │ Node 2  │         │ Node 3  │
    │┌───────┐│         │┌───────┐│         │┌───────┐│
    ││kubelet││         ││kubelet││         ││kubelet││
    │├───────┤│         │├───────┤│         │├───────┤│
    ││kube-  ││         ││kube-  ││         ││kube-  ││
    ││proxy  ││         ││proxy  ││         ││proxy  ││
    │├───────┤│         │├───────┤│         │├───────┤│
    ││容器   ││         ││容器   ││         ││容器   ││
    ││运行时 ││         ││运行时 ││         ││运行时 ││
    │└───────┘│         │└───────┘│         │└───────┘│
    └─────────┘         └─────────┘         └─────────┘

控制平面组件：

API Server：集群的唯一入口，所有操作（通过 kubectl、API 调用等）都经过它。它负责验证请求、执行认证鉴权，并将状态写入 etcd。
etcd：一个高可用的分布式键值存储，保存集群的所有状态数据（Pod 定义、ConfigMap、Secret 等）。可以理解为集群的"大脑"。
Scheduler：监听新创建但尚未分配节点的 Pod，根据资源需求、亲和性规则、污点容忍等策略决定把 Pod 调度到哪个节点。
Controller Manager：包含一系列控制器（如 ReplicaSet Controller、Deployment Controller、Node Controller 等），它们持续运行，确保集群的实际状态不断趋近于你声明的期望状态。

节点组件：

kubelet：运行在每个节点上的代理，负责接收 API Server 的指令，确保本节点上的容器按照 Pod 规范正常运行。
kube-proxy：维护节点上的网络规则（iptables/IPVS），实现 Service 的负载均衡和网络转发。
容器运行时（CRI）：实际运行容器的软件。Kubernetes 从 v1.24 起移除了对 Docker 的直接支持（dockershim），现在主流使用 containerd 或 CRI-O。

第二章：搭建学习环境

学习 Kubernetes 的第一步是拥有一个可用的集群。以下是 2026 年主流的搭建方式，按推荐程度排序：

2.1 方式对比

工具	适用场景	最低配置	上手难度	特点
Minikube	本地学习	2 核 4G	低	功能最完整，支持多种驱动
Kind	CI/CD 测试	2 核 4G	低	基于 Docker，启动快
K3s	边缘/IoT/低配机器	1 核 512M	中	Rancher 出品，极其轻量
Docker Desktop	最简入门	2 核 4G	最低	一键开启，无需额外安装
kubeadm	生产部署	2 核 2G×N	高	官方工具，适合搭建真实集群

2.2 Windows 上使用 Docker Desktop（最简方案）

这是 Windows 用户最快的上手方式：

从 https://www.docker.com/products/docker-desktop/ 下载安装 Docker Desktop。
打开 Docker Desktop → Settings → Kubernetes → 勾选 Enable Kubernetes。
点击 Apply & Restart，等待状态变为绿色（首次可能需要几分钟）。
打开终端验证：

kubectl version --client
kubectl cluster-info

2.3 Windows 上使用 Minikube（推荐方案）

Minikube 提供更完整的集群体验，支持多节点模拟。

第一步：安装 kubectl

在 Windows PowerShell（管理员）中执行：

# 方式一：使用 winget（推荐）
winget install Kubernetes.kubectl

# 方式二：手动下载
# 访问 https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/
# 下载对应版本的二进制文件，添加到 PATH

第二步：安装 Minikube

# 使用 winget
winget install minikube

# 或手动下载安装
# https://minikube.sigs.k8s.io/docs/start/

第三步：启动集群

# 使用 Docker 作为驱动（推荐，需要先安装 Docker Desktop）
minikube start --driver=docker

# 验证
kubectl get nodes

你应该看到类似输出：

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   30s   v1.36.0

2.4 使用 Kind（适合 CI/CD 场景）

# 安装 kind
go install sigs.k8s.io/kind@latest

# 或通过 winget（Windows）
winget install Kubernetes.kind

# 创建集群
kind create cluster --name k8s-learn

# 验证
kubectl get nodes

Kind 还支持创建多节点集群，只需提供一个配置文件：

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

kind create cluster --name k8s-multi --config kind-config.yaml

第三章：kubectl 核心操作

kubectl 是 Kubernetes 的命令行工具，是你与集群交互的主要方式。掌握它是学习 K8s 的基本功。

3.1 配置与集群信息

# 查看当前配置（包含集群、用户、上下文信息）
kubectl config view

# 查看当前上下文
kubectl config current-context

# 切换上下文
kubectl config use-context my-cluster

# 查看集群信息
kubectl cluster-info

# 查看集群中的所有节点
kubectl get nodes

3.2 声明式 vs 命令式

Kubernetes 推崇**声明式（Declarative）**管理方式——你告诉集群"我想要什么状态"，而不是"怎么一步步操作"。

# 声明式（推荐）：通过 YAML 文件定义资源
kubectl apply -f my-deployment.yaml

# 命令式（适合快速测试）
kubectl run nginx --image=nginx:latest
kubectl create deployment web --image=nginx:1.27
kubectl expose deployment web --port=80 --type=NodePort

3.3 常用命令速查

# ========== 资源查看 ==========
kubectl get pods                    # 查看 Pod
kubectl get pods -o wide            # 更多详情（含 IP、节点）
kubectl get pods --all-namespaces   # 所有命名空间
kubectl get pods -l app=web         # 按标签过滤
kubectl get pods -w                 # 实时监视变化
kubectl get deploy                  # 查看 Deployment
kubectl get svc                     # 查看 Service
kubectl get all                     # 查看所有资源

# ========== 资源详情 ==========
kubectl describe pod <pod-name>     # 查看 Pod 详细事件
kubectl describe svc <svc-name>     # 查看 Service 详情

# ========== 日志与调试 ==========
kubectl logs <pod-name>             # 查看容器日志
kubectl logs -f <pod-name>          # 实时跟踪日志
kubectl logs <pod-name> -c <容器名> # 多容器 Pod 中指定容器
kubectl exec -it <pod-name> -- /bin/sh   # 进入容器
kubectl port-forward svc/my-svc 8080:80  # 端口转发到本地

# ========== 资源管理 ==========
kubectl apply -f <file.yaml>        # 创建或更新资源
kubectl delete -f <file.yaml>       # 删除资源
kubectl delete pod <pod-name>       # 删除指定 Pod
kubectl scale deploy web --replicas=5   # 手动扩缩容

# ========== 编辑与补丁 ==========
kubectl edit deploy web             # 交互式编辑
kubectl patch deploy web -p '{"spec":{"replicas":3}}'  # 补丁更新

3.4 YAML 资源清单结构

几乎所有 Kubernetes 资源都遵循相同的 YAML 结构：

apiVersion: apps/v1          # API 版本
kind: Deployment              # 资源类型
metadata:                     # 元数据
  name: my-app                # 名称
  namespace: default          # 命名空间
  labels:                     # 标签
    app: my-app
spec:                         # 规格定义（期望状态）
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:                   # Pod 模板
    metadata:
      labels:
        app: my-app
    spec:                     # Pod 规格
      containers:
        - name: app
          image: nginx:1.27
          ports:
            - containerPort: 80

提示：不确定某个资源的字段怎么写？使用 kubectl explain：

kubectl explain deployment.spec.replicas
kubectl explain pod.spec.containers
kubectl explain --recursive pod.spec  # 查看所有字段

第四章：核心资源详解

4.1 Pod — 最小调度单元

Pod 是 Kubernetes 中最小的可部署单元。一个 Pod 封装一个或多个紧密关联的容器，它们共享网络和存储。

为什么不直接管理容器？ 因为有些场景需要多个容器协同工作，比如：主应用容器 + 日志收集 sidecar，或 Web 服务器 + 静态文件同步器。Pod 就是为这种场景设计的。

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: demo
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
      resources:                    # 始终建议设置资源限制
        requests:
          cpu: "100m"               # 请求 0.1 核 CPU
          memory: "128Mi"           # 请求 128MB 内存
        limits:
          cpu: "500m"
          memory: "256Mi"
      livenessProbe:                # 存活探针
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 10
      readinessProbe:               # 就绪探针
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 3
        periodSeconds: 5
  restartPolicy: OnFailure

关键概念：

resources.requests：调度器用来决定 Pod 放到哪个节点的最低资源保证。
resources.limits：容器实际能使用的资源上限，超出会被限流或 OOM Kill。
livenessProbe：如果探测失败，kubelet 会重启容器。
readinessProbe：如果探测失败，Pod 会从 Service 的端点中移除，不再接收流量。

4.2 Deployment — 无状态应用管理

实际生产中你几乎不会直接创建 Pod，而是通过 Deployment 来管理。Deployment 负责管理一组 Pod 的副本数量、滚动更新和回滚。

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3                    # 期望运行的 Pod 副本数
  selector:
    matchLabels:
      app: web-app
  strategy:                      # 更新策略
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                # 更新时最多多出 1 个 Pod
      maxUnavailable: 0          # 更新时不允许有不可用的 Pod
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: app
          image: my-app:v1.0
          ports:
            - containerPort: 8080

滚动更新与回滚：

# 更新镜像（触发滚动更新）
kubectl set image deployment/web-app app=my-app:v2.0

# 查看更新状态
kubectl rollout status deployment/web-app

# 查看历史版本
kubectl rollout history deployment/web-app

# 回滚到上一版本
kubectl rollout undo deployment/web-app

# 回滚到指定版本
kubectl rollout undo deployment/web-app --to-revision=3

4.3 Service — 服务发现与负载均衡

Pod 的 IP 是动态的（重建后会变），Service 提供了一组稳定的访问入口，并通过标签选择器自动关联后端的 Pod。

四种 Service 类型：

# ClusterIP（默认）— 仅集群内可访问
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
    - port: 80           # Service 端口
      targetPort: 8080   # 容器端口

---
# NodePort — 通过节点 IP:端口 从外部访问
apiVersion: v1
kind: Service
metadata:
  name: my-service-nodeport
spec:
  type: NodePort
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080    # 节点端口（范围 30000-32767）

---
# LoadBalancer — 云厂商提供外部负载均衡器
apiVersion: v1
kind: Service
metadata:
  name: my-service-lb
spec:
  type: LoadBalancer
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 8080

在本地学习时访问 Service：

# Minikube
minikube service my-service-nodeport

# 或使用端口转发（通用方法）
kubectl port-forward svc/my-service 8080:80
# 然后访问 http://localhost:8080

4.4 Namespace — 资源隔离

Namespace 是集群内的逻辑隔离机制，适合在多团队或多环境（dev/staging/prod）共享同一集群时使用。

# 创建命名空间
kubectl create namespace dev
kubectl create namespace prod

# 在指定命名空间操作
kubectl get pods -n dev
kubectl apply -f deployment.yaml -n prod

# 设置默认命名空间（避免每次加 -n）
kubectl config set-context --current --namespace=dev

Kubernetes 有四个系统命名空间：kube-system（核心组件）、kube-public（公开资源）、kube-node-lease（节点心跳）、default（默认）。

4.5 ConfigMap 与 Secret — 配置管理

将配置与容器镜像解耦是重要的最佳实践。ConfigMap 存储明文配置，Secret 存储敏感数据。

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
  config.yaml: |
    database:
      host: db.example.com
      port: 5432

# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  # 值需要 base64 编码
  # echo -n "my-password" | base64  →  bXktcGFzc3dvcmQ=
  DB_PASSWORD: bXktcGFzc3dvcmQ=

在 Pod 中使用：

spec:
  containers:
    - name: app
      image: my-app:v1
      env:
        - name: APP_ENV
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: APP_ENV
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: DB_PASSWORD
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

第五章：存储

容器本身是无状态的，重启后数据丢失。Kubernetes 提供了一套完善的存储抽象来管理持久化数据。

5.1 存储架构

Pod → PersistentVolumeClaim (PVC) → PersistentVolume (PV) → 实际存储
     （"我需要 10G 存储"）          （"我有 100G 可用"）    （云盘/NFS/本地盘）

5.2 PersistentVolume 与 PersistentVolumeClaim

# pv.yaml — 管理员创建
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce           # 单节点读写
  storageClassName: standard
  hostPath:                   # 本地学习用 hostPath，生产环境用云盘
    path: /data/my-pv

---
# pvc.yaml — 开发者创建
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 5Gi

5.3 在 Pod 中使用持久化存储

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db
spec:
  replicas: 1                 # 有状态应用通常先跑 1 个副本
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: postgres
          image: postgres:16
          env:
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: password
          volumeMounts:
            - name: db-data
              mountPath: /var/lib/postgresql/data
      volumes:
        - name: db-data
          persistentVolumeClaim:
            claimName: my-pvc

5.4 StatefulSet — 有状态应用

对于数据库、消息队列等有状态应用，推荐使用 StatefulSet 而不是 Deployment。它保证 Pod 有稳定的网络标识（固定名称）和独立的持久化存储。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:8.0
          ports:
            - containerPort: 3306
          volumeMounts:
            - name: data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:         # 自动为每个 Pod 创建 PVC
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

Pod 名称会是 mysql-0、mysql-1、mysql-2，且各自拥有独立的 PVC。

第六章：网络与流量管理

6.1 网络模型基础

Kubernetes 的网络模型遵循一个核心原则：每个 Pod 拥有独立的 IP，任意两个 Pod 之间可以直接通信，无需 NAT。这通过 CNI 网络插件（如 Calico、Cilium、Flannel 等）实现。

集群内的 DNS 由 CoreDNS 提供。同一个 Namespace 内的 Pod 可以直接通过 <service-name> 访问其他 Service；跨 Namespace 则使用 <service-name>.<namespace>。

6.2 Ingress — 传统 HTTP 路由（正在被替代）

Ingress 是 Kubernetes 早期的七层（HTTP/HTTPS）流量管理方案。需要注意的是，2026 年 3 月，Kubernetes 社区正式宣布退役 Ingress NGINX Controller（最主流的 Ingress 实现），不再发布新版本和安全补丁。

虽然 Ingress API 本身仍可用，但社区强烈建议新用户使用 Gateway API。

6.3 Gateway API — 下一代流量管理（推荐）

Gateway API 是 Kubernetes SIG-Network 主导的新一代流量管理标准，在 v1.36 中已经完全成熟可用。它解决了 Ingress 表达能力不足的问题，支持请求头匹配、流量切分、gRPC 路由等高级特性。

Gateway API 引入了三层角色分离模型：

基础设施提供者（云厂商/集群管理员）
    ↓ 管理
GatewayClass（定义网关类型，如 nginx、envoy、istio）
    ↓
Gateway（网关实例，定义监听器和地址）
    ↓ 关联
HTTPRoute / GRPCRoute / TCPRoute（应用开发者定义路由规则）

安装 Gateway API CRD：

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml

示例：使用 Gateway API 暴露应用

# gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: infra
spec:
  gatewayClassName: nginx        # 需要先安装对应的控制器
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All              # 允许所有命名空间的路由关联

---
# httproute.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: default
spec:
  parentRefs:
    - name: my-gateway
      namespace: infra
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: frontend-service
          port: 80

Gateway API 相比 Ingress 的优势：

角色分离更清晰，集群管理员和应用开发者各管各的资源。
路由能力更丰富：支持基于 Header、QueryParam 的匹配，支持流量权重分配。
可扩展性强：不同实现（Nginx、Envoy、Istio 等）通过 GatewayClass 对接。
支持 TCP/UDP/gRPC，不再局限于 HTTP。

推荐的 Gateway API 实现包括 NGINX Gateway Fabric、Envoy Gateway、Istio 等。

第七章：工作负载进阶

7.1 Job 与 CronJob — 一次性任务

# job.yaml — 运行一次就结束
apiVersion: batch/v1
kind: Job
metadata:
  name: data-migration
spec:
  completions: 1
  backoffLimit: 3             # 最多重试 3 次
  template:
    spec:
      containers:
        - name: migrator
          image: my-migrator:v1
          command: ["python", "migrate.py"]
      restartPolicy: Never

---
# cronjob.yaml — 定时运行
apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup
spec:
  schedule: "0 2 * * *"       # 每天凌晨 2 点
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: my-backup:v1
          restartPolicy: OnFailure

v1.36 中 Job 的一个实用新特性（Beta）：Job 挂起时可变更容器资源。这意味着你可以在不重建 Job 的情况下调整 CPU/内存请求。

7.2 DaemonSet — 每节点守护进程

DaemonSet 确保每个节点（或满足条件的节点）上恰好运行一个 Pod 副本。常用于日志收集（Fluentd）、监控代理（Prometheus Node Exporter）、网络插件等。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
        - name: fluentd
          image: fluentd:v1.17
          volumeMounts:
            - name: varlog
              mountPath: /var/log
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

7.3 HorizontalPodAutoscaler — 自动扩缩容

HPA 根据 CPU/内存使用率或自定义指标自动调整 Deployment 的副本数。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # CPU 使用率超过 70% 时扩容
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

注意：使用 HPA 需要集群安装 Metrics Server。Minikube 可以通过 minikube addons enable metrics-server 启用。

第八章：RBAC — 权限控制

基于角色的访问控制（RBAC）是 Kubernetes 权限管理的标准方案，核心思路是：创建角色（Role），然后将角色绑定给用户或服务账号（ServiceAccount）。

# Role — 定义命名空间内的权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list"]

---
# RoleBinding — 将角色绑定到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: dev
subjects:
  - kind: User
    name: developer1
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

如果需要集群级别的权限，使用 ClusterRole 和 ClusterRoleBinding。原则是最小权限：只授予完成工作所需的最少权限。

第九章：Helm — 包管理器

Helm 是 Kubernetes 的包管理工具，类似于 Linux 的 apt/yum。它用模板化的方式（Chart）打包和部署应用，是生产环境管理复杂应用的标准方式。

9.1 安装 Helm

# Windows
winget install Helm.Helm

# 或通过 Chocolatey
choco install kubernetes-helm

# 验证
helm version

9.2 基本使用

# 添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# 搜索 Chart
helm search repo nginx

# 安装
helm install my-nginx bitnami/nginx

# 查看已安装的 Release
helm list

# 升级
helm upgrade my-nginx bitnami/nginx --set service.type=NodePort

# 回滚
helm rollback my-nginx 1

# 卸载
helm uninstall my-nginx

9.3 自定义 Chart

# 创建新 Chart
helm create my-chart

# 目录结构
# my-chart/
# ├── Chart.yaml          # 元信息
# ├── values.yaml         # 默认配置
# ├── templates/          # 模板文件
# │   ├── deployment.yaml
# │   ├── service.yaml
# │   └── ...
# └── charts/             # 依赖 Chart

# 自定义值安装
helm install my-app ./my-chart -f custom-values.yaml

# 渲染模板但不安装（调试用）
helm template my-app ./my-chart

第十章：监控与可观测性

一个生产级别的 Kubernetes 集群需要完善的可观测性体系。

10.1 推荐的监控栈

当前社区的主流方案是 Prometheus + Grafana 组合：

Prometheus：采集和存储指标数据（CPU、内存、自定义指标等）。
Grafana：可视化和告警。
kube-prometheus-stack：一键部署的 Helm Chart，包含 Prometheus Operator、Grafana、Alertmanager 以及预配置的 K8s 监控规则。

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace

10.2 日志方案

Kubernetes 原生的 kubectl logs 只能查看单个容器的日志。生产环境通常需要集中式日志系统：

EFK/ELK（Elasticsearch + Fluentd/Filebeat + Kibana）：成熟但较重。
Loki + Grafana：轻量级方案，与 Prometheus 生态集成良好，社区推荐度越来越高。

10.3 v1.36 新增的可观测性特性

v1.36 在可观测性方面有几个值得关注的新功能：

NodeLogQuery（GA）：可以直接通过 kubectl 查询节点日志，无需 SSH 到节点。
ComponentStatusz 和 ComponentFlagz（Beta）：提供 /statusz 和 /flagz 端点，方便排查控制平面组件的运行状态和启动参数。
基于 cgroup v2 的 PSI 指标：导出 CPU、内存和 I/O 的压力信息，可用于更精准的自动伸缩决策。

第十一章：安全最佳实践

11.1 容器安全

spec:
  containers:
    - name: app
      image: my-app:v1
      securityContext:
        runAsNonRoot: true              # 不以 root 用户运行
        readOnlyRootFilesystem: true    # 只读文件系统
        allowPrivilegeEscalation: false # 禁止提权
        capabilities:
          drop: ["ALL"]                 # 移除所有 Linux capabilities

11.2 网络策略

NetworkPolicy 控制 Pod 之间的网络通信，默认情况下 K8s 集群中所有 Pod 都可以互相通信。生产环境应使用 NetworkPolicy 限制为最小范围。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-only
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 8080

11.3 v1.36 安全新特性

Pod 用户命名空间（GA）：允许将容器内的 root 映射为宿主机上的非特权用户，显著增强隔离。
细粒度 Kubelet API 鉴权（GA）：替代宽泛的 nodes/proxy 权限，实现最小权限访问。
Service .spec.externalIPs 被弃用：因存在中间人攻击风险，计划于 v1.43 移除，建议迁移到 LoadBalancer 或 Gateway API。

第十二章：v1.36 重点新特性速览

以下是 v1.36 中对日常使用最有影响的特性总结：

已经 GA（可直接用于生产）

特性	说明
MutatingAdmissionPolicy	用 CEL 表达式定义资源变更逻辑，替代部分 Webhook
VolumeGroupSnapshot	为多个 PVC 创建一致性快照
OCI 制品作为 VolumeSource	直接从 OCI 仓库拉取数据挂载为卷
Pod 用户命名空间	增强容器安全隔离
NodeLogQuery	通过 kubectl 查询节点日志
DRA 管理员访问与优先级列表	增强 GPU 等硬件资源的管理能力

Beta（可在测试环境试用）

特性	说明
Job 挂起时变更资源	无需重建 Job 即可调整 CPU/内存
HPA 缩容到零	基于自定义指标将副本缩到 0（Alpha）
分离 kubectl 配置（.kuberc）	用户偏好与集群配置解耦
DRA 可分区设备	GPU 等硬件的细粒度共享
混合版本代理	优化滚动升级过程中的 API 兼容性

需要注意的变更

Ingress NGINX 控制器已退役：不再有安全更新，建议尽快迁移到 Gateway API。
gitRepo 卷插件已移除：使用 Init 容器或 git-sync 替代。
SELinux 卷标签行为变更（GA）：默认影响所有卷，特权与非特权 Pod 共享卷时需审计。

第十三章：学习路线与资源

官方与社区资源

官方文档：https://kubernetes.io/zh-cn/docs/ — 最权威的参考，有中文版本。
Kubernetes Playground：https://kubernetes.io/docs/tutorials/ — 官方交互式教程。
CKA/CKAD/CKS 认证：云原生计算基金会提供的官方认证，是检验学习成果的好方式。
CNCF 全景图：https://landscape.cncf.io — 了解整个云原生生态。

日常练习建议

学习 Kubernetes 最有效的方式是动手。建议的日常练习：

从 Dockerfile 开始，构建自己的应用镜像。
编写 Deployment + Service + ConfigMap，完整部署一个应用。
尝试滚动更新和回滚。
用 HPA 实现自动扩缩容，用 kubectl stress 或压测工具制造负载观察效果。
搭建 Prometheus + Grafana，观察自己应用的指标。
故意制造故障（删除 Pod、停止节点），观察 K8s 的自愈行为。

Kubernetes 学习指南