kubernetes 概述

一、应用部署方式演变

各有各的优点与缺点，不同场景用不同部署

1.1 前端部署（传统）

没用到虚拟化或者容器就是传统部署，这种部署方式是在物理服务器上直接运行应用程序，无法为物理服务器上的应用程序定义资源边界，容易导致资源分配不均，一个应用程序占用大部分资源，影响其他应用程序的性能

早期，各个组织是在物理服务器上运行应用程序。 由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题

1.2 虚拟化部署

虚拟化技术允许在单个物理服务器上运行多台虚拟机（VM），使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性，通过虚拟化可以将一组物理资源呈现为可丢弃的虚拟机集群

这种部署方式好处是每个虚拟机拥有独立的操作系统和硬件资源，可以合理利用物理服务器的资源，但每个虚拟机需要完整的系统副本和所有硬件的副本，占用大量内存和硬盘空间，运行步骤冗余且速度较慢

1.3 容器部署

容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。 因此，容器比起 VM 被认为是更轻量级的，与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植

这种部署方式好处是容器共享操作系统的内核和硬件资源，不需要完整的系统副本，只需必要的配置，因此占用资源少，启动速度快，且可以跨云和操作系统分发 。

容器化部署方式给带来很多的便利，但是也会出现一些问题
比如说： 一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器。 当并发访问量变大的时候，怎么样做到横向扩展容器数量。 这些容器管理的问题统称为容器编排问题。

为了解决这些容器编排问题，就产生了一些容器编排的软件：

• Swarm：Docker自己的容器编排工具
• Mesos：Apache的一个资源统一管控的工具，需要和Marathon结合使用
• Kubernetes：Google开源的的容器编排工具

二、集群服务

2.1 Iaas 基础设施即服务（阿里、腾讯、七牛）

Iaas - Infrastructure as a Service 基础设施即服务是一种云服务模式：把内存、磁盘、网络、cup 配置好的服务器卖个客户，允许业务通过互联网按需租用计算、存储、网络资源，而不是购买和自行维护物理服务器、数据中心和网络设备

是云服务中最为底层的服务模式，为上层的平台即服务（PaaS）和软件即服务（SaaS）提供了基础支持

2.2 PaaS 平台即服务

Paas - Platform as a Service 平台即服务是一种云计算服务模式：在 Iaas 中驻入平台，用户可以在这个平台上开发、测试、部署和管理应用程序，而无需关注底层的基础设施，类似 k8s，在平台部署应用即可，可做云原生开发，直接在服务器开发（整个过程都在云上面）

系统不需要我们去部署，环境也不需要我们去安装，只需把应用扔进去就可以提供访问

2.3 SaaS 软件即服务

SaaS -Software as a Service，一种将软件部署在云端服务器上，通过互联网向用户提供应用软件服务的模式。用户通常通过订阅的方式，按需支付服务费用，而无需购买、安装和运维软件及相关硬件。

SaaS服务商负责软件的维护、更新和安全保障，使用户能够随时随地通过网络访问最新版本的软件。

三、kubernetes 的介绍

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，方便进行声明式配置和自动化

开源平台，go语言，协程（性能高），运维开发——>go语言

特点

1. 自动化上线和回滚（回滚很丝滑）：Kubernetes 会分步骤地将针对应用或其配置的更改上线，同时监视应用程序运行状况以确保不会同时终止所有实例

2. 服务发现与负载均衡：无需修改应用来使用陌生的服务发现机制。

   Kubernetes 为每个 Pod 提供 了自己的 IP 地址并为一组 Pod 提供一个 DNS 名称，并且可以在它们之间实现负载均衡。

3. 自我修复（nfs：网络文件服务）：重新启动失败的容器，在节点死亡时替换并重新调度容器

4. 存储编排（卷–docker 卷的升级与管理）：自动挂载所选存储系统

5. secret 和配置管理：部署和更新 Secret 和应用程序的配置而不必重新构建容器镜像

