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
docs/admin/cluster-large.md
+1 -1
View File
@@ -56,7 +56,7 @@ When creating a cluster, existing salt scripts:
### Size of master and master components
On GCE/GKE and AWS, `kube-up` automatically configures the proper VM size for your master depending on the number of nodes
On GCE/Google Kubernetes Engine, and AWS, `kube-up` automatically configures the proper VM size for your master depending on the number of nodes
in your cluster. On other providers, you will need to configure it manually. For reference, the sizes we use on GCE are
* 1-5 nodes: n1-standard-1
docs/admin/federation/index.md
+2 -2
View File
@@ -154,7 +154,7 @@ to be able to talk to federation apiserver. You can view this by running
`kubectl config view`.
Note: Dynamic provisioning for persistent volume currently works only on
AWS, GKE, and GCE. However, you can edit the created `Deployments` to suit
AWS, Google Kubernetes Engine, and GCE. However, you can edit the created `Deployments` to suit
your needs, if required.
## Registering Kubernetes clusters with federation
@@ -378,7 +378,7 @@ to be able to talk to federation apiserver. You can view this by running
Note: `federation-up.sh` creates the federation-apiserver pod with an etcd
container that is backed by a persistent volume, so as to persist data. This
currently works only on AWS, GKE, and GCE. You can edit
currently works only on AWS, Google Kubernetes Engine, and GCE. You can edit
`federation/manifests/federation-apiserver-deployment.yaml` to suit your needs,
if required.
docs/admin/high-availability/index.md
+1 -1
View File
@@ -7,7 +7,7 @@ title: Building High-Availability Clusters
This document describes how to build a high-availability (HA) Kubernetes cluster. This is a fairly advanced topic.
Users who merely want to experiment with Kubernetes are encouraged to use configurations that are simpler to set up such
as [Minikube](/docs/getting-started-guides/minikube/)
or try [Google Container Engine](https://cloud.google.com/container-engine/) for hosted Kubernetes.
or try [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted Kubernetes.
Also, at this time high availability support for Kubernetes is not continuously tested in our end-to-end (e2e) testing. We will
be working to add this continuous testing, but for now the single-node master installations are more heavily tested.
docs/concepts/architecture/master-node-communication.md
+1 -1
View File
@@ -99,7 +99,7 @@ public networks.
### SSH Tunnels
[Google Container Engine](https://cloud.google.com/container-engine/docs/) uses
[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) uses
SSH tunnels to protect the Master -> Cluster communication paths. In this
configuration, the apiserver initiates an SSH tunnel to each node in the
cluster (connecting to the ssh server listening on port 22) and passes all
docs/concepts/cluster-administration/cluster-administration-overview.md
+1 -1
View File
@@ -19,7 +19,7 @@ Before choosing a guide, here are some considerations:
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- **If you are designing for high-availability**, learn about configuring [clusters in multiple zones](/docs/concepts/cluster-administration/federation/).
- Will you be using **a hosted Kubernetes cluster**, such as [Google Container Engine (GKE)](https://cloud.google.com/container-engine/), or **hosting your own cluster**?
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. One option for custom networking is [*OpenVSwitch GRE/VxLAN networking*](/docs/admin/ovs-networking/), which uses OpenVSwitch to set up networking between pods across Kubernetes nodes.
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
docs/concepts/containers/images.md
+8 -10
View File
@@ -39,7 +39,7 @@ Credentials can be provided in several ways:
- Using Google Container Registry
- Per-cluster
- automatically configured on Google Compute Engine or Google Container Engine
- automatically configured on Google Compute Engine or Google Kubernetes Engine
- all pods can read the project's private registry
- Using AWS EC2 Container Registry (ECR)
- use IAM roles and policies to control access to ECR repositories
@@ -60,7 +60,7 @@ Each option is described in more detail below.
Kubernetes has native support for the [Google Container
Registry (GCR)](https://cloud.google.com/tools/container-registry/), when running on Google Compute
Engine (GCE). If you are running your cluster on GCE or Google Container Engine (GKE), simply
Engine (GCE). If you are running your cluster on GCE or Google Kubernetes Engine, simply
use the full image name (e.g. gcr.io/my_project/image:tag).
All pods in a cluster will have read access to images in this registry.
@@ -128,8 +128,7 @@ Once you have those variables filled in you can
### Configuring Nodes to Authenticate to a Private Repository
**Note:** if you are running on Google Container Engine (GKE), there will already be a `.dockercfg` on each node
with credentials for Google Container Registry. You cannot use this approach.
**Note:** if you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
**Note:** if you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
manage and update the ECR login credentials. You cannot use this approach.
@@ -199,8 +198,7 @@ It should also work for a private registry such as quay.io, but that has not bee
### Pre-pulling Images
**Note:** if you are running on Google Container Engine (GKE), there will already be a `.dockercfg` on each node
with credentials for Google Container Registry. You cannot use this approach.
**Note:** if you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
**Note:** this approach is suitable if you can control node configuration. It
will not work reliably on GCE, and any other cloud provider that does automatic
@@ -219,7 +217,7 @@ All pods will have read access to any pre-pulled images.
### Specifying ImagePullSecrets on a Pod
**Note:** This approach is currently the recommended approach for GKE, GCE, and any cloud-providers
**Note:** This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
where node creation is automated.
Kubernetes supports specifying registry keys on a pod.
@@ -295,7 +293,7 @@ However, setting of this field can be automated by setting the imagePullSecrets
in a [serviceAccount](/docs/user-guide/service-accounts) resource.
You can use this in conjunction with a per-node `.docker/config.json`. The credentials
will be merged. This approach will work on Google Container Engine (GKE).
will be merged. This approach will work on Google Kubernetes Engine.
### Use Cases
@@ -305,7 +303,7 @@ common use cases and suggested solutions.
1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images.
- Use public images on the Docker hub.
- No configuration required.
- On GCE/GKE, a local mirror is automatically used for improved speed and availability.
- On GCE/Google Kubernetes Engine, a local mirror is automatically used for improved speed and availability.
1. Cluster running some proprietary images which should be hidden to those outside the company, but
visible to all cluster users.
- Use a hosted private [Docker registry](https://docs.docker.com/registry/).
@@ -313,7 +311,7 @@ common use cases and suggested solutions.
- Manually configure .docker/config.json on each node as described above.
- Or, run an internal private registry behind your firewall with open read access.
- No Kubernetes configuration is required.
- Or, when on GCE/GKE, use the project's Google Container Registry.
- Or, when on GCE/Google Kubernetes Engine, use the project's Google Container Registry.
- It will work better with cluster autoscaling than manual node configuration.
- Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
1. Cluster with a proprietary images, a few of which require stricter access control.
docs/concepts/overview/what-is-kubernetes.md
+1 -1
View File
@@ -53,7 +53,7 @@ Summary of container benefits:
* **Environmental consistency across development, testing, and production**:
Runs the same on a laptop as it does in the cloud.
* **Cloud and OS distribution portability**:
Runs on Ubuntu, RHEL, CoreOS, on-prem, Google Container Engine, and anywhere else.
Runs on Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine, and anywhere else.
* **Application-centric management**:
Raises the level of abstraction from running an OS on virtual hardware to run an application on an OS using logical resources.
* **Loosely coupled, distributed, elastic, liberated [micro-services](https://martinfowler.com/articles/microservices.html)**:
docs/concepts/services-networking/ingress.md
+2 -2
View File
@@ -46,9 +46,9 @@ It can be configured to give services externally-reachable URLs, load balance tr
Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect.
GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://git.k8s.io/ingress#running-multiple-ingress-controllers) and [here](https://git.k8s.io/ingress-gce/BETA_LIMITATIONS.md#disabling-glbc).
GCE/Google Kubernetes Engine deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://git.k8s.io/ingress#running-multiple-ingress-controllers) and [here](https://git.k8s.io/ingress-gce/BETA_LIMITATIONS.md#disabling-glbc).
Make sure you review the [beta limitations](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://git.k8s.io/ingress-nginx/README.md) as a pod.
Make sure you review the [beta limitations](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations) of this controller. In environments other than GCE/Google Kubernetes Engine, you need to [deploy a controller](https://git.k8s.io/ingress-nginx/README.md) as a pod.
## The Ingress Resource
docs/concepts/services-networking/service.md
+1 -1
View File
@@ -482,7 +482,7 @@ metadata:
[...]
```
Use `cloud.google.com/load-balancer-type: "internal"` for masters with version 1.7.0 to 1.7.3.
For more information, see the [docs](https://cloud.google.com/container-engine/docs/internal-load-balancing).
For more information, see the [docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing).
{% endcapture %}
{% capture aws %}
docs/getting-started-guides/binary_release.md
+1 -1
View File
@@ -50,7 +50,7 @@ export KUBERNETES_PROVIDER=YOUR_PROVIDER; curl -sS https://get.k8s.io | bash
Possible values for `YOUR_PROVIDER` include:
* `gce` - Google Compute Engine [default]
* `gke` - Google Container Engine
* `gke` - Google Kubernetes Engine
* `aws` - Amazon EC2
* `azure` - Microsoft Azure
* `vagrant` - Vagrant (on local virtual machines)
docs/getting-started-guides/gce.md
+1 -1
View File
@@ -14,7 +14,7 @@ The example below creates a Kubernetes cluster with 4 worker node Virtual Machin
### Before you start
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Container Engine](https://cloud.google.com/container-engine/) (GKE) for hosted cluster installation and management.
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing) for hosted cluster installation and management.
For an easy way to experiment with the Kubernetes development environment, [click here](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/kubernetes/kubernetes&page=editor&open_in_editor=README.md)
to open a Google Cloud Shell with an auto-cloned copy of the Kubernetes source repo.
docs/getting-started-guides/stackpoint.md
+4 -7
View File
@@ -76,9 +76,9 @@ For information on using and managing a Kubernetes cluster on GCE, [consult the
## GKE
## Google Kubernetes Engine
To create a Kubernetes cluster on GKE, you will need the Service Account JSON Data from Google.
To create a Kubernetes cluster on Google Kubernetes Engine, you will need the Service Account JSON Data from Google.
### Choose a Provider
@@ -86,7 +86,7 @@ Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitt
Click **+ADD A CLUSTER NOW**.
Click to select Google Container Engine (GKE).
Click to select Google Kubernetes Engine.
### Configure Your Provider
@@ -103,10 +103,7 @@ Choose any extra options you may want to include with your cluster, then click *
You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
For information on using and managing a Kubernetes cluster on GKE, consult [the official documentation](/docs/home/).
For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/docs/home/).
## DigitalOcean
docs/setup/independent/create-cluster-kubeadm.md
+1 -1
View File
@@ -30,7 +30,7 @@ system (e.g. Puppet) that you have to integrate with.
If you are not constrained, there are other higher-level tools built to give you
complete clusters:
* On GCE, [Google Container Engine](https://cloud.google.com/container-engine/)
* On GCE, [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)
gives you one-click Kubernetes clusters.
* On Microsoft Azure, [Azure Container Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)
gives you managed Kubernetes clusters as a service.
docs/setup/pick-right-solution.md
+3 -3
View File
@@ -37,7 +37,7 @@ a Kubernetes cluster from scratch.
# Hosted Solutions
* [Google Container Engine](https://cloud.google.com/container-engine) offers managed Kubernetes clusters.
* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) offers managed Kubernetes clusters.
* [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/) can easily deploy Kubernetes clusters.
@@ -142,7 +142,7 @@ Below is a table of all of the solutions listed above.
IaaS Provider | Config. Mgmt. | OS | Networking | Docs | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ----------------------------
any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))
GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | Commercial
Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial
Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial
AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial
KUBE2GO.io | | multi-support | multi-support | [docs](https://kube2go.io) | Commercial
@@ -211,5 +211,5 @@ any | any | any | any | [docs](http://docs.
[1]: https://gist.github.com/erictune/4cabc010906afbcc5061
<!-- Vagrant conformance test result -->
[2]: https://gist.github.com/derekwaynecarr/505e56036cdf010bf6b6
<!-- GKE conformance test result -->
<!-- Google Kubernetes Engine conformance test result -->
[3]: https://gist.github.com/erictune/2f39b22f72565365e59b
docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
+2 -2
View File
@@ -14,7 +14,7 @@ well as any provider specific details that may be necessary.
When using a Service with `spec.type: LoadBalancer`, you can specify the IP ranges that are allowed to access the load balancer
by using `spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions.
This feature is currently supported on Google Compute Engine, Google Container Engine and AWS. This field will be ignored if the cloud provider does not support the feature.
This feature is currently supported on Google Compute Engine, Google Kubernetes Engine and AWS. This field will be ignored if the cloud provider does not support the feature.
Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal IPs.
This will not allow clients from outside of your Kubernetes cluster to access the load balancer.
@@ -89,7 +89,7 @@ Consider:
the VM's external IP address.
Consequently, please be careful when opening firewalls in Google Compute Engine
or Google Container Engine. You may accidentally be exposing other services to
or Google Kubernetes Engine. You may accidentally be exposing other services to
the wilds of the internet.
This will be fixed in an upcoming release of Kubernetes.
docs/tasks/access-application-cluster/create-external-load-balancer.md
+1 -1
View File
@@ -104,7 +104,7 @@ The IP address is listed next to `LoadBalancer Ingress`.
Due to the implementation of this feature, the source IP seen in the target
container will *not be the original source IP* of the client. To enable
preservation of the client IP, the following fields can be configured in the
service spec (supported in GCE/GKE environments):
service spec (supported in GCE/Google Kubernetes Engine environments):
* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route
external traffic to node-local or cluster-wide endpoints. There are two available
docs/tasks/administer-cluster/cluster-management.md
+7 -8
View File
@@ -49,12 +49,11 @@ Alternatively, to upgrade your entire cluster to the latest stable release:
cluster/gce/upgrade.sh release/stable
```
### Upgrading Google Container Engine (GKE) clusters
### Upgrading Google Kubernetes Engine clusters
Google Container Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest
version. It also handles upgrading the operating system and other components that the master runs on.
Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.
The node upgrade process is user-initiated and is described in the [GKE documentation.](https://cloud.google.com/container-engine/docs/clusters/upgrade)
The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine//docs/clusters/upgrade).
### Upgrading clusters on other platforms
@@ -68,7 +67,7 @@ Different providers, and tools, will manage upgrades differently. It is recomme
## Resizing a cluster
If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes).
If you're using GCE or GKE it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
If you're using GCE or Google Kubernetes Engine it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
```shell
gcloud compute instance-groups managed resize kubernetes-minion-group --size=42 --zone=$ZONE
@@ -80,7 +79,7 @@ In other environments you may need to configure the machine yourself and tell th
### Cluster autoscaling
If you are using GCE or GKE, you can configure your cluster so that it is automatically rescaled based on
If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
pod needs.
As described in [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/), users can reserve how much CPU and memory is allocated to pods.
@@ -94,7 +93,7 @@ to the other in the cluster, would help. If yes, then it resizes the cluster to
Cluster autoscaler also scales down the cluster if it notices that one or more nodes are not needed anymore for
an extended period of time (10min but it may change in the future).
Cluster autoscaler is configured per instance group (GCE) or node pool (GKE).
Cluster autoscaler is configured per instance group (GCE) or node pool (Google Kubernetes Engine).
If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
To configure cluster autoscaler you have to set three environment variables:
@@ -109,7 +108,7 @@ Example:
KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
```
On GKE you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
On Google Kubernetes Engine you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
(which you want to be autoscaled) by passing flags `--enable-autoscaling` `--min-nodes` and `--max-nodes`
to the corresponding `gcloud` commands.
docs/tasks/administer-cluster/ip-masq-agent.md
+2 -2
View File
@@ -28,7 +28,7 @@ The ip-masq-agent configures iptables rules to hide a pod's IP address behind th
* **Link Local**
A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
The ip-masq-agent configures iptables rules to handle masquerading node/pod IP addresses when sending traffic to destinations outside the cluster node's IP and the Cluster IP range. This essentially hides pod IP addresses behind the cluster node's IP address. In some environments, traffic to "external" addresses must come from a known machine address. For example, in Google Cloud, any traffic to the internet must come from a VM's IP. When containers are used, as in GKE, the Pod IP will be rejected for egress. To avoid this, we must hide the Pod IP behind the VM's own IP address - generally known as "masquerade". By default, the agent is configured to treat the three private IP ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918) as non-masquerade [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). These ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The agent will also treat link-local (169.254.0.0/16) as a non-masquerade CIDR by default. The agent is configured to reload its configuration from the location */etc/config/ip-masq-agent* every 60 seconds, which is also configurable.
The ip-masq-agent configures iptables rules to handle masquerading node/pod IP addresses when sending traffic to destinations outside the cluster node's IP and the Cluster IP range. This essentially hides pod IP addresses behind the cluster node's IP address. In some environments, traffic to "external" addresses must come from a known machine address. For example, in Google Cloud, any traffic to the internet must come from a VM's IP. When containers are used, as in Google Kubernetes Engine, the Pod IP will be rejected for egress. To avoid this, we must hide the Pod IP behind the VM's own IP address - generally known as "masquerade". By default, the agent is configured to treat the three private IP ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918) as non-masquerade [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). These ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The agent will also treat link-local (169.254.0.0/16) as a non-masquerade CIDR by default. The agent is configured to reload its configuration from the location */etc/config/ip-masq-agent* every 60 seconds, which is also configurable.
![masq/non-masq example](/images/docs/ip-masq.png)
@@ -50,7 +50,7 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent:
```
By default, in GCE/GKE starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to your cluster:
By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to your cluster:
{% endcapture %}
docs/tasks/administer-federation/ingress.md
+2 -2
View File
@@ -6,7 +6,7 @@ title: Federated Ingress
This page explains how to use Kubernetes Federated Ingress to deploy
a common HTTP(S) virtual IP load balancer across a federated service running in
multiple Kubernetes clusters. As of v1.4, clusters hosted in Google
Cloud (both GKE and GCE, or both) are supported. This makes it
Cloud (both Google Kubernetes Engine and GCE, or both) are supported. This makes it
easy to deploy a service that reliably serves HTTP(S) traffic
originating from web clients around the globe on a single, static IP
address. Low network latency, high fault tolerance and easy administration are
@@ -19,7 +19,7 @@ automatically checks the health of the pods comprising the service,
and avoids sending requests to unresponsive or slow pods (or entire
unresponsive clusters).
Federated Ingress is released as an alpha feature, and supports Google Cloud Platform (GKE,
Federated Ingress is released as an alpha feature, and supports Google Cloud Platform (Google Kubernetes Engine,
GCE and hybrid scenarios involving both) in Kubernetes v1.4. Work is under way to support other cloud
providers such as AWS, and other hybrid cloud scenarios (e.g. services
spanning private on-premises as well as public cloud Kubernetes
docs/tasks/debug-application-cluster/events-stackdriver.md
+2 -2
View File
@@ -38,9 +38,9 @@ of the potential inaccuracy.
## Deployment
### Google Container Engine
### Google Kubernetes Engine
In Google Container Engine (GKE), if cloud logging is enabled, event exporter
In Google Kubernetes Engine, if cloud logging is enabled, event exporter
is deployed by default to the clusters with master running version 1.7 and
higher. To prevent disturbing your workloads, event exporter does not have
resources set and is in the best effort QOS class, which means that it will
docs/tasks/debug-application-cluster/local-debugging.md
+1 -1
View File
@@ -49,7 +49,7 @@ Running this command spawns a shell. In the shell, start your service. You can t
{% capture whatsnext %}
If you're interested in a hands-on tutorial, check out [this tutorial](https://cloud.google.com/community/tutorials/developing-services-with-k8s) that walks through locally developing the Guestbook application on Google Container Engine.
If you're interested in a hands-on tutorial, check out [this tutorial](https://cloud.google.com/community/tutorials/developing-services-with-k8s) that walks through locally developing the Guestbook application on Google Kubernetes Engine.
Telepresence has [numerous proxying options](https://www.telepresence.io/reference/methods), depending on your situation.
docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+1 -1
View File
@@ -14,7 +14,7 @@ This article describes how to set up a cluster to ingest logs into
them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
Stackdriver Logging when running on GCE. Note that Elasticsearch and Kibana
cannot be setup automatically in the Kubernetes cluster hosted on
Google Container Engine, you have to deploy it manually.
Google Kubernetes Engine, you have to deploy it manually.
To use Elasticsearch and Kibana for cluster logging, you should set the
following environment variable as shown below when creating your cluster with
docs/tasks/debug-application-cluster/logging-stackdriver.md
+4 -4
View File
@@ -22,9 +22,9 @@ and the instances are managed using a Kubernetes `DaemonSet`. The actual deploym
### Deploying to a new cluster
#### Google Container Engine
#### Google Kubernetes Engine
Stackdriver is the default logging solution for clusters deployed on Google Container Engine.
Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine.
Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out.
#### Other platforms
@@ -186,14 +186,14 @@ the messages from a particular pod.
The most important pieces of metadata are the resource type and log name.
The resource type of a container log is `container`, which is named
`GKE Containers` in the UI (even if the Kubernetes cluster is not on GKE).
`GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine).
The log name is the name of the container, so that if you have a pod with
two containers, named `container_1` and `container_2` in the spec, their logs
will have log names `container_1` and `container_2` respectively.
System components have resource type `compute`, which is named
`GCE VM Instance` in the interface. Log names for system components are fixed.
For a GKE node, every log entry from a system component has one of the following
For a Google Kubernetes Engine node, every log entry from a system component has one of the following
log names:
* docker
docs/tasks/debug-application-cluster/troubleshooting.md
+2 -2
View File
@@ -34,7 +34,7 @@ and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl
You may also find the Stack Overflow topics relevant:
* [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes)
* [Google Container Engine - GKE](http://stackoverflow.com/questions/tagged/google-container-engine)
* [Google Kubernetes Engine](http://stackoverflow.com/questions/tagged/google-container-engine)
## Help! My question isn't covered! I need help now!
@@ -67,7 +67,7 @@ these channels for localized support and info:
### Mailing List
The Kubernetes / Google Container Engine mailing list is [kubernetes-users@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-users)
The Kubernetes / Google Kubernetes Engine mailing list is [kubernetes-users@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-users)
### Bugs and Feature requests
docs/tasks/federation/set-up-cluster-federation-kubefed.md
+3 -3
View File
@@ -148,11 +148,11 @@ to program the DNS service that you are using. For example, if your
cluster is running on Google Compute Engine, you must enable the
Google Cloud DNS API for your project.
The machines in Google Container Engine (GKE) clusters are created
The machines in Google Kubernetes Engine clusters are created
without the Google Cloud DNS API scope by default. If you want to use a
GKE cluster as a Federation host, you must create it using the `gcloud`
Google Kubernetes Engine cluster as a Federation host, you must create it using the `gcloud`
command with the appropriate value in the `--scopes` field. You cannot
modify a GKE cluster directly to add this scope, but you can create a
modify a Google Kubernetes Engine cluster directly to add this scope, but you can create a
new node pool for your cluster and delete the old one. *Note that this
will cause pods in the cluster to be rescheduled.*
docs/tutorials/services/source-ip.md
+1 -1
View File
@@ -231,7 +231,7 @@ client_address=10.240.0.5
...
```
However, if you're running on GKE/GCE, setting the same `service.spec.externalTrafficPolicy`
However, if you're running on Google Kubernetes Engine/GCE, setting the same `service.spec.externalTrafficPolicy`
field to `Local` forces nodes *without* Service endpoints to remove
themselves from the list of nodes eligible for loadbalanced traffic by
deliberately failing health checks.
docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+1 -1
View File
@@ -46,7 +46,7 @@ Download the following configuration files:
MySQL and Wordpress each use a PersistentVolume to store data. While Kubernetes supports many different [types of PersistentVolumes](/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes), this tutorial covers [hostPath](/docs/concepts/storage/volumes/#hostpath).
**Note:** If you have a Kubernetes cluster running on Google Container Engine, please follow [this guide](https://cloud.google.com/container-engine/docs/tutorials/persistent-disk).
**Note:** If you have a Kubernetes cluster running on Google Kubernetes Engine, please follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).
{: .note}
### Setting up a hostPath Volume
docs/tutorials/stateless-application/expose-external-ip-address.md
+1 -1
View File
@@ -14,7 +14,7 @@ external IP address.
* Install [kubectl](/docs/tasks/tools/install-kubectl/).
* Use a cloud provider like Google Container Engine or Amazon Web Services to
* Use a cloud provider like Google Kubernetes Engine or Amazon Web Services to
create a Kubernetes cluster. This tutorial creates an
[external load balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/),
which requires a cloud provider.
docs/tutorials/stateless-application/guestbook.md
+1 -1
View File
@@ -168,7 +168,7 @@ The `redis-slave` and `redis-master` Services you applied are only accessible wi
If you want guests to be able to access your guestbook, you must configure the frontend Service to be externally visible, so a client can request the Service from outside the container cluster. Minikube can only expose Services through `NodePort`.
**Note:** Some cloud providers, like Google Compute Engine or Google Container Engine, support external load balancers. If your cloud provider supports load balancers and you want to use it, simply delete or comment out `type: NodePort`, and uncomment `type: LoadBalancer`.
**Note:** Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, support external load balancers. If your cloud provider supports load balancers and you want to use it, simply delete or comment out `type: NodePort`, and uncomment `type: LoadBalancer`.
{: .note}
1. Apply the frontend Service from the following `frontend-service.yaml` file: