Official 1.14 Release Docs (#13174)
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)
* Added documentation about Poseidon-Firmament scheduler
* Fixed some style issues.
* Udpated the document as per the review comments.
* Fixed some typos and updated the document
* Updated the document as per the review comments.
* Document timeout attribute for kms-plugin. (#12158)
See 72540.
* Official documentation on Poseidon/Firmament, a new multi-scheduler (#12343)
* Removed the old version of the Poseidon documentation. Incorrect location.
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S (#12069)
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)
* Added documentation about Poseidon-Firmament scheduler
* Fixed some style issues.
* Udpated the document as per the review comments.
* Fixed some typos and updated the document
* Updated the document as per the review comments.
* Updated the document as per review comments. Added config details.
* Updated the document as per the latest review comments. Fixed nits
* Made changes as per latest suggestions.
* Some more changes added.
* Updated as per suggestions.
* Changed the release process section.
* SIG Docs edits
Small edits to match style guidelines.
* add plus to feature state
* capitalization
* revert feature state shortcode
since this is a Kubernetes extension, not a direct feature, it shouldn't use the regular feature state tagging.
(cherry picked from commit 7730c1540b)
* Remove initializers from doc. It will be removed in 1.14 (#12331)
* kubeadm: Document CRI auto detection functionality (#12462)
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
* Minor doc change for GAing Pod DNS Config (#12514)
* Graduate ExpandInUsePersistentVolumes feature to beta (#10574)
* Rename 2018-11-07-grpc-load-balancing-with-linkerd.md.md file (#12594)
* Add dynamic percentage of node scoring to user docs (#12235)
* Add dynamic percentage of node scoring to user docs
* addressed review comments
* delete special symbol (#12445)
* Update documentation for VolumeSubpathEnvExpansion (#11843)
* Update documentation for VolumeSubpathEnvExpansion
* Address comments - improve descriptions
* Graduate Pod Priority and Preemption to GA (#12428)
* Added Instana links to the documentation (#12977)
* Added link to the Instana Kubernetes integration
* Added Instana link for services section
Added Instana and a link to the Kubernetes integration to the analytics services section and broadened the scope to APM, monitoring and analytics.
* Oxford comma /flex
* More Oxford commas, because they matter
* Update kubectl plugins to stable (#12847)
* documentation for CSI topology beta (#12889)
* Document changes to default RBAC discovery ClusterRole(Binding)s (#12888)
* Document changes to default RBAC discovery ClusterRole(Binding)s
Documentation for https://github.com/kubernetes/enhancements/issues/789 and https://github.com/kubernetes/kubernetes/pull/73807
* documentation review feedback
* CSI raw block to beta (#12931)
* Change incorrect string raw to block (#12926)
Fixes #12925
* Update documentation on node OS/arch labels (#12976)
These labels have been promoted to GA:
https://github.com/kubernetes/enhancements/issues/793
* local pv GA doc updates (#12915)
* Publish CRD OpenAPI Documentation (#12910)
* add documentation for CustomResourcePublishOpenAPI
* address comments
fix links, ordered lists, style and typo
* kubeadm: add document for upgrading from 1.13 to 1.14 (single CP and HA) (#13189)
* kubeadm: add document for upgrading from 1.13 to 1.14
- remove doc for upgrading 1.10 -> 1.11
* kubeadm: apply amends to upgrade-1.14 doc
* kubeadm: apply amends to upgrade-1.14 doc (part2)
* kubeadm: apply amends to upgrade-1.14 doc (part3)
* kubeadm: add note about "upgrade node experimental-control-plane"
+ add comment about `upgrade plan`
* kubeadm: add missing "You should see output similar to this"
* fix bullet indentation (#13214)
* mark PodReadinessGate GA (#12800)
* Update RuntimeClass documentation for beta (#13043)
* Update RuntimeClass documentation for beta
* Update feature gate & add upgrade section
* formatting fixes
* Highlight upgrade action required
* Address feedback
* CSI ephemeral volume alpha documentation (#10934)
* update kubectl documentation (#12867)
* update kubectl documentation
* add document for Secret/ConfigMap generators
* replace `kubectl create -f` by `kubectl apply -f`
* Add page for kustomization support in kubectl
* fix spelling errors and address comments
* Documentation for Windows GMSA feature (#12936)
* Documentation for Windows GMSA feature
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Enhancements to GMSA docs
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Fix links
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Fix GMSA link
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add GMSA feature flag in feature flag list
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Relocate GMSA to container configuration
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add example for container spec
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Remove changes in Windows index
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Update configure-gmsa.md
* Update configure-gmsa.md
* Update configure-gmsa.md
* Update configure-gmsa.md
* Rearrange the steps into two sections and other edits
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Fix links
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add reference to script to generate GMSA YAMLs
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Some more clarifications for GMSA
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* HugePages graduated to GA (#13004)
* HugePages graduated to GA
* fixing nit for build
* Docs for node PID limiting (https://github.com/kubernetes/kubernetes/pull/73651) (#12932)
* kubeadm: update the reference documentation for 1.14 (#12911)
* kubeadm: update list of generated files for 1.14
NOTE: PLACEHOLDERS! these files are generated by SIG Docs each
release, but we need them to pass the k/website PR CI.
- add join_phase* (new sub phases of join)
- add init_phase_upload-certs.md (new upload certs phase for init)
- remove alpha-preflight (now both init and join have this)
* kubeadm: update reference docs includes for 1.14
- remove includes from alpha.md
- add upload-certs to init-phase.md
- add join-phase.md and it's phases
* kubeadm: update the editorial content of join and init
- cleanup master->control-plane node
- add some notes about phases and join
- remove table about pre-pulling images
- remove outdated info about self-hosting
* kubeadm: update target release for v1alpha3 removal
1.14 -> 1.15
* kubeadm: copy edits for 1.14 reference docs (part1)
* kubeadm: use "shell" for code blocks
* kubeadm: update the 1.14 HA guide (#13191)
* kubeadm: update the 1.14 HA guide
* kubeadm: try to fix note/caution indent in HA page
* kubeadm: fix missing sudo and minor amends in HA doc
* kubeadm: apply latest amends to the HA doc for 1.14
* fixed a few missed merge conflicts
* Admission Webhook new features doc (#12938)
- kubernetes/kubernetes#74998
- kubernetes/kubernetes#74477
- kubernetes/kubernetes#74562
* Clarifications and fixes in GMSA doc (#13226)
* Clarifications and fixes in GMSA doc
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Update configure-gmsa.md
* Reformat to align headings and pre-reqs better
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Reformat to align headings and pre-reqs better
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Reformat to fix bullets
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Reword application of sample gmsa
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Update configure-gmsa.md
* Address feedback to use active voice
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Address feedback to use active voice
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* RunAsGroup documentation for Progressing this to Beta (#12297)
* start serverside-apply documentation (#13077)
* start serverside-apply documentation
* add more concept info on server side apply
* Update api concepts
* Update api-concepts.md
* fix style issues
* Document CSI update (#12928)
* Document CSI update
* Finish CSI documentation
Also fix mistake with ExpandInUsePersistentVolumes documented as beta
* Overall docs for CSI Migration feature (#12935)
* Placeholder docs for CSI Migration feature
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Address CR comments and update feature gates
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add mappings for CSI plugins
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add sections for AWS and GCE PD migration
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Add docs for Cinder and CSI Migration info
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Clarify scope to volumes with file system
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Change the format of EBS and Cinder CSI Migration sections to follow the GCE template
Signed-off-by: Deep Debroy <ddebroy@docker.com>
* Windows documentation updates for 1.14 (#12929)
* Updated the note to indicate doc work for 1.14
* first attempt at md export from gdoc
* simplifyig
* big attempt
* moving DRAFT windows content to PR for review
* moving content to PR in markdown for review
* updated note tags
* Delete windows-contributing.md
deleting this file as it is already ported to the github contributor guide
* fixed formatting in intro and cluster setup guide
* updating formatting for running containers guide
* rejiggered end of troubleshooting
* fixed minor typos
* Clarified the windows binary download step
* Update _index.md
making updates based on feedback
* Update _index.md
updating ovn-kubernetes docs
* Update _index.md
* Update _index.md
* updating relative docs links
updating all the links to be relative links to /docs
* Update _index.md
* Update _index.md
updates for windows services and ovn-kubernetes
* formatted for correct step numbering
* fix typos
* Update _index.md
updates for flannel PR in troubleshooting
* Update _index.md
* Update _index.md
updating a few sections like roadmap, services, troubleshooting/filing tickets
* Update _index.md
* Update _index.md
* Update _index.md
* Fixed a few whitespace issues
* Update _index.md
* Update _index.md
* Update _index.md
* add section on upgrading CoreDNS (#12909)
* documentation for kubelet resource metrics endpoint (#12934)
* windows docs updates for 1.14 (#13279)
* Delete sample-l2bridge-wincni-config.json
this file is not used anywhere
* Update _index.md
* Update _index.md
* Update _index.md
* Update _index.md
* Update _index.md
* Rename content/en/docs/getting-started-guides/windows/_index.md to content/en/docs/setup/windows/_index.md
moving to new location
* Delete flannel-master-kubectl-get-ds.png
* Delete flannel-master-kubeclt-get-pods.png
* Delete windows-docker-error.png
* Add files via upload
* Rename _index.md to add-windows-nodes.md
* Create _index.md
* Update _index.md
* Update add-windows-nodes.md
* Update add-windows-nodes.md
* Create user-guide-windows-nodes.md
* Create user-guide-windows-containers.md
* Update and rename add-windows-nodes.md to intro-windows-nodes.md
* Update user-guide-windows-containers.md
* Rename intro-windows-nodes.md to intro-windows-in-kubernetes.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-containers.md
* Update user-guide-windows-containers.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-containers.md
* Update _index.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
fixing the pause image
* Update intro-windows-in-kubernetes.md
changing tables from html to MD
* Update user-guide-windows-nodes.md
converting tables from HTML to MD
* Update intro-windows-in-kubernetes.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-nodes.md
* Update user-guide-windows-nodes.md
updating the numbering , even though it messes up the notes a little bit. Jim will file a ticket to follow up
* Update user-guide-windows-nodes.md
* update to windows docs for 1.14 (#13322)
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update intro-windows-in-kubernetes.md
* Update user-guide-windows-containers.md
* Update user-guide-windows-nodes.md
* Update intro-windows-in-kubernetes.md (#13344)
* server side apply followup (#13321)
* change some parts of serverside apply docs in response to comments
* fix typos and wording
* Update config.toml (#13365)
This commit is contained in:
committed by
Kubernetes Prow Robot
parent
28dd4d5154
commit
851ef58fa8
@@ -0,0 +1,758 @@
|
||||
---
|
||||
title: Declarative Management of Kubernetes Objects Using Kustomize
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
[Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool
|
||||
to customize Kubernetes objects
|
||||
through a [kustomization file](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/kustomization.yaml).
|
||||
Since 1.14, Kubectl also
|
||||
supports the management of Kubernetes objects using a kustomization file.
|
||||
To view Resources found in a directory containing a kustomization file, run the following command:
|
||||
```shell
|
||||
kubectl kustomize <kustomization_directory>
|
||||
```
|
||||
To apply those Resources, run `kubectl apply` with `--kustomize` or `-k` flag:
|
||||
```shell
|
||||
kubectl apply -k <kustomization_directory>
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Overview of Kustomize
|
||||
Kustomize is a tool for customizing Kubernetes configurations. It has the following features to manage application configuration files:
|
||||
|
||||
* generating resources from other sources
|
||||
* setting cross-cutting fields for resources
|
||||
* composing and customizing collections of resources
|
||||
|
||||
### Generating Resources
|
||||
ConfigMap and Secret hold config or sensitive data that are used by other Kubernetes objects, such as Pods. The source
|
||||
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.
|
||||
|
||||
|
||||
#### 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.
|
||||
```shell
|
||||
# Create a application.properties file
|
||||
cat <<EOF >application.properties
|
||||
FOO=Bar
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
configMapGenerator:
|
||||
- name: example-configmap-1
|
||||
files:
|
||||
- application.properties
|
||||
EOF
|
||||
```
|
||||
The generated ConfigMap can be checked by the following command:
|
||||
```shell
|
||||
kubectl kustomize ./
|
||||
```
|
||||
The generated ConfigMap is
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
application.properties: |
|
||||
FOO=Bar
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
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.
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
configMapGenerator:
|
||||
- name: example-configmap-2
|
||||
literals:
|
||||
- FOO=Bar
|
||||
EOF
|
||||
```
|
||||
The generated ConfigMap can be checked by the following command:
|
||||
```shell
|
||||
kubectl kustomize ./
|
||||
```
|
||||
The generated ConfigMap is
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
FOO: Bar
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: example-configmap-2-g2hdhfc6tk
|
||||
```
|
||||
|
||||
#### secretGenerator
|
||||
Secret can also be generated 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.
|
||||
```shell
|
||||
# Create a password.txt file
|
||||
cat <<EOF >./password.txt
|
||||
username=admin
|
||||
password=secret
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: example-secret-1
|
||||
files:
|
||||
- password.txt
|
||||
EOF
|
||||
```
|
||||
The generated Secret is as follows:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg==
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: example-secret-1-t2kt65hgtb
|
||||
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.
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: example-secret-2
|
||||
literals:
|
||||
- username=admin
|
||||
- password=secert
|
||||
EOF
|
||||
```
|
||||
The generated Secret is as follows:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
password: c2VjZXJ0
|
||||
username: YWRtaW4=
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: example-secret-2-t52t6g96d8
|
||||
type: Opaque
|
||||
```
|
||||
|
||||
#### 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.
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
configMapGenerator:
|
||||
- name: example-configmap-3
|
||||
literals:
|
||||
- FOO=Bar
|
||||
generatorOptions:
|
||||
disableNameSuffixHash: true
|
||||
labels:
|
||||
type: generated
|
||||
annotations:
|
||||
note: generated
|
||||
EOF
|
||||
```
|
||||
Run`kubectl kustomize ./` to view the generated ConfigMap:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
FOO: Bar
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
annotations:
|
||||
note: generated
|
||||
labels:
|
||||
type: generated
|
||||
name: example-configmap-3
|
||||
```
|
||||
|
||||
### Setting cross-cutting fields
|
||||
It is quite common to set cross-cutting fields for all Kubernetes resources in a project.
|
||||
Some use cases for setting cross-cutting fields:
|
||||
|
||||
* setting the same namespace for all Resource
|
||||
* adding the same name prefix or suffix
|
||||
* adding the same set of labels
|
||||
* adding the same set of annotations
|
||||
|
||||
Here is an example:
|
||||
```shell
|
||||
# Create a deployment.yaml
|
||||
cat <<EOF >./deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx-deployment
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
namespace: my-namespace
|
||||
namePrefix: dev-
|
||||
nameSuffix: "-001"
|
||||
commonLabels:
|
||||
app: bingo
|
||||
commonAnnotations:
|
||||
oncallPager: 800-555-1212
|
||||
resources:
|
||||
- deployment.yaml
|
||||
EOF
|
||||
```
|
||||
Run `kubectl kustomize ./` to view those fields are all set in the Deployment Resource:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
annotations:
|
||||
oncallPager: 800-555-1212
|
||||
labels:
|
||||
app: bingo
|
||||
name: dev-nginx-deployment-001
|
||||
namespace: my-namespace
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: bingo
|
||||
template:
|
||||
metadata:
|
||||
annotations:
|
||||
oncallPager: 800-555-1212
|
||||
labels:
|
||||
app: bingo
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
```
|
||||
|
||||
### Composing and Customizing Resources
|
||||
It is common to compose a set of Resources in a project and manage them inside
|
||||
the same file or directory.
|
||||
Kustomize offers composing Resources from different files and applying patches or other customization to them.
|
||||
|
||||
#### 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.
|
||||
Here is an example for an nginx application with a Deployment and a Service.
|
||||
```shell
|
||||
# Create a deployment.yaml file
|
||||
cat <<EOF > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
|
||||
# Create a service.yaml file
|
||||
cat <<EOF > service.yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-nginx
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
selector:
|
||||
run: my-nginx
|
||||
EOF
|
||||
|
||||
# Create a kustomization.yaml composing them
|
||||
cat <<EOF >./kustomization.yaml
|
||||
resources:
|
||||
- deployment.yaml
|
||||
- service.yaml
|
||||
EOF
|
||||
```
|
||||
The Resources from `kubectl kustomize ./` contains both the Deployment and the Service objects.
|
||||
|
||||
#### Customizing
|
||||
On top of Resources, one can apply different customizations by applying patches. 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.
|
||||
```shell
|
||||
# Create a deployment.yaml file
|
||||
cat <<EOF > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
|
||||
# Create a patch increase_replicas.yaml
|
||||
cat <<EOF > increase_replicas.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
replicas: 3
|
||||
EOF
|
||||
|
||||
# Create another patch set_memory.yaml
|
||||
cat <<EOF > set_memory.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: 512Mi
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
resources:
|
||||
- deployment.yaml
|
||||
patchesStrategicMerge:
|
||||
- increase_replicas.yaml
|
||||
- set_memory.yaml
|
||||
EOF
|
||||
```
|
||||
Run `kubectl kustomize ./` to view the Deployment:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
limits:
|
||||
memory: 512Mi
|
||||
name: my-nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
Not all Resources or fields support strategic merge patches. To support modifying arbitrary fields in arbitrary Resources,
|
||||
Kustomize offers applying [JSON patch](https://tools.ietf.org/html/rfc6902) through `patchesJson6902`.
|
||||
To find the correct Resource for a Json patch, the group, version, kind and name of that Resource need to be
|
||||
specified in `kustomization.yaml`. For example, increasing the replica number of a Deployment object can also be done
|
||||
through `patchesJson6902`.
|
||||
```shell
|
||||
# Create a deployment.yaml file
|
||||
cat <<EOF > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
|
||||
# Create a json patch
|
||||
cat <<EOF > patch.yaml
|
||||
- op: replace
|
||||
path: /spec/replicas
|
||||
value: 3
|
||||
EOF
|
||||
|
||||
# Create a kustomization.yaml
|
||||
cat <<EOF >./kustomization.yaml
|
||||
resources:
|
||||
- deployment.yaml
|
||||
|
||||
patchesJson6902:
|
||||
- target:
|
||||
group: apps
|
||||
version: v1
|
||||
kind: Deployment
|
||||
name: my-nginx
|
||||
path: patch.yaml
|
||||
EOF
|
||||
```
|
||||
Run `kubectl kustomize ./` to see the `replicas` field is updated:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: my-nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
In addition to patches, Kustomize also offers customizing container images or injecting field values from other objects into containers
|
||||
without creating patches. For example, you can change the image used inside containers by specifying the new image in `images` field in `kustomization.yaml`.
|
||||
```shell
|
||||
cat <<EOF > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
resources:
|
||||
- deployment.yaml
|
||||
images:
|
||||
- name: nginx
|
||||
newName: my.image.registry/nginx
|
||||
newTag: 1.4.0
|
||||
EOF
|
||||
```
|
||||
Run `kubectl kustomize ./` to see that the image being used is updated:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: my.image.registry/nginx:1.4.0
|
||||
name: my-nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
Sometimes, the application running in a Pod may need to use configuration values from other objects. For example,
|
||||
a Pod from a Deployment object need to read the corresponding Service name from Env or as a command argument.
|
||||
Since the Service name may change as `namePrefix` or `nameSuffix` is added in the `kustomization.yaml` file. It is
|
||||
not recommended to hard code the Service name in the command argument. For this usage, Kustomize can inject the Service name into containers through `vars`.
|
||||
|
||||
```shell
|
||||
# Create a deployment.yaml file
|
||||
cat <<EOF > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
command: ["start", "--host", "\$(MY_SERVICE_NAME)"]
|
||||
EOF
|
||||
|
||||
# Create a service.yaml file
|
||||
cat <<EOF > service.yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-nginx
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
selector:
|
||||
run: my-nginx
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
namePrefix: dev-
|
||||
nameSuffix: "-001"
|
||||
|
||||
resources:
|
||||
- deployment.yaml
|
||||
- service.yaml
|
||||
|
||||
vars:
|
||||
- name: MY_SERVICE_NAME
|
||||
objref:
|
||||
kind: Service
|
||||
name: my-nginx
|
||||
apiVersion: v1
|
||||
EOF
|
||||
```
|
||||
Run `kubectl kustomize ./` to see that the Service name injected into containers is `dev-my-nginx-001`:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: dev-my-nginx-001
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- command:
|
||||
- start
|
||||
- --host
|
||||
- dev-my-nginx-001
|
||||
image: nginx
|
||||
name: my-nginx
|
||||
```
|
||||
|
||||
## Bases and Overlays
|
||||
Kustomize has the concepts of **bases** and **overlays**. A **base** is a directory with a `kustomization.yaml`, which contains a
|
||||
set of resources and associated customization. A base could be either a local directory or a directory from a remote repo,
|
||||
as long as a `kustomization.yaml` is present inside. An **overlay** is a directory with a `kustomization.yaml` that refers to other
|
||||
kustomization directories as its `bases`. A **base** has no knowledge of an overlay and can be used in multiple overlays.
|
||||
An overlay may have multiple bases and it composes all resources
|
||||
from bases and may also have customization on top of them.
|
||||
|
||||
Here is an example of a base.
|
||||
```shell
|
||||
# Create a directory to hold the base
|
||||
mkdir base
|
||||
# Create a base/deployment.yaml
|
||||
cat <<EOF > base/deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
EOF
|
||||
|
||||
# Create a base/service.yaml file
|
||||
cat <<EOF > base/service.yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-nginx
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
selector:
|
||||
run: my-nginx
|
||||
EOF
|
||||
# Create a base/kustomization.yaml
|
||||
cat <<EOF > base/kustomization.yaml
|
||||
resources:
|
||||
- deployment.yaml
|
||||
- service.yaml
|
||||
```
|
||||
This base can be used in multiple overlays. You can add different `namePrefix` or other cross-cutting fields
|
||||
in different overlays. Here are two overlays using the same base.
|
||||
```shell
|
||||
mkdir dev
|
||||
cat <<EOF > dev/kustomization.yaml
|
||||
bases:
|
||||
- ../base
|
||||
namePrefix: dev-
|
||||
EOF
|
||||
|
||||
mkdir prod
|
||||
cat <<EOF > prod/kustomization.yaml
|
||||
bases:
|
||||
- ../base
|
||||
namePrefix: prod-
|
||||
EOF
|
||||
```
|
||||
|
||||
## How to apply/view/delete objects using Kustomize
|
||||
Use `--kustomize` or `-k` in `kubectl` commands to recognize Resources managed by `kustomization.yaml`.
|
||||
Note that `-k` should point to a kustomization directory, such as
|
||||
|
||||
```shell
|
||||
kubectl apply -k <kustomization directory>/
|
||||
```
|
||||
Given the following `kustomization.yaml`,
|
||||
```shell
|
||||
# Create a deployment.yaml file
|
||||
cat <<EOF > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
run: my-nginx
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
run: my-nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
|
||||
# Create a kustomization.yaml
|
||||
cat <<EOF >./kustomization.yaml
|
||||
namePrefix: dev-
|
||||
commonLabels:
|
||||
app: my-nginx
|
||||
resources:
|
||||
- deployment.yaml
|
||||
EOF
|
||||
```
|
||||
Running the following command will apply the Deployment object `dev-my-nginx`:
|
||||
```shell
|
||||
> kubectl apply -k ./
|
||||
deployment.apps/dev-my-nginx created
|
||||
```
|
||||
Running the following command will get he Deployment object `dev-my-nginx`:
|
||||
```shell
|
||||
kubectl get -k ./
|
||||
```
|
||||
or
|
||||
```shell
|
||||
kubectl describe -k ./
|
||||
```
|
||||
Running the following command will delete the Deployment object `dev-my-nginx`:
|
||||
```shell
|
||||
> kubectl delete -k ./
|
||||
deployment.apps "dev-my-nginx" deleted
|
||||
```
|
||||
|
||||
|
||||
## Kustomize Feature List
|
||||
Here is a list of all the features in Kustomize.
|
||||
|
||||
| Field | Type | Explanation |
|
||||
|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
|
||||
| namespace | string | add namespace to all resources |
|
||||
| namePrefix | string | value of this field is prepended to the names of all resources |
|
||||
| nameSuffix | string | value of this field is appended to the names of all resources |
|
||||
| commonlabels | map[string]string | labels to add to all resources and selectors |
|
||||
| commonAnnotations | map[string]string | annotations to add to all resources |
|
||||
| resources | []string | each entry in this list must resolve to an existing resource configuration file |
|
||||
| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L195) | Each entry in this list generates a ConfigMap |
|
||||
| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L201) | Each entry in this list generates a Secret |
|
||||
| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L239) | Modify behaviors of all ConfigMap and Secret generatos |
|
||||
| bases | []string | Each entry in this list should resolve to a directory containing a kustomization.yaml file |
|
||||
| patchesStrategicMerge | []string | Each entry in this list should resolve a strategic merge patch of a Kubernetes object |
|
||||
| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/patch/json6902.go#L23) | Each entry in this list should resolve to a Kubernetes object and a Json Patch |
|
||||
| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/var.go#L31) | Each entry is to capture text from one resource's field |
|
||||
| images | [][Image](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/image/image.go#L23) | Each entry is to modify the name, tags and/or digest for one image without creating patches |
|
||||
| configurations | []string | Each entry in this list should resolve to a file containing [Kustomize transformer configurations](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) |
|
||||
| crds | []string | Each entry in this list should resolve to an OpenAPI definition file for Kubernetes types |
|
||||
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
- [Kustomize](https://github.com/kubernetes-sigs/kustomize)
|
||||
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
|
||||
- [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
||||
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
{{% /capture %}}
|
||||
@@ -7,7 +7,8 @@ weight: 10
|
||||
{{% capture overview %}}
|
||||
The `kubectl` command-line tool supports several different ways to create and manage
|
||||
Kubernetes objects. This document provides an overview of the different
|
||||
approaches.
|
||||
approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for
|
||||
details of managing objects by Kubectl.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
@@ -179,6 +180,7 @@ Disadvantages compared to imperative object configuration:
|
||||
- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
|
||||
- [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
|
||||
- [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
|
||||
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
{{< comment >}}
|
||||
|
||||
@@ -42,11 +42,11 @@ Here's an example `.yaml` file that shows the required fields and object spec fo
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
One way to create a Deployment using a `.yaml` file like the one above is to use the
|
||||
[`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands#create) command
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
|
||||
in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/deployment.yaml --record
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
Reference in New Issue
Block a user