Merge pull request #852 from gg7/scratch-improvements
"Custom Cluster from Scratch" improvements
This commit is contained in:
@@ -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.
|
cannot move it without disrupting the services and pods that already use it.
|
||||||
|
|
||||||
Also, you need to pick a static IP for master node.
|
Also, you need to pick a static IP for master node.
|
||||||
|
|
||||||
- Call this `MASTER_IP`.
|
- Call this `MASTER_IP`.
|
||||||
- Open any firewalls to allow access to the apiserver ports 80 and/or 443.
|
- Open any firewalls to allow access to the apiserver ports 80 and/or 443.
|
||||||
- Enable ipv4 forwarding sysctl, `net.ipv4.ip_forward = 1`
|
- 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
|
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.
|
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):
|
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`
|
- `ETCD_IMAGE=gcr.io/google_containers/etcd:$ETCD_VERSION`
|
||||||
|
|
||||||
### Security Models
|
### 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
|
- The kubelets optionally need certs to identify themselves as clients of the master, and when
|
||||||
serving its own API over HTTPS.
|
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.
|
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
|
||||||
- see function `create-certs` in `cluster/common.sh`
|
kubectl certs. How to do this is described in the [authentication
|
||||||
- see also `cluster/saltbase/salt/generate-cert/make-ca-cert.sh` and
|
documentation](/docs/admin/authentication/#creating-certificates).
|
||||||
`cluster/saltbase/salt/generate-cert/make-cert.sh`
|
|
||||||
|
|
||||||
You will end up with the following files (we will use these variables later on)
|
You will end up with the following files (we will use these variables later on)
|
||||||
|
|
||||||
@@ -285,7 +285,7 @@ users:
|
|||||||
clusters:
|
clusters:
|
||||||
- name: local
|
- name: local
|
||||||
cluster:
|
cluster:
|
||||||
certificate-authority-data: ${CA_CERT_BASE64_ENCODED}
|
certificate-authority: /srv/kubernetes/ca.crt
|
||||||
contexts:
|
contexts:
|
||||||
- context:
|
- context:
|
||||||
cluster: local
|
cluster: local
|
||||||
@@ -558,8 +558,10 @@ For each of these components, the steps to start them running are similar:
|
|||||||
],
|
],
|
||||||
"livenessProbe": {
|
"livenessProbe": {
|
||||||
"httpGet": {
|
"httpGet": {
|
||||||
"path": "/healthz",
|
"scheme": "HTTP",
|
||||||
"port": 8080
|
"host": "127.0.0.1",
|
||||||
|
"port": 8080,
|
||||||
|
"path": "/healthz"
|
||||||
},
|
},
|
||||||
"initialDelaySeconds": 15,
|
"initialDelaySeconds": 15,
|
||||||
"timeoutSeconds": 15
|
"timeoutSeconds": 15
|
||||||
@@ -605,6 +607,7 @@ If you are following the firewall-only security approach, then use these argumen
|
|||||||
- `--advertise-address=$MASTER_IP`
|
- `--advertise-address=$MASTER_IP`
|
||||||
|
|
||||||
If you are using the HTTPS approach, then set:
|
If you are using the HTTPS approach, then set:
|
||||||
|
|
||||||
- `--client-ca-file=/srv/kubernetes/ca.crt`
|
- `--client-ca-file=/srv/kubernetes/ca.crt`
|
||||||
- `--token-auth-file=/srv/kubernetes/known_tokens.csv`
|
- `--token-auth-file=/srv/kubernetes/known_tokens.csv`
|
||||||
- `--basic-auth-file=/srv/kubernetes/basic_auth.csv`
|
- `--basic-auth-file=/srv/kubernetes/basic_auth.csv`
|
||||||
@@ -666,9 +669,10 @@ Complete this template for the scheduler pod:
|
|||||||
],
|
],
|
||||||
"livenessProbe": {
|
"livenessProbe": {
|
||||||
"httpGet": {
|
"httpGet": {
|
||||||
"host" : "127.0.0.1",
|
"scheme": "HTTP",
|
||||||
"path": "/healthz",
|
"host": "127.0.0.1",
|
||||||
"port": 10251
|
"port": 10251,
|
||||||
|
"path": "/healthz"
|
||||||
},
|
},
|
||||||
"initialDelaySeconds": 15,
|
"initialDelaySeconds": 15,
|
||||||
"timeoutSeconds": 15
|
"timeoutSeconds": 15
|
||||||
@@ -721,9 +725,10 @@ Template for controller manager pod:
|
|||||||
],
|
],
|
||||||
"livenessProbe": {
|
"livenessProbe": {
|
||||||
"httpGet": {
|
"httpGet": {
|
||||||
|
"scheme": "HTTP",
|
||||||
"host": "127.0.0.1",
|
"host": "127.0.0.1",
|
||||||
"path": "/healthz",
|
"port": 10252,
|
||||||
"port": 10252
|
"path": "/healthz"
|
||||||
},
|
},
|
||||||
"initialDelaySeconds": 15,
|
"initialDelaySeconds": 15,
|
||||||
"timeoutSeconds": 15
|
"timeoutSeconds": 15
|
||||||
|
|||||||
Reference in New Issue
Block a user