1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

Update node docs

Signed-off-by: Avital Pinnick <apinnick@redhat.com>
This commit is contained in:
Avital Pinnick
2023-08-10 16:21:47 +03:00
parent eb82506b27
commit 1f6da87721
22 changed files with 28 additions and 35 deletions

View File

@@ -3847,13 +3847,11 @@ Topics:
- Name: Configuring live migration policies
File: virt-configuring-live-migration-policies
# Node maintenance mode
- Name: Node maintenance
Dir: node_maintenance
- Name: Nodes
Dir: nodes
Topics:
- Name: About node maintenance
File: virt-about-node-maintenance
- Name: Automatic renewal of TLS certificates
File: virt-automatic-certificates
- Name: Managing node labeling for obsolete CPU models
File: virt-managing-node-labeling-obsolete-cpu-models
- Name: Preventing node reconciliation

View File

@@ -1,5 +1,5 @@
// Module included in the following assemblies:
// * virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc
// * virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc
:_content-type: CONCEPT
[id="virt-about-node-labeling-cpu-features_{context}"]

View File

@@ -1,5 +1,5 @@
// Module included in the following assemblies:
// * virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc
// * virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc
:_content-type: CONCEPT
[id="virt-about-node-labeling-obsolete-cpu-models_{context}"]

View File

@@ -1,5 +1,5 @@
// Module included in the following assemblies:
// virt/node_maintenance/virt-about-node-maintenance.adoc
// virt/nodes/virt-about-node-maintenance.adoc
:_content-type: CONCEPT
[id="virt-about-node-maintenance_{context}"]

View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * virt/node_maintenance/virt-about-node-maintenance.adoc
// * virt/nodes/virt-about-node-maintenance.adoc
:_content-type: CONCEPT
[id="virt-about-runstrategies-vms_{context}"]

View File

@@ -4,7 +4,7 @@
:_content-type: REFERENCE
[id="virt-additional-scc-for-kubevirt-controller_{context}"]
= Additional {product-title} security context constraints and Linux capabilities for the kubevirt-controller service account
= Additional SCCs and permissions for the kubevirt-controller service account
Security context constraints (SCCs) control permissions for pods. These permissions include actions that a pod, a collection of containers, can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system.
@@ -20,12 +20,12 @@ This allows virtual machines to use the hostpath volume plugin.
* `scc.AllowPrivilegedContainer = false` +
This ensures the virt-launcher pod is not run as a privileged container.
* `scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}` +
* `scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}`
** `SYS_NICE` allows setting the CPU affinity.
** `NET_BIND_SERVICE` allows DHCP and Slirp operations.
== Viewing the SCC and RBAC definitions for the kubevirt-controller
.Viewing the SCC and RBAC definitions for the kubevirt-controller
You can view the `SecurityContextConstraints` definition for the `kubevirt-controller` by using the `oc` tool:

View File

@@ -1,9 +1,13 @@
// Module included in the following assemblies:
//
// * virt/node_maintenance/virt-automatic-certificates.adoc
// * virt/about_virt/virt-security-policies.adoc
[id="virt-automatic-certificates-renewal_{context}"]
= TLS certificates automatic renewal schedules
= TLS certificates
TLS certificates for {VirtProductName} components are renewed and rotated automatically. You are not required to refresh them manually.
.Automatic renewal schedules
TLS certificates are automatically deleted and replaced according to the following schedule:

View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc
// * virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc
:_content-type: PROCEDURE
[id="virt-configuring-obsolete-cpu-models_{context}"]

View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// virt/node_maintenance/virt-about-node-maintenance.adoc
// virt/nodes/virt-about-node-maintenance.adoc
[id="virt-maintaining-bare-metal-nodes_{context}"]
= Maintaining bare metal nodes

View File

@@ -1,6 +1,6 @@
// Module included in the following assembly:
//
// * virt/node_maintenance/virt-preventing-node-reconciliation.adoc
// * virt/nodes/virt-preventing-node-reconciliation.adoc
//
:_content-type: PROCEDURE

View File

