mirror of
https://github.com/k3s-io/kubernetes.git
synced 2026-01-06 07:57:35 +00:00
Copy edits for typos
This commit is contained in:
@@ -35,7 +35,7 @@ Documentation for other releases can be found at
|
||||
|
||||
This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
|
||||
upgrading your cluster's
|
||||
master and worker nodes, performing node maintainence (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
|
||||
master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
|
||||
running cluster.
|
||||
|
||||
## Creating and configuring a Cluster
|
||||
@@ -132,7 +132,7 @@ For pods with a replication controller, the pod will eventually be replaced by a
|
||||
|
||||
For pods with no replication controller, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
|
||||
|
||||
Perform maintainence work on the node.
|
||||
Perform maintenance work on the node.
|
||||
|
||||
Make the node schedulable again:
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ objects.
|
||||
|
||||
Access Control: give *only* kube-apiserver read/write access to etcd. You do not
|
||||
want apiserver's etcd exposed to every node in your cluster (or worse, to the
|
||||
internet at large), because access to etcd is equivilent to root in your
|
||||
internet at large), because access to etcd is equivalent to root in your
|
||||
cluster.
|
||||
|
||||
Data Reliability: for reasonable safety, either etcd needs to be run as a
|
||||
|
||||
@@ -41,7 +41,7 @@ Documentation for other releases can be found at
|
||||
The kubelet is the primary "node agent" that runs on each
|
||||
node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object
|
||||
that describes a pod. The kubelet takes a set of PodSpecs that are provided through
|
||||
various echanisms (primarily through the apiserver) and ensures that the containers
|
||||
various mechanisms (primarily through the apiserver) and ensures that the containers
|
||||
described in those PodSpecs are running and healthy.
|
||||
|
||||
Other than from an PodSpec from the apiserver, there are three ways that a container
|
||||
|
||||
@@ -84,7 +84,7 @@ TokenController runs as part of controller-manager. It acts asynchronously. It:
|
||||
- observes serviceAccount creation and creates a corresponding Secret to allow API access.
|
||||
- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets
|
||||
- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed
|
||||
- observes secret deleteion and removes a reference from the corresponding ServiceAccount if needed
|
||||
- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed
|
||||
|
||||
#### To create additional API tokens
|
||||
|
||||
|
||||
Reference in New Issue
Block a user