k8s配置与存储学习
1 配置管理-ConfigMap
ConfigMap是一种以键值对形式存放配置的文件。
1.1 ConfigMap的创建
1）ConfigMap的创建方式。（官方提供了5种创建方式，如下图所示）
# 1 使用以下命令可以查看创建ConfigMap配置文件的方法
kubectl create configmap -h
2）ConfigMap第一种创建方式。（这种方式可以创建一个目录下的多个配置文件）
# 2 第一种方法主要是按配置文件路径来创建ConfigMap配置文件
# 2.1 首先创建一个test文件夹
mkdir test
cd test
# 2.2 创建2个配置文件,并写入简单的配置内容
vim mysql.yaml
hostname: root
password: 123456
vim redis.yaml
host: 127.0.0.1
port: 8080
# 2.3进行创建
kubectl create configmap test-config(自己指定配置文件名称) --from-file=test/(配置文件存放路径)
3）ConfigMap第二种创建方式。（按指定的配置文件名来创建，一次可以创建多个或者一个）
# 3 第一种方法主要是按配置文件路径来创建指定的ConfigMap配置文件
# 3.1 先写一个配置文件
vim applicat.yaml
applicat:
name: test-app
server:
port: 8081
# 3.2 进行创建
kubectl create configmap app-test-config(指定配置文件名称) --from-file=app.yaml(设置文件名称，如果不设置，默认为配置文件的名称)=applicat.yaml(配置文件路径)
4）ConfigMap其他的创建方法不是很常用就不一一介绍了。
5）进行配置文件的查看。
# 1 查看本机目前存在那些configMap文件
kubectl get cm
# 2 查看configMap文件的详细信息
kubectl describe cm (configMap文件名称)
1.2 ConfigMap配置环境变量
1）先创建configMap。
# 1 先写configMap配置文件,这里做演示，参数少，所以使用第三种方法
# configMap的名称为 test-env-config 其中有2个键值对为 APP_OPTS_TEST='-Xms512m -Xmx512m' APP_NAME=app-env-test
kubectl create configmap test-env-config --from-literal=APP_OPTS_TEST='-Xms512m -Xmx512m' --from-literal=APP_NAME=app-env-test
2）创建一个pod进行演示，其配置文件如下。
# 1 创建pod配置文件
vim env-test-pod.yaml
# 2 配置文件内容如下
apiVersion: v1
kind: Pod
metadata:
name: test-env-pod
spec:
containers:
- name: env-test
image: alpine
command: ["/bin/sh","-c","env;sleep 3600"]
imagePullPolicy: IfNotPresent
env:
- name: APP_OPTS
valueFrom:
configMapKeyRef:
name: test-env-config # configMap的名字
key: APP_OPTS_TEST # 表示从 name 的 ConfigMap 中获取名字为 key 的 values 将其赋值给本地环境 变量 APP_OPTS - name: APP_OPTS
- name: APP
valueFrom:
configMapKeyRef:
name: test-env-config
key: APP_NAME
restartPolicy: Never
# 3 进行pod创建
kubectl create -f env-test-pod.yaml
3）进行观察，该Pod的环境变量种是否已经加载了配置信息。如下图所示，可以发现已经加载到了该pod的环境变量。
# 查看 test-env-pod 的日志信息
kubectl logs -f test-env-pod
1.3ConfigMap配置文件加载
1） 这里使用之前创建的配置文件进行测试，具体配置如1.1中方法一所示。
# 1 创建pod的配置文件
vim file-test-pod.yaml
# 2 配置文件内容如下所示
apiVersion: v1
kind: Pod
metadata:
name: test-configfile-pod
spec:
containers:
- name: configfile-test
image: alpine
command: ["/bin/sh","-c","env;sleep 3600"]
imagePullPolicy: IfNotPresent
volumeMounts: #加载数据卷
- name: db-config # 表示加载volumes中那个数据卷
mountPath: "/usr/local/mysql/conf" # 想要将数据卷中的文件加载到那个目录下
readOnly: true # 只读
volumes: # 数据卷挂载 configMap secret
- name: db-config # 数据卷的名字，可以自己起
configMap: # 数据卷类型
name: test-config # configMap的名字 ，必须和想要挂载的数据一个名字
items: # 对 configMap中的key进行映射，如果不指定默认将configMap中的所有的key全部替换为一个个同名的文件
- key: "db.yaml" # configmap 中的 key
path: "db.properties" # 将该key 的值 转换为文件
restartPolicy: Never
# 3 进行pod的创建
kubectl create -f file-test-pod.yaml
2）进行观察是否已经挂载成功，如下图所示。
# 1 进入创建的pod的内部
kubectl exec -it test-configfile-pod -- sh
# 2 去找是否将配置文件挂载成功
cd /usr/local/mysql/conf/
1.4 SubPath解决目录覆盖问题
使用 ConfigMap 或 Secret 挂载到目录的时候，会将容器中源目录给覆盖掉，此时我们可能只想覆盖目录中的某一个文件，但是这样的操作会覆盖整个文件，因此需要使用到 SubPath。
1）首先创建一个nginx.conf文件，试图将其挂载到nginx pod的目录下。
vim nginx.conf (其内容，随便找个nginx.conf的内容复制过来即可)
2）进行挂载，修改nginx-deploy的容器信息。其内容修改如下如图所示。
3）当执行以上操作保存后，会自动重新启动nginx容器。使用以下命令进入到nginx容器内部进行观察，会发现nginx目录下只存在nginx.conf文件了。这是因为当前目录直接覆盖了nginx原本的目录。
kubectl exec -it (xxxx-pod名称) -- sh
4）使用subPath来解决该目录被覆盖的问题，如下如图所示。
5）再次进入nginx的etc/nginx目录下就会发现，其他文件都存在，并将本地的nginx.conf挂载了进来。
1.5 ConfigMap的热更新
1）对使用了subPath的Pod是不会进行更新的。
2）使用edit命令进行修改。
kubectl edit cm (configMap名称)
3)使用replace进行替换configMap配置文件。
# kubectl create cm --from-file=nginx.conf 得到一个yaml文件
# --dry-run 打印yaml文件，但是不会发送给apiserver
# -oyaml 输出yaml文件
# kubectl replace -f- 将上面输出的文件作为输入进行替换
kubectl create cm --from-file=nginx.conf --dry-run -oyaml | kubectl replace -f-
1.6 ConfigMap配置文件不可变
1）有时有些配置文件比较重要，所以要求在系统上线后就不允许再修改配置文件了，所以就要使用到配置文件不可变。其使用方式如下如图所示，只需要在配置文件中加入immutable: true即可。
2 存储管理-持久化存储
1.1 主机和容器内容共享-HostPath
1）使用HostPath来实现，主机和容器中的内容进行共享，其配置如下所示。
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: nginx
name: nginx-volume
volumeMounts:
- mountPath: /test-pd # 挂载到容器的哪个目录
name: test-volume # 挂载哪个 volume
volumes:
- name: test-volume
hostPath:
path: /data # 节点中的目录
type: DirectoryOrCreate # 检查类型，在挂载前对挂载目录做什么检查操作，有多种选项，默认为空字符串，不做任何检查
其中使用HostPath时有以下几种type。
空字符串：默认类型，不做任何检查
DirectoryOrCreate：如果给定的 path 不存在，就创建一个 755 的空目录
Directory：这个目录必须存在
FileOrCreate：如果给定的文件不存在，则创建一个空文件，权限为 644
File：这个文件必须存在
Socket：UNIX 套接字，必须存在
CharDevice：字符设备，必须存在
BlockDevice：块设备，必须存在
2）进行容器的创建，并查看其挂在那个节点上。
kubectl create -f (xxxxx.yaml 配置文件名称)
kubectl get po -o wide
3）去对应的节点的根目录下会发现多了一个data文件夹。这是因为本例使用的是DirectoryOrCreate类型。
# 进入data文件下，创建一个文本文件。
cd data
vim test.html
This is a test (本文中写入内容)
4）使用以下命令进入创建的容器中。
# 以命令行方式进入容器
kubectl exec -it (pod名称) -- sh
# 进入test-pd中，因为本例中是将容器卷挂载到test-pd目录下的
cd test-pd
# 进行查看，会发现test.html已经存在
ls
# 对test.html中追加新内容
echo '1111' >> test.html
5）再次回到容器对应的节点中，查看test.html文本，会发现本文已经更新了。
# 在节点下再次对test.html进行查看，会发现1111已经追加到文本中了
cat test.html
1.2 一个pod中的2个容器进行数据共享-EmptyDir
1）EmptyDir可以实现一个pod中的2容器进行数据的共享。但是其没有持久化功能，即pod一旦被删除则数据也会丢失。其配置文件如下所示。
apiVersion: v1
kind: Pod
metadata:
name: empty-dir-pd
spec:
containers:
- image: nginx
name: emptydir1 # 第一个容器
volumeMounts:
- mountPath: /cache # 挂载到的目录
name: cache-volume
- image: nginx
name: emptydir2 # 第二个容器
volumeMounts:
- mountPath: /opt # 挂载到的目录
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
2）对Pod进行创建。并开启2个窗口分别进入容器内部。
# 对pod进行创建
kubectl create -f (xxxx.yaml 配置文件名称)
# 进入第一个容器
kubectl exec -it (xxxx.xxx pod名称) -c (第一个容器名称) --sh
# 进入第二个容器
kubectl exec -it (xxxx.xxx pod名称) -c (第二个容器名称) --sh
3）分别进入2个容器各自挂载的目录cache和opt。
# 第一个容器
cd cache
# 第二个容器
cd opt
# 在的第一个容器创建文本进行测试
vim test.html
# 第二个容器下也会出现test.html文本，此时就完成了数据的共享
1.3 NFS的设置
1）由于使用EmptyDir来进行pod中容器之间数据共享时会出现pod删除，数据丢失的情况。所以就引入了NFS来进行可以持久化的数据共享。
2）NFS的安装。是需要在每个node节点都进行安装，因为NFS是基于局域网进行数据共享的。
# NFS的下载
yum install nfs-utils -y
# NFS启动
systemctl start nfs-server
3）进行测试是否安装成功。
# 找一个磁盘容量大的节点，创建共享目录(本示例是将nfs放在101节点的home下)
mkdir -p /home/nfs
# 在nfs下创建只读和可读可写文件
cd /home/nfs
mkdir rw
mkdir ro
# 设置共享目录 export (这个网段需要设置为虚拟机所在的网段)
vim /etc/exports
/data/nfs/rw 192.168.229.0/24(rw,sync,no_subtree_check,no_root_squash)
/data/nfs/ro 192.168.229.0/24(ro,sync,no_subtree_check,no_root_squash)
# 重新加载
exportfs -f
systemctl reload nfs-server
# 到其他测试节点安装 nfs-utils 并加载测试
# 在master节点下创建2个目录
mkdir -p /mnt/nfs/rw
mkdir -p /mnt/nfs/ro
# 将101节点创建的共享目录映射到master下
mount -t nfs 192.168.229.101:/home/nfs/rw /mnt/nfs/rw
mount -t nfs 192.168.229.101:/home/nfs/ro /mnt/nfs/ro
4） 然后进行文件的创建等操作，就可以发现master和noe1节点之间可以进行文件共享了。
1.4 NFS文件系统的挂载
1）使用NFS对容器进行文件挂载的配置文件如下所示。
apiVersion: v1
kind: Pod
metadata:
name: nfs-test-pd1
spec:
containers:
- image: nginx
name: test-container
volumeMounts:
- mountPath: /usr/share/nginx/html
name: test-volume
volumes:
- name: test-volume
nfs:
server: 192.168.229.101 # 网络存储服务地址
path: /home/nfs/rw/www/index # 网络存储路径
readOnly: false # 是否只读
2）去NFS共享目录节点的rw下创建www/index目录，并创建index.html，其中写入helloworld用来覆盖nginx原本的html。
3）对Pod其进行创建。
kubectl create -f (xxxx.yaml 配置文件名称)
4）这里出现了一点小错误，在创建好之后一致run不起来，查看pod的详情发现了以下错误。
# 错误如下
Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container ...
# 经过查阅发现是calico.yaml文件配置中少了东西
# 找到calico.yaml文件，我的是在opt/k8s/cni下
# 找到CALICO_IPV4POOL_CIDR，并在同级目录下配置以下信息
- name: IP_AUTODETECTION_METHOD
value: "interface=eth0" #eth0是本地网卡名称
# 然后进行更新
kubectl apply -f calico.yaml
# 再次对pod进行创建就发现ok了
5）当容器创建成功后，查看nginx的index.html文件。就会发现展现的是helloworld，而不是nginx自带的index页面了。
# 先查看pod对应的地址
kubectl get po -o wide
# 进行查看
curl (对应的ip地址)
6）此时在NFS共享目录下修改index.html文件，则nginx容器的index.html页面也会被更改。并且如果pod节点被删除后，其数据仍然存在于NFS共享目录下，不会丢失。
1.5 PV与PVC
（1）PV就是持久卷，它用来管理磁盘等存储，就像是给磁盘存储进行了一次抽象。
PVC就是持久卷申领，是用户对存储的请求，也就是使用PVC来申领PV。
如下图所示PV就是对磁盘进行管理，PVC就是对Pod所需资源的一个配置，然后PVC通过相对的配置信息去找合适 的PV。
（2）PV的创建，其配置如下。
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
spec:
capacity:
storage: 5Gi # pv 的容量
volumeMode: Filesystem # 存储类型为文件系统
accessModes: # 访问模式：ReadWriteOnce、ReadWriteMany、ReadOnlyMany
- ReadWriteOnce # 可被单节点独写
persistentVolumeReclaimPolicy: Recycle # 回收策略
storageClassName: slow # 创建 PV 的存储类名，需要与 pvc 的相同
mountOptions: # 加载配置
- hard
- nfsvers=4.1
nfs: # 连接到 nfs
path: /data/nfs/rw/test-pv # 存储路径
server: 192.168.229.101 # nfs 服务地址
# 创建pv
kubectl create -f xxx.yaml
# 查看创建的pv
kubectl get pv
（3）PVC的创建，其配置如下。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteOnce # 权限需要与对应的 pv 相同
volumeMode: Filesystem
resources:
requests:
storage: 3Gi # 资源可以小于 pv 的，但是不能大于，如果大于就会匹配不到 pv
storageClassName: slow # 名字需要与对应的 pv 相同
# selector: # 使用选择器选择对应的 pv
# matchLabels:
# release: "stable"
# matchExpressions:
# - {key: environment, operator: In, values: [dev]}
# 创建pvc
kubectl create -f xxx.yaml
# 查看创建的pvc
kubectl get pvc
（4）当pv和pvc创建好了之后，就会发现pvc已经关联到了pv上。如下图所示。
（5）接下来创建一个Pod进行测试，其配置文件如下。
apiVersion: v1
kind: Pod
metadata:
name: test-pvc-pd
spec:
containers:
- image: nginx
name: nginx-volume
volumeMounts:
- mountPath: /usr/share/nginx/html # 挂载到容器的哪个目录
name: test-volume # 挂载哪个 volume
volumes:
- name: test-volume
persistentVolumeClaim: # 关联 pvc
claimName: nfs-pvc # 要关联到那个pvc
# 创建pvc-test-pod
kubectl create -f xxx.yaml
# 查看创建的pod
kubectl get pod -o wide
随后在设置pv下的/data/nfs/rw/test-pv存储路径下创建一个index.html文件，将其挂载到test-pvc-pd中。然后使用以下命令就可以看到在data路径下存储的index.html就已经挂载到了pod中。
# 进入test-pv目录下
cd /data/nfs/rw/test-pv
# 进行index.html文件的创建,并写入hello
echo 'hello' > index.html
# 通过curl + 该pod对应的地址，就可以看到hello被输出
1.6 StorageClass
在之前，我们都是需要自己创建好PV供PVC去选择，但是StorageClass可以自动的通过PVC的配置去创建PV。其大致工作流程如下图所示。（由于其中要使用到身份认证的相关知识，所以之后再进行学习如何使用）
903
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