6. 编码的方式，用户名和密码通过 base64 进行编码，进而进行存储

7. 自动装箱：根据资源需求和其他限制自动放置容器

8. 批量执行：：除了服务之外，Kubernetes 还可以管理批处理和 CI 工作负载，在期望时替换掉失效的容器。

9. IPv4/IPv6 双协议栈：为 Pod 和 Service 分配 IPv4 和 IPv6 地址

10. 水平扩缩：使用一个简单的命令、一个 UI 或基于 CPU 使用情况自动对应用程序进行扩缩

11. 为扩展性设计

四、kubernetes 架构

Kubernetes 集群由一个控制平面和一组用于运行容器化应用的工作机器组成， 这些工作机器称作节点 （Node）。每个集群至少需要一个工作节点来运行 Pod。

工作节点托管着组成应用负载的 Pod。控制平面管理集群中的工作节点和 Pod。 在生产环境中，控制平面通常跨多台计算机运行，而一个集群通常运行多个节点，以提供容错和高可用。

4.1 控制屏面节点

Control Plane（控制平台组件）会为集群做出全局决策，比如资源的调度，以及检测和响应集群事件。

• kubectl：Kubernetes 集群的客户端管理工具，或者叫命令行端工具，后期所有的命令键入都需要通过这个工具下发给当前的 Kubernetes 集群来完成。
• kube-apiserver：API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开 Kubernetes API，资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制。API 服务器是 Kubernetes 控制平面的前端。
• etcd：一致且高可用的键值存储，由 CoreOS 公司基于 GO 语言且使用 RAFT 协议开发，用作 Kubernetes 所有集群数据的后台数据库。
• kube-scheduler： 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。
• kube-controller-manager：运行控制器来实现 Kubernetes API 行为，负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等。

4.2 节点组件

节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行时环境

• kubelet：会在集群中每个节点（node）上运行。负责维护容器的生命周期，即通过控制 docker 来创建、更新、销毁容器。它保证容器（containers）都运行在 Pod 中。kubelet 接收一组通过各 类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
• kube-proxy：负责提供集群内部的服务发现和负载均衡，是集群中每个节点（node）上所运行的网络代理，实现 Kubernetes 服务（Service） 概念的一部分。kube-proxy 维护节点上的一些网络规则，这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。如果操作系统提供 了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。如果你使用网络插件为 Service 实现本身的数据包转发， 并提供与 kube-proxy 等效的行为，那么你不需要在集群中的节点上运行 kube-proxy。
• 容器运行时：这个基础组件使 Kubernetes 能够有效运行容器。它负责管理 Kubernetes 环境中容器的执行和生命周期。Kubernetes 支持许多容器运行环境，例如 containerd、CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现

五、Pod 概念

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元

Pod是一组容器（一个或多个）；这些容器共享存储、网络、以及怎样运行这些容器的规约。Pod 中的内容总是并置的并且一同调度，在共享的上下文中运行。

除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器 。 可以注入临时性容器来调试正在运行的 Pod。

nginx、redis、mysql 和 php-fpm 、pause 都是运行在 Pod 中的容器

Kubernetes 通过引入 pause 容器，创建了一个共享沙箱环境

5.1 Pause

在 Kubernetes 中，Pause 容器（又叫 Infra 容器）是一种特殊类型的容器，它的主要作用是充当依赖其他容器的容器，为其他容器提供一个可靠的、隔离的运行环境

5.1.1 Pause 简介与特点

Pause 容器是一种轻量级的容器，它本身不包含任何业务逻辑，只是为其他容器提供一个稳定、可靠的运行环境。

Pause 容器的实现基于 Docker 的 pause 镜像，可以在创建其他容器之前将其加载到 Pod 中，以确保 Pod 中的其他容器在 Pause 容器的基础上运行。

• 作用：
  • 是为其他容器提供生命周期的隔离和协调
  • 帮助管理员确保 Pod 中各个容器的启动顺序和依赖关系，避免容器之间的相互干扰和冲突
  • 为 Pod 中的容器提供一个稳定的网络环境，确保容器的网络连接可靠性
    

