Skip to content

Commit

Permalink
[zh] Fix links in concepts section
Browse files Browse the repository at this point in the history
  • Loading branch information
@tengqm
tengqm committed Jul 31, 2020
1 parent 897a6f3 commit 9f7414e
Show file tree
Hide file tree
Showing 13 changed files with 535 additions and 561 deletions.
13 changes: 6 additions & 7 deletions content/zh/docs/concepts/configuration/secret.md
View file
Expand Up @@ -244,18 +244,17 @@ You can also create a Secret in a file first, in JSON or YAML format,
and then create that object.
The name of a Secret object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
he
[Secret](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core) contains two maps:
data and stringData. The data field is used to store arbitrary data, encoded using
The [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
contains two maps:
`data` and `stringData`. The `data` field is used to store arbitrary data, encoded using
base64. The stringData field is provided for convenience, and allows you to provide
secret data as unencoded strings.
-->
#### 手动创建 Secret

您也可以先以 JSON 或 YAML 格式文件创建一个 Secret，然后创建该对象。
Secret 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
[Secret](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core)
[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
包含两个映射：`data` 和 `stringData`。
`data` 字段用于存储使用 base64 编码的任意数据。
提供 `stringData` 字段是为了方便，允许您用未编码的字符串提供机密数据。
Expand Down Expand Up @@ -1237,7 +1236,7 @@ See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-

手动创建的 Secret（例如包含用于访问 GitHub 帐户令牌的 Secret）可以
根据其服务帐户自动附加到 Pod。
请参阅[使用 PodPreset 向 Pod 中注入信息](/zh/docs/tasks/run-application/podpreset/)
请参阅[使用 PodPreset 向 Pod 中注入信息](/zh/docs/tasks/inject-data-application/podpreset/)
以获取该过程的详细说明。

<!--
Expand Down Expand Up @@ -1872,7 +1871,7 @@ Secrets are protected when transmitted over these channels.
You can enable [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
for secret data, so that the secrets are not stored in the clear into {{< glossary_tooltip term_id="etcd" >}}.
-->
你可以为 Secret 数据开启[静态加密](//zhdocs/tasks/administer-cluster/encrypt-data/)，
你可以为 Secret 数据开启[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)，
这样 Secret 数据就不会以明文形式存储到{{< glossary_tooltip term_id="etcd" >}} 中。

<!--
Expand Down
20 changes: 13 additions & 7 deletions content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
View file
Expand Up @@ -285,7 +285,10 @@ You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, o
[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes.
-->

你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符： `In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)将 pod 从特定节点中驱逐。
你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符：
`In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。
你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用
[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)将 pod 从特定节点中驱逐。

<!--
If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
Expand Down Expand Up @@ -599,7 +602,10 @@ no two instances are located on the same host.
See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique.
-->
上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"` 来部署 redis 集群以便在同一主机上没有两个实例。参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)，以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。
上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"`
来部署 redis 集群以便在同一主机上没有两个实例。
参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)，
以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。

## nodeName

Expand Down Expand Up @@ -660,24 +666,24 @@ The above pod will run on the node kube-01.
[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods.
-->

[污点](/docs/concepts/scheduling-eviction/taint-and-toleration/)允许节点*排斥*一组 pod。
[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)允许节点*排斥*一组 pod。

<!--
The design documents for
[node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) contain extra background information about these features.
-->

[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与 [pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。
[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与
[pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。

<!--
Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-local resources.
The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can take part in node-level
resource allocation decisions.
-->

一旦 pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。
[拓扑管理](/zh/docs/tasks/administer-cluster/topology-manager/)
一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。
[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
可以参与到节点级别的资源分配决定中。


84 changes: 46 additions & 38 deletions content/zh/docs/concepts/services-networking/connect-applications-service.md
View file
@@ -1,10 +1,9 @@
---
title: 应用连接到 Service
title: 使用 Service 连接到应用
content_type: concept
weight: 30
---


<!-- overview -->

<!--
Expand All @@ -24,8 +23,6 @@ This guide uses a simple nginx server to demonstrate proof of concept. The same
既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。
在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。



默认情况下，Docker 使用私有主机网络连接，只能与同在一台机器上的容器进行通信。
为了实现容器的跨节点通信，必须在机器自己的 IP 上为这些容器分配端口，为容器进行端口转发或者代理。

Expand All @@ -35,10 +32,8 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上
这表明了在 Pod 内的容器都能够连接到本地的每个端口，集群中的所有 Pod 不需要通过 NAT 转换就能够互相看到。
文档的剩余部分将详述如何在一个网络模型之上运行可靠的服务。

该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 [Jenkins CI 应用](http://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。



该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的
[Jenkins CI 应用](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。

<!-- body -->

Expand All @@ -48,7 +43,6 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上
We did this in a previous example, but let's do it once again and focus on the networking perspective.
Create an nginx Pod, and note that it has a container port specification:
-->

## 在集群中暴露 Pod

我们在之前的示例中已经做过，然而再让我重试一次，这次聚焦在网络连接的视角。
Expand All @@ -75,7 +69,6 @@ my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5
<!--
Check your pods' IPs:
-->

检查 Pod 的 IP 地址：

```shell
Expand All @@ -89,14 +82,12 @@ You should be able to ssh into any node in your cluster and curl both IPs. Note
You can read more about [how we achieve this](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) if you're curious.
-->

应该能够通过 ssh 登录到集群中的任何一个节点上，使用 curl 也能调通所有 IP 地址。
需要注意的是，容器不会使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。
这意味着可以在同一个节点上运行多个 Pod，使用相同的容器端口，并且可以从集群中任何其他的 Pod 或节点上使用 IP 的方式访问到它们。
像 Docker 一样，端口能够被发布到主机节点的接口上，但是出于网络模型的原因应该从根本上减少这种用法。

如果对此好奇，可以获取更多关于 [如何实现网络模型](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。

如果对此好奇，可以获取更多关于 [如何实现网络模型](/zh/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。

<!--
## Creating a Service
Expand All @@ -107,7 +98,6 @@ A Kubernetes Service is an abstraction which defines a logical set of Pods runni
You can create a Service for your 2 nginx replicas with `kubectl expose`:
-->

## 创建 Service

我们有 Pod 在一个扁平的、集群范围的地址空间中运行 Nginx 服务，可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？
Expand Down Expand Up @@ -145,9 +135,11 @@ View [Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/
API object to see the list of supported fields in service definition.
Check your Service:
-->

上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。
查看 [Service API 对象](/docs/api-reference/{{< param "version" >}}/#service-v1-core) 了解 Service 定义支持的字段列表。
上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，
并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service
端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。
查看 [Service API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
了解 Service 定义支持的字段列表。
查看你的 Service 资源:

```shell
Expand All @@ -167,7 +159,6 @@ matching the Service's selector will automatically get added to the endpoints.
Check the endpoints, and note that the IPs are the same as the Pods created in
the first step:
-->

正如前面所提到的，一个 Service 由一组 backend Pod 组成。这些 Pod 通过 `endpoints` 暴露出来。
Service Selector 将持续评估，结果被 POST 到一个名称为 `my-nginx` 的 Endpoint 对象上。
当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。
Expand Down Expand Up @@ -206,7 +197,8 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip

现在，能够从集群中任意节点上使用 curl 命令请求 Nginx Service `<CLUSTER-IP>:<PORT>` 。
注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，
可以阅读更多关于 [服务代理](/docs/user-guide/services/#virtual-ips-and-service-proxies) 的内容。
可以进一步阅读[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
的内容。

<!--
## Accessing the Service
Expand All @@ -219,22 +211,19 @@ and DNS. The former works out of the box while the latter requires the
## 访问 Service

Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件]
[CoreDNS 集群插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).

{{< note >}}
[CoreDNS 集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).

<!--
If the service environment variables are not desired (because possible clashing with expected program ones,
too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
-->

{{< note >}}
如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在
[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。

[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。
{{< /note >}}


<!--
### Environment Variables
Expand Down Expand Up @@ -324,9 +313,10 @@ The rest of this section will assume you have a Service with a long lived IP
cluster addon), so you can talk to the Service from any pod in your cluster using
standard methods (e.g. gethostbyname). Let's run another curl application to test this:
-->

如果没有在运行，可以 [启用它](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。
本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法，使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。
如果没有在运行，可以[启用它](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。
本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），
一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法，
使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。
让我们运行另一个 curl 应用来进行测试：

```shell
Expand Down Expand Up @@ -370,9 +360,10 @@ You can acquire all these from the [nginx https example](https://github.com/kube

* https 自签名证书（除非已经有了一个识别身份的证书）
* 使用证书配置的 Nginx server
* 使证书可以访问 Pod 的[秘钥](/docs/user-guide/secrets)
* 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/)

可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) 获取所有上述内容，简明示例如下：
可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/)
获取所有上述内容，简明示例如下：

```shell
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
Expand Down Expand Up @@ -456,7 +447,8 @@ Noteworthy points about the nginx-secure-app manifest:
关于 nginx-secure-app manifest 值得注意的点如下：

- 它在相同的文件中包含了 Deployment 和 Service 的规格
- [Nginx server](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) 处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。
- [Nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf)
处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。
- 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。

```shell
Expand All @@ -483,7 +475,8 @@ so we have to tell curl to ignore the CName mismatch. By creating a Service we l
Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service):
-->

注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时，我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。
注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时，
我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。
通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。
让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）：

Expand Down Expand Up @@ -513,15 +506,18 @@ LoadBalancers. The Service created in the last section already used `NodePort`,
so your nginx HTTPS replica is ready to serve traffic on the internet if your
node has a public IP.
-->

## 暴露 Service

对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。
Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。
在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪，如果使用一个公网 IP，能够处理 Internet 上的流量。
在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪，
如果使用一个公网 IP，能够处理 Internet 上的流量。

```shell
kubectl get svc my-nginx -o yaml | grep nodePort -C 5
```

```
uid: 07191fb3-f61a-11e5-8ae5-42010af00002
spec:
clusterIP: 10.0.162.149
Expand All @@ -539,8 +535,12 @@ spec:
selector:
run: my-nginx
```

```shell
kubectl get nodes -o yaml | grep ExternalIP -C 1
```

```
- address: 104.197.41.11
type: ExternalIP
allocatable:
Expand All @@ -549,8 +549,14 @@ kubectl get nodes -o yaml | grep ExternalIP -C 1
type: ExternalIP
allocatable:
...
```

$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
```shell
curl https://<EXTERNAL-IP>:<NODE-PORT> -k
```

输出类似于：
```
...
<h1>Welcome to nginx!</h1>
```
Expand Down Expand Up @@ -593,13 +599,14 @@ see it. You'll see something like this:

```shell
kubectl describe service my-nginx
```

```
...
LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
...
```



## {{% heading "whatsnext" %}}

<!--
Expand All @@ -610,3 +617,4 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)

0 comments on commit 9f7414e

Please sign in to comment.