upstream/terraform-provider-kubernetes
1
0
Fork 0
mirror of https://github.com/hashicorp/terraform-provider-kubernetes.git synced 2025-12-18 23:06:07 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 8

TF Plugin Docs - migrating to new structure (#2470)

Browse source 
Co-authored-by: Aleksandr Rybolovlev <sacha.rybolovlev@hashicorp.com>
This commit is contained in:
Sheneska Williams 2024-04-25 11:56:19 -04:00 committed by GitHub
parent 4f75983bd1
commit c746a844fd
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
420 changed files with 21993 additions and 1217 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
.changelog/2470.txt Normal file
View file

@ -0,0 +1,3 @@
```release-note:doc
Migrate legacy structure to new tfplugindocs template structure
```

2
.github/workflows/checkers-and-linters.yml vendored
View file

@ -36,5 +36,5 @@ jobs:
make vet
- name: Run linters
run: |
make website-lint
make docs-lint
make tests-lint

4
.github/workflows/markdown-link-check.yaml vendored
View file

@ -8,7 +8,7 @@ on:
branches:
- main
paths:
- 'website/docs/**'
- 'docs/**'
workflow_dispatch:
jobs:
@ -24,7 +24,7 @@ jobs:
base-branch: main
config-file: '.github/workflows/markdown.links.config.json'
file-extension: '.markdown'
folder-path: 'website/docs'
folder-path: 'docs'
use-verbose-mode: yes
use-quiet-mode: yes
max-depth: 2

8
.github/workflows/markdown.links.config.json vendored
View file

@ -18,15 +18,15 @@
},
{
"pattern": "^/docs/providers/kubernetes/",
"replacement": "file:///github/workspace/website/docs/"
"replacement": "file:///github/workspace/docs/"
},
{
"pattern": "^(getting-started).html.markdown(#.*)?$",
"replacement": "file:///github/workspace/website/docs/guides/$1.html.md$2"
"replacement": "file:///github/workspace/docs/guides/$1.html.md$2"
},
{
"pattern": "^file:///github/workspace/website/docs/guides/(.*)\\.markdown(#.*)?$",
"replacement": "file:///github/workspace/website/docs/guides/$1.md$2"
"pattern": "^file:///github/workspace/docs/guides/(.*)\\.markdown(#.*)?$",
"replacement": "file:///github/workspace/docs/guides/$1.md$2"
}
]
}

8
.markdownlinkcheck.json
View file

@ -18,15 +18,15 @@
},
{
"pattern": "^/docs/providers/kubernetes/",
"replacement": "file:///github/workspace/website/docs/"
"replacement": "file:///github/workspace/docs/"
},
{
"pattern": "^(getting-started).html.markdown(#.*)?$",
"replacement": "file:///github/workspace/website/docs/guides/$1.html.md$2"
"replacement": "file:///github/workspace/docs/guides/$1.html.md$2"
},
{
"pattern": "^file:///github/workspace/website/docs/guides/(.*)\\.markdown(#.*)?$",
"replacement": "file:///github/workspace/website/docs/guides/$1.md$2"
"pattern": "^file:///github/workspace/docs/guides/(.*)\\.markdown(#.*)?$",
"replacement": "file:///github/workspace/docs/guides/$1.md$2"
}
]
}

37
GNUmakefile
View file

