Helm是Kubernetes的包管理器，类似于Linux的yum/apt，可以简化应用的安装、升级和管理。
本文系统介绍Helm的核心概念、Chart开发和实战应用，帮助你掌握K8s应用管理的最佳实践。

一、Helm概述

1.1 核心概念

Kubernetes是云原生时代的容器编排标准，理解其架构设计是部署和管理微服务的基础。
本文深入剖析Kubernetes的核心架构、组件功能和工作原理，帮助你掌握容器编排的精髓。

一、Kubernetes概述

1.1 核心能力

早上 9 点，你收到告警：K8s 集群有 3 个 Node 状态变成 Not Ready，上面运行的 47 个 Pod 被 Evicted。订单服务的 Pod 在其他节点重建后持续 CrashLoopBackOff。这不是简单的重启能解决的——Node 为什么 Not Ready？Pod 为什么被驱逐？重建后为什么起不来？本文带你完整排查 K8s 集群级故障。

一、Node Not Ready：原因全景与快速判断

1.1 Node 状态详解

# 查看所有 Node 状态
kubectl get nodes -o wide

# NAME            STATUS     ROLES    AGE    VERSION    INTERNAL-IP
# worker-node-01  Ready      <none>   120d   v1.28.4    10.0.1.21
# worker-node-02  NotReady   <none>   120d   v1.28.4    10.0.1.22  ← 故障节点
# worker-node-03  NotReady   <none>   120d   v1.28.4    10.0.1.23  ← 故障节点
# worker-node-04  Ready      <none>   90d    v1.28.4    10.0.1.24

# 查看 NotReady 节点的详细信息
kubectl describe node worker-node-02

Jenkins 管道太重？部署状态不可见？回滚靠手动？GitOps 是 K8s 时代的 CD 标准方案，ArgoCD 是最佳实践工具。

一、GitOps 核心理念

1.1 传统 CD vs GitOps

传统 CD：
  CI Pipeline → kubectl apply → Cluster
  问题：谁在什么时候部署了什么？集群状态不可追溯

GitOps：
  CI Pipeline → Git Repo（声明式配置） → ArgoCD → Cluster
  Git 是唯一真相源（Single Source of Truth）
  一切变更通过 PR，可审计、可回滚

Kubernetes是容器编排领域的标准，它为容器化应用提供了自动化部署、扩缩容和管理能力。
本文介绍了Kubernetes的核心概念和实践经验，帮助你构建云原生应用。

假设你要在 K8s 上管理一个 MySQL 主从集群，传统做法需要：

1. 写一堆 YAML 部署 StatefulSet
2. 手动初始化主从复制
3. 手动创建用户、数据库
4. 节点故障时手动修复
5. 备份需要手动配 CronJob

每次操作都要人工介入，这不"云原生"。

Kubernetes是容器编排领域的标准，它为容器化应用提供了自动化部署、扩缩容和管理能力。
本文介绍了Kubernetes的核心概念和实践经验，帮助你构建云原生应用。

容器的文件系统是临时的——容器重启后数据就没了。早期 Docker 用 Volume 挂载宿主机目录，但这在 K8s 中行不通：

• Pod 可能被调度到任何节点
• 节点故障后 Pod 迁移，数据留在了旧节点上
• 不同应用对存储性能要求不同（SSD vs HDD）

所以 K8s 设计了一套存储抽象体系：

K8s 网络是云原生最难的领域之一。Pod 之间怎么通信？Service 怎么负载均衡？外部流量怎么进来？CNI、kube-proxy、Ingress 三层体系一次讲清。

一、K8s 网络模型

K8s 网络的四个核心问题：

1. 容器间通信（同一 Pod 内）    → localhost（共享网络命名空间）
2. Pod 间通信（同一 Node）      → 通过 cni0 网桥/路由
3. Pod 间通信（跨 Node）        → CNI 插件实现（Overlay 或 Underlay）
4. Service 与外部通信           → kube-proxy + Ingress/LB

Pod 被 OOMKilled？节点资源不均衡？HPA 扩缩容不及时？这些都是资源管理没做好。K8s 资源管理从 requests/limits 到 QoS 到自动伸缩，是一条完整链路。

一、资源请求与限制

1.1 requests 和 limits

apiVersion: v1
kind: Pod
metadata:
  name: order-service
spec:
  containers:
  - name: app
    image: order:v1.0
    resources:
      requests:        # 调度依据：保证最低资源
        cpu: "500m"    # 0.5 核
        memory: "512Mi"
      limits:          # 上限：超过会被限制或杀死
        cpu: "1000m"   # 1 核
        memory: "1Gi"

Kubernetes是容器编排领域的标准，它为容器化应用提供了自动化部署、扩缩容和管理能力。
本文介绍了Kubernetes的核心概念和实践经验，帮助你构建云原生应用。

很多初学者认为 Pod 就是"包着一组容器的壳"，但这个理解太浅了。Pod 是 K8s 中最小的可调度单元，它存在的意义是：

• 共享网络：Pod 内所有容器共享同一个网络命名空间（IP、端口空间）
• 共享存储：Pod 内的 Volume 可以被所有容器挂载
• 共享生命周期：Pod 作为一个整体被调度、创建、销毁

Kubernetes是容器编排领域的标准，它为容器化应用提供了自动化部署、扩缩容和管理能力。
本文介绍了Kubernetes的核心概念和实践经验，帮助你构建云原生应用。

K8s 中 Pod 重启通常由以下原因触发：