哈喽~大家好呀，我们这篇继续开始上篇和上上篇的讲解，好吧，废话少说，我们就来开始上课吧！
一、基本概念与NFS环境搭建
看图，在未来，我们有各种各样的 Pod，有一些数据想挂在外面修改，比如：我们将 Pod 的 / data，挂在到 / a里面，其他也一样。
当我们三号机某一应用出现故障时，这是他会故障转移，等 5 分钟后还没自愈成功，这是会转移到 2 号机上面，但三号机的数据会在 2 号机吗？答案是不会。我们将外面的叫——存储层。
1、搭建网络文件系统
要搭建，必须所有的人都安装 nfs
所有机器安装
yum install -y nfs-utils
然后在主节点设置 nfs 主节点
echo "/nfs/data/ *(insecure,rw,sync,no_root_squash)" > /etc/exports
mkdir -p /nfs/data systemctl enable rpcbind --now systemctl enable nfs-server --now
检查配置是否生效
exportfs -r
执行命令挂载 nfs 服务器上的共享目录到本机路径 /root/nfsmount
mkdir -p /nfs/data mount -t nfs 172.31.0.4:/nfs/data /nfs/data
写入测试文件
echo "hello nfs server" > /nfs/data/test.txt
2、Deplryment使用NFS进行挂载
输入一下代码来测试一下
apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx-pv-demo name: nginx-pv-demo spec: replicas: 2 selector: matchLabels: app: nginx-pv-demo template: metadata: labels: app: nginx-pv-demo spec: containers: - image: nginx name: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/html volumes: - name: html nfs: server: 172.31.0.4 path: /nfs/data/nginx-pv
二、PV 与 PVC使用
啥是 PV？啥又是 PVC ？
PV：持久卷（Persistent Volume），将应用需要持久化的数据保存到指定位置
PVC：持久卷申明（Persistent Volume Claim），申明需要使用的持久卷规格
举个例子，假设我们需要 1GB 的持久卷（PV），那么 PVC 就是我们 Pod 要去申请的申请书，申请书与 PV 的卷符合之后，再来确定位置。
1、创建pv池
nfs主节点
mkdir -p /nfs/data/01 mkdir -p /nfs/data/02 mkdir -p /nfs/data/03
创建PV
（注：记得改 server 的地址）
apiVersion: v1 kind: PersistentVolume metadata: name: pv01-10m spec: capacity: storage: 10M accessModes: - ReadWriteMany storageClassName: nfs nfs: path: /nfs/data/01 server: 172.31.0.4 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv02-1gi spec: capacity: storage: 1Gi accessModes: - ReadWriteMany storageClassName: nfs nfs: path: /nfs/data/02 server: 172.31.0.4 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv03-3gi spec: capacity: storage: 3Gi accessModes: - ReadWriteMany storageClassName: nfs nfs: path: /nfs/data/03 server: 172.31.0.4
PV 创建好了之后再来创建 PVC
创建Pod绑定PVC
apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx-deploy-pvc name: nginx-deploy-pvc spec: replicas: 2 selector: matchLabels: app: nginx-deploy-pvc template: metadata: labels: app: nginx-deploy-pvc spec: containers: - image: nginx name: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/html volumes: - name: html persistentVolumeClaim: claimName: nginx-pvc
三、使用SConfigMap抽取配置
在这里挂在文件用 ConfigMap
作用：抽取应用配置，并且可以自动更新
创建配置，redis保存到k8s的etcd；
kubectl create cm redis-conf --from-file=redis.conf
data是所有真正的数据，key：默认是文件名 value：配置文件的内容
apiVersion: v1 data: redis.conf: | appendonly yes kind: ConfigMap metadata: name: redis-conf namespace: default
创建Pod
apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: redis command: - redis-server - "/redis-master/redis.conf" #指的是redis容器内部的位置 ports: - containerPort: 6379 volumeMounts: - mountPath: /data name: data - mountPath: /redis-master name: config volumes: - name: data emptyDir: {} - name: config configMap: name: redis-conf items: - key: redis.conf path: redis.conf
检查默认配置
kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET appendonly 127.0.0.1:6379> CONFIG GET requirepass
修改ConfigMap
apiVersion: v1 kind: ConfigMap metadata: name: example-redis-config data: redis-config: | maxmemory 2mb maxmemory-policy allkeys-lru
检查配置是否更新
kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 127.0.0.1:6379> CONFIG GET maxmemory-policy
检查指定文件内容是否已经更新
修改了CM。Pod里面的配置文件会跟着变
配置值未更改，因为需要重新启动 Pod 才能从关联的 ConfigMap 中获取更新的值。
原因：我们的Pod部署的中间件自己本身没有热更新能力
四、Secret场景示例
Secret 对象类型用来保存敏感信息，例如密码、令牌和密钥等信息。 将这些信息放在 secret 中比放在 Pod 的定义或者容器镜像中来说更加安全和灵活。
kubectl create secret docker-registry leifengyang-docker \ --docker-username=leifengyang \ --docker-password=Lfy123456 \ --docker-email=534096094@qq.com ##命令格式 kubectl create secret docker-registry regcred \ --docker-server=<你的镜像仓库服务器> \ --docker-username=<你的用户名> \ --docker-password=<你的密码> \ --docker-email=<你的邮箱地址>
apiVersion: v1 kind: Pod metadata: name: private-nginx spec: containers: - name: private-nginx image: leifengyang/guignginx:v1.0 imagePullSecrets: - name: leifengyang-docker
好了致辞我们 k8s 篇就讲完了，下一篇就来到了 KubeSphere 篇。
