不飞则已，一飞冲天；不鸣则已，一鸣惊人。这篇文章主要讲述解读kubernetes集群常用资源yaml文件相关的知识，希望能为你提供帮助。
一、解读kubernetes集群常用资源yaml文件
1、POD资源类型案例
vi nginx-pod.yaml
apiVersion: v1
# 指定api版本，此值必须在kubectl apiversion中
kind: Pod
# 指定创建资源的角色/类型
metadata:
# 资源的元数据/属性
name: nginx-pod
# 资源的名称，在同一个namespace中必须唯一
namespace: learn
# 部署在哪个namespace中
labels:
# 设定资源的标签
env: nginx-test
spec:
# 指定该资源的内容
restartPolicy: Always
# 表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器
containers:
- env:
# 指定容器中的环境变量
- name: mysql_username
# 变量的名称
value: learn
# 变量的值
- name: mysql_passwd
# 变量的名称
value: learn1234#
# 变量的值
name: nginx-pod
# 容器的名称
image: nginx:1.19.6
# 容器使用的镜像地址
nodeSelector:
# 节点选择，先给主机打标签kubectl label nodes 192.168.1.13 onling=node1
onling=node1
imagePullPolicy: Always
# 三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略
# Always，每次都检查，如果本地有镜像，总是从指定的仓库中获取镜像
# Never，每次都不检查（不管本地是否有），禁止从仓库中下载镜像，也就是说只能使用本地镜像；
# IfNotPresent，如果本地有就不检查，如果没有就拉取目标仓库中镜像；
# 默认的镜像下载策略是：当镜像标签是latest时，默认策略是Always；当镜像标签是自定义时（也就是标签不是latest），那么默认策略是IfNotPresent
resources:
# 资源管理
requests:
# 容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行
cpu: 0.1
# CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
memory: 32Mi
# 内存使用量
limits:
# 资源限制
cpu: 0.5
# CPU资源
memory: 300Mi
# 内存使用量
ports:
- containerPort: 80
# 容器开发对外的端口
name: httpd
# 名称
protocol: TCP
# 协议
2、资源控制器，又称副本控制器
●
资源的类型/角色
（1）ReplicationController 和 ReplicaSet
● 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；
● 而如果异常多出来的容器也会自动回收；
● ReplicaSet 支持集合式的selector；
（2）Deployment
● 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法；
● 滚动升级和回滚应用；
● 扩容和缩容；
● 暂停和继续 Deployment；
（3）DaemonSet
● 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod；
应用场景：
● 运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph；
● 在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash；
● 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、 New Relic 代理，或 Ganglia gmond；
（4）StateFulSet
● 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序；
为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：
● 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现；
● 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有 Cluster IP的Service）来实现；
● 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到 N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现；
● 有序收缩，有序删除（即从N-1到0）
（5）Job/CronJob
● 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束
（6）Horizontal Pod Autoscaling
● Pod水平自动缩放。应用的资源使用率通常都有高峰和低谷，为提高集群的整体资源利用率，使用Horizontal Pod Autoscaling削峰填谷
●
Deployment资源类型案例
vi nginx-demo-deploy.yaml
apiVersion: apps/v1
# 指定api版本，此值必须在kubectl apiversion中
kind: Deployment
# 指定创建资源的角色/类型，deployment为控制器
metadata:
# 资源的元数据/属性
name: nginx-demo
# 资源的名称，在同一个namespace中必须唯一
namespace: learn
# 部署在哪个namespace中
labels:
# 设定资源的标签
app: nginx-demo
spec:
# 指定该资源的内容
replicas: 3
# 声明副本数
revisionHistoryLimit: 3
# 保留历史版本
selector:
# 选择器
matchLabels:
# 匹配标签名
app: nginx-demo
strategy:
# 策略
rollingUpdate:
# 滚动更新
maxSurge: 30%
# 最大额外可以存在的副本数，可以为百分比，也可以为整数
maxUnavailable: 30%
# 表示在更新过程中能够进入不可用状态的 Pod 的最大值，可以为百分比，也可以为整数
type: RollingUpdate
# 滚动更新策略
template:
# 模板
metadata:
# 资源的元数据/属性
labels:
# 设定资源的标签
app: nginx-demo
spec:
# 指定该资源的内容
containers:
# 定义容器信息
- name: nginx-demo
# 容器名，与标签名要相同
image: nginx:1.19.6
# 容器使用的镜像和版本
imagePullPolicy: Always
# 三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略
resources:
# 资源管理
requests:
# 容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行
cpu: 0.1
# CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
memory: 32Mi
# 内存使用量
limits:
# 资源限制
cpu: 0.5
# CPU资源
memory: 300Mi
# 内存使用量
volumeMounts:
# 挂载资源，指向容器里目录
- mountPath: /app/conf/
# 挂载到容器里的目录
name: app-conf
# 挂载卷名称
- mountPath: /app/config
# 挂载到容器里的目录
name: dingding_config
# 挂载卷名称
ports:
- containerPort: 80
# 容器开发对外的端口
name: httpd
# 名称
protocol: TCP
# 协议
restartPolicy: Always
# Always：当容器失效时，由kubelet自动重启该容器。默认Always
# OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。
# Never：不论容器运行状态如何，kubelet都不会重启该容器。
# RC和DaemonSet：必须设置为Always，需要保证该容器持续运行。
# Job和CronJob：OnFailure或Never，确保容器执行完成后不再重启。
# kubelet：在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查。
schedulerName: default-scheduler
securityContext: {}
volumes:
# 挂载资源
- configMap:
# 挂载configMap类型资源
defaultMode: 420
# 文件权限
name: go-dingding-cm
# configMap名称，需提前创建名称为go-dingding-cm的configMap资源
name: app-conf
# 挂载卷名称
- hostPath:
path: /data/go-dingding/config
# 宿主机目录
type: ""
name: dingding_config
# 挂载卷名称
3、Service资源类型案例
vi nginx-demo-service.yaml
apiVersion: v1
# 指定api版本，此值必须在kubectl api-versions中
kind: Service
# 指定创建资源的角色/类型
metadata:
# 资源的元数据/属性
name: nginx-demo
# 资源的名称，在同一个namespace中必须唯一
namespace: learn
# 部署在哪个namespace中
labels:
# 设定资源的标签
app: nginx-demo
spec:
# 指定该资源的内容
type: NodePort
# ClusterIP、NodePort、LoadBalancer、ExternalName类型
ports:
- port: 8089
# service 端口
targetPort: 80
# 容器暴露的端口
protocol: TCP
# 协议
name: http
# 端口名称
selector:
# 选择器
app: nginx-demo
4、EndPoint资源类型案例
vi nginx-demo-ep.yaml
apiVersion: v1
# 指定api版本，此值必须在kubectl api-versions中
kind: EndPoints
# 指定创建资源的角色/类型
labels:
# 设定资源的标签
name: nginx-demo
version: 1.0.0
name: nginx-demo
# 资源的名称，在同一个namespace中必须唯一
namespace: learn
# 部署到namespace中
5、ConfigMap资源类型案例
vi go-dingding-cm.yaml
apiVersion: v1
# 指定api版本，此值必须在kubectl api-versions中
data:
app.conf: |
# beego config
appname
=
go-dingding
httpport
=
8091
runmode
= prod
copyrequestbody = true
EnableDocs = true
sessionon = true
# debug | info | warn | error | fatal | panic
log_level = debug
DingtalkURL="https://oapi.dingtalk.com/robot/send?access_token=xxxxxx"
# 钉钉机器人地址，根据实际需要更改
kind: ConfigMap
# 指定创建资源的角色/类型
metadata:
# 资源的元数据/属性
name: go-dingding-cm
# 资源的名称，在同一个namespace中必须唯一
namespace: learn
# 部署到namespace中
6、PersistentVolume资源类型案例
vi nas-learn-pv.yaml
apiVersion: v1
# 指定api版本，此值必须在kubectl api-versions中
kind: PersistentVolume
# 指定创建资源的角色/类型
metadata:
# 资源的元数据/属性
finalizers:
- kubernetes.io/pv-protection
labels:
# 设定资源的标签
name: nfs-learn
name: nas-learn
# 资源的名称，在同一个集群中必须唯一，PV不分namespace
spec:
# 指定该资源的内容
accessModes:
# 权限
- ReadWriteMany
# 可以以读写的方式被多个node挂载；
# ReadWriteOnce：可读可写，但支持被单个node挂载，HostPath只支持ReadWriteOnce；
# ReadOnlyMany：可以以读的方式被多个node挂载；
capacity:
# 定义资源容量
storage: 1Pi
# 定义资源容量值
mountOptions:
# 挂载设置
- vers=4.0
# 版本
- noresvport
# 设置连接服务器是否使用保密源端口。默认的resvport设置保密端口，带noresvport参数设置为非保密端口。内核2.6.28及以后版本支持
nfs:
# 挂载资源文件系统类型
path: /learn
# 挂载路径
server: xxxxxx.cn-hangzhou.nas.aliyuncs.com
# 阿里云nas地址
persistentVolumeReclaimPolicy: Retain
# 回收策略：不清理保留数据。即删除pvc或者pv后，在插件上的数据（nfs服务端）不会被删除。这种方式是最常用的，可以避免误删pvc或者pv而造成数据的丢失。
# Recycle：不保留数据。经测试pvc删除后，在nfs服务端的数据也会随机删除。只有hostPath和NFS支持这种方式
# Delete：删除存储资源，AWS EBS, GCE PD, Azure Disk, and Cinder volumes支持这种方式。
7、PersistentVolumeClaim资源类型案例
vi nasclaim-learn-pvc.yaml
apiVersion: v1
# 指定api版本，此值必须在kubectl api-versions中
kind: PersistentVolumeClaim
# 指定创建资源的角色/类型
metadata:
# 资源的元数据/属性
finalizers:
- kubernetes.io/pvc-protection
name: nasclaim-nas-learn
# 资源的名称，在同一个namespace中必须唯一
namespace: learn
# 部署到namespace中
spec:
# 指定该资源的内容
accessModes:
# 权限
- ReadWriteMany
# 可以以读写的方式被多个node挂载；
# ReadWriteOnce：可读可写，但支持被单个node挂载，HostPath只支持ReadWriteOnce；
# ReadOnlyMany：可以以读的方式被多个node挂载；
dataSource: null
resources:
# 资源
requests:
# 请求资源
storage: 1Pi
# 请求资源大小
selector:
# 标签选择器
matchLabels:
# 匹配标签名
name: nfs-learn
volumeName: nas-learn
# 卷名
status:
# 状态
accessModes:
# 权限
- ReadWriteMany
# 可以以读写的方式被多个node挂载；
capacity:
storage: 1Pi
# 绑定资源大小
phase: Bound
# 绑定结果Bound为绑定成功
【解读kubernetes集群常用资源yaml文件】
推荐阅读
- #yyds干货盘点#设计模式之策略模式
- #yyds干货盘点#使用U_BOOT_CMD()自定义uboot命令
- 进程查看和进程管理
- 进程与计划任务管理
- #yyds干货盘点# web安全day9（5个实验实实在在学习windows域部署）
- 进程与管理
- JavaScript 定时器
- 老王读Spring IoC-2Spring IoC之BeanDefinition扫描注册的原理
- 多云搭建 K3S 集群