Rename Google Container Engine to Google Kubernetes Engine

2017-11-13 12:02:31 -08:00
parent bfc642a066
commit 4f38e0aefd
39 changed files with 88 additions and 94 deletions
@@ -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.
@@ -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
@@ -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.

@@ -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 %}

@@ -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
@@ -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
@@ -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.

@@ -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
@@ -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
@@ -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

@@ -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.*