为什么我们需要 Pod 之间的点对点连接，而我们有工作负载抽象和网络机制（Service/kube-proxy/Ingress 等）？
什么是默认 CNI？
已编辑：我对这个问题感到困惑，因为我在安装 Kubernetes 时感觉自己没有安装任何流行的 CNI 插件。事实证明 Kubernetes 默认为 kubenet
顺便说一句，我看到 Istio 和容器网络之间有很多重叠的功能。 IMO 他们可以实现相同的目标。唯一不同的是，Istio 是高层，CNI 是低层，效率更高，对吗？
已编辑：有趣的是，istio 有 it's own CNI
【问题讨论】：
标签： kubernetes istio cni
Kubernetes 网络有一些要求：
一个节点上的 Pod 可以在没有 NAT 的情况下与所有节点上的所有 Pod 通信 节点上的代理（例如系统守护进程、kubelet）可以与该节点上的所有 pod 通信 一个节点的宿主网络中的 pod 可以与所有节点上的所有 pod 通信而无需 NAT
和CNI(Container Network Interface)建立了一个标准的接口，所有的工具(calico, flannel)都需要遵循它。
所以它旨在解决kubernetes网络问题。
SVC 不同，它提供了一个虚拟地址来代理pods，正弦pods 是短暂的，它的 ip 会改变，但svc 的地址是不可变的。
对于istio，则是另外一回事，它将微服务之间的连接作为基础设施，并将这部分从业务代码中抽出来（想想spring cloud）。
【讨论】：
SVC的IP是10.96.0.1，后面有两个pod，ip为172.18.0.11和172.18.0.12。然后kube-proxy 将创建iptables（默认模式）规则以在每个node 上创建从10.96.0.1 到172.18.0.11/172.18.0.12 的路由。所以让它工作肯定利用CNI的功能，但对于SVC本身，它只是一个代理
172.18.0.11 的 Pod 会发生什么？那太可怕了
pod会分配一个唯一的ip，所以无论pod实际在哪个节点，这种情况都不会发生
为什么我们需要 Pod 之间的点对点连接，而我们有工作负载抽象和网络机制（Service/kube-proxy/Ingress 等）？
一般来说，您可以在this documentation 中找到有关集群网络的所有信息。你可以找到更多关于pod networking的信息：
每个
Pod都有自己的IP 地址。这意味着您不需要在Pods之间显式创建链接，并且您几乎不需要处理将容器端口映射到主机端口的问题。这创建了一个干净、向后兼容的模型，从端口分配、命名、服务发现、负载平衡、应用程序配置和迁移的角度来看，Pods可以被视为虚拟机或物理主机。Kubernetes 对任何网络实现都提出了以下基本要求（除非任何有意的网络分段策略）：
- 一个节点上的 Pod 可以在没有 NAT 的情况下与所有节点上的所有 Pod 通信
- 节点上的代理（例如系统守护进程、kubelet）可以与该节点上的所有 pod 通信
注意：对于那些支持在主机网络中运行的
Pods的平台（例如Linux）：
- 一个节点的宿主网络中的 Pod 可以在没有 NAT 的情况下与所有节点上的所有 Pod 通信
那么你在问：
什么是默认的 cni？
kubernetes 集群中没有单一的默认 CNI。这取决于您遇到的类型、设置集群的位置和方式等。正如您在阅读this doc about implementing networking model 时看到的那样，Kubernetes 中有许多可用的 CNI。
Istio 是一个完全不同的工具。你不能这样比较它们。 Istio 是一个service mesh 工具。
Istio 扩展了 Kubernetes 以使用强大的 Envoy 服务代理建立一个可编程的、应用感知的网络。 Istio 同时处理 Kubernetes 和传统工作负载，为复杂的部署带来标准的通用流量管理、遥测和安全性。
【讨论】：