Kubernetes已有Service等网络机制仍需容器网络的相关问题咨询

问题1：Kubernetes已经提供Service、kube-proxy、Ingress等工作负载抽象及上层网络机制，为何还需要Pod之间的点对点连接？哪些场景下已有Service仍需使用容器网络？ #

Service、kube-proxy、Ingress属于上层的流量转发和服务抽象，本身不提供基础网络连通能力，所有转发规则的生效都依赖Pod之间的点对点网络可达，没有底层容器网络保障Pod互通的话，这些上层组件的配置根本无法落地。除此之外这些上层抽象本身有能力边界，覆盖不了所有通信需求：

• 上层转发会引入额外的性能开销，且会做SNAT替换源IP，丢失原始网络上下文
• 仅支持TCP/UDP类的标准协议，无法兼容自定义私有协议、特殊网络包的传输需求
• 只能按IP、端口、域名做基础转发，无法适配有状态应用的精细化通信需求

需要直接使用容器网络点对点通信的常见场景：

• 有状态集群内部通信：比如Etcd、Redis、MySQL集群的选主、数据同步，需要固定Pod之间的直接长连接，走Service负载均衡会打散连接，破坏集群的正常选举和同步逻辑
• 低延迟敏感场景：比如实时计算、高频交易类业务，跳过Service转发的点对点通信可以把网络延迟降到最低
• 网络管控类需求：比如网络策略配置、流量审计、自定义监控，需要拿到Pod的原始源IP、端口等信息，走Service转发后无法获取到完整的原始数据
• 非标准协议通信：比如GRPC流式传输、IP-in-IP隧道、自定义RPC协议的通信，上层抽象无法适配，只能走底层容器网络传输

问题2：Kubernetes的默认CNI是什么？很多用户安装Kubernetes时未手动安装主流CNI插件，默认使用的是kubenet吗？ #

Kubernetes核心本身没有内置默认的CNI实现，CNI是独立于K8s核心的第三方网络组件，不同安装渠道的默认网络方案差异很大：

• 如果你用官方的kubeadm工具部署裸金属集群，确实会预配置kubenet作为临时基础网络方案，但kubenet能力非常有限，仅支持同节点Pod互通，跨节点通信需要用户自己手动配置节点路由规则，也不支持网络策略、Overlay网络等高级能力，只能用于测试或单节点集群
• 云厂商的托管K8s服务默认会内置厂商自研的CNI插件，不需要用户手动安装，所以很多用户感知不到CNI的存在，这类场景用的不是kubenet
• 本地测试用的K8s发行版比如minikube、kind，默认会内置kindnet、flannel这类轻量CNI，也不是kubenet

问题3：Istio与容器网络存在较多功能重叠，二者是否可以实现相同目标？是否仅存在Istio为上层实现、CNI为底层实现且效率更高的差异？Istio是否也有自身的CNI实现？ #

二者定位完全不同，不可能实现相同目标：

• 容器网络（CNI）的核心职责是解决集群内Pod的基础网络连通问题，属于二层/三层的网络基础设施，保障网络包可以在Pod、节点之间正常传输
• Istio属于服务网格产品，核心职责是做服务治理，比如灰度发布、流量熔断、链路追踪、细粒度权限控制，这些能力是CNI完全不具备的，所谓的功能重叠只是二者都能做部分流量管控动作，实际覆盖场景和实现逻辑差异极大

二者的差异也不止是上层/下层、效率高低的区别：

• CNI的流量管控是网络层维度的，比如网络策略只能基于IP、端口做访问控制，完全感知不到服务、接口、用户这类上层业务属性
• Istio的流量管控是应用层维度的，比如可以按请求头、用户ID、接口路径做流量切分，这类业务侧的管控逻辑CNI完全无法实现

Istio确实有自己的CNI实现，也就是Istio CNI Plugin，但它的作用不是替代底层CNI做网络连通，而是替代原来的Istio init容器，自动给Pod的网络命名空间注入流量拦截规则，把Pod的进出流量转发到Envoy代理，解决init容器需要NET_ADMIN权限的安全隐患，底层仍然依赖集群原有的CNI插件提供基础网络连通能力。

内容的提问来源于stack exchange，提问作者Li Ziyan