Merge pull request #5354 from zhangqx2010/upstream
k8smeetup-cn-translation-zhangqx-pr-20170907
This commit is contained in:
Tim(Xiaoyu) Zhang
GitHub
commit
d4a8800cab
|
|
@ -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 %}
|
||||
<table class="includecode">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>
|
||||
{% if ghlink %}<a href="{{ghlink}}" download="{{include.file}}">{% endif %}
|
||||
<code>{{include.file}}</code>
|
||||
{% if ghlink %}</a>{% endif %}
|
||||
<img src="/images/copycode.svg" style="max-height:24px" onclick="copyCode('{{include.file | handleize}}')" title="Copy {{include.file}} to clipboard">
|
||||
</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>{{ mysample | markdownify }}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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).
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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-<token id>`。
|
||||
`description` 是人类可读的描述，而不应该是机器可读的信息。令牌 ID 和 Secret 是包含在数据字典中的。
|
||||
|
||||
`usage-bootstrap-*` 成员表示这个 secret 的用途。启用时，值必须设置为 `true`。
|
||||
|
||||
`usage-bootstrap-authentication` 表示令牌可以用于 API 服务器的认证。认证器会以
|
||||
`system:bootstrap:<Token ID>` 认证。它被包含在 `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 <token id>|<token id>.<token secret>` 删除令牌。
|
||||
令牌可以只用 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: <really long certificate 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。
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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:<port>
|
||||
```
|
||||
|
||||
|
||||
|
||||
**注意**
|
||||
使用 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 后续版本中被修复。
|
||||
|
||||
|
||||
### 其他云服务商
|
||||
|
||||
|
||||
即将更新
|
||||
|
||||
|
|
@ -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: <none>
|
||||
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 会显示为 `<pending>`。
|
||||
|
||||
```
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend 10.51.252.116 <pending> 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://<EXTERNAL-IP>
|
||||
```
|
||||
|
||||
|
||||
后端生成的消息输出如下：
|
||||
|
||||
```
|
||||
{"message":"Hello"}
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
|
||||
|
||||
* 了解更多 [Services](/docs/concepts/services-networking/service/)
|
||||
* 了解更多 [ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/tutorial.md %}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
upstream hello {
|
||||
server hello;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
|
||||
location / {
|
||||
proxy_pass http://hello;
|
||||
}
|
||||
}
|
||||
Loading…
Reference in New Issue