Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

4.2. Working with nodes

As an administrator, you can perform a number of tasks to make your clusters more efficient.

4.2.1. Understanding how to evacuate pods on nodes
复制链接

Evacuating pods allows you to migrate all or selected pods from a given node or nodes.

You can only evacuate pods backed by a replication controller. The replication controller creates new pods on other nodes and removes the existing pods from the specified node(s).

Bare pods, meaning those not backed by a replication controller, are unaffected by default. You can evacuate a subset of pods by specifying a pod-selector. Pod selectors are based on labels, so all the pods with the specified label will be evacuated.

Procedure

  1. Mark the nodes unschedulable before performing the pod evacuation.

    1. Mark the node as unschedulable: 

      $ oc adm cordon <node1>
      Copy to Clipboard Toggle word wrap

      Example output

      node/<node1> cordoned
      Copy to Clipboard Toggle word wrap

    2. Check that the node status is NotReady,SchedulingDisabled: 

      $ oc get node <node1>
      Copy to Clipboard Toggle word wrap

      Example output

      NAME        STATUS                        ROLES     AGE       VERSION
<node1>     NotReady,SchedulingDisabled   worker    1d        v1.18.3
      Copy to Clipboard Toggle word wrap

  2. Evacuate the pods using one of the following methods:

    • Evacuate all or selected pods on one or more nodes: 

      $ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
      Copy to Clipboard Toggle word wrap

    • Force the deletion of bare pods using the --force option. When set to true, deletion continues even if there are pods not managed by a replication controller, replica set, job, daemon set, or stateful set: 

      $ oc adm drain <node1> <node2> --force=true
      Copy to Clipboard Toggle word wrap

    • Set a period of time in seconds for each Pod to terminate gracefully, use --grace-period. If negative, the default value specified in the Pod will be used: 

      $ oc adm drain <node1> <node2> --grace-period=-1
      Copy to Clipboard Toggle word wrap

    • Ignore pods managed by daemon sets using the --ignore-daemonsets flag set to true: 

      $ oc adm drain <node1> <node2> --ignore-daemonsets=true
      Copy to Clipboard Toggle word wrap

    • Set the length of time to wait before giving up using the --timeout flag. A value of 0 sets an infinite length of time: 

      $ oc adm drain <node1> <node2> --timeout=5s
      Copy to Clipboard Toggle word wrap

    • Delete pods even if there are pods using emptyDir using the --delete-local-data flag set to true. Local data is deleted when the node is drained: 

      $ oc adm drain <node1> <node2> --delete-local-data=true
      Copy to Clipboard Toggle word wrap

    • List objects that will be migrated without actually performing the evacuation, using the --dry-run option set to true: 

      $ oc adm drain <node1> <node2>  --dry-run=true
      Copy to Clipboard Toggle word wrap

      Instead of specifying specific node names (for example, <node1> <node2>), you can use the --selector=<node_selector> option to evacuate pods on selected nodes.

  3. Mark the node as schedulable when done. 

    $ oc adm uncordon <node1>
    Copy to Clipboard Toggle word wrap

4.2.2. Understanding how to update labels on nodes
复制链接

You can update any label on a node.

Node labels are not persisted after a node is deleted even if the node is backed up by a Machine.

注意

Any change to a MachineSet object is not applied to existing machines owned by the machine set. For example, labels edited or added to an existing MachineSet object are not propagated to existing machines and nodes associated with the machine set.

  • The following command adds or updates labels on a node: 

    $ oc label node <node> <key_1>=<value_1> ... <key_n>=<value_n>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc label nodes webconsole-7f7f6 unhealthy=true
    Copy to Clipboard Toggle word wrap

  • The following command updates all pods in the namespace: 

    $ oc label pods --all <key_1>=<value_1>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc label pods --all status=unhealthy
    Copy to Clipboard Toggle word wrap

By default, healthy nodes with a Ready status are marked as schedulable, meaning that new pods are allowed for placement on the node. Manually marking a node as unschedulable blocks any new pods from being scheduled on the node. Existing pods on the node are not affected.

  • The following command marks a node or nodes as unschedulable:

    Example output

    $ oc adm cordon <node>
    Copy to Clipboard Toggle word wrap

    For example: 

    $ oc adm cordon node1.example.com
    Copy to Clipboard Toggle word wrap

    Example output

    node/node1.example.com cordoned

NAME                 LABELS                                        STATUS
node1.example.com    kubernetes.io/hostname=node1.example.com      Ready,SchedulingDisabled
    Copy to Clipboard Toggle word wrap

  • The following command marks a currently unschedulable node or nodes as schedulable: 

    $ oc adm uncordon <node1>
    Copy to Clipboard Toggle word wrap

    Alternatively, instead of specifying specific node names (for example, <node>), you can use the --selector=<node_selector> option to mark selected nodes as schedulable or unschedulable.

4.2.4. Configuring master nodes as schedulable
复制链接

You can configure master nodes to be schedulable, meaning that new pods are allowed for placement on the master nodes. By default, master nodes are not schedulable.

You can set the masters to be schedulable, but must retain the worker nodes.

注意

You can deploy OpenShift Container Platform with no worker nodes on a bare metal cluster. In this case, the master nodes are marked schedulable by default.

You can allow or disallow master nodes to be schedulable by configuring the mastersSchedulable field.

Procedure

  1. Edit the schedulers.config.openshift.io resource. 

    $ oc edit schedulers.config.openshift.io cluster
    Copy to Clipboard Toggle word wrap

  2. Configure the mastersSchedulable field. 

    apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: "2019-09-10T03:04:05Z"
  generation: 1
  name: cluster
  resourceVersion: "433"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: a636d30a-d377-11e9-88d4-0a60097bee62
spec:
  mastersSchedulable: false
    1 
    
  policy:
    name: ""
status: {}
    Copy to Clipboard Toggle word wrap
    1
    Set to true to allow master nodes to be schedulable, or false to disallow master nodes to be schedulable.
  3. Save the file to apply the changes.

4.2.5. Deleting nodes
复制链接

4.2.5.1. Deleting nodes from a cluster
复制链接

When you delete a node using the CLI, the node object is deleted in Kubernetes, but the pods that exist on the node are not deleted. Any bare pods not backed by a replication controller become inaccessible to OpenShift Container Platform. Pods backed by replication controllers are rescheduled to other available nodes. You must delete local manifest pods.

Procedure

To delete a node from the OpenShift Container Platform cluster, edit the appropriate MachineSet object:

注意

If you are running cluster on bare metal, you cannot delete a node by editing MachineSet objects. Machine sets are only available when a cluster is integrated with a cloud provider. Instead you must unschedule and drain the node before manually deleting it.

  1. View the machine sets that are in the cluster: 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    The machine sets are listed in the form of <clusterid>-worker-<aws-region-az>.

  2. Scale the machine set: 

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

For more information on scaling your cluster using a machine set, see Manually scaling a machine set.

4.2.5.2. Deleting nodes from a bare metal cluster
复制链接

When you delete a node using the CLI, the node object is deleted in Kubernetes, but the pods that exist on the node are not deleted. Any bare pods not backed by a replication controller become inaccessible to OpenShift Container Platform. Pods backed by replication controllers are rescheduled to other available nodes. You must delete local manifest pods.

Procedure

Delete a node from an OpenShift Container Platform cluster running on bare metal by completing the following steps:

  1. Mark the node as unschedulable: 

    $ oc adm cordon <node_name>
    Copy to Clipboard Toggle word wrap

  2. Drain all pods on your node: 

    $ oc adm drain <node_name> --force=true
    Copy to Clipboard Toggle word wrap

  3. Delete your node from the cluster: 

    $ oc delete node <node_name>
    Copy to Clipboard Toggle word wrap

Although the node object is now deleted from the cluster, it can still rejoin the cluster after reboot or if the kubelet service is restarted. To permanently delete the node and all its data, you must decommission the node.

4.2.6. Adding kernel arguments to Nodes
复制链接

In some special cases, you might want to add kernel arguments to a set of nodes in your cluster. This should only be done with caution and clear understanding of the implications of the arguments you set.

警告

Improper use of kernel arguments can result in your systems becoming unbootable.

Examples of kernel arguments you could set include:

  • enforcing=0: Configures Security Enhanced Linux (SELinux) to run in permissive mode. In permissive mode, the system acts as if SELinux is enforcing the loaded security policy, including labeling objects and emitting access denial entries in the logs, but it does not actually deny any operations. While not recommended for production systems, permissive mode can be helpful for debugging.
  • nosmt: Disables symmetric multithreading (SMT) in the kernel. Multithreading allows multiple logical threads for each CPU. You could consider nosmt in multi-tenant environments to reduce risks from potential cross-thread attacks. By disabling SMT, you essentially choose security over performance.

See Kernel.org kernel parameters for a list and descriptions of kernel arguments.

In the following procedure, you create a MachineConfig object that identifies:

  • A set of machines to which you want to add the kernel argument. In this case, machines with a worker role.
  • Kernel arguments that are appended to the end of the existing kernel arguments.
  • A label that indicates where in the list of machine configs the change is applied.

Prerequisites

  • Have administrative privilege to a working OpenShift Container Platform cluster.

Procedure

  1. List existing MachineConfig objects for your OpenShift Container Platform cluster to determine how to label your machine config: 

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap

    Example output

    NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
00-master                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
00-worker                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
01-master-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
01-master-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
01-worker-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
01-worker-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
99-master-1131169f-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
99-master-ssh                                                                                          2.2.0             30m
99-worker-114e8ac7-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
99-worker-ssh                                                                                          2.2.0             30m
rendered-master-b3729e5f6124ca3678188071343115d0            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
rendered-worker-18ff9506c718be1e8bd0a066850065b7            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
    Copy to Clipboard Toggle word wrap

  2. Create a MachineConfig object file that identifies the kernel argument (for example, 05-worker-kernelarg-selinuxpermissive.yaml) 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    1 
    
  name: 05-worker-kernelarg-selinuxpermissive
    2 
    
spec:
  config:
    ignition:
      version: 2.2.0
  kernelArguments:
    - enforcing=0
    3
    Copy to Clipboard Toggle word wrap
    1
    Applies the new kernel argument only to worker nodes.
    2
    Named to identify where it fits among the machine configs (05) and what it does (adds a kernel argument to configure SELinux permissive mode).
    3
    Identifies the exact kernel argument as enforcing=0.

  3. Create the new machine config: 

    $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml
    Copy to Clipboard Toggle word wrap

  4. Check the machine configs to see that the new one was added: 

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap

    Example output

    NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
00-master                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
00-worker                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
01-master-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
01-master-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
01-worker-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
01-worker-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m

05-worker-kernelarg-selinuxpermissive                                                                  3.1.0             105s

99-master-1131169f-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
99-master-ssh                                                                                          2.2.0             30m
99-worker-114e8ac7-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
99-worker-ssh                                                                                          2.2.0             31m
rendered-master-b3729e5f6124ca3678188071343115d0            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
rendered-worker-18ff9506c718be1e8bd0a066850065b7            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
    Copy to Clipboard Toggle word wrap

  5. Check the nodes: 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    Example output

    NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.18.3
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.18.3
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.18.3
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.18.3
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.18.3
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.18.3
    Copy to Clipboard Toggle word wrap

    You can see that scheduling on each worker node is disabled as the change is being applied.

  6. Check that the kernel argument worked by going to one of the worker nodes and listing the kernel command line arguments (in /proc/cmdline on the host): 

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard Toggle word wrap

    Example output

    Starting pod/ip-10-0-141-105ec2internal-debug ...
To use host binaries, run `chroot /host`

sh-4.2# cat /host/proc/cmdline
BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0

sh-4.2# exit
    Copy to Clipboard Toggle word wrap

    You should see the enforcing=0 argument added to the other kernel arguments.

4.2.7. Additional resources
复制链接

For more information on scaling your cluster using a MachineSet, see Manually scaling a MachineSet.

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat