【云原生之k8s】k8s之持久化存储PV、PVC

最新推荐文章于 2024-04-27 09:46:12 发布
最新推荐文章于 2024-04-27 09:46:12 发布
阅读量1.8k 收藏 6
点赞数 5
分类专栏： 云原生之K8S 文章标签： 云原生 kubernetes PV 持久化
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_45088125/article/details/126187167
版权

文章目录


在这里插入图片描述

一、PV和PVC

1、PV 概念

  1. PersistentVolume(PV) 是集群中由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源，可以从远程的NFS 或分布式对象存储系统中创建得来（PV 存储空间大小、访问方式）。
  2. PV 是诸如卷之类的卷插件，但是只有独立于使用 PV 的任何单个 pod 的生命周期。
  3. 该 API 对象捕获存储的实现细节，即 NFS，ISCSI 或云提供商特定的存储系统。
  4. PV 就是从存储设备中的空间创建出一个存储资源。

2、PVC概念

  1. PersistentVolumeClaim(PVC) 是用户存储的请求。PVC 的使用逻辑：在 pod 中定义一个存储卷（该存储卷类型为PVC)，定义的时候直按指定大小，PVC 必须与对应的 PV 建立关系，PVC 会根据定义去 PV 申请，而 PV是由存储空间创建出来的。PV 和 PVC 是 kubernetes 抽象出来的一种存储资源。
  2. 虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但是常见的需求是，用户需要根据不同的需求去创建PV，用于不同的场景。而此时需要集群管理员提供不同需求的 PV，而不仅仅是 PV 的大小和访问模式，但又不需要用户了解这些卷的实现细节。
  3. 对于这样的需求，此时可以采用 storageclass 资源。

3、PV 与 PVC 之间的关系

PV 是集群中的资源，PVC 是对这些资源的请求，也是对资源的索引检查。

3.1 PV和PVC的生命周期

PV 和 PVC 之间的相互作用遵循这个生命周期：

Provisioning(配置) ---> Binding(绑定) ---> Using(使用) ---> Releasing(释放) ---> Recycling(回收)
  • Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建
  • Binding，将 PV 分配给 PVC
  • Using，Pod 通过 PVC 使用该Volume，并可以通过准入控制StorageProtection（1.9及以前版本为PVCProtection） 阻止删除正在使用的PVC
  • Releasing，Pod 释放 Volume 并删除 PVC
  • Recycling，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除

根据这 5 个阶段，PV 的状态有以下 4 种：

  • Available（可用）：表示可用状态，还未被任何 PVC 绑定

  • Bound（已绑定）：表示 PV 已经绑定到 PVC

  • Released（已释放）：表示 PVC 被删掉，但是资源尚未被集群回收

  • Failed（失败）：表示该 PV 的自动回收失败

3.2 一个PV从创建到销毁的具体流程

  1. 一个PV创建完后状态会变成Available，等待被PVC绑定。
  2. 一旦被PVC邦定，PV的状态会变成Bound，就可以被定义了相应PVC的Pod使用。
  3. Pod使用完后会释放PV，PV的状态变成Released。
  4. 变成Released的PV会根据定义的回收策略做相应的回收工作。

3.3 三种回收策略

有三种回收策略，Retain、Delete和Recycle。

  1. Retain就是保留现场，K8S集群什么也不做，等待用户手动去处理PV里的数据，处理完后，再手动删除PV。
  2. Delete策略，K8S会自动删除该PV及里面的数据。
  3. Recycle方式，K8S会将PV里的数据删除，然后把PV的状态变成Available，又可以被新的PVC绑定使用。

3.4 查看pv、pvc的定义方式、规格

查看pv的定义方式
kubectl explain pv

FIELDS:
	apiVersion: v1
	kind: PersistentVolume
	metadata:    #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespace
	  name: 
	spec

查看pv定义的规格
kubectl explain pv.spec

spec:
  nfs:（定义存储类型）
    path:（定义挂载卷路径）
    server:（定义服务器名称）
  accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）
    - ReadWriteOnce          #（RWO）存储可读可写，但只支持被单个 Pod 挂载
	- ReadOnlyMany           #（ROX）存储可以以只读的方式被多个 Pod 挂载
	- ReadWriteMany          #（RWX）存储可以以读写的方式被多个 Pod 共享
