k8s-pvc-demo

该博客展示了如何在 Kubernetes 集群中配置 PersistentVolume、PersistentVolumeClaim,创建 Deployment 以挂载存储,并设置 Service 和 Ingress,以实现应用的持久化存储和外部访问。

[root@master test-dir]# cat nginx-1.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pvc
  namespace: test
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  nfs:
    path: /ifs/kubernetes
    server: 192.168.3.214

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: test
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-1
  name: nginx-1-deployment
  namespace: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-1
  template:
    metadata:
      labels:
        app: nginx-1
        project: blog
    spec:
      containers:
      - image: nginx
        name: nginx-1-container
        volumeMounts:
        - name: my-pvc
          mountPath: /usr/share/nginx/html

      volumes:
      - name: my-pvc
        persistentVolumeClaim:
          claimName: my-pvc

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-1-service
  namespace: test
spec:
  ports:
  - port: 8001  # 访问 Service 的端口,集群端口
    protocol: TCP
    targetPort: 80 # 容器商品,即应用程序端口
  selector:
    app: nginx-1 # pod 的 label
    project: blog

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-1-ingress
  namespace: test
spec:
  rules:
  - host: nginx.1.ingress
    http:
      paths:
      - path: "/" 
        backend:
          serviceName: nginx-1-service
          servicePort: 8001
[root@master test-dir]# 

09-20
<think> 嗯,用户想要了解Kubernetes中持久卷声明(PVC)的详细信息。用户之前的问题和当前的引用都聚焦在PVC概念和应用上,看来可能是运维工程师或开发者在搭建K8s存储方案时遇到了实际问题。 从引用内容看,用户提供的材料质量不错:引用[1]解释了PVC的基础定位,引用[2]涉及运维痛点,引用[3]有具体yaml示例,引用[4]则警示了数据丢失风险。不过用户没有说明具体想了解哪个层面——是概念原理、实操配置还是故障排除? 考虑到PVC属于K8s存储体系的核心概念,我决定采用分层讲解策略:先建立PVC-PV-StorageClass的三角关系认知,再用具体用例说明工作流程,最后补充关键细节(如回收策略和访问模式)。这样既覆盖基础知识,又能预防用户后续可能遇到的坑。 特别注意引用[3]中的yaml片段非常实用,应该作为核心示例拆解。而引用[4]提到的数据丢失风险需要单独强调,这是实际部署时的高频问题点。用户没有要求英文术语,但PV/PVC这种缩写首次出现时还是标注全称为好。 用户身份推测:从能提供具体引用来看,应该不是完全的新手,可能正在设计有状态服务的存储方案。因此回答需要平衡理论深度和实操参考性,避免过于基础的操作指导。 </think> 以下是 Kubernetes 持久卷声明(PVC)的详细介绍,结合核心概念和工作原理: --- ### **一、PVC 的核心概念** 1. **抽象层作用** PVC 是用户对存储资源的**抽象请求**,开发者无需关心底层存储细节(如 NFS/iSCSI/云存储),只需声明所需的存储大小、访问模式和存储类(StorageClass)。 2. **与 PV 的关系** - **持久卷(PV)**:集群中的实际存储资源,由管理员创建(如 NFS 卷、云磁盘)。 - **PVC**:用户通过 PVC **绑定**到匹配的 PV,实现存储的动态供给(参考引用 [1][^1])。 --- ### **二、PVC 核心配置详解** ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: demo-pvc spec: accessModes: - ReadWriteOnce # 访问模式(见下表) resources: requests: storage: 5Gi # 请求的存储空间 storageClassName: cbs # 指定存储类(动态配置必需) ``` #### **关键配置说明:** | **字段** | **可选值/示例** | **作用** | |-------------------|-----------------------------------|--------------------------------------------------------------------------| | `accessModes` | `ReadWriteOnce`(单节点读写) | 定义卷的访问权限 | | | `ReadOnlyMany`(多节点只读) | | | | `ReadWriteMany`(多节点读写) | | | `storage` | `10Gi`, `1Ti` | 声明所需存储容量 | | `storageClassName`| `cbs`, `gp2` | 指定动态供给的存储类(为空时使用默认 StorageClass) | > 注:`ReadWriteOncePod`(单 Pod 读写)是 Kubernetes 1.22+ 新增特性(参考引用 [3][^3])。 --- ### **三、PVC 工作流程** 1. **用户创建 PVC** 提交包含存储需求(大小、访问模式)的 PVC 清单。 2. **Kubernetes 匹配 PV** - **静态供给**:绑定到预先创建的、满足条件的 PV。 - **动态供给**:
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值