Merge pull request #852 from gg7/scratch-improvements

"Custom Cluster from Scratch" improvements
This commit is contained in:
Kelsey Hightower
2016-08-02 23:12:06 -07:00
committed by GitHub
+20 -15
View File
@@ -111,6 +111,7 @@ be active at once. Note that you can grow the end of this range, but you
cannot move it without disrupting the services and pods that already use it.
Also, you need to pick a static IP for master node.
- Call this `MASTER_IP`.
- Open any firewalls to allow access to the apiserver ports 80 and/or 443.
- Enable ipv4 forwarding sysctl, `net.ipv4.ip_forward = 1`
@@ -184,11 +185,11 @@ For etcd, you can:
We recommend that you use the etcd version which is provided in the Kubernetes binary distribution. The Kubernetes binaries in the release
were tested extensively with this version of etcd and not with any other version.
The recommended version number can also be found as the value of `ETCD_VERSION` in `kubernetes/cluster/images/etcd/Makefile`.
The recommended version number can also be found as the value of `TAG` in `kubernetes/cluster/images/etcd/Makefile`.
The remainder of the document assumes that the image identifiers have been chosen and stored in corresponding env vars. Examples (replace with latest tags and appropriate registry):
- `HYPERKUBE_IMAGE==gcr.io/google_containers/hyperkube:$TAG`
- `HYPERKUBE_IMAGE=gcr.io/google_containers/hyperkube:$TAG`
- `ETCD_IMAGE=gcr.io/google_containers/etcd:$ETCD_VERSION`
### Security Models
@@ -213,11 +214,10 @@ You need to prepare several certs:
- The kubelets optionally need certs to identify themselves as clients of the master, and when
serving its own API over HTTPS.
Unless you plan to have a real CA generate your certs, you will need to generate a root cert and use that to sign the master, kubelet, and kubectl certs.
- see function `create-certs` in `cluster/common.sh`
- see also `cluster/saltbase/salt/generate-cert/make-ca-cert.sh` and
`cluster/saltbase/salt/generate-cert/make-cert.sh`
Unless you plan to have a real CA generate your certs, you will need
to generate a root cert and use that to sign the master, kubelet, and
kubectl certs. How to do this is described in the [authentication
documentation](/docs/admin/authentication/#creating-certificates).
You will end up with the following files (we will use these variables later on)
@@ -285,7 +285,7 @@ users:
clusters:
- name: local
cluster:
certificate-authority-data: ${CA_CERT_BASE64_ENCODED}
certificate-authority: /srv/kubernetes/ca.crt
contexts:
- context:
cluster: local
@@ -558,8 +558,10 @@ For each of these components, the steps to start them running are similar:
],
"livenessProbe": {
"httpGet": {
"path": "/healthz",
"port": 8080
"scheme": "HTTP",
"host": "127.0.0.1",
"port": 8080,
"path": "/healthz"
},
"initialDelaySeconds": 15,
"timeoutSeconds": 15
@@ -605,6 +607,7 @@ If you are following the firewall-only security approach, then use these argumen
- `--advertise-address=$MASTER_IP`
If you are using the HTTPS approach, then set:
- `--client-ca-file=/srv/kubernetes/ca.crt`
- `--token-auth-file=/srv/kubernetes/known_tokens.csv`
- `--basic-auth-file=/srv/kubernetes/basic_auth.csv`
@@ -666,9 +669,10 @@ Complete this template for the scheduler pod:
],
"livenessProbe": {
"httpGet": {
"host" : "127.0.0.1",
"path": "/healthz",
"port": 10251
"scheme": "HTTP",
"host": "127.0.0.1",
"port": 10251,
"path": "/healthz"
},
"initialDelaySeconds": 15,
"timeoutSeconds": 15
@@ -721,9 +725,10 @@ Template for controller manager pod:
],
"livenessProbe": {
"httpGet": {
"scheme": "HTTP",
"host": "127.0.0.1",
"path": "/healthz",
"port": 10252
"port": 10252,
"path": "/healthz"
},
"initialDelaySeconds": 15,
"timeoutSeconds": 15