kubernetes核心概念

个人笔记分享

1. 概述

Kubernetes（K8s） 是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用。它提供了声明式配置、服务发现、负载均衡、自动回滚、自愈等能力，已成为云原生应用的事实标准。

本笔记涵盖从基础概念到生产级运维的常见知识点，适用于学习与日常参考。

2. 核心概念

2.1 集群架构与组件

Kubernetes 集群由 控制平面（Control Plane） 和 工作节点（Node） 组成。

组件分类	组件名称	职责
控制平面	`kube-apiserver`	集群统一 API 入口，认证授权，所有操作均通过它
	`etcd`	分布式键值存储，保存所有集群状态数据
	`kube-scheduler`	为新创建的 Pod 选择合适节点（调度）
	`kube-controller-manager`	运行各种控制器（如 Deployment、Node 控制器）
	`cloud-controller-manager`	对接云厂商 API（可选）
工作节点	`kubelet`	节点代理，管理 Pod 生命周期，与 apiserver 通信
	`kube-proxy`	维护网络规则，实现 Service 负载均衡
	容器运行时（CRI）	运行容器的引擎，如 containerd、Docker（已弃用）
附加组件	CoreDNS	集群内部 DNS 服务，用于服务发现
	CNI 网络插件	实现 Pod 网络互通，如 Calico、Flannel
	Ingress Controller	实现七层 HTTP/S 路由（如 Nginx Ingress）

注意：Docker 作为运行时已被弃用，推荐使用 containerd 或 CRI-O（Kubernetes v1.24+）。

2.2 API 对象与控制器

Kubernetes 通过 API 对象 定义资源（如 Pod、Deployment、Service），每个对象由 spec（期望状态）和 status（实际状态）组成。

控制器（Controller） 是管理特定资源对象的后台循环，将实际状态调谐至期望状态。例如：

DeploymentController 管理 Deployment
IngressController 管理 Ingress 规则（通常由第三方实现）

查看所有 API 资源：

kubectl api-resources

2.3 声明式管理与 YAML

Kubernetes 推崇 声明式管理，即通过 YAML 文件描述资源的期望状态，并使用 kubectl apply 提交。YAML 具有幂等性，重复执行不会产生副作用。

一个标准的 Pod YAML 示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.25.2
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "200m"

关键字段说明：

apiVersion：资源所属 API 组和版本

kind：资源类型

metadata：名称、命名空间、标签等元数据

spec：期望状态，因资源类型而异

生成 YAML 模板：

# 生成 Deployment 的 YAML（不实际创建）
kubectl create deployment nginx --image=nginx:1.27.3 --dry-run=client -o yaml > nginx-deploy.yaml

2.4 标签（Label）与选择器

标签是附加到资源上的键值对，用于组织和选择资源。选择器（Selector） 通过标签筛选资源，常见于 Service 绑定 Pod、Deployment 管理 Pod 等场景。

示例：

metadata:
  labels:
    app: web
    env: prod

Service 通过 selector 匹配：

selector:
  app: web

2.5 命名空间（Namespace）

命名空间实现 逻辑隔离，将同一集群划分为多个虚拟集群。适用于多租户、环境隔离（dev/test/prod）、资源配额管理等。

特性：

资源名称在命名空间内唯一
跨命名空间的资源相互隔离（如 Service 只能访问同命名空间的 Service）
部分全局资源（如 Node、PV）不属于任何命名空间

常用命令：

# 查看命名空间
kubectl get ns

# 指定命名空间操作
kubectl get pods -n kube-system

3. 工作负载资源

3.1 Pod

Pod 是 Kubernetes 中最小的部署单元，包含一个或多个紧密相关的容器。Pod 内容器共享网络命名空间和存储卷。

Pod 状态（Phase）

状态	说明
`Pending`	Pod 已创建但尚未调度或镜像拉取中
`Running`	至少一个容器正在运行
`Succeeded`	所有容器正常退出（退出码 0）
`Failed`	至少一个容器异常退出（非 0）
`Unknown`	无法获取状态（如节点失联）

重启策略（restartPolicy）

策略	说明	适用场景
`Always`（默认）	容器无论以何种方式退出，都重启	长期运行服务
`OnFailure`	仅当退出码非 0 时重启	批处理任务
`Never`	永不重启	临时调试 Pod

重启间隔采用指数退避（10s → 20s → 40s，最大 5min）。

