docs: tweak grammar, tenses, punctuation

pull/20827/head
Jai Govindani 2020-05-07 20:55:09 +07:00 committed by GitHub
parent 0f91086750
commit e381dc787a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 13 deletions

View File

@ -46,13 +46,12 @@ Kustomize is a tool for customizing Kubernetes configurations. It has the follow
### Generating Resources ### Generating Resources
ConfigMap and Secret hold config or sensitive data that are used by other Kubernetes objects, such as Pods. The source ConfigMaps and Secrets hold configuration or sensitive data that are used by other Kubernetes objects, such as Pods. The source of truth of ConfigMaps or Secrets are usually external to a cluster, such as a `.properties` file or an SSH keyfile.
of truth of ConfigMap or Secret are usually from somewhere else, such as a `.properties` file or a ssh key file.
Kustomize has `secretGenerator` and `configMapGenerator`, which generate Secret and ConfigMap from files or literals. Kustomize has `secretGenerator` and `configMapGenerator`, which generate Secret and ConfigMap from files or literals.
#### configMapGenerator #### configMapGenerator
To generate a ConfigMap from a file, add an entry to `files` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a file content. To generate a ConfigMap from a file, add an entry to the `files` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.properties` file:
```shell ```shell
# Create a application.properties file # Create a application.properties file
@ -68,7 +67,7 @@ configMapGenerator:
EOF EOF
``` ```
The generated ConfigMap can be checked by the following command: The generated ConfigMap can be examined with the following command:
```shell ```shell
kubectl kustomize ./ kubectl kustomize ./
@ -86,7 +85,7 @@ metadata:
name: example-configmap-1-8mbdf7882g name: example-configmap-1-8mbdf7882g
``` ```
ConfigMap can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair. ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair:
```shell ```shell
cat <<EOF >./kustomization.yaml cat <<EOF >./kustomization.yaml
@ -103,7 +102,7 @@ The generated ConfigMap can be checked by the following command:
kubectl kustomize ./ kubectl kustomize ./
``` ```
The generated ConfigMap is The generated ConfigMap is:
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@ -116,7 +115,7 @@ metadata:
#### secretGenerator #### secretGenerator
You can generate Secrets from files or literal key-value pairs. To generate a Secret from a file, add an entry to `files` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a file. You can generate Secrets from files or literal key-value pairs. To generate a Secret from a file, add an entry to the `files` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a file:
```shell ```shell
# Create a password.txt file # Create a password.txt file
@ -145,7 +144,7 @@ metadata:
type: Opaque type: Opaque
``` ```
To generate a Secret from a literal key-value pair, add an entry to `literals` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a key-value pair. To generate a Secret from a literal key-value pair, add an entry to `literals` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a key-value pair:
```shell ```shell
cat <<EOF >./kustomization.yaml cat <<EOF >./kustomization.yaml
@ -172,7 +171,7 @@ type: Opaque
#### generatorOptions #### generatorOptions
The generated ConfigMaps and Secrets have a suffix appended by hashing the contents. This ensures that a new ConfigMap or Secret is generated when the content is changed. To disable the behavior of appending a suffix, one can use `generatorOptions`. Besides that, it is also possible to specify cross-cutting options for generated ConfigMaps and Secrets. The generated ConfigMaps and Secrets have a content hash suffix appended. This ensures that a new ConfigMap or Secret is generated when the contents are changed. To disable the behavior of appending a suffix, one can use `generatorOptions`. Besides that, it is also possible to specify cross-cutting options for generated ConfigMaps and Secrets.
```shell ```shell
cat <<EOF >./kustomization.yaml cat <<EOF >./kustomization.yaml
@ -209,7 +208,7 @@ metadata:
It is quite common to set cross-cutting fields for all Kubernetes resources in a project. It is quite common to set cross-cutting fields for all Kubernetes resources in a project.
Some use cases for setting cross-cutting fields: Some use cases for setting cross-cutting fields:
* setting the same namespace for all Resource * setting the same namespace for all Resources
* adding the same name prefix or suffix * adding the same name prefix or suffix
* adding the same set of labels * adding the same set of labels
* adding the same set of annotations * adding the same set of annotations
@ -289,7 +288,7 @@ Kustomize offers composing Resources from different files and applying patches o
#### Composing #### Composing
Kustomize supports composition of different resources. The `resources` field, in the `kustomization.yaml` file, defines the list of resources to include in a configuration. Set the path to a resource's configuration file in the `resources` list. Kustomize supports composition of different resources. The `resources` field, in the `kustomization.yaml` file, defines the list of resources to include in a configuration. Set the path to a resource's configuration file in the `resources` list.
Here is an example for an nginx application with a Deployment and a Service. Here is an example of an NGINX application comprised of a Deployment and a Service:
```shell ```shell
# Create a deployment.yaml file # Create a deployment.yaml file
@ -339,11 +338,11 @@ resources:
EOF EOF
``` ```
The Resources from `kubectl kustomize ./` contains both the Deployment and the Service objects. The Resources from `kubectl kustomize ./` contain both the Deployment and the Service objects.
#### Customizing #### Customizing
On top of Resources, one can apply different customizations by applying patches. Kustomize supports different patching Patches can be used to apply different customizations to Resources. Kustomize supports different patching
mechanisms through `patchesStrategicMerge` and `patchesJson6902`. `patchesStrategicMerge` is a list of file paths. Each file should be resolved to a [strategic merge patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md). The names inside the patches must match Resource names that are already loaded. Small patches that do one thing are recommended. For example, create one patch for increasing the deployment replica number and another patch for setting the memory limit. mechanisms through `patchesStrategicMerge` and `patchesJson6902`. `patchesStrategicMerge` is a list of file paths. Each file should be resolved to a [strategic merge patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md). The names inside the patches must match Resource names that are already loaded. Small patches that do one thing are recommended. For example, create one patch for increasing the deployment replica number and another patch for setting the memory limit.
```shell ```shell