本身不包含任何业务逻辑（不占用资源=>死亡率低=>为别的容器做一个支撑/依赖）

• 特点：
  1. 镜像非常小
  2. 永远处于 Pause 暂停状态
  3. 是 Pod 内部第一个启动的容器
  4. 回收僵尸进程，已经死了，但占用资源，并且删除不掉
  5. 生命周期与pod容器一样，pod启动，pause容器也一定一起启动；
  6. 每个pod容器里面都必须有pause容器

5.2 通过Docker模拟Pod

5.2.1 创建虚拟机

创建虚拟机教程
创建好虚拟机后编辑虚拟机设置

第一块网络适配器为仅主机模式是为了模拟一种局域网的环境，而第二块网络适配器为NAT 模式主要是为了提供一个外网的支持

5.2.2 安装Redhat9.5

安装系统教程

5.2.3 初始化环境

1. 配置本地仓库

# 1. 配置本地仓库
[root@192 ~]# vi /etc/yum.repos.d/yum.repo
 [root@192 ~]# cat /etc/yum.repos.d/yum.repo 
[BaseOS]
 name=BaseOS
 baseurl=/mnt/BaseOS
 gpgcheck=0
 [AppStream]
 name=AppStream
 baseurl=/mnt/AppStream
 gpgcheck=0
 
 # 2. 配置自动挂载
[root@192 ~]# vi /etc/fstab
 [root@192 ~]# cat /etc/fstab
 ....
/dev/mapper/rhel_192-home /home       xfs   defaults  0  0            
/dev/mapper/rhel_192-swap none        swap  defaults  0  0     
/dev/sr0      /mnt        iso9660 defaults  0  0        

# 3. 验证挂载
[root@192 ~]# systemctl daemon-reload
[root@192 ~]# mount -a
[root@192 ~]# df -h
Filesystem    				 Size  Used Avail Use% Mounted on
devtmpfs       				 4.0M     0  4.0M   0%  /dev
tmpfs          				 1.9G     0  1.9G   0%  /dev/shm
tmpfs          				 777M  9.0M  768M   2%  /run
efivarfs 					 256K   57K  195K  23%  /sys/firmware/efi/efivars
/dev/mapper/rhel_192-root     64G  1.8G   62G   3%  /              
/dev/nvme0n1p2               960M  191M  770M  20%  /boot
/dev/nvme0n1p1               599M  7.1M  592M   2%  /boot/efi
/dev/mapper/rhel_192-home     31G  254M   31G   1%  /home    
tmpfs                        389M     0  389M   0%  /run/user/0
/dev/sr0                      11G   11G     0 100%  /mnt

如果是Rock系统的话，可以修改软件源

 [root@192 ~]# sed -e 's|^mirrorlist=|#mirrorlist=|g' \
 	-e 
's|^#baseurl=http://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.aliyun.com/rockylinux|g' 
	\-i .bak /etc/yum.repos.d/[Rr]ocky*.repo

关闭防火墙和selinux

[root@192 ~]# systemctl disable --now firewalld
Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service".
Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service".
[root@192 ~]# sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
[root@192 ~]# setenforce 0

关闭交换分区

[root@192 ~]# swapoff -a
[root@192 ~]# sed -i 's/.*swap.*/#&/' /etc/fstab

安装基本软件

[root@192 ~]# dnf install net-tools vim wget curl bash-completion -y

修改linux最大连接数

[root@192 ~]# vim /etc/security/limits.conf
 # End of file
*       soft    nofile  655350
*       hard    nofile  655350
*       soft    nproc   655350
*       hard    nproc   655350
*       soft    memlock unlimited
*       hard    memlock unlimited

配置好以上内容后，对虚拟机做好快照

5.2.4 安装Docker

修改仅主机网络适配器IP（修改仅主机网络适配器的IP）

