whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Official 1.14 Release Docs (#13174)

Browse Source 
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)

* Added documentation about Poseidon-Firmament scheduler

* Fixed some style issues.

* Udpated the document as per the review comments.

* Fixed some typos and updated the document

* Updated the document as per the review comments.

* Document timeout attribute for kms-plugin. (#12158)

See 72540.

* Official documentation on Poseidon/Firmament, a new multi-scheduler  (#12343)

* Removed the old version of the Poseidon documentation. Incorrect location.

* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S (#12069)

* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)

* Added documentation about Poseidon-Firmament scheduler

* Fixed some style issues.

* Udpated the document as per the review comments.

* Fixed some typos and updated the document

* Updated the document as per the review comments.

* Updated the document as per review comments. Added config details.

* Updated the document as per the latest review comments. Fixed nits

* Made changes as per latest suggestions.

* Some more changes added.

* Updated as per suggestions.

* Changed the release process section.

* SIG Docs edits

Small edits to match style guidelines.

* add plus to feature state

* capitalization

* revert feature state shortcode

since this is a Kubernetes extension, not a direct feature, it shouldn't use the regular feature state tagging.

(cherry picked from commit 7730c1540b)

* Remove initializers from doc. It will be removed in 1.14 (#12331)

* kubeadm: Document CRI auto detection functionality (#12462)

Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>

* Minor doc change for GAing Pod DNS Config (#12514)

* Graduate ExpandInUsePersistentVolumes feature to beta (#10574)

* Rename 2018-11-07-grpc-load-balancing-with-linkerd.md.md file (#12594)

* Add dynamic percentage of node scoring to user docs (#12235)

* Add dynamic percentage of node scoring to user docs

* addressed review comments

* delete special symbol (#12445)

* Update documentation for VolumeSubpathEnvExpansion (#11843)

* Update documentation for VolumeSubpathEnvExpansion

* Address comments - improve descriptions

* Graduate Pod Priority and Preemption to GA (#12428)

* Added Instana links to the documentation (#12977)

* Added link to the Instana Kubernetes integration

* Added Instana link for services section

Added Instana and a link to the Kubernetes integration to the analytics services section and broadened the scope to APM, monitoring and analytics.

* Oxford comma /flex

* More Oxford commas, because they matter

* Update kubectl plugins to stable (#12847)

* documentation for CSI topology beta (#12889)

* Document changes to default RBAC discovery ClusterRole(Binding)s (#12888)

* Document changes to default RBAC discovery ClusterRole(Binding)s

Documentation for https://github.com/kubernetes/enhancements/issues/789 and https://github.com/kubernetes/kubernetes/pull/73807

* documentation review feedback

* CSI raw block to beta (#12931)

* Change incorrect string raw to block (#12926)

Fixes #12925

* Update documentation on node OS/arch labels (#12976)

These labels have been promoted to GA:
https://github.com/kubernetes/enhancements/issues/793

* local pv GA doc updates (#12915)

* Publish CRD OpenAPI Documentation (#12910)

* add documentation for CustomResourcePublishOpenAPI

* address comments

fix links, ordered lists, style and typo

* kubeadm: add document for upgrading from 1.13 to 1.14 (single CP and HA) (#13189)

* kubeadm: add document for upgrading from 1.13 to 1.14

- remove doc for upgrading 1.10 -> 1.11

* kubeadm: apply amends to upgrade-1.14 doc

* kubeadm: apply amends to upgrade-1.14 doc (part2)

* kubeadm: apply amends to upgrade-1.14 doc (part3)

* kubeadm: add note about "upgrade node experimental-control-plane"

+ add comment about `upgrade plan`

* kubeadm: add missing "You should see output similar to this"

* fix bullet indentation (#13214)

* mark PodReadinessGate GA (#12800)

* Update RuntimeClass documentation for beta (#13043)

* Update RuntimeClass documentation for beta

* Update feature gate & add upgrade section

* formatting fixes

* Highlight upgrade action required

* Address feedback

* CSI ephemeral volume alpha documentation (#10934)

* update kubectl documentation (#12867)

* update kubectl documentation

* add document for Secret/ConfigMap generators

* replace `kubectl create -f` by `kubectl apply -f`

* Add page for kustomization support in kubectl

* fix spelling errors and address comments

* Documentation for Windows GMSA feature (#12936)

* Documentation for Windows GMSA feature

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Enhancements to GMSA docs

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Fix links

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Fix GMSA link

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add GMSA feature flag in feature flag list

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Relocate GMSA to container configuration

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add example for container spec

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Remove changes in Windows index

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Update configure-gmsa.md

* Update configure-gmsa.md

* Update configure-gmsa.md

* Update configure-gmsa.md

* Rearrange the steps into two sections and other edits

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Fix links

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add reference to script to generate GMSA YAMLs

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Some more clarifications for GMSA

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* HugePages graduated to GA (#13004)

* HugePages graduated to GA

* fixing nit for build

* Docs for node PID limiting (https://github.com/kubernetes/kubernetes/pull/73651) (#12932)

* kubeadm: update the reference documentation for 1.14 (#12911)

* kubeadm: update list of generated files for 1.14

NOTE: PLACEHOLDERS! these files are generated by SIG Docs each
release, but we need them to pass the k/website PR CI.

- add join_phase* (new sub phases of join)
- add init_phase_upload-certs.md (new upload certs phase for init)
- remove alpha-preflight (now both init and join have this)

* kubeadm: update reference docs includes for 1.14

- remove includes from alpha.md
- add upload-certs to init-phase.md
- add join-phase.md and it's phases

* kubeadm: update the editorial content of join and init

- cleanup master->control-plane node
- add some notes about phases and join
- remove table about pre-pulling images
- remove outdated info about self-hosting

* kubeadm: update target release for v1alpha3 removal

1.14 -> 1.15

* kubeadm: copy edits for 1.14 reference docs (part1)

* kubeadm: use "shell" for code blocks

* kubeadm: update the 1.14 HA guide (#13191)

* kubeadm: update the 1.14 HA guide

* kubeadm: try to fix note/caution indent in HA page

* kubeadm: fix missing sudo and minor amends in HA doc

* kubeadm: apply latest amends to the HA doc for 1.14

* fixed a few missed merge conflicts

* Admission Webhook new features doc (#12938)

- kubernetes/kubernetes#74998
- kubernetes/kubernetes#74477
- kubernetes/kubernetes#74562

* Clarifications and fixes in GMSA doc (#13226)

* Clarifications and fixes in GMSA doc

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Update configure-gmsa.md

* Reformat to align headings and pre-reqs better

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Reformat to align headings and pre-reqs better

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Reformat to fix bullets

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Reword application of sample gmsa

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Update configure-gmsa.md

* Address feedback to use active voice

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Address feedback to use active voice

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* RunAsGroup documentation for Progressing this to Beta (#12297)

* start serverside-apply documentation (#13077)

* start serverside-apply documentation

* add more concept info on server side apply

* Update api concepts

* Update api-concepts.md

* fix style issues

* Document CSI update (#12928)

* Document CSI update

* Finish CSI documentation

Also fix mistake with  ExpandInUsePersistentVolumes documented as beta

* Overall docs for CSI Migration feature (#12935)

* Placeholder docs for CSI Migration feature

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Address CR comments and update feature gates

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add mappings for CSI plugins

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add sections for AWS and GCE PD migration

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add docs for Cinder and CSI Migration info

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Clarify scope to volumes with file system

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Change the format of EBS and Cinder CSI Migration sections to follow the GCE template

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Windows documentation updates for 1.14 (#12929)

* Updated the note to indicate doc work for 1.14

* first attempt at md export from gdoc

* simplifyig

* big attempt

* moving DRAFT windows content to PR for review

* moving content to PR in markdown for review

* updated note tags

* Delete windows-contributing.md

deleting this file as it is already ported to the github contributor guide

* fixed formatting in intro and cluster setup guide

* updating formatting for running containers guide

* rejiggered end of troubleshooting

* fixed minor typos

* Clarified the windows binary download step

* Update _index.md

making updates based on feedback

* Update _index.md

updating ovn-kubernetes docs

* Update _index.md

* Update _index.md

* updating relative docs links

updating all the links to be relative links to /docs

* Update _index.md

* Update _index.md

updates for windows services and ovn-kubernetes

* formatted for correct step numbering

* fix typos

* Update _index.md

updates for flannel PR in troubleshooting

* Update _index.md

* Update _index.md

updating a few sections like roadmap, services, troubleshooting/filing tickets

* Update _index.md

* Update _index.md

* Update _index.md

* Fixed a few whitespace issues

* Update _index.md

* Update _index.md

* Update _index.md

* add section on upgrading CoreDNS (#12909)

* documentation for kubelet resource metrics endpoint (#12934)

* windows docs updates for 1.14 (#13279)

* Delete sample-l2bridge-wincni-config.json

this file is not used anywhere

* Update _index.md

* Update _index.md

* Update _index.md

* Update _index.md

* Update _index.md

* Rename content/en/docs/getting-started-guides/windows/_index.md to content/en/docs/setup/windows/_index.md

moving to new location

* Delete flannel-master-kubectl-get-ds.png

* Delete flannel-master-kubeclt-get-pods.png

* Delete windows-docker-error.png

* Add files via upload

* Rename _index.md to add-windows-nodes.md

* Create _index.md

* Update _index.md

* Update add-windows-nodes.md

* Update add-windows-nodes.md

* Create user-guide-windows-nodes.md

* Create user-guide-windows-containers.md

* Update and rename add-windows-nodes.md to intro-windows-nodes.md

* Update user-guide-windows-containers.md

* Rename intro-windows-nodes.md to intro-windows-in-kubernetes.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-containers.md

* Update user-guide-windows-containers.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-containers.md

* Update _index.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

fixing the pause image

* Update intro-windows-in-kubernetes.md

changing tables from html to MD

* Update user-guide-windows-nodes.md

converting tables from HTML to MD

* Update intro-windows-in-kubernetes.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-nodes.md

updating the numbering , even though it messes up the notes a little bit. Jim will file a ticket to follow up

* Update user-guide-windows-nodes.md

* update to windows docs for 1.14 (#13322)

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update user-guide-windows-containers.md

* Update user-guide-windows-nodes.md

* Update intro-windows-in-kubernetes.md (#13344)

* server side apply followup (#13321)

* change some parts of serverside apply docs in response to comments

* fix typos and wording

* Update config.toml (#13365)
This commit is contained in:
Jim Angel
2019-03-25 17:06:16 -05:00
committed by Kubernetes Prow Robot
parent 28dd4d5154
commit 851ef58fa8
160 changed files with 4319 additions and 1812 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+1 -1
View File
@@ -44,7 +44,7 @@ directory of the nginx server.
Create the Pod and the two Containers:
kubectl create -f https://k8s.io/examples/pods/two-container-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml
View information about the Pod and the Containers:
content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+3 -3
View File
@@ -49,7 +49,7 @@ file for the backend Deployment:
Create the backend Deployment:
```shell
kubectl create -f https://k8s.io/examples/service/access/hello.yaml
kubectl apply -f https://k8s.io/examples/service/access/hello.yaml
```
View information about the backend Deployment:
@@ -113,7 +113,7 @@ that have the labels `app: hello` and `tier: backend`.
Create the `hello` Service:
```shell
kubectl create -f https://k8s.io/examples/service/access/hello-service.yaml
kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
```
At this point, you have a backend Deployment running, and you have a
@@ -140,7 +140,7 @@ the Service uses the default load balancer of your cloud provider.
Create the frontend Deployment and Service:
```shell
kubectl create -f https://k8s.io/examples/service/access/frontend.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml
```
The output verifies that both resources were created:
content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+2 -2
View File
@@ -28,7 +28,7 @@ for database debugging.
1. Create a Redis deployment:
kubectl create -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
The output of a successful command verifies that the deployment was created:
@@ -64,7 +64,7 @@ for database debugging.
2. Create a Redis service:
kubectl create -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
The output of a successful command verifies that the service was created:
content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+1 -1
View File
@@ -30,7 +30,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
The Dashboard UI is not deployed by default. To deploy it, run the following command:
```
kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml
```
## Accessing the Dashboard UI
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
+2 -2
View File
@@ -87,10 +87,10 @@ spec:
```
You can save the CustomResourceDefinition in a YAML file, then use
`kubectl create` to create it.
`kubectl apply` to create it.
```shell
kubectl create -f my-versioned-crontab.yaml
kubectl apply -f my-versioned-crontab.yaml
```
After creation, the API server starts to serve each enabled version at an HTTP
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
+62 -10
View File
@@ -70,7 +70,7 @@ spec:
And create it:
```shell
kubectl create -f resourcedefinition.yaml
kubectl apply -f resourcedefinition.yaml
```
Then a new namespaced RESTful API endpoint is created at:
@@ -112,7 +112,7 @@ spec:
and create it:
```shell
kubectl create -f my-crontab.yaml
kubectl apply -f my-crontab.yaml
```
You can then manage your CronTab objects using kubectl. For example:
@@ -288,7 +288,7 @@ spec:
And create it:
```shell
kubectl create -f resourcedefinition.yaml
kubectl apply -f resourcedefinition.yaml
```
A request to create a custom object of kind `CronTab` will be rejected if there are invalid values in its fields.
@@ -313,7 +313,7 @@ spec:
and create it:
```shell
kubectl create -f my-crontab.yaml
kubectl apply -f my-crontab.yaml
```
you will get an error:
@@ -343,10 +343,62 @@ spec:
And create it:
```shell
kubectl create -f my-crontab.yaml
kubectl apply -f my-crontab.yaml
crontab "my-new-cron-object" created
```
### Publish Validation Schema in OpenAPI v2
{{< feature-state state="alpha" for_kubernetes_version="1.14" >}}
Starting with Kubernetes 1.14, [custom resource validation schema](#validation) can be published as part
of [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from
Kubernetes API server.
[kubectl](/docs/reference/kubectl/overview) consumes the published schema to perform client-side validation
(`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources.
The published schema can be consumed for other purposes. The feature is Alpha in 1.14 and disabled by default.
You can enable the feature using the `CustomResourcePublishOpenAPI` feature gate on the
[kube-apiserver](/docs/admin/kube-apiserver):
```
--feature-gates=CustomResourcePublishOpenAPI=true
```
Custom resource validation schema will be converted to OpenAPI v2 schema, and
show up in `definitions` and `paths` fields in the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions).
The following modifications are applied during the conversion to keep backwards compatiblity with
kubectl in previous 1.13 version. These modifications prevent kubectl from being over-strict and rejecting
valid OpenAPI schemas that it doesn't understand. The conversion won't modify the validation schema defined in CRD,
and therefore won't affect [validation](#validation) in the API server.
1. The following fields are removed as they aren't supported by OpenAPI v2 (in future versions OpenAPI v3 will be used without these restrictions)
- The fields `oneOf`, `anyOf` and `not` are removed
2. The following fields are removed as they aren't allowed by kubectl in
previous 1.13 version
- For a schema with a `$ref`
- the fields `properties` and `type` are removed
- if the `$ref` is outside of the `definitions`, the field `$ref` is removed
- For a schema of a primitive data type (which means the field `type` has two elements: one type and one format)
- if any one of the two elements is `null`, the field `type` is removed
- otherwise, the fields `type` and `properties` are removed
- For a schema of more than two types
- the fields `type` and `properties` are removed
- For a schema of `null` type
- the field `type` is removed
- For a schema of `array` type
- if the schema doesn't have exactly one item, the fields `type` and `items` are
removed
- For a schema with no type specified
- the field `properties` is removed
3. The following fields are removed as they aren't supported by the OpenAPI protobuf implementation
- The fields `id`, `schema`, `definitions`, `additionalItems`, `dependencies`,
and `patternProperties` are removed
- For a schema with a `externalDocs`
- if the `externalDocs` has `url` defined, the field `externalDocs` is removed
- For a schema with `items` defined
- if the field `items` has multiple schemas, the field `items` is removed
### Additional printer columns
Starting with Kubernetes 1.11, kubectl uses server-side printing. The server decides which
@@ -387,7 +439,7 @@ columns.
2. Create the CustomResourceDefinition:
```shell
kubectl create -f resourcedefinition.yaml
kubectl apply -f resourcedefinition.yaml
```
3. Create an instance using the `my-crontab.yaml` from the previous section.
@@ -560,7 +612,7 @@ spec:
And create it:
```shell
kubectl create -f resourcedefinition.yaml
kubectl apply -f resourcedefinition.yaml
```
After the CustomResourceDefinition object has been created, you can create custom objects.
@@ -581,7 +633,7 @@ spec:
and create it:
```shell
kubectl create -f my-crontab.yaml
kubectl apply -f my-crontab.yaml
```
Then new namespaced RESTful API endpoints are created at:
@@ -645,7 +697,7 @@ spec:
And create it:
```shell
kubectl create -f resourcedefinition.yaml
kubectl apply -f resourcedefinition.yaml
```
After the CustomResourceDefinition object has been created, you can create custom objects.
@@ -665,7 +717,7 @@ spec:
and create it:
```shell
kubectl create -f my-crontab.yaml
kubectl apply -f my-crontab.yaml
```
You can specify the category using `kubectl get`:
content/en/docs/tasks/administer-cluster/coredns.md
+13 -2
View File
@@ -29,7 +29,9 @@ deployment, or by using tools like kubeadm that will deploy and upgrade the clus
For manual deployment or replacement of kube-dns, see the documentation at the
[CoreDNS GitHub project.](https://github.com/coredns/deployment/tree/master/kubernetes)
## Upgrading an existing cluster with kubeadm
## Migrating to CoreDNS
### Upgrading an existing cluster with kubeadm
In Kubernetes version 1.10 and later, you can also move to CoreDNS when you use `kubeadm` to upgrade
a cluster that is using `kube-dns`. In this case, `kubeadm` will generate the CoreDNS configuration
@@ -53,7 +55,8 @@ customizations after the new ConfigMap is up and running.
If you are running CoreDNS in Kubernetes version 1.11 and later, during upgrade,
your existing Corefile will be retained.
## Installing kube-dns instead of CoreDNS with kubeadm
### Installing kube-dns instead of CoreDNS with kubeadm
{{< note >}}
In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
@@ -69,6 +72,14 @@ kubeadm init --feature-gates=CoreDNS=false
For versions 1.13 and later, follow the guide outlined [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon).
## Upgrading CoreDNS
CoreDNS is available in Kubernetes since v1.9.
You can check the version of CoreDNS shipped with Kubernetes and the changes made to CoreDNS [here](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md).
CoreDNS can be upgraded manually in case you want to only upgrade CoreDNS or use your own custom image.
There is a helpful [guideline and walkthrough](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md) available to ensure a smooth upgrade.
## Tuning CoreDNS
When resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the
content/en/docs/tasks/administer-cluster/declare-network-policy.md
+1 -1
View File
@@ -110,7 +110,7 @@ spec:
Use kubectl to create a NetworkPolicy from the above nginx-policy.yaml file:
```console
kubectl create -f nginx-policy.yaml
kubectl apply -f nginx-policy.yaml
```
```none
content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
+1 -1
View File
@@ -27,7 +27,7 @@ Create a file named busybox.yaml with the following contents:
Then create a pod using this file and verify its status:
```shell
kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml
kubectl apply -f https://k8s.io/examples/admin/dns/busybox.yaml
pod/busybox created
kubectl get pods busybox
content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+1 -1
View File
@@ -98,7 +98,7 @@ In the file, replace `<SCALE_TARGET>` with your scale target.
Go to the directory that contains your configuration file, and enter this
command to create the Deployment:
kubectl create -f dns-horizontal-autoscaler.yaml
kubectl apply -f dns-horizontal-autoscaler.yaml
The output of a successful command is:
content/en/docs/tasks/administer-cluster/ip-masq-agent.md
+1 -1
View File
@@ -61,7 +61,7 @@ By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7
To create an ip-masq-agent, run the following kubectl command:
`
kubectl create -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml
`
You must also apply the appropriate node label to any nodes in your cluster that you want the agent to run on.
content/en/docs/tasks/administer-cluster/kms-provider.md
+3 -1
View File
@@ -31,7 +31,8 @@ To configure a KMS provider on the API server, include a provider of type ```kms
* `name`: Display name of the KMS plugin.
* `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket.
* `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap..
* `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap.
* `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds).
See [Understanding the encryption at rest configuration.](/docs/tasks/administer-cluster/encrypt-data)
@@ -89,6 +90,7 @@ resources:
name: myKmsPlugin
endpoint: unix:///tmp/socketfile.sock
cachesize: 100
timeout: 3s
- identity: {}
```
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11.md
-279
View File
@@ -1,279 +0,0 @@
---
reviewers:
- sig-cluster-lifecycle
title: Upgrading kubeadm clusters from v1.10 to v1.11
content_template: templates/task
---
{{% capture overview %}}
This page explains how to upgrade a Kubernetes cluster created with `kubeadm` from version 1.10.x to version 1.11.x, and from version 1.11.x to 1.11.y, where `y > x`.
{{% /capture %}}
{{% capture prerequisites %}}
- You need to have a `kubeadm` Kubernetes cluster running version 1.10.0 or later. Swap must be disabled. The cluster should use a static control plane and etcd pods.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md) carefully.
- Make sure to back up any important components, such as app-level state stored in a database. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
### Additional information
- All containers are restarted after upgrade, because the container spec hash value is changed.
- You can upgrade only from one minor version to the next minor version. That is, you cannot skip versions when you upgrade. For example, you can upgrade only from 1.10 to 1.11, not from 1.9 to 1.11.
- The default DNS provider in version 1.11 is [CoreDNS](https://coredns.io/) rather than [kube-dns](https://github.com/kubernetes/dns).
To keep `kube-dns`, pass `--feature-gates=CoreDNS=false` to `kubeadm upgrade apply`.
{{% /capture %}}
{{% capture steps %}}
## Upgrade the control plane
1. On your master node, run the following (as root):
export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
chmod a+rx /usr/bin/kubeadm
Note that upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade. Even though `kubeadm` ships in the Kubernetes repositories, it's important to install it manually. The kubeadm team is working on fixing this limitation.
1. Verify that the download works and has the expected version:
```shell
kubeadm version
```
1. On the master node, run:
```shell
kubeadm upgrade plan
```
You should see output similar to this:
<!-- TODO: copy-paste actual output once new version is stable -->
```shell
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
I0618 20:32:32.950358 15307 feature_gate.go:230] feature gates: &{map[]}
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.10.4
[upgrade/versions] kubeadm version: v1.11.0-beta.2.78+e0b33dbc2bde88
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.10.4 v1.11.0
Upgrade to the latest version in the v1.10 series:
COMPONENT CURRENT AVAILABLE
API Server v1.10.4 v1.11.0
Controller Manager v1.10.4 v1.11.0
Scheduler v1.10.4 v1.11.0
Kube Proxy v1.10.4 v1.11.0
CoreDNS 1.1.3
Kube DNS 1.14.8
Etcd 3.1.12 3.2.18
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.11.0
Note: Before you can perform this upgrade, you have to update kubeadm to v1.11.0.
_____________________________________________________________________
```
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
1. Choose a version to upgrade to, and run the appropriate command. For example:
```shell
kubeadm upgrade apply v1.11.0
```
If you currently use `kube-dns` and wish to continue doing so, add `--feature-gates=CoreDNS=false`.
You should see output similar to this:
<!-- TODO: output from stable -->
```shell
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
I0614 20:56:08.320369 30918 feature_gate.go:230] feature gates: &{map[]}
[upgrade/apply] Respecting the --cri-socket flag that is set with higher priority than the config file.
[upgrade/version] You have chosen to change the cluster version to "v1.11.0-beta.2.78+e0b33dbc2bde88"
[upgrade/versions] Cluster version: v1.10.4
[upgrade/versions] kubeadm version: v1.11.0-beta.2.78+e0b33dbc2bde88
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.11.0-beta.2.78+e0b33dbc2bde88"...
Static pod: kube-apiserver-ip-172-31-85-18 hash: 7a329408b21bc0c44d7b3b78ff8187bf
Static pod: kube-controller-manager-ip-172-31-85-18 hash: 24fd3157627c7567b687968967c6a5e8
Static pod: kube-scheduler-ip-172-31-85-18 hash: 5179266fb24d4c1834814c4f69486371
Static pod: etcd-ip-172-31-85-18 hash: 9dfc197f444be11fcc70ab1467b030b8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests089436939/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-06-14-20-56-11/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: etcd-ip-172-31-85-18 hash: 9dfc197f444be11fcc70ab1467b030b8
< snip >
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 0s for initial delay
[util/etcd] Attempting to see if all cluster endpoints are available 1/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests089436939"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests089436939/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests089436939/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests089436939/kube-scheduler.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-06-14-20-56-11/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-apiserver-ip-172-31-85-18 hash: 7a329408b21bc0c44d7b3b78ff8187bf
< snip >
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-06-14-20-56-11/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-controller-manager-ip-172-31-85-18 hash: 24fd3157627c7567b687968967c6a5e8
Static pod: kube-controller-manager-ip-172-31-85-18 hash: 63992ff14733dcb9dcfa6ac0a3b8031a
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2018-06-14-20-56-11/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-scheduler-ip-172-31-85-18 hash: 5179266fb24d4c1834814c4f69486371
Static pod: kube-scheduler-ip-172-31-85-18 hash: 831e4b9425f758e572392976311e56d9
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.11" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.11" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "ip-172-31-85-18" as an annotation
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.11.0-beta.2.78+e0b33dbc2bde88". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
1. Manually upgrade your Software Defined Network (SDN).
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
find your CNI provider and see whether additional upgrade steps are required.
## Upgrade master and node packages
1. Prepare each host for maintenance, marking it unschedulable and evicting the workload:
```shell
kubectl drain $HOST --ignore-daemonsets
```
On the master host, you must add `--ignore-daemonsets`:
```shell
kubectl drain ip-172-31-85-18
node "ip-172-31-85-18" cordoned
error: unable to drain node "ip-172-31-85-18", aborting command...
There are pending nodes to be drained:
ip-172-31-85-18
error: DaemonSet-managed pods (use --ignore-daemonsets to ignore): calico-node-5798d, kube-proxy-thjp9
```
```
kubectl drain ip-172-31-85-18 --ignore-daemonsets
node "ip-172-31-85-18" already cordoned
WARNING: Ignoring DaemonSet-managed pods: calico-node-5798d, kube-proxy-thjp9
node "ip-172-31-85-18" drained
```
1. Upgrade the Kubernetes package version on each `$HOST` node by running the Linux package manager for your distribution:
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
apt-get update
apt-get upgrade -y kubelet kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
yum upgrade -y kubelet kubeadm --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
## Upgrade kubelet on each node
1. On each node except the master node, upgrade the kubelet config:
```shell
sudo kubeadm upgrade node config --kubelet-version $(kubelet --version | cut -d ' ' -f 2)
```
1. Restart the kubectl process:
```shell
sudo systemctl restart kubelet
```
1. Verify that the new version of the `kubelet` is running on the host:
```shell
systemctl status kubelet
```
1. Bring the host back online by marking it schedulable:
```shell
kubectl uncordon $HOST
```
1. After the kubelet is upgraded on all hosts, verify that all nodes are available again by running the following command from anywhere -- for example, from outside the cluster:
```shell
kubectl get nodes
```
The `STATUS` column should show `Ready` for all your hosts, and the version number should be updated.
{{% /capture %}}
## Recovering from a failure state
If `kubeadm upgrade` fails and does not roll back, for example because of an unexpected shutdown during execution,
you can run `kubeadm upgrade` again. This command is idempotent and eventually makes sure that the actual state is the desired state you declare.
To recover from a bad state, you can also run `kubeadm upgrade --force` without changing the version that your cluster is running.
## How it works
`kubeadm upgrade apply` does the following:
- Checks that your cluster is in an upgradeable state:
- The API server is reachable,
- All nodes are in the `Ready` state
- The control plane is healthy
- Enforces the version skew policies.
- Makes sure the control plane images are available or available to pull to the machine.
- Upgrades the control plane components or rollbacks if any of them fails to come up.
- Applies the new `kube-dns` and `kube-proxy` manifests and enforces that all necessary RBAC rules are created.
- Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days.
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14.md
+382
View File
@@ -0,0 +1,382 @@
---
reviewers:
- sig-cluster-lifecycle
title: Upgrading kubeadm clusters from v1.13 to v1.14
content_template: templates/task
---
{{% capture overview %}}
This page explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.13.x to version 1.14.x,
and from version 1.14.x to 1.14.y (where `y > x`).
The upgrade workflow at high level is the following:
1. Upgrade the primary control plane node.
1. Upgrade additional control plane nodes.
1. Upgrade worker nodes.
{{< note >}}
With the release of Kubernetes v1.14, the kubeadm instructions for upgrading both HA and single control plane clusters
are merged into a single document.
{{</ note >}}
{{% /capture %}}
{{% capture prerequisites %}}
- You need to have a kubeadm Kubernetes cluster running version 1.13.0 or later.
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- The cluster should use a static control plane and etcd pods.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md) carefully.
- Make sure to back up any important components, such as app-level state stored in a database.
`kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
### Additional information
- All containers are restarted after upgrade, because the container spec hash value is changed.
- You only can upgrade from one MINOR version to the next MINOR version,
or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade.
For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.
{{% /capture %}}
{{% capture steps %}}
## Determine which version to upgrade to
1. Find the latest stable 1.14 version:
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
apt update
apt-cache policy kubeadm
# find the latest 1.14 version in the list
# it should look like 1.14.x-00, where x is the latest patch
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# find the latest 1.14 version in the list
# it should look like 1.14.x-0, where x is the latest patch
{{% /tab %}}
{{< /tabs >}}
## Upgrade the first control plane node
1. On your first control plane node, upgrade kubeadm:
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.14.x-00 with the latest patch version
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.14.x-00 && \
apt-mark hold kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.14.x-0 with the latest patch version
yum install -y kubeadm-1.14.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
1. Verify that the download works and has the expected version:
```shell
kubeadm version
```
1. On the control plane node, run:
```shell
sudo kubeadm upgrade plan
```
You should see output similar to this:
```shell
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.13.3
[upgrade/versions] kubeadm version: v1.14.0
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 2 x v1.13.3 v1.14.0
Upgrade to the latest version in the v1.13 series:
COMPONENT CURRENT AVAILABLE
API Server v1.13.3 v1.14.0
Controller Manager v1.13.3 v1.14.0
Scheduler v1.13.3 v1.14.0
Kube Proxy v1.13.3 v1.14.0
CoreDNS 1.2.6 1.3.1
Etcd 3.2.24 3.3.10
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.14.0
_____________________________________________________________________
```
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
1. Choose a version to upgrade to, and run the appropriate command. For example:
```shell
sudo kubeadm upgrade apply v1.14.x
```
- Replace `x` with the patch version you picked for this ugprade.
You should see output similar to this:
```shell
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.14.0"
[upgrade/versions] Cluster version: v1.13.3
[upgrade/versions] kubeadm version: v1.14.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/prepull] Prepulling image for component etcd.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[upgrade/prepull] Prepulling image for component kube-controller-manager.
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Successfully prepulled the images for all the control plane components
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.14.0"...
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-controller-manager-myhost hash: 8ee730c1a5607a87f35abb2183bf03f2
Static pod: kube-scheduler-myhost hash: 4b52d75cab61380f07c0c5a69fb371d4
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239
Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239
Static pod: etcd-myhost hash: 64a28f011070816f4beb07a9c96d73b6
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests043818770"
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-apiserver-myhost hash: b8a6533e241a8c6dab84d32bb708b8a1
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-myhost hash: 8ee730c1a5607a87f35abb2183bf03f2
Static pod: kube-controller-manager-myhost hash: 6f77d441d2488efd9fc2d9a9987ad30b
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-myhost hash: 4b52d75cab61380f07c0c5a69fb371d4
Static pod: kube-scheduler-myhost hash: a24773c92bb69c3748fcce5e540b7574
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.14" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.14.0". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
1. Manually upgrade your CNI provider plugin.
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
find your CNI provider and see whether additional upgrade steps are required.
1. Upgrade the kubelet and kubectl on the control plane node:
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.14.x-00 with the latest patch version
apt-mark unhold kubelet && \
apt-get update && apt-get install -y kubelet=1.14.x-00 kubectl=1.14.x-00 && \
apt-mark hold kubelet
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.14.x-0 with the latest patch version
yum install -y kubelet-1.14.x-0 kubectl-1.14.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
1. Restart the kubelet
```shell
sudo systemctl restart kubelet
```
## Upgrade additional control plane nodes
1. Same as the first control plane node but use:
```
sudo kubeadm upgrade node experimental-control-plane
```
instead of:
```
sudo kubeadm upgrade apply
```
Also `sudo kubeadm upgrade plan` is not needed.
## Ugrade worker nodes
The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time,
without compromising the minimum required capacity for running your workloads.
### Upgrade kubeadm
1. Upgrade kubeadm on all worker nodes:
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.14.x-00 with the latest patch version
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.14.x-00 && \
apt-mark hold kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.14.x-0 with the latest patch version
yum install -y kubeadm-1.14.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
### Cordon the node
1. Prepare the node for maintenance by marking it unschedulable and evicting the workloads. Run:
```shell
kubectl drain $NODE --ignore-daemonsets
```
You should see output similar to this:
```shell
kubectl drain ip-172-31-85-18
node "ip-172-31-85-18" cordoned
error: unable to drain node "ip-172-31-85-18", aborting command...
There are pending nodes to be drained:
ip-172-31-85-18
error: DaemonSet-managed pods (use --ignore-daemonsets to ignore): calico-node-5798d, kube-proxy-thjp9
```
### Upgrade the kubelet config
1. Upgrade the kubelet config:
```shell
sudo kubeadm upgrade node config --kubelet-version v1.14.x
```
Replace `x` with the patch version you picked for this ugprade.
### Upgrade kubelet and kubectl
1. Upgrade the Kubernetes package version by running the Linux package manager for your distribution:
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.14.x-00 with the latest patch version
apt-get update
apt-get install -y kubelet=1.14.x-00 kubectl=1.14.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.14.x-0 with the latest patch version
yum install -y kubelet-1.14.x-0 kubectl-1.14.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
1. Restart the kubelet
```shell
sudo systemctl restart kubelet
```
### Uncordon the node
1. Bring the node back online by marking it schedulable:
```shell
kubectl uncordon $NODE
```
## Verify the status of the cluster
After the kubelet is upgraded on all nodes verify that all nodes are available again by running the following command from anywhere kubectl can access the cluster:
```shell
kubectl get nodes
```
The `STATUS` column should show `Ready` for all your nodes, and the version number should be updated.
{{% /capture %}}
## Recovering from a failure state
If `kubeadm upgrade` fails and does not roll back, for example because of an unexpected shutdown during execution, you can run `kubeadm upgrade` again.
This command is idempotent and eventually makes sure that the actual state is the desired state you declare.
To recover from a bad state, you can also run `kubeadm upgrade --force` without changing the version that your cluster is running.
## How it works
`kubeadm upgrade apply` does the following:
- Checks that your cluster is in an upgradeable state:
- The API server is reachable
- All nodes are in the `Ready` state
- The control plane is healthy
- Enforces the version skew policies.
- Makes sure the control plane images are available or available to pull to the machine.
- Upgrades the control plane components or rollbacks if any of them fails to come up.
- Applies the new `kube-dns` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created.
- Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days.
`kubeadm upgrade node experimental-control-plane` does the following on additional control plane nodes:
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
- Optionally backups the kube-apiserver certificate.
- Upgrades the static Pod manifests for the control plane components.
content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
+5 -5
View File
@@ -45,7 +45,7 @@ Here's the configuration file for a LimitRange:
Create the LimitRange:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example
```
View detailed information about the LimitRange:
@@ -96,7 +96,7 @@ minimum and maximum CPU constraints imposed by the LimitRange.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
```
Verify that the Pod's Container is running:
@@ -138,7 +138,7 @@ CPU request of 500 millicpu and a cpu limit of 1.5 cpu.
Attempt to create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
```
The output shows that the Pod does not get created, because the Container specifies a CPU limit that is
@@ -159,7 +159,7 @@ CPU request of 100 millicpu and a CPU limit of 800 millicpu.
Attempt to create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
```
The output shows that the Pod does not get created, because the Container specifies a CPU
@@ -180,7 +180,7 @@ specify a CPU request, and it does not specify a CPU limit.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example
```
View detailed information about the Pod:
content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
+4 -4
View File
@@ -40,7 +40,7 @@ a default CPU request and a default CPU limit.
Create the LimitRange in the default-cpu-example namespace:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
```
Now if a Container is created in the default-cpu-example namespace, and the
@@ -56,7 +56,7 @@ does not specify a CPU request and limit.
Create the Pod.
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example
```
View the Pod's specification:
@@ -91,7 +91,7 @@ Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
```
View the Pod specification:
@@ -121,7 +121,7 @@ specifies a CPU request, but not a limit:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
```
View the Pod specification:
content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
+5 -5
View File
@@ -45,7 +45,7 @@ Here's the configuration file for a LimitRange:
Create the LimitRange:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
```
View detailed information about the LimitRange:
@@ -90,7 +90,7 @@ minimum and maximum memory constraints imposed by the LimitRange.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
```
Verify that the Pod's Container is running:
@@ -132,7 +132,7 @@ memory request of 800 MiB and a memory limit of 1.5 GiB.
Attempt to create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
```
The output shows that the Pod does not get created, because the Container specifies a memory limit that is
@@ -153,7 +153,7 @@ memory request of 100 MiB and a memory limit of 800 MiB.
Attempt to create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
```
The output shows that the Pod does not get created, because the Container specifies a memory
@@ -176,7 +176,7 @@ specify a memory request, and it does not specify a memory limit.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
```
View detailed information about the Pod:
content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
+4 -4
View File
@@ -42,7 +42,7 @@ a default memory request and a default memory limit.
Create the LimitRange in the default-mem-example namespace:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
```
Now if a Container is created in the default-mem-example namespace, and the
@@ -58,7 +58,7 @@ does not specify a memory request and limit.
Create the Pod.
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example
```
View detailed information about the Pod:
@@ -99,7 +99,7 @@ Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example
```
View detailed information about the Pod:
@@ -129,7 +129,7 @@ specifies a memory request, but not a limit:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example
```
View the Pod's specification:
content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
+3 -3
View File
@@ -44,7 +44,7 @@ Here is the configuration file for a ResourceQuota object:
Create the ResourceQuota:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example
```
View detailed information about the ResourceQuota:
@@ -71,7 +71,7 @@ Here is the configuration file for a Pod:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
```
Verify that the Pod's Container is running:
@@ -117,7 +117,7 @@ request exceeds the memory request quota. 600 MiB + 700 MiB > 1 GiB.
Attempt to create the Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
```
The second Pod does not get created. The output shows that creating the second Pod
content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
+2 -2
View File
@@ -42,7 +42,7 @@ Here is the configuration file for a ResourceQuota object:
Create the ResourceQuota:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-pod.yaml --namespace=quota-pod-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod.yaml --namespace=quota-pod-example
```
View detailed information about the ResourceQuota:
@@ -74,7 +74,7 @@ In the configuration file, `replicas: 3` tells Kubernetes to attempt to create t
Create the Deployment:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yaml --namespace=quota-pod-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yaml --namespace=quota-pod-example
```
View detailed information about the Deployment:
content/en/docs/tasks/administer-cluster/quota-api-object.md
+3 -3
View File
@@ -43,7 +43,7 @@ Here is the configuration file for a ResourceQuota object:
Create the ResourceQuota:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-objects.yaml --namespace=quota-object-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects.yaml --namespace=quota-object-example
```
View detailed information about the ResourceQuota:
@@ -77,7 +77,7 @@ Here is the configuration file for a PersistentVolumeClaim object:
Create the PersistentVolumeClaim:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-objects-pvc.yaml --namespace=quota-object-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects-pvc.yaml --namespace=quota-object-example
```
Verify that the PersistentVolumeClaim was created:
@@ -102,7 +102,7 @@ Here is the configuration file for a second PersistentVolumeClaim:
Attempt to create the second PersistentVolumeClaim:
```shell
kubectl create -f https://k8s.io/examples/admin/resource/quota-objects-pvc-2.yaml --namespace=quota-object-example
kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects-pvc-2.yaml --namespace=quota-object-example
```
The output shows that the second PersistentVolumeClaim was not created,
content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+12 -3
View File
@@ -88,7 +88,7 @@ be configured to use the `systemd` cgroup driver.
### Kube Reserved
- **Kubelet Flag**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi]`
- **Kubelet Flag**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
- **Kubelet Flag**: `--kube-reserved-cgroup=`
`kube-reserved` is meant to capture resource reservation for kubernetes system
@@ -102,6 +102,10 @@ post](https://kubernetes.io/blog/2016/11/visualize-kubelet-performance-with-node
explains how the dashboard can be interpreted to come up with a suitable
`kube-reserved` reservation.
In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
specified to reserve the specified number of process IDs for
kubernetes system daemons.
To optionally enforce `kube-reserved` on system daemons, specify the parent
control group for kube daemons as the value for `--kube-reserved-cgroup` kubelet
flag.
@@ -118,7 +122,7 @@ exist. Kubelet will fail if an invalid cgroup is specified.
### System Reserved
- **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi]`
- **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
- **Kubelet Flag**: `--system-reserved-cgroup=`
@@ -128,6 +132,10 @@ like `sshd`, `udev`, etc. `system-reserved` should reserve `memory` for the
Reserving resources for user login sessions is also recommended (`user.slice` in
systemd world).
In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
specified to reserve the specified number of process IDs for OS system
daemons.
To optionally enforce `system-reserved` on system daemons, specify the parent
control group for OS system daemons as the value for `--system-reserved-cgroup`
kubelet flag.
@@ -182,7 +190,8 @@ container runtime. However, Kubelet cannot burst and use up all available Node
resources if `kube-reserved` is enforced.
Be extra careful while enforcing `system-reserved` reservation since it can lead
to critical system services being CPU starved or OOM killed on the node. The
to critical system services being CPU starved, OOM killed, or unable
to fork on the node. The
recommendation is to enforce `system-reserved` only if a user has profiled their
nodes exhaustively to come up with precise estimates and is confident in their
ability to recover if any process in that group is oom_killed.
content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
+2 -2
View File
@@ -77,7 +77,7 @@ The `-cpus "2"` argument tells the Container to attempt to use 2 CPUs.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
```
Verify that the Pod Container is running:
@@ -168,7 +168,7 @@ capacity of any Node in your cluster.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
```
View the Pod status:
content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
+3 -3
View File
@@ -76,7 +76,7 @@ The `"--vm-bytes", "150M"` arguments tell the Container to attempt to allocate 1
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
```
Verify that the Pod Container is running:
@@ -146,7 +146,7 @@ will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limi
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
```
View detailed information about the Pod:
@@ -252,7 +252,7 @@ of any Node in your cluster.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
```
View the Pod status:
content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
+1 -1
View File
@@ -71,7 +71,7 @@ a `disktype=ssd` label.
chosen node:
```shell
kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml
kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml
```
1. Verify that the pod is running on your chosen node:
content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+1 -1
View File
@@ -38,7 +38,7 @@ nginx gracefully. This is helpful if the Container is being terminated because o
Create the Pod:
kubectl create -f https://k8s.io/examples/pods/lifecycle-events.yaml
kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml
Verify that the Container in the Pod is running:
content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+204
View File
@@ -0,0 +1,204 @@
---
title: Configure GMSA for Windows pods and containers
content_template: templates/task
weight: 20
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers.
In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as custom resources. Windows pods, as well as individual containers within a pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.14, the only container runtime interface that supports GMSA for Windows workloads is Dockershim. Implementation of GMSA through CRI and other runtimes is planned for the future.
{{< note >}}
Currently this feature is in alpha state. While the overall goals and functionality will not change, the way in which the GMSA credspec references are specified in pod specs may change from annotations to API fields. Please take this into consideration when testing or adopting this feature.
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads requiring GMSA credentials will get scheduled. This section covers a set of initial steps required once for each cluster:
### Enable the WindowsGMSA feature gate
In the alpha state, the `WindowsGMSA` feature gate needs to be enabled on kubelet on Windows nodes. This is required to pass down the GMSA credential specs from the cluster scoped configurations to the container runtime. See [Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. Please make sure `--feature-gates=WindowsGMSA=true` parameter exists in the kubelet.exe command line.
### Install the GMSACredentialSpec CRD
A [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) (CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
### Install webhooks to validate GMSA users
Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the pod or container level:
1. A mutating webhook that expands references to GMSAs (by name from a pod specification) into the full credential spec in JSON form within the pod spec.
1. A validating webhook ensures all references to GMSAs are authorized to be used by the pod service account.
Installing the above webhooks and associated objects require the steps below:
1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster)
1. Install a secret with the certificate from above.
1. Create a deployment for the core webhook logic.
1. Create the validating and mutating webhook configurations referring to the deployment.
A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a ```--dry-run``` option to allow you to review the changes that would be made to your cluster.
The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters)
{{% /capture %}}
{{% capture steps %}}
## Configure GMSAs and Windows nodes in Active Directory
Before pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)
## Create GMSA credential spec resources
With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1).
Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it:
1. Import the CredentialSpec [module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1`
1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`
1. Use `Get-CredentialSpec` to show the path of the JSON file.
1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes.
The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`:
```
apiVersion: windows.k8s.io/v1alpha1
kind: GMSACredentialSpec
metadata:
name: gmsa-WebApp1 #This is an arbitrary name but it will be used as a reference
credspec:
ActiveDirectoryConfig:
GroupManagedServiceAccounts:
- Name: WebApp1 #Username of the GMSA account
Scope: CONTOSO #NETBIOS Domain Name
- Name: WebApp1 #Username of the GMSA account
Scope: contoso.com #DNS Domain Name
CmsPlugins:
- ActiveDirectory
DomainJoinConfig:
DnsName: contoso.com #DNS Domain Name
DnsTreeName: contoso.com #DNS Domain Name Root
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a #GUID
MachineAccountName: WebApp1 #Username of the GMSA account
NetBiosName: CONTOSO #NETBIOS Domain Name
Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA
```
The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml`
## Configure cluster role to enable RBAC on specific GMSA credential specs
A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml`
```
#Create the Role to read the credspec
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: webapp1-role
rules:
- apiGroups: ["windows.k8s.io"]
resources: ["gmsacredentialspecs"]
verbs: ["use"]
resourceNames: ["gmsa-WebApp1"]
```
## Assign role to service accounts to use specific GMSA credspecs
A service account (that pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to "use" the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above.
```
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: allow-default-svc-account-read-on-gmsa-WebApp1
namespace: default
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: webapp1-role
apiGroup: rbac.authorization.k8s.io
```
## Configure GMSA credential spec reference in pod spec
In the alpha stage of the feature, the annotation `pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name` is used to specify references to desired GMSA credential spec custom resources in pod specs. This configures all containers in the pod spec to use the specified GMSA. A sample pod spec with the annotation populated to refer to `gmsa-WebApp1`:
```
apiVersion: apps/v1beta1
kind: Deployment
metadata:
labels:
run: with-creds
name: with-creds
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: with-creds
template:
metadata:
labels:
run: with-creds
annotations:
pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name: gmsa-WebApp1 # This must be the name of the cred spec you created
spec:
containers:
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
imagePullPolicy: Always
name: iis
nodeSelector:
beta.kubernetes.io/os: windows
```
Individual containers in a pod spec can also specify the desired GMSA credspec using annotation `<containerName>.container.alpha.windows.kubernetes.io/gmsa-credential-spec`. For example:
```
apiVersion: apps/v1beta1
kind: Deployment
metadata:
labels:
run: with-creds
name: with-creds
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: with-creds
template:
metadata:
labels:
run: with-creds
annotations:
iis.container.alpha.windows.kubernetes.io/gmsa-credential-spec-name: gmsa-WebApp1 # This must be the name of the cred spec you created
spec:
containers:
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
imagePullPolicy: Always
name: iis
nodeSelector:
beta.kubernetes.io/os: windows
```
As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events take place:
1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec.
1. The validating webhook ensures the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec.
1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity.
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
+3 -3
View File
@@ -62,7 +62,7 @@ code. After 30 seconds, `cat /tmp/healthy` returns a failure code.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
```
Within 30 seconds, view the Pod events:
@@ -163,7 +163,7 @@ checks will fail, and the kubelet will kill and restart the Container.
To try the HTTP liveness check, create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/probe/http-liveness.yaml
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
```
After 10 seconds, view Pod events to verify that liveness probes have failed and
@@ -204,7 +204,7 @@ will be restarted.
To try the TCP liveness check, create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
```
After 15 seconds, view Pod events to verify that liveness probes:
content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+3 -3
View File
@@ -73,7 +73,7 @@ PersistentVolumeClaim requests to this PersistentVolume.
Create the PersistentVolume:
kubectl create -f https://k8s.io/examples/pods/storage/pv-volume.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
View information about the PersistentVolume:
@@ -98,7 +98,7 @@ Here is the configuration file for the PersistentVolumeClaim:
Create the PersistentVolumeClaim:
kubectl create -f https://k8s.io/examples/pods/storage/pv-claim.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml
After you create the PersistentVolumeClaim, the Kubernetes control plane looks
for a PersistentVolume that satisfies the claim's requirements. If the control
@@ -138,7 +138,7 @@ is a volume.
Create the Pod:
kubectl create -f https://k8s.io/examples/pods/storage/pv-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
Verify that the Container in the Pod is running;
content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
+102 -4
View File
@@ -21,7 +21,10 @@ ConfigMaps allow you to decouple configuration artifacts from image content to k
{{% capture steps %}}
## Create a ConfigMap
## Create a ConfigMap
You can use either `kubectl create configmap` or a ConfigMap generator in `kustomization.yaml` to create a ConfigMap. Note that `kubectl` starts to support `kustomization.yaml` since 1.14.
### Create a ConfigMap Using kubectl create configmap
Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):
@@ -40,7 +43,7 @@ You can use [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-comma
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to retrieve information
about a ConfigMap.
### Create ConfigMaps from directories
#### Create ConfigMaps from directories
You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory.
@@ -117,7 +120,7 @@ metadata:
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from files
#### Create ConfigMaps from files
You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files.
@@ -300,7 +303,7 @@ metadata:
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from literal values
#### Create ConfigMaps from literal values
You can use `kubectl create configmap` with the `--from-literal` argument to define a literal value from the command line:
@@ -330,6 +333,101 @@ metadata:
uid: dadce046-d673-11e5-8cd0-68f728db1985
```
### Create a ConfigMap from generator
`kubectl` supports `kustomization.yaml` since 1.14.
You can also create a ConfigMap from generators and then apply it to create the object on
the Apiserver. The generators
should be specified in a `kustomization.yaml` inside a directory.
#### Generate ConfigMaps from files
For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
files:
- configure-pod-container/configmap/kubectl/game.properties
EOF
```
Apply the kustomization directory to create the ConfigMap object.
```shell
kubectl apply -k .
configmap/game-config-4-m9dm2f92bt created
```
You can check that the ConfigMap was created like this:
```shell
kubectl get configmap
NAME DATA AGE
game-config-4-m9dm2f92bt 1 37s
kubectl describe configmaps/game-config-4-m9dm2f92bt
Name: game-config-4-m9dm2f92bt
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events: <none>
```
Note that the generated ConfigMap name has a suffix appended by hashing the contents. This ensures that a
new ConfigMap is generated each time the content is modified.
#### Define the key to use when generating a ConfigMap from a file
You can define a key other than the file name to use in the ConfigMap generator.
For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
with the key `game-special-key`
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
files:
- game-special-key=configure-pod-container/configmap/kubectl/game.properties
EOF
```
Apply the kustomization directory to create the ConfigMap object.
```shell
kubectl apply -k .
configmap/game-config-5-m67dt67794 created
```
#### Generate ConfigMaps from Literals
To generate a ConfigMap from literals `special.type=charm` and `special.how=very`,
you can specify the ConfigMap generator in `kusotmization.yaml` as
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: special-config-2
literals:
- special.how=very
- special.type=charm
EOF
```
Apply the kustomization directory to create the ConfigMap object.
```shell
kubectl apply -k .
configmap/special-config-2-c92b5mmcf2 created
```
## Define container environment variables using ConfigMap data
content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
+1 -1
View File
@@ -43,7 +43,7 @@ of the nginx server.
Create the Pod:
kubectl create -f https://k8s.io/examples/pods/init-containers.yaml
kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml
Verify that the nginx container is running:
content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+1 -1
View File
@@ -42,7 +42,7 @@ Here is the configuration file for the Pod:
```
1. Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
```
1. Verify that the Pod's Container is running, and then watch for changes to
the Pod:
content/en/docs/tasks/configure-pod-container/configure-service-account.md
+2 -2
View File
@@ -90,7 +90,7 @@ default 1 1d
You can create additional ServiceAccount objects like this:
```shell
kubectl create -f - <<EOF
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
@@ -142,7 +142,7 @@ Suppose we have an existing service account named "build-robot" as mentioned abo
a new secret manually.
```shell
kubectl create -f - <<EOF
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
+1 -1
View File
@@ -37,7 +37,7 @@ restarts. Here is the configuration file for the Pod:
1. Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/storage/redis.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
```
1. Verify that the Pod's Container is running, and then watch for changes to
content/en/docs/tasks/configure-pod-container/extended-resource.md
+2 -2
View File
@@ -43,7 +43,7 @@ In the configuration file, you can see that the Container requests 3 dongles.
Create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml
```
Verify that the Pod is running:
@@ -80,7 +80,7 @@ used three of the four available dongles.
Attempt to create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml
```
Describe the Pod
content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
+1 -1
View File
@@ -196,7 +196,7 @@ The `imagePullSecrets` field in the configuration file specifies that Kubernetes
Create a Pod that uses your Secret, and verify that the Pod is running:
```shell
kubectl create -f my-private-reg-pod.yaml
kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg
```
content/en/docs/tasks/configure-pod-container/quality-service-pod.md
+4 -4
View File
@@ -55,7 +55,7 @@ memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU r
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
```
View detailed information about the Pod:
@@ -111,7 +111,7 @@ and a memory request of 100 MiB.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
```
View detailed information about the Pod:
@@ -156,7 +156,7 @@ limits or requests:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
```
View detailed information about the Pod:
@@ -195,7 +195,7 @@ criteria for QoS class Guaranteed, and one of its Containers has a memory reques
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
```
View detailed information about the Pod:
content/en/docs/tasks/configure-pod-container/security-context.md
+19 -10
View File
@@ -52,15 +52,16 @@ Here is a configuration file for a Pod that has a `securityContext` and an `empt
{{< codenew file="pods/security/security-context.yaml" >}}
In the configuration file, the `runAsUser` field specifies that for any Containers in
the Pod, the first process runs with user ID 1000. The `fsGroup` field specifies that
group ID 2000 is associated with all Containers in the Pod. Group ID 2000 is also
associated with the volume mounted at `/data/demo` and with any files created in that
volume.
the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for
all processes within any containers of the Pod. If this field is ommitted, the primary group ID of the containers
will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified.
Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000.
The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml
```
Verify that the Pod's Container is running:
@@ -123,6 +124,16 @@ The output shows that `testfile` has group ID 2000, which is the value of `fsGro
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
```
Run the following command:
```shell
$ id
uid=1000 gid=3000 groups=2000
```
You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was ommitted the gid would
remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
the required group permissions for root(0) group.
Exit your shell:
```shell
@@ -146,7 +157,7 @@ and the Container have a `securityContext` field:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context-2.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml
```
Verify that the Pod's Container is running:
@@ -199,7 +210,7 @@ Here is configuration file that does not add or remove any Container capabilitie
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context-3.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml
```
Verify that the Pod's Container is running:
@@ -261,7 +272,7 @@ adds the `CAP_NET_ADMIN` and `CAP_SYS_TIME` capabilities:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context-4.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml
```
Get a shell into the running Container:
@@ -357,5 +368,3 @@ After you specify an MCS label for a Pod, all Pods with the same label can acces
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/share-process-namespace.md
+1 -1
View File
@@ -43,7 +43,7 @@ Process Namespace Sharing is enabled using the `ShareProcessNamespace` field of
1. Create the pod `nginx` on your cluster:
kubectl create -f https://k8s.io/examples/pods/share-process-namespace.yaml
kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
1. Attach to the `shell` container and run `ps`:
content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+6 -6
View File
@@ -124,7 +124,7 @@ you need is an existing `docker-compose.yml` file.
```bash
$ kompose up
We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Successfully created Service: redis
INFO Successfully created Service: web
@@ -135,7 +135,7 @@ you need is an existing `docker-compose.yml` file.
```
3. To convert the `docker-compose.yml` file to files that you can use with
`kubectl`, run `kompose convert` and then `kubectl create -f <output file>`.
`kubectl`, run `kompose convert` and then `kubectl apply -f <output file>`.
```bash
$ kompose convert
@@ -148,7 +148,7 @@ you need is an existing `docker-compose.yml` file.
```
```bash
$ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
$ kubectl apply -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
service/frontend created
service/redis-master created
service/redis-slave created
@@ -309,7 +309,7 @@ Kompose supports a straightforward way to deploy your "composed" application to
```sh
$ kompose --file ./examples/docker-guestbook.yml up
We are going to create Kubernetes deployments and services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Successfully created service: redis-master
INFO Successfully created service: redis-slave
@@ -341,7 +341,7 @@ pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
**Note**:
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the `kompose convert` and `kubectl create -f` commands instead.
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the `kompose convert` and `kubectl apply -f` commands instead.
### OpenShift
```sh
@@ -426,7 +426,7 @@ INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
INFO Pushing image 'foo/bar:latest' to registry 'docker.io'
INFO Attempting authentication credentials 'https://index.docker.io/v1/
INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io'
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Deploying application in "default" namespace
INFO Successfully created Service: foo
content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md
+3 -3
View File
@@ -26,7 +26,7 @@ For this example we'll use a Deployment to create two pods, similar to the earli
Create deployment by running following command:
```shell
kubectl create -f https://k8s.io/examples/application/nginx-with-request.yaml
kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml
```
```none
@@ -293,8 +293,8 @@ kubectl describe node kubernetes-node-861h
```none
Name: kubernetes-node-861h
Role
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
Labels: kubernetes.io/arch=amd64
kubernetes.io/os=linux
kubernetes.io/hostname=kubernetes-node-861h
Annotations: node.alpha.kubernetes.io/ttl=0
volumes.kubernetes.io/controller-managed-attach-detach=true
content/en/docs/tasks/debug-application-cluster/debug-application.md
+1 -1
View File
@@ -107,7 +107,7 @@ For example, if you misspelled `command` as `commnd` then the pod will be create
will not use the command line you intended it to use.
The first thing to do is to delete your pod and try creating it again with the `--validate` option.
For example, run `kubectl create --validate -f mypod.yaml`.
For example, run `kubectl apply --validate -f mypod.yaml`.
If you misspelled `command` as `commnd` then will give an error like this:
```shell
content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+1 -1
View File
@@ -38,7 +38,7 @@ the container starts.
1. Create a Pod based on the YAML configuration file:
kubectl create -f https://k8s.io/examples/debug/termination.yaml
kubectl apply -f https://k8s.io/examples/debug/termination.yaml
In the YAML file, in the `cmd` and `args` fields, you can see that the
container sleeps for 10 seconds and then writes "Sleep expired" to
content/en/docs/tasks/debug-application-cluster/events-stackdriver.md
+1 -1
View File
@@ -59,7 +59,7 @@ average, approximately 100Mb RAM and 100m CPU is needed.
Deploy event exporter to your cluster using the following command:
```shell
kubectl create -f https://k8s.io/examples/debug/event-exporter.yaml
kubectl apply -f https://k8s.io/examples/debug/event-exporter.yaml
```
Since event exporter accesses the Kubernetes API, it requires permissions to
content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md
+1 -1
View File
@@ -33,7 +33,7 @@ runs the nginx image. Here is the configuration file for the Pod:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/application/shell-demo.yaml
kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml
```
Verify that the Container is running:
content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
+3 -3
View File
@@ -97,7 +97,7 @@ than Google Kubernetes Engine. Proceed at your own risk.
1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
```
kubectl create -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
```
The command creates the `ConfigMap` in the `default` namespace. You can download the file
@@ -106,7 +106,7 @@ than Google Kubernetes Engine. Proceed at your own risk.
1. Deploy the logging agent `DaemonSet` by running the following command:
```
kubectl create -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
```
You can download and edit this file before using it as well.
@@ -139,7 +139,7 @@ that writes out the value of a counter and the datetime once per
second, and runs indefinitely. Let's create this pod in the default namespace.
```shell
kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
```
You can observe the running pod:
content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
+2 -2
View File
@@ -73,7 +73,7 @@ OS distro.***
* **Step 2:** Start node problem detector with `kubectl`:
```shell
kubectl create -f https://k8s.io/examples/debug/node-problem-detector.yaml
kubectl apply -f https://k8s.io/examples/debug/node-problem-detector.yaml
```
### Addon Pod
@@ -105,7 +105,7 @@ node-problem-detector-config --from-file=config/`.
```shell
kubectl delete -f https://k8s.io/examples/debug/node-problem-detector.yaml # If you have a node-problem-detector running
kubectl create -f https://k8s.io/examples/debug/node-problem-detector-configmap.yaml
kubectl apply -f https://k8s.io/examples/debug/node-problem-detector-configmap.yaml
```
***Notice that this approach only applies to node problem detector started with `kubectl`.***
content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md → content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+1 -1
View File
@@ -2,7 +2,7 @@
reviewers:
- fgrzadkowski
- piosz
title: Core metrics pipeline
title: Resource metrics pipeline
content_template: templates/concept
---
content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+1 -1
View File
@@ -46,7 +46,7 @@ monitoring statistics by default:
### Kubelet
The Kubelet acts as a bridge between the Kubernetes master and the nodes. It manages the pods and containers running on a machine. Kubelet translates each pod into its constituent containers and fetches individual container usage statistics from cAdvisor. It then exposes the aggregated pod resource usage statistics via a REST API.
The Kubelet acts as a bridge between the Kubernetes master and the nodes. It manages the pods and containers running on a machine. Kubelet translates each pod into its constituent containers and fetches individual container usage statistics from the container runtime, through the container runtime interface. For the legacy docker integration, it fetches this information from cAdvisor. It then exposes the aggregated pod resource usage statistics through the kubelet resource metrics api. This api is served at `/metrics/resource/v1alpha1` on the kubelet's authenticated and read-only ports.
### cAdvisor
content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+1 -3
View File
@@ -9,7 +9,7 @@ content_template: templates/task
{{% capture overview %}}
{{< feature-state state="beta" >}}
{{< feature-state state="stable" >}}
This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think
of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
@@ -24,8 +24,6 @@ You need to have a working `kubectl` binary installed.
Plugins were officially introduced as an alpha feature in the v1.8.0 release. They have been re-worked in the v1.12.0 release to support a wider range of use-cases. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.12.0 or later is recommended if you are following these docs.
{{< /note >}}
Until a GA version is released, plugins should be considered unstable, and their underlying mechanism is prone to change.
{{% /capture %}}
{{% capture steps %}}
content/en/docs/tasks/federation/set-up-placement-policies-federation.md
+3 -3
View File
@@ -33,7 +33,7 @@ After deploying the Federation control plane, you must configure an Admission
Controller in the Federation API server that enforces placement decisions
received from the external policy engine.
kubectl create -f scheduling-policy-admission.yaml
kubectl apply -f scheduling-policy-admission.yaml
Shown below is an example ConfigMap for the Admission Controller:
@@ -83,7 +83,7 @@ decisions in the Federation control plane.
Create a Service in the host cluster to contact the external policy engine:
kubectl create -f policy-engine-service.yaml
kubectl apply -f policy-engine-service.yaml
Shown below is an example Service for OPA.
@@ -91,7 +91,7 @@ Shown below is an example Service for OPA.
Create a Deployment in the host cluster with the Federation control plane:
kubectl create -f policy-engine-deployment.yaml
kubectl apply -f policy-engine-deployment.yaml
Shown below is an example Deployment for OPA.
content/en/docs/tasks/inject-data-application/define-command-argument-container.md
+1 -1
View File
@@ -47,7 +47,7 @@ file for the Pod defines a command and two arguments:
1. Create a Pod based on the YAML configuration file:
```shell
kubectl create -f https://k8s.io/examples/pods/commands.yaml
kubectl apply -f https://k8s.io/examples/pods/commands.yaml
```
1. List the running Pods:
content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
+1 -1
View File
@@ -37,7 +37,7 @@ Pod:
1. Create a Pod based on the YAML configuration file:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/envars.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
```
1. List the running Pods:
content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
+3 -3
View File
@@ -42,7 +42,7 @@ username and password:
1. Create the Secret
```shell
kubectl create -f https://k8s.io/examples/pods/inject/secret.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
```
1. View information about the Secret:
@@ -98,7 +98,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/secret-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
```
1. Verify that your Pod is running:
@@ -153,7 +153,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/secret-envars-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/secret-envars-pod.yaml
```
1. Verify that your Pod is running:
content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+2 -2
View File
@@ -56,7 +56,7 @@ fields of the Container in the Pod.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
```
Verify that Container in the Pod is running:
@@ -172,7 +172,7 @@ default value of `1` which means cores for cpu and bytes for memory.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
```
Get a shell into the Container that is running in your Pod:
content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
+2 -2
View File
@@ -55,7 +55,7 @@ Container in the Pod.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
```
Verify that the Container in the Pod is running:
@@ -130,7 +130,7 @@ from Container fields.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
```
Verify that the Container in the Pod is running:
content/en/docs/tasks/inject-data-application/podpreset.md
+1 -1
View File
@@ -36,7 +36,7 @@ Preset.
Create the PodPreset:
```shell
kubectl create -f https://k8s.io/examples/podpreset/preset.yaml
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
Examine the created PodPreset:
content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md
+1 -1
View File
@@ -245,7 +245,7 @@ done. So we set, `.spec.completions: 8` for the example, since we put 8 items i
So, now run the Job:
```shell
kubectl create -f ./job.yaml
kubectl apply -f ./job.yaml
```
Now wait a bit, then check on the job.
content/en/docs/tasks/job/fine-parallel-processing-work-queue.md
+1 -1
View File
@@ -182,7 +182,7 @@ too.
So, now run the Job:
```shell
kubectl create -f ./job.yaml
kubectl apply -f ./job.yaml
```
Now wait a bit, then check on the job.
content/en/docs/tasks/job/parallel-processing-expansion.md
+1 -1
View File
@@ -178,7 +178,7 @@ cat job.yaml.jinja2 | render_template > jobs.yaml
Or sent directly to kubectl, like this:
```shell
cat job.yaml.jinja2 | render_template | kubectl create -f -
cat job.yaml.jinja2 | render_template | kubectl apply -f -
```
## Alternatives
content/en/docs/tasks/manage-daemon/update-daemon-set.md
+2 -2
View File
@@ -56,7 +56,7 @@ If you haven't created the DaemonSet in the system, check your DaemonSet
manifest with the following command instead:
```shell
kubectl create -f ds.yaml --dry-run -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
kubectl apply -f ds.yaml --dry-run -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
```
The output from both commands should be:
@@ -76,7 +76,7 @@ step 3.
After verifying the update strategy of the DaemonSet manifest, create the DaemonSet:
```shell
kubectl create -f ds.yaml
kubectl apply -f ds.yaml
```
Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to
content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
+2 -2
View File
@@ -6,10 +6,10 @@ content_template: templates/task
---
{{% capture overview %}}
{{< feature-state state="beta" >}}
{{< feature-state state="stable" >}}
Kubernetes supports the allocation and consumption of pre-allocated huge pages
by applications in a Pod as a **beta** feature. This page describes how users
by applications in a Pod as a **GA** feature. This page describes how users
can consume huge pages and the current limitations.
{{% /capture %}}
content/en/docs/tasks/run-application/configure-pdb.md
+1 -1
View File
@@ -167,7 +167,7 @@ automatically responds to changes in the number of replicas of the corresponding
## Create the PDB object
You can create the PDB object with a command like `kubectl create -f mypdb.yaml`.
You can create the PDB object with a command like `kubectl apply -f mypdb.yaml`.
You cannot update PDB objects. They must be deleted and re-created.
content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+3 -3
View File
@@ -60,7 +60,7 @@ and a StatefulSet.
Create the ConfigMap from the following YAML configuration file:
```shell
kubectl create -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
```
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
@@ -80,7 +80,7 @@ based on information provided by the StatefulSet controller.
Create the Services from the following YAML configuration file:
```shell
kubectl create -f https://k8s.io/examples/application/mysql/mysql-services.yaml
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
```
{{< codenew file="application/mysql/mysql-services.yaml" >}}
@@ -106,7 +106,7 @@ writes.
Finally, create the StatefulSet from the following YAML configuration file:
```shell
kubectl create -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
```
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
content/en/docs/tasks/run-application/run-single-instance-stateful-application.md
+2 -2
View File
@@ -53,11 +53,11 @@ for a secure solution.
1. Deploy the PV and PVC of the YAML file:
kubectl create -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
1. Deploy the contents of the YAML file:
kubectl create -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
1. Display information about the Deployment:
content/en/docs/tasks/run-application/scale-stateful-set.md
+1 -1
View File
@@ -50,7 +50,7 @@ kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>
Alternatively, you can do [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) on your StatefulSets.
If your StatefulSet was initially created with `kubectl apply` or `kubectl create --save-config`,
If your StatefulSet was initially created with `kubectl apply`,
update `.spec.replicas` of the StatefulSet manifests, and then do a `kubectl apply`:
```shell
content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md
+1 -1
View File
@@ -31,7 +31,7 @@ is a Pod that has one container:
Create the Deployment:
```shell
kubectl create -f https://k8s.io/examples/application/deployment-patch.yaml
kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml
```
View the Pods associated with your Deployment:
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+1 -1
View File
@@ -104,7 +104,7 @@ Generate a CSR yaml blob and send it to the apiserver by running the following
command:
```shell
cat <<EOF | kubectl create -f -
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata: