下级分类
服务器与部署36 篇
基础设施
服务器、部署、容器与运行环境。
专题分组
下级分类
容器与云原生5 分钟
利用 kong 进行流量负载均衡处理
这篇笔记聚焦用 Kong Upstream 为 Kubernetes 中的后端副本做流量分发，场景是 3 个 Pod 暴露在 10.42.0.20 到 10.42.0.22，并通过 Target 与 Service 组合交给 Kong 选择实际后端。内容先区分 Round Robin、Least Connections 与 Consistent Hashing：无状态标准 API 适合轮询，耗时较长的 RAG 向量计算更适合最小连接数，而带本地缓存、用户 Session 或上下文依赖的服务则需要哈希分流来保持请求落点稳定。配置层面强调 Upstream 模式与直连模式的差异，Service Host 指向 upstream 名称后，Service Port 即使写 80 也不会决定最终端口，Kong 会根据上游 Target 中的地址与端口转发到具体的 10.42.0.x:8006。文章还用取余哈希和一致性哈希对比解释扩缩容影响：简单取模在节点数量变化时会导致大量请求重新分布，而 Kong 的一致性哈希通过环形空间顺时针查找，只让新增或减少节点附近的一小段流量发生漂移。对于依赖缓存命中率的 RAG 服务，这种机制能降低扩容、缩容或 Pod 变更时的缓存失效范围，避免瞬时流量冲击。最后对 Target 的 weight 做了关键澄清：在一致性哈希下它更像虚拟节点数量，权重越高，在哈希环上的“分身”和覆盖范围越多，从而获得更大比例的请求，适合需要按 Pod 能力差异分配流量的后端服务。
12 分钟
部署 Kong
这是一份在 Kubernetes 中部署 Kong 网关的配置笔记，重点放在 hostNetwork 模式下如何同时兼顾网关性能、本机 PostgreSQL 连接和外部访问安全。配置先用 Secret 保存 pg_password，再通过 Job 执行 kong migrations bootstrap 初始化数据库，随后在 Deployment 中设置 KONG_DATABASE、KONG_PG_HOST、KONG_PG_USER、KONG_PG_DATABASE 等环境变量，让 Kong 直接连接宿主机 127.0.0.1:5432 上的 postgres 数据库。网关容器启用 hostNetwork 并配合 ClusterFirstWithHostNet，代理端口只开放 0.0.0.0:8000，而 Admin API 和 Admin GUI 分别限制在 127.0.0.1:8001 与 127.0.0.1:1337，避免管理端口被公网直接访问。由于 Kong UI 默认没有账号体系，文章给出 Nginx 反代方案，通过 auth_basic 和 .htpasswd 为 kong-ui 域名增加访问保护，并将 /manager-api/ 转发到本地 8001，根路径转发到本地 1337，其中 proxy_pass 末尾斜杠被特别标注为关键细节。另一组 Nginx 配置用于 api 域名，将外部 HTTPS 请求转发到本地 8000 的 Kong Proxy，同时保留真实 IP、WebSocket Upgrade、关闭代理缓冲和上传大小设置。适合需要在单机或混合 Docker/K8s 环境中部署 Kong、使用本机数据库并通过 Nginx 统一暴露 UI 与 API 的后端和运维读者参考。
3 分钟
K8s pod 副本与 Uvicorn Workers
这篇笔记围绕 FastAPI/Uvicorn 服务在 Kubernetes 中的并发扩展方式，区分了 Pod 副本和 Uvicorn Workers 的层级差异：前者是由 K8s 管理的容器级横向扩展，后者是在单容器内由 Python/Uvicorn 管理的进程级纵向扩展。正文强调二者本质上都会启动独立 Python 进程，因此无论是单 Pod 多 Worker，还是多 Pod 单 Worker，都可以绕开 GIL 对单解释器线程并行的限制，实现多核并行。差异主要落在资源隔离、负载均衡和故障边界上：多 Worker 会共享同一个容器的 CPU 与内存限制，由 Uvicorn 主进程分发请求；多 Pod 则由 K8s Service 做网络层负载均衡，并可为每个 Pod 设置独立资源配额。单 Pod 多 Worker 的优势是启动快、内存更省、进程切换开销较小，但在 2 核 CPU 开 4 个 Worker 这类配置下会发生资源争抢，容器 OOM 时所有 Worker 会一起退出。多 Pod 单 Worker 的优势是每个进程拥有更明确的资源保障，单个 Pod 死锁或内存泄漏只损失部分服务能力，并可由 K8s 自动重启，适合追求稳定性、容灾和大规模水平扩展的部署。读者可以据此判断在成本、启动速度、资源利用率与故障隔离之间如何取舍，而不是简单把副本数和 Worker 数视为等价参数。
1 分钟
关于“容器与云原生”类别
“容器与云原生”类别用于归纳与容器化、云原生体系及相关工程实践有关的内容，并为后续文章归类提供一致的判断依据。该类别的重点不只是收纳零散技术笔记，而是明确它适合承载哪些主题、解决哪些分类场景，以及与站内既有类别之间应如何区分。其准则需要说明使用该类别的理由、覆盖范围、典型话题边界，并判断是否存在与其他分类或子分类合并的可能。读者可以据此理解该分类的定位：它面向需要查找容器、平台化、部署运行和云原生相关知识的技术内容，同时强调分类边界的清晰性，避免相近主题被重复放置或分散管理。
容器与云原生14 分钟
部署 k8s 与配置项目
这份笔记围绕在单机环境中用 k3s 搭建 Kubernetes 并部署实际项目展开，先从 /root/k8s/config.yaml 的基础配置入手，记录了设置 token、tls-san、API 端口、kubeconfig 权限、禁用默认 Traefik 以及把数据目录固定到 /root/k8s/data 的安装方式。可视化管理部分使用 Portainer 官方 manifest 部署到 portainer 命名空间，通过 NodePort 暴露 9000 与 9443，并提醒 Portainer 需要 HTTPS 访问、首次初始化超时后可删除 Pod 触发重建。文章随后给出 Nginx 反向代理到本机 30779 端口的配置示例，包括 SSL、WebSocket 升级头、真实 IP 传递、关闭代理缓冲和上传大小限制。项目部署部分强调用 YAML 与环境文件管理应用，而不是依赖 UI 表单，示例中通过 kubectl create secret generic 从 ragapi.env 创建 Secret，再在 Deployment 中用 envFrom 注入环境变量，并配置私有镜像拉取、RollingUpdate 滚动更新和 Service 的 NodePort 暴露。文中还用类比区分 ConfigMap 与 Secret、Deployment 与 Service：前者分别承载非敏感配置和敏感信息，后者分别负责 Pod 生命周期与流量入口，解释了为什么更新 Pod 时 Service 的地址和端口可以保持稳定。最后整理了一组从 Docker 使用习惯迁移到 kubectl 的常用命令，覆盖查看 Pod/Service/Deployment、跟踪日志、查看资源占用、进入容器，以及通过 rollout restart 或删除 Pod 实现重启，适合刚把个人项目迁移到 k3s 的后端开发者和运维学习者参考。
k8s
容器与云原生13 分钟
K8s 简单介绍
这是一篇面向 Docker 使用者的 Kubernetes 入门笔记，核心在于把 K8s 理解为负责管理和调度容器的编排系统，而不是 Docker 的替代品：Docker 负责打包和运行，K8s 通过声明式期望状态维持副本、自愈、伸缩和资源抽象。文章用对照表梳理 Namespace、Pod、Deployment、StatefulSet、Service、Ingress、ConfigMap/Secret、PV/PVC 等常见对象，并解释 Pod 是 K8s 的最小调度单位，同一 Pod 内容器共享 IP、localhost 通信和存储卷，因此端口不能冲突。重点说明 Pod 具有一次性生命周期，重建后 IP 会变化，所以需要 Service 作为稳定访问入口，并依赖 DNS 将服务名导向当前可用的后端 Pod。Namespace 用于隔离开发、测试、生产等环境，Ingress 则作为七层反向代理处理域名、路径和 HTTPS，相比 NodePort 更适合对外暴露 Web 服务。存储部分通过 PV 与 PVC 区分真实存储资源和使用申请，说明它如何让 Pod 跨节点漂移时仍能挂载到持久化数据。文章最后区分 Deployment 管理无状态应用、StatefulSet 管理数据库等有状态应用，并提醒滚动更新只保证新请求入口平滑切换，长连接仍会在宽限期结束或旧 Pod 退出时断开，需要应用处理 SIGTERM 和客户端重连。
k8s
1 分钟
Nginx 配置 非域名 443 端口的自签证书
这是一篇面向 Nginx HTTPS 默认入口的防探测配置笔记，目标是处理直接通过服务器 IP 访问 443 端口时可能暴露真实站点证书信息的问题。做法先使用 OpenSSL 生成一个有效期较长、CN 设置为 AccessDenied 的自签证书，并把生成的 fake.crt 与 fake.key 放到 Nginx 可读取的位置。随后在 default 配置中声明同时监听 80 和 443 的 default_server，用 server_name _ 承接未匹配到具体域名的请求，并将该默认虚拟主机绑定到这张“假证书”。这样扫描器或访问者如果不带正确域名访问 IP，在 TLS 阶段看到的不是生产站点证书，而是自签证书中的 AccessDenied；连接建立后，Nginx 再通过 return 444 直接断开请求。文章还给出一个验证思路：到 Censys 按 IP 搜索，检查公开扫描结果中是否仍能反查到真实域名。该配置适合希望降低证书透明度、互联网扫描或 IP 反查带来的域名暴露风险的运维与站点维护者，但它只针对默认入口和证书展示层面，不能替代完整的访问控制与资产隐藏策略。
nginx
1 分钟
Docker -pg 创建数据库
这则笔记记录了在 Docker 容器中直接维护 PostgreSQL 的两个常用操作：创建数据库和调整最大连接数。创建数据库部分使用 docker exec 进入正在运行的 my-postgres 容器，并通过 psql 指定用户、目标库和 -c 参数执行 CREATE DATABASE demo_db_for_gin，其中示例里的 super_postgres 需要替换成实际 PostgreSQL 用户名。连接数配置部分面向 docker-compose 场景，通过在服务配置中加入 command: postgres -c max_connections=1000，将 PostgreSQL 默认的 100 个连接提升到 1000。配置值并非固定推荐，需要结合机器资源和业务并发情况调整，避免只提高参数而忽略内存与连接管理成本。修改后可再次使用 docker exec 调用 psql，并执行 SHOW max_connections; 验证容器内 PostgreSQL 是否按预期加载新参数。整体适合作为容器化 PostgreSQL 日常初始化、临时建库和连接数参数核验的速查记录，尤其适合已经具备 Docker 与 psql 基础用法的开发或运维人员。
6 分钟
基于软链接的 nginx 管理 server 模块
这份笔记围绕 Nginx 多站点配置的模块化管理展开，核心做法是用软链接把“已编写的配置”和“当前生效的配置”分离。正文将 /etc/nginx/sites-available/ 定位为配置仓库，用来保存所有 server 文件、草稿、备份或暂时下线的网站；将 /etc/nginx/sites-enabled/ 作为实际加载目录，只放指向仓库文件的软链接，并通过 nginx.conf 在 http 段 include 该目录来决定哪些站点生效。文章给出了一份基础 nginx.conf 示例，包含事件连接数、日志、gzip、Keep-Alive、SSL 全局参数，以及同时加载 conf.d 和 sites-enabled 的关键配置。随后以一个 HTTPS 探针站点为例，展示 server 块如何配置证书、server_name、反向代理到 localhost:25774，并补充真实 IP、转发协议、WebSocket Upgrade、关闭代理缓冲和 50M 上传限制等常见代理设置。启用流程则被简化为脚本：使用 ln -sf 将 sites-available 下的配置批量链接到 sites-enabled，再执行 nginx -t 校验，通过后 reload 服务。它适合小型服务器或个人多站点环境，用较低成本实现站点配置的归档、迁移、批量启用和下线控制；需要注意的是，真正被 Nginx 读取的是 include 的 enabled 目录，单独把文件放进 available 并不会生效。
nginx
7 分钟
Nginx 配置防火墙
这篇笔记围绕 Nginx 在反向代理和 Cloudflare 接入场景下的访问控制配置展开，核心问题是如何在使用真实客户端 IP 的同时避免错误信任可伪造的请求头。文中先给出一种粗糙写法：在 server 中将 set_real_ip_from 设为 0.0.0.0/0，并通过 real_ip_header CF-Connecting-IP 改写 remote_addr，再配合 allow 与 deny all 做访问限制；但这种做法等于让任意来源都能提交 CF-Connecting-IP，攻击者可借此伪造来源地址。文章解释了 Nginx 默认情况下 remote_addr 代表 TCP 连接源 IP，未启用 real_ip 时相对可信，而一旦信任范围放得过宽，就会主动放弃这一安全边界。更稳妥的方案是从 Cloudflare 官方 IPv4、IPv6 地址接口拉取网段，生成 cloudflare_real_ip.conf，逐行写入 set_real_ip_from，并配置 real_ip_header 与 real_ip_recursive。随后可在 http 块全局 include，或在单个 server 块中按站点生效，更新脚本执行后通过 nginx -t 校验并 reload 服务。文中还提醒 allow 规则按顺序匹配，deny all 会直接拒绝并返回 403；如果 VPS 同时具备 IPv4 和 IPv6，放行列表也要同时覆盖两类地址。最后通过 crontab 每周自动刷新 Cloudflare 网段，适合需要在 Nginx、Cloudflare 和反向代理链路中正确处理真实 IP 与访问白名单的运维或后端开发者参考。
nginx