k8s中 资源配额 ResourceQuota
文章转载自:https://www.kuboard.cn/learning/k8s-advanced/policy/lr.html
当多个用户(团队)共享一个节点数量有限的集群时,如何在多个用户(团队)之间分配集群的资源就会变得非常重要。Resource quota 的用途便在于此。
资源配额
资源配额(Resource quota)通过 ResourceQuota 对象定义,可以限定单个名称空间中可使用的计算资源的总量。限定的方式有:
- 按对象类型限定名称空间中可创建的对象的总数
- 按对象类型限定名称空间中可消耗的计算资源
资源配额(Resource quota)的工作方式描述如下:
- 不同的用户(团队)使用不同的名称空间。如果通过 ACL(权限控制),可以强制用户只能访问特定的名称空间
- 集群管理员为每个名称空间创建一个 ResourceQuota 对象
- 用户在名称空间中创建对象(Pod、Service等),ResourceQuota 系统跟踪对象的资源使用情况,并确保不会超过 ResourceQuota 对象中定义的配额
- 如果创建或更新对象时与 ResourceQuota 冲突,则 apiserver 会返回 HTTP 状态码 403,以及对应的错误提示信息
- 如果在名称空间中为计算资源 CPU 和 内存 激活 ResourceQuota,用户在创建对象(Pod、Service等)时,必须指定 requests 和 limits。
使用 LimitRange 可以为没有定义 requests、limits 的对象强制添加默认值
下面是一些使用 ResourceQuota 的场景描述:
- 在一个总容量为 32GiB 内存、16核CPU 的集群里,允许 teamA 使用 20GiB内存、10核CPU,允许 teamB 使用 10GiB 内存、4核CPU,保留 2GiB 内存和 2核CPU 待将来分配
- 限定 “Testing” 名称空间使用 1核CPU、1GiB内存,允许 “Production” 名称空间使用任意数量的计算资源
当集群中总的容量小于名称空间资源配额的总和时,可能会发生资源争夺。此时 Kubernetes 集群将按照先到先得的方式分配资源。
无论是资源争夺还是修改名称空间的资源配额(ResourceQuota),都不会影响到已经创建的对象。
启用ResourceQuota
Kubernetes集群中默认启用 ResourceQuota。如果没有,可在启动 apiserver 时为参数 --enable-admission-plugins
添加 ResourceQuota 配置项。
在名称空间中定义一个 ResourceQuota 对象,就可以激活该名称空间的资源配额检查。
资源类型
当多个用户(团队)共享一个节点数量有限的集群时,如何在多个用户(团队)之间分配集群的资源就会变得非常重要。Resource quota 的用途便在于此。本文主要探索通过 ResourceQuota 限定名称空间的计算资源配额、存储资源配额、对象数量配额。
计算资源配额
通过 ResourceQuota 可以限定名称空间中可以使用的 计算资源 的总量。支持的计算资源定义类型如下:
资源名称 | 描述 |
---|---|
limits.cpu | 名称空间中,所有非终止状态(non-terminal)的 Pod 的 CPU限制 resources.limits.cpu 之和不能超过此值 |
limits.memory | 名称空间中,所有非终止状态(non-terminal)的 Pod 的内存限制 resources.limits.memory 之和不能超过此值 |
requests.cpu | 名称空间中,所有非终止状态(non-terminal)的 Pod 的 CPU请求 resources.requrest.cpu 之和不能超过此值 |
requests.memory | 名称空间中,所有非终止状态(non-terminal)的 Pod 的 CPU请求 resources.requests.memory 之和不能超过此值 |
存储资源配额
通过 ResourceQuota 可以:
- 限定名称空间中可以使用的 存储资源 的总量
- 限定名称空间中可以使用的某个 存储类 存储资源的总量
资源名称 | 描述 |
---|---|
requests.storage | 名称空间中,所有存储卷声明(PersistentVolumeClaim)请求的存储总量不能超过此值 |
persistentvolumeclaims | 名称空间中,可以创建的 存储卷声明(PersistentVolumeClaim)的总数不能超过此值 |
.storageclass | |
.storage.k8s.io/requests.storage | 名称空间中,所有与指定存储类(StorageClass)关联的存储卷声明(PersistentVolumeClaim)请求的存储总量不能超过此值 |
.storageclass | |
.storage.k8s.io/persistentvolumeclaims | 名称空间中,所有与指定存储类(StorageClass)关联的存储卷声明(PersistentVolumeClaim)的总数不能超过此值 |
例如,假设管理员想要对存储类 gold 和存储类 bronze 做不同的配额限定,那么,可以按如下方式定义 ResourceQuota:
- gold.storageclass.storage.k8s.io/requests.storage: 500Gi
- bronze.storageclass.storage.k8s.io/requests.storage: 100Gi
在 Kubernetes v1.8 中,引入了本地短时存储(local ephemeral storage)的资源配额设置 (Alpha)
资源名称 | 描述 |
---|---|
requests.ephemeral-storage | 名称空间中,所有 Pod 的本地短时存储(local ephemeral storage)请求的总和不能超过此值 |
limits.ephemeral-storage | 名称空间中,所有 Pod 的本地短时存储(local ephemeral storage)限定的总和不能超过此值 |
对象数量配额
从 Kubernetes v1.9 开始,支持使用如下格式的限定名称空间中标准类型对象的总数量:
- count/.
下面是一些例子:
- count/persistentvolumeclaims
- count/services
- count/secrets
- count/configmaps
- count/replicationcontrollers
- count/deployments.apps
- count/replicasets.apps
- count/statefulsets.apps
- count/jobs.batch
- count/cronjobs.batch
- count/deployments.extensions
Kubernetes v1.15 开始,支持使用相同的格式限定名称空间中自定义资源(CustomResource)对象的总量。例如,为 example.com API group 中的自定义资源(CustomResource) widgets 限定对象数量总数的配额,可以使用 count/widgets.example.com。
当使用 count/*
的方式限定对象总数的配额时,只要对象存储在 apiserver 中,无论其状态如何,该对象就被计数。 此类配额限定可以保护 apiserver 的存储空间不被过度消耗。例如,
- 您可能需要限定名称空间中 Secret 的总数,因为他们通常占用的存储空间比较大。集群中如果存在大量的 Secret 对象,可能会导致 apiserver 或者控制器(Controller)启动失败
- 您可能也需要限定名称空间中 Job 对象的个数,以避免某个配置错误的 cronjob 创建了太多的 Job,造成了拒绝服务(denial of service)的情况
作用域
每个 ResourceQuota 对象都可以绑定一组作用域,当 Kubernetes 对象与此 ResourceQuota 的作用域匹配(在作用域中)时,ResourceQuota 的限定才对该对象生效。
Scope(作用域) | 描述 |
---|---|
Terminating | 包含所有 .spec.activeDeadlineSeconds >= 0 的 Pod |
NotTerminating | 包含所有 .spec.activeDeadlineSeconds is nil 的Pod |
BestEffort | 包含所有服务等级(quality of service)为 BestEffort 的 Pod |
NotBestEffort | 包含所有服务等级(quality of service)为 NotBestEffort 的 Pod |
- 带有 BestEffort 作用域的 ResourceQuota 关注点为: Pod
- 带有 Terminating、NotTerminating、 NotBestEffort 的作用域关注点为:
- cpu
- limits.cpu
- limits.memory
- memory
- pods
- requests.cpu
- requests.memory
按PriorityClass设定ResourceQuota
创建 Pod 时,可以指定 priority
(opens new window)。使用 ResourceQuota 的 .spec.scopeSelector 字段将 ResourceQuota 和 Pod 的 priority 关联,进而限定 Pod 的资源消耗。
只有当 ResourceQuota 的 .spec.scopeSelector 字段与 Pod 的 priorty 字段匹配时,ResourceQuota 才生效。
下面的例子创建了一个通过 priority 限定特定 Pod 的 ResourceQuota 对象,该例子的工作方式如下:
- 假设集群中的 Pod 可以被指定三种 priority class: low、medium、high
- 集群中为每个 Priority 都创建了一个 ResourceQuota 对象
定义 ResourceQuota 对象的文件如下所示:
apiVersion: v1
kind: List
items:
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-high
spec:
hard:
cpu: "1000"
memory: 200Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["high"]
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-medium
spec:
hard:
cpu: "10"
memory: 20Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["medium"]
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-low
spec:
hard:
cpu: "5"
memory: 10Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["low"]
执行命令以创建 ResourceQuota:
kubectl create -f https://kuboard.cn/statics/learning/policy/rq-scope-quota.yaml
resourcequota/pods-high created
resourcequota/pods-medium created
resourcequota/pods-low created
执行如下命令验证 quota 的使用为 0:
kubectl describe quota
Name: pods-high
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 1k
memory 0 200Gi
pods 0 10
Name: pods-low
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 5
memory 0 10Gi
pods 0 10
Name: pods-medium
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 10
memory 0 20Gi
pods 0 10
创建 “high” priority Pod,YAML 文件如下所示:
apiVersion: v1
kind: Pod
metadata:
name: high-priority
spec:
containers:
- name: high-priority
image: ubuntu
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello; sleep 10;done"]
resources:
requests:
memory: "10Gi"
cpu: "500m"
limits:
memory: "10Gi"
cpu: "500m"
priorityClassName: high
执行命令以创建
kubectl create -f https://kuboard.cn/statics/learning/policy/rq-scope-high-priority-pod.yaml
验证 "high" priority 对应的 ResourceQuota pods-high 的 Used 统计结果,可以发现 pods-heigh 的配额已经被使用,而其他两个的配额则没有被使用。
kubectl describe quota
Name: pods-high
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 500m 1k
memory 10Gi 200Gi
pods 1 10
Name: pods-low
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 5
memory 0 10Gi
pods 0 10
Name: pods-medium
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 10
memory 0 20Gi
pods 0 10
scopeSelector.matchExpressions.operator 字段中,可以使用如下几种取值:
- In
- NotIn
- Exist
- DoesNotExist
Requests vs Limits
Kubernetes 中,在为容器分配计算资源时,每一个容器都可以指定 resources.limits.cpu、resources.limits.memory、resources.requests.cpu、resources.requests.memory。
ResourceQuota可以为 limits 和 requests 各自设定资源配额。
- 如果 ResourceQuota 指定了 requests.cpu 或者 requests.memory,此时任何新建的容器都必须明确指定自己的 requests.cpu、requests.memory。
- 如果 ResourceQuota 指定了 limits.cpu 或者 limits.memory,此时任何新建的容器都必须明确指定自己的 limits.cpu、limits.memory。
查看和设定ResourceQuota
使用 kubectl 可以查看和设定 ResourceQuota:
kubectl create namespace myspace
cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
requests.nvidia.com/gpu: 4
EOF
kubectl create -f ./compute-resources.yaml --namespace=myspace
cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: object-counts
spec:
hard:
configmaps: "10"
persistentvolumeclaims: "4"
pods: "4"
replicationcontrollers: "20"
secrets: "10"
services: "10"
services.loadbalancers: "2"
EOF
kubectl create -f ./object-counts.yaml --namespace=myspace
查看
kubectl get quota --namespace=myspace
NAME AGE
compute-resources 30s
object-counts 32s
执行
kubectl describe quota compute-resources --namespace=myspace
Name: compute-resources
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
requests.cpu 0 1
requests.memory 0 1Gi
requests.nvidia.com/gpu 0 4
执行
kubectl describe quota object-counts --namespace=myspace
Name: object-counts
Namespace: myspace
Resource Used Hard
-------- ---- ----
configmaps 0 10
persistentvolumeclaims 0 4
pods 0 4
replicationcontrollers 0 20
secrets 1 10
services 0 10
services.loadbalancers 0 2
使用 kubectl 还可以支持对象数量配额(count/<resource>.<group>
)的查看和设定:
kubectl create namespace myspace
kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
kubectl describe quota --namespace=myspace
Name: test
Namespace: myspace
Resource Used Hard
-------- ---- ----
count/deployments.extensions 1 2
count/pods 2 3
count/replicasets.extensions 1 4
count/secrets 1 4
ResourceQuota和Cluster Capacity
ResourceQuota 与 Cluster Capacity 相互独立,都使用绝对值来标识其大小(而不是百分比)。如果您想集群中添加节点,并不会自动使其中任何一个名称空间的可用资源配额发生变化。
某些情况下,需要更加复杂的策略配置,例如:
- 在多个团队之间按比例切分集群的资源
- 允许每一个租户按需增加资源使用,但是又有合适的限定以避免资源耗尽的情况发生
- 根据某个名称空间的实际需要,增加节点,并提高为其提高资源配额
要实现这些策略,可以使用 ResourceQuota 作为基础,编写自己的控制器来监听资源配额的使用情况,并根据具体的情况动态调整名称空间的 ResourceQuota。
尽管 ResourceQuota 可以将集群中的资源配额分配到名称空间,但是它并不对节点做任何限定,不同名称空间的 Pod 可以运行在同一个节点上。
限定Priority Class的默认资源消耗
某些情况下我们可能需要做如下设定:某个特定 priority 的 Pod(例如,cluster-services)当且仅当名称空间中存在匹配的 ResourceQuota 时才可以创建。
使用这样的机制,集群管理员可以限定某些特别的 priority class 只在指定的名称空间中使用。
如果要激活此特性,您需要将如下配置文件的路径通过 --admission-control-config-file
参数指定到 kube-apiserver 的启动参数中:
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
configuration:
apiVersion: resourcequota.admission.k8s.io/v1beta1
kind: Configuration
limitedResources:
- resource: pods
matchScopes:
- scopeName: PriorityClass
operator: In
values: ["cluster-services"]
完成此配置后,cluster-services priority 的 Pod 将只能在带有对应 scopeSelector 的 ResourceQuota 的名称空间中创建,例如:
scopeSelector:
matchExpressions:
- scopeName: PriorityClass
operator: In
values: ["cluster-services"]
CPU/内存资源限额
本文通过实例演示了如何通过ResourceQuota为名称空间配置CPU和内存的资源限额。
创建名称空间
执行如下命令,创建名称空间:
kubectl create namespace quota-mem-cpu-example
创建ResourceQuota
下面是 ResourceQuota 的YAML文件:
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-cpu-demo
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
执行命令以创建该 ResourceQuota:
kubectl apply -f https://kuboard.cn/statics/learning/policy/rq-mem-cpu-quota.yaml --namespace=quota-mem-cpu-example
执行命令查看刚创建的 ResourceQuota:
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml
ResourceQuota 为 quota-mem-cpu-example 名称空间设定了如下资源配额:
- 每一个容器必须有 内存请求(request)、内存限制(limit)、CPU请求(request)、CPU限制(limit)
- 所有容器的内存请求总和不超过 1 GiB
- 所有容器的内存限定总和不超过 2 GiB
- 所有容器的CPU请求总和不超过 1 cpu
- 所有容器的CPU限定总和不超过 2 cpu
创建Pod
下面是一个 Pod 的配置文件:
apiVersion: v1
kind: Pod
metadata:
name: quota-mem-cpu-demo
spec:
containers:
- name: quota-mem-cpu-demo-ctr
image: nginx
resources:
limits:
memory: "800Mi"
cpu: "800m"
requests:
memory: "600Mi"
cpu: "400m"
执行命令以创建该 Pod
kubectl apply -f https://kuboard.cn/statics/learning/policy/rq-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
执行命令验证 Pod 已运行:
kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example
此时执行命令再次查看名称空间的资源配额消耗情况:
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml
输出结果中除了显示名称空间的资源配额之外,同时还显示了该配额的使用情况。结果如下所示:
status:
hard:
limits.cpu: "2"
limits.memory: 2Gi
requests.cpu: "1"
requests.memory: 1Gi
used:
limits.cpu: 800m
limits.memory: 800Mi
requests.cpu: 400m
requests.memory: 600Mi
尝试创建第二个Pod
下面是另外一个 Pod 的 YAML 文件:
apiVersion: v1
kind: Pod
metadata:
name: quota-mem-cpu-demo-2
spec:
containers:
- name: quota-mem-cpu-demo-2-ctr
image: redis
resources:
limits:
memory: "1Gi"
cpu: "800m"
requests:
memory: "700Mi"
cpu: "400m"
在此配置文件中,Pod 请求了 700MiB 的内存,如果加上第一个 Pod 所请求的内存,其结果已经超出了名称空间的资源配额中对内存请求的限制:600MiB + 600MiB > 1GiB
执行如下命令尝试创建该 Pod:
kubectl apply -f https://kuboard.cn/statics/learning/policy/rq-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
第二个 Pod 将不能创建成功,该命令的输出结果将提示创建 Pod 失败的原因是内存请求之和超过了内存请求的资源配额,错误信息如下所示:
Error from server (Forbidden): error when creating "examples/admin/resource/quota-mem-cpu-pod-2.yaml":
pods "quota-mem-cpu-demo-2" is forbidden: exceeded quota: mem-cpu-demo,
requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.memory=1Gi
总结
在本文的例子中,您可以使用 ResourceQuota 来限定名称空间中所有容器的内存请求(request)之和不超过指定的配额。同时也可以设置内存限定(limit)、CPU请求(request)、CPU限定(limit)的资源配额。
如果需要限定单个Pod、容器的资源使用情况,请参考 LimitRange
清理
删除名称空间可清理本文所创建的所有内容:
kubectl delete namespace quota-mem-cpu-example
Pod数量限额
本文通过实例演示了如何通过ResourceQuota为名称空间配置最多可以运行多少个Pod。
创建名称空间
为本次演示创建名称空间:
kubectl create namespace quota-pod-example
创建ResourceQuota
为本次演示创建 ResourceQuota 对象,yaml文件如下所示:
apiVersion: v1
kind: ResourceQuota
metadata:
name: pod-demo
spec:
hard:
pods: "2"
执行命令创建该 ResourceQuota
kubectl apply -f https://kuboard.cn/statics/learning/policy/rq-pod-quota.yaml --namespace=quota-pod-example
执行如下命令查看已创建的 ResourceQuota
kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml
输出结果中显示了该名称空间的配额限定了只能创建两个 Pod,当前没有任何 Pod 被创建:
spec:
hard:
pods: "2"
status:
hard:
pods: "2"
used:
pods: "0"
创建Pod
创建如下 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: pod-quota-demo
spec:
selector:
matchLabels:
purpose: quota-demo
replicas: 3
template:
metadata:
labels:
purpose: quota-demo
spec:
containers:
- name: pod-quota-demo
image: nginx
该 Deployment 的副本数为 3 replicas: 3,执行命令以创建该 Deployment:
kubectl apply -f https://kuboard.cn/statics/learning/policy/rq-pod-deployment.yaml --namespace=quota-pod-example
执行命令以查看 Deployment 的详细信息
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
尽管 Deployment 期望的副本数是 3,但是由于名称空间通过 ResourceQuota 限定了最大的 Pod 数量,因此,最终只有两个 Pod 被创建成功。输出结果如下所示:
spec:
...
replicas: 3
...
status:
availableReplicas: 2
...
lastUpdateTime: 2017-07-07T20:57:05Z
message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
清理
删除名称空间可清理本次演示创建的对象:
kubectl delete namespace quota-pod-example
k8s中 资源配额 ResourceQuota的更多相关文章
- Kubernetes中资源配额管理
设置资源请求数量 创建Pod的时候,可以为每个容器指定资源消耗的限制.Pod的资源请求限制则是Pod中所有容器请求资源的总和. apiVersion: v1 kind: Pod metadata: n ...
- kubernetes调度之资源配额
系列目录 当多个用户或者开发团队共享一个有固定节点的的kubernetes集群时,一个团队或者一个用户使用的资源超过他应当使用的资源是需要关注的问题,资源配额是管理员用来解决这个问题的一个工具. 资源 ...
- K8s容器资源限制
在K8s中定义Pod中运行容器有两个维度的限制: 1. 资源需求:即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod. 如: Pod运行至少需要2G内存,1核CPU 2. 资源限额: ...
- K8s 资源配额管理对象 ResourcesQuota
Kubernetes 是一个多租户平台,更是一个镜像集群管理工具.一个 Kubernetes 集群中的资源一般是由多个团队共享的,这时候经常要考虑的是如何对这个整体资源进行分配.在 kubernete ...
- k8s中yaml文常见语法
在k8s中,所有的配置都是 json格式的.但为了读写方便,通常将这些配置写成yaml 格式,其运行的时候,还是会靠yaml引擎将其转化为json,apiserver 也仅接受json的数据类型. y ...
- kubernetes调度之资源配额示例
系列目录 前面说过,资源配额限制在指定名称空间下,对资源对象数量和特定类型的资源的限制,你可以在ResourceQuota中指定配额 创建名称空间 我们创建一个新的名称空间来演示 kubectl cr ...
- Kubernetes笔记(四):详解Namespace与资源限制ResourceQuota,LimitRange
前面我们对K8s的基本组件与概念有了个大致的印象,并且基于K8s实现了一个初步的CI/CD流程,但对里面涉及的各个对象(如Namespace, Pod, Deployment, Service, In ...
- 使用 Admission Webhook 机制实现多集群资源配额控制
1 要解决的问题 集群分配给多个用户使用时,需要使用配额以限制用户的资源使用,包括 CPU 核数.内存大小.GPU 卡数等,以防止资源被某些用户耗尽,造成不公平的资源分配. 大多数情况下,集群原生的 ...
- k8s学习-资源控制器
4.3.资源控制器 4.3.1.概念 Kubernetes中内建了很多种controller(控制器),这些相当于一个状态机,用来控制Pod的具体状态和行为. 4.3.2.分类 Replication ...
随机推荐
- resultMap自定义映射(多对一)
自定义resultMap,处理复杂的表关系,实现高级结果集映射 1) id :用于完成主键值的映射 2) result :用于完成普通列的映射 3) association :一个复杂的类型关联;许多 ...
- windows配置skywalking集群
一.zookeeper 准备配置三个zookeeper,因为我是单台模拟,所以需要使用不同的端口,使用版本是apache-zookeeper-3.6.3-bin (必须是3.5+) 1.第1个zook ...
- Solution -「Luogu 3959」 宝藏
果真是宝藏题目. 0x01 前置芝士 这道题我是真没往状压dp上去想.题目来源. 大概看了一下结构.盲猜直接模拟退火!\xyx 所需知识点:模拟退火,贪心. 0x02 分析 题目大意:给你一个图,可能 ...
- django项目、vue项目部署云服务器
目录 上线架构图 服务器购买与远程连接 安装git 安装mysql 安装redis(源码安装) 安装python3.8(源码安装) 安装uwsgi 安装虚拟环境 安装nginx(源码安装) vue项目 ...
- 【ASP.NET Core】选项模式的相关接口
在 .NET 中,配置与选项模式其实有联系的(这些功能现在不仅限于 ASP.NET Core,而是作为平台扩展来提供,在其他.NET 项目中都能用).配置一般从多个来源(上一篇水文中的例子,记得否?) ...
- 网易云UI模仿-->侧边栏
侧边栏 效果图 界面分解 可以看到从上到下的流式布局.需要一个Column来容纳,并且在往上滑动的过程中顶部的个人信息是不会动的.所以接下来需要将剩余部分占满使用Flexibel组件. 实现 个人信息 ...
- PHP及相关服务器防盗链
服务器防盗链 假设域名为www.localhost.com 1.apache配置httpd.conf SetEnvIfNoCase Referer "^http://www.localhos ...
- 趣味问题《寻人启事》的Python程序解决
偷懒了很久,今天我终于又来更新博客了~ 最近,我看到了一个趣味问题,或者说是数学游戏:<寻人启事>. 在表述这个问题前,我们需要了解一下"冰雹猜想": 对于任意一个正整 ...
- EPLAN中的edz文件的用法
1 EDZ 文件的定义 EDZ 是 EPLAN Data Archive Zipped(EPLAN 数据压缩文件包)的缩写,最早是专门为西门子定制的,现在已经 成为 EPLAN 中一种标准的部件 ...
- React报错之No duplicate props allowed
正文从这开始~ 总览 当我们为相同的组件传递相同的属性多次时,就会导致"No duplicate props allowed"警告.为了解决该警告,请确保只传递一次该属性.比如说, ...