3.2 Deployment

Deployment 是管理无状态应用的首选控制器，提供：

滚动更新与回滚
副本数扩缩容
版本记录与历史回退

示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25

常用操作：

# 滚动重启（基于新镜像重建，不中断服务）
kubectl rollout restart deploy/nginx-deploy

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

# 查看历史版本
kubectl rollout history deploy/nginx-deploy

3.3 StatefulSet

StatefulSet 用于管理有状态应用，提供以下特性：

稳定的网络标识（固定 Pod 名称和 DNS）
有序部署、扩缩容、更新
关联持久化存储（PVC 模板）

适用于数据库、消息队列等需要持久状态的服务。

3.4 DaemonSet

DaemonSet 确保每个节点（或符合条件的节点）上运行一个 Pod 副本，常用于：

日志收集（如 Fluentd）
节点监控（如 Prometheus Node Exporter）
网络代理（如 kube-proxy 本身是用 DaemonSet 部署的）

3.5 Job 与 CronJob

Job：运行一次性任务，完成后 Pod 退出且不重启。
CronJob：定时执行 Job，类似 Linux crontab。

示例（CronJob）：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tool
          restartPolicy: OnFailure

4. 服务发现与负载均衡

4.1 Service

Service 为一组 Pod 提供稳定的访问入口和负载均衡。类型如下：

类型	访问范围	说明
`ClusterIP`（默认）	集群内部	分配一个内部虚拟 IP，仅集群内可访问
`NodePort`	集群内外	在每个节点上开放一个静态端口（30000~32767），通过 `<NodeIP>:<NodePort>` 访问
`LoadBalancer`	外部	使用云厂商或 MetalLB 分配外部 IP，通常基于 NodePort 实现
`ExternalName`	集群内部	将 Service 映射到外部 DNS 名称，不代理流量
`Headless`	集群内部	不分配 ClusterIP，直接解析为 Pod IP（用于 StatefulSet）

YAML 示例（ClusterIP）：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80          # Service 端口
    targetPort: 8080  # Pod 容器端口

访问方式：集群内可通过 my-service.default.svc.cluster.local（或简写 my-service）访问。

Endpoints 与 EndpointSlices

Endpoints：记录 Service 关联的 Pod IP 列表，由 K8s 自动维护。
EndpointSlices：更大规模场景下的替代方案，减少 API 压力。

4.2 Ingress 与 Ingress Controller

Ingress 是七层（HTTP/HTTPS）路由规则资源，可将外部流量根据域名/路径转发到不同 Service。
Ingress Controller 是实现 Ingress 规则的组件（如 Nginx Ingress、Traefik）。

示例 Ingress 规则：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

生产环境通常结合证书管理（如 cert-manager）实现 HTTPS。

4.3 网络策略（NetworkPolicy）

NetworkPolicy 定义 Pod 间的网络访问规则（类似防火墙），需要 CNI 插件支持（如 Calico）。默认情况下，所有 Pod 可以互相访问。

5. 配置与存储

5.1 ConfigMap 与 Secret

两者均用于存储配置数据，挂载到 Pod 中作为环境变量或文件。

特性	ConfigMap	Secret
用途	非敏感配置（如应用参数）	敏感信息（密码、Token、证书）
存储形式	明文（base64 可选）	base64 编码（需额外加密方可安全）
默认权限	644	400（更严格）

Secret 的 stringData 字段可直接写明文，自动 base64 编码。

使用方式（环境变量挂载）：

env:
- name: DB_USER
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: username

使用方式（文件挂载）：

volumeMounts:
- name: config
  mountPath: /etc/config
volumes:
- name: config
  configMap:
    name: app-config

5.2 Volume 与挂载

容器中的文件是临时的，Volume 提供持久化或共享存储。

常见 Volume 类型：

类型	持久性	跨节点	场景
`emptyDir`	❌ 随 Pod 删除	✅ 同 Pod 内共享	临时缓存、数据交换
`hostPath`	✅ 节点级持久	❌ 单节点	访问宿主机文件
`configMap` / `secret`	✅ API 对象持久	✅ 集群级	配置注入
`projected`	依赖源	✅	组合多个 ConfigMap/Secret
`CSI`	✅	视驱动而定	对接云存储或专用存储

路径挂载：

volumeMounts.mountPath 为容器内目标路径
volumes 定义存储源（需与 volumeMounts.name 匹配）

