成都网站制作关键词推广排名,wordpress4 中文,免费网站的app,学校网站建设的技术方案Linux 常用资源对象清单配置速查手册-1 文章目录 1、Pod 容器集合2、Pod 的存储卷3、Pod 的容器探针4、ResourceQuota 全局资源配额管理5、PriorityClass 优先级类 管理多个资源对象清单文件常用方法#xff1a;
使用 sed 流式编辑器批量修改脚本键值进行资源清单的创建
使用 sed 流式编辑器批量修改脚本键值进行资源清单的创建有助于日常测试工作
for i in {1..5}
dosed s,web,$i, app.yaml | kubectl apply -f - # - 为标准输入占位符表示上一个命令的输出
done-f 指定应用多个资源对象清单创建有启动顺序kubectl apply -f 清单1 -f 清单2 -f 清单3-f 还可以应用文件夹内所有 yaml 清单: kubectl apply -f yaml/ # 无法保证 Pod 启动的顺序合并多个资源对象管理文件用于多个资源清单文件测试完毕后统一合并使用
cat app/* app.yaml # 先读取目录下所有文件后再重定向进行合并资源对象清单配置模板获取方式
常用模板使用创建命令获取 kubectl create service --dry-runclient -o yaml template.yaml官方文档获取https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/使用“解释”命令查询每一个子字段的解释与应用 kubectl explain Pod.spec.containers.ports.使用 AI 编写资源清单模板再修改。
1、Pod 容器集合 Pod 的主要特点 共享网络Pod 中的所有容器共享同一个网络命名空间这意味着它们能够访问相同的IP地址和端口范围并且能够相互通信。 共享存储Pod 中的容器能够访问相同的存储卷Volumes这使得它们可以共享数据和文件。 协同工作Pod 中的容器设计为协同工作它们可能是一个应用的不同组件例如一个容器处理用户请求而另一个容器处理数据存储。 生命周期管理Pods 拥有自己的生命周期它们可以被创建、启动、停止和删除。Kubernetes 会保证 Pod 按照声明的状态运行。 重启策略Pods 可以配置重启策略以确定在容器崩溃时是否需要重启。 易于部署通过定义Pod 的配置可以很容易地部署和管理容器化应用。 不可变性Pods 是短暂的它们不应该被修改。如果需要更新 Pod 应该创建一个新的 Pod 并通过更新控制器如Deployment替换旧的Pod。 扩展性虽然 Pods 可以包含多个容器但它们通常用于运行单个应用程序或服务。对于需要水平扩展的应用通常会使用多个 Pod 副本并通过 Kubernetes 的控制器如Deployment、StatefulSet或DaemonSet来管理。 健康检查 Kubernetes 可以对Pod执行健康检查以确保它们正常运行并在检测到问题时进行适当的响应。
---
kind: Pod # 资源对象类型
apiVersion: v1 # api 版本通过 kubectl api-resources 查看
metadata: # 元数据信息name: web # 资源对象命名namespace: work # 所属名称空间labels: # map go 语言的 map 无序键值对集合数据类型app: apache type: web
spec: activeDeadlineSeconds: 30
# Pod 最大生命周期,即使容器重启也不会重置从 kubelet 通过 API-server
# 收到 scheduler 调度时为 Pod 拉取容器镜像之前计时。到达时间 Pod 不会重启terminationGracePeriodSeconds: 0
# 宽限期Pod 停止前进行清理工作比如保存状态、完成本地事务、结束服务的预留时间。
# nodeName: node-0002 # Pod 调度方式 1 指定节点进行调度 nodeSelector: kubernetes.io/hostname: node-0001# map Pod 调度方式 2 标签选择运算符指定标签节点过滤进行调度restartPolicy: OnFailure
#
# initContainers: # 在主容器之前运行可进行依赖检查、资源准备、执行脚本hostname: myweb # 指定 Pod 的主机名hostAliases: # 写入 Pod 内容器的 hosts 文件映射Pod 设置 hostNetwork 后不生效- ip: 192.168.1.100 # IP 列表hostnames: # IP 映射的主机名列表- web- nginxcontainers: - name: nginx image: myos:nginx imagePullPolicy: IfNotPresent
# Always 只拉取镜像仓库镜像Nerver 只使用本地镜像IfNotPresent 优先拉取本地镜像无则拉取镜像仓库env: # 传入一个环境变量列表- name: TZvalue: Asia/Shanghai # 方式 1指定传入单个确定值# valueFrom:# configMapKeyRef: # 方式 2: 通过配置映射的方式引用单个键值# name: timezone # 可传入加密的键值对象使用 secretKeyRef# key: timezone# envFrom: # 方式 3: 使用 configMap 或 secret 方式引入一组环境变量# - configMapRef:# name: timezone command: [/bin/sh] args:- -c - | sleep 3 exit $((RANDOM%10)) lifecycle:postStart: # 事件处理器/生命周期钩子函数用于特定时刻执行代码exec: # 容器启动后执行以下指定命令command: [/bin/sh,-c,|,sleep 1]# preStop: # 容器停止前执行格式同上。用于执行容器结束前的清理工作。 resources: # 节点资源调配requests: # 需求的配额cpu: 300m # 300 毫核的CPU额定资源memory: 400Mi # 400 Mi 的内存额定资源limits: # 定义资源限额会同时进行配额默认配额大小等于限额cpu: 500mmemory: 600Mi hostPID: true # 开启特权容器共享宿主机进程命名空间hostNetwork: true # 必须开启系统进程特权共享宿主机网络命名空间
status: {} # 由 kubelet 定期将 Pod 运行状态写入 2、Pod 的存储卷 Pod 支持多种存储卷 (volumes)有临时卷、持久卷、投射卷通常需要创建此类资源对象最后在 volumes 中声明containers 内挂载使用一个存储卷可被多个容器挂载进行共享存储。持久卷可以在 Volume 内定义并挂载使用也可以作为资源对象 PV 被创建继而创建 PVC在 Volumes 中调用 PVC最后挂载使用。 临时卷有 emptyDirconfigMapsecret 等持久卷也有 hostPath、NFS、CephFS 等投射卷则是指将多种其他卷投射到 Pod 容器内的一个目录。 1) Pod 内定义 PV 并使用
---
spec:volumes: # 定义 Pod 的存储卷- name: logdatahostPath: # 该 PV 可以让 Pod 挂载所在节点的文件、目录不过存在许多安全风险且可用性取决于底层节点状态path: /var/weblog # Pod 所在节点文件、目录type: DirectoryOrCreate # 检查挂载路径的目录是否存在不存在则创建# FileOrCreate 同理但不会创建父目录- name: website nfs: # 定义一个 nfs 类型的 PV 卷用于共享前端页面server: 192.168.1.30 # 需提供 nfs 共享的服务器 IPpath: /var/website # 挂载源路径readOnly: true # 默认 false 强制该类型 存储设备 使用只读权限挂载 nfs 导出通用配置。containers:- name: nginx image: myos:nginx volumeMounts: # 使用容器预先定义的存储卷进行卷挂载- name: logdata # 定义的 PV 名mountPath: /usr/local/nginx/logs# 挂载到 Pod 内的路径subPath: nginx # 用于指定所引用的卷内的子路径而不是其根路径。即 /var/weblog/nginx- name: websitemountPath: /usr/local/nginx/htmlreadOnly: true # 挂载时定义 PV 存储设备时均可强制以只读方式 挂载、导出双重保障。 2) 创建 PV 与 PVC 持久卷声明 (申领、索要 PV) PV 持久化存储卷可以持久存储容器数据跟 Pod 生命周期不同不会随着 Pod 被删除而丢失。同时具有不同资源回收策略如 RetainDelete。PV 没有命名空间限制属于集群基础资源PVC 是用命名空间进行隔离的。 K8S 靠 PV 与 PVC 对众多存储资源进行抽象的集合PVC 允许用户按照需求声明存储资源而无需关心具体的底层 PV 的存储细节如存储容量是否足够可供单个还是多个 Pod 读写等直接通过 PVC 绑定合适的 PV 进行使用。 PV 与 PVC 的特点
PV 有自己的生命周期它的状态包括可用Available、绑定Bound、释放Released、回收Retained等状态。PVC 与 PV 之间是一种声明与提供的关系。PVC 声明了对存储资源的需求而 PV 则是提供这些资源的实际载体。PVC 可以指定所需的存储容量、访问模式等参数但通常不需要指定具体的 PV而是通过标签选择器来动态匹配 PV。当 PVC 被删除时绑定的 PV 不会被删除而是变成了 Available 状态可以被其他 PVC 绑定。当 PV 被删除时绑定的 PVC 也会被删除。
---
kind: PersistentVolume # PV 持久卷的标准资源对象名
apiVersion: v1
metadata:name: pv-nfslabels: # map PVC 通过标签来寻找预先分类的 PVpv: nfsspec:volumeMode: Filesystem # PV 卷的模式文件系统块设备 BlockaccessModes:- ReadWriteOnce- ReadWriteMany- ReadOnlyManycapacity: # map 定义该 PV 的资源和容量storage: 20Gi # 目前仅支持定义 容量未来可能包括 IOPS、吞吐量等属性persistentVolumeReclaimPolicy: Retain# 资源回收策略: Retain 不删除 PV 与 数据# Delete 删除 PV 与 数据目前 nfs 还保留了 Recycle 策略不删除 PV仅删除数据PV 留着给其他 PVC 绑定。mountOptions: # 支持对应存储设备的挂载选项- nolock # nfs 挂载参数不对文件进行 “写锁定”nfs: # 该 PV 提供者的存储设备类型为 nfsserver: 192.168.1.30 path: /var/website---
kind: PersistentVolumeClaim # 定义 PVC 存储卷声明 (申领索要)
apiVersion: v1
metadata:name: pvc-nfs
spec: # PVC 将自动寻找并绑定符合以下 spec 规约的 PVvolumeMode: Filesystem # 需要 文件系统类型的 PVselector: # 通用的标签选择器matchLabels: # map 匹配下列标签即满足条件PVC 可进行绑定。pv: nfs accessModes:- ReadWriteOnce # 只要定义了 RWO 访问模式的 PVresources: # 定义对 PV 的资源请求requests: # 定义请求内容目前只支持对 存储容量 的请求storage: 15Gi # 需要有 15 GiB 存储容量的 PV———————————————————————————————— # 在 Pod 中使用 PVC
---
spec:volumes: # 定义一个 PVC 持久卷声明卷- name: pvc-testpersistentVolumeClaim: # 引用 PVC 资源定义 PVC 对象claimName: pvc-nfs # 需要使用的 PVC 对象名称containers:‥‥‥‥‥‥ 3) StorageClass 动态制备 PV K8S有两种制作基础存储资源 PV 的方式如下 静态制备 PV管理员需要预先创建满足各种需求的 PV等待 PVC 申请使用 动态制备 PV管理员无须预先创建 PV而是通过 StorageClass 自动完成 PV 的创建以及与 PVC 的绑定。这在商业环境下需要数千 Pod 时至关重要手动制作需要动态变化的 PV 工作量巨大。 4) PV 卷的访问模式 每个 PV 持久卷的提供者能支持的访问模式都不同如 NFS 可支持多个节点进行读写而 hostPath 只支持单个节点进行读写PV 卷中的 accessModes 描述的是本身的访问能力可只定义当前 PV 所需的访问模式在 PVC 中可以声明需要使用何种访问模式的 PV进行绑定。 重要提醒 每个卷同一时刻只能以一种访问模式挂载即使该卷能够支持多种访问模式。 RWO: ReadWriteOnce 仅供一个节点 读、写。RWX: ReadWriteMany 可供多个节点 读、写。ROX : ReadOnlyMany 可供多个节点 读但不会对 PV 施加写保护只是标记此 PV 有此属性。RWOP: ReadWriteOncePod 仅供单个 Pod 读、写。 5) 临时卷 (Ephemeral Volume) ① emptyDir : 该临时卷最初是空的尽管 Pod 中其他容器挂载 emptyDir 卷的路径可能相同可能不同该卷默认选择宿主机上的介质进行存储可以是硬盘、SSD、或网络存储也可以在 medium 中选择 Memory 挂载到 tmpfs 内存文件系统但此时通常需要限制存储大小。 emptyDir 卷的一些用途
缓存空间例如基于磁盘的归并排序。为耗时较长的计算任务提供检查点以便任务能方便地从崩溃前状态恢复执行。在 Web 服务器容器服务数据时保存内容管理器容器获取的文件。 emptyDir 卷 YAML 示例
spec:volumes: # 定义 存储卷- name: cache-volumeemptyDir: # 定义 emptyDir 空目录存储卷medium: Memory # 挂载到 tmpfssizeLimit: 500Mi# empty: {} # 默认挂载到宿主机文件系统无法指定路径② configMap : 配置映射卷可以集合生产环境配置、测试环境配置、开发环境配置等不同需求的配置根据需求应用在不同命名空间的 Pod 内对于生产环境下的 Pod不能及时停服停机也可以用 configMap 实现配置热更新的目的。只有通过 Kubernetes API 创建的 Pod 才能使用 configMapkubelet 使用 manifest 创建的 static Pod 无法使用 configMap。 热更新配置对于正在运行的 Pod使用 configMap 挂载的 env 是在容器一创建好就注入其中k8s 不会再更新 Pod 内的环境变量且 pod 的环境变量是不断累加的只要 Pod 不重启。对于 configMap 挂载的 Volume 来说可以做到应用配置文件的动态更新然而有不支持热更新的容器应用可以使用滚动更新、或者蓝绿发布的方式。 注意 1 configMap 不能用来存储大量数据文件最好不要超过 1MB因为 etcd 保证支持不超过 1MB 数据的 RPC 请求。 注意 2 configMap 的 yaml 文件中键值行末存在空格会导致 data 中的 “ | ” 失效键值末尾的换行符不能被正确转换影响配置文件的应用。 可用 sed 删除多余的行末空格 sed -i s/[[:space:]]*$// 文件名.yaml configMap 可以使用命令创建导入配置文件、目录、或单个键值对也可以通过 sed s,^, , nginx.conf nginx-config.yaml 控制缩进并手动导入配置文件内容到 YAML 中。 命令方式: kubectl create configmap nginx-config.yaml --from-filenginx.config 也可以用 --from-fileconf/ 的方式导入目录。 configMap 卷 YAML 示例
kind: ConfigMap
apiVersion: v1
metadata:name: nginx-config
data: # 导入需要映射的配置文件内容nginx.conf: | # 文件名为键名文件内容为键值注意使用 “|” 后的缩进# For more information on configuration, see:# * Official English Documentation: http://nginx.org/en/docs/# * Official Russian Documentation: http://nginx.org/ru/docs/user nginx;worker_processes auto;error_log /var/log/nginx/error.log;pid /run/nginx.pid;···········————————————————————
spec:volumes:- name: nginx-configconfigMap: # 定义 configMap 配置映射存储卷name: nginx-configcontainers:- name: nginximage: myos:nginxvolumeMounts: # 挂载上述定义的 configMap 配置文件- name: nginx-configmountPath: /usr/local/nginx/conf/nginx.conf # 默认挂载到 nginx.conf 目录除非配置 subPathsubPath: nginx.conf
# 设定挂载卷内的子目录在 configMap 挂载中指定把键名映射为文件名键值即为文件内容。③ secret 加密卷 secret 加密卷可以专门用于保存机密数据在设置 secret.data 字段时所有的键值必须是经过 base64 编码加密的字符串所以需要通过命令的方式加密键值对主要用来证书、token、环境变量、镜像仓库认证等敏感数据的加密 kubectl create secret generic secret-tls --from-filecret.pem --dry-runclient 3、Pod 的容器探针 针对启动探针、就绪性探针、存活探针的容器探针检查机制
exec : 用于在容器内执行指定命令命令退出码为 0 则诊断成功grpc : 使用 gRPC 健康检查协议检测容器内进程存活状态httpGet : 对容器的 IP 地址上指定路径、端口执行 HTTP GET 请求200 响应状态码 400 此区间内诊断成功tcpSocket : 对容器 IP 指定端口执行 TCP 检查。端口打开诊断成功打开连接后立即关闭也算做健康。 每次探测只有三种状态Success 成功Failure 失败Unknown 未知诊断失败不会采取任何行动。 1) startupProbe 启动探针 检测主容器启动前依赖的某个重要服务。
主容器启动后进行检测直到 启动探针 成功之前禁用其他探针探测失败直接杀死容器重启开始下一次探测主容器启动启动探针执行成功就不会重复执行
spec:containers:- name: webimages: myos:httpdstartupProbe: # 定义启动探针tcpSocket: # TCP 存活探测检测 Pod 8080 端口是否开放port: 8080 # 可使用命名端口httpGet也是gRPC不支持# host: 127.0.0.1 # 默认 Pod IP一般不需要修改除非 hostNetWork: true# 容器使用了宿主机的网络命名空间才需要改为 127.0.0.1initialDelaySeconds: 5 # 容器启动后延迟 5s 启动探针若定义了启动探针# 其他探针在其成功后才开始计时timeoutSeconds: 4 # 超时等待时间探测后等待容器响应的时间# 超过时间无回应则认为探测失败。failureThreshold: 3 # 失败阈值超过 3 次失败 Failure 杀死容器successThreshold: 3 # 默认 1,成功阈值3 次成功才标记为 SuccessperiodSeconds: 60 # 检测间隔加长用来保护慢启动容器2) readinessProbe 就绪性探针 检测主容器运行时服务的状态是否正常能否准备好接受请求流量向外提供服务。
启用就绪性探针后默认容器状态为 Failure直到检测成功被标记为就绪状态。当检测失败时端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。就绪性探针在 Pod 生命周期内会一直存在。
spec:containers:- name: webimages: myos:httpdreadinessProbe:httpGet: # HTTP 探测200 x 400 Successscheme: HTTPS # 连接主机方式默认 HTTPpath: /info.php # URL 请求路径port: 80 # 检测 80 端口 http get 状态3) livenessProbe 存活探针 许多长时间运行的应用最终会进入损坏状态除非重新启动分则无法被恢复可用存活探针探测损坏状态检测失败不可用kubelet 会直接杀死容器执行重启策略
存活探针在 Pod 生命周期中一直存在检测结果为 Failure 执行重启策略当 restartPolicy: Never检测失败不会重建容器被存活探针杀死并重启的容器会重新执行 启动探针但不会执行 initContainer
spec:containers:- name: webimages: myos:httpdlivenessProbe: # 定义存活探针exec: # 执行命令返回值检测commands: # 命令的列表- sh - -c - | # 执行脚本命令检测最后一个命令的返回值为 0 Success 4、ResourceQuota 全局资源配额管理 ResourceQuota设置每个命名空间内强制执行的总资源限额。 可限额对象范围。可进行限额对象有 计算资源、存储资源、资源对象。 Limit Range 资源范围限制可以做到精细化限制命名空间内每一个 Pod 的最小、最大配额限制区间配置复杂暂不常用。
kind: ResourceQuota # 全局资源限额 资源对象
apiVersion: v1
metadata:name: myquota namespace: work # 限额生效空间
spec:hard: # map 创建强制限额规则pods: 5 # 限制 Pod 总量为 5个cpu: 2000m # 空间内 CPU 总配额为 2 核memory: 6Gi # 空间内内存总配额为 6Giscopes: # 匹配过滤所有被配额跟踪的对像- BestEffort # Pod 节点压力驱逐类型为“尽量型”的数量限制为 5# Guaranteed 保障型配额 限额,这影响了 Pod 的 QoS 服务质量评级# Burstable 暴发型配额 限额# 尽量型无明确资源限额节点资源消耗过大会被优先驱逐5、PriorityClass 优先级类 PriorityClass是一个无命名空间资源对象定义了从优先级类“名称”到优先级“整数值”的映射Priority 关系到 Pod 之间的调度规则优先级高的 Pod 可以被优先调度系统资源紧张时能够抢占其他 Pod 的资源。 情景设计帮助理解 scheduler 触发抢占策略并调度系统资源逻辑。 php1、2、3 定向调度到同一节点模拟资源不足依次运行查看抢占情况 php1 无优先级 php2 1000 优先级不抢占 php3 500 优先级抢占 ① php1 运行 ② php2 排队资源不足 ③ php3 被 scheduler 触发抢占策略发生抢占 注Pod 无法被调度时scheduler 会由于触发 Pod 上设定的抢占策略从而尝试抢占驱逐较低优先级的 Pod 以使悬决(pending) Pod 可以被调度。kubelet 执行其指令资源被释放 ④ php2 运行 原因 php3 优先级 php2 无法被优先调度即使它先 “抢占了 php1”但释放后的系统资源被 scheduler 严格分配调度给其他 Pod它只触发抢占策略判断有低优先级 Pod 需要被抢占释放资源重新调度 Pod 时判断 php 2 优先级高优先调度。 scheduler 调度 Pod 原则priority 优先级大的 Pod 优先运行禁止私下分配资源。
kind: PriorityClass # 优先级类资源对象
apiVersion: scheduling.k8s.io/v1
metadata:name: low-pri
value: 500 # Priority 的范围(int32) -2,147,483,648 ~ 10^9 (十亿)
preemptionPolicy: Never # 抢占策略 /ˌpriːˈempʃn/ pre emption# 默认项PreemptionLowerPriority 抢占低优先级Neber 从不
description: low priority # 优先级类的描述信息
globalDefault: false # 默认 false设置集群级别的全局默认优先级# 多个全局默认优先级类取 value 最小的生效
———————————————————————————
Pod 中使用方式声明优先级类名称即可
spec:priorityClassName: low-non
