云计算基础概念

一、IaaS / PaaS / SaaS 核心区别 📊

维度 IaaS 🏗️ PaaS ⚙️ SaaS 📦
一句话 租虚拟机,自己装系统 只管写代码部署 开箱即用
用户管 OS、中间件、应用、数据 应用代码和数据 几乎不用管
厂商管 虚拟化、硬件、网络 运行时、OS、硬件 全部(应用→硬件)
典型产品 AWS EC2、阿里云 ECS Google App Engine、Heroku Gmail、Salesforce
运维负担 🔴 高 🟡 中 🟢 低

二、公有云 / 私有云 / 混合云 ☁️

维度 公有云 🌐 私有云 🔒 混合云 🔗
通俗类比 共享写字楼 独栋别墅 别墅+写字楼组合
资源归属 厂商所有,多租户共享 企业专属独享 核心私有+弹性公有
成本门槛 低,按量付费 高,硬件+团队投入 中,固定+弹性组合
安全合规 中等 高,满足等保 中-高
弹性扩容 极高,分钟级 低,需提前采购 高,公有部分弹性
运维难度

三、典型场景 🎯

  • IaaS:传统 IDC 迁移上云、大数据集群搭建、游戏渲染
  • PaaS:Web/API 后端开发、微服务架构、Serverless 函数计算
  • SaaS:企业办公、CRM、项目管理
  • 公有云:初创快速启动、电商大促弹性扩容
  • 私有云:金融/政务/医疗等强合规行业
  • 混合云:核心数据留本地+峰值弹性上云(云爆发)

四、运维特点 🔧

维度 IaaS PaaS SaaS
监控重点 CPU/内存/磁盘/网络 延迟/错误率/并发 业务指标
OS 补丁/中间件 用户管 厂商管 厂商管
弹性伸缩 自动/快 自动/极快 厂商负责
团队要求 Linux+网络+自动化 开发者+APM 无需运维背景

核心趋势:IaaS → PaaS → SaaS,运维工作逐步转移给云厂商,企业角色从”修机器”转向”管资源、定策略” 🔄。

🔗 相关文档

OpenStack 概述 | Docker 架构解析 | Kubernetes 核心概念全景 | 容器核心概念:容器与虚拟机的区别

Kubernetes网络模型与实现详解 🌐

CNI 插件配置 🔌

Flannel 安装与配置 🚀

CNI(Container Network Interface) 是Kubernetes标准化的网络插件接口规范,负责容器网络接口的动态配置与管理,实现跨节点Pod间通信和网络资源分配。
安装命令:

1
2
3
4
5
6
7
8
9
10
# 下载 Flannel 配置文件
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
# 拉取 Flannel 镜像
docker pull quay.io/coreos/flannel:v0.14.0
# 安装 Flannel
kubectl create -f kube-flannel.yml
# 查看 Flannel 状态
kubectl get pod -n kube-system
# 卸载 Flannel
kubectl delete -f kube-flannel.yml

关键配置参数:

  • 网络配置:"Network": "10.244.0.0/16" # Pod网络CIDR
  • 后端类型:"Type": "vxlan" # 虚拟可扩展局域网
  • 部署方式:DaemonSet # 每个节点运行一个实例
  • CNI 配置路径:/etc/cni/net.d/10-flannel.conflist

Calico 安装与配置 🐱

Calico 是高性能的CNI插件,提供网络策略、BGP路由和细粒度安全控制,支持大规模企业级Kubernetes集群。
安装命令:

1
2
3
4
5
6
7
8
# 下载 Calico 配置文件
wget https://docs.projectcalico.org/manifests/calico.yaml
# 安装 Calico
kubectl apply -f calico.yaml
# 查看 Calico 状态
kubectl get pod -n kube-system | grep calico
# 应用自定义配置
kubectl apply -f calico-installation.yaml

关键配置参数:

  • CNI 网络配置:"name": "k8s-pod-network" # 网络名称
  • 支持网络策略功能 # Pod间访问控制
  • etcd 配置(可选) # 分布式键值存储
  • MTU 值可调整 # 最大传输单元

Service 类型配置 🌐

ClusterIP Service 🏠

ClusterIP 是Kubernetes默认的Service类型,为集群内部应用提供虚拟IP地址,实现Pod间负载均衡和服务发现。
创建命令:

1
2
3
4
5
6
# 创建 ClusterIP Service
kubectl create service clusterip my-service --tcp=80:80
# 通过 Deployment 暴露
kubectl expose deployment my-app --name=my-service --port=80 --target-port=8080
# 查看 Service
kubectl get services

配置文件示例:

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: Service
metadata:
name: my-clusterip-service
spec:
type: ClusterIP # 集群内部访问类型
selector:
app: my-app # 选择器匹配Pod标签
ports:
- protocol: TCP
port: 80 # Service端口
targetPort: 8080 # Pod目标端口

NodePort Service 🚪

NodePort 通过每个节点的IP和固定端口向集群外部暴露服务,适合测试环境和小规模部署。
创建命令:

1
2
3
4
5
6
# 创建 NodePort Service
kubectl create service nodeport my-service --tcp=80:80 --node-port=30080
# 通过 Deployment 暴露为 NodePort
kubectl expose deployment my-app --name=my-nodeport-service --port=80 --target-port=8080 --type=NodePort
# 查看 Service
kubectl get services

配置文件示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
type: NodePort # 节点端口访问类型
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
nodePort: 30080 # 节点端口(30000-32767)

LoadBalancer Service ⚖️

LoadBalancer 通过云提供商的负载均衡器向外部暴露服务,自动分配外部IP,适合生产环境。
创建命令:

1
2
3
4
5
6
# 创建 LoadBalancer Service
kubectl create service loadbalancer my-service --tcp=80:80
# 查看 LoadBalancer Service
kubectl get services
# 查看 LoadBalancer 的外部 IP
kubectl get service my-service -o wide

配置文件示例:

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: Service
metadata:
name: my-loadbalancer-service
spec:
type: LoadBalancer # 负载均衡器类型
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080

Ingress Controller 配置 🛣️

NGINX Ingress Controller 安装 🎯

Ingress Controller 是Kubernetes的HTTP/HTTPS路由控制器,基于域名和路径规则将外部流量路由到内部Service,提供七层负载均衡。
安装命令:

1
2
3
4
5
6
7
8
# 安装 NGINX Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/cloud/deploy.yaml
# 或者使用官方 manifests
kubectl apply -f deployments/deployment/nginx-ingress.yaml
# 查看 Ingress Controller 状态
kubectl get pods -n ingress-nginx
# 查看 Ingress Controller Service
kubectl get svc -n ingress-nginx

Ingress 资源配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: / # URL重写规则
spec:
ingressClassName: nginx # Ingress类名
rules:
- host: my-app.example.com # 域名
http:
paths:
- path: / # 路径匹配
pathType: Prefix # 前缀匹配类型
backend:
service:
name: my-service # 后端Service名称
port:
number: 80 # 后端Service端口

NGINX Ingress Controller Service 配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: v1
kind: Service
metadata:
name: nginx-ingress-lb
namespace: kube-system
labels:
app: nginx-ingress-lb
spec:
type: LoadBalancer # 负载均衡器类型
ports:
- port: 80 # HTTP端口
targetPort: 80 # 容器端口
protocol: TCP
name: http
- port: 443 # HTTPS端口
targetPort: 443
protocol: TCP
name: https
selector:
app: nginx-ingress-lb # 选择器匹配Pod标签

通用管理命令 🛠️

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 查看所有 Service
kubectl get services --all-namespaces
# 查看 Service 详细信息
kubectl describe service my-service
# 查看 Service 端点
kubectl get endpoints
# 查看 Ingress 资源
kubectl get ingress --all-namespaces
# 查看 Ingress 详细信息
kubectl describe ingress my-ingress
# 查看 CNI 插件状态
kubectl get pods -n kube-system | grep -E 'flannel|calico'
# 查看节点网络状态
kubectl get nodes -o wide

注意事项 ⚠️

  • 确保所有命令和配置文件准确无误
  • 根据实际环境调整网络配置参数
  • 定期检查网络组件状态,确保集群网络正常运行

🔗 相关文档

Kubernetes核心概念详解 | Kubernetes调度与部署机制详解 | Kubernetes安全基础

声明式YAML管理 📄

YAML文件基本结构

YAML文件主要包含四个部分:

  1. apiVersion:指定API版本
  2. kind:资源类型(如Deployment、Service、Pod等)
  3. metadata:元数据(名称、命名空间、标签等)
  4. spec:资源规格配置

YAML语法规则

  • 大小写敏感 ⚠️
  • 使用缩进表示层级关系,不支持Tab键
  • 缩进空格数目不重要,相同层级左对齐即可
  • 使用#号表示注释 💬
  • 符号字符后缩进一个空格(冒号、逗号、横杠等)

声明式管理命令

1
2
3
kubectl create -f XXXX.YAML  # 从YAML文件创建资源
kubectl apply -f XXXX.YAML # 应用配置变更,支持更新
kubectl delete -f XXXX.YAML # 根据YAML文件删除资源

kubectl常用命令 ⚡

基础命令

1
2
3
4
5
6
7
kubectl get pod  # 列出所有Pod
kubectl get pod -n NAMESPACE # 列出指定命名空间的Pod
kubectl get pod -o wide # 显示详细信息包括IP和节点
kubectl get all # 列出所有资源
kubectl describe pod POD-NAME # 显示Pod详细信息
kubectl logs POD-NAME # 查看Pod日志
kubectl logs -f POD-NAME # 实时跟踪日志输出

资源管理命令

1
2
3
4
5
kubectl create -f YAML-FILE  # 从文件创建资源
kubectl apply -f YAML-FILE # 应用配置变更
kubectl delete -f YAML-FILE # 删除文件中定义的资源
kubectl edit RESOURCE-TYPE RESOURCE-NAME # 编辑资源配置
kubectl scale deployment DEPLOY-NAME --replicas=3 # 扩缩容到3个副本

部署管理命令

1
2
3
4
kubectl rollout status deployment/DEPLOY-NAME  # 查看部署状态
kubectl rollout history deployment/DEPLOY-NAME # 查看部署历史
kubectl rollout undo deployment/DEPLOY-NAME # 回滚到上一版本
kubectl set image deployment/DEPLOY-NAME CONTAINER-NAME=IMAGE:TAG # 更新容器镜像

故障排查命令

1
2
3
4
kubectl exec -it POD-NAME -- bash  # 进入容器交互式shell
kubectl cp LOCAL-FILE POD-NAME:/path # 在本地和容器间复制文件
kubectl top pod # 查看Pod资源使用情况
kubectl top nodes # 查看节点资源使用情况

Namespace隔离 🏗️

Namespace概念

Namespace是K8s中用于隔离和组织资源的机制,将物理集群划分为多个逻辑部分,每个部分有自己的一组资源 🔄

默认Namespace

  • default:所有未指定Namespace的对象默认分配
  • kube-system:K8s系统创建的资源 🖥️
  • kube-public:可被所有人访问的资源 🌐
  • kube-node-lease:节点心跳维护 💓

Namespace管理命令

1
2
3
4
5
kubectl create namespace NAMESPACE-NAME  # 创建命名空间
kubectl get namespace # 列出所有命名空间
kubectl get ns # 列出命名空间的简写形式
kubectl delete namespace NAMESPACE-NAME # 删除命名空间
kubectl config set-context --current --namespace=NAMESPACE-NAME # 设置当前上下文的默认命名空间

Namespace隔离特性

  1. 资源对象隔离:Service、Deployment、Pod等资源在不同Namespace中相互隔离 📦
  2. 资源配额隔离:可以限制不同Namespace的CPU、内存使用量 📊
  3. 权限控制:通过RBAC对不同Namespace进行权限管理 🔐
  4. 网络隔离:默认情况下不同Namespace的Pod可以互相访问,可通过NetworkPolicy实现网络隔离 🌐

网络隔离配置

通过NetworkPolicy实现Namespace间网络隔离:

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all # 拒绝所有网络流量
namespace: target-ns # 应用到目标命名空间
spec:
podSelector: {} # 选择所有Pod
policyTypes:
- Ingress # 入站流量
- Egress # 出站流量
ingress: [] # 空数组表示拒绝所有入站流量
egress: [] # 空数组表示拒绝所有出站流量