5.3 PersistentVolume（PV）与 PersistentVolumeClaim（PVC）

PV：集群级存储资源，由管理员预先创建或通过 StorageClass 动态供给。
PVC：用户对存储的请求（如大小、访问模式），绑定到符合条件的 PV。

生命周期：

管理员创建 PV（或配置 StorageClass）
用户创建 PVC
K8s 将 PVC 绑定到 PV
Pod 通过 PVC 使用存储

注意：PVC 是命名空间级资源，PV 是集群级资源。

6. 集群网络详解

6.1 CNI 网络插件

CNI（Container Network Interface） 是 Kubelet 调用以配置 Pod 网络的插件接口。没有 CNI，Pod 将处于 Creating 状态。

CNI 在 Pod 创建/删除时被调用，负责分配 IP 并设置路由。
常见插件：Calico（支持网络策略）、Flannel（简单）、Cilium（基于 eBPF）。

同一 Node 内的 Pod 间通信由 CNI 直接实现。

6.2 Service 实现原理（kube-proxy）

kube-proxy 在 Node 上维护网络规则，将 Service 的 ClusterIP 请求负载均衡到后端 Pod。后端有三种实现模式：

模式	性能	说明
`iptables`（默认）	中等	成熟稳定，适合中小集群
`IPVS`（推荐）	高	基于内核哈希表，生产环境首选
`userspace`（已废弃）	低	仅用于测试

6.3 外部访问：MetalLB 与 Ingress

在裸机（非云环境）中，LoadBalancer 类型的 Service 无法自动分配 IP，MetalLB 填补了这一空白，为集群提供负载均衡 IP 分配。

MetalLB 工作在四层（网络层），为 Service 分配外部可访问 IP。
Ingress 工作在七层（应用层），基于域名/路径路由。

典型组合：

外部请求 → MetalLB（提供入口 IP）→ Ingress Controller（Nginx）→ 根据规则转发至 Service → Pod

7. 监控与可观测性

7.1 资源监控与 top 命令

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

# 查看命名空间下 Pod 资源使用（含各容器）
kubectl top pod -n <namespace> --containers

# 查看单个 Pod 详细资源（可查看是否达到 Limits）
kubectl describe pod <pod-name> -n <namespace>

需要 Metrics Server 组件支持。

7.2 Prometheus + Grafana 监控体系

Prometheus：开源监控系统，内置时序数据库，通过 Pull 方式采集指标。
Grafana：可视化仪表盘，可对接 Prometheus 展示图表。

在 K8s 中常通过 Prometheus Operator 或 Helm 部署。
参考社区教程：Kubernetes集群部署Prometheus和Grafana

8. 高级主题

8.1 探针（Probe）与健康检查

探针是 Kubelet 对容器进行的健康检查，分为三类：

探针类型	目的	失败后果
`livenessProbe`	容器是否存活	重启容器
`readinessProbe`	容器是否可接收流量	从 Service 端点移除
`startupProbe`	应用启动是否完成	启动失败则重启（用于慢启动应用）

探测方式：

HTTP GET：检查 HTTP 状态码（2xx/3xx 为成功）
TCP Socket：能否建立 TCP 连接
Exec：执行命令，退出码 0 为成功

重要参数：

参数	含义	默认
`initialDelaySeconds`	容器启动后延迟多久开始探测	0
`periodSeconds`	探测间隔	10
`timeoutSeconds`	单次探测超时	1
`successThreshold`	连续成功多少次才算成功	1
`failureThreshold`	连续失败多少次才算失败	3
`terminationGracePeriodSeconds`	容器终止前的宽限期	30

注意：同时配置 startupProbe 时，initialDelaySeconds 被忽略。

8.2 钩子（Hook）

钩子是在容器生命周期特定时刻执行的一次性操作（非周期性探测）。

postStart：容器创建后立即执行（与主进程并行），常用于初始化。
preStop：容器终止前执行，用于优雅关闭（需配合宽限期）。

示例：

lifecycle:
  postStart:
    exec:
      command: ["/bin/sh", "-c", "echo init"]
  preStop:
    httpGet:
      path: /shutdown
      port: 8080

8.3 HPA 动态扩缩容

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

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

8.4 污点（Taint）与容忍（Toleration）

污点加在 Node 上，表示该节点排斥某些 Pod（除非 Pod 带有对应的容忍）。