配置宿主机网卡转发

[root@192 ~]# cat > /etc/sysctl.d/docker.conf <<EOF
net.ipv4.ip_forward = 1
EOF
[root@192 ~]# sysctl -p /etc/sysctl.d/docker.conf
net.ipv4.ip_forward = 1

删除旧版本

[root@192 ~]# dnf remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-engine \
                  podman \
                  runc

安装docker仓库

[root@192 ~]# dnf install yum-utils -y
[root@192 ~]# yum-config-manager --add-repo https://mirrors.aliyun.com/dockerce/linux/rhel/docker-ce.repo

安装docker

[root@192 yum.repos.d]# dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

配置docker

[root@192 yum.repos.d]# cat > /etc/docker/daemon.json <<EOF
{
    "default-ipc-mode": "shareable",
    "data-root": "/data/docker",
    "exec-opts": ["native.cgroupdriver=systemd"],
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "100m",
        "max-file": "50"
    },
    "insecure-registries": ["harbor.jock.com"],
	"registry-mirrors":[
		 "https://docker.m.daocloud.io",
		 "https://docker.imgdb.de",
		 "https://docker-0.unsee.tech",
		 "https://docker.hlmirror.com",
		 "https://docker.1ms.run",
		 "https://func.ink",
		 "https://lispy.org",
		 "https://docker.xiaogenban1993.com"
	 ]
}
EOF

启动docker

[root@localhost ~]# systemctl start docker
[root@localhost ~]# systemctl enable docker

5.2.5 基于docker模拟pod

编写一个 nginx 服务器配置文件 nginx.conf

在配置文件中指定了错误日志，同时指定了当前的线程的数量为 1024，监听 80 端口并且是一个默认服务器。反向代理到回环网卡的 2368 端口上

[root@localhost ~]# cat > nginx.conf <<EOF
error_log stderr;
events { worker_connections 1024; }
http {
	 access_log /dev/stdout combined;
	 server {
		 listen 80 default_server;
		 server_name example.com www.example.com;
		 location / {
		 	proxy_pass http://127.0.0.1:2368;
		    }
	    }
	}
EOF

创建并运行 pause 容器

[root@localhost ~]# docker run --name pause -p 8080:80 -d registry.k8s.io/pause:3.10
 6fd088643d24a711dc30847143e21768197262f268fc090748648cb073634461

创建并运行 nginx 容器，同时挂载配置文件

[root@localhost ~]# docker run --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause -d nginx:1.27.4
 5f6c52d69f133eb88bc3c8d053e709b842361afdea20918ff47839ccb90dcdfa

创建并运行 ghost 容器，它是使用 php 语言编写的博客系统

# 1. 创建数据目录
[root@localhost data]# mkdir /opt/ghost
# 2. 为目录设置权限
[root@localhost data]# chmod -R 777 /opt/ghost
# 3. 创建容器
[root@localhost data]# docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause -v /opt/ghost:/var/lig/content -e NODE_ENV=development ghost:latest
90a5b69e509d924f770bdfa6b06efc882afc41f88c605eba7dcf4d579b47f8d4

三个容器都已经运行成功

[root@localhost ~]# docker ps

打开浏览器来访问运行

http://192.168.86.11:8080/

这个博客的代理已经部署完成，而现在这种状态其实我们就可以把它理解为是一个 Pod

Pod 的特性：第一个启动 pause 容器，然后再启动 nginx 容器，nginx 容器与 pause 容器去共享 network、ipc 和 pid，最后启动了 ghost 容器，它也与 pause 共享 network、ipc 和 pid。它们三个在一起就是 Pod 的概念

六、Kubernetes 网络

Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁平的网络空间中（假设有两个 Pod，这两个 Pod 可以通过对方的地址直接去发送数据）

Kubernetes 是为运行分布式集群而建立的，分布式系统的本质使得网络成为 Kubernetes 的核心和必要组成部分

