From d10f643e20f10010b010186d6b9e46978812429e Mon Sep 17 00:00:00 2001 From: Sam Foo Date: Mon, 5 Feb 2018 12:15:26 -0500 Subject: [PATCH] Remove duplicate words (#7243) * Remove duplicate words * Remove generated-reference change --- docs/admin/authorization/rbac.md | 2 +- docs/concepts/api-extension/custom-resources.md | 2 +- docs/concepts/overview/extending.md | 2 +- .../object-management-kubectl/declarative-config.md | 2 +- docs/concepts/storage/dynamic-provisioning.md | 2 +- docs/concepts/storage/persistent-volumes.md | 2 +- docs/concepts/storage/volumes.md | 2 +- docs/concepts/workloads/controllers/replicaset.md | 2 +- .../setup-tools/kubeadm/implementation-details.md | 12 ++++++------ docs/setup/independent/high-availability.md | 2 +- .../configure-persistent-volume-storage.md | 2 +- .../configure-projected-volume-storage.md | 2 +- docs/tutorials/stateful-application/cassandra.md | 2 +- .../users/application-developer/foundational.md | 4 ++-- 14 files changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/admin/authorization/rbac.md b/docs/admin/authorization/rbac.md index 83649663b6..d171694b07 100644 --- a/docs/admin/authorization/rbac.md +++ b/docs/admin/authorization/rbac.md @@ -789,7 +789,7 @@ In order from most secure to least secure, the approaches are: If you want all applications in a namespace to have a role, no matter what service account they use, you can grant a role to the service account group for that namespace. - For example, grant read-only permission within "my-namespace" to to all service accounts in that namespace: + For example, grant read-only permission within "my-namespace" to all service accounts in that namespace: ```shell kubectl create rolebinding serviceaccounts-view \ diff --git a/docs/concepts/api-extension/custom-resources.md b/docs/concepts/api-extension/custom-resources.md index 15fa657559..8fecaf0c4a 100644 --- a/docs/concepts/api-extension/custom-resources.md +++ b/docs/concepts/api-extension/custom-resources.md @@ -159,7 +159,7 @@ Aggregated APIs offer more advanced API features and customization of other feat | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | No | Yes | | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes | | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | No, but can get some of the same effects with Initializers or Finalizers (requires programming) | Yes | -| Subresources | {::nomarkdown}{:/} | No but planned | Yes, any Subresource | +| Subresources | {::nomarkdown}{:/} | No but planned | Yes, any Subresource | | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes | | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes | | OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | No but planned | Yes | diff --git a/docs/concepts/overview/extending.md b/docs/concepts/overview/extending.md index d13e732f0e..4d27dee318 100644 --- a/docs/concepts/overview/extending.md +++ b/docs/concepts/overview/extending.md @@ -181,7 +181,7 @@ Different networking fabrics can be supported via node-level [Network Plugins](/ ### Scheduler Extensions The scheduler is a special type of controller that watches pods, and assigns -pods to nodes. The default scheduler can be be replaced entirely, while +pods to nodes. The default scheduler can be replaced entirely, while continuing to use other Kubernetes components, or [multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) can run at the same time. diff --git a/docs/concepts/overview/object-management-kubectl/declarative-config.md b/docs/concepts/overview/object-management-kubectl/declarative-config.md index 7bf37d22b5..facfb49094 100644 --- a/docs/concepts/overview/object-management-kubectl/declarative-config.md +++ b/docs/concepts/overview/object-management-kubectl/declarative-config.md @@ -517,7 +517,7 @@ Primitive fields are replaced or cleared. ### Merging changes to map fields -Fields that represent maps are merged by comparing each of the subfields or elements of of the map: +Fields that represent maps are merged by comparing each of the subfields or elements of the map: **Note:** '-' is used for "not applicable" because the value is not used. diff --git a/docs/concepts/storage/dynamic-provisioning.md b/docs/concepts/storage/dynamic-provisioning.md index e6bee64a26..3370dc9da8 100644 --- a/docs/concepts/storage/dynamic-provisioning.md +++ b/docs/concepts/storage/dynamic-provisioning.md @@ -30,7 +30,7 @@ that provisioner when provisioning. A cluster administrator can define and expose multiple flavors of storage (from the same or different storage systems) within a cluster, each with a custom set of parameters. This design also ensures that end users don’t have to worry -about the the complexity and nuances of how storage is provisioned, but still +about the complexity and nuances of how storage is provisioned, but still have the ability to select from multiple storage options. More information on storage classes can be found diff --git a/docs/concepts/storage/persistent-volumes.md b/docs/concepts/storage/persistent-volumes.md index 9091f39277..4256900d8d 100644 --- a/docs/concepts/storage/persistent-volumes.md +++ b/docs/concepts/storage/persistent-volumes.md @@ -74,7 +74,7 @@ Once a user has a claim and that claim is bound, the bound PV belongs to the use {% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %} The purpose of the PVC protection is to ensure that PVCs in active use by a pod are not removed from the system as this may result in data loss. -**Note:** PVC is in active use by a pod when the the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`. +**Note:** PVC is in active use by a pod when the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`. {: .note} When the [PVC protection alpha feature](/docs/tasks/administer-cluster/pvc-protection/) is enabled, if a user deletes a PVC in active use by a pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any pods. diff --git a/docs/concepts/storage/volumes.md b/docs/concepts/storage/volumes.md index b32b053f32..3c49b03672 100644 --- a/docs/concepts/storage/volumes.md +++ b/docs/concepts/storage/volumes.md @@ -239,7 +239,7 @@ A CSI persistent volume has the following fields for users to specify: name can have '`.`', '`-`', '`_`' or digits in it. - `volumeHandle`: A string value that uniquely identify the volume name returned from the CSI volume plugin's `CreateVolume` call. The volume handle is then - used in all subsequent calls to the the volume driver for referencing the volume. + used in all subsequent calls to the volume driver for referencing the volume. - `readOnly`: An optional boolean value indicating whether the volume is to be published as read only. Default is false. diff --git a/docs/concepts/workloads/controllers/replicaset.md b/docs/concepts/workloads/controllers/replicaset.md index 8bbc6e08d4..750346e7b0 100644 --- a/docs/concepts/workloads/controllers/replicaset.md +++ b/docs/concepts/workloads/controllers/replicaset.md @@ -181,7 +181,7 @@ from service for debugging, data recovery, etc. Pods that are removed in this wa ### Scaling a ReplicaSet A ReplicaSet can be easily scaled up or down by simply updating the `.spec.replicas` field. The ReplicaSet controller -ensures that that a desired number of pods with a matching label selector are available and operational. +ensures that a desired number of pods with a matching label selector are available and operational. ### ReplicaSet as an Horizontal Pod Autoscaler Target diff --git a/docs/reference/setup-tools/kubeadm/implementation-details.md b/docs/reference/setup-tools/kubeadm/implementation-details.md index 12cd673859..6a57e131b8 100644 --- a/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -59,7 +59,7 @@ in a majority of cases, and the most intuitive location; other constants paths a - `apiserver.crt`, `apiserver.key` for the API server certificate - `apiserver-kubelet-client.crt`, `apiserver-kubelet-client.key` for the client certificate used by the API server to connect to the kubelets securely - `sa.pub`, `sa.key` for the key used by the controller manager when signing ServiceAccount - - `front-proxy-ca.crt`, `front-proxy-ca.key` for the the front proxy certificate authority + - `front-proxy-ca.crt`, `front-proxy-ca.key` for the front proxy certificate authority - `front-proxy-client.crt`, `front-proxy-client.key` for the front proxy client ## kubeadm init workflow internal design @@ -200,7 +200,7 @@ Static Pod manifest share a set of common properties: - Leader election is enabled for both the controller-manager and the scheduler - Controller-manager and the scheduler will reference kubeconfig files with their respective, unique identities - All static Pods gets any extra flags specified by the user as described in [passing custom arguments to control plane components](kubeadm-init.md/#custom-args) -- All static Pods gets any extra extra Volumes specified by the user (Host path) +- All static Pods gets any extra Volumes specified by the user (Host path) Please note that: @@ -401,7 +401,7 @@ RBAC role `system:node-bootstrapper`. #### Setup auto approval for new bootstrap tokens -Kubeadm ensures that the Boostrap Token will get its CSR request automatically approved by the the csrapprover controller. +Kubeadm ensures that the Boostrap Token will get its CSR request automatically approved by the csrapprover controller. This is implemented by creating ClusterRoleBinding named `kubeadm:node-autoapprove-bootstrap` between the `system:bootstrappers:kubeadm:default-node-token` group and the default role `system:certificates.k8s.io:certificatesigningrequests:nodeclient`. @@ -412,7 +412,7 @@ POST permission to `/apis/certificates.k8s.io/certificatesigningrequests/nodecli #### Setup nodes certificate rotation with auto approval Kubeadm ensures that certificate rotation is enabled for nodes, and that new certificate request for nodes will get its CSR request -automatically approved by the the csrapprover controller. +automatically approved by the csrapprover controller. This is implemented by creating ClusterRoleBinding named `kubeadm:node-autoapprove-certificate-rotation` between the `system:nodes` group and the default role `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`. @@ -570,7 +570,7 @@ If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: 1. Read the kubelet base configuration from the `kubelet-base-config-v1.9` ConfigMap in the `kube-system` namespace using the Bootstrap Token credentials, and write it to disk as kubelet init configuration file `/var/lib/kubelet/config/init/kubelet` 2. As soon as kubelet starts with the Node's own credential (`/etc/kubernetes/kubelet.conf`), update current node configuration - specifying that the the source for the node/kubelet configuration is the above ConfigMap. + specifying that the source for the node/kubelet configuration is the above ConfigMap. Please note that: @@ -578,4 +578,4 @@ Please note that: {% endcapture %} -{% include templates/concept.md %} \ No newline at end of file +{% include templates/concept.md %} diff --git a/docs/setup/independent/high-availability.md b/docs/setup/independent/high-availability.md index 32e7878500..29fd93d2a7 100644 --- a/docs/setup/independent/high-availability.md +++ b/docs/setup/independent/high-availability.md @@ -152,7 +152,7 @@ This should result in `client.pem` and `client-key.pem` being created. In order to copy certs between machines, you must enable SSH access for `scp`. -1. First, open new new tabs in your shell for `etcd1` and `etcd2`. Ensure you are SSHed into all three machines and then run the following (it will be a lot quicker if you use tmux syncing - to do this in iTerm enter `cmd+shift+i`): +1. First, open new tabs in your shell for `etcd1` and `etcd2`. Ensure you are SSHed into all three machines and then run the following (it will be a lot quicker if you use tmux syncing - to do this in iTerm enter `cmd+shift+i`): ```shell export PEER_NAME=$(hostname) diff --git a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 6542e93955..70119be3c0 100644 --- a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -63,7 +63,7 @@ Here is the configuration file for the hostPath PersistentVolume: {% include code.html language="yaml" file="task-pv-volume.yaml" ghlink="/docs/tasks/configure-pod-container/task-pv-volume.yaml" %} The configuration file specifies that the volume is at `/mnt/data` on the -the cluster's Node. The configuration also specifies a size of 10 gibibytes and +cluster's Node. The configuration also specifies a size of 10 gibibytes and an access mode of `ReadWriteOnce`, which means the volume can be mounted as read-write by a single Node. It defines the [StorageClass name](/docs/concepts/storage/persistent-volumes/#class) `manual` for the PersistentVolume, which will be used to bind diff --git a/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index 9b86a48323..3920c2f239 100644 --- a/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -57,7 +57,7 @@ the Pod: {% capture whatsnext %} * Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes. -* Read the the [all-in-one volume](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/node/all-in-one-volume.md) design document. +* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/node/all-in-one-volume.md) design document. {% endcapture %} {% include templates/task.md %} diff --git a/docs/tutorials/stateful-application/cassandra.md b/docs/tutorials/stateful-application/cassandra.md index 9e7c753b91..30eebc7a31 100644 --- a/docs/tutorials/stateful-application/cassandra.md +++ b/docs/tutorials/stateful-application/cassandra.md @@ -143,7 +143,7 @@ The StatefulSet manifest, included below, creates a Cassandra ring that consists UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo ## Modifying the Cassandra StatefulSet -Use `kubectl edit` to modify the size of of a Cassandra StatefulSet. +Use `kubectl edit` to modify the size of a Cassandra StatefulSet. 1. Run the following command: diff --git a/docs/user-journeys/users/application-developer/foundational.md b/docs/user-journeys/users/application-developer/foundational.md index f0eff01342..0ae6e4565e 100644 --- a/docs/user-journeys/users/application-developer/foundational.md +++ b/docs/user-journeys/users/application-developer/foundational.md @@ -94,7 +94,7 @@ You can also specify custom information about your Kubernetes API objects by att You'll also want to think about storage. Kubernetes provides different types of storage API objects for different storage needs: -* **{% glossary_tooltip text="Volumes" term_id="volume" %}** - Let you define storage for your cluster that is tied to the lifecycle of a Pod. It is therefore more persistent than container storage. Learn [how to configure volume storage](/docs/tasks/configure-pod-container/configure-volume-storage/){:target="_blank"}, or [read more about about volume storage](/docs/concepts/storage/volumes/){:target="_blank"}. +* **{% glossary_tooltip text="Volumes" term_id="volume" %}** - Let you define storage for your cluster that is tied to the lifecycle of a Pod. It is therefore more persistent than container storage. Learn [how to configure volume storage](/docs/tasks/configure-pod-container/configure-volume-storage/){:target="_blank"}, or [read more about volume storage](/docs/concepts/storage/volumes/){:target="_blank"}. * **{% glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" %}** and **{% glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" %}** - Let you define storage at the cluster level. Typically a cluster operator defines the PersistentVolume objects for the cluster, and cluster users (application developers, you) define the PersistentVolumeClaim objects that your application requires. Learn [how to set up persistent storage for your cluster](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/){:target="_blank"} or [read more about persistent volumes](/docs/concepts/storage/persistent-volumes/){:target="_blank"}. @@ -156,7 +156,7 @@ If you're not running Kubernetes or a similar automated system, you might find t This process can be tedious and also inconvenient, especially if (2) happens in the early hours of the morning! -**If you have Kubernetes set up, however, manual intervention is not as necessary.** The Kubernetes [control plane](/docs/concepts/overview/components/#master-components){:target="_blank"}, which runs on your cluster's master node, gracefully handles (3) and (4) on your behalf. As a a result, Kubernetes is often referred to as a *self-healing* system. +**If you have Kubernetes set up, however, manual intervention is not as necessary.** The Kubernetes [control plane](/docs/concepts/overview/components/#master-components){:target="_blank"}, which runs on your cluster's master node, gracefully handles (3) and (4) on your behalf. As a result, Kubernetes is often referred to as a *self-healing* system. There are two key parts of the control plane that facilitate this behavior: the *Kubernetes API server* and the *Controllers*.