本文翻译回：Kubernetes中的数据包的生命 - 第3部分[1]
作者：Dinesh Kumar Ramasamy
本文根据原始文本进行了适当的修改。如果您有任何疑问，请参考原始文本。
本文是Kubernetes中数据包的生命周期系列的一部分。我们将讨论如何使用Kubernetes组件来控制流量。这对于了解Kubernetes环境中的作用以及如何控制流量很重要。
本文包含以下各章：
请勿参与POD之间的通信，因为CNI将配置为节点和POD。所有容器都可以与没有NAT的其他容器进行通信。所有节点都可以与没有NAT的容器进行通信（反之亦然）。
注意：POD的IP地址不是静态的（静态IP有多种配置方法，但是默认配置不能保证静态IP地址）。当POD重新启动时，CNI将为POD分配一个新的IP地址，因为CNI CNI确实可以不维护POD和IP地址之间的映射关系。此外，通过部署方法部署的POD的名称不是静态的。
实际上，通过部署部署的POD应使用负载平衡实体发布服务，因为该应用程序是无状态的，并且通常有多个POD托管应用程序。负载平衡器类型的实体在Kubernetes中称为服务。
对于从POD到外部地址的流量，Kubernetes使用SNAT（源地址转换）。它是替换pod ip：pod ip：端口到主机ip：port。数据包中的端口为POD IP：端口，并将数据包发送回原始POD。整个过程都透明了原始POD，并且POD不知道已发生地址转换。
Kubernetes有一个名为“服务”的概念，即Pod前面的L4负载平衡器。Kubernetes中有几种不同类型的服务。最基本的类型称为clusterip。此类型的服务具有独特的VIP地址，只能在集群中路由。
通过POD IP将流量发送到特定应用程序并不容易。Kubernetes群集的动态特性意味着可以移动，重新启动，升级或扩展POD。此外，一些服务将有许多副本，因此我们需要一些方法，因此我们需要一些方法。平衡它们之间的负载。
Kubernetes通过服务解决此问题。服务是一个API对象，它将单个虚拟IP（VIP）映射到一组POD IP.IN添加，Kubernetes还为每个服务VIP提供DNS解析条目，以便您可以轻松地访问服务服务通过域名。
群集中从VIP到POD IP的映射由每个节点上的进程协调。Kube-Proxy通过设置IPTABLES或IPVS规则将服务VIP请求的目标地址转换为POD IP。请求请求的连接将为跟踪，因此，当数据包从POD中返回时，可以将其正确转换为服务的VIP并响应客户端。IPVS和IPTABLES可以平衡单个服务的VIP负载到多个POD IPS。IPV和IPTABLE具有更好的性能和更灵活的负载平衡算法。
接下来，创建两个部署两个部署，并使用clusterip类型服务通过clusterip类型进行平衡。
前端部署：
后端部署：
服务：
前端POD可以通过clusterip或kubernetes添加的DNS条目访问后端。群集感知的DNS服务器（例如coredns），Monitor kubernetes api以获取新创建的服务并为每种服务创建一组DNS记录。
“普通”服务（无头服务除外）将以此名称的形式分配DNS记录。该名称将被解析为与该服务相对应的群集。
现在，我们可以通过群集内的VIP或域名访问服务。
让我们创建一个nodeport -type服务，以公开集群外的弗罗斯顿服务。如果设置了服务字段，Kubernetes将为服务分配一个随机端口。该端口的默认范围为30000-32767，可以设置该端口通过API服务器的参数，EAST节点将充当访问NodePort端口（每个端的相同数字）的请求。
现在我们可以在集群外面传递 <任何一个节点 IP>路口
外部Trafficpolicy表示，该服务是否希望将外部流程路由乘坐到节点或群集范围的端点。本地表示客户端的源IP保留，并且NodePort或LoadBalancer的服务不会将流量分配给其他节点上的PODS。这可以避免其他网络跳跃。在同一TimeEssenceCluster上，隐藏了客户端的源IP，并可能将流量分配给其他节点上的POD。目前，将生成其他网络跳跃，但这将具有良好的总体负载余额。
集群流量策略是Kubernetes服务的默认外部Trafficpolicy策略。您始终想平衡与所服务的所有POD的流量。
使用此策略的预防措施是，当您访问nodePort服务外部流量外服务时，您可能会看到节点之间的不必要的网络跳跃点。例如，当通过NodePort接收外部流量时，NodePort服务可能（随机）到另一个主机上的PODS，它最初可以将流量路由放在同一主机上的POD上，以避免其他网络跳跃。
集群流量策略中数据包的流量如下：
当使用本地流量策略策略时，Kube-Proxy将仅针对同一节点（本地）POD添加代理规则，而不是为每个服务的每个POD添加代理规则。这次，Kube-Proxy仅将请求替换为本地终点无需转发流向其他节点。该端点可以保留原始的源IP地址。如果没有局部端点，请丢弃发送到节点的数据包。
如果您尝试将其设置为serivce，则Kubernetes API会要求您使用LoadBalancer或NodePort类型服务。这是因为本地模式的外部Trafficpolicy策略仅与外部流量有关，因此仅适用于这两种类型服务。
本地流量策略中数据包的流量如下：
当您设置Service Kubernetes服务（例如Google Kubernetes Engine（GCE）时，当您将其设置在节点中时，将没有与Node中对应的POD相对应的POD。丢弃数据包。此模型非常适合大量访问，同时，希望避免网络上不必要的跳跃点以减少延迟应用程序。在同一时间，我们也可以保留真实客户端IP，因为我们不再需要来自代理节点的SNAT流量！但是，如Kubernetes文档中提到的那样，使用本地流量策略策略的最大缺点是应用程序的流量可能是不平衡的。
kubernetes实现了一个名为kube-proxy的服务组件。Kubernetes或其他程序插入的iPtables规则是最重要的链条。
对于DNAT，Conntrack将跟踪连接状态，因为它需要记住修改的目标地址，以便在数据包返回时可以更改数据包。Iptables也可以依靠Conntrack状态（CTSTTATE）来确定数据包的命运。4 Conntrack状态尤其重要：
以下是在POD和服务之间连接的一种方法。事件的顺序如下：
GIF移动地图演示：
它是用于控制，修改和过滤Linux内核中数据包的框架。它是配置过滤器函数的用户空间工具。
iptables中有5条链，每个链都负责一项特定任务：
仅在启用Linux服务器时，向前链有效。这就是为什么在设置和调试Kubernetes群集时以下命令很重要的原因。
上述命令的修改不是永久性的。要永久启用Linux系统上的IP转发，请编辑/etc/sysctl.conf并添加以下内容：
iptables中有5个表：
让我们部署一个带有Kubernetes中2副本的NGINX应用程序，然后检查Iptables规则。服务类型：NodePort。
主机接口上不存在clusterip。它的虚拟IP存在于iPtables规则中，并将以下DNS条目添加到核心。
Kubernetes在Iptables中创建了Kube-Services链以过滤和NAT进行数据包，它将将所有预先访问和输出链的流量重定向到Kube-Services链。
在使用Kube-Services链中进行包装和NAT之后，Kubernetes可以检查服务的流量并相应地应用SNAT/DNAT。在Kube-Services链的末端，它将插入另一个自定义的链条kube-nodeports来处理服务服务类型的类型。
如果流量用于集群，则Kube-SVC-2iracualRelarsnd链将处理流量；否则，下一个链将处理流量，即Kube-Nodeports。
让我们检查Kube-Nodeports链。
您会看到Kube-Nodeports链最终将将流量发送到Kube-SVC-2iracualRelarsnd链。
摘要：聚类：Kube-Services→Kube-SVC-XXX→kube-sep-xxx.nodeport：kube-services→kube-nodeports→kube-nodeports→kube-svc-xxx→kube-sep-xxx。
注意：NodePort类型的服务将分配群集以处理内部和外部流量。
上述规则的示意图如下：
外部肢发液：如前所述，本地局部使用，使用externalTrafficPolicy：本地将保留源IP并丢弃数据包，而无需局部端点。LET介绍没有本地端点的节点中的iptables规则。
这次仅部署了一个Nginx POD，并且该服务设置为外部Trafficpolicy：local。
检查外部恐怖分子。
获得服务。
让我们检查Minikube-M02节点中的Iptables规则。由于节点上没有nginx pod，因此应该有一个丢弃数据包的掉落规则。
检查Kube-XLB-2iracualRelarsnd链。
检查Minikube节点的Iptables，该节点上有Nginx Pod，因此您不会丢弃数据包。
某些应用程序不需要负载平衡和服务IP。在这种情况下，您可以使用无头服务，只要设置为即可。
您可以使用这种类型的服务类型和其他服务来发现无需绑定Kubernetes的机制来协作。无头服务不会分配群集IP。Kube-Proxy将无法处理它们，并且该平台将不会为其执行负载平衡和路线。此外，应根据选择器确定DNS的配置。
使用选择器（选择器）服务
选择器的无头服务，端点控制器将创建端点记录并修改DNS记录。可以直接通过域名访问的背端POD。
没有选择设备服务
没有选择器无头服务的定义，也没有端点记录。但是，DNS系统将尝试配置：
到目前为止，您可能已经了解了如何实现Kubernetes中的网络策略。CNI负责实施网络策略，而不是Kube-Proxy。
让我们创建3个服务：Frontend，Backen和DB。默认情况下，POD不隔离；他们接受来自任何来源的流量。
但是，应该有一种网络策略将DB POD与冻伤舱分离，以避免它们之间的任何流量。
我们可以通过设置网络电池来实现网络策略。如果访问的豆荚具有标签，则允许访问DB。
应用上面的网络电池，您可以看到前端可以正常访问后端，但是不再不可能访问DB。
但是后端仍然可以访问DB。
如果使用的CNI是印花布，Calico将将Kubernetes的网络策略转换为印花布格式。
使用Calicoctl获取工作负载终点的详细信息。
Cali95AA86CBB2A是DB Pod.LET的VETH对的主机端。
印花布将IPSET用于流量管理。IPSET是Iptables的扩展。有几个优势：
通过检查IPSET，很明显，您只能从后端POD的IP 10.88.0.27中访问DB POD。