Merge branch 'master' into master
This commit is contained in:
Aaron.L.Xu
@@ -207,7 +207,7 @@ Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VM
|
||||
|
||||
## Cluster Features and Architecture
|
||||
|
||||
We configue the Kubernetes cluster with the following features:
|
||||
We configure the Kubernetes cluster with the following features:
|
||||
|
||||
* KubeDNS: DNS resolution and service discovery
|
||||
* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
|
||||
@@ -218,7 +218,7 @@ We configue the Kubernetes cluster with the following features:
|
||||
We use the following to create the kubernetes cluster:
|
||||
|
||||
* Kubernetes 1.1.7
|
||||
* Unbuntu 14.04
|
||||
* Ubuntu 14.04
|
||||
* Flannel 0.5.4
|
||||
* Docker 1.9.1-0~trusty
|
||||
* Etcd 2.2.2
|
||||
|
||||
@@ -57,7 +57,7 @@ kops uses DNS for discovery, both inside the cluster and so that you can reach t
|
||||
from clients.
|
||||
|
||||
kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will
|
||||
no longer get your clusters confused, you can share clusters with your colleagues unambigiously,
|
||||
no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
|
||||
and you can reach them without relying on remembering an IP address.
|
||||
|
||||
You can, and probably should, use subdomains to divide your clusters. As our example we will use
|
||||
|
||||
@@ -31,4 +31,4 @@ There are two main components to be aware of:
|
||||
- One `calico-node` Pod runs on each node in your cluster, and enforces network policy on the traffic to/from Pods on that machine by configuring iptables.
|
||||
- The `calico-policy-controller` Pod reads policy and label information from the Kubernetes API and configures Calico appropriately.
|
||||
|
||||
Once your cluster is running, you can follow the [NetworkPolicy gettting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
|
||||
Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
|
||||
|
||||
@@ -8,4 +8,4 @@ The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for K
|
||||
|
||||
This component automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces, and configures `iptables` rules to allow or block traffic as directed by the policies.
|
||||
|
||||
Once you have installed the Weave Net Addon you can follow the [NetworkPolicy gettting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
|
||||
Once you have installed the Weave Net Addon you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
|
||||
|
||||
@@ -163,7 +163,7 @@ balancer. Specifically:
|
||||
Configure your service with the NodePort option. For example, this
|
||||
service uses the NodePort option. All Kubernetes nodes will listen on
|
||||
a port and forward network traffic to any pods in the service. In this
|
||||
case, Kubernets will choose a random port, but it will be the same
|
||||
case, Kubernetes will choose a random port, but it will be the same
|
||||
port on all nodes.
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -69,7 +69,7 @@ accomplished in two ways:
|
||||
|
||||
- **Using an overlay network**
|
||||
- An overlay network obscures the underlying network architecture from the
|
||||
pod network through traffic encapsulation (e.g vxlan).
|
||||
pod network through traffic encapsulation (e.g. vxlan).
|
||||
- Encapsulation reduces performance, though exactly how much depends on your solution.
|
||||
- **Without an overlay network**
|
||||
- Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses.
|
||||
@@ -180,7 +180,7 @@ we recommend that you run these as containers, so you need an image to be built.
|
||||
You have several choices for Kubernetes images:
|
||||
|
||||
- Use images hosted on Google Container Registry (GCR):
|
||||
- e.g `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest
|
||||
- e.g. `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest
|
||||
release tag, which can be found on the [latest releases page](https://github.com/kubernetes/kubernetes/releases/latest).
|
||||
- Ensure $TAG is the same tag as the release tag you are using for kubelet and kube-proxy.
|
||||
- The [hyperkube](https://releases.k8s.io/{{page.githubbranch}}/cmd/hyperkube) binary is an all in one binary
|
||||
|
||||
@@ -93,7 +93,7 @@ Note that each controller can host multiple Kubernetes clusters in a given cloud
|
||||
|
||||
## Launch a Kubernetes cluster
|
||||
|
||||
The following command will deploy the intial 12-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to, but
|
||||
The following command will deploy the initial 12-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to, but
|
||||
|
||||
```shell
|
||||
juju deploy canonical-kubernetes
|
||||
@@ -206,7 +206,7 @@ Congratulations, you've now set up a Kubernetes cluster!
|
||||
Want larger Kubernetes nodes? It is easy to request different sizes of cloud
|
||||
resources from Juju by using **constraints**. You can increase the amount of
|
||||
CPU or memory (RAM) in any of the systems requested by Juju. This allows you
|
||||
to fine tune th Kubernetes cluster to fit your workload. Use flags on the
|
||||
to fine tune the Kubernetes cluster to fit your workload. Use flags on the
|
||||
bootstrap command or as a separate `juju constraints` command. Look to the
|
||||
[Juju documentation for machine](https://jujucharms.com/docs/2.0/charms-constraints)
|
||||
details.
|
||||
|
||||
@@ -122,7 +122,7 @@ through `FLANNEL_BACKEND` and `FLANNEL_OTHER_NET_CONFIG`, as explained in `clust
|
||||
The default setting for `ADMISSION_CONTROL` is right for the latest
|
||||
release of Kubernetes, but if you choose an earlier release then you
|
||||
might want a different setting. See
|
||||
[the admisson control doc](http://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use)
|
||||
[the admission control doc](http://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use)
|
||||
for the recommended settings for various releases.
|
||||
|
||||
**Note:** When deploying, master needs to be connected to the Internet to download the necessary files.
|
||||
|
||||
Reference in New Issue
Block a user