Kubernetes 由几个核心概念构建而成，这些概念组合成越来越强盛的功能。本节列出了这些概念中的每一个，并提供了一个简短的概述，以资助促进讨论。Kubernetes 的内容远不止此，这里仅仅扼要论述一些底子知识。如果您已经熟悉 Kubernetes，请随意跳过本节。
1.1、Kubernetes API server
在 Kubernetes 中，齐备都是由 Kubernetes API 服务器（kube-apiserver）提供的 API 调用。API 服务器是 etcd 数据存储的网关，它维护应用步伐集群的所需状态。要更新 Kubernetes 集群的状态，您可以对形貌所需状态的 API 服务器举行 API 调用。
1.2、Controllers
控制器是用于构建 Kubernetes 的核心抽象。一旦您使用 API 服务器声明了集群的所需状态，控制器就会通过连续观察 API 服务器的状态并对任何更改做出反应来确保集群的当前状态与所需状态相匹配。控制器内部实现了一个循环，该循环不绝查抄集群的当前状态与集群的盼望状态。如果有任何差别，控制器将执利用命以使当前状态与所需状态匹配。在伪代码中：
while true:X = currentState()Y = desiredState()if X == Y:return # Do nothingelse: do(tasks to get to Y)比方，当您使用 API 服务器创建新 Pod 时，Kubernetes 调治步伐（控制器）会注意到更改并决定将 Pod 放置在集群中的哪个位置。然后它使用 API 服务器（由 etcd 支持）写入状态更改。kubelet（一个控制器）然后会注意到新的变革并设置所需的网络功能以使 Pod 在集群内可访问。在这里，两个独立的控制器对两个独立的状态变革做出反应，以使集群的实际与用户的意图相匹配。
1.3、Pods
Pod 是 Kubernetes 的原子——用于构建应用步伐的最小可摆设对象。单个 Pod 代表集群中正在运行的工作负载，并封装了一个或多个 Docker 容器、任何所需的存储和唯一的 IP 地点，构成 pod 的容器被计划为在同一台呆板上共同定位和调治。
1.4、Nodes
Kubernetes 对 Pod 的联网方式做出了自以为是的选择。特殊是，Kubernetes 对任何网络实现都规定了以下要求：
全部 Pod 都可以在不使用网络地点转换 (NAT) 的情况下与全部其他 Pod 通信。
全部节点都可以在没有 NAT 的情况下与全部 Pod 通信。
Pod 以为本身的 IP 与其他人以为的 IP 雷同。
鉴于这些限制，我们必要办理四个差别的网络题目：
容器到容器网络
Pod 到 Pod 网络
Pod 到服务网络
Internet 到服务网络
本指南的别的部分将讨论这些题目中的每一个以及他们的办理方案。
3、容器和容器之间网络通信
通常，我们将捏造机中的网络通信视为直接与以太网(局域网)装备交互，如图 1 所示。
实际上，情况比这更玄妙。在 Linux 中，每个正在运行的进程都在一个网络命名空间内举行通信，该命名空间为逻辑网络堆栈提供了本身的路由、防火墙规则和网络装备。本质上，网络命名空间为命名空间内的全部进程提供了一个全新的网络堆栈。作为 Linux 用户，可以使用 ip 下令创建网络命名空间。比方，以下下令将创建一个名为 ns1 的新网络命名空间。
$ ip netns add ns1创建命名空间时，会在 /var/run/netns 下为其创建一个挂载点，纵然没有附加任何进程，命名空间也可以生存。
您可以通过列出 /var/run/netns 下的全部挂载点或使用 ip 下令来列出可用的命名空间。
$ ls /var/run/netnsns1$ ip netnsns1默认情况下，Linux 将每个进程分配给根网络命名空间以提供对外部天下的访问，如图 2 所示。
就 Docker 结构而言，Pod 被建模为一组共享网络命名空间的 Docker 容器。Pod 中的容器都具有雷同的 IP 地点和端口空间，这些 IP 地点和端口空间是通太过配给 Pod 的网络命名空间分配的，而且可以通过 localhost 找到相互，由于它们位于同一个命名空间中。我们可以为捏造机上的每个 Pod 创建一个网络命名空间。这是使用 Docker 作为“Pod 容器”实现的，它保持网络命名空间打开，而“应用容器”（用户指定的东西）通过 Docker 的 –net=container: 函数到场该命名空间。图 3 显示了每个 Pod 怎样由共享命名空间内的多个 Docker 容器 (ctr*) 构成。
Pod 中的应用步伐还可以访问共享卷，这些卷被定义为 Pod 的一部分，而且可以挂载到每个应用步伐的文件系统中。
4、Pod和Pod之间网络通信
在 Kubernetes 中，每个 Pod 都有一个真实的 IP 地点，而且每个 Pod 都使用该 IP 地点与其他 Pod 通信。现在使命是了解 Kubernetes 怎样使用真实 IP 实现 Pod 到 Pod 的通信，无论 Pod 摆设在集群中的同一个物理节点还是差别的节点上。我们通过思量驻留在同一台呆板上的 Pod 来开始这个讨论，以制止通过内部网络跨节点通信的复杂性。
从 Pod 的角度来看，它存在于本身的以太网命名空间中，必要与同一节点上的其他网络命名空间举行通信。值得庆幸的是，可以使用 Linux 捏造以太网装备或由两个捏造接口构成的 veth 对毗连命名空间，这些捏造接口可以分布在多个命名空间上。要毗连 Pod 命名空间，我们可以将 veth 对的一侧分配给根网络命名空间，将另一侧分配给 Pod 的网络命名空间。每对 veth 对的工作方式就像一根跳线，毗连两侧并允许流量在它们之间活动。这个设置可以复制到呆板上的尽可能多的 Pod。图 4 显示了将 VM 上的每个 Pod 毗连到根命名空间的 veth 对。
此时，我们已将 Pod 设置为每个都有本身的网络命名空间，以便它们信托本身拥有本身的以太网装备和 IP 地点，而且它们毗连到节点的根命名空间。现在，我们盼望 Pod 通过根命名空间相互通信，为此我们使用网桥。
Linux 以太网网桥是一个捏造的第 2 层网络装备，用于团结两个或多个网段，透明地工作以将两个网络毗连在一起。网桥通过查抄通过它的数据包的目的地并决定是否将数据包通报到毗连到网桥的其他网段来维护源和目的之间的转发表来运行。桥接代码通过查察网络中每个以太网装备的唯一 MAC 地点来决定是桥接数据还是抛弃数据。
网桥实现 ARP 协议以发现与给定 IP 地点关联的链路层 MAC 地点。当网桥吸取到数据帧时，网桥将帧广播到全部毗连的装备（原始发送者除外），响应该帧的装备存储在查找表中。具有雷同 IP 地点的将来流量使用查找表来发现将数据包转发到的精确 MAC 地点。
4.1、同节点Pod通信
给定将每个 Pod 与本身的网络堆栈隔离的网络命名空间、将每个命名空间毗连到根命名空间的捏造以太网装备以及将命名空间毗连在一起的网桥，我们终于准备幸亏同一节点上的 Pod 之间举行通信。这如图 6 所示。
在图 6 中，Pod 1 将数据包发送到它本身的以太网装备 eth0，该装备可用作 Pod 的默认装备。对于 Pod 1，eth0 通过捏造以太网装备毗连到根命名空间 veth0 (1)。网桥 cbr0 设置有 veth0 毗连到它的网段。一旦数据包到达网桥，网桥会分析精确的网段以使用 ARP 协议将数据包发送到 veth1 (3)。当数据包到达捏造装备 veth1 时，它被直接转发到 Pod 2 的命名空间和该命名空间内的 eth0 装备 (4)。在整个流量流中，每个 Pod 仅与 localhost 上的 eth0 通信，而且流量被路由到精确的 Pod。使用网络的开发体验是开发职员所盼望的默认举动。
Kubernetes 的网络模子规定 Pod 必须可以通过其 IP 地点跨节点访问。也就是说，一个 Pod 的 IP 地点始终对网络中的其他 Pod 可见，每个 Pod 对待本身的 IP 地点的方式与其他 Pod 对待它的方式雷同。我们现在转向差别节点上的 Pod 之间怎样举行通信的题目。
4.2、跨节点Pod通信
在研究了如安在同一节点上的 Pod 之间怎样举行通信之后，我们继承研究在差别节点上的 Pod 怎样举行通信。Kubernetes 网络模子要求 Pod IP 可以通过网络访问，但它没有指定必须怎样完成。
通常，集群中的每个node节点都分配有一个 CIDR（无种别域间路由，是一个用于给用户分配IP地点以及在互联网上有效地路由IP数据包的对IP地点举行归类的方法） 块，指定该节点上运行的 Pod 可用的 IP 地点。一旦流向 CIDR 块的流量到达节点，节点就有责任将流量转发到精确的 Pod。图 7 阐明了两个节点之间的流量流，假设网络可以将 CIDR 块中的流量路由到精确的节点。
图 7 以与图 6 雷同的哀求开始，但这次，目的 Pod（以绿色突出显示）与源 Pod（以蓝色突出显示）位于差别的节点上。数据包起首通过 Pod 1 的以太网装备发送，该装备与根命名空间 (1) 中的捏造以太网装备配对。终极，数据包终极到达根命名空间的网桥 (2)。ARP 将在网桥上失败，由于没有装备毗连到网桥并具有精确的数据包 MAC 地点。失败时，网桥将数据包发送到默认路由——根命名空间的 eth0 装备。此时路由脱离节点并进入网络 (3)。我们现在假设网络可以根据分配给节点的 CIDR 块将数据包路由到精确的节点 (4)。数据包进入目的节点的根命名空间（VM 2 上的 eth0），在那里它通过网桥路由到精确的捏造以太网装备 (5)。最后，路由通过位于 Pod 4 的命名空间 (6) 中的捏造以太网装备对来完成。一样平常来说，每个节点都知道怎样将数据包通报给在此中运行的 Pod。一旦数据包到达目的节点，数据包的活动方式与在同一节点上的 Pod 之间路由流量的方式雷同。
我们轻松地避开了怎样设置网络以将 Pod IP 的流量转发到负责这些 IP 的精确节点。这是特定于网络的，但查察特定示例将提供对所涉及题目的一些看法。比方，借助 AWS，Amazon 为 Kubernetes 维护了一个容器网络插件，允许节点到节点网络使用容器网络接口 (CNI) 插件在 Amazon VPC 情况中运行-vpc-cni-k8s。
容器网络接口 (CNI) 提供了一个通用 API，用于将容器毗连到外部网络。作为开发职员，我们想知道 Pod 可以使用 IP 地点与网络通信，而且我们盼望此操纵的机制是透明的。AWS 开发的 CNI 插件试图满足这些需求，同时通过 AWS 提供的现有 VPC、IAM 和安全组功能提供安全和可管理的情况，办理方案是使用弹性网络接口。
在 EC2 中，每个实例都绑定到一个弹性网络接口 (ENI)，而且全部 ENI 都毗连在一个 VPC 内——ENI 无需额外积极即可相互访问。默认情况下，每个 EC2 实例摆设一个 ENI，但您可以自由创建多个 ENI 并将它们摆设到您以为符合的 EC2 实例。实用于 Kubernetes 的 AWS CNI 插件通过为摆设到节点的每个 Pod 创建一个新的 ENI 来使用这种机动性。由于 VPC 中的 ENI 已经毗连到现有 AWS 底子设施中，以是这允许每个 Pod 的 IP 地点在 VPC 中当地可寻址。当 CNI 插件摆设到集群时，每个节点（EC2 实例）都会创建多个弹性网络接口并为这些实例分配 IP 地点，从而为每个节点形成一个 CIDR 块。摆设 Pod 时，作为 DaemonSet 摆设到 Kubernetes 集群的小型二进制文件会从 Nodes 当地 kubelet 进程吸取任何将 Pod 添加到网络的哀求。这个二进制文件从节点的可用 ENI 池中选择一个可用的 IP 地点，并通过在 Linux 内核中毗连捏造以太网装备和网桥将其分配给 Pod，如在同一节点内联网 Pod 时所述。有了这个，Pod 流量就可以跨集群内的节点路由。
5、Pod和Service之间网络通信
我们已经展示了如安在 Pod 及其关联的 IP 地点之间路由转发。在我们必要应对变革之前，这很有效。Pod IP 地点不是长期的，而且会随着扩展或缩减、应用步伐瓦解或节点重启而出现和消失。这些变乱中的每一个都可以使 Pod IP 地点在没有警告的情况下更改。Service被内置到 Kubernetes 中来办理这个题目。
Kubernetes Service 管理一组 Pod 的状态，允许您跟踪一组随时间动态变革的 Pod IP 地点。Service充当对 Pod 的抽象，并将单个捏造 IP 地点分配给一组 Pod IP 地点。任何发往 Service 捏造 IP 的流量都将被转发到与捏造 IP 关联的 Pod 集。这允许与 Service 关联的 Pod 集随时更改——客户端只必要知道 Service 的捏造 IP即可，它不会更改。
创建新的 Kubernetes Service时，会为您创建一个新的捏造 IP（也称为集群 IP）。在集群中的任何地方，发往捏造 IP 的流量都将负载均衡到与服务关联的一组支持 Pod。实际上，Kubernetes 会自动创建并维护一个分布式集群内负载均衡器，将流量分配到服务干系联的康健 Pod。让我们过细看看它是怎样工作的。
5.1、netfilter 和 iptables
为了在集群中执行负载均衡，Kubernetes 依靠于 Linux 内置的网络框架——netfilter。Netfilter 是 Linux 提供的一个框架，它允许以自定义处理惩罚步伐的情势实现各种与网络干系的操纵。Netfilter 为数据包过滤、网络地点转换和端口转换提供了各种功能和操纵，它们提供了引导数据包通过网络所需的功能，以及提供克制数据包到达盘算机网络中敏感位置的本领。
iptables 是一个用户空间步伐，它提供了一个基于表的系统，用于定义使用 netfilter 框架操纵和转换数据包的规则。在 Kubernetes 中，iptables 规则由 kube-proxy 控制器设置，该控制器监督 Kubernetes API 服务器的更改。当对 Service 或 Pod 的更改更新 Service 的捏造 IP 地点或 Pod 的 IP 地点时，iptables 规则会更新以精确地将指向 Service 的流量转发到精确的Pod。iptables 规则监督发往 Service 的捏造 IP 的流量，而且在匹配时，从可用 Pod 会集选择一个随机 Pod IP 地点，而且 iptables 规则将数据包的目的 IP 地点从 Service 的捏造 IP 更改为选定的 Pod。当 Pod 启动或关闭时，iptables 规则集会集会更新以反映集群不绝变革的状态。换句话说，iptables 已经在呆板上举行了负载均衡，以将定向到服务 IP 的流量转移到实际 pod 的 IP。
在返回路径上，IP 地点来自目的 Pod。在这种情况下，iptables 再次重写 IP 标头以将 Pod IP 更换为 Service 的 IP，以便 Pod 以为它不停只与 Service 的 IP 通信。
5.2、IPVS
Kubernetes 的最新版本 (1.11) 包罗用于集群内负载均衡的第二个选项：IPVS。IPVS（IP 捏造服务器）也构建在 netfilter 之上，并将传输层负载均衡作为 Linux 内核的一部分实现。IPVS 被归并到 LVS（Linux 捏造服务器）中，它在主机上运行并充认真实服务器集群前面的负载均衡器。IPVS 可以将基于 TCP 和 UDP 的服务的哀求定向到真实服务器，并使真实服务器的服务在单个 IP 地点上体现为捏造服务。这使得 IPVS 非常得当 Kubernetes 服务。
声明 Kubernetes Service时，您可以指定是否盼望使用 iptables 或 IPVS 完成集群内负载均衡。IPVS 专为负载均衡而计划，并使用更高效的数据结构（哈希表），与 iptables 相比允许险些无穷的规模。在使用 IPVS 创建负载均衡的 Service 时，会发生三件事：在 Node 上创建一个捏造 IPVS 接口，将 Service 的 IP 地点绑定到捏造 IPVS 接口，并为每个 Service IP 地点创建 IPVS 服务器。
将来，IPVS 有望成为集群内负载均衡的默认方法。此更改仅影响集群内负载均衡，而且在本指南的别的部分中，您可以安全地将 iptables 更换为 IPVS 以实现集群内负载均衡，而不会影响别的讨论。现在让我们看看通过集群内负载均衡服务的数据包的生命周期。
5.3、Pod和Service通信
在 Pod 和 Service 之间路由数据包时，与从前雷同的方式开始。数据包起首通过毗连到 Pod 的网络命名空间 (1) 的 eth0 接口脱离 Pod。然后它通过捏造以太网装备到达网桥 (2)。网桥上运行的 ARP 协议不知道 Service，因此它通过默认路由 eth0 (3) 将数据包传输出去。在这里，发生了一些差别的变乱。在 eth0 接受之前，数据包会通过 iptables 过滤。iptables 收到数据包后，使用 kube-proxy 安装在 Node 上的规则响应 Service 或 Pod 变乱，将数据包的目的地从 Service IP 重写为特定的 Pod IP（4）。数据包现在注定要到达 Pod 4，而不是服务的捏造 IP。iptables 使用 Linux 内核的 conntrack 实用步伐来记取所做的 Pod 选择，以便将来的流量路由到同一个 Pod（除非发生任何扩展变乱）。本质上，iptables 直接在 Node 上做了集群内负载均衡。然后流量使用我们已经查抄过的 Pod 到 Pod 路由流向 Pod (5)。
5.4、Service和Pod通信
收到此数据包的 Pod 将响应，将源 IP 辨以为本身的 IP，将目的 IP 辨以为最初发送数据包的 Pod (1)。进入节点后，数据包流经 iptables，它使用 conntrack 记取它之前所做的选择，并将数据包的源重写为服务的 IP 而不是 Pod 的 IP (2)。从这里开始，数据包通过网桥流向与 Pod 的命名空间配对的捏造以太网装备 (3)，然后流向我们之前看到的 Pod 的以太网装备 (4)。
5.5、使用DNS
Kubernetes 可以选择使用 DNS 来制止将服务的集群 IP 地点硬编码到您的应用步伐中。Kubernetes DNS 作为在集群上调治的通例 Kubernetes 服务运行。它设置在每个节点上运行的 kubelet，以便容器使用 DNS 服务的 IP 来分析 DNS 名称。集群中定义的每个服务（包罗 DNS 服务器本身）都被分配了一个 DNS 名称。DNS 记录将 DNS 名称分析为服务的集群 IP 或 POD 的 IP，详细取决于您的必要。SRV 记任命于指定运行服务的特定命名端口。
DNS Pod 由三个独立的容器构成：
kubedns：监督 Kubernetes 主服务器的服务和端点变革，并维护内存中的查找结构以服务 DNS 哀求。
dnsmasq：添加 DNS 缓存以进步性能。
sidecar：提供一个单一的康健查抄端点来执行 dnsmasq 和 kubedns 的康健查抄。
DNS Pod 本身作为 Kubernetes 服务公开，具有静态集群 IP，该 IP 在启动时通报给每个正在运行的容器，以便每个容器都可以分析 DNS 条目。DNS 条目通过维护内存中 DNS 体现的 kubedns 系统分析。etcd 是集群状态的后端存储系统，kubedns 使用一个库将 etcd 键值存储转换为 DNS 团体，以便在须要时重修内存中 DNS 查找结构的状态。
CoreDNS 与 kubedns 的工作方式雷同，但使用插件架构构建，使其更加机动。从 Kubernetes 1.11 开始，CoreDNS 是 Kubernetes 的默认 DNS 实现。
6、Internet和Service之间网络通信
从节点到公共 Internet 的流量转发是特定于网络的，而且实际上取决于您的网络怎样设置以发布流量。为了使本节更加详细，我将使用 AWS VPC 来讨论任何详细细节。
在 AWS 中，Kubernetes 集群在 VPC 中运行，此中每个节点都分配有一个私有 IP 地点，该地点可从 Kubernetes 集群内访问。要从集群外部访问流量，您必要将 Internet 网关毗连到您的 VPC。Internet 网关有两个用途：在您的 VPC 路由表中为可路由到 Internet 的流量提供目的，以及为已分配公共 IP 地点的任何实例执行网络地点转换 (NAT)。NAT 转换负责将集群专用的节点内部 IP 地点更改为公共 Internet 中可用的外部 IP 地点。
有了 Internet 网关，VM 就可以自由地将流量路由到 Internet。不幸的是，有一个小题目。Pod 有本身的 IP 地点，与托管 Pod 的节点的 IP 地点差别，而且 Internet 网关的 NAT 转换仅实用于 VM IP 地点，由于它不知道 Pod 正在运行什么哪些捏造机——网关不支持容器。让我们看看 Kubernetes 怎样使用 iptables 办理这个题目（再次）。
6.1.1、Node和Internet通信
在下图中，数据包源自 Pod 的命名空间 (1)，并颠末毗连到根命名空间 (2) 的 veth 对。一旦进入根命名空间，数据包就会从网桥移动到默认装备，由于数据包上的 IP 与毗连到网桥的任何网段都不匹配。在到达根命名空间的以太网装备 (3) 之前，iptables 会粉碎数据包 (3)。在这种情况下，数据包的源 IP 地点是 Pod，如果我们将源生存为 Pod，Internet 网关将拒绝它，由于网关 NAT 只了解毗连到 VM 的 IP 地点。办理方案是让 iptables 执行源 NAT——更改数据包源——使数据包看起来来自 VM 而不是 Pod。有了精确的源 IP，数据包现在可以脱离 VM (4) 并到达 Internet 网关 (5)。Internet 网关将执行另一个 NAT，将源 IP 从 VM 内部 IP 重写为外部 IP。最后，数据包将到达公共 Internet (6)。在返回的路上，数据包依照雷同的路径，而且任何源 IP 修改都被撤消，以便系统的每一层都吸取到它理解的 IP 地点：节点或 VM 级别的 VM 内部，以及 Pod 内的 Pod IP命名空间。
让我们看看这在实践中是怎样工作的。摆设服务后，您正在使用的云提供商将为您创建一个新的负载均衡器 (1)。由于负载均衡器不支持容器，以是一旦流量到达负载均衡器，它就会分布在构成集群的全部捏造机中 (2)。每个 VM 上的 iptables 规则会将来自尊载均衡器的传入流量引导到精确的 Pod (3) — 这些是在服务创建期间实验并在前面讨论过的雷同 IP 表规则。Pod 到客户端的响应将返回 Pod 的 IP，但客户端必要有负载均衡器的 IP 地点。正如我们之前看到的，iptables 和 conntrack 用于在返回路径上精确重写 IP。
下图显示了托管 Pod 的三个 VM 前面的网络负载均衡器。传入流量 (1) 指向您的服务的负载均衡器。一旦负载均衡器收到数据包 (2)，它就会随机选择一个 VM。在这种情况下，我们病态地选择了没有运行 Pod 的 VM：VM 2 (3)。在这里，运行在 VM 上的 iptables 规则将使用 kube-proxy 安装到集群中的内部负载均衡规则将数据包定向到精确的 Pod。iptables 执行精确的 NAT 并将数据包转发到精确的 Pod (4)。
6.2.3、七层转发-Ingress Controller
第 7 层网络 Ingress 在网络堆栈的 HTTP/HTTPS 协议范围内运行，并构建在 Services 之上。启用 Ingress 的第一步是使用 Kubernetes 中的 NodePort 服务范例在您的服务上打开一个端口。如果将 Service 的 type 字段设置为 NodePort，Kubernetes master 将从您指定的范围内分配一个端口，而且每个 Node 都会将该端口（每个 Node 上的雷同端标语）署理到您的 Service 中。也就是说，任何指向节点端口的流量都将使用 iptables 规则转发到服务。这个 Service 到 Pod 的路由依照我们在将流量从 Service 路由到 Pod 时已经讨论过的雷同的内部集群负载均衡模式。
要向 Internet 公开节点的端口，您必要使用 Ingress 对象。Ingress 是一个更高级别的 HTTP 负载均衡器，它将 HTTP 哀求映射到 Kubernetes 服务。Ingress 方法将根据 Kubernetes 云提供商控制器的实现方式而有所差别。HTTP 负载均衡器，如第 4 层网络负载均衡器，仅了解节点 IP（而不是 Pod IP），因此流量路由同样使用由 kube-proxy 安装在每个节点上的 iptables 规则提供的内部负载均衡。
在 AWS 情况中，ALB 入口控制器使用 Amazon 的第 7 层应用步伐负载均衡器提供 Kubernetes 入口。下图详细介绍了此控制器创建的 AWS 组件。它还演示了 Ingress 流量从 ALB 到 Kubernetes 集群的路由。
Nat网络地点转换
NAT 或网络地点转换是将一个地点空间重新映射到另一个地点空间的 IP 级别。映射通过在数据包通过流量路由装备传输时修改数据包的 IP 标头中的网络地点信息来实现。
根本 NAT 是从一个 IP 地点到另一个 IP 地点的简朴映射。更常见的是，NAT 用于将多个私有 IP 地点映射到一个公开的 IP 地点。通常，当地网络使用私有 IP 地点空间，而且该网络上的路由器在该空间中被赋予私有地点。然后路由器使用公共 IP 地点毗连到 Internet。当流量从当地网络通报到 Internet 时，每个数据包的源地点都从私有地点转换为公共地点，这使得哀求看起来好像直接来自路由器。路由器维护毗连跟踪，以将复兴转发到当地网络上的精确专用 IP。
NAT 提供了一个额外的利益，即允许大型专用网络使用单个公共 IP 地点毗连到 Internet，从而节省公共使用的 IP 地点的数目。
snat-源地点转换
SNAT 只是指修改 IP 数据包源地点的 NAT 过程。这是上述 NAT 的典范举动。
dnat-目的地点转换
DNAT 是指修改 IP 数据包的目的地点的 NAT 过程。DNAT 用于将位于专用网络中的服务发布到可公开寻址的 IP 地点。
