Skip to content

Commit c1dd174

Browse files
authored
Merge pull request #37844 from windsonsea/seraccen
Fix typos in /service-accounts-admin.md
2 parents 3684791 + ed98389 commit c1dd174

File tree

1 file changed

+14
-6
lines changed

1 file changed

+14
-6
lines changed

content/en/docs/reference/access-authn-authz/service-accounts-admin.md

Lines changed: 14 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -96,7 +96,7 @@ Here's an example of how that looks for a launched Pod:
9696
That manifest snippet defines a projected volume that consists of three sources. In this case,
9797
each source also represents a single path within that volume. The three sources are:
9898
99-
1. A `serviceAccountToken` source, that contains a token that the kubelet acquires from kube-apiserver
99+
1. A `serviceAccountToken` source, that contains a token that the kubelet acquires from kube-apiserver.
100100
The kubelet fetches time-bound tokens using the TokenRequest API. A token served for a TokenRequest expires
101101
either when the pod is deleted or after a defined lifespan (by default, that is 1 hour).
102102
The token is bound to the specific Pod and has the kube-apiserver as its audience.
@@ -105,7 +105,7 @@ each source also represents a single path within that volume. The three sources
105105
1. A `configMap` source. The ConfigMap contains a bundle of certificate authority data. Pods can use these
106106
certificates to make sure that they are connecting to your cluster's kube-apiserver (and not to middlebox
107107
or an accidentally misconfigured peer).
108-
1. A `downwardAPI` source that looks up the name of thhe namespace containing the Pod, and makes
108+
1. A `downwardAPI` source that looks up the name of the namespace containing the Pod, and makes
109109
that name information available to application code running inside the Pod.
110110

111111
Any container within the Pod that mounts this particular volume can access the above information.
@@ -232,14 +232,14 @@ Here's an example of how that looks for a launched Pod:
232232

233233
That manifest snippet defines a projected volume that combines information from three sources:
234234

235-
1. A `serviceAccountToken` source, that contains a token that the kubelet acquires from kube-apiserver
235+
1. A `serviceAccountToken` source, that contains a token that the kubelet acquires from kube-apiserver.
236236
The kubelet fetches time-bound tokens using the TokenRequest API. A token served for a TokenRequest expires
237237
either when the pod is deleted or after a defined lifespan (by default, that is 1 hour).
238238
The token is bound to the specific Pod and has the kube-apiserver as its audience.
239239
1. A `configMap` source. The ConfigMap contains a bundle of certificate authority data. Pods can use these
240240
certificates to make sure that they are connecting to your cluster's kube-apiserver (and not to middlebox
241241
or an accidentally misconfigured peer).
242-
1. A `downwardAPI` source. This `downwardAPI` volume makes the name of the namespace container the Pod available
242+
1. A `downwardAPI` source. This `downwardAPI` volume makes the name of the namespace containing the Pod available
243243
to application code running inside the Pod.
244244

245245
Any container within the Pod that mounts this volume can access the above information.
@@ -262,6 +262,7 @@ Here is a sample manifest for such a Secret:
262262
{{< codenew file="secret/serviceaccount/mysecretname.yaml" >}}
263263

264264
To create a Secret based on this example, run:
265+
265266
```shell
266267
kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml
267268
```
@@ -273,6 +274,7 @@ kubectl -n examplens describe secret mysecretname
273274
```
274275

275276
The output is similar to:
277+
276278
```
277279
Name: mysecretname
278280
Namespace: examplens
@@ -306,7 +308,9 @@ Otherwise, first find the Secret for the ServiceAccount.
306308
# This assumes that you already have a namespace named 'examplens'
307309
kubectl -n examplens get serviceaccount/example-automated-thing -o yaml
308310
```
311+
309312
The output is similar to:
313+
310314
```yaml
311315
apiVersion: v1
312316
kind: ServiceAccount
@@ -321,9 +325,11 @@ metadata:
321325
selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing
322326
uid: f23fd170-66f2-4697-b049-e1e266b7f835
323327
secrets:
324-
- name: example-automated-thing-token-zyxwv
328+
- name: example-automated-thing-token-zyxwv
325329
```
330+
326331
Then, delete the Secret you now know the name of:
332+
327333
```shell
328334
kubectl -n examplens delete secret/example-automated-thing-token-zyxwv
329335
```
@@ -334,6 +340,7 @@ and creates a replacement:
334340
```shell
335341
kubectl -n examplens get serviceaccount/example-automated-thing -o yaml
336342
```
343+
337344
```yaml
338345
apiVersion: v1
339346
kind: ServiceAccount
@@ -348,12 +355,13 @@ metadata:
348355
selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing
349356
uid: f23fd170-66f2-4697-b049-e1e266b7f835
350357
secrets:
351-
- name: example-automated-thing-token-4rdrh
358+
- name: example-automated-thing-token-4rdrh
352359
```
353360

354361
## Clean up
355362

356363
If you created a namespace `examplens` to experiment with, you can remove it:
364+
357365
```shell
358366
kubectl delete namespace examplens
359367
```

0 commit comments

Comments
 (0)