#nfs 支持全部三种；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。
  capacity:（定义存储能力，一般用于设置存储空间）
    storage: 2Gi （指定大小）
  storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）
  persistentVolumeReclaimPolicy: Retain    #回收策略（Retain/Delete/Recycle）
#Retain（保留）：当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
#Delete（删除）：删除与PV相连的后端存储资源（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
#Recycle（回收）：删除数据，效果相当于执行了 rm -rf /thevolume/* （只有 NFS 和 HostPath 支持）

查看PVC的定义方式
kubectl explain pvc

KIND:     PersistentVolumeClaim
VERSION:  v1
FIELDS:
   apiVersion	<string>
   kind	<string>  
   metadata	<Object>
   spec	<Object>

PV和PVC中的spec关键字段要匹配，比如存储（storage）大小、访问模式（accessModes）、存储类名称（storageClassName）

kubectl explain pvc.spec
spec:
  accessModes: （定义访问模式，必须是PV的访问模式的子集）
  resources:
    requests:
      storage: （定义申请资源的大小）
  storageClassName: （定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）

4、两种PV的提供方式

这里有两种 PV 的提供方式：静态或者动态

静态 —》直接固定存储空间

  • 集群管理员创建一些 PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于 Kubernetes API 中，可用于消费。

动态 —》通过存储类进行动态创建存储空间

  • 当管理员创建的静态 PV 都不匹配用户的 PVC 时，集群可能会尝试动态地为 PVC 配置卷。此配置基于
    StorageClasses：PVC必须请求存储类，并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。

二、基于 nfs 创建静态 PV 资源和 PVC 资源

在这里插入图片描述

1、实验环境

nfs-serverk8s-master（192.168.109.11）
nfs-clientk8s-node1（192.168.109.12），k8s-node2（192.168.109.13）

2、所有节点安装nfs

yum install -y nfs-utils rpcbind

3、在master节点创建共享目录

mkdir /nfsdata1
mkdir /nfsdata2
mkdir /nfsdata3

4、master 授权共享目录

chmod 777 /nfsdata1
chmod 777 /nfsdata2
chmod 777 /nfsdata3

5、master 编辑 exports 文件

vim /etc/exports
/nfsdata1 192.168.10.0/24(rw,no_root_squash,sync)
/nfsdata2 192.168.10.0/24(rw,no_root_squash,sync)
/nfsdata3 192.168.10.0/24(rw,no_root_squash,sync)

exportfs -rv

6、master 启动 rpc 和 nfs（注意顺序）

#手动加载 NFS 共享服务时，应该先启动 rpcbind，再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs

#查看 rpcbind 端口是否开启，rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind

查看本机发布的共享目录

showmount -e

7、master 创建访问页面供测试用

echo '11111' > /nfsdata1/index.html
echo '22222' > /nfsdata2/index.html
echo '33333' > /nfsdata3/index.html

8、master 创建 PV

这里定义 3 个 PV，并且定义挂载的路径以及访问模式，还有 PV 划分的大小。

vim pv-demo.yaml	#注意自己的共享目录和主机名
————————————————————————————————————————————
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /nfsdata1
    server: master
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /nfsdata2
    server: master
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /nfsdata3
    server: master
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi

创建并查看

kubectl apply -f pv-demo.yaml 
kubectl get pv
----------------------------------------
[root@master ~]# kubectl apply -f pv-demo.yaml
persistentvolume/pv001 created
persistentvolume/pv002 created
persistentvolume/pv003 created
[root@master ~]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                   6s
pv002   2Gi        RWO            Retain           Available                                   6s
pv003   2Gi        RWO,RWX        Retain           Available                                   6s

9、定义PVC

这里定义了 PVC 的访问模式为多路读写，该访问模式必须在前面 PV 定义的访问模式之中。定义 PVC 申请的大小为 2Gi，此时 PVC 会自动去匹配多路读写且大小为 2Gi 的 PV ，匹配成功获取 PVC 的状态即为 Bound。

vim pvc-demo.yaml
---------------------------------------
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pv-pvc
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
      claimName: mypvc

发布并查看

kubectl apply -f pvc-demo.yaml
kubectl get pv
------------------------------------
[root@master ~]# kubectl apply -f pvc-demo.yaml
persistentvolumeclaim/mypvc created
pod/pv-pvc created
[root@master ~]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                           4m51s
pv002   2Gi        RWO            Retain           Available                                           4m51s
pv003   2Gi        RWO,RWX        Retain           Bound       default/mypvc                           4m51s

