Golang微服务部署：Kubernetes上的资源配额-Golang-PHP中文网

resourcequota必须在命名空间创建后立即应用，因为它仅对绑定的命名空间生效且只约束后续新建资源；已存在的pod不受影响，配额仅拦截新资源申请，故须在部署任何工作负载前配置，否则可能导致used超hard却无报错、后续操作失败。

golang微服务部署：kubernetes上的资源配额

为什么 `ResourceQuota` 必须在命名空间创建后立即应用

资源配额不是集群全局开关，它只对绑定的命名空间生效，且仅约束后续创建的资源。如果先部署了 Deployment，再创建 ResourceQuota，已存在的 Pod 和容器不会被回收或限流——配额只拦住新资源申请。

必须在 kubectl create namespace myapp-ns 后、任何 kubectl apply -f *.yaml 前，就应用配额配置
若已有资源超出配额，kubectl describe resourcequota -n myapp-ns 会显示 Used 超过 Hard，但不会报错；后续 create 操作才会失败并提示 exceeded quota
配额对象本身不带 spec.scopeSelector 时，默认作用于所有资源类型；加了 scope 才能按条件过滤（比如只限制 PriorityClass=high 的 Pod）

`requests` 和 `limits` 在配额里怎么填才不冲突

配额中的 requests.cpu 和 limits.memory 是独立字段，但它们和 Pod 模板里的 resources.requests / resources.limits 必须逻辑自洽。常见错误是只设 limits 配额却允许 Pod 不设 requests，导致调度器无法预留资源。

Colly Golang Web Scraper and Crawler Framework

Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。

下载

配额中 requests.cpu 控制该命名空间内所有 Pod 的 resources.requests.cpu 总和上限，不是单个 Pod 的限制
若配额含 requests.memory: "2Gi"，而某个 Pod 写了 requests: { memory: "1.5Gi" }，那这个命名空间最多还能创建一个 requests.memory ≤ 512Mi 的 Pod
避免同时设置 limits.cpu 配额但不设 requests.cpu：Kubernetes 允许 limits > requests，但若没设 requests，调度器可能把 Pod 调度到内存不足的节点，引发 OOMKill

Pod 的 `resourceRequirements` 与配额不匹配时的真实报错

不是所有错误都直接说“quota exceeded”。实际失败路径取决于你提交的是什么资源、配额是否启用对应 scope，以及是否触发 admission controller。

提交 Deployment 时，若其模板中某容器 resources.requests.memory 为 "512Mi"，而命名空间配额只剩 "256Mi" 可用，kubectl apply 会卡住并返回：Error from server (Forbidden): error when creating "deploy.yaml": pods "user-service-xxx" is forbidden: exceeded quota: example-quota, requested: memory=512Mi, used: 1792Mi, limited: 2Gi
若配额未启用 scope: PriorityClass，但 Pod 声明了 priorityClassName，配额检查会跳过，不会拦截——这不是 bug，是设计行为
用 kubectl top pods -n myapp-ns 看不到配额使用量，得查 kubectl describe quota -n myapp-ns 或 kubectl get quota -n myapp-ns -o yaml

配额 + Golang 微服务：容易被忽略的 GC 影响

Golang 的 GC 周期会短暂推高 CPU 使用率，如果 limits.cpu 设得太紧（比如和 requests.cpu 相同），Pod 可能在 GC 时被 throttled，导致 HTTP 延迟毛刺。这和配额无关，但会放大配额误判风险。

配额统计的是 requests 总和，不看实际 CPU 使用曲线；但 limits 才真正约束运行时行为
建议 Golang 服务的 limits.cpu 至少比 requests.cpu 高 50%，例如 requests: 200m → limits: 300m，给 GC 和突发流量留余量
若用 HorizontalPodAutoscaler，它的指标来源是 cpu utilization（基于 limits 计算），而非配额值；别把配额当 HPA 阈值依据