今天学习kubernets管理平台。
一、集群管理
1.1集群管理命令
Kubernetes 集群的管理主要通过 kubectl 命令行工具完成。以下是一些常用命令：
| 命令 | 说明 |
|---|---|
kubectl get nodes |
查看集群节点状态 |
kubectl cluster-info |
查看集群基本信息 |
kubectl describe node <node-name> |
查看节点详细信息 |
kubectl get componentstatuses |
查看控制平面组件状态（已弃用，建议使用 kubectl get --all-namespaces 查询核心组件） |
kubectl taint node <node> key=value:NoSchedule |
为节点设置污点，控制 Pod 调度 |
kubectl cordon <node> |
标记节点为不可调度 |
kubectl uncordon <node> |
恢复节点调度能力 |
kubectl drain <node> |
安全驱逐节点上的所有 Pod（用于维护） |
1.2 管理主机授权
主节点（Control Plane）是集群的大脑，包含 API Server、etcd、Scheduler、Controller Manager 等组件。对其授权管理至关重要。
核心机制：RBAC（基于角色的访问控制）
Kubernetes 使用 RBAC 实现权限控制，主要涉及以下资源对象：
- Role / ClusterRole：定义权限规则（如：读取 Pods、创建 Deployments）
- RoleBinding / ClusterRoleBinding：将角色绑定到用户或组
示例：用 YAML 配置定义了 Kubernetes 中的 RBAC（基于角色的访问控制）规则，用于在 default 命名空间中为用户 alice 创建一个只读权限的角色。让我为你详细解释
# 第一部分：定义 Role（角色）
#创建一个命名空间内的只读角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default # 角色作用的命名空间
name: pod-reader # 角色名称
rules:
- apiGroups: [""] # API 组，空字符串表示核心 API 组
resources: ["pods"] # 该角色可访问的资源类型（这里是 pods）
verbs: ["get", "list", "watch"] # 允许的操作（都是只读操作）
第二部分：定义 RoleBinding（角色绑定）
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods # 绑定名称
namespace: default # 绑定作用的命名空间
subjects:
- kind: User # 被绑定的主体类型（这里是用户）
name: alice # 用户名
apiGroup: "" # 用户所在的 API 组
roleRef:
kind: Role # 引用的角色类型
name: pod-reader # 引用的角色名称（与上面定义的 Role 对应）
apiGroup: "" # 角色所在的 API 组Role是命名空间级别的资源，仅在指定的命名空间内有效rules定义了该角色拥有的权限：get：获取单个 Pod 的详细信息list：列出命名空间中的所有 Podwatch：实时监控 Pod 的变化
RoleBinding用于将前面定义的Role绑定到特定用户subjects指定了被授予权限的对象（这里是用户alice）roleRef指定了要绑定的角色（这里是前面定义的pod-reader）
整体效果
应用这个配置后，用户 alice 将在 default 命名空间中获得对 Pod 的只读权限，即可以查看 Pod 信息，但不能创建、修改或删除 Pod。这是 Kubernetes 中实现权限控制的标准方式，遵循最小权限原则。
🛡️ 安全建议：
- 不要轻易授予
cluster-admin权限。 - 使用 ServiceAccount 代替用户账户进行应用授权。
- 定期审计权限配置。
1.3资源对象的概述
1.3.1 什么是资源对象
在 Kubernetes 中，资源对象（Resource Object） 是集群状态的抽象表示，用于描述你希望系统运行的状态（声明式配置）。
常见资源对象包括：
| 类型 | 说明 |
|---|---|
| Pod | 最小部署单元，运行一个或多个容器 |
| Deployment | 管理 Pod 的副本与更新（推荐用于无状态应用） |
| Service | 为 Pod 提供稳定的网络访问入口 |
| ConfigMap | 存储非敏感配置数据 |
| Secret | 存储敏感信息（如密码、密钥） |
| Namespace | 资源逻辑隔离 |
| StatefulSet | 用于有状态应用（如数据库） |
| DaemonSet | 确保每个节点运行一个 Pod（如日志采集） |
| Job / CronJob | 执行一次性或定时任务 |
特点：声明式 API，你只需描述"想要什么"，Kubernetes 控制器会自动维持该状态。
1.3.2 如何创建对象资源
有两种主要方式：
-
命令式命令（Imperative Commands）
kubectl run nginx --image=nginx:latest --port=80缺点：不易版本控制、难以复用，不推荐用于生产。
-
声明式配置（Declarative Configuration）------推荐方式
使用 YAML 文件定义资源，通过
kubectl apply -f xxx.yaml创建。kubectl apply -f deployment.yaml优点：可版本控制、可复用、可审计、适合 CI/CD。
二、pod详解
2.1 pod概述
2.1.1 什么是pod
Pod 是 Kubernetes 中最小的调度和管理单元。它封装了一个或多个紧密关联的容器，共享以下资源：
- 网络命名空间（共享 IP 和端口）
- 存储卷（Volume）
- IPC 和 UTS 命名空间
举例：一个 Pod 中可以包含一个主应用容器和一个日志收集 sidecar 容器。
2.1.2为什么需要 Pod？
- 容器本身不具备"协作"能力，Pod 提供了一种逻辑上的"主机"概念。
- 允许多个容器协同工作（如：主应用 + sidecar）。
- 实现更灵活的部署模型（如：initContainer 初始化容器）。
Pod 的 5 种核心 Phase（阶段）
| Phase | 说明 |
|---|---|
| Pending | Pod 创建过程中，但是它尚未被调度成功。 |
| Running | Pod 已调度到节点，且至少有一个容器正在运行 |
| Succeeded | 所有容器都已成功执行完毕并退出（如 Job 完成） |
| Failed | 至少有一个容器以失败状态退出（非 0 状态码） |
| Unknown | 无法获取 Pod 状态（通常因节点失联） |
2.1.3pod的创建过程
当执行 kubectl apply -f pod.yaml 后，Kubernetes 内部发生了什么？
- API Server 接收请求，验证并持久化到 etcd。
- Scheduler 监听到未调度的 Pod，选择合适的节点（基于资源、亲和性等）。
- kubelet（运行在目标节点上）收到 Pod 创建指令。
- 容器运行时（如 containerd）拉取镜像并启动容器。
- 健康检查（liveness/readiness probe）开始运行。
- Pod 状态变为
Running。
🔍 可通过
kubectl describe pod <name>查看事件日志，排查创建失败原因。
2.2 pod管理命令
| 命令 | 说明 |
|---|---|
kubectl get pods |
列出 Pod |
kubectl get pods -o wide |
显示 Pod 所在节点 |
kubectl describe pod <name> |
查看 Pod 详细信息（事件、容器状态等） |
kubectl logs <pod-name> |
查看容器日志 |
kubectl logs <pod-name> -c <container> |
查看多容器 Pod 中指定容器日志 |
kubectl exec -it <pod-name> -- sh |
进入容器交互式终端 |
kubectl delete pod <name> |
删除 Pod（Deployment 会自动重建） |
|-----------------------------------|--------------------------|
| kubectl cp 源文件 目标文件 [pod名:绝对路径] | 删除 Pod（Deployment 会自动重建） |
注意：直接删除 Pod 通常不会影响 Deployment 管理的应用，因为控制器会自动重建。
三、资源监控指标
3.1资源指标概述
Kubernetes 支持对集群资源使用情况进行监控，主要包括：
- CPU 使用率
- 内存使用量
- 网络 I/O
- 存储使用
这些指标用于：
- 故障排查
- 自动扩缩容（HPA）
- 成本优化
3.2 Meterics组件安装
Metrics Server 是 Kubernetes 的核心监控组件，负责聚合各节点的资源指标。
安装步骤（以主流方式为例）：
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 编辑 components.yaml，添加 --kubelet-insecure-tls
containers:
- name: metrics-server
image: registry.k8s.io/metrics-server/metrics-server:v0.6.4
args:
- --kubelet-insecure-tls
kubectl apply -f components.yaml验证安装：
kubectl top nodes
kubectl top pods如果能正常显示 CPU 和内存使用，则安装成功。
3.3监控资源指标
常用命令：
| 命令 | 说明 |
|---|---|
kubectl top node |
查看节点资源使用 |
kubectl top pod |
查看 Pod 资源使用 |
kubectl top pod --containers |
查看 Pod 内各容器资源使用 |
📊 进阶：生产环境建议使用 Prometheus + Grafana 实现更全面的监控告警。
四、资源清单文件
4.1 什么是资源清单文件
资源清单文件（Manifest File） 是一个 YAML 或 JSON 格式的文件，用于声明 Kubernetes 资源对象的期望状态。
它包含以下关键字段：
apiVersion: apps/v1 # API 版本
kind: Deployment # 指定资源类型为 Deployment，用于管理 Pod 的副本集和滚动更新
metadata:
name: nginx-deployment # 名称 定义 Deployment 的名称为 nginx-deployment
labels:
app: nginx
#副本与 Pod 模板
spec:
replicas: 3 # replicas: 3：指定运行 3 个相同的 Pod 副本以实现高可用
selector:
matchLabels:
app: nginx
template: # template：定义 Pod 的配置模板，包括容器镜像、端口等
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21 使用 Nginx 1.21 版本的官方镜像
ports:
- containerPort: 80 暴露容器内的 80 端口，用于 HTTP 流量metadata.labels 和 spec.selector.matchLabels：通过标签 app: nginx 关联 Pod 模板与选择器，确保 Deployment 管理正确的 Pod
核心功能
该配置会创建 3 个 Nginx Pod，并通过 Service 或 Ingress 对外提供服务
支持滚动更新和回滚，修改镜像版本后会自动替换旧 Pod
4.3 为什么使用资源清单文件
| 优势 | 说明 |
|---|---|
| 可版本控制 | 使用 Git 管理配置变更历史 |
| 可复用 | 同一份文件可用于开发、测试、生产环境 |
| 可审计 | 谁在什么时候修改了什么？一目了然 |
| 支持 CI/CD | 与 Jenkins、ArgoCD 等工具集成 |
| 减少人为错误 | 避免手动命令出错 |
对比：命令式操作无法追溯、难以协作。
4.4 资源清单文件可以做什么
- 定义应用部署（Deployment）
- 暴露服务（Service）
- 挂载配置（ConfigMap）
- 存储密钥（Secret）
- 设置资源限制（requests/limits）
- 配置健康检查（liveness/readiness probe）
- 实现自动扩缩容（HPA）
- 管理有状态应用（StatefulSet）
- 执行定时任务（CronJob）
实践建议：将不同资源分类存放，如
deployments/,services/,configs/。
4.5 清单文件创建pod
这是 Kubernetes 最基础也是最重要的操作之一。下面我们通过一个完整示例来演示如何用 YAML 文件创建 Pod。
示例：创建一个 Nginx Pod
文件名：pod-nginx.yaml
apiVersion: v1 # 定义Kubernetes API版本（v1是核心API版本）
kind: Pod # 资源类型：Pod是Kubernetes中最小的部署单元
metadata: # 元数据部分
name: nginx-pod # Pod名称（需唯一）
labels: # 标签用于分类和选择器匹配
app: nginx # 标识应用类型
environment: demo # 标记环境类型
spec: # 规格定义
containers: # 容器列表
- name: nginx-container # 容器名称
image: nginx:1.21 # 使用Nginx官方1.21版本镜像
ports: # 端口配置
- containerPort: 80 # 容器内部监听80端口
name: http # 端口命名（可选）
resources: # 资源请求/限制（单位：Mi=MiB，m=毫核）
requests: # 最低资源保障（调度依据）
memory: "64Mi" # 最低64Mi内存 cpu: "250m" # 最低0.25个CPU核心
cpu: "250m"
limits: # 资源使用上限
memory: "128Mi" # limits: memory: "128Mi"
cpu: "500m" # 最多128Mi内存 cpu: "500m" # 最多0.5个CPU核心
readinessProbe: # 就绪探针（检查容器是否准备好接收流量）
httpGet: # HTTP探测方式
path: / # 检查根路径
port: 80 # 使用http端口
initialDelaySeconds: 5 # 启动后5秒开始探测
periodSeconds: 10 # 每10秒探测一次
livenessProbe: # 存活探针（检查容器是否健康运行）
httpGet:
path: /
port: 80
initialDelaySeconds: 15 # 启动后15秒开始探测
periodSeconds: 20 # 每20秒探测一次
restartPolicy: Always # 重启策略：Always表示容器退出时总是重启创建 Pod
kubectl apply -f pod-nginx.yaml验证
kubectl get pods
kubectl describe pod nginx-pod
kubectl logs nginx-pod进阶技巧
-
使用 ConfigMap 注入配置
env: - name: ENV_NAME valueFrom: configMapKeyRef: name: app-config key: environment -
挂载存储卷
volumes: - name: html-volume emptyDir: {} containers: volumeMounts: - name: html-volume mountPath: /usr/share/nginx/html -
多容器 Pod（Sidecar 模式）
在同一 Pod 中运行 Nginx 和一个日志同步容器，共享存储卷。
提示：虽然可以直接创建 Pod，但生产环境强烈建议使用 Deployment 管理 Pod，以实现滚动更新、自动恢复等功能。
总结
| 模块 | 核心要点 |
|---|---|
| 集群管理 | kubectl 命令、RBAC 授权、节点维护 |
| Pod | 最小单元、共享网络/存储、生命周期管理 |
| 监控 | Metrics Server、kubectl top、HPA 基础 |
| 清单文件 | 声明式配置、YAML 结构、GitOps 基础 |