容器与云原生

分类下的全部文章

2026年1月4日2 分钟

使用 stern 查看 k8s 多 Pods 日志

这是一篇面向 Kubernetes/k3s 日志查看场景的 stern 使用笔记，聚焦在需要同时观察多个 Pod 日志、并在滚动重启后保持日志连续性的日常排查需求。正文先给出 Linux 环境下从 GitHub release 下载 stern 1.33.1、解压、赋权、移动到 /usr/local/bin 并用 stern --version 验证安装的完整命令。随后说明 stern 与 kubectl 一样默认读取本机 K8s 配置，因此在 k3s 环境中可以通过 --kubeconfig /etc/rancher/k3s/k3s.yaml 临时指定配置，也可以把 KUBECONFIG 写入 ~/.bashrc 让后续命令永久生效。示例以 ragapi 为匹配对象，展示 stern ragapi --tail 20/50 这类命令如何聚合查看相关 Pod 的最近日志。文章还强调 stern 相比普通 kubectl logs 的两个实用差异：它会用不同颜色区分不同 Pod，便于定位报错来源；在 rollout restart 后也能自动发现新 Pod 并接续日志流，减少重复执行命令的麻烦。最后补充了按正则包含 error、exception 以及用 -v 排除 GET /health 等噪声日志的过滤方式，适合运维、后端开发或使用 k3s 部署服务的开发者快速整理多实例日志排查流程。

容器与云原生

2026年1月4日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 能力差异分配流量的后端服务。

容器与云原生

2026年1月4日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 数视为等价参数。

容器与云原生

2026年1月4日1 分钟

关于“容器与云原生”类别

“容器与云原生”类别用于归纳与容器化、云原生体系及相关工程实践有关的内容，并为后续文章归类提供一致的判断依据。该类别的重点不只是收纳零散技术笔记，而是明确它适合承载哪些主题、解决哪些分类场景，以及与站内既有类别之间应如何区分。其准则需要说明使用该类别的理由、覆盖范围、典型话题边界，并判断是否存在与其他分类或子分类合并的可能。读者可以据此理解该分类的定位：它面向需要查找容器、平台化、部署运行和云原生相关知识的技术内容，同时强调分类边界的清晰性，避免相近主题被重复放置或分散管理。

容器与云原生

2026年1月2日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

容器与云原生

2026年1月2日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