资源配额管理

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: ResourceQuota
metadata:
name: resource-quota # 配额名称
namespace: prod # 应用到生产环境命名空间
spec:
hard: # 硬性限制
requests.cpu: "1" # CPU请求总量不超过1核
requests.memory: "1Gi" # 内存请求总量不超过1GB
limits.cpu: "2" # CPU限制总量不超过2核
limits.memory: "4Gi" # 内存限制总量不超过4GB
pods: "10" # Pod数量不超过10个

实际应用场景

  1. 按环境划分:dev、test、prod 🌍
  2. 按团队划分:不同团队使用不同Namespace 👥
  3. 按项目划分:每个项目独立Namespace 📁
  4. 多租户隔离:实现资源隔离和权限控制 🏢

🔗 相关文档

Kubernetes调度与部署机制详解 | Kubernetes可观测性完整指南

私有云 OpenStack 学习路径 🚀

学习私有云 OpenStack 通常建议按”基础概念 → 核心组件 → 架构部署 → 运维排错 → 性能调优”的顺序推进。

1. 第一阶段:云计算与 OpenStack 基础 ☁️

  • 云计算基础:IaaS / PaaS / SaaS 区别,私有云 / 公有云 / 混合云概念,典型应用场景与运维特点
  • OpenStack 概述:起源(NASA + Rackspace)、主要版本演进、核心价值(开源、可扩展、API 驱动)
  • 架构与角色:控制节点、计算节点、网络节点、存储节点的分工,以及多节点协同方式

2. 第二阶段:核心组件(必备)⚙️

Keystone(认证)🔐

  • 核心概念:User / Project / Role / Domain / Endpoint / Token
  • 认证流程:用户凭据 → Token → 服务访问,理解 Keystone 作为”统一门卫”的角色

Nova(计算)💻

  • 架构:nova-api / nova-scheduler / nova-conductor / nova-compute
  • 虚拟化支持:KVM / QEMU / Xen 等,虚拟机生命周期与调度策略

Neutron(网络)🌐

  • 网络模型:Provider Network / Self-Service Network / 路由器 / 安全组
  • 插件架构:ML2 + Linux Bridge / Open vSwitch,理解 SDN 思想与虚拟网络实现

Glance(镜像)📦

  • 镜像管理:镜像格式(QCOW2 / RAW / VMDK / ISO)、上传/下载/共享
  • 后端存储:本地文件 / Swift / Ceph 等,镜像与后端存储解耦

3. 第三阶段:存储组件(常用)💾

Cinder(块存储)🔲

  • 核心功能:为虚拟机提供持久化块存储(卷),创建/挂载/扩展/快照
  • 常见后端:LVM / NFS / iSCSI / Ceph RBD / GlusterFS

Swift(对象存储)🗂️

  • 核心概念:Account / Container / Object,一致性哈希与数据冗余
  • 应用场景:备份归档、图片/视频、非结构化数据存储

4. 第四阶段:管理组件(常用)🎛️

Horizon(Web 界面)🖥️

  • 功能:项目/用户/网络/存储/虚拟机的可视化管理与自助服务
  • 定制:主题、品牌、功能模块扩展

Heat(编排)🔥

  • 核心思想:基于 HOT 模板的基础设施即代码,自动化创建/更新/删除一组资源
  • 与 AWS CloudFormation 兼容,理解 stack / resource / parameter

Ceilometer(监控计量)📊

  • 数据采集:轮询(polling)与通知(notification),资源使用率与计费数据
  • 与告警/计费系统集成,为性能调优和成本分析提供数据基础

5. 第五阶段:架构设计与部署(最低实践要求)🏗️

硬件规划(最低)🖥️

  • 控制节点:4 核 CPU / 8 GB 内存 / 100 GB 磁盘 / 千兆网卡
  • 计算节点:4 核 CPU(支持硬件虚拟化) / 8 GB 内存 / 100 GB 磁盘 / 千兆网卡
  • 存储:可与计算节点合并或独立少量磁盘

网络架构(简化)🔗

  • 最少:管理 + 数据 + 存储合一的物理网络,外加单独外部网络
  • 生产建议:管理 / 数据 / 存储 / 外部多平面分离,Spine-Leaf 或三层架构

部署工具选择 🛠️

  • DevStack:All-in-One 快速实验,适合学习与验证
  • Kolla-Ansible:容器化生产部署,推荐用于真实私有云搭建
  • TripleO / Packstack:裸机或传统部署方式,按需了解

6. 第六阶段:运维排错思路 🔧

日志与状态 📝

  • 日志路径:/var/log/keystone、nova、neutron、glance、cinder 等
  • 服务状态openstack-status / openstack-service status / systemctl status

典型排错流程 🔍

  • Keystone:5000/35357 端口、数据库连接、endpoint 配置、Apache 状态
  • Novanova service-list、虚拟化支持、计算节点服务、调度器日志
  • Neutronneutron agent-list、插件配置、OVS/Bridge 状态、DHCP/L3 代理
  • Cindercinder service-list、后端连接、卷组空间、日志中的错误信息

监控与备份 📈

  • 资源监控:Prometheus + Grafana / Ceilometer,关注 API 响应时间、虚拟机启动时间、存储 I/O
  • 备份恢复:数据库每日全量 + 增量、镜像定期备份、配置文件版本控制

7. 第七阶段:性能调优 ⚡

数据库与缓存 🗄️

  • MariaDBinnodb_buffer_pool_size / innodb_log_file_size / max_allowed_packet 等参数调优
  • Memcached:内存大小 / 最大连接数 / hash 算法调整

计算与调度 🔄

  • Nova:CPU/内存超分比(cpu_allocation_ratio / ram_allocation_ratio)、缓存调度器、大页内存

存储与后端 💿

  • Cinder:LVM 条带化、SSD 缓存、后端多路径与队列深度
  • Ceph:OSD journal / op threads / disk threads 调优

网络与内核 🌐

  • OVS:队列长度、DPDK 加速(OVS-DPDK)、VXLAN 封装优化
  • 内核:TCP 参数(somaxconn / tcp_window_scaling / tcp_fastopen)、文件系统挂载选项(noatime/nodiratime)、swappiness 调整

