calico:默认是ip-ip模式， ipip 开销小
vxlan模式：后期版本才支持

不会创建虚拟交换机

Calico 是一种用于构建和管理容器网络的开源软件定义网络（SDN）解决方案。它专门设计用于在容器和虚拟机之间提供高性能、高可扩展性和灵活的网络连接。

Calico 有以下几种模式：

1. 基于扁平网络的模式（Overlay Mode）：在这种模式下，Calico 使用虚拟网络覆盖（overlay）技术来创建虚拟网络层，以跨主机连接容器和虚拟机。它利用网络隧道技术，在底层网络基础设施之上创建一个逻辑网络层，使得容器可以无缝地通信。这种模式适用于跨主机、跨云的场景。由于需要封装和解封装网络包，所以会有一些额外的性能开销。

2. 基于物理网络的模式（Host Gateway Mode）：在这种模式下，Calico 利用主机上的物理网络接口（通常是以太网卡）来直接连接容器和虚拟机。每个容器都会被分配一个唯一的IP地址，并直接与主机的网络接口进行通信。这种模式避免了额外的封装和解封装开销，因此具有较低的延迟和较高的性能。但是，需要物理网络基础设施的支持，因此适用于单机场景。

3. 混合模式（Hybrid Mode）：这是 Calico 的一种混合模式，结合了基于扁平网络和基于物理网络的优点。在混合模式下，可以根据实际需求选择使用 Overlay Mode 或 Host Gateway Mode 来连接容器和虚拟机。这种模式非常灵活，可以根据应用的特点选择合适的网络连接方式。

总体来说，Calico 提供了多种不同的网络模式，可以根据不同的场景和需求选择适合的模式，以满足容器网络的性能、可扩展性和灵活性要求。

在 Calico 中，IPIP（IP in IP）和 VXLAN（Virtual Extensible LAN）是两种常见的 overlay 网络隧道技术，用于在扁平网络模式下实现跨主机的容器和虚拟机的通信。它们的应用场景和区别如下：

1. IPIP 应用场景和区别：

   • 应用场景：IPIP 是一种简单的 overlay 技术，它使用 IP 包封装在另一个 IP 包中进行传输。IPIP 需要两个主机之间的直接连通性，因此适用于较小规模、有限数量的主机集群。它通常用于基于扁平网络的 Calico 部署，当网络环境中不支持 VLAN 或 VXLAN 时，可以选择使用 IPIP 进行跨主机通信。
   • 区别：IPIP 技术将整个 IP 数据包封装在一个新的 IP 数据包中，然后通过底层网络进行传输。由于封装和解封装的开销比较高，会产生一定的性能损耗。因此，IPIP 的性能相对较低，但配置和部署比较简单。

2. VXLAN 应用场景和区别：

   • 应用场景：VXLAN 是一种更为复杂和灵活的 overlay 技术，基于 UDP 协议进行封装和传输。它可以在任何 IP 网络上实现虚拟隔离的虚拟局域网（VLAN）扩展。VXLAN 可以适用于大规模、复杂网络环境下的 Calico 部署，特别是在云计算和跨数据中心的场景中，以实现多租户的隔离和跨主机的容器通信。
   • 区别：VXLAN 技术通过在每个数据包头部添加 VXLAN 标签，将原始 IP 数据包封装在 UDP 数据包中传输。由于封装和解封装过程中需附加额外的 VXLAN 头部信息，因此会引入一些轻微的性能开销。然而，VXLAN 支持更多的虚拟网络标识、更大的扩展性和更灵活的网络拓扑。

总结来说，IPIP 是一种简单且易于部署的 overlay 技术，适用于较小规模的主机集群。VXLAN 是一种更为强大和灵活的 overlay 技术，适用于大规模、复杂的网络环境。选择哪种技术取决于实际的网络需求和限制。

Pod 容器不能够相互 ping 通可以出现在很多可能的原因，以下是排查的步骤和注意事项。

1. 检查网络插件是否正确安装和配置：在 Kubernetes 集群上，需要选择合适的网络插件（如 Calico，Flannel 等）及其实现，配置正确。这是 Pod 网络通信的基础，如果网络插件没有正确安装或者配置错误，则有可能导致容器之间无法正常通信。

2. 检查 Pod 的网络设置是否正确：每个 Pod 都有一个 IP 地址，需要确保每个 Pod 的 IP 地址唯一且不冲突。可以通过 kubectl describe pod [pod-name] 命令查看 Pod 及其容器的网络设置，检查是否存在错误或冲突。

3. 检查容器端口是否正确配置：每个容器都可以暴露不同的端口，以便通过服务进行访问。需要确保容器的暴露端口与服务之间的映射是否正确。

4. 检查服务是否正确配置：如果使用了 Kubernetes 中的服务功能，需要确保服务已正确地配置和部署。可以通过 kubectl get svc 命令查看服务并检查其 IP 地址和端口是否正确。

5. 检查防火墙和网络安全组规则：在某些场景下，防火墙和网络安全组规则也可能会影响容器之间的通信。需要确保防火墙和网络安全组规则已允许 Pod 之间的通信。

6. 检查日志和监控信息：对于问题排查的过程中，需要充分利用 Kubernetes 提供的监控和日志等信息来追踪和分析问题。可以使用 kubectl logs 和 kubectl exec 命令来获取容器的日志和进入容器进行排查。

以上是排查 Pod 容器无法相互 ping 通的一些常见步骤，当然，具体情况需要视实际情况而定。

在Kubernetes（K8s）中，Pause容器是一个特殊的容器，它的作用是维护Pod的IP地址和网络命名空间，并与其他容器共享网络栈。以下是Pause容器的主要作用：

1. 维护Pod的IP地址：K8s中的每个Pod都有唯一的IP地址。Pause容器通过持续运行，保持Pod的网络命名空间和IP地址的稳定性。其他容器将会与Pause容器共享相同的网络命名空间，与Pause容器在同一个网络中。

2. 共享网络栈：Pause容器会在Pod中创建一个网络命名空间，并设置网络栈。其他容器在创建时会与Pause容器的网络命名空间进行关联，共享同一个网络栈。这样，Pod中的容器可以通过localhost进行通信，而无需通过网络。

3. 实现Pod级别的生命周期：Pause容器作为Pod的主容器，在创建和销毁Pod时，它的生命周期控制着整个Pod的生命周期。当Pod被创建时，Pause容器会被首先启动；当Pod被销毁时，Pause容器会最后停止。其他容器的启动和停止都会与Pause容器同步。

需要说明的是，Pause容器本身不承载任何应用程序的功能，它只是维护Pod的网络状态。其目的是为了提供Pod级别的网络隔离，使得在同一个Pod中的容器可以共享同一个网络环境，实现容器间的高效通信。因此，应用程序不应该直接与Pause容器进行交互，而是与其他容器通过网络进行通信。

总之，Pause容器在Kubernetes中起到了维护Pod的网络命名空间和IP地址的重要作用，为同一Pod中的其他容器提供了共享网络环境，促进容器之间的通信。

Kube-proxy有两种模式：iptables和IPVS。

1. iptables模式（默认模式）：在该模式下，kube-proxy使用iptables规则来实现负载均衡和代理。它通过iptables规则将Service的Cluster IP映射到后端Pod的IP，并将流量转发到正确的后端Pod。这是Kubernetes中较早采用的模式，适用于大多数场景。iptables模式具有广泛的兼容性和成熟的稳定性。

2. IPVS模式：从Kubernetes 1.9版本开始，引入了对IPVS（IP Virtual Server）的支持作为Kube-proxy的替代代理模式。IPVS是一个基于内核的负载均衡技术，可以提供更高性能和更丰富的负载均衡算法。在IPVS模式下，kube-proxy使用IPVS规则来实现负载均衡和代理。IPVS模式相对于iptables模式具有更好的性能和弹性，特别是在大规模集群和高并发流量的环境中。

要设置kube-proxy模式，您可以通过编辑配置文件或命令行选项来指定。在Kubeasz等工具中，可以编辑配置文件并重新应用配置来更改模式。默认情况下，kube-proxy将使用iptables模式。如果要使用IPVS模式，可以在相应的配置文件中配置kube-proxy_mode参数为"ipvs"。

需要注意的是，更改kube-proxy模式后，需要重启kube-proxy才能使更改生效。重启kube-proxy的方法因Kubernetes部署方式而异，可以使用kubectl或其他管理工具来删除kube-proxy的Pod，然后Kubernetes会根据新的配置重新创建kube-proxy的Pod，并以指定的模式运行。