容器设计模式
基于容器的分布式系统中常用的3类设计模式
◼ 单容器模式：单一容器形式运行的应用
◼ 单节点模式：由强耦合的多个容器协同共生
◼ 多节点模式：基于特定部署单元（Pod）实现分布式算法
单节点多容器模式
◼ 一种跨容器的设计模式
◼ 目的是在单个节点之上同时运行多个共生关系的容器，因而容器管理系统需要由将它们作为一个原子单位进行统一调度
◼ Pod概念就是这个设计模式的实现之一
单节点多容器模式的常见实现
◼ Sidecar模式 (挎斗模式)
◆ Pod中的应用由主应用程序（通常是基于HTTP协议的应用程序）以及一个Sidecar容器组成
◆ 辅助容器用于为主容器提供辅助服务以增强主容器的功能，是主应用程序是必不可少的一部分，但却未必非得运行为应用的一部分
◼ Ambassador模式(大使模式)
◆ Pod中的应用由主应用程序和一个Ambassador容器组成
◆ 辅助容器代表主容器发送网络请求至外部环境中，因此可以将其视作主容器应用的“大使”
◆ 应用场景：云原生应用程序需要诸如断路、路由、计量和监视等功能，但更新已有的应用程序或现有代码库以添加这些功能可能很困难，甚至难以实现，进程外代理便成了一种有效的解决方案
◼ Adapter模式(适配器容器)
◆ Pod中的应用由主应用程序和一个Adapter容器组成
◆ Adapter容器为主应用程序提供一致的接口，实现了模块重用，支持标准化和规范化主容器应用程序的输出以便于外部服务进行聚合
◼ Init Container模式(初始化容器)
◆ 一个Pod中可以同时定义多个Init容器
◆ Init容器负责以不同于主容器的生命周期来完成那些必要的初始化任务，包括在文件系统上设置必要的特殊权限、数据库模式设置或为主应用程序提供初始数据等，但这些初始化逻辑无法包含在应用程序的镜像文件中，或者出于安全原因，应用程序镜像没有执行初始化活动的权限等等
◆ Init容器需要串行运行，且在所有Init容器均正常终止后，才能运行主容器
实验
使用初始化容器模拟实验：
[root@master1 chapter4]#vim init-container-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: init-container-demo
namespace: default
spec:
initContainers: #定义一个初始化容器
- name: iptables-init
image: ikubernetes/admin-box:latest
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c']
args: ['iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80']
securityContext:
capabilities:
add:
- NET_ADMIN
containers: #定义一个持久运行的容器
- name: demo
image: ikubernetes/demoapp:v1.0
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
存储卷
存储卷的基本概念
从概念上讲，存储卷是可供Pod中的所有容器访问的目录
◼ Pod规范中声明的存储卷来源决定了目录的创建方式、使用的存储介质以及目录的初始内容
◆ 存储卷插件（存储驱动）决定了支持的后端存储介质或存储服务，例如
hostPath插件使用宿主机文件系统，而nfs插件则对接指定的NFS存储服务等
◆ kubelet内置支持多种存储卷插件
◼ Pod在规范中需要指定其包含的卷以及这些卷在容器中的挂载路径
存储卷对象并非Kubernetes系统一等公民，它定义在Pod上，因而卷本身的生命周期同Pod，但其后端的存储及相关数据的生命周期通常要取决于存储介质
存储卷类型和相应的插件
In-Tree存储卷插件
◼ 临时存储卷
◆ emptyDir
◼ 节点本地存储卷
◆ hostPath, local
◼ 网络存储卷
◆ 文件系统：NFS、GlusterFS、CephFS和Cinder
◆ 块设备：iSCSI、FC、RBD和vSphereVolume
◆ 存储平台：Quobyte、PortworxVolume、StorageOS和ScaleIO
◆ 云存储：awsElasticBlockStore、gcePersistentDisk、azureDisk和azureFile
◼ 特殊存储卷
◆ Secret、ConfigMap、DownwardAPI和Projected
◼ 扩展接口
◆ CSI和FlexVolume
Out-of-Tree存储卷插件
◼ 经由CSI或FlexVolume接口扩展出的存储系统称为Out-of-Tree类的存储插件
存储卷资源规范
定义存储卷
◼ 存储卷对象并非Kubernetes系统一等公民，它需要定义在Pod上
◼ 卷本身的生命周期同Pod，但其后端的存储及相关数据的生命周期通常要取决于存储介质
存储卷的配置由两部分组成
◼ 通过.spec.volumes字段定义在Pod之上的存储卷列表，它经由特定的存储卷插件并结合特定的存储供给方的访问接口
进行定义
◼ 嵌套定义在容器的volumeMounts字段上的存储卷挂载列表，它只能挂载当前Pod对象中定义的存储卷
存储卷的运用
emptyDir存储卷
emptyDir存储卷
◼ Pod对象上的一个临时目录
◼ 在Pod对象启动时即被创建，而在Pod对象被移除时一并被删除
◼ 通常只能用于某些特殊场景中
◆ 同一Pod内的多个容器间文件共享
◆ 作为容器数据的临时存储目录用于数据缓存系统
配置参数
◼ medium：此目录所在的存储介质的类型，可用值为“default”或“Memory”
◼ sizeLimit：当前存储卷的空间限额，默认值为nil，表示不限制
临时存储实验
[root@master1 chapter5]#vim pods-with-rmptyDir.yaml
apiVersion: v1
kind: Pod
metadata:
name: pods-with-emptydir-vol
spec:
containers:
- image: ikubernetes/admin-box:v1.2
name: admin
command: ["/bin/sh" , "-c"]
args: ["sleep 99999"]
volumeMounts:
- name: data
mountPath: /data
- image: ikubernetes/demoapp:v1.0
name: demoapp
volumeMounts:
- name: data
mountPath: /var/www/html
volumes:
- name: data
emptyDir:
medium: Memory #使用内存空间
sizeLimit: 16Mi
hostPath存储卷
hostPath卷
◼ 将Pod所在节点上的文件系统的某目录用作存储卷
◼ 数据的生命周期与节点相同
配置参数
◼ path：指定工作节点上的目录路径，必选字段
◼ type：指定节点之上存储类型
实验：节点存储
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis:6 #镜像名字
imagePullPolicy: IfNotPresent #镜像拉取策略
volumeMounts:
- name: redisdata #指定存储卷
mountPath: /data #挂载目录
volumes:
- name: redisdata
hostPath:
type: DirectoryOrCreate #有这个目录就用没有就创建
path: /data/redis
存储类型可以看https://kubernetes.io/docs/concepts/storage/volumes#hostpath中的信息有详细说明
NFS存储卷
nfs存储卷
◼ 将nfs服务器上导出（export）的文件系统用作存储卷
◼ nfs是文件系统级共享服务，它支持多路挂载请求，可由多
个Pod对象同时用作存储卷后端
配置参数
◼ server ：NFS服务器的IP地址或主机名，必选字段
◼ path ：NFS服务器导出（共享）的文件系统路径，
必选字段
◼ readOnly ：是否以只读方式挂载，默认为false
实验一：保存redis数据
#安装NFS服务
[root@master2 ~]#apt install -y nfs-common #安装nfs客户端
[root@ubuntu2004 redis]#vim /etc/exports #编辑共享目录的权限
/data/redis 10.0.0.0/24(rw,no_subtree_check,no_root_squash)
[root@ubuntu2004 redis]#mkdir /data/redis #将共享的目录创建出去
[root@ubuntu2004 redis]#exportfs -ra #读取配置文件
[root@ubuntu2004 redis]#exportfs -v #显示共享的目录详细信息
/data/redis 10.0.0.0/24(rw,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
#在k8s服务节点上创建使用nfs的pod
[root@master1 ~]#apt install -y nfs-common
[root@master1 chapter5]#vim /wwj/test/pod-redis2.yaml
apiVersion: v1
kind: Pod
metadata:
name: redis2 #资源的名称
spec: #定义终态
containers: ##对象列表
- name: redis2 #容器的名字
image: redis:6 #镜像
imagePullPolicy: IfNotPresent #拉取策略
volumeMounts: #定义存储卷
- name: redisdata #使用redisdata这个定义好的存储
mountPath: /data #挂载到容器的/data目录上
volumes: #定义存储卷
- name: redisdata #指定这个存储卷的名字
nfs: #使用nfs服务
server: 10.0.0.106 #远程服务的地址
path: /data/redis #远程服务的共享目录
实验二：保存MySQL数据及wordpress
#定义MySQL的存储卷
[root@master1 wordpress]#vim mysql/02-mysql.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: mysql
name: mysql
spec:
replicas: 1
selector:
matchLabels:
app: mysql
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: mysql
spec:
containers:
- image: mysql:8.0
name: mysql
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
env:
- name: MYSQL_RANDOM_ROOT_PASSWORD
value: "1"
- name: MYSQL_DATABASE
value: "wordpress"
- name: MYSQL_USER
value: "wordpress"
- name: MYSQL_PASSWORD
value: "123456"
resources: #资源限制
requests: #资源需求为
memory: "128Mi" #128M内存
cpu: "200m" #占用一个核心cpu的百分之20
limits: #资源限制
memory: "512Mi" #最大使用内存为
cpu: "400m" #最大使用cpu为
livenessProbe: #存活探针
exec: #执行的命令
command: [ 'mysqladmin', '-uwordpress', '-p123456' ,'ping' ]
initialDelaySeconds: 5 #延迟探针时间
timeoutSeconds: 15 #超时时间
periodSeconds: 5 #周期性间隔时间
readinessProbe:
exec:
command: [ 'mysql','-uwordpress','-p123456' ]
initialDelaySeconds: 5 #延迟探针时间
timeoutSeconds: 15 #超时时间
periodSeconds: 5 #周期时间
volumes: #定义储存卷
- name: mysql-data #定义储存卷的名字
nfs: #使用NFS储存
server: 10.0.0.106 #指定nfs的地址
path: /data/mysql #指定nfs的共享目录的路径
#定义wordpress的储存卷
[root@master1 wordpress]#vim mysql/02-mysql.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: wordpress
name: wordpress
spec:
replicas: 1
selector:
matchLabels:
app: wordpress
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: wordpress
spec:
containers:
- image: wordpress:5.7
name: wordpress
ports: #定义posts端口
- name: http #名字为http
containerPort: 80
volumeMounts:
- name: wordpress-data
mountPath: /var/www/html
env:
- name: WORDPRESS_DB_HOST
value: "mysql"
- name: WORDPRESS_DB_NAME
value: "wordpress"
- name: WORDPRESS_DB_USER
value: "wordpress"
- name: WORDPRESS_DB_PASSWORD
value: "123456"
resources: #资源限制
requests: #资源需求为
memory: "128Mi" #128M内存
cpu: "200m" #占用一个核心cpu的百分之20
limits: #资源限制
memory: "512Mi" #最大使用内存为
cpu: "400m" #最大使用cpu为
readinessProbe: #活体探针——就绪探针
httpGet:
path: /wp-admin/install.php
port: 80
scheme: HTTP
initialDelaySeconds: 3 #探测延时时间
timeoutSeconds: 10 #超时时间
periodSeconds: 5 #周期时间
failureThreshold: 3 #失败阈值
livenessProbe: #存活探针
tcpSocket: #使用TCP套接字连接探测
port: http #使用http
periodSeconds: 5 #周期为5s
initialDelaySeconds: 5 #启动延迟探测时间为5s
volumes:
- name: wordpress-data
nfs:
server: 10.0.0.106
path: /data/wordpress
持久卷
PV和PVC
在Pod级别定义存储卷有两个弊端
◼ 卷对象的生命周期无法独立于Pod而存在
◼ 用户必须要足够熟悉可用的存储及其详情才能在Pod上配置和使用卷
PV和PVC可用于降低这种耦合关系
◼ PV（Persistent Volume）是集群级别的资源，负责将存储空间引入到集群中，通常由管理员定义
◼ PVC（Persistent Volume Claim）是名称空间级别的资源，由用户定义，用于在空闲的PV中申请使用符合过滤
条件的PV之一，与选定的PV是“一对一”的关系
◼ 用户在Pod上通过pvc插件请求绑定使用定义好的PVC资源
StorageClass资源支持PV的动态预配（Provision）
PV资源
◼ PV是标准的资源类型，除了负责关联至后端存储系统外，它通常还需要定义支持的存储特性
◆ Volume Mode：当前PV卷提供的存储空间模型，分为块设备和文件系统两种
◆ StorageClassName：当前PV隶属的存储类；
◆ AccessMode：支持的访问模型，分为单路读写、多路读写和多路只读三种
◆ Size：当前PV允许使用的空间上限
◼ 在对象元数据上，还能够根据需要定义标签
◼ 一般需要定义回收策略：Retain、Recycle和Delete
PVC资源
◼ PVC也是标准的资源类型，它允许用户按需指定期望的存储特性，并以之为条件，按特定的条件顺序进行PV过滤
◆ VolumeMode → LabelSelector → StorageClassName → AccessMode → Size
◼ 支持动态预配的存储类，还可以根据PVC的条件按需完成PV创建
使用静态PV和PVC
使用静态PV和PVC的配置卷的步骤
定义存储：由管理完成
消费存储：最终用户
PV/PVC
pv: persistent volume
标准的API资源类型，支持声明式创建
由管理员负责管理
集群级别的资源
不能够被Pod直接使用
pvc: persistent volume claim
标准的API资源类型，支持声明式创建
由最终用户负责创建
名称空间级别的资源
可被Pod直接使用
In-Tree的卷插件类型
persistentVolumeClaim:
claimName: <PVC_NAME>
PV如何满足PVC期望？
1、管理员事先创建多种规格的PV；
2、管理流程：提交工单；
PV静态置备（Static Provisioning）
3、管理员不去创建PV，取而代之，创建StorageClass（PV模板）管理员创建SC资源对象：配置了远程存储服务管理接口的API调用操作
远程存储服务：有管理API，而且还要支持远程访问
PV动态置备（Dynamic Provisioning）
实验静态置备卷
#创建pv
[root@master1 chapter5]#vim pv-nfs-demo.yaml
apiVersion: v1 #指定资源版本
kind: PersistentVolume #指定资源类型
metadata: #元数据
name: pv-nfs-demo #资源名称
spec: #定义终态
capacity: #指定大小
storage: 5Gi #定义大小
volumeMode: Filesystem #指的设备类型
accessModes: #指定工作模式
- ReadWriteMany #多路读写
- ReadOnlyMany #多路只读
- ReadWriteOnce #单路读写
persistentVolumeReclaimPolicy: Retain #使用的删除策略为Retain
mountOptions: #使用的存储类型
- hard
- nfsvers=4.1 #为nfs存储
nfs:
path: "/data/pv1" #指定的远程目录为
server: 10.0.0.106 #远程服务器的地址
[root@master1 chapter5]# kubectl apply -f pv-nfs-demo
[root@master1 chapter5]#kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs-demo 5Gi RWO,ROX,RWX Retain Available 4m
#NAME：pv的名字
#CAPACITY：pv的空间
#ACCESS MODES：支持的模式
#RECLAIM POLICY：卷的移除策略
#STATUS：是否被绑定(Available是没有)
#CLAIM：绑定关系
#STORAGECLASS：存储类型
#REASON：关联关系(是什么原因导致的)
#AGE：
定义pvc
#创建pvc
[root@master1 chapter5]#vim pvc-demo-0001.yaml
apiVersion: v1 #资源版本
kind: PersistentVolumeClaim #资源类型
metadata: #元数据
name: pvc-demo-0001 #资源名称
namespace: default #名称空间
spec: #定义终态
accessModes: ["ReadWriteMany"] #指定工作模式为ReadWriteMany
volumeMode: Filesystem #指定设备类型
resources: #资源定义
requests: #最小容量为3G
storage: 3Gi
limits: #最大容量为10G
storage: 10Gi
[root@master1 chapter5]#kubectl apply -f pvc-demo-0001.yaml
[root@master1 chapter5]#kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-demo-0001 Bound pv-nfs-demo 5Gi RWO,ROX,RWX 7m59s
#NAME：指定pvc名字为pvc-demo-0001
#STATUS：绑定状态为绑定
#VOLUME：绑定的pv为pv-nfs-demo
#CAPACITY：pvc的大小为5G
#ACCESS MODES: 工作类型为RWO,ROX,RWX
#AGE：创建的时间
创建pod引用pvc
[root@master1 chapter5]#vim volumes-pvc-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-pvc-demo
namespace: default
spec:
containers:
- name: redis
image: redis:6
imagePullPolicy: IfNotPresent
ports: #开一个端口
- containerPort: 6379
name: redisport #名字
volumeMounts: #定义挂载目录及卷
- mountPath: /data
name: redis-rbd-vol
volumes:
- name: redis-rbd-vol #名字
persistentVolumeClaim: #使用pvc
claimName: pvc-demo-0001 #pvc的名字
StorageClass
实验基于csi-driver-nfs动态置备卷
StorageClass资源
◼ Kubernetes支持的标准资源类型之一
◼ 为管理PV资源之便而按需创建的存储资源类别（逻辑组）
◼ 是PVC筛选PV时的过滤条件之一
◼ 为动态创建PV提供“模板”
◆ 需要存储服务提供管理API
◆ StorageClass资源上配置接入API的各种参数
⚫ 定义在parameters字段中
⚫ 还需要使用provisioner字段指明存储服务类型
◼ 一般由集群管理员定义，隶属集群级别
PVC和动态PV
有些存储类型默认并不支持动态PV机制，如右图所示
多数CSI存储都支持动态PV，且支持卷扩展和卷快照等功能
Kubernetes存储架构及CSI简介
Kubernetes存储架构
存储卷的具体的管理操作由相关的控制器向卷插件发起调用请求来完成
◼ AD控制器：负责存储设备的Attach/Detach操作
◆ Attach：将设备附加到目标节点
◆ Detach：将设备从目标节点上拆除
◼ 存储卷管理器：负责完成卷的Mount/Umount操作，以及设备的格式化操作等
◼ PV控制器：负责PV/PVC的绑定、生命周期管理，以及存储卷的Provision/Delete操作
Scheduler：特定调度插件的调度决策会受到目标节点上的存储卷的影响
Out-of-Tree存储
CSI简介
◼ 容器存储接口规范，与平台无关
◼ 驱动程序组件
◆ CSI Controller：负责与存储服务的API通信从而完成后端存储的管理操作
◆ Node Plugin：也称为CSI Node，负责在节点级别完成存储卷的管理
CSI存储组件和部署架构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qd1339dw-1670485801739)(kubernetes的基础概念和安装.assets/image-20221208150449593.png)]
CSI Controller Pod中的Sidecar容器
◼ CSI Controller被假定为不受信任而不允许运行于Master节点之上，因此，kube-controller-manager无法借助
UnixSock套接字与之通信，而是要经由API Server进行；
◼ 该通用需求由Kubernetes提供的external-attacher和external-provisioner程序完成，此两者通常会以一个Sidecar容器运行于CSI Controller Pod中
◆ external-attacher：负责针对CSI上的卷执行attach和detach操作，类似于CSI专用的AD Controller
◆ external-provisioner：负责针对CSI上的卷进行Provision和Delete操作等，类似于CSI专用的PV Controller
◼ CSI支持卷扩展和快照时，可能还会用到external-resizer和external-snapshotter一类的程序
CSI Node Pod中的Sidecar容器
◼ kubelet（实现卷的Mount/Umount操作）将UnixSock套接字与CSI Node Plugin进行通信
◼ 将Node Plugin注册到kubelet上，并初始化NodeID（获取从Kubernetes节点名称到CSI驱动程序NodeID的映射）的功能由通用的node-driver-registrar程序提供，它通用运行为CSI Node Pod的Sidecar容器
部署及使用NFS CSI
kubernetes-csi/csi-driver-nfs项目在其代码仓库中提供了示例性的部署及测试配置文件，它们都位于deploy目录下
我们采用将代码仓库克隆到本地，而后基于本地的配置清单完成部署
① 部署NFS Provisioner
◆ 示例配置文件为deploy/example/nfs-provisioner/nfs-server.yaml，可按需定义节点上用于存储数据的目录路径
◆ ~$ kubectl apply -f deploy/example/nfs-provisioner/nfs-server.yaml
② 部署NFS CSI Driver
◆ 首先需要确认deploy/csi-nfs-driverinfo.yaml文件中，CSIDriver资源隶属的API群组为“storage.k8s.io/v1”
⚫ 提示：废除了对“storage.k8s.io/v1beta1”群组支持的较新版本的Kubernetes有此要求
◆ 示例部署脚本为deploy/install-driver.sh，向其传递参数即可完成部署，例如如下
⚫ ./deploy/install-driver.sh master local
③ 测试
◆ 首先需要创建基于NFS CSI的PVC，或者创建一个支持动态PV创建的StorageClass，这些deploy/example/nfs-provisioner/nginx-pod.yaml文件中有示例
◆ kubectl apply -f deploy/example/nfs-provisioner/nginx-pod.yaml
阿里云的CSI插件简介
阿里云CSI插件实现了在Kubernetes中对阿里云云存储卷的生命周期管理
◼ CSI-Plugin组件遵循标准CSI规范，提供了EBS、NAS、OSS等类型阿里云云存储服务的挂载能力
◼ 自ACK 1.16版本的集群开始，部署集群时默认即会自动安装最新版本的CSI组件
◼ CSI Plugin提供了数据卷的全生命周期管理，包括数据卷的：创建、挂载、卸载、删除、扩容等服务
实验：动态置备卷
安装csi-driver-nfs
#1、部署nfs server；
[root@master1 test]# kubectl create namespace nfs
[root@master1 test]#kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/deploy/example/nfs-provisioner/nfs-server.yaml --namespace nfs
service/nfs-server unchanged
deployment.apps/nfs-server unchanged
[root@master1 chapter5]#kubectl get svc -n nfs
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nfs-server ClusterIP 10.102.58.246 <none> 2049/TCP,111/UDP 3h40m
#2、部署nfs csi driver;
[root@master1 test]#curl -skSL https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/v3.1.0/deploy/install-driver.sh | bash -s v3.1.0 --
Installing NFS CSI driver, version: v3.1.0 ...
serviceaccount/csi-nfs-controller-sa unchanged
clusterrole.rbac.authorization.k8s.io/nfs-external-provisioner-role unchanged
clusterrolebinding.rbac.authorization.k8s.io/nfs-csi-provisioner-binding unchanged
csidriver.storage.k8s.io/nfs.csi.k8s.io unchanged
deployment.apps/csi-nfs-controller unchanged
daemonset.apps/csi-nfs-node unchanged
NFS CSI driver installed successfully.
#3、创建storageclass，配置CSI Driver引用前面部署的nfs server为存储后端；
[root@master1 chapter5]#vim storageclass-nfs.yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-csi
provisioner: nfs.csi.k8s.io
parameters:
#server: nfs-server.default.svc.cluster.local
server: 10.102.58.246 #此处写nfs的svc的地址
share: /
#reclaimPolicy: Delete
reclaimPolicy: Retain
volumeBindingMode: Immediate
mountOptions:
- hard
- nfsvers=4.1
[root@master1 chapter5]#kubectl apply -f storageclass-nfs.yaml
#4、测试，创建storageclass内部，创建一个PVC，验证PVC的动态置备功能；
[root@master1 chapter5]#vim dynamic-pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-nfs-dynamic
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
storageClassName: nfs-csi
[root@master1 chapter5]#kubectl apply -f dynamic-pvc.yaml
[root@master1 chapter5]#kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-dynamic Bound pvc-2770fcc1-c9a4-4b67-ba9d-c9ca66ba7f9e 10Gi RWX nfs-csi 106m
基于csi-driver-nfs动态置备pvc卷
[root@master1 test]#vim pvc_dt/01-mysql_pvc.yaml
---
apiVersion: v1 #资源版本
kind: PersistentVolumeClaim #资源类型
metadata: #元数据
name: pvc-mysql-nfs #资源名
spec: #终态定义
accessModes: #访问模式
- ReadWriteMany #多路读写
resources: #资源
requests: #最小使用10G
storage: 10Gi
storageClassName: nfs-csi #存储类名
[root@master1 test]#vim pvc_dt/02-wordpress_pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-wordpress-nfs
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
storageClassName: nfs-csi
引用pvc卷
#MySQL引用
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: mysql
name: mysql
spec:
replicas: 1
selector:
matchLabels:
app: mysql
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: mysql
spec:
containers:
- image: mysql:8.0
name: mysql
volumeMounts:
- name: mysql-data #引用定义好的存储
mountPath: /var/lib/mysql #挂载目录
env:
- name: MYSQL_RANDOM_ROOT_PASSWORD
value: "1"
- name: MYSQL_DATABASE
value: "wordpress"
- name: MYSQL_USER
value: "wordpress"
- name: MYSQL_PASSWORD
value: "123456"
resources: #资源限制
requests: #资源需求为
memory: "128Mi" #128M内存
cpu: "200m" #占用一个核心cpu的百分之20
limits: #资源限制
memory: "512Mi" #最大使用内存为
cpu: "400m" #最大使用cpu为
livenessProbe: #存活探针
exec: #执行的命令
command: [ 'mysqladmin', '-uwordpress', '-p123456' ,'ping' ]
initialDelaySeconds: 5 #延迟探针时间
timeoutSeconds: 15 #超时时间
periodSeconds: 5 #周期性间隔时间
readinessProbe:
exec:
command: [ 'mysql','-uwordpress','-p123456' ]
initialDelaySeconds: 5 #延迟探针时间
timeoutSeconds: 15 #超时时间
periodSeconds: 5 #周期时间
volumes: #定义储存卷
- name: mysql-data #定义储存卷的名字
persistentVolumeClaim: #使用pvc
claimName: pvc-mysql-nfs #pvc的名字
#wordpress引用
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: wordpress
name: wordpress
spec:
replicas: 1
selector:
matchLabels:
app: wordpress
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: wordpress
spec:
containers:
- image: wordpress:5.7
name: wordpress
ports: #定义posts端口
- name: http #名字为http
containerPort: 80
volumeMounts:
- name: wordpress-data
mountPath: /var/www/html
env:
- name: WORDPRESS_DB_HOST
value: "mysql"
- name: WORDPRESS_DB_NAME
value: "wordpress"
- name: WORDPRESS_DB_USER
value: "wordpress"
- name: WORDPRESS_DB_PASSWORD
value: "123456"
resources: #资源限制
requests: #资源需求为
memory: "128Mi" #128M内存
cpu: "200m" #占用一个核心cpu的百分之20
limits: #资源限制
memory: "512Mi" #最大使用内存为
cpu: "400m" #最大使用cpu为
readinessProbe: #活体探针——就绪探针
httpGet:
path: /wp-admin/install.php
port: 80
scheme: HTTP
initialDelaySeconds: 3 #探测延时时间
timeoutSeconds: 10 #超时时间
periodSeconds: 5 #周期时间
failureThreshold: 3 #失败阈值
livenessProbe: #存活探针
tcpSocket: #使用TCP套接字连接探测
port: http #使用http
periodSeconds: 5 #周期为5s
initialDelaySeconds: 5 #启动延迟探测时间为5s
volumes:
- name: wordpress-data
persistentVolumeClaim: #使用pvc
claimName: pvc-wordpress-nfs
测试：
[root@master1 test]#kubectl apply -f mysql/ -f pvc_dt/ -f wordpress/ #跑起来
[root@master1 test]#kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-767549ffb-hh27f 1/1 Running 0 11m
pod-pvc-demo 1/1 Running 0 123m
wordpress-67f9f776bb-5ndlg 1/1 Running 0 11m
[root@master1 test]#kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-demo-wordpress Bound pv-nfs-demo-wordpress 2Gi RWO,ROX,RWX 57m
pvc-wordpress-nfs Bound pvc-29d61fc0-9175-4cf9-a4a2-8a04576e5c31 10Gi RWX nfs-csi 11m
特殊卷configmaps及secret
ConfigMap和Secret基础
ConfigMap和Secret资源
ConfigMap和Secret是Kubernetes系统上两种特殊类型的存储卷
◼ ConfigMap用于为容器中的应用提供配置数据以定制程序的行为，而敏感的配置信息，例如密钥、证书等则通常由Secret来配置
◼ ConfigMap和Secret将相应的配置信息保存于资源对象中，而后在Pod对象上支持以存储卷的形式将其挂载并加载相关的配置，从而降低了配置与镜像文件的耦合关系，提高了镜像复用能力
◼ Kubernetes借助于ConfigMap对象实现了将配置文件从容器镜像中解耦，从而增强了工作负载的可移植性，使其配置更易于更改和管理，并避免了将配置数据硬编码到Pod配置清单中
此二者都属于名称空间级别，只能被同一名称空间中的Pod引用
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Rw6d4j3j-1670485801742)(kubernetes的基础概念和安装.assets/image-20221208151927240.png)]
ConfigMap和Secret资源都是数据承载类的组件，是Kubernetes API的标准资源类型，是一等公民
◼ 主要负责提供key-value格式的数据项，其值支持
◆ 单行字符串：常用于保存环境变量值，或者命令行参数等
◆ 多行字串：常用于保存配置文件的内容
例如：
apiVersion: v1
kind: ConfigMap
metadata:
name: myapp-confs
data:
PORT: "8080"
myserver-status.cfg: |
location /nginx-status {
stub_status on;
access_log off;
}
◼ 资源规范中不使用spec字段，而是直接使用特定的字段嵌套定义key-value数据
◆ ConfigMap支持使用data或binaryData字段嵌套一至多个键值数据项
◆ Secret支持使用data或stringData（非base64编码的明文格式）字段嵌套一至多个键值数据项
◼ 从Kubernetes v1.19版本开始，ConfigMap和Secret支持使用immutable字段创建不可变实例
ConfigMap资源
创建ConfigMap对象
创建ConfigMap对象的方法有两种
◼ 命令式命令
◆ 字面量：kubectl create configmap NAME --from-literal=key1=value1
◆ 从文件加载：kubectl create configmap NAME --from-file=[key=]/PATH/TO/FILE
◆ 从目录加载： kubectl create configmap NAME --from-file=[key=]/PATH/TO/DIR/
◼ 配置文件
◆ 命令式：kubectl create -f
◆ 声明式：kubectl apply -f
提示：基于文件内容生成时，可以使用命令式命令以dry-run模式生成并保存
示例：
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
资源创建示例：
[root@master1 ~]# kubectl create configmap nginx-confs --from-file=./nginx-conf.d/myserver.conf --from-file=status.cfg=./nginx-conf.d/myserver-status.cfg
配置文件实例：
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-confs
namespace: default
data:
status.cfg: | # “|”是键名及多行键值的分割符，多行键值要进行固定缩进
location /nginx-status { # 该缩进范围内的文本块即为多行键值
stub_status on;
access_log off;
}
myserver.conf: |
server {
listen 8080;
server_name www.ik8s.io;
include /etc/nginx/conf.d/myserver-*.cfg;
location / {
root /usr/share/nginx/html;
}
}
引用ConfigMap对象
ConfigMap资源对象中以key-value保存的数据，在Pod中引用的方式通常有两种
◼ 环境变量
◆ 引用ConfigMap对象上特定的key，以valueFrom赋值给Pod上指定的环境变量
◆ 在Pod上使用envFrom一次性导入ConfigMap对象上的所有key-value，key（也可以统一附加特定前缀）即为环境变量名，value自动成为相应的变量值
◼ configMap卷
◆ 在Pod上将ConfigMap对象引用为存储卷，而后整体由容器mount至某个目录下
⚫ key转为文件名，value即为相应的文件内容
◆ 在Pod上定义configMap卷时，仅引用其中的部分key，而后由容器mount至目录下
◆ 在容器上仅mount configMap卷上指定的key
实验：使用configmaps定义环境变量并且引用
使用configmaps特殊卷的环境变量定义配置文件的参数
[root@master1 chapter6]#vim configmaps-env-demo.yaml
---
apiVersion: v1 #资源版本号码
kind: ConfigMap #资源类型
metadata: #元数据
name: demoapp-config #资源名称
namespace: default #名称空间
data: #定义数据
demoapp.port: "8080" #定义环境变量
demoapp.host: 127.0.0.1 #定义环境变量
---
apiVersion: v1 #指定资源版本
kind: Pod #指定资源类型
metadata: #元数据
name: configmaps-env-demo #资源名称
namespace: default #名称空间
spec: #定义终态
containers: #对象列表
- image: ikubernetes/demoapp:v1.0 #镜像
name: demoapp #容器名
env: #定义环境标量
- name: PORT #定义port的变量
valueFrom: #使用configmaps卷定义
configMapKeyRef: #使用configmaps的key定义
name: demoapp-config #指定configmaps卷为demoapp-config
key: demoapp.port #指定demoapp-config卷中的demoapp.port键中的值来赋值
optional: false #指定是必选的还得可选的(必选的如果指定的键没有值则pod无法正常启动，反之则可以启动)false为指定的键名为必选
- name: HOST
valueFrom:
configMapKeyRef:
name: demoapp-config
key: demoapp.host
optional: true #指定是必选的还得可选的(必选的如果指定的键没有值则pod无法正常启动，反之则可以启动)true为指定的键名为可选
基于cm存储卷
#创建nginx的server模块
[root@master1 nginx-conf.d]#cat myserver.conf
server {
listen 8080;
server_name www.ik8s.io;
include /etc/nginx/conf.d/myserver-*.cfg;
location / {
root /usr/share/nginx/html;
}
}
#创建nginx的压缩配置文件
[root@master1 nginx-conf.d]#cat myserver-gzip.cfg
gzip on;
gzip_comp_level 5;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css application/xml text/javascript;
#创建nginx的状态页模块
[root@master1 nginx-conf.d]#cat myserver-status.cfg
location /nginx-status {
stub_status on;
access_log off;
}
基于创建好的配置文件创建configmaps
[root@master1 nginx-conf.d]# kubectl create configmap nginx-config --from-file=nginx-conf.d/
[root@master1 chapter6]#kubectl get cm
NAME DATA AGE
nginx-config 3 11s
创建pod引用特殊卷
[root@master1 chapter6]#vim configmaps-volume-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: configmaps-volume-demo
namespace: default
spec:
containers:
- image: nginx:alpine
name: nginx-server
volumeMounts:
- name: ngxconfs
mountPath: /etc/nginx/conf.d/ #将cm定义好的配置文件挂载到指定的目录中
readOnly: true #可选项——就是没有就不挂了
volumes:
- name: ngxconfs #定义cm卷
configMap:
name: nginx-config #引用的cm卷的名字(和刚刚创建好的cm卷的名字呼应上)
optional: false #必选项
测试：
[root@master1 chapter6]#kubectl get pods
NAME READY STATUS RESTARTS AGE
configmaps-volume-demo 1/1 Running 0 39m
[root@master1 chapter6]#kubectl exec configmaps-volume-demo -- ls -al /etc/nginx/conf.d/ #查看挂载到的目录中是否以生成
total 12
drwxrwxrwx 3 root root 4096 Dec 7 14:45 .
drwxr-xr-x 3 root root 4096 Oct 19 18:20 ..
drwxr-xr-x 2 root root 4096 Dec 7 14:45 ..2022_12_07_14_45_56.2933036079
lrwxrwxrwx 1 root root 32 Dec 7 14:45 ..data -> ..2022_12_07_14_45_56.2933036079
lrwxrwxrwx 1 root root 24 Dec 7 14:13 myserver-gzip.cfg -> ..data/myserver-gzip.cfg
lrwxrwxrwx 1 root root 26 Dec 7 14:13 myserver-status.cfg -> ..data/myserver-status.cfg
lrwxrwxrwx 1 root root 20 Dec 7 14:13 myserver.conf -> ..data/myserver.conf
Secret资源
Secret主要用于存储密钥、OAuth令牌和 SSH 密钥等敏感信息，这些敏感信息采用base64编码保存，略好于明文存储
Secret根据其用途等，还有类型上的区分
创建Secret资源
支持类似于ConfigMap的创建方式，但Secret有类型子命令，而且不同类型在data或stringData字段中支持嵌套使用的key亦会有所有同；
命令式命令
◼ generic
◆ kubectl create secret generic NAME [–type=string] [–from-file=[key=]source] [–from-literal=key1=value1]
◆ 除了后面docker-registry和tls命令之外的其它类型，都可以使用该命令中的–type选项进行定义，但有些类型有key特
定要求
◼ tls
◆ kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file
◆ 通常，其保存cert文件内容的key为tls.crt，而保存private key的key为tls.key
◼ docker-registry
◆ kubectl create secret docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [–docker-server=string] [–from-file=[key=]source]
◆ 通常，从已有的json格式的文件加载生成的就是dockerconfigjson类型，命令行直接量生成的也是该类型
示例一：创建secret
命令式命令
kubectl create secret generic mysql-root-authn --from-literal=username=root --from literal=password=MagEdu.c0m
配置文件
apiVersion: v1
data:
password: TWFnRWR1LmMwbQ==
username: cm9vdA==
kind: Secret
metadata:
name: mysql-root-authn
namespace: default
type: Opaque
示例二：创建secret
[root@master1 chapter6]#kubectl create secret generic mysql-secret --from-literal=root.pass=wwj --from-literal=db-name=wpdb --from-literal=db.user=wpuser --from-literal=db.pass=123456 #创建secret类型为generic定义一个键名为root.pass值为wwj 定义一个键名为db-name值为wpdb 定义一个键名为db.user值为wpuser 定义一个键名为db.pass值为123456
引用secret资源
Secret资源在Pod中引用的方式同样有两种
⚫ 环境变量
◆ 引用Secret对象上特定的key，以valueFrom赋值给Pod上指定的环境变量
◆ 在Pod上使用envFrom一次性导入Secret对象上的所有key-value，key（也可以统一附加特定前缀）即为环境变量名，value自动成为相应的变量值
⚫ secret卷
◆ 在Pod上将Secret对象引用为存储卷，而后整体由容器mount至某个目录下
key转为文件名，value即为相应的文件内容
◆ 在Pod上定义Secret卷时，仅引用其中的部分key，而后由容器mount至目录下
◆ 在容器上仅mount Secret卷上指定的key
注意：容器很可能会将环境变量打印到日志中，因而不建议以环境变量方式引用Secret中的数据
引用实例：
apiVersion: v1
kind: Pod
metadata:
name: secrets-volume-demo
spec:
containers: #定义资源对象
- image: nginx:alpine #引用镜像
name: ngxserver #容器名字
volumeMounts: #定义挂载信息
- name: nginxcerts #指定挂载谁
mountPath: /etc/nginx/certs/ #挂载到哪里
readOnly: true #此项为可选，挂载失败pod也会正常运行
- name: nginxconfs
mountPath: /etc/nginx/conf.d/
readOnly: true
volumes: #定义挂载
- name: nginxcerts #定义此资源名字
secret: #使用secret卷
secretName: nginx-ssl-secret #使用secret的这个卷nginx-ssl-secret
- name: nginxconfs
configMap:
name: nginx-sslvhosts-confs
optional: false
实验：基于secret引用的方式，为多个环境变量提供值；
创建出来secret的环境变量的定义
[root@master1 chapter6]# kubectl create secret generic mysql-secret --from-literal=MYSQL_RANDOM_ROOT_PASSWORD=1 --from-literal=MYSQL_DATABASE=wordpress --from-literal=MYSQL_USER=wordpress --from-literal=MYSQL_PASSWORD=123456 --dry-run=client -oyaml > mysql-secret.yaml
引用secret的环境变量定义
[root@master1 test]#vim mysql/02-mysql.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: mysql
name: mysql
spec:
replicas: 1
selector:
matchLabels:
app: mysql
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: mysql
spec:
containers:
- image: mysql:8.0
name: mysql
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
env:
- name: MYSQL_RANDOM_ROOT_PASSWORD #要定义的环境变量
valueFrom:
secretKeyRef: #从secret卷中获取
name: mysql-secret #获取secret的mysql-secret中的数据
key: MYSQL_RANDOM_ROOT_PASSWORD #从mysql-secret里读取MYSQL_RANDOM_ROOT_PASSWORD键的值赋值到pod中的MYSQL_RANDOM_ROOT_PASSWORD上
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_DATABASE
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_PASSWORD
resources: #资源限制
requests: #资源需求为
memory: "128Mi" #128M内存
cpu: "200m" #占用一个核心cpu的百分之20
limits: #资源限制
memory: "512Mi" #最大使用内存为
cpu: "400m" #最大使用cpu为
livenessProbe: #存活探针
exec: #执行的命令
command: [ 'mysqladmin', '-uwordpress', '-p123456' ,'ping' ]
initialDelaySeconds: 5 #延迟探针时间
timeoutSeconds: 15 #超时时间
periodSeconds: 5 #周期性间隔时间
readinessProbe:
exec:
command: [ 'mysql','-uwordpress','-p123456' ]
initialDelaySeconds: 5 #延迟探针时间
timeoutSeconds: 15 #超时时间
periodSeconds: 5 #周期时间
volumes: #定义储存卷
- name: mysql-data #定义储存卷的名字
persistentVolumeClaim: #使用pvc
claimName: pvc-mysql-nfs #pvc的名字
wordpress赋值
[root@master1 test]#vim wordpress/02-wordpress.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: wordpress
name: wordpress
spec:
replicas: 1
selector:
matchLabels:
app: wordpress
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: wordpress
spec:
containers:
- image: wordpress:5.7
name: wordpress
ports: #定义posts端口
- name: http #名字为http
containerPort: 80
volumeMounts:
- name: wordpress-data
mountPath: /var/www/html
env:
- name: WORDPRESS_DB_HOST
value: "mysql"
- name: WORDPRESS_DB_NAME #赋值pod中的WORDPRESS_DB_NAME变量
valueFrom: #从卷中读取数据
secretKeyRef: #使用secret卷
name: mysql-secret #读取mysql-secret这个secret卷中的值
key: MYSQL_DATABASE #将mysql-secret卷中的MYSQL_DATABASE的值复制到pod上的WORDPRESS_DB_NAME上
- name: WORDPRESS_DB_USER
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_USER
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_PASSWORD
resources: #资源限制
requests: #资源需求为
memory: "128Mi" #128M内存
cpu: "200m" #占用一个核心cpu的百分之20
limits: #资源限制
memory: "512Mi" #最大使用内存为
cpu: "400m" #最大使用cpu为
readinessProbe: #活体探针——就绪探针
httpGet:
path: /wp-admin/install.php
port: 80
scheme: HTTP
initialDelaySeconds: 3 #探测延时时间
timeoutSeconds: 10 #超时时间
periodSeconds: 5 #周期时间
failureThreshold: 3 #失败阈值
livenessProbe: #存活探针
tcpSocket: #使用TCP套接字连接探测
port: http #使用http
periodSeconds: 5 #周期为5s
initialDelaySeconds: 5 #启动延迟探测时间为5s
volumes:
- name: wordpress-data
persistentVolumeClaim: #使用pvc
claimName: pvc-wordpress-nfs
基于configmaps卷和secret卷完成nginx的https
创建配置文件
#创建https的跳转模块的配置文件
[root@master1 configuration_file]#cat myserver.conf
server {
listen 443 ssl;
server_name www.ik8s.io;
ssl_certificate /etc/nginx/certs/tls.crt;
ssl_certificate_key /etc/nginx/certs/tls.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
ssl_prefer_server_ciphers on;
include /etc/nginx/conf.d/myserver-*.cfg;
location / {
root /usr/share/nginx/html;
}
}
server {
listen 80;
server_name www.ilinux.io;
return 301 https://$host$request_uri;
}
#创建nginx的压缩模块配置文件
[root@master1 configuration_file]#cat myserver-gzip.cfg
gzip on;
gzip_comp_level 5;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css application/xml text/javascript;
#创建状态也模块的配置信息
[root@master1 configuration_file]#cat myserver-status.cfg
location /nginx-status {
stub_status on;
access_log off;
}
基于以上的配置文件创建出configmaps卷
[root@master1 nginx-ssh]#kubectl create configmap nginx-conf--from-file=configuration_file/
configmap/nginx-pzwj created
基于指定证书文件创建出secret卷
[root@master1 nginx-ssh]#ls secret/
nginx.crt nginx.key
[root@master1 nginx-ssh]#kubectl create secret tls nginx-ssh-my --cert=./secret/nginx.crt --key=./secret/nginx.key
创建出nginx的pod并引用
[root@master1 nginx-ssh]#vim pod-nginx/nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
run: pod-nginx
name: pod-nginx-ssh.com
spec:
containers:
- image: nginx:alpine
name: pod-nginx
volumeMounts:
- name: ssh-mywj #挂载secret卷
mountPath: /etc/nginx/certs/
readOnly: true
- name: configma-pzwj #挂载configmaps卷
mountPath: /etc/nginx/conf.d
readOnly: true
volumes: #定义卷
- name: configma-pzwj #定义名字
configMap: #使用configmaps卷
name: nginx-conf #configmaps卷的名字(要和刚刚定义好的一样）
optional: false #必选
- name: ssh-mywj #定义名字
secret: #使用secret卷
secretName: nginx-ssh-my #指定secret卷的名字
测试：
[root@master1 nginx-ssh]#kubectl get pods #查看pod
NAME READY STATUS RESTARTS AGE
pod-nginx-ssh.com 1/1 Running 0 38m
[root@master1 nginx-ssh]#curl -ILk 10.244.3.36 #测试访问以跳转
HTTP/1.1 301 Moved Permanently
Server: nginx/1.23.2
Date: Wed, 07 Dec 2022 18:27:06 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://10.244.3.36/
HTTP/1.1 200 OK
Server: nginx/1.23.2
Date: Wed, 07 Dec 2022 18:27:06 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Wed, 19 Oct 2022 10:28:53 GMT
Connection: keep-alive
ETag: "634fd165-267"
Accept-Ranges: bytes
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