@ -3,7 +3,6 @@
PROVIDER_DIR := $(abspath $(lastword $(dir $(MAKEFILE_LIST))))
TEST := "$(PROVIDER_DIR)/kubernetes"
GOFMT_FILES := $$(find $(PROVIDER_DIR) -name '*.go')
WEBSITE_REPO := github.com/hashicorp/terraform-website
PKG_NAME := kubernetes
OS_ARCH := $(shell go env GOOS)_$(shell go env GOARCH)
TF_PROV_DOCS := $(PWD)/kubernetes/test-infra/tfproviderdocs
@ -24,7 +23,7 @@ PARALLEL_RUNS?=8
default: build
all: build depscheck fmtcheck test testacc test-compile tests-lint tests-lint-fix tools vet website-lint website-lint-fix
all: build depscheck fmtcheck test testacc test-compile tests-lint tests-lint-fix tools vet docs-lint docs-lint-fix
build: fmtcheck
go install
@ -125,8 +124,8 @@ vet:
# The docker command and run options may be overridden using env variables DOCKER and DOCKER_RUN_OPTS.
# Example:
# DOCKER="podman --cgroup-manager=cgroupfs" make website-lint
# DOCKER_RUN_OPTS="--userns=keep-id" make website-lint
# DOCKER="podman --cgroup-manager=cgroupfs" make docs-lint
# DOCKER_RUN_OPTS="--userns=keep-id" make docs-lint
# This option is needed for systems using SELinux and rootless containers.
# DOCKER_VOLUME_OPTS="rw,Z"
# For more info, see https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label
@ -140,40 +139,40 @@ ifeq ($(.SHELLSTATUS),0)
DOCKER_VOLUME_OPTS="rw,Z"
endif
website-lint: tools
docs-lint: tools
@echo "==> Checking website against linters..."
@misspell -error -source=text ./website || (echo; \
@misspell -error -source=text ./docs || (echo; \
echo "Unexpected mispelling found in website files."; \
echo "To automatically fix the misspelling, run 'make website-lint-fix' and commit the changes."; \
echo "To automatically fix the misspelling, run 'make docs-lint-fix' and commit the changes."; \
exit 1)
@echo "==> Running markdownlint-cli using DOCKER='$(DOCKER)', DOCKER_RUN_OPTS='$(DOCKER_RUN_OPTS)' and DOCKER_VOLUME_OPTS='$(DOCKER_VOLUME_OPTS)'"
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(PROVIDER_DIR):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace 06kellyjac/markdownlint-cli ./website || (echo; \
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(PROVIDER_DIR):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace 06kellyjac/markdownlint-cli ./docs || (echo; \
echo "Unexpected issues found in website Markdown files."; \
echo "To apply any automatic fixes, run 'make website-lint-fix' and commit the changes."; \
echo "To apply any automatic fixes, run 'make docs-lint-fix' and commit the changes."; \
exit 1)
@echo "==> Running terrafmt diff..."
@terrafmt diff ./website --check --pattern '*.markdown' --quiet || (echo; \
@terrafmt diff ./docs --check --pattern '*.markdown' --quiet || (echo; \
echo "Unexpected differences in website HCL formatting."; \
echo "To see the full differences, run: terrafmt diff ./website --pattern '*.markdown'"; \
echo "To automatically fix the formatting, run 'make website-lint-fix' and commit the changes."; \
echo "To see the full differences, run: terrafmt diff ./docs --pattern '*.markdown'"; \
echo "To automatically fix the formatting, run 'make docs-lint-fix' and commit the changes."; \
exit 1)
@echo "==> Statically compiling provider for tfproviderdocs..."
@env CGO_ENABLED=0 GOOS=$$(go env GOOS) GOARCH=$$(go env GOARCH) go build -a -o $(TF_PROV_DOCS)/terraform-provider-kubernetes
@echo "==> Getting provider schema for tfproviderdocs..."
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(TF_PROV_DOCS):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace hashicorp/terraform:0.12.29 init
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(TF_PROV_DOCS):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace hashicorp/terraform:0.12.29 providers schema -json > $(TF_PROV_DOCS)/schema.json
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(TF_PROV_DOCS):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace hashicorp/terraform:1.8.2 init
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(TF_PROV_DOCS):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace hashicorp/terraform:1.8.2 providers schema -json > $(TF_PROV_DOCS)/schema.json
@echo "==> Running tfproviderdocs..."
@tfproviderdocs check -providers-schema-json $(TF_PROV_DOCS)/schema.json -provider-name kubernetes
@rm -f $(TF_PROV_DOCS)/schema.json $(TF_PROV_DOCS)/terraform-provider-kubernetes
@echo "==> Checking for broken links..."
@scripts/markdown-link-check.sh "$(DOCKER)" "$(DOCKER_RUN_OPTS)" "$(DOCKER_VOLUME_OPTS)" "$(PROVIDER_DIR)"
website-lint-fix: tools
docs-lint-fix: tools
@echo "==> Applying automatic website linter fixes..."
@misspell -w -source=text ./website
@misspell -w -source=text ./docs
@echo "==> Running markdownlint-cli --fix using DOCKER='$(DOCKER)', DOCKER_RUN_OPTS='$(DOCKER_RUN_OPTS)' and DOCKER_VOLUME_OPTS='$(DOCKER_VOLUME_OPTS)'"
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(PROVIDER_DIR):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace 06kellyjac/markdownlint-cli --fix ./website
@$(DOCKER) run $(DOCKER_RUN_OPTS) -v $(PROVIDER_DIR):/workspace:$(DOCKER_VOLUME_OPTS) -w /workspace 06kellyjac/markdownlint-cli --fix ./docs
@echo "==> Fixing website terraform blocks code with terrafmt..."
@terrafmt fmt ./website --pattern '*.markdown'
@terrafmt fmt ./docs --pattern '*.markdown'
.PHONY: build test testacc tools vet fmt fmtcheck terrafmt test-compile depscheck tests-lint tests-lint-fix website-lint website-lint-fix changelog changelog-entry
.PHONY: build test testacc tools vet fmt fmtcheck terrafmt test-compile depscheck tests-lint tests-lint-fix docs-lint docs-lint-fix changelog changelog-entry

7
website/docs/d/all_namespaces.html.markdown → docs/data-sources/all_namespaces.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_all_namespaces"
description: |-
Lists all namespaces within a cluster.
@ -8,14 +7,13 @@ description: |-
# kubernetes_all_namespaces
This data source provides a mechanism for listing the names of all available namespaces in a Kubernetes cluster.
It can be used to check for existence of a specific namespaces or to apply another resource to all or a subset of existing namespaces in a cluster.
This data source provides a mechanism for listing the names of all available namespaces in a Kubernetes cluster. It can be used to check for existence of a specific namespaces or to apply another resource to all or a subset of existing namespaces in a cluster.
In Kubernetes, namespaces provide a scope for names and are intended as a way to divide cluster resources between multiple users.
## Example Usage
```hcl
```terraform
data "kubernetes_all_namespaces" "allns" {}
output "all-ns" {
@ -25,5 +23,4 @@ output "all-ns" {
output "ns-present" {
value = contains(data.kubernetes_all_namespaces.allns.namespaces, "kube-system")
}
```

3
website/docs/d/config_map.html.markdown → docs/data-sources/config_map.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_config_map"
description: |-
This data source reads configuration data from a config map.
@ -14,7 +13,7 @@ Config Maps are key-value pairs containing configuration data. The Config Map da
## Example Usage
```hcl
```terraform
data "kubernetes_config_map" "example" {
metadata {
name = "my-config"

3
website/docs/d/config_map_v1.html.markdown → docs/data-sources/config_map_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_config_map_v1"
description: |-
This data source reads configuration data from a config map.
@ -14,7 +13,7 @@ Config Maps are key-value pairs containing configuration data. The Config Map da
## Example Usage
```hcl
```terraform
data "kubernetes_config_map_v1" "example" {
metadata {
name = "my-config"

6
website/docs/d/endpoints_v1.html.markdown → docs/data-sources/endpoints_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_endpoints_v1"
description: |-
An Endpoints resource is an abstraction, linked to a Service, which defines the list of endpoints that actually implement the service.
@ -10,10 +9,9 @@ description: |-
An Endpoints resource is an abstraction, linked to a Service, which defines the list of endpoints that actually implement the service.
## Example Usage
```hcl
```terraform
data "kubernetes_endpoints_v1" "api_endpoints" {
metadata {
name = "kubernetes"
@ -39,7 +37,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this endpoints resource that can be used by clients to determine when endpoints resource has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this endpoints resource. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -77,4 +74,3 @@ The following arguments are supported:
* `name` - (Optional) The name of this port within the endpoint. All ports within the endpoint must have unique names. Optional if only one port is defined on this endpoint.
* `port` - (Required) The port that will be utilized by this endpoint.
* `protocol` - (Optional) The IP protocol for this port. Supports `TCP` and `UDP`. Default is `TCP`.

11
website/docs/d/ingress.html.markdown → docs/data-sources/ingress.md
View file

@ -1,6 +1,5 @@
---
subcategory: "extensions/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_ingress"
description: |-
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.
@ -8,12 +7,11 @@ description: |-
# kubernetes_ingress
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.
This data source allows you to pull data about such ingress.
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc. This data source allows you to pull data about such ingress.
## Example Usage
```hcl
```terraform
data "kubernetes_ingress" "example" {
metadata {
name = "terraform-example"
@ -77,14 +75,13 @@ The following arguments are supported:
* `host` - Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the \"host\" part of the URI as defined in the RFC: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to the IP in the Spec of the parent Ingress. 2. The : delimiter is not respected because ports are not allowed. Currently the port of an Ingress is implicitly :80 for http and :443 for https. Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.
* `http` - http is a list of http selectors pointing to backends. In the example: http:///? -> backend where parts of the url correspond to RFC 3986, this resource will be used to match against everything after the last '/' and before the first '?' or '#'. See `http` block attributes below.
#### `http`
* `path` - Path array of path regex associated with a backend. Incoming urls matching the path are forwarded to the backend, see below for `path` block structure.
#### `path`
* `path` - A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `path` - A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `backend` - Backend defines the referenced service endpoint to which the traffic will be forwarded to.
### `tls`
@ -110,5 +107,5 @@ The following arguments are supported:
###### Attributes
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `hostname` - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers).

17
website/docs/d/ingress_v1.html.markdown → docs/data-sources/ingress_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "networking/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_ingress_v1"
description: |-
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.
@ -8,12 +7,11 @@ description: |-
# kubernetes_ingress_v1
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.
This data source allows you to pull data about such ingress.
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc. This data source allows you to pull data about such ingress.
## Example Usage
```hcl
```terraform
data "kubernetes_ingress_v1" "example" {
metadata {
name = "terraform-example"
@ -79,8 +77,8 @@ The following arguments are supported:
### `port`
* `name` - Name is the name of the port on the Service.
* `number` - Number is the numerical port number (e.g. 80) on the Service.
* `name` - Name is the name of the port on the Service.
* `number` - Number is the numerical port number (e.g. 80) on the Service.
### `rule`
@ -89,15 +87,14 @@ The following arguments are supported:
* `host` - Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the \"host\" part of the URI as defined in the RFC: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to the IP in the Spec of the parent Ingress. 2. The : delimiter is not respected because ports are not allowed. Currently the port of an Ingress is implicitly :80 for http and :443 for https. Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.
* `http` - http is a list of http selectors pointing to backends. In the example: http:///? -> backend where parts of the url correspond to RFC 3986, this resource will be used to match against everything after the last '/' and before the first '?' or '#'. See `http` block attributes below.
#### `http`
* `path` - Path array of path regex associated with a backend. Incoming urls matching the path are forwarded to the backend, see below for `path` block structure.
#### `path`
* `path` - (Required) A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `path_type` - PathType determines the interpretation of the Path matching. PathType can be one of the following values: `ImplementationSpecific`, `Exact`, or `Prefix`. See the [Kubernetes Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types) for details.
* `path` - (Required) A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `path_type` - PathType determines the interpretation of the Path matching. PathType can be one of the following values: `ImplementationSpecific`, `Exact`, or `Prefix`. See the [Kubernetes Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types) for details.
* `backend` - Backend defines the referenced service endpoint to which the traffic will be forwarded to.
### `tls`
@ -123,5 +120,5 @@ The following arguments are supported:
###### Attributes
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `hostname` - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers).

17
website/docs/d/mutating_webhook_configuration_v1.html.markdown → docs/data-sources/mutating_webhook_configuration_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "admissionregistration/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_mutating_webhook_configuration_v1"
description: |-
Mutating Webhook Configuration configures a mutating admission webhook
@ -8,12 +7,11 @@ description: |-
# kubernetes_mutating_webhook_configuration_v1
A Mutating Webhook Configuration configures a [mutating admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks).
This data source allows you to pull data about a given mutating webhook configuration based on its name.
A Mutating Webhook Configuration configures a [mutating admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks). This data source allows you to pull data about a given mutating webhook configuration based on its name.
## Example Usage
```hcl
```terraform
data "kubernetes_mutating_webhook_configuration_v1" "example" {
metadata {
name = "terraform-example"
@ -52,25 +50,24 @@ The following arguments are supported:
#### Arguments
* `admission_review_versions` - AdmissionReviewVersions is an ordered list of preferred `AdmissionReview` versions the Webhook expects. API server will try to use first version in the list which it supports. If none of the versions specified in this list are supported by API server, validation will fail for this object. If a persisted webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail and be subject to the failure policy.
* `client_config` - ClientConfig defines how to communicate with the hook.
* `client_config` - ClientConfig defines how to communicate with the hook.
* `failure_policy` - FailurePolicy defines how unrecognized errors from the admission endpoint are handled - Allowed values are "Ignore" or "Fail". Defaults to "Fail".
* `match_policy` - matchPolicy defines how the "rules" list is used to match incoming requests. Allowed values are "Exact" or "Equivalent". - Exact: match a request only if it exactly matches a specified rule. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, but "rules" only included `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]`, a request to apps/v1beta1 or extensions/v1beta1 would not be sent to the webhook. - Equivalent: match a request if modifies a resource listed in rules, even via another API group or version. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, and "rules" only included `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]`, a request to apps/v1beta1 or extensions/v1beta1 would be converted to apps/v1 and sent to the webhook. Defaults to "Equivalent"
* `name` - The name of the admission webhook. Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where "imagepolicy" is the name of the webhook, and kubernetes.io is the name of the organization.
* `namespace_selector` - NamespaceSelector decides whether to run the webhook on an object based on whether the namespace for that object matches the selector. If the object itself is a namespace, the matching is performed on object.metadata.labels. If the object is another cluster scoped resource, it never skips the webhook. For example, to run the webhook on any objects whose namespace is not associated with "runlevel" of "0" or "1"; you will set the selector as follows: "namespaceSelector": { "matchExpressions": [ { "key": "runlevel", "operator": "NotIn", "values": [ "0", "1" ] } ] } If instead you want to only run the webhook on any objects whose namespace is associated with the "environment" of "prod" or "staging"; you will set the selector as follows: "namespaceSelector": { "matchExpressions": [ { "key": "environment", "operator": "In", "values": [ "prod", "staging" ] } ] } See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors. Default to the empty LabelSelector, which matches everything.
* `object_selector` - ObjectSelector decides whether to run the webhook based on if the object has matching labels. objectSelector is evaluated against both the oldObject and newObject that would be sent to the webhook, and is considered to match if either object matches the selector. A null object (oldObject in the case of create, or newObject in the case of delete) or an object that cannot have labels (like a DeploymentRollback or a PodProxyOptions object) is not considered to match. Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels. Default to the empty LabelSelector, which matches everything.
* `reinvocation_policy` - reinvocationPolicy indicates whether this webhook should be called multiple times as part of a single admission evaluation. Allowed values are "Never" and "IfNeeded". Never: the webhook will not be called more than once in a single admission evaluation. IfNeeded: the webhook will be called at least one additional time as part of the admission evaluation if the object being admitted is modified by other admission plugins after the initial webhook call. Webhooks that specify this option *must* be idempotent, able to process objects they previously admitted. Note: *the number of additional invocations is not guaranteed to be exactly one.* if additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again. *webhooks that use this option may be reordered to minimize the number of additional invocations.* to validate an object after all mutations are guaranteed complete, use a validating admission webhook instead. Defaults to "Never".
* `rule` - Describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.
* `rule` - Describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches *any* Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.
* `side_effects` - SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some.
* `timeout_seconds` - TimeoutSeconds specifies the timeout for this webhook. After the timeout passes, the webhook call will be ignored or the API call will fail based on the failure policy. The timeout value must be between 1 and 30 seconds. Default to 10 seconds.
### `client_config`
#### Arguments
* `ca_bundle` - A PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used.
* `service` - A reference to the service for this webhook. Either `service` or `url` must be specified. If the webhook is running within the cluster, then you should use `service`.
* `url` - Gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
* `url` - Gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
~> Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
@ -78,8 +75,8 @@ The following arguments are supported:
#### Arguments
* `name` - The name of the service.
* `namespace` - The namespace of the service.
* `name` - The name of the service.
* `namespace` - The namespace of the service.
* `path` - The URL path which will be sent in any request to this service.
* `port` - If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).

6
website/docs/d/namespace.html.markdown → docs/data-sources/namespace.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_namespace"
description: |-
Queries attributes of a Namespace within the cluster.
@ -8,12 +7,11 @@ description: |-
# kubernetes_namespace
This data source provides a mechanism to query attributes of any specific namespace within a Kubernetes cluster.
In Kubernetes, namespaces provide a scope for names and are intended as a way to divide cluster resources between multiple users.
This data source provides a mechanism to query attributes of any specific namespace within a Kubernetes cluster. In Kubernetes, namespaces provide a scope for names and are intended as a way to divide cluster resources between multiple users.
## Example Usage
```hcl
```terraform
data "kubernetes_namespace" "example" {
metadata {
name = "kube-system"

6
website/docs/d/namespace_v1.html.markdown → docs/data-sources/namespace_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_namespace_v1"
description: |-
Queries attributes of a Namespace within the cluster.
@ -8,12 +7,11 @@ description: |-
# kubernetes_namespace_v1
This data source provides a mechanism to query attributes of any specific namespace within a Kubernetes cluster.
In Kubernetes, namespaces provide a scope for names and are intended as a way to divide cluster resources between multiple users.
This data source provides a mechanism to query attributes of any specific namespace within a Kubernetes cluster. In Kubernetes, namespaces provide a scope for names and are intended as a way to divide cluster resources between multiple users.
## Example Usage
```hcl
```terraform
data "kubernetes_namespace_v1" "example" {
metadata {
name = "kube-system"

27
website/docs/d/nodes.html.markdown → docs/data-sources/nodes.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_nodes"
description: |-
Gets nodes within a cluster.
@ -18,7 +17,7 @@ It can be used to check for the existence of a specific node or to lookup a node
### All nodes
```hcl
```terraform
data "kubernetes_nodes" "example" {}
output "node-ids" {
@ -28,7 +27,7 @@ output "node-ids" {
### By label
```hcl
```terraform
data "kubernetes_nodes" "example" {
metadata {
labels = {
@ -50,11 +49,9 @@ The following arguments are supported:
### Attributes
* `metadata` - Metadata describing the node. See [metadata](#metadata) for more
info.
* `metadata` - Metadata describing the node. See [metadata](#metadata) for more info.
* `spec` - Defines the behavior of the node. See [spec](#spec) for more info.
* `status` - Status information for the node. See [status](#status) for more
info.
* `status` - Status information for the node. See [status](#status) for more info.
## Nested Blocks
@ -66,7 +63,7 @@ The following arguments are supported:
#### Attributes
* `name` - Name of the node, must be unique.
* `name` - Name of the node, must be unique.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the node.
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this node that can be used by clients to determine when the node has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
@ -77,12 +74,10 @@ The following arguments are supported:
#### Attributes
* `pod_cidr` - (Optional) The pod IP range assigned to the node
* `pod_cidrs` - (Optional) A list of IP address ranges assigned to the node for
usage by pods on that node.
* `pod_cidrs` - (Optional) A list of IP address ranges assigned to the node for usage by pods on that node.
* `provider_id` - (Optional) ID of the node assigned by the cloud provider.
* `unschedulable` - Controls the schedulability of new pods on the node. By default, node is schedulable.
* `taints` - (Optional) Taints applied to the node. See [taints](#taints) for
more info.
* `unschedulable` - Controls the schedulability of new pods on the node. By default, node is schedulable.
* `taints` - (Optional) Taints applied to the node. See [taints](#taints) for more info.
### `status`
@ -104,10 +99,8 @@ The following arguments are supported:
#### Attributes
* `machine_id` - Machine ID reported by the node see [main(5)
machine-id](http://man7.org/linux/man-pages/man5/machine-id.5.html) for more info.
* `system_uuid` - System UUID reported by the node. This field is
specific to Red Hat hosts.
* `machine_id` - Machine ID reported by the node see [main(5) machine-id](http://man7.org/linux/man-pages/man5/machine-id.5.html) for more info.
* `system_uuid` - System UUID reported by the node. This field is specific to Red Hat hosts.
* `boot_id` - Boot ID reported by the node.
* `kernel_version` - Kernel Version reported by the node from `uname -r`
* `os_image` - OS Image reported by the node from `/etc/os-release`

6
website/docs/d/persistent_volume_claim.html.markdown → docs/data-sources/persistent_volume_claim.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_persistent_volume_claim"
description: |-
A PersistentVolumeClaim (PVC) is a request for storage by a user. This data source retrieves information about the specified PVC.
@ -10,10 +9,9 @@ description: |-
A PersistentVolumeClaim (PVC) is a request for storage by a user. This data source retrieves information about the specified PVC.
## Example Usage
```hcl
```terraform
data "kubernetes_persistent_volume_claim" "example" {
metadata {
name = "terraform-example"
@ -27,8 +25,6 @@ The following arguments are supported:
* `metadata` - (Required) Standard persistent volume claim's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
## Nested Blocks
### `metadata`

6
website/docs/d/persistent_volume_claim_v1.html.markdown → docs/data-sources/persistent_volume_claim_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_persistent_volume_claim_v1"
description: |-
A PersistentVolumeClaim (PVC) is a request for storage by a user. This data source retrieves information about the specified PVC.
@ -10,10 +9,9 @@ description: |-
A PersistentVolumeClaim (PVC) is a request for storage by a user. This data source retrieves information about the specified PVC.
## Example Usage
```hcl
```terraform
data "kubernetes_persistent_volume_claim_v1" "example" {
metadata {
name = "terraform-example"
@ -27,8 +25,6 @@ The following arguments are supported:
* `metadata` - (Required) Standard persistent volume claim's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
## Nested Blocks
### `metadata`

13
website/docs/d/persistent_volume_v1.html.markdown → docs/data-sources/persistent_volume_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_persistent_volume_v1"
description: |-
A Persistent Volume (PV) is a piece of networked storage in the cluster that has been provisioned by an administrator.
@ -10,10 +9,9 @@ description: |-
A PersistentVolume (PV) is a piece of networked storage in the cluster provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. Persistent Volumes have a lifecycle independent of any individual pod that uses the PV. This data source retrieves information about the specified PV.
## Example Usage
```hcl
```terraform
data "kubernetes_persistent_volume_v1" "example" {
metadata {
name = "terraform-example"
@ -103,7 +101,6 @@ The following arguments are supported:
* `rbd` - (Optional) Represents a Rados Block Device mount on the host that shares a pod's lifetime. For more info see https://examples.k8s.io/volumes/rbd/README.md
* `vsphere_volume` - (Optional) Represents a vSphere volume attached and mounted on kubelets host machine
### `aws_elastic_block_store`
#### Arguments
@ -235,12 +232,8 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the persistent volume that may be used to store arbitrary metadata.
**By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem).**
For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the persistent volume. May match selectors of replication controllers and services.
**By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem).**
For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
* `annotations` - (Optional) An unstructured key value map stored with the persistent volume that may be used to store arbitrary metadata. **By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem).** For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the persistent volume. May match selectors of replication controllers and services. **By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem).** For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
* `name` - (Optional) Name of the persistent volume, must be unique. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
#### Attributes

200
website/docs/d/pod.html.markdown → docs/data-sources/pod.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod"
description: |-
A pod is a group of one or more containers, the shared storage for those containers, and options about how to run the containers. Pods are always co-located and co-scheduled, and run in a shared context.
@ -28,7 +27,6 @@ The following arguments are supported:
* `metadata` - (Required) Standard pod's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
## Nested Blocks
### `metadata`
@ -38,10 +36,8 @@ The following arguments are supported:
* `name` - (Required) Name of the pod, must be unique. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `namespace` - (Optional) Namespace defines the space within which name of the pod must be unique.
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this pod that can be used by clients to determine when pod has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this pod. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -58,7 +54,7 @@ The following arguments are supported:
* `dns_policy` - Set DNS policy for containers within the pod. Valid values are 'ClusterFirstWithHostNet', 'ClusterFirst', 'Default' or 'None'. DNS parameters given in DNSConfig will be merged with the policy selected with DNSPolicy. To have DNS options set along with hostNetwork, you have to specify DNS policy explicitly to 'ClusterFirstWithHostNet'. Optional: Defaults to 'ClusterFirst', see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy).
* `dns_config` - Specifies the DNS parameters of a pod. Parameters specified here will be merged to the generated DNS configuration based on DNSPolicy. Defaults to empty. See `dns_config` block definition below.
* `host_alias` - List of hosts and IPs that will be injected into the pod's hosts file if specified. Optional: Defaults to empty. See `host_alias` block definition below.
* `host_ipc` - Use the host's ipc namespace. Optional: Defaults to false.
* `host_ipc` - Use the host's ipc namespace. Optional: Defaults to false.
* `host_network` - Host networking requested for this pod. Use the host's network namespace. If this option is set, the ports that will be used must be specified.
* `host_pid` - Use the host's pid namespace.
* `hostname` - Specifies the hostname of the Pod If not specified, the pod's hostname will be set to a system-defined value.
@ -84,7 +80,6 @@ The following arguments are supported:
* `pod_affinity` - Inter-pod topological affinity. rules that specify that certain pods should be placed in the same topological domain (e.g. same node, same rack, same zone, same power domain, etc.) For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
* `pod_anti_affinity` - Inter-pod topological affinity. rules that specify that certain pods should be placed in the same topological domain (e.g. same node, same rack, same zone, same power domain, etc.) For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
### `container`
#### Attributes
@ -121,7 +116,7 @@ The following arguments are supported:
#### Attributes
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `optional` - Specify whether the ConfigMap must be defined
### `config_map_key_ref`
@ -137,11 +132,11 @@ The following arguments are supported:
* `nameservers` - A list of DNS name server IP addresses specified as strings. This will be appended to the base nameservers generated from DNSPolicy. Duplicated nameservers will be removed. Optional: Defaults to empty.
* `option` - A list of DNS resolver options specified as blocks with `name`/`value` pairs. This will be merged with the base options generated from DNSPolicy. Duplicated entries will be removed. Resolution options given in Options will override those that appear in the base DNSPolicy. Optional: Defaults to empty.
* `searches` - A list of DNS search domains for host-name lookup specified as strings. This will be appended to the base search paths generated from DNSPolicy. Duplicated search paths will be removed. Optional: Defaults to empty.
* `searches` - A list of DNS search domains for host-name lookup specified as strings. This will be appended to the base search paths generated from DNSPolicy. Duplicated search paths will be removed. Optional: Defaults to empty.
The `option` block supports the following:
* `name` - Name of the option.
* `name` - Name of the option.
* `value` - Value of the option. Optional: Defaults to empty.
### `downward_api`
@ -211,100 +206,100 @@ The `option` block supports the following:
#### Attributes
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `http_get` - Specifies the http request to perform.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `initial_delay_seconds` - Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `http_get` - Specifies the http request to perform.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `initial_delay_seconds` - Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
### `nfs`
#### Attributes
* `path` - Path that is exported by the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `read_only` - Whether to force the NFS export to be mounted with read-only permissions. Defaults to false. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `server` - Server is the hostname or IP address of the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `path` - Path that is exported by the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `read_only` - Whether to force the NFS export to be mounted with read-only permissions. Defaults to false. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `server` - Server is the hostname or IP address of the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
### `persistent_volume_claim`
#### Attributes
* `claim_name` - ClaimName is the name of a PersistentVolumeClaim in the same
* `read_only` - Will force the ReadOnly setting in VolumeMounts.
* `claim_name` - ClaimName is the name of a PersistentVolumeClaim in the same
* `read_only` - Will force the ReadOnly setting in VolumeMounts.
### `photon_persistent_disk`
#### Attributes
* `fs_type` - Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified.
* `pd_id` - ID that identifies Photon Controller persistent disk
* `fs_type` - Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified.
* `pd_id` - ID that identifies Photon Controller persistent disk
### `port`
#### Attributes
* `container_port` - Number of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536.
* `host_ip` - What host IP to bind the external port to.
* `host_port` - Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this.
* `name` - If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services
* `protocol` - Protocol for port. Must be UDP or TCP. Defaults to "TCP".
* `container_port` - Number of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536.
* `host_ip` - What host IP to bind the external port to.
* `host_port` - Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this.
* `name` - If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services
* `protocol` - Protocol for port. Must be UDP or TCP. Defaults to "TCP".
### `post_start`
#### Attributes
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
### `pre_stop`
#### Attributes
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
### `quobyte`
#### Attributes
* `group` - Group to map volume access to Default is no group
* `read_only` - Whether to force the Quobyte volume to be mounted with read-only permissions. Defaults to false.
* `registry` - Registry represents a single or multiple Quobyte Registry services specified as a string as host:port pair (multiple entries are separated with commas) which acts as the central registry for volumes
* `user` - User to map volume access to Defaults to serivceaccount user
* `volume` - Volume is a string that references an already created Quobyte volume by name.
* `group` - Group to map volume access to Default is no group
* `read_only` - Whether to force the Quobyte volume to be mounted with read-only permissions. Defaults to false.
* `registry` - Registry represents a single or multiple Quobyte Registry services specified as a string as host:port pair (multiple entries are separated with commas) which acts as the central registry for volumes
* `user` - User to map volume access to Defaults to serivceaccount user
* `volume` - Volume is a string that references an already created Quobyte volume by name.
### `rbd`
#### Attributes
* `ceph_monitors` - A collection of Ceph monitors. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#cephfs.
* `fs_type` - Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#rbd)
* `ceph_monitors` - A collection of Ceph monitors. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#cephfs.
* `fs_type` - Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#rbd)
* `keyring` - Keyring is the path to key ring for RBDUser. Default is /etc/ceph/keyring. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rados_user` - The rados user name. Default is admin. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_image` - The rados image name. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_pool` - The rados pool name. Default is rbd. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `read_only` - Whether to force the read-only setting in VolumeMounts. Defaults to false. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `secret_ref` - Name of the authentication secret for RBDUser. If provided overrides keyring. Default is nil. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rados_user` - The rados user name. Default is admin. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_image` - The rados image name. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_pool` - The rados pool name. Default is rbd. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `read_only` - Whether to force the read-only setting in VolumeMounts. Defaults to false. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `secret_ref` - Name of the authentication secret for RBDUser. If provided overrides keyring. Default is nil. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
### `readiness_probe`
#### Attributes
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `http_get` - Specifies the http request to perform.
* `initial_delay_seconds` - Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `http_get` - Specifies the http request to perform.
* `initial_delay_seconds` - Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
### `resources`
@ -317,7 +312,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}
@ -335,8 +330,8 @@ resources {
#### Attributes
* `container_name` - The name of the container
* `resource` - Resource to select
* `container_name` - The name of the container
* `resource` - Resource to select
### `seccomp_profile`
@ -352,105 +347,104 @@ resources {
#### Attributes
* `level` - Level is SELinux level label that applies to the container.
* `role` - Role is a SELinux role label that applies to the container.
* `type` - Type is a SELinux type label that applies to the container.
* `user` - User is a SELinux user label that applies to the container.
* `level` - Level is SELinux level label that applies to the container.
* `role` - Role is a SELinux role label that applies to the container.
* `type` - Type is a SELinux type label that applies to the container.
* `user` - User is a SELinux user label that applies to the container.
### `secret`
#### Attributes
* `default_mode` - Mode bits to use on created files by default. Must be a value between 0 and 0777. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.
* `items` - List of Secret Items to project into the volume. See `items` block definition below. If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked `optional`. Paths must be relative and may not contain the '..' path or start with '..'.
* `optional` - Specify whether the Secret or its keys must be defined.
* `secret_name` - Name of the secret in the pod's namespace to use. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#secrets)
* `default_mode` - Mode bits to use on created files by default. Must be a value between 0 and 0777. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.
* `items` - List of Secret Items to project into the volume. See `items` block definition below. If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked `optional`. Paths must be relative and may not contain the '..' path or start with '..'.
* `optional` - Specify whether the Secret or its keys must be defined.
* `secret_name` - Name of the secret in the pod's namespace to use. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#secrets)
The `items` block supports the following:
* `key` - The key to project.
* `mode` - Mode bits to use on this file, must be a value between 0 and 0777. If not specified, the volume defaultMode will be used.
* `path` - The relative path of the file to map the key to. May not be an absolute path. May not contain the path element '..'. May not start with the string '..'.
* `key` - The key to project.
* `mode` - Mode bits to use on this file, must be a value between 0 and 0777. If not specified, the volume defaultMode will be used.
* `path` - The relative path of the file to map the key to. May not be an absolute path. May not contain the path element '..'. May not start with the string '..'.
### `secret_ref`
#### Attributes
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `optional` - Specify whether the Secret must be defined
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `optional` - Specify whether the Secret must be defined
### `secret_key_ref`
#### Attributes
* `key` - The key of the secret to select from. Must be a valid secret key.
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `key` - The key of the secret to select from. Must be a valid secret key.
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
### `secret_ref`
#### Attributes
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
### container `security_context`
#### ArgumAttributesents
* `allow_privilege_escalation` - AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN
* `capabilities` - The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime.
* `privileged` - Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.
* `read_only_root_filesystem` - Whether this container has a read-only root filesystem. Default is false.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `allow_privilege_escalation` - AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN
* `capabilities` - The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime.
* `privileged` - Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.
* `read_only_root_filesystem` - Whether this container has a read-only root filesystem. Default is false.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `seccomp_profile` - The seccomp options to use by the containers in this pod. Note that this field cannot be set when spec.os.name is windows.
* `se_linux_options` - The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `se_linux_options` - The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `fs_group_change_policy` - Defines behavior of changing ownership and permission of the volume before being exposed inside Pod. This field will only apply to volume types which support fsGroup based ownership(and permissions). It will have no effect on ephemeral volume types such as: secret, configmaps and emptydir. Valid values are "OnRootMismatch" and "Always". If not specified, "Always" is used. Note that this field cannot be set when spec.os.name is windows.
### `capabilities`
#### Attributes
* `add` - A list of added capabilities.
* `drop` - A list of removed capabilities.
* `add` - A list of added capabilities.
* `drop` - A list of removed capabilities.
### pod `security_context`
#### Attributes
* `fs_group` - A special supplemental group that applies to all containers in a pod. Some volume types allow the Kubelet to change the ownership of that volume to be owned by the pod: 1. The owning GID will be the FSGroup 2. The setgid bit is set (new files created in the volume will be owned by FSGroup) 3. The permission bits are OR'd with rw-rw---- If unset, the Kubelet will not modify the ownership and permissions of any volume.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `fs_group` - A special supplemental group that applies to all containers in a pod. Some volume types allow the Kubelet to change the ownership of that volume to be owned by the pod: 1. The owning GID will be the FSGroup 2. The setgid bit is set (new files created in the volume will be owned by FSGroup) 3. The permission bits are OR'd with rw-rw---- If unset, the Kubelet will not modify the ownership and permissions of any volume.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `seccomp_profile` - The seccomp options to use by the containers in this pod. Note that this field cannot be set when spec.os.name is windows.
* `se_linux_options` - The SELinux context to be applied to all containers. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `supplemental_groups` - A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container.
* `se_linux_options` - The SELinux context to be applied to all containers. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `supplemental_groups` - A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container.
### `tcp_socket`
#### Attributes
* `port` - Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME.
* `port` - Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME.
### `value_from`
#### Attributes
* `config_map_key_ref` - Selects a key of a ConfigMap.
* `field_ref` - (Optional) Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, spec.nodeName, spec.serviceAccountName, status.podIP.
* `resource_field_ref` - (Optional) Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.
* `secret_key_ref` - (Optional) Selects a key of a secret in the pod's namespace.
* `config_map_key_ref` - Selects a key of a ConfigMap.
* `field_ref` - (Optional) Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, spec.nodeName, spec.serviceAccountName, status.podIP.
* `resource_field_ref` - (Optional) Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.
* `secret_key_ref` - (Optional) Selects a key of a secret in the pod's namespace.
### `volume_mount`
#### Attributes
* `mount_path` - Path within the container at which the volume should be mounted. Must not contain ':'.
* `name` - This must match the Name of a Volume.
* `read_only` - Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.
* `sub_path` - Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root).
* `mount_propagation` - Mount propagation mode. Defaults to "None". For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation)
* `mount_path` - Path within the container at which the volume should be mounted. Must not contain ':'.
* `name` - This must match the Name of a Volume.
* `read_only` - Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.
* `sub_path` - Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root).
* `mount_propagation` - Mount propagation mode. Defaults to "None". For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation)
## Argument Reference

200
website/docs/d/pod_v1.html.markdown → docs/data-sources/pod_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod_v1"
description: |-
A pod is a group of one or more containers, the shared storage for those containers, and options about how to run the containers. Pods are always co-located and co-scheduled, and run in a shared context.
@ -28,7 +27,6 @@ The following arguments are supported:
* `metadata` - (Required) Standard pod's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
## Nested Blocks
### `metadata`
@ -38,10 +36,8 @@ The following arguments are supported:
* `name` - (Required) Name of the pod, must be unique. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `namespace` - (Optional) Namespace defines the space within which name of the pod must be unique.
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this pod that can be used by clients to determine when pod has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this pod. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -58,7 +54,7 @@ The following arguments are supported:
* `dns_policy` - Set DNS policy for containers within the pod. Valid values are 'ClusterFirstWithHostNet', 'ClusterFirst', 'Default' or 'None'. DNS parameters given in DNSConfig will be merged with the policy selected with DNSPolicy. To have DNS options set along with hostNetwork, you have to specify DNS policy explicitly to 'ClusterFirstWithHostNet'. Optional: Defaults to 'ClusterFirst', see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy).
* `dns_config` - Specifies the DNS parameters of a pod. Parameters specified here will be merged to the generated DNS configuration based on DNSPolicy. Defaults to empty. See `dns_config` block definition below.
* `host_alias` - List of hosts and IPs that will be injected into the pod's hosts file if specified. Optional: Defaults to empty. See `host_alias` block definition below.
* `host_ipc` - Use the host's ipc namespace. Optional: Defaults to false.
* `host_ipc` - Use the host's ipc namespace. Optional: Defaults to false.
* `host_network` - Host networking requested for this pod. Use the host's network namespace. If this option is set, the ports that will be used must be specified.
* `host_pid` - Use the host's pid namespace.
* `hostname` - Specifies the hostname of the Pod If not specified, the pod's hostname will be set to a system-defined value.
@ -84,7 +80,6 @@ The following arguments are supported:
* `pod_affinity` - Inter-pod topological affinity. rules that specify that certain pods should be placed in the same topological domain (e.g. same node, same rack, same zone, same power domain, etc.) For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
* `pod_anti_affinity` - Inter-pod topological affinity. rules that specify that certain pods should be placed in the same topological domain (e.g. same node, same rack, same zone, same power domain, etc.) For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
### `container`
#### Attributes
@ -121,7 +116,7 @@ The following arguments are supported:
#### Attributes
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `optional` - Specify whether the ConfigMap must be defined
### `config_map_key_ref`
@ -137,11 +132,11 @@ The following arguments are supported:
* `nameservers` - A list of DNS name server IP addresses specified as strings. This will be appended to the base nameservers generated from DNSPolicy. Duplicated nameservers will be removed. Optional: Defaults to empty.
* `option` - A list of DNS resolver options specified as blocks with `name`/`value` pairs. This will be merged with the base options generated from DNSPolicy. Duplicated entries will be removed. Resolution options given in Options will override those that appear in the base DNSPolicy. Optional: Defaults to empty.
* `searches` - A list of DNS search domains for host-name lookup specified as strings. This will be appended to the base search paths generated from DNSPolicy. Duplicated search paths will be removed. Optional: Defaults to empty.
* `searches` - A list of DNS search domains for host-name lookup specified as strings. This will be appended to the base search paths generated from DNSPolicy. Duplicated search paths will be removed. Optional: Defaults to empty.
The `option` block supports the following:
* `name` - Name of the option.
* `name` - Name of the option.
* `value` - Value of the option. Optional: Defaults to empty.
### `downward_api`
@ -211,100 +206,100 @@ The `option` block supports the following:
#### Attributes
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `http_get` - Specifies the http request to perform.
* `initial_delay_seconds` - Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `http_get` - Specifies the http request to perform.
* `initial_delay_seconds` - Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
### `nfs`
#### Attributes
* `path` - Path that is exported by the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `read_only` - Whether to force the NFS export to be mounted with read-only permissions. Defaults to false. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `server` - Server is the hostname or IP address of the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `path` - Path that is exported by the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `read_only` - Whether to force the NFS export to be mounted with read-only permissions. Defaults to false. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
* `server` - Server is the hostname or IP address of the NFS server. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#nfs)
### `persistent_volume_claim`
#### Attributes
* `claim_name` - ClaimName is the name of a PersistentVolumeClaim in the same
* `read_only` - Will force the ReadOnly setting in VolumeMounts.
* `claim_name` - ClaimName is the name of a PersistentVolumeClaim in the same
* `read_only` - Will force the ReadOnly setting in VolumeMounts.
### `photon_persistent_disk`
#### Attributes
* `fs_type` - Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified.
* `pd_id` - ID that identifies Photon Controller persistent disk
* `fs_type` - Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified.
* `pd_id` - ID that identifies Photon Controller persistent disk
### `port`
#### Attributes
* `container_port` - Number of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536.
* `host_ip` - What host IP to bind the external port to.
* `host_port` - Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this.
* `name` - If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services
* `protocol` - Protocol for port. Must be UDP or TCP. Defaults to "TCP".
* `container_port` - Number of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536.
* `host_ip` - What host IP to bind the external port to.
* `host_port` - Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this.
* `name` - If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services
* `protocol` - Protocol for port. Must be UDP or TCP. Defaults to "TCP".
### `post_start`
#### Attributes
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
### `pre_stop`
#### Attributes
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `exec` - exec specifies the action to take.
* `http_get` - Specifies the http request to perform.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
### `quobyte`
#### Attributes
* `group` - Group to map volume access to Default is no group
* `read_only` - Whether to force the Quobyte volume to be mounted with read-only permissions. Defaults to false.
* `registry` - Registry represents a single or multiple Quobyte Registry services specified as a string as host:port pair (multiple entries are separated with commas) which acts as the central registry for volumes
* `user` - User to map volume access to Defaults to serivceaccount user
* `volume` - Volume is a string that references an already created Quobyte volume by name.
* `group` - Group to map volume access to Default is no group
* `read_only` - Whether to force the Quobyte volume to be mounted with read-only permissions. Defaults to false.
* `registry` - Registry represents a single or multiple Quobyte Registry services specified as a string as host:port pair (multiple entries are separated with commas) which acts as the central registry for volumes
* `user` - User to map volume access to Defaults to serivceaccount user
* `volume` - Volume is a string that references an already created Quobyte volume by name.
### `rbd`
#### Attributes
* `ceph_monitors` - A collection of Ceph monitors. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#cephfs.
* `fs_type` - Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#rbd)
* `ceph_monitors` - A collection of Ceph monitors. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#cephfs.
* `fs_type` - Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#rbd)
* `keyring` - Keyring is the path to key ring for RBDUser. Default is /etc/ceph/keyring. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rados_user` - The rados user name. Default is admin. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_image` - The rados image name. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_pool` - The rados pool name. Default is rbd. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `read_only` - Whether to force the read-only setting in VolumeMounts. Defaults to false. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `secret_ref` - Name of the authentication secret for RBDUser. If provided overrides keyring. Default is nil. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rados_user` - The rados user name. Default is admin. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_image` - The rados image name. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `rbd_pool` - The rados pool name. Default is rbd. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `read_only` - Whether to force the read-only setting in VolumeMounts. Defaults to false. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
* `secret_ref` - Name of the authentication secret for RBDUser. If provided overrides keyring. Default is nil. For more info see https://github.com/kubernetes/examples/tree/master/volumes/rbd#how-to-use-it.
### `readiness_probe`
#### Attributes
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `http_get` - Specifies the http request to perform.
* `initial_delay_seconds` - Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `exec` - exec specifies the action to take.
* `failure_threshold` - Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - GRPC specifies an action involving a GRPC port.
* `http_get` - Specifies the http request to perform.
* `initial_delay_seconds` - Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - How often (in seconds) to perform the probe
* `success_threshold` - Minimum consecutive successes for the probe to be considered successful after having failed.
* `tcp_socket` - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported
* `timeout_seconds` - Number of seconds after which the probe times out. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
### `resources`
@ -317,7 +312,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}
@ -335,8 +330,8 @@ resources {
#### Attributes
* `container_name` - The name of the container
* `resource` - Resource to select
* `container_name` - The name of the container
* `resource` - Resource to select
### `seccomp_profile`
@ -352,104 +347,103 @@ resources {
#### Attributes
* `level` - Level is SELinux level label that applies to the container.
* `role` - Role is a SELinux role label that applies to the container.
* `type` - Type is a SELinux type label that applies to the container.
* `user` - User is a SELinux user label that applies to the container.
* `level` - Level is SELinux level label that applies to the container.
* `role` - Role is a SELinux role label that applies to the container.
* `type` - Type is a SELinux type label that applies to the container.
* `user` - User is a SELinux user label that applies to the container.
### `secret`
#### Attributes
* `default_mode` - Mode bits to use on created files by default. Must be a value between 0 and 0777. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.
* `items` - List of Secret Items to project into the volume. See `items` block definition below. If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked `optional`. Paths must be relative and may not contain the '..' path or start with '..'.
* `optional` - Specify whether the Secret or its keys must be defined.
* `secret_name` - Name of the secret in the pod's namespace to use. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#secrets)
* `default_mode` - Mode bits to use on created files by default. Must be a value between 0 and 0777. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.
* `items` - List of Secret Items to project into the volume. See `items` block definition below. If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked `optional`. Paths must be relative and may not contain the '..' path or start with '..'.
* `optional` - Specify whether the Secret or its keys must be defined.
* `secret_name` - Name of the secret in the pod's namespace to use. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#secrets)
The `items` block supports the following:
* `key` - The key to project.
* `mode` - Mode bits to use on this file, must be a value between 0 and 0777. If not specified, the volume defaultMode will be used.
* `path` - The relative path of the file to map the key to. May not be an absolute path. May not contain the path element '..'. May not start with the string '..'.
* `key` - The key to project.
* `mode` - Mode bits to use on this file, must be a value between 0 and 0777. If not specified, the volume defaultMode will be used.
* `path` - The relative path of the file to map the key to. May not be an absolute path. May not contain the path element '..'. May not start with the string '..'.
### `secret_ref`
#### Attributes
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `optional` - Specify whether the Secret must be defined
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `optional` - Specify whether the Secret must be defined
### `secret_key_ref`
#### Attributes
* `key` - The key of the secret to select from. Must be a valid secret key.
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `key` - The key of the secret to select from. Must be a valid secret key.
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
### `secret_ref`
#### Attributes
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `name` - Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
### container `security_context`
#### ArgumAttributesents
* `allow_privilege_escalation` - AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN
* `capabilities` - The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime.
* `privileged` - Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.
* `read_only_root_filesystem` - Whether this container has a read-only root filesystem. Default is false.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `allow_privilege_escalation` - AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN
* `capabilities` - The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime.
* `privileged` - Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.
* `read_only_root_filesystem` - Whether this container has a read-only root filesystem. Default is false.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `seccomp_profile` - The seccomp options to use by the containers in this pod. Note that this field cannot be set when spec.os.name is windows.
* `se_linux_options` - The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `se_linux_options` - The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
### `capabilities`
#### Attributes
* `add` - A list of added capabilities.
* `drop` - A list of removed capabilities.
* `add` - A list of added capabilities.
* `drop` - A list of removed capabilities.
### pod `security_context`
#### Attributes
* `fs_group` - A special supplemental group that applies to all containers in a pod. Some volume types allow the Kubelet to change the ownership of that volume to be owned by the pod: 1. The owning GID will be the FSGroup 2. The setgid bit is set (new files created in the volume will be owned by FSGroup) 3. The permission bits are OR'd with rw-rw---- If unset, the Kubelet will not modify the ownership and permissions of any volume.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `fs_group` - A special supplemental group that applies to all containers in a pod. Some volume types allow the Kubelet to change the ownership of that volume to be owned by the pod: 1. The owning GID will be the FSGroup 2. The setgid bit is set (new files created in the volume will be owned by FSGroup) 3. The permission bits are OR'd with rw-rw---- If unset, the Kubelet will not modify the ownership and permissions of any volume.
* `run_as_group` - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `run_as_non_root` - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.
* `run_as_user` - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `seccomp_profile` - The seccomp options to use by the containers in this pod. Note that this field cannot be set when spec.os.name is windows.
* `se_linux_options` - The SELinux context to be applied to all containers. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `supplemental_groups` - A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container.
* `se_linux_options` - The SELinux context to be applied to all containers. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.
* `supplemental_groups` - A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container.
### `tcp_socket`
#### Attributes
* `port` - Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME.
* `port` - Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME.
### `value_from`
#### Attributes
* `config_map_key_ref` - Selects a key of a ConfigMap.
* `field_ref` - (Optional) Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, spec.nodeName, spec.serviceAccountName, status.podIP.
* `resource_field_ref` - (Optional) Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.
* `secret_key_ref` - (Optional) Selects a key of a secret in the pod's namespace.
* `config_map_key_ref` - Selects a key of a ConfigMap.
* `field_ref` - (Optional) Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, spec.nodeName, spec.serviceAccountName, status.podIP.
* `resource_field_ref` - (Optional) Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.
* `secret_key_ref` - (Optional) Selects a key of a secret in the pod's namespace.
### `volume_mount`
#### Attributes
* `mount_path` - Path within the container at which the volume should be mounted. Must not contain ':'.
* `name` - This must match the Name of a Volume.
* `read_only` - Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.
* `sub_path` - Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root).
* `mount_propagation` - Mount propagation mode. Defaults to "None". For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation)
* `mount_path` - Path within the container at which the volume should be mounted. Must not contain ':'.
* `name` - This must match the Name of a Volume.
* `read_only` - Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.
* `sub_path` - Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root).
* `mount_propagation` - Mount propagation mode. Defaults to "None". For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation)
## Argument Reference

6
website/docs/d/resource.html.markdown → docs/data-sources/resource.md
View file

