Kubernetes on 纪伟的个人博客

K8s 学习笔记（八）：排错与运维

Thu, 14 May 2026 10:00:00 +0800

写在前面

本文是 K8s 学习笔记系列的最后一篇，介绍生产环境的排错方法、监控告警和 Helm 包管理。前置知识：安全与 RBAC（第七篇）。

一、排错方法论

1.1 排错流程

1. 定位问题层级（应用 / K8s / 基础设施）
2. 查看 Pod 状态和事件
3. 查看容器日志
4. 进入容器排查
5. 查看相关资源状态（Service、Ingress、PVC 等）
6. 检查节点状态和资源

1.2 按症状排查

Pod 一直 Pending
  → kubectl describe pod 看 Events
  → 原因：资源不足、PVC 未绑定、镜像拉取失败

Pod CrashLoopBackOff
  → kubectl logs --previous 看崩溃日志
  → 原因：应用启动失败、健康检查失败、OOMKilled

Pod ImagePullBackOff
  → kubectl describe pod 看 Events
  → 原因：镜像名错误、仓库认证失败、网络不通

Service 无法访问
  → kubectl get endpoints 检查是否有后端
  → 原因：selector 不匹配、Pod 不 Ready、端口不对

Ingress 不通
  → kubectl describe ingress 看 Events
  → 原因：Ingress Controller 未安装、规则配置错误、DNS 未解析

Pod 间网络不通
  → 用 debug Pod 测试 DNS 和连通性
  → 原因：DNS 问题、NetworkPolicy 阻断、CNI 插件问题

1.3 排错命令速查

# Pod 排错
kubectl describe pod <pod>                       # 看 Events
kubectl logs <pod> -f --tail=100                 # 看日志
kubectl logs <pod> --previous                    # 看上次崩溃日志
kubectl exec -it <pod> -- sh                     # 进入容器
kubectl get events --sort-by=.lastTimestamp       # 看集群事件

# Service 排错
kubectl get endpoints <service>                 # 检查后端 Pod
kubectl describe svc <service>                  # 看 selector 和端口

# 节点排错
kubectl describe node <node>                    # 看条件和资源
kubectl top nodes                               # 看资源使用

# 网络排错
kubectl run debug --image=busybox --rm -it -- sh
# 在 debug Pod 中：
nslookup <service>                             # DNS 测试
wget -qO- http://<service>:<port>              # 连通性测试

二、监控

2.1 监控体系

Metrics Server    — K8s 内置指标（CPU/内存）
Prometheus        — 指标采集和存储
Grafana           — 可视化仪表盘
Alertmanager      — 告警通知

2.2 Metrics Server

# 安装
minikube addons enable metrics-server
# 或
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 使用
kubectl top nodes                  # 节点资源
kubectl top pods                    # Pod 资源
kubectl top pods -n dev             # 指定命名空间
kubectl top pods --sort-by=memory   # 按内存排序

2.3 Prometheus + Grafana

# 用 Helm 安装 kube-prometheus-stack（包含 Prometheus + Grafana + Alertmanager）
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

# 查看
kubectl get pods -n monitoring

# 访问 Grafana
kubectl port-forward svc/monitoring-grafana 3000:80 -n monitoring
# 浏览器访问 http://localhost:3000
# 默认账号：admin / prom-operator

2.4 关键监控指标

Pod 层面：
  CPU 使用率         → container_cpu_usage_seconds_total
  内存使用率         → container_memory_working_set_bytes
  重启次数           → kube_pod_container_status_restarts_total
  OOMKilled          → kube_pod_container_status_last_terminated_reason

节点层面：
  CPU 使用率         → node_cpu_seconds_total
  内存使用率         → node_memory_MemAvailable_bytes
  磁盘使用           → node_filesystem_avail_bytes
  网络流量           → node_network_transmit_bytes_total

应用层面：
  HTTP 请求量        → 自定义 metrics
  响应时间           → 自定义 metrics
  错误率             → 自定义 metrics

三、日志管理

3.1 日志架构

容器 stdout/stderr → 容器运行时收集 → kubelet 存储
                                        ↓
                              日志收集 Agent（Fluentd/Filebeat）
                                        ↓
                              日志存储（Elasticsearch / Loki）
                                        ↓
                              日志查询（Kibana / Grafana）

3.2 应用日志最佳实践

// 日志输出到 stdout/stderr（K8s 自动收集）
log.Println("处理请求", "path", r.URL.Path, "status", statusCode)

// 结构化日志（方便日志平台解析）
// 使用 JSON 格式
log.Printf(`{"time":"%s","level":"INFO","msg":"请求处理","path":"%s","status":%d}`,
    time.Now().Format(time.RFC3339), r.URL.Path, statusCode)

原则：
1. 日志输出到 stdout/stderr
2. 不写文件（或写文件也同步到 stdout）
3. 使用 JSON 格式（方便解析）
4. 包含 trace_id（方便链路追踪）

3.3 查看日志

# 单个 Pod
kubectl logs <pod> -f

# 多副本 Deployment 的所有 Pod
kubectl logs -l app=web-app --all-containers

# 指定时间段
kubectl logs <pod> --since=1h

# 多容器 Pod
kubectl logs <pod> -c <container>

# 之前的容器（崩溃后）
kubectl logs <pod> --previous

四、Helm 包管理

Helm 是 K8s 的包管理器，类似 apt/yum，简化应用的部署和管理。

4.1 安装 Helm

# Windows
winget install Helm.Helm

# macOS
brew install helm

# 验证
helm version

4.2 基本使用

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

# 搜索 Chart
helm search repo nginx
helm search repo nginx --versions    # 查看所有版本

# 安装
helm install my-nginx bitnami/nginx              # 默认配置
helm install my-nginx bitnami/nginx -n dev        # 指定命名空间
helm install my-nginx bitnami/nginx -f values.yaml  # 自定义配置

# 查看
helm list                    # 查看已安装的 Release
helm status my-nginx         # 查看 Release 状态
helm history my-nginx        # 查看历史版本

# 更新
helm upgrade my-nginx bitnami/nginx -f values.yaml

# 回滚
helm rollback my-nginx 1     # 回滚到版本1

# 卸载
helm uninstall my-nginx
helm uninstall my-nginx -n dev

4.3 自定义 values

# 查看 Chart 的默认配置
helm show values bitnami/nginx > values.yaml

# 编辑 values.yaml 后安装
helm install my-nginx bitnami/nginx -f values.yaml

常用 values 示例：

# values.yaml
replicaCount: 3

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

service:
  type: NodePort
  port: 80

ingress:
  enabled: true
  hostname: app.example.com
  tls: true
  tlsSecret: tls-secret

4.4 常用 Helm 仓库

1
2
3

bitnami             — https://charts.bitnami.com/bitnami
prometheus-community — https://prometheus-community.github.io/helm-charts
ingress-nginx       — https://kubernetes.github.io/ingress-nginx

4.5 常用应用安装

# Nginx Ingress Controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx --create-namespace

# Prometheus + Grafana
helm install monitoring prometheus-community/kube-prometheus-stack \
  -n monitoring --create-namespace

# Redis
helm install redis bitnami/redis -n dev

# MySQL
helm install mysql bitnami/mysql -n dev

五、CI/CD 集成

5.1 常用方案

GitLab CI + Helm       — 提交代码 → 构建镜像 → helm upgrade
GitHub Actions + kubectl — 推送到 main → 构建镜像 → kubectl apply
ArgoCD                 — GitOps 方式，监控 Git 仓库自动同步到集群
Jenkins + Helm         — 经典方案，适合复杂流水线

5.2 GitOps 模式（推荐）

1. 开发提交代码到 Git
2. CI 构建镜像并推送镜像仓库
3. 更新 K8s YAML 中的镜像版本
4. ArgoCD 检测到 Git 变更，自动同步到集群

优势：
  - 所有变更都有 Git 记录
  - 配置和代码一起管理
  - 回滚就是 git revert
  - 多环境管理清晰

5.3 开发者工作流

开发阶段：
  1. 本地开发（minikube 或 Docker Compose）
  2. 写好 K8s YAML（Deployment + Service + ConfigMap）
  3. 本地测试通过

部署阶段：
  1. 构建镜像推到仓库
  2. 更新 YAML 中的镜像版本
  3. kubectl apply 或 helm upgrade
  4. 验证部署结果

六、运维常用操作

6.1 集群维护

# 节点维护（驱逐 Pod + 标记不可调度）
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

# 维护完成后恢复
kubectl uncordon <node>

# 查看集群资源总量
kubectl top nodes
kubectl describe nodes | grep -A 5 "Allocated resources"

6.2 清理操作

# 清理 Completed 的 Pod
kubectl delete pods --field-selector=status.phase=Succeeded -A

# 清理 Evicted 的 Pod
kubectl get pods -A | grep Evicted | \
  awk '{print "kubectl delete pod "$2" -n "$1}' | sh

# 清理失败的 Job
kubectl delete jobs --field-selector status.successful!=1 -A

6.3 资源用量分析

# 查看所有 Deployment 的镜像版本和副本数
kubectl get deploy -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,IMAGE:.spec.template.spec.containers[0].image'

# 查看各命名空间的 Pod 数量
kubectl get pods -A --no-headers | awk '{print $1}' | sort | uniq -c | sort -rn

# 查看资源配额使用
kubectl describe resourcequota -n dev
kubectl describe limitrange -n dev

七、小结

本文学习了 K8s 的排错与运维：

排错方法论和常见问题排查
监控体系（Metrics Server、Prometheus、Grafana）
日志管理和最佳实践
Helm 包管理
CI/CD 集成和 GitOps
运维常用操作