应用层与监控闭环 🔄

  • API 服务:Worker 数量 / 超时时间 / 连接池配置
  • Django/Horizon:会话存储改为文件或缓存,减轻数据库压力
  • 调优闭环:先建立性能基线,再用监控工具验证优化效果

8. 学习建议(精炼版)💡

  1. 从 All-in-One 开始:先用 DevStack 或单节点 Kolla 跑通最小环境,再扩展多节点
  2. 组件逐一实践:每学一个组件(Keystone/Nova/Neutron…)就完成一次部署和配置实验
  3. 多看官方文档:OpenStack 官方文档和架构指南是最权威的参考
  4. 主动制造故障:停服务、改错配置,练习排错和日志分析
  5. 关注性能与监控:从一开始就接入 Prometheus + Grafana,养成”看指标再调参”的习惯
  6. 逐步接近生产:从最低硬件与简单网络,演进到多平面网络、高可用控制面和 Ceph 后端

🔗 相关文档

OpenStack 概述 | OpenStack架构详解:四大节点分工与多节点协同 | 云计算基础概念

资源监控(Metrics Server)📈

安装和配置

  • 准备工作:确保Kubernetes版本1.8及以上,API聚合层必须启用,Kubelet必须启用Webhook认证和授权 ⚙️
  • 安装命令
    • 下载部署文件:wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
    • 高可用版本:kubectl apply -f high-availability-1.21+.yaml
    • 国内镜像替换:将registry.k8s.io/metrics-server/metrics-server:v0.7.2替换为可用镜像地址 🌏

核心参数配置

1
2
3
4
5
6
7
args:
- --kubelet-insecure-tls
- --cert-dir=/tmp
- --secure-port=10250
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
- --kubelet-use-node-status-port
- --metric-resolution=15s

使用命令

  • 查看节点资源使用:kubectl top nodes
  • 查看Pod资源使用:kubectl top pods -n <NAMESPACE>
  • 验证安装:kubectl get pods -n kube-system | grep metrics-server

日志收集(EFK)📝

EFK架构

  • Elasticsearch:分布式搜索和分析引擎,用于存储和索引日志数据 🔍
  • Fluentd:日志收集器,作为DaemonSet部署在每个节点上,收集容器日志 🔄
  • Kibana:可视化分析平台,提供日志查询和展示界面 📊

部署步骤

  1. 创建命名空间kubectl create namespace logging
  2. 部署Elasticsearch
    • 使用StatefulSet部署ES集群
    • 配置存储卷和环境变量 💾
  3. 部署Fluentd
    • 作为DaemonSet部署,确保每个节点都有实例
    • 配置RBAC权限访问Kubernetes API 🔐
  4. 部署Kibana
    • 使用Deployment部署
    • 配置Service和Ingress暴露服务 🌐

