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

Official 1.13 Release Docs (#11401)

Browse Source 
* Update metadata.generation behaviour for custom resources (#10705)

* update docs promoting plugins to beta (#10796)

* docs update to promote TaintBasedEvictions to beta (#10765)

* First Korean l10n work for dev-1.13 (#10719)

* Update outdated l10n(ko) contents (#10689)

fixes #10686

* Translate concepts/overview/what-is-kubernetes in Korean (#10690)

* Translate concepts/overview/what-is-kubernetes in Korean

* Feedback from ClaudiaJKang

* Translate concepts/overview/components in Korean (#10882)

* Translate concepts/overview/components in Korean #10717

* Translate concepts/overview/components in Korean

* Translate concepts/overview/components in Korean

* Apply Korean glossary: 서비스 어카운트

* Translate concepts/overview/kubernetes-api in Korean (#10773)

* Translate concepts/overview/kubernetes-api in Korean

* Applied feedback from ianychoi

* kubeadm: update the configuration docs to v1beta1 (#10959)

* kubeadm: add small v1beta1 related updates (#10988)

* ADD content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md (#11031)

* ADD content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md

* ADD content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md

* Update content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md

Accepted

Co-Authored-By: YouthLab <tsui@highyouth.com>

* do not change 'master' or 'worker' nodes to '主从'

* Doc updates for volume scheduling GA (#10743)

* Doc updates for volume scheduling GA

* Make trivial change to kick build

* Document nodelease feature (#10699)

* advanced audit doc for ModeBlockingStrict (#10203)

* Rename EncryptionConfig to EncryptionConfiguration (#11080)

EncryptionConfig was renamed to EncryptedConfiguration and added to
the `apiserver.config.k8s.io` API group in Kubernetes 1.13.

The feature was previously in alpha and was not handling versions
properly, which lead to an originally unnoticed `v1` in the docs.

* content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md

* trsanlate create-cluster-kubeadm.md to chinese (#11041)

* trsanlate create-cluster-kubeadm.md to chinese

* Update create-cluster-kubeadm.md

* update the feature stage in v1.13 (#11307)

* update new feature gates to document (#11295)

* refresh controller role list on rbac description page (#11290)

* node labeling restriction docs (#10944)

* Update 1.13 docs for CSI GA (#10893)

* dynamic audit documentation (#9947)

* adds dynamic audit documentation

* Copyedit for clarity

See also inline question/s

* Fix feature state shortcode

* Update feature state

* changes wording for dynamic audit flag behavior

* Minor copyedit

* fix dynamic audit yaml

* adds api enablement command to dynamic audit docs

* change ordering dynamic audit appears in

* add references to dynamic audit in webhook backend

* reword dynamic audit reference

* updates stages field for audit sink object

* changes audit sink api definition; rewords policy

* kubeadm: remove kube-proxy workaround (#11162)

* zh-trans content/en/docs/setup/independent/install-kubeadm.md (#11338)

* zh-trans content/en/docs/setup/independent/install-kubeadm.md

* Update install-kubeadm.md

* Update dry run feature to beta (#11140)

* vSphere volume raw block support doc update (#10932)

* Add docs for Windows DNS configurations (#10036)

* Update docs for fields allowed at root of CRD schema (#9973)

* Add docs for Windows DNS configurations

* add device monitoring documentation (#9945)

* kubeadm: adds upgrade instructions for 1.13 (#11138)

* kubeadm: adds upgrade instructions for 1.13

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* add minor copyedits

Addressed a couple of copyedit comments a bit more cleanly.

* kubeadm: add improvements to HA docs (#11094)

* kubeadm: add information and diagrams for HA topologies

* kubeadm: update HA doc with simplified steps

* kubeadm: update HA doc with simplified steps

* edit ha, add new topology topic, reorder by weight

* troubleshoot markdown

* fix more markdown, fix links

* more markdown

* more markdown

* more markdown

* changes after reviewer comments

* add steps about Weave

* update note about stacked topology

* kubeadm external etcd HA upgrade 1.13 (#11364)

* kubeadm external etcd HA upgrade 1.13

Signed-off-by: Ruben Orduz <rubenoz@gmail.com>

* Update stacked controlplane steps

* kubeadm cert documentation (#11093)

* kubeadm certificate API and CSR documentation

* copyedits

* fix typo

* PR for diff docs (#10789)

* Empty commit against dev-1.13 for diff documentation

* Complete Declarative maangement with diff commands

* Second Korean l10n work for dev-1.13. (#11030)

* Update outdated l10n(ko) contents (#10915)
* Translate main menu for l10n(ko) docs (#10916)
* Translate tasks/run-application/horizontal-pod-autoscale-walkthrough (#10980)
* Translate content/ko/docs/concepts/overview/working-with-objects/kubernetes-object in Korean #11104 (#11332)
* Pick-right-solution page translates into Korean. (#11340)
* ko-trans: add jd/..., sap/..., ebay/..., homeoffice/... (#11336)
* Translate concept/workloads/pods/pod-overview.md (#11092)

Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: zerobig <38598117+zer0big@users.noreply.github.com>
Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: lIuDuI <1693291525@qq.com>
Co-authored-by: Woojin Na(Eddie) <cheapluv@gmail.com>

* Rename encryption-at-rest related objects (#11059)

EncryptionConfig was renamed to EncryptedConfiguration and added to
the `apiserver.config.k8s.io` API group in Kubernetes 1.13.

The feature was previously in alpha and was not handling versions
properly, which lead to an originally unnoticed `v1` in the docs.

Also, the `--experimental-encryption-provider-config` flag is now called
just `--encryption-provider-config`.

* Documenting FlexVolume Resize alpha feature. (#10097)

* CR webhook conversion documentation (#10986)

* CR Conversion

* Addressing comments

* Addressing more comments

* Addressing even more comments

* Addressing even^2 more comments

* Remove references to etcd2 in v1.13 since support has been removed (#11414)

* Remove etcd2 references as etcd2 is deprecated

Link back to the v1.12 version of the etcd3 doc for
the etcd2->etcd3 migration instructions.

I updated the kube-apiserver reference manually,
unsure if that is auto-generated somehow.

The federation-apiserver can still potentially
support etcd2 so I didn't touch that.

* Remove outdated {master,node}.yaml files

There are master/node yaml files that reference
etcd2.service that are likely highly out of date.
I couldn't find any docs that actually reference
these templates so I removed them

* Address review comments

* Final Korean l10n work for dev-1.13 (#11440)

* Update outdated l10n(ko) contents (#11425)

fixes #11424

* Remove references to etcd2 in content/ko (#11416)

* Resolve conflicts against master for /ko contents (#11438)

* Fix unopened caution shortcode

* kubeadm: update the reference docs for 1.13 (#10960)

* docs update to promote TaintBasedEvictions to beta (#10765)

* First Korean l10n work for dev-1.13 (#10719)

* Update outdated l10n(ko) contents (#10689)

fixes #10686

* Translate concepts/overview/what-is-kubernetes in Korean (#10690)

* Translate concepts/overview/what-is-kubernetes in Korean

* Feedback from ClaudiaJKang

* Translate concepts/overview/components in Korean (#10882)

* Translate concepts/overview/components in Korean #10717

* Translate concepts/overview/components in Korean

* Translate concepts/overview/components in Korean

* Apply Korean glossary: 서비스 어카운트

* Translate concepts/overview/kubernetes-api in Korean (#10773)

* Translate concepts/overview/kubernetes-api in Korean

* Applied feedback from ianychoi

* kubeadm: update the configuration docs to v1beta1 (#10959)

* kubeadm: add small v1beta1 related updates (#10988)

* update new feature gates to document (#11295)

* Update dry run feature to beta (#11140)

* kubeadm: add improvements to HA docs (#11094)

* kubeadm: add information and diagrams for HA topologies

* kubeadm: update HA doc with simplified steps

* kubeadm: update HA doc with simplified steps

* edit ha, add new topology topic, reorder by weight

* troubleshoot markdown

* fix more markdown, fix links

* more markdown

* more markdown

* more markdown

* changes after reviewer comments

* add steps about Weave

* update note about stacked topology

* kubeadm: update reference docs

- add section about working with phases under kubeadm-init.md
- update GA / beta status of features
- kubeadm alpha phase was moved to kubeadm init phase
- new commands were added under kubeadm alpha
- included new CoreDNS usage examples

* Generate components and tools reference

* Add generated federation API Reference (#11491)

* Add generated federation API Reference

* Add front matter to federation reference

* Remove whitespace from federation front matter

* Remove more whitespace from federation front matter

* Remove superfluous kubefed reference

* Add frontmatter to generated kubefed reference

* Fix kubefed reference page frontmatter

* Generate kubectl reference docs 1.13 (#11487)

* Generate kubectl reference docs 1.13

* Fix links in kubectl reference

* Add 1.13 API reference (#11489)

* Update config.toml (#11486)

* Update config.toml

Preparing for 1.13 release, updating the config.toml and dropping the 1.8 docs reference.

* update dot releases and docsbranch typo

* adding .Site. to Params.currentUrl (#11503)

see https://github.com/kubernetes/website/pull/11502 for context

* Add 1.13 Release notes (#11499)
This commit is contained in:
Jim Angel
2018-12-03 19:21:11 -06:00
committed by Kubernetes Prow Robot
parent b1dde5578c
commit 27b7b453a9
347 changed files with 69250 additions and 4447 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+124
View File
@@ -0,0 +1,124 @@
---
reviewers:
- sig-cluster-lifecycle
title: Certificate Management with kubeadm
content_template: templates/task
---
{{% capture overview %}}
This page explains how to manage certificates manually with kubeadm.
{{% /capture %}}
{{% capture prerequisites %}}
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If kubeadm with the default configuration satisfies your needs, you should let kubeadm manage certificates instead.
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/certificates/).
{{% /capture %}}
{{% capture steps %}}
## Renew certificates with the certificates API
Kubeadm can renew certificates with the `kubeadm alpha certs renew` commands.
Typically this is done by loading on-disk CA certificates and keys and using them to issue new certificates.
This approach works well if your certificate tree is self-contained. However, if your certificates are externally
managed, you might need a different approach.
As an alternative, Kubernetes provides its own [API for managing certificates][manage-tls].
With kubeadm, you can use this API by running `kubeadm alpha certs renew --use-api`.
## Set up a signer
The Kubernetes Certificate Authority does not work out of the box.
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
The built-in signer is part of [`kube-controller-manager`][kcm].
To activate the build-in signer, you pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` arguments.
You pass these arguments in any of the following ways:
* Edit `/etc/kubernetes/manifests/kube-controller-manager.yaml` to add the arguments to the command.
Remember that your changes could be overwritten when you upgrade.
* If you're creating a new cluster, you can use a kubeadm [configuration file][config]:
```yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
controllerManager:
extraArgs:
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
```
* You can also upload a config file using [`kubeadm config upload from-files`][config-upload]
[cert-manager-issuer]: https://cert-manager.readthedocs.io/en/latest/tutorials/ca/creating-ca-issuer.html
[kcm]: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/
[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
[config-upload]: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-config/#cmd-config-from-file
### Approve requests
If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
Otherwise, you must manually approve certificates with the [`kubectl certificates`][certs] command.
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
```shell
$ sudo kubeadm alpha certs renew apiserver --use-api &
[1] 2890
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
$ kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
[1]+ Done sudo kubeadm alpha certs renew apiserver --use-api
```
You can view a list of pending certificates with `kubectl get csr`.
[manage-tls]: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/
[cert-manager]: https://github.com/jetstack/cert-manager
[certs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#certificate
## Certificate requests with kubeadm
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
A CSR represents a request to a CA for a signed certificate for a client.
In kubeadm terms, any certificate that would normally be signed by an on-disk CA can be produced as a CSR instead. A CA, however, cannot be produced as a CSR.
You can create an individual CSR with `kubeadm init phase certs apiserver --use-csr`.
The `--use-csr` flag can be applied only to individual phases. After [all certificates are in place][certs], you can run `kubeadm init --external-ca`.
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
If `--csr-dire` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
Both the CSR and the accompanying private key are given in the output. After a certificate is signed, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
### Renew certificates
Certificates can be renewed with `kubeadm alpha certs renew --use-csr`.
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
To use the new certificates, copy the signed certificate and private key into the PKI directory (by default `/etc/kubernetes/pki`)
## Cert usage
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate.
* In `openssl` this is done with the [`openssl ca` command][openssl-ca].
* In `cfssl` you specify [usages in the config file][cfssl-usages]
## CA selection
Kubeadm sets up [three CAs][cert-cas] by default. Make sure to sign the CSRs with a corresponding CA.
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
[certs]: https://kubernetes.io/docs/setup/certificates
[cert-cas]: https://kubernetes.io/docs/setup/certificates/#single-root-ca
[cert-table]: https://kubernetes.io/docs/setup/certificates/#all-certificates
{{% /capture %}}
https://prow.k8s.io/?pull=71212
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13.md
+278
View File
@@ -0,0 +1,278 @@
---
reviewers:
- sig-cluster-lifecycle
title: Upgrading kubeadm clusters from v1.12 to v1.13
content_template: templates/task
---
{{% capture overview %}}
This page explains how to upgrade a Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.x, and from version 1.13.x to 1.13.y, where `y > x`.
{{% /capture %}}
{{% capture prerequisites %}}
- You need to have a `kubeadm` Kubernetes cluster running version 1.12.0 or later.
[Swap must be disabled][swap].
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.13.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.
[swap]: https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux
### 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.
{{% /capture %}}
{{% capture steps %}}
## Upgrade the control plane
1. On your master node, upgrade kubeadm:
{{< 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 kubeadm --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
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:
```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.12.2
[upgrade/versions] kubeadm version: v1.13.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.12.2 v1.13.0
Upgrade to the latest version in the v1.12 series:
COMPONENT CURRENT AVAILABLE
API Server v1.12.2 v1.13.0
Controller Manager v1.12.2 v1.13.0
Scheduler v1.12.2 v1.13.0
Kube Proxy v1.12.2 v1.13.0
CoreDNS 1.2.2 1.2.6
Etcd 3.2.24 3.2.24
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.13.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.13.0
```
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'
[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.13.0"
[upgrade/versions] Cluster version: v1.12.2
[upgrade/versions] kubeadm version: v1.13.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-controller-manager.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[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-etcd
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[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-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[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.13.0"...
Static pod: kube-apiserver-ip-10-0-0-7 hash: 4af3463d6ace12615f1795e40811c1a1
Static pod: kube-controller-manager-ip-10-0-0-7 hash: a640b0098f5bddc701786e007c96e220
Static pod: kube-scheduler-ip-10-0-0-7 hash: ee7b1077c61516320f4273309e9b4690
map[localhost:2379:3.2.24]
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests969681047"
[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-11-20-18-30-42/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-ip-10-0-0-7 hash: 4af3463d6ace12615f1795e40811c1a1
Static pod: kube-apiserver-ip-10-0-0-7 hash: bf5b045d2be93e73654f3eb7027a4ef8
[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-11-20-18-30-42/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-ip-10-0-0-7 hash: a640b0098f5bddc701786e007c96e220
Static pod: kube-controller-manager-ip-10-0-0-7 hash: 1e0eea23b3d971460ac032c18ab7daac
[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-11-20-18-30-42/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-ip-10-0-0-7 hash: ee7b1077c61516320f4273309e9b4690
Static pod: kube-scheduler-ip-10-0-0-7 hash: 7f7d929b61a2cc5bcdf36609f75927ec
[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.13" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.13" ConfigMap in the kube-system namespace
[kubelet-start] 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-10-0-0-7" 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.13.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 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 node for maintenance by marking it unschedulable and evicting the workloads. Run:
```shell
kubectl drain $NODE --ignore-daemonsets
```
On the master node, 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 `$NODE` 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
kubeadm upgrade node config --kubelet-version $(kubelet --version | cut -d ' ' -f 2)
```
1. Restart the kubelet process:
```shell
systemctl restart kubelet
```
1. Verify that the new version of the `kubelet` is running on the node:
```shell
systemctl status kubelet
```
1. Bring the node back online by marking it schedulable:
```shell
kubectl uncordon $NODE
```
1. 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.
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-12.md
+1 -1
View File
@@ -113,7 +113,7 @@ You should see something like the following:
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.0". Enjoy!
The `kubeadm-config` ConfigMap is now updated from `v1alpha2` version to `v1alpha3`.
The `kubeadm-config` ConfigMap is now updated from `v1alpha3` version to `v1beta1`.
### Upgrading additional control plane nodes
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13.md
+168
View File
@@ -0,0 +1,168 @@
---
reviewers:
- luxas
- timothysc
- jbeda
title: Upgrading kubeadm HA clusters from v1.12 to v1.13
content_template: templates/task
---
{{% capture overview %}}
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.y. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/independent/high-availability/).
{{% /capture %}}
{{% capture prerequisites %}}
Before proceeding:
- You need to have a `kubeadm` HA cluster running version 1.12 or higher.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.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.
- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.12 to v1.13](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13/).
{{< note >}}
All commands on any control plane or etcd node should be run as root.
{{< /note >}}
{{% /capture %}}
{{% capture steps %}}
## Prepare for both methods
Upgrade `kubeadm` to the version that matches the version of Kubernetes that you are upgrading to:
```shell
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm && \
apt-mark hold kubeadm
```
Check prerequisites and determine the upgrade versions:
```shell
kubeadm upgrade plan
```
You should see something like the following:
```
Upgrade to the latest version in the v1.13 series:
COMPONENT CURRENT AVAILABLE
API Server v1.12.2 v1.13.0
Controller Manager v1.12.2 v1.13.0
Scheduler v1.12.2 v1.13.0
Kube Proxy v1.12.2 v1.13.0
CoreDNS 1.2.2 1.2.6
```
## Stacked control plane nodes
### Upgrade the first control plane node
Modify `configmap/kubeadm-config` for this control plane node:
```shell
kubectl edit configmap -n kube-system kubeadm-config
```
Make the following modifications to the ClusterConfiguration key:
- `etcd`
Remove the etcd section completely
Make the following modifications to the ClusterStatus key:
- `apiEndpoints`
Add an entry for each of the additional control plane hosts
Start the upgrade:
```shell
kubeadm upgrade apply v<YOUR-CHOSEN-VERSION-HERE>
```
You should see something like the following:
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.13.0". Enjoy!
The `kubeadm-config` ConfigMap is now updated from `v1alpha3` version to `v1beta1`.
### Upgrading additional control plane nodes
Start the upgrade:
```shell
kubeadm upgrade node experimental-control-plane
```
## External etcd
### Upgrade the first control plane
Run the upgrade:
```
kubeadm upgrade apply v1.13.0
```
### Upgrade the other control plane nodes
For other control plane nodes in the cluster, run the following command:
```
kubeadm upgrade node experimental-control-plane
```
## Next steps
### Manually upgrade your CNI provider
Your Container Network Interface (CNI) provider might have its own upgrade instructions to follow. Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see whether you need to take additional upgrade steps.
### Update kubelet and kubectl packages
Upgrade the kubelet and kubectl by running the following on each node:
```shell
# use your distro's package manager, e.g. 'apt-get' on Debian-based systems
# for the versions stick to kubeadm's output (see above)
apt-mark unhold kubelet kubectl && \
apt-get update && \
apt-get install kubelet=<NEW-K8S-VERSION> kubectl=<NEW-K8S-VERSION> && \
apt-mark hold kubelet kubectl && \
systemctl restart kubelet
```
In this example a _deb_-based system is assumed and `apt-get` is used for installing the upgraded software. On rpm-based systems the command is `yum install <PACKAGE>=<NEW-K8S-VERSION>` for all packages.
Verify that the new version of the kubelet is running:
```shell
systemctl status kubelet
```
Verify that the upgraded node is available again by running the following command from wherever you run `kubectl`:
```shell
kubectl get nodes
```
If the `STATUS` column shows `Ready` for the upgraded host, you can continue. You might need to repeat the command until the node shows `Ready`.
## If something goes wrong
If the upgrade fails, see whether one of the following scenarios applies:
- If `kubeadm upgrade apply` failed to upgrade the cluster, it will try to perform a rollback. If this is the case on the first master, the cluster is probably still intact.
You can run `kubeadm upgrade apply` again, because it is idempotent and should eventually make sure the actual state is the desired state you are declaring. You can run `kubeadm upgrade apply` to change a running cluster with `x.x.x --> x.x.x` with `--force` to recover from a bad state.
- If `kubeadm upgrade apply` on one of the secondary masters failed, the cluster is upgraded and working, but the secondary masters are in an undefined state. You need to investigate further and join the secondaries manually.
{{% /capture %}}