到此 K8s 学习笔记系列全部完成。从集群搭建、Pod 管理、工作负载、网络、存储、调度、安全到运维，覆盖了 K8s 的核心知识。

K8s 学习笔记（七）：安全与 RBAC

Wed, 13 May 2026 10:00:00 +0800

写在前面

本文是 K8s 学习笔记系列的第七篇，介绍 K8s 的安全机制：Namespace 隔离、RBAC 权限控制、SecurityContext 和安全最佳实践。前置知识：调度与扩缩（第六篇）。

一、Namespace 隔离

Namespace 是 K8s 资源隔离的基本单位。

1.1 Namespace 的作用

资源隔离    — 不同团队/环境的资源互相不可见
权限控制    — RBAC 按 Namespace 授权
资源配额    — 限制每个 Namespace 的资源使用
命名隔离    — 不同 Namespace 中资源可以同名

Namespace 只隔离资源对象，不隔离网络（默认情况下 Pod 可以跨 Namespace 通信）。

1.2 Namespace 管理

# 查看所有 Namespace
kubectl get ns

# 创建
kubectl create ns dev
kubectl create ns staging
kubectl create ns prod

# 查看某个 Namespace 的所有资源
kubectl get all -n dev

# 在指定 Namespace 操作
kubectl apply -f deploy.yaml -n dev

1.3 环境划分示例

default       — 默认命名空间（别放正式资源）
dev           — 开发环境
staging       — 预发环境
prod          — 生产环境
kube-system   — 系统组件（kube-apiserver、CoreDNS 等）
monitoring    — 监控组件（Prometheus、Grafana）

1.4 ResourceQuota（资源配额）

限制 Namespace 的总资源使用：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "10"              # 总 CPU 上限
    requests.memory: "20Gi"         # 总内存上限
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"                      # 最大 Pod 数
    services: "20"                  # 最大 Service 数
    persistentvolumeclaims: "20"    # 最大 PVC 数

1.5 LimitRange（默认资源限制）

给 Namespace 中的 Pod 设置默认 resources：

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: dev
spec:
  limits:
  - max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    default:
      cpu: "500m"
      memory: "256Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    type: Container

二、RBAC 权限控制

RBAC（Role-Based Access Control）控制谁能在集群中做什么。

2.1 RBAC 核心概念

Role          — 角色，定义权限（Namespace 级别）
ClusterRole   — 集群角色，定义权限（集群级别）
RoleBinding   — 把角色绑定给用户/组（Namespace 级别）
ClusterRoleBinding — 把集群角色绑定给用户/组（集群级别）

2.2 Role 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-developer
  namespace: dev
rules:
- apiGroups: ["", "apps"]        # "" = core API, "apps" = Deployment 等
  resources: ["pods", "deployments", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]          # Secret 只读

2.3 RoleBinding 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-developer-binding
  namespace: dev
subjects:
- kind: User
  name: zhangsan                  # 绑定给用户
- kind: ServiceAccount
  name: dev-sa                    # 绑定给 ServiceAccount
roleRef:
  kind: Role
  name: dev-developer
  apiGroup: rbac.authorization.k8s.io

2.4 ClusterRole 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

2.5 常用 verbs

get       — 获取单个资源
list      — 列出资源
watch     — 监听资源变化
create    — 创建资源
update    — 更新资源
delete    — 删除资源
patch     — 部分更新
*         — 所有操作

2.6 常用 ClusterRole 绑定场景

# 给用户只读权限
kubectl create clusterrolebinding zhangsan-view \
  --clusterrole=view \
  --user=zhangsan

# 给用户 admin 权限（限于某个 Namespace）
kubectl create rolebinding zhangsan-admin \
  --clusterrole=admin \
  --user=zhangsan \
  --namespace=dev

三、ServiceAccount

ServiceAccount 是 Pod 访问 K8s API 的身份。

3.1 默认 ServiceAccount

每个 Namespace 都有一个默认的 ServiceAccount（default），Pod 默认使用它。

3.2 创建 ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: dev

3.3 Pod 指定 ServiceAccount

1
2
3

spec:
  serviceAccountName: app-sa     # 指定 ServiceAccount
  automountServiceAccountToken: true

3.4 应用场景

1
2
3

Pod 调用 K8s API   → 用 ServiceAccount + RBAC 授权
CI/CD 部署         → 用 ServiceAccount 的 kubeconfig
第三方集成         → 用 ServiceAccount 认证

四、SecurityContext

SecurityContext 控制 Pod 和容器的安全设置。

4.1 Pod 级别

spec:
  securityContext:
    runAsNonRoot: true           # 不允许以 root 运行
    runAsUser: 1000              # 以 UID 1000 运行
    fsGroup: 2000                # 文件系统组

4.2 容器级别

spec:
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false   # 不允许提权
      readOnlyRootFilesystem: true      # 只读根文件系统
      capabilities:
        drop: ["ALL"]                   # 去掉所有 Linux capabilities

4.3 安全最佳实践

# 安全的 Pod 配置
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

五、Secret 安全

5.1 Secret 风险

1
2
3

默认只是 base64 编码，不是加密
etcd 中明文存储（除非开启加密）
任何人有权限就能解码查看

5.2 安全措施

1. 开启 etcd 加密（EncryptionConfiguration）
2. 使用外部密钥管理（HashiCorp Vault、AWS Secrets Manager）
3. RBAC 限制 Secret 访问权限
4. 审计日志记录 Secret 访问

5.3 开启 Secret 加密

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-secret>
  - identity: {}

六、安全检查清单

Pod 安全：
  □ 不以 root 运行（runAsNonRoot: true）
  □ 只读文件系统（readOnlyRootFilesystem: true）
  □ 去掉 capabilities（drop ALL）
  □ 设置 resources limits（防止资源耗尽）

RBAC：
  □ 不用 cluster-admin 给普通用户
  □ 按 Namespace 和角色分配最小权限
  □ ServiceAccount 按需创建，不用 default

Secret：
  □ 敏感信息用 Secret 不用 ConfigMap
  □ 开启 etcd 加密
  □ RBAC 限制 Secret 访问

网络：
  □ 使用 NetworkPolicy 限制 Pod 间通信
  □ Ingress 配置 TLS
  □ 不暴露不必要的 NodePort

七、小结

本文学习了 K8s 的安全机制：

Namespace 隔离和资源配额
RBAC 权限控制（Role、ClusterRole、Binding）
ServiceAccount 身份管理
SecurityContext 容器安全
Secret 安全和加密
安全检查清单

下一篇将学习排错与运维：排错方法、监控告警和 Helm 包管理。

K8s 学习笔记（六）：调度与扩缩

Tue, 12 May 2026 10:00:00 +0800

写在前面

本文是 K8s 学习笔记系列的第六篇，介绍 Pod 调度机制和自动扩缩容：标签与选择器、nodeSelector、亲和性、污点与容忍、HPA。前置知识：配置与存储（第五篇）。

一、标签与选择器

标签（Label）是 K8s 最核心的组织机制，几乎所有资源都可以打标签。

1.1 标签规范

metadata:
  labels:
    app: web-app              # 应用名
    env: prod                 # 环境
    tier: frontend            # 层级
    version: v2.0             # 版本
    team: backend             # 团队

标签规则：
- 前缀可选：team.example.com/role=admin
- 值最多63字符
- 只能字母、数字、-、_、.
- 建议用统一的标签体系

1.2 标签操作

# 查看标签
kubectl get pods --show-labels
kubectl get nodes --show-labels

# 按标签筛选
kubectl get pods -l app=web-app
kubectl get pods -l 'env in (prod, staging)'
kubectl get pods -l 'env!=dev'
kubectl get pods -l 'version in (v1, v2),app=web-app'

# 添加/修改标签
kubectl label pod <pod-name> env=prod
kubectl label pod <pod-name> env=staging --overwrite

# 删除标签
kubectl label pod <pod-name> env-

# 给节点打标签
kubectl label node <node-name> disktype=ssd
kubectl label node <node-name> zone=cn-east-1

1.3 选择器在 YAML 中的使用

# Service 匹配 Pod
spec:
  selector:
    matchLabels:
      app: web-app

# Deployment 匹配 Pod
spec:
  selector:
    matchLabels:
      app: web-app
    matchExpressions:
    - key: env
      operator: In
      values: ["prod", "staging"]

二、Pod 调度

2.1 调度过程

1. 用户创建 Pod
2. kube-scheduler 监听到未调度的 Pod
3. 过滤：排除不满足条件的节点
4. 打分：对可用节点评分
5. 绑定：将 Pod 绑定到得分最高的节点

2.2 nodeSelector（最简单）

直接指定 Pod 调度到有特定标签的节点：

1
2

# 给节点打标签
kubectl label node node-1 disktype=ssd

1
2
3

spec:
  nodeSelector:
    disktype: ssd              # 只调度到有这个标签的节点

2.3 nodeAffinity（更灵活）

spec:
  affinity:
    nodeAffinity:
      # 必须满足（硬性要求）
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: zone
            operator: In
            values: ["cn-east-1", "cn-east-2"]
      # 尽量满足（软性偏好）
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 80             # 权重
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values: ["ssd"]

IgnoredDuringExecution 表示 Pod 已运行后，节点标签变化不会驱逐 Pod。

2.4 podAffinity / podAntiAffinity

控制 Pod 之间的亲和性（倾向在一起或分开）：

spec:
  affinity:
    # Pod 亲和：倾向调度到已有相同标签 Pod 的节点
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: cache          # 和 cache Pod 在同一节点
        topologyKey: kubernetes.io/hostname

    # Pod 反亲和：避免调度到已有相同 Pod 的节点（分散部署）
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: web-app      # 尽量分散到不同节点
          topologyKey: kubernetes.io/hostname