Fluentd配置要点

  • 监听路径:/var/log/containers/*.log
  • 输出目标:Elasticsearch集群
  • 使用kubernetes插件增强日志信息

常见排查命令🔧

基础状态检查

  • 查看Pod状态kubectl get pods -n <NAMESPACE>
  • 查看节点状态kubectl get nodes
  • 查看集群事件kubectl get events --all-namespaces

详细信息查询

  • 查看Pod详细信息kubectl describe pod <POD-NAME> -n <NAMESPACE>
  • 查看节点详细信息kubectl describe node <NODE-NAME>
  • 查看Service信息kubectl describe svc <SERVICE-NAME> -n <NAMESPACE>

日志查看

  • 查看容器日志kubectl logs <POD-NAME> -c <CONTAINER-NAME> -n <NAMESPACE>
  • 查看前一次日志kubectl logs <POD-NAME> --previous
  • 实时跟踪日志kubectl logs -f <POD-NAME>

容器操作

  • 进入容器kubectl exec -it <POD-NAME> -n <NAMESPACE> -- /bin/bash
  • 在容器中执行命令kubectl exec <POD-NAME> -- <COMMAND>
  • 文件拷贝kubectl cp <LOCAL-FILE> <POD-NAME>:<PATH>

网络和存储排查

  • 端口转发kubectl port-forward <POD-NAME> <LOCAL-PORT>:<POD-PORT>
  • 检查Endpointskubectl get endpoints <SERVICE-NAME> -n <NAMESPACE>
  • 检查PVC状态kubectl get pvc -n <NAMESPACE>

资源监控

  • 查看资源使用情况kubectl top nodeskubectl top pods -n <NAMESPACE>
  • 检查API服务器健康kubectl get --raw=/healthz

常见问题排查

  • Pod Pending:检查资源不足、节点Selector不匹配 ⏳
  • CrashLoopBackOff:查看应用日志,检查启动命令 🔄
  • ImagePullBackOff:检查镜像名称和认证配置 🐳
  • Service无法访问:检查Endpoints和网络策略 🌐

🔗 相关文档

Kubernetes核心概念详解 | Kubernetes调度与部署机制详解 | Kubernetes资源管理详解

Kubernetes安全基础 🛡️

RBAC(基于角色的访问控制)👥

RBAC是一种基于组织中个人用户角色来调节对计算机或网络资源访问的方法。RBAC授权使用rbac.authorization.k8s.io API组来驱动授权决策,允许您通过Kubernetes API动态配置策略。

RBAC核心对象

RBAC API声明了四种Kubernetes对象:

  • Role: 定义在特定命名空间内的权限
  • ClusterRole: 可在集群范围内使用的权限
  • RoleBinding: 将Role绑定到用户、组或ServiceAccount
  • ClusterRoleBinding: 将ClusterRole绑定到用户、组或ServiceAccount
    ServiceAccount与Role或ClusterRole绑定后,可以为Pod提供身份标识和访问权限。

Pod Security Policy(Pod安全策略)🚫

⚠️ 注意: PodSecurityPolicy已在Kubernetes v1.21中被弃用,并在v1.25中被移除。
取而代之的是Pod Security Admission(Pod安全准入控制器)或第三方准入插件来对Pod强制执行类似的限制。

Pod Security Admission(Pod安全准入)✅

Pod Security Admission根据Pod安全标准定义的三个级别,对Pod的安全上下文和其他相关字段设置要求。这是Kubernetes引入的一个功能,用于为Pod强制执行清晰一致的隔离级别。

三个安全级别

  1. Privileged: 无限制,最宽松的安全策略
  2. Baseline: 最小限度的限制,防止已知的权限提升
  3. Restricted: 严格限制,最大程度的安全保障

NetworkPolicy(网络策略)🌐

如果您希望在IP地址或端口级别(OSI第3层或第4层)控制流量,NetworkPolicy允许您为集群内的流量以及Pod与外部世界之间的流量指定规则。

使用前提

您的集群必须使用支持NetworkPolicy执行的网络插件。

功能特性

NetworkPolicy是一组规则,用于确定Pod如何相互通信以及与外部服务通信。它提供了集群网络级别的安全控制,可以限制Pod之间的网络访问。

典型应用场景

  • 限制Pod之间的网络通信
  • 控制Pod与外部服务的访问
  • 实现网络分段和隔离
  • 防止横向移动攻击

注意事项 ⚠️

  • 在生产环境中使用前,建议在测试环境充分验证
  • 定期更新安全策略以应对新的安全威胁

🔗 相关文档

Kubernetes核心概念详解 | Kubernetes网络模型与实现详解 | ConfigMap配置与密文管理详解

🚀 Kubernetes核心概念详解

📦 Pod - 最小部署单元

概念:Kubernetes中最小的可部署计算单元,封装一个或多个共享网络和存储的容器。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 创建pod
kubectl run <pod-name> --image=<image-name>
# 查看pod列表
kubectl get pods
# 查看pod详情
kubectl describe pod <pod-name>
# 删除pod
kubectl delete pod <pod-name>
# 查看pod日志
kubectl logs <pod-name>
# 进入pod容器
kubectl exec -it <pod-name> -- /bin/sh
# 查看pod资源使用
kubectl top pod

🎮 Deployment - Pod管理器

概念:管理Pod副本,提供自愈、扩缩容、滚动更新和回滚能力。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 创建deployment
kubectl create deployment <deployment-name> --image=<image-name>
# 查看deployment列表
kubectl get deployments
# 扩缩容副本数
kubectl scale deployment <deployment-name> --replicas=<number>
# 更新镜像版本
kubectl set image deployment/<deployment-name> <container-name>=<new-image>
# 查看更新状态
kubectl rollout status deployment/<deployment-name>
# 回滚版本
kubectl rollout undo deployment/<deployment-name>
# 删除deployment
kubectl delete deployment <deployment-name>

🎯 StatefulSet - 有状态应用管理

概念:管理有状态应用,保证Pod标识、网络、存储的稳定性。

1
2
3
4
5
6
# 查看statefulset列表
kubectl get statefulsets
# 扩缩容副本数
kubectl scale statefulset <statefulset-name> --replicas=<number>
# 删除statefulset
kubectl delete statefulset <statefulset-name>

🔄 DaemonSet - 节点守护进程

概念:在每个节点上运行一个Pod副本,适合日志收集、监控等系统级任务。

1
2
3
4
# 查看daemonset列表
kubectl get daemonsets
# 删除daemonset
kubectl delete daemonset <daemonset-name>

🔗 Service - 服务发现与负载均衡

概念:为Pod提供稳定的网络访问入口,支持服务发现和负载均衡。

1
2
3
4
5
6
7
8
9
10
# 创建service
kubectl expose deployment <deployment-name> --type=<service-type> --port=<port>
# 查看service列表
kubectl get services
# 查看service详情
kubectl describe service <service-name>
# 删除service
kubectl delete service <service-name>
# 查看端点
kubectl get endpoints

🌐 Ingress - HTTP路由规则

概念:配置HTTP/HTTPS路由规则,将外部流量路由到集群内部服务。

1
2
3
4
5
6
7
8
# 创建ingress
kubectl create ingress <ingress-name> --rule=<host>/<path>=<service>:<port>
# 查看ingress列表
kubectl get ingress
# 查看ingress详情
kubectl describe ingress <ingress-name>
# 删除ingress
kubectl delete ingress <ingress-name>

🛠️ 通用管理命令

配置文件管理

1
2
3
4
5
6
7
8
# 应用配置文件
kubectl apply -f <filename.yaml>
# 删除配置文件中的资源
kubectl delete -f <filename.yaml>
# 查看资源配置
kubectl get -o yaml <resource-type> <resource-name>
# 查看所有资源
kubectl get all

命名空间管理

1
2
3
4
5
6
7
8
# 查看命名空间
kubectl get namespaces
# 创建命名空间
kubectl create namespace <namespace-name>
# 设置默认命名空间
kubectl config set-context --current --namespace=<namespace-name>
# 删除命名空间
kubectl delete namespace <namespace-name>

故障排查

1
2
3
4
5
6
7
8
9
10
# 查看事件
kubectl get events
# 实时跟踪日志
kubectl logs -f <pod-name>
# 在pod中执行命令
kubectl exec -it <pod-name> -- <command>
# 查看节点资源使用
kubectl top nodes
# 查看pod资源使用
kubectl top pods

节点管理

1
2
3
4
5
6
7
8
# 查看节点
kubectl get nodes
# 标记节点不可调度
kubectl cordon <node-name>
# 恢复节点调度
kubectl uncordon <node-name>
# 驱逐节点上的pod
kubectl drain <node-name>

📝 文档说明

本文档整理了Kubernetes的核心概念和常用命令,涵盖了从基础的Pod管理到高级的服务发现和路由配置。所有命令都遵循小写命令、大写参数的规范,便于在实际工作中快速查阅和使用。

核心概念总结

  • Pod:最小部署单元,容器编排的基础
  • Deployment:无状态应用管理,支持滚动更新和回滚
  • StatefulSet:有状态应用管理,保证稳定标识和存储
  • DaemonSet:节点级守护进程,确保每个节点运行副本
  • Service:服务发现和负载均衡,提供稳定访问入口
  • Ingress:HTTP路由规则,管理外部流量访问

🔗 相关文档

Kubernetes调度与部署机制详解 | Kubernetes网络模型与实现详解 | Kubernetes存储抽象详解 | Kubernetes安全基础 | Kubernetes可观测性完整指南

ConfigMap配置管理 🔧

ConfigMap概述 💡

  • 概念: ConfigMap是Kubernetes中用于存储非敏感配置数据的API对象,以键值对形式存储配置信息
  • 实现: 提供了向Pod注入配置数据的标准方法,实现镜像与配置的解耦,提升应用的可移植性和可复用性

ConfigMap典型使用场景 🎯

  • 概念: ConfigMap在实际应用中的主要用途
  • 实现:
    • 填充环境变量的值
    • 设置容器内的命令行参数
    • 填充卷的配置文件

ConfigMap创建方式 🛠️

1. 使用字面值创建

1
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

2. 使用文件创建

1
kubectl create configmap my-config --from-file=path/to/bar

3. 使用目录创建

1
kubectl create configmap my-config --from-file=path/to/bar

4. 编写YAML文件创建

通过定义完整的YAML清单文件来创建ConfigMap对象

1
2
3
4
5
6
7
8
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: ConfigMap # 资源类型,声明为ConfigMap对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: my-config # ConfigMap的名称
namespace: default # 所属命名空间
data: # 配置数据,以键值对形式存储
key1: config1 # 配置键值对1
key2: config2 # 配置键值对2

ConfigMap注入方式 🚀

1. 环境变量方式

通过spec.envspec.envFrom进行引用配置数据

2. 卷挂载方式

通过spec.volumes引用,将ConfigMap挂载到容器内部的文件或目录

环境变量注入示例 📝

使用spec.env方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: Pod # 资源类型,声明为Pod对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: cm-pod-test001 # Pod的名称
spec: # Pod规格,定义Pod的配置
containers: # 容器列表
- name: cm-test # 容器名称
image: tomcat:8 # 容器镜像
command: ["/bin/sh", "-c", "env | grep APP"] # 容器启动命令
env: # 环境变量配置
- name: APPCONF01 # 环境变量名称
valueFrom: # 值来源配置
configMapKeyRef: # ConfigMap键引用
name: cm-test01 # ConfigMap名称
key: appconf01 # ConfigMap中的键名
- name: APPCONF02 # 环境变量名称
valueFrom: # 值来源配置
configMapKeyRef: # ConfigMap键引用
name: cm-test01 # ConfigMap名称
key: appconf02 # ConfigMap中的键名

使用spec.envFrom方式

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: Pod # 资源类型,声明为Pod对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: cm-pod-test002 # Pod的名称
spec: # Pod规格,定义Pod的配置
containers: # 容器列表
- name: cm-test2 # 容器名称
image: tomcat:8 # 容器镜像
command: ["/bin/sh", "-c", "env"] # 容器启动命令
envFrom: # 环境变量来源配置
- configMapRef: # ConfigMap引用
name: cm-test01 # ConfigMap名称,所有键值对都会作为环境变量注入

Volume挂载示例 📁

指定items的方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: Pod # 资源类型,声明为Pod对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: cm-pod-test003 # Pod的名称
spec: # Pod规格,定义Pod的配置
containers: # 容器列表
- name: cm-test3 # 容器名称
image: tomcat:8 # 容器镜像
volumeMounts: # 卷挂载配置
- name: vm-01-1 # 卷名称,与volumes中的name对应
mountPath: /conf # 挂载路径,容器内的目录路径
volumes: # 卷定义列表
- name: vm-01-1 # 卷名称
configMap: # ConfigMap卷配置
name: cm-test-file # ConfigMap名称
items: # 指定要挂载的键值对
- key: key-testproperties # ConfigMap中的键名
path: test.properties # 挂载后的文件名

不指定items的方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: Pod # 资源类型,声明为Pod对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: cm-pod-test004 # Pod的名称
spec: # Pod规格,定义Pod的配置
containers: # 容器列表
- name: cm-test4 # 容器名称
image: tomcat:8 # 容器镜像
volumeMounts: # 卷挂载配置
- name: vm-02-2 # 卷名称,与volumes中的name对应
mountPath: /conf # 挂载路径,容器内的目录路径
volumes: # 卷定义列表
- name: vm-02-2 # 卷名称
configMap: # ConfigMap卷配置
name: cm-test-file # ConfigMap名称,所有键值对都会被挂载

Secret密文管理 🔒

Secret概述 🔐

  • 概念: Secret对象与ConfigMap对象类似,专门用于存储敏感信息
  • 实现: 主要存储密码、OAuth token和SSH key等敏感数据,比直接存储在Pod定义或Docker镜像中更加安全和灵活

Secret类型 🏷️

1. Opaque类型

  • 特点: 使用base64编码存储信息
  • 安全性: 可以通过base64 --decode解码获得原始数据,安全性相对较弱

2. kubernetes.io/dockerconfigjson类型

  • 用途: 专门用于存储docker registry的认证信息

3. kubernetes.io/service-account-token类型

  • 用途: 用于被serviceaccount引用的服务账号令牌

Secret创建方式 🛠️

1. 从文件中创建Secret

1
2
3
echo -n "admin" > ./username.txt
echo -n "123456" > ./password.txt
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

2. 使用描述文件创建Secret

首先进行base64编码:

1
2
echo -n 'name' | base64
echo -n '123456' | base64

然后创建secret.yaml文件:

1
2
3
4
5
6
7
8
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: Secret # 资源类型,声明为Secret对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: mysecret # Secret的名称
type: Opaque # Secret类型,Opaque表示通用类型
data: # 敏感数据,以base64编码的键值对形式存储
username: bmFtZQ== # 用户名,base64编码后的值
password: MTIzNDU2 # 密码,base64编码后的值

Secret注入方式 🚀

1. 将Secret挂载到Volume中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: Pod # 资源类型,声明为Pod对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: mypod # Pod的名称
spec: # Pod规格,定义Pod的配置
containers: # 容器列表
- name: mypod # 容器名称
image: redis # 容器镜像
volumeMounts: # 卷挂载配置
- name: foo # 卷名称,与volumes中的name对应
mountPath: "/etc/foo" # 挂载路径,容器内的目录路径
readOnly: true # 只读挂载,增强安全性
volumes: # 卷定义列表
- name: foo # 卷名称
secret: # Secret卷配置
secretName: mysecret # Secret名称

2. 将Secret设置为环境变量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: v1 # API版本,指定使用的Kubernetes API版本
kind: Pod # 资源类型,声明为Pod对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: secret-env-pod # Pod的名称
spec: # Pod规格,定义Pod的配置
containers: # 容器列表
- name: mycontainer # 容器名称
image: redis # 容器镜像
env: # 环境变量配置
- name: SECRET_USERNAME # 环境变量名称
valueFrom: # 值来源配置
secretKeyRef: # Secret键引用
name: mysecret # Secret名称
key: username # Secret中的键名
- name: SECRET_PASSWORD # 环境变量名称
valueFrom: # 值来源配置
secretKeyRef: # Secret键引用
name: mysecret # Secret名称
key: password # Secret中的键名

ConfigMap热更新机制 🔄

更新特性说明 ⚡

  • Volume挂载方式: 可以感知配置变化(延迟几秒到一分钟左右)
  • 环境变量方式: 不会自动更新,需要重启Pod才能生效

使用建议 💡

  • 频繁变化的配置: 推荐使用Volume挂载方式
  • 固定配置: 可以使用环境变量注入方式

实际应用示例 🎯

MySQL密码注入Pod示例 🗄️

1. 创建Secret

1
kubectl create secret generic test --from-literal=MYSQL_ROOT_PASSWORD=1234567

2. 创建Deployment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
apiVersion: apps/v1 # API版本,指定使用的Kubernetes API版本
kind: Deployment # 资源类型,声明为Deployment对象
metadata: # 元数据,包含资源的名称、命名空间等信息
name: myapp-demo # Deployment的名称
namespace: default # 所属命名空间
spec: # Deployment规格,定义Deployment的配置
replicas: 1 # 副本数量
selector: # 选择器,用于匹配Pod
matchLabels: # 标签匹配规则
app: myapp # 匹配标签为app=myapp的Pod
template: # Pod模板,定义Pod的配置
metadata: # Pod元数据
labels: # Pod标签
app: myapp # Pod的标签
spec: # Pod规格
containers: # 容器列表
- name: myapp # 容器名称
image: ikubernetes/myapp:v1 # 容器镜像
imagePullPolicy: IfNotPresent # 镜像拉取策略
ports: # 端口配置
- name: http # 端口名称
containerPort: 80 # 容器端口
volumeMounts: # 卷挂载配置
- name: mysql # 卷名称,与volumes中的name对应
mountPath: /test/ # 挂载路径,容器内的目录路径
volumes: # 卷定义列表
- name: mysql # 卷名称
secret: # Secret卷配置
secretName: test # Secret名称

注意事项 ⚠️

  • 安全性: Secret虽然使用base64编码,但并非真正的加密,敏感信息仍需谨慎处理
  • 性能: ConfigMap和Secret都有大小限制,不宜存储过大的配置文件
  • 更新策略: 根据配置变化频率选择合适的注入方式
  • 权限管理: 合理设置RBAC权限,控制ConfigMap和Secret的访问范围
    通过合理使用ConfigMap和Secret,可以实现Kubernetes应用的配置与镜像分离,提升应用的可维护性和安全性 🚀

🔗 相关文档

Kubernetes调度与部署机制详解 | Kubernetes存储抽象详解 | Kubernetes安全基础 | YAML 文档格式概述

云计算专业学习方法 🚀

一、夯实底层基础 🏗️

云计算构建于 Linux 操作系统与计算机网络之上。需深入掌握 Linux 系统管理、内核机制及网络协议(尤以 TCP/IP、HTTP 为重),此为排查复杂分布式问题之根基。

二、遵循技术演进脉络 📈

学习应顺应技术发展逻辑,按”物理机 → 虚拟化 → 容器 → 容器编排”的路径递进。先理解虚拟化技术原理,再掌握 Docker 容器化,最终深入 Kubernetes 集群编排。

三、坚持实操驱动 💻

云计算重工程实践,忌纸上谈兵。需依托云平台资源,完成架构搭建、压力测试、容灾演练等全链路实验,在真实配置与排错中构建技术能力。

四、对标行业标准 📋

以主流云厂商(如 AWS、阿里云)的解决方案架构师认证考纲为学习路径,强制自身建立完整、符合工业界标准的云架构知识体系。

五、深化架构思维 🧠

跳出单一组件视角,聚焦云计算核心特性。在学习和设计中,始终围绕高可用、弹性伸缩、容灾解耦与资源抽象进行系统性思考。

常用学习交流平台 🌐

一、代码协作与技术问答 💬

  • GitHub:阅读云原生开源项目源码,参与社区协作。
  • Stack Overflow:K8s、Terraform 等云生态工具的报错排查与技术问答首选。

二、行业深度与开发者社区 📚

  • InfoQ (极客邦):获取云原生深度架构文章与行业技术趋势。
  • 阿里云/腾讯云开发者社区:国内云计算最佳实践、技术图谱与解决方案的核心阵地。
  • 掘金:一线开发者的云技术实战经验分享。

三、云原生专属社区 ☁️

  • CNCF Slack / Kubernetes 官方论坛:云原生计算基金会与 K8s 官方交流阵地,获取一手技术动态。
  • DockOne.io:国内老牌容器与云原生技术社区,专业讨论氛围浓厚。

四、云端实验与沙箱环境 🧪

  • Killercoda:浏览器内直接实操 K8s 与 Linux 环境,免本地配置。
  • Play with K8s / Docker:官方提供的免费临时集群搭建与演练平台。
  • 各大云厂商免费试用专区:AWS Free Tier、阿里云飞天加速计划等,提供真实生产环境练手机会。

注意事项 ⚠️

  • 在实际学习中,要理论与实践相结合,多动手操作。
  • 积极参与社区交流,保持对新技术趋势的敏感度。

🔗 相关文档

Linux 1月速成计划 | 从 Day 1 开始

核心概念解析 📚

一、PV(持久卷)💾

PV是集群级别的存储资源,代表实际的存储设备或存储空间,如NFS、Ceph、云硬盘等。

主要特性

  • 独立生命周期: 即使Pod被删除,PV中的数据仍然保留
  • 访问模式支持:
    • ReadWriteOnce(单节点读写)
    • ReadOnlyMany(多节点只读)
    • ReadWriteMany(多节点读写)

静态PV创建示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
capacity:
storage: 2Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /opt/k8s-pods/data
server: 192.168.179.102

二、PVC(持久卷声明)📝

PVC是用户对存储资源的请求,定义了所需存储的大小、访问模式等属性。

核心作用

  • 作为存储的”接口”,封装底层存储复杂性
  • 使开发者无需关心具体存储实现
  • 一个PV只能被一个PVC绑定

PVC创建示例

1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 2Gi
storageClassName: nfs

三、StorageClass(存储类)⚙️

StorageClass是实现动态存储供应的核心组件,定义了如何创建PV的模板。

关键字段

  • provisioner: 存储供应者
  • parameters: 存储参数
  • reclaimPolicy: 回收策略
  • volumeBindingMode: 绑定模式

StorageClass创建示例

1
2
3
4
5
6
7
8
9
10
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client-storageclass
provisioner: nfs-storage
parameters:
archiveOnDelete: "false"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

存储供应模式 🔄

静态供应模式 📦

由管理员预先创建PV,然后PVC进行绑定。

创建命令

1
2
3
kubectl create -f pv.yaml
kubectl create -f pvc.yaml
kubectl create -f storageclass.yaml

动态供应模式 🚀

通过StorageClass自动创建PV,大大简化存储管理。

创建命令

1
2
3
kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml
kubectl apply -f storageclass.yaml

PV生命周期状态 📊

PV的生命周期包括四种状态:

状态 描述
Available 还未与某个PVC绑定
Bound 已与某个PVC绑定
Released 绑定的PVC已经删除,资源已释放,但未被集群回收
Failed 自动资源回收失败

回收策略 ♻️

回收策略决定了PVC删除后PV的处理方式:

策略 描述
Retain PV不会被自动删除,数据依然保留
Delete PV会被自动删除,关联的存储资源也会被清理
Recycle 对卷执行基本清理操作,但已被弃用

完整创建方法 🔧

动态供应完整配置

RBAC权限配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-client-provisioner-runner
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: run-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io

NFS Provisioner部署

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
spec:
replicas: 1
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: quay.io/external_storage/nfs-client-provisioner:latest
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: nfs-storage
- name: NFS_SERVER
value: 192.168.179.102
- name: NFS_PATH
value: /opt/k8s
volumes:
- name: nfs-client-root
nfs:
server: 192.168.179.102
path: /opt/k8s

创建动态供应组件

1
2
3
4
kubectl apply -f rbac.yaml
kubectl apply -f nfs-provisioner.yaml
kubectl apply -f storageclass.yaml
kubectl apply -f dynamic-pvc.yaml

Pod使用PVC创建方法 🐳

Pod使用PVC的YAML示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
kind: Pod
metadata:
name: nginx-pv-pod
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- name: nginx-pv-storage
mountPath: "/usr/share/nginx/html"
volumes:
- name: nginx-pv-storage
persistentVolumeClaim:
claimName: nfs-pvc

StatefulSet使用PVC模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: "nfs-client-storageclass"
resources:
requests:
storage: 1Gi

管理命令汇总 🛠️

资源创建命令

1
2
3
kubectl create -f <yaml-file>           # 创建资源
kubectl apply -f <yaml-file> # 应用配置
kubectl apply -f <directory> # 应用目录下所有配置

资源查看命令

1
2
3
4
5
kubectl get pv,pvc,sc                   # 查看所有存储资源
kubectl get pv -o wide # 查看PV详细信息
kubectl get pvc -o wide # 查看PVC详细信息
kubectl describe sc <sc-name> # 查看StorageClass详情
kubectl get pv --sort-by=.spec.capacity.storage # 按容量排序PV

资源删除命令

1
2
3
4
5
kubectl delete pv <pv-name>             # 删除PV
kubectl delete pvc <pvc-name> # 删除PVC
kubectl delete sc <sc-name> # 删除StorageClass
kubectl delete -f <yaml-file> # 删除配置文件中的资源
kubectl delete pod,pvc,pv --all # 删除所有相关资源

故障排查命令

1
2
3
4
5
kubectl describe pvc <pvc-name>         # 查看PVC详细状态
kubectl describe pv <pv-name> # 查看PV详细状态
kubectl logs <provisioner-pod> # 查看Provisioner日志
kubectl get events --sort-by=.metadata.creationTimestamp # 查看事件
kubectl exec -it <pod-name> -- /bin/bash # 进入容器调试

存储资源扩展命令

1
2
kubectl patch pvc <pvc-name> -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}'  # 扩展PVC容量
kubectl get pv,pvc -o wide # 查看扩展后的状态

不同存储类型创建示例 💿

本地存储PV创建

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: v1
kind: PersistentVolume
metadata:
name: local-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
storageClassName: local-storage
local:
path: /mnt/disks/ssd1
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node1

云存储PV创建(AWS EBS示例)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
kind: PersistentVolume
metadata:
name: aws-ebs-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
storageClassName: aws-ebs
awsElasticBlockStore:
volumeID: vol-0123456789abcdef0
fsType: ext4

Ceph RBD PV创建

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: v1
kind: PersistentVolume
metadata:
name: ceph-rbd-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: ceph-rbd
rbd:
monitors:
- "192.168.1.100:6789"
- "192.168.1.101:6789"
- "192.168.1.102:6789"
pool: rbd
image: foo
fsType: ext4
readOnly: false
user: admin
secretRef:
name: ceph-secret

动态供应工作流程 🔄

动态供应机制的工作流程为:

  1. 用户创建PVC并指定StorageClass 📝
  2. Kubernetes根据StorageClass调用对应的provisioner创建PV ⚙️
  3. PV自动绑定到PVC 🔗
  4. Pod通过PVC使用存储资源 🐳

最佳实践建议 ✨

  1. 存储类规划: 根据应用需求创建多个StorageClass,如高性能存储、标准存储、归档存储等
  2. 回收策略选择: 生产环境建议使用Retain策略以避免数据意外丢失
  3. 容量规划: 合理设置PV容量,避免资源浪费或不足
  4. 监控告警: 定期检查PV/PVC状态,设置存储使用率告警
  5. 备份策略: 为重要数据制定定期备份计划

🔗 相关文档

Kubernetes核心概念详解 | Kubernetes调度与部署机制详解 | ConfigMap配置与密文管理详解
0%