k8s基础概念和组件介绍

k8s涉及到的概念和组件介绍

Kubernetes（简称 k8s）是一个开源的容器编排系统，由 Google 开发并于 2014 年开源，后捐赠给云原生计算基金会（CNCF）。它用于自动化应用程序的部署、扩展和管理，特别是在容器化环境中，已成为业界容器编排的事实标准。它通过自动化、弹性和自我修复能力，简化了容器化应用的部署和管理。无论是小型创业公司还是大型企业，k8s 都能帮助团队更高效地构建、扩展和维护应用程序，是云原生时代的核心基础设施。

1、核心概念

1.1、容器（Container）

• 轻量级、可移植的应用运行环境，打包了应用代码、依赖库、配置文件等，确保应用在不同环境中一致运行。
• 基于Linux内核的namespace和cgroup实现资源隔离，比虚拟机（VM）更轻量（共享宿主机内核）。

关键特性

• 隔离性：资源（CPU、内存）和文件系统隔离。
• 快速部署：秒级启动，无需启动完整操作系统。
• 环境一致性：开发、测试、生产环境一致。

一个独立的小型“集装箱”，内部运行一个应用进程（如 Nginx、MySQL）。

就好比货运集装箱，标准化封装，不依赖运输工具。

一个Python Web应用可打包为容器，包含Python解释器、Flask框架和应用代码。

1.2、Pod

Kubernetes 最小调度、可部署单元，像一个“逻辑主机”，包含：

• 1个或多个紧密关联的容器（如主容器+日志收集 sidecar 容器）。
• 同一Pod内的容器运行在同一节点上，可通过localhost通信，共享Volume存储。
• 共享的网络命名空间（同一个 IP 地址）。
• 共享的存储卷（Volumes）。

关键特性

• 原子调度：Pod作为整体被调度到节点，不可拆分；将多个容器作为单一实体管理（同生共死、同节点部署）。
• 生命周期短暂：失败后会被重建，但IP可能变化（依赖Service保持稳定访问）。
• 生命周期：临时存在（被删除后不可恢复）。

就好比合租公寓（多个租户共享客厅、网络，但有独立卧室）。

应用场景

• 单容器Pod：最常见的形式，基本上每个Pod只运行一个容器。
• 多容器Pod：用于那些紧密相关且需要共享资源的容器之间进行协作的情况。

一台“微型服务器”，上面运行一组需要直接通信的服务（如 Web 服务 + 日志代理）。

为什么需要 Pod？

答案：解决容器间紧密协作问题（例如：Web 容器和日志收集容器需共享日志目录）。

1.3、服务 (Service)

为一组Pod提供稳定的网络访问接口，屏蔽Pod的动态变化（如IP变更、扩容缩容）。

关键特性

• 服务发现：为动态变化的 Pod 提供固定访问地址（DNS 名称或虚拟 IP）。
• 负载均衡：将请求自动分发到后端多个 Pod。

关键类型

• ClusterIP：集群内部访问的虚拟 IP（默认类型）。
• NodePort：通过节点 IP + 端口暴露服务（可从集群外访问）。
• LoadBalancer：云厂商提供的负载均衡器（如如AWS ELB，自动分配公网 IP）。
• ExternalName：将服务映射到外部 DNS 名称（如访问 my-db 实际指向 rds.aws.com）。

就好比一个“前台接待处”，无论后端 Pod 如何变化（扩缩容、重启），访问者只需找这个固定入口。

1.4、部署（Deployment）

声明式的Pod控制器，定义Pod的期望状态（如副本数、镜像版本），自动管理Pod的生命周期。

管理无状态应用（如 Web 服务）。

• 副本集（ReplicaSet）：确保在任何给定时间运行指定数量的Pod副本。

核心能力

• 水平扩缩容：通过 kubectl scale 调整Pod副本数，或声明 Pod 副本数（如始终维持 3 个 Nginx Pod）。
• 滚动更新/回滚：逐步替换旧版本Pod，确保服务不中断（分批替换 Pod 版本），出错时可快速回退到上一版本。
• 故障自愈：自动重启失败容器：。

就好比 自动生产线（按模板复制产品，坏了自动替换）。

1.5、StatefulSet

