@@ -799,7 +799,6 @@ should see something like:
799
799
``` none
800
800
I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy"
801
801
I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier.
802
- I1027 22:14:53.999055 5063 server.go:255] Tearing down userspace rules. Errors here are acceptable.
803
802
I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53]
804
803
I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53]
805
804
I1027 22:14:54.038209 5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443]
@@ -830,13 +829,11 @@ and then retry.
830
829
<!--
831
830
Kube-proxy can run in one of a few modes. In the log listed above, the
832
831
line `Using iptables Proxier` indicates that kube-proxy is running in
833
- "iptables" mode. The most common other mode is "ipvs". The older "userspace"
834
- mode has largely been replaced by these.
835
-
832
+ "iptables" mode. The most common other mode is "ipvs".
836
833
-->
837
834
Kube-proxy 可以以若干模式之一运行。在上述日志中,` Using iptables Proxier `
838
835
行表示 kube-proxy 在 "iptables" 模式下运行。
839
- 最常见的另一种模式是 "ipvs"。先前的 "userspace" 模式已经被这些所代替。
836
+ 最常见的另一种模式是 "ipvs"。
840
837
841
838
<!--
842
839
#### Iptables mode
@@ -913,36 +910,6 @@ hostnames(`10.0.1.175:80`) has 3 endpoints(`10.244.0.5:9376`,
913
910
在此示例中,服务主机名(` 10.0.1.175:80 ` )拥有 3 个末端(` 10.244.0.5:9376 ` 、
914
911
` 10.244.0.6:9376 ` 和 ` 10.244.0.7:9376 ` )。
915
912
916
- <!--
917
- #### Userspace mode
918
-
919
- In rare cases, you may be using "userspace" mode. From your Node:
920
- -->
921
- #### Userspace 模式 {#userspace-mode}
922
-
923
- 在极少数情况下,你可能会用到 "userspace" 模式。在你的节点上运行:
924
-
925
- ``` shell
926
- iptables-save | grep hostnames
927
- ```
928
-
929
- ``` none
930
- -A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577
931
- -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
932
- ```
933
-
934
- <!--
935
- There should be 2 rules for each port of your Service (only one in this
936
- example) - a "KUBE-PORTALS-CONTAINER" and a "KUBE-PORTALS-HOST".
937
-
938
- Almost nobody should be using the "userspace" mode any more, so you won't spend
939
- more time on it here.
940
- -->
941
- 对于 Service (本例中只有一个)的每个端口,应当有 2 条规则:
942
- 一条 "KUBE-PORTALS-CONTAINER" 和一条 "KUBE-PORTALS-HOST" 规则。
943
-
944
- 几乎没有人应该再使用 "userspace" 模式,因此你在这里不会花更多的时间。
945
-
946
913
<!--
947
914
### Is kube-proxy proxying?
948
915
@@ -961,28 +928,6 @@ curl 10.0.1.175:80
961
928
hostnames-632524106-bbpiw
962
929
```
963
930
964
- <!--
965
- If this fails and you are using the userspace proxy, you can try accessing the
966
- proxy directly. If you are using the iptables proxy, skip this section.
967
-
968
- Look back at the `iptables-save` output above, and extract the
969
- port number that `kube-proxy` is using for your Service. In the above
970
- examples it is "48577". Now connect to that:
971
- -->
972
- 如果失败,并且你正在使用用户空间代理,则可以尝试直接访问代理。
973
- 如果你使用的是 iptables 代理,请跳过本节。
974
-
975
- 回顾上面的 ` iptables-save ` 输出,并提取 ` kube-proxy ` 为你的 Service 所使用的端口号。
976
- 在上面的例子中,端口号是 “48577”。现在试着连接它:
977
-
978
- ``` shell
979
- curl localhost:48577
980
- ```
981
-
982
- ``` none
983
- hostnames-632524106-tlaok
984
- ```
985
-
986
931
<!--
987
932
If this still fails, look at the `kube-proxy` logs for specific lines like:
988
933
-->
@@ -996,7 +941,7 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
996
941
If you don't see those, try restarting `kube-proxy` with the `-v` flag set to 4, and
997
942
then look at the logs again.
998
943
-->
999
- 如果你没有看到这些,请尝试将 ` -V ` 标志设置为 4 并重新启动 ` kube-proxy ` ,然后再查看日志。
944
+ 如果你没有看到这些,请尝试将 ` -v ` 标志设置为 4 并重新启动 ` kube-proxy ` ,然后再查看日志。
1000
945
1001
946
<!--
1002
947
### Edge case: A Pod fails to reach itself via the Service IP {#a-pod-fails-to-reach-itself-via-the-service-ip}
@@ -1010,7 +955,6 @@ are connected with bridge network. The `Kubelet` exposes a `hairpin-mode`
1010
955
back to themselves if they try to access their own Service VIP. The
1011
956
`hairpin-mode` flag must either be set to `hairpin-veth` or
1012
957
`promiscuous-bridge`.
1013
-
1014
958
-->
1015
959
### 边缘案例: Pod 无法通过 Service IP 连接到它本身 {#a-pod-fails-to-reach-itself-via-the-service-ip}
1016
960
0 commit comments