Merge pull request #7024 from stewart-yu/patch-1
Update certificates.md
This commit is contained in:
commit
64b5ea9208
|
@ -54,8 +54,7 @@ choices. For example, on systemd-based systems (e.g. RHEL, CentOS), you can run
|
|||
|
||||
If you are extending from a standard Kubernetes installation, the `kubelet` binary should already be present on your system. You can run
|
||||
`which kubelet` to determine if the binary is in fact installed. If it is not installed,
|
||||
you should install the [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet), the
|
||||
[kubelet init file](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kubelet/initd) and [default-kubelet](/docs/admin/high-availability/default-kubelet)
|
||||
you should install the [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet) and [default-kubelet](/docs/admin/high-availability/default-kubelet)
|
||||
scripts.
|
||||
|
||||
If you are using monit, you should also install the monit daemon (`apt-get install monit`) and the [monit-kubelet](/docs/admin/high-availability/monit-kubelet) and
|
||||
|
|
|
@ -99,7 +99,3 @@ When configuring default arguments for processes, it's best to avoid the use of
|
|||
Per pod IP configuration is provider-specific, so when making networking changes, it's important to sandbox these as all providers may not use the same mechanisms (iptables, openvswitch, etc.)
|
||||
|
||||
We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers.
|
||||
|
||||
## Further reading
|
||||
|
||||
The [cluster/saltbase](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/) tree has more details on the current SaltStack configuration.
|
||||
|
|
|
@ -8,26 +8,7 @@ title: Certificates
|
|||
## Creating Certificates
|
||||
|
||||
When using client certificate authentication, you can generate certificates
|
||||
using an existing deployment script or manually through `easyrsa`, `openssl`
|
||||
or `cfssl`.
|
||||
|
||||
### Using an Existing Deployment Script
|
||||
|
||||
**Using an existing deployment script** is implemented at
|
||||
`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`.
|
||||
|
||||
Execute this script with two parameters. The first is the IP address
|
||||
of API server. The second is a list of subject alternate names in the form `IP:<ip-address> or DNS:<dns-name>`.
|
||||
|
||||
The script generates three files: `ca.crt`, `server.crt`, and `server.key`.
|
||||
|
||||
Finally, add the following parameters into API server start parameters:
|
||||
|
||||
```
|
||||
--client-ca-file=/srv/kubernetes/ca.crt
|
||||
--tls-cert-file=/srv/kubernetes/server.crt
|
||||
--tls-private-key-file=/srv/kubernetes/server.key
|
||||
```
|
||||
manually through `easyrsa`, `openssl` or `cfssl`.
|
||||
|
||||
### easyrsa
|
||||
|
||||
|
|
|
@ -39,12 +39,8 @@ killed for this purpose.
|
|||
|
||||
## Config
|
||||
|
||||
Rescheduler should be [enabled by default as a static pod](https://git.k8s.io/kubernetes/cluster/saltbase/salt/rescheduler/rescheduler.manifest).
|
||||
It doesn't have any user facing configuration (component config) or API and can be disabled:
|
||||
|
||||
* during cluster setup by setting `ENABLE_RESCHEDULER` flag to `false`
|
||||
* on running cluster by deleting its manifest from master node
|
||||
(default path `/etc/kubernetes/manifests/rescheduler.manifest`)
|
||||
Rescheduler should be enabled by default. It doesn't have any user facing configuration (component config) or API.
|
||||
Rescheduler may also be disabled.
|
||||
|
||||
### Marking add-on as critical
|
||||
|
||||
|
|
Loading…
Reference in New Issue