diff --git a/cn/_includes/code.html b/cn/_includes/code.html new file mode 100644 index 0000000000..d59db08ff7 --- /dev/null +++ b/cn/_includes/code.html @@ -0,0 +1,26 @@ +{% capture samplecode %}{% include_relative {{include.file}} %}{% endcapture %} +{% if include.k8slink %}{% capture ghlink %}https://raw.githubusercontent.com/kubernetes/kubernetes/blob/{{page.githubbranch}}{{include.k8slink}}{% endcapture %}{% endif %} +{% if include.ghlink %}{% capture ghlink %}https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/{{page.docsbranch}}{{include.ghlink}}{% endcapture %}{% endif %} +{% capture mysample %} +```{{include.language}} +{{ samplecode | raw | strip }} +``` +{: id="{{include.file | handleize}}"} +{% endcapture %} + + + + + + + + + + + +
+ {% if ghlink %}{% endif %} + {{include.file}} + {% if ghlink %}{% endif %} + +
{{ mysample | markdownify }}
diff --git a/cn/_includes/task-tutorial-prereqs.md b/cn/_includes/task-tutorial-prereqs.md new file mode 100644 index 0000000000..a9cf90d265 --- /dev/null +++ b/cn/_includes/task-tutorial-prereqs.md @@ -0,0 +1,4 @@ +You need to have a Kubernetes cluster, and the kubectl command-line tool must +be configured to communicate with your cluster. If you do not already have a +cluster, you can create one by using +[Minikube](/docs/getting-started-guides/minikube). diff --git a/cn/_includes/templates/task.md b/cn/_includes/templates/task.md new file mode 100644 index 0000000000..e76cb7b117 --- /dev/null +++ b/cn/_includes/templates/task.md @@ -0,0 +1,55 @@ +{% if overview %} + +{{ overview }} + +{% else %} + +{% include templates/_errorthrower.md missing_block='overview' purpose='states, in one or two sentences, the purpose of this document' %} + +{% endif %} + + +* TOC +{: toc} + + +{% if prerequisites %} + +## Before you begin + +{{ prerequisites }} + +{% else %} + +{% include templates/_errorthrower.md missing_block='prerequisites' heading='Before you begin' purpose='lists action prerequisites and knowledge prerequisites' %} + +{% endif %} + + +{% if steps %} + +{{ steps }} + +{% else %} + +{% include templates/_errorthrower.md missing_block='steps' purpose='lists a sequence of numbered steps that accomplish the task.' %} + +{% endif %} + + +{% if discussion %} + +{{ discussion }} + +{% else %} + +{% endif %} + + +{% if whatsnext %} + +## What's next + +{{ whatsnext }} + +{% endif %} diff --git a/cn/_includes/templates/tutorial.md b/cn/_includes/templates/tutorial.md new file mode 100644 index 0000000000..b4c1faa0f1 --- /dev/null +++ b/cn/_includes/templates/tutorial.md @@ -0,0 +1,68 @@ +{% if overview %} + +{{ overview }} + +{% else %} + +{% include templates/_errorthrower.md missing_block='overview' purpose='states, in one or two sentences, the purpose of this document' %} + +{% endif %} + + +* TOC +{: toc} + + +{% if objectives %} + +## Objectives + +{{ objectives }} + +{% else %} + +{% include templates/_errorthrower.md missing_block='objectives' heading='Objectives' purpose='lists the objectives for this tutorial.' %} + +{% endif %} + + +{% if prerequisites %} + +## Before you begin + +{{ prerequisites }} + +{% else %} + +{% include templates/_errorthrower.md missing_block='prerequisites' heading='Before you begin' purpose='lists action prerequisites and knowledge prerequisites' %} + +{% endif %} + + +{% if lessoncontent %} + +{{ lessoncontent }} + +{% else %} + +{% include templates/_errorthrower.md missing_block='lessoncontent' purpose='provides the lesson content for this tutorial.' %} + +{% endif %} + + +{% if cleanup %} + +## Cleaning up + +{{ cleanup }} + +{% endif %} + + +{% if whatsnext %} + +## What's next + +{{ whatsnext }} + +{% endif %} diff --git a/cn/docs/admin/authorization/webhook.md b/cn/docs/admin/authorization/webhook.md new file mode 100644 index 0000000000..3a08d14ed1 --- /dev/null +++ b/cn/docs/admin/authorization/webhook.md @@ -0,0 +1,142 @@ +--- +assignees: +- erictune +- lavalamp +- deads2k +- liggitt +title: Webhook Mode +--- + +{% capture overview %} +WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL 。 +{% endcapture %} + +{% capture body %} +具体来说，当在判断用户权限时，`Webhook` 模式会使 Kubernetes 查询外部的 REST 服务。 + +## 配置文件格式 + +`Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。 + +配置文件的格式使用 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)。 +在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。 + +使用 HTTPS 客户端认证的配置例子： + +```yaml +# clusters 代表远程服务。 +clusters: + - name: name-of-remote-authz-service + cluster: + certificate-authority: /path/to/ca.pem # 对远程服务进行身份认证的CA。 + server: https://authz.example.com/authorize # 远程服务的查询 URL. 必须使用 'https'。 + +# users 代表 API 服务器的 webhook 配置. +users: + - name: name-of-api-server + user: + client-certificate: /path/to/cert.pem # webhook plugin 使用的 cert。 + client-key: /path/to/key.pem # cert 所对应的 key。 + +# kubeconfig 文件必须有 context 。 需要提供一个给 API 服务器。 +current-context: webhook +contexts: +- context: + cluster: name-of-remote-authz-service + user: name-of-api-server + name: webhook +``` + + +## 请求载荷 + +在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 api.authorization.v1beta1.SubjectAccessReview 对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或者请求特征的具体信息。 + +需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从 [版本兼容规则](/docs/api/) 。 +实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段以确保能被正确地反序列化。 +此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组(`--runtime-config=authorization.k8s.io/v1beta1=true`)。 + + +一个请求内容的例子： + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "resourceAttributes": { + "namespace": "kittensandponies", + "verb": "get", + "group": "unicorn.example.org", + "resource": "pods" + }, + "user": "jane", + "group": [ + "group1", + "group2" + ] + } +} +``` + +远程服务被预期能填写请求和反馈的 SubjectAccessReviewStatus 字段，无论是允许访问还是拒绝访问。 +反馈内容的 "spec" 字段是被忽略的，也是可以被省略的。当请求是被允许的时候，返回的响应如下例所示： + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "status": { + "allowed": true + } +} +``` + + +如拒绝，远程服务器会返回： + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "status": { + "allowed": false, + "reason": "user does not have read access to the namespace" + } +} +``` + + +对于非资源的路径访问是这么发送的： + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "nonResourceAttributes": { + "path": "/debug", + "verb": "get" + }, + "user": "jane", + "group": [ + "group1", + "group2" + ] + } +} +``` + + +非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`, +`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and +`/version`。 客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便 +能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。 + + +更多信息可以参考 uthorization.v1beta1 API 对象和 +[webhook.go](https://git.k8s.io/kubernetes/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). + +{% endcapture %} + +{% include templates/concept.md %} diff --git a/cn/docs/admin/bootstrap-tokens.md b/cn/docs/admin/bootstrap-tokens.md new file mode 100644 index 0000000000..1e0bdcc6fe --- /dev/null +++ b/cn/docs/admin/bootstrap-tokens.md @@ -0,0 +1,137 @@ +--- +assignees: +- jbeda +title: 使用启动引导令牌（Bootstrap Tokens）认证 +--- + +* TOC +{:toc} + +## 概述 + +启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群或者在现有集群中添加新节点时使用的。 +它被设计成能够支持 [`kubeadm`](/docs/admin/kubeadm/)，但是也可以被用在其他的案例中以便用户在 +不使用 `kubeadm` 的情况下启动集群。它也被设计成可以通过 RBAC 策略，结合 [Kubelet TLS +Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。 + +启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`)，并存在于 +`kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。 +控制器管理器中的控制器TokenCleaner能够删除过期的令牌。在节点发现的过程中Kubernetes会使用特殊的ConfigMap对象。 +控制器管理器中的BootstrapSigner控制器也会使用启动引导令牌为这类对象生成签名信息。 + +目前，启动引导令牌处于 **alpha** 阶段，但是预期也不会有大的突破性变化。 + +## 令牌格式 + +启动引导令牌使用 `abcdef.0123456789abcdef` 的形式。 +更加规范地说，它们必须符合正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。 + +令牌的第一部分是 "Token ID" ，它是公共信息。用于引用某个令牌，并确保不会泄露认证所使用的秘密信息。 +第二部分是 "令牌秘密（Token Secret）"，它应该被共享给收信的第三方。 + +## 启用启动引导令牌 + +所有与启动引导令牌相关的特性在 Kubernetes v1.6 版本中默认都是禁用的。 + +你可以在 API 服务器上通过 `--experimental-bootstrap-token-auth` 参数启用启动引导令牌。 +你可以设置控制管理器的 `--controllers` 参数来启用启动引导令牌相关的控制器，例如 `--controllers=*,tokencleaner,bootstrapsigner` 。 +在使用 `kubeadm` 时，这是自动完成的。 + +HTTPS 调用中的令牌是这样使用的： + +```http +Authorization: Bearer 07401b.f395accd246ae52d +``` + +## 启动引导令牌的密文格式 + +每个合法的令牌背后对应着 `kube-system` 命名空间中的某个 Secret 对象。 +你可以从 [这里](https://git.k8s.io/community/contributors/design-proposals/bootstrap-discovery.md) 找到完整设计文档。 + +这是 secret 看起来的样子。注意，`base64(string)` 表示应该通过 base64 对值进行编码。 +这里使用的是未解码的版本以便于阅读。 + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: bootstrap-token-07401b + namespace: kube-system +type: bootstrap.kubernetes.io/token +data: + description: base64(The default bootstrap token generated by 'kubeadm init'.) + token-id: base64(07401b) + token-secret: base64(f395accd246ae52d) + expiration: base64(2017-03-10T03:22:11Z) + usage-bootstrap-authentication: base64(true) + usage-bootstrap-signing: base64(true) +``` + +secret 的类型必须是 `bootstrap.kubernetes.io/token` ，而且名字必须是 `bootstrap-token-`。 +`description` 是人类可读的描述，而不应该是机器可读的信息。令牌 ID 和 Secret 是包含在数据字典中的。 + +`usage-bootstrap-*` 成员表示这个 secret 的用途。启用时，值必须设置为 `true`。 + +`usage-bootstrap-authentication` 表示令牌可以用于 API 服务器的认证。认证器会以 +`system:bootstrap:` 认证。它被包含在 `system:bootstrappers` 组中。 +命名和组是故意受限制的，以防止用户在启动引导后再使用这些令牌。 + +`usage-bootstrap-signing` 表示令牌应该被用于 `cluster-info` ConfigMap 的签名，就像下面描述的那样。 + +`expiration` 数据成员显示了令牌在失效后到现在的时间。这是遵循 RFC3339 进行编码的 UTC 时间。 +TokenCleaner 控制器会删除过期的令牌。 + +## 使用 `kubeadm` 管理令牌 + +你可以使用 `kubeadm` 工具管理正在运行集群的令牌。它会从 `kubeadm` 创建的集群(`/etc/kubernetes/admin.conf`) +自动抓取默认管理员密码。你可以通过参数 `--kubeconfig` 对下面命令指定一个另外的 kubeconfig 文件抓取密码。 + +* `kubeadm token list` 列举了令牌，同时显示了它们的过期时间和用途。 +* `kubeadm token create` 创建一个新令牌。 + * `--description` 设置新令牌的描述。 + * `--ttl duration` 设置令牌从 "现在" 起到过期时间的差值。 + 默认是 0 ，也就是不过期。 + * `--usages` 设置令牌被使用的方式。默认是 `signing,authentication`。用途在上面已经描述。 +* `kubeadm token delete |.` 删除令牌。 + 令牌可以只用 ID 来确认，也可以用整个令牌的值。如果只用 ID 的情况下，密文不匹配的令牌也会被删除。 + +### ConfigMap签名 + +除了认证之外，令牌可以用于签名 ConfigMap。这在集群启动过程的早期，在客户端信任 API 服务器之前被使用。 +被签名的 ConfigMap 可以通过共享令牌被认证。 + +被签名的 ConfigMap 是 `cluster-info`，存在于 `kube-public` 命名空间中。 +典型的工作流中，客户端在未经认证和忽略 TLS 报错的状态下读取这个 ConfigMap。 +通过 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。 + +ConfigMap 会是这个样子的： + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: cluster-info + namespace: kube-public +data: + jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U + kubeconfig: | + apiVersion: v1 + clusters: + - cluster: + certificate-authority-data: + server: https://10.138.0.2:6443 + name: "" + contexts: [] + current-context: "" + kind: Config + preferences: {} + users: [] +``` + +ConfigMap 的 `kubeconfig` 成员是一个填好了集群信息的配置文件。 +这里主要交换的信息是 `certificate-authority-data`。在将来可能会有扩展。 + +签名是一个 JWS 签名，使用了 "detached" 模式。为了检验签名，用户应该按照 JWS 规则 +(base64 编码而忽略结尾的 `=`)对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间 +，用于形成一个完整的 JWS。可以使用令牌的完整信息（比如 `07401b.f395accd246ae52d`）作为共享密钥， +通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 _必须_ 确保使用了 HS256。 \ No newline at end of file diff --git a/cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md new file mode 100644 index 0000000000..0a0b9b953f --- /dev/null +++ b/cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -0,0 +1,186 @@ +--- +title: 同 Pod 内的容器使用共享卷通信 +redirect_from: +- "/docs/user-guide/pods/multi-container/" +- "/docs/user-guide/pods/multi-container.html" +- "/docs/tasks/configure-pod-container/communicate-containers-same-pod/" +- "/docs/tasks/configure-pod-container/communicate-containers-same-pod.html" +--- + + +{% capture overview %} + + + +本文旨在说明如何让一个 Pod 内的两个容器使用一个卷（Volume）进行通信。 + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + + +{% capture steps %} + + +## 创建一个包含两个容器的 Pod + + + + +在这个练习中，你会创建一个包含两个容器的 Pod。两个容器共享一个卷用于他们之间的通信。 +Pod 的配置文件如下： + +{% include code.html language="yaml" file="two-container-pod.yaml" ghlink="/docs/tasks/access-application-cluster/two-container-pod.yaml" %} + + + +在配置文件中，你可以看到 Pod 有一个共享卷，名为 `shared-data`。 + + + + + +配置文件中的第一个容器运行了一个 nginx 服务器。共享卷的挂载路径是 `/usr/share/nginx/html`。 +第二个容器是基于 debian 镜像的，有一个 `/pod-data` 的挂载路径。第二个容器运行了下面的命令然后终止。 + + echo Hello from the debian container > /pod-data/index.html + + + +注意，第二个容器在 nginx 服务器的根目录下写了 `index.html` 文件。 + + +创建一个包含两个容器的 Pod： + + kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/two-container-pod.yaml + + +查看 Pod 和容器的信息： + + kubectl get pod two-containers --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: + ... + + + +你可以看到 debian 容器已经被终止了，而 nginx 服务器依然在运行。 + + +进入 nginx 容器的 shell： + + kubectl exec -it two-containers -c nginx-container -- /bin/bash + + +在 shell 中，确认 nginx 还在运行。 + + root@two-containers:/# ps aux + + +输出类似于这样： + + USER PID ... STAT START TIME COMMAND + root 1 ... Ss 21:12 0:00 nginx: master process nginx -g daemon off; + + + +回忆一下，debian 容器在 nginx 的根目录下创建了 `index.html` 文件。 +使用 `curl` 向 nginx 服务器发送一个 GET 请求： + + root@two-containers:/# apt-get update + root@two-containers:/# apt-get install curl + root@two-containers:/# curl localhost + + +输出表示 nginx 提供了 debian 容器写的页面： + + Hello from the debian container + +{% endcapture %} + + +{% capture discussion %} + + +## 讨论 + + + + + + + + +Pod 能有多个容器的主要原因是为了支持辅助应用（helper applications），以协助主应用（primary application）。 +辅助应用的典型例子是数据抽取，数据推送和代理。辅助应用和主应用经常需要相互通信。 +就如这个练习所示，通信通常是通过共享文件系统完成的，或者，也通过回环网络接口 localhost 完成。 +举个网络接口的例子，web 服务器带有一个协助程序用于拉取 Git 仓库的更新。 + + + + +在本练习中的卷为 Pod 生命周期中的容器相互通信提供了一种方法。如果 Pod 被删除或者重建了， +任何共享卷中的数据都会丢失。 + +{% endcapture %} + + +{% capture whatsnext %} + + + +* 更多学习内容 +[混合容器的方式](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html)。 + + + +* 学习 [模块化架构的混合容器](http://www.slideshare.net/Docker/slideshare-burns)。 + + + +* 参见 [配置一个使用存储卷的 Pod](/docs/tasks/configure-pod-container/configure-volume-storage/)。 + + +* 参见 [卷](/docs/api-reference/{{page.version}}/#volume-v1-core)。 + + +* 参见 [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core). + +{% endcapture %} + + +{% include templates/task.md %} diff --git a/cn/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/cn/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md new file mode 100644 index 0000000000..552822ec23 --- /dev/null +++ b/cn/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md @@ -0,0 +1,126 @@ +--- +approvers: +- bprashanth +- davidopp +title: 配置你的云平台防火墙 +--- + + + + + + +许多云服务商（比如 Google Compute Engine）定义防火墙以防止服务无意间暴露到 internet 上。 +当暴露服务给外网时，你可能需要在防火墙上开启一个或者更多的端口来支持服务。 +本文描述了这个过程，以及其他云服务商的具体信息。 + + +## 负载均衡（LoadBalancer）服务的访问限制 + + + + + 当以 `spec.type: LoadBalancer` 使用服务时，你可以使用 `spec.loadBalancerSourceRanges` 指定允许访问负载均衡的 IP 段。 + 这个字段采用 CIDR 的 IP 段，Kubernetes 会使用这个段配置防火墙。支持这个功能的平台目前有 Google Compute Engine，Google Container Engine 和 AWS。 + 如果云服务商不支持这个功能，这个字段会被忽略。 + + + + 假设 10.0.0.0/8 是内部的子网。在下面这个例子中，会创建一个只有集群内部 ip 可以访问的负载均衡器。 + 集群外部的客户端是无法访问这个负载均衡器的。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: myapp +spec: + ports: + - port: 8765 + targetPort: 9376 + selector: + app: example + type: LoadBalancer + loadBalancerSourceRanges: + - 10.0.0.0/8 +``` + + + 这个例子中，会创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: myapp +spec: + ports: + - port: 8765 + targetPort: 9376 + selector: + app: example + type: LoadBalancer + loadBalancerSourceRanges: + - 130.211.204.1/32 + - 130.211.204.2/32 +``` + + +### 谷歌计算引擎（Google Compute Engine） + + + + +当以 `spec.type: LoadBalancer` 使用服务时，防火墙会被自动打开。 +然而，当以 `spec.type: NodePort` 使用服务时，防火墙默认 *不会* 被打开。 + + +Google Compute Engine 的防火墙文档在[别处](https://cloud.google.com/compute/docs/networking#firewalls_1)。 + + +你可以使用 `gcloud` 命令行工具添加一个防火墙： + +```shell +$ gcloud compute firewall-rules create my-rule --allow=tcp: +``` + + + +**注意** +使用 Google Compute Engine 平台的防火墙时有一个重要的关于安全的注意点： + + + + + + + +在 Kubernetes v1.0.0 版本，GCE 防火墙是定义按虚拟机（VM）来的，而不是按 ip 来的。 +这就意味着当你在防火墙上打开一个服务端口时，任何在那台虚拟机 IP 上的同一端口的服务 +都有被外部访问的潜在可能。注意，这对于其他 Kubernetes 服务来说不是问题，因为他们监 +听的 IP 地址与主机节点的外部 IP 地址不同。 + + +考虑一下: + + * 你创建了一个服务，使用了外部服务均衡 (IP 地址为 1.2.3.4) 和 80 端口。 + * 你在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的 + 服务发送数据包。 + * 你又在虚拟机（IP 为2.3.4.5）上使用 80 端口启动了一台 nginx 服务器. + 这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了 internet 上。 + + + + +因此，在 Google Compute Engine 或者 Google Container Engine 上开启防火墙端口时请 +小心。你可能无意间把其他服务也暴露给了 internet。 + + +这个问题会在 Kubernetes 后续版本中被修复。 + + +### 其他云服务商 + + +即将更新 + diff --git a/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md new file mode 100644 index 0000000000..f2d82fae7e --- /dev/null +++ b/cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -0,0 +1,223 @@ +--- +title: 使用 Service 把前端连接到后端 +--- + + +{% capture overview %} + + + + +本任务会描述如何创建前端微服务和后端微服务。后端微服务是一个 hello 欢迎程序。 +前端和后端的连接是通过 Kubernetes 服务对象（Service object）完成的。 + +{% endcapture %} + + +{% capture objectives %} + + + + +* 使用部署对象（Deployment object）创建并运行一个微服务 +* 从后端将流量路由到前端 +* 使用服务对象把前端应用连接到后端应用 + +{% endcapture %} + + +{% capture prerequisites %} + +* {% include task-tutorial-prereqs.md %} + + +* 本任务使用 [外部负载均衡服务](/docs/tasks/access-application-cluster/create-external-load-balancer/)， + 所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用 + [NodePort](/docs/user-guide/services/#type-nodeport) 类型的服务代替。 + +{% endcapture %} + + +{% capture lessoncontent %} + + +### 使用部署对象（Deployment）创建后端 + + + +后端是一个简单的 hello 欢迎微服务应用。这是后端应用的 Deployment 配置文件： + +{% include code.html language="yaml" file="hello.yaml" ghlink="/docs/tasks/access-application-cluster/hello.yaml" %} + + +创建后端 Deployment： + +``` +kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello.yaml +``` + + +查看后端的 Deployment 信息： + +``` +kubectl describe deployment hello +``` + + +输出类似于： + +``` +Name: hello +Namespace: default +CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700 +Labels: app=hello + tier=backend + track=stable +Selector: app=hello,tier=backend,track=stable +Replicas: 7 updated | 7 total | 7 available | 0 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 1 max unavailable, 1 max surge +OldReplicaSets: +NewReplicaSet: hello-3621623197 (7/7 replicas created) +Events: +... +``` + + +### 创建后端服务对象（Service object） + + + + + +前端连接到后端的关键是 Service。Service 创建一个固定 IP 和 DNS 解析名入口， +使得后端微服务可达。Service 使用 selector 标签来寻找目标 Pod。 + + +首先，浏览 Service 的配置文件： + +{% include code.html language="yaml" file="hello-service.yaml" ghlink="/docs/tasks/access-application-cluster/hello-service.yaml" %} + + + +配置文件中，你可以看到 Service 将流量路由到包含 `app: hello` 和 `tier: backend` 标签的 Pod。 + + +创建 `hello` Service： + +``` +kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello-service.yaml +``` + + + +此时，你已经有了一个在运行的后端 Deployment，你也有了一个 Service 用于路由网络流量。 + + +### 创建前端应用 + + + + + +既然你已经有了后端应用，你可以创建一个前端应用连接到后端。前端应用通过 DNS 名连接到后端的工作 Pods。 +DNS 名是 "hello"，也就是 Service 配置文件中 `name` 字段的值。 + + + +前端 Deployment 中的 Pods 运行一个 nginx 镜像，这个已经配置好镜像去寻找后端的 hello Service。 +只是 nginx 的配置文件： + +{% include code.html file="frontend/frontend.conf" ghlink="/docs/tasks/access-application-cluster/frontend/frontend.conf" %} + + + + +与后端类似，前端用包含一个 Deployment 和一个 Service。Service 的配置文件包含了 `type: LoadBalancer`， +也就是说，Service 会使用你的云服务商的默认负载均衡设备。 + +{% include code.html language="yaml" file="frontend.yaml" ghlink="/docs/tasks/access-application-cluster/frontend.yaml" %} + + +创建前端 Deployment 和 Service： + +``` +kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/frontend.yaml +``` + + +通过输出确认两个资源都已经被创建： + +``` +deployment "frontend" created +service "frontend" created +``` + + + + + + +**注意**：这个 nginx 配置文件是被打包在 [容器镜像](/docs/tasks/access-application-cluster/frontend/Dockerfile) 里的。 +更好的方法是使用 [ConfigMap](/docs/tasks/configure-pod-container/configmap/)，这样的话你可以更轻易地更改配置。 + + +### 与前端 Service 交互 + + + +一旦你创建了 LoadBalancer 类型的 Service，你可以使用这条命令查看外部 IP： + +``` +kubectl get service frontend +``` + + + +外部 IP 字段的生成可能需要一些时间。如果是这种情况，外部 IP 会显示为 ``。 + +``` +NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE +frontend 10.51.252.116 80/TCP 10s +``` + + +使用相同的命令直到它显示外部 IP 地址： + +``` +NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE +frontend 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m +``` + + +### 通过前端发送流量 + + + +前端和后端已经完成连接了。你可以使用 curl 命令通过你的前端 Service 的外部 IP 访问服务端点。 + +``` +curl http:// +``` + + +后端生成的消息输出如下： + +``` +{"message":"Hello"} +``` + +{% endcapture %} + + +{% capture whatsnext %} + + + +* 了解更多 [Services](/docs/concepts/services-networking/service/) +* 了解更多 [ConfigMaps](/docs/tasks/configure-pod-container/configmap/) + +{% endcapture %} + +{% include templates/tutorial.md %} diff --git a/cn/docs/tasks/access-application-cluster/frontend/frontend.conf b/cn/docs/tasks/access-application-cluster/frontend/frontend.conf new file mode 100644 index 0000000000..9a1f5a0ed6 --- /dev/null +++ b/cn/docs/tasks/access-application-cluster/frontend/frontend.conf @@ -0,0 +1,11 @@ +upstream hello { + server hello; +} + +server { + listen 80; + + location / { + proxy_pass http://hello; + } +}