如何借助织梦制作一个简单的网站wordpress安装教程 linux
申请与限制
在CPU配额和内存配额设置中，申请与限制的含义如下：
- 申请（Request）：根据申请值调度该实例到满足条件的节点去部署工作负载。
- 限制（Limit）：根据限制值限制工作负载使用的资源。
如果实例运行所在的节点具有足够的可用资源，实例可以使用超出申请的资源量，但不能超过限制的资源量。
例如，如果您将实例的内存申请值为1GiB、限制值为2GiB，而该实例被调度到一个具有8GiB内存的节点上，且该节点上没有其他实例运行，那么该实例在负载压力较大的情况下可使用超过1GiB的内存，但内存使用量不得超过2GiB。若容器中的进程尝试使用超过2GiB的资源时，系统内核将会尝试将进程终止，出现内存不足（OOM）错误。
配置说明
在实际生产业务中，建议申请和限制比例为1:1.5左右，对于一些敏感业务建议设置成1:1。如果申请值过小而限制值过大，容易导致节点超分严重。如果遇到业务高峰或流量高峰，容易把节点内存或者CPU耗尽，导致节点不可用的情况发生。
- CPU配额：CPU资源单位为核，可以通过数量或带单位后缀（m）的整数表达，例如数量表达式0.1核等价于表达式100m，但Kubernetes不允许设置精度小于1m的CPU资源。
建议配置方法：
节点的实际可用分配CPU量 ≥ 当前实例所有容器CPU限制值之和 ≥ 当前实例所有容器CPU申请值之和，节点的实际可用分配CPU量请在“资源管理 > 节点管理”中对应节点的“可分配资源”列下查看“CPU: ** Core”。
- 内存配额：内存资源默认单位为字节，或者也可以使用带单位后缀的整数来表达，例如100Mi。但需要注意单位大小写。
CPU和内存配额使用示例
假设集群中可调度的节点资源总量为4Core 8GiB，且已经在集群中部署了两个实例，其中实例1存在CPU和内存资源超分（即限制值>申请值），而实例2不存在资源超分。两个实例的规格设置如下：
那么节点上CPU和内存的资源使用情况如下：
- CPU可分配资源=4Core-（实例1申请的1Core+实例2申请的2Core）=1Core
- 内存可分配资源=8GiB-（实例1申请的1GiB+实例2申请的2GiB）=5GiB
此时节点还剩余1Core 5GiB的资源可供下一个新增的实例调度。
如果实例1处于业务高峰、负载压力较大时，会尝试在限制值范围内使用更多的CPU和内存，因此实际可用的资源将会小于1Core 5GiB。
其他资源配额
节点通常还可以具有本地的临时性存储（Ephemeral Storage），由本地挂载的可写入设备或者有时也用RAM来提供支持。临时性存储所存储的数据不提供长期可用性的保证，Pod通常可以使用本地临时性存储来实现缓冲区、保存日志等功能，也可以使用emptyDir类型的存储卷挂载到容器中。更多详情请参见本地临时存储。
Kubernetes支持在容器的定义中指定ephemeral-storage的申请值和限制值来管理本地临时性存储。 Pod中的每个容器可以设置以下属性：
- spec.containers[].resources.limits.ephemeral-storage
- spec.containers[].resources.requests.ephemeral-storage
以下示例中，Pod包含两个容器，每个容器的本地临时性存储申请值为2GiB，限制值为4GiB。 因此，整个Pod的本地临时性存储申请值是4GiB，限制值为8GiB，且emptyDir卷使用了500Mi的本地临时性存储。
apiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: container-1image: <example_app_image>resources:requests:ephemeral-storage: "2Gi"limits:ephemeral-storage: "4Gi"volumeMounts:- name: ephemeralmountPath: "/tmp"- name: container-2image: <example_log_aggregator_image>resources:requests:ephemeral-storage: "2Gi"limits:ephemeral-storage: "4Gi"volumeMounts:- name: ephemeralmountPath: "/tmp"volumes:- name: ephemeralemptyDir:sizeLimit: 500Mi