0

为什么我们需要 Pod 之间的点对点连接，而我们有工作负载抽象和网络机制（Service/kube-proxy/Ingress 等）？

什么是默认 CNI？
已编辑：我对这个问题感到困惑，因为我在安装 Kubernetes 时感觉自己没有安装任何流行的 CNI 插件。事实证明 Kubernetes 默认为kubenet

顺便说一句，我看到 Istio 和容器网络之间有很多重叠的特性。IMO 他们可以实现相同的目标。唯一的区别是 Istio 是高层，而 CNI 是低层，效率更高，对吗？
已编辑：有趣的是，istio 有自己的 CNI

4

2 回答 2

0

Kubernetes 网络有一些要求：

节点上的 pod 可以与所有节点上的所有 pod 通信，无需 NAT 代理（例如系统守护进程、kubelet） 可以与该节点上的所有 pod 通信 节点主机网络中的 pod 可以与所有节点上的所有 pod 通信，无需NAT

并且 CNI（Container Network Interface）设置了一个标准接口，所有工具（calico，flannel）都需要遵循它。

所以它旨在解决kubernetes网络。

不同的SVC是，它提供了一个虚拟地址来代理pods，正弦pods是短暂的，它的 ip 会改变，但地址svc是不可变的。

对于istio，这是另一回事，它把微服务之间的连接作为基础设施，并将这部分从业务代码中抽出来（想想 Spring Cloud）。

于 2021-09-23T07:36:48.430 回答
0

为什么我们需要 Pod 之间的点对点连接，而我们有工作负载抽象和网络机制（Service/kube-proxy/Ingress 等）？

通常，您会在本文档中找到有关集群中网络的所有信息。您可以找到有关pod 网络的更多信息：

每个Pod都有自己的 IP 地址。这意味着您不需要显式地在它们之间创建链接，Pods并且几乎不需要处理将容器端口映射到主机端口的问题。这创建了一个干净、向后兼容的模型，Pods从端口分配、命名、服务发现、负载平衡、应用程序配置和迁移的角度来看，可以将其视为虚拟机或物理主机。

Kubernetes 对任何网络实现都提出了以下基本要求（除非任何有意的网络分段策略）：

  • 一个节点上的 pod 可以与所有节点上的所有 pod 通信，无需 NAT
  • 节点上的代理（例如系统守护进程、kubelet）可以与该节点上的所有 pod 通信

注意：对于那些支持 Pods 在宿主网络中运行的平台（例如 Linux）：

  • 一个节点的宿主网络中的 pod 可以与所有节点上的所有 pod 通信，无需 NAT

然后你问：

默认cni是什么？

Kubernetes 集群中没有单一的默认CNI。这取决于您遇到的类型、设置集群的位置和方式等。正如您在阅读这篇关于实现网络模型的文档时看到的，Kubernetes 中有许多 CNI 可用。

Istio是一个完全不同的工具。你不能这样比较它们。Istio 是一个服务网格工具。

Istio 扩展了 Kubernetes 以使用强大的 Envoy 服务代理建立一个可编程的、应用感知的网络。Istio 与 Kubernetes 和传统工作负载一起使用，为复杂的部署带来了标准的通用流量管理、遥测和安全性。

于 2021-09-23T08:14:24.060 回答