解读kubernetes集群常用资源yaml文件

Posted 2021-11-21 mb6020154eb4caa

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了解读kubernetes集群常用资源yaml文件相关的知识，希望对你有一定的参考价值。

一、解读kubernetes集群常用资源yaml文件

1、POD资源类型案例

vi nginx-pod.yaml

apiVersion: v1 # 指定api版本，此值必须在kubectl apiversion中

kind: Pod # 指定创建资源的角色/类型

metadata: # 资源的元数据/属性

namespace: learn # 部署在哪个namespace中

labels: # 设定资源的标签

env: nginx-test

spec: # 指定该资源的内容

restartPolicy: Always # 表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器

containers:

- env: # 指定容器中的环境变量

- name: mysql_username # 变量的名称

value: learn # 变量的值

- name: mysql_passwd # 变量的名称

value: learn1234# # 变量的值

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 # 容器开发对外的端口

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: # 资源的元数据/属性

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 # 滚动更新策略

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/ # 挂载到容器里的目录

- mountPath: /app/config # 挂载到容器里的目录

ports:

- containerPort: 80 # 容器开发对外的端口

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 # 文件权限

- hostPath:

path: /data/go-dingding/config # 宿主机目录

type: ""

3、Service资源类型案例

vi nginx-demo-service.yaml

apiVersion: v1 # 指定api版本，此值必须在kubectl api-versions中

kind: Service # 指定创建资源的角色/类型

metadata: # 资源的元数据/属性

namespace: learn # 部署在哪个namespace中

labels: # 设定资源的标签

app: nginx-demo

spec: # 指定该资源的内容

type: NodePort # ClusterIP、NodePort、LoadBalancer、ExternalName类型

ports:

- port: 8089 # service 端口

targetPort: 80 # 容器暴露的端口

protocol: TCP # 协议

selector: # 选择器

app: nginx-demo

4、EndPoint资源类型案例

vi nginx-demo-ep.yaml

apiVersion: v1 # 指定api版本，此值必须在kubectl api-versions中

kind: EndPoints # 指定创建资源的角色/类型

labels: # 设定资源的标签

version: 1.0.0

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

log_level = debug

DingtalkURL="https://oapi.dingtalk.com/robot/send?access_token=xxxxxx" # 钉钉机器人地址，根据实际需要更改

kind: ConfigMap # 指定创建资源的角色/类型

metadata: # 资源的元数据/属性

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: # 设定资源的标签

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

namespace: learn # 部署到namespace中

spec: # 指定该资源的内容

accessModes: # 权限

- ReadWriteMany # 可以以读写的方式被多个node挂载；

# ReadWriteOnce：可读可写，但支持被单个node挂载，HostPath只支持ReadWriteOnce；

# ReadOnlyMany：可以以读的方式被多个node挂载；

dataSource: null

resources: # 资源

requests: # 请求资源

storage: 1Pi # 请求资源大小

selector: # 标签选择器

matchLabels: # 匹配标签名

volumeName: nas-learn # 卷名

status: # 状态

accessModes: # 权限

- ReadWriteMany # 可以以读写的方式被多个node挂载；

capacity:

storage: 1Pi # 绑定资源大小

phase: Bound # 绑定结果Bound为绑定成功

以上是关于解读kubernetes集群常用资源yaml文件的主要内容，如果未能解决你的问题，请参考以下文章

再战 k8s：kubernetes 集群 YAML 文件

Docker&Kubernetes ❀ Kubernetes集群YAML语法与不同等级属性资源配置清单参数查询方法

云原生之kubernetes实战k8s集群核心资源对象之Pod

Kubernetes:通过轻量化工具 kubespy 实时观察YAML资源变更