Update certificates.md

docs/admin/high-availability/index.md

@@ -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
+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)
-[kubelet init file](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kubelet/initd) 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

docs/admin/salt.md

@@ -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.

docs/concepts/cluster-administration/certificates.md

@@ -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`
+manually through `easyrsa`, `openssl` or `cfssl`.
-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
-```
 
 ### easyrsa
 

docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md

@@ -39,12 +39,7 @@ 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).
+Rescheduler should be enabled by default. It doesn't have any user facing configuration (component config) or API and can be disabled too.
-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`)
 
 ### Marking add-on as critical