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

Convert site to Hugo (#8316)

Browse Source 
This commit converts content and layout to use Hugo.
This commit is contained in:
Bjørn Erik Pedersen
2018-05-05 18:00:51 +02:00
committed by k8s-ci-robot
parent 7745f0e0c5
commit 7f3b633aa0
2327 changed files with 10928 additions and 171503 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/cn/docs/concepts/cluster-administration/addons.md
+45
View File
@@ -0,0 +1,45 @@
---
title: 安装扩展（Addons）
---
## 概览
Add-ons 扩展了 Kubernetes 的功能。
本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。
每个 add-ons 按字母顺序排序 - 顺序不代表任何优先地位。
## 网络和网络策略
* [Calico](http://docs.projectcalico.org/latest/getting-started/kubernetes/installation/hosted/) 是一个安全的 L3 网络和网络策略提供者。
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) 结合 Flannel 和 Calico， 提供网络和网络策略。
* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件， 能够透明的实施 HTTP/API/L7 策略。 同时支持路由（routing）和叠加/封装（ overlay/encapsulation）模式。
* [Contiv](http://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的 overlay，经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。
* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案，并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 提供了在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，例如：Flannel、Calico、Canal、Romana 或者 Weave。
## 可视化管理
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，用于查看你的 containers、 pods、services等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用，或者自己运行 UI。
## 遗留 Add-ons
还有一些其它 add-ons 归档在已废弃的 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。
维护完善的 add-ons 应该被链接到这里。欢迎提出 PRs！
content/cn/docs/concepts/cluster-administration/certificates.md
+247
View File
@@ -0,0 +1,247 @@
---
cn-approvers:
- lichuqiang
title: 证书
---
{{< toc >}}
## 创建证书
当使用客户端证书进行认证时，用户可以使用现有部署脚本，或者通过 `easyrsa`、`openssl` 或
`cfssl` 手动生成证书。
### 使用现有部署脚本
**现有部署脚本** 位于
`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`。
执行该脚本时需传入两个参数。 第一个参数为 API 服务器的 IP 地址，第二个参数为对象的候补名称列表，
形如 `IP:<ip地址> 或 DNS:<dns名称>`。
脚本生成三个文件： `ca.crt`、`server.crt` 和 `server.key`。
最后，将以下参数加入到 API 服务器的启动参数中：
```
--client-ca-file=/srv/kubernetes/ca.crt
--tls-cert-file=/srv/kubernetes/server.crt
--tls-private-key-file=/srv/kubernetes/server.key
```
### easyrsa
使用 **easyrsa** 能够手动地为集群生成证书。
1. 下载、解压并初始化 easyrsa3 的补丁版本。
curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki
1. 生成 CA（通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN）
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
1. 生成服务器证书和密钥。
参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 `MASTER_CLUSTER_IP`
通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址，`--service-cluster-ip-range`同时用于
API 服务器和控制器管理器组件。 `--days` 参数用于设置证书的有效期限。
下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。
./easyrsa --subject-alt-name="IP:${MASTER_IP}"\
"IP:${MASTER_CLUSTER_IP},"\
"DNS:kubernetes,"\
"DNS:kubernetes.default,"\
"DNS:kubernetes.default.svc,"\
"DNS:kubernetes.default.svc.cluster,"\
"DNS:kubernetes.default.svc.cluster.local" \
--days=10000 \
build-server-full server nopass
1. 拷贝 `pki/ca.crt`、 `pki/issued/server.crt` 和 `pki/private/server.key` 至您的目录。
1. 填充并在 API 服务器的启动参数中添加以下参数：
--client-ca-file=/yourdirectory/ca.crt
--tls-cert-file=/yourdirectory/server.crt
--tls-private-key-file=/yourdirectory/server.key
### openssl
使用 **openssl** 能够手动地为集群生成证书。
1. 生成密钥位数为 2048 的 ca.key：
openssl genrsa -out ca.key 2048
1. 依据 ca.key 生成 ca.crt （使用 -days 参数来设置证书有效时间）：
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
1. 生成密钥位数为 2048 的 server.key：
openssl genrsa -out server.key 2048
1. 创建用于生成证书签名请求（CSR）的配置文件。
确保在将其保存至文件（如`csr.conf`）之前将尖括号标记的值（如`<MASTER_IP>`）
替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP
(service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
IP.1 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
1. 基于配置文件生成证书签名请求：
openssl req -new -key server.key -out server.csr -config csr.conf
1. 使用 ca.key、ca.crt 和 server.csr 生成服务器证书：
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf
1. 查看证书：
openssl x509 -noout -text -in ./server.crt
最后，添加同样的参数到 API 服务器的启动参数中。
### cfssl
**cfssl** 是另一种用来生成证书的工具。
1. 按如下所示的方式下载、解压并准备命令行工具。
注意：你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。
curl -LO https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl
chmod +x cfssl
curl -LO https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
chmod +x cfssljson
curl -LO https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
1. 创建目录来存放物料，并初始化 cfssl：
mkdir cert
cd cert
../cfssl print-defaults config > config.json
../cfssl print-defaults csr > csr.json
1. 创建用来生成 CA 文件的 JSON 配置文件，例如 `ca-config.json`：
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth",
],
"expiry": "8760h"
}
}
}
}
1. 创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件，例如 `ca-csr.json`。
确保将尖括号标记的值替换为你想使用的真实值。
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names":[{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>",
}]
}
1. 生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）：
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
1. 按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。
确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的
API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"<MASTER_IP>",
"<MASTER_CLUSTER_IP>",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
1. 为 API 服务器生成密钥和证书，生成的秘钥和证书分别默认保存在文件 `server-key.pem`
和 `server.pem` 中：
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
--config=ca-config.json -profile=kubernetes \
server-csr.json | ../cfssljson -bare server
## 分发自签名 CA 证书
客户端节点可能拒绝承认自签名 CA 证书有效。
对于非生产环境的部署，或运行在企业防火墙后的部署，用户可以向所有客户端分发自签名 CA 证书，
并刷新本地的有效证书列表。
在每个客户端上执行以下操作：
```bash
$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.
```
## 证书 API
您可以按照[这里](/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式，
使用 `certificates.k8s.io` API 来准备 x509 证书，用于认证。
content/cn/docs/concepts/cluster-administration/cloud-providers.md
+109
View File
@@ -0,0 +1,109 @@
---
title: 云供应商
content_template: templates/concept
---
{{% capture overview %}}
本文介绍了如何管理运行在特定云供应商上的 Kubernetes 集群。
{{% /capture %}}
{{% capture body %}}
# AWS
本节介绍在 Amazon Web Services 上运行 Kubernetes 时可以使用的所有配置。
## 负载均衡器
用户可以通过配置注解（annotations）来设置 [外部负载均衡器](/docs/tasks/access-application-cluster/create-external-load-balancer/)，以在 AWS 中使用特定功能，如下所示：
```yaml
apiVersion: v1
kind: Service
metadata:
name: example
namespace: kube-system
labels:
run: example
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
spec:
type: LoadBalancer
ports:
- port: 443
targetPort: 5556
protocol: TCP
selector:
app: example
```
可以使用 _注解_ 将不同的设置应用于 AWS 中的负载平衡器服务。 下面描述了 AWS ELB 所支持的注解：
* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`：用于指定访问日志的间隔。
* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`：用于在服务中启用或禁用日志访问。
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`：用于指定访问日志的 S3 桶名称。
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`：用于指定访问日志的 S3 桶前缀。
* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`：用于在服务中指定一个逗号分隔的键值对列表，它将作为附加标签被记录在 ELB 中。 例如： `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`。
* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`：用于在服务中指定监听器后端（pod）所使用的协议。 如果指定 `http` （默认） 或 `https`， 将创建一个终止连接和解析头的 HTTPS 监听器。 如果设置为 `ssl` 或 `tcp`， 将会使用 “原生的” SSL 监听器。 如果设置为 `http` 且不使用 `aws-load-balancer-ssl-cert`，将使用 HTTP 监听器。
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`：用于在服务中请求安全监听器，其值为合法的证书 ARN（Amazon Resource Name）。 更多内容，请参考 [ELB 监听器配置](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。 证书 ARN 是 IAM（身份和访问管理） 或 CM（证书管理）类型的 ARN，例如 `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`。
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`：用于在服务中启用或禁用连接耗尽（connection draining）。
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`：用于在服务中指定连接耗尽超时时间。
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`：用于在服务中指定空闲连接超时时间。
* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`：用于在服务中启用或禁用跨区域负载平衡。
* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`：用于在服务中指定要添加到创建的 ELB 中的其他安全组。
* `service.beta.kubernetes.io/aws-load-balancer-internal`：用于在服务中表明需要内部 ELB。
* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`：用于在 ELB 上启用代理协议。 当前仅接受 `*` 值，也就是在所有 ELB 后端启用代理协议。 将来可能进行调整，只允许特定的后端设置代理协议。
* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`：用于在服务中指定一个逗号分隔的端口列表，这些端口会使用 SSL/HTTPS 监听器。 默认为 `*`（全部）
AWS 相关的注解信息取自 [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go) 文件的注释。
# OpenStack
本节介绍了使用 OpenStack 运行 Kubernetes 时所有可用的配置。
## cloud.conf
Kubernetes 知道如何通过文件 cloud.conf 与 OpenStack 进行交互。 该文件会为 Kubernetes 提供证书和 OpenStack 认证端点的区位信息。
用户可以通过在其中指定以下信息来创建 cloud.conf 文件。
### 最小配置
这是一个最小配置的例子，它涉及最常用的值：
```yaml
[Global]
username=user
password=pass
auth-url=https://<keystone_ip>/identity/v3
tenant-id=c869168a828847f39f7f06edd7305637
domain-id=2a73b8f597c04551a0fdc8e95544be8a
[LoadBalancer]
subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
```
#### 全局配置
* `username`：指 keystone 中设置的一个合法用户的用户名。
* `password`：指 keystone 中设置的一个合法用户的密码。
* `auth-url`：用于认证的 keystone API 的 URL 。 在 OpenStack 控制面板上，可以在 “访问和安全（Access and Security）> api 访问（API Access）> 凭证（Credentials）” 路径下找到它。
* `tenant-id`：用于指定要创建资源的项目 ID。
* `domain-id`：用于指定用户所属的域（domain）ID。
#### 负载均衡器
* `subnet-id`：用于指定要创建的负载均衡器所在的子网 ID。 可以在 “Network > Networks” 路径下找到它。 点击相应的网络获取其子网。
### 可选配置
#### 块存储
Kubernetes 利用 OpenStack 服务目录对它知道如何使用的服务进行定位，包括 Cinder 块存储服务。 然而，云供应商的配置中包含一个附加选项，可以影响块存储 API 的使用方式：
* `bs-version`：指所使用的块存储 API 版本。 其合法值为
`v1`、 `v2`、 `v3` 和 `auto`。 `auto` 为默认值，将使用底层 Openstack 所支持的块存储 API 的最新版本。
如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本，同时使用路径而不是端口来区分端点（endpoints），那么可能需要显式设置 `bs-version` 参数。 基于路径的端点形如 `http://foo.bar/volume` ，而基于端口的的端点形如
`http://foo.bar:xxx`。
在使用基于路径的端点，并且 Kubernetes 使用较旧的自动检索逻辑的环境中，尝试卷卸载（detachment）会返回 `BS API version autodetection failed.` 错误。 为了解决这个问题，可以通过添加以下内容到云供应商配置中，来强制使用 Cinder API V2 版本。
```yaml
[BlockStorage]
bs-version=v2
```
{{% /capture %}}
content/cn/docs/concepts/cluster-administration/cluster-administration-overview.md
+87
View File
@@ -0,0 +1,87 @@
---
approvers:
- davidopp
- lavalamp
title: 集群管理概述
content_template: templates/concept
---
{{% capture overview %}}
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对 [用户指南](/docs/user-guide/)中的概念有一些熟悉。
{{% /capture %}}
{{% capture body %}}
## 规划集群
查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版*。
在选择一个指南前，有一些因素需要考虑：
- 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。
- **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/admin/multi-cluster)。
- 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/admin/networking)最适合。一种自定义网络的选项是 [*OpenVSwitch GRE/VxLAN 网络*](/docs/admin/ovs-networking/)，它使用 OpenVSwitch 在跨 Kubernetes 节点的 pods 之间建立起网络。
- 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）**上运行？
- 你**只想运行一个集群**，还是打算**活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
- 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components) 。
请注意：不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。
如果你正在使用和 Salt 有关的指南，请查阅 [使用 Salt 配置 Kubernetes](/docs/admin/salt)。
## 管理集群
[管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。
## 保护集群
* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api) 描述了如何为用户和 service accounts 建立权限许可.
* [用户认证](/docs/admin/authentication) 阐述了 Kubernetes 中的认证功能，包括许多认证选项。
* [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。
* [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
* [审计](/docs/tasks/debug-application-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。
### 保护 kubelet
* [Master 节点通信](/docs/concepts/cluster-administration/master-node-communication/)
* [TLS 引导](/docs/admin/kubelet-tls-bootstrapping/)
* [Kubelet 认证/授权](/docs/admin/kubelet-authentication-authorization/)
## 可选集群服务
* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个Kubernetes service。
* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 阐述了Kubernetes 的日志如何工作以及怎样实现。
{{% /capture %}}
content/cn/docs/concepts/cluster-administration/device-plugins.md
+97
View File
@@ -0,0 +1,97 @@
---
approvers:
title: 设备插件
description: 使用 Kubernetes 设备插件框架来为 GPUs、 NICs、 FPGAs、 InfiniBand 和其他类似的需要供应商特别设置的资源开发插件。
content_template: templates/concept
---
{{< feature-state state="alpha" >}}
{{% capture overview %}}
从1.8版本开始，Kubernetes 提供了一套
[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，
使得供应商能够在不改动 Kubernetes 核心代码的情况下，向 kubelet 发布它们的资源。
供应商可以实现一个手动或以 DaemonSet 形式部署的插件，而不是编写自定义的 Kubernetes 代码。
插件的目标设备包括 GPUs、 高性能 NICs、 FPGAs、 InfiniBand
和其他类似的可能需要供应商特定的初始化和设置的计算资源。
{{% /capture %}}
{{% capture body %}}
## 设备插件注册
设备插件功能通过 `DevicePlugins` 功能入口控制， 该功能默认是禁用的。
当设备插件功能被启用时，kubelet 会对外提供一个 `Registration` gRPC 服务：
```gRPC
service Registration {
rpc Register(RegisterRequest) returns (Empty) {}
}
```
设备插件通过该 gRPC 服务将自身注册到 kubelet 。
注册过程中，设备插件需要发送:
* 它的 Unix 套接字名称。
* 所基于的设备插件 API 版本。
* 希望发布的 `ResourceName` 。 这里的 `ResourceName` 需要符合
[扩展资源命名方案](https://github.com/kubernetes/kubernetes/pull/48922)，
形如 `vendor-domain/resource` 。
例如，Nvidia GPU 资源被发布为 `nvidia.com/gpu` 。
注册成功后，设备插件将其管理的设备列表发送至 kubelet ，然后 kubelet 负责将这些资源作为 kubelet 节点状态更新的一部分，通知 apiserver 。
例如， 设备插件注册 `vendor-domain/foo` 到 kubelet ，
并上报了节点上的两个健康的设备后，节点状态将更新， 发布2个 `vendor-domain/foo` 。
然后，开发者可以在 [容器](/docs/api-reference/{{< param "version" >}}/#container-v1-core)
规格中通过使用与
[不透明整数型资源](/docs/tasks/configure-pod-container/opaque-integer-resource/)
中同样的流程来请求使用设备。
在1.8版本中， 扩展资源仅支持整型的资源，且容器规格中声明的 `limit` 与 `request` 必须相等。
## 设备插件实现
设备插件的工作流程一般包括以下步骤:
* 初始化。 在这个阶段，设备插件执行供应商特定的初始化和设置，以确保设备处于就绪状态。
* 插件通过主机路径 `/var/lib/kubelet/device-plugins/` 下的一个 Unix 套接字启动 gRPC 服务，该服务实现了以下接口：
```gRPC
service DevicePlugin {
// ListAndWatch returns a stream of List of Devices
// Whenever a Device state change or a Device disappears, ListAndWatch
// returns the new list
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
// Allocate is called during container creation so that the Device
// Plugin can run device specific operations and instruct Kubelet
// of the steps to make the Device available in the container
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
}
```
* 插件通过主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 下的 Unix 套接字将自身注册到 kubelet 。
* 注册成功之后，设备插件以服务模式运行，其间持续监测设备健康状态，并在任何设备状态变化时上报到 kubelet 。
插件也负责服务 `Allocate` gRPC 请求。 在 `Allocate` 过程中，插件可能会做设备特定的准备动作； 如 GPU 清理 或 QRNG 初始化。
如操作成功，设备插件会返回一个 `AllocateResponse` ，它包含了用于访问分配的设备的容器运行时配置信息。 kubelet 将该信息传递到容器运行时。
我们期望设备插件能够监测到 kubelet 重启，并将自身重新注册到新的 kubelet 实例中。 在1.8版本中，新的 kubelet 实例启动时，会清理当前 `/var/lib/kubelet/device-plugins` 路径下已存在的 Unix 套接字。 通过这一事件，设备插件能够监测到其 Unix 套接字被删除，并重新对自身进行注册。
## 设备插件部署
设备插件可以手动部署，也可以作为 DaemonSet 进行部署。 以 DaemonSet 形式部署的好处是设备插件故障时，
Kubernetes能够重新启动 Pods 。 否则就需要额外的设备插件故障恢复机制。
目录 `/var/lib/kubelet/device-plugins` 需要访问特权，
所以设备插件必须在特权的安全上下文环境下运行。
如果设备插件以 DaemonSet 形式运行， `/var/lib/kubelet/device-plugins`
目录必须在插件的 [PodSpec](/docs/api-reference/{{< param "version" >}}/#podspec-v1-core) 中以 [Volume](/docs/api-reference/{{< param "version" >}}/#volume-v1-core) 的形式挂载。
## 示例
设备插件实现的示例，参考
[基于 COS 操作系统的 nvidia GPU 设备插件](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)。
{{% /capture %}}
content/cn/docs/concepts/cluster-administration/federation.md
+117
View File
@@ -0,0 +1,117 @@
---
title: 联邦
content_template: templates/concept
---
{{% capture overview %}}
本页面阐明了为何以及如何使用联邦创建Kubernetes集群。
{{% /capture %}}
{{% capture body %}}
## 为何使用联邦
联邦可以使多个集群的管理简单化。它提供了两个主要构件模块：
* 跨集群同步资源：联邦能够让资源在多个集群中同步。例如，你可以确保在多个集群中存在同样的部署。
* 跨集群发现：联邦能够在所有集群的后端自动配置DNS服务和负载均衡。例如，通过多个集群的后端，你可以确保全局的VIP或DNS记录可用。
联邦技术的其他应用场景：
* 高可用性：通过跨集群分摊负载，自动配置DNS服务和负载均衡，联邦将集群失败所带来的影响降到最低。
* 避免供应商锁定：跨集群使迁移应用程序变得更容易，联邦服务避免了供应商锁定。
只有在多个集群的场景下联邦服务才是有帮助的。这里列出了一些你会使用多个集群的原因：
* 降低延迟：在多个区域含有集群，可使用离用户最近的集群来服务用户，从而最大限度降低延迟。
* 故障隔离：对于故障隔离，也许有多个小的集群比有一个大的集群要更好一些（例如：一个云供应商的不同可用域里有多个集群）。详细信息请参阅[多集群指南](/docs/admin/multi-cluster)。
* 可伸缩性：对于单个kubernetes集群是有伸缩性限制的（但对于大多数用户来说并非如此。更多细节参考[Kubernetes扩展和性能目标](https://git.k8s.io/community/sig-scalability/goals.md)）。
* [混合云](#混合云的能力)：可以有多个集群，它们分别拥有不同的云供应商或者本地数据中心。
### 注意事项
虽然联邦有很多吸引人的场景，但这里还是有一些需要关注的事项：
* 增加网络的带宽和损耗：联邦控制面会监控所有的集群，来确保集群的当前状态与预期一致。那么当这些集群运行在一个或者多个云提供者的不同区域中，则会带来重大的网络损耗。
* 降低集群的隔离：当联邦控制面中存在一个故障时，会影响所有的集群。把联邦控制面的逻辑降到最小可以缓解这个问题。 无论何时，它都是kubernetes集群里控制面的代表。设计和实现也使其变得更安全,避免多集群运行中断。
* 完整性：联邦项目相对较新，还不是很成熟。不是所有资源都可用，且很多资源才刚刚开始。[Issue 38893](https://github.com/kubernetes/kubernetes/issues/38893) 列举了一些团队正忙于解决的系统已知问题。
### 混合云的能力
Kubernetes集群里的联邦包括运行在不同云供应商上的集群（例如，谷歌云、亚马逊），和本地部署的集群（例如，OpenStack）。只需在适当的云供应商和/或位置创建所需的所有集群，并将每个集群的API endpoint和凭据注册到您的联邦API服务中（详情参考[联邦管理指南](/docs/admin/federation/)）。
在此之后，您的[API资源](#api资源)就可以跨越不同的集群和云供应商。
## 建立联邦
若要能联合多个集群，首先需要建立一个联邦控制面。参照[安装指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 建立联邦控制面。
## API资源
控制面建立完成后，就可以开始创建联邦API资源了。
以下指南详细介绍了一些资源：
* [Cluster](/docs/tasks/administer-federation/cluster/)
* [ConfigMap](/docs/tasks/administer-federation/configmap/)
* [DaemonSets](/docs/tasks/administer-federation/daemonset/)
* [Deployment](/docs/tasks/administer-federation/deployment/)
* [Events](/docs/tasks/administer-federation/events/)
* [Ingress](/docs/tasks/administer-federation/ingress/)
* [Namespaces](/docs/tasks/administer-federation/namespaces/)
* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
* [Secrets](/docs/tasks/administer-federation/secret/)
* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
[API参考文档](/docs/reference/federation/)列举了联邦API服务支持的所有资源。
## 级联删除
Kubernetes1.6版本支持联邦资源级联删除。使用级联删除，即当删除联邦控制面的一个资源时，也删除了所有底层集群中的相应资源。
当使用REST API时，级联删除功能不是默认开启的。若使用REST API从联邦控制面删除一个资源时，要开启级联删除功能，即需配置选项 `DeleteOptions.orphanDependents=false`。使用`kubectl delete`使级联删除功能默认开启。使用`kubectl delete --cascade=false`禁用级联删除功能。
注意：Kubernetes1.5版本开始支持联邦资源子集的级联删除。
## 单个集群的范围
对于IaaS供应商如谷歌计算引擎或亚马逊网络服务，一个虚拟机存在于一个[域](https://cloud.google.com/compute/docs/zones)或[可用域](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)中。
我们建议一个Kubernetes集群里的所有虚机应该在相同的可用域里，因为：
- 与单一的全局Kubernetes集群对比，该方式有较少的单点故障。
- 与跨可用域的集群对比，该方式更容易推断单区域集群的可用性属性。
- 当Kubernetes开发者设计一个系统(例如，对延迟、带宽或相关故障进行假设)，他们也会假设所有的机器都在一个单一的数据中心，或者以其他方式紧密相连。
每个可用区域里包含多个集群当然是可以的，但是总的来说我们认为集群数越少越好。
偏爱较少集群数的原因是：
- 在某些情况下，在一个集群里有更多的节点，可以改进Pods的装箱问题（更少的资源碎片）。
- 减少操作开销（尽管随着OPS工具和流程的成熟而降低了这块的优势）。
- 为每个集群的固定资源花费降低开销，例如，使用apiserver的虚拟机（但是在全体集群开销中，中小型集群的开销占比要小的多）。
多集群的原因包括：
- 严格的安全性策略要求隔离一类工作与另一类工作（但是，请参见下面的集群分割）。
- 测试集群或其他集群软件直至最优的新Kubernetes版本发布。
## 选择合适的集群数
Kubernetes集群数量选择也许是一个相对静止的选择，因为对其重新审核的情况很少。相比之下，一个集群中的节点数和一个服务中的pods数可能会根据负载和增长频繁变化。
选择集群的数量，首先，需要决定哪些区域对于将要运行在Kubernetes上的服务，可以有足够的时间到达所有的终端用户（如果使用内容分发网络，则不需要考虑CDN-hosted内容的延迟需求）。法律问题也可能影响这一点。例如，拥有全球客户群的公司可能会对于在美国、欧盟、亚太和南非地区拥有集群起到决定权。使用`R`代表区域的数量。
其次，决定有多少集群在同一时间不可用，而一些仍然可用。使用`U`代表不可用的数量。如果不确定，最好选择1。
如果允许负载均衡在集群故障发生时将通信引导到任何区域，那么至少需要较大的`R`或`U + 1`集群。若非如此（例如，若要在集群故障发生时确保所有用户的低延迟），则需要`R * (U + 1)`集群(在每一个`R`区域里都有`U + 1`)。在任何情况下，尝试将每个集群放在不同的区域中。
最后，如果你的集群需求超过一个Kubernetes集群推荐的最大节点数，那么你可能需要更多的集群。Kubernetes1.3版本支持多达1000个节点的集群规模。
{{% /capture %}}
{{% capture whatsnext %}}
* 进一步学习[联邦提案](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)。
* 集群联邦参考该[配置指导](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)。
* 查看[Kubecon2016浅谈联邦](https://www.youtube.com/watch?v=pq9lbkmxpS8)
{{% /capture %}}
content/cn/docs/concepts/cluster-administration/proxies.md
+64
View File
@@ -0,0 +1,64 @@
---
title: Kubernetes 中的代理
content_template: templates/concept
---
{{% capture overview %}}
本文讲述了 Kubernetes 中所使用的代理。
{{% /capture %}}
{{% capture body %}}
## 代理
用户在使用 Kubernetes 的过程中可能遇到几种不同的代理（proxy）：
1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)：
- 运行在用户的桌面或 pod 中
- 从本机地址到 Kubernetes apiserver 的代理
- 客户端到代理使用 HTTP 协议
- 代理到 apiserver 使用 HTTPS 协议
- 指向 apiserver
- 添加认证头信息
1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)：
- 是一个建立在 apiserver 内部的“堡垒”
- 将集群外部的用户与群集 IP 相连接，这些IP是无法通过其他方式访问的
- 运行在 apiserver 进程内
- 客户端到代理使用 HTTPS 协议 (如果配置 apiserver 使用 HTTP 协议，则使用 HTTP 协议)
- 通过可用信息进行选择，代理到目的地可能使用 HTTP 或 HTTPS 协议
- 可以用来访问 Node、 Pod 或 Service
- 当用来访问 Service 时，会进行负载均衡
1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)：
- 在每个节点上运行
- 代理 UDP 和 TCP
- 不支持 HTTP
- 提供负载均衡能力
- 只用来访问 Service
1. apiserver 之前的代理/负载均衡器：
- 在不同集群间的存在形式和实现不同 (如 nginx)
- 位于所有客户端和一个或多个 apiserver 之间
- 存在多个 apiserver 时，扮演负载均衡器的角色
1. 外部服务的云负载均衡器：
- 由一些云供应商提供 (如AWS ELB、 Google Cloud Load Balancer)
- Kubernetes service 为 `LoadBalancer` 类型时自动创建
- 只使用 UDP/TCP 协议
- 不同云供应商的实现不同。
Kubernetes 用户通常只需要关心前两种类型的代理，集群管理员通常需要确保后面几种类型的代理设置正确。
## 请求重定向
代理已经取代重定向功能，重定向已被弃用。
{{% /capture %}}
content/cn/docs/concepts/cluster-administration/sysctl-cluster.md
+100
View File
@@ -0,0 +1,100 @@
---
approvers:
- sttts
title: Kubernetes集群中使用Sysctls
---
{{< toc >}}
这篇文章描述了如何在Kubernetes集群中使用Sysctls。
## 什么是Sysctl？
在Linux中，Sysctl接口允许管理员在内核运行时修改内核参数。这些可用参数都存在于虚拟进程文件系统中的`/proc/sys/`目录。这些内核参数作用于各种子系统中，例如：
- 内核 (通用前缀：`kernel.`)
- 网络 (通用前缀：`net.`)
- 虚拟内存 (通用前缀：`vm.`)
- 设备专用 (通用前缀：`dev.`)
- 更多子系统描述见 [Kernel docs](https://www.kernel.org/doc/Documentation/sysctl/README).
获取所有参数列表，可运行
```
$ sudo sysctl -a
```
## 命名空间级vs.节点级Sysctls
在今天的Linux内核系统中有一些Sysctls是 _命名空间级_ 的。这意味着他们在同节点的不同pod间是可配置成独立的。在kubernetes里，命名空间级是Sysctls的一个必要条件，以使其在一个pod语境里易于理解。
以下列出了Sysctls中已知的 _命名空间级_ ：
- `kernel.shm*`（内核中共享内存相关参数），
- `kernel.msg*`（内核中SystemV消息队列相关参数），
- `kernel.sem`（内核中信号量参数），
- `fs.mqueue.*`（内核中POSIX消息队列相关参数），
- `net.*`（内核中网络配置项相关参数）。
Sysctls中非命名空间级的被称为 _节点级_ ，其必须由集群管理员手动设置，要么通过节点的底层Linux分布方式(例如，通过 `/etc/sysctls.conf`)，亦或在特权容器中使用Daemonset。
**注意**: 这是很好的做法，考虑在一个集群里给有特殊sysctl的节点设置为 _污点_ ，并且给他们安排仅需要这些sysctl设置的pods。 建议采用Kubernetes [_污点和容点_
特征](/docs/user-guide/kubectl/{{< param "version" >}}/#taint) 来实现。
## 安全的 vs. 不安全的 Sysctls
Sysctls被分为 _安全的_ 和 _不安全的_ sysctls。同一节点上的pods间除了适当命名空间命名一个 _安全的_ sysctl，还必须适当的 _隔离_ 。 这意味着给一个pod设置一个 _安全的_ sysctl
- 不能对相同节点上其他pod产生任何影响
- 不能对节点的健康造成损害
- 不能在pod资源限制以外获取更多的CPU和内存资源
目前看来，大多数的 _命名空间级_ sysctls 不一定被认为是 _安全的_ 。
在Kubernetes 1.4版本中，以下sysctls提供了 _安全的_ 配置：
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
- `net.ipv4.tcp_syncookies`.
该列表在未来的Kubernetes版本里还会继续扩充，当kubelet提供更好的隔离机制时。
所有 _安全的_ sysctls 都是默认启用的。
所有 _不安全的_ sysctls 默认是关闭的，且必须通过每个节点基础上的集群管理手动开启。禁用不安全的sysctls的Pods将会被计划，但不会启动。
**警告**: 由于他们的本质是 _不安全的_ ，使用 _不安全的_ sysctls是自担风险的，并且会导致严重的问题，例如容器的错误行为，资源短缺或者是一个节点的完全破损。
## 使能不安全的Sysctls
牢记上面的警告， 在非常特殊的情况下，例如高性能指标或是实时应用程序优化，集群管理员可以允许 _不安全的_
sysctls。 _不安全的_ sysctls 会打上kubelet标识，在逐节点的基础上被启用，例如：
```shell
$ kubelet --experimental-allowed-unsafe-sysctls 'kernel.msg*,net.ipv4.route.min_pmtu' ...
```
只有 _命名空间级_ sysctls 可以使用该方法启用。
## 给Pod配置Sysctls
在Kubernetes 1.4版本中，sysctl特性是一个alpha API。因此，sysctls被设置为在pods上使用注释。它们适用于同一个pod上的所有容器。
这里列举了一个例子， _安全的_ 和 _不安全的_ sysctls使用不同的注释:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
annotations:
security.alpha.kubernetes.io/sysctls: kernel.shm_rmid_forced=1
security.alpha.kubernetes.io/unsafe-sysctls: net.ipv4.route.min_pmtu=1000,kernel.msgmax=1 2 3
spec:
...
```
**注意**: 包含以上规定的 _不安全的_ sysctls的一个Pod， 将无法启动任何不能使这两个 _不安全的_ sysctls明确的节点。 推荐
_节点级_ sysctls使用 [_容点和污点_
特征](/docs/user-guide/kubectl/v1.6/#taint) or [taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
来将这些pods分配到正确的nodes上。