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

Rename Google Container Engine to Google Kubernetes Engine

Browse Source
This commit is contained in:
Andrew Chen
2017-11-13 12:02:31 -08:00
parent bfc642a066
commit 4f38e0aefd
39 changed files with 88 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files
cn/docs/admin/cluster-large.md
+1 -1
View File
@@ -56,7 +56,7 @@ title: 创建大规模集群
### 管理节点和组件的规格
在 GCE/GKE 或 AWS平台中， `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上，用户需要手动配置。 作为参考，GCE使用的规格为：
在 GCE/Google Kubernetes Engine 或 AWS平台中， `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上，用户需要手动配置。 作为参考，GCE使用的规格为：
* 1-5 节点： n1-standard-1
* 6-10 节点： n1-standard-2
cn/docs/admin/high-availability/index.md
+1 -1
View File
@@ -9,7 +9,7 @@ title: 构建高可用集群
本文描述了如何构建一个高可用（high-availability, HA）的Kubernetes集群。这是一个非常高级的主题。
对于仅希望使用Kubernetes进行试验的用户，推荐使用更简单的配置工具进行搭建，例如：
[Minikube](/docs/getting-started-guides/minikube/)，或者尝试使用[Google Container Engine](https://cloud.google.com/container-engine/) 来运行Kubernetes。
[Minikube](/docs/getting-started-guides/minikube/)，或者尝试使用[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 来运行Kubernetes。
此外，当前在我们的端到端（e2e）测试环境中，没有对Kubernetes高可用的支持进行连续测试。我们将会增加这个连续测试项，但当前对单节点master的安装测试得更加严格。
cn/docs/concepts/architecture/master-node-communication.md
+1 -1
View File
@@ -68,4 +68,4 @@ Master 组件通过非安全（没有加密或认证）端口和集群的 apiser
### SSH 隧道
[Google Container Engine](https://cloud.google.com/container-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。
[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。
cn/docs/concepts/containers/images.md
+6 -6
View File
@@ -31,7 +31,7 @@ title: 镜像
- 使用Google Container Registry
- 每个集群分别配置
- 在Google Compute Engine 或者 Google Container Engine上自动配置
- 在Google Compute Engine 或者 Google Kubernetes Engine上自动配置
- 所有的pod都能读取项目的私有仓库
- 使用 AWS EC2 Container Registry (ECR)
- 使用IAM角色和策略来控制对ECR仓库的访问
@@ -51,7 +51,7 @@ title: 镜像
### 使用 Google Container Registry
Kuberetes运行在Google Compute Engine (GCE)时原生支持[Google ContainerRegistry (GCR)]
(https://cloud.google.com/tools/container-registry/)。如果kubernetes集群运行在GCE
或者Google Container Engine (GKE)上，使用镜像全名(e.g. gcr.io/my_project/image:tag)即可。
或者Google Kubernetes Engine 上，使用镜像全名(e.g. gcr.io/my_project/image:tag)即可。
集群中的所有pod都会有读取这个仓库中镜像的权限。
@@ -112,7 +112,7 @@ Kubelet会获取并且定期刷新ECR的凭证。它需要以下权限
### 配置Nodes对私有仓库认证
**注意：** 如果在Google Container Engine (GKE)上运行集群，每个节点上都会有`.dockercfg`文件，它包含对Google Container Registry的凭证。
**注意：** 如果在Google Kubernetes Engine 上运行集群，每个节点上都会有`.dockercfg`文件，它包含对Google Container Registry的凭证。
不需要使用以下方法。
**注意：** 如果在AWS EC2上运行集群且准备使用EC2 Container Registry (ECR)，每个node上的kubelet会管理和更新ECR的登录凭证。不需要使用以下方法。
@@ -175,7 +175,7 @@ $ kubectl describe pods/private-image-test-1 | grep "Failed"
### 提前拉取镜像
**注意：** 如果在Google Container Engine (GKE)上运行集群，每个节点上都会有`.dockercfg`文件，它包含对Google Container Registry的凭证。
**注意：** 如果在Google Kubernetes Engine 上运行集群，每个节点上都会有`.dockercfg`文件，它包含对Google Container Registry的凭证。
不需要使用以下方法。
**注意：** 该方法适用于能够对节点进行配置的情况。该方法在GCE及在其它能自动配置节点的云平台上并不适合。
@@ -193,7 +193,7 @@ $ kubectl describe pods/private-image-test-1 | grep "Failed"
### 在pod上指定ImagePullSecrets
**注意:** GKE,GCE及其他自动创建node的云平台上，推荐使用本方法。
**注意:** Google Kubernetes Engine,GCE及其他自动创建node的云平台上，推荐使用本方法。
Kuberentes支持在pod中指定仓库密钥。
@@ -262,7 +262,7 @@ spec:
也可以在[serviceAccount](/docs/user-guide/service-accounts) 资源中设置imagePullSecrets自动设置`imagePullSecrets`
`imagePullSecrets`可以和每个node上的`.docker/config.json`一起使用，他们将共同生效。本方法在Google Container Engine (GKE)
`imagePullSecrets`可以和每个node上的`.docker/config.json`一起使用，他们将共同生效。本方法在Google Kubernetes Engine
也能正常工作。
### 使用场景
cn/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
+2 -2
View File
@@ -21,7 +21,7 @@ title: 配置你的云平台防火墙
当以 `spec.type: LoadBalancer` 使用服务时，你可以使用 `spec.loadBalancerSourceRanges` 指定允许访问负载均衡的 IP 段。
这个字段采用 CIDR 的 IP 段，Kubernetes 会使用这个段配置防火墙。支持这个功能的平台目前有 Google Compute Engine，Google Container Engine 和 AWS。
这个字段采用 CIDR 的 IP 段，Kubernetes 会使用这个段配置防火墙。支持这个功能的平台目前有 Google Compute Engine，Google Kubernetes Engine 和 AWS。
如果云服务商不支持这个功能，这个字段会被忽略。
@@ -112,7 +112,7 @@ $ gcloud compute firewall-rules create my-rule --allow=tcp:<port>
因此，在 Google Compute Engine 或者 Google Container Engine 上开启防火墙端口时请
因此，在 Google Compute Engine 或者 Google Kubernetes Engine 上开启防火墙端口时请
小心。你可能无意间把其他服务也暴露给了 internet。
cn/docs/tasks/administer-cluster/cluster-management.md
+7 -7
View File
@@ -57,13 +57,13 @@ cluster/gce/upgrade.sh release/stable
```
### 升级 Google Container Engine (GKE) 集群
### 升级 Google Kubernetes Engine 集群
Google Container Engine 自动升级 master 组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。它还负责 master 运行的操作系统和其它组件。
Google Kubernetes Engine 自动升级 master 组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。它还负责 master 运行的操作系统和其它组件。
节点升级过程由用户初始化，[GKE 文档](https://cloud.google.com/container-engine/docs/clusters/upgrade) 里有相关描述。
节点升级过程由用户初始化，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade) 里有相关描述。
### 在其他平台上升级集群
@@ -80,7 +80,7 @@ Google Container Engine 自动升级 master 组件（例如 `kube-apiserver`、`
## 调整集群大小
如果集群资源短缺，您可以轻松的添加更多的机器，如果集群正运行在[节点自注册模式](/docs/admin/node/#self-registration-of-nodes)下的话。如果正在使用的是 GCE 或者 GKE，这将通过调整管理节点的实例组的大小完成。在 [Google Cloud Console page](https://console.developers.google.com) 的 `Compute > Compute Engine > Instance groups > your group > Edit group` 下修改实例数量或使用 gcloud CLI 都可以完成这个任务。
如果集群资源短缺，您可以轻松的添加更多的机器，如果集群正运行在[节点自注册模式](/docs/admin/node/#self-registration-of-nodes)下的话。如果正在使用的是 GCE 或者 Google Kubernetes Engine，这将通过调整管理节点的实例组的大小完成。在 [Google Cloud Console page](https://console.developers.google.com) 的 `Compute > Compute Engine > Instance groups > your group > Edit group` 下修改实例数量或使用 gcloud CLI 都可以完成这个任务。
```shell
gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE
@@ -96,7 +96,7 @@ gcloud compute instance-groups managed resize kubernetes-minion-group --size 42
### 集群自动伸缩
如果正在使用 GCE 或者 GKE，您可以配置您的集群，使其能够基于 pod 需求自动重新调整大小。
如果正在使用 GCE 或者 Google Kubernetes Engine，您可以配置您的集群，使其能够基于 pod 需求自动重新调整大小。
如 [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/) 所述，用户可以控制预留多少 CPU 和内存来分配给 pod。这个信息被 Kubernetes scheduler 用来寻找一个运行 pod 的地方。如果没有一个节点有足够的空闲容量（或者不能满足其他 pod 的需求），这个 pod 就需要等待某些 pod 结束，或者一个新的节点被添加。
@@ -108,7 +108,7 @@ gcloud compute instance-groups managed resize kubernetes-minion-group --size 42
如果发现在一段延时时间内（默认10分钟，将来有可能改变）某些节点不再需要，集群 autoscaler 也会缩小集群。
集群 autoscaler 在每一个实例组（GCE）或节点池（GKE）上配置。
集群 autoscaler 在每一个实例组（GCE）或节点池（Google Kubernetes Engine）上配置。
如果您使用 GCE，那么您可以在使用 kube-up.sh 脚本创建集群的时候启用它。要想配置集群 autoscaler，您需要设置三个环境变量：
@@ -126,7 +126,7 @@ KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_
```
在 GKE 上，您可以在创建、更新集群或创建一个特别的节点池（您希望自动伸缩的）时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling` `--min-nodes` 和 `--max-nodes` 来配置集群 autoscaler。
在 Google Kubernetes Engine 上，您可以在创建、更新集群或创建一个特别的节点池（您希望自动伸缩的）时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling` `--min-nodes` 和 `--max-nodes` 来配置集群 autoscaler。
示例：
cn/docs/tutorials/services/source-ip.md
+1 -1
View File
@@ -229,7 +229,7 @@ client_address=10.240.0.5
```
然而，如果你的集群运行在 GKE/GCE 上，设置 `service.spec.externalTrafficPolicy` 字段值为 `Local` 可以强制使*没有* endpoints 的节点把他们自己从负载均衡流量的可选节点名单中删除。这是通过故意使它们健康检查失败达到的。
然而，如果你的集群运行在 Google Kubernetes Engine/GCE 上，设置 `service.spec.externalTrafficPolicy` 字段值为 `Local` 可以强制使*没有* endpoints 的节点把他们自己从负载均衡流量的可选节点名单中删除。这是通过故意使它们健康检查失败达到的。
形象的：