@ -1,6 +1,5 @@
---
subcategory: "manifest"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_resource"
description: |-
This is a generic data source for Kubernetes API resources
@ -8,11 +7,11 @@ description: |-
# kubernetes_resource
This data source is a generic way to retrieve resources from the Kubernetes API.
This data source is a generic way to retrieve resources from the Kubernetes API.
### Example: Get data from a ConfigMap
```hcl
```terraform
data "kubernetes_resource" "example" {
api_version = "v1"
kind = "ConfigMap"
@ -43,4 +42,3 @@ The following arguments are supported:
* `name` - (Required) The name of the requested resource.
* `namespace` - (Optional) The namespace of the requested resource.

6
website/docs/d/resources.html.markdown → docs/data-sources/resources.md
View file

@ -1,6 +1,5 @@
---
subcategory: "manifest"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_resources"
description: |-
This data source is a generic way to query for a list of resources from the Kubernetes API and filter them.
@ -12,7 +11,7 @@ This data source is a generic way to query for a list of Kubernetes resources an
### Example: Get a list of namespaces excluding "kube-system" using `field_selector`
```hcl
```terraform
data "kubernetes_resources" "example" {
api_version = "v1"
kind = "Namespace"
@ -26,7 +25,7 @@ output "test" {
### Example: Get a list of namespaces excluding "kube-system" using `label_selector`
```hcl
```terraform
data "kubernetes_resources" "example" {
api_version = "v1"
kind = "Namespace"
@ -48,4 +47,3 @@ The following arguments are supported:
* `field_selector` - (Optional) A selector to restrict the list of returned objects by their fields.
* `namespace` - (Optional) The namespace of the requested resource.
* `object` - (Optional) The response returned from the API server.

9
website/docs/d/secret.html.markdown → docs/data-sources/secret.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_secret"
description: |-
The resource provides mechanisms to inject containers with sensitive information while keeping containers agnostic of Kubernetes.
@ -8,9 +7,7 @@ description: |-
# kubernetes_secret
The resource provides mechanisms to inject containers with sensitive information, such as passwords, while keeping containers agnostic of Kubernetes.
Secrets can be used to store sensitive information either as individual properties or coarse-grained entries like entire files or JSON blobs.
The resource will by default create a secret which is available to any pod in the specified (or default) namespace.
The resource provides mechanisms to inject containers with sensitive information, such as passwords, while keeping containers agnostic of Kubernetes. Secrets can be used to store sensitive information either as individual properties or coarse-grained entries like entire files or JSON blobs. The resource will by default create a secret which is available to any pod in the specified (or default) namespace.
~> Read more about security properties and risks involved with using Kubernetes secrets: [Kubernetes reference](https://kubernetes.io/docs/concepts/configuration/secret/#information-security-for-secrets)
@ -18,7 +15,7 @@ The resource will by default create a secret which is available to any pod in th
## Example Usage
```hcl
```terraform
data "kubernetes_secret" "example" {
metadata {
name = "basic-auth"
@ -54,7 +51,7 @@ The following arguments are supported:
~> In case the secret has been created outside terraform in order to retrieve binary data from the secret in base64 format you need to define a `binary_data` map with data to retrieve as key and an empty string as a value
```hcl
```terraform
data "kubernetes_secret" "example" {
metadata {
name = "example-secret"

9
website/docs/d/secret_v1.html.markdown → docs/data-sources/secret_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_secret_v1"
description: |-
The resource provides mechanisms to inject containers with sensitive information while keeping containers agnostic of Kubernetes.
@ -8,9 +7,7 @@ description: |-
# kubernetes_secret_v1
The resource provides mechanisms to inject containers with sensitive information, such as passwords, while keeping containers agnostic of Kubernetes.
Secrets can be used to store sensitive information either as individual properties or coarse-grained entries like entire files or JSON blobs.
The resource will by default create a secret which is available to any pod in the specified (or default) namespace.
The resource provides mechanisms to inject containers with sensitive information, such as passwords, while keeping containers agnostic of Kubernetes. Secrets can be used to store sensitive information either as individual properties or coarse-grained entries like entire files or JSON blobs. The resource will by default create a secret which is available to any pod in the specified (or default) namespace.
~> Read more about security properties and risks involved with using Kubernetes secrets: [Kubernetes reference](https://kubernetes.io/docs/concepts/configuration/secret/#information-security-for-secrets)
@ -18,7 +15,7 @@ The resource will by default create a secret which is available to any pod in th
## Example Usage
```hcl
```terraform
data "kubernetes_secret_v1" "example" {
metadata {
name = "basic-auth"
@ -54,7 +51,7 @@ The following arguments are supported:
~> In case the secret has been created outside terraform in order to retrieve binary data from the secret in base64 format you need to define a `binary_data` map with data to retrieve as key and an empty string as a value
```hcl
```terraform
data "kubernetes_secret_v1" "example" {
metadata {
name = "example-secret"

18
website/docs/d/service.html.markdown → docs/data-sources/service.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_service"
description: |-
A Service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a micro-service.
@ -8,12 +7,11 @@ description: |-
# kubernetes_service
A Service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a micro-service.
This data source allows you to pull data about such service.
A Service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a micro-service. This data source allows you to pull data about such service.
## Example Usage
```hcl
```terraform
data "kubernetes_service" "example" {
metadata {
name = "terraform-example"
@ -71,10 +69,10 @@ The following arguments are supported:
#### Attributes
* `allocate_load_balancer_node_ports` - (Optional) Defines if `NodePorts` will be automatically allocated for services with type `LoadBalancer`. It may be set to `false` if the cluster load-balancer does not rely on `NodePorts`. If the caller requests specific `NodePorts` (by specifying a value), those requests will be respected, regardless of this field. This field may only be set for services with type `LoadBalancer`. Default is `true`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation)
* `allocate_load_balancer_node_ports` - (Optional) Defines if `NodePorts` will be automatically allocated for services with type `LoadBalancer`. It may be set to `false` if the cluster load-balancer does not rely on `NodePorts`. If the caller requests specific `NodePorts` (by specifying a value), those requests will be respected, regardless of this field. This field may only be set for services with type `LoadBalancer`. Default is `true`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation)
* `cluster_ip` - The IP address of the service. It is usually assigned randomly by the master. If an address is specified manually and is not in use by others, it will be allocated to the service; otherwise, creation of the service will fail. `None` can be specified for headless services when proxying is not required. Ignored if type is `ExternalName`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
* `cluster_ips` - (Optional) List of IP addresses assigned to this service, and are usually assigned randomly. If an address is specified manually and is not in use by others, it will be allocated to the service; otherwise creation of the service will fail. If this field is not specified, it will be initialized from the `clusterIP` field. If this field is specified, clients must ensure that `clusterIPs[0]` and `clusterIP` have the same value. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
* `external_ips` - A list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.
* `external_ips` - A list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.
* `external_name` - The external reference that kubedns or equivalent will return as a CNAME record for this service. No proxying will be involved. Must be a valid DNS name and requires `type` to be `ExternalName`.
* `external_traffic_policy` - (Optional) Denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. `Local` preserves the client source IP and avoids a second hop for LoadBalancer and Nodeport type services, but risks potentially imbalanced traffic spreading. `Cluster` obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading. For more info see [Kubernetes reference](https://kubernetes.io/docs/tutorials/services/source-ip/)
* `ip_families` - (Optional) A list of IP families (e.g. IPv4, IPv6) assigned to this service. This field is usually assigned automatically based on cluster configuration and the `ip_family_policy` field. If this field is specified manually, the requested family is available in the cluster, and `ip_family_policy` allows it, it will be used; otherwise creation of the service will fail. This field is conditionally mutable: it allows for adding or removing a secondary IP family, but it does not allow changing the primary IP family of the Service. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/dual-stack/)
@ -89,25 +87,25 @@ The following arguments are supported:
* `session_affinity_config` - (Optional) Contains the configurations of session affinity. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-ipvs)
* `type` - Determines how the service is exposed. Defaults to `ClusterIP`. Valid options are `ExternalName`, `ClusterIP`, `NodePort`, and `LoadBalancer`. `ExternalName` maps to the specified `external_name`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types)
## Attributes
* `status` - Status is a list containing the most recently observed status of the service. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
### `status`
#### Attributes
* `load_balancer` - a list containing the current status of the load-balancer, if one is present.
### `load_balancer`
#### Attributes
* `ingress` - a list containing ingress points for the load-balancer. Traffic intended for the service should be sent to these ingress points.
### `ingress`
#### Attributes
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `hostname` - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers).

5
website/docs/d/service_account.html.markdown → docs/data-sources/service_account.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_service_account"
description: |-
A service account provides an identity for processes that run in a Pod.
@ -8,13 +7,13 @@ description: |-
# kubernetes_service_account
A service account provides an identity for processes that run in a Pod. This data source reads the service account and makes specific attributes available to Terraform.
A service account provides an identity for processes that run in a Pod. This data source reads the service account and makes specific attributes available to Terraform.
Read more at [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/)
## Example Usage
```hcl
```terraform
data "kubernetes_service_account" "example" {
metadata {
name = "terraform-example"

5
website/docs/d/service_account_v1.html.markdown → docs/data-sources/service_account_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_service_account_v1"
description: |-
A service account provides an identity for processes that run in a Pod.
@ -8,13 +7,13 @@ description: |-
# kubernetes_service_account_v1
A service account provides an identity for processes that run in a Pod. This data source reads the service account and makes specific attributes available to Terraform.
A service account provides an identity for processes that run in a Pod. This data source reads the service account and makes specific attributes available to Terraform.
Read more at [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/)
## Example Usage
```hcl
```terraform
data "kubernetes_service_account_v1" "example" {
metadata {
name = "terraform-example"

18
website/docs/d/service_v1.html.markdown → docs/data-sources/service_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_service_v1"
description: |-
A Service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a micro-service.
@ -8,12 +7,11 @@ description: |-
# kubernetes_service_v1
A Service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a micro-service.
This data source allows you to pull data about such service.
A Service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a micro-service. This data source allows you to pull data about such service.
## Example Usage
```hcl
```terraform
data "kubernetes_service_v1" "example" {
metadata {
name = "terraform-example"
@ -71,10 +69,10 @@ The following arguments are supported:
#### Attributes
* `allocate_load_balancer_node_ports` - (Optional) Defines if `NodePorts` will be automatically allocated for services with type `LoadBalancer`. It may be set to `false` if the cluster load-balancer does not rely on `NodePorts`. If the caller requests specific `NodePorts` (by specifying a value), those requests will be respected, regardless of this field. This field may only be set for services with type `LoadBalancer`. Default is `true`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation)
* `allocate_load_balancer_node_ports` - (Optional) Defines if `NodePorts` will be automatically allocated for services with type `LoadBalancer`. It may be set to `false` if the cluster load-balancer does not rely on `NodePorts`. If the caller requests specific `NodePorts` (by specifying a value), those requests will be respected, regardless of this field. This field may only be set for services with type `LoadBalancer`. Default is `true`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation)
* `cluster_ip` - The IP address of the service. It is usually assigned randomly by the master. If an address is specified manually and is not in use by others, it will be allocated to the service; otherwise, creation of the service will fail. `None` can be specified for headless services when proxying is not required. Ignored if type is `ExternalName`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
* `cluster_ips` - (Optional) List of IP addresses assigned to this service, and are usually assigned randomly. If an address is specified manually and is not in use by others, it will be allocated to the service; otherwise creation of the service will fail. If this field is not specified, it will be initialized from the `clusterIP` field. If this field is specified, clients must ensure that `clusterIPs[0]` and `clusterIP` have the same value. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
* `external_ips` - A list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.
* `external_ips` - A list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.
* `external_name` - The external reference that kubedns or equivalent will return as a CNAME record for this service. No proxying will be involved. Must be a valid DNS name and requires `type` to be `ExternalName`.
* `external_traffic_policy` - (Optional) Denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. `Local` preserves the client source IP and avoids a second hop for LoadBalancer and Nodeport type services, but risks potentially imbalanced traffic spreading. `Cluster` obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading. For more info see [Kubernetes reference](https://kubernetes.io/docs/tutorials/services/source-ip/)
* `ip_families` - (Optional) A list of IP families (e.g. IPv4, IPv6) assigned to this service. This field is usually assigned automatically based on cluster configuration and the `ip_family_policy` field. If this field is specified manually, the requested family is available in the cluster, and `ip_family_policy` allows it, it will be used; otherwise creation of the service will fail. This field is conditionally mutable: it allows for adding or removing a secondary IP family, but it does not allow changing the primary IP family of the Service. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/dual-stack/)
@ -89,25 +87,25 @@ The following arguments are supported:
* `session_affinity_config` - (Optional) Contains the configurations of session affinity. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-ipvs)
* `type` - Determines how the service is exposed. Defaults to `ClusterIP`. Valid options are `ExternalName`, `ClusterIP`, `NodePort`, and `LoadBalancer`. `ExternalName` maps to the specified `external_name`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types)
## Attributes
* `status` - Status is a list containing the most recently observed status of the service. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
### `status`
#### Attributes
* `load_balancer` - a list containing the current status of the load-balancer, if one is present.
### `load_balancer`
#### Attributes
* `ingress` - a list containing ingress points for the load-balancer. Traffic intended for the service should be sent to these ingress points.
### `ingress`
#### Attributes
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `hostname` - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers).

10
website/docs/d/storage_class.html.markdown → docs/data-sources/storage_class.md
View file

@ -1,6 +1,5 @@
---
subcategory: "storage/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_storage_class"
description: |-
Storage class is the foundation of dynamic provisioning, allowing cluster administrators to define abstractions for the underlying storage platform.
@ -28,7 +27,6 @@ The following arguments are supported:
* `metadata` - (Required) Standard storage class's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
## Nested Blocks
### `metadata`
@ -38,8 +36,11 @@ The following arguments are supported:
* `name` - (Required) Name of the storage class, must be unique. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
### `allowed_topologies`

#### Arguments

* `match_label_expressions` - (Optional) A list of topology selector requirements by labels. See [match_label_expressions](#match_label_expressions)
@ -53,18 +54,15 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this storage class that can be used by clients to determine when storage class has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this storage class. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
## Argument Reference
The following attributes are exported:
* `parameters` - The parameters for the provisioner that creates volume of this storage class.
Read more about [available parameters](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#parameters).
* `parameters` - The parameters for the provisioner that creates volume of this storage class. Read more about [available parameters](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#parameters).
* `storage_provisioner` - Indicates the type of the provisioner this storage class represents
* `reclaim_policy` - Indicates the reclaim policy used.
* `volume_binding_mode` - Indicates when volume binding and dynamic provisioning should occur.

10
website/docs/d/storage_class_v1.html.markdown → docs/data-sources/storage_class_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "storage/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_storage_class_v1"
description: |-
Storage class is the foundation of dynamic provisioning, allowing cluster administrators to define abstractions for the underlying storage platform.
@ -28,7 +27,6 @@ The following arguments are supported:
* `metadata` - (Required) Standard storage class's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
## Nested Blocks
### `metadata`
@ -38,8 +36,11 @@ The following arguments are supported:
* `name` - (Required) Name of the storage class, must be unique. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
### `allowed_topologies`

#### Arguments

* `match_label_expressions` - (Optional) A list of topology selector requirements by labels. See [match_label_expressions](#match_label_expressions)
@ -53,18 +54,15 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this storage class that can be used by clients to determine when storage class has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this storage class. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
## Argument Reference
The following attributes are exported:
* `parameters` - The parameters for the provisioner that creates volume of this storage class.
Read more about [available parameters](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#parameters).
* `parameters` - The parameters for the provisioner that creates volume of this storage class. Read more about [available parameters](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#parameters).
* `storage_provisioner` - Indicates the type of the provisioner this storage class represents
* `reclaim_policy` - Indicates the reclaim policy used.
* `volume_binding_mode` - Indicates when volume binding and dynamic provisioning should occur.

7
website/docs/functions/manifest_decode.html.markdown → docs/functions/manifest_decode.md
View file

@ -1,6 +1,5 @@
---
subcategory: ""
layout: "kubernetes"
page_title: "manifest_decode function"
description: |-
Decode a Kubernetes YAML manifest
@ -12,7 +11,7 @@ Given a YAML text containing a Kubernetes manifest, will decode and return an ob
## Example Usage
```hcl
```terraform
# Configuration using provider functions must include required_providers configuration.
terraform {
required_providers {
@ -39,10 +38,8 @@ manifest_decode(manifest string) object
## Arguments
1. `manifest` (String) The YAML text for a Kubernetes manifest
## Return Type
The `object` returned from `manifest_decode` is dynamic and will mirror the structure of the YAML manifest supplied.
The `object` returned from `manifest_decode` is dynamic and will mirror the structure of the YAML manifest supplied.

7
website/docs/functions/manifest_decode_multi.html.markdown → docs/functions/manifest_decode_multi.md
View file

@ -1,6 +1,5 @@
---
subcategory: ""
layout: "kubernetes"
page_title: "manifest_decode_multi function"
description: |-
Decode a Kubernetes YAML manifest containing multiple resources
@ -12,7 +11,7 @@ Given a YAML text containing a Kubernetes manifest with multiple resources, will
## Example Usage
```hcl
```terraform
# Configuration using provider functions must include required_providers configuration.
terraform {
required_providers {
@ -39,10 +38,8 @@ manifest_decode_multi(manifest string) tuple
## Arguments
1. `manifest` (String) The YAML text for a Kubernetes manifest containing multiple resources
## Return Type
The `tuple` returned from `manifest_decode_multi` will contain dynamic objects that mirror the structure of the resources in YAML manifest supplied.
The `tuple` returned from `manifest_decode_multi` will contain dynamic objects that mirror the structure of the resources in YAML manifest supplied.

5
website/docs/functions/manifest_encode.html.markdown → docs/functions/manifest_encode.md
View file

@ -1,6 +1,5 @@
---
subcategory: ""
layout: "kubernetes"
page_title: "manifest_encode function"
description: |-
Decode a Kubernetes YAML manifest containing multiple resources
@ -12,7 +11,7 @@ Given an object representation of a Kubernetes manifest, will encode and return
## Example Usage
```hcl
```terraform
# Configuration using provider functions must include required_providers configuration.
terraform {
required_providers {
@ -52,10 +51,8 @@ manifest_encode(manifest object) string
## Arguments
1. `manifest` (String) The object representation of a Kubernetes manifest
## Return Type
The `string` returned from `manifest_encode` will contain the YAML encoded Kubernetes manifest.

116
docs/guides/alpha-manifest-migration-guide.md Normal file
View file

@ -0,0 +1,116 @@
---
subcategory: ""
page_title: "Migrating `kubernetes_manifest` resources from the kubernetes-alpha provider"
description: |-
This guide covers adopting `kubernetes_manifest` resources created using the kubernetes-alpha provider.
---
# The kubernetes_manifest resource
Earlier this year we announced a new provider capable of managing any kind of Kubernetes resource, but more specifically Custom Resources via a manifest configuration that could be translated directly from Kubernetes YAML. This was released as the experimental [kubernetes-alpha](https://github.com/hashicorp/terraform-provider-kubernetes-alpha) provider.
The `kubernetes_manifest` resource in now available in the official provider for Kubernetes. This guide walks through the actions needed to adopt existing `kubernetes_manifest` resources into configurations that use the Kubernetes provider.
Follow these steps to migrate your configuration and continue using the `kubernetes_manifest` resource with the Kubernetes provider.
## Step 1: Provider configuration blocks
The provider configuration blocks for the `kubernetes-alpha` provider are no longer supported. To carry over the configuration, simply rename the provider block to "kubernetes".
For example:
```
provider "kubernetes-alpha" {
config_path = "/my/kube/config"
}
```
becomes
```
provider "kubernetes" {
config_path = "/my/kube/config"
experiments {
manifest_resource = true
}
}
```
## Step 2: Provider references on resources
The provider references to `kubernetes-alpha` are no longer required. Simply remove the `provider = kubernetes-alpha` text from all `kubernetes_manifest` resources in your configuration.
For example:
```
resource "kubernetes_manifest" "my-resource" {
provider = kubernetes-alpha
manifest = {....}
}
```
becomes
```
resource "kubernetes_manifest" "my-resource" {
manifest = {....}
}
```
## Step 3: Provider version constraints
If your configuration includes a `terraform` block which specifies required provider versions, you should remove any references to provider `kubernetes-alpha` from that block. At the same time, you should add a requirement for provider `kubernetes` version 2.4.0 and above.
For example:
```
terraform {
required_providers {
kubernetes-alpha = {
source = "hashicorp/kubernetes-alpha"
version = "0.5.0"
}
...
}
}
```
becomes:
```
terraform {
required_providers {
kubernetes = {
source = "hashicorp/kubernetes"
version = ">= 2.4"
}
...
}
}
```
If you made any changes to existing entries in the `required_providers` section, make sure to run `terraform init -upgrade` to let Terraform retrieve any required new provider versions.
## Step 4: Replace providers in existing state
If your configuration was already in use with the `kubernetes_alpha` provider, you likely also have Terraform state generated from it.
It is recommended to start fresh and re-apply configurations using the kubernetes provider from a clean slate.
However, in case you find it necessary to preserve state, you can rename the provider associated with any `kubernetes_manifest` resources using the dedicated `replace-provider` command in Terraform.
Run the following command in the directory where the `terraform.tfstate` file is:
```
terraform state replace-provider hashicorp/kubernetes-alpha hashicorp/kubernetes
```
## Mixing 'kubernetes_manifest' with other 'kubernetes_*' resources
In case you plan on adding `kubernetes_manifest` resources to your existing configuration which contains other resources of the Kubernetes provider there are some important aspects to be aware of.
If your present configuration for the Kubernetes provider also creates the Kubernetes cluster using Terraform resources in the same `apply` operation (against best-practice recommendations), this will no longer work when adding `kubernetes_manifest` resources. The reason behind this is that `kubernetes_manifest` require access to the API during planning, at which point the cluster resource would not have yet been created.
As a solution, choose one of the following options:
* separate the cluster creation in a different `apply` operation.
* add a new `apply` operation only for the `kubernetes_manifest` resources.

747
docs/guides/getting-started.html.md Normal file
View file

@ -0,0 +1,747 @@
---
subcategory: ""
page_title: "Kubernetes: Getting Started with Kubernetes provider"
description: |-
This guide focuses on configuring authentication to your existing Kubernetes
cluster so that resources can be managed using the Kubernetes provider for Terraform.
---
# Getting Started with Kubernetes provider
## Kubernetes
-> Visit the [Manage Kubernetes Resources via Terraform](https://learn.hashicorp.com/tutorials/terraform/kubernetes-provider?in=terraform/kubernetes&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) Learn tutorial for an interactive getting
started experience.
[Kubernetes](https://kubernetes.io/) (K8S) is an open-source workload scheduler with focus on containerized applications.
There are at least 2 steps involved in scheduling your first container
on a Kubernetes cluster. You need the Kubernetes cluster with all its components
running _somewhere_ and then define the Kubernetes resources, such as Deployments, Services, etc.
This guide focuses mainly on the latter part and expects you to have
a properly configured & running Kubernetes cluster.
## Why Terraform
While you could use `kubectl` or similar CLI-based tools mapped to API calls
to manage all Kubernetes resources described in YAML files,
orchestration with Terraform presents a few benefits.
- Use the same [configuration language](/docs/configuration/syntax.html)
to provision the Kubernetes infrastructure and to deploy applications into it.
- drift detection - `terraform plan` will always present you the difference
between reality at a given time and config you intend to apply.
- full lifecycle management - Terraform doesn't just initially create resources,
but offers a single command for creation, update, and deletion of tracked
resources without needing to inspect the API to identify those resources.
- synchronous feedback - While asynchronous behaviour is often useful,
sometimes it's counter-productive as the job of identifying operation result
(failures or details of created resource) is left to the user. e.g. you don't
have IP/hostname of load balancer until it has finished provisioning,
hence you can't create any DNS record pointing to it.
- [graph of relationships](https://www.terraform.io/docs/internals/graph.html) -
Terraform understands relationships between resources which may help
in scheduling - e.g. if a Persistent Volume Claim claims space from
a particular Persistent Volume Terraform won't even attempt to create
the PVC if creation of the PV has failed.
## Provider Setup
The provider needs to be configured with the proper credentials before it can be used. The simplest configuration is to specify the kubeconfig path:
```hcl
provider "kubernetes" {
config_path = "~/.kube/config"
}
```
Another configuration option is to **statically** define TLS certificate credentials:
```hcl
provider "kubernetes" {
host = "https://104.196.242.174"
client_certificate = "${file("~/.kube/client-cert.pem")}"
client_key = "${file("~/.kube/client-key.pem")}"
cluster_ca_certificate = "${file("~/.kube/cluster-ca-cert.pem")}"
}
```
Static TLS certficate credentials are present in Azure AKS clusters by default, and can be used with the [azurerm_kubernetes_cluster](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/data-sources/kubernetes_cluster) data source as shown below. This will automatically read the certficate information from the AKS cluster and pass it to the Kubernetes provider.
```hcl
data "azurerm_kubernetes_cluster" "example" {
name = "myakscluster"
resource_group_name = "my-example-resource-group"
}
provider "kubernetes" {
host = "${data.azurerm_kubernetes_cluster.example.kube_config.0.host}"
client_certificate = "${base64decode(data.azurerm_kubernetes_cluster.example.kube_config.0.client_certificate)}"
client_key = "${base64decode(data.azurerm_kubernetes_cluster.example.kube_config.0.client_key)}"
cluster_ca_certificate = "${base64decode(data.azurerm_kubernetes_cluster.example.kube_config.0.cluster_ca_certificate)}"
}
```
Another option is to use an oauth token, such as this example from a GKE cluster. The [google_client_config](https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/client_config) data source fetches a token from the Google Authorization server, which expires in 1 hour by default.
```hcl
data "google_client_config" "default" {}
data "google_container_cluster" "my_cluster" {
name = "my-cluster"
location = "us-east1-a"
}
provider "kubernetes" {
host = "https://${data.google_container_cluster.my_cluster.endpoint}"
token = data.google_client_config.default.access_token
cluster_ca_certificate = base64decode(data.google_container_cluster.my_cluster.master_auth[0].cluster_ca_certificate)
}
```
For short-lived authentication tokens, like those found in EKS, which [expire in 15 minutes](https://aws.github.io/aws-eks-best-practices/security/docs/iam#controlling-access-to-eks-clusters), an exec-based credential plugin can be used to ensure the token is always up to date:
```hcl
data "aws_eks_cluster" "example" {
name = "example"
}
data "aws_eks_cluster_auth" "example" {
name = "example"
}
provider "kubernetes" {
host = data.aws_eks_cluster.example.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.example.certificate_authority[0].data)
exec {
api_version = "client.authentication.k8s.io/v1beta1"
args = ["eks", "get-token", "--cluster-name", var.cluster_name]
command = "aws"
}
}
```
## Creating your first Kubernetes resources
Once the provider is configured, you can apply the Kubernetes resources defined in your Terraform config file. The following is an example Terraform config file containing a few Kubernetes resources. We'll use [minikube](https://minikube.sigs.k8s.io/docs/start/) for the Kubernetes cluster in this example, but any Kubernetes cluster can be used. Ensure that a Kubernetes cluster of some kind is running before applying the example config below.
This configuration will create a scalable Nginx Deployment with 2 replicas. It will expose the Nginx frontend using a Service of type NodePort, which will make Nginx accessible via the public IP of the node running the containers.
```hcl
terraform {
required_providers {
kubernetes = {
source = "hashicorp/kubernetes"
version = ">= 2.0.0"
}
}
}
provider "kubernetes" {
config_path = "~/.kube/config"
}
resource "kubernetes_namespace" "test" {
metadata {
name = "nginx"
}
}
resource "kubernetes_deployment" "test" {
metadata {
name = "nginx"
namespace = kubernetes_namespace.test.metadata.0.name
}
spec {
replicas = 2
selector {
match_labels = {
app = "MyTestApp"
}
}
template {
metadata {
labels = {
app = "MyTestApp"
}
}
spec {
container {
image = "nginx"
name = "nginx-container"
port {
container_port = 80
}
}
}
}
}
}
resource "kubernetes_service" "test" {
metadata {
name = "nginx"
namespace = kubernetes_namespace.test.metadata.0.name
}
spec {
selector = {
app = kubernetes_deployment.test.spec.0.template.0.metadata.0.labels.app
}
type = "NodePort"
port {
node_port = 30201
port = 80
target_port = 80
}
}
}
```
Use `terraform init` to download the specified version of the Kubernetes provider:
```
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/kubernetes versions matching "2.0"...
- Installing hashicorp/kubernetes v2.0...
- Installed hashicorp/kubernetes v2.0 (unauthenticated)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
```
Next, use `terraform plan` to display a list of resources to be created, and highlight any possible unknown attributes at apply time. For Deployments, all disk options are shown at plan time, but none will be created unless explicitly configured in the Deployment resource.
```
$ terraform plan
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# kubernetes_deployment.test will be created
+ resource "kubernetes_deployment" "test" {
+ id = (known after apply)
+ wait_for_rollout = true
+ metadata {
+ generation = (known after apply)
+ name = "nginx"
+ namespace = "nginx"
+ resource_version = (known after apply)
+ uid = (known after apply)
}
+ spec {
+ min_ready_seconds = 0
+ paused = false
+ progress_deadline_seconds = 600
+ replicas = "2"
+ revision_history_limit = 10
+ selector {
+ match_labels = {
+ "app" = "MyTestApp"
}
}
+ strategy {
+ type = (known after apply)
+ rolling_update {
+ max_surge = (known after apply)
+ max_unavailable = (known after apply)
}
}
+ template {
+ metadata {
+ generation = (known after apply)
+ labels = {
+ "app" = "MyTestApp"
}
+ name = (known after apply)
+ resource_version = (known after apply)
+ uid = (known after apply)
}
+ spec {
+ automount_service_account_token = true
+ dns_policy = "ClusterFirst"
+ enable_service_links = true
+ host_ipc = false
+ host_network = false
+ host_pid = false
+ hostname = (known after apply)
+ node_name = (known after apply)
+ restart_policy = "Always"
+ service_account_name = (known after apply)
+ share_process_namespace = false
+ termination_grace_period_seconds = 30
+ container {
+ image = "nginx"
+ image_pull_policy = (known after apply)
+ name = "nginx-container"
+ stdin = false
+ stdin_once = false
+ termination_message_path = "/dev/termination-log"
+ termination_message_policy = (known after apply)
+ tty = false
+ port {
+ container_port = 80
+ protocol = "TCP"
}
+ resources {
+ limits = (known after apply)
+ requests = (known after apply)
}
+ volume_mount {
+ mount_path = (known after apply)
+ mount_propagation = (known after apply)
+ name = (known after apply)
+ read_only = (known after apply)
+ sub_path = (known after apply)
}
}
+ image_pull_secrets {
+ name = (known after apply)
}
+ readiness_gate {
+ condition_type = (known after apply)
}
+ volume {
+ name = (known after apply)
+ aws_elastic_block_store {
+ fs_type = (known after apply)
+ partition = (known after apply)
+ read_only = (known after apply)
+ volume_id = (known after apply)
}
+ azure_disk {
+ caching_mode = (known after apply)
+ data_disk_uri = (known after apply)
+ disk_name = (known after apply)
+ fs_type = (known after apply)
+ kind = (known after apply)
+ read_only = (known after apply)
}
+ azure_file {
+ read_only = (known after apply)
+ secret_name = (known after apply)
+ share_name = (known after apply)
+ secret_namespace = (known after apply)
}
+ ceph_fs {
+ monitors = (known after apply)
+ path = (known after apply)
+ read_only = (known after apply)
+ secret_file = (known after apply)
+ user = (known after apply)
+ secret_ref {
+ name = (known after apply)
+ namespace = (known after apply)
}
}
+ cinder {
+ fs_type = (known after apply)
+ read_only = (known after apply)
+ volume_id = (known after apply)
}
+ config_map {
+ default_mode = (known after apply)
+ name = (known after apply)
+ optional = (known after apply)
+ items {
+ key = (known after apply)
+ mode = (known after apply)
+ path = (known after apply)
}
}
+ csi {
+ driver = (known after apply)
+ fs_type = (known after apply)
+ read_only = (known after apply)
+ volume_attributes = (known after apply)
+ volume_handle = (known after apply)
+ controller_expand_secret_ref {
+ name = (known after apply)
+ namespace = (known after apply)
}
+ controller_publish_secret_ref {
+ name = (known after apply)
+ namespace = (known after apply)
}
+ node_publish_secret_ref {
+ name = (known after apply)
+ namespace = (known after apply)
}
+ node_stage_secret_ref {
+ name = (known after apply)
+ namespace = (known after apply)
}
}
+ downward_api {
+ default_mode = (known after apply)
+ items {
+ mode = (known after apply)
+ path = (known after apply)
+ field_ref {
+ api_version = (known after apply)
+ field_path = (known after apply)
}
+ resource_field_ref {
+ container_name = (known after apply)
+ divisor = (known after apply)
+ resource = (known after apply)
}
}
}
+ empty_dir {
+ medium = (known after apply)
+ size_limit = (known after apply)
}
+ fc {
+ fs_type = (known after apply)
+ lun = (known after apply)
+ read_only = (known after apply)
+ target_ww_ns = (known after apply)
}
+ flex_volume {
+ driver = (known after apply)
+ fs_type = (known after apply)
+ options = (known after apply)
+ read_only = (known after apply)
+ secret_ref {
+ name = (known after apply)
+ namespace = (known after apply)
}
}
+ flocker {
+ dataset_name = (known after apply)
+ dataset_uuid = (known after apply)
}
+ gce_persistent_disk {
+ fs_type = (known after apply)
+ partition = (known after apply)
+ pd_name = (known after apply)
+ read_only = (known after apply)
}
+ git_repo {
+ directory = (known after apply)
+ repository = (known after apply)
+ revision = (known after apply)
}
+ glusterfs {
+ endpoints_name = (known after apply)
+ path = (known after apply)
+ read_only = (known after apply)
}
+ host_path {
+ path = (known after apply)
+ type = (known after apply)
}
+ iscsi {
+ fs_type = (known after apply)
+ iqn = (known after apply)
+ iscsi_interface = (known after apply)
+ lun = (known after apply)
+ read_only = (known after apply)
+ target_portal = (known after apply)
}
+ local {
+ path = (known after apply)
}
+ nfs {
+ path = (known after apply)
+ read_only = (known after apply)
+ server = (known after apply)
}
+ persistent_volume_claim {
+ claim_name = (known after apply)
+ read_only = (known after apply)
}
+ photon_persistent_disk {
+ fs_type = (known after apply)
+ pd_id = (known after apply)
}
+ projected {
+ default_mode = (known after apply)
+ sources {
+ config_map {
+ name = (known after apply)
+ optional = (known after apply)
+ items {
+ key = (known after apply)
+ mode = (known after apply)
+ path = (known after apply)
}
}
+ downward_api {
+ items {
+ mode = (known after apply)
+ path = (known after apply)
+ field_ref {
+ api_version = (known after apply)
+ field_path = (known after apply)
}
+ resource_field_ref {
+ container_name = (known after apply)
+ quantity = (known after apply)
+ resource = (known after apply)
}
}
}
+ secret {
+ name = (known after apply)
+ optional = (known after apply)
+ items {
+ key = (known after apply)
+ mode = (known after apply)
+ path = (known after apply)
}
}
+ service_account_token {
+ audience = (known after apply)
+ expiration_seconds = (known after apply)
+ path = (known after apply)
}
}
}
+ quobyte {
+ group = (known after apply)
+ read_only = (known after apply)
+ registry = (known after apply)
+ user = (known after apply)
+ volume = (known after apply)
}
+ rbd {
+ ceph_monitors = (known after apply)
+ fs_type = (known after apply)
+ keyring = (known after apply)
+ rados_user = (known after apply)
+ rbd_image = (known after apply)
+ rbd_pool = (known after apply)
+ read_only = (known after apply)
+ secret_ref {
+ name = (known after apply)
+ namespace = (known after apply)
}
}
+ secret {
+ default_mode = (known after apply)
+ optional = (known after apply)
+ secret_name = (known after apply)
+ items {
+ key = (known after apply)
+ mode = (known after apply)
+ path = (known after apply)
}
}
+ vsphere_volume {
+ fs_type = (known after apply)
+ volume_path = (known after apply)
}
}
}
}
}
}
# kubernetes_namespace.test will be created
+ resource "kubernetes_namespace" "test" {
+ id = (known after apply)
+ metadata {
+ generation = (known after apply)
+ name = "nginx"
+ resource_version = (known after apply)
+ uid = (known after apply)
}
}
# kubernetes_service.test will be created
+ resource "kubernetes_service" "test" {
+ id = (known after apply)
+ status = (known after apply)
+ wait_for_load_balancer = true
+ metadata {
+ generation = (known after apply)
+ name = "nginx"
+ namespace = "nginx"
+ resource_version = (known after apply)
+ uid = (known after apply)
}
+ spec {
+ cluster_ip = (known after apply)
+ external_traffic_policy = (known after apply)
+ health_check_node_port = (known after apply)
+ publish_not_ready_addresses = false
+ selector = {
+ "app" = "MyTestApp"
}
+ session_affinity = "None"
+ type = "NodePort"
+ port {
+ node_port = 30201
+ port = 80
+ protocol = "TCP"
+ target_port = "80"
}
}
}
Plan: 3 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
```
Use `terraform apply` to create the resources shown above.
```
$ terraform apply --auto-approve
kubernetes_namespace.test: Creating...
kubernetes_namespace.test: Creation complete after 0s [id=nginx]
kubernetes_deployment.test: Creating...
kubernetes_deployment.test: Creation complete after 7s [id=nginx/nginx]
kubernetes_service.test: Creating...
kubernetes_service.test: Creation complete after 0s [id=nginx/nginx]
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
```
The resources are now visible in the Kubernetes cluster.
```
$ kubectl get all -n nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-86c669bff4-8g7g2 1/1 Running 0 38s
pod/nginx-86c669bff4-zgjkv 1/1 Running 0 38s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/nginx NodePort 10.109.205.23 <none> 80:30201/TCP 30s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx 2/2 2 2 38s
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-86c669bff4 2 2 2 38s
```
The web server can be accessed using the public IP of the node running the Deployment. In this example, we're using minikube as the Kubernetes cluster, so the IP can be fetched using `minikube ip`.
```
$ curl $(minikube ip):30201
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
```
Alternatively, look for the hostIP associated with a running Nginx pod and combine it with the NodePort to assemble the URL:
```
$ kubectl get pod nginx-86c669bff4-zgjkv -n nginx -o json | jq .status.hostIP
"192.168.39.189"
$ kubectl get services -n nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx NodePort 10.109.205.23 <none> 80:30201/TCP 19m
$ curl 192.168.39.189:30201
```

305
docs/guides/v2-upgrade-guide.md Normal file
View file

@ -0,0 +1,305 @@
---
subcategory: ""
page_title: "Kubernetes: Upgrade Guide for Kubernetes Provider v2.0.0"
description: |-
This guide covers the changes introduced in v2.0.0 of the Kubernetes provider and what you may need to do to upgrade your configuration.
---
# Upgrading to v2.0.0 of the Kubernetes provider
This guide covers the changes introduced in v2.0.0 of the Kubernetes provider and what you may need to do to upgrade your configuration.
Use `terraform init` to install version 2 of the provider. Then run `terraform plan` to determine if the upgrade will affect any existing resources. Some resources will have updated defaults and may be modified as a result. To opt out of this change, see the guide below and update your Terraform config file to match the existing resource settings (for example, set `automount_service_account_token=false`). Then run `terraform plan` again to ensure no resource updates will be applied.
NOTE: Even if there are no resource updates to apply, you may need to run `terraform refresh` to update your state to the newest version. Otherwise, some commands might fail with `Error: missing expected {`.
## Installing and testing this update
The `required_providers` block can be used to move between version 1.x and version 2.x of the Kubernetes provider, for testing purposes. Please note that this is only possible using `terraform plan`. Once you run `terraform apply` or `terraform refresh`, the changes to Terraform State become permanent, and rolling back is no longer an option. It may be possible to roll back the State by making a copy of `.terraform.tfstate` before running `apply` or `refresh`, but this configuration is unsupported.
### Using required_providers to test the update
The version of the Kubernetes provider can be controlled using the `required_providers` block:
```hcl
terraform {
required_providers {
kubernetes = {
source = "hashicorp/kubernetes"
version = ">= 2.0"
}
}
}
```
When the above code is in place, run `terraform init` to upgrade the provider version.
```
$ terraform init -upgrade
```
Ensure you have a valid provider block for 2.0 before proceeding with the `terraform plan` below. In version 2.0 of the provider, [provider configuration is now required](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs). A quick way to get up and running with the new provider configuration is to set `KUBE_CONFIG_PATH` to point to your existing kubeconfig.
```
export KUBE_CONFIG_PATH=$KUBECONFIG
```
Then run `terraform plan` to see what changes will be applied. This example shows the specific fields that would have been modified, and their effect on the resources, such as replacement or an in-place update. Some output is omitted for clarity.
```
$ export KUBE_CONFIG_PATH=$KUBECONFIG
$ terraform plan
kubernetes_pod.test: Refreshing state... [id=default/test]
kubernetes_job.test: Refreshing state... [id=default/test]
kubernetes_stateful_set.test: Refreshing state... [id=default/test]
kubernetes_deployment.test: Refreshing state... [id=default/test]
kubernetes_daemonset.test: Refreshing state... [id=default/test]
kubernetes_cron_job.test: Refreshing state... [id=default/test]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
-/+ destroy and then create replacement
Terraform will perform the following actions:
# kubernetes_cron_job.test must be replaced
-/+ resource "kubernetes_cron_job" "test" {
~ enable_service_links = false -> true # forces replacement
# kubernetes_daemonset.test will be updated in-place
~ resource "kubernetes_daemonset" "test" {
+ wait_for_rollout = true
~ template {
~ spec {
~ enable_service_links = false -> true
# kubernetes_deployment.test will be updated in-place
~ resource "kubernetes_deployment" "test" {
~ spec {
~ enable_service_links = false -> true
# kubernetes_job.test must be replaced
-/+ resource "kubernetes_job" "test" {
~ enable_service_links = false -> true # forces replacement
# kubernetes_stateful_set.test will be updated in-place
~ resource "kubernetes_stateful_set" "test" {
~ spec {
~ enable_service_links = false -> true
Plan: 2 to add, 3 to change, 2 to destroy.
```
Using the output from `terraform plan`, you can make modifications to your existing Terraform config, to avoid any unwanted resource changes. For example, in the above config, adding `enable_service_links = false` to the resources would prevent any changes from occurring to the existing resources.
#### Known limitation: Pod data sources need manual upgrade
During `terraform plan`, you might encounter the error below:
```
Error: .spec[0].container[0].resources[0].limits: missing expected {
```
This ocurrs when a Pod data source is present during upgrade. To work around this error, remove the data source from state and try the plan again.
```
$ terraform state rm data.kubernetes_pod.test
Removed data.kubernetes_pod.test
Successfully removed 1 resource instance(s).
$ terraform plan
```
The data source will automatically be added back to state with data from the upgraded schema.
### Rolling back to version 1.x
If you've run the above upgrade and plan, but you don't want to proceed with the 2.0 upgrade, you can roll back using the following steps. NOTE: this will only work if you haven't run `terraform apply` or `terraform refresh` while testing version 2 of the provider.
```
$ terraform version
Terraform v0.14.4
+ provider registry.terraform.io/hashicorp/kubernetes v2.0
```
Set the provider version back to 1.x.
```
terraform {
required_providers {
kubernetes = {
source = "hashicorp/kubernetes"
version = "1.13"
}
}
}
```
Then run `terraform init -upgrade` to install the old provider version.
```
$ terraform init -upgrade
Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/kubernetes versions matching "1.13.0"...
- Installing hashicorp/kubernetes v1.13.0...
- Installed hashicorp/kubernetes v1.13.0 (signed by HashiCorp)
```
The provider is now downgraded.
```
$ terraform version
Terraform v0.14.4
+ provider registry.terraform.io/hashicorp/kubernetes v1.13.0
```
## Changes in v2.0.0
### Changes to Kubernetes credentials supplied in the provider block
We have made several changes to the way access to Kubernetes is configured in the provider block.
1. The `load_config_file` attribute has been removed.
2. Support for the `KUBECONFIG` environment variable has been dropped. (Use `KUBE_CONFIG_PATH` or `KUBE_CONFIG_PATHS` instead).
3. The `config_path` attribute will no longer default to `~/.kube/config`.
The above changes have been made to encourage the best practice of configuring access to Kubernetes in the provider block explicitly, instead of relying upon default paths or `KUBECONFIG` being set. We have done this because allowing the provider to configure its access to Kubernetes implicitly caused confusion with a subset of our users. It also created risk for users who use Terraform to manage multiple clusters. Requiring explicit configuration for Kubernetes in the provider block eliminates the possibility that the configuration will be applied to the wrong cluster.
You will therefore need to explicitly configure access to your Kubernetes cluster in the provider block going forward. For many users this will simply mean specifying the `config_path` attribute in the provider block. Users already explicitly configuring the provider should not be affected by this change, but will need to remove the `load_config_file` attribute if they are currently using it.
### Changes to the `load_balancers_ingress` block on Service and Ingress
We changed the `load_balancers_ingress` block on the Service and Ingress resources and data sources to align with the upstream Kubernetes API. `load_balancers_ingress` was a computed attribute that allowed users to obtain the `ip` or `hostname` of a `load_balancer`. Instead of `load_balancers_ingress`, users should use `status[].load_balancer[].ingress[]` to obtain the `ip` or `hostname` attributes.
```hcl
output "ingress_hostname" {
value = kubernetes_ingress.example_ingress.status[0].load_balancer[0].ingress[0].hostname
}
```
### The `automount_service_account_token` attribute now defaults to `true` on Service, Deployment, StatefulSet, and DaemonSet
Previously if `automount_service_account_token = true` was not set on the Service, Deployment, StatefulSet, or DaemonSet resources, the service account token was not mounted, even when a `service_account_name` was specified. This lead to confusion for many users, because our implementation did not align with the default behavior of the Kubernetes API, which defaults to `true` for this attribute.
```hcl
resource "kubernetes_deployment" "example" {
metadata {
name = "terraform-example"
labels = {
test = "MyExampleApp"
}
}
spec {
replicas = 1
selector {
match_labels = {
test = "MyExampleApp"
}
}
template {
metadata {
labels = {
test = "MyExampleApp"
}
}
spec {
container {
image = "nginx:1.21.6"
name = "example"
}
service_account_name = "default"
automount_service_account_token = false
}
}
}
}
```
### Normalize wait defaults across Deployment, DaemonSet, StatefulSet, Service, Ingress, and Job
All of the `wait_for` attributes now default to `true`, including:
- `wait_for_rollout` on the `kubernetes_deployment`, `kubernetes_daemonset`, and `kubernetes_stateful_set` resources
- `wait_for_loadbalancer` on the `kubernetes_service` and `kubernetes_ingress` resources
- `wait_for_completion` on the `kubernetes_job` resource
Previously some of them defaulted to `false` while others defaulted to `true`, causing an inconsistent user experience. If you don't want Terraform to wait for the specified condition before moving on, you must now always set the appropriate attribute to `false`
```hcl
resource "kubernetes_service" "myapp1" {
metadata {
name = "myapp1"
}
spec {
selector = {
app = kubernetes_pod.example.metadata[0].labels.app
}
session_affinity = "ClientIP"
type = "LoadBalancer"
port {
port = 8080
target_port = 80
}
}
wait_for_load_balancer = "false"
}
```
### Changes to the `limits` and `requests` attributes on all resources that support a PodSpec
The `limits` and `requests` attributes on all resources that include a PodSpec, are now a map. This means that `limits {}` must be changed to `limits = {}`, and the same for `requests`. This change impacts the following resources: `kubernetes_deployment`, `kubernetes_daemonset`, `kubernetes_stateful_set`, `kubernetes_pod`, `kubernetes_job`, `kubernetes_cron_job`.
This change was made to enable the use of extended resources, such as GPUs, in these fields.
```hcl
resource "kubernetes_pod" "test" {
metadata {
name = "terraform-example"
}
spec {
container {
image = "nginx:1.21.6"
name = "example"
resources {
limits = {
cpu = "0.5"
memory = "512Mi"
"nvidia/gpu" = "1"
}
requests = {
cpu = "250m"
memory = "50Mi"
"nvidia/gpu" = "1"
}
}
}
}
}
```
### Dropped support for Terraform 0.11
All builds of the Kubernetes provider going forward will no longer work with Terraform 0.11. See [Upgrade Guides](https://www.terraform.io/upgrade-guides/index.html) for how to migrate your configurations to a newer version of Terraform.
### Upgrade to v2 of the Terraform Plugin SDK
Contributors to the provider will be interested to know this upgrade has brought the latest version of the [Terraform Plugin SDK](https://github.com/hashicorp/terraform-plugin-sdk) which introduced a number of enhancements to the developer experience. Details of the changes introduced can be found under [Extending Terraform](https://www.terraform.io/docs/extend/guides/v2-upgrade-guide.html).

62
docs/guides/versioned-resources.md Normal file
View file

@ -0,0 +1,62 @@
---
subcategory: ""
page_title: "Versioned resource names"
description: |-
This guide explains the naming conventions for resources and data sources in the Kubernetes provider.
---
# Versioned resource names
This guide explains the naming conventions for resources and data sources in the Kubernetes provider.
## Version suffixes
From provider version v2.7.0 onwards Terraform resources and data sources that cover the [standard set of Kubernetes APIs](https://kubernetes.io/docs/reference/kubernetes-api/) will be suffixed with their corresponding Kubernetes API version (e.g `v1`, `v2`, `v2beta1`). The existing resources in the provider will continue to be maintained as is.
## Motivation
We are doing this to make it easier to use and maintain the provider, and to promote long-term stability and backwards compatibility with resources in the Kubernetes API as they reach maturity, and as the provider sees wider adoption.
Because Terraform does not support configurable schema versions for individual resources in the same way that the Kubernetes API does, the user sees a simpler unversioned schema for the Terraform resource. This is sometimes a good thing as the user is not burdened by Kubernetes API groups and versions, but it has caused confusion as the Kubernetes API evolves while the Terraform provider still has to support older versions of API resources. This also burdens the user with having to version pin the provider if they still rely upon a specific API version in their configuration.
In the past we have tried to support multiple Kubernetes API versions using a single Terraform resource with varying degrees of success. The [kubernetes_horizontal_pod_autoscaler](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/horizontal_pod_autoscaler) supports multiple versions of the autoscaling API by having a schema that includes attributes from both the `v1` and `v2beta2` APIs and then looks which attributes have been set to determine the appropriate Kubernetes API version to use. The [kubernetes_mutating_webhook_configuration](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/mutating_webhook_configuration) and [kubernetes_validating_webhook_configuration](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/validating_webhook_configuration) resources use the discovery client to determine which version of the `admissionregistration` API the cluster supports. These approaches seem reasonable but lead to Terraform resource schemas where it is not obvious which attributes are actually supported by the target cluster, and creates an unsustainable maintenance burden as a resource has to be cobbled together by hand to support multiple API versions.
Ultimately, we plan to completely automate the generation of Terraform resources to cover the core Kubernetes API. Having a set of versioned schemas that more closely matches the Kubernetes API definition is going to make this easier to achieve and will enable us to add built-in support for new API versions much faster.
## What will happen to the resources without versions in the name?
These resources will continue to be supported and maintained as is through to v3.0.0 of the provider, at which point they will be marked as deprecated and then subsequently removed in v4.0.0.
## `v1` and above resources
Resources suffixed with a major version number are considered to have stable APIs that will not change. These resources will be supported by the provider so long as the API version continues to be supported by the Kubernetes API, and likely for some time after it is deprecated and removed as there is often a long tail of migration as users of the provider continue to support legacy infrastructure.
While the API contract for these resources is assumed to be concrete, we will still accept changes to add additional attributes to these resources for configuring convenience features such as the `wait_for_rollout` attribute seen on resources such as `kubernetes_deployment`. Changes to these attributes should always be accompanied by deprecation warnings, state upgraders, and follow our typical [semantic versioning](https://www.terraform.io/docs/extend/best-practices/versioning.html#versioning-specification) scheme.
## `beta` resources
We will continue to bring support for API resources which reach `beta` however it is expected that the API contract for these resources can still change and so they should be used with some caution. When a `beta` API changes we will provide a state upgrader for the resource where possible. Refer to the Kubernetes API documentation on the use of [beta resources](https://kubernetes.io/docs/reference/using-api/#api-versioning).
## `alpha` resources
We will continue our policy of not building support for `alpha` versioned resources into the provider. Please use the [kubernetes_manifest](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/manifest) resource to manage those resources.
## How can I move a resource without a version to its versioned resource name?
The simplest, non-destructive way to do this is to modify the name of the resource to include the version suffix. Then remove the old resource from state and import the resource under the versioned resource like so:
```
terraform state rm kubernetes_config_map.example
terraform import kubernetes_config_map_v1.example default/example
```
Then run `terraform plan` to confirm that the import was successful. **NOTE: Do not run the plan after renaming the resource in the configuration until after the above steps have been carried out.**
You can also skip this and just allow Terraform to destroy and recreate the resource, but this is not recommended for resources like `kubernetes_service` and `kubernetes_deployment`.

37
website/docs/index.html.markdown → docs/index.md
View file

@ -1,5 +1,4 @@
---
layout: "kubernetes"
page_title: "Provider: Kubernetes"
description: |-
The Kubernetes (K8s) provider is used to interact with the resources supported by Kubernetes. The provider needs to be configured with the proper credentials before it can be used.
@ -13,7 +12,7 @@ Use the navigation to the left to read about the available resources.
## Example Usage
```hcl
```terraform
provider "kubernetes" {
config_path = "~/.kube/config"
config_context = "my-context"
@ -28,10 +27,7 @@ resource "kubernetes_namespace" "example" {
## Kubernetes versions
Both backward and forward compatibility with Kubernetes API is mostly defined
by the [official K8S Go library](https://github.com/kubernetes/kubernetes) (prior to `1.1` release)
and [client Go library](https://github.com/kubernetes/client-go) which we ship with Terraform.
Below are versions of the library bundled with given versions of Terraform.
Both backward and forward compatibility with Kubernetes API is mostly defined by the [official K8S Go library](https://github.com/kubernetes/kubernetes) (prior to `1.1` release) and [client Go library](https://github.com/kubernetes/client-go) which we ship with Terraform. Below are versions of the library bundled with given versions of Terraform.
* Terraform `<= 0.9.6` (prior to provider split) - Kubernetes `1.5.4`
* Terraform `0.9.7` (prior to provider split) `< 1.1` (provider version) - Kubernetes `1.6.1`
@ -49,33 +45,28 @@ The most reliable way to configure the Kubernetes provider is to ensure that the
For specific usage examples, see the guides for [AKS](https://github.com/hashicorp/terraform-provider-kubernetes/blob/main/_examples/aks/README.md), [EKS](https://github.com/hashicorp/terraform-provider-kubernetes/blob/main/_examples/eks/README.md), and [GKE](https://github.com/hashicorp/terraform-provider-kubernetes/blob/main/_examples/gke/README.md).
## Authentication
~> NOTE: The provider does not use the `KUBECONFIG` environment variable by default. See the attribute reference below for the environment variables that map to provider block attributes.
The Kubernetes provider can get its configuration in two ways:
1. _Explicitly_ by supplying attributes to the provider block. This includes:
1. *Explicitly* by supplying attributes to the provider block. This includes:
* [Using a kubeconfig file](#file-config)
* [Supplying credentials](#credentials-config)
* [Exec plugins](#exec-plugins)
2. _Implicitly_ through environment variables. This includes:
2. *Implicitly* through environment variables. This includes:
* [Using the in-cluster config](#in-cluster-config)
The provider always first tries to load **a config file** from a given location
when `config_path` or `config_paths` (or their equivalent environment variables) are set.
Depending on whether you have a current context set this _may_ require
`config_context_auth_info` and/or `config_context_cluster` and/or `config_context`.
The provider always first tries to load **a config file** from a given location when `config_path` or `config_paths` (or their equivalent environment variables) are set. Depending on whether you have a current context set this *may* require `config_context_auth_info` and/or `config_context_cluster` and/or `config_context`.
For a full list of supported provider authentication arguments and their corresponding environment variables, see the [argument reference](#argument-reference) below.
### File config
The easiest way is to supply a path to your kubeconfig file using the `config_path` attribute or using the `KUBE_CONFIG_PATH` environment variable. A kubeconfig file may have multiple contexts. If `config_context` is not specified, the provider will use the `default` context.
```hcl
```terraform
provider "kubernetes" {
config_path = "~/.kube/config"
}
@ -83,7 +74,7 @@ provider "kubernetes" {
The provider also supports multiple paths in the same way that kubectl does using the `config_paths` attribute or `KUBE_CONFIG_PATHS` environment variable.
```hcl
```terraform
provider "kubernetes" {
config_paths = [
"/path/to/config_a.yaml",
@ -96,7 +87,7 @@ provider "kubernetes" {
You can also configure the host, basic auth credentials, and client certificate authentication explicitly or through environment variables.
```hcl
```terraform
provider "kubernetes" {
host = "https://cluster_endpoint:port"
@ -120,7 +111,7 @@ Some cloud providers have short-lived authentication tokens that can expire rela
~> IMPORTANT: DO NOT mix `exec` blocks with other credential attributes such as `token` or `client_certificate` in the provider configuration. This leads to undefined behaviour and there is no guarantee about which credential will actually be used.
```hcl
```terraform
provider "kubernetes" {
host = var.cluster_endpoint
cluster_ca_certificate = base64decode(var.cluster_ca_cert)
@ -132,7 +123,7 @@ provider "kubernetes" {
}
```
## Examples
## Examples
For further reading, see these examples which demonstrate different approaches to keeping the cluster credentials up to date: [AKS](https://github.com/hashicorp/terraform-provider-kubernetes/blob/main/_examples/aks/README.md), [EKS](https://github.com/hashicorp/terraform-provider-kubernetes/blob/main/_examples/eks/README.md), and [GKE](https://github.com/hashicorp/terraform-provider-kubernetes/blob/main/_examples/gke/README.md).
@ -150,7 +141,7 @@ Please keep in mind that all data sources remain unaffected, and the provider al
The following example demonstrates how to ignore changes related to the `kubectl.kubernetes.io/restartedAt` annotation that were made in the upstream Kubernetes object:
```hcl
```terraform
resource "kubernetes_deployment_v1" "this" {
// omit the resource config
lifecycle {
@ -163,7 +154,7 @@ resource "kubernetes_deployment_v1" "this" {
The following example demonstrates how to ignore particular annotation keys:
```hcl
```terraform
provider "kubernetes" {
ignore_annotations = [
"cni\\.projectcalico\\.org\\/podIP",
@ -174,7 +165,7 @@ provider "kubernetes" {
Next example demonstrates how to ignore AWS load balancer annotations:
```hcl
```terraform
provider "kubernetes" {
ignore_annotations = [
"^service\\.beta\\.kubernetes\\.io\\/aws-load-balancer.*",
@ -201,7 +192,7 @@ The following arguments are supported:
* `config_context` - (Optional) Context to choose from the config file. Can be sourced from `KUBE_CTX`.
* `config_context_auth_info` - (Optional) Authentication info context of the kube config (name of the kubeconfig user, `--user` flag in `kubectl`). Can be sourced from `KUBE_CTX_AUTH_INFO`.
* `config_context_cluster` - (Optional) Cluster context of the kube config (name of the kubeconfig cluster, `--cluster` flag in `kubectl`). Can be sourced from `KUBE_CTX_CLUSTER`.
* `token` - (Optional) Token of your service account. Can be sourced from `KUBE_TOKEN`.
* `token` - (Optional) Token of your service account. Can be sourced from `KUBE_TOKEN`.
* `proxy_url` - (Optional) URL to the proxy to be used for all API requests. URLs with "http", "https", and "socks5" schemes are supported. Can be sourced from `KUBE_PROXY_URL`.
* `exec` - (Optional) Configuration block to use an [exec-based credential plugin] (https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins), e.g. call an external command to receive user credentials.
* `api_version` - (Required) API version to use when decoding the ExecCredentials resource, e.g. `client.authentication.k8s.io/v1beta1`.

18
website/docs/r/annotations.html.markdown → docs/resources/annotations.md
View file

@ -1,6 +1,5 @@
---
subcategory: "manifest"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_annotations"
description: |-
This resource allows Terraform to manage the annotations for a resource that already exists
@ -8,12 +7,11 @@ description: |-
# kubernetes_annotations
This resource allows Terraform to manage the annotations for a resource that already exists. This resource uses [field management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) and [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to manage only the annotations that are defined in the Terraform configuration. Existing annotations not specified in the configuration will be ignored. If an annotation specified in the config and is already managed by another client it will cause a conflict which can be overridden by setting `force` to true.
This resource allows Terraform to manage the annotations for a resource that already exists. This resource uses [field management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) and [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to manage only the annotations that are defined in the Terraform configuration. Existing annotations not specified in the configuration will be ignored. If an annotation specified in the config and is already managed by another client it will cause a conflict which can be overridden by setting `force` to true.
## Example Usage
```hcl
```terraform
resource "kubernetes_annotations" "example" {
api_version = "v1"
kind = "ConfigMap"
@ -28,7 +26,7 @@ resource "kubernetes_annotations" "example" {
## Example Usage: Patching resources which contain a pod template, e.g Deployment, Job
```hcl
```terraform
resource "kubernetes_annotations" "example" {
api_version = "apps/v1"
kind = "Deployment"
@ -48,13 +46,13 @@ resource "kubernetes_annotations" "example" {
## Argument Reference
The following arguments are supported:
The following arguments are supported:
~> NOTE: At least one of `annotations` or `template_annotations` is required.
~> NOTE: At least one of `annotations` or `template_annotations` is required.
* `api_version` - (Required) The apiVersion of the resource to be annotated.
* `kind` - (Required) The kind of the resource to be annotated.
* `metadata` - (Required) Standard metadata of the resource to be annotated.
* `metadata` - (Required) Standard metadata of the resource to be annotated.
* `annotations` - (Optional) A map of annotations to apply to the resource.
* `template_annotations` - (Optional) A map of annotations to apply to the pod template within the resource.
* `force` - (Optional) Force management of annotations if there is a conflict. Defaults to `false`.
@ -71,6 +69,4 @@ The following arguments are supported:
## Import
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.

7
website/docs/r/api_service.html.markdown → docs/resources/api_service.md
View file

@ -1,6 +1,5 @@
---
subcategory: "apiregistration/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_api_service"
description: |-
An API Service is an abstraction which defines for locating and communicating with servers.
@ -10,10 +9,9 @@ description: |-
An API Service is an abstraction which defines for locating and communicating with servers.
## Example Usage
```hcl
```terraform
resource "kubernetes_api_service" "example" {
metadata {
name = "terraform-example"
@ -51,7 +49,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the API service.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the API service.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -59,7 +57,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this API service that can be used by clients to determine when API service has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this API service. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)

7
website/docs/r/api_service_v1.html.markdown → docs/resources/api_service_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "apiregistration/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_api_service_v1"
description: |-
An API Service is an abstraction which defines for locating and communicating with servers.
@ -10,10 +9,9 @@ description: |-
An API Service is an abstraction which defines for locating and communicating with servers.
## Example Usage
```hcl
```terraform
resource "kubernetes_api_service_v1" "example" {
metadata {
name = "terraform-example"
@ -51,7 +49,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the API service.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the API service.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -59,7 +57,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this API service that can be used by clients to determine when API service has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this API service. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)

11
website/docs/r/certificate_signing_request.html.markdown → docs/resources/certificate_signing_request.md
View file

@ -1,6 +1,5 @@
---
subcategory: "certificates/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_certificate_signing_request"
description: |-
Use this resource to generate TLS certificates using Kubernetes.
@ -16,7 +15,7 @@ This resource enables automation of [X.509](https://www.itu.int/rec/T-REC-X.509)
## Example Usage
```hcl
```terraform
resource "kubernetes_certificate_signing_request" "example" {
metadata {
name = "example"
@ -91,14 +90,12 @@ The following arguments are supported:
## Generating a New Certificate
Since the certificate is a logical resource that lives only in the Terraform state,
it will persist until it is explicitly destroyed by the user.
Since the certificate is a logical resource that lives only in the Terraform state, it will persist until it is explicitly destroyed by the user.
In order to force the generation of a new certificate within an existing state, the
certificate instance can be "tainted":
In order to force the generation of a new certificate within an existing state, the certificate instance can be "tainted":
```
terraform taint kubernetes_certificate_signing_request.example
```
A new certificate will then be generated on the next ``terraform apply``.
A new certificate will then be generated on the next `terraform apply`.

11
website/docs/r/certificate_signing_request_v1.html.markdown → docs/resources/certificate_signing_request_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "certificates/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_certificate_signing_request_v1"
description: |-
Use this resource to generate TLS certificates using Kubernetes.
@ -16,7 +15,7 @@ This resource enables automation of [X.509](https://www.itu.int/rec/T-REC-X.509)
## Example Usage
```hcl
```terraform
resource "kubernetes_certificate_signing_request_v1" "example" {
metadata {
name = "example"
@ -94,14 +93,12 @@ The following arguments are supported:
## Generating a New Certificate
Since the certificate is a logical resource that lives only in the Terraform state,
it will persist until it is explicitly destroyed by the user.
Since the certificate is a logical resource that lives only in the Terraform state, it will persist until it is explicitly destroyed by the user.
In order to force the generation of a new certificate within an existing state, the
certificate instance can be "tainted":
In order to force the generation of a new certificate within an existing state, the certificate instance can be "tainted":
```
terraform taint kubernetes_certificate_signing_request_v1.example
```
A new certificate will then be generated on the next ``terraform apply``.
A new certificate will then be generated on the next `terraform apply`.

13
website/docs/r/cluster_role.html.markdown → docs/resources/cluster_role.md
View file

@ -1,6 +1,5 @@
---
subcategory: "rbac/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_cluster_role"
description: |-
A ClusterRole creates a role at the cluster level and in all namespaces.
@ -12,7 +11,7 @@ A ClusterRole creates a role at the cluster level and in all namespaces.
## Example Usage
```hcl
```terraform
resource "kubernetes_cluster_role" "example" {
metadata {
name = "terraform-example"
@ -28,7 +27,7 @@ resource "kubernetes_cluster_role" "example" {
## Aggregation Rule Example Usage
```hcl
```terraform
resource "kubernetes_cluster_role" "example" {
metadata {
name = "terraform-example"
@ -56,8 +55,7 @@ The following arguments are supported:
* `metadata` - (Required) Standard kubernetes metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
* `rule` - (Optional) The PolicyRoles for this ClusterRole. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)
* `aggregation_rule` - (Optional) Describes how to build the Rules for this ClusterRole. If AggregationRule is set, then the Rules are controller managed and direct changes to Rules will be overwritten by the controller.
. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)
* `aggregation_rule` - (Optional) Describes how to build the Rules for this ClusterRole. If AggregationRule is set, then the Rules are controller managed and direct changes to Rules will be overwritten by the controller. . For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)
## Nested Blocks
@ -65,12 +63,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the cluster role binding that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the cluster role binding that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the cluster role binding.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the cluster role binding.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -105,7 +103,6 @@ The following arguments are supported:
* `match_expressions` - (Optional) A list of label selector requirements. The requirements are ANDed.
* `match_labels` - (Optional) A map of `{key,value}` pairs. A single `{key,value}` in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
## Import
ClusterRole can be imported using the name, e.g.

5
website/docs/r/cluster_role_binding.html.markdown → docs/resources/cluster_role_binding.md
View file

@ -1,6 +1,5 @@
---
subcategory: "rbac/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_cluster_role_binding"
description: |-
A ClusterRoleBinding may be used to grant permission at the cluster level and in all namespaces.
@ -10,10 +9,9 @@ description: |-
A ClusterRoleBinding may be used to grant permission at the cluster level and in all namespaces
## Example Usage
```hcl
```terraform
resource "kubernetes_cluster_role_binding" "example" {
metadata {
name = "terraform-example"
@ -49,7 +47,6 @@ The following arguments are supported:
* `role_ref` - (Required) The ClusterRole to bind Subjects to. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)
* `subject` - (Required) The Users, Groups, or ServiceAccounts to grant permissions to. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects)
## Nested Blocks
### `metadata`

5
website/docs/r/cluster_role_binding_v1.html.markdown → docs/resources/cluster_role_binding_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "rbac/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_cluster_role_binding_v1"
description: |-
A ClusterRoleBinding may be used to grant permission at the cluster level and in all namespaces.
@ -10,10 +9,9 @@ description: |-
A ClusterRoleBinding may be used to grant permission at the cluster level and in all namespaces
## Example Usage
```hcl
```terraform
resource "kubernetes_cluster_role_binding_v1" "example" {
metadata {
name = "terraform-example"
@ -49,7 +47,6 @@ The following arguments are supported:
* `role_ref` - (Required) The ClusterRole to bind Subjects to. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)
* `subject` - (Required) The Users, Groups, or ServiceAccounts to grant permissions to. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects)
## Nested Blocks
### `metadata`

13
website/docs/r/cluster_role_v1.html.markdown → docs/resources/cluster_role_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "rbac/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_cluster_role_v1"
description: |-
A ClusterRole creates a role at the cluster level and in all namespaces.
@ -12,7 +11,7 @@ A ClusterRole creates a role at the cluster level and in all namespaces.
## Example Usage
```hcl
```terraform
resource "kubernetes_cluster_role_v1" "example" {
metadata {
name = "terraform-example"
@ -28,7 +27,7 @@ resource "kubernetes_cluster_role_v1" "example" {
## Aggregation Rule Example Usage
```hcl
```terraform
resource "kubernetes_cluster_role_v1" "example" {
metadata {
name = "terraform-example"
@ -56,8 +55,7 @@ The following arguments are supported:
* `metadata` - (Required) Standard kubernetes metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
* `rule` - (Optional) The PolicyRoles for this ClusterRole. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)
* `aggregation_rule` - (Optional) Describes how to build the Rules for this ClusterRole. If AggregationRule is set, then the Rules are controller managed and direct changes to Rules will be overwritten by the controller.
. For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)
* `aggregation_rule` - (Optional) Describes how to build the Rules for this ClusterRole. If AggregationRule is set, then the Rules are controller managed and direct changes to Rules will be overwritten by the controller. . For more info see [Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)
## Nested Blocks
@ -65,12 +63,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the cluster role binding that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the cluster role binding that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the cluster role binding.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the cluster role binding.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -105,7 +103,6 @@ The following arguments are supported:
* `match_expressions` - (Optional) A list of label selector requirements. The requirements are ANDed.
* `match_labels` - (Optional) A map of `{key,value}` pairs. A single `{key,value}` in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
## Import
ClusterRole can be imported using the name, e.g.

6
website/docs/r/config_map.html.markdown → docs/resources/config_map.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_config_map"
description: |-
The resource provides mechanisms to inject containers with configuration data while keeping containers agnostic of Kubernetes.
@ -8,12 +7,11 @@ description: |-
# kubernetes_config_map
The resource provides mechanisms to inject containers with configuration data while keeping containers agnostic of Kubernetes.
Config Map can be used to store fine-grained information like individual properties or coarse-grained information like entire config files or JSON blobs.
The resource provides mechanisms to inject containers with configuration data while keeping containers agnostic of Kubernetes. Config Map can be used to store fine-grained information like individual properties or coarse-grained information like entire config files or JSON blobs.
## Example Usage
```hcl
```terraform
resource "kubernetes_config_map" "example" {
metadata {
name = "my-config"

6
website/docs/r/config_map_v1.html.markdown → docs/resources/config_map_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_config_map_v1"
description: |-
The resource provides mechanisms to inject containers with configuration data while keeping containers agnostic of Kubernetes.
@ -8,12 +7,11 @@ description: |-
# kubernetes_config_map_v1
The resource provides mechanisms to inject containers with configuration data while keeping containers agnostic of Kubernetes.
Config Map can be used to store fine-grained information like individual properties or coarse-grained information like entire config files or JSON blobs.
The resource provides mechanisms to inject containers with configuration data while keeping containers agnostic of Kubernetes. Config Map can be used to store fine-grained information like individual properties or coarse-grained information like entire config files or JSON blobs.
## Example Usage
```hcl
```terraform
resource "kubernetes_config_map_v1" "example" {
metadata {
name = "my-config"

12
website/docs/r/config_map_v1_data.html.markdown → docs/resources/config_map_v1_data.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_config_map_v1_data"
description: |-
This resource allows Terraform to manage the data for a ConfigMap that already exists
@ -8,12 +7,11 @@ description: |-
# kubernetes_config_map_v1_data
This resource allows Terraform to manage data within a pre-existing ConfigMap. This resource uses [field management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) and [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to manage only the data that is defined in the Terraform configuration. Existing data not specified in the configuration will be ignored. If data specified in the config and is already managed by another client it will cause a conflict which can be overridden by setting `force` to true.
This resource allows Terraform to manage data within a pre-existing ConfigMap. This resource uses [field management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) and [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to manage only the data that is defined in the Terraform configuration. Existing data not specified in the configuration will be ignored. If data specified in the config and is already managed by another client it will cause a conflict which can be overridden by setting `force` to true.
## Example Usage
```hcl
```terraform
resource "kubernetes_config_map_v1_data" "example" {
metadata {
name = "my-config"
@ -28,7 +26,7 @@ resource "kubernetes_config_map_v1_data" "example" {
The following arguments are supported:
* `metadata` - (Required) Standard metadata of the ConfigMap.
* `metadata` - (Required) Standard metadata of the ConfigMap.
* `data` - (Required) A map of data to apply to the ConfigMap.
* `force` - (Optional) Force management of the configured data if there is a conflict.
* `field_manager` - (Optional) The name of the [field manager](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management). Defaults to `Terraform`.
@ -44,6 +42,4 @@ The following arguments are supported:
## Import
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.

13
website/docs/r/cron_job.html.markdown → docs/resources/cron_job.md
View file

@ -1,6 +1,5 @@
---
subcategory: "batch/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_cron_job"
description: |-
A Cron Job creates Jobs on a time-based schedule. One CronJob object is like one line of a crontab (cron table) file.
@ -8,18 +7,17 @@ description: |-
# kubernetes_cron_job
A Cron Job creates Jobs on a time-based schedule.
A Cron Job creates Jobs on a time-based schedule.
One CronJob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.
One CronJob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.
Note: All CronJob `schedule` times are based on the timezone of the master where the job is initiated.
For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Kubernetes reference](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/).
Note: All CronJob `schedule` times are based on the timezone of the master where the job is initiated. For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Kubernetes reference](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/).
~> NOTE: With the release of Kubernetes v1.25, CronJob batch/v1beta1 has been removed. You can read more information about migrating to batch/v1 in the [Kubernetes 1.25 migration guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#cronjob-v125).
## Example Usage
```hcl
```terraform
resource "kubernetes_cron_job" "demo" {
metadata {
name = "demo"
@ -69,7 +67,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
@ -152,7 +150,6 @@ These arguments are the same as the for the `metadata` block of a Pod with a few
* `status` - (Optional) Specifies the required Pod condition status. To match a pod condition it is required that the specified status equals the pod condition status. Defaults to True.
* `type` - (Optional) Specifies the required Pod condition type. To match a pod condition it is required that specified type equals the pod condition type.
### `selector`
#### Arguments

12
website/docs/r/cron_job_v1.html.markdown → docs/resources/cron_job_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "batch/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_cron_job_v1"
description: |-
A Cron Job creates Jobs on a time-based schedule. One CronJob object is like one line of a crontab (cron table) file.
@ -8,16 +7,15 @@ description: |-
# kubernetes_cron_job_v1
A Cron Job creates Jobs on a time-based schedule.
A Cron Job creates Jobs on a time-based schedule.
One CronJob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.
One CronJob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.
Note: All CronJob `schedule` times are based on the timezone of the master where the job is initiated.
For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Kubernetes reference](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/).
Note: All CronJob `schedule` times are based on the timezone of the master where the job is initiated. For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Kubernetes reference](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/).
## Example Usage
```hcl
```terraform
resource "kubernetes_cron_job_v1" "demo" {
metadata {
name = "demo"
@ -68,7 +66,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

13
website/docs/r/csi_driver.html.markdown → docs/resources/csi_driver.md
View file

@ -1,6 +1,5 @@
---
subcategory: "storage/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_csi_driver"
description: |-
The Container Storage Interface (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes.
@ -8,13 +7,11 @@ description: |-
# kubernetes_csi_driver
The [Container Storage Interface](https://kubernetes-csi.github.io/docs/introduction.html)
(CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container
Orchestration Systems (COs) like Kubernetes.
The [Container Storage Interface](https://kubernetes-csi.github.io/docs/introduction.html) (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes.
## Example Usage
```hcl
```terraform
resource "kubernetes_csi_driver" "example" {
metadata {
name = "terraform-example"
@ -33,7 +30,7 @@ resource "kubernetes_csi_driver" "example" {
The following arguments are supported:
* `metadata` - (Required) Standard CSI driver's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
* `spec` - (Required) The Specification of the CSI Driver.
* `spec` - (Required) The Specification of the CSI Driver.
## Nested Blocks
@ -41,12 +38,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the csi driver that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the csi driver that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the csi driver. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the csi driver. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)

13
website/docs/r/csi_driver_v1.html.markdown → docs/resources/csi_driver_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "storage/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_csi_driver_v1"
description: |-
The Container Storage Interface (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes.
@ -8,13 +7,11 @@ description: |-
# kubernetes_csi_driver_v1
The [Container Storage Interface](https://kubernetes-csi.github.io/docs/introduction.html)
(CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container
Orchestration Systems (COs) like Kubernetes.
The [Container Storage Interface](https://kubernetes-csi.github.io/docs/introduction.html) (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes.
## Example Usage
```hcl
```terraform
resource "kubernetes_csi_driver_v1" "example" {
metadata {
name = "terraform-example"
@ -33,7 +30,7 @@ resource "kubernetes_csi_driver_v1" "example" {
The following arguments are supported:
* `metadata` - (Required) Standard CSI driver's metadata. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata)
* `spec` - (Required) The Specification of the CSI Driver.
* `spec` - (Required) The Specification of the CSI Driver.
## Nested Blocks
@ -41,12 +38,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the csi driver that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the csi driver that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the csi driver. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the csi driver. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)

10
website/docs/r/daemon_set_v1.html.markdown → docs/resources/daemon_set_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "apps/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_daemon_set_v1"
description: |-
A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.
@ -12,7 +11,7 @@ A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are a
## Example Usage
```hcl
```terraform
resource "kubernetes_daemon_set_v1" "example" {
metadata {
name = "terraform-example"
@ -203,7 +202,6 @@ Please see the [Pod resource](pod_v1.html#metadata) for reference.
#### Arguments
* `match_expressions` - (Optional) A list of node selector requirements by node's labels.
* `match_fields` - (Optional) A list of node selector requirements by node's fields.
@ -560,7 +558,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -645,7 +643,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -664,7 +662,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}

10
website/docs/r/daemonset.html.markdown → docs/resources/daemonset.md
View file

@ -1,6 +1,5 @@
---
subcategory: "apps/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_daemonset"
description: |-
A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.
@ -12,7 +11,7 @@ A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are a
## Example Usage
```hcl
```terraform
resource "kubernetes_daemonset" "example" {
metadata {
name = "terraform-example"
@ -203,7 +202,6 @@ Please see the [Pod resource](pod_v1.html#metadata) for reference.
#### Arguments
* `match_expressions` - (Optional) A list of node selector requirements by node's labels.
* `match_fields` - (Optional) A list of node selector requirements by node's fields.
@ -570,7 +568,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -655,7 +653,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -674,7 +672,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}

9
website/docs/r/default_service_account.html.markdown → docs/resources/default_service_account.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_default_service_account"
description: |-
The default service account resource configures the default service account created by Kubernetes in each namespace.
@ -8,13 +7,13 @@ description: |-
# kubernetes_default_service_account
Kubernetes creates a "default" service account in each namespace. This is the service account that will be assigned by default to pods in the namespace.
Kubernetes creates a "default" service account in each namespace. This is the service account that will be assigned by default to pods in the namespace.
The `kubernetes_default_service_account` resource behaves differently from normal resources. The service account is created by a Kubernetes controller and Terraform "adopts" it into management. This resource should only be used once per namespace.
## Example Usage
```hcl
```terraform
resource "kubernetes_default_service_account" "example" {
metadata {
namespace = "terraform-example"
@ -46,11 +45,11 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the service account that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the service account that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service account. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service account. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)

9
website/docs/r/default_service_account_v1.html.markdown → docs/resources/default_service_account_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_default_service_account_v1"
description: |-
The default service account resource configures the default service account created by Kubernetes in each namespace.
@ -8,13 +7,13 @@ description: |-
# kubernetes_default_service_account_v1
Kubernetes creates a "default" service account in each namespace. This is the service account that will be assigned by default to pods in the namespace.
Kubernetes creates a "default" service account in each namespace. This is the service account that will be assigned by default to pods in the namespace.
The `kubernetes_default_service_account_v1` resource behaves differently from normal resources. The service account is created by a Kubernetes controller and Terraform "adopts" it into management. This resource should only be used once per namespace.
## Example Usage
```hcl
```terraform
resource "kubernetes_default_service_account_v1" "example" {
metadata {
namespace = "terraform-example"
@ -46,11 +45,11 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the service account that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the service account that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service account. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service account. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)

16
website/docs/r/deployment.html.markdown → docs/resources/deployment.md
View file

@ -1,6 +1,5 @@
---
subcategory: "apps/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_deployment"
description: |-
A Deployment ensures that a specified number of pod “replicas” are running at any one time. In other words, a Deployment makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the Deployment will start more.
@ -10,10 +9,9 @@ description: |-
A Deployment ensures that a specified number of pod “replicas” are running at any one time. In other words, a Deployment makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the Deployment will start more.
## Example Usage
```hcl
```terraform
resource "kubernetes_deployment" "example" {
metadata {
name = "terraform-example"
@ -89,12 +87,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the deployment that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the deployment that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the deployment.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the deployment.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). **Must match `selector`**. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -252,7 +250,7 @@ The following arguments are supported:
#### Arguments
* `required_during_scheduling_ignored_during_execution` - (Optional) If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node.
* `required_during_scheduling_ignored_during_execution` - (Optional) If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node.
* `preferred_during_scheduling_ignored_during_execution` - (Optional) The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions.
@ -572,7 +570,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -657,7 +655,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -676,7 +674,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}

16
website/docs/r/deployment_v1.html.markdown → docs/resources/deployment_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "apps/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_deployment_v1"
description: |-
A Deployment ensures that a specified number of pod “replicas” are running at any one time. In other words, a Deployment makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the Deployment will start more.
@ -10,10 +9,9 @@ description: |-
A Deployment ensures that a specified number of pod “replicas” are running at any one time. In other words, a Deployment makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the Deployment will start more.
## Example Usage
```hcl
```terraform
resource "kubernetes_deployment_v1" "example" {
metadata {
name = "terraform-example"
@ -89,12 +87,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the deployment that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the deployment that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the deployment.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the deployment.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). **Must match `selector`**. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -252,7 +250,7 @@ The following arguments are supported:
#### Arguments
* `required_during_scheduling_ignored_during_execution` - (Optional) If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node.
* `required_during_scheduling_ignored_during_execution` - (Optional) If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node.
* `preferred_during_scheduling_ignored_during_execution` - (Optional) The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions.
@ -562,7 +560,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -647,7 +645,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -666,7 +664,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}

12
website/docs/r/endpoint_slice_v1.html.markdown → docs/resources/endpoint_slice_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "discovery/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_endpoint_slice_v1"
description: |-
An EndpointSlice contains references to a set of network endpoints.
@ -12,7 +11,7 @@ An EndpointSlice contains references to a set of network endpoints.
## Example Usage
```hcl
```terraform
resource "kubernetes_endpoint_slice_v1" "test" {
metadata {
name = "test"
@ -49,12 +48,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the endpoints resource that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the endpoints resource that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the endpoints resource. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the endpoints resource. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -63,7 +62,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this endpoints resource that can be used by clients to determine when endpoints resource has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this endpoints resource. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -72,7 +70,7 @@ The following arguments are supported:
#### Arguments
* `addresses` - (Required) addresses of this endpoint. The contents of this field are interpreted according to the corresponding EndpointSlice addressType field. Consumers must handle different types of addresses in the context of their own capabilities. This must contain at least one address but no more than 100.
* `addresses` - (Required) addresses of this endpoint. The contents of this field are interpreted according to the corresponding EndpointSlice addressType field. Consumers must handle different types of addresses in the context of their own capabilities. This must contain at least one address but no more than 100.
* `condition` - (Optional) Contains information about the current status of the endpoint.
* `hostname` - (Optional) hostname of this endpoint. This field may be used by consumers of endpoints to distinguish endpoints from each other (e.g. in DNS names). Multiple endpoints which use the same hostname should be considered fungible (e.g. multiple A values in DNS). Must be lowercase and pass DNS Label (RFC 1123) validation.
* `node_name` - (Optional) Represents the name of the Node hosting this endpoint. This can be used to determine endpoints local to a Node.
@ -84,7 +82,7 @@ The following arguments are supported:
#### Attributes
* `ready` - (Optional) Indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint.
* `serving` - (Optional) Serving is identical to ready except that it is set regardless of the terminating state of endpoints.
* `serving` - (Optional) Serving is identical to ready except that it is set regardless of the terminating state of endpoints.
* `terminating` - (Optional) Indicates that this endpoint is terminating.
### `target_ref`

9
website/docs/r/endpoints.html.markdown → docs/resources/endpoints.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_endpoints"
description: |-
An Endpoints resource is an abstraction, linked to a Service, which defines the list of endpoints that actually implement the service.
@ -10,10 +9,9 @@ description: |-
An Endpoints resource is an abstraction, linked to a Service, which defines the list of endpoints that actually implement the service.
## Example Usage
```hcl
```terraform
resource "kubernetes_endpoints" "example" {
metadata {
name = "terraform-example"
@ -96,12 +94,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the endpoints resource that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the endpoints resource that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the endpoints resource. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the endpoints resource. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -110,7 +108,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this endpoints resource that can be used by clients to determine when endpoints resource has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this endpoints resource. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)

9
website/docs/r/endpoints_v1.html.markdown → docs/resources/endpoints_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_endpoints_v1"
description: |-
An Endpoints resource is an abstraction, linked to a Service, which defines the list of endpoints that actually implement the service.
@ -10,10 +9,9 @@ description: |-
An Endpoints resource is an abstraction, linked to a Service, which defines the list of endpoints that actually implement the service.
## Example Usage
```hcl
```terraform
resource "kubernetes_endpoints_v1" "example" {
metadata {
name = "terraform-example"
@ -96,12 +94,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the endpoints resource that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the endpoints resource that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the endpoints resource. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the endpoints resource. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -110,7 +108,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this endpoints resource that can be used by clients to determine when endpoints resource has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this endpoints resource. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)

10
website/docs/r/env.html.markdown → docs/resources/env.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_env"
description: |-
This resource provides a way to manage environment variables in resources that were created outside of Terraform.
@ -8,11 +7,11 @@ description: |-
# kubernetes_env
This resource provides a way to manage environment variables in resources that were created outside of Terraform. This resource provides functionality similar to the `kubectl set env` command.
This resource provides a way to manage environment variables in resources that were created outside of Terraform. This resource provides functionality similar to the `kubectl set env` command.
## Example Usage
```hcl
```terraform
resource "kubernetes_env" "example" {
container = "nginx"
metadata {
@ -40,7 +39,7 @@ The following arguments are supported:
* `api_version` - (Required) The apiVersion of the resource to add environment variables to.
* `kind` - (Required) The kind of the resource to add environment variables to.
* `metadata` - (Required) Standard metadata of the resource to add environment variables to.
* `metadata` - (Required) Standard metadata of the resource to add environment variables to.
* `container` - (Optional) Name of the container for which we are updating the environment variables.
* `init_container` - (Optional) Name of the initContainer for which we are updating the environment variables.
* `env` - (Required) Value block with custom values used to represent environment variables
@ -104,7 +103,6 @@ The following arguments are supported:
* `name` - (Optional) Name of the referent. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
* `optional` - (Optional) Specify whether the Secret or its key must be defined
## Import
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.

21
website/docs/r/horizontal_pod_autoscaler.html.markdown → docs/resources/horizontal_pod_autoscaler.md
View file

@ -1,5 +1,4 @@
---
layout: "kubernetes"
subcategory: "autoscaling/v1"
page_title: "Kubernetes: kubernetes_horizontal_pod_autoscaler"
description: |-
@ -10,10 +9,9 @@ description: |-
Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization.
## Example Usage
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler" "example" {
metadata {
name = "terraform-example"
@ -33,7 +31,7 @@ resource "kubernetes_horizontal_pod_autoscaler" "example" {
## Example Usage, with `metric`
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler" "example" {
metadata {
name = "test"
@ -71,7 +69,7 @@ resource "kubernetes_horizontal_pod_autoscaler" "example" {
## Example Usage, with `behavior`
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler" "example" {
metadata {
name = "test"
@ -121,7 +119,7 @@ resource "kubernetes_horizontal_pod_autoscaler" "example" {
}
```
## Support for multiple and custom metrics
## Support for multiple and custom metrics
The provider currently supports two version of the HorizontalPodAutoscaler API resource.
@ -142,12 +140,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -156,7 +154,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this horizontal pod autoscaler that can be used by clients to determine when horizontal pod autoscaler has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this horizontal pod autoscaler. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -211,12 +208,12 @@ The following arguments are supported:
* `name` - (Required) Name of the resource in question.
* `target` - (Required) The target for the given metric.
### `metric`
### `metric`
#### Arguments
* `name` - (Required) The name of the given metric
* `selector` - (Optional) The label selector for the given metric
* `selector` - (Optional) The label selector for the given metric
### `target`
@ -254,7 +251,6 @@ See [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-co
* `scale_up` - (Optional) Scaling policy for scaling Up
* `scale_down` - (Optional) Scaling policy for scaling Down
### `scale_up`
#### Arguments
@ -271,7 +267,6 @@ See [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-co
* `type` - (Required) Type is used to specify the scaling policy: Percent or Pods
* `value` - (Required) Value contains the amount of change which is permitted by the policy. It must be greater than zero.
## Import
Horizontal Pod Autoscaler can be imported using the namespace and name, e.g.

10
website/docs/r/horizontal_pod_autoscaler_v1.html.markdown → docs/resources/horizontal_pod_autoscaler_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "autoscaling/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_horizontal_pod_autoscaler_v1"
description: |-
Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization.
@ -10,10 +9,9 @@ description: |-
Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization.
## Example Usage
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler_v1" "example" {
metadata {
name = "terraform-example"
@ -31,7 +29,6 @@ resource "kubernetes_horizontal_pod_autoscaler_v1" "example" {
}
```
## Argument Reference
The following arguments are supported:
@ -45,12 +42,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -59,7 +56,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this horizontal pod autoscaler that can be used by clients to determine when horizontal pod autoscaler has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this horizontal pod autoscaler. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)

18
website/docs/r/horizontal_pod_autoscaler_v2.html.markdown → docs/resources/horizontal_pod_autoscaler_v2.md
View file

@ -1,5 +1,4 @@
---
layout: "kubernetes"
subcategory: "autoscaling/v2"
page_title: "Kubernetes: kubernetes_horizontal_pod_autoscaler_v2"
description: |-
@ -10,11 +9,9 @@ description: |-
Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization.
## Example Usage, with `metric`
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler_v2" "example" {
metadata {
name = "test"
@ -52,7 +49,7 @@ resource "kubernetes_horizontal_pod_autoscaler_v2" "example" {
## Example Usage, with `behavior`
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler_v2" "example" {
metadata {
name = "test"
@ -115,12 +112,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -129,7 +126,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this horizontal pod autoscaler that can be used by clients to determine when horizontal pod autoscaler has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this horizontal pod autoscaler. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -192,12 +188,12 @@ The following arguments are supported:
* `name` - (Required) Name of the resource in question.
* `target` - (Required) The target for the given metric.
### `metric`
### `metric`
#### Arguments
* `name` - (Required) The name of the given metric
* `selector` - (Optional) The label selector for the given metric
* `selector` - (Optional) The label selector for the given metric
### `target`
@ -235,7 +231,6 @@ See [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-co
* `scale_up` - (Optional) Scaling policy for scaling Up
* `scale_down` - (Optional) Scaling policy for scaling Down
### `scale_up`
#### Arguments
@ -252,7 +247,6 @@ See [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-co
* `type` - (Required) Type is used to specify the scaling policy: Percent or Pods
* `value` - (Required) Value contains the amount of change which is permitted by the policy. It must be greater than zero.
## Import
Horizontal Pod Autoscaler can be imported using the namespace and name, e.g.

18
website/docs/r/horizontal_pod_autoscaler_v2beta2.html.markdown → docs/resources/horizontal_pod_autoscaler_v2beta2.md
View file

@ -1,5 +1,4 @@
---
layout: "kubernetes"
subcategory: "autoscaling/v2beta2"
page_title: "Kubernetes: kubernetes_horizontal_pod_autoscaler_v2beta2"
description: |-
@ -10,11 +9,9 @@ description: |-
Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization.
## Example Usage, with `metric`
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler_v2beta2" "example" {
metadata {
name = "test"
@ -52,7 +49,7 @@ resource "kubernetes_horizontal_pod_autoscaler_v2beta2" "example" {
## Example Usage, with `behavior`
```hcl
```terraform
resource "kubernetes_horizontal_pod_autoscaler_v2beta2" "example" {
metadata {
name = "test"
@ -115,12 +112,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the horizontal pod autoscaler that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the horizontal pod autoscaler. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -129,7 +126,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this horizontal pod autoscaler that can be used by clients to determine when horizontal pod autoscaler has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this horizontal pod autoscaler. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -192,12 +188,12 @@ The following arguments are supported:
* `name` - (Required) Name of the resource in question.
* `target` - (Required) The target for the given metric.
### `metric`
### `metric`
#### Arguments
* `name` - (Required) The name of the given metric
* `selector` - (Optional) The label selector for the given metric
* `selector` - (Optional) The label selector for the given metric
### `target`
@ -235,7 +231,6 @@ See [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-co
* `scale_up` - (Optional) Scaling policy for scaling Up
* `scale_down` - (Optional) Scaling policy for scaling Down
### `scale_up`
#### Arguments
@ -252,7 +247,6 @@ See [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-co
* `type` - (Required) Type is used to specify the scaling policy: Percent or Pods
* `value` - (Required) Value contains the amount of change which is permitted by the policy. It must be greater than zero.
## Import
Horizontal Pod Autoscaler can be imported using the namespace and name, e.g.

15
website/docs/r/ingress.html.markdown → docs/resources/ingress.md
View file

@ -1,6 +1,5 @@
---
subcategory: "extensions/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_ingress"
description: |-
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.
@ -10,10 +9,9 @@ description: |-
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.
## Example Usage
```hcl
```terraform
resource "kubernetes_ingress" "example_ingress" {
metadata {
name = "example-ingress"
@ -132,7 +130,7 @@ resource "kubernetes_pod" "example2" {
## Example using Nginx ingress controller
```hcl
```terraform
resource "kubernetes_service" "example" {
metadata {
name = "ingress-service"
@ -181,8 +179,6 @@ output "load_balancer_ip" {
}
```
## Argument Reference
The following arguments are supported:
@ -211,7 +207,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this service that can be used by clients to determine when service has changed. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
* `uid` - The unique in time and space value for this service. For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids
@ -239,14 +234,13 @@ The following arguments are supported:
* `host` - (Optional) Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the \"host\" part of the URI as defined in the RFC: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to the IP in the Spec of the parent Ingress. 2. The : delimiter is not respected because ports are not allowed. Currently the port of an Ingress is implicitly :80 for http and :443 for https. Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.
* `http` - (Required) http is a list of http selectors pointing to backends. In the example: http:///? -> backend where parts of the url correspond to RFC 3986, this resource will be used to match against everything after the last '/' and before the first '?' or '#'. See `http` block attributes below.
#### `http`
* `path` - (Required) Path array of path regex associated with a backend. Incoming urls matching the path are forwarded to the backend, see below for `path` block structure.
#### `path`
* `path` - (Required) A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `path` - (Required) A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `backend` - (Required) Backend defines the referenced service endpoint to which the traffic will be forwarded to.
### `tls`
@ -272,10 +266,9 @@ The following arguments are supported:
###### Attributes
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `hostname` - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers).
## Import
Ingress can be imported using its namespace and name:

7
website/docs/r/ingress_class.html.markdown → docs/resources/ingress_class.md
View file

@ -1,6 +1,5 @@
---
subcategory: "networking/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_ingress_class"
description: |-
Ingresses can be implemented by different controllers, often with different configuration. Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class.
@ -10,10 +9,9 @@ description: |-
Ingresses can be implemented by different controllers, often with different configuration. Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class.
## Example Usage
```hcl
```terraform
resource "kubernetes_ingress_class" "example" {
metadata {
name = "example"
@ -30,8 +28,6 @@ resource "kubernetes_ingress_class" "example" {
}
```
## Argument Reference
The following arguments are supported:
@ -59,7 +55,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this service that can be used by clients to determine when service has changed. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
* `uid` - The unique in time and space value for this service. For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids

7
website/docs/r/ingress_class_v1.html.markdown → docs/resources/ingress_class_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "networking/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_ingress_class_v1"
description: |-
Ingresses can be implemented by different controllers, often with different configuration. Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class.
@ -10,10 +9,9 @@ description: |-
Ingresses can be implemented by different controllers, often with different configuration. Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class.
## Example Usage
```hcl
```terraform
resource "kubernetes_ingress_class_v1" "example" {
metadata {
name = "example"
@ -30,8 +28,6 @@ resource "kubernetes_ingress_class_v1" "example" {
}
```
## Argument Reference
The following arguments are supported:
@ -59,7 +55,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this service that can be used by clients to determine when service has changed. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
* `uid` - The unique in time and space value for this service. For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids

21
website/docs/r/ingress_v1.html.markdown → docs/resources/ingress_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "networking/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_ingress_v1"
description: |-
Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.
@ -12,7 +11,7 @@ Ingress is a collection of rules that allow inbound connections to reach the end
## Example Usage
```hcl
```terraform
resource "kubernetes_ingress_v1" "example_ingress" {
metadata {
name = "example-ingress"
@ -143,7 +142,7 @@ resource "kubernetes_pod_v1" "example2" {
## Example using Nginx ingress controller
```hcl
```terraform
resource "kubernetes_service_v1" "example" {
metadata {
name = "ingress-service"
@ -194,8 +193,6 @@ output "load_balancer_ip" {
}
```
## Argument Reference
The following arguments are supported:
@ -224,7 +221,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this service that can be used by clients to determine when service has changed. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
* `uid` - The unique in time and space value for this service. For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids
@ -242,7 +238,6 @@ The following arguments are supported:
#### Arguments
* `resource` - (Optional) Resource is an ObjectRef to another Kubernetes resource in the namespace of the Ingress object. If resource is specified, a `service.name` and `service.port` must not be specified.
* `service` - (Optional) Service references a Service as a Backend.
@ -255,9 +250,8 @@ The following arguments are supported:
### `port`
* `name` - (Optional) Name is the name of the port on the Service.
* `number` - (Optional) Number is the numerical port number (e.g. 80) on the Service.
* `name` - (Optional) Name is the name of the port on the Service.
* `number` - (Optional) Number is the numerical port number (e.g. 80) on the Service.
#### Arguments
@ -268,15 +262,14 @@ The following arguments are supported:
* `host` - (Optional) Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the \"host\" part of the URI as defined in the RFC: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to the IP in the Spec of the parent Ingress. 2. The : delimiter is not respected because ports are not allowed. Currently the port of an Ingress is implicitly :80 for http and :443 for https. Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.
* `http` - (Optional) http is a list of http selectors pointing to backends. In the example: http:///? -> backend where parts of the url correspond to RFC 3986, this resource will be used to match against everything after the last '/' and before the first '?' or '#'. See `http` block attributes below.
#### `http`
* `path` - (Required) Path array of path regex associated with a backend. Incoming urls matching the path are forwarded to the backend, see below for `path` block structure.
#### `path`
* `path` - (Required) A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `path_type` - (Optional) PathType determines the interpretation of the Path matching. PathType can be one of the following values: `ImplementationSpecific`, `Exact`, or `Prefix`. See the [Kubernetes Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types) for details.
* `path` - (Required) A string or an extended POSIX regular expression as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional \"path\" part of a URL as defined by RFC 3986. Paths must begin with a '/'. If unspecified, the path defaults to a catch all sending traffic to the backend.
* `path_type` - (Optional) PathType determines the interpretation of the Path matching. PathType can be one of the following values: `ImplementationSpecific`, `Exact`, or `Prefix`. See the [Kubernetes Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types) for details.
* `backend` - (Required) Backend defines the referenced service endpoint to which the traffic will be forwarded to.
### `tls`
@ -302,7 +295,7 @@ The following arguments are supported:
###### Attributes
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `ip` - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers).
* `hostname` - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers).
## Timeouts

23
website/docs/r/job.html.markdown → docs/resources/job.md
View file

@ -1,6 +1,5 @@
---
subcategory: "batch/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_job"
description: |-
A Job creates one or more Pods and ensures that a specified number of them successfully terminate. You can also use a Job to run multiple Pods in parallel.
@ -8,15 +7,15 @@ description: |-
# kubernetes_job
A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created.
A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created.
A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot.
A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot.
You can also use a Job to run multiple Pods in parallel.
You can also use a Job to run multiple Pods in parallel.
## Example Usage - No waiting
```hcl
```terraform
resource "kubernetes_job" "demo" {
metadata {
name = "demo"
@ -41,7 +40,7 @@ resource "kubernetes_job" "demo" {
## Example Usage - waiting for job successful completion
```hcl
```terraform
resource "kubernetes_job" "demo" {
metadata {
name = "demo"
@ -74,8 +73,7 @@ The following arguments are supported:
* `metadata` - (Required) Standard resource's metadata. For more info: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata
* `spec` - (Required) Specification of the desired behavior of a job. For more info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
* `wait_for_completion` -
(Optional) If `true` blocks job `create` or `update` until the status of the job has a `Complete` or `Failed` condition. Defaults to `true`.
* `wait_for_completion` - (Optional) If `true` blocks job `create` or `update` until the status of the job has a `Complete` or `Failed` condition. Defaults to `true`.
## Nested Blocks
@ -88,7 +86,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
@ -167,8 +165,7 @@ The following [Timeout](/docs/language/resources/syntax.html#operation-timeouts)
* `create` - (Default `1m`) Used for creating a new job and waiting for a successful job completion.
* `update` - (Default `1m`) Used for updating an existing job and waiting for a successful job completion.
Note:
Note:
- Kubernetes provider will treat update operations that change the Job spec resulting in the job re-run as "# forces replacement".
In such cases, the `create` timeout value is used for both Create and Update operations.
- `wait_for_completion` is not applicable during Delete operations; thus, there is no "delete" timeout value for Delete operation.
- Kubernetes provider will treat update operations that change the Job spec resulting in the job re-run as "# forces replacement". In such cases, the `create` timeout value is used for both Create and Update operations.
- `wait_for_completion` is not applicable during Delete operations; thus, there is no "delete" timeout value for Delete operation.

23
website/docs/r/job_v1.html.markdown → docs/resources/job_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "batch/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_job_v1"
description: |-
A Job creates one or more Pods and ensures that a specified number of them successfully terminate. You can also use a Job to run multiple Pods in parallel.
@ -8,15 +7,15 @@ description: |-
# kubernetes_job_v1
A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created.
A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created.
A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot.
A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot.
You can also use a Job to run multiple Pods in parallel.
You can also use a Job to run multiple Pods in parallel.
## Example Usage - No waiting
```hcl
```terraform
resource "kubernetes_job_v1" "demo" {
metadata {
name = "demo"
@ -41,7 +40,7 @@ resource "kubernetes_job_v1" "demo" {
## Example Usage - waiting for job successful completion
```hcl
```terraform
resource "kubernetes_job_v1" "demo" {
metadata {
name = "demo"
@ -74,8 +73,7 @@ The following arguments are supported:
* `metadata` - (Required) Standard resource's metadata. For more info: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata
* `spec` - (Required) Specification of the desired behavior of a job. For more info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
* `wait_for_completion` -
(Optional) If `true` blocks job `create` or `update` until the status of the job has a `Complete` or `Failed` condition. Defaults to `true`.
* `wait_for_completion` - (Optional) If `true` blocks job `create` or `update` until the status of the job has a `Complete` or `Failed` condition. Defaults to `true`.
## Nested Blocks
@ -88,7 +86,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
@ -167,8 +165,7 @@ The following [Timeout](/docs/language/resources/syntax.html#operation-timeouts)
* `create` - (Default `1m`) Used for creating a new job and waiting for a successful job completion.
* `update` - (Default `1m`) Used for updating an existing job and waiting for a successful job completion.
Note:
Note:
- Kubernetes provider will treat update operations that change the Job spec resulting in the job re-run as "# forces replacement".
In such cases, the `create` timeout value is used for both Create and Update operations.
- `wait_for_completion` is not applicable during Delete operations; thus, there is no "delete" timeout value for Delete operation.
- Kubernetes provider will treat update operations that change the Job spec resulting in the job re-run as "# forces replacement". In such cases, the `create` timeout value is used for both Create and Update operations.
- `wait_for_completion` is not applicable during Delete operations; thus, there is no "delete" timeout value for Delete operation.

12
website/docs/r/labels.html.markdown → docs/resources/labels.md
View file

@ -1,6 +1,5 @@
---
subcategory: "manifest"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_labels"
description: |-
This resource allows Terraform to manage the labels for a resource that already exists
@ -8,12 +7,11 @@ description: |-
# kubernetes_labels
This resource allows Terraform to manage the labels for a resource that already exists. This resource uses [field management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) and [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to manage only the labels that are defined in the Terraform configuration. Existing labels not specified in the configuration will be ignored. If a label specified in the config and is already managed by another client it will cause a conflict which can be overridden by setting `force` to true.
This resource allows Terraform to manage the labels for a resource that already exists. This resource uses [field management](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) and [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to manage only the labels that are defined in the Terraform configuration. Existing labels not specified in the configuration will be ignored. If a label specified in the config and is already managed by another client it will cause a conflict which can be overridden by setting `force` to true.
## Example Usage
```hcl
```terraform
resource "kubernetes_labels" "example" {
api_version = "v1"
kind = "ConfigMap"
@ -32,7 +30,7 @@ The following arguments are supported:
* `api_version` - (Required) The apiVersion of the resource to be labelled.
* `kind` - (Required) The kind of the resource to be labelled.
* `metadata` - (Required) Standard metadata of the resource to be labelled.
* `metadata` - (Required) Standard metadata of the resource to be labelled.
* `labels` - (Required) A map of labels to apply to the resource.
* `force` - (Optional) Force management of labels if there is a conflict.
* `field_manager` - (Optional) The name of the [field manager](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management). Defaults to `Terraform`.
@ -48,6 +46,4 @@ The following arguments are supported:
## Import
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.
This resource does not support the `import` command. As this resource operates on Kubernetes resources that already exist, creating the resource is equivalent to importing it.

6
website/docs/r/limit_range.html.markdown → docs/resources/limit_range.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_limit_range"
description: |-
Limit Range sets resource usage limits (e.g. memory, cpu, storage) for supported kinds of resources in a namespace.
@ -12,10 +11,9 @@ Limit Range sets resource usage limits (e.g. memory, cpu, storage) for supported
Read more in [the official docs](https://kubernetes.io/docs/concepts/policy/limit-range/).
## Example Usage
```hcl
```terraform
resource "kubernetes_limit_range" "example" {
metadata {
name = "terraform-example"
@ -75,7 +73,7 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the limit range that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the limit range that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)

6
website/docs/r/limit_range_v1.html.markdown → docs/resources/limit_range_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_limit_range_v1"
description: |-
Limit Range sets resource usage limits (e.g. memory, cpu, storage) for supported kinds of resources in a namespace.
@ -12,10 +11,9 @@ Limit Range sets resource usage limits (e.g. memory, cpu, storage) for supported
Read more in [the official docs](https://kubernetes.io/docs/concepts/policy/limit-range/).
## Example Usage
```hcl
```terraform
resource "kubernetes_limit_range_v1" "example" {
metadata {
name = "terraform-example"
@ -75,7 +73,7 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the limit range that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the limit range that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)

32
website/docs/r/manifest.html.markdown → docs/resources/manifest.md
View file

@ -1,6 +1,5 @@
---
subcategory: "manifest"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_manifest"
description: |-
The resource provides a way to create and manage custom resources
@ -20,10 +19,9 @@ Once applied, the `object` attribute contains the state of the resource as retur
- This resource uses [Server-side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to carry out apply operations. A minimum Kubernetes version of 1.16.x is required, but versions 1.17+ are strongly recommended as the SSA implementation in Kubernetes 1.16.x is incomplete and unstable.
### Example: Create a Kubernetes ConfigMap
```hcl
```terraform
resource "kubernetes_manifest" "test-configmap" {
manifest = {
"apiVersion" = "v1"
@ -41,7 +39,7 @@ resource "kubernetes_manifest" "test-configmap" {
### Example: Create a Kubernetes Custom Resource Definition
```hcl
```terraform
resource "kubernetes_manifest" "test-crd" {
manifest = {
apiVersion = "apiextensions.k8s.io/v1"
@ -100,8 +98,7 @@ kubectl get secrets sample -o yaml | tfk8s --strip -o sample.tf
terraform import kubernetes_manifest.secret_sample "apiVersion=v1,kind=Secret,namespace=default,name=sample"
```
Note the import ID as the last argument to the import command. This ID points Terraform at which Kubernetes object to read when importing.
It should be constructed with the following syntax: `"apiVersion=<string>,kind=<string>,[namespace=<string>,]name=<string>"`. The `namespace=<string>` in the ID string is required only for Kubernetes namespaced objects and should be omitted for cluster-wide objects.
Note the import ID as the last argument to the import command. This ID points Terraform at which Kubernetes object to read when importing. It should be constructed with the following syntax: `"apiVersion=<string>,kind=<string>,[namespace=<string>,]name=<string>"`. The `namespace=<string>` in the ID string is required only for Kubernetes namespaced objects and should be omitted for cluster-wide objects.
## Using `wait` to block create and update calls
@ -109,7 +106,7 @@ The `kubernetes_manifest` resource supports the ability to block create and upda
`wait` supports supports a `fields` attribute which allows you specify a map of fields paths to regular expressions. You can also specify `*` if you just want to wait for a field to have any value.
```hcl
```terraform
resource "kubernetes_manifest" "test" {
manifest = {
// ...
@ -139,9 +136,9 @@ resource "kubernetes_manifest" "test" {
}
```
The `wait` block also supports a `rollout` attribute which will wait for rollout to complete on Deployment, StatefulSet, and DaemonSet resources.
The `wait` block also supports a `rollout` attribute which will wait for rollout to complete on Deployment, StatefulSet, and DaemonSet resources.
```hcl
```terraform
resource "kubernetes_manifest" "test" {
manifest = {
// ...
@ -155,7 +152,7 @@ resource "kubernetes_manifest" "test" {
You can also wait for specified conditions to be met by specifying a `condition` block.
```hcl
```terraform
resource "kubernetes_manifest" "test" {
manifest = {
// ...
@ -174,7 +171,7 @@ resource "kubernetes_manifest" "test" {
The `kubernetes_manifest` exposes configuration of the field manager through the optional `field_manager` block.
```hcl
```terraform
resource "kubernetes_manifest" "test" {
provider = kubernetes-alpha
@ -196,11 +193,11 @@ resource "kubernetes_manifest" "test" {
When setting the value of an field in configuration, Terraform will check that the same value is returned after the apply operation. This ensures that the actual configuration requested by the user is successfully applied. In some cases, with the Kubernetes API this is not the desired behavior. Particularly when using mutating admission controllers, there is a chance that the values configured by the user will be modified by the API. This usually manifest as `Error: Provider produced inconsistent result after apply` and `produced an unexpected new value:` messages when applying.
To accommodate this, the `kubernetes_manifest` resources allows defining so-called "computed" fields. When an field is defined as "computed" Terraform will allow the final value stored in state after `apply` as returned by the API to be different than what the user requested.
To accommodate this, the `kubernetes_manifest` resources allows defining so-called "computed" fields. When an field is defined as "computed" Terraform will allow the final value stored in state after `apply` as returned by the API to be different than what the user requested.
The most common example of this is `metadata.annotations`. In some cases, the API will add extra annotations on top of the ones configured by the user. Unless the field is declared as "computed" Terraform will throw an error signaling that the state returned by the 'apply' operation is inconsistent with the value defined in the 'plan'.
The most common example of this is `metadata.annotations`. In some cases, the API will add extra annotations on top of the ones configured by the user. Unless the field is declared as "computed" Terraform will throw an error signaling that the state returned by the 'apply' operation is inconsistent with the value defined in the 'plan'.
To declare an field as "computed" add its full field path to the `computed_fields` field under the respective `kubernetes_manifest` resource. For example, to declare the "metadata.labels" field as "computed", add the following:
To declare an field as "computed" add its full field path to the `computed_fields` field under the respective `kubernetes_manifest` resource. For example, to declare the "metadata.labels" field as "computed", add the following:
```
resource "kubernetes_manifest" "test-ns" {
@ -231,8 +228,8 @@ The following arguments are supported:
#### Arguments
- `rollout` (Optional) When set to `true` will wait for the resource to roll out, equivalent to `kubectl rollout status`.
- `condition` (Optional) A set of condition to wait for. You can specify multiple `condition` blocks and it will wait for all of them.
- `rollout` (Optional) When set to `true` will wait for the resource to roll out, equivalent to `kubectl rollout status`.
- `condition` (Optional) A set of condition to wait for. You can specify multiple `condition` blocks and it will wait for all of them.
- `fields` (Optional) A map of field paths and a corresponding regular expression with a pattern to wait for. The provider will wait until the field's value matches the regular expression. Use `*` for any value.
A field path is a string that describes the fully qualified address of a field within the resource, including its parent fields all the way up to "object". The syntax of a path string follows the rules below:
@ -262,8 +259,7 @@ A field path is a string that describes the fully qualified address of a field w
#### Arguments
- `fields` (Optional) A map of fields and a corresponding regular expression with a pattern to wait for. The provider will wait until the field matches the regular expression. Use `*` for any value.
- `fields` (Optional) A map of fields and a corresponding regular expression with a pattern to wait for. The provider will wait until the field matches the regular expression. Use `*` for any value.
### `field_manager`

20
website/docs/r/mutating_webhook_configuration.html.markdown → docs/resources/mutating_webhook_configuration.md
View file

@ -1,6 +1,5 @@
---
subcategory: "admissionregistration/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_mutating_webhook_configuration"
description: |-
Mutating Webhook Configuration configures a mutating admission webhook
@ -12,7 +11,7 @@ Mutating Webhook Configuration configures a [mutating admission webhook](https:/
## Example Usage
```hcl
```terraform
resource "kubernetes_mutating_webhook_configuration" "example" {
metadata {
name = "test.terraform.io"
@ -44,7 +43,6 @@ resource "kubernetes_mutating_webhook_configuration" "example" {
}
```
## API version support
The provider supports clusters running either `v1` or `v1beta1` of the Admission Registration API.
@ -62,12 +60,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the Mutating Webhook Configuration that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the Mutating Webhook Configuration that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Mutating Webhook Configuration. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Mutating Webhook Configuration. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -75,7 +73,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this Mutating Webhook Configuration that can be used by clients to determine when Mutating Webhook Configuration has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this Mutating Webhook Configuration. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -85,25 +82,24 @@ The following arguments are supported:
#### Arguments
* `admission_review_versions` - (Optional) AdmissionReviewVersions is an ordered list of preferred `AdmissionReview` versions the Webhook expects. API server will try to use first version in the list which it supports. If none of the versions specified in this list are supported by API server, validation will fail for this object. If a persisted webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail and be subject to the failure policy.
* `client_config` - (Required) ClientConfig defines how to communicate with the hook.
* `client_config` - (Required) ClientConfig defines how to communicate with the hook.
* `failure_policy` - (Optional) FailurePolicy defines how unrecognized errors from the admission endpoint are handled - Allowed values are "Ignore" or "Fail". Defaults to "Fail".
* `match_policy` - (Optional) matchPolicy defines how the "rules" list is used to match incoming requests. Allowed values are "Exact" or "Equivalent". - Exact: match a request only if it exactly matches a specified rule. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, but "rules" only included `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]`, a request to apps/v1beta1 or extensions/v1beta1 would not be sent to the webhook. - Equivalent: match a request if modifies a resource listed in rules, even via another API group or version. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, and "rules" only included `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]`, a request to apps/v1beta1 or extensions/v1beta1 would be converted to apps/v1 and sent to the webhook. Defaults to "Equivalent"
* `name` - (Required) The name of the admission webhook. Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where "imagepolicy" is the name of the webhook, and kubernetes.io is the name of the organization.
* `namespace_selector` - (Optional) NamespaceSelector decides whether to run the webhook on an object based on whether the namespace for that object matches the selector. If the object itself is a namespace, the matching is performed on object.metadata.labels. If the object is another cluster scoped resource, it never skips the webhook. For example, to run the webhook on any objects whose namespace is not associated with "runlevel" of "0" or "1"; you will set the selector as follows: "namespaceSelector": { "matchExpressions": [ { "key": "runlevel", "operator": "NotIn", "values": [ "0", "1" ] } ] } If instead you want to only run the webhook on any objects whose namespace is associated with the "environment" of "prod" or "staging"; you will set the selector as follows: "namespaceSelector": { "matchExpressions": [ { "key": "environment", "operator": "In", "values": [ "prod", "staging" ] } ] } See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors. Default to the empty LabelSelector, which matches everything.
* `object_selector` - (Optional) ObjectSelector decides whether to run the webhook based on if the object has matching labels. objectSelector is evaluated against both the oldObject and newObject that would be sent to the webhook, and is considered to match if either object matches the selector. A null object (oldObject in the case of create, or newObject in the case of delete) or an object that cannot have labels (like a DeploymentRollback or a PodProxyOptions object) is not considered to match. Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels. Default to the empty LabelSelector, which matches everything.
* `reinvocation_policy` - (Optional) reinvocationPolicy indicates whether this webhook should be called multiple times as part of a single admission evaluation. Allowed values are "Never" and "IfNeeded". Never: the webhook will not be called more than once in a single admission evaluation. IfNeeded: the webhook will be called at least one additional time as part of the admission evaluation if the object being admitted is modified by other admission plugins after the initial webhook call. Webhooks that specify this option *must* be idempotent, able to process objects they previously admitted. Note: *the number of additional invocations is not guaranteed to be exactly one.* if additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again. *webhooks that use this option may be reordered to minimize the number of additional invocations.* to validate an object after all mutations are guaranteed complete, use a validating admission webhook instead. Defaults to "Never".
* `rule` - (Optional) Describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.
* `rule` - (Optional) Describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches *any* Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.
* `side_effects` - (Required) SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some.
* `timeout_seconds` - (Optional) TimeoutSeconds specifies the timeout for this webhook. After the timeout passes, the webhook call will be ignored or the API call will fail based on the failure policy. The timeout value must be between 1 and 30 seconds. Default to 10 seconds.
### `client_config`
#### Arguments
* `ca_bundle` - (Optional) A PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used.
* `service` - (Optional) A reference to the service for this webhook. Either `service` or `url` must be specified. If the webhook is running within the cluster, then you should use `service`.
* `url` - (Optional) Gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
* `url` - (Optional) Gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
~> Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
@ -111,8 +107,8 @@ The following arguments are supported:
#### Arguments
* `name` - (Required) The name of the service.
* `namespace` - (Required) The namespace of the service.
* `name` - (Required) The name of the service.
* `namespace` - (Required) The namespace of the service.
* `path` - (Optional) The URL path which will be sent in any request to this service.
* `port` - (Optional) If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).

20
website/docs/r/mutating_webhook_configuration_v1.html.markdown → docs/resources/mutating_webhook_configuration_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "admissionregistration/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_mutating_webhook_configuration_v1"
description: |-
Mutating Webhook Configuration configures a mutating admission webhook
@ -12,7 +11,7 @@ Mutating Webhook Configuration configures a [mutating admission webhook](https:/
## Example Usage
```hcl
```terraform
resource "kubernetes_mutating_webhook_configuration_v1" "example" {
metadata {
name = "test.terraform.io"
@ -44,7 +43,6 @@ resource "kubernetes_mutating_webhook_configuration_v1" "example" {
}
```
## API version support
The provider supports clusters running either `v1` or `v1beta1` of the Admission Registration API.
@ -62,12 +60,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the Mutating Webhook Configuration that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the Mutating Webhook Configuration that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Mutating Webhook Configuration. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Mutating Webhook Configuration. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -75,7 +73,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this Mutating Webhook Configuration that can be used by clients to determine when Mutating Webhook Configuration has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this Mutating Webhook Configuration. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -85,25 +82,24 @@ The following arguments are supported:
#### Arguments
* `admission_review_versions` - (Optional) AdmissionReviewVersions is an ordered list of preferred `AdmissionReview` versions the Webhook expects. API server will try to use first version in the list which it supports. If none of the versions specified in this list are supported by API server, validation will fail for this object. If a persisted webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail and be subject to the failure policy.
* `client_config` - (Required) ClientConfig defines how to communicate with the hook.
* `client_config` - (Required) ClientConfig defines how to communicate with the hook.
* `failure_policy` - (Optional) FailurePolicy defines how unrecognized errors from the admission endpoint are handled - Allowed values are "Ignore" or "Fail". Defaults to "Fail".
* `match_policy` - (Optional) matchPolicy defines how the "rules" list is used to match incoming requests. Allowed values are "Exact" or "Equivalent". - Exact: match a request only if it exactly matches a specified rule. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, but "rules" only included `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]`, a request to apps/v1beta1 or extensions/v1beta1 would not be sent to the webhook. - Equivalent: match a request if modifies a resource listed in rules, even via another API group or version. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, and "rules" only included `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]`, a request to apps/v1beta1 or extensions/v1beta1 would be converted to apps/v1 and sent to the webhook. Defaults to "Equivalent"
* `name` - (Required) The name of the admission webhook. Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where "imagepolicy" is the name of the webhook, and kubernetes.io is the name of the organization.
* `namespace_selector` - (Optional) NamespaceSelector decides whether to run the webhook on an object based on whether the namespace for that object matches the selector. If the object itself is a namespace, the matching is performed on object.metadata.labels. If the object is another cluster scoped resource, it never skips the webhook. For example, to run the webhook on any objects whose namespace is not associated with "runlevel" of "0" or "1"; you will set the selector as follows: "namespaceSelector": { "matchExpressions": [ { "key": "runlevel", "operator": "NotIn", "values": [ "0", "1" ] } ] } If instead you want to only run the webhook on any objects whose namespace is associated with the "environment" of "prod" or "staging"; you will set the selector as follows: "namespaceSelector": { "matchExpressions": [ { "key": "environment", "operator": "In", "values": [ "prod", "staging" ] } ] } See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors. Default to the empty LabelSelector, which matches everything.
* `object_selector` - (Optional) ObjectSelector decides whether to run the webhook based on if the object has matching labels. objectSelector is evaluated against both the oldObject and newObject that would be sent to the webhook, and is considered to match if either object matches the selector. A null object (oldObject in the case of create, or newObject in the case of delete) or an object that cannot have labels (like a DeploymentRollback or a PodProxyOptions object) is not considered to match. Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels. Default to the empty LabelSelector, which matches everything.
* `reinvocation_policy` - (Optional) reinvocationPolicy indicates whether this webhook should be called multiple times as part of a single admission evaluation. Allowed values are "Never" and "IfNeeded". Never: the webhook will not be called more than once in a single admission evaluation. IfNeeded: the webhook will be called at least one additional time as part of the admission evaluation if the object being admitted is modified by other admission plugins after the initial webhook call. Webhooks that specify this option *must* be idempotent, able to process objects they previously admitted. Note: *the number of additional invocations is not guaranteed to be exactly one.* if additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again. *webhooks that use this option may be reordered to minimize the number of additional invocations.* to validate an object after all mutations are guaranteed complete, use a validating admission webhook instead. Defaults to "Never".
* `rule` - (Optional) Describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.
* `rule` - (Optional) Describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches *any* Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.
* `side_effects` - (Required) SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some.
* `timeout_seconds` - (Optional) TimeoutSeconds specifies the timeout for this webhook. After the timeout passes, the webhook call will be ignored or the API call will fail based on the failure policy. The timeout value must be between 1 and 30 seconds. Default to 10 seconds.
### `client_config`
#### Arguments
* `ca_bundle` - (Optional) A PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used.
* `service` - (Optional) A reference to the service for this webhook. Either `service` or `url` must be specified. If the webhook is running within the cluster, then you should use `service`.
* `url` - (Optional) Gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
* `url` - (Optional) Gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
~> Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
@ -111,8 +107,8 @@ The following arguments are supported:
#### Arguments
* `name` - (Required) The name of the service.
* `namespace` - (Required) The namespace of the service.
* `name` - (Required) The name of the service.
* `namespace` - (Required) The namespace of the service.
* `path` - (Optional) The URL path which will be sent in any request to this service.
* `port` - (Optional) If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).

14
website/docs/r/namespace.html.markdown → docs/resources/namespace.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_namespace"
description: |-
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
@ -8,12 +7,11 @@ description: |-
# kubernetes_namespace
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
Read more about namespaces at [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. Read more about namespaces at [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
## Example Usage
```hcl
```terraform
resource "kubernetes_namespace" "example" {
metadata {
annotations = {
@ -37,8 +35,7 @@ The following arguments are supported:
### Timeouts
`kubernetes_namespace` provides the following
[Timeouts](/docs/configuration/resources.html#timeouts) configuration options:
`kubernetes_namespace` provides the following [Timeouts](/docs/configuration/resources.html#timeouts) configuration options:
- `delete` - Default `5 minutes`
@ -48,12 +45,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the namespace that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the namespace that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/).
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more about [name idempotency](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency).
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) namespaces. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) namespaces. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
@ -76,4 +73,3 @@ Namespaces can be imported using their name, e.g.
```
$ terraform import kubernetes_namespace.n terraform-example-namespace
```

13
website/docs/r/namespace_v1.html.markdown → docs/resources/namespace_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_namespace_v1"
description: |-
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
@ -8,12 +7,11 @@ description: |-
# kubernetes_namespace_v1
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
Read more about namespaces at [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. Read more about namespaces at [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
## Example Usage
```hcl
```terraform
resource "kubernetes_namespace_v1" "example" {
metadata {
annotations = {
@ -37,8 +35,7 @@ The following arguments are supported:
### Timeouts
`kubernetes_namespace_v1` provides the following
[Timeouts](/docs/configuration/resources.html#timeouts) configuration options:
`kubernetes_namespace_v1` provides the following [Timeouts](/docs/configuration/resources.html#timeouts) configuration options:
- `delete` - Default `5 minutes`
@ -48,12 +45,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the namespace that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the namespace that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more about [name idempotency](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency).
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) namespaces. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) namespaces. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)

21
website/docs/r/network_policy.html.markdown → docs/resources/network_policy.md
View file

@ -1,6 +1,5 @@
---
subcategory: "networking/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_network_policy"
description: |-
Kubernetes supports network policies to specify how groups of pods are allowed to communicate with each other and with other network endpoints.
@ -9,13 +8,11 @@ description: |-
# kubernetes_network_policy
Kubernetes supports network policies to specify how groups of pods are allowed to communicate with each other and with other network endpoints.
NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods.
Read more about network policies at https://kubernetes.io/docs/concepts/services-networking/network-policies/
Kubernetes supports network policies to specify how groups of pods are allowed to communicate with each other and with other network endpoints. NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods. Read more about network policies at https://kubernetes.io/docs/concepts/services-networking/network-policies/
## Example Usage
```hcl
```terraform
resource "kubernetes_network_policy" "example" {
metadata {
name = "terraform-example-network-policy"
@ -96,7 +93,6 @@ The following arguments are supported:
* `resource_version` - An opaque value that represents the internal version of this network policy that can be used by clients to determine when network policies have changed. Read more about [concurrency control and consistency](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency).
* `uid` - The unique in time and space value for this network policy. For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids
### `spec`
#### Arguments
@ -104,8 +100,8 @@ The following arguments are supported:
* `egress` - (Optional) List of egress rules to be applied to the selected pods. Outgoing traffic is allowed if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic matches at least one egress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this block is empty then this NetworkPolicy allows all outgoing traffic. If this block is omitted then this NetworkPolicy does not allow any outgoing traffic (and serves solely to ensure that the pods it selects are isolated by default).
* `ingress` - (Optional) List of ingress rules to be applied to the selected pods. Traffic is allowed to a pod if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic source is the pod's local node, OR if the traffic matches at least one ingress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this block is empty then this NetworkPolicy allows all incoming traffic. If this block is omitted then this NetworkPolicy does not allow any incoming traffic (and serves solely to ensure that the pods it selects are isolated by default).
* `pod_selector` - (Required) Selects the pods to which this NetworkPolicy object applies. The array of ingress rules is applied to any pods selected by this field. Multiple network policies can select the same set of pods. In this case, the ingress rules for each are combined additively. This field is NOT optional and follows standard label selector semantics. An empty podSelector matches all pods in this namespace.
* `policy_types` (Required) List of rule types that the NetworkPolicy relates to. Valid options are `Ingress`, `Egress`, or `Ingress,Egress`. This field is beta-level in 1.8
**Note**: the native Kubernetes API allows not to specify the `policy_types` property with the following description:
* `policy_types` (Required) List of rule types that the NetworkPolicy relates to. Valid options are `Ingress`, `Egress`, or `Ingress,Egress`. This field is beta-level in 1.8 **Note**: the native Kubernetes API allows not to specify the `policy_types` property with the following description:
> If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]).
Leaving the `policy_types` property optional here would have prevented an `egress` rule added to a Network Policy initially created without any `egress` rule nor `policy_types` from working as expected. Indeed, the PolicyTypes would have stuck to Ingress server side as the default value is only computed server side on resource creation, not on updates.
@ -131,7 +127,6 @@ The following arguments are supported:
* `namespace_selector` - (Optional) Selects Namespaces using cluster scoped-labels. This matches all pods in all namespaces selected by this label selector. This field follows standard label selector semantics. If present but empty, this selector selects all namespaces.
* `pod_selector` - (Optional) This is a label selector which selects Pods in this namespace. This field follows standard label selector semantics. If present but empty, this selector selects all pods in this namespace.
### `ports`
#### Arguments
@ -139,7 +134,6 @@ The following arguments are supported:
* `port` - (Optional) The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers.
* `protocol` - (Optional) The protocol (TCP or UDP) which traffic must match. If not specified, this field defaults to TCP.
### `to`
#### Arguments
@ -152,7 +146,7 @@ The following arguments are supported:
#### Arguments
* `cidr` - (Optional) CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"
* `cidr` - (Optional) CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"
* `except` - (Optional) Except is a slice of CIDRs that should not be included within an IP Block. Valid examples are "192.168.1.1/24". Except values will be rejected if they are outside the CIDR range.
### `namespace_selector`
@ -162,7 +156,6 @@ The following arguments are supported:
* `match_expressions` - (Optional) A list of label selector requirements. The requirements are ANDed.
* `match_labels` - (Optional) A map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of `match_expressions`, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
### `pod_selector`
#### Arguments
@ -170,7 +163,6 @@ The following arguments are supported:
* `match_expressions` - (Optional) A list of label selector requirements. The requirements are ANDed.
* `match_labels` - (Optional) A map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of `match_expressions`, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
### `match_expressions`
#### Arguments
@ -179,10 +171,9 @@ The following arguments are supported:
* `operator` - (Optional) A key's relationship to a set of values. Valid operators ard `In`, `NotIn`, `Exists` and `DoesNotExist`.
* `values` - (Optional) An array of string values. If the operator is `In` or `NotIn`, the values array must be non-empty. If the operator is `Exists` or `DoesNotExist`, the values array must be empty. This array is replaced during a strategic merge patch.
## Import
Network policies can be imported using their identifier consisting of `<namespace-name>/<network-policy-name>`, e.g.:
Network policies can be imported using their identifier consisting of `<namespace-name>/<network-policy-name>`, e.g.:
```
$ terraform import kubernetes_network_policy.example default/terraform-example-network-policy

21
website/docs/r/network_policy_v1.html.markdown → docs/resources/network_policy_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "networking/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_network_policy_v1"
description: |-
Kubernetes supports network policies to specify how groups of pods are allowed to communicate with each other and with other network endpoints.
@ -9,13 +8,11 @@ description: |-
# kubernetes_network_policy_v1
Kubernetes supports network policies to specify how groups of pods are allowed to communicate with each other and with other network endpoints.
NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods.
Read more about network policies at https://kubernetes.io/docs/concepts/services-networking/network-policies/
Kubernetes supports network policies to specify how groups of pods are allowed to communicate with each other and with other network endpoints. NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods. Read more about network policies at https://kubernetes.io/docs/concepts/services-networking/network-policies/
## Example Usage
```hcl
```terraform
resource "kubernetes_network_policy_v1" "example" {
metadata {
name = "terraform-example-network-policy"
@ -96,7 +93,6 @@ The following arguments are supported:
* `resource_version` - An opaque value that represents the internal version of this network policy that can be used by clients to determine when network policies have changed. Read more about [concurrency control and consistency](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency).
* `uid` - The unique in time and space value for this network policy. For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids
### `spec`
#### Arguments
@ -104,8 +100,8 @@ The following arguments are supported:
* `egress` - (Optional) List of egress rules to be applied to the selected pods. Outgoing traffic is allowed if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic matches at least one egress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this block is empty then this NetworkPolicy allows all outgoing traffic. If this block is omitted then this NetworkPolicy does not allow any outgoing traffic (and serves solely to ensure that the pods it selects are isolated by default).
* `ingress` - (Optional) List of ingress rules to be applied to the selected pods. Traffic is allowed to a pod if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic source is the pod's local node, OR if the traffic matches at least one ingress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this block is empty then this NetworkPolicy allows all incoming traffic. If this block is omitted then this NetworkPolicy does not allow any incoming traffic (and serves solely to ensure that the pods it selects are isolated by default).
* `pod_selector` - (Required) Selects the pods to which this NetworkPolicy object applies. The array of ingress rules is applied to any pods selected by this field. Multiple network policies can select the same set of pods. In this case, the ingress rules for each are combined additively. This field is NOT optional and follows standard label selector semantics. An empty podSelector matches all pods in this namespace.
* `policy_types` (Required) List of rule types that the NetworkPolicy relates to. Valid options are `Ingress`, `Egress`, or `Ingress,Egress`. This field is beta-level in 1.8
**Note**: the native Kubernetes API allows not to specify the `policy_types` property with the following description:
* `policy_types` (Required) List of rule types that the NetworkPolicy relates to. Valid options are `Ingress`, `Egress`, or `Ingress,Egress`. This field is beta-level in 1.8 **Note**: the native Kubernetes API allows not to specify the `policy_types` property with the following description:
> If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]).
Leaving the `policy_types` property optional here would have prevented an `egress` rule added to a Network Policy initially created without any `egress` rule nor `policy_types` from working as expected. Indeed, the PolicyTypes would have stuck to Ingress server side as the default value is only computed server side on resource creation, not on updates.
@ -131,7 +127,6 @@ The following arguments are supported:
* `namespace_selector` - (Optional) Selects Namespaces using cluster scoped-labels. This matches all pods in all namespaces selected by this label selector. This field follows standard label selector semantics. If present but empty, this selector selects all namespaces.
* `pod_selector` - (Optional) This is a label selector which selects Pods in this namespace. This field follows standard label selector semantics. If present but empty, this selector selects all pods in this namespace.
### `ports`
#### Arguments
@ -139,7 +134,6 @@ The following arguments are supported:
* `port` - (Optional) The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers.
* `protocol` - (Optional) The protocol (TCP or UDP) which traffic must match. If not specified, this field defaults to TCP.
### `to`
#### Arguments
@ -152,7 +146,7 @@ The following arguments are supported:
#### Arguments
* `cidr` - (Optional) CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"
* `cidr` - (Optional) CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"
* `except` - (Optional) Except is a slice of CIDRs that should not be included within an IP Block. Valid examples are "192.168.1.1/24". Except values will be rejected if they are outside the CIDR range.
### `namespace_selector`
@ -162,7 +156,6 @@ The following arguments are supported:
* `match_expressions` - (Optional) A list of label selector requirements. The requirements are ANDed.
* `match_labels` - (Optional) A map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of `match_expressions`, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
### `pod_selector`
#### Arguments
@ -170,7 +163,6 @@ The following arguments are supported:
* `match_expressions` - (Optional) A list of label selector requirements. The requirements are ANDed.
* `match_labels` - (Optional) A map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of `match_expressions`, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
### `match_expressions`
#### Arguments
@ -179,10 +171,9 @@ The following arguments are supported:
* `operator` - (Optional) A key's relationship to a set of values. Valid operators ard `In`, `NotIn`, `Exists` and `DoesNotExist`.
* `values` - (Optional) An array of string values. If the operator is `In` or `NotIn`, the values array must be non-empty. If the operator is `Exists` or `DoesNotExist`, the values array must be empty. This array is replaced during a strategic merge patch.
## Import
Network policies can be imported using their identifier consisting of `<namespace-name>/<network-policy-name>`, e.g.:
Network policies can be imported using their identifier consisting of `<namespace-name>/<network-policy-name>`, e.g.:
```
$ terraform import kubernetes_network_policy_v1.example default/terraform-example-network-policy

6
website/docs/r/node_taint.html.markdown → docs/resources/node_taint.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_node_taint"
description: |-
A Node Taint is an anti-affinity rule allowing a Kubernetes node to repel a set of pods.
@ -12,7 +11,7 @@ description: |-
## Example Usage
```hcl
```terraform
resource "kubernetes_node_taint" "example" {
metadata {
name = "my-node.my-cluster.k8s.local"
@ -25,7 +24,6 @@ resource "kubernetes_node_taint" "example" {
}
```
## Argument Reference
The following arguments are supported:
@ -49,7 +47,7 @@ The following arguments are supported:
* `key` - (Required, Forces new resource) The key of this node taint.
* `value` - (Required) The value of this node taint. Can be empty string.
* `effect` - (Required, Forces new resource) The scheduling effect to apply with this taint. Must be one of: `NoSchedule`, `PreferNoSchedule`, `NoExecute`.
* `effect` - (Required, Forces new resource) The scheduling effect to apply with this taint. Must be one of: `NoSchedule`, `PreferNoSchedule`, `NoExecute`.
## Import

15
website/docs/r/persistent_volume.html.markdown → docs/resources/persistent_volume.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_persistent_volume"
description: |-
A Persistent Volume (PV) is a piece of networked storage in the cluster that has been provisioned by an administrator.
@ -8,12 +7,11 @@ description: |-
# kubernetes_persistent_volume
The resource provides a piece of networked storage in the cluster provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. Persistent Volumes have a lifecycle independent of any individual pod that uses the PV.
For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
The resource provides a piece of networked storage in the cluster provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. Persistent Volumes have a lifecycle independent of any individual pod that uses the PV. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
## Example Usage
```hcl
```terraform
resource "kubernetes_persistent_volume" "example" {
metadata {
name = "terraform-example"
@ -34,7 +32,7 @@ resource "kubernetes_persistent_volume" "example" {
## Example: Persistent Volume using Azure Managed Disk
```hcl
```terraform
resource "kubernetes_persistent_volume" "example" {
metadata {
name = "example"
@ -100,7 +98,7 @@ The following arguments are supported:
* `storage_class_name` - (Optional) The name of the persistent volume's storage class. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class)
* `mount_options` - (Optional) A Kubernetes administrator can specify additional mount options for when a Persistent Volume is mounted on a node.
~> Not all Persistent Volume types support mount options. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options)
~> Not all Persistent Volume types support mount options. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options)
* `volume_mode` - (Optional) Defines if a volume is used with a formatted filesystem or to remain in raw block state. Possible values are `Block` and `Filesystem`. Default value is `Filesystem`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#volume-mode)
@ -155,7 +153,6 @@ The following arguments are supported:
* `rbd` - (Optional) Represents a Rados Block Device mount on the host that shares a pod's lifetime. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#rbd.
* `vsphere_volume` - (Optional) Represents a vSphere volume attached and mounted on kubelets host machine.
### `aws_elastic_block_store`
#### Arguments
@ -191,7 +188,7 @@ The following arguments are supported:
* `monitors` - (Required) Monitors is a collection of Ceph monitors. For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `path` - (Optional) Used as the mounted root, rather than the full Ceph tree, default is /.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to `false` (read/write). For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to `false` (read/write). For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `secret_file` - (Optional) The path to key ring for User, default is /etc/ceph/user.secret. For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `secret_ref` - (Optional) Reference to the authentication secret for User, default is empty. sFor more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it. see [secret_ref](#secret_ref) for more details.
* `user` - (Optional) User is the rados user name, default is admin. For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
@ -201,7 +198,7 @@ The following arguments are supported:
#### Arguments
* `fs_type` - (Optional) Filesystem type to mount. Must be a filesystem type supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to false (read/write). For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to false (read/write). For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
* `volume_id` - (Required) Volume ID used to identify the volume in Cinder. For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
### `csi`

8
website/docs/r/persistent_volume_claim.html.markdown → docs/resources/persistent_volume_claim.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_persistent_volume_claim"
description: |-
This resource allows the user to request for and claim to a persistent volume.
@ -12,7 +11,7 @@ This resource allows the user to request for and claim to a persistent volume.
## Example Usage
```hcl
```terraform
resource "kubernetes_persistent_volume_claim" "example" {
metadata {
name = "exampleclaimname"
@ -60,12 +59,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the persistent volume claim that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the persistent volume claim that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the persistent volume claim. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the persistent volume claim. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -97,7 +96,6 @@ The following arguments are supported:
* `operator` - (Optional) A key's relationship to a set of values. Valid operators ard `In`, `NotIn`, `Exists` and `DoesNotExist`.
* `values` - (Optional) An array of string values. If the operator is `In` or `NotIn`, the values array must be non-empty. If the operator is `Exists` or `DoesNotExist`, the values array must be empty. This array is replaced during a strategic merge patch.
### `resources`
#### Arguments

8
website/docs/r/persistent_volume_claim_v1.html.markdown → docs/resources/persistent_volume_claim_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_persistent_volume_claim_v1"
description: |-
This resource allows the user to request for and claim to a persistent volume.
@ -12,7 +11,7 @@ This resource allows the user to request for and claim to a persistent volume.
## Example Usage
```hcl
```terraform
resource "kubernetes_persistent_volume_claim_v1" "example" {
metadata {
name = "exampleclaimname"
@ -60,12 +59,12 @@ The following arguments are supported:
#### Arguments
* `annotations` - (Optional) An unstructured key value map stored with the persistent volume claim that may be used to store arbitrary metadata.
* `annotations` - (Optional) An unstructured key value map stored with the persistent volume claim that may be used to store arbitrary metadata.
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the persistent volume claim. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the persistent volume claim. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -97,7 +96,6 @@ The following arguments are supported:
* `operator` - (Optional) A key's relationship to a set of values. Valid operators ard `In`, `NotIn`, `Exists` and `DoesNotExist`.
* `values` - (Optional) An array of string values. If the operator is `In` or `NotIn`, the values array must be non-empty. If the operator is `Exists` or `DoesNotExist`, the values array must be empty. This array is replaced during a strategic merge patch.
### `resources`
#### Arguments

15
website/docs/r/persistent_volume_v1.html.markdown → docs/resources/persistent_volume_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_persistent_volume_v1"
description: |-
A Persistent Volume (PV) is a piece of networked storage in the cluster that has been provisioned by an administrator.
@ -8,12 +7,11 @@ description: |-
# kubernetes_persistent_volume_v1
The resource provides a piece of networked storage in the cluster provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. Persistent Volumes have a lifecycle independent of any individual pod that uses the PV.
For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
The resource provides a piece of networked storage in the cluster provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. Persistent Volumes have a lifecycle independent of any individual pod that uses the PV. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
## Example Usage
```hcl
```terraform
resource "kubernetes_persistent_volume_v1" "example" {
metadata {
name = "terraform-example"
@ -34,7 +32,7 @@ resource "kubernetes_persistent_volume_v1" "example" {
## Example: Persistent Volume using Azure Managed Disk
```hcl
```terraform
resource "kubernetes_persistent_volume_v1" "example" {
metadata {
name = "example"
@ -100,7 +98,7 @@ The following arguments are supported:
* `storage_class_name` - (Optional) The name of the persistent volume's storage class. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class)
* `mount_options` - (Optional) A Kubernetes administrator can specify additional mount options for when a Persistent Volume is mounted on a node.
~> Not all Persistent Volume types support mount options. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options)
~> Not all Persistent Volume types support mount options. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options)
* `volume_mode` - (Optional) Defines if a volume is used with a formatted filesystem or to remain in raw block state. Possible values are `Block` and `Filesystem`. Default value is `Filesystem`. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#volume-mode)
@ -155,7 +153,6 @@ The following arguments are supported:
* `rbd` - (Optional) Represents a Rados Block Device mount on the host that shares a pod's lifetime. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#rbd.
* `vsphere_volume` - (Optional) Represents a vSphere volume attached and mounted on kubelets host machine.
### `aws_elastic_block_store`
#### Arguments
@ -191,7 +188,7 @@ The following arguments are supported:
* `monitors` - (Required) Monitors is a collection of Ceph monitors. For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `path` - (Optional) Used as the mounted root, rather than the full Ceph tree, default is /.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to `false` (read/write). For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to `false` (read/write). For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `secret_file` - (Optional) The path to key ring for User, default is /etc/ceph/user.secret. For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
* `secret_ref` - (Optional) Reference to the authentication secret for User, default is empty. sFor more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it. see [secret_ref](#secret_ref) for more details.
* `user` - (Optional) User is the rados user name, default is admin. For more info see https://github.com/kubernetes/examples/tree/master/volumes/cephfs/#how-to-use-it.
@ -201,7 +198,7 @@ The following arguments are supported:
#### Arguments
* `fs_type` - (Optional) Filesystem type to mount. Must be a filesystem type supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to false (read/write). For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
* `read_only` - (Optional) Whether to force the read-only setting in VolumeMounts. Defaults to false (read/write). For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
* `volume_id` - (Required) Volume ID used to identify the volume in Cinder. For more info see https://github.com/kubernetes/examples/blob/master/mysql-cinder-pd/README.md#mysql-installation-with-cinder-volume-plugin.
### `csi`

19
website/docs/r/pod.html.markdown → docs/resources/pod.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod"
description: |-
A pod is a group of one or more containers, the shared storage for those containers, and options about how to run the containers. Pods are always co-located and co-scheduled, and run in a shared context.
@ -14,7 +13,7 @@ Read more at [Kubernetes reference](https://kubernetes.io/docs/concepts/workload
## Example Usage
```hcl
```terraform
resource "kubernetes_pod" "test" {
metadata {
name = "terraform-example"
@ -71,7 +70,7 @@ resource "kubernetes_pod" "test" {
terraform version of the [pods/pod-with-node-affinity.yaml](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/pod-with-node-affinity.yaml) example.
```hcl
```terraform
resource "kubernetes_pod" "with_node_affinity" {
metadata {
name = "with-node-affinity"
@ -114,7 +113,7 @@ resource "kubernetes_pod" "with_node_affinity" {
terraform version of the [pods/pod-with-pod-affinity.yaml](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/pod-with-pod-affinity.yaml) example.
```hcl
```terraform
resource "kubernetes_pod" "with_pod_affinity" {
metadata {
name = "with-pod-affinity"
@ -292,7 +291,7 @@ The following arguments are supported:
* `key` - (Required) The label key that the selector applies to.
* `operator` - (Required) Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
* `operator` - (Required) Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
* `values` - (Optional) An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer.
@ -346,7 +345,7 @@ The following arguments are supported:
* `lifecycle` - (Optional) Actions that the management system should take in response to container lifecycle events
* `liveness_probe` - (Optional) Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `name` - (Required) Name of the container specified as a DNS_LABEL. Each container in a pod must have a unique name (DNS_LABEL). Cannot be updated.
* `port` - (Optional) Block(s) of [port](#port)s to expose on the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. May be used multiple times. Cannot be updated.
* `port` - (Optional) Block(s) of [port](#port)s to expose on the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. May be used multiple times. Cannot be updated.
* `readiness_probe` - (Optional) Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `resources` - (Optional) Compute Resources required by this container. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources)
* `security_context` - (Optional) Security options the pod should run with. For more info see https://kubernetes.io/docs/tasks/configure-pod-container/security-context/.
@ -629,7 +628,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -714,7 +713,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -733,7 +732,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}
@ -933,7 +932,7 @@ The `items` block supports the following:
* `photon_persistent_disk` - (Optional) Represents a PhotonController persistent disk attached and mounted on kubelets host machine
* `projected` (Optional) Items for all in one resources secrets, configmaps, and downward API.
* `quobyte` - (Optional) Quobyte represents a Quobyte mount on the host that shares a pod's lifetime
* `rbd` - (Optional) Represents a Rados Block Device mount on the host that shares a pod's lifetime. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#rbd.
* `rbd` - (Optional) Represents a Rados Block Device mount on the host that shares a pod's lifetime. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#rbd.
* `secret` - (Optional) Secret represents a secret that should populate this volume. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#secrets)
* `vsphere_volume` - (Optional) Represents a vSphere volume attached and mounted on kubelets host machine

11
website/docs/r/pod_disruption_budget.html.markdown → docs/resources/pod_disruption_budget.md
View file

@ -1,6 +1,5 @@
---
subcategory: "policy/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod_disruption_budget"
description: |-
A Pod Disruption Budget limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.
@ -8,13 +7,13 @@ description: |-
# kubernetes_pod_disruption_budget
A Pod Disruption Budget limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions.
For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.
A Pod Disruption Budget limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions.
For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.
## Example Usage
```hcl
```terraform
resource "kubernetes_pod_disruption_budget" "demo" {
metadata {
name = "demo"
@ -48,7 +47,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#idempotency
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

11
website/docs/r/pod_disruption_budget_v1.html.markdown → docs/resources/pod_disruption_budget_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "policy/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod_disruption_budget_v1"
description: |-
A Pod Disruption Budget limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.
@ -8,13 +7,13 @@ description: |-
# kubernetes_pod_disruption_budget_v1
A Pod Disruption Budget limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions.
For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.
A Pod Disruption Budget limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions.
For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.
## Example Usage
```hcl
```terraform
resource "kubernetes_pod_disruption_budget_v1" "demo" {
metadata {
name = "demo"
@ -48,7 +47,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. Read more: https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#idempotency
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the service. May match selectors of replication controllers and services.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

19
website/docs/r/pod_security_policy.html.markdown → docs/resources/pod_security_policy.md
View file

@ -1,6 +1,5 @@
---
subcategory: "policy/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod_security_policy"
description: |-
A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification.
@ -14,7 +13,7 @@ A Pod Security Policy is a cluster-level resource that controls security sensiti
## Example Usage
```hcl
```terraform
resource "kubernetes_pod_security_policy" "example" {
metadata {
name = "terraform-example"
@ -79,7 +78,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/e59e666e3464c7d4851136baa8835a311efdfb8e/contributors/devel/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Pod Security Policy.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Pod Security Policy.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -87,7 +86,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this Pod Security Policy that can be used by clients to determine when Pod Security Policy has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/e59e666e3464c7d4851136baa8835a311efdfb8e/contributors/devel/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this Pod Security Policy. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -98,11 +96,11 @@ The following arguments are supported:
* `allow_privilege_escalation` - (Optional) determines if a pod can request to allow privilege escalation. If unspecified, defaults to true.
* `allowed_capabilities` - (Optional) a list of capabilities that can be requested to add to the container. Capabilities in this field may be added at the pod author's discretion. You must not list a capability in both allowedCapabilities and requiredDropCapabilities.
* [`allowed_flex_volumes`](#allowed_flex_volumes) - (Optional) a whitelist of allowed Flexvolumes. Empty or nil indicates that all Flexvolumes may be used. This parameter is effective only when the usage of the Flexvolumes is allowed in the "volumes" field.
* [`allowed_flex_volumes`](#allowed_flex_volumes) - (Optional) a whitelist of allowed Flexvolumes. Empty or nil indicates that all Flexvolumes may be used. This parameter is effective only when the usage of the Flexvolumes is allowed in the "volumes" field.
* [`allowed_host_paths`](#allowed_host_paths) - (Optional) a white list of allowed host paths. Empty indicates that all host paths may be used.
* `allowed_proc_mount_types` - (Optional) a whitelist of allowed ProcMountTypes. Empty or nil indicates that only the DefaultProcMountType may be used. This requires the ProcMountType feature flag to be enabled. Possible values are `"Default"` or `"Unmasked"`
* `allowed_unsafe_sysctls` - (Optional) a list of explicitly allowed unsafe sysctls, defaults to none. Each entry is either a plain sysctl name or ends in "*" in which case it is considered as a prefix of allowed sysctls. Single* means all unsafe sysctls are allowed. Kubelet has to whitelist all allowed unsafe sysctls explicitly to avoid rejection. Examples: "foo/*" allows "foo/bar", "foo/baz", etc. and "foo.*" allows "foo.bar", "foo.baz", etc.
* `default_add_capabilities` - (Optional) the default set of capabilities that will be added to the container unless the pod spec specifically drops the capability. You may not list a capability in both defaultAddCapabilities and requiredDropCapabilities. Capabilities added here are implicitly allowed, and need not be included in the allowedCapabilities list.
* `default_add_capabilities` - (Optional) the default set of capabilities that will be added to the container unless the pod spec specifically drops the capability. You may not list a capability in both defaultAddCapabilities and requiredDropCapabilities. Capabilities added here are implicitly allowed, and need not be included in the allowedCapabilities list.
* `default_allow_privilege_escalation` - (Optional) controls the default setting for whether a process can gain more privileges than its parent process.
* `forbidden_sysctls` - (Optional) forbiddenSysctls is a list of explicitly forbidden sysctls, defaults to none. Each entry is either a plain sysctl name or ends in "*" in which case it is considered as a prefix of forbidden sysctls. Single* means all sysctls are forbidden.
* [`fs_group`](#fs_group) - (Required) the strategy that will dictate what fs group is used by the SecurityContext.
@ -111,8 +109,8 @@ The following arguments are supported:
* `host_pid` - (Optional) determines if the policy allows the use of HostPID in the pod spec.
* `host_ports` - (Optional) determines which host port ranges are allowed to be exposed.
* `privileged` - (Optional) determines if a pod can request to be run as privileged.
* `read_only_root_filesystem` - (Optional) when set to true will force containers to run with a read only root file system. If the container specifically requests to run with a non-read only root file system the PSP should deny the pod. If set to false the container may run with a read only root file system if it wishes but it will not be forced to.
* `required_drop_capabilities` - (Optional) the capabilities that will be dropped from the container. These are required to be dropped and cannot be added.
* `read_only_root_filesystem` - (Optional) when set to true will force containers to run with a read only root file system. If the container specifically requests to run with a non-read only root file system the PSP should deny the pod. If set to false the container may run with a read only root file system if it wishes but it will not be forced to.
* `required_drop_capabilities` - (Optional) the capabilities that will be dropped from the container. These are required to be dropped and cannot be added.
* [`run_as_user`](#run_as_user) - (Required) the strategy that will dictate the allowable RunAsUser values that may be set.
* [`run_as_group`](#run_as_group) - (Optional) the strategy that will dictate the allowable RunAsGroup values that may be set. If this field is omitted, the pod's RunAsGroup can take any value. This field requires the RunAsGroup feature gate to be enabled.
* [`se_linux`](#se_linux) - (Required) the strategy that will dictate the allowable labels that may be set.
@ -137,7 +135,7 @@ The following arguments are supported:
#### Arguments
* `rule` - (Required) the strategy that will dictate what FSGroup is used in the SecurityContext.
* `range` - (Optional) the allowed ranges of fs groups. If you would like to force a single fs group then supply a single range with the same start and end. Required for MustRunAs.
* `range` - (Optional) the allowed ranges of fs groups. If you would like to force a single fs group then supply a single range with the same start and end. Required for MustRunAs.
### `run_as_user`
@ -165,8 +163,7 @@ The following arguments are supported:
#### Arguments
* `rule` - (Required) the strategy that will dictate what supplemental groups is used in the SecurityContext.
* `range` - (Optional) the allowed ranges of supplemental groups. If you would like to force a single supplemental group then supply a single range with the same start and end. Required for MustRunAs.
* `range` - (Optional) the allowed ranges of supplemental groups. If you would like to force a single supplemental group then supply a single range with the same start and end. Required for MustRunAs.
### `range`

19
website/docs/r/pod_security_policy_v1beta1.html.markdown → docs/resources/pod_security_policy_v1beta1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "policy/v1beta1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod_security_policy_v1beta1"
description: |-
A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification.
@ -14,7 +13,7 @@ A Pod Security Policy is a cluster-level resource that controls security sensiti
## Example Usage
```hcl
```terraform
resource "kubernetes_pod_security_policy_v1beta1" "example" {
metadata {
name = "terraform-example"
@ -79,7 +78,7 @@ The following arguments are supported:
~> By default, the provider ignores any annotations whose key names end with *kubernetes.io*. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
* `generate_name` - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the `name` field has not been provided. This value will also be combined with a unique suffix. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/e59e666e3464c7d4851136baa8835a311efdfb8e/contributors/devel/api-conventions.md#idempotency)
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Pod Security Policy.
* `labels` - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the Pod Security Policy.
~> By default, the provider ignores any labels whose key names end with *kubernetes.io*. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
@ -87,7 +86,6 @@ The following arguments are supported:
#### Attributes
* `generation` - A sequence number representing a specific generation of the desired state.
* `resource_version` - An opaque value that represents the internal version of this Pod Security Policy that can be used by clients to determine when Pod Security Policy has changed. For more info see [Kubernetes reference](https://github.com/kubernetes/community/blob/e59e666e3464c7d4851136baa8835a311efdfb8e/contributors/devel/api-conventions.md#concurrency-control-and-consistency)
* `uid` - The unique in time and space value for this Pod Security Policy. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)
@ -98,11 +96,11 @@ The following arguments are supported:
* `allow_privilege_escalation` - (Optional) determines if a pod can request to allow privilege escalation. If unspecified, defaults to true.
* `allowed_capabilities` - (Optional) a list of capabilities that can be requested to add to the container. Capabilities in this field may be added at the pod author's discretion. You must not list a capability in both allowedCapabilities and requiredDropCapabilities.
* [`allowed_flex_volumes`](#allowed_flex_volumes) - (Optional) a whitelist of allowed Flexvolumes. Empty or nil indicates that all Flexvolumes may be used. This parameter is effective only when the usage of the Flexvolumes is allowed in the "volumes" field.
* [`allowed_flex_volumes`](#allowed_flex_volumes) - (Optional) a whitelist of allowed Flexvolumes. Empty or nil indicates that all Flexvolumes may be used. This parameter is effective only when the usage of the Flexvolumes is allowed in the "volumes" field.
* [`allowed_host_paths`](#allowed_host_paths) - (Optional) a white list of allowed host paths. Empty indicates that all host paths may be used.
* `allowed_proc_mount_types` - (Optional) a whitelist of allowed ProcMountTypes. Empty or nil indicates that only the DefaultProcMountType may be used. This requires the ProcMountType feature flag to be enabled. Possible values are `"Default"` or `"Unmasked"`
* `allowed_unsafe_sysctls` - (Optional) a list of explicitly allowed unsafe sysctls, defaults to none. Each entry is either a plain sysctl name or ends in "*" in which case it is considered as a prefix of allowed sysctls. Single* means all unsafe sysctls are allowed. Kubelet has to whitelist all allowed unsafe sysctls explicitly to avoid rejection. Examples: "foo/*" allows "foo/bar", "foo/baz", etc. and "foo.*" allows "foo.bar", "foo.baz", etc.
* `default_add_capabilities` - (Optional) the default set of capabilities that will be added to the container unless the pod spec specifically drops the capability. You may not list a capability in both defaultAddCapabilities and requiredDropCapabilities. Capabilities added here are implicitly allowed, and need not be included in the allowedCapabilities list.
* `default_add_capabilities` - (Optional) the default set of capabilities that will be added to the container unless the pod spec specifically drops the capability. You may not list a capability in both defaultAddCapabilities and requiredDropCapabilities. Capabilities added here are implicitly allowed, and need not be included in the allowedCapabilities list.
* `default_allow_privilege_escalation` - (Optional) controls the default setting for whether a process can gain more privileges than its parent process.
* `forbidden_sysctls` - (Optional) forbiddenSysctls is a list of explicitly forbidden sysctls, defaults to none. Each entry is either a plain sysctl name or ends in "*" in which case it is considered as a prefix of forbidden sysctls. Single* means all sysctls are forbidden.
* [`fs_group`](#fs_group) - (Required) the strategy that will dictate what fs group is used by the SecurityContext.
@ -111,8 +109,8 @@ The following arguments are supported:
* `host_pid` - (Optional) determines if the policy allows the use of HostPID in the pod spec.
* `host_ports` - (Optional) determines which host port ranges are allowed to be exposed.
* `privileged` - (Optional) determines if a pod can request to be run as privileged.
* `read_only_root_filesystem` - (Optional) when set to true will force containers to run with a read only root file system. If the container specifically requests to run with a non-read only root file system the PSP should deny the pod. If set to false the container may run with a read only root file system if it wishes but it will not be forced to.
* `required_drop_capabilities` - (Optional) the capabilities that will be dropped from the container. These are required to be dropped and cannot be added.
* `read_only_root_filesystem` - (Optional) when set to true will force containers to run with a read only root file system. If the container specifically requests to run with a non-read only root file system the PSP should deny the pod. If set to false the container may run with a read only root file system if it wishes but it will not be forced to.
* `required_drop_capabilities` - (Optional) the capabilities that will be dropped from the container. These are required to be dropped and cannot be added.
* [`run_as_user`](#run_as_user) - (Required) the strategy that will dictate the allowable RunAsUser values that may be set.
* [`run_as_group`](#run_as_group) - (Optional) the strategy that will dictate the allowable RunAsGroup values that may be set. If this field is omitted, the pod's RunAsGroup can take any value. This field requires the RunAsGroup feature gate to be enabled.
* [`se_linux`](#se_linux) - (Required) the strategy that will dictate the allowable labels that may be set.
@ -137,7 +135,7 @@ The following arguments are supported:
#### Arguments
* `rule` - (Required) the strategy that will dictate what FSGroup is used in the SecurityContext.
* `range` - (Optional) the allowed ranges of fs groups. If you would like to force a single fs group then supply a single range with the same start and end. Required for MustRunAs.
* `range` - (Optional) the allowed ranges of fs groups. If you would like to force a single fs group then supply a single range with the same start and end. Required for MustRunAs.
### `run_as_user`
@ -165,8 +163,7 @@ The following arguments are supported:
#### Arguments
* `rule` - (Required) the strategy that will dictate what supplemental groups is used in the SecurityContext.
* `range` - (Optional) the allowed ranges of supplemental groups. If you would like to force a single supplemental group then supply a single range with the same start and end. Required for MustRunAs.
* `range` - (Optional) the allowed ranges of supplemental groups. If you would like to force a single supplemental group then supply a single range with the same start and end. Required for MustRunAs.
### `range`

19
website/docs/r/pod_v1.html.markdown → docs/resources/pod_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_pod_v1"
description: |-
A pod is a group of one or more containers, the shared storage for those containers, and options about how to run the containers. Pods are always co-located and co-scheduled, and run in a shared context.
@ -14,7 +13,7 @@ Read more at [Kubernetes reference](https://kubernetes.io/docs/concepts/workload
## Example Usage
```hcl
```terraform
resource "kubernetes_pod_v1" "test" {
metadata {
name = "terraform-example"
@ -71,7 +70,7 @@ resource "kubernetes_pod_v1" "test" {
terraform version of the [pods/pod-with-node-affinity.yaml](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/pod-with-node-affinity.yaml) example.
```hcl
```terraform
resource "kubernetes_pod_v1" "with_node_affinity" {
metadata {
name = "with-node-affinity"
@ -114,7 +113,7 @@ resource "kubernetes_pod_v1" "with_node_affinity" {
terraform version of the [pods/pod-with-pod-affinity.yaml](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/pod-with-pod-affinity.yaml) example.
```hcl
```terraform
resource "kubernetes_pod_v1" "with_pod_affinity" {
metadata {
name = "with-pod-affinity"
@ -292,7 +291,7 @@ The following arguments are supported:
* `key` - (Required) The label key that the selector applies to.
* `operator` - (Required) Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
* `operator` - (Required) Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
* `values` - (Optional) An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer.
@ -346,7 +345,7 @@ The following arguments are supported:
* `lifecycle` - (Optional) Actions that the management system should take in response to container lifecycle events
* `liveness_probe` - (Optional) Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `name` - (Required) Name of the container specified as a DNS_LABEL. Each container in a pod must have a unique name (DNS_LABEL). Cannot be updated.
* `port` - (Optional) Block(s) of [port](#port)s to expose on the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. May be used multiple times. Cannot be updated.
* `port` - (Optional) Block(s) of [port](#port)s to expose on the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. May be used multiple times. Cannot be updated.
* `readiness_probe` - (Optional) Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `resources` - (Optional) Compute Resources required by this container. Cannot be updated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources)
* `security_context` - (Optional) Security options the pod should run with. For more info see https://kubernetes.io/docs/tasks/configure-pod-container/security-context/.
@ -619,7 +618,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before liveness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -704,7 +703,7 @@ The `option` block supports the following:
* `exec` - (Optional) exec specifies the action to take.
* `failure_threshold` - (Optional) Minimum consecutive failures for the probe to be considered failed after having succeeded.
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `grpc` - (Optional) GRPC specifies an action involving a GRPC port. **NOTE: This field is behind a [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) prior to v1.24**
* `http_get` - (Optional) Specifies the http request to perform.
* `initial_delay_seconds` - (Optional) Number of seconds after the container has started before readiness probes are initiated. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
* `period_seconds` - (Optional) How often (in seconds) to perform the probe
@ -723,7 +722,7 @@ The `option` block supports the following:
Please, look at the example below:
```hcl
```terraform
resources {
limits = {}
requests = {}
@ -921,7 +920,7 @@ The `items` block supports the following:
* `photon_persistent_disk` - (Optional) Represents a PhotonController persistent disk attached and mounted on kubelets host machine
* `projected` (Optional) Items for all in one resources secrets, configmaps, and downward API.
* `quobyte` - (Optional) Quobyte represents a Quobyte mount on the host that shares a pod's lifetime
* `rbd` - (Optional) Represents a Rados Block Device mount on the host that shares a pod's lifetime. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#rbd.
* `rbd` - (Optional) Represents a Rados Block Device mount on the host that shares a pod's lifetime. For more info see https://kubernetes.io/docs/concepts/storage/volumes/#rbd.
* `secret` - (Optional) Secret represents a secret that should populate this volume. For more info see [Kubernetes reference](https://kubernetes.io/docs/concepts/storage/volumes#secrets)
* `vsphere_volume` - (Optional) Represents a vSphere volume attached and mounted on kubelets host machine

4
website/docs/r/priority_class.html.markdown → docs/resources/priority_class.md
View file

@ -1,6 +1,5 @@
---
subcategory: "scheduling/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_priority_class"
description: |-
A PriorityClass is a non-namespaced object that defines a mapping from a priority class name to the integer value of the priority.
@ -12,7 +11,7 @@ A PriorityClass is a non-namespaced object that defines a mapping from a priorit
## Example Usage
```hcl
```terraform
resource "kubernetes_priority_class" "example" {
metadata {
name = "terraform-example"
@ -32,7 +31,6 @@ The following arguments are supported:
* `global_default` - (Optional) Boolean that specifies whether this PriorityClass should be considered as the default priority for pods that do not have any priority class.
* `preemption_policy` - (Optional) PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset.
## Nested Blocks
### `metadata`

4
website/docs/r/priority_class_v1.html.markdown → docs/resources/priority_class_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "scheduling/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_priority_class_v1"
description: |-
A PriorityClass is a non-namespaced object that defines a mapping from a priority class name to the integer value of the priority.
@ -12,7 +11,7 @@ A PriorityClass is a non-namespaced object that defines a mapping from a priorit
## Example Usage
```hcl
```terraform
resource "kubernetes_priority_class_v1" "example" {
metadata {
name = "terraform-example"
@ -62,4 +61,3 @@ Priority Class can be imported using its name, e.g.
```
$ terraform import kubernetes_priority_class_v1.example terraform-example
```

3
website/docs/r/replication_controller.html.markdown → docs/resources/replication_controller.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_replication_controller"
description: |-
A Replication Controller ensures that a specified number of pod “replicas” are running at any one time. In other words, a Replication Controller makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the Replication Controller will start more.
@ -14,7 +13,7 @@ A Replication Controller ensures that a specified number of pod “replicas” a
## Example Usage
```hcl
```terraform
resource "kubernetes_replication_controller" "example" {
metadata {
name = "terraform-example"

3
website/docs/r/replication_controller_v1.html.markdown → docs/resources/replication_controller_v1.md
View file

@ -1,6 +1,5 @@
---
subcategory: "core/v1"
layout: "kubernetes"
page_title: "Kubernetes: kubernetes_replication_controller_v1"
description: |-
A Replication Controller ensures that a specified number of pod “replicas” are running at any one time. In other words, a Replication Controller makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the Replication Controller will start more.
@ -14,7 +13,7 @@ A Replication Controller ensures that a specified number of pod “replicas” a
## Example Usage
```hcl
```terraform
resource "kubernetes_replication_controller_v1" "example" {
metadata {
name = "terraform-example"

Some files were not shown because too many files have changed in this diff Show more