Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: 访问集群中的应用程序
|
||||
weight: 60
|
||||
description: 配置负载平衡、端口转发或设置防火墙或 DNS 配置，以访问集群中的应用程序。
|
||||
---
|
||||
@@ -0,0 +1,253 @@
|
||||
---
|
||||
title: 访问集群上运行的服务
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This page shows how to connect to services running on the Kubernetes cluster.
|
||||
-->
|
||||
本文展示了如何连接 Kubernetes 集群上运行的服务。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Accessing services running on the cluster
|
||||
|
||||
In Kubernetes, [nodes](/docs/concepts/architecture/nodes/),
|
||||
[pods](/docs/concepts/workloads/pods/) and [services](/docs/concepts/services-networking/service/) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
-->
|
||||
## 访问集群上运行的服务
|
||||
|
||||
在 Kubernetes 里，[节点](/zh/docs/concepts/architecture/nodes/)、
|
||||
[Pod](/zh/docs/concepts/workloads/pods/) 和
|
||||
[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
|
||||
许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 是路由不可达的，
|
||||
所以不能从集群之外访问它们，例如从你自己的台式机。
|
||||
|
||||
<!--
|
||||
### Ways to connect
|
||||
|
||||
You have several options for connecting to nodes, pods and services from outside the cluster:
|
||||
-->
|
||||
### 连接方式 {#ways-to-connect}
|
||||
|
||||
你有多种可选方式从集群外连接节点、Pod 和服务：
|
||||
|
||||
<!--
|
||||
- Access services through public IPs.
|
||||
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
|
||||
the cluster. See the [services](/docs/concepts/services-networking/service/) and
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
|
||||
- Depending on your cluster environment, this may only expose the service to your corporate network,
|
||||
or it may expose it to the internet. Think about whether the service being exposed is secure.
|
||||
Does it do its own authentication?
|
||||
- Place pods behind services. To access one specific pod from a set of replicas, such as for debugging,
|
||||
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.
|
||||
-->
|
||||
- 通过公网 IP 访问服务
|
||||
- 使用类型为 `NodePort` 或 `LoadBalancer` 的服务，可以从外部访问它们。
|
||||
请查阅[服务](/zh/docs/concepts/services-networking/service/) 和
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
|
||||
- 取决于你的集群环境，你可以仅把服务暴露在你的企业网络环境中，也可以将其暴露在
|
||||
因特网上。需要考虑暴露的服务是否安全，它是否有自己的用户认证？
|
||||
- 将 Pod 放置于服务背后。如果要访问一个副本集合中特定的 Pod，例如用于调试目的，
|
||||
请给 Pod 指定一个独特的标签并创建一个新服务选择该标签。
|
||||
- 大部分情况下，都不需要应用开发者通过节点 IP 直接访问节点。
|
||||
<!--
|
||||
- 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
|
||||
access to ports on the node IP, or for debugging.
|
||||
- Proxies may cause problems for some web applications.
|
||||
- Only works for HTTP/HTTPS.
|
||||
- Described [here](#manually-constructing-apiserver-proxy-urls).
|
||||
-->
|
||||
- 通过 Proxy 动词访问服务、节点或者 Pod
|
||||
- 在访问远程服务之前，利用 API 服务器执行身份认证和鉴权。
|
||||
如果你的服务不够安全，无法暴露到因特网中，或者需要访问节点 IP 上的端口，
|
||||
又或者出于调试目的，可使用这种方式。
|
||||
- 代理可能给某些应用带来麻烦
|
||||
- 此方式仅适用于 HTTP/HTTPS
|
||||
- 进一步的描述在[这里](#manually-constructing-apiserver-proxy-urls)
|
||||
- 从集群中的 node 或者 pod 访问。
|
||||
<!--
|
||||
- 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.
|
||||
- Some clusters may allow you to ssh to a node in the cluster. From there you may be able to
|
||||
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，然后使用
|
||||
[kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
|
||||
连接到它的 Shell。从那个 Shell 连接其他的节点、Pod 和 服务
|
||||
- 某些集群可能允许你 SSH 到集群中的节点。你可能可以从那儿访问集群服务。
|
||||
这是一个非标准的方式，可能在一些集群上能工作，但在另一些上却不能。
|
||||
浏览器和其他工具可能已经安装也可能没有安装。集群 DNS 可能不会正常工作。
|
||||
|
||||
<!--
|
||||
### Discovering builtin services
|
||||
|
||||
Typically, there are several services which are started on a cluster by kube-system. Get a list of these
|
||||
with the `kubectl cluster-info` command:
|
||||
-->
|
||||
### 发现内置服务 {#discovering-builtin-services}
|
||||
|
||||
典型情况下，kube-system 名字空间中会启动集群的几个服务。
|
||||
使用 `kubectl cluster-info` 命令获取这些服务的列表：
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
Kubernetes master is running at https://192.0.2.1
|
||||
elasticsearch-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
|
||||
kibana-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kibana-logging/proxy
|
||||
kube-dns is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
grafana is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
|
||||
heapster is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
```
|
||||
|
||||
<!--
|
||||
This shows the proxy-verb URL for accessing each service.
|
||||
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
|
||||
at `https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example:
|
||||
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
|
||||
-->
|
||||
这一输出显示了用 proxy 动词访问每个服务时可用的 URL。例如，此集群
|
||||
（使用 Elasticsearch）启用了集群层面的日志。如果提供合适的凭据，可以通过
|
||||
`https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`
|
||||
访问，或通过一个 `kubectl proxy` 来访问：
|
||||
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
|
||||
|
||||
<!--
|
||||
See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.
|
||||
-->
|
||||
{{< note >}}
|
||||
请参阅[使用 Kubernetes API 访问集群](/zh/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)
|
||||
了解如何传递凭据或如何使用 `kubectl proxy`。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
#### Manually constructing apiserver proxy URLs
|
||||
|
||||
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
|
||||
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
|
||||
|
||||
By default, the API server proxies to your service using HTTP. To use HTTPS, prefix the service name with `https:`:
|
||||
`http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy`
|
||||
|
||||
The supported formats for the `<service_name>` segment of the URL are:
|
||||
|
||||
* `<service_name>` - proxies to the default or unnamed port using http
|
||||
* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
|
||||
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
|
||||
* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
|
||||
-->
|
||||
#### 手动构建 API 服务器代理 URLs {#manually-constructing-apiserver-proxy-urls}
|
||||
|
||||
如前所述，你可以使用 `kubectl cluster-info` 命令取得服务的代理 URL。
|
||||
为了创建包含服务末端、后缀和参数的代理 URLs，你可以在服务的代理 URL 中添加：
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
|
||||
|
||||
如果还没有为你的端口指定名称，你可以不用在 URL 中指定 *port_name*。
|
||||
对于命名和未命名端口，你还可以使用端口号代替 *port_name*。
|
||||
|
||||
默认情况下，API 服务器使用 HTTP 为你的服务提供代理。 要使用 HTTPS，请在服务名称前加上 `https:`：
|
||||
`http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy`
|
||||
URL 的 `<service_name>` 段支持的格式为：
|
||||
* `<service_name>` - 使用 http 代理到默认或未命名端口
|
||||
* `<service_name>:<port_name>` - 使用 http 代理到指定的端口名称或端口号
|
||||
* `https:<service_name>:` - 使用 https 代理到默认或未命名端口（注意尾随冒号）
|
||||
* `https:<service_name>:<port_name>` - 使用 https 代理到指定的端口名称或端口号
|
||||
|
||||
<!--
|
||||
##### Examples
|
||||
|
||||
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use:
|
||||
-->
|
||||
##### 示例
|
||||
|
||||
* 如要访问 Elasticsearch 服务末端 `_search?q=user:kimchy`，你可以使用：
|
||||
|
||||
```
|
||||
http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
|
||||
```
|
||||
|
||||
<!--
|
||||
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use:
|
||||
-->
|
||||
* 如要访问 Elasticsearch 集群健康信息`_cluster/health?pretty=true`，你会使用：
|
||||
|
||||
```
|
||||
https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
|
||||
<!--
|
||||
The health information is similar to this:
|
||||
-->
|
||||
健康信息与下面的例子类似：
|
||||
|
||||
```json
|
||||
{
|
||||
"cluster_name" : "kubernetes_logging",
|
||||
"status" : "yellow",
|
||||
"timed_out" : false,
|
||||
"number_of_nodes" : 1,
|
||||
"number_of_data_nodes" : 1,
|
||||
"active_primary_shards" : 5,
|
||||
"active_shards" : 5,
|
||||
"relocating_shards" : 0,
|
||||
"initializing_shards" : 0,
|
||||
"unassigned_shards" : 5
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
* To access the *https* Elasticsearch service health information `_cluster/health?pretty=true`, you would use:
|
||||
-->
|
||||
* 要访问 *https* Elasticsearch 服务健康信息 `_cluster/health?pretty=true`，你会使用：
|
||||
|
||||
```
|
||||
https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Using web browsers to access services running on the cluster
|
||||
|
||||
You may be able to put an apiserver proxy URL into the address bar of a browser. However:
|
||||
-->
|
||||
#### 通过 Web 浏览器访问集群中运行的服务
|
||||
|
||||
你或许能够将 API 服务器代理的 URL 放入浏览器的地址栏，然而：
|
||||
|
||||
<!--
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
but your cluster may not be configured to accept basic auth.
|
||||
- Some web apps may not work, particularly those with client side javascript that construct URLs in a
|
||||
way that is unaware of the proxy path prefix.
|
||||
-->
|
||||
- Web 服务器通常不能传递令牌，所以你可能需要使用基本（密码）认证。
|
||||
API 服务器可以配置为接受基本认证，但你的集群可能并没有这样配置。
|
||||
- 某些 Web 应用可能无法工作，特别是那些使用客户端 Javascript 构造 URL 的
|
||||
应用，所构造的 URL 可能并不支持代理路径前缀。
|
||||
@@ -0,0 +1,476 @@
|
||||
---
|
||||
title: 访问集群
|
||||
weight: 20
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Accessing Clusters
|
||||
weight: 20
|
||||
content_type: concept
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This topic discusses multiple ways to interact with clusters.
|
||||
-->
|
||||
本文阐述多种与集群交互的方法。
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Accessing for the first time with kubectl
|
||||
|
||||
When accessing the Kubernetes API for the first time, we suggest using the
|
||||
Kubernetes CLI, `kubectl`.
|
||||
|
||||
To access a cluster, you need to know the location of the cluster and have credentials
|
||||
to access it. Typically, this is automatically set-up when you work through
|
||||
a [Getting started guide](/docs/setup/),
|
||||
or someone else setup the cluster and provided you with credentials and a location.
|
||||
|
||||
Check the location and credentials that kubectl knows about with this command:
|
||||
-->
|
||||
## 使用 kubectl 完成集群的第一次访问 {#accessing-for-the-first-time-with-kubectl}
|
||||
|
||||
当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI 工具 `kubectl`。
|
||||
|
||||
访问集群时，你需要知道集群的地址并且拥有访问的凭证。通常，这些在你通过
|
||||
[启动安装](/zh/docs/setup/)安装集群时都是自动安装好的，或者其他人安装时
|
||||
也应该提供了凭证和集群地址。
|
||||
|
||||
通过以下命令检查 kubectl 是否知道集群地址及凭证：
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using
|
||||
`kubectl`, and complete documentation is found in the
|
||||
[kubectl reference](/docs/reference/kubectl/).
|
||||
-->
|
||||
有许多[例子](/zh/docs/reference/kubectl/cheatsheet/)介绍了如何使用 kubectl，
|
||||
可以在 [kubectl 参考](/zh/docs/reference/kubectl/)中找到更完整的文档。
|
||||
|
||||
<!--
|
||||
## Directly accessing the REST API
|
||||
|
||||
Kubectl handles locating and authenticating to the apiserver.
|
||||
If you want to directly access the REST API with an http client like
|
||||
curl or wget, or a browser, there are several ways to locate and authenticate:
|
||||
|
||||
- Run kubectl in proxy mode.
|
||||
- Recommended approach.
|
||||
- Uses stored apiserver location.
|
||||
- Verifies identity of apiserver using self-signed cert. No MITM possible.
|
||||
- Authenticates to apiserver.
|
||||
- In future, may do intelligent client-side load-balancing and failover.
|
||||
- Provide the location and credentials directly to the http client.
|
||||
- Alternate approach.
|
||||
- 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.
|
||||
-->
|
||||
## 直接访问 REST API {#directly-accessing-the-rest-api}
|
||||
|
||||
Kubectl 处理 apiserver 的定位和身份验证。
|
||||
如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过
|
||||
多种方式查找和验证：
|
||||
|
||||
- 以代理模式运行 kubectl。
|
||||
- 推荐此方式。
|
||||
- 使用已存储的 apiserver 地址。
|
||||
- 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
|
||||
- 对 apiserver 进行身份验证。
|
||||
- 未来可能会实现智能化的客户端负载均衡和故障恢复。
|
||||
- 直接向 http 客户端提供位置和凭据。
|
||||
- 可选的方案。
|
||||
- 适用于代理可能引起混淆的某些客户端类型。
|
||||
- 需要引入根证书到你的浏览器以防止 MITM 攻击。
|
||||
|
||||
<!--
|
||||
### Using kubectl proxy
|
||||
|
||||
The following command runs kubectl in a mode where it acts as a reverse proxy. It handles
|
||||
locating the apiserver and authenticating.
|
||||
Run it like this:
|
||||
-->
|
||||
### 使用 kubectl proxy {#using-kubectl-proxy}
|
||||
|
||||
以下命令以反向代理的模式运行 kubectl。它处理 apiserver 的定位和验证。
|
||||
像这样运行：
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
<!--
|
||||
See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) for more details.
|
||||
|
||||
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)
|
||||
获取更多详细信息。
|
||||
|
||||
然后，你可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，
|
||||
如下所示：
|
||||
|
||||
```shell
|
||||
curl http://localhost:8080/api/
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
### Without kubectl proxy
|
||||
|
||||
Use `kubectl apply` and `kubectl describe secret...` to create a token for the default service account with grep/cut:
|
||||
|
||||
First, create the Secret, requesting a token for the default ServiceAccount:
|
||||
|
||||
-->
|
||||
|
||||
### 不使用 kubectl proxy {#without-kubectl-proxy}
|
||||
|
||||
使用 `kubectl apply` 和 `kubectl describe secret ...` 及 grep 和剪切操作来为 default 服务帐户创建令牌，如下所示：
|
||||
|
||||
首先，创建 Secret，请求默认 ServiceAccount 的令牌：
|
||||
|
||||
```shell
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: default-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: default
|
||||
type: kubernetes.io/service-account-token
|
||||
EOF
|
||||
```
|
||||
|
||||
<!--
|
||||
Next, wait for the token controller to populate the Secret with a token:
|
||||
-->
|
||||
接下来，等待令牌控制器使用令牌填充 Secret：
|
||||
|
||||
```shell
|
||||
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
|
||||
echo "waiting for token..." >&2
|
||||
sleep 1
|
||||
done
|
||||
```
|
||||
|
||||
<!--
|
||||
Capture and use the generated token:
|
||||
-->
|
||||
捕获并使用生成的令牌：
|
||||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
|
||||
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
Using `jsonpath`:
|
||||
-->
|
||||
`jsonpath` 方法实现：
|
||||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
The above examples use the `--insecure` flag. This leaves it subject to MITM
|
||||
attacks. When kubectl accesses the cluster it uses a stored root certificate
|
||||
and client certificates to access the server. (These are installed in the
|
||||
`~/.kube` directory). Since cluster certificates are typically self-signed, it
|
||||
may take special configuration to get your http client to use root
|
||||
certificate.
|
||||
|
||||
On some clusters, the apiserver does not require authentication; it may serve
|
||||
on localhost, or be protected by a firewall. There is not a standard
|
||||
for this. [Controlling Access to the API](/docs/concepts/security/controlling-access)
|
||||
describes how a cluster admin can configure this.
|
||||
-->
|
||||
上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。
|
||||
当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器
|
||||
（它们安装在 `~/.kube` 目录中）。
|
||||
由于集群证书通常是自签名的，因此可能需要特殊配置才能让你的 http 客户端使用根证书。
|
||||
|
||||
在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，
|
||||
这个没有一定的标准。
|
||||
[配置对 API 的访问](/zh/docs/concepts/security/controlling-access/)
|
||||
描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
|
||||
|
||||
<!--
|
||||
## Programmatic access to the API
|
||||
|
||||
Kubernetes officially supports [Go](#go-client) and [Python](#python-client)
|
||||
client libraries.
|
||||
|
||||
### Go client
|
||||
|
||||
* To get the library, run the following command: `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`, see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) for detailed installation instructions. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) 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/kubernetes"` is correct.
|
||||
|
||||
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).
|
||||
-->
|
||||
## 以编程方式访问 API {#programmatic-access-to-the-api}
|
||||
|
||||
Kubernetes 官方提供对 [Go](#go-client) 和 [Python](#python-client) 的客户端库支持。
|
||||
|
||||
### Go 客户端 {#go-client}
|
||||
|
||||
* 想要获得这个库，请运行命令：`go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`，
|
||||
有关详细安装说明，请参阅 [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)。
|
||||
请参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) 以查看支持的版本。
|
||||
* 基于这个 client-go 客户端库编写应用程序。
|
||||
请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库
|
||||
导入 API 定义，例如，`import "k8s.io/client-go/kubernetes"` 才是对的。
|
||||
|
||||
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)。
|
||||
|
||||
<!--
|
||||
### Python client
|
||||
|
||||
To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
|
||||
|
||||
The Python 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://github.com/kubernetes-client/python/tree/master/examples).
|
||||
|
||||
### Other languages
|
||||
|
||||
There are [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages.
|
||||
See documentation for other libraries for how they authenticate.
|
||||
-->
|
||||
### Python 客户端 {#python-client}
|
||||
|
||||
如果想要使用 [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/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
来定位和验证 apiserver，可参阅
|
||||
[示例](https://github.com/kubernetes-client/python/tree/master/examples)。
|
||||
|
||||
### 其它语言 {#other-languages}
|
||||
|
||||
目前有多个[客户端库](/zh/docs/reference/using-api/client-libraries/)
|
||||
为其它语言提供访问 API 的方法。
|
||||
参阅其它库的相关文档以获取他们是如何验证的。
|
||||
|
||||
<!--
|
||||
## Accessing the API from a Pod
|
||||
|
||||
When accessing the API from a pod, locating and authenticating
|
||||
to the API server are somewhat different.
|
||||
-->
|
||||
### 从 Pod 中访问 API {#accessing-the-api-from-a-pod}
|
||||
|
||||
当你从 Pod 中访问 API 时，定位和验证 API 服务器会有些许不同。
|
||||
|
||||
<!--
|
||||
Please check [Accessing the API from within a Pod](/docs/tasks/run-application/access-api-from-pod/)
|
||||
for more details.
|
||||
-->
|
||||
请参阅[从 Pod 中访问 API](/zh/docs/tasks/run-application/access-api-from-pod/)
|
||||
了解更多详情。
|
||||
|
||||
<!--
|
||||
## Accessing services running on the cluster
|
||||
|
||||
The previous section describes how to connect to the Kubernetes API server.
|
||||
For information about connecting to other services running on a Kubernetes cluster, see
|
||||
[Access Cluster Services](/docs/tasks/access-application-cluster/access-cluster-services/).
|
||||
-->
|
||||
|
||||
## 访问集群上运行的服务 {#accessing-services-running-on-the-cluster}
|
||||
|
||||
上一节介绍了如何连接到 Kubernetes API 服务器。
|
||||
有关连接到 Kubernetes 集群上运行的其他服务的信息，请参阅
|
||||
[访问集群服务](/zh/docs/tasks/access-application-cluster/access-cluster-services/)。
|
||||
|
||||
<!--
|
||||
## Requesting redirects
|
||||
|
||||
The redirect capabilities have been deprecated and removed. Please use a proxy (see below) instead.
|
||||
-->
|
||||
## 请求重定向 {#requesting-redirects}
|
||||
|
||||
重定向功能已弃用并被删除。请改用代理（见下文）。
|
||||
|
||||
<!--
|
||||
## So Many Proxies
|
||||
|
||||
There are several different proxies you may encounter when using Kubernetes:
|
||||
|
||||
1. The [kubectl proxy](#directly-accessing-the-rest-api):
|
||||
|
||||
- runs on a user's desktop or in a pod
|
||||
- proxies from a localhost address to the Kubernetes apiserver
|
||||
- client to proxy uses HTTP
|
||||
- proxy to apiserver uses HTTPS
|
||||
- locates apiserver
|
||||
- adds authentication headers
|
||||
|
||||
-->
|
||||
## 多种代理 {#so-many-proxies}
|
||||
|
||||
使用 Kubernetes 时可能会遇到几种不同的代理：
|
||||
|
||||
1. [kubectl 代理](#directly-accessing-the-rest-api)：
|
||||
|
||||
- 在用户的桌面或 Pod 中运行
|
||||
- 代理从本地主机地址到 Kubernetes apiserver
|
||||
- 客户端到代理将使用 HTTP
|
||||
- 代理到 apiserver 使用 HTTPS
|
||||
- 定位 apiserver
|
||||
- 添加身份验证头部
|
||||
|
||||
<!--
|
||||
1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services):
|
||||
|
||||
- is a bastion built into the apiserver
|
||||
- connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
|
||||
- runs in the apiserver processes
|
||||
- client to proxy uses HTTPS (or http if apiserver so configured)
|
||||
- proxy to target may use HTTP or HTTPS as chosen by proxy using available information
|
||||
- can be used to reach a Node, Pod, or Service
|
||||
- does load balancing when used to reach a Service
|
||||
-->
|
||||
2. [apiserver 代理](/zh/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services)：
|
||||
|
||||
- 内置于 apiserver 中
|
||||
- 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
|
||||
- 运行在 apiserver 进程中
|
||||
- 客户端代理使用 HTTPS（也可配置为 http）
|
||||
- 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
|
||||
- 可用于访问节点、Pod 或服务
|
||||
- 在访问服务时进行负载平衡
|
||||
|
||||
<!--
|
||||
1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
|
||||
|
||||
- runs on each node
|
||||
- proxies UDP and TCP
|
||||
- does not understand HTTP
|
||||
- provides load balancing
|
||||
- is only used to reach services
|
||||
-->
|
||||
3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
|
||||
|
||||
- 运行在每个节点上
|
||||
- 代理 UDP 和 TCP
|
||||
- 不能代理 HTTP
|
||||
- 提供负载均衡
|
||||
- 只能用来访问服务
|
||||
|
||||
<!--
|
||||
1. A Proxy/Load-balancer in front of apiserver(s):
|
||||
|
||||
- existence and implementation varies from cluster to cluster (e.g. nginx)
|
||||
- sits between all clients and one or more apiservers
|
||||
- acts as load balancer if there are several apiservers.
|
||||
-->
|
||||
4. 位于 apiserver 之前的 Proxy/Load-balancer：
|
||||
|
||||
- 存在和实现因集群而异（例如 nginx）
|
||||
- 位于所有客户和一个或多个 apiserver 之间
|
||||
- 如果有多个 apiserver，则充当负载均衡器
|
||||
|
||||
<!--
|
||||
1. Cloud Load Balancers on external services:
|
||||
|
||||
- are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
|
||||
- are created automatically when the Kubernetes service has type `LoadBalancer`
|
||||
- use UDP/TCP only
|
||||
- implementation varies by cloud provider.
|
||||
|
||||
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. 外部服务上的云负载均衡器：
|
||||
|
||||
- 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
|
||||
- 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
|
||||
- 只使用 UDP/TCP
|
||||
- 具体实现因云提供商而异。
|
||||
|
||||
除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。
|
||||
集群管理员通常会确保后者的正确配置。
|
||||
+212
@@ -0,0 +1,212 @@
|
||||
---
|
||||
title: 同 Pod 内的容器使用共享卷通信
|
||||
content_type: task
|
||||
---
|
||||
<!--
|
||||
title: Communicate Between Containers in the Same Pod Using a Shared Volume
|
||||
content_type: task
|
||||
weight: 110
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to use a Volume to communicate between two Containers running
|
||||
in the same Pod. See also how to allow processes to communicate by
|
||||
[sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
between containers.
|
||||
-->
|
||||
本文旨在说明如何让一个 Pod 内的两个容器使用一个卷（Volume）进行通信。
|
||||
参阅如何让两个进程跨容器通过
|
||||
[共享进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Creating a Pod that runs two Containers
|
||||
|
||||
In this exercise, you create a Pod that runs two Containers. The two containers
|
||||
share a Volume that they can use to communicate. Here is the configuration file
|
||||
for the Pod:
|
||||
-->
|
||||
## 创建一个包含两个容器的 Pod
|
||||
|
||||
在这个练习中，你会创建一个包含两个容器的 Pod。两个容器共享一个卷用于他们之间的通信。
|
||||
Pod 的配置文件如下：
|
||||
|
||||
{{< codenew file="pods/two-container-pod.yaml" >}}
|
||||
|
||||
<!--
|
||||
In the configuration file, you can see that the Pod has a Volume named
|
||||
`shared-data`.
|
||||
|
||||
The first container listed in the configuration file runs an nginx server. The
|
||||
mount path for the shared Volume is `/usr/share/nginx/html`.
|
||||
The second container is based on the debian image, and has a mount path of
|
||||
`/pod-data`. The second container runs the following command and then terminates.
|
||||
-->
|
||||
在配置文件中，你可以看到 Pod 有一个共享卷，名为 `shared-data`。
|
||||
|
||||
配置文件中的第一个容器运行了一个 nginx 服务器。共享卷的挂载路径是 `/usr/share/nginx/html`。
|
||||
第二个容器是基于 debian 镜像的，有一个 `/pod-data` 的挂载路径。第二个容器运行了下面的命令然后终止。
|
||||
|
||||
```shell
|
||||
echo Hello from the debian container > /pod-data/index.html
|
||||
```
|
||||
|
||||
<!--
|
||||
Notice that the second container writes the `index.html` file in the root
|
||||
directory of the nginx server.
|
||||
|
||||
Create the Pod and the two Containers:
|
||||
-->
|
||||
注意，第二个容器在 nginx 服务器的根目录下写了 `index.html` 文件。
|
||||
|
||||
创建一个包含两个容器的 Pod：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
View information about the Pod and the Containers:
|
||||
-->
|
||||
查看 Pod 和容器的信息：
|
||||
|
||||
```shell
|
||||
kubectl get pod two-containers --output=yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
Here is a portion of the output:
|
||||
-->
|
||||
这是输出的一部分：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
...
|
||||
name: two-containers
|
||||
namespace: default
|
||||
...
|
||||
spec:
|
||||
...
|
||||
containerStatuses:
|
||||
|
||||
- containerID: docker://c1d8abd1 ...
|
||||
image: debian
|
||||
...
|
||||
lastState:
|
||||
terminated:
|
||||
...
|
||||
name: debian-container
|
||||
...
|
||||
|
||||
- containerID: docker://96c1ff2c5bb ...
|
||||
image: nginx
|
||||
...
|
||||
name: nginx-container
|
||||
...
|
||||
state:
|
||||
running:
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
You can see that the debian Container has terminated, and the nginx Container
|
||||
is still running.
|
||||
|
||||
Get a shell to nginx Container:
|
||||
-->
|
||||
你可以看到 debian 容器已经被终止了，而 nginx 服务器依然在运行。
|
||||
|
||||
进入 nginx 容器的 shell：
|
||||
|
||||
```shell
|
||||
kubectl exec -it two-containers -c nginx-container -- /bin/bash
|
||||
```
|
||||
|
||||
<!--
|
||||
In your shell, verify that nginx is running:
|
||||
-->
|
||||
在 shell 中，确认 nginx 还在运行。
|
||||
|
||||
```
|
||||
root@two-containers:/# ps aux
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于这样：
|
||||
|
||||
```
|
||||
USER PID ... STAT START TIME COMMAND
|
||||
root 1 ... Ss 21:12 0:00 nginx: master process nginx -g daemon off;
|
||||
```
|
||||
|
||||
<!--
|
||||
Recall that the debian Container created the `index.html` file in the nginx root
|
||||
directory. Use `curl` to send a GET request to the nginx server:
|
||||
-->
|
||||
回忆一下，debian 容器在 nginx 的根目录下创建了 `index.html` 文件。
|
||||
使用 `curl` 向 nginx 服务器发送一个 GET 请求：
|
||||
|
||||
```
|
||||
root@two-containers:/# curl localhost
|
||||
```
|
||||
|
||||
输出表示 nginx 提供了 debian 容器写的页面：
|
||||
|
||||
```
|
||||
Hello from the debian container
|
||||
```
|
||||
<!-- discussion -->
|
||||
|
||||
<!--
|
||||
## Discussion
|
||||
|
||||
The primary reason that Pods can have multiple containers is to support
|
||||
helper applications that assist a primary application. Typical examples of
|
||||
helper applications are data pullers, data pushers, and proxies.
|
||||
Helper and primary applications often need to communicate with each other.
|
||||
Typically this is done through a shared filesystem, as shown in this exercise,
|
||||
or through the loopback network interface, localhost. An example of this pattern is a
|
||||
web server along with a helper program that polls a Git repository for new updates.
|
||||
-->
|
||||
## 讨论
|
||||
|
||||
Pod 能有多个容器的主要原因是为了支持辅助应用（helper applications），以协助主应用（primary application）。
|
||||
辅助应用的典型例子是数据抽取，数据推送和代理。辅助应用和主应用经常需要相互通信。
|
||||
就如这个练习所示，通信通常是通过共享文件系统完成的，或者，也通过回环网络接口 localhost 完成。
|
||||
举个网络接口的例子，web 服务器带有一个协助程序用于拉取 Git 仓库的更新。
|
||||
|
||||
<!--
|
||||
The Volume in this exercise provides a way for Containers to communicate during
|
||||
the life of the Pod. If the Pod is deleted and recreated, any data stored in
|
||||
the shared Volume is lost.
|
||||
-->
|
||||
在本练习中的卷为 Pod 生命周期中的容器相互通信提供了一种方法。如果 Pod 被删除或者重建了，
|
||||
任何共享卷中的数据都会丢失。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
|
||||
* Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns).
|
||||
* See [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
|
||||
* See [Configure a Pod to share process namespace between containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
|
||||
* See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
||||
-->
|
||||
* 进一步了解[复合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns.html)
|
||||
* 学习[模块化架构中的复合容器](https://www.slideshare.net/Docker/slideshare-burns)
|
||||
* 参见[配置 Pod 使用卷来存储数据](/zh/docs/tasks/configure-pod-container/configure-volume-storage/)
|
||||
* 参考[在 Pod 中的容器之间共享进程命名空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
* 参考 [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
|
||||
* 参考 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
|
||||
|
||||
+568
@@ -0,0 +1,568 @@
|
||||
---
|
||||
title: 配置对多集群的访问
|
||||
content_type: task
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Configure Access to Multiple Clusters
|
||||
content_type: task
|
||||
weight: 30
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This page shows how to configure access to multiple clusters by using
|
||||
configuration files. After your clusters, users, and contexts are defined in
|
||||
one or more configuration files, you can quickly switch between clusters by using the
|
||||
`kubectl config use-context` command.
|
||||
-->
|
||||
本文展示如何使用配置文件来配置对多个集群的访问。
|
||||
在将集群、用户和上下文定义在一个或多个配置文件中之后，用户可以使用
|
||||
`kubectl config use-context` 命令快速地在集群之间进行切换。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
A file that is used to configure access to a cluster is sometimes called
|
||||
a *kubeconfig file*. This is a generic way of referring to configuration files.
|
||||
It does not mean that there is a file named `kubeconfig`.
|
||||
-->
|
||||
用于配置集群访问的文件有时被称为 *kubeconfig 文件*。
|
||||
这是一种引用配置文件的通用方式，并不意味着存在一个名为 `kubeconfig` 的文件。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
<!--
|
||||
{{< warning >}}
|
||||
Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure.
|
||||
If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script.
|
||||
{{< /warning>}}
|
||||
-->
|
||||
{{< warning >}}
|
||||
只使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。
|
||||
如果必须使用不受信任的 kubeconfig 文件，请首先像检查 shell 脚本一样仔细检查它。
|
||||
{{< /warning>}}
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!--
|
||||
To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed,
|
||||
run `kubectl version --client`. The kubectl version should be
|
||||
[within one minor version](/releases/version-skew-policy/#kubectl) of your
|
||||
cluster's API server.
|
||||
-->
|
||||
要检查 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 是否安装，
|
||||
执行 `kubectl version --client` 命令。
|
||||
kubectl 的版本应该与集群的 API 服务器
|
||||
[使用同一次版本号](/zh/releases/version-skew-policy/#kubectl)。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Define clusters, users, and contexts
|
||||
|
||||
Suppose you have two clusters, one for development work and one for scratch work.
|
||||
In the `development` cluster, your frontend developers work in a namespace called `frontend`,
|
||||
and your storage developers work in a namespace called `storage`. In your `scratch` cluster,
|
||||
developers work in the default namespace, or they create auxiliary namespaces as they
|
||||
see fit. Access to the development cluster requires authentication by certificate. Access
|
||||
to the scratch cluster requires authentication by username and password.
|
||||
|
||||
Create a directory named `config-exercise`. In your
|
||||
`config-exercise` directory, create a file named `config-demo` with this content:
|
||||
-->
|
||||
## 定义集群、用户和上下文 {#define-clusters-users-and-contexts}
|
||||
|
||||
假设用户有两个集群，一个用于正式开发工作，一个用于其它临时用途（scratch）。
|
||||
在 `development` 集群中，前端开发者在名为 `frontend` 的名字空间下工作，
|
||||
存储开发者在名为 `storage` 的名字空间下工作。在 `scratch` 集群中，
|
||||
开发人员可能在默认名字空间下工作，也可能视情况创建附加的名字空间。
|
||||
访问开发集群需要通过证书进行认证。
|
||||
访问其它临时用途的集群需要通过用户名和密码进行认证。
|
||||
|
||||
创建名为 `config-exercise` 的目录。在
|
||||
`config-exercise` 目录中，创建名为 `config-demo` 的文件，其内容为：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
clusters:
|
||||
- cluster:
|
||||
name: development
|
||||
- cluster:
|
||||
name: scratch
|
||||
|
||||
users:
|
||||
- name: developer
|
||||
- name: experimenter
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
name: dev-frontend
|
||||
- context:
|
||||
name: dev-storage
|
||||
- context:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
<!--
|
||||
A configuration file describes clusters, users, and contexts. Your `config-demo` file
|
||||
has the framework to describe two clusters, two users, and three contexts.
|
||||
|
||||
Go to your `config-exercise` directory. Enter these commands to add cluster details to
|
||||
your configuration file:
|
||||
-->
|
||||
配置文件描述了集群、用户名和上下文。`config-demo` 文件中含有描述两个集群、
|
||||
两个用户和三个上下文的框架。
|
||||
|
||||
进入 `config-exercise` 目录。输入以下命令，将集群详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
|
||||
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
```
|
||||
|
||||
<!--
|
||||
Add user details to your configuration file:
|
||||
-->
|
||||
将用户详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
|
||||
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
- To delete a user you can run `kubectl --kubeconfig=config-demo config unset users.<name>`
|
||||
- To remove a cluster, you can run `kubectl --kubeconfig=config-demo config unset clusters.<name>`
|
||||
- To remove a context, you can run `kubectl --kubeconfig=config-demo config unset contexts.<name>`
|
||||
-->
|
||||
- 要删除用户，可以运行 `kubectl --kubeconfig=config-demo config unset users.<name>`
|
||||
- 要删除集群，可以运行 `kubectl --kubeconfig=config-demo config unset clusters.<name>`
|
||||
- 要删除上下文，可以运行 `kubectl --kubeconfig=config-demo config unset contexts.<name>`
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Add context details to your configuration file:
|
||||
-->
|
||||
将上下文详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
<!--
|
||||
Open your `config-demo` file to see the added details. As an alternative to opening the
|
||||
`config-demo` file, you can use the `config view` command.
|
||||
-->
|
||||
打开 `config-demo` 文件查看添加的详细信息。也可以使用 `config view`
|
||||
命令进行查看：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows the two clusters, two users, and three contexts:
|
||||
-->
|
||||
输出展示了两个集群、两个用户和三个上下文：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://5.6.7.8
|
||||
name: scratch
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
current-context: ""
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
- name: experimenter
|
||||
user:
|
||||
password: some-password
|
||||
username: exp
|
||||
```
|
||||
|
||||
<!--
|
||||
The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders
|
||||
for the pathnames of the certificate files. You need to change these to the actual pathnames
|
||||
of certificate files in your environment.
|
||||
|
||||
Sometimes you may want to use Base64-encoded data embedded here instead of separate
|
||||
certificate files; in that case you need to add the suffix `-data` to the keys, for example,
|
||||
`certificate-authority-data`, `client-certificate-data`, `client-key-data`.
|
||||
-->
|
||||
其中的 `fake-ca-file`、`fake-cert-file` 和 `fake-key-file` 是证书文件路径名的占位符。
|
||||
你需要更改这些值，使之对应你的环境中证书文件的实际路径名。
|
||||
|
||||
有时你可能希望在这里使用 BASE64 编码的数据而不是一个个独立的证书文件。
|
||||
如果是这样，你需要在键名上添加 `-data` 后缀。例如，
|
||||
`certificate-authority-data`、`client-certificate-data` 和 `client-key-data`。
|
||||
|
||||
<!--
|
||||
Each context is a triple (cluster, user, namespace). For example, the
|
||||
`dev-frontend` context says, "Use the credentials of the `developer`
|
||||
user to access the `frontend` namespace of the `development` cluster".
|
||||
|
||||
Set the current context:
|
||||
-->
|
||||
每个上下文包含三部分（集群、用户和名字空间），例如，
|
||||
`dev-frontend` 上下文表明：使用 `developer` 用户的凭证来访问 `development` 集群的
|
||||
`frontend` 名字空间。
|
||||
|
||||
设置当前上下文：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
Now whenever you enter a `kubectl` command, the action will apply to the cluster,
|
||||
and namespace listed in the `dev-frontend` context. And the command will use
|
||||
the credentials of the user listed in the `dev-frontend` context.
|
||||
|
||||
To see only the configuration information associated with
|
||||
the current context, use the `--minify` flag.
|
||||
-->
|
||||
现在当输入 `kubectl` 命令时，相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间，
|
||||
同时，命令会使用 `dev-frontend` 上下文中所列用户的凭证。
|
||||
|
||||
使用 `--minify` 参数，来查看与当前上下文相关联的配置信息。
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows configuration information associated with the `dev-frontend` context:
|
||||
-->
|
||||
输出结果展示了 `dev-frontend` 上下文相关的配置信息：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
current-context: dev-frontend
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
```
|
||||
|
||||
<!--
|
||||
Now suppose you want to work for a while in the scratch cluster.
|
||||
|
||||
Change the current context to `exp-scratch`:
|
||||
-->
|
||||
现在假设用户希望在其它临时用途集群中工作一段时间。
|
||||
|
||||
将当前上下文更改为 `exp-scratch`：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
```
|
||||
|
||||
<!--
|
||||
Now any `kubectl` command you give will apply to the default namespace of
|
||||
the `scratch` cluster. And the command will use the credentials of the user
|
||||
listed in the `exp-scratch` context.
|
||||
|
||||
View configuration associated with the new current context, `exp-scratch`.
|
||||
-->
|
||||
|
||||
现在你发出的所有 `kubectl` 命令都将应用于 `scratch` 集群的默认名字空间。
|
||||
同时，命令会使用 `exp-scratch` 上下文中所列用户的凭证。
|
||||
|
||||
查看更新后的当前上下文 `exp-scratch` 相关的配置：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
Finally, suppose you want to work for a while in the `storage` namespace of the
|
||||
`development` cluster.
|
||||
|
||||
Change the current context to `dev-storage`:
|
||||
-->
|
||||
最后，假设用户希望在 `development` 集群中的 `storage` 名字空间下工作一段时间。
|
||||
|
||||
将当前上下文更改为 `dev-storage`：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-storage
|
||||
```
|
||||
|
||||
<!--
|
||||
View configuration associated with the new current context, `dev-storage`.
|
||||
-->
|
||||
查看更新后的当前上下文 `dev-storage` 相关的配置：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
## Create a second configuration file
|
||||
|
||||
In your `config-exercise` directory, create a file named `config-demo-2` with this content:
|
||||
-->
|
||||
|
||||
## 创建第二个配置文件 {#create-a-second-configuration-file}
|
||||
|
||||
在 `config-exercise` 目录中，创建名为 `config-demo-2` 的文件，其中包含以下内容：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
```
|
||||
|
||||
<!--
|
||||
The preceding configuration file defines a new context named `dev-ramp-up`.
|
||||
-->
|
||||
上述配置文件定义了一个新的上下文，名为 `dev-ramp-up`。
|
||||
|
||||
<!--
|
||||
## Set the KUBECONFIG environment variable
|
||||
|
||||
See whether you have an environment variable named `KUBECONFIG`. If so, save the
|
||||
current value of your `KUBECONFIG` environment variable, so you can restore it later.
|
||||
For example:
|
||||
-->
|
||||
## 设置 KUBECONFIG 环境变量 {#set-the-kubeconfig-environment-variable}
|
||||
|
||||
查看是否有名为 `KUBECONFIG` 的环境变量。
|
||||
如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。
|
||||
例如：
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
|
||||
```
|
||||
|
||||
<!--
|
||||
The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is
|
||||
colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have
|
||||
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
|
||||
in the list.
|
||||
|
||||
Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
|
||||
-->
|
||||
`KUBECONFIG` 环境变量是配置文件路径的列表，该列表在 Linux 和 Mac 中以冒号分隔，
|
||||
在 Windows 中以分号分隔。
|
||||
如果有 `KUBECONFIG` 环境变量，请熟悉列表中的配置文件。
|
||||
|
||||
临时添加两条路径到 `KUBECONFIG` 环境变量中。例如：
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG=("config-demo;config-demo-2")
|
||||
```
|
||||
|
||||
<!--
|
||||
In your `config-exercise` directory, enter this command:
|
||||
-->
|
||||
在 `config-exercise` 目录中输入以下命令：
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows merged information from all the files listed in your `KUBECONFIG`
|
||||
environment variable. In particular, notice that the merged information has the
|
||||
`dev-ramp-up` context from the `config-demo-2` file and the three contexts from
|
||||
the `config-demo` file:
|
||||
-->
|
||||
输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。
|
||||
特别地，注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自
|
||||
`config-demo` 文件的三个上下文：
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
<!--
|
||||
For more information about how kubeconfig files are merged, see
|
||||
[Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
-->
|
||||
关于 kubeconfig 文件如何合并的更多信息，请参考
|
||||
[使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
|
||||
<!--
|
||||
## Explore the $HOME/.kube directory
|
||||
|
||||
If you already have a cluster, and you can use `kubectl` to interact with
|
||||
the cluster, then you probably have a file named `config` in the `$HOME/.kube`
|
||||
directory.
|
||||
|
||||
Go to `$HOME/.kube`, and see what files are there. Typically, there is a file named
|
||||
`config`. There might also be other configuration files in this directory. Briefly
|
||||
familiarize yourself with the contents of these files.
|
||||
-->
|
||||
## 探索 $HOME/.kube 目录 {#explore-the-home-kube-directory}
|
||||
|
||||
如果用户已经拥有一个集群，可以使用 `kubectl` 与集群进行交互，
|
||||
那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。
|
||||
|
||||
进入 `$HOME/.kube` 目录，看看那里有什么文件。通常会有一个名为
|
||||
`config` 的文件，目录中可能还有其他配置文件。请简单地熟悉这些文件的内容。
|
||||
|
||||
<!--
|
||||
## Append $HOME/.kube/config to your KUBECONFIG environment variable
|
||||
|
||||
If you have a `$HOME/.kube/config` file, and it's not already listed in your
|
||||
`KUBECONFIG` environment variable, append it to your `KUBECONFIG` environment variable now.
|
||||
For example:
|
||||
-->
|
||||
## 将 $HOME/.kube/config 追加到 KUBECONFIG 环境变量中 {#append-home-kube-config-to-your-kubeconfig-environment-variable}
|
||||
|
||||
如果有 `$HOME/.kube/config` 文件，并且还未列在 `KUBECONFIG` 环境变量中，
|
||||
那么现在将它追加到 `KUBECONFIG` 环境变量中。
|
||||
例如：
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
```
|
||||
|
||||
### Windows Powershell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
|
||||
```
|
||||
|
||||
<!--
|
||||
View configuration information merged from all the files that are now listed
|
||||
in your `KUBECONFIG` environment variable. In your config-exercise directory, enter:
|
||||
-->
|
||||
在配置练习目录中输入以下命令，查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息：
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
## Clean up
|
||||
|
||||
Return your `KUBECONFIG` environment variable to its original value. For example:<br>
|
||||
-->
|
||||
## 清理 {#clean-up}
|
||||
|
||||
将 `KUBECONFIG` 环境变量还原为原始值。例如：
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
-->
|
||||
|
||||
* [使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: 为集群配置 DNS
|
||||
weight: 120
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Configure DNS for a Cluster
|
||||
weight: 120
|
||||
content_type: concept
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default. In Kubernetes version 1.11 and later, CoreDNS is recommended and is installed by default with kubeadm.
|
||||
-->
|
||||
Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。
|
||||
在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS，
|
||||
kubeadm 默认会安装 CoreDNS。
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
For more information on how to configure CoreDNS for a Kubernetes cluster, see the [Customizing DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/). An example demonstrating how to use Kubernetes DNS with kube-dns, see the [Kubernetes DNS sample plugin](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
|
||||
-->
|
||||
要了解关于如何为 Kubernetes 集群配置 CoreDNS 的更多信息，参阅
|
||||
[定制 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/)。
|
||||
关于如何利用 kube-dns 配置 kubernetes DNS 的演示例子，参阅
|
||||
[Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。
|
||||
|
||||
|
||||
@@ -0,0 +1,349 @@
|
||||
---
|
||||
title: 使用 Service 把前端连接到后端
|
||||
content_type: tutorial
|
||||
weight: 70
|
||||
---
|
||||
<!--
|
||||
title: Connect a Frontend to a Backend Using Services
|
||||
content_type: tutorial
|
||||
weight: 70
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This task shows how to create a _frontend_ and a _backend_ microservice. The backend
|
||||
microservice is a hello greeter. The frontend exposes the backend using nginx and a
|
||||
Kubernetes {{< glossary_tooltip term_id="service" >}} object.
|
||||
-->
|
||||
|
||||
本任务会描述如何创建前端（Frontend）微服务和后端（Backend）微服务。后端微服务是一个 hello 欢迎程序。
|
||||
前端通过 nginx 和一个 Kubernetes {{< glossary_tooltip term_id="service" text="服务" >}}
|
||||
暴露后端所提供的服务。
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
<!--
|
||||
* Create and run a sample `hello` backend microservice using a
|
||||
{{< glossary_tooltip term_id="deployment" >}} object.
|
||||
* Use a Service object to send traffic to the backend microservice's multiple replicas.
|
||||
* Create and run a `nginx` frontend microservice, also using a Deployment object.
|
||||
* Configure the frontend microservice to send traffic to the backend microservice.
|
||||
* Use a Service object of `type=LoadBalancer` to expose the frontend microservice
|
||||
outside the cluster.
|
||||
-->
|
||||
* 使用部署对象（Deployment object）创建并运行一个 `hello` 后端微服务
|
||||
* 使用一个 Service 对象将请求流量发送到后端微服务的多个副本
|
||||
* 同样使用一个 Deployment 对象创建并运行一个 `nginx` 前端微服务
|
||||
* 配置前端微服务将请求流量发送到后端微服务
|
||||
* 使用 `type=LoadBalancer` 的 Service 对象将全段微服务暴露到集群外部
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
This task uses
|
||||
[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
|
||||
require a supported environment. If your environment does not support this, you can use a Service of type
|
||||
[NodePort](/docs/concepts/services-networking/service/#type-nodeport) instead.
|
||||
-->
|
||||
本任务使用[外部负载均衡服务](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，
|
||||
所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用
|
||||
[NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport)
|
||||
类型的服务代替。
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
<!--
|
||||
## Creating the backend using a Deployment
|
||||
|
||||
The backend is a simple hello greeter microservice. Here is the configuration
|
||||
file for the backend Deployment:
|
||||
-->
|
||||
### 使用部署对象（Deployment）创建后端
|
||||
|
||||
后端是一个简单的 hello 欢迎微服务应用。这是后端应用的 Deployment 配置文件：
|
||||
|
||||
{{< codenew file="service/access/backend-deployment.yaml" >}}
|
||||
|
||||
<!--
|
||||
Create the backend Deployment:
|
||||
-->
|
||||
创建后端 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
View information about the backend Deployment:
|
||||
-->
|
||||
查看后端的 Deployment 信息：
|
||||
|
||||
```shell
|
||||
kubectl describe deployment backend
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
Name: backend
|
||||
Namespace: default
|
||||
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
|
||||
Labels: app=hello
|
||||
tier=backend
|
||||
track=stable
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=hello,tier=backend,track=stable
|
||||
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
Pod Template:
|
||||
Labels: app=hello
|
||||
tier=backend
|
||||
track=stable
|
||||
Containers:
|
||||
hello:
|
||||
Image: "gcr.io/google-samples/hello-go-gke:1.0"
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: hello-3621623197 (3/3 replicas created)
|
||||
Events:
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
## Creating the `hello` Service object
|
||||
|
||||
The key to sending requests from a frontend to a backend is the backend
|
||||
Service. A Service creates a persistent IP address and DNS name entry
|
||||
so that the backend microservice can always be reached. A Service uses
|
||||
{{< glossary_tooltip text="selectors" term_id="selector" >}} to find
|
||||
the Pods that it routes traffic to.
|
||||
|
||||
First, explore the Service configuration file:
|
||||
-->
|
||||
### 创建 `hello` Service 对象
|
||||
|
||||
将请求从前端发送到到后端的关键是后端 Service。Service 创建一个固定 IP 和 DNS 解析名入口，
|
||||
使得后端微服务总是可达。Service 使用
|
||||
{{< glossary_tooltip text="选择算符" term_id="selector" >}}
|
||||
来寻找目标 Pod。
|
||||
|
||||
首先，浏览 Service 的配置文件：
|
||||
|
||||
{{< codenew file="service/access/backend-service.yaml" >}}
|
||||
|
||||
<!--
|
||||
In the configuration file, you can see that the Service named `hello` routes
|
||||
traffic to Pods that have the labels `app: hello` and `tier: backend`.
|
||||
-->
|
||||
配置文件中，你可以看到名为 `hello` 的 Service 将流量路由到包含 `app: hello`
|
||||
和 `tier: backend` 标签的 Pod。
|
||||
|
||||
<!--
|
||||
Create the backend Service:
|
||||
-->
|
||||
创建后端 Service：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
At this point, you have a `backend` Deployment running three replicas of your `hello`
|
||||
application, and you have a Service that can route traffic to them. However, this
|
||||
service is neither available nor resolvable outside the cluster.
|
||||
-->
|
||||
此时，你已经有了一个运行着 `hello` 应用的三个副本的 `backend` Deployment，你也有了
|
||||
一个 Service 用于路由网络流量。不过，这个服务在集群外部无法访问也无法解析。
|
||||
|
||||
<!--
|
||||
## Creating the frontend
|
||||
|
||||
Now that you have your backend running, you can create a frontend that is accessible
|
||||
outside the cluster, and connects to the backend by proxying requests to it.
|
||||
|
||||
The frontend sends requests to the backend worker Pods by using the DNS name
|
||||
given to the backend Service. The DNS name is `hello`, which is the value
|
||||
of the `name` field in the `examples/service/access/backend-service.yaml`
|
||||
configuration file.
|
||||
|
||||
The Pods in the frontend Deployment run an nginx image that is configured
|
||||
to proxy requests to the hello backend Service. Here is the nginx configuration file:
|
||||
-->
|
||||
### 创建前端应用
|
||||
|
||||
现在你已经有了运行中的后端应用，你可以创建一个可在集群外部访问的前端，并通过代理
|
||||
前端的请求连接到后端。
|
||||
|
||||
前端使用被赋予后端 Service 的 DNS 名称将请求发送到后端工作 Pods。这一 DNS
|
||||
名称为 `hello`，也就是 `examples/service/access/backend-service.yaml` 配置
|
||||
文件中 `name` 字段的取值。
|
||||
|
||||
前端 Deployment 中的 Pods 运行一个 nginx 镜像，这个已经配置好的镜像会将请求转发
|
||||
给后端的 hello Service。下面是 nginx 的配置文件：
|
||||
|
||||
{{< codenew file="service/access/frontend-nginx.conf" >}}
|
||||
|
||||
<!--
|
||||
Similar to the backend, the frontend has a Deployment and a Service. An important
|
||||
difference to notice between the backend and frontend services, is that the
|
||||
configuration for the frontend Service has `type: LoadBalancer`, which means that
|
||||
the Service uses a load balancer provisioned by your cloud provider and will be
|
||||
accessible from outside the cluster.
|
||||
-->
|
||||
与后端类似，前端用包含一个 Deployment 和一个 Service。后端与前端服务之间的一个
|
||||
重要区别是前端 Service 的配置文件包含了 `type: LoadBalancer`，也就是说，Service
|
||||
会使用你的云服务商的默认负载均衡设备，从而实现从集群外访问的目的。
|
||||
|
||||
{{< codenew file="service/access/frontend-service.yaml" >}}
|
||||
|
||||
{{< codenew file="service/access/frontend-deployment.yaml" >}}
|
||||
|
||||
|
||||
<!--
|
||||
Create the frontend Deployment and Service:
|
||||
-->
|
||||
创建前端 Deployment 和 Service：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output verifies that both resources were created:
|
||||
-->
|
||||
通过输出确认两个资源都已经被创建：
|
||||
|
||||
```
|
||||
deployment.apps/frontend created
|
||||
service/frontend created
|
||||
```
|
||||
|
||||
<!--
|
||||
The nginx configuration is baked into the
|
||||
[container image](/examples/service/access/Dockerfile). A better way to do this would
|
||||
be to use a
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
|
||||
so that you can change the configuration more easily.
|
||||
-->
|
||||
{{< note >}}
|
||||
这个 nginx 配置文件是被打包在
|
||||
[容器镜像](/examples/service/access/Dockerfile) 里的。
|
||||
更好的方法是使用
|
||||
[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)，
|
||||
这样的话你可以更轻易地更改配置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Interact with the frontend Service
|
||||
|
||||
Once you've created a Service of type LoadBalancer, you can use this
|
||||
command to find the external IP:
|
||||
-->
|
||||
### 与前端 Service 交互 {#interact-with-the-frontend-service}
|
||||
|
||||
一旦你创建了 LoadBalancer 类型的 Service，你可以使用这条命令查看外部 IP：
|
||||
|
||||
```shell
|
||||
kubectl get service frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
This displays the configuration for the `frontend` Service and watches for
|
||||
changes. Initially, the external IP is listed as `<pending>`:
|
||||
-->
|
||||
外部 IP 字段的生成可能需要一些时间。如果是这种情况，外部 IP 会显示为 `<pending>`。
|
||||
|
||||
```
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend 10.51.252.116 <pending> 80/TCP 10s
|
||||
```
|
||||
|
||||
<!--
|
||||
As soon as an external IP is provisioned, however, the configuration updates
|
||||
to include the new IP under the `EXTERNAL-IP` heading:
|
||||
-->
|
||||
当外部 IP 地址被分配可用时，配置会更新，在 `EXTERNAL-IP` 头部下显示新的 IP：
|
||||
|
||||
```
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m
|
||||
```
|
||||
|
||||
<!--
|
||||
That IP can now be used to interact with the `frontend` service from outside the
|
||||
cluster.
|
||||
-->
|
||||
这一新的 IP 地址就可以用来从集群外与 `frontend` 服务交互了。
|
||||
|
||||
|
||||
<!--
|
||||
## Send traffic through the frontend
|
||||
|
||||
The frontend and backend are now connected. You can hit the endpoint
|
||||
by using the curl command on the external IP of your frontend Service.
|
||||
-->
|
||||
### 通过前端发送流量
|
||||
|
||||
前端和后端已经完成连接了。你可以使用 curl 命令通过你的前端 Service 的外部
|
||||
IP 访问服务端点。
|
||||
|
||||
```shell
|
||||
curl http://${EXTERNAL_IP} # 将 EXTERNAL_P 替换为你之前看到的外部 IP
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows the message generated by the backend:
|
||||
-->
|
||||
输出显示后端生成的消息：
|
||||
|
||||
```json
|
||||
{"message":"Hello"}
|
||||
```
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
<!--
|
||||
To delete the Services, enter this command:
|
||||
-->
|
||||
要删除服务，输入下面的命令：
|
||||
|
||||
```shell
|
||||
kubectl delete services frontend backend
|
||||
```
|
||||
|
||||
<!--
|
||||
To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command:
|
||||
-->
|
||||
要删除在前端和后端应用中运行的 Deployment、ReplicaSet 和 Pod，输入下面的命令：
|
||||
|
||||
```shell
|
||||
kubectl delete deployment frontend backend
|
||||
```
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn more about [Services](/docs/concepts/services-networking/service/)
|
||||
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
* Learn more about [DNS for Service and Pods](/docs/concepts/services-networking/dns-pod-service/)
|
||||
-->
|
||||
* 进一步了解 [Service](/zh/docs/concepts/services-networking/service/)
|
||||
* 进一步了解 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
* 进一步了解 [Service 和 Pods 的 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)
|
||||
|
||||
@@ -0,0 +1,331 @@
|
||||
---
|
||||
title: 创建外部负载均衡器
|
||||
content_type: task
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Create an External Load Balancer
|
||||
content_type: task
|
||||
weight: 80
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to create an external load balancer.
|
||||
-->
|
||||
本文展示如何创建一个外部负载均衡器。
|
||||
|
||||
<!--
|
||||
When creating a {{< glossary_tooltip text="Service" term_id="service" >}}, you have
|
||||
the option of automatically creating a cloud load balancer. This provides an
|
||||
externally-accessible IP address that sends traffic to the correct port on your cluster
|
||||
nodes,
|
||||
_provided your cluster runs in a supported environment and is configured with
|
||||
the correct cloud load balancer provider package_.
|
||||
-->
|
||||
创建 {{< glossary_tooltip text="服务" term_id="service" >}} 时，你可以选择自动创建云网络负载均衡器。
|
||||
负载均衡器提供外部可访问的 IP 地址，可将流量发送到集群节点上的正确端口上
|
||||
（ **假设集群在支持的环境中运行，并配置了正确的云负载均衡器驱动包**）。
|
||||
|
||||
<!--
|
||||
You can also use an {{< glossary_tooltip term_id="ingress" >}} in place of Service.
|
||||
For more information, check the [Ingress](/docs/concepts/services-networking/ingress/)
|
||||
documentation.
|
||||
-->
|
||||
你还可以使用 {{< glossary_tooltip text="Ingress" term_id="ingress" >}} 代替 Service。
|
||||
更多信息，请参阅 [Ingress](/zh/docs/concepts/services-networking/ingress/) 文档。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!--
|
||||
Your cluster must be running in a cloud or other environment that already has support
|
||||
for configuring external load balancers.
|
||||
-->
|
||||
你的集群必须在已经支持配置外部负载均衡器的云或其他环境中运行。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Create a Service
|
||||
|
||||
### Create a Service from a manifest
|
||||
|
||||
To create an external load balancer, add the following line to your
|
||||
Service manifest:
|
||||
-->
|
||||
## 创建服务 {#create-a-service}
|
||||
|
||||
### 基于清单文件创建服务 {#create-a-service-from-a-manifest}
|
||||
|
||||
要创建外部负载均衡器，请将以下内容添加到你的 Service 清单文件：
|
||||
|
||||
```yaml
|
||||
type: LoadBalancer
|
||||
```
|
||||
|
||||
<!--
|
||||
Your manifest might then look like:
|
||||
-->
|
||||
你的清单文件可能会如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: example-service
|
||||
spec:
|
||||
selector:
|
||||
app: example
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
type: LoadBalancer
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create a Service using kubectl
|
||||
|
||||
You can alternatively create the service with the `kubectl expose` command and
|
||||
its `--type=LoadBalancer` flag:
|
||||
-->
|
||||
### 使用 kubectl 创建 Service {#create-a-service-using-kubectl}
|
||||
|
||||
你也可以使用 `kubectl expose` 命令及其 `--type=LoadBalancer` 参数创建服务：
|
||||
|
||||
```bash
|
||||
kubectl expose deployment example --port=8765 --target-port=9376 \
|
||||
--name=example-service --type=LoadBalancer
|
||||
```
|
||||
|
||||
<!--
|
||||
This command creates a new Service using the same selectors as the referenced
|
||||
resource (in the case of the example above, a
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}} named `example`).
|
||||
|
||||
For more information, including optional flags, refer to the
|
||||
[`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose).
|
||||
-->
|
||||
此命令通过使用与引用资源（在上面的示例的情况下，名为 `example` 的
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
|
||||
相同的选择器来创建一个新的服务。
|
||||
|
||||
更多信息（包括更多的可选参数），请参阅
|
||||
[`kubectl expose` 指南](/docs/reference/generated/kubectl/kubectl-commands/#expose)。
|
||||
|
||||
<!--
|
||||
## Finding your IP address
|
||||
|
||||
You can find the IP address created for your service by getting the service
|
||||
information through `kubectl`:
|
||||
-->
|
||||
## 找到你的 IP 地址 {#finding-your-ip-address}
|
||||
|
||||
你可以通过 `kubectl` 获取服务信息，找到为你的服务创建的 IP 地址：
|
||||
|
||||
```bash
|
||||
kubectl describe services example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
which should produce output similar to:
|
||||
-->
|
||||
这将获得类似如下输出：
|
||||
|
||||
```
|
||||
Name: example-service
|
||||
Namespace: default
|
||||
Labels: app=example
|
||||
Annotations: <none>
|
||||
Selector: app=example
|
||||
Type: LoadBalancer
|
||||
IP Families: <none>
|
||||
IP: 10.3.22.96
|
||||
IPs: 10.3.22.96
|
||||
LoadBalancer Ingress: 192.0.2.89
|
||||
Port: <unset> 8765/TCP
|
||||
TargetPort: 9376/TCP
|
||||
NodePort: <unset> 30593/TCP
|
||||
Endpoints: 172.17.0.3:9376
|
||||
Session Affinity: None
|
||||
External Traffic Policy: Cluster
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
<!--
|
||||
The load balancer's IP address is listed next to `LoadBalancer Ingress`.
|
||||
-->
|
||||
负载均衡器的 IP 地址列在 `LoadBalancer Ingress` 旁边。
|
||||
|
||||
<!--
|
||||
If you are running your service on Minikube, you can find the assigned IP address and port with:
|
||||
-->
|
||||
{{< note >}}
|
||||
如果你在 Minikube 上运行服务，你可以通过以下命令找到分配的 IP 地址和端口：
|
||||
|
||||
```bash
|
||||
minikube service example-service --url
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Preserving the client source IP
|
||||
|
||||
By default, the source IP seen in the target container is *not the original
|
||||
source IP* of the client. To enable preservation of the client IP, the following
|
||||
fields can be configured in the `.spec` of the Service:
|
||||
-->
|
||||
## 保留客户端源 IP {#preserving-the-client-source-ip}
|
||||
|
||||
默认情况下，目标容器中看到的源 IP 将**不是客户端的原始源 IP**。
|
||||
要启用保留客户端 IP，可以在服务的 `.spec` 中配置以下字段：
|
||||
|
||||
<!--
|
||||
* `.spec.externalTrafficPolicy` - denotes if this Service desires to route
|
||||
external traffic to node-local or cluster-wide endpoints. There are two available
|
||||
options: `Cluster` (default) and `Local`. `Cluster` obscures the client source
|
||||
IP and may cause a second hop to another node, but should have good overall
|
||||
load-spreading. `Local` preserves the client source IP and avoids a second hop
|
||||
for LoadBalancer and NodePort type Services, but risks potentially imbalanced
|
||||
traffic spreading.
|
||||
-->
|
||||
* `.spec.externalTrafficPolicy` - 表示此 Service 是否希望将外部流量路由到节点本地或集群范围的端点。
|
||||
有两个可用选项：`Cluster`（默认）和 `Local`。
|
||||
`Cluster` 隐藏了客户端源 IP，可能导致第二跳到另一个节点，但具有良好的整体负载分布。
|
||||
`Local` 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二跳，
|
||||
但存在潜在的不均衡流量传播风险。
|
||||
|
||||
<!--
|
||||
* `.spec.healthCheckNodePort` - specifies the health check node port
|
||||
(numeric port number) for the service. If you don't specify
|
||||
`healthCheckNodePort`, the service controller allocates a port from your
|
||||
cluster's NodePort range.
|
||||
You can configure that range by setting an API server command line option,
|
||||
`--service-node-port-range`. The Service will use the user-specified
|
||||
`healthCheckNodePort` value if you specify it, provided that the
|
||||
Service `type` is set to LoadBalancer and `externalTrafficPolicy` is set
|
||||
to `Local`.
|
||||
-->
|
||||
* `.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。
|
||||
如果你未指定 `healthCheckNodePort`，服务控制器从集群的 NodePort 范围内分配一个端口。
|
||||
你可以通过设置 API 服务器的命令行选项 `--service-node-port-range` 来配置上述范围。
|
||||
在服务 `type` 设置为 LoadBalancer 并且 `externalTrafficPolicy` 设置为 `Local` 时，
|
||||
Service 将会使用用户指定的 `healthCheckNodePort` 值（如果你指定了它）。
|
||||
|
||||
<!--
|
||||
Setting `externalTrafficPolicy` to Local in the Service manifest
|
||||
activates this feature. For example:
|
||||
-->
|
||||
可以通过在服务的清单文件中将 `externalTrafficPolicy` 设置为 Local 来激活此功能。比如：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: example-service
|
||||
spec:
|
||||
selector:
|
||||
app: example
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
externalTrafficPolicy: Local
|
||||
type: LoadBalancer
|
||||
```
|
||||
|
||||
<!--
|
||||
### Caveats and limitations when preserving source IPs
|
||||
|
||||
Load balancing services from some cloud providers do not let you configure different weights for each target.
|
||||
|
||||
With each target weighted equally in terms of sending traffic to Nodes, external
|
||||
traffic is not equally load balanced across different Pods. The external load balancer
|
||||
is unaware of the number of Pods on each node that are used as a target.
|
||||
-->
|
||||
### 保留源 IP 时的注意事项和限制 {#caveats-and-limitations-when-preserving-source-ips}
|
||||
|
||||
一些云服务供应商的负载均衡服务不允许你为每个目标配置不同的权重。
|
||||
|
||||
由于每个目标在向节点发送流量方面的权重相同，因此外部流量不会在不同 Pod 之间平均负载。
|
||||
外部负载均衡器不知道每个节点上用作目标的 Pod 数量。
|
||||
|
||||
<!--
|
||||
Where `NumServicePods << _NumNodes` or `NumServicePods >> NumNodes`, a fairly close-to-equal
|
||||
distribution will be seen, even without weights.
|
||||
|
||||
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
|
||||
-->
|
||||
在 `NumServicePods << _NumNodes` 或 `NumServicePods >> NumNodes` 时，
|
||||
即使没有权重，也会看到接近相等的分布。
|
||||
|
||||
内部 Pod 到 Pod 的流量应该与 ClusterIP 服务类似，所有 Pod 的概率相同。
|
||||
|
||||
<!--
|
||||
## Garbage Collecting Load Balancers
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
|
||||
|
||||
In usual case, the correlating load balancer resources in cloud provider should
|
||||
be cleaned up soon after a LoadBalancer type Service is deleted. But it is known
|
||||
that there are various corner cases where cloud resources are orphaned after the
|
||||
associated Service is deleted. Finalizer Protection for Service LoadBalancers was
|
||||
introduced to prevent this from happening. By using finalizers, a Service resource
|
||||
will never be deleted until the correlating load balancer resources are also deleted.
|
||||
-->
|
||||
## 回收负载均衡器 {#garbage-collecting-load-balancers}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
|
||||
|
||||
在通常情况下，应在删除 LoadBalancer 类型 Service 后立即清除云服务供应商中的相关负载均衡器资源。
|
||||
但是，众所周知，在删除关联的服务后，云资源被孤立的情况很多。
|
||||
引入了针对服务负载均衡器的终结器保护，以防止这种情况发生。
|
||||
通过使用终结器，在删除相关的负载均衡器资源之前，也不会删除服务资源。
|
||||
|
||||
<!--
|
||||
Specifically, if a Service has `type` LoadBalancer, the service controller will attach
|
||||
a finalizer named `service.kubernetes.io/load-balancer-cleanup`.
|
||||
The finalizer will only be removed after the load balancer resource is cleaned up.
|
||||
This prevents dangling load balancer resources even in corner cases such as the
|
||||
service controller crashing.
|
||||
-->
|
||||
具体来说，如果服务具有 `type` LoadBalancer，则服务控制器将附加一个名为
|
||||
`service.kubernetes.io/load-balancer-cleanup` 的终结器。
|
||||
仅在清除负载均衡器资源后才能删除终结器。
|
||||
即使在诸如服务控制器崩溃之类的极端情况下，这也可以防止负载均衡器资源悬空。
|
||||
|
||||
<!--
|
||||
## External load balancer providers
|
||||
|
||||
It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
|
||||
-->
|
||||
## 外部负载均衡器供应商 {#external-load-balancer-providers}
|
||||
|
||||
请务必注意，此功能的数据路径由 Kubernetes 集群外部的负载均衡器提供。
|
||||
|
||||
<!--
|
||||
When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods
|
||||
within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the nodes
|
||||
hosting the relevant Kubernetes pods. The Kubernetes control plane automates the creation of the external load balancer,
|
||||
health checks (if needed), and packet filtering rules (if needed). Once the cloud provider allocates an IP address for the load
|
||||
balancer, the control plane looks up that external IP address and populates it into the Service object.
|
||||
-->
|
||||
当服务 `type` 设置为 LoadBalancer 时，Kubernetes 向集群中的 Pod 提供的功能等同于
|
||||
`type` 设置为 ClusterIP，并通过使用托管了相关 Kubernetes Pod 的节点作为条目对负载均衡器
|
||||
（从外部到 Kubernetes）进行编程来扩展它。
|
||||
Kubernetes 控制平面自动创建外部负载均衡器、健康检查（如果需要）和包过滤规则（如果需要）。
|
||||
一旦云服务供应商为负载均衡器分配了 IP 地址，控制平面就会查找该外部 IP 地址并将其填充到 Service 对象中。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read about [Service](/docs/concepts/services-networking/service/)
|
||||
* Read about [Ingress](/docs/concepts/services-networking/ingress/)
|
||||
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
|
||||
-->
|
||||
* 阅读[服务](/zh/docs/concepts/services-networking/service/)
|
||||
* 阅读 [Ingress](/zh/docs/concepts/services-networking/ingress/)
|
||||
* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
@@ -0,0 +1,443 @@
|
||||
---
|
||||
title: 在 Minikube 环境中使用 NGINX Ingress 控制器配置 Ingress
|
||||
content_type: task
|
||||
weight: 100
|
||||
min-kubernetes-server-version: 1.19
|
||||
---
|
||||
<!--
|
||||
title: Set up Ingress on Minikube with the NGINX Ingress Controller
|
||||
content_type: task
|
||||
weight: 100
|
||||
min-kubernetes-server-version: 1.19
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access
|
||||
to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress.
|
||||
|
||||
This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.
|
||||
-->
|
||||
[Ingress](/zh/docs/concepts/services-networking/ingress/)是一种 API 对象，其中定义了一些规则使得集群中的
|
||||
服务可以从集群外访问。
|
||||
[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
|
||||
负责满足 Ingress 中所设置的规则。
|
||||
|
||||
本节为你展示如何配置一个简单的 Ingress，根据 HTTP URI 将服务请求路由到
|
||||
服务 `web` 或 `web2`。
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
如果你使用的是较早的 Kubernetes 版本，请切换到该版本的文档。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
### Create a Minikube cluster
|
||||
-->
|
||||
### 创建一个 Minikube 集群
|
||||
|
||||
使用 Katacoda
|
||||
: {{< kat-button >}}
|
||||
|
||||
本地
|
||||
: 如果已经在本地[安装Minikube](/zh/docs/tasks/tools/#minikube)，
|
||||
请运行 `minikube start` 创建一个集群。
|
||||
|
||||
<!--
|
||||
## Enable the Ingress controller
|
||||
|
||||
1. To enable the NGINX Ingress controller, run the following command:
|
||||
-->
|
||||
## 启用 Ingress 控制器
|
||||
|
||||
1. 为了启用 NGINIX Ingress 控制器，可以运行下面的命令：
|
||||
|
||||
|
||||
```shell
|
||||
minikube addons enable ingress
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Verify that the NGINX Ingress controller is running
|
||||
-->
|
||||
2. 检查验证 NGINX Ingress 控制器处于运行状态：
|
||||
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="minikube v1.19 或更高版本" %}}
|
||||
```shell
|
||||
kubectl get pods -n ingress-nginx
|
||||
```
|
||||
<!-- It can take up to a minute before you see these pods running OK. -->
|
||||
{{< note >}}最多可能需要等待一分钟才能看到这些 Pod 运行正常。{{< /note >}}
|
||||
|
||||
<!-- The output is similar to: -->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m
|
||||
ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m
|
||||
ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="minikube v1.18.1 或更早版本" %}}
|
||||
```shell
|
||||
kubectl get pods -n kube-system
|
||||
```
|
||||
<!-- It can take up to a minute before you see these pods running OK. -->
|
||||
{{< note >}}最多可能需要等待一分钟才能看到这些 Pod 运行正常。{{< /note >}}
|
||||
|
||||
<!-- The output is similar to: -->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m
|
||||
kube-addon-manager-minikube 1/1 Running 0 3m
|
||||
kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m
|
||||
kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m
|
||||
nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m
|
||||
storage-provisioner 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
<!--
|
||||
Make sure that you see a Pod with a name that starts with `nginx-ingress-controller-`.
|
||||
-->
|
||||
请确保可以在输出中看到一个名称以 `nginx-ingress-controller-` 为前缀的 Pod。
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
## Deploy a hello, world app
|
||||
|
||||
1. Create a Deployment using the following command:
|
||||
-->
|
||||
## 部署一个 Hello World 应用
|
||||
|
||||
1. 使用下面的命令创建一个 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
|
||||
```
|
||||
|
||||
<!--The output should be:-->
|
||||
输出：
|
||||
|
||||
```
|
||||
deployment.apps/web created
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Expose the Deployment:
|
||||
-->
|
||||
2. 将 Deployment 暴露出来：
|
||||
|
||||
```shell
|
||||
kubectl expose deployment web --type=NodePort --port=8080
|
||||
```
|
||||
|
||||
<!--The output should be:-->
|
||||
输出：
|
||||
|
||||
```
|
||||
service/web exposed
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Verify the Service is created and is available on a node port:
|
||||
-->
|
||||
3. 验证 Service 已经创建，并且可能从节点端口访问：
|
||||
|
||||
```shell
|
||||
kubectl get service web
|
||||
```
|
||||
|
||||
<!-- The output is similar to: -->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Visit the service via NodePort:
|
||||
-->
|
||||
4. 使用节点端口信息访问服务：
|
||||
|
||||
```shell
|
||||
minikube service web --url
|
||||
```
|
||||
|
||||
<!-- The output is similar to: -->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
http://172.17.0.15:31637
|
||||
```
|
||||
|
||||
<!--
|
||||
Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果使用的是 Katacoda 环境，在终端面板顶端，请点击加号标志。
|
||||
然后点击 **Select port to view on Host 1**。
|
||||
输入节点和端口号（这里是`31637`），之后点击 **Display Port**。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- The output is similar to: -->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
|
||||
<!--
|
||||
You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
|
||||
the app using the Ingress resource.
|
||||
-->
|
||||
你现在应该可以通过 Minikube 的 IP 地址和节点端口来访问示例应用了。
|
||||
下一步是让自己能够通过 Ingress 资源来访问应用。
|
||||
|
||||
<!--
|
||||
## Create an Ingress
|
||||
|
||||
The following manifest defines an Ingress that sends traffic to your Service via hello-world.info.
|
||||
|
||||
1. Create `example-ingress.yaml` from the following file:
|
||||
-->
|
||||
## 创建一个 Ingress
|
||||
|
||||
下面是一个定义 Ingress 的配置文件，负责通过 `hello-world.info` 将请求
|
||||
转发到你的服务。
|
||||
|
||||
1. 根据下面的 YAML 创建文件 `example-ingress.yaml`：
|
||||
|
||||
{{< codenew file="service/networking/example-ingress.yaml" >}}
|
||||
|
||||
<!--
|
||||
1. Create the Ingress object by running the following command:
|
||||
-->
|
||||
2. 通过运行下面的命令创建 Ingress 对象：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
|
||||
```
|
||||
|
||||
<!-- The output should be: -->
|
||||
输出：
|
||||
|
||||
```
|
||||
ingress.networking.k8s.io/example-ingress created
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Verify the IP address is set:
|
||||
-->
|
||||
3. 验证 IP 地址已被设置：
|
||||
|
||||
```shell
|
||||
kubectl get ingress
|
||||
```
|
||||
|
||||
<!-- This can take a couple of minutes. -->
|
||||
{{< note >}}
|
||||
此操作可能需要几分钟时间。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- You should see an IPv4 address in the ADDRESS column; for example: -->
|
||||
接下来你将会在ADDRESS列中看到IPv4地址，例如：
|
||||
|
||||
```
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
example-ingress <none> hello-world.info 172.17.0.15 80 38s
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Add the following line to the bottom of the `/etc/hosts` file on
|
||||
your computer (you will need administrator access):
|
||||
-->
|
||||
4. 在 `/etc/hosts` 文件的末尾添加以下内容（需要管理员访问权限）：
|
||||
|
||||
<!--
|
||||
If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果你在本地运行 Minikube 环境，需要使用 `minikube ip` 获得外部 IP 地址。
|
||||
Ingress 列表中显示的 IP 地址会是内部 IP 地址。
|
||||
{{< /note >}}
|
||||
```
|
||||
172.17.0.15 hello-world.info
|
||||
```
|
||||
|
||||
<!--
|
||||
After you make this change, your web browser sends requests for
|
||||
hello-world.info URLs to Minikube.
|
||||
-->
|
||||
添加完成后，在浏览器中访问URL `hello-world.info`，请求将被发送到 Minikube。
|
||||
|
||||
<!--
|
||||
1. Verify that the Ingress controller is directing traffic:
|
||||
-->
|
||||
5. 验证 Ingress 控制器能够转发请求流量：
|
||||
|
||||
```shell
|
||||
curl hello-world.info
|
||||
```
|
||||
|
||||
<!-- You should see: -->
|
||||
你应该看到类似输出：
|
||||
|
||||
```
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
|
||||
<!--
|
||||
If you are running Minikube locally, you can visit hello-world.info from your browser.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果你在使用本地 Minikube 环境，你可以从浏览器中访问 hello-world.info。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Create a second Deployment
|
||||
|
||||
1. Create another Deployment using the following command:
|
||||
-->
|
||||
## 创建第二个 Deployment
|
||||
|
||||
1. 使用下面的命令创建第二个 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
|
||||
```
|
||||
|
||||
<!-- The output should be: -->
|
||||
输出：
|
||||
|
||||
```
|
||||
deployment.apps/web2 created
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Expose the second Deployment:
|
||||
-->
|
||||
2. 将第二个 Deployment 暴露出来：
|
||||
|
||||
```shell
|
||||
kubectl expose deployment web2 --port=8080 --type=NodePort
|
||||
```
|
||||
|
||||
<!-- The output should be: -->
|
||||
输出：
|
||||
|
||||
```
|
||||
service/web2 exposed
|
||||
```
|
||||
|
||||
<!--
|
||||
## Edit the existing Ingress {#edit-ingress}
|
||||
|
||||
1. Edit the existing `example-ingress.yaml` manifest, and add the
|
||||
following lines at the end:
|
||||
-->
|
||||
## 编辑现有的 Ingress {#edit-ingress}
|
||||
|
||||
1. 编辑现有的 `example-ingress.yaml`，在文件最后添加以下行：
|
||||
|
||||
|
||||
```yaml
|
||||
- path: /v2
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: web2
|
||||
port:
|
||||
number: 8080
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Apply the changes:
|
||||
-->
|
||||
2. 应用变更：
|
||||
|
||||
```shell
|
||||
kubectl apply -f example-ingress.yaml
|
||||
```
|
||||
|
||||
<!-- You should see: -->
|
||||
输出：
|
||||
|
||||
```
|
||||
ingress.networking/example-ingress configured
|
||||
```
|
||||
|
||||
<!--
|
||||
## Test Your Ingress
|
||||
|
||||
1. Access the 1st version of the Hello World app.
|
||||
-->
|
||||
## 测试你的 Ingress
|
||||
|
||||
1. 访问 HelloWorld 应用的第一个版本：
|
||||
|
||||
```shell
|
||||
curl hello-world.info
|
||||
```
|
||||
|
||||
<!-- The output is similar to: -->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Access the 2nd version of the Hello World app.
|
||||
-->
|
||||
2. 访问 HelloWorld 应用的第二个版本：
|
||||
|
||||
```shell
|
||||
curl hello-world.info/v2
|
||||
```
|
||||
|
||||
<!-- The output is similar to: -->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
Hello, world!
|
||||
Version: 2.0.0
|
||||
Hostname: web2-75cd47646f-t8cjk
|
||||
```
|
||||
|
||||
<!--
|
||||
If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果你在本地运行 Minikube 环境，你可以使用浏览器来访问
|
||||
hello-world.info 和 hello-world.info/v2。
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read more about [Ingress](/docs/concepts/services-networking/ingress/)
|
||||
* Read more about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
|
||||
* Read more about [Services](/docs/concepts/services-networking/service/)
|
||||
-->
|
||||
|
||||
* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。
|
||||
* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
|
||||
* 进一步了解 [服务](/zh/docs/concepts/services-networking/service/)
|
||||
+178
@@ -0,0 +1,178 @@
|
||||
---
|
||||
title: 列出集群中所有运行容器的镜像
|
||||
content_type: task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!--
|
||||
title: List All Container Images Running in a Cluster
|
||||
content_type: task
|
||||
weight: 100
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to use kubectl to list all of the Container images
|
||||
for Pods running in a cluster.
|
||||
-->
|
||||
本文展示如何使用 kubectl 来列出集群中所有运行 Pod 的容器的镜像
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
In this exercise you will use kubectl to fetch all of the Pods
|
||||
running in a cluster, and format the output to pull out the list
|
||||
of Containers for each.
|
||||
-->
|
||||
在本练习中，你将使用 kubectl 来获取集群中运行的所有 Pod，并格式化输出来提取每个 Pod 中的容器列表。
|
||||
|
||||
<!--
|
||||
## List all Containers in all namespaces
|
||||
|
||||
- Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces`
|
||||
- Format the output to include only the list of Container image names
|
||||
using `-o jsonpath={.items[*].spec.containers[*].image}`. This will recursively parse out the
|
||||
`image` field from the returned json.
|
||||
- See the [jsonpath reference](/docs/user-guide/jsonpath/)
|
||||
for further information on how to use jsonpath.
|
||||
- Format the output using standard tools: `tr`, `sort`, `uniq`
|
||||
- Use `tr` to replace spaces with newlines
|
||||
- Use `sort` to sort the results
|
||||
- Use `uniq` to aggregate image counts
|
||||
-->
|
||||
## 列出所有命名空间下的所有容器
|
||||
|
||||
- 使用 `kubectl get pods --all-namespaces` 获取所有命名空间下的所有 Pod
|
||||
- 使用 `-o jsonpath={.items[*].spec.containers[*].image}` 来格式化输出，以仅包含容器镜像名称。
|
||||
这将以递归方式从返回的 json 中解析出 `image` 字段。
|
||||
- 参阅 [jsonpath 说明](/zh/docs/reference/kubectl/jsonpath/)
|
||||
获取更多关于如何使用 jsonpath 的信息。
|
||||
- 使用标准化工具来格式化输出：`tr`, `sort`, `uniq`
|
||||
- 使用 `tr` 以用换行符替换空格
|
||||
- 使用 `sort` 来对结果进行排序
|
||||
- 使用 `uniq` 来聚合镜像计数
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
|
||||
tr -s '[[:space:]]' '\n' |\
|
||||
sort |\
|
||||
uniq -c
|
||||
```
|
||||
|
||||
<!--
|
||||
The above command will recursively return all fields named `image`
|
||||
for all items returned.
|
||||
|
||||
As an alternative, it is possible to use the absolute path to the image
|
||||
field within the Pod. This ensures the correct field is retrieved
|
||||
even when the field name is repeated,
|
||||
e.g. many fields are called `name` within a given item:
|
||||
-->
|
||||
上面的命令将递归获取所有返回项目的名为 `image` 的字段。
|
||||
|
||||
作为替代方案，可以使用 Pod 的镜像字段的绝对路径。这确保即使字段名称重复的情况下也能检索到正确的字段，例如，特定项目中的许多字段都称为 `name`：
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
|
||||
```
|
||||
|
||||
<!--
|
||||
The jsonpath is interpreted as follows:
|
||||
|
||||
- `.items[*]`: for each returned value
|
||||
- `.spec`: get the spec
|
||||
- `.containers[*]`: for each container
|
||||
- `.image`: get the image
|
||||
-->
|
||||
jsonpath 解释如下：
|
||||
|
||||
- `.items[*]`: 对于每个返回的值
|
||||
- `.spec`: 获取 spec
|
||||
- `.containers[*]`: 对于每个容器
|
||||
- `.image`: 获取镜像
|
||||
|
||||
<!--
|
||||
When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
|
||||
the `.items[*]` portion of the path should be omitted because a single
|
||||
Pod is returned instead of a list of items.
|
||||
-->
|
||||
{{< note >}}
|
||||
按名字获取单个 Pod 时，例如 `kubectl get pod nginx`，路径的 `.items[*]` 部分应该省略，
|
||||
因为返回的是一个 Pod 而不是一个项目列表。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## List Container images by Pod
|
||||
|
||||
The formatting can be controlled further by using the `range` operation to
|
||||
iterate over elements individually.
|
||||
-->
|
||||
## 按 Pod 列出容器镜像
|
||||
|
||||
可以使用 `range` 操作进一步控制格式化，以单独操作每个元素。
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
sort
|
||||
```
|
||||
|
||||
<!--
|
||||
## List Containers filtering by Pod label
|
||||
|
||||
To target only Pods matching a specific label, use the -l flag. The
|
||||
following matches only Pods with labels matching `app=nginx`.
|
||||
-->
|
||||
## 列出以标签过滤后的 Pod 的所有容器
|
||||
|
||||
要获取匹配特定标签的 Pod，请使用 -l 参数。以下匹配仅与标签 `app=nginx` 相符的 Pod。
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
|
||||
```
|
||||
|
||||
<!--
|
||||
## List Containers filtering by Pod namespace
|
||||
|
||||
To target only pods in a specific namespace, use the namespace flag. The
|
||||
following matches only Pods in the `kube-system` namespace.
|
||||
-->
|
||||
## 列出以命名空间过滤后的 Pod 的所有容器
|
||||
|
||||
要获取匹配特定命名空间的 Pod，请使用 namespace 参数。以下仅匹配 `kube-system` 命名空间下的 Pod。
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
|
||||
```
|
||||
|
||||
<!--
|
||||
## List Containers using a go-template instead of jsonpath
|
||||
|
||||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
|
||||
for formatting the output:
|
||||
-->
|
||||
## 使用 go-template 代替 jsonpath 来获取容器
|
||||
|
||||
作为 jsonpath 的替代，Kubectl 支持使用 [go-templates](https://golang.org/pkg/text/template/) 来格式化输出：
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
### Reference
|
||||
|
||||
* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide
|
||||
* [Go template](https://golang.org/pkg/text/template/) reference guide
|
||||
-->
|
||||
### 参考
|
||||
|
||||
* [Jsonpath](/zh/docs/reference/kubectl/jsonpath/) 参考指南
|
||||
* [Go template](https://golang.org/pkg/text/template/) 参考指南
|
||||
|
||||
+330
@@ -0,0 +1,330 @@
|
||||
---
|
||||
title: 使用端口转发来访问集群中的应用
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Use Port Forwarding to Access Applications in a Cluster
|
||||
content_type: task
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This page shows how to use `kubectl port-forward` to connect to a MongoDB
|
||||
server running in a Kubernetes cluster. This type of connection can be useful
|
||||
for database debugging.
|
||||
-->
|
||||
本文展示如何使用 `kubectl port-forward` 连接到在 Kubernetes 集群中
|
||||
运行的 MongoDB 服务。这种类型的连接对数据库调试很有用。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
* Install [MongoDB Shell](https://www.mongodb.com/try/download/shell).
|
||||
-->
|
||||
* 安装 [MongoDB Shell](https://www.mongodb.com/try/download/shell)。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Creating MongoDB deployment and service
|
||||
|
||||
1. Create a Deployment that runs MongoDB:
|
||||
-->
|
||||
## 创建 MongoDB deployment 和服务
|
||||
|
||||
1. 创建一个运行 MongoDB 的 deployment：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output of a successful command verifies that the deployment was created:
|
||||
-->
|
||||
查看输出是否成功，以验证是否成功创建 deployment：
|
||||
|
||||
```
|
||||
deployment.apps/mongo created
|
||||
```
|
||||
|
||||
<!--
|
||||
View the pod status to check that it is ready:
|
||||
-->
|
||||
查看 pod 状态，检查其是否准备就绪：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The output displays the pod created:
|
||||
-->
|
||||
输出显示创建的 pod：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s
|
||||
```
|
||||
|
||||
<!--
|
||||
View the Deployment's status:
|
||||
-->
|
||||
查看 Deployment 状态：
|
||||
|
||||
```shell
|
||||
kubectl get deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
The output displays that the Deployment was created:
|
||||
-->
|
||||
输出显示创建的 Deployment：
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
mongo 1/1 1 1 2m21s
|
||||
```
|
||||
|
||||
<!--
|
||||
The Deployment automatically manages a ReplicaSet.
|
||||
View the ReplicaSet status using:
|
||||
-->
|
||||
Deployment 自动管理 ReplicaSet。
|
||||
查看 ReplicaSet 状态：
|
||||
|
||||
```shell
|
||||
kubectl get replicaset
|
||||
```
|
||||
|
||||
<!--
|
||||
The output displays that the ReplicaSet was created:
|
||||
-->
|
||||
输出显示创建的 ReplicaSet：
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
mongo-75f59d57f4 1 1 1 3m12s
|
||||
```
|
||||
|
||||
<!--
|
||||
2. Create a Service to expose MongoDB on the network:
|
||||
-->
|
||||
2. 创建一个在网络上公开的 MongoDB 服务：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output of a successful command verifies that the Service was created:
|
||||
-->
|
||||
查看输出是否成功，以验证是否成功创建 Service：
|
||||
|
||||
```
|
||||
service/mongo created
|
||||
```
|
||||
|
||||
<!--
|
||||
Check the Service created:
|
||||
-->
|
||||
检查 Service 是否创建：
|
||||
|
||||
```shell
|
||||
kubectl get service mongo
|
||||
```
|
||||
|
||||
<!--
|
||||
The output displays the service created:
|
||||
-->
|
||||
输出显示创建的 Service：
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
mongo ClusterIP 10.96.41.183 <none> 27017/TCP 11s
|
||||
```
|
||||
|
||||
<!--
|
||||
3. Verify that the MongoDB server is running in the Pod, and listening on port 27017:
|
||||
-->
|
||||
3. 验证 MongoDB 服务是否运行在 Pod 中并且监听 27017 端口：
|
||||
|
||||
```shell
|
||||
# Change mongo-75f59d57f4-4nd6q to the name of the Pod
|
||||
kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||
```
|
||||
|
||||
<!--
|
||||
The output displays the port for MongoDB in that Pod:
|
||||
-->
|
||||
输出应该显示 Pod 中 MongoDB 的端口：
|
||||
|
||||
```
|
||||
27017
|
||||
```
|
||||
|
||||
<!--
|
||||
(this is the TCP port allocated to MongoDB on the internet).
|
||||
-->
|
||||
（这是 Internet 分配给 MongoDB 的 TCP 端口）。
|
||||
|
||||
<!--
|
||||
## Forward a local port to a port on the Pod
|
||||
|
||||
1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to.
|
||||
-->
|
||||
## 转发一个本地端口到 Pod 端口
|
||||
|
||||
1. `kubectl port-forward` 允许使用资源名称
|
||||
（例如 pod 名称）来选择匹配的 pod 来进行端口转发。
|
||||
|
||||
```shell
|
||||
# Change mongo-75f59d57f4-4nd6q to the name of the Pod
|
||||
kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
|
||||
<!--
|
||||
which is the same as
|
||||
-->
|
||||
这相当于
|
||||
|
||||
```shell
|
||||
kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
|
||||
```
|
||||
|
||||
<!-- or -->
|
||||
或者
|
||||
|
||||
```shell
|
||||
kubectl port-forward deployment/mongo 28015:27017
|
||||
```
|
||||
|
||||
<!-- or -->
|
||||
或者
|
||||
|
||||
```shell
|
||||
kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
|
||||
```
|
||||
|
||||
<!-- or -->
|
||||
或者
|
||||
|
||||
```shell
|
||||
kubectl port-forward service/mongo 28015:27017
|
||||
```
|
||||
|
||||
<!--
|
||||
Any of the above commands works. The output is similar to this:
|
||||
-->
|
||||
以上所有命令都应该有效。输出应该类似于：
|
||||
|
||||
```
|
||||
Forwarding from 127.0.0.1:28015 -> 27017
|
||||
Forwarding from [::1]:28015 -> 27017
|
||||
```
|
||||
<!--
|
||||
{{< note >}}
|
||||
|
||||
`kubectl port-forward` does not return. To continue with the exercises, you will need to open another terminal.
|
||||
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
|
||||
`kubectl port-forward` 不会返回。你需要打开另一个终端来继续这个练习。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
<!--
|
||||
2. Start the MongoDB command line interface:
|
||||
-->
|
||||
2. 启动 MongoDB 命令行接口：
|
||||
|
||||
```shell
|
||||
mongosh --port 28015
|
||||
```
|
||||
|
||||
<!--
|
||||
3. At the MongoDB command line prompt, enter the `ping` command:
|
||||
-->
|
||||
3. 在 MongoDB 命令行提示符下，输入 `ping` 命令：
|
||||
|
||||
```
|
||||
db.runCommand( { ping: 1 } )
|
||||
```
|
||||
|
||||
<!--
|
||||
A successful ping request returns:
|
||||
-->
|
||||
成功的 ping 请求应该返回：
|
||||
|
||||
```
|
||||
{ ok: 1 }
|
||||
```
|
||||
|
||||
<!--
|
||||
### Optionally let _kubectl_ choose the local port {#let-kubectl-choose-local-port}
|
||||
-->
|
||||
### （可选操作）让 _kubectl_ 来选择本地端口 {#let-kubectl-choose-local-port}
|
||||
|
||||
<!--
|
||||
If you don't need a specific local port, you can let `kubectl` choose and allocate
|
||||
the local port and thus relieve you from having to manage local port conflicts, with
|
||||
the slightly simpler syntax:
|
||||
-->
|
||||
如果你不需要指定特定的本地端口，你可以让 `kubectl` 来选择和分配本地端口，
|
||||
以便你不需要管理本地端口冲突。该命令使用稍微不同的语法：
|
||||
|
||||
```shell
|
||||
kubectl port-forward deployment/mongo :27017
|
||||
```
|
||||
|
||||
<!--
|
||||
The `kubectl` tool finds a local port number that is not in use (avoiding low ports numbers,
|
||||
because these might be used by other applications). The output is similar to:
|
||||
-->
|
||||
`kubectl` 工具会找到一个未被使用的本地端口号（避免使用低段位的端口号，因为他们可能会被其他应用程序使用）。
|
||||
输出应该类似于：
|
||||
|
||||
```
|
||||
Forwarding from 127.0.0.1:63753 -> 27017
|
||||
Forwarding from [::1]:63753 -> 27017
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
<!--
|
||||
## Discussion
|
||||
|
||||
Connections made to local port 28015 are forwarded to port 27017 of the Pod that
|
||||
is running the MongoDB server. With this connection in place, you can use your
|
||||
local workstation to debug the database that is running in the Pod.
|
||||
-->
|
||||
## 讨论 {#discussion}
|
||||
|
||||
与本地 28015 端口建立的连接将转发到运行 MongoDB 服务器的 Pod 的 27017 端口。
|
||||
通过此连接，你可以使用本地工作站来调试在 Pod 中运行的数据库。
|
||||
|
||||
<!--
|
||||
`kubectl port-forward` is implemented for TCP ports only.
|
||||
The support for UDP protocol is tracked in
|
||||
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
|
||||
-->
|
||||
{{< warning >}}
|
||||
`kubectl port-forward` 仅适用于 TCP 端口。
|
||||
在 [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862)
|
||||
中跟踪了对 UDP 协议的支持。
|
||||
{{< /warning >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
|
||||
-->
|
||||
进一步了解 [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)。
|
||||
|
||||
+244
@@ -0,0 +1,244 @@
|
||||
---
|
||||
title: 使用服务来访问集群中的应用
|
||||
content_type: tutorial
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Use a Service to Access an Application in a Cluster
|
||||
content_type: tutorial
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to create a Kubernetes Service object that external
|
||||
clients can use to access an application running in a cluster. The Service
|
||||
provides load balancing for an application that has two running instances.
|
||||
-->
|
||||
本文展示如何创建一个 Kubernetes 服务对象，能让外部客户端访问在集群中运行的应用。
|
||||
该服务为一个应用的两个运行实例提供负载均衡。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
<!--
|
||||
* Run two instances of a Hello World application.
|
||||
* Create a Service object that exposes a node port.
|
||||
* Use the Service object to access the running application.
|
||||
-->
|
||||
* 运行 Hello World 应用的两个实例。
|
||||
* 创建一个服务对象来暴露 node port。
|
||||
* 使用服务对象来访问正在运行的应用。
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
<!--
|
||||
## Creating a service for an application running in two pods
|
||||
|
||||
Here is the configuration file for the application Deployment:
|
||||
-->
|
||||
## 为运行在两个 pod 中的应用创建一个服务
|
||||
|
||||
这是应用程序部署的配置文件：
|
||||
|
||||
{{< codenew file="service/access/hello-application.yaml" >}}
|
||||
|
||||
<!--
|
||||
1. Run a Hello World application in your cluster:
|
||||
Create the application Deployment using the file above:
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
|
||||
```
|
||||
The preceding command creates a
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
object and an associated
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
object. The ReplicaSet has two
|
||||
[Pods](/docs/concepts/workloads/pods/pod/),
|
||||
each of which runs the Hello World application.
|
||||
-->
|
||||
|
||||
1. 在你的集群中运行一个 Hello World 应用：
|
||||
使用上面的文件创建应用程序 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
|
||||
```
|
||||
|
||||
上面的命令创建一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 对象
|
||||
和一个关联的 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 对象。
|
||||
这个 ReplicaSet 有两个 [Pod](/zh/docs/concepts/workloads/pods/)，
|
||||
每个 Pod 都运行着 Hello World 应用。
|
||||
|
||||
<!--
|
||||
1. Display information about the Deployment:
|
||||
-->
|
||||
2. 展示 Deployment 的信息：
|
||||
|
||||
```shell
|
||||
kubectl get deployments hello-world
|
||||
kubectl describe deployments hello-world
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Display information about your ReplicaSet objects:
|
||||
-->
|
||||
3. 展示你的 ReplicaSet 对象信息：
|
||||
|
||||
```shell
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Create a Service object that exposes the deployment:
|
||||
-->
|
||||
4. 创建一个服务对象来暴露 Deployment：
|
||||
|
||||
```shell
|
||||
kubectl expose deployment hello-world --type=NodePort --name=example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Display information about the Service:
|
||||
-->
|
||||
5. 展示 Service 信息：
|
||||
|
||||
```shell
|
||||
kubectl describe services example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
Name: example-service
|
||||
Namespace: default
|
||||
Labels: run=load-balancer-example
|
||||
Annotations: <none>
|
||||
Selector: run=load-balancer-example
|
||||
Type: NodePort
|
||||
IP: 10.32.0.16
|
||||
Port: <unset> 8080/TCP
|
||||
TargetPort: 8080/TCP
|
||||
NodePort: <unset> 31496/TCP
|
||||
Endpoints: 10.200.1.4:8080,10.200.2.5:8080
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
<!--
|
||||
Make a note of the NodePort value for the service. For example,
|
||||
in the preceding output, the NodePort value is 31496.
|
||||
-->
|
||||
注意服务中的 NodePort 值。例如在上面的输出中，NodePort 是 31496。
|
||||
|
||||
<!--
|
||||
1. List the pods that are running the Hello World application:
|
||||
-->
|
||||
7. 列出运行 Hello World 应用的 Pod：
|
||||
|
||||
```shell
|
||||
kubectl get pods --selector="run=load-balancer-example" --output=wide
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
NAME READY STATUS ... IP NODE
|
||||
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
|
||||
hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
|
||||
```
|
||||
<!--
|
||||
1. Get the public IP address of one of your nodes that is running
|
||||
a Hello World pod. How you get this address depends on how you set
|
||||
up your cluster. For example, if you are using Minikube, you can
|
||||
see the node address by running `kubectl cluster-info`. If you are
|
||||
using Google Compute Engine instances, you can use the
|
||||
`gcloud compute instances list` command to see the public addresses of your
|
||||
nodes.
|
||||
|
||||
1. On your chosen node, create a firewall rule that allows TCP traffic
|
||||
on your node port. For example, if your Service has a NodePort value of
|
||||
31568, create a firewall rule that allows TCP traffic on port 31568. Different
|
||||
cloud providers offer different ways of configuring firewall rules.
|
||||
|
||||
1. Use the node address and node port to access the Hello World application:
|
||||
-->
|
||||
8. 获取运行 Hello World 的 pod 的其中一个节点的公共 IP 地址。如何获得此地址取决于你设置集群的方式。
|
||||
例如，如果你使用的是 Minikube，则可以通过运行 `kubectl cluster-info` 来查看节点地址。
|
||||
如果你使用的是 Google Compute Engine 实例，则可以使用 `gcloud compute instances list` 命令查看节点的公共地址。
|
||||
|
||||
9. 在你选择的节点上，创建一个防火墙规则以开放节点端口上的 TCP 流量。
|
||||
例如，如果你的服务的 NodePort 值为 31568，请创建一个防火墙规则以允许 31568 端口上的 TCP 流量。
|
||||
不同的云提供商提供了不同方法来配置防火墙规则。
|
||||
|
||||
10. 使用节点地址和 node port 来访问 Hello World 应用：
|
||||
|
||||
```shell
|
||||
curl http://<public-node-ip>:<node-port>
|
||||
```
|
||||
|
||||
<!--
|
||||
where `<public-node-ip>` is the public IP address of your node,
|
||||
and `<node-port>` is the NodePort value for your service. The
|
||||
response to a successful request is a hello message:
|
||||
-->
|
||||
这里的 `<public-node-ip>` 是你节点的公共 IP 地址，`<node-port>` 是你服务的 NodePort 值。
|
||||
对于请求成功的响应是一个 hello 消息：
|
||||
|
||||
```shell
|
||||
Hello Kubernetes!
|
||||
```
|
||||
|
||||
<!--
|
||||
## Using a service configuration file
|
||||
|
||||
As an alternative to using `kubectl expose`, you can use a
|
||||
[service configuration file](/docs/concepts/services-networking/service/)
|
||||
to create a Service.
|
||||
-->
|
||||
## 使用服务配置文件
|
||||
|
||||
作为 `kubectl expose` 的替代方法，你可以使用
|
||||
[服务配置文件](/zh/docs/concepts/services-networking/service/) 来创建服务。
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
<!--
|
||||
To delete the Service, enter this command:
|
||||
-->
|
||||
想要删除服务，输入以下命令：
|
||||
|
||||
```shell
|
||||
kubectl delete services example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
To delete the Deployment, the ReplicaSet, and the Pods that are running
|
||||
the Hello World application, enter this command:
|
||||
-->
|
||||
想要删除运行 Hello World 应用的 Deployment、ReplicaSet 和 Pod，输入以下命令：
|
||||
|
||||
```shell
|
||||
kubectl delete deployment hello-world
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
Learn more about
|
||||
[connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
|
||||
-->
|
||||
- 进一步了解[通过服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)。
|
||||
|
||||
@@ -0,0 +1,475 @@
|
||||
---
|
||||
title: 部署和访问 Kubernetes 仪表板（Dashboard）
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 30
|
||||
title: 使用 Web 界面 Dashboard
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- floreks
|
||||
- maciaszczykm
|
||||
- shu-mutou
|
||||
- mikedanese
|
||||
title: Deploy and Access the Kubernetes Dashboard
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 30
|
||||
title: Use the Web UI Dashboard
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Dashboard is a web-based Kubernetes user interface.
|
||||
You can use Dashboard to deploy containerized applications to a Kubernetes cluster,
|
||||
troubleshoot your containerized application, and manage the cluster resources.
|
||||
You can use Dashboard to get an overview of applications running on your cluster,
|
||||
as well as for creating or modifying individual Kubernetes resources
|
||||
(such as Deployments, Jobs, DaemonSets, etc).
|
||||
For example, you can scale a Deployment, initiate a rolling update, restart a pod
|
||||
or deploy new applications using a deploy wizard.
|
||||
|
||||
Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred.
|
||||
-->
|
||||
Dashboard 是基于网页的 Kubernetes 用户界面。
|
||||
你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。
|
||||
你可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源
|
||||
（如 Deployment，Job，DaemonSet 等等）。
|
||||
例如，你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。
|
||||
|
||||
Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Deploying the Dashboard UI
|
||||
|
||||
The Dashboard UI is not deployed by default. To deploy it, run the following command:
|
||||
-->
|
||||
## 部署 Dashboard UI
|
||||
默认情况下不会部署 Dashboard。可以通过以下命令部署：
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
## Accessing the Dashboard UI
|
||||
|
||||
To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default.
|
||||
Currently, Dashboard only supports logging in with a Bearer Token.
|
||||
To create a token for this demo, you can follow our guide on
|
||||
[creating a sample user](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user).
|
||||
-->
|
||||
## 访问 Dashboard 用户界面
|
||||
|
||||
为了保护你的集群数据，默认情况下，Dashboard 会使用最少的 RBAC 配置进行部署。
|
||||
当前，Dashboard 仅支持使用 Bearer 令牌登录。
|
||||
要为此样本演示创建令牌，你可以按照
|
||||
[创建示例用户](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user)
|
||||
上的指南进行操作。
|
||||
|
||||
<!--
|
||||
The sample user created in the tutorial will have administrative privileges and is for educational purposes only.
|
||||
-->
|
||||
{{< warning >}}
|
||||
在教程中创建的样本用户将具有管理特权，并且仅用于教育目的。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
### Command line proxy
|
||||
|
||||
You can enable access to the Dashboard using the `kubectl` command-line tool,
|
||||
by running the following command:
|
||||
-->
|
||||
### 命令行代理
|
||||
|
||||
你可以使用 `kubectl` 命令行工具来启用 Dashboard 访问，命令如下：
|
||||
|
||||
```
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
<!--
|
||||
Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/).
|
||||
-->
|
||||
kubectl 会使得 Dashboard 可以通过 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/) 访问。
|
||||
|
||||
<!--
|
||||
The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options.
|
||||
-->
|
||||
UI _只能_ 通过执行这条命令的机器进行访问。更多选项参见 `kubectl proxy --help`。
|
||||
|
||||
<!--
|
||||
The kubeconfig authentication method does **not** support external identity providers
|
||||
or X.509 certificate-based authentication.
|
||||
-->
|
||||
{{< note >}}
|
||||
Kubeconfig 身份验证方法**不**支持外部身份提供程序或基于 x509 证书的身份验证。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Welcome view
|
||||
-->
|
||||
## 欢迎界面
|
||||
|
||||
<!--
|
||||
When you access Dashboard on an empty cluster, you'll see the welcome page. This page contains a link to this document as well as a button to deploy your first application. In addition, you can view which system applications are running by default in the `kube-system` [namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.
|
||||
-->
|
||||
当访问空集群的 Dashboard 时，你会看到欢迎界面。
|
||||
页面包含一个指向此文档的链接，以及一个用于部署第一个应用程序的按钮。
|
||||
此外，你可以看到在默认情况下有哪些默认系统应用运行在 `kube-system`
|
||||
[名字空间](/zh/docs/tasks/administer-cluster/namespaces/) 中，比如 Dashboard 自己。
|
||||
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
<!--
|
||||
## Deploying containerized applications
|
||||
|
||||
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard.
|
||||
You can either manually specify application details, or upload a YAML or JSON _manifest_ file containing application configuration.
|
||||
-->
|
||||
## 部署容器化应用
|
||||
|
||||
通过一个简单的部署向导，你可以使用 Dashboard 将容器化应用作为一个 Deployment 和可选的
|
||||
Service 进行创建和部署。你可以手工指定应用的详细配置，或者上传一个包含应用配置的 YAML
|
||||
或 JSON _清单_文件。
|
||||
|
||||
<!--
|
||||
Click the **CREATE** button in the upper right corner of any page to begin.
|
||||
-->
|
||||
点击任何页面右上角的 **CREATE** 按钮以开始。
|
||||
|
||||
<!--
|
||||
### Specifying application details
|
||||
|
||||
The deploy wizard expects that you provide the following information:
|
||||
-->
|
||||
### 指定应用的详细配置
|
||||
|
||||
部署向导需要你提供以下信息：
|
||||
|
||||
<!--
|
||||
- **App name** (mandatory): Name for your application. A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
|
||||
-->
|
||||
- **应用名称**（必填）：应用的名称。内容为`应用名称`的
|
||||
[标签](/zh/docs/concepts/overview/working-with-objects/labels/)
|
||||
会被添加到任何将被部署的 Deployment 和 Service。
|
||||
|
||||
<!--
|
||||
The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
|
||||
-->
|
||||
在选定的 Kubernetes [名字空间](/zh/docs/tasks/administer-cluster/namespaces/) 中，
|
||||
应用名称必须唯一。必须由小写字母开头，以数字或者小写字母结尾，
|
||||
并且只含有小写字母、数字和中划线（-）。小于等于24个字符。开头和结尾的空格会被忽略。
|
||||
|
||||
<!--
|
||||
- **Container image** (mandatory): The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.
|
||||
-->
|
||||
- **容器镜像**（必填）：公共镜像仓库上的 Docker
|
||||
[容器镜像](/zh/docs/concepts/containers/images/) 或者私有镜像仓库
|
||||
（通常是 Google Container Registry 或者 Docker Hub）的 URL。容器镜像参数说明必须以冒号结尾。
|
||||
|
||||
<!--
|
||||
- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in. The value must be a positive integer.
|
||||
-->
|
||||
- **Pod 的数量**（必填）：你希望应用程序部署的 Pod 的数量。值必须为正整数。
|
||||
|
||||
<!--
|
||||
A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to
|
||||
maintain the desired number of Pods across your cluster.
|
||||
-->
|
||||
系统会创建一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)
|
||||
以保证集群中运行期望的 Pod 数量。
|
||||
|
||||
<!--
|
||||
- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service).
|
||||
-->
|
||||
- **服务**（可选）：对于部分应用（比如前端），你可能想对外暴露一个
|
||||
[Service](/zh/docs/concepts/services-networking/service/) ，这个 Service
|
||||
可能用的是集群之外的公网 IP 地址（外部 Service）。
|
||||
|
||||
<!--
|
||||
For external Services, you may need to open up one or more ports to do so.
|
||||
-->
|
||||
{{< note >}}
|
||||
对于外部服务，你可能需要开放一个或多个端口才行。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Other Services that are only visible from inside the cluster are called internal Services.
|
||||
-->
|
||||
其它只能对集群内部可见的 Service 称为内部 Service。
|
||||
|
||||
<!--
|
||||
Irrespective of the Service type, if you choose to create a Service and your container listens
|
||||
on a port (incoming), you need to specify two ports.
|
||||
The Service will be created mapping the port (incoming) to the target port seen by the container.
|
||||
This Service will route to your deployed Pods. Supported protocols are TCP and UDP.
|
||||
The internal DNS name for this Service will be the value you specified as application name above.
|
||||
-->
|
||||
不管哪种 Service 类型，如果你选择创建一个 Service，而且容器在一个端口上开启了监听（入向的），
|
||||
那么你需要定义两个端口。创建的 Service 会把（入向的）端口映射到容器可见的目标端口。
|
||||
该 Service 会把流量路由到你部署的 Pod。支持 TCP 协议和 UDP 协议。
|
||||
这个 Service 的内部 DNS 解析名就是之前你定义的应用名称的值。
|
||||
|
||||
<!--
|
||||
If needed, you can expand the **Advanced options** section where you can specify more settings:
|
||||
-->
|
||||
如果需要，你可以打开 **Advanced Options** 部分，这里你可以定义更多设置：
|
||||
|
||||
<!--
|
||||
- **Description**: The text you enter here will be added as an
|
||||
[annotation](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
to the Deployment and displayed in the application's details.
|
||||
-->
|
||||
- **描述**：这里你输入的文本会作为一个
|
||||
[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)
|
||||
添加到 Deployment，并显示在应用的详细信息中。
|
||||
|
||||
<!--
|
||||
- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.
|
||||
-->
|
||||
- **标签**：应用默认使用的
|
||||
[标签](/zh/docs/concepts/overview/working-with-objects/labels/) 是应用名称和版本。
|
||||
你可以为 Deployment、Service（如果有）定义额外的标签，比如 release（版本）、
|
||||
environment（环境）、tier（层级）、partition（分区） 和 release track（版本跟踪）。
|
||||
|
||||
<!-- Example: -->
|
||||
例子：
|
||||
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
|
||||
<!--
|
||||
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
|
||||
-->
|
||||
- **名字空间**：Kubernetes 支持多个虚拟集群依附于同一个物理集群。
|
||||
这些虚拟集群被称为
|
||||
[名字空间](/zh/docs/tasks/administer-cluster/namespaces/)，
|
||||
可以让你将资源划分为逻辑命名的组。
|
||||
|
||||
<!--
|
||||
Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace.
|
||||
The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-)
|
||||
but can not contain capital letters.
|
||||
-->
|
||||
Dashboard 通过下拉菜单提供所有可用的名字空间，并允许你创建新的名字空间。
|
||||
名字空间的名称最长可以包含 63 个字母或数字和中横线（-），但是不能包含大写字母。
|
||||
|
||||
<!--
|
||||
Namespace names should not consist of only numbers.
|
||||
If the name is set as a number, such as 10, the pod will be put in the default namespace.
|
||||
-->
|
||||
名字空间的名称不能只包含数字。如果名字被设置成一个数字，比如 10，pod 就
|
||||
|
||||
<!--
|
||||
In case the creation of the namespace is successful, it is selected by default.
|
||||
If the creation fails, the first namespace is selected.
|
||||
-->
|
||||
在名字空间创建成功的情况下，默认会使用新创建的名字空间。如果创建失败，那么第一个名字空间会被选中。
|
||||
|
||||
<!--
|
||||
- **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials.
|
||||
-->
|
||||
- **镜像拉取 Secret**：如果要使用私有的 Docker 容器镜像，需要拉取
|
||||
[Secret](/zh/docs/concepts/configuration/secret/) 凭证。
|
||||
|
||||
<!--
|
||||
Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret.
|
||||
The secret name must follow the DNS domain name syntax, e.g. `new.image-pull.secret`.
|
||||
The content of a secret must be base64-encoded and specified in a
|
||||
[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file.
|
||||
The secret name may consist of a maximum of 253 characters.
|
||||
-->
|
||||
Dashboard 通过下拉菜单提供所有可用的 Secret，并允许你创建新的 Secret。
|
||||
Secret 名称必须遵循 DNS 域名语法，比如 `new.image-pull.secret`。
|
||||
Secret 的内容必须是 base64 编码的，并且在一个
|
||||
[`.dockercfg`](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
|
||||
文件中声明。Secret 名称最大可以包含 253 个字符。
|
||||
|
||||
<!--
|
||||
In case the creation of the image pull secret is successful, it is selected by default.
|
||||
If the creation fails, no secret is applied.
|
||||
-->
|
||||
在镜像拉取 Secret 创建成功的情况下，默认会使用新创建的 Secret。
|
||||
如果创建失败，则不会使用任何 Secret。
|
||||
|
||||
<!--
|
||||
- **CPU requirement (cores)** and **Memory requirement (MiB)**: You can specify the minimum [resource limits](/docs/tasks/configure-pod-container/limit-range/) for the container. By default, Pods run with unbounded CPU and memory limits.
|
||||
-->
|
||||
- **CPU 需求（核数）**和**内存需求（MiB）**：你可以为容器定义最小的
|
||||
[资源限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
|
||||
默认情况下，Pod 没有 CPU 和内存限制。
|
||||
|
||||
<!--
|
||||
- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/user-guide/containers/#containers-and-commands). You can use the command options and arguments to override the default.
|
||||
-->
|
||||
- **运行命令**和**运行命令参数**：默认情况下，你的容器会运行 Docker 镜像的默认
|
||||
[入口命令](/zh/docs/tasks/inject-data-application/define-command-argument-container/)。
|
||||
你可以使用 command 选项覆盖默认值。
|
||||
|
||||
<!--
|
||||
- **Run as privileged**: This setting determines whether processes in [privileged containers](/docs/user-guide/pods/#privileged-mode-for-pod-containers) are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
|
||||
-->
|
||||
- **以特权模式运行**：这个设置决定了在
|
||||
[特权容器](/zh/docs/concepts/workloads/pods/#privileged-mode-for-containers)
|
||||
中运行的进程是否像主机中使用 root 运行的进程一样。
|
||||
特权容器可以使用诸如操纵网络堆栈和访问设备的功能。
|
||||
|
||||
<!--
|
||||
- **Environment variables**: Kubernetes exposes Services through [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). You can compose environment variable or pass arguments to your commands using the values of environment variables. They can be used in applications to find a Service. Values can reference other variables using the `$(VAR_NAME)` syntax.
|
||||
-->
|
||||
- **环境变量**：Kubernetes 通过
|
||||
[环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
|
||||
暴露 Service。你可以构建环境变量，或者将环境变量的值作为参数传递给你的命令。
|
||||
它们可以被应用用于查找 Service。值可以通过 `$(VAR_NAME)` 语法关联其他变量。
|
||||
|
||||
<!--
|
||||
### Uploading a YAML or JSON file
|
||||
|
||||
Kubernetes supports declarative configuration.
|
||||
In this style, all configuration is stored in manifests (YAML or JSON configuration files).
|
||||
The manifests use the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
|
||||
-->
|
||||
### 上传 YAML 或者 JSON 文件
|
||||
|
||||
Kubernetes 支持声明式配置。所有的配置都存储在清单文件
|
||||
（YAML 或者 JSON 配置文件）中。这些
|
||||
清单使用 Kubernetes [API](/zh/docs/concepts/overview/kubernetes-api/) 定义的资源模式。
|
||||
|
||||
<!--
|
||||
As an alternative to specifying application details in the deploy wizard,
|
||||
you can define your application one or more manifests, and upload the files using Dashboard.
|
||||
-->
|
||||
作为一种替代在部署向导中指定应用详情的方式，你可以在一个或多个清单文件中定义应用，并且使用
|
||||
Dashboard 上传文件。
|
||||
|
||||
<!--
|
||||
## Using Dashboard
|
||||
|
||||
Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used.
|
||||
-->
|
||||
## 使用 Dashboard
|
||||
|
||||
以下各节描述了 Kubernetes Dashboard UI 视图；包括它们提供的内容，以及怎么使用它们。
|
||||
|
||||
<!--
|
||||
### Navigation
|
||||
|
||||
When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. By default only objects from the _default_ namespace are shown and this can be changed using the namespace selector located in the navigation menu.
|
||||
-->
|
||||
### 导航
|
||||
|
||||
当在集群中定义 Kubernetes 对象时，Dashboard 会在初始视图中显示它们。
|
||||
默认情况下只会显示 _默认_ 名字空间中的对象，可以通过更改导航栏菜单中的名字空间筛选器进行改变。
|
||||
|
||||
<!--
|
||||
Dashboard shows most Kubernetes object kinds and groups them in a few menu categories.
|
||||
-->
|
||||
Dashboard 展示大部分 Kubernetes 对象，并将它们分组放在几个菜单类别中。
|
||||
|
||||
<!--
|
||||
#### Admin Overview
|
||||
|
||||
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and PersistentVolumes and has detail views for them.
|
||||
Node list view contains CPU and memory usage metrics aggregated across all Nodes.
|
||||
The details view shows the metrics for a Node, its specification, status,
|
||||
allocated resources, events and pods running on the node.
|
||||
-->
|
||||
#### 管理概述
|
||||
|
||||
集群和名字空间管理的视图, Dashboard 会列出节点、名字空间和持久卷，并且有它们的详细视图。
|
||||
节点列表视图包含从所有节点聚合的 CPU 和内存使用的度量值。
|
||||
详细信息视图显示了一个节点的度量值，它的规格、状态、分配的资源、事件和这个节点上运行的 Pod。
|
||||
|
||||
<!--
|
||||
#### Workloads
|
||||
|
||||
Shows all applications running in the selected namespace.
|
||||
The view lists applications by workload kind (e.g., Deployments, ReplicaSets, Stateful Sets, etc.).
|
||||
Each workload kind can be viewed separately.
|
||||
The lists summarize actionable information about the workloads,
|
||||
such as the number of ready pods for a ReplicaSet or current memory usage for a Pod.
|
||||
-->
|
||||
#### 负载
|
||||
|
||||
显示选中的名字空间中所有运行的应用。
|
||||
视图按照负载类型（如 Deployment、ReplicaSet、StatefulSet 等）罗列应用，并且每种负载都可以单独查看。
|
||||
列表总结了关于负载的可执行信息，比如一个 ReplicaSet 的就绪状态的 Pod 数量，或者目前一个 Pod 的内存用量。
|
||||
|
||||
<!--
|
||||
Detail views for workloads show status and specification information and
|
||||
surface relationships between objects.
|
||||
For example, Pods that Replica Set is controlling or New ReplicaSets and HorizontalPodAutoscalers for Deployments.
|
||||
-->
|
||||
工作负载的详情视图展示了对象的状态、详细信息和相互关系。
|
||||
例如，ReplicaSet 所控制的 Pod，或者 Deployment 所关联的新 ReplicaSet 和
|
||||
HorizontalPodAutoscalers。
|
||||
|
||||
<!--
|
||||
#### Services
|
||||
|
||||
Shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users.
|
||||
-->
|
||||
#### 服务
|
||||
|
||||
展示允许暴露给外网服务和允许集群内部发现的 Kubernetes 资源。
|
||||
因此，Service 和 Ingress 视图展示他们关联的 Pod、给集群连接使用的内部端点和给外部用户使用的外部端点。
|
||||
|
||||
<!--
|
||||
#### Storage
|
||||
|
||||
Storage view shows PersistentVolumeClaim resources which are used by applications for storing data.
|
||||
-->
|
||||
#### 存储
|
||||
|
||||
存储视图展示持久卷申领（PVC）资源，这些资源被应用程序用来存储数据。
|
||||
|
||||
<!--
|
||||
#### Config Maps and Secrets
|
||||
|
||||
Shows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default.
|
||||
-->
|
||||
#### ConfigMap 和 Secret
|
||||
|
||||
展示的所有 Kubernetes 资源是在集群中运行的应用程序的实时配置。
|
||||
通过这个视图可以编辑和管理配置对象，并显示那些默认隐藏的 Secret。
|
||||
|
||||
<!--
|
||||
#### Logs viewer
|
||||
|
||||
Pod lists and detail pages link to logs viewer that is built into Dashboard. The viewer allows for drilling down logs from containers belonging to a single Pod.
|
||||
-->
|
||||
#### 日志查看器
|
||||
|
||||
Pod 列表和详细信息页面可以链接到 Dashboard 内置的日志查看器。
|
||||
查看器可以深入查看属于同一个 Pod 的不同容器的日志。
|
||||
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
For more information, see the
|
||||
[Kubernetes Dashboard project page](https://github.com/kubernetes/dashboard).
|
||||
-->
|
||||
更多信息，参见 [Kubernetes Dashboard 项目页面](https://github.com/kubernetes/dashboard).
|
||||
|
||||
Reference in New Issue
Block a user