反亲和在生产中很常用：确保同一 Deployment 的副本分布在不同节点上，一个节点挂了不会影响全部实例。

三、污点与容忍

Taint（污点）让节点排斥 Pod，Toleration（容忍）让 Pod 接受污点。

3.1 节点污点

# 添加污点
kubectl taint nodes node-1 dedicated=gpu:NoSchedule      # 不调度新 Pod
kubectl taint nodes node-1 special=true:NoExecute        # 不调度且驱逐已有 Pod
kubectl taint nodes node-1 maintenance=true:NoSchedule

# 查看污点
kubectl describe node node-1 | grep Taints

# 删除污点
kubectl taint nodes node-1 dedicated=gpu:NoSchedule-

3.2 污点效果

1
2
3

NoSchedule      — 不调度新 Pod（已有的不受影响）
PreferNoSchedule — 尽量不调度（不是强制的）
NoExecute       — 不调度新 Pod + 驱逐已有的 Pod

3.3 Pod 容忍

spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

  # 容忍所有污点（DaemonSet 常见配置）
  - operator: "Exists"

  # 容忍 Master 节点污点
  - key: "node-role.kubernetes.io/control-plane"
    effect: "NoSchedule"

3.4 常见场景

GPU 节点        → 打 taint dedicated=gpu:NoSchedule，只有标记容忍的 Pod 能调度
Master 节点     → 默认有污点，只有系统组件有容忍
专用节点        → 打 taint 给特定业务，其他 Pod 不受影响
节点维护        → 打 taint NoExecute，驱逐 Pod

四、HPA 自动扩缩容

HPA（Horizontal Pod Autoscaler）根据指标自动调整 Pod 副本数。

4.1 基于 CPU 的 HPA

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% 就扩容

4.2 基于内存的 HPA

metrics:
- type: Resource
  resource:
    name: memory
    target:
      type: Utilization
      averageUtilization: 80

4.2 多指标组合

metrics:
- type: Resource
  resource:
    name: cpu
    target:
      type: Utilization
      averageUtilization: 70
- type: Resource
  resource:
    name: memory
    target:
      type: Utilization
      averageUtilization: 80

多指标时，HPA 取需要最多副本的指标。

4.3 命令行创建 HPA

# 快速创建
kubectl autoscale deployment web-app --min=2 --max=10 --cpu-percent=70

# 查看 HPA
kubectl get hpa

# 查看 HPA 详情
kubectl describe hpa web-app-hpa

4.4 HPA 工作原理

1. Metrics Server 采集 Pod 的 CPU/内存指标
2. HPA Controller 定期检查指标（默认15秒）
3. 计算目标副本数 = 当前副本数 × (当前指标值 / 目标值)
4. 调整 Deployment 的 replicas

4.5 安装 Metrics Server

# minikube
minikube addons enable metrics-server

# 通用安装
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 验证
kubectl top nodes
kubectl top pods

4.6 扩缩行为配置

spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0     # 扩容不等待
      policies:
      - type: Percent
        value: 100                       # 一次最多扩容 100%（翻倍）
        periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300    # 缩容等待5分钟
      policies:
      - type: Percent
        value: 10                        # 一次最多缩容 10%
        periodSeconds: 60

五、调度场景总结

指定节点       → nodeSelector
灵活调度       → nodeAffinity
Pod 分散       → podAntiAffinity
专用节点       → Taint + Toleration
自动扩缩容     → HPA

六、小结

本文学习了 K8s 的调度与扩缩：

标签与选择器
nodeSelector 和 nodeAffinity
podAffinity / podAntiAffinity
Taint 和 Toleration
HPA 自动扩缩容

下一篇将学习安全与 RBAC。

K8s 学习笔记（五）：配置与存储

Mon, 11 May 2026 10:00:00 +0800

写在前面

本文是 K8s 学习笔记系列的第五篇，介绍配置管理（ConfigMap、Secret）和存储（PV/PVC、StorageClass）。前置知识：服务发现与网络（第四篇）。

一、ConfigMap

ConfigMap 用于存储非敏感的配置数据，让配置和镜像解耦。

1.1 创建 ConfigMap

# 从字面量创建
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=APP_PORT=8080 \
  --from-literal=DB_HOST=mysql.prod

# 从文件创建
kubectl create configmap nginx-config --from-file=nginx.conf

# 从目录创建（每个文件变成一个 key）
kubectl create configmap app-config --from-file=./config/

# 从 YAML 创建
kubectl apply -f configmap.yaml

1.2 ConfigMap YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  # 键值对
  APP_ENV: "production"
  APP_PORT: "8080"
  DB_HOST: "mysql.prod"

  # 完整配置文件
  application.yml: |
    server:
      port: 8080
    spring:
      datasource:
        url: jdbc:mysql://mysql.prod:3306/mydb

1.3 在 Pod 中使用

方式1：环境变量

spec:
  containers:
  - name: app
    env:
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_ENV
    - name: DB_HOST
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: DB_HOST

    # 或者全部加载为环境变量
    envFrom:
    - configMapRef:
        name: app-config

方式2：挂载为文件

spec:
  containers:
  - name: app
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
      readOnly: true

  volumes:
  - name: config-volume
    configMap:
      name: app-config

挂载后文件结构：

/etc/config/
├── APP_ENV             # 内容：production
├── APP_PORT            # 内容：8080
├── DB_HOST             # 内容：mysql.prod
└── application.yml     # 内容：完整 YAML

方式3：挂载单个文件

volumes:
- name: config-volume
  configMap:
    name: app-config
    items:                      # 只挂载指定 key
    - key: application.yml
      path: application.yml

1.4 更新 ConfigMap

# 直接编辑
kubectl edit configmap app-config

# 更新后，挂载为文件的 Pod 会自动刷新（有延迟，约1分钟）
# 通过环境变量注入的不会自动更新，需要重启 Pod

二、Secret

Secret 用于存储敏感信息（密码、Token、证书），数据以 base64 编码存储。

Secret 只是编码不是加密，生产环境建议开启 EncryptionConfiguration 或用外部密钥管理（Vault）。

2.1 创建 Secret

# 从字面量创建
kubectl create secret generic db-secret \
  --from-literal=username=admin \
  --from-literal=password='P@ssw0rd'

# 从文件创建
kubectl create secret generic tls-secret \
  --from-file=tls.crt=./server.crt \
  --from-file=tls.key=./server.key

# 创建 Docker 仓库认证 Secret
kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=user \
  --docker-password=password

2.2 Secret YAML

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque                  # 通用类型
data:
  username: YWRtaW4=           # base64 编码的 "admin"
  password: UEBzc3cwcmQ=       # base64 编码的 "P@ssw0rd"

# 也可以用 stringData（明文，K8s 会自动编码）
stringData:
  username: admin
  password: P@ssw0rd

2.3 Secret 类型

Opaque                    — 通用（默认）
docker-registry           — Docker 仓库认证
tls                       — TLS 证书
basic-auth                — 基础认证
ssh-auth                  — SSH 认证
token                     — Token

2.4 在 Pod 中使用

# 环境变量
env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

# 挂载为文件
volumeMounts:
- name: secret-volume
  mountPath: /etc/secrets
  readOnly: true
volumes:
- name: secret-volume
  secret:
    secretName: db-secret

# 拉取私有镜像
spec:
  imagePullSecrets:
  - name: regcred
  containers:
  - name: app
    image: registry.example.com/my-app:1.0

2.5 查看 Secret 内容

# 查看列表
kubectl get secrets

# 查看详情（不显示内容）
kubectl describe secret db-secret

# 解码查看内容
kubectl get secret db-secret -o jsonpath='{.data.password}' | base64 --decode

三、Volume

Volume 解决容器数据持久化问题。容器重启后文件会丢失，Volume 让数据独立于容器生命周期。

3.1 Volume 类型

emptyDir     — 临时目录，Pod 删除后数据丢失（Pod 内容器共享）
hostPath     — 挂载宿主机目录（单节点，不适合多节点）
configMap    — 挂载 ConfigMap
secret       — 挂载 Secret
persistentVolumeClaim — 挂载持久化存储（推荐）

3.2 emptyDir

Pod 内容器共享临时目录，Pod 删除后数据丢失：

spec:
  containers:
  - name: app
    volumeMounts:
    - name: cache
      mountPath: /cache
  - name: sidecar
    volumeMounts:
    - name: cache
      mountPath: /cache
  volumes:
  - name: cache
    emptyDir: {}

3.3 hostPath

挂载宿主机目录（开发/测试用，不推荐生产）：

volumes:
- name: data
  hostPath:
    path: /data/app           # 宿主机路径
    type: DirectoryOrCreate

四、持久化存储（PV/PVC）

PV（PersistentVolume）是集群级别的存储资源，PVC（PersistentVolumeClaim）是用户对存储的申请。

4.1 存储架构

管理员创建 PV（或由 StorageClass 动态创建）
    ↓
用户创建 PVC（声明需要的存储大小和访问模式）
    ↓
K8s 绑定 PVC 到合适的 PV
    ↓
Pod 通过 PVC 使用存储

4.2 PV 示例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-10gi
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce              # 单节点读写
  persistentVolumeReclaimPolicy: Retain   # 释放后保留数据
  storageClassName: standard
  hostPath:                    # 本地存储（测试用）
    path: /data/pv-10gi

4.3 PVC 示例

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

4.4 在 Pod 中使用 PVC

spec:
  containers:
  - name: app
    volumeMounts:
    - name: data
      mountPath: /var/lib/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: app-data

4.5 访问模式

