集群

Redis Cluster 把键的落点与机器身份分成两层：键先映射到一万六千三百八十四个固定槽之一，再由集群元数据描述各槽的主节点和副本。增加机器不会改变槽哈希函数，运维需要重新分配槽，客户端则发现当前拓扑并处理路由变化。槽、分片、主节点与副本不是可以相互替代的概念。 原有实验把四个等长槽段分配给 A、B、A、C。访问错误节点返回 MOVED。相同标签的键同槽，但同主节点不同槽的 MSET 失败且不改值。没有副本的三个主节点无法替代故障主节点。 键选择槽，不要求机器持有连续区间 普通映射使用键的 CRC16/XMODEM 值对一万六千三百八十四取模。如果第一个左花括号与其后第一个右花括号之间存在非空标签，则只哈希这部分。例如 profile:{42} 和 quota:{42} 的完整键名不同，却位于同一个槽。标签只是数据放置规则，不是权限控制或租户隔离机制。 一个主节点可以拥有多个不连续的槽段。拓扑稳定时，一个槽有权威主节点；整个键属于该槽，大 hash 或有序集合不会被自动拆到多台机器。CLUSTER SHARDS 能显示分片成员及其槽段。尤其不能把“同一主节点”误当成“同一个槽”：前者是当前机器分配关系，后者才是多键操作需要的条件。 客户端也参与路由 支持集群的客户端维护槽映射，并连接拓扑中公布的节点。访问错误的主节点可能收到带目标地址的 MOVED，而不是得到键不存在。MOVED 要求更新路由；ASK 是迁移期间的临时重定向，需要先向目标发送 ASKING 再发送被重定向的命令，不能因此把该槽永久改归目标节点。 迁移也不是所有参与方瞬间同步更新地图。不同客户端可能暂时持有不同拓扑，多键涉及的数据在迁移期间分散到两端时，还可能得到 TRYAGAIN。应使用维护中的集群客户端，不能假设随便连一个入口就会自动代理所有命令。公布的地址不仅要让 Redis 节点互相可达，也必须能从应用所在网络访问。 ...

命名空间为 Kubernetes 集群中的许多对象限定范围。两个团队都可以创建名为 settings 的 ConfigMap，因为包含命名空间后的完整身份不同。这种组织边界很有价值，但不会自动提供网络隔离、独立内核、专属节点容量或完整租户隔离。工作负载实际需要哪一种保障，就应确认额外由什么政策和执行机制落实，而不是把它们都归因于命名空间。 命名空间身份只是一类边界。历史实验未证明网络政策执行、CPU 公平性或面对敌对租户的完整隔离。ResourceQuota 约束准入，不是运行中进程带宽或物理容量预留。本次未重跑示例。 名称范围取决于资源类型 Pod、Service、ConfigMap 和许多工作负载控制器属于命名空间资源。Node、命名空间本身以及其他集群级资源，则不会因为客户端指定了某个命名空间，就被划分成另一份独立副本。应查看具体资源的 API 范围，不能假定所有对象都住在某个房间里面。命名空间也不是由独立子集群构成的嵌套层级。 在 Pod 内部，服务短名称通常按所在命名空间解析。带限定的名称可以指向别处，例如默认集群域下的 api.other.svc.cluster.local。这种约定负责定位目的地址，并不决定允许还是拒绝连接。集群域也可以另行配置，因此示例中的后缀不是所有安装都必须采用的常量。诊断 DNS 时需要结合实际域和工作负载所在位置。 自动化中的命名空间选择应保持明确。对象名称即使正确，如果当前活动命名空间错误，仍然会访问另一个资源。尤其是修改操作，应有意指定 kubeconfig、上下文和命名空间，而不是依赖操作者终端之前留下的状态。对象范围让身份更清楚，但具有广泛权限的管理员依然能够跨范围修改内容，不能因此省略权限审查。 坏掉的样子 没有适用网络政策的命名空间，仍然按照集群网络本身的行为保持连通。仅创建命名空间，或在 DNS 中加入它的名称，并不会拒绝其他 Pod。网络隔离需要正确的政策，以及真正执行这些政策的网络实现。应用认证还是另一层：域名能解析，只说明找到了地址，并不能证明某个调用者应该获准读取返回内容。 ...