12.存储卷

重点: pv pvc configMap secret

1.emptyDir 只在节点本地使用,pod一删除,存储卷也就删除,临时目录,可以当缓存空间使用,无持久性,生命周期与pod一样
存储卷是可以在一个pod中的各个容器中共享。

2.gitRepo
本质上也是一个emptyDir
不会去实时同步git仓库更新,但是也可以通过一个辅助的容器去定时同步

3.hostPath 存储在宿主机上,对于集群来讲它也无持久性,如果pod被删除,新建的pod如果是在其他的node上创建,那么会访问不到之前的存储卷

[[email protected]ter volumes]# cat pod-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-vol-hostpath
namespace: default
spec:
containers:
- name: myapp-vol
image: ikubernetes/myapp:v1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html/
volumes:
- name: html
hostPath:
path: /data/pod/volumel
type: DirectoryOrCreate

4.网络直连存储
SAN: iSCS
NAS: nfs cifs

nfs:
[[email protected] volumes]# cat pod-nfs.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-vol-nfs
namespace: default
spec:
containers:
- name: myapp-vol
image: ikubernetes/myapp:v1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html/
volumes:
- name: html
nfs:
path: /data/volumes
server: 10.250.0.99 #nfs server地址

5.分布式存储
glusterfs
rbd
cephfs
6.云存储 需要k8s托管在云上,关键数据还是需要有自己的异地备份
EBS 亚马逊
Azure Disk
阿里等块存储

============
persistentVolumeClaim pvc
persistentVolumeClaim 简称pvc
pvc pv(存储系统上的一块存储空间) 动态供给

pvc -- pv 一一对应
一个pvc是可以定义被多个pod引用。

查看pv:
kubectl get pv

pv回收策略
RECLAIM POLICY : 回收策略
Retain 保留

创建pv资源:
[[email protected] volumes]# cat pv-demo.yml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001 #定义pv的时候一定不要指定名称空间(namespace),它属于集群级别的资源
labels:
name: pv001
spec:
nfs:
path: /data/volumes/v1
server: 10.250.0.88
accessModes: ["ReadWriteMany","ReadWriteOnce"] #定义访问模型,参照官网
capacity:
storage: 2Gi #注意单位

创建pvc资源:

如果pv被pvc绑定则pv不能被删除。

特殊存储卷
7.configMap :可以从外部映射配置到pod内部,实现配置信息的注入 ,配置中心也是存储卷的一种,明文存储数据的。将镜像与配置文件解耦。
使用环境变量的前提,是容器应用能支持从变量中加载

8.secrit :功能和configMap一样,但是内容是加密的。

应用可以根据状态分为
有状态要存储
有状态不存储
无状态要存储
无状态不存储

存储卷属于pod

===========================================
容器化应用的配置的修改加载的方式:
1.自定义命令行参数
command
args: []
2.把配置文件直接焙进镜像
3.环境变量env (这种方式不能动态更新加载,pod需要重启)
(1) Cloud Native 的应用程序一般可以直接通过环境变量加载配置
(2)通过entrypoint脚本来预处理变量为配置文件中的配置信息

eg:
使用命令创建configMap:
kubectl create configmap nginx-config --from-literal=nginx_port=80 --from-literal=server_name=myapp.magedu.com
也可以使用文件:
--

[[email protected] volumes]# cat pod-configmap.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-cm-1
namespace: default
labels:
app: myapp
tier: frontend
annotations:
magedu.com/created-by: "cluster admin"
spec:
containers:
- name: myapp-nginx
image: nginx:1.14-alpine
ports:
- name: http
containerPort: 80 #这里填写并不完全决定真正的暴露
env:
- name: NGINX_SERVER_PORT #变量只能是下划线
valueFrom:
configMapKeyRef:
name: nginx-config
key: nginx_port
- name: NGINX_SERVER_NAME
valueFrom:
configMapKeyRef:
name: nginx-config
key: server_name

连接到对应的pod中查看环境变量:printenv,当我们在外部修改变量的值过后,pod中的变量值不会被修改

4.存储卷(使用configMap 就可以动态的加载变量)

[[email protected] volumes]# cat pod-configmap-cm2.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-cm-2
namespace: default
labels:
app: myapp
tier: frontend
annotations:
magedu.com/created-by: "cluster admin"
spec:
containers:
- name: myapp-nginx
image: nginx:1.14-alpine
ports:
- name: http
containerPort: 80 #这里填写并不完全决定真正的暴露
volumeMounts:
- name: nginxconf
mountPath: /etc/nginx/config.d/
readOnly: true
volumes:
- name: nginxconf
configMap:
name: nginx-config