ReadWriteOnce（RWO）    — 单节点读写（最常用）
ReadOnlyMany（ROX）     — 多节点只读
ReadWriteMany（RWX）    — 多节点读写（需要存储后端支持）
ReadWriteOncePod（RWOP） — 单 Pod 读写（K8s 1.27+）

4.6 回收策略

1
2
3

Retain    — 保留数据，需要手动清理（生产推荐）
Delete    — 自动删除 PV 和底层存储
Recycle   — 已废弃，用 Delete 替代

五、StorageClass

StorageClass 定义存储类型，支持动态创建 PV。

5.1 StorageClass 示例

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs    # 存储提供者
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

5.2 PVC 动态分配

# 不需要手动创建 PV，StorageClass 自动创建
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-data
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: fast-ssd     # 指定 StorageClass
  resources:
    requests:
      storage: 10Gi

5.3 minikube 的默认存储

# minikube 自带 standard StorageClass
kubectl get storageclass
# NAME                 PROVISIONER                RECLAIMPOLICY
# standard (default)   k8s.io/minikube-hostpath   Delete

# 创建 PVC 后自动创建 PV
kubectl apply -f pvc.yaml
kubectl get pv          # 自动创建的 PV
kubectl get pvc         # PVC 自动绑定

六、StatefulSet + PVC 模式

StatefulSet 配合 volumeClaimTemplates，每个 Pod 自动获得独立的持久化存储：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  template:
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: standard
      resources:
        requests:
          storage: 10Gi

自动创建的 PVC：
mysql-data-mysql-0   → mysql-0 的存储
mysql-data-mysql-1   → mysql-1 的存储
mysql-data-mysql-2   → mysql-2 的存储

Pod 重建后，PVC 不会删除，Pod 自动绑定回原来的 PVC

七、开发者视角：配置管理最佳实践

7.1 配置分层

环境变量        → 非敏感配置（APP_ENV、APP_PORT）
ConfigMap      → 配置文件、环境变量（不同环境不同 ConfigMap）
Secret         → 密码、Token、证书
PVC            → 需要持久化的数据

7.2 应用适配

func main() {
    // 从环境变量读取配置
    dbHost := os.Getenv("DB_HOST")
    dbPassword := os.Getenv("DB_PASSWORD")
    
    // 本地开发用 .env 文件，K8s 用 ConfigMap/Secret 注入
    // 代码不需要感知配置来源
}

7.3 不同环境管理

dev 环境配置   → app-config-dev
staging 配置  → app-config-staging
prod 配置     → app-config-prod

部署时通过 -n 或 -f 指定对应的 ConfigMap

八、小结

本文学习了 K8s 的配置与存储：

ConfigMap：非敏感配置管理
Secret：敏感信息管理
Volume：容器存储
PV/PVC：持久化存储
StorageClass：动态存储分配
StatefulSet + PVC 模式
配置管理最佳实践

下一篇将学习调度与扩缩：标签选择器、节点亲和性和 HPA。

K8s 学习笔记（四）：服务发现与网络

Sun, 10 May 2026 10:00:00 +0800

写在前面

本文是 K8s 学习笔记系列的第四篇，介绍 K8s 的服务发现和网络机制：Service、Ingress 和 DNS。前置知识：工作负载管理（第三篇）。

一、Service 概述

Pod 的 IP 是不固定的（重启后会变），Service 提供稳定的访问入口。

`1`	`客户端 → Service（固定 IP + 固定 DNS）→ Pod（通过标签选择器自动转发）`

1.1 Service 工作原理

1. Service 通过 selector 匹配 Pod 的标签
2. kube-proxy 在每个节点上配置转发规则
3. 客户端访问 Service IP，流量被转发到后端 Pod
4. Pod 变化时，Service 自动更新后端列表（Endpoints）

二、Service 类型

2.1 ClusterIP（默认）

集群内部访问，外部不可达。

apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  type: ClusterIP              # 默认值，可省略
  selector:
    app: web-app
  ports:
  - port: 80                   # Service 端口
    targetPort: 8080            # Pod 端口

集群内访问方式：
- Service 名称：http://web-app:80
- Service IP：http://10.100.200.50:80
- 完整 DNS：http://web-app.default.svc.cluster.local:80

2.2 NodePort

通过节点端口暴露服务，外部可以通过 节点IP:端口 访问。

apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  type: NodePort
  selector:
    app: web-app
  ports:
  - port: 80                   # Service 端口
    targetPort: 8080            # Pod 端口
    nodePort: 30080             # 节点端口（30000-32767，可省略自动分配）

1
2

外部访问方式：
- http://<任意节点IP>:30080

NodePort 适合测试和小规模使用，生产环境一般用 Ingress 或 LoadBalancer。

2.3 LoadBalancer

云厂商提供的负载均衡器（AWS ELB、GCP LB 等）。

apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  type: LoadBalancer
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080

本地环境（minikube）没有真正的 LoadBalancer。可以用 minikube tunnel 模拟。

2.4 ExternalName

将 Service 映射到外部 DNS 名称，不创建 Endpoints。

apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  type: ExternalName
  externalName: db.example.com   # 外部数据库地址

1
2

集群内访问：mysql://external-db:3306
实际解析到：mysql://db.example.com:3306

三、Headless Service

不分配 ClusterIP，直接返回后端 Pod 的 IP。常配合 StatefulSet 使用。

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None              # Headless
  selector:
    app: mysql
  ports:
  - port: 3306

DNS 解析结果：
mysql-0.mysql.default.svc.cluster.local → Pod-0 的 IP
mysql-1.mysql.default.svc.cluster.local → Pod-1 的 IP
mysql-2.mysql.default.svc.cluster.local → Pod-2 的 IP

StatefulSet 的每个 Pod 有固定的 DNS 名称，适合需要知道具体连接哪个实例的场景（如 MySQL 主从）。

四、Endpoints

Endpoints 是 Service 和 Pod 之间的桥梁。

# 查看 Service 对应的 Endpoints
kubectl get endpoints web-app
# NAME      ENDPOINTS                                      AGE
# web-app   10.244.1.5:8080,10.244.2.3:8080,10.244.3.7:8080

# Service 没有 selector 时，需要手动创建 Endpoints
# 用于代理集群外部的服务

手动 Endpoints 示例（代理外部服务）：

# Service（不指定 selector）
apiVersion: v1
kind: Service
metadata:
  name: external-api
spec:
  ports:
  - port: 80
    targetPort: 80
---
# 手动指定 Endpoints
apiVersion: v1
kind: Endpoints
metadata:
  name: external-api            # 和 Service 同名
subsets:
- addresses:
  - ip: 192.168.1.100           # 外部服务 IP
  ports:
  - port: 80

五、Ingress

Ingress 是 K8s 的 HTTP 路由层，类似 Nginx 反向代理，根据域名和路径转发到不同 Service。

5.1 为什么需要 Ingress

没有 Ingress：
  每个 Service 都需要 NodePort/LoadBalancer
  端口管理混乱，无法按域名路由

有 Ingress：
  只需要一个入口（LoadBalancer 或 NodePort）
  按域名和路径路由到不同 Service
  支持 TLS 证书

5.2 Ingress 示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx       # 指定 Ingress Controller
  rules:
  - host: app.example.com       # 域名
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app       # 转发到这个 Service
            port:
              number: 80

  - host: api.example.com       # 另一个域名
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

5.3 路径路由

rules:
- host: app.example.com
  http:
    paths:
    - path: /api
      pathType: Prefix
      backend:
        service:
          name: api-service
          port:
            number: 80
    - path: /static
      pathType: Prefix
      backend:
        service:
          name: static-service
          port:
            number: 80
    - path: /
      pathType: Prefix
      backend:
        service:
          name: web-app
          port:
            number: 80

5.4 TLS 配置

spec:
  tls:
  - hosts:
    - app.example.com
    secretName: tls-secret      # 包含 TLS 证书的 Secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app
            port:
              number: 80

5.5 安装 Ingress Controller

# minikube 启用 Ingress 插件
minikube addons enable ingress

# 验证 Ingress Controller
kubectl get pods -n ingress-nginx

六、DNS

K8s 集群内置 DNS 服务（CoreDNS），Pod 自动配置 DNS 解析。

6.1 DNS 命名规则

<service-name>                          # 同命名空间
<service-name>.<namespace>              # 跨命名空间
<service-name>.<namespace>.svc          # 完整写法
<service-name>.<namespace>.svc.cluster.local  # 完整 FQDN

6.2 跨命名空间访问

# 在 dev 命名空间访问 prod 命名空间的 Service
mysql://mysql.prod.svc.cluster.local:3306

# 简写
mysql://mysql.prod:3306

6.3 DNS 调试

# 启动调试 Pod
kubectl run debug --image=busybox --rm -it --restart=Never -- sh

# 在调试 Pod 中
nslookup web-app                          # 同命名空间
nslookup web-app.default.svc.cluster.local # 完整域名
nslookup web-app.prod                      # 跨命名空间

# 查看Pod 的 DNS 配置
cat /etc/resolv.conf

七、网络策略

NetworkPolicy 控制 Pod 之间的网络访问（默认全部互通）。

7.1 网络策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: api-server        # 策略应用到这些 Pod
  policyTypes:
  - Ingress                  # 入站规则
  ingress:
  - from:
    - podSelector:            # 只允许这些 Pod 访问
        matchLabels:
          app: web-app
    ports:
    - port: 8080
      protocol: TCP

7.2 常见策略

# 拒绝所有入站（默认拒绝）
spec:
  podSelector: {}
  policyTypes:
  - Ingress

# 允许同命名空间访问
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

# 允许指定命名空间访问
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          env: dev

NetworkPolicy 需要网络插件支持（Calico、Cilium 等），minikube 默认不支持。

