前言上一篇整理 Deployment 时，我把它理解成“长期维护一组 Pod 的声明”。Deployment 能让 Pod 少了就补，版本变了就逐步替换。 但这里马上会出现另一个问题：Pod 会不断变化，那别人到底该访问谁？ 假设 demo-api ...

前言上一篇整理 Pod 时，我留下了一个问题：Pod 本身是短暂的，被删除后不会自己回来，那长期运行的服务到底靠什么稳定住？ 刚开始看 Kubernetes 时，我总觉得 Deployment、ReplicaSet、Pod 这三层有点绕。明明最终跑起...

前言刚接触 Kubernetes 时，我一直把 Pod 当成“换了个名字的容器”。毕竟大多数示例里，一个 Pod 只有一个容器，看起来只是外面多包了一层。 继续往下看后，我发现这个理解会留下不少问题：既然一个容器就能运行应用，为什么 Kubernet...

前言上一篇整理 Kubernetes 基本概念时，我把集群简单分成了两部分：控制面负责“管”，工作节点负责“跑”。 这个说法比较容易记，但继续往下看时，我又遇到了新的问题：控制面到底怎么管？调度器选完节点后，是谁真正启动容器？Pod 挂掉以后，又是谁...

前言刚开始接触 Kubernetes 时，我最先看到的是一堆 kubectl 命令，但真正让我困惑的其实是：这些命令背后的 Kubernetes 到底在解决什么问题？ 我试着从一个更熟悉的场景来理解它。 如果把应用部署比作开餐馆，最开始可能只有一个小...

背景最近重新梳理 Kubernetes 时，我发现最容易卡住的地方，不是某一条命令，也不是某一个 YAML 字段，而是它把很多事情都抽象成了“对象”。 我一开始看这些概念，很像第一次走进一个大型园区：有门禁、有调度中心、有楼栋、有房间、有物业、有告示...

好久没有认真写博客了。 上一次比较持续地整理东西，应该还是前几年折腾 Hexo、写软考笔记、记录一些工作和学习中遇到的问题的时候。后来慢慢就断了。不是完全没有东西可写，而是工作节奏变了，生活也跟着变了。 中间换了工作，新公司对开发环境和网络访问管得比...

RFC3489（STUN）简介 RFC3489（Session Traversal Utilities for NAT，早期称为 Simple Traversal of UDP Through NAT）是最初定义的 STUN 协议，用于帮助客户端在有...

我在软路由上加了代理后，git pull/push 无法连接（比如路由器系统是 OpenWrt,代理软件用的 PassWall ），但是如果设置Github 不走代理就可以正常使用。但是如果不代理那就有点治标不治本，还是很慢。 然后排查了一下，发现是...

WebRTC 是 Web 实时通信（Real-Time Communication）的缩写，它既是 API 也是协议。WebRTC 协议是两个 WebRTC Agent 协商双向安全实时通信的一组规则。开发人员可以通过 WebRTC API 使用 W...