启动pod后进入查看 /etc/nginx/config.d 下面会发现有两个文件,文件名称是键名,内容为值

/ # cat /etc/nginx/config.d/nginx_port
8080

手动修改configMap中的变量值nginx_port 为8088
[[email protected] volumes]# kubectl edit cm nginx-config

稍等片刻(可能需要一两分钟)后再次进入pod查看挂载的变量文件的值:
[[email protected] volumes]# kubectl exec -it pod-cm-2 -- /bin/sh
/ # cat /etc/nginx/config.d/nginx_port
8088/ #
发现已经自动变成8088

nginx操作实例:

[[email protected] volumes]# cat www.conf
server {

listen 80;
server_name test.long.com;
root /usr/share/html/;
}

使用文件创建configMap:
[[email protected] volumes]# kubectl create configmap nginx-www --from-file=./www.conf
configmap/nginx-www created

[[email protected] volumes]# cat pod-configmap-nginx-cm3.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-cm-nginx-3
namespace: default
labels:
app: myapp
tier: frontend
annotations:
magedu.com/created-by: "cluster admin"
spec:
containers:
- name: myapp
image: nginx:1.14-alpine
ports:
- name: http
containerPort: 80 #这里填写并不完全决定真正的暴露
volumeMounts:
- name: nginxconf
mountPath: /etc/nginx/conf.d/
readOnly: true
volumes:
- name: nginxconf
configMap:
name: nginx-www

启动:
kubectl apply -f pod-configmap-nginx-cm3.yaml

连入pod:
kubectl exec -it pod-cm-nginx-3 -- /bin/sh

/ # cat /etc/nginx/conf.d/www.conf
server {

listen 80;
server_name test.long.com;
root /usr/share/html/;

}

在根目录/usr/share/html/ 创建文件index.html然后可以通过集群中的其他机器绑定hosts 然后curl访问测试
[[email protected] ~]# curl test.long.com/index.html
you get it!!!!!

--
然后实时修改configMap
我们修改监听的端口为 8080
# [[email protected] volumes]# kubectl edit cm nginx-www

再次进入pod查看www.conf
# cat /etc/nginx/conf.d/www.conf
server {

listen 8080;
server_name test.long.com;
root /usr/share/html/;

}
文件已经自动变更

我们需要重新reload nginx
# /usr/sbin/nginx -s reload
2019/06/26 08:01:33 [notice] 34#34: signal process started

然后再curl访问:
[[email protected] ~]# curl test.long.com:8080/index.html
you get it!!!!!
---

=======================
secret
secret有三种类型:
docker-registry 连接私有仓库秘钥
generic
tls ssl证书时候使用

创建secret:
[[email protected] volumes]# kubectl create secret generic mysql-root-pswd [email protected]
secret/mysql-root-pswd created

查看:
[[email protected] volumes]# kubectl get secret mysql-root-pswd -o yaml
apiVersion: v1
data:
password: TVlQQDEyMw==
kind: Secret
metadata:
creationTimestamp: "2019-06-26T08:09:33Z"
name: mysql-root-pswd
namespace: default
resourceVersion: "34373"
selfLink: /api/v1/namespaces/default/secrets/mysql-root-pswd
uid: bb4644aa-97e9-11e9-bb28-000c299c8399
type: Opaque

解密:
[[email protected] volumes]# echo TVlQQDEyMw== | base64 -d
[email protected]

由于直接就可以解密所以还是不怎么安全。

这个的使用方式和configMap类似,
使用方式也是有env及存储卷挂载的方式。同configMap

原文地址:https://www.cnblogs.com/heaven-xi/p/11312614.html

时间: 2024-10-04 06:12:27

12.存储卷的相关文章

Kubernetes 学习12 kubernetes 存储卷

一.概述 1.我们此前讲过根据应用本身是否需要持久存储数据以及某一次请求和之前的请求是否有联系,可以分为四类应用 a.有状态,要存储 b.有状态,无持久存储 c.无状态,要存储 d.无状态,无持久存储 其中,大多数和数据存储服务相关的应用和有状态应用几乎都是需要持久存储数据的.在docker中说过,容器有生命周期,为了使容器将来终结以后可以把其删除,甚至是编排到其它节点上去运行,意味着我们数据不能放在容器本地,不能放在容器自己的名称空间中.注意这是两套逻辑,以k8s为例,pod运行时应该是运行在

SUSE CaaS Platform 4 - Ceph RBD 作为 Pod 存储卷