@@ -10,10 +10,9 @@ Learn about {VirtProductName} security and authorization.
.Key points
* {VirtProductName} adheres to the `restricted` link:https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted[Kubernetes pod security standards] profile, which aims to enforce the current best practices for pod security.
* Virtual machine (VM) workloads run as unprivileged pods.
* xref:../../authentication/managing-security-context-constraints.adoc#security-context-constraints-about_configuring-internal-oauth[Security context constraints] (SCCs) are defined for the `kubevirt-controller` service account.
* TLS certificates for {VirtProductName} components are renewed and rotated automatically.
include::modules/virt-about-workload-security.adoc[leveloffset=+1]
@@ -26,11 +25,14 @@ include::modules/virt-additional-scc-for-kubevirt-controller.adoc[leveloffset=+1
include::modules/virt-default-cluster-roles.adoc[leveloffset=+2]
[discrete]
[role="_additional-resources"]
[id="additional-resources_{context}"]
[id="additional-resources_authorization"]
== Additional resources
* xref:../../authentication/managing-security-context-constraints.adoc#security-context-constraints-about_configuring-internal-oauth[Managing security context constraints]
* xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define and apply permissions]
* xref:../../authentication/using-rbac.adoc#creating-cluster-role_using-rbac[Creating a cluster role]
* xref:../../authentication/using-rbac.adoc#cluster-role-binding-commands_using-rbac[Cluster role binding commands]
* xref:../../virt/virtual_machines/cloning_vms/virt-enabling-user-permissions-to-clone-datavolumes.adoc#virt-enabling-user-permissions-to-clone-datavolumes[Enabling user permissions to clone data volumes across namespaces]
* xref:../../virt/virtual_machines/cloning_vms/virt-enabling-user-permissions-to-clone-datavolumes.adoc#virt-enabling-user-permissions-to-clone-datavolumes[Enabling user permissions to clone data volumes across namespaces]
include::modules/virt-automatic-certificates-renewal.adoc[leveloffset=+1]

View File

@@ -143,7 +143,7 @@ You can configure one of the following high-availability (HA) options for your c
+
[NOTE]
====
In {product-title} clusters installed using installer-provisioned infrastructure and with MachineHealthCheck properly configured, if a node fails the MachineHealthCheck and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See xref:../../virt/node_maintenance/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[About RunStrategies for virtual machines] for more detailed information about the potential outcomes and how RunStrategies affect those outcomes.
In {product-title} clusters installed using installer-provisioned infrastructure and with MachineHealthCheck properly configured, if a node fails the MachineHealthCheck and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See xref:../../virt/nodes/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[About RunStrategies for virtual machines] for more detailed information about the potential outcomes and how RunStrategies affect those outcomes.
====
* Automatic high availability for both IPI and non-IPI is available by using the *Node Health Check Operator* on the {product-title} cluster to deploy the `NodeHealthCheck` controller. The controller identifies unhealthy nodes and uses the Self Node Remediation Operator to remediate the unhealthy nodes. For more information on remediation, fencing, and maintaining nodes, see the link:https://access.redhat.com/documentation/en-us/workload_availability_for_red_hat_openshift/23.2/html-single/remediation_fencing_and_maintenance/index#about-remediation-fencing-maintenance[Workload Availability for Red Hat OpenShift] documentation.

View File

@@ -1,11 +0,0 @@
:_content-type: ASSEMBLY
[id="virt-automatic-certificates"]
= Automatic renewal of TLS certificates
include::_attributes/common-attributes.adoc[]
:context: virt-automatic-certificates
toc::[]
All TLS certificates for {VirtProductName} components are renewed and rotated automatically. You are not required to refresh them manually.
include::modules/virt-automatic-certificates-renewal.adoc[leveloffset=+1]

View File

@@ -14,4 +14,4 @@ include::modules/virt-using-skip-node.adoc[leveloffset=+1]
[role="_additional-resources"]
== Additional resources
* xref:../../virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc#virt-managing-node-labeling-obsolete-cpu-models[Managing node labeling for obsolete CPU models]
* xref:../../virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc#virt-managing-node-labeling-obsolete-cpu-models[Managing node labeling for obsolete CPU models]

View File

@@ -13,7 +13,7 @@ If a node fails and xref:../../machine_management/deploying-machine-health-check
If you installed your cluster by using xref:../../installing/installing_bare_metal_ipi/ipi-install-overview.adoc#ipi-install-overview[installer-provisioned infrastructure] and you properly configured machine health checks, the following events occur:
* Failed nodes are automatically recycled.
* Virtual machines with xref:../../virt/node_maintenance/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[`runStrategy`] set to `Always` or `RerunOnFailure` are automatically scheduled on healthy nodes.
* Virtual machines with xref:../../virt/nodes/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[`runStrategy`] set to `Always` or `RerunOnFailure` are automatically scheduled on healthy nodes.
====
[id="prerequisites_{context}"]

View File

@@ -12,7 +12,7 @@ You can enable high availability for virtual machines (VMs) by manually deleting
If a node fails and machine health checks are not deployed on your cluster, virtual machines with `runStrategy: Always` configured are not automatically relocated to healthy nodes. To trigger VM failover, you must manually delete the `Node` object.
See xref:../../../virt/node_maintenance/virt-triggering-vm-failover-resolving-failed-node.adoc#virt-triggering-vm-failover-resolving-failed-node[Deleting a failed node to trigger virtual machine failover].
See xref:../../../virt/nodes/virt-triggering-vm-failover-resolving-failed-node.adoc#virt-triggering-vm-failover-resolving-failed-node[Deleting a failed node to trigger virtual machine failover].
.Configuring remediating nodes