八、开发者视角：服务接入

8.1 微服务间的调用方式

1
2
3

// 不要硬编码 IP，用 Service 名称
resp, err := http.Get("http://user-service:8080/api/users")
resp, err := http.Get("http://order-service.prod.svc.cluster.local:8080/api/orders")

8.2 服务接入检查清单

1. Service selector 是否匹配 Pod 的 labels？
   → kubectl get endpoints <service> 检查是否有后端

2. 端口是否正确？
   → Service port → targetPort → containerPort 要对应

3. Pod 是否 Ready？
   → readinessProbe 没通过的 Pod 不会接收流量

4. 跨命名空间是否用了完整 DNS？
   → 用 <service>.<namespace> 格式

5. 外部访问是否配置了 Ingress？
   → 检查 Ingress 规则和域名解析

九、小结

本文学习了 K8s 的服务发现与网络：

Service 四种类型（ClusterIP、NodePort、LoadBalancer、ExternalName）
Headless Service 和 StatefulSet 的配合
Endpoints 和外部服务代理
Ingress HTTP 路由和 TLS
DNS 命名规则和跨命名空间访问
NetworkPolicy 网络策略
开发者视角的服务接入

下一篇将学习配置与存储：ConfigMap、Secret、PV/PVC。

K8s 学习笔记（三）：工作负载管理

Sat, 09 May 2026 10:00:00 +0800

写在前面

本文是 K8s 学习笔记系列的第三篇，介绍 K8s 的工作负载管理：Deployment、StatefulSet、DaemonSet、Job 和 CronJob。前置知识：Pod 与容器管理（第二篇）。

一、Deployment

Deployment 是最常用的工作负载，管理无状态应用（Web 服务、API 等）。

1.1 Deployment 完整示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3                       # 副本数
  selector:
    matchLabels:
      app: web-app                  # 匹配 Pod 标签
  strategy:
    type: RollingUpdate             # 滚动更新策略
    rollingUpdate:
      maxSurge: 1                   # 更新时最多多出1个 Pod
      maxUnavailable: 0             # 更新时允许0个不可用
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: my-app:v1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

1.2 滚动更新

Deployment 更新镜像时会自动滚动更新：

# 方式1：set image
kubectl set image deployment/web-app web-app=my-app:v2.0

# 方式2：edit 直接编辑
kubectl edit deployment web-app

# 方式3：apply 新的 YAML
kubectl apply -f deployment-v2.yaml

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

# 查看更新历史
kubectl rollout history deployment/web-app

1.3 回滚

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

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

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

1.4 滚动更新策略

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1         # 更新时额外创建的 Pod 数（可以是数字或百分比）
      maxUnavailable: 0    # 更新时允许不可用的 Pod 数

1
2

maxSurge: 1, maxUnavailable: 0  → 先起新 Pod，再删旧 Pod（最安全，需要多余资源）
maxSurge: 0, maxUnavailable: 1  → 先删旧 Pod，再起新 Pod（省资源，有短暂不可用）

1.5 扩缩容

# 手动扩缩容
kubectl scale deployment web-app --replicas=5
kubectl scale deployment web-app --replicas=2

# 基于指标自动扩缩（HPA）
kubectl autoscale deployment web-app --min=2 --max=10 --cpu-percent=70

二、StatefulSet

StatefulSet 用于有状态应用（数据库、消息队列等），提供稳定的标识和持久化存储。

2.1 和 Deployment 的区别

Deployment：
- Pod 名随机（web-app-7854ff8879-abcde）
- Pod IP 不固定
- 没有稳定的持久化标识
- 适合无状态应用

StatefulSet：
- Pod 名有序（mysql-0, mysql-1, mysql-2）
- 每个 Pod 有稳定的网络标识
- 每个 Pod 有独立的持久化存储
- 适合有状态应用

2.2 StatefulSet 示例

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql              # 关联的 Headless Service
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        ports:
        - containerPort: 3306
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:           # 每个 Pod 独立的 PVC
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

2.3 Headless Service

StatefulSet 通常配合 Headless Service 使用：

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None                # Headless：不分配 ClusterIP
  selector:
    app: mysql
  ports:
  - port: 3306

Headless Service 让每个 Pod 有固定的 DNS 名称：mysql-0.mysql.default.svc.cluster.local

三、DaemonSet

DaemonSet 确保每个节点上运行一个 Pod 副本，常用于日志收集、监控、网络插件。

3.1 DaemonSet 示例

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
  labels:
    app: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      tolerations:                # 容忍 Master 节点的污点
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluentd:latest
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log          # 挂载宿主机日志目录

3.2 常见使用场景

日志收集    — Fluentd、Filebeat
监控 Agent — Prometheus Node Exporter
网络插件    — Calico、Flannel
存储插件    — CSI Driver

四、Job

Job 运行一次性任务，完成后退出。

4.1 Job 示例

apiVersion: batch/v1
kind: Job
metadata:
  name: data-migration
spec:
  completions: 1                  # 需要1次成功完成
  parallelism: 1                  # 并行数
  backoffLimit: 3                 # 失败重试次数
  activeDeadlineSeconds: 300      # 最长运行时间（秒）
  template:
    spec:
      restartPolicy: Never        # Job 不能用 Always
      containers:
      - name: migrate
        image: my-app:latest
        command: ["python", "migrate.py"]

4.2 批处理 Job

# 并行处理多个任务
spec:
  completions: 10                 # 需要成功10次
  parallelism: 3                  # 3个 Pod 并行执行

五、CronJob

CronJob 按时间计划运行 Job。

5.1 CronJob 示例

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup
spec:
  schedule: "0 2 * * *"           # 每天凌晨2点（cron 格式）
  concurrencyPolicy: Forbid       # 禁止并发执行
  successfulJobsHistoryLimit: 3   # 保留3个成功记录
  failedJobsHistoryLimit: 1       # 保留1个失败记录
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup
            image: my-app:latest
            command: ["sh", "-c", "pg_dump ... | gzip > /backup/db.sql.gz"]

5.2 Cron 格式

┌──────── 分钟 (0-59)
│ ┌────── 小时 (0-23)
│ │ ┌──── 日 (1-31)
│ │ │ ┌── 月 (1-12)
│ │ │ │ ┌ 星期 (0-6, 0=周日)
│ │ │ │ │
* * * * *

"*/5 * * * *"     → 每5分钟
"0 * * * *"        → 每小时整点
"0 2 * * *"        → 每天凌晨2点
"0 0 * * 1"        → 每周一零点
"0 0 1 * *"        → 每月1号零点

5.3 手动触发 CronJob

`1`	`kubectl create job --from=cronjob/backup backup-manual`

六、工作负载选型

Web 服务 / API        → Deployment
数据库 / 消息队列      → StatefulSet
日志 / 监控 Agent     → DaemonSet
数据迁移 / 批处理      → Job
定时备份 / 报表        → CronJob

七、小结

本文学习了 K8s 的工作负载管理：

Deployment：无状态应用、滚动更新、回滚
StatefulSet：有状态应用、稳定的网络标识和存储
DaemonSet：每个节点运行一个 Pod
Job：一次性任务
CronJob：定时任务
工作负载选型

下一篇将学习服务发现与网络：Service、Ingress 和 DNS。

K8s 学习笔记（二）：Pod 与容器管理

Fri, 08 May 2026 10:00:00 +0800

写在前面

本文是 K8s 学习笔记系列的第二篇，深入 Pod 的生命周期、多容器模式、健康检查和资源限制。前置知识：集群搭建和基本操作（第一篇）。

一、Pod 基础

1.1 什么是 Pod

Pod 是 K8s 最小的调度单元，包含一个或多个容器，共享网络和存储。

Pod
├── 容器1（应用容器）
├── 容器2（Sidecar）
├── 共享网络（同一个 IP，localhost 互通）
├── 共享存储（Volume）
└── 共享配置（环境变量、ConfigMap）

为什么不直接调度容器？因为有些容器需要紧密协作（如应用 + 日志收集），把它们放在一个 Pod 里共享网络和存储。

1.2 Pod YAML 详解

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
    env: prod
spec:
  containers:
  - name: app
    image: my-app:1.0
    ports:
    - containerPort: 8080
    env:
    - name: APP_ENV
      value: "production"
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "500m"
  restartPolicy: Always

1.3 Pod 生命周期

创建 Pod → 调度到节点 → 拉取镜像 → 启动容器 → 运行中
                                                      ↓
                                              崩溃/健康检查失败
                                                      ↓
                                                   重启容器

Pod 的 phase（阶段）：

Pending    — 等待调度或拉取镜像
Running    — 至少一个容器在运行
Succeeded  — 所有容器正常退出（不会重启）
Failed     — 至少一个容器异常退出
Unknown    — 无法获取状态

1.4 容器重启策略

spec:
  restartPolicy: Always     # 总是重启（默认，适合长期运行的服务）
  restartPolicy: OnFailure  # 只在失败时重启（适合 Job）
  restartPolicy: Never      # 从不重启

二、多容器模式

2.1 Sidecar（边车模式）

主容器 + 辅助容器，最常用的模式：

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
  - name: app                    # 主容器：业务应用
    image: my-app:1.0
    volumeMounts:
    - name: logs
      mountPath: /var/log/app

  - name: log-collector          # Sidecar：日志收集
    image: busybox
    command: ["sh", "-c", "tail -f /var/log/app/*.log"]
    volumeMounts:
    - name: logs
      mountPath: /var/log/app

  volumes:
  - name: logs
    emptyDir: {}                  # 共享的临时目录

2.2 常见多容器场景

Sidecar     — 日志收集、代理（如 Envoy/Istio）
Ambassador  — 代理外部服务连接
Adapter     — 标准化输出（如监控指标转换）
Init 容器   — 启动前执行初始化任务