网络存储卷系列文章 (1)SUSE CaaS Platform 4 - 简介 (2)SUSE CaaS Platform 4 - 安装部署 (3)SUSE CaaS Platform 4 - 安装技巧 (4)SUSE CaaS Platform 4 - Ceph RBD 作为 Pod 存储卷 (5)SUSE CaaS Platform 4 - 使用 Ceph RBD 作为持久存储(静态) (6)SUSE CaaS Platform 4 - 使用 Ceph RBD 作为持久存储(动态) RBD存储

邮件监控存储卷空间的脚本

邮件监控存储卷空间的脚本: 说明: 1.显示存储名.ip.卷名.total空间.free空间.1天用空间.已用百分比 2.对卷名字符数的统计(echo aa1 | wc -m) 3.对卷名部分的排除,只保留数值部分(/usr/lib64/nagios/plugins/check-netapp-ng2.pl -H 10.0.0.16 -C public -T DISKUSED -v /vol/$eNas/ -w 80 -c 90 | awk -F[:" "]+ '{print $5}'

glusterfs 的存储卷类型

glusterfs是一个流行的分布式文件系统,它的存储卷分为几种 一.分布式卷(Distributed volume) 近似于raid0,文件没有分片,将文件逐个写入各个硬盘上,优点是容量大,缺点是没冗余. 二.条带卷(Striped volume) 相当于raid0,文件是分片均匀写在各个硬盘上的,优点是分布式读写,性能整体较好.缺点是没冗余,分片随机读写可能会导致硬盘IOPS饱和. 三.复制卷(Replicated volume) 相当于raid1,复制的份数,决定集群的大小,通常与分布式卷

理解 QEMU/KVM 和 Ceph(3):存储卷挂接和设备名称

本系列文章会总结 QEMU/KVM 和 Ceph 之间的整合: (1)QEMU-KVM 和 Ceph RBD 的 缓存机制总结 (2)QEMU 的 RBD 块驱动(block driver) (3)存储卷挂接和设备名称 这篇文章分析一下一个 Ceph RBD 卷是如何被映射到一个 QEMU/KVM 客户机的,以及客户机中设备的命名问题. 1. 遇到的设备命名问题 1.1 通过 Nova 和 Cinder 做 Ceph RDB 卷挂接和卸载步骤 挂接一个卷: #运行nova-attach 命令no

关于LUN和存储卷的区别详解

一.LUN的概念 LUN的全称是Logical Unit Number,也就是逻辑单元号.我们知道SCSI总线上可挂接的设备数量是有限的,一般为6个或者15个,我们可以用Target ID(也有称为SCSI ID的)来描述这些设备,设备只要一加入系统,就有一个代号,我们在区别设备的时候,只要说几号几号就ok了. 而实际上我们需要用来描述的对象,是远远超过该数字的,于是我们引进了LUN的概念,也就是说LUN ID的作用就是扩充了Target ID.每个Target下都可以有多个LUN Device

Apache Stratos Mock架构及持久化存储卷的映射

Apache Stratos Mock IaaS 简介 Apache Stratos 支持许多基础设施作为服务 (IaaS) 的平台:EC2,OpenStack,vCloud,CloudStack,Docker等.然而,设立IaaS 或购买公共 IaaS 服务对于尝试Stratos来说是额外的开销.此外,设置本地 IaaS 需要大量的硬件资源和购买公有云上的IaaS账户所涉及的成本.这些对尝试Stratos带来了障碍 Stratos. 通过引入Docker/Kubernetes来支持Linux容

利用AWS boto实现EC2 存储卷的自动快照

boto是AWS的Python SDK,可以利用boto自动生成ec2的存储卷快照,实现ec2数据的备份 1.安装boot pip install boto ,如果没有安装pip,需要提前安装 2.配置boto配置文件 ~/.aws/credentials  #设置aws认证凭据   [default]  aws_access_key_id = AAAAAAAAAAAAAAA  aws_secret_access_key = TNAAAAXXXXXXXXXXXXXXXXXXXXXX ~/.aws

Kubernetes之存储卷

存储卷概述 容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题.首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失--容器以干净的状态(镜像最初的状态)重新启动.其次,在 Pod 中同时运行多个容器时,这些容器之间通常需要共享文件.Kubernetes 中的 Volume 抽象就很好的解决了这些问题.在原docker环境中也有存储卷的概念,但docker环境的存储卷调度在宿主机上的目录,当docker重新创建的时候存储卷还会挂载统一宿主机上,但我们