可以看到 pv003 设定的 pvc 请求存储卷是 2Gi 并且多路可读可写。
访问 pv003

[root@master ~]# kubectl get pod -o wide
NAME     READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
pv-pvc   1/1     Running   0          58s   10.244.1.3   node01   <none>           <none>
[root@master ~]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                           84s
pv002   2Gi        RWO            Retain           Available                                           84s
pv003   2Gi        RWO,RWX        Retain           Bound       default/mypvc                           84s
[root@master ~]# curl 10.244.1.3
33333

pod 创建不成功检查下网络怎么样，delete pv/pvc.yaml 重试。

10、测试多路读写

1. 我们通过相同的存储卷，只修改 pod 的名称
cp pvc-demo.yaml 1.yaml
cp pvc-demo.yaml 2.yaml
2. 修改 pod 的名称后，apply 执行创建
kubectl apply -f 1.yaml
kubectl apply -f 2.yaml
3. 查看 ip
kubectl get pod -o wide 
4. curl 进行测试，查看是否共享存储卷，多路读写

三、基于动态 storageclass 创建 PV 与 PVC

1、storageclass 定义

前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。
  与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。
在这里插入图片描述
在这里插入图片描述

2、storageclass 用途

在 PV 和 PVC 使用过程中存在的问题，在 PVC 申请存储空间时，未必就有现成的 PV 符合 PVC 申请的需求，上面 nfs 在做 PVC 可以成功的因素是因为我们做了指定的需求处理。当 PVC 申请的存储空间不一定有满足 PVC 要求的 PV 时，Kubernetes 为管理员提供了描述存储 “class(类)” 的方法(StorageClass)。举个例子，在存储系统中划分一个 1TB 的存储空间提供给 Kubernetes 使用，当用户需要一个 10G 的 PVC 时，会立即通过 restful 发送请求，从而让存储空间创建一个 10G 的 image，之后在我们的集群中定义成 10G 的 PV 供给给当前的 PVC 作为挂载使用。在此之前我们的存储系统必须支持 restful 接口，比如 ceph 分布式存储，而 glusterfs 则需要借助第三方接口完成这样的请求。

3、storageclass 的 yaml 格式

kubectl explain storageclass	#storageclass 也是 k8s 上的资源
KIND: Storageclass
VERSION: storage.k8s.io/vl
FIELDS:
  allowVolumeExpansion <boolean>
  allowedTopologies<[]Object>apiversion<string>
  kind <string>
  metadata <object>
  mountOptions <[]string>挂载选项
  parameters <map[string]string	#参数，取决于分配器，可以接受不同的参数。例如参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。当参数被省略时,会使用默认值。
  provisioner <string-requred-	#存储分配器，用来决定使用哪个卷插件分配 PV。该字段必须指定。
  reclaimPolicy <string>		#回收策略，可以是 Delete 或者 Retain。如果 StorageClass 对象被创建时没有指定 reclaimPolicy，它将默认为 Delete。
  volumeBindingMode<string>		#卷的绑定模式


StorageClass 中包含 provisioner、parameters 和 reclaimPolicy 字段，当 class 需要动态分配  PersistentVolume 时会使用到。由于 storageclass 需要一个独立的存储系统，此处就不再演示。从其他资料查看定义 storageclass 的方式如下:
==========================================================
kind: storageClass
apiversion: storage.k8s.io/v1432
metadata :
  name : standard
provisioner: kubernetes.iol aws-ebs435 parameters:
  type: gp2
reclaimPolicy: Retain
mountoptions:
  - debug

示例：
StorageClass standard：
在这里插入图片描述
StorageClass slow：
在这里插入图片描述
这两个 StorageClass 都会动态创建 AWS EBS，不同在于 standard 创建的是 gp2 类型的 EBS，而 slow 创建的是 io1 类型的 EBS。不同类型的 EBS 支持的参数可参考 AWS 官方文档。StorageClass 支持 Delete 和 Retain 两种 reclaimPolicy，默认是 Delete。

与之前一样，PVC 在申请 PV 时，只需要指定 StorageClass 和容量以及访问模式，比如：
在这里插入图片描述
除了 AWS EBS，Kubernetes 支持其他多种动态供给 PV 的 Provisioner

四、PV、PVC 应用在 mysql 的持久化存储