管理有状态应用（如 MySQL、Redis）。

特点

• Pod 名称固定且有序（mysql-0, mysql-1）。
• 持久化存储（每个 Pod 绑定独立 Volume）。
• 稳定的网络标识（mysql-0.mysql-svc.default.svc.cluster.local）。

1.6、DaemonSet

在每个节点上运行一个 Pod（如日志收集 agent、网络插件）。

1.7、Job & CronJob

运行一次性任务（Job）或定时任务（CronJob）。

Job

创建一个或多个Pod执行一次性任务，任务完成后Pod终止。

CronJob

定时任务，基于Cron表达式周期性执行Job（如每天凌晨备份数据库）。

使用场景

• Job：批量数据处理、一次性脚本执行。
• CronJob：定时备份、数据同步。

1.8、ConfigMap & Secret

• ConfigMap：存储应用的配置文件，主要是存储非敏感配置信息（如环境变量、配置文件、nginx.conf等）。
• Secret：存储敏感数据，以 Base64 编码存储，主要是存储敏感信息（如密码、证书），加密存储在etcd中。
• 使用方式：挂载到 Pod 中作为文件或环境变量。

示例场景

• ConfigMap存储数据库连接地址，Secret存储数据库密码。

1.9、Volume (存储卷)

为 Pod 提供持久化存储（即使 Pod 重启数据不丢失），解决容器生命周期短暂导致的数据丢失问题。

就好比 网盘一样，数据独立于容器，可挂载到不同容器。

关键特性

• 生命周期分离：Volume的生命周期可独立于Pod。
• 共享存储：同一Volume可被多个容器挂载。

支持类型

• emptyDir：临时目录（Pod 删除后消失）。
• PersistentVolume (PV)：集群级存储资源（网络存储，如云硬盘、NFS）。
• PersistentVolumeClaim (PVC)：用户对存储资源的“申请”（如申请 10Gi 空间）。
• HostPath：节点本地存储。

示例场景

• 数据库持久化：MySQL容器挂载PersistentVolume，确保数据不随Pod重启丢失。

1.10、Namespace

将集群划分为虚拟子集群（如 dev/prod），实现资源隔离。

虚拟集群，用于隔离和划分资源，避免命名冲突，适用于多团队、多环境（开发/测试/生产）的资源隔离。

就好比公司部门（不同部门使用独立资源，避免名称冲突）。

默认命名空间：default、kube-system（系统组件）、kube-public。

默认Namespace

• default：未指定Namespace的资源默认归属。
• kube-system：K8s系统组件（如CoreDNS）所在的Namespace。

使用场景

• 开发团队使用dev Namespace，生产环境使用prod Namespace。

1.11、Ingress

管理外部访问集群内服务的 HTTP/HTTPS 路由（如根据域名分流流量）。

需要配合 Ingress Controller（如 Nginx、Traefik）实现。

核心功能

