Kubernetes命名空间与Pod核心概念（自用笔记）

本次笔记记录了Kubernetes中命名空间（Namespace）和Pod的核心概念、作用机制及实操要点，包括命名空间的逻辑隔离特性、资源配额设置与应用、Pod作为最小可部署单元的结构设计、生命周期管理、探针机制及资源清单编写规范。

一、命名空间（Namespace）的概念与作用

1.1 命名空间的定义与类比

1.2 命名空间的隔离性与应用场景

核心作用：实现多团队/多项目下的资源隔离

典型应用场景：

|-------------|--------|
| 命名空间 | 用途 |
| development | 开发环境 |
| test | 测试环境 |
| production | 生产环境 |
| default | 单一业务场景 |

注意：单一业务无需使用命名空间，直接置于default即可。

1.3 命名空间的创建方式

方式一：命令行创建

bash 复制代码

bash

    kubectl create namespace <name>

方式二：资源清单文件创建

bash 复制代码

yaml
  
    apiVersion: v1
    kind: Namespace
    metadate:  
       name development

禁止在清单中硬编码以下字段（由集群自动分配）：

creaionTomestamp

uid

resourceVersion

二、命名空间级别与集群级别资源区分

2.1 资源的两个作用域层级

2.2 判断依据

bash 复制代码

bash

    #查看资源作用域
    kubectl api-resources

    #NAMESPACED列值为true→命名空间级别资源
    #NAMESPACED列值为false→集群级别资源

三、命名空间资源配额（ResourceQuota）机制

3.1 资源配额的目的

防止某命名空间无限占用物理集群资源，导致其他业务无法正常调度。

类比：磁盘配额------针对"目录"（即命名空间）限制其可使用的总资源上限，而非针对单个容器。

3.2 配额类型与字段含义

|-----------------|--------------------|------------|
| 字段 | 说明 | 单位 |
| requests.cpu | Pod启动时申请的CPU最小保障量 | 0.5 或 500m |
| requests.memory | Pod启动时申请的内存最小保障量 | Gi、Mi |
| imits.cpu | Pod运行期间CPU使用量硬性上限 | 1（1核） |
| imits.memory | Pod运行期间内存使用硬性上限 | 4Gi |

3.3 配额配置示例

bash 复制代码

yaml 
   
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: compute-quota
      namespace: development
    spec:
      hard:
        requests.cpu: "4"
        requests.memory: 8Gi
        limits.cpu: "8"
        limits.memory: 16Gi
        pods: "10"

3.4配额验证

bash 复制代码

bash

    #查看配额状态
    kubectl get quto -n development
  
    #查看配额详情
    kubectl describe quota compute-quota -n development

3.5配额限制导致的错误

若Pod未声明 resources.requests 与 resources.limits ，且所在命名空间已启用ResourceQuota，

则创建失败：

Error: pods "nginx" is forbidden: failed quota: compute-quota:

must specify limits.cpu,limits.memory,requests.cpu,requests.memory

四、Pod的核心概念与结构

4.1 Pod的定义与最小单元属性

Pod是Kubernetes中最小的可部署、可管理的计算单元。

类比：豌豆荚与豌豆

Pod = 豌豆荚（逻辑宿主）

容器 = 豌豆（实际运行的工作负载）

4.2Pod内容器的共享机制

同一Pod内的所有容器共享：

|-------------|--------------------------|
| 共享资源 | 说明 |
| 网络命名空间 | 同一IP、端口空间、可通过localhost互通 |
| 存储卷 | 共享数据存储 |
| IPC命名空间 | 进程间通信 |
| UTS命名空间 | 主机名与域名 |
| PID命名空间 | 进程ID（可选） |

注意：Pod内不应混布异构服务（如Web服务器与MySQL），否则端口冲突、健康检查逻辑复杂

化。

4.3 Pod的三种特殊容器类型

|-------------------------|-----------------------|--------------------|
| 类型 | 说明 | 用途 |
| Init Container | 初始化容器，必须先于主容器启动并成功完成 | 前置准备任务（等待依赖、下载配置） |
| Ephemeral Container | 临时容器，可在运行中注入 | 调试排查问题 |
| Sidecar Container | 边车容器，伴随主容器运行 | 日志收集、监控代理 |

4.4 Pod的生命周期特征

1.并置且同调度：所有容器必须在同一节点启动

2.任一容器启动失败 → Pod处于Pending或CrashLoopBackOff状态

3.所有容器共享Linux命名空间与cgroups，形成统一的隔离边界

五、Pod的创建流程（五步核心机制）

六、Pod资源清单（YAML）关键字段详解

6.1 核心四段式结构

bash 复制代码

yaml

    # 第一段：API版本
    apiVersion: v1

    # 第二段：资源类型
    kind: Pod
   
    # 第三段：元数据
    metadata:
      name: nginx-pod
      namespace: default
      labels:
         app: nginx
         env: production

    # 第四段：规格定义
    spec:
      containers:
      - name: nginx
      image: nginx:1.21
      imagePullPolicy: IfNotPresent
      ports:
      - containerPort: 80
        protocol: TCP
      resources:
        requests:
           cpu: "500m"
           memory: "1Gi"
        limits:
           cpu: "1"
           memory: "2Gi"
      restartPolicy: Always

6.2 关键字段说明

|--------------------------|------------------|--------|
| 字段 | 说明 | 必填 |
| apiVersion | Kubernetes API版本 | √ |
| kind | 资源类型 | √ |
| metadata.name | Pod名称 | √ |
| spec.containers[] | 容器数组 | √ |
| containers[].name | 容器名称 | √ |
| containers[].image | 镜像名称 | √ |
| containers[].resources | 资源请求与限制 | |

6.3 imagePullPolicy镜像拉取策略

|--------------|---------------|
| 策略 | 说你 |
| Always | 每次都拉取最新镜像 |
| IfNotPresent | 本地不存在时才拉取（默认） |
| Never | 从不拉取，仅使用本地镜像 |

6.4resources资源配置

bash 复制代码

yaml

    resources:
      requests:        # 请求资源（调度依据）
        cpu: "500m"    # 0.5核CPU
        memory: "1Gi"  # 1GB内存
      limits:          # 资源上限（运行时限制）
        cpu: "1"       # 1核CPU
        memory: "2Gi"  # 2GB内存

注意：内存单位必须使用 Gi 、 Mi 等标准二进制前缀，不可写 2G 。

七、Pod探针（Probes）机制与类型

7.1 探针目的

主动检测Pod内容器的健康状态，确保其真正可提供服务，而非仅进程存活。

由Kubelet执行，非容器自身逻辑。

7.2 三类探针及其适用场景

7.3 三种探测方式与精度对比

|---------------|--------------------------|--------|-----------|
| 方式 | 说明 | 精度 | 适用场景 |
| exec | 在容器内执行命令，返回码0为成功 | 低 | 验证进程/文件存在 |
| httpGet | 发送HTTP GET请求， 2xx/3xx为成功 | 中 | Web服务 |
| tcpSocket | 尝试与指定端口建立 TCP连接 | 高 | 所有监听端口的服务 |

探测方式示例：

bash 复制代码

yaml
     
    # httpGet方式
    livenessProbe:
       httpGet:
          path: /health
          port: 80
       initialDelaySeconds: 5
       periodSeconds: 10
    
    # tcpSocket方式
    livenessProbe:
       tcpSocket:
          port: 3306
       initialDelaySeconds: 5
       periodSeconds: 10

7.4探针通用参数

|---------------------|-----------------|
| 参数 | 说明 |
| initialDelaySeconds | 容器启动后延迟多久开始探测 |
| periodSeconds | 探测间隔 |
| timeoutSeconds | 单次探测超时时间 |
| successThreshold | 失败后连续成功多次视为恢复 |
| failureThreshold | 连续失败多次触发动作（如重启） |

八、标签（Labels）与选择器（Selectors）管理

8.1 标签的核心作用

为Kubernetes资源对象添加可查询、可组织的键值对元数据。

用途：

1.资源分组

2.批量操作

3.Service/Deployment等控制器关联

8.2 标签使用规范

|--------|--------------------------------------|
| 规范 | 说明 |
| √ | 同一命名空间内，不同资源可拥有相同标签 |
| √ | 标签应具有业务语义（如 app: nginx 、 env: prod ） |
| × | 不相关资源严禁共用同一标签 |

8.3标签管理命令

bash 复制代码

bash

    #增加标签
    kubectl label pods nginx-pod env=staging

    #修改标签
    kubectl label pods nginx-pod env=production --overwrite

    #删除标签
    kubectl label pods nginx-pod env-

    #按标签查询
    kubectl get pods -l app=nginx

    #按标签删除
    kubectl delete pods -l app=nginx

九、常见故障与排错要点

9.1Pod处于Pending状态

常见原因：

|---------------------|--------------------|
| 原因 | 说明 |
| 资源请求超限 | 无足够节点满足requests |
| 节点污点 | Taint无匹配Toleration |
| 镜像拉取失败 | magePullBackOff |
| ResourceQuota拒绝 | 配额不足 |

排除命令：

bash 复制代码

bash

    kubectl describe pod <pod-name> -n <namespace>
    #查看Events事件与Conditions字段

9.2命名空间无法删除（卡在Terminating）

原因：Finalizer机制阻塞

强制解除方法：

bash 复制代码

bash

    #导出命名空间JSON
    kubectl get namespace <name> -o json >tmp.json

    #编辑tmp.json,清空spec.finalizers数组

    #应用修改
    kubectl replace --raw "/api/v1/namespaces/<name>/finalize" -f tmp.json

9.3资源清单编辑常见错误

|-----------------------|--------------------------|
| 错误 | 正确写法 |
| 不可见Unicode字符（如U+00A0） | 使用纯ASCII编辑器 |
| containerpor | containerPort |
| 内存写 2G | 2Gi |
| 缺失必填字段 | 补充 containers[].name 等 |

总结

|-----------|----------------------------------------------------|
| 模块 | 核心要点 |
| 命名空间 | 逻辑隔离、集群级vs命名空间级资源、 ResourceQuota配额 |
| Pod结构 | 最小部署单元、容器共享资源、三种特殊容器 |
| 创建流程 | 五步：提交→持久化→调度→执行→上报 |
| 资源清单 | 四段式结构、必填字段、资源配置 |
| 探针机制 | Liveness/Readiness/Startup、exec/httpGet/ tcpSocket |
| 标签管理 | 键值对元数据、资源分组、批量操作 |

实践要点 ：命名空间启用ResourceQuota后，Pod必须声明resources；探针探测方式优先选择

tcpSocket（精度高）；资源清单避免Unicode字符和单位错误。