用途：

专用节点（如 GPU 节点）
维护隔离（NoExecute 会在节点故障时驱逐 Pod）

示例：

tolerations:
- key: "gpu"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

8.5 亲和性（Affinity）与反亲和性

亲和性 用于将 Pod 调度到特定节点（或与其他 Pod 共处），比 NodeSelector 更灵活。

nodeAffinity：选择节点（硬/软）
podAffinity / podAntiAffinity：与现有 Pod 的位置关系

8.6 Helm 包管理

Helm 是 Kubernetes 的包管理器，类似 apt/yum，用于管理 Chart（一组 K8s 资源模板）。

核心组件：

Chart：包含 Chart.yaml、values.yaml、templates/ 等目录
Repository：Chart 仓库（如 Bitnami、Grafana）
Release：Chart 的一次部署实例

常用命令：

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

# 搜索 Chart
helm search repo redis

# 安装
helm install my-release bitnami/nginx

# 升级
helm upgrade my-release bitnami/nginx --set replicaCount=3

# 回滚
helm rollback my-release 1

# 打包 Chart
helm package mychart

Chart 目录结构：

mychart/
├── Chart.yaml          # 元数据（名称、版本）
├── values.yaml         # 默认配置
├── templates/          # 模板文件（deployment.yaml 等）
└── charts/             # 子 Chart（可选）

Helm 不干预运行时状态，它只负责资源对象的创建/更新/删除。

8.7 Operator 模式

Operator 是一种扩展 Kubernetes API 的模式，将运维知识（如数据库备份、故障恢复）编码为自定义控制器，实现 有状态应用的全生命周期自动化管理。

Operator 基于 CRD（自定义资源）和控制器实现，能主动维护应用状态，具备 运行时状态干预能力（区别于 Helm 的纯声明式管理）。

常见 Operator：Prometheus Operator、Etcd Operator、MySQL Operator 等。

9. 常用 kubectl 命令速查

9.1 通用选项

选项	说明
`-n, --namespace`	指定命名空间
`-l, --selector`	按标签过滤
`-o, --output`	输出格式（`wide`, `json`, `yaml`, `custom-columns`）
`--kubeconfig`	指定 kubeconfig 文件
`--context`	使用指定 context
`-v, --v`	日志级别（调试用）
`--dry-run=client`	试运行，不实际创建
`-f, --filename`	指定 YAML 文件
`-A, --all-namespaces`	跨所有命名空间

9.2 资源操作

# 创建/更新资源（声明式）
kubectl apply -f resource.yaml

# 强制替换（全量覆盖，谨慎使用）
kubectl replace --force -f resource.yaml

# 删除资源
kubectl delete <type> <name> -n <ns>

# 查看资源
kubectl get pods -o wide
kubectl get deploy -A
kubectl get svc,ingress

# 描述资源详情
kubectl describe pod <pod-name>

# 查看日志
kubectl logs <pod-name> [-c <container>] [-f]

# 进入容器
kubectl exec -it <pod-name> -- /bin/bash

# 编辑资源（热修改，部分需重启生效）
kubectl edit deploy <name> -n <ns>

9.3 调试与排错

# 查看事件（默认保留1小时）
kubectl get events -n <ns> | grep <pod-name>

# 实时监控
watch -n 1 kubectl get pods

# 查看节点状态
kubectl describe node <node-name>

10. 故障排查思路

现象	可能原因	排查步骤
Pod 一直 Pending	资源不足、调度失败、污点不匹配	`describe pod` 查看 Events；检查节点资源
Pod 一直 Creating	CNI 未安装或网络插件异常	检查 CNI Pod 状态；查看 kubelet 日志
Pod 频繁重启	应用崩溃、探针失败、OOM	查看 logs；检查探针配置；查看资源 Limits
Service 无法访问	Selector 不匹配、端口错误、网络策略限制	`describe svc` 检查 Endpoints；验证标签
外部访问不通	NodePort 防火墙、Ingress 配置错误	检查 NodePort 是否开放；验证 Ingress 规则

Tips：

kubectl describe 中的 Events 是首要排查信息来源（默认保留 1 小时，可重定向保存）。

使用 kubectl exec 进入容器，使用 curl、ping 等工具测试连通性。

11. 附录

11.1 阿里云 PPU 配置示例

以下为阿里云 PPU（高性能 AI 加速卡）的 Pod 配置（适用于 AI 推理场景）：