• Kubernetes 中对任何网络实现都规定了以下的一些要求：
  • 所有 Pod 都可以在不使用 NAT 的情况下与所有其他 Pod 进行通信。
  • 所有节点都可以在没有 NAT 的情况下与所有 Pod 进行通信。
  • 每个 Pod 都有自己的IP地址（IP-per-Pod），并且任意其他 Pod 都可以通过相同的这个地址访问它

鉴于这些限制，需要解决几个不同的网络问题：

1. 容器到容器的网络
2. Pod 到 Pod 的网络
3. Pod 到 Service 的网络
4. 互联网到 Service 的网络

6.1 CN（容器网络的 API 接口）

Kubernetes 本身并没有实现自己的容器网络 ，而是借助 CNI 标准，通过插件化的方式来集成各种网络插件 ，实现集群内部网络相互通信

CNI 旨在为容器平台提供网络的标准化，为解决容器网络连接和容器销毁时的资源释放，提供了一套框架。所以 CNI 可以支持大量不同的网络模式，并且容易实现。不同的容器平台（e.g. Kubernetes、Mesos 和 RKT）能够通过相同的接口调用不同的网络组件，解决容器网络问题

CNI 接口是指对可执行程序的调用（exec），
Kubernetes 节点默认的 CNI 插件路径为 /opt/cni/bin

6.1.1 CNI 分类

6.1.2 CNI 作用

大部分的 CN I插件功能设计上遵守功能职责单一原则，比如：

• Bridge 插件负责网桥的相关配置；
• Firewall 插件负责防火墙相关配置；
• Portmap 插件负责端口映射相关配置。

因此，当网络设置比较复杂时，通常通过调用多个插件来完成。CNI 通过链式调用多个插件，将多个插件组合起来按顺序调用。

6.1.3 第三方插件

CNI 第三方网络插件通常有 3 种实现模式：

1. Overlay：靠隧道通，不依赖底层网络；
2. Underlay：靠底层网络打通，强依赖底层网络；
3. 路由：靠路由打通，部分依赖底层网络；
   
   常见的第三方网络插件：

• Calico（性能好、灵活性最强，目前的企业级主流）：是一个基于 BGP 路由协议的纯 L3 的数据中心网络方案（不需要 Overlay），提供简单，可扩展的网络。除了可扩展的网络， Calico 还提供策略隔离。
• Flannel（最成熟、最简单的选择）：基于 Linux TUN/TAP，使用 UDP 封装 IP 数据包的方式来创建 Overlay 网络，并借助 etcd 来维护网络资源的分配情况，是一种简单易用的 Overlay 网络方案。
• Weave：支持多主机容器网络，可以跨越不同的云网络配置。独有的功能，是对整个网络的简单加密，会增加网络开销。
  Cilium：是一个开源软件，基于 Linux Kernel BPF 技术，可以在 Linux Kernel 内部动态地插入具有安全性、可见性的网络控制逻辑。
• kopeio-networking：是专为 Kubernetes 而设计的网络方案，充分利用了 Kubernetes API，因此更简单，更可靠。
• kube-router：也是专为 Kubernetes 打造的专用网络解决方案，旨在提供操作简单性和性能。

6.2 calico

Calico 是一个开源的网络及网络安全解决方案，主要用于容器、虚拟机、基于本地主机的工作负载之间的网络连接；适用于需要高性能、高可扩展性和安全性的容器网络应用场景
支持的平台包括 Kubernetes、OpenShift、Mirantis Kubernetes Engine （MKE）、OpenStack 以及裸机服务

Calico 是一个纯三层的虚拟网络，它没有复用 docker 的 docker0 网桥，而是自己实现，Calico 网络不对数据包进行额外封装，不需要 NAT 和端口映射

6.2.1 Calico 特点

Calico 的主要特点如下：

