测验：网络与替换 kube-proxy

Pod 被重新调度到不同的节点，并且其 IP 发生变化。 Cilium 更新了哪些内容？

• 重新计算所有节点的策略映射
• 仅更新 ipcache 的 IP 身份映射，策略映射保持不变。
• 为 pod 颁发了新身份。
• 整个conntrack表被初始化。

为什么像pod-template-hash这样的标签被排除在身份计算之外？

• 这是因为标签键太长，增加了地图大小。
• 这是因为 Kubernetes 不会将此标签附加到 pod 上。
• 这是因为它与命名空间信息重叠。
• 这是因为每次重新部署 Deployment 时，值都会发生变化，并且所有 Pod 都会收到新的身份。

Cilium的socket级负载均衡有什么特点？

• 对于每个数据包，都会在 XDP 挂钩中重新计算目的地。
• 在 connect() 时将服务 IP 更改为后端 IP，从而无需逐包 NAT 和 conntrack 项。
• 它甚至解析 L7 协议并为每个请求路径选择不同的后端。
• 通过操纵 DNS 响应来分配后端

为什么开启kubeProxyReplacement时必须指定k8sServiceHost和k8sServicePort？

• 将kubernetes服务的ClusterIP更改为实际地址的人是Cilium本身，但这是因为它在引导时尚未出现。
• Cilium 需要它来验证 API 服务器证书。
• 这对于删除 kube-proxy 留下的 iptables 规则是必要的。
• 这是因为连接 API 服务器时使用了 Hubble 中继。

什么情况下应该选择隧道（VXLAN）模式而不是原生路由？

• 节点间带宽非常大的环境
• 必须使用DSR模式的环境
• MTU 必须保持尽可能大的环境
• Underlay网络不知道也无法控制PodCIDR路径的环境

Maglev一致性哈希在Cilium服务负载均衡中解决了什么问题？

• 最大限度地减少重新定位，以便在后端增长或收缩时，大多数现有流仍保留在同一后端上。
• 为每个 L7 路由选择不同的后端
• 权重根据后端CPU使用率自动调整。
• 通过调整 DNS TTL 使客户端缓存无效