apiVersion: v1
kind: Pod
metadata:
  name: des-ai-pod
  labels:
    app: des-ai
spec:
  tolerations:
    - key: "virtual-kubelet.io/provider"
      operator: "Equal"
      value: "aliclouddb"
      effect: "NoSchedule"
  restartPolicy: Always
  nodeSelector:
    alibabacloud.com/virtual-node: "true"
  containers:
    - name: des-ai-container
      image: aliclouddb-pub-registry-vpc.cn-wulanchabu.cr.aliyuncs.com/aliclouddb-public/des-ai:25.05-v1.5.1-vllm0.8.5-torch2.6-cu126-20250528
      imagePullPolicy: IfNotPresent
      command:
        - sh
        - -c
        - echo hello world; sleep infinity;
      ports:
        - containerPort: 8080
        - containerPort: 8000
      env:
        - name: MODEL_PATH
          value: /models
        - name: TOKENIZER_PATH
          value: /models
        - name: HF_HOME
          value: /cache/huggingface
      resources:
        requests:
          aliyun/ppu: "8"
          cpu: "80"
          memory: "512Gi"
        limits:
          aliyun/ppu: "8"
          cpu: "80"
          memory: "1024Gi"      # 大内存避免 OOM
      volumeMounts:
        - name: model-storage
          mountPath: /models
        - name: hf-cache
          mountPath: /cache/huggingface
        - name: shm
          mountPath: /dev/shm   # 共享内存，支持 vLLM 多进程通信
  volumes:
    - name: model-storage
      emptyDir:
        medium: Memory
        sizeLimit: 1200Gi
    - name: hf-cache
      emptyDir:
        medium: Memory
        sizeLimit: 100Gi
    - name: shm
      emptyDir:
        medium: Memory
        sizeLimit: 200Gi

该示例展示了自定义资源（aliyun/ppu）、大内存、共享内存及环境变量的配置。

11.2 参考文档与社区

官方文档：https://kubernetes.io/zh-cn/docs/home
中文社区：http://docs.kubernetes.org.cn/
Kuboard 学习手册：https://kuboard.cn/learning/
Sealos 部署文档：https://www.yuque.com/xianzhou-eiffx/aklhoc/gc82cegph6ftw2t0
阿里云开发者文章：https://developer.aliyun.com/article/1645394

posted @ 2026-09-14 09:34 ignibera 阅读(7) 评论(0) 收藏举报

刷新页面返回顶部

ignibera

kubernetes核心概念

1. 概述

2. 核心概念

2.1 集群架构与组件

2.2 API 对象与控制器

2.3 声明式管理与 YAML

一个标准的 Pod YAML 示例：

生成 YAML 模板：

2.4 标签（Label）与选择器

2.5 命名空间（Namespace）

3. 工作负载资源

3.1 Pod

Pod 状态（Phase）

重启策略（restartPolicy）

3.2 Deployment

3.3 StatefulSet

3.4 DaemonSet

3.5 Job 与 CronJob

4. 服务发现与负载均衡

4.1 Service

Endpoints 与 EndpointSlices

4.2 Ingress 与 Ingress Controller

4.3 网络策略（NetworkPolicy）

5. 配置与存储

5.1 ConfigMap 与 Secret

使用方式（环境变量挂载）：

使用方式（文件挂载）：

5.2 Volume 与挂载

5.3 PersistentVolume（PV）与 PersistentVolumeClaim（PVC）

6. 集群网络详解

6.1 CNI 网络插件

6.2 Service 实现原理（kube-proxy）

6.3 外部访问：MetalLB 与 Ingress

7. 监控与可观测性

7.1 资源监控与 top 命令

7.2 Prometheus + Grafana 监控体系

8. 高级主题

8.1 探针（Probe）与健康检查

探测方式：

重要参数：

8.2 钩子（Hook）

8.3 HPA 动态扩缩容

8.4 污点（Taint）与容忍（Toleration）

8.5 亲和性（Affinity）与反亲和性

8.6 Helm 包管理

核心组件：

常用命令：

Chart 目录结构：

8.7 Operator 模式

9. 常用 kubectl 命令速查

9.1 通用选项

9.2 资源操作

9.3 调试与排错

10. 故障排查思路

11. 附录

11.1 阿里云 PPU 配置示例

11.2 参考文档与社区

公告