2.3 Init 容器

在主容器启动前执行，完成后退出：

spec:
  initContainers:
  - name: init-db
    image: busybox
    command: ["sh", "-c", "until nslookup mysql-service; do echo waiting; sleep 2; done"]
    # 等待数据库服务可用后再启动主容器

  containers:
  - name: app
    image: my-app:1.0

Init 容器按顺序执行，全部成功后才开始主容器。任何一个失败，Pod 都会重启。

三、健康检查

K8s 通过探针（Probe）检查容器健康状态。

3.1 三种探针

1
2
3

livenessProbe   — 存活检查：失败则重启容器
readinessProbe  — 就绪检查：失败则从 Service 摘除流量
startupProbe    — 启动检查：先等这个通过，再执行上面两个

3.2 探针配置方式

spec:
  containers:
  - name: app
    image: my-app:1.0

    # 存活检查：挂了就重启
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10   # 容器启动后等10秒开始检查
      periodSeconds: 10         # 每10秒检查一次
      failureThreshold: 3       # 连续失败3次才判定不健康

    # 就绪检查：没准备好就不接收流量
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

    # 启动检查：慢启动应用用这个（避免被 liveness 杀掉）
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30      # 允许失败30次
      periodSeconds: 10         # 最长等 30*10=300秒

3.3 探针类型

# HTTP GET（最常用）
httpGet:
  path: /health
  port: 8080

# TCP 检查（适合非 HTTP 服务）
tcpSocket:
  port: 3306

# 执行命令（适合自定义检查）
exec:
  command:
  - cat
  - /tmp/healthy

3.4 探针配置建议

Web 服务       → httpGet + liveness + readiness
数据库          → tcpSocket + readiness
慢启动应用      → startupProbe + liveness + readiness
健康检查接口    → 返回 200 表示健康，返回 500 或超时表示不健康

四、资源限制

4.1 requests 和 limits

resources:
  requests:           # 调度依据：保证最少有这么多资源
    memory: "128Mi"
    cpu: "100m"       # 100m = 0.1 核
  limits:             # 上限：最多用这么多，超过会被限制或杀掉
    memory: "256Mi"
    cpu: "500m"       # 500m = 0.5 核

requests  — 调度器用来决定 Pod 放在哪个节点
limits    — 运行时的硬上限

CPU 超限  → 被限流（throttled），不会杀容器
内存超限  → 被杀掉（OOMKilled）

4.2 CPU 单位

1
2
3

1      = 1 核 CPU
500m   = 0.5 核（500 millicores）
100m   = 0.1 核

4.3 内存单位

1
2
3

Mi = Mebibytes（1024 KiB，K8s 中常用）
Gi = Gibibytes（1024 Mi）
M  = Megabytes（1000 KB，不推荐用）

4.4 QoS 等级

根据 requests 和 limits 的设置，Pod 分为三个等级：

1
2
3

Guaranteed  — requests = limits（最高优先级，最后被杀）
Burstable   — 设置了 requests 但不等于 limits
BestEffort  — 没设置 requests 和 limits（最先被杀）

建议生产环境所有 Pod 都设置 requests 和 limits，保证 Guaranteed 或 Burstable。

4.5 LimitRange（默认资源限制）

给命名空间设置默认值，防止忘记配置：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - default:               # 默认 limits
      cpu: "500m"
      memory: "256Mi"
    defaultRequest:         # 默认 requests
      cpu: "100m"
      memory: "128Mi"
    type: Container

五、环境变量与配置注入

5.1 直接定义

env:
- name: APP_ENV
  value: "production"
- name: APP_PORT
  value: "8080"

5.2 从 ConfigMap 引用

env:
- name: DB_HOST
  valueFrom:
    configMapKeyRef:
      name: app-config        # ConfigMap 名
      key: database_host      # ConfigMap 中的 key

5.3 从 Secret 引用

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret         # Secret 名
      key: password           # Secret 中的 key

5.4 挂载为文件

spec:
  containers:
  - name: app
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
      readOnly: true

  volumes:
  - name: config-volume
    configMap:
      name: app-config

六、Pod 排错

6.1 常见问题速查

Pending           → 资源不足，kubectl describe pod 看 Events
CrashLoopBackOff  → 容器启动后崩溃，kubectl logs --previous 看上次日志
ImagePullBackOff  → 镜像拉取失败，检查镜像名和仓库权限
OOMKilled         → 内存超限，增大 limits.memory
Completed         → 容器执行完退出了，正常（Job）或命令写错
ContainerCreating → 一直在创建，检查镜像拉取和挂载

6.2 排查步骤

# 1. 查看 Pod 状态
kubectl get pods -o wide

# 2. 查看 Pod 详情和事件
kubectl describe pod <pod-name>

# 3. 查看容器日志
kubectl logs <pod-name>
kubectl logs <pod-name> --previous          # 上次崩溃的日志
kubectl logs <pod-name> -c <container>      # 指定容器

# 4. 进入容器排查
kubectl exec -it <pod-name> -- sh

# 5. 查看资源使用
kubectl top pods

七、小结

本文学习了 Pod 的核心知识：

Pod 的概念和生命周期
多容器模式（Sidecar、Init 容器）
健康检查（liveness、readiness、startup 探针）
资源限制（requests/limits、QoS）
环境变量与配置注入
Pod 常见问题排查

下一篇将学习工作负载管理：Deployment 滚动更新、StatefulSet 和 DaemonSet。

K8s 学习笔记（一）：入门与集群搭建

Thu, 07 May 2026 10:00:00 +0800

写在前面

这是 Kubernetes 学习笔记系列的第一篇，介绍 K8s 的核心概念和架构，并带你搭建本地学习环境。读完本文你将理解 K8s 是什么、为什么需要它，并能独立部署一个应用到集群中。

本系列适合有后端开发经验、刚开始学 K8s 的开发者。

一、什么是 Kubernetes

1.1 容器编排的痛点

用 Docker 跑一两个容器很简单，但生产环境会面临：

- 容器挂了怎么自动重启？
- 怎么滚动更新不停服？
- 怎么自动扩容应对流量高峰？
- 多个容器怎么互相发现和通信？
- 怎么管理配置和密钥？
- 怎么保证资源分配和隔离？

Kubernetes（简称 K8s）就是解决这些问题的容器编排平台。

1.2 核心概念

Cluster  — 集群，一组节点的集合
Node     — 节点，集群中的一台机器（物理机或虚拟机）
Pod      — K8s 最小调度单元，包含一个或多个容器
Service  — 为一组 Pod 提供稳定的访问入口
Deployment — 管理 Pod 的副本数、更新策略
Namespace — 资源隔离的逻辑分区

1.3 架构概览

Master 节点（控制面）：
├── kube-apiserver     — API 入口，所有操作都经过它
├── etcd               — 存储集群状态数据
├── kube-scheduler     — 负责把 Pod 调度到合适的节点
├── kube-controller-manager — 控制器（Deployment、ReplicaSet 等）
└── cloud-controller-manager — 云厂商相关控制器

Worker 节点（数据面）：
├── kubelet            — 管理节点上的 Pod 生命周期
├── kube-proxy         — 负责网络规则和 Service 转发
└── Container Runtime  — 容器运行时（containerd、Docker）

开发者主要和 kube-apiserver 交互（通过 kubectl），不需要直接操作其他组件。

二、搭建本地环境

学习 K8s 不需要真实集群，本地工具足够。

2.1 方案对比

minikube  — 最成熟，功能全，推荐初学者
kind      — 用 Docker 容器模拟节点，启动快
k3s       — 轻量级 K8s，适合边缘计算和本地
Docker Desktop — 自带 K8s，Windows/Mac 一键开启

2.2 安装 minikube

# Windows（用 winget）
winget install Kubernetes.minikube

# macOS
brew install minikube

# Linux
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

2.3 启动集群

# 启动（默认用 Docker 驱动）
minikube start

# 指定 K8s 版本
minikube start --kubernetes-version=v1.30.0

# 查看集群状态
minikube status

# 查看集群信息
kubectl cluster-info

# 验证节点
kubectl get nodes
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   60s   v1.30.0

2.4 常用 minikube 命令

minikube start          # 启动集群
minikube stop           # 停止集群（不删除）
minikube delete         # 删除集群
minikube dashboard      # 打开 Web 控制台
minikube ssh            # SSH 进入节点
minikube addons list    # 查看可用插件
minikube addons enable metrics-server  # 启用指标服务

2.5 安装 kubectl

# Windows
winget install Kubernetes.kubectl

# macOS
brew install kubectl

# 验证
kubectl version --client

minikube 启动后会自动配置 kubectl，可以直接使用。

三、第一个应用部署

3.1 部署一个 Nginx

# 创建 Deployment
kubectl create deployment nginx --image=nginx:latest

# 查看 Deployment
kubectl get deployments
# NAME    READY   UP-TO-DATE   AVAILABLE   AGE
# nginx   1/1     1            1           30s

# 查看 Pod
kubectl get pods
# NAME                     READY   STATUS    RESTARTS   AGE
# nginx-7854ff8879-abcde   1/1     Running   0          30s

# 查看 Pod 详情
kubectl describe pod <pod-name>

3.2 暴露服务

# 创建 Service（NodePort 类型，允许外部访问）
kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort

# 查看 Service
kubectl get services
# NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
# kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        5m
# nginx        NodePort    10.100.200.50   <none>        80:31234/TCP   10s

# minikube 直接打开浏览器访问
minikube service nginx

3.3 扩容

# 扩展到 3 个副本
kubectl scale deployment nginx --replicas=3