下面演示如何为 MySQL 数据库提供持久化存储，步骤为：

  1. 创建 PV 和 PVC。
  2. 部署 MySQL。
  3. 向 MySQL 添加数据。
  4. 模拟节点宕机故障，Kubernetes 将 MySQL 自动迁移到其他节点。
  5. 验证数据一致性。

1、创建 MySQL PV 和 PVC

mysql-pv.yml

vim mysql-pv.yml
---------------------------------------
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfsdata1/mysql-pv
    server: master

mysql-pvc.yml

vim mysql-pvc.yml
-----------------------------------
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs

创建 mysql-pv 和 mysql-pvc

[root@master ~]# kubectl apply -f mysql-pv.yml 
persistentvolume/mysql-pv created
[root@master ~]# kubectl apply -f mysql-pvc.yml 
persistentvolumeclaim/mysql-pvc created
[root@master ~]# kubectl get pv,pvc
NAME                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
persistentvolume/mysql-pv   1Gi        RWO            Retain           Bound    default/mysql-pvc   nfs                     24s

NAME                              STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/mysql-pvc   Bound    mysql-pv   1Gi        RWO            nfs            20s
#将先前实验的配置清除，方便检查

2、部署 MySQL

mysql.yml

vim mysql.yml
------------------------------------
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
      app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pvc

PVC mysql-pvc Bound 的 PV mysql-pv 将被 mount 到 MySQL 的数据目录 /var/lib/mysql。

