-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathservice-advanced-topics.html
More file actions
1590 lines (1422 loc) · 67 KB
/
Copy pathservice-advanced-topics.html
File metadata and controls
1590 lines (1422 loc) · 67 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Kubernetes Service 高级主题 | K8S 网络原理</title>
<link rel="stylesheet" href="css/style.css">
<script src="js/main.js" defer></script>
</head>
<body>
<header>
<div class="container">
<h1>Kubernetes (K8S) 网络原理</h1>
<nav>
<ul>
<li><a href="index.html">首页</a></li>
<li><a href="pod-network.html">Pod 网络</a></li>
<li><a href="service-network.html">Service 网络</a></li>
<li><a href="ingress.html">Ingress</a></li>
<li><a href="cni.html">CNI 插件</a></li>
<li><a href="experiments.html">动手实验</a></li>
</ul>
</nav>
</div>
</header>
<main class="container">
<section class="intro">
<h2>Kubernetes Service 高级主题</h2>
<p>本文将深入探讨 Kubernetes Service 的高级特性、优化技巧和专家级最佳实践，帮助您充分掌握 Service 机制并解决复杂的生产环境网络问题。适合已经熟悉 Service 基础知识的读者进一步提升。</p>
<div class="diagram-container">
<object type="image/svg+xml" data="svg/service-advanced-overview.svg" class="diagram">
Service 高级特性概览
</object>
</div>
</section>
<section>
<h2>Service 内部机制深度剖析</h2>
<h3>核心组件和交互流程</h3>
<p>Service 的实现涉及多个组件的协同工作，下面我们将分析这些组件间的详细交互流程：</p>
<div class="diagram-container">
<object type="image/svg+xml" data="svg/service-components-interaction.svg" class="diagram">
Service 组件交互流程
</object>
</div>
<ol>
<li><strong>API Server</strong>: 接收和验证 Service 资源对象的创建/更新/删除请求，将结果持久化到 etcd</li>
<li><strong>Controller Manager</strong>: Service 控制器监听 Service 和 Pod 变化，维护 Endpoints 或 EndpointSlices 对象</li>
<li><strong>kube-proxy</strong>: 监听 Service、Endpoints/EndpointSlices 变化，在节点上配置网络规则</li>
<li><strong>CoreDNS</strong>: 监听 Service 变化，动态更新 DNS 记录</li>
<li><strong>Cloud Controller Manager</strong>: 对于 LoadBalancer 类型，与云平台交互创建负载均衡器</li>
</ol>
<h3>Service、Endpoints 和 EndpointSlices</h3>
<p>理解这三种资源对象的关系对于掌握 Service 机制至关重要：</p>
<div class="tab-container">
<div class="tabs">
<div class="tab active">Service</div>
<div class="tab">Endpoints</div>
<div class="tab">EndpointSlices</div>
</div>
<div class="tab-content">
<div class="tab-pane active">
<h4>Service 资源解析</h4>
<p>Service 定义了一个抽象：如何访问一组 Pod 以及这些 Pod 提供什么类型的网络服务。</p>
<div class="code-block">
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: default
# 重要注解字段示例
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
spec:
selector:
app: MyApp # 选择后端 Pod 的标签
ports:
- name: http # 端口名称，多端口时必须
protocol: TCP # 协议：TCP、UDP 或 SCTP
port: 80 # Service 暴露的端口
targetPort: http # 目标容器端口（可以是数字或命名端口）
nodePort: 30080 # 节点端口（NodePort 和 LoadBalancer 类型）
type: ClusterIP # Service 类型
clusterIP: 10.96.10.10 # 可选：指定 ClusterIP（None 表示 Headless）
# 高级选项
externalTrafficPolicy: Cluster # 外部流量路由策略：Cluster 或 Local
sessionAffinity: None # 会话亲和性：None 或 ClientIP
sessionAffinityConfig: # 会话亲和性配置
clientIP:
timeoutSeconds: 10800 # 会话粘性超时时间
publishNotReadyAddresses: false # 是否发布未就绪的端点
ipFamilies: # IP 协议族：IPv4 和/或 IPv6
- IPv4
ipFamilyPolicy: SingleStack # IP 协议族策略
loadBalancerSourceRanges: # LoadBalancer 流量源 IP 限制
- 203.0.113.0/24
externalName: example.com # ExternalName 类型的目标域名
allocateLoadBalancerNodePorts: true # 是否分配 LoadBalancer NodePort
loadBalancerClass: service.k8s.aws/nlb # LoadBalancer 类型指定
</div>
<p><strong>高级功能字段解析：</strong></p>
<ul>
<li><code>publishNotReadyAddresses</code>：设为 true 时，即使 Pod 未就绪也会被添加到 Endpoints 中，适用于有状态应用的发现</li>
<li><code>ipFamilyPolicy</code>：控制 Service 的 IP 协议族支持策略（SingleStack、PreferDualStack、RequireDualStack）</li>
<li><code>allocateLoadBalancerNodePorts</code>：LoadBalancer 类型是否分配 NodePort，从 Kubernetes 1.20 引入</li>
<li><code>loadBalancerClass</code>：指定 LoadBalancer 的实现类，从 Kubernetes 1.22 引入</li>
</ul>
</div>
<div class="tab-pane">
<h4>Endpoints 资源解析</h4>
<p>Endpoints 对象包含 Service 后端的实际 Pod IP 地址和端口列表。当 Service 使用选择器时，系统自动创建和维护 Endpoints。</p>
<div class="code-block">
apiVersion: v1
kind: Endpoints
metadata:
name: my-service # 必须与 Service 名称相同
namespace: default
labels:
service: my-service # 常见约定但非必须
annotations:
endpoints.kubernetes.io/last-change-trigger-time: "2023-01-01T10:00:00Z"
subsets:
- addresses: # 就绪端点的地址列表
- ip: 10.244.0.5 # Pod IP 地址
nodeName: node-1 # Pod 所在节点
targetRef:
kind: Pod
name: my-pod-1
namespace: default
uid: d7e8d56f-c87e-4c1a-8c1f-6412a788acd9
- ip: 10.244.0.6
nodeName: node-2
targetRef:
kind: Pod
name: my-pod-2
namespace: default
uid: a4d45f3e-b7c8-4d3e-9e8f-2a1b3c4d5e6f
notReadyAddresses: # 未就绪端点的地址列表
- ip: 10.244.0.7
nodeName: node-3
targetRef:
kind: Pod
name: my-pod-3
namespace: default
uid: 7a8b9c0d-1e2f-3g4h-5i6j-7k8l9m0n1o2p
ports: # 端口列表
- name: http # 端口名称
port: 8080 # 端口号
protocol: TCP # 协议
- name: https
port: 8443
protocol: TCP
</div>
<p><strong>Endpoints 的高级使用：</strong></p>
<ul>
<li><strong>无选择器 Service</strong>：手动创建和管理 Endpoints，实现对外部服务的代理</li>
<li><strong>自定义端点管理</strong>：实现复杂的流量管理策略，如蓝绿部署或金丝雀发布</li>
<li><strong>服务别名</strong>：使不同的 Service 指向同一组 Endpoints</li>
</ul>
<div class="code-block">
# 无选择器 Service 示例
---
apiVersion: v1
kind: Service
metadata:
name: external-db
spec:
ports:
- port: 3306
targetPort: 3306
# 注意：没有 selector 字段
---
apiVersion: v1
kind: Endpoints
metadata:
name: external-db # 必须与 Service 名称匹配
subsets:
- addresses:
- ip: 192.168.1.100 # 外部数据库 IP
ports:
- port: 3306
</div>
</div>
<div class="tab-pane">
<h4>EndpointSlices 资源解析</h4>
<p>EndpointSlices 是 Kubernetes 1.17 引入的新资源，用于解决大规模集群中 Endpoints 对象可能过大的问题。每个 EndpointSlice 包含一部分后端地址，共同组成完整的端点集合。</p>
<div class="code-block">
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: my-service-abc123 # 自动生成的名称
labels:
kubernetes.io/service-name: my-service # 关联的 Service
endpointslice.kubernetes.io/managed-by: endpointslice-controller.k8s.io
addressType: IPv4 # 地址类型：IPv4、IPv6 或 FQDN
ports:
- name: http # 端口名称
protocol: TCP # 协议
port: 8080 # 端口号
appProtocol: http # 应用协议（可选）
endpoints:
- addresses:
- "10.244.0.5" # Pod IP 地址
conditions:
ready: true # 是否就绪
serving: true # 是否提供服务
terminating: false # 是否正在终止
hostname: my-pod-1 # 主机名（可选）
nodeName: node-1 # 节点名称
zone: us-west-2a # 可用区（可选）
targetRef: # 引用对象
kind: Pod
name: my-pod-1
namespace: default
uid: d7e8d56f-c87e-4c1a-8c1f-6412a788acd9
- addresses:
- "10.244.0.6"
conditions:
ready: true
serving: true
terminating: false
nodeName: node-2
targetRef:
kind: Pod
name: my-pod-2
namespace: default
uid: a4d45f3e-b7c8-4d3e-9e8f-2a1b3c4d5e6f
</div>
<p><strong>EndpointSlices 的优势：</strong></p>
<ul>
<li><strong>可扩展性</strong>：单个 EndpointSlice 限制为 100 个端点，大型服务会创建多个 EndpointSlice</li>
<li><strong>增量更新</strong>：只需更新变化的 EndpointSlice，减少大型服务更新时的资源消耗</li>
<li><strong>拓扑感知</strong>：包含节点、可用区等拓扑信息，支持更智能的路由</li>
<li><strong>多地址类型</strong>：支持 IPv4、IPv6 和 FQDN 类型的端点</li>
<li><strong>应用协议</strong>：可以指定端口的应用协议，如 HTTP、HTTPS、gRPC 等</li>
</ul>
<p><strong>启用 EndpointSlices：</strong></p>
<div class="code-block">
# kube-proxy 配置（ConfigMap）
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-proxy
namespace: kube-system
data:
config.conf: |-
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
endpointsConfigSource:
type: EndpointSliceProxying # 启用 EndpointSlice 代理
featureGates:
EndpointSliceProxying: true # 启用特性门控
</div>
</div>
</div>
</div>
</section>
<section>
<h2>Service 高级特性与使用模式</h2>
<h3>双栈（Dual-Stack）Service</h3>
<p>从 Kubernetes 1.20 开始，Service 支持 IPv4 和 IPv6 双栈网络，允许同时通过 IPv4 和 IPv6 地址访问服务。</p>
<div class="code-block">
apiVersion: v1
kind: Service
metadata:
name: dual-stack-service
spec:
selector:
app: MyApp
ports:
- port: 80
targetPort: 80
ipFamilyPolicy: PreferDualStack # 使用双栈 IP
ipFamilies: # 指定 IP 族顺序
- IPv4
- IPv6
</div>
<p><strong>双栈配置选项：</strong></p>
<ul>
<li><code>SingleStack</code>：默认值，仅使用第一个配置的 IP 族</li>
<li><code>PreferDualStack</code>：优先使用双栈，如果集群支持</li>
<li><code>RequireDualStack</code>：要求双栈，如果不支持则创建失败</li>
</ul>
<p><strong>使用场景：</strong></p>
<ul>
<li>面向 IPv4 和 IPv6 客户端的混合环境</li>
<li>向 IPv6 网络迁移的过渡期</li>
<li>需要同时支持传统和现代网络的应用</li>
</ul>
<div class="note-card">
<p><strong>注意：</strong> 要使用双栈 Service，集群必须启用双栈网络功能，包括 CNI 插件的支持和适当的节点网络配置。</p>
</div>
<h3>拓扑感知服务路由</h3>
<p>拓扑感知服务路由（Topology Aware Service Routing）是 Kubernetes 1.21 引入的功能，允许将服务流量优先路由到与客户端在同一拓扑区域（如同一可用区）的端点。</p>
<div class="code-block">
apiVersion: v1
kind: Service
metadata:
name: topology-aware-service
annotations:
service.kubernetes.io/topology-aware-hints: "auto" # 启用拓扑感知路由
spec:
selector:
app: MyApp
ports:
- port: 80
targetPort: 80
</div>
<p><strong>工作原理：</strong></p>
<ol>
<li>EndpointSlice 控制器检测节点的拓扑信息（通常是可用区 zone）</li>
<li>为 EndpointSlice 添加拓扑提示信息</li>
<li>kube-proxy 使用这些提示创建网络规则，优先将流量路由到同一拓扑区域内的端点</li>
<li>如果本地区域没有可用端点，则回退到全局负载均衡</li>
</ol>
<p><strong>优势：</strong></p>
<ul>
<li>减少跨区域流量，降低延迟和成本</li>
<li>提高网络性能和可靠性</li>
<li>优化云服务商的计费（许多云提供商对跨区流量收费）</li>
<li>提高系统弹性，避免区域故障级联</li>
</ul>
<h3>自定义 LoadBalancer 实现</h3>
<p>从 Kubernetes 1.22 开始，Service 支持通过 <code>loadBalancerClass</code> 字段指定使用特定的负载均衡器实现。</p>
<div class="code-block">
apiVersion: v1
kind: Service
metadata:
name: custom-lb-service
spec:
selector:
app: MyApp
ports:
- port: 80
targetPort: 80
type: LoadBalancer
loadBalancerClass: "service.k8s.aws/nlb" # 指定使用 AWS NLB
</div>
<p><strong>使用场景：</strong></p>
<ul>
<li>在同一集群中使用多种负载均衡器实现</li>
<li>使用特定于厂商的负载均衡特性</li>
<li>裸机环境中选择特定的软件负载均衡器（如 MetalLB 或 OpenELB）</li>
</ul>
</section>
<section>
<h2>Service 内部实现的高级优化</h2>
<h3>1. kube-proxy 的性能优化</h3>
<p>在大规模集群中，kube-proxy 的性能对整体服务性能至关重要。以下是一些针对不同模式的优化策略：</p>
<div class="tab-container">
<div class="tabs">
<div class="tab active">IPVS 模式优化</div>
<div class="tab">iptables 模式优化</div>
<div class="tab">模式选择建议</div>
</div>
<div class="tab-content">
<div class="tab-pane active">
<h4>IPVS 模式优化</h4>
<p>IPVS 模式在大规模集群中性能更优，以下是一些优化技巧：</p>
<div class="code-block">
# IPVS 配置优化示例
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-proxy
namespace: kube-system
data:
config.conf: |-
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
scheduler: "rr" # 负载均衡算法（rr, lc, dh, sh, sed, nq）
syncPeriod: "30s" # 同步周期
minSyncPeriod: "10s" # 最小同步周期
tcpTimeout: "900s" # TCP 连接超时
tcpFinTimeout: "30s" # TCP FIN 超时
udpTimeout: "300s" # UDP 超时
bindAddress: "0.0.0.0"
metricsBindAddress: "0.0.0.0:10249"
conntrack:
maxPerCore: 32768 # 每个 CPU 核心的最大连接跟踪条目
min: 131072 # 最小连接跟踪条目数
tcpEstablishedTimeout: 86400 # TCP 已建立连接的超时（秒）
tcpCloseWaitTimeout: 30 # TCP CLOSE_WAIT 状态的超时（秒）
</div>
<p><strong>内核参数优化：</strong></p>
<div class="code-block command">
# 增加连接跟踪表大小
sysctl -w net.netfilter.nf_conntrack_max=1000000
# 增加连接跟踪表哈希大小（必须是 2 的幂）
sysctl -w net.netfilter.nf_conntrack_buckets=262144
# 增加已建立连接的超时时间（减少跟踪更新频率）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400
# IPVS 相关优化
sysctl -w net.ipv4.vs.conn_reuse_mode=0
sysctl -w net.ipv4.vs.expire_nodest_conn=1
sysctl -w net.ipv4.vs.expire_quiescent_template=1
</div>
<p><strong>IPVS 调度算法选择：</strong></p>
<ul>
<li><code>rr</code>（轮询）：最简单，适合同质后端</li>
<li><code>lc</code>（最少连接）：适合不同处理能力的后端</li>
<li><code>dh</code>（目的地哈希）：适合需要会话保持的场景</li>
<li><code>sh</code>（源哈希）：类似 dh，但基于源 IP</li>
<li><code>sed</code>（最短期望延迟）：考虑连接数和权重的算法</li>
<li><code>nq</code>（从不排队）：把请求分配给空闲服务器，如果没有则使用 sed</li>
</ul>
</div>
<div class="tab-pane">
<h4>iptables 模式优化</h4>
<p>尽管 IPVS 模式更适合大规模集群，但在某些环境中仍然使用 iptables 模式。以下是优化建议：</p>
<div class="code-block">
# iptables 配置优化示例
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-proxy
namespace: kube-system
data:
config.conf: |-
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "iptables"
iptables:
masqueradeAll: false # 是否对所有流量进行 SNAT
masqueradeBit: 14 # SNAT 使用的标记位
minSyncPeriod: "10s" # 最小同步周期
syncPeriod: "30s" # 同步周期
conntrack:
maxPerCore: 32768 # 每个 CPU 核心的最大连接跟踪条目
min: 131072 # 最小连接跟踪条目数
tcpEstablishedTimeout: 86400 # TCP 已建立连接的超时（秒）
tcpCloseWaitTimeout: 30 # TCP CLOSE_WAIT 状态的超时（秒）
</div>
<p><strong>iptables 模式的性能优化技巧：</strong></p>
<ul>
<li>增加同步周期减少规则更新频率</li>
<li>使用 EndpointSlices 减少规则复杂度</li>
<li>合理设置连接跟踪参数</li>
<li>定期清理无效规则</li>
<li>避免过多的 Service（考虑使用 Ingress 合并）</li>
</ul>
<div class="code-block command">
# 检查 iptables 规则数量
iptables-save | wc -l
# 检查 iptables 规则链长度
iptables-save | grep -c KUBE-SERVICES
# 优化内核参数
sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.ipv4.vs.conntrack=1
sysctl -w net.ipv4.conf.all.forwarding=1
</div>
</div>
<div class="tab-pane">
<h4>kube-proxy 模式选择建议</h4>
<p>不同的 kube-proxy 模式适用于不同的场景：</p>
<div class="comparison-table">
<table>
<thead>
<tr>
<th>特性</th>
<th>IPVS 模式</th>
<th>iptables 模式</th>
<th>userspace 模式</th>
</tr>
</thead>
<tbody>
<tr>
<td>大规模集群支持</td>
<td>★★★★★</td>
<td>★★★</td>
<td>★</td>
</tr>
<tr>
<td>CPU 使用率</td>
<td>★★★★★</td>
<td>★★★</td>
<td>★</td>
</tr>
<tr>
<td>负载均衡算法</td>
<td>多种（rr, lc, dh, sh, sed, nq）</td>
<td>随机</td>
<td>轮询</td>
</tr>
<tr>
<td>会话保持支持</td>
<td>原生支持多种</td>
<td>仅支持 ClientIP</td>
<td>仅支持 ClientIP</td>
</tr>
<tr>
<td>性能特点</td>
<td>O(1) 复杂度查找</td>
<td>O(n) 复杂度查找</td>
<td>内核态用户态切换开销大</td>
</tr>
<tr>
<td>内核依赖</td>
<td>需要 IPVS 模块</td>
<td>几乎所有 Linux 支持</td>
<td>几乎所有 Linux 支持</td>
</tr>
<tr>
<td>适用场景</td>
<td>生产环境大规模集群</td>
<td>中小规模集群</td>
<td>仅用于测试/开发</td>
</tr>
<tr>
<td>配置复杂度</td>
<td>★★★</td>
<td>★★</td>
<td>★</td>
</tr>
</tbody>
</table>
</div>
<p><strong>建议选择标准：</strong></p>
<ul>
<li>如果集群规模 > 1000 Service 或 > 5000 Pod，强烈推荐 IPVS 模式</li>
<li>如果内核不支持 IPVS（< 4.1）或无法加载相关模块，使用 iptables 模式</li>
<li>如果需要高级负载均衡算法或会话保持功能，选择 IPVS 模式</li>
<li>如果是轻量级环境（如 MicroK8s、K3s），iptables 模式可能更简单</li>
<li>userspace 模式仅建议用于特殊调试目的，生产环境不应使用</li>
</ul>
</div>
</div>
</div>
<h3>2. 连接跟踪调优</h3>
<p>连接跟踪（conntrack）是 Service 实现的关键组件，在高流量环境下可能成为瓶颈：</p>
<div class="code-block command">
# 检查连接跟踪表使用情况
cat /proc/sys/net/netfilter/nf_conntrack_count # 当前使用的连接跟踪条目数
cat /proc/sys/net/netfilter/nf_conntrack_max # 最大连接跟踪条目数
# 检查连接跟踪表满时的丢包情况
cat /proc/net/stat/nf_conntrack | grep drop
# 查看连接跟踪统计
conntrack -S
</div>
<div class="warning-card">
<h4>避免连接跟踪表溢出</h4>
<p>连接跟踪表溢出是服务网络问题的常见原因，会导致新连接建立失败，表现为间歇性超时或连接拒绝。</p>
<p>典型症状：内核日志中出现大量 <code>nf_conntrack: table full, dropping packet</code> 信息。</p>
</div>
<p><strong>连接跟踪调优建议：</strong></p>
<ul>
<li>增加连接跟踪表大小：<code>net.netfilter.nf_conntrack_max</code></li>
<li>增加已建立连接的超时时间：<code>net.netfilter.nf_conntrack_tcp_timeout_established</code></li>
<li>减少 TIME_WAIT 连接的超时时间：<code>net.ipv4.tcp_fin_timeout</code></li>
<li>开启 TIME_WAIT 复用：<code>net.ipv4.tcp_tw_reuse</code></li>
<li>适当减少 NodePort 范围，减少预分配的连接跟踪资源</li>
<li>使用 <code>externalTrafficPolicy: Local</code> 减少 SNAT 数量</li>
</ul>
<div class="code-block">
# 推荐的系统参数配置（在节点上设置）
cat > /etc/sysctl.d/90-conntrack.conf << EOF
# 增加连接跟踪表大小
net.netfilter.nf_conntrack_max=1048576
net.netfilter.nf_conntrack_buckets=262144
# 调整超时时间
net.netfilter.nf_conntrack_tcp_timeout_established=86400
net.netfilter.nf_conntrack_tcp_timeout_close_wait=30
net.netfilter.nf_conntrack_tcp_timeout_fin_wait=30
net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
# TCP 相关优化
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_max_tw_buckets=262144
EOF
sysctl -p /etc/sysctl.d/90-conntrack.conf
</div>
<h3>3. DNS 缓存优化</h3>
<p>Service 发现依赖于 DNS 查询，优化 DNS 解析可以减少延迟并提高可靠性：</p>
<div class="diagram-container">
<object type="image/svg+xml" data="svg/node-local-dns.svg" class="diagram">
NodeLocal DNSCache 架构
</object>
</div>
<p><strong>NodeLocal DNSCache</strong> 是 Kubernetes 提供的一种优化方案，在每个节点上运行一个 DNS 缓存，减少到 kube-dns/CoreDNS 的请求：</p>
<div class="code-block">
# 部署 NodeLocal DNSCache
kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml
</div>
<p><strong>NodeLocal DNSCache 的优势：</strong></p>
<ul>
<li>减少 DNS 查询延迟 (平均可减少 10-30ms)</li>
<li>避免 conntrack 表争用问题</li>
<li>减轻集群 DNS 服务器负载</li>
<li>提高 DNS 查询可靠性</li>
<li>解决 "五元组耗尽" 问题（大量 Pod 查询相同 DNS 服务器）</li>
</ul>
<p><strong>CoreDNS 调优：</strong></p>
<div class="code-block">
# CoreDNS 配置调优示例
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache {
success 10000 # 增加缓存大小
denial 1000
prefetch 10 10% # 启用预取
serve_stale 30s # 启用过期缓存服务
}
loop
reload
loadbalance
}
</div>
</section>
<section>
<h2>专家级实践：高级 Service 网络模式</h2>
<h3>1. 多集群服务发现</h3>
<p>随着 Kubernetes 生态的发展，多集群部署变得越来越常见。多集群服务发现允许在不同集群间实现透明的服务访问。</p>
<div class="tab-container">
<div class="tabs">
<div class="tab active">KubeFed 方案</div>
<div class="tab">Istio 多集群</div>
<div class="tab">Submariner</div>
</div>
<div class="tab-content">
<div class="tab-pane active">
<h4>Kubernetes Federation v2 (KubeFed)</h4>
<p>KubeFed 允许将服务联合到多个集群，并提供统一的服务发现机制。</p>
<div class="code-block">
# 定义联邦服务
apiVersion: types.kubefed.io/v1beta1
kind: FederatedService
metadata:
name: test-service
namespace: test-namespace
spec:
template:
spec:
selector:
app: test-app
ports:
- port: 80
targetPort: 8080
type: ClusterIP
placement:
clusters:
- name: cluster1
- name: cluster2
overrides:
- clusterName: cluster2
clusterOverrides:
- path: "/spec/ports/0/port"
value: 8080
</div>
<p><strong>KubeFed 的工作原理：</strong></p>
<ol>
<li>在 Host 集群创建 FederatedService 对象</li>
<li>KubeFed 控制器将其传播到成员集群</li>
<li>在每个集群中创建对应的 Service 对象</li>
<li>ServiceDNSRecord 控制器创建 DNS 记录</li>
<li>客户端通过 DNS 发现服务</li>
</ol>
</div>
<div class="tab-pane">
<h4>Istio 多集群服务网格</h4>
<p>Istio 提供了强大的多集群服务发现和负载均衡能力，可以跨集群边界无缝访问服务。</p>
<div class="code-block">
# Istio 多集群配置（简化示例）
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-cluster2
spec:
hosts:
- service.cluster2.global
location: MESH_EXTERNAL
ports:
- name: http
number: 80
protocol: HTTP
resolution: DNS
endpoints:
- address: service.namespace.svc.cluster2.local
ports:
http: 80
locality: us-west/zone2
labels:
cluster: cluster2
</div>
<p><strong>Istio 多集群模式：</strong></p>
<ul>
<li><strong>主主配置</strong>：所有集群对等，每个集群都可以发起请求</li>
<li><strong>主从配置</strong>：一个主集群包含控制平面，多个从集群包含数据平面</li>
<li><strong>联邦模型</strong>：每个集群有自己的控制平面，跨集群共享服务注册</li>
</ul>
<p>Istio 通过 ServiceEntry 和特殊的 DNS 解析机制，实现了透明的跨集群服务发现。</p>
</div>
<div class="tab-pane">
<h4>Submariner</h4>
<p>Submariner 是一个专注于连接多个 Kubernetes 集群的开源项目，提供直接的跨集群连接性和服务发现。</p>
<div class="code-block">
# 导出服务使其在其他集群可见
kubectl apply -f - << EOF
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
name: nginx
namespace: default
EOF
</div>
<p><strong>Submariner 的组件：</strong></p>
<ul>
<li><strong>Gateway Engine</strong>：在每个集群的指定节点上运行，负责建立和维护安全隧道</li>
<li><strong>Broker</strong>：用于集群发现和交换信息的中心组件</li>
<li><strong>Lighthouse</strong>：提供跨集群服务发现的 DNS 控制器</li>
</ul>
<p><strong>优势：</strong></p>
<ul>
<li>直接的 Pod 到 Pod 通信，无需额外的网关或代理</li>
<li>支持 ClusterIP Service 的跨集群访问</li>
<li>提供跨集群服务发现</li>
<li>与 Kubernetes 网络模型兼容</li>
</ul>
</div>
</div>
</div>
</section>
<section>
<h2>Service 网络监控与故障排除</h2>
<h3>1. 专家级监控指标</h3>
<p>除了基本的可用性监控外，专家级 Service 监控应关注以下方面：</p>
<div class="code-block">
# Prometheus 查询示例
# 1. 服务连接错误率
sum(rate(kube_service_connection_errors_total{service="my-service"}[5m])) /
sum(rate(kube_service_connections_total{service="my-service"}[5m]))
# 2. Service 端点健康比例
sum(kube_endpoint_address_available{service="my-service"}) /
sum(kube_endpoint_address_total{service="my-service"})
# 3. kube-proxy 规则同步延迟
rate(kubeproxy_sync_proxy_rules_duration_seconds_count[5m])
# 4. 连接跟踪表利用率
node_nf_conntrack_entries / node_nf_conntrack_entries_limit
# 5. DNS 查询延迟和错误率
histogram_quantile(0.95, sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by (le))
sum(rate(coredns_dns_responses_total{rcode="SERVFAIL"}[5m])) / sum(rate(coredns_dns_responses_total[5m]))
</div>
<p><strong>关键监控指标组合：</strong></p>
<ul>
<li><strong>Service 可用性金丝雀</strong>：定期从集群内不同节点访问服务并测量成功率</li>
<li><strong>连接建立时间</strong>：监控 TCP 连接建立的时间，可以早期发现网络问题</li>
<li><strong>DNS 解析性能</strong>：监控服务 DNS 解析的成功率和延迟</li>
<li><strong>跨区域流量</strong>：监控不同可用区之间的服务流量比例</li>
<li><strong>后端负载均衡指标</strong>：监控流量在后端 Pod 之间的分布是否均匀</li>
</ul>
<h3>2. 专家级故障诊断技术</h3>
<p>当面对复杂的 Service 网络问题时，以下技术可以帮助快速定位根因：</p>
<h4>网络包捕获与分析</h4>
<div class="code-block command">
# 1. 在节点上捕获 Service 相关流量
kubectl debug node/<node-name> -it --image=nicolaka/netshoot
# 在节点 shell 中执行
SERVICE_IP="10.96.1.10"
tcpdump -nn -i any "host $SERVICE_IP" -w service-traffic.pcap
# 2. 分析连接跟踪表
conntrack -L | grep $SERVICE_IP
# 3. 深入分析 iptables/IPVS 规则
iptables-save | grep -A 10 -B 10 $SERVICE_IP
ipvsadm -ln | grep -A 3 $SERVICE_IP
</div>
<h4>服务网络故障树分析</h4>
<p>当 Service 连接失败时，按照以下故障树系统化排查：</p>
<ol>
<li><strong>DNS 解析问题</strong>
<ul>
<li>检查 CoreDNS Pod 是否健康</li>
<li>验证 Service DNS 记录是否存在</li>
<li>检查 Pod 的 DNS 配置</li>
</ul>
</li>
<li><strong>Service 定义问题</strong>
<ul>
<li>验证 Service 选择器是否匹配 Pod 标签</li>
<li>检查 Service 端口和 Pod 端口配置是否正确</li>
<li>验证 Service 和 Pod 是否在同一命名空间</li>
</ul>
</li>
<li><strong>网络规则问题</strong>
<ul>
<li>检查 kube-proxy 是否正常运行</li>
<li>验证 iptables/IPVS 规则是否正确创建</li>
<li>检查连接跟踪表是否溢出</li>
</ul>
</li>
<li><strong>Pod 健康问题</strong>
<ul>
<li>检查 Pod 是否处于 Running 状态</li>
<li>验证 Pod 的就绪探针是否通过</li>
<li>检查 Pod 日志是否有异常</li>
</ul>
</li>
<li><strong>网络策略限制</strong>
<ul>
<li>检查是否有 NetworkPolicy 阻止流量</li>
<li>验证安全组/防火墙配置</li>
</ul>
</li>
</ol>
<div class="warning-card">
<h4>常见的隐蔽故障</h4>
<ul>
<li><strong>DNS 5 秒超时</strong>：集群 DNS 查询超时默认为 5 秒，这会导致服务调用的高尾延迟</li>
<li><strong>源端口耗尽</strong>：高并发场景下，单个 Pod 到同一目标的连接可能耗尽源端口</li>
<li><strong>conntrack 冲突</strong>：使用 ClusterIP 时的 SNAT 可能导致 conntrack 表项冲突</li>
<li><strong>NAT 穿透问题</strong>：某些网络拓扑中，SNAT 和 DNAT 组合可能导致连接问题</li>
<li><strong>kube-proxy 缓慢同步</strong>：大规模集群中 kube-proxy 更新网络规则可能很慢</li>
</ul>
</div>
<h3>3. Service 网络深度故障排查</h3>
<p>Service 网络问题往往表现为复杂且难以诊断的现象，以下是针对 Service 网络的深度故障排查方法和实战案例分析。</p>
<h4>iptables 规则深度分析</h4>
<p>当 Service 网络出现异常时，深入分析 iptables 规则是关键步骤：</p>
<div class="code-block command">
# 查看与特定 Service 相关的 iptables 规则
SERVICE_PORT="30080" # NodePort 或其他端口
iptables-save | grep $SERVICE_PORT
# 查看 KUBE-SERVICES 链中的规则
iptables -t nat -L KUBE-SERVICES -n --line-numbers
# 查看 KUBE-NODEPORTS 链中的规则
iptables -t nat -L KUBE-NODEPORTS -n --line-numbers
# 查看 KUBE-EXTERNAL-SERVICES 链中的规则（常见问题源）
iptables -t filter -L KUBE-EXTERNAL-SERVICES -n --line-numbers
# 跟踪 iptables 规则链路
iptables -t nat -L KUBE-SVC-XXXXXXX -n # 查看特定服务的 KUBE-SVC-XXX 链
iptables -t nat -L KUBE-SEP-XXXXXXX -n # 查看特定端点的 KUBE-SEP-XXX 链
</div>
<div class="note-card">
<p><strong>iptables 规则链关系：</strong> Service 网络中的 iptables 规则形成了复杂的链路：</p>
<ol>
<li><code>PREROUTING/OUTPUT</code> → <code>KUBE-SERVICES</code> → <code>KUBE-SVC-XXX</code> → <code>KUBE-SEP-XXX</code></li>
<li>对于 NodePort：<code>KUBE-SERVICES</code> → <code>KUBE-NODEPORTS</code> → <code>KUBE-SVC-XXX</code></li>
<li>对于外部流量过滤：<code>KUBE-EXTERNAL-SERVICES</code>（filter 表）</li>
</ol>
</div>
<h4>kube-proxy 异常行为分析</h4>
<p>kube-proxy 负责维护 Service 网络规则，其异常行为是许多 Service 问题的根源：</p>
<div class="code-block command">
# 检查 kube-proxy 日志
kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=200
# 检查 kube-proxy 配置
kubectl get cm -n kube-system kube-proxy -o yaml
# 检查 kube-proxy 健康状态
kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide
# 重启特定节点的 kube-proxy（尝试修复）
NODE_NAME="node-b"
kubectl delete pod -n kube-system $(kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide | grep $NODE_NAME | awk '{print $1}')
</div>
<p><strong>kube-proxy 异常的常见原因：</strong></p>
<ul>
<li>配置不一致（如不同节点的 kube-proxy 配置不同）</li>
<li>资源限制导致处理延迟或失败</li>
<li>与其他网络组件（如 CNI 插件）的冲突</li>
<li>节点网络隔离或防火墙规则干扰</li>
<li>Endpoints 对象更新不及时或不完整</li>
</ul>
<h4>实战案例：NodePort 跨节点访问失败</h4>
<p>以下是一个真实案例：某集群中应用 A 的 NodePort 服务在节点 A 上可以访问，但在节点 B 上无法访问，而应用 B 在两个节点上都正常。</p>
<div class="comparison-table">
<table>