mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-06 06:46:26 +01:00
113 lines
4.3 KiB
Plaintext
113 lines
4.3 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * post_installation_configuration/machine-configuration-tasks.adoc
|
|
|
|
[id="checking-mco-status_{context}"]
|
|
= Checking Machine Config Pool status
|
|
|
|
To see the status of the Machine Config Operator, its sub-components,
|
|
and the resources it manages, use the following `oc` commands:
|
|
|
|
.Procedure
|
|
. To see the number of MCO-managed nodes available on your cluster for each pool, type:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get machineconfigpool
|
|
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
|
|
master rendered-master-dd… True False False 3 3 3 0 4h42m
|
|
worker rendered-worker-fde… True False False 3 3 3 0 4h42m
|
|
----
|
|
+
|
|
In the previous output, there are three master and three worker nodes. All machines are updated
|
|
and none are currently updating. Because all nodes are Updated and Ready and none are Degraded,
|
|
you can ell that there are no issues.
|
|
|
|
. To see each existing `machineconfig`, type:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get machineconfigs
|
|
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE
|
|
00-master 2c9371fbb673b97a6fe8b1c52... 3.1.0 5h18m
|
|
00-worker 2c9371fbb673b97a6fe8b1c52... 3.1.0 5h18m
|
|
01-master-container-runtime 2c9371fbb673b97a6fe8b1c52... 3.1.0 5h18m
|
|
01-master-kubelet 2c9371fbb673b97a6fe8b1c52… 3.1.0 5h18m
|
|
...
|
|
rendered-master-dde... 2c9371fbb673b97a6fe8b1c52... 3.1.0 5h18m
|
|
rendered-worker-fde... 2c9371fbb673b97a6fe8b1c52... 3.1.0 5h18m
|
|
----
|
|
+
|
|
Note that the `machineconfigs` listed as `rendered` are not meant to be
|
|
changed or deleted. Expect them to be hidden at some point in the future.
|
|
|
|
. Check the status of worker (or change to master) to see the status of that pool of nodes:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc describe mcp worker
|
|
...
|
|
Degraded Machine Count: 0
|
|
Machine Count: 3
|
|
Observed Generation: 2
|
|
Ready Machine Count: 3
|
|
Unavailable Machine Count: 0
|
|
Updated Machine Count: 3
|
|
Events: <none>
|
|
----
|
|
|
|
. You can view the contents of a particular machineconfig (in this case,
|
|
`01-master-kubelet`). The trimmed output from the following `oc describe`
|
|
command shows that this `machineconfig` contains both configuration files
|
|
(`cloud.conf` and `kubelet.conf`) and a systemd service
|
|
(Kubernetes Kubelet):
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc describe machineconfigs 01-master-kubelet
|
|
Name: 01-master-kubelet
|
|
...
|
|
Spec:
|
|
Config:
|
|
Ignition:
|
|
Version: 3.1.0
|
|
Storage:
|
|
Files:
|
|
Contents:
|
|
Source: data:,
|
|
Mode: 420
|
|
Overwrite: true
|
|
Path: /etc/kubernetes/cloud.conf
|
|
Contents:
|
|
Source: data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous...
|
|
Mode: 420
|
|
Overwrite: true
|
|
Path: /etc/kubernetes/kubelet.conf
|
|
Systemd:
|
|
Units:
|
|
Contents: [Unit]
|
|
Description=Kubernetes Kubelet
|
|
Wants=rpc-statd.service network-online.target crio.service
|
|
After=network-online.target crio.service
|
|
|
|
ExecStart=/usr/bin/hyperkube \
|
|
kubelet \
|
|
--config=/etc/kubernetes/kubelet.conf \ ...
|
|
----
|
|
|
|
If something goes wrong with a machineconfig that you apply, you can always
|
|
back out that change. For example, if you had run `oc create -f ./myconfig.yaml`
|
|
to apply a machineconfig, you could remove that machineconfig by typing:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc delete -f ./myconfig.yaml
|
|
----
|
|
+
|
|
If that was the only problem, the nodes in the affected pool should return to a non-degraded state.
|
|
This actually causes the rendered configuration to roll back to its previously rendered state.
|
|
|
|
If you add your own MachineConfigs to your cluster, you can use the commands
|
|
shown in the previous example to check their status and the related status of
|
|
the pool to which they are applied.
|