Rename Google Container Engine to Google Kubernetes Engine
This commit is contained in:
Andrew Chen
@@ -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
|
||||
|
||||
@@ -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)**?
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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)**:
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
Reference in New Issue
Block a user