kubeadm upgrade is a user-friendly command that wraps complex upgrading logic behind one command, with support for both planning an upgrade and actually performing it. kubeadm upgrade guidance The steps for performing an upgrade using kubeadm are outlined in this document. For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website. You can use kubeadm upgrade diff to see the changes that would be applied to static pod manifests.

Synopsis Show the status of the rollout. By default 'rollout status' will watch the status of the latest rollout until it's done. If you don't want to wait for the rollout to finish then you can use --watch=false. Note that if a new rollout starts in-between, then 'rollout status' will continue watching the latest revision. If you want to pin to a specific revision and abort if it is rolled over by another revision, use --revision=N where N is the revision you need to watch for.

Production-Grade Container Orchestration

kubeadm reset phase enables you to invoke atomic steps of the node reset process. Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization. kubeadm reset phase is consistent with the kubeadm reset workflow, and behind the scene both use the same code. kubeadm reset phase phase Synopsis Use this command to invoke single phase of the "reset" workflow

Production-Grade Container Orchestration

This page contains an overview of the various feature gates an administrator can specify on different Kubernetes components. See feature stages for an explanation of the stages for a feature. Overview Feature gates are a set of key=value pairs that describe Kubernetes features. You can turn these features on or off using the --feature-gates command line flag on each Kubernetes component. How to enable Feature Gates To enable or disable a feature gate for a particular Kubernetes component, use the --feature-gates flag.

Synopsis Display resource (CPU/memory) usage of nodes. The top-node command allows you to see the resource consumption of nodes. kubectl top node [NAME | -l label] Examples # Show metrics for all nodes kubectl top node # Show metrics for a given node kubectl top node NODE_NAME Options -h, --help help for node --no-headers If present, print output without headers -l, --selector string Selector (label query) to filter on, supports '=', '==', '!

Production-Grade Container Orchestration

Synopsis View previous rollout revisions and configurations. kubectl rollout history (TYPE NAME | TYPE/NAME) [flags] Examples # View the rollout history of a deployment kubectl rollout history deployment/abc # View the details of daemonset revision 3 kubectl rollout history daemonset/abc --revision=3 Options --allow-missing-template-keys     Default: true If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.

By default, kubeadm runs a local etcd instance on each control plane node. It is also possible to treat the etcd cluster as external and provision etcd instances on separate hosts. The differences between the two approaches are covered in the Options for Highly Available topology page. This task walks through the process of creating a high availability external etcd cluster of three members that can be used by kubeadm during cluster creation.