主机频道
总结：当应用程序被访问时，流量经过表中的规则链处理，跳转到子链。 该链包含特定处理的规则。 仔细检查您的防火墙规则，找出要通过的模块并以平衡的方式分配流量。 换句话说，负载均衡模式就是轮训。
简介
在K8S集群中，应用程序经常使用服务与各个集群进行通信。 此外，了解服务技术的优点和缺点可以帮助您规划和部署应用程序。 考虑到这一点，本文使用一个简单的案例来考虑Cluster-Ip类型Services服务的优缺点。
为了便于解释，首先创建以下应用程序和服务服务。
# kubectl run --image=nginx nginx[ k4 ]web-1 --image-pull-policy="IfNotPresent"# kubectl 发布部署 nginx-web-1 --port=80 [k4 ] -target-port=80
服务探索
作者的K8S环境是。 在 1.9 版本中，service内部服务由 Kube-Proxy1 提供并使用将会完成。 默认情况下它是>iptables技术的实现，因此本文将重点介绍K8S集群的service技术，即 iptables >我们会调查。 K8S技术实现。
服务路由（Service Routing）
如下图后端pod实际上可以通过nginx-web-1服务访问：
# nginx pod ip address: # 描述kubectl pod nginx-web-1-fb8d45f5f-dcbtt。 grep "IP" IP: 10.129.1.22# Service服务，通过172.30.132.253:80，实际访问是10.129.1.22:80# kubectl描述 svc nginx-web-1 ... 这样回车。 ClusterIPIP: 172.30.132.253Port: 80/TCPTargetPort: 80/TCPEndpoints: 10.129.1.22:80Session Affinity: None...# Reset nginx web page :# kubectl exec -it nginx-web[k4 ] 1-fb8d45f5f-dcbtt -- sh -c "echo hello>/usr/share/nginx/html/index .html"#curl 10.129.1.22hello#curl 172.30.132.253hello
服务CLUSTER-IP以及服务分配的监听端口都是虚拟的。 也就是说，在 K8S 集群节点上都找不到 ip a 和 netstat -an 命令。事实上，IP和端口是由iptables在每个K8S节点上设置的。 在节点上运行以下命令以查找与此服务相关的iptables设置。 这是一个快速分析：
当经过Service访问Service时IP：172.30.132.253:80，匹配3后跳转到规则链（KUBE-SERVICES），子链4（KUBE-SVC-...）。 );
对子链4链进行快速评论后，跳转到1, 2规则链（ KUBE-SEP-...);
源Pod通过Service访问自身时，匹配1 规则并跳转到链中的KUBE-MARK -MASQ。
匹配 2。 它遵循规则并通过 DNATPod: 108.29.1.22:80 重定向到后端。
# iptables-save | grep nginx-web-1-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m评论 - - 评论 "demo/nginx- ]web-1:" -j KUBE-MARK-MASQ-A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m 评论 --评论 "demo/nginx[ k4]web-1：“-m tcp -j DNAT --到-到 10.129.1.22:80-A KUBE-服务 -d 172.30。 132.253/32 -p tcp -m 注释 --注释 "demo/nginx-web-1: 集群 IP" -m tcp --dport 80 [ k4]j KUBE-SVC-SNP24T7IBBNZDJ76-A KUBE-SVC-SNP24T7IBBNZDJ76 -m 评论 --评论“demo/nginx-web-1: " -j KUBE-SEP-UWNFTKZFYWNNNTK7
详细分析 iptables 规则并运行 iptables-save 两个 < nat 中的 em>PREROUTING 和 OUTPUT 链有一个 KUBE-SERVICES 规则链，
*nat-A PREROUTING -m 评论 --评论“kubernetes 服务门户”-j KUBE-SERVICES-A OUTPUT -m comment --comment "kubernetes service ports" -j KUBE-SERVICES
Services如果您通过 After 访问您的应用程序处理流量 nat 表的 PREROUTING 规则链，我们跳转到 KUBE-SERVICES 子链。 该链包括特定的服务处理规则。 如下所示，对172.30.132.253:80的访问被重定向到KUBE-SEP-...子规则链。
-A KUBE-服务 -d 172.30.132.253/32 -p tcp -m 评论 --评论“demo/nginx-web -1: 集群 IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76-A KUBE-SVC-SNP24T7IBBNZDJ76 - m Comment --Comment "demo/nginx-web-1:" -j KUBE-SEP-UWNFTKZFYWNNNTK7
如下图， >KUBE-SEP-...子链有两条规则：
规则1：Pod访问时匹配本身通过服务。 这条规则（只需标记MARK）处理；
规则2：通过DNAT到后端Pod重定向。 实例，此时流量最终通过Service到达后端实例；
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129 已发送。 1.22/32 -m 评论 --评论“demo/nginx-web-1:”-j KUBE-MARK-MASQ-A KUBE- SEP-UWNFTKZFYWNNNTK7 -p tcp -m 评论 --评论“demo/nginx-web-1:”-m tcp -j DNAT - [ k4]到-目的地 10.129.1.22:80-A KUBE-MARK-MASQ -j MARK --set-xmark 0x1/0x1
负载均衡
要将Deployment部署到3pods，请执行以下操作：命令。 这里我们将研究与服务技术和负载平衡相关的问题。
# kubectlscaledeploy/nginx-web-1 --replicas=3
再次转储防火墙规则。 ，通过iptables的统计模块发现服务。区块以平衡方式随机分布。 换句话说，负载均衡的模式就是轮训。
DNAT和KUBE-MARK-MASQ有3条规则，对应于 各 3 个。 后端pod的真实地址；
KUBE-SERVICES有3条子链。 chain ，除了最后一个KUBE-SVC-...子链，其余子链都使用模块statistic<我会的随机模式。 /strong> 流量拆分或负载平衡：文章1应用33% 的KUBE-SVC-...流量； 2KUBE-SVC-...该规则将应用于剩余的50%流量。 3 >strong>KUBE-SVC-...该规则应用于最后一个流量。
# iptables-save | grep nginx-web-1-A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m评论 --评论 "demo/nginx- ]web-1:" -j KUBE-MARK-MASQ-AKUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m 评论 --评论“demo/nginx-web-1:”-m tcp -j DNAT --目的地 10.129.1.27:80-A KUBE-SEP-CDQIKEVSTA766BRK -s 10.129.1.28/32 -m 评论 --评论“demo/nginx -web-1:" -j KUBE-MARK-MASQ-A KUBE-SEP-CDQIKEVSTA766BRK -p tcp -m 评论 -[ k4]注释“demo/nginx-web-1：”-m tcp -j DNAT --到-目的地10.129.1.28:80- A KUBE[k4 ]SEP-W5HTO42ZVNHJQWBG -s 10.129.3.57/32 -m 评论 --评论“demo/nginx-web-1:”-j KUBE -MARK -MASQ-A KUBE-SEP-W5HTO42ZVNHJQWBG -p tcp -m 评论 --评论“demo/nginx-web-1 :”[k4 ]m tcp -j DNAT --到-目的地 10.129.3.57:80-A KUBE-]Service -d 172.30.132.253/32 -p tcp -m Comment --Comment "demo/nginx-web-1: 集群 IP" -m tcp [ k4]-dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76-A KUBE-SVC-SNP24T7IBBNZDJ76 -m 评论 --评论“demo/nginx[ k4]web-1:" -m 统计数据 --模式随机 --概率 0.33332999982 -j KUBE-SEP-BI762VOIAZZWU5S7-A KUBE[k4 ] ]SVC-SNP24T7IBBNZDJ76 -m 评论 --评论“demo/nginx-web-1:” -m 统计数据 --模式随机 -[ k4] ]概率 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK-A KUBE-SVC-SNP24T7IBBNZDJ76 -m 评论 --评论“demo/nginx- web[ k4]1:" -j KUBE-SEP-W5HTO42ZVNHJQWBG
会话亲和性（会话持久性）
下面调整和打开 Service 服务，如图所示会话保留功能。 将会话保留期设置为3小时（PS：如果未设置，默认为3小时）。
# kubectl edit svc nginx-web-1... sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800...
iptables实现发现原始基础最近将模块添加到iptables规则中。 该模块用于会话持久化功能，因此与 kube-proxyiptables< 的 Statistics 和 Recents 模块结合起来， /em>、服务实现轮流负载平衡和会话并继续运行。
服务 通过服务访问应用程序。 数据包进入KUBE-SERVICES规则链，并跳转到子链中的KUBE-SVC[ k4]...。
KUBE-SVC-SNP...子链有最近统计数据在前面。 strong> 模块，出现以下情况：
当客户端第一次访问服务时，KUBE-SVC-...子链规则（ > >-m 最后 --r检查 -- 秒10800 --reap...--rsource) 数据包匹配失败，因为客户端地址没有记录在池中，并且数据包被阻塞。 一旦处理完统计模块规则，它们就会均匀分布在KUBE-SEP-...子链上。 该链使用最近模块--设置参数记录规则池中的客户源地址，并将其更改为真实地址记录DNAT。 >s。 后端实例；
KUBE-SVC-...子链中最近模块由源地址记录组成，已用于一段时间。 如果客户端3（如果它没有在-[ k4]秒10800 --闰内访问服务）时间，则客户端>最近规则池将被删除。 在这种情况下，客户端再次访问服务与第一次访问服务是一样的。
当客户端再次访问服务时，KUBE-SVC-... 会匹配子最近模块规则。跳转到KUBE-SEP子链后3小时内，规则中最近模块 --set 参数已更新。 记录规则池中的TTL到DNAT；
# iptab到实际后端实例les-保存 | grep nginx-web-1-A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m 评论 --评论“演示/nginx-]web-1：”-j KUBE-MARK-MASQ-A KUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m评论 -- 评论 "demo/nginx-web-1:" -m 最近 --设置 --name KUBE-SEP-BI762VOIAZZWU5S7 [ k4]-mask 255.255.255.255 --rsource -m tcp -j DNAT --to-destination 10.129.1.27:80# 两个相似的 KUBE[ 省略 k4 ]SEP 规则...[ k4]A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m 评论 -- 评论“demo/nginx -web [ k4]1：集群 IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76-A KUBE-SVC- SNP24T7IBBNZDJ76 - m评论 -- 评论 "demo/nginx-web-1:" -最近--rcheck -- 秒 10800 --leap --名称 KUBE-SEP-BI762VOIAZZWU5S7 --掩码 255.255.255.255 --rsource [ k4]j KUBE-SEP-BI762VOIAZZWU5S7# 省略两条类似的 KUBE-SVC 规则...-A KUBE-SVC-SNP24T7IBBNZDJ76 -m 评论 [k4 ]-评论“demo/nginx-web-1：”-m 统计数据 --模式随机 --概率 0.33332999982 -j KUBE-SEP[ k4]BI762VOIAZZWU5S7 [k4 ] ]A KUBE-SVC-SNP24T7IBBNZDJ76 -m 评论 --评论“demo/nginx-web-1:” -m 统计信息 - ]-模式 随机 --概率 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK-A KUBE-SVC-SNP24T7IBBNZDJ76 -m 评论 -[k4 ]评论“演示/nginx -web-1:" -j KUBE-SEP-W5HTO42ZVNHJQWBG
摘要
K8S> 服务服务可以提供负载均衡平衡和会话持久功能是通过 Linux 内核中的 netfilter 模块配置 iptables 来实现的。 网络数据包流经内核，但很少符合规则。 因此，效率非常高。 Service的负载均衡分布比较弱，但是我们通过Statistics中的Random规则实现了轮训分布，无法实现复杂的任务，例如 强大的最小链接分发方法。 考虑到这一点，我们在 K8S 1.9 的后续版本中调整了 kube- 代理服务。 实现ipvsservice负载均衡功能。
在K8S 1.9版本中，kube-router可以用来替代kube-proxy和ipvs，你可以使用. 替换iptables并实现service服务。 ↩
评论前必须登录！
注册