# 查看 Pod（变成 3 个）
kubectl get pods
# NAME                     READY   STATUS    RESTARTS   AGE
# nginx-7854ff8879-abcde   1/1     Running   0          3m
# nginx-7854ff8879-fghij   1/1     Running   0          10s
# nginx-7854ff8879-klmno   1/1     Running   0          10s

3.4 清理

1
2
3

# 删除 Service 和 Deployment
kubectl delete service nginx
kubectl delete deployment nginx

四、用 YAML 部署

命令行操作适合临时测试，正式环境都用 YAML 文件。

4.1 Deployment YAML

创建 nginx-deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"

4.2 Service YAML

创建 nginx-service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx          # 匹配 Pod 的标签
  ports:
  - port: 80            # Service 端口
    targetPort: 80       # Pod 端口
  type: ClusterIP       # 集群内部访问

4.3 应用 YAML

# 创建/更新资源
kubectl apply -f nginx-deployment.yaml
kubectl apply -f nginx-service.yaml

# 也可以把多个资源写在一个文件里（用 --- 分隔），一次应用
kubectl apply -f nginx-all.yaml

# 删除
kubectl delete -f nginx-deployment.yaml
kubectl delete -f nginx-service.yaml

4.4 YAML 结构说明

apiVersion: <API 版本>        # 如 apps/v1, v1, batch/v1
kind: <资源类型>              # 如 Deployment, Service, Pod
metadata:                     # 元数据
  name: <资源名称>
  namespace: <命名空间>       # 可选，默认 default
  labels: {}                  # 标签
spec:                         # 规格（每种资源不同）
  ...

五、K8s 资源类型速览

工作负载：
  Pod          — 最小调度单元
  Deployment   — 无状态应用（Web 服务、API）
  StatefulSet  — 有状态应用（数据库、消息队列）
  DaemonSet    — 每个节点跑一个 Pod（日志、监控）
  Job          — 一次性任务
  CronJob      — 定时任务

服务发现：
  Service      — Pod 的稳定访问入口
  Ingress      — HTTP 路由和域名接入

配置存储：
  ConfigMap    — 配置文件
  Secret       — 敏感信息
  PV/PVC       — 持久化存储

安全：
  Namespace    — 资源隔离
  RBAC         — 权限控制
  NetworkPolicy — 网络隔离

六、开发者视角：应用如何适配 K8s

作为开发者，把应用部署到 K8s 需要关注：

6.1 应用要做的

- 提供健康检查接口（/health、/ready）
- 通过环境变量读取配置（不要硬编码）
- 日志输出到 stdout/stderr（K8s 自动收集）
- 优雅关闭（处理 SIGTERM 信号）
- 无状态化（Session 等状态存 Redis）

6.2 配置外部化示例（Go）

// 从环境变量读取配置
func main() {
    port := os.Getenv("APP_PORT")
    if port == "" {
        port = "8080"
    }
    dbHost := os.Getenv("DB_HOST")    // 从 ConfigMap/Secret 注入
    dbPort := os.Getenv("DB_PORT")
    
    // 启动 HTTP 服务
    http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusOK)
    })
    log.Fatal(http.ListenAndServe(":"+port, nil))
}

6.3 对应的 K8s 配置思路

应用配置    → ConfigMap
数据库密码  → Secret
健康检查    → Deployment 的 livenessProbe / readinessProbe
资源限制    → Deployment 的 resources.requests / limits
对外暴露    → Service + Ingress

七、小结

本文完成了以下内容：

K8s 的核心概念和架构
本地环境搭建（minikube + kubectl）
第一个应用的部署和访问
YAML 文件编写和部署
K8s 资源类型速览
开发者如何适配 K8s

下一篇将深入 Pod 与容器管理，包括生命周期、健康检查和资源限制。

Kubectl 命令速查手册

Wed, 06 May 2026 10:00:00 +0800

写在前面

本文整理了日常使用 Kubernetes 最常用的 kubectl 命令，涵盖资源查看、部署管理、排错调试和集群运维。每个命令都力求实用，避免罗列用不到的冷门参数。

一、基础操作

1.1 集群信息

# 查看集群信息
kubectl cluster-info

# 查看集群节点
kubectl get nodes

# 查看节点详细信息
kubectl describe node <node-name>

# 查看节点资源使用
kubectl top nodes

# 查看 kubeconfig 配置
kubectl config view

# 切换命名空间（需要 kubectx 或手动切换）
kubectl config set-context --current --namespace=<namespace>

1.2 命名空间

# 查看所有命名空间
kubectl get namespaces
kubectl get ns

# 创建命名空间
kubectl create namespace dev

# 删除命名空间
kubectl delete namespace dev

# 在指定命名空间下操作（-n 或 --namespace）
kubectl get pods -n dev

# 查看所有命名空间的资源
kubectl get pods --all-namespaces
kubectl get pods -A

1.3 通用操作

# 查看资源列表
kubectl get <resource>                    # 如 kubectl get pods
kubectl get <resource> -o wide            # 显示更多信息
kubectl get <resource> -o yaml            # 输出 YAML 格式
kubectl get <resource> -o json            # 输出 JSON 格式
kubectl get <resource> -o name            # 只显示资源名
kubectl get <resource> --show-labels      # 显示标签
kubectl get <resource> --sort-by=.metadata.creationTimestamp   # 按创建时间排序

# 查看资源详情
kubectl describe <resource> <name>

# 创建/更新资源
kubectl apply -f manifest.yaml            # 推荐，幂等操作
kubectl apply -f ./manifests/             # 应用目录下所有文件
kubectl apply -f https://url/manifest.yaml  # 从 URL 应用

# 删除资源
kubectl delete -f manifest.yaml           # 按文件删除
kubectl delete pod <pod-name>             # 按名称删除
kubectl delete pod <pod-name> --grace-period=0 --force  # 强制删除（卡住时用）

# 编辑资源
kubectl edit <resource> <name>            # 打开编辑器修改

# 查看资源定义帮助
kubectl explain pod
kubectl explain pod.spec.containers

二、Pod 管理

2.1 查看 Pod

# 列出 Pod
kubectl get pods
kubectl get pods -o wide                  # 显示 IP 和所在节点
kubectl get pods -w                       # 持续监控变化（watch）
kubectl get pods --field-selector status.phase=Running   # 按状态过滤

# 查看所有命名空间的 Pod
kubectl get pods -A

# 按标签筛选
kubectl get pods -l app=nginx
kubectl get pods -l 'app in (nginx, redis)'

# 查看 Pod 详情
kubectl describe pod <pod-name>

# 查看 Pod 的 YAML
kubectl get pod <pod-name> -o yaml

2.2 Pod 生命周期

Pod 状态：
Pending     — 正在调度或拉取镜像
Running     — 正在运行
Succeeded   — 执行完成（Job/CronJob）
Failed      — 执行失败
Unknown     — 无法获取状态（通常是节点失联）
CrashLoopBackOff — 容器反复崩溃重启
ImagePullBackOff — 镜像拉取失败

2.3 快速创建 Pod

# 用命令行快速创建（临时测试用）
kubectl run nginx --image=nginx:latest
kubectl run busybox --image=busybox --rm -it -- /bin/sh   # 运行后进入，退出自动删除

# 从 YAML 生成（不执行，输出到文件）
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

2.4 容器交互

# 查看容器日志
kubectl logs <pod-name>                          # 查看当前日志
kubectl logs <pod-name> -f                       # 实时跟踪日志
kubectl logs <pod-name> -f --tail=100            # 最后100行，持续跟踪
kubectl logs <pod-name> -c <container-name>      # 指定容器（多容器 Pod）
kubectl logs <pod-name> --previous               # 查看上一次崩溃的日志（排错神器）
kubectl logs <pod-name> --since=1h               # 最近1小时的日志
kubectl logs <pod-name> --since-time="2026-01-01T00:00:00Z"

# 进入容器
kubectl exec -it <pod-name> -- /bin/bash         # 进入容器 shell
kubectl exec -it <pod-name> -- /bin/sh            # 没有 bash 时用 sh
kubectl exec -it <pod-name> -c <container> -- sh  # 指定容器

# 在容器中执行命令（不进入）
kubectl exec <pod-name> -- cat /etc/config/app.conf
kubectl exec <pod-name> -- env                    # 查看环境变量
kubectl exec <pod-name> -- df -h                  # 查看磁盘

# 文件拷贝
kubectl cp <pod-name>:/tmp/file.txt ./file.txt           # 从容器拷贝到本地
kubectl cp ./file.txt <pod-name>:/tmp/file.txt           # 从本地拷贝到容器
kubectl cp ./file.txt <pod-name>:/tmp/ -c <container>    # 指定容器

2.5 端口转发

# 本地端口转发到 Pod（调试用）
kubectl port-forward <pod-name> 8080:80           # 本地8080 → Pod的80
kubectl port-forward <pod-name> 8080:80 3306:3306  # 同时转发多个端口
kubectl port-forward svc/<service-name> 8080:80    # 转发到 Service
kubectl port-forward deploy/<deploy-name> 8080:80  # 转发到 Deployment

三、工作负载管理

3.1 Deployment

# 查看 Deployment
kubectl get deployments
kubectl get deploy

# 创建 Deployment
kubectl create deployment nginx --image=nginx:latest --replicas=3
kubectl create deployment nginx --image=nginx --replicas=3 --dry-run=client -o yaml > deploy.yaml

# 扩缩容
kubectl scale deployment nginx --replicas=5

# 更新镜像（触发滚动更新）
kubectl set image deployment/nginx nginx=nginx:1.25
kubectl edit deployment nginx              # 直接编辑

# 查看滚动更新状态
kubectl rollout status deployment/nginx

