whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Fix links in zh localization (3)

Browse Source
This commit is contained in:
Qiming Teng
2020-12-04 16:05:40 +08:00
parent 9c696a5883
commit b9e8fb699e
22 changed files with 514 additions and 352 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/access-application-cluster/access-cluster.md
+204 -131
View File
@@ -5,11 +5,9 @@ content_type: concept
---
<!--
---
title: Accessing Clusters
weight: 20
content_type: concept
---
-->
<!-- overview -->
@@ -19,8 +17,6 @@ This topic discusses multiple ways to interact with clusters.
-->
本文阐述多种与集群交互的方法。
{{< toc >}}
<!-- body -->
@@ -40,20 +36,26 @@ Check the location and credentials that kubectl knows about with this command:
-->
## 使用 kubectl 完成集群的第一次访问
当您第一次访问 Kubernetes API 的时候，我们建议您使用 Kubernetes CLI，`kubectl`。
当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI，`kubectl`。
访问集群时，您需要知道集群的地址并且拥有访问的凭证。通常，这些在您通过 [Getting started guide](/zh/docs/setup/) 安装集群时都是自动安装好的，或者其他人安装时也应该提供了凭证和集群地址。
访问集群时，你需要知道集群的地址并且拥有访问的凭证。通常，这些在你通过
[启动安装](/zh/docs/setup/)安装集群时都是自动安装好的，或者其他人安装时
也应该提供了凭证和集群地址。
通过以下命令检查 kubectl 是否知道集群地址及凭证：
```shell
$ kubectl config view
kubectl config view
```
<!--
Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview).
-->
有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl，
可以在 [kubectl手册](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。
<!--
## Directly accessing the REST API
Kubectl handles locating and authenticating to the apiserver.
@@ -71,23 +73,22 @@ curl or wget, or a browser, there are several ways to locate and authenticate:
- Works with some types of client code that are confused by using a proxy.
- Need to import a root cert into your browser to protect against MITM.
-->
有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl，可以在 [kubectl手册](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。
## 直接访问 REST API
Kubectl 处理 apiserver 的定位和身份验证。
如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过多种方式查找和验证：
如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过
多种方式查找和验证：
- 以代理模式运行 kubectl。
- 推荐此方式。
- 使用已存储的 apiserver 地址。
- 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
- 对 apiserver 进行身份验证。
- 未来可能会实现智能化的客户端负载均衡和故障恢复。
- 直接向 http 客户端提供位置和凭据。
- 可选的方案。
- 适用于代理可能引起混淆的某些客户端类型。
- 需要引入根证书到您的浏览器以防止 MITM 攻击。
- 以代理模式运行 kubectl。
- 推荐此方式。
- 使用已存储的 apiserver 地址。
- 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
- 对 apiserver 进行身份验证。
- 未来可能会实现智能化的客户端负载均衡和故障恢复。
- 直接向 http 客户端提供位置和凭据。
- 可选的方案。
- 适用于代理可能引起混淆的某些客户端类型。
- 需要引入根证书到你的浏览器以防止 MITM 攻击。
<!--
### Using kubectl proxy
@@ -96,13 +97,13 @@ The following command runs kubectl in a mode where it acts as a reverse proxy.
locating the apiserver and authenticating.
Run it like this:
-->
### 使用 kubectl 代理
### 使用 kubectl proxy
以下命令以反向代理的模式运行kubectl。它处理 apiserver 的定位和验证。
以下命令以反向代理的模式运行 kubectl。它处理 apiserver 的定位和验证。
像这样运行：
```shell
$ kubectl proxy --port=8080 &
kubectl proxy --port=8080 &
```
<!--
@@ -111,12 +112,16 @@ See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) f
Then you can explore the API with curl, wget, or a browser, replacing localhost
with [::1] for IPv6, like so:
-->
参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) 获取更多详细信息。
参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy)
获取更多详细信息。
然后，您可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，如下所示：
然后，你可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，
如下所示：
```shell
$ curl http://localhost:8080/api/
curl http://localhost:8080/api/
```
```json
{
"kind": "APIVersions",
"versions": [
@@ -131,22 +136,24 @@ $ curl http://localhost:8080/api/
}
```
<!--
### Without kubectl proxy
In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this:
-->
### 不使用 kubectl 代理
### 不使用 kubectl proxy
在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。
使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
`grep/cut` 方法实现：
```shell
$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ')
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ')
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
```
```json
{
"kind": "APIVersions",
"versions": [
@@ -164,9 +171,12 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
`jsonpath` 方法实现：
```shell
$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
```
```json
{
"kind": "APIVersions",
"versions": [
@@ -195,9 +205,15 @@ for this. [Configuring Access to the API](/docs/admin/accessing-the-api)
describes how a cluster admin can configure this. Such approaches may conflict
with future high-availability support.
-->
上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器（这些安装在 `~/.kube` 目录中）。由于集群证书通常是自签名的，因此可能需要特殊配置才能让您的 http 客户端使用根证书。
上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。
当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器
（它们安装在 `~/.kube` 目录中）。
由于集群证书通常是自签名的，因此可能需要特殊配置才能让你的 http 客户端使用根证书。
在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，这个没有一定的标准。 [配置对 API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/) 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，
这个没有一定的标准。
[配置对 API 的访问](/zh/docs/concepts/security/controlling-access/)
描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
<!--
## Programmatic access to the API
@@ -210,7 +226,7 @@ client libraries.
* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes`. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
@@ -221,12 +237,20 @@ Kubernetes 官方提供对 [Go](#go-client) 和 [Python](#python-client) 的客
### Go 客户端
* 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 来查看目前支持哪些版本。
* 基于这个 client-go 客户端库编写应用程序。 请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
* 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。
参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go)
来查看目前支持哪些版本。
* 基于这个 client-go 客户端库编写应用程序。
请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库
导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
Go 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来定位和验证 apiserver。可参阅 [示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
Go 客户端可以像 kubectl CLI 一样使用相同的
[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
来定位和验证 apiserver。可参阅
[示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
如果应用程序以 Pod 的形式部署在集群中，那么请参阅 [下一章](#accessing-the-api-from-a-pod)。
如果应用程序以 Pod 的形式部署在集群中，那么请参阅
[下一章](#accessing-the-api-from-a-pod)。
<!--
### Python client
@@ -243,13 +267,20 @@ See documentation for other libraries for how they authenticate.
-->
### Python 客户端
如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，请运行命令：`pip install kubernetes`。参阅 [Python Client Library page](https://github.com/kubernetes-client/python) 以获得更详细的安装参数。
如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，
请运行命令：`pip install kubernetes`。参阅
[Python Client Library page](https://github.com/kubernetes-client/python)
以获得更详细的安装参数。
Python 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来定位和验证 apiserver，可参阅 [示例](https://github.com/kubernetes-client/python/tree/master/examples)。
Python 客户端可以像 kubectl CLI 一样使用相同的
[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
来定位和验证 apiserver，可参阅
[示例](https://github.com/kubernetes-client/python/tree/master/examples)。
### 其它语言
目前有多个 [客户端库](/zh/docs/reference/using-api/client-libraries/) 为其它语言提供访问 API 的方法。
目前有多个[客户端库](/zh/docs/reference/using-api/client-libraries/)
为其它语言提供访问 API 的方法。
参阅其它库的相关文档以获取他们是如何验证的。
<!--
@@ -272,10 +303,14 @@ at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。
在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc` 这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc`
这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
向 apiserver 进行身份验证的推荐方法是使用 [服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
通过 kube-system，pod 与服务帐户相关联，并且该服务帐户的凭证（token）被放置在该 pod 中每个容器的文件系统中，位于 `/var/run/secrets/kubernetes.io/serviceaccount/token`。
向 apiserver 进行身份验证的推荐方法是使用
[服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
通过 kube-system，Pod 与服务帐户相关联，并且该服务帐户的凭证（token）
被放置在该 Pod 中每个容器的文件系统中，位于
`/var/run/secrets/kubernetes.io/serviceaccount/token`。
<!--
If available, a certificate bundle is placed into the filesystem tree of each
@@ -284,7 +319,16 @@ used to verify the serving certificate of the apiserver.
Finally, the default namespace to be used for namespaced API operations is placed in a file
at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
-->
如果可用，则将证书放入每个容器的文件系统中的
`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`，
并且应该用于验证 apiserver 的服务证书。
最后，名字空间作用域的 API 操作所使用的 default 名字空间将被放置在
每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace`
文件中。
<!--
From within a pod the recommended ways to connect to API are:
- run `kubectl proxy` in a sidecar container in the pod, or as a background
@@ -296,18 +340,17 @@ From within a pod the recommended ways to connect to API are:
In each case, the credentials of the pod are used to communicate securely with the apiserver.
-->
如果可用，则将证书放入每个容器的文件系统中的 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`，并且应该用于验证 apiserver 的服务证书。
在 Pod 中，建议连接 API 的方法是：
最后，命名空间化的 API 操作所使用的默认命名空间将被放置在每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
- 在 Pod 的边车容器中运行 `kubectl proxy`，或者以后台进程的形式运行。
这将把 Kubernetes API 代理到当前 Pod 的 localhost 接口，
所以 Pod 中的所有容器中的进程都能访问它。
- 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和
`kubernetes.NewForConfig()` 函数创建一个客户端。
他们处理 apiserver 的定位和身份验证。
[示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
在 pod 中，建议连接 API 的方法是：
- 在 pod 的 sidecar 容器中运行 `kubectl proxy`，或者以后台进程的形式运行。
这将把 Kubernetes API 代理到当前 pod 的 localhost interface，所以 pod 中的所有容器中的进程都能访问它。
- 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和 `kubernetes.NewForConfig()` 函数创建一个客户端。
他们处理 apiserver 的定位和身份验证。[示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
在每种情况下，pod 的凭证都是为了与 apiserver 安全地通信。
在每种情况下，Pod 的凭证都是为了与 apiserver 安全地通信。
<!--
## Accessing services running on the cluster
@@ -321,9 +364,13 @@ such as your desktop machine.
-->
## 访问集群中正在运行的服务 {#accessing-services-running-on-the-cluster}
上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。
在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)，[pods](/zh/docs/concepts/workloads/pods/) 和 [服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。
上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes
集群上运行的其他服务。
在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)、
[pods](/zh/docs/concepts/workloads/pods/) 和
[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
在许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 将无法路由，
因此无法从集群外部的计算机（例如桌面计算机）访问它们。
<!--
### Ways to connect
@@ -341,6 +388,24 @@ You have several options for connecting to nodes, pods and services from outside
place a unique label on the pod and create a new service which selects this label.
- In most cases, it should not be necessary for application developer to directly access
nodes via their nodeIPs.
-->
### 连接的方法 {#ways-to-connect}
有多种方式可以从集群外部连接节点、Pod 和服务：
- 通过公共 IP 访问服务。
- 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。
请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
- 取决于你的集群环境，该服务可能仅暴露给你的公司网络，或者也可能暴露给
整个互联网。
请考虑公开该服务是否安全。它是否进行自己的身份验证？
- 在服务后端放置 Pod。要从一组副本中访问一个特定的 Pod，例如进行调试，
请在 Pod 上设置一个唯一的标签，然后创建一个选择此标签的新服务。
- 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。
<!--
- Access services, nodes, or pods using the Proxy Verb.
- Does apiserver authentication and authorization prior to accessing the remote service.
Use this if the services are not secure enough to expose to the internet, or to gain
@@ -348,6 +413,16 @@ You have several options for connecting to nodes, pods and services from outside
- Proxies may cause problems for some web applications.
- Only works for HTTP/HTTPS.
- Described [here](#manually-constructing-apiserver-proxy-urls).
-->
- 使用 proxy 动词访问服务、节点或者 Pod。
- 在访问远程服务之前进行 apiserver 身份验证和授权。
如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的
访问权限，或者是为了调试，那么请使用此选项。
- 代理可能会给一些 web 应用带来问题。
- 只适用于 HTTP/HTTPS。
- 更多详细信息在[这里](#manually-constructing-apiserver-proxy-urls)。
<!--
- Access from a node or pod in the cluster.
- Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
Connect to other nodes, pods, and services from that shell.
@@ -355,29 +430,14 @@ You have several options for connecting to nodes, pods and services from outside
access cluster services. This is a non-standard method, and will work on some clusters but
not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.
-->
### 连接的方法
- 从集群中的节点或者 Pod 中访问。
有多种方式可以从集群外部连接节点、pod 和服务：
- 通过公共 IP 访问服务。
- 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。
请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
- 取决于您的集群环境，该服务可能仅暴露给您的公司网络，或者也可能暴露给整个互联网。
请考虑公开该服务是否安全。它是否进行自己的身份验证？
- 在服务后端放置 pod。要从一组副本中访问一个特定的 pod，例如进行调试，请在 pod 上放置一个唯一的标签，然后创建一个选择此标签的新服务。
- 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。
- 使用 Proxy Verb 访问服务、node 或者 pod。
- 在访问远程服务之前进行 apiserver 身份验证和授权。
如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的访问权限，或者是为了 debug，那么请使用此选项。
- 代理可能会给一些 web 应用带来问题。
- 只适用于 HTTP/HTTPS。
- 更多详细信息在 [这里](#manually-constructing-apiserver-proxy-urls)。
- 从集群中的 node 或者 pod 中访问。
- 运行一个 pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) 来连接 pod 里的 shell。
然后从 shell 中连接其它的节点、pod 和服务。
- 有些集群可能允许您通过 ssh 连接到 node，从那您可能可以访问集群的服务。
这是一个非正式的方式，可能可以运行在个别的集群上。
浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。
- 运行一个 Pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
来连接 Pod 里的 Shell。
然后从 Shell 中连接其它的节点、Pod 和服务。
- 有些集群可能允许你通过 SSH 连接到节点，从那你可能可以访问集群的服务。
这是一个非正式的方式，可能可以运行在个别的集群上。
浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。
<!--
### Discovering builtin services
@@ -392,14 +452,16 @@ with the `kubectl cluster-info` command:
通过 `kubectl cluster-info` 命令获得这些服务列表：
```shell
$ kubectl cluster-info
kubectl cluster-info
```
Kubernetes master is running at https://104.197.5.247
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
```
Kubernetes master is running at https://104.197.5.247
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
```
<!--
@@ -410,7 +472,10 @@ at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-l
(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
-->
这展示了访问每个服务的 proxy-verb URL。
例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证，那么可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 进行访问。日志也能通过 kubectl 代理获取，例如：
例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证，
那么可以通过
`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`
进行访问。日志也能通过 kubectl 代理获取，例如：
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
（参阅 [上面的内容](#accessing-the-cluster-api) 来获取如何使用 kubectl 代理来传递凭证）
@@ -434,12 +499,14 @@ The supported formats for the name segment of the URL are:
-->
#### 手动构建 apiserver 代理 URL {#manually-constructing-apiserver-proxy-urls}
如上所述，您可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL：
如上所述，你可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。
要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL：
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
如果尚未为端口指定名称，则不必在 URL 中指定 *port_name*。
默认情况下，API server 使用 http 代理您的服务。要使用 https，请在服务名称前加上 `https:`：
默认情况下，API server 使用 HTTP 代理你的服务。
要使用 HTTPS，请在服务名称前加上 `https:`：
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
URL 名称段支持的格式为：
@@ -457,8 +524,10 @@ URL 名称段支持的格式为：
-->
##### 示例
* 要访问 Elasticsearch 服务端点 `_search?q=user:kimchy`，您需要使用：`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
* 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，您需要使用：`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
* 要访问 Elasticsearch 服务端点 `_search?q=user:kimchy`，你需要使用：
`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
* 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，你需要使用：
`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
```json
{
@@ -487,10 +556,12 @@ You may be able to put an apiserver proxy url into the address bar of a browser.
-->
### 使用 web 浏览器访问运行在集群上的服务
您可以在浏览器地址栏中输入 apiserver 代理 URL。但是：
你可以在浏览器地址栏中输入 apiserver 代理 URL。但是：
- Web 浏览器通常不能传递 token，因此您可能需要使用基本（密码）身份验证。Apiserver 可以配置为接受基本身份验证，但您的集群可能未进行配置。
- 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript 以不知道代理路径前缀的方式构建 URL 的应用程序。
- Web 浏览器通常不能传递令牌，因此你可能需要使用基本（密码）身份验证。
Apiserver 可以配置为接受基本身份验证，但你的集群可能未进行配置。
- 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript
以不知道代理路径前缀的方式构建 URL 的应用程序。
<!--
## Requesting redirects
@@ -499,7 +570,7 @@ The redirect capabilities have been deprecated and removed. Please use a proxy
-->
## 请求重定向
已弃用并删除了重定向功能。请改用代理（见下文）。
重定向功能已弃用并被删除。请改用代理（见下文）。
<!--
## So Many Proxies
@@ -520,14 +591,14 @@ There are several different proxies you may encounter when using Kubernetes:
使用 Kubernetes 时可能会遇到几种不同的代理：
1. [kubectl 代理](#directly-accessing-the-rest-api)：
1. [kubectl 代理](#directly-accessing-the-rest-api)：
- 在用户的桌面或 pod 中运行
- 代理从本地主机地址到 Kubernetes apiserver
- 客户端到代理将使用 HTTP
- 代理到 apiserver 使用 HTTPS
- 定位 apiserver
- 添加身份验证 header
- 在用户的桌面或 Pod 中运行
- 代理从本地主机地址到 Kubernetes apiserver
- 客户端到代理将使用 HTTP
- 代理到 apiserver 使用 HTTPS
- 定位 apiserver
- 添加身份验证头部
<!--
1. The [apiserver proxy](#discovering-builtin-services):
@@ -540,15 +611,15 @@ There are several different proxies you may encounter when using Kubernetes:
- can be used to reach a Node, Pod, or Service
- does load balancing when used to reach a Service
-->
2. [apiserver 代理](#discovering-builtin-services)：
2. [apiserver 代理](#discovering-builtin-services)：
- 内置于 apiserver 中
- 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
- 运行在 apiserver 进程中
- 客户端代理使用 HTTPS（也可配置为 http）
- 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
- 可用于访问节点、Pod 或服务
- 在访问服务时进行负载平衡
- 内置于 apiserver 中
- 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
- 运行在 apiserver 进程中
- 客户端代理使用 HTTPS（也可配置为 http）
- 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
- 可用于访问节点、Pod 或服务
- 在访问服务时进行负载平衡
<!--
1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
@@ -559,13 +630,13 @@ There are several different proxies you may encounter when using Kubernetes:
- provides load balancing
- is just used to reach services
-->
3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
- 运行在每个节点上
- 代理 UDP 和 TCP
- 不能代理 HTTP
- 提供负载均衡
- 只能用来访问服务
- 运行在每个节点上
- 代理 UDP 和 TCP
- 不能代理 HTTP
- 提供负载均衡
- 只能用来访问服务
<!--
1. A Proxy/Load-balancer in front of apiserver(s):
@@ -574,11 +645,11 @@ There are several different proxies you may encounter when using Kubernetes:
- sits between all clients and one or more apiservers
- acts as load balancer if there are several apiservers.
-->
4. 位于 apiserver 之前的 Proxy/Load-balancer：
4. 位于 apiserver 之前的 Proxy/Load-balancer：
- 存在和实现因集群而异（例如 nginx）
- 位于所有客户和一个或多个 apiserver 之间
- 如果有多个 apiserver，则充当负载均衡器
- 存在和实现因集群而异（例如 nginx）
- 位于所有客户和一个或多个 apiserver 之间
- 如果有多个 apiserver，则充当负载均衡器
<!--
1. Cloud Load Balancers on external services:
@@ -591,11 +662,13 @@ There are several different proxies you may encounter when using Kubernetes:
Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin
will typically ensure that the latter types are setup correctly.
-->
5. 外部服务上的云负载均衡器：
5. 外部服务上的云负载均衡器：
- 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
- 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
- 只使用 UDP/TCP
- 具体实现因云提供商而异。
- 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
- 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
- 只使用 UDP/TCP
- 具体实现因云提供商而异。
除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。
集群管理员通常会确保后者的正确配置。
除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。集群管理员通常会确保后者的正确配置。