• 域名路由：根据域名将请求转发到不同Service。
• 路径匹配：如/api/*转发到API Service，/web/*转发到Web Service。
• SSL/TLS终止：处理HTTPS证书。

就好比公司前台（根据访客需求引导至不同部门）。

1.99、实际例子

假设部署一个 Web 应用：

1. 容器：封装你的 Python 应用代码。
2. Pod：包含 Python 容器 + 一个日志收集的 Sidecar 容器。
3. Deployment：声明需要运行 3 个该 Pod 副本。
4. Service：创建 ClusterIP 服务，为这组 Pod 提供内部访问地址。
5. Ingress：配置规则 myapp.com → 指向该 Service。
6. ConfigMap：存储应用配置文件（如数据库地址）。
7. PersistentVolume：为上传文件提供持久化存储。

2、节点介绍

在Kubernetes集群中，节点（Nodes）是物理机或虚拟机，它们作为运行容器化应用的工作单元。每个节点都包含一些关键组件，以确保容器化应用能够在该节点上正确运行，并与集群的其他部分通信。

Kubernetes集群通常由两种类型的节点组成：

• 主节点（Master Node）：负责管理（调度、API 服务、状态存储）集群状态和做出全局决策，常部署多节点实现高可用（HA）。
• 工作节点（Worker Node）：运行实际的应用容器（Pod），通过 Kubelet 与控制平面通信，执行具体工作负载。

2.1、主节点（Master Node）

也称控制平面节点（Control Plane Node）。

通常由多个节点组成以实现高可用（生产环境建议至少 3 个）。

下面罗列主要包含的组件。

2.1.1、kube-apiserver

Kubernetes API服务器是集群的前端接口，所有外部访问和内部组件之间的通信都要通过它进行。

它是唯一可以直接访问etcd数据库的组件，用于验证并配置API对象的数据。

角色

K8s 的统一入口，所有组件间的通信枢纽。

功能

• 提供 RESTful API，处理用户请求（如创建 Pod、Service）。
• 验证请求合法性，维护集群状态到 etcd。

部署方式

通常部署为负载均衡器后面的多个实例（高可用）。

2.1.2、etcd

分布式键值存储，用作保存Kubernetes集群所有状态数据的后台数据库。提供可靠的数据持久化存储机制。

如 Pod、Service 配置等等。

角色

分布式键值存储，存储集群的所有配置数据和状态。

功能

• 持久化存储资源定义（如 Pod、Service）、集群元数据。
• 基于 Raft 协议实现多节点数据一致性。

注意事项

需定期备份，建议部署奇数个节点（如 3、5）以保证选举稳定性。

2.1.3、kube-scheduler

监视新创建且未分配节点的Pod，并根据资源需求、服务质量要求等因素选择最合适的节点为其提供服务。

角色

负责将 Pod 调度到合适的 Worker 节点。

功能

• 根据资源需求、节点亲和性、污点 / 容忍度等策略选择节点。
• 支持优先级和抢占机制（高优先级 Pod 可驱逐低优先级 Pod）。

2.1.4、kube-controller-manager

包含多种控制器，这些控制器负责特定的任务，如节点控制器、副本集控制器等，它们监控集群状态，并努力将当前状态向期望状态推进。

运行所有控制器的守护进程，确保集群状态与期望一致。

角色

运行各种控制器，确保集群状态符合期望。

核心控制器

• Node Controller：监控节点状态，处理节点故障。
• ReplicaSet Controller：维护 Pod 副本数，自动创建 / 删除 Pod。
• Deployment Controller：管理 Deployment 的滚动更新和回滚。
• Service Controller：维护 Service 与 Endpoint 的映射关系。

2.1.5、cloud-controller-manager

是可选组件服务，根据情况选择，非必须部署。

对接云厂商 API（如 AWS/GCP），实现节点管理、负载均衡等云服务集成。

角色

对接云服务商 API（如 AWS、GCP），管理云资源。

功能

• 创建云负载均衡器（如 ELB）、存储卷（如 EBS）。
• 实现节点与云基础设施的集成。

2.2、工作节点（Worker Node）

运行容器化应用的节点，由控制平面管理。一个集群可以有数十至数千个工作节点。

工作节点是运行应用的 “执行单元”。

下面罗列主要包含的组件。

2.2.1、kubelet

每个工作节点上的代理，确保容器在Pod中健康地运行。它定期采集所在节点及节点上容器的状态信息，并上报给API服务器。

负责接收 PodSpec 并启动容器，监控容器状态并上报。

与容器运行时（如 containerd）交互，执行存活/就绪探针。

角色

节点上的代理，负责 Pod 的生命周期管理。

功能

• 从 API Server 接收 Pod 定义，通过容器运行时启动容器。
• 监控 Pod 健康状态，上报节点和 Pod 状态到 API Server。
• 执行 Volume 挂载、容器健康检查等操作。

2.2.2、kube-proxy

每个节点上的网络代理，维护网络规则以允许跨节点的服务通信。支持TCP、UDP和SCTP连接的转发。

维护节点网络规则，实现 Service 的 负载均衡 和 网络代理。

• 支持 iptables/ipvs 模式
• 处理 ClusterIP → Pod IP 的流量转发

角色

实现 Service 的网络代理和负载均衡。

功能

• 在节点上维护网络规则（如 iptables 或 IPVS），将 Service 流量转发到 Pod。
• 支持集群内部和外部的服务发现（如通过 ClusterIP 或 NodePort 访问 Service）。

2.2.3、Container Runtime

实际运行容器的引擎（如 Docker、containerd、CRI-O）。

必须实现 CRI（容器运行时接口）。

运行容器的软件，负责镜像拉取、容器生命周期管理等。

角色

负责容器的创建和运行。

常见实现

• containerd：K8s 官方推荐，轻量级、高性能。
• CRI-O：专为 K8s 设计的容器运行时。
• Docker：需通过cri-dockerd适配器与 K8s 集成（旧版方案）。

2.2.4、网络插件（CNI）

角色

实现 Pod 间的网络通信，提供集群网络。

常见插件

• Calico：基于 BGP 的三层网络，支持网络策略。
• Flannel：简单的覆盖网络（Overlay Network）。
• Canal：Calico（网络策略）+ Flannel（网络连通性）的组合。

2.2.5、存储插件（CSI）

角色

为 Pod 提供持久化存储。

常见实现

• AWS EBS CSI Driver：对接 AWS 弹性块存储。
• NFS CSI Driver：挂载 NFS 共享存储。
• Ceph CSI Driver：集成 Ceph 分布式存储。

2.2.6、附加组件（Add-ons）

以下组件通常作为集群插件部署，不属于核心组件但提供重要功能：

CoreDNS

• 功能：为集群提供 DNS 服务，解析 Service 名称到 IP 地址。
• 部署方式：作为 Pod 部署在集群中，通常位于kube-system命名空间。

Ingress Controller

• 功能：管理外部流量进入集群，实现 HTTP/HTTPS 路由。
• 常见实现
  • Nginx Ingress Controller：基于 Nginx 的高性能负载均衡器。
  • Traefik：轻量级、支持自动 TLS 证书。

监控与日志组件

• Prometheus + Grafana：收集和可视化集群指标（如 CPU、内存使用）。
• EFK Stack（Elasticsearch + Fluentd + Kibana）：集中管理容器日志。

容器网络策略（NetworkPolicy）

• 功能：基于标签定义 Pod 间的流量访问规则，增强网络安全性。
• 依赖网络插件：如 Calico、Cilium 等支持 NetworkPolicy 的实现。

2.3、组件间通信逻辑

控制平面内部

• 所有组件通过 API Server 通信（如 Scheduler 从 API Server 获取未调度的 Pod）。
• etcd 作为后端存储，仅由 API Server 直接读写。

控制平面与工作节点

• ubelet 定期向 API Server 上报节点和 Pod 状态。
• API Server 通过 Kubelet 下发 Pod 调度任务。

工作节点内部

• Kubelet 通过 CRI 接口与容器运行时交互（如创建容器）。
• Kube Proxy 从 API Server 获取 Service 信息，更新本地网络规则。

节点间通信关键路径

通信方向	协议/端口	用途
Master → Worker	6443 (API Server)	kubelet/kube-proxy 访问 API Server 获取指令
Worker → Master	2379-2380 (etcd)	仅控制平面节点间 etcd 集群通信（Worker 不直接访问 etcd）
Worker ↔ Worker	VXLAN/Calico	Pod 跨节点通信（通过 CNI 插件）
kubelet ↔ API Server	10250 (HTTPS)	API Server 主动访问 kubelet 获取日志/执行命令

3、常用的工具

在Kubernetes生态系统中，有多种工具可以帮助用户更高效地部署和管理集群。

3.1、kubeadm

kubeadm是一个用于快速部署Kubernetes集群的工具。它简化了创建一个安全的Kubernetes集群的过程。

官方推荐的集群快速部署工具，适合新手和测试环境。

核心功能

• 初始化 Master 节点（kubeadm init）
• 加入 Worker 节点（kubeadm join）
• 升级集群版本（kubeadm upgrade）

特点

• 提供了简单的命令行界面来启动和管理集群。
• 支持高可用性（HA）集群的设置（需额外配置负载均衡）。
• 能够自动处理证书生成、配置组件清单等安全相关的任务。
• 默认使用 containerd 作为容器运行时。

使用场景

• 初始化一个新的Kubernetes主节点
• 将工作节点加入现有的集群
• 升级集群版本

示例命令

# 初始化控制平面
kubeadm init --pod-network-cidr=192.168.0.0/16

# 初始化 Master
kubeadm init --apiserver-advertise-address=192.168.1.100 \
             --pod-network-cidr=10.244.0.0/16

# Worker节点加入集群
kubeadm join <控制平面IP>:6443 --token <令牌> --discovery-token-ca-cert-hash <哈希值>

# 加入 Worker
kubeadm join 192.168.1.100:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

3.2、kubectl

kubectl是与Kubernetes集群进行交互的命令行工具。它允许用户直接从命令行运行命令来部署应用、检查和管理集群资源以及查看日志。

kubectl主要用于开发人员或运维人员手动管理Kubernetes集群时使用。通过本地安装kubectl，用户可以方便地从命令行与远程Kubernetes集群交互。

核心功能

• 资源创建 / 删除/查看Pod、Deployment 等（如kubectl create deploy、kubectl delete pod）。
• 状态查看（如kubectl get nodes、kubectl describe pod）。
• 日志和集群调试（日志、执行命令、端口转发，如kubectl logs、kubectl exec）。
• 配置管理（应用 YAML 文件，如kubectl apply -f config.yaml）。

使用场景

• 部署应用程序和服务
• 检查集群状态和资源
• 管理配置和机密信息
• 查看和分析日志

可以通过官方文档提供的步骤轻松安装到本地机器上，并通过配置文件连接到你的Kubernetes集群。

常用命令

# 查看集群状态
kubectl get nodes -o wide

# 查看Pod列表
kubectl get pods -o wide

# 部署应用
kubectl apply -f deployment.yaml

# 进入容器调试
kubectl exec -it <pod-name> -- /bin/bash

# 查看日志
kubectl logs -f <pod-name>

# 创建Deployment
kubectl create deployment nginx --image=nginx

# 暴露Service
kubectl expose deployment nginx --port=80 --type=NodePort

插件生态

• kubectl-ctx/kubectl-ns：快速切换上下文和命名空间
• kubectl-tree：可视化资源依赖关系

3.3、kubelet

运行在每个节点上的代理组件，直接管理容器。

kubelet是部署在每个节点（Node）上的主要“节点代理”，它确保容器在Pod中健康地运行。kubelet会定期采集所在节点及节点上容器的状态信息，并上报给Kubernetes的API服务器。

核心职责

• 监控分配给节点的Pod

• 确保容器在Pod中正常运行

• 向API服务器报告状态更新

• 响应来自控制平面的命令（例如，根据调度器的决定启动新的容器）

• 维护容器的生命周期（启动、停止容器等）

• 监听 API Server 下发的 PodSpec

• 调用容器运行时（如 containerd）启动容器

• 定期上报节点状态到控制平面

使用场景

kubelet运行在集群中的每个节点上，不需要用户直接操作，它是自动安装和配置的一部分。

关键配置

• /var/lib/kubelet/config.yaml：kubelet 配置文件
• --cgroup-driver=systemd：需与容器运行时一致

3.4、kubectl与kubelet

主要区别

• 服务对象：kubelet服务于Kubernetes集群内部，负责节点级别的容器管理；而kubectl则是为用户提供了一个界面来管理和操作Kubernetes集群。

• 部署位置：kubelet部署在Kubernetes集群的每个节点上，而kubectl通常安装在用户的本地机器上或CI/CD环境中，用于与集群进行交互。

• 操作层面：kubelet关注的是节点级别、容器级别的操作，保证分配给该节点的任务正确执行；kubectl则允许用户执行集群范围的操作，如部署应用、扩展副本集等。

3.5、Helm

Helm是Kubernetes的包管理器，它简化了查找、共享和使用Kubernetes应用的过程。通过Helm Charts，可以方便地定义、安装和升级复杂的Kubernetes应用。

Kubernetes 包管理工具（类似 yum/apt），用于简化复杂应用的部署。

核心概念

• Chart：应用的打包模板（如 MySQL、WordPress）。
• Values：参数化配置，支持环境变量注入。
• Release：Chart 的实例化部署。

使用场景

• 快速部署复杂的应用架构
• 管理应用的不同版本
• 分享和复用已有的应用配置

示例命令

# 安装官方仓库的Nginx Chart
helm repo add stable https://charts.helm.sh/stable
helm install my-nginx stable/nginx

# 安装应用
helm install my-mysql bitnami/mysql

# 自定义配置部署
helm install my-mysql stable/mysql -f values.yaml

# 添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami

# 查看已安装应用
helm list

4、网络插件

在Kubernetes中，网络插件对于实现容器间的通信至关重要。由于Kubernetes本身并没有强制规定具体的网络实现方式，而是提供了一套CNI（Container Network Interface）规范，允许第三方网络插件来实现具体的网络功能。

为什么需要网络插件？

答：

Kubernetes 要求集群满足以下网络模型：

• Pod 间直接通信：所有 Pod 无需 NAT 即可跨节点互通。
• Service 虚拟 IP：通过 kube-proxy 实现 Service 到 Pod 的负载均衡。
• 网络策略：支持按规则隔离 Pod 间流量（NetworkPolicy）。

网络插件（CNI 插件）负责实现这些需求，主要解决：

• 跨节点 Pod 通信（Overlay/Underlay 网络）
• IP 地址管理（IPAM）
• 网络策略 enforcement

网络插件核心功能

Pod 网络

• 为每个 Pod 分配唯一 IP 地址，实现跨节点通信。
• 支持 “扁平网络” 模型（Pod 可直接通过 IP 互访）。

网络策略（NetworkPolicy）

• 基于标签定义 Pod 间的流量访问规则（如允许 / 拒绝特定端口）。
• 增强集群安全性，实现微隔离（Microsegmentation）。

服务发现与负载均衡

• 配合 Kube Proxy 实现 Service 的网络代理和流量分发。

主流网络插件分类

• 覆盖网络（Overlay Network）：通过隧道技术（如 VXLAN）在现有网络上构建虚拟网络。

  代表插件：Flannel、Weave Net等

• 三层网络（BGP-Based）：基于路由协议（如 BGP）实现 Pod 网络，无需隧道，性能更高。

  代表插件：Calico等

• 混合方案：结合覆盖网络和三层网络的优势。

  代表插件：Cana等

• 云原生方案：与云服务商深度集成的网络插件。

  代表插件：AWS VPC CNI、GKE GKE Networking

• 高性能方案：专为高性能场景优化的网络插件。

  代表插件：Cilium等

网络插件对比

特性	Flannel	Calico	Canal	Cilium	Weave Net
网络模式	覆盖	三层	混合	eBPF	覆盖
NetworkPolicy 支持	❌	✅	✅	✅	✅
性能	低	高	中	极高	中
部署复杂度	低	中	中	高	低
策略丰富度	无	L3-L4	L3-L4	L3-L7	L3-L4
大规模集群支持	一般	优秀	良好	优秀	一般

以下是几款流行的Kubernetes网络插件介绍：

4.1、Flannel

Flannel是由CoreOS开发的一个简单易用的覆盖网络（Overlay Network）解决方案。它通过为每个节点分配一个子网，并在节点间转发封装的数据包来实现跨主机的容器通信。

工作原理

• 使用 VXLAN 封装跨节点 Pod 流量。
• 每个节点分配一个子网（IPAM 由 host-local 实现）。

特点：轻量级、易部署，支持多种后端（VXLAN、UDP、host-gw）。

不足：缺乏网络策略支持，性能一般，仅支持基本连通性（不支持 NetworkPolicy）。

适用场景：测试环境或对网络性能要求不高的场景。

部署命令

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

4.2、Calico

Calico是一个高性能且可扩展的网络方案，支持三层路由和二层交换。它不仅可以作为纯三层的SDN解决方案，也可以与其他网络技术（如VXLAN）结合使用。

工作原理

• 数据平面：纯 BGP 路由（高性能）或 IP-in-IP 封装。
• 控制平面：Felix 组件管理路由，Typha 优化大规模集群性能。

特点

• 高性能、支持丰富的 NetworkPolicy（L3-L7 策略）。
• 强大的网络策略支持，允许细粒度控制Pod之间的流量。
• 高性能，适用于大规模生产环境。
• 支持BGP协议，可以与现有网络基础设施无缝集成。

组件

• Felix：运行在节点上，配置路由和 ACL 规则。
• BIRD：BGP 客户端，与其他节点交换路由信息。
• Typha（可选）：减轻 API Server 压力，适用于大规模集群。

高级功能

• 网络策略（支持 ingress/egress 规则）
• 硬件加速（eBPF 模式）
• 多集群网络互联

适用场景：生产环境、需要精细网络策略的场景。

部署命令

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/custom-resources.yaml

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

4.3、Cilium

Cilium是一种基于eBPF技术构建的网络和网络安全解决方案，旨在提供高效的网络连接和高级别的安全防护。它不仅支持传统的IP地址/端口过滤，还支持基于HTTP、gRPC等应用层协议的精细访问控制。

新兴趋势

• eBPF 统一网络/安全：Cilium 已成为云原生网络的事实标准。

• 服务网格集成：Linkerd/Istio 开始依赖 Cilium 作为数据平面。

• 多集群网络：Submariner（Calico）和 Cilium Cluster Mesh 提供跨集群连通。

核心技术

• 基于 eBPF（Linux 内核技术）实现高性能网络和安全策略。
• 提供网络流量观测能力（Hubble）。
• 使用eBPF技术提供了极高的性能。
• 强大的安全性，包括微分割和API感知的网络策略。
• 对现代云原生应用的支持非常好。

优势场景

• 高性能服务网格（替代 Istio 数据平面）
• 安全审计（基于 DNS/HTTP 的七层策略）

部署命令

# 使用Helm部署
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --version 1.13.0

cilium install --version 1.13.0
cilium status

4.4、Weave Net

Weave Net是另一个覆盖网络解决方案，它创建了一个虚拟网络，使部署在不同主机上的容器能够像在同一个局域网内一样相互通信。

特点

• 自建 Fast Datapath 绕过内核协议栈提升性能。
• 支持 加密通信（PSK）。
• 快速启动，无需额外配置即可工作
• 内置服务发现机制
• 支持加密通信，增强了跨公共网络的安全性
• 自动发现节点，支持加密通信，内置 NetworkPolicy。

适用场景：需要加密和简单策略控制的中小型集群。

部署命令

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

4.5、Canal

Canal实际上是将Flannel和Calico的优势结合起来的一种网络方案。它使用Flannel进行底层网络连接，同时利用Calico强大的网络策略能力来增强安全性。

从 Kubernetes 1.6 版本开始，官方更推荐单独安装 Calico，并根据需要选择是否启用其与 Flannel 的兼容模式或直接使用 Calico 自带的网络后端。因此，现在部署 Canal 通常指的是部署 Calico 并配置它以与 Flannel 兼容的方式工作。

组成：Calico（网络策略） + Flannel（网络连通性）。

特点

• 同时提供高性能路由和灵活的策略控制。
• 结合了Flannel的简易性和Calico的安全性
• 提供了灵活的网络策略管理
• 适合那些需要既简单又安全网络配置的用户

适用场景：需要 NetworkPolicy 但希望简化部署的场景。

4.8、选择建议

1. 测试 / 开发环境：
   • 优先选择 Flannel（简单）或 Weave Net（支持策略）。
2. 生产环境：
   • 通用场景：Calico（性能 + 策略）或 Canal（简化部署）。
   • 云环境：AWS VPC CNI（AWS）或 GKE Networking（Google Cloud）。
   • 微服务架构：Cilium（L7 策略 + 可观测性）。
3. 关键考量因素：
   • 性能需求：优先选择三层网络（Calico）或 eBPF（Cilium）。
   • 策略复杂度：Calico 和 Cilium 支持更丰富的策略。
   • 集群规模：大规模集群（>500 节点）建议使用 Calico + Typha 或 Cilium。

4.9、网络插件对比

特性	Flannel	Calico	Canal	Cilium	Weave Net
网络模式	覆盖	三层	混合	eBPF	覆盖
NetworkPolicy 支持	❌	✅	✅	✅	✅
性能	低	高	中	极高	中
部署复杂度	低	中	中	高	低
策略丰富度	无	L3-L4	L3-L4	L3-L7	L3-L4
大规模集群支持	一般	优秀	良好	优秀	一般

---

完毕。