# 查看更新历史
kubectl rollout history deployment/nginx

# 回滚到上一版本
kubectl rollout undo deployment/nginx

# 回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=2

# 暂停/恢复滚动更新（用于多次修改一次性生效）
kubectl rollout pause deployment/nginx
kubectl set image deployment/nginx nginx=nginx:1.25
kubectl set resources deployment/nginx -c nginx --limits=memory=512Mi
kubectl rollout resume deployment/nginx

# 查看 ReplicaSet（每个版本对应一个 RS）
kubectl get replicaset

3.2 StatefulSet

# 查看 StatefulSet
kubectl get statefulsets
kubectl get sts

# 扩缩容
kubectl scale statefulset mysql --replicas=3

# 查看详情
kubectl describe statefulset mysql

3.3 DaemonSet

# 查看 DaemonSet
kubectl get daemonsets
kubectl get ds

# 查看每个节点上的 Pod
kubectl get pods -o wide | grep <daemonset-name>

3.4 Job 和 CronJob

# 查看 Job
kubectl get jobs

# 查看 CronJob
kubectl get cronjobs

# 手动触发 CronJob
kubectl create job --from=cronjob/<cronjob-name> <job-name>

# 删除 Job
kubectl delete job <job-name>

四、服务与网络

4.1 Service

# 查看 Service
kubectl get services
kubectl get svc

# 查看 Service 详情（查看 Endpoints）
kubectl describe svc <service-name>

# 查看 Endpoints
kubectl get endpoints <service-name>

# 暴露 Deployment 为 Service
kubectl expose deployment nginx --port=80 --target-port=80 --type=ClusterIP
kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --type=LoadBalancer

# 常用 Service 类型：
# ClusterIP     — 集群内部访问（默认）
# NodePort      — 通过节点端口外部访问（30000-32767）
# LoadBalancer  — 云厂商提供的负载均衡器
# ExternalName  — 映射到外部 DNS 名

4.2 Ingress

# 查看 Ingress
kubectl get ingress
kubectl get ing

# 查看 Ingress 详情
kubectl describe ingress <ingress-name>

4.3 网络诊断

# 临时启动一个网络调试 Pod
kubectl run debug --image=busybox --rm -it --restart=Never -- sh

# 在调试 Pod 中测试 DNS
nslookup <service-name>
nslookup <service-name>.<namespace>.svc.cluster.local

# 测试 Service 连通性
wget -qO- http://<service-name>:<port>
curl http://<service-name>:<port>

# 查看集群 DNS 配置
kubectl get configmap coredns -n kube-system

五、配置与存储

5.1 ConfigMap

# 从字面量创建
kubectl create configmap app-config --from-literal=DB_HOST=mysql --from-literal=DB_PORT=3306

# 从文件创建
kubectl create configmap app-config --from-file=config.properties

# 从目录创建（目录下每个文件变成一个 key）
kubectl create configmap app-config --from-file=./config/

# 查看 ConfigMap
kubectl get configmaps
kubectl get cm
kubectl describe configmap app-config

5.2 Secret

# 创建 Secret
kubectl create secret generic db-secret --from-literal=username=admin --from-literal=password='P@ssw0rd'

# 从文件创建
kubectl create secret generic tls-secret --from-file=tls.crt=./cert.pem --from-file=tls.key=./key.pem

# 查看 Secret（内容是 base64 编码的）
kubectl get secrets
kubectl describe secret <secret-name>

# 解码查看 Secret 内容
kubectl get secret <secret-name> -o jsonpath='{.data.password}' | base64 --decode

5.3 PV 和 PVC

# 查看持久卷
kubectl get persistentvolumes
kubectl get pv

# 查看持久卷声明
kubectl get persistentvolumeclaims
kubectl get pvc

# 查看 PVC 绑定状态
kubectl get pvc -o wide

# 查看 PV 详情
kubectl describe pv <pv-name>
kubectl describe pvc <pvc-name>

六、排错调试

6.1 排查流程

Pod 一直 Pending       → kubectl describe pod 查看 Events，通常是资源不足
Pod 一直 CrashLoopBackOff → kubectl logs --previous 查看上次崩溃日志
Pod ImagePullBackOff   → 检查镜像名和镜像仓库权限
Service 无法访问       → 检查 Endpoints 是否有 Pod，标签是否匹配
Pod 间无法通信         → 检查 NetworkPolicy，检查 DNS 解析

6.2 常用排错命令

# 查看 Pod 事件（排错第一步）
kubectl describe pod <pod-name> | grep -A 20 Events

# 查看 Pod 状态和重启次数
kubectl get pods -o wide

# 查看容器日志
kubectl logs <pod-name> --previous              # 上次崩溃的日志
kubectl logs <pod-name> -c <container> -f       # 指定容器，实时跟踪

# 进入容器排查
kubectl exec -it <pod-name> -- sh

# 查看 Pod 失败原因
kubectl get pod <pod-name> -o jsonpath='{.status.conditions[?(@.type=="Ready")].message}'

# 查看节点事件
kubectl get events --sort-by='.lastTimestamp'
kubectl get events --field-selector involvedObject.name=<pod-name>

# 查看 API 资源消耗
kubectl get --raw /metrics

6.3 资源使用

# 查看节点资源使用（需要 metrics-server）
kubectl top nodes

# 查看 Pod 资源使用
kubectl top pods
kubectl top pods -n <namespace>
kubectl top pods --sort-by=memory              # 按内存排序
kubectl top pods --sort-by=cpu                 # 按 CPU 排序

# 安装 metrics-server（如果 top 命令报错）
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

七、标签与选择器

7.1 标签操作

# 查看标签
kubectl get pods --show-labels

# 添加标签
kubectl label pod <pod-name> env=prod

# 修改标签（覆盖已有值）
kubectl label pod <pod-name> env=staging --overwrite

# 删除标签
kubectl label pod <pod-name> env-

# 按标签筛选
kubectl get pods -l app=nginx
kubectl get pods -l 'tier in (frontend,backend)'
kubectl get pods -l 'env!=debug'
kubectl get pods -l 'version in (v1, v2),app=nginx'

7.2 注解

# 添加注解
kubectl annotate pod <pod-name> description="测试 Pod"

# 查看注解
kubectl describe pod <pod-name> | grep -A 5 Annotations

# 删除注解
kubectl annotate pod <pod-name> description-

八、集群运维

8.1 节点管理

# 查看节点详情
kubectl describe node <node-name>

# 节点资源使用
kubectl top nodes

# 标记节点为不可调度（维护前操作）
kubectl cordon <node-name>

# 恢复节点调度
kubectl uncordon <node-name>

# 驱逐节点上的 Pod（维护用）
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# 查看节点标签
kubectl get nodes --show-labels

# 给节点打标签（用于调度）
kubectl label node <node-name> disktype=ssd

8.2 集群资源

# 查看 API 资源类型
kubectl api-resources

# 查看 API 版本
kubectl api-versions

# 查看所有资源（包括 CRD）
kubectl get all -A

# 查看集群组件状态
kubectl get componentstatuses
kubectl get cs

8.3 RBAC

# 查看角色
kubectl get roles
kubectl get clusterroles

# 查看角色绑定
kubectl get rolebindings
kubectl get clusterrolebindings

# 查看角色详情
kubectl describe role <role-name>
kubectl describe clusterrole <clusterrole-name>

九、常用组合命令

# 快速查看所有命名空间的 Pod 状态（排除 Running 的）
kubectl get pods -A --field-selector=status.phase!=Running

# 查看 CrashLoopBackOff 的 Pod
kubectl get pods -A | grep -E "CrashLoop|Error|Pending"

# 批量删除 Completed 状态的 Pod
kubectl get pods -A --field-selector=status.phase=Succeeded -o json | \
  kubectl delete -f -

# 批量删除 Evicted 状态的 Pod
kubectl get pods -A | grep Evicted | awk '{print $2 " --namespace=" $1}' | xargs -n 2 kubectl delete pod

# 查看 Deployment 的 Pod 模板镜像版本
kubectl get deployment <name> -o jsonpath='{.spec.template.spec.containers[*].image}'

# 查看所有 Deployment 的镜像版本
kubectl get deployments -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGES:.spec.template.spec.containers[*].image'

# 快速导出资源定义（去掉集群特有字段）
kubectl get <resource> <name> -o yaml | kubectl neat

# 查看资源配额
kubectl describe resourcequota -n <namespace>

# 查看限制范围
kubectl describe limitrange -n <namespace>

十、kubectl 命令速查

按场景选命令

查状态    → kubectl get pods/svc/deploy -A
查日志    → kubectl logs <pod> -f --tail=100
查原因    → kubectl describe pod <pod>
进容器    → kubectl exec -it <pod> -- sh
调端口    → kubectl port-forward <pod> 8080:80
更新镜像  → kubectl set image deploy/<name> <container>=<image>
扩缩容    → kubectl scale deploy <name> --replicas=5
回滚      → kubectl rollout undo deploy/<name>
看资源    → kubectl top pods/nodes
节点维护  → kubectl drain <node> --ignore-daemonsets

输出格式

-o wide            # 更多列（IP、节点等）
-o yaml            # YAML 格式
-o json            # JSON 格式
-o name            # 只显示资源名
-o custom-columns  # 自定义列

常用简写

po/pods           → pod
svc/services      → service
deploy/deployments → deployment
sts/statefulsets  → statefulset
ds/daemonsets     → daemonset
cm/configmaps     → configmap
sec/secrets       → secret
ns/namespaces     → namespace
pv/persistentvolumes → persistentvolume
pvc/persistentvolumeclaims → persistentvolumeclaim
ing/ingress       → ingress
no/nodes          → node