• 支持多种数据层，包括 Linux eBPF、Linux 标准网络和 Windows HNS。
• 具有丰富的网络策略模型可以轻松锁定需要的通信流量，还内置支持 Wireguard 加密，为 Pod 之间的流量提供保护。
• 可以使用 Linux eBPF 或 Linux 标准网络来提供高性能网络。Calico 可以在大多数环境中运行而无需使用覆盖网络，从而避免了数据包封装/解封的开销，其控制平面和策略引擎可以最大限度地降低整体 CPU 使用率。
• 具备良好的可扩展性。
• 支持 Kubernetes 工作负载与非 Kubernetes 或传统工作负载无缝、安全地通信，所有工作负载都受相同的网络策略模型的约束。
• 持完整的 Kubernetes 网络策略，与 Kubernetes API 无缝协作，使用户能够更灵活地定义网络策略。

6.2.2 Calico 架构

Calico 的核心组件如下：

• Felix：运行在每个节点的代理程序，主要负责网络接口监听、路由信息管理、ARP 信息管理、ACL 规则管理、上报节点网络状态、创建 Calico 虚拟网络设备（如 tunl0、vxlan.calico）。
• ETCD：存储集群中节点的所有路由信息，确保网络元数据的一致性、Calico 网络状态的准确性，可以与 Kubernetes 共用。
• BIRD：BGP 客户端，作用是监听并将 Felix 的路由信息读入内核，并通过 BGP 协议在集群节点中广播分发，实现网络互通。BIRD 支持的路由协议包括 BGP、OSPF、RIP 等。
• BGP Route Reflector：使所有 BGP 客户端仅与特定的 Route Reflector（路由反射）节点互联，并进行路由同步以减少连接数，可以解决大型网络下的节点规模问题。
• Confd：通过监听 ETCD 以了解 BGP 配置和全局默认值的更改，Confd 根据 ETCD 中数据的更新，动态生成 BIRD 配置文件。当配置文件更改时，Confd 触发 BIRD 重新加载新文件

6.2.3 VXLAN 模式-虚拟可扩展局域网

是 Linux 本身支持的一网种网络虚拟化技术。VXLAN 可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制构建出覆盖网络

VXLAN 模式是基于三层的“二层”通信
层即 VXLAN 封装在 UDP 数据包中，要求 UDP 在 K8S 节点间三层可达。二层是指 VXLAN 封包的源 MAC 地址和目的 MAC 地址是自己端的 VXLAN 设备 MAC 和对端 VXLAN 设备 MAC 实现通讯。因此，这类通讯原理是基于 MAC 地址的寻址去实现的，三层只不过是跨节点通讯的一种手段

VXLAN 模式的 Calico 会为每个 Node 节点创建一个 vxlan.calico 接口，作为隧道出入口设备，用来封装 VXLAN 数据报文，Pod 间的通信经由 VXLAN 的三层隧道进行转发

• 数据联通图
  
• 底层的封包的逻辑
  

右边蓝色部分叫原始报文，负载就是报文本身，也就是承载的真实数据段。在外层是 IP 头部，包括以太网头部。右边是一旦进入 vxlan 设备以后封装的结果，也就是原始报文前面加上一个 vxlan 封装包头，有 vxlan 头部标记，有 udp 头部标记，IP 头部标记，最后是以太网头部标记。需求注意的是：vxlan 封装的是自己的 vxlan 的 Mac 信息和对方 vxlan 的 Mac 信息，从而去实现跨节点间的连接通讯。
VXLAN 模式的 Calico 会将数据报文的源 MAC 地址和目的 MAC 地址，分别替换为本机 VXLAN 网卡和目的节点 VXLAN 网卡的 MAC 地址，外层 UDP 网络报文的目的 IP 地址将根据路由及目的节点 VXLAN 的 MAC 查 FDB（MAC 地址与 IP 地址对应关系表）表获取。所以是通过 UDP 实现跨节点传递，再通过 VXLAN 封包的 MAC 信息进行通信，所以叫基于三层的二层实现。

如果想在 Calico 中开启 VXLAN 网络模式，需要打开 Calico 的部署文件，然后找到如下内容配置位置并参照如下进行修改。