kubectl apply -f mysql.yml
kubectl get pod -o wide
风雪一更ing
关注
  • 5
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
专栏目录
云原生+k8s+面试题集锦+128题
10-25
需要面试k8s相关岗位的小朋友来取，增加面试过关率
K8s持久化存储PV和PVC（通俗易懂）
热门推荐
hanjinjuan的博客
10-14 1万+
一、PV和PVC的引入 Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。 拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息： 当前 Volume 来自 AWS EBS。 EBS Volume 已经提前创建，并且知道确切的 volume-id。 Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息： 要么询问管理员。 要么自己就是管理员。 这样就带来一个管理上的问题：应用开发人员和系统
Kubernetes07-数据存储【PV、PVC】
d495435207的博客
09-04 325
本文主要介绍了kubernetes的数据存储，包括基本存储 emptyDir，hostPath，NFS 和高级存储PV，PVC以及配置存储configMap和Secret
Kubernetes基础(二十二)-K8S的PV/PVC/StorageClass详解
sre救赎之路
02-19 1259
先来个一句话总结：PV、PVC是K8S用来做存储管理的资源对象，它们让存储资源的使用变得可控，从而保障系统的稳定性、可靠性。StorageClass则是为了减少人工的工作量而去自动化创建PV的组件。所有Pod使用存储只有一个原则：先规划→后申请→再使用。
【 云原生 | kubernetes 】资源对象 - 持久化存储PV,PVC
ycloud
10-22 257
这篇文章我们了解了Volume ，还有Project Volume这个特殊的卷，它不是用来存储容器的数据，而是为容器提供预先定义好的数据。今天我们了解一下持久卷(Persistent Volume)
k8s中PV、PVC、StorageClass的简单理解
可乐多点冰的博客
12-09 7015
1、PersistentVolume（PV）就可以理解为是一个网络存储，就是一个实实在在的存储数据的地方，只不过是以网络的方式发生数据到存储的地方，比如NFS, iSCSI和云提供商指定的存储系统。 若严格来说，PV是k8s里面的一个概念，它本身不是存储，只不过是创建pv的资源清单文件中指定了网络存储的地址，同时也指定了一些存储的参数，例如一些大小，性能等指标。 apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv namespac
k8s——pv（静态+动态storageclass）与pvc
Yusheng9527的博客
04-13 3229
k8s——pv（静态+动态storageclass）与pvc PVC和PVPV概念PVC概念PV与PVC之间的关系两种PV的提供方式基于nfs创建静态PV资源和PVC资源配置nfs存储（192.168.80.14）k8s的master节点定义PV定义PVC测试多路读写基于动态storageclass创建pv与pvcstorageclass的用处storageclass的yaml格式 PVC和PV PV概念 PersistentVolume(PV)是集群中已由管理员配置的一段网络存储。集群中的资源就像一个节
k8s nfs pv pvc
Neil的博客
02-04 231
1. nfs准备 1. yum install nfs-utils rpcbind -y 2. cd / && mkdir tmp1 3. chown -R nfsnobody.nfsnobody /tmp1 4. vim /etc/exports [root@k8s-master manifests]# cd /etc [root@k8s-master etc]# vi...
我就想存个文件，怎么这么麻烦 ？- k8s PV、PVC、StorageClass 的关系
m0_38017860的博客
11-26 1427
Docker当我们使用 Docker 时，设置数据卷（Volume）还是比较简单的，只需要在容器映射指定卷的路径，然后在容器中使用该路径即可。比如这种：# tomcat   tomcat01:     hostname: tomcat01     restart: always     image: jdk-tomcat:v8 &
Kubernetes K8S之存储PV-PVC详解
踏歌行的专栏
10-23 1万+
K8S之存储PV-PVC概述与说明，并详解常用PV-PVC示例
k8s之PV&PVC(NFS)
jiayu的博客
10-17 2562
k8s之PV&PVC(NFS) 实验环境 k8s环境参考： k8s-v1.20.10 二进制部署指导文档 访问模式 PersistentVolume 卷可以用资源提供者所支持的任何方式挂载到宿主系统上。 如下表所示，提供者（驱动）的能力不同，每个 PV 卷的访问模式都会设置为 对应卷所支持的模式值。 例如，NFS 可以支持多个读写客户，但是某个特定的 NFS PV 卷可能在服务器 上以只读的方式导出。每个 PV 卷都会获得自身的访问模式集合，描述的是 特定 PV 卷的能力 模式 作用
云原生 k8s HPA components.yaml
03-06
云原生 k8s HPA components.yaml，搭建metrics server环境，适用于外网下载不到文件的小伙伴，镜像仓库地址已改为阿里云国内镜像，必要的配置也已配置完成，助你快速完成metrics server环境搭建。云原生 k8s HPA ...
云原生k8s部署流水线
09-22
云原生k8s部署流水线
云原生-基于k8s部署-分布式底层存储-Rook-Ceph
06-13
分布式存储系统是一个有效的解决有状态工作负载高可用问题的方案。Ceph 就是一个分布式存储系统，近年来其影响主键扩大。Rook 是一个编排器，能够支持包括 Ceph 在内的多种存储方案。Rook 简化了 Ceph 在 Kubernetes...
K8S云原生技术与实战
05-31
K8S云原生技术与实战
【打工日常】云原生之部署个人使用的高速下载器Gopeed
全糖少冰我吃不了苦
04-26 638
【打工日常】云原生之部署个人使用的高速下载器Gopeed。
深入理解Java消息中间件-云原生和容器化对消息中间件的影响
最新发布
u011532237的博客
04-27 912
在经历了从物理服务器到虚拟化技术的演进后，当前IT架构的发展势头正在向云原生和容器化迈进。从集中式到分布式： 云原生架构倾向于使用微服务模式，这导致消息中间件从传统的集中式架构转向更加分布式的设计。云原生和容器化技术为消息中间件的发展带来了新的机遇和挑战。通过设计上的革新、部署和运维方式的转型，以及性能和安全性的增强，现代消息中间件能够更好地适应动态、分布式的云原生环境。云原生消息中间件需要支持数据的分区副本、跨集群复制等特性，以确保在节点或网络故障时，消息不丢失且服务可用。
K8s（二十三）：Pod的生命周期详解
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
04-21 1609
🔴 K8s（二十三）：Pod的生命周期详解
K8s初次入门
qq_43982499的博客
04-27 851
k8s 集群主机清单事先准备所有的k8s集群主机卸载防火墙和（docker、k8s建议禁用swap)安装工具修改配置文件配置内核参数设置Tab补全功能键对master主控节安装测试系统环境主控节点初始化安装计算节点（node系列）1.先从master主机获取凭证2.对各个计算节点进行配置（是否防火墙关掉/禁用swap、安装k8s相关软件包、配置内核参数）3.逐个加入master集群通过master主机查看所有加入集群的计算节点主机。
云原生和云平台、k8s、微服务的关联
03-28
云原生是一种软件开发和部署的方法论，旨在利用云计算的优势，实现更快、更灵活、更可靠的部署和运行...云原生、云平台、K8s和微服务共同构成了现代化的云计算架构，使得企业可以更加敏捷、高效地开发和运营应用程序。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

风雪一更ing

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值