1.Kubernetes概叙

概述 | Kubernetes

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上， 结合了社区中最优秀的想法和实践。

时光回溯

让我们回顾一下为何 Kubernetes 能够裨益四方。

传统部署时代：

早期，各个组织是在物理服务器上运行应用程序。 由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。 例如，如果在同一台物理服务器上运行多个应用程序， 则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。 一种解决方案是将每个应用程序都运行在不同的物理服务器上， 但是当某个应用程式资源利用率不高时，剩余资源无法被分配给其他应用程式， 而且维护许多物理服务器的成本很高。

虚拟化部署时代：

因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。 虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性， 因为一个应用程序的信息不能被另一应用程序随意访问。

虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序， 而因此可以具有更高的可扩缩性，以及降低硬件成本等等的好处。 通过虚拟化，你可以将一组物理资源呈现为可丢弃的虚拟机集群。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代：

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

容器因具有许多优势而变得流行起来，例如：

• 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
• 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性）， 提供可靠且频繁的容器镜像构建和部署。
• 关注开发与运维的分离：在构建、发布时创建应用程序容器镜像，而不是在部署时， 从而将应用程序与基础架构分离。
• 可观察性：不仅可以显示 OS 级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
• 跨开发、测试和生产的环境一致性：在笔记本计算机上也可以和在云中运行一样的应用程序。
• 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
• 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
• 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
• 资源隔离：可预测的应用程序性能。
• 资源利用：高效率和高密度。

为什么需要 Kubernetes，它能做什么？

容器是打包和运行应用程序的好方式。在生产环境中， 你需要管理运行着应用程序的容器，并确保服务不会下线。 例如，如果一个容器发生故障，则你需要启动另一个容器。 如果此行为交由给系统处理，是不是会更容易一些？

这就是 Kubernetes 要来做的事情！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移你的应用、提供部署模式等。 例如，Kubernetes 可以轻松管理系统的 Canary 部署。

Kubernetes 为你提供：

• 服务发现和负载均衡

  Kubernetes 可以使用 DNS 名称或自己的 IP 地址来曝露容器。 如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排

  Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚

  你可以使用 Kubernetes 描述已部署容器的所需状态， 它可以以受控的速率将实际状态更改为期望状态。 例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。

• 自动完成装箱计算

  你为 Kubernetes 提供许多节点组成的集群，在这个集群上运行容器化的任务。 你告诉 Kubernetes 每个容器需要多少 CPU 和内存 (RAM)。 Kubernetes 可以将这些容器按实际情况调度到你的节点上，以最佳方式利用你的资源。

• 自我修复

  Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器， 并且在准备好服务之前不将其通告给客户端。

• 密钥与配置管理

  Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

Kubernetes 不是什么

Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。 由于 Kubernetes 是在容器级别运行，而非在硬件级别，它提供了 PaaS 产品共有的一些普遍适用的功能， 例如部署、扩展、负载均衡，允许用户集成他们的日志记录、监控和警报方案。 但是，Kubernetes 不是单体式（monolithic）系统，那些默认解决方案都是可选、可插拔的。 Kubernetes 为构建开发人员平台提供了基础，但是在重要的地方保留了用户选择权，能有更高的灵活性。

Kubernetes：

• 不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
• 不部署源代码，也不构建你的应用程序。 持续集成（CI）、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
• 不提供应用程序级别的服务作为内置服务，例如中间件（例如消息中间件）、 数据处理框架（例如 Spark）、数据库（例如 MySQL）、缓存、集群存储系统 （例如 Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制 （例如开放服务代理）来访问。

• 不是日志记录、监视或警报的解决方案。 它集成了一些功能作为概念证明，并提供了收集和导出指标的机制。
• 不提供也不要求配置用的语言、系统（例如 jsonnet），它提供了声明性 API， 该声明性 API 可以由任意形式的声明性规范所构成。
• 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
• 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。 而 Kubernetes 包含了一组独立可组合的控制过程，可以连续地将当前状态驱动到所提供的预期状态。 你不需要在乎如何从 A 移动到 C，也不需要集中控制，这使得系统更易于使用 且功能更强大、系统更健壮，更为弹性和可扩展。

什么是Kubernetes 

Kubernetes是一个全新的基于容器技术的分布式领先方案。

简称：k8s。它是Google开源的容器集群管理系统，它的设计灵感来自于Google内部的一个叫做Borg的容器管理系统。继承了Google十余年的容器集群使用经验，它为容器化的应用提供了部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，极大的提高了大规模容器集群管理的便捷性。
Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。
在 Kubernetes 集群中，它解决了传统 IT 系统中服务扩容和升级的两大难题。

如果今天的软件并不是特别复杂并且需要承载的峰值流量不是特别多，那么后端项目的部署其实也只需要在虚拟机上安装一些简单的依赖，将需要部署的项目编译后运行就可以了。但是随着软件变得越来越复杂，一个完整的后端服务不再是单体服务，而是由多个职责和功能不同的服务组成，服务之间复杂的拓扑关系以及单机已经无法满足的性能需求使得软件的部署和运维工作变得非常复杂，这也就使得部署和运维大型集群变成了非常迫切的需求。
Kubernetes 的出现不仅主宰了容器编排的市场，更改变了过去的运维方式，不仅将开发与运维之间边界变得更加模糊，而且让 DevOps 这一角色变得更加清晰，每一个软件工程师都可以通过 Kubernetes 来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且能够快速实现水平扩容、蓝绿部署等在过去复杂的运维操作

Kubernetes优势

• 自动装箱,水平扩展,自我修复

• 服务发现和负载均衡

• 自动发布(默认滚动发布模式)和回滚

• 集中化配置管理和密钥管理

• 存储编排

• 任务批处理运行

2.Kubernetes架构及其组件

Kubernetes 遵循非常传统的客户端服务端架构，客户端通过 RESTful 接口或者直接使用 kubectl 与Kubernetes 集群进行通信，这两者在实际上并没有太多的区别，后者也只是对 Kubernetes 提供的 RESTfulAPI 进行封装并提供出来。每一个 Kubernetes 集群都由一组 Master 节点和一系列的 Worker 节点组成，其中 Master 节点主要负责存储集群的状态并为 Kubernetes 对象分配和调度资源。

在集群管理方面，Kubernetes将集群中的机器划分为一个 Master 节点和一群工作节点 Node，其中，在 Master节点运行着集群管理相关的一组进程 kube-apiserver、kube-controller-manager 和 kube-scheduler，这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。Node 作为集群中的工作节点，运行真正的应用程序，在 Node 上 Kubernetes 管理的最小运行单元是 Pod。Node 上运行着 Kubernetes 的kubelet、kube-proxy 服务进程，这些服务进程负责 Pod 的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

1.Master（主要用来管理集群）

它主要负责接受客户端的请求，安排容器的执行并且运行控制循环，将集群的状态向目标状态进行迁移，Master节点内部由7个组件构成：

#1.APIServer（kube-apiserver ： 中央管理器，调度管理集群）
负责处理来自用户的请求，其主要作用就是对外提供RESTful的接口
包括用于查看集群状态的读请求以及改变集群状态的写请求，也是唯一一个于etcd集群通信的组件。

#2.Controller（kube-controller-manager ：控制器： 管理容器，监控容器）
管理器运行了一系列的控制器进程，这些进程会按照用户的期望状态在后台不断地调节整个集群中的对象，需要有高可用机制
当服务的状态发生改变，控制器就会发现这个改变并且开始向目标状态迁移。
由一系列控制器组成,通过apiserver监控整个集群的状态,并确保集群处于预期的工作状态
Node Controller       #节点控制器
Deployment Controller   #pod控制器
Service Controller    #服务控制器
Volume Controller      #存储卷控制器
Endpoint Controller    #接入点控制器
Garbage Controller    #垃圾回收控制器
Namespace Controller    #名称空间控制器
Job Controller       #任务控制器
Resource quta Controller    #资源配额控制器

#3.Scheduler（kube-scheduler：调度器：调度容器）
调度器其实为kubernetes中运行的Pod选择部署的Worker节点
它会根据用户的需要选择最能满足请求的节点来运行Pod，它会在每次需要调度Pod时执行。
主要功能是接收调度pod到适合的运算节点上
预选策略( predict )
优选策略( priorities )

#4.Flannel(提供集群间网络)

#5.Etcd(数据库)

#6.kubelet(部署容器，监控容器)

#7.kube-proxy(提供容器间的网络)

2.Node(主要用来部署应用)

#1.kube-kubelet(部署容器，监控容器)
kubelet是一个节点上的主要服务，他周期性的从APIServer接受新的或者修改的pod规范并且保证节点上的pod和其容器的正常运行
还会保证节点会向目标状态迁移，该节点仍然会向Master节点发送宿主机的健康状态。
简单地说, kubelet的主要功能就是定时从某个地方获取节点上pod的期望状态(运行什么容器、运行的副本数量、网络或者存储如何配置等等) ,并调用对应的容器平台接口达到这个状态
定时汇报当前节点的状态给apiserver,以供调度的时候使用
镜像和容器的清理工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源

#2.kube-proxy(提供容器间的网络)
负责宿主机的子网管理，同时也能将服务暴露给外部
其原理就是在多个隔离的网络中把请求转发给正确的Pod或者容器。
是K8S在每个节点 上运行网络代理, service资源的载体
建立了pod网络和集群网络的关系( clusterip >podip )
常用三种流量调度模式
Userspace (废弃)
Iptables (濒临废弃)（绝大部分公司在用）
Ipvs(推荐)
负责建立和删除包括更新调度规则、通知apiserver自己的更新,或者从apiserver哪里获取其他kube- proxy的调度规则变化来更新自己的

3.Kubernetes核心组件

Kubernetes全部组件

kubernetes核心组件

其实在上面两小节（Master和Node）有概叙

API Server

API Server是控制平面的前端，也是控制平面中唯一与我们直接交互的组件。内部系统组件以及外部用户组件都通过相同的 API 进行通信。

API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

功能：

1. 验证和授权：Kube-APIServer 负责验证用户的身份，并根据配置的访问控制策略进行授权，确保只有合法的请求才能对集群进行操作。
2. 集群状态管理：APIServer 是集群的状态中心，所有的集群状态信息都通过它来访问和更新。
3. 通信枢纽：Kube-APIServer 是其他控制平面组件和工作节点与集群进行通信的桥梁。所有的组件和节点都通过它来获取和更新集群状态。

Key-Value Store (etcd)

键值存储，也称为etcd，是 Kubernetes 用于备份所有集群数据的数据库。它存储集群的整个配置和状态。主节点查询etcd以检索节点、pod 和容器状态的参数。

一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库。

如果你的 Kubernetes 集群使用 etcd 作为其后台数据库， 请确保你针对这些数据有一份 备份计划。

你可以在官方文档中找到有关 etcd 的深入知识。

科普文： Etcd实现高可用AP+强一致性CP的分布式锁_etcd如何保证数据的一致性-CSDN博客

功能：

1. 数据存储：Etcd 负责存储所有的集群状态数据，包括 Pod、Service、ConfigMap、Secret 等。
2. 数据可靠性：Etcd 通过分布式架构保证数据的高可用性和一致性，确保集群状态数据在发生故障时仍能可靠存储。
3. 数据访问：Etcd 提供了高效的键值对存储和访问接口，支持高频率的读写操作，满足 Kubernetes 对集群状态数据的高频访问需求。

Controller 控制器

Controller的作用是从API Server获取所需的状态。它检查其任务控制的节点的当前状态，并确定是否存在任何差异，并解决它们（如果有）。

kube-controller-manager 是控制平面的组件， 负责运行控制器进程。

从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

这些控制器包括：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
• 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

cloud-controller-manager

一个 Kubernetes 控制平面组件， 嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器

功能：

1. 控制器管理：包括 Node Controller、Replication Controller、Endpoint Controller、Namespace Controller 等，这些控制器分别负责节点管理、副本管理、服务发现、命名空间管理等功能。
2. 自动化操作：控制器通过监听集群状态变化，自动执行相应的操作，如副本调整、故障节点隔离、服务更新等。
3. 一致性保证：通过控制器的自动化操作，Kube-Controller-Manager 保证了集群状态的一致性和可靠性。

Scheduler

调度程序监视来自 API 服务器的新请求并将它们分配给健康的节点。它对节点进行排名并将 Pod 部署到最适合的节点上。如果没有合适的节点，Pod 将处于挂起状态，直到出现这样的节点。

kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

功能：

1. 资源调度：Kube-Scheduler 根据节点的资源使用情况和 Pod 的资源需求，选择合适的节点来运行 Pod。
2. 策略配置：Kube-Scheduler 支持多种调度策略，包括资源优先、亲和性、反亲和性等，用户可以根据需求自定义调度策略。
3. 负载均衡：通过合理的调度策略，Kube-Scheduler 能够有效地分配负载，避免节点过载，确保集群的高效运行。

Worker Node-工作节点

Worker节点监听API Server以获取新的工作；他们执行工作，然后将结果报告回 Kubernetes 主节点。节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。

kubelet

kubelet运行在集群中的每个节点上。它是主要的 Kubernetes 代理。通过安装 kubelet，节点的 CPU、RAM 和存储成为更广泛集群的一部分。它监视从 API Server 发送的任务，执行任务，并向 Master 报告。它还监视 Pod，并在 Pod 未完全正常工作时向控制面板报告。根据该信息，Master 可以决定如何分配任务和资源以达到所需的状态。

kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

功能：

1. Pod 管理：Kubelet 负责启动和停止节点上的 Pod，并监控它们的状态，确保每个 Pod 按照预期运行。
2. 状态报告：Kubelet 定期向 Kube-APIServer 报告节点和 Pod 的状态，包括资源使用情况、健康状态等。
3. 配置管理：Kubelet 根据从 Kube-APIServer 获取的配置信息，配置和管理节点上的容器运行环境。

Container Runtime

容器运行环境从容器映像注册表中提取映像并启动和停止容器。第三方软件或插件（例如 Docker， PodMan）通常执行此功能。

容器运行环境是负责运行容器的软件。

Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

功能：

1. 容器管理：容器运行时负责启动、停止和监控容器的运行状态。

2. 资源隔离：容器运行时通过 cgroup、namespace 等机制实现容器的资源隔离和限制。

3. 镜像管理：容器运行时负责从镜像仓库拉取容器镜像，并在节点上进行存储和管理。

Kube代理

kube -proxy确保每个节点获取其 IP 地址，实现本地iptables和规则来处理路由和流量负载平衡。

kube-proxy 是集群中每个节点（node）所上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

功能：

1. 服务发现：Kube-Proxy 负责维护节点上的网络规则，确保服务 IP 和端口能够正确映射到相应的 Pod 上。
2. 负载均衡：Kube-Proxy 通过 IPTables 或 IPVS 实现服务的负载均衡，将请求分发到后端的多个 Pod 上。
3. 网络路由：Kube-Proxy 处理网络流量，确保节点内外的通信能够正确路由到目标 Pod。

Pod

Pod是 Kubernetes中最小的调度元素。没有它，容器就不能成为集群的一部分。如果您需要扩展应用程序，则只能通过添加或删除 Pod 来实现。
Pod 充当具有应用程序代码的单个容器的“包装器”。Master根据资源的可用性，将pod调度到特定的节点上，并与容器运行环境协调来启动容器。

微服务的终点就是容器化，对应也就是最后的Pod。

容器化给微服务运维管理带来了便利。接着往下看服务编排和容器编排。

4.Kubernetes核心概念

如果 Pod 意外无法执行其任务，Kubernetes 不会尝试修复它们。相反，它会在其位置创建并启动一个新的 Pod。

这个新的Kubernetes Pod是一个副本，除了 DNS 和 IP 地址之外。此功能对开发人员设计应用程序的方式产生了深远的影响。
由于 Kubernetes 架构的灵活性，应用程序不再需要绑定到 Pod 的特定实例。

相反，需要设计应用程序，以便在集群内任何位置创建的全新 Pod 可以无缝取代它。为了协助完成此过程，Kubernetes 使用services。

Deployment、‌Pod、‌Container和Service在Kubernetes中各自扮演着不同的角色，‌它们之间通过特定的方式相互关联和作用。‌

• Pod是Kubernetes中的最小部署单元，‌它包含了一个或多个容器（‌Container）‌。‌Pod提供了一种抽象，‌将容器及其运行时的环境（‌如网络和存储）‌封装在一起，‌使得容器的运行更加独立和可移植。‌Pod通过共享存储和网络栈，‌确保了容器之间的通信和资源共享。‌

• Container是运行中的程序，‌它是Pod中的基本运行单元。‌在Kubernetes中，‌容器通过Docker等技术实现，‌它们被设计用来运行单个进程，‌并且具有可移植性、‌轻量级和隔离性等特点。‌

• Deployment是Kubernetes中的一个资源对象，‌用于管理无状态应用。‌它提供了声明式更新机制，‌可以定义Pod的副本数量、‌更新策略等。‌Deployment通过控制ReplicaSet来实现Pod的创建和管理，‌ReplicaSet负责确保Pod的副本数量符合Deployment的定义。‌简而言之，‌Deployment是ReplicaSet的更高层次的抽象，‌用于管理ReplicaSet。‌

• Service在Kubernetes中是一个网络服务抽象，‌它为Pod提供了一种统一访问入口。‌Service可以是一个集群内部的负载均衡器，‌能够将流量分发到后端的Pod上。‌Service通过标签选择器（‌Label Selector）‌与Pod进行关联，‌确保了服务的高可用性和可扩展性。‌

综上所述，‌Deployment、‌Pod、‌Container和Service在Kubernetes中形成了完整的应用部署和服务发现机制。‌

1. Deployment通过管理Pod的副本数量和更新策略来确保应用的可用性和可扩展性。‌
2. Pod作为运行容器的基本单元，‌通过Container来运行具体的业务进程。‌
3. Service则提供了一个统一的网络访问入口，‌确保了应用的高可用性和可扩展性。

1.Container
容器，是实体，有资源。

2.Pod

实例，是逻辑概念，多个相关的Container构成一个Pod，它是Kubernetes资源调度的基本单位。

pod本身没有资源。

Pod是一组紧密关联的容器集合，它们共享PID、IPC、Network和UTS namespace。Pod的设计理念是支持多个容器在一个Pod中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

缺点: 不支持高并发, 高可用, 当Pod当机后无法自动恢复。

3.replicaset(RS)

是pod的复制抽象，用于保证与label selector匹配的pod数量维持在期望状态。RS用来管理正常运行Pod数量。

4.service

service是pod的路由代理抽象，用于解决pod之间的服务发现问题，即上下游pod之间使用的问题。

传统部署方式中，实例所在的主机ip（或者dns名字）一般是不会改变的，但是pod的运行状态可动态变化(比如容器重启、切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。

service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理。

5.Deployment

Deployment在继承Pod和Replicaset的所有特性的同时, 它可以实现对template模板进行实时滚动更新并具备我们线上的Application life circle的特性.

Deployment 通过“控制器模式”，来操作 ReplicaSet 的个数和属性，进而实现“水平扩展 / 收缩”和“滚动更新”这两个编排动作。

详细的容器编排和服务编排将在后面的文章中描叙，这里就不再展开。很多时候，开发人员需要了解的就是Deployment。

6.Lable

Label是attach到Pod的一对键/值对，用来传递用户定义的属性。

比如，你可能创建了一个"tier"和“app”标签，通过Label（tier=frontend, app=myapp）来标记前端Pod容器，使用Label（tier=backend, app=myapp）标记后台Pod。

然后可以使用Selectors选择带有特定Label的Pod，让具体某一个Pod或者Deployment​去使用某一个Service​实现特定的网络配置.

7.StatefulSet

“Deployment用于部署无状态服务，StatefulSet用来部署有状态服务”。

RC、Deployment、DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的.

而StatefulSet是什么？顾名思义，有状态的集合，管理所有有状态的服务，比如MySQL、MongoDB集群等。

StatefulSet本质上是Deployment的一种变体，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识(hostname)，还必须要用到共享存储。

在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service，headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。

除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名。

5.Kubernetes工作流程

上面的核心概念，基本包含了k8s工作流程中的概念。

k8s工作流程如下：

1. kubectl发送部署deployment的请求到API Server。
2. API Server通知Controller Manager创建一个deployment资源。
3. Deployment controller向API Server发送创建ReplicaSet的需求。
4. ReplicaSet通知ReplicaSet controller启动。
5. ReplicaSet controller发送创建Pod需求到API Server
6. API Server通知Scheduler执行调度任务
7. Scheduler根据副本数将分配Pod到集群中的node节点
8. API Server通知对应的node节点上面的kubelet组件准备创建pod
9. kubelet告诉docker在本节点上运行容器。
10. docker在节点上运行一个或多个容器。

需要注意：

应用的配置和当前状态信息是保存在etcd中的，执行kubectl get pod 时 API Server 会从 etcd 中读取这些数据。

flannel 会为每个 Pod 都分配 IP。因为没有创建 service，目前 kube-proxy 还没参与进来。

 

5. 底层网络Underlay Network Model

什么是 Underlay Network

底层网络 Underlay Network 顾名思义是指网络设备基础设施，如交换机，路由器, DWDM 使用网络介质将其链接成的物理网络拓扑，负责网络之间的数据包传输。

underlay network 可以是二层，也可以是三层；二层的典型例子是以太网 Ethernet，三层是的典型例子是互联网 Internet。

而工作于二层的技术是 vlan，工作在三层的技术是由 OSPF, BGP 等协议组成。

k8s 中的 underlay network

在 kubernetes 中，underlay network 中比较典型的例子是通过将宿主机作为路由器设备，Pod 的网络则通过学习路由条目从而实现跨节点通讯。

这种模型下典型的有 flannel 的 host-gw 模式与 calico BGP 模式。

flannel host-gw

flannel host-gw 模式中每个 Node 需要在同一个二层网络中，并将 Node 作为一个路由器，跨节点通讯将通过路由表方式进行，这样方式下将网络模拟成一个underlay network。

Notes：因为是通过路由方式，集群的 cidr 至少要配置 16，因为这样可以保证，跨节点的 Node 作为一层网络，同节点的 Pod 作为一个网络。如果不是这种用情况，路由表处于相同的网络中，会存在网络不可达

Calico BGP

BGP（Border Gateway Protocol）是去中心化自治路由协议。它是通过维护 IP 路由表或前缀表来实现 AS （Autonomous System）之间的可访问性，属于向量路由协议。

与 flannel 不同的是，Calico 提供了的 BGP 网络解决方案，在网络模型上，Calico 与 Flannel host-gw 是近似的，但在软件架构的实现上，flannel 使用 flanneld 进程来维护路由信息；而 Calico 是包含多个守护进程的，其中 Brid 进程是一个 BGP 客户端与路由反射器(Router Reflector)，BGP 客户端负责从 Felix 中获取路由并分发到其他 BGP Peer，而反射器在 BGP 中起了优化的作用。在同一个 IBGP 中，BGP 客户端仅需要和一个 RR 相连，这样减少了AS内部维护的大量的 BGP 连接。通常情况下，RR 是真实的路由设备，而 Bird 作为 BGP 客户端工作。

IPVLAN & MACVLAN

IPVLAN 和 MACVLAN 是一种网卡虚拟化技术，两者之间的区别为， IPVLAN 允许一个物理网卡拥有多个 IP 地址，并且所有的虚拟接口用同一个 MAC 地址；而 MACVLAN 则是相反的，其允许同一个网卡拥有多个 MAC 地址，而虚拟出的网卡可以没有 IP 地址。

因为是网卡虚拟化技术，而不是网络虚拟化技术，本质上来说属于 Overlay network，这种方式在虚拟化环境中与 Overlay network 相比最大的特点就是可以将 Pod 的网络拉平到 Node 网络同级，从而提供更高的性能、低延迟的网络接口。本质上来说其网络模型属于下图中第二个。

• 虚拟网桥：创建一个虚拟网卡对(veth pair)，一头在容器内，一头在宿主机的 root namespaces 内。这样一来容器内发出的数据包可以通过网桥直接进入宿主机网络栈，而发往容器的数据包也可以经过网桥进入容器。
• 多路复用：使用一个中间网络设备，暴露多个虚拟网卡接口，容器网卡都可以介入这个中间设备，并通过 MAC/IP 地址来区分 packet 应该发往哪个容器设备。
• 硬件交换，为每个 Pod 分配一个虚拟网卡，这样一来，Pod 与 Pod 之间的连接关系就会变得非常清晰，因为近乎物理机之间的通信基础。如今大多数网卡都支持 SR-IOV 功能，该功能将单一的物理网卡虚拟成多个 VF 接口，每个 VF 接口都有单独的虚拟 PCIe 通道，这些虚拟的 PCIe 通道共用物理网卡的 PCIe 通道。

在 kubernetes 中 IPVLAN 这种网络模型下典型的 CNI 有，multus 与 danm。

multus

multus 是 intel 开源的 CNI 方案，是由传统的 cni 与 multus，并且提供了 SR-IOV CNI 插件使 K8s pod 能够连接到 SR-IOV VF 。这是使用了 IPVLAN/MACVLAN 的功能。

当创建新的 Pod 后，SR-IOV 插件开始工作。配置 VF 将被移动到新的 CNI 名称空间。该插件根据 CNI 配置文件中的 “name” 选项设置接口名称。最后将 VF 状态设置为 UP。

下图是一个 Multus 和 SR-IOV CNI 插件的网络环境，具有三个接口的 pod。

• eth0 是 flannel 网络插件，也是作为 Pod 的默认网络
• VF 是主机的物理端口 ens2f0 的实例化。这是英特尔 X710-DA4 上的一个端口。在 Pod 端的 VF 接口名称为 south0 。
• 这个 VF 使用了 DPDK 驱动程序，此 VF 是从主机的物理端口 ens2f1 实例化出的。这个是英特尔 ® X710-DA4 上另外一个端口。Pod 内的 VF 接口名称为 north0。该接口绑定到 DPDK 驱动程序 vfio-pci 。

Notes：术语

• NIC：network interface card，网卡
• SR-IOV：single root I/O virtualization，硬件实现的功能，允许各虚拟机间共享 PCIe 设备。
• VF：Virtual Function，基于 PF，与 PF 或者其他 VF 共享一个物理资源。
• PF：PCIe Physical Function，拥有完全控制 PCIe 资源的能力
• DPDK：Data Plane Development Kit

于此同时，也可以将主机接口直接移动到 Pod 的网络名称空间，当然这个接口是必须存在，并且不能是与默认网络使用同一个接口。这种情况下，在普通网卡的环境中，就直接将 Pod 网络与 Node 网络处于同一个平面内了。

danm

DANM 是诺基亚开源的 CNI 项目，目的是将电信级网络引入 kubernetes 中，与 multus 相同的是，也提供了 SR-IOV/DPDK 的硬件技术，并且支持 IPVLAN.

6. 叠加网络Overlay Network Model

什么是 Overlay

叠加网络是使用网络虚拟化技术，在 underlay 网络上构建出的虚拟逻辑网络，而无需对物理网络架构进行更改。本质上来说，overlay network 使用的是一种或多种隧道协议 (tunneling)，通过将数据包封装，实现一个网络到另一个网络中的传输，具体来说隧道协议关注的是数据包（帧）。

常见的网络隧道技术

• 通用路由封装 ( Generic Routing Encapsulation ) 用于将来自 IPv4/IPv6 的数据包封装为另一个协议的数据包中，通常工作与 L3 网络层中。
• VxLAN (Virtual Extensible LAN)，是一个简单的隧道协议，本质上是将 L2 的以太网帧封装为 L4 中 UDP 数据包的方法，使用 4789 作为默认端口。VxLAN 也是 VLAN 的扩展，对于 4096（ 位 VLAN ID） 扩展为 1600 万（ 位 VN·ID ）个逻辑网络。

这种工作在 overlay 模型下典型的有 flannel 与 calico 中的的 VxLAN, IPIP 模式。

IPIP

IP in IP 也是一种隧道协议，与 VxLAN 类似的是，IPIP 的实现也是通过 Linux 内核功能进行的封装。IPIP 需要内核模块 ipip.ko 使用命令查看内核是否加载 IPIP 模块lsmod | grep ipip ；使用命令modprobe ipip 加载。

Kubernetes 中 IPIP 与 VxLAN 类似，也是通过网络隧道技术实现的。与 VxLAN 差别就是，VxLAN 本质上是一个 UDP 包，而 IPIP 则是将包封装在本身的报文包上。

Notes：公有云可能不允许 IPIP 流量，例如 Azure

VxLAN

kubernetes 中不管是 flannel 还是 calico VxLAN 的实现都是使用 Linux 内核功能进行的封装，Linux 对 vxlan 协议的支持时间并不久，2012 年 Stephen Hemminger 才把相关的工作合并到 kernel 中，并最终出现在 kernel 3.7.0 版本。为了稳定性和很多的功能，你可以会看到某些软件推荐在 3.9.0 或者 3.10.0 以后版本的 kernel 上使用 VxLAN。

在 kubernetes 中 vxlan 网络，例如 flannel，守护进程会根据 kubernetes 的 Node 而维护 VxLAN，名称为 flannel.1 这是 VNID，并维护这个网络的路由，当发生跨节点的流量时，本地会维护对端 VxLAN 设备的 MAC 地址，通过这个地址可以知道发送的目的端，这样就可以封包发送到对端，收到包的对端 VxLAN 设备 flannel.1 解包后得到真实的目的地址。

查看 Forwarding database 列表

$bridgefdb 26:5e:87:90:91:fcdevflannel.1dst10.0.0.3selfpermanent

Notes：VxLAN 使用的 4789 端口，wireshark 应该是根据端口进行分析协议的，而 flannel 在 linux 中默认端口是 8472，此时抓包仅能看到是一个 UDP 包。

通过上述的架构可以看出，隧道实际上是一个抽象的概念，并不是建立的真实的两端的隧道，而是通过将数据包封装成另一个数据包，通过物理设备传输后，经由相同的设备（网络隧道）进行解包实现网络的叠加。

weave vxlan

weave 也是使用了 VxLAN 技术完成的包的封装，这个技术在 weave 中称之为 fastdp (fast data path)，与 calico 和 flannel 中用到的技术不同的，这里使用的是 Linux 内核中的 openvswitch datapath module，并且 weave 对网络流量进行了加密。

Notes：fastdp 工作在 Linux 内核版本 3.12 及更高版本，如果低于此版本的例如 CentOS7，weave 将工作在用户空间，weave 中称之为 sleeve mode

7. Kubernetes 网络

Kubernetes 网络模型

Pod 和 Service 的网络通信

Kubernetes 的网络模型基于 Pod 和 Service 的通信，通过统一的 IP 地址和端口分配，确保集群内的各个组件能够无缝通信。

Pod 网络

1. 每个 Pod 一个 IP：每个 Pod 都有一个唯一的 IP 地址，这个 IP 地址在整个集群内都是可达的。
2. Pod 间通信：Pod 可以直接通过 IP 地址互相通信，无需进行 NAT（网络地址转换）。
3. Pod 网络插件：Kubernetes 支持多种网络插件（如 Flannel、Calico、Weave），它们通过 CNI（Container Network Interface）接口与 Kubernetes 集成，提供灵活的网络实现。

Service 网络

1. 虚拟 IP：Service 在 Kubernetes 中有一个虚拟 IP 地址（Cluster IP），用于暴露一组 Pod。
2. 服务发现：Service 的 IP 地址和端口通过 DNS 解析，使得客户端可以通过服务名访问相应的服务。
3. 负载均衡：Service 自动将请求分发到后端的多个 Pod 上，实现负载均衡。

网络策略（Network Policy）

网络策略是 Kubernetes 中用于定义 Pod 之间通信规则的机制，通过配置网络策略，可以控制哪些 Pod 可以互相通信。

功能：

1. 访问控制：通过网络策略，可以定义允许和拒绝的通信规则，控制 Pod 之间的访问。
2. 隔离策略：网络策略可以用于隔离不同的应用和环境，确保敏感数据和服务的安全性。
3. 动态更新：网络策略可以动态更新，根据业务需求调整通信规则，提供灵活的网络控制。

网络策略是基于标签的规则，通过定义一组规则，指定允许或拒绝哪些 Pod 的通信。网络策略由网络插件实现，通过监听和解析网络策略的配置，动态更新网络规则，确保 Pod 间的通信符合预期。

Kubernetes 网络被设计来满足四个关键要求，每个要求在 Kubernetes 集群的功能和操作中都扮演着至关重要的角色。

容器与容器之间的通信：这是 Kubernetes 网络的基本层。它实现了同一个 Pod 内容器之间的直接通信。这些容器共享相同的网络命名空间，意味着它们可以使用 localhost 互相通信。对于涉及多容器 Pod 的应用程序而言，这种设置对于需要密切高效地交互的容器至关重要。

Pod-to-Pod 通讯: 在 Kubernetes 中，每个 Pod 都被分配了一个唯一的 IP 地址。这种设计选择简化了启用 Pod 之间通信的过程，无论它们位于哪个节点上。Pod 之间可以直接通信，无需进行网络地址转换（NAT），确保了直接且简单的连接。这种模型是创建分布式系统的基础，其中每个 Pod 都可以作为独立的微服务运行。

Pod-to-Service 通讯: Kubernetes 服务是一个关键的抽象，为 Pod 访问其他 Pod 提供了一种一致可靠的方式。服务本质上是一组变化的 Pod 的稳定地址。它确保任何发送到服务的请求都会自动智能地路由到正确的 Pod，即使 Pod 被创建、销毁或更新。这种抽象层对于维护一个具有弹性和可扩展性的系统至关重要。

External-to-Internal 通讯: Kubernetes 网络的这一方面涉及管理来自集群外部到集群内部服务的入站流量。通过 Ingress 控制器和负载均衡器等机制来处理。这些工具允许外部用户和应用程序安全高效地访问运行在集群内部的服务。它们在将应用程序暴露给最终用户和其他外部系统方面发挥着至关重要的作用。

服务和负载均衡

Kubernetes 中的服务对于为一组可能随时间动态变化的 Pod 提供稳定的地址至关重要。它们在管理访问运行在 Pod 上的应用程序方面起着至关重要的作用。让我们深入了解不同类型的服务及其在负载均衡中的作用：

ClusterIP：这是 Kubernetes 的默认服务。ClusterIP 服务分配一个唯一的内部 IP 地址，用于与服务进行通信。这些服务只能在集群内部访问，对于集群中的 Pod 之间的内部通信非常有用。这在不需要外部访问服务的场景中非常理想。

NodePort：NodePort 服务扩展了 ClusterIP 的功能。除了内部 IP 外，NodePort 服务还在所有集群节点上提供了一个特定的端口。外部流量可以访问这些暴露的端口上的服务，然后将流量路由到相应的内部 IP。当您需要外部流量跨所有节点访问特定端口时，这尤其有用。

LoadBalancer：在 NodePort 的基础上，LoadBalancer 服务与云服务提供商的负载均衡器集成。这种类型会自动创建一个外部负载均衡器，将外部流量引导到整个集群节点上的 NodePort，然后再路由到正确的 Pod 上。它简化了将服务暴露到互联网的过程，特别适用于分发传入的网络流量，从而提高了应用程序的可扩展性和可靠性。

ExternalName: 与其他类型不同，ExternalName 服务不会将流量路由到 Pod。相反，它们充当别名，通过返回一个 CNAME 记录到一个外部服务。当您想要使用 DNS 将 Kubernetes 集群中的服务与外部服务集成时，这是非常有用的。

网络安全的网络策略

Kubernetes 中的网络策略提供了一个重要的安全层，规定了 Pod 之间以及与其他网络端点之间的通信方式。它们充当了 Pod 的防火墙，允许用户根据标签选择器和 CIDR 块指定入站和出站规则。

例如，考虑这样一个情景：您有一个前端和一个后端服务。后端服务不应该从集群外部访问，但应该允许来自前端服务的流量。您可以使用类似以下内容的网络策略来实现：

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: backend-network-policy  namespace: defaultspec:  podSelector:    matchLabels:      app: backend  policyTypes:  - Ingress  ingress:  - from:    - podSelector:        matchLabels:          app: kubeops-frontend    ports:    - protocol: TCP      port: 80

这个策略确保只有带有标签 app: kubeops-frontend 的 Pod 可以访问 TCP 端口 80 上的后端 Pod。这种细粒度的控制有助于在 Kubernetes 中维护一个安全且受控的网络环境。

考虑默认行为也是至关重要的。默认情况下，Kubernetes 集群中的所有 Pod 都可以彼此通信。应用网络策略可以改变这种默认行为。例如，应用允许特定流量的策略意味着所有不符合该策略的其他流量都将被拒绝。

Ingress 和 Egress 控制器

Kubernetes 中的入口和出口控制器管理集群内部服务的外部访问，通常是 HTTP。入口控制器促进将外部流量路由到正确的内部资源，而出口控制器则管理集群的出站流量。

入口控制器负责读取入口资源信息并适当地处理它。例如，当用户请求 URL 时，入口控制器根据入口资源中定义的路由规则将请求路由到适当的服务。这对于管理对微服务的访问和实现 SSL/TLS 终止特别有用。

另一方面，出口控制器处理出站流量。它们确保来自集群内部到外部世界的请求被正确管理和路由。出口控制器可以强制执行限制 Pod 可以建立连接的目的地的策略，增强了集群的整体安全性。

实现这些控制器需要对网络架构和应用程序的流量模式有清晰的理解。例如，一个配置良好的入口控制器可以高效地处理流量突增，根据 URL 路径进行路由，并提供基于名称的虚拟主机。

核心网络解决方案：重要性与作用

Calico 用于网络策略执行：以其强大的网络策略执行而闻名，Calico 在维护应用程序安全方面发挥着关键作用。它对 Pod 通信提供了精细的控制，仅允许授权的流量，从而执行安全策略并分段网络流量以防止未经授权的访问。其重要性在于增强了应用程序内部网络交互的整体安全性和完整性。

Flannel 用于简单的覆盖网络：Flannel 以其在设置覆盖网络方面的简单性和效率而至关重要，连接跨节点的 Pod。它的作用是通过自动管理子网分配来简化 Kubernetes 部署中的网络配置。这减少了与网络管理相关的复杂性和运营开销，使其成为直接但有效的网络连接的有价值工具。

Cilium 用于 API 感知网络：Cilium 对于将 API 感知的网络安全过滤引入 Kubernetes 至关重要。利用 BPF，在内核级别过滤网络流量，理解 Kubernetes 标签和元数据。它的作用在于增强安全性，并为网络流量提供改进的可见性，特别是对于微服务，从而促进更安全、更透明的网络环境。

Canal 作为 Flannel 和 Calico 的组合：Canal 合并了 Flannel 和 Calico 的优点，为 Kubernetes 提供了全面的网络解决方案。它的作用是提供易用性（来自 Flannel）和强大的安全功能（来自 Calico）。这种组合使得 Canal 成为一个多功能的选择，满足了对高效网络覆盖和灵活网络策略的需求。

Kube-router 作为轻量级解决方案：Kube-router 是标准网络解决方案的简化、更高效的替代方案。它的作用是通过单个守护程序处理路由、网络策略和服务代理功能。这使其成为较小或资源受限环境的理想选择，提供了轻量级但有效的网络解决方案。

8. Kubernetes 网络的最佳实践

1. 利用网络策略控制流量流向：网络策略对于保护 Kubernetes 环境至关重要。它们充当 Pod 的防火墙，允许您定义哪些 Pod 可以彼此通信。例如，您可以限制数据库 Pod，使其只能被特定应用程序 Pod 访问，增强数据的安全性和完整性。

2. 实现服务网格以处理复杂通信：在微服务架构中，像 Istio 或 Linkerd 这样的服务网格提供了额外的通信控制、可观察性和可靠性层。例如，您可以通过服务网格管理负载均衡、服务间身份验证，并监控服务间通信，从而更容易调试和优化您的应用程序。

3. 优化负载均衡策略：负载均衡对于平均分配流量到各个 Pod 至关重要。您可以使用轮询策略，其中请求按顺序分配，或者更高级的方法，如 IP 哈希，确保用户的会话始终由相同的 Pod 服务。这确保了资源的有效利用和用户体验的改进。

4. 启用 DNS 进行服务发现：Kubernetes DNS 服务在服务发现中起着关键作用。它允许 Pod 通过名称定位其他 Pod 和服务，而不是依赖于可能变化的 IP 地址。例如，一个应用程序可以通过其 DNS 名称轻松定位到数据库服务，简化配置和服务间通信。

5. 利用 Ingress 控制器进行外部访问：当将您的服务暴露给外部世界时，Ingress 控制器是比 NodePort 或 LoadBalancer 服务更高级和灵活的选项。它们提供 HTTP/HTTPS 路由、SSL 终止和基于名称的虚拟主机。这意味着您可以通过精细的控制高效管理对服务的外部访问。

6. 监控和记录网络活动：持续监控和记录网络流量对于诊断问题和确保安全至关重要。像 Prometheus 监控和 Fluentd 记录这样的工具提供了对您的网络性能和安全性的洞察。它们帮助您发现异常、了解流量模式，并就扩展和优化做出明智决策。

7. 采用 IPv6 网络以实现可扩展性：随着 Kubernetes 集群规模的增长，IPv6 网络变得越来越重要。它提供了更大的地址空间，消除了复杂的 NAT 设置的需要。过渡到 IPv6 可以未雨绸缪，确保您有足够的 IP 地址用于所有的 Pod 和服务。