......
# Enable IPIP
- name: CALICO_IPV4POOL_IPIP
  value: "Never"
# Enable or Disable VXLAN on the default IP pool.
- name: CALICO_IPV4POOL_VXLAN
  value: "Always"
# Enable or Disable VXLAN on the default IPv6 IP pool.
- name: CALICO_IPV6POOL_VXLAN
  value: "Always"
......
# calico_backend: "bird"
 calico_backend: "vxlan"
.....

还需要将启动命令中的如下两个选项进行注释，由于采用了 vxlan 模式而不是采用网桥模式，因此不需要对网桥进行存活探测和就绪探测

# --bird-live
# --bird-ready
如果需要验证配置是否生效，可以执行如下命令来查看
[root@master ~]# ifconfig vxlan.calico
如果能够看到有 vxlan.calico 则表示已经开启成功，或者使用 calicoctl 命令来查看状态
[root@master ~]# calicoctl node status

6.2.4 IPIP 模式

IPIP（IP in IP）模式是 Linux 原生内核就支持的一种模式

IPIP 隧道的工作原理是：
将源主机的 IP 数据包封装在一个新的 IP 数据包中，新的 IP 数据包的目的地址是隧道的另一端。在隧道的另一端，接收方将解封装原始 IP 数据包，并将其传递到目标主机。IPIP 隧道可以在不同的网络之间建立连接
例如在 IPv4 网络和 IPv6 网络之间建立连接。

IPIP 模式下的每个数据报文都有两个 IP 网络层，内层是 Pod 容器之间的 IP 网络报文，外层是 Node 节点之间的网络报文

IPIP 模式下的 Calico 会为每个 Node 节点创建一个 tunl0 接口，作为隧道出入口设备，用来封装 IPIP 数据报文，Pod 间的通信经由 IPIP 的三层隧道进行转发。

如果想在 Calico 中开启 IPIP 网络模式，需要打开 Calico 的部署文件，然后找到如下内容配置位置并参照如下进行修改

......
# Enable IPIP
- name: CALICO_IPV4POOL_IPIP
  value: "Always"
# Enable or Disable VXLAN on the default IP pool.
- name: CALICO_IPV4POOL_VXLAN
  value: "Never"
# Enable or Disable VXLAN on the default IPv6 IP pool.
- name: CALICO_IPV6POOL_VXLAN
  value: "Never"
......

验证配置是否生效，执行如下命令来查看。

[root@master ~]# ifconfig tunl0
如果能够看到有 tunl0 则表示已经开启成功。或者使用 calicoctl 命令来查看
[root@master ~]# calicoctl node status

IPIP 模式需要 BGP 来建立节点间的邻接关系，VXLAN 不需要

6.2.5 BGP 模式

动态路由模式（Dynamic Routing）采用 BGP 路由协议

BGP（Border Gateway Protocol, 边界网关协议）是一种基于策略的域间路由协议，它通过维护 IP 路由表或 ‘前缀’ 表来实现自治系统（AS）之间的可达性，属于矢量路由协议

如果想在 Calico 中开启 BGP 网络模式，需要打开 Calico 的部署文件，然后找到如下内容配置位置并参照如下进行修改

......
# Enable IPIP
- name: CALICO_IPV4POOL_IPIP
  value: "Off"
# Enable or Disable VXLAN on the default IP pool.
 - name: CALICO_IPV4POOL_VXLAN
   value: "Never"
# Enable or Disable VXLAN on the default IPv6 IP pool.
 - name: CALICO_IPV6POOL_VXLAN
   value: "Never"
......

如果需要验证配置是否生效，执行如下命令来查看

[root@master ~]# calicoctl get ippool -o wide --allow-version-mismatch
[root@master ~]# calicoctl get node -o wide --allow-version-mismatch

或者：

[root@master ~]# calicoctl node status

如果能够看到 IPv4 BGP status 则表示配置成功