Skip to content

Commit 422691d

Browse files
authored
Merge pull request #38710 from windsonsea/debser
[zh] sync /debug-application/debug-service.md
2 parents 8312e09 + 090d480 commit 422691d

File tree

1 file changed

+3
-59
lines changed

1 file changed

+3
-59
lines changed

content/zh-cn/docs/tasks/debug/debug-application/debug-service.md

Lines changed: 3 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -799,7 +799,6 @@ should see something like:
799799
```none
800800
I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy"
801801
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.
803802
I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53]
804803
I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53]
805804
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.
830829
<!--
831830
Kube-proxy can run in one of a few modes. In the log listed above, the
832831
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".
836833
-->
837834
Kube-proxy 可以以若干模式之一运行。在上述日志中,`Using iptables Proxier`
838835
行表示 kube-proxy 在 "iptables" 模式下运行。
839-
最常见的另一种模式是 "ipvs"。先前的 "userspace" 模式已经被这些所代替。
836+
最常见的另一种模式是 "ipvs"。
840837

841838
<!--
842839
#### Iptables mode
@@ -913,36 +910,6 @@ hostnames(`10.0.1.175:80`) has 3 endpoints(`10.244.0.5:9376`,
913910
在此示例中,服务主机名(`10.0.1.175:80`)拥有 3 个末端(`10.244.0.5:9376`
914911
`10.244.0.6:9376``10.244.0.7:9376`)。
915912

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-
946913
<!--
947914
### Is kube-proxy proxying?
948915
@@ -961,28 +928,6 @@ curl 10.0.1.175:80
961928
hostnames-632524106-bbpiw
962929
```
963930

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-
986931
<!--
987932
If this still fails, look at the `kube-proxy` logs for specific lines like:
988933
-->
@@ -996,7 +941,7 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
996941
If you don't see those, try restarting `kube-proxy` with the `-v` flag set to 4, and
997942
then look at the logs again.
998943
-->
999-
如果你没有看到这些,请尝试将 `-V` 标志设置为 4 并重新启动 `kube-proxy`,然后再查看日志。
944+
如果你没有看到这些,请尝试将 `-v` 标志设置为 4 并重新启动 `kube-proxy`,然后再查看日志。
1000945

1001946
<!--
1002947
### 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`
1010955
back to themselves if they try to access their own Service VIP. The
1011956
`hairpin-mode` flag must either be set to `hairpin-veth` or
1012957
`promiscuous-bridge`.
1013-
1014958
-->
1015959
### 边缘案例: Pod 无法通过 Service IP 连接到它本身 {#a-pod-fails-to-reach-itself-via-the-service-ip}
1016960

0 commit comments

Comments
 (0)