Modify network configuration on an existing machine¶

TechPreview

Caution

For MKE clusters that are part of MOSK infrastructure, the feature is not supported yet.

Modification of network configuration on an existing machine requires a separate approval step from the Infrastructure Operator. This validation is required to prevent accidental cluster failures due to misconfiguration.

While making approval decisions, the Operator verifies the result of network configuration changes per host using the fields located in the IpamHost object status. For details, see IpamHost status.

Warning

When a new network configuration is being applied on nodes,: sequential draining of corresponding nodes and re-running of LCM on them occurs the same way as it is done during cluster update.

Therefore, before proceeding with modifying the network configuration, verify that the Container Cloud management cluster is up-to-date as described in Verify the Container Cloud status before managed cluster update.

To modify network configuration on existing machines:

Edit the L2Template or/and Subnet objects as required.
Caution

For the following L2Template configurations, Mirantis does not recommend changing the original L2template object but creating a new one and change the L2Template assignment exclusively for designated machines:
- If L2Template is used across a group of machines, and changes are required only to certain machines within the group
- If L2Template is used as the default one for the cluster and hence contains the ipam/DefaultForCluster label
For these scenarios, select from the following options:
- Create a new L2 template using the Create L2 templates procedure.
- Duplicate the existing L2Template object associated with the machine to be configured, ensuring that the duplicated L2Template:
  - Does not contain the ipam/DefaultForCluster label
  - Refers to the cluster using Spec.clusterRef: <cluster-name>
Verify the statuses of the IpamHost objects that use the objects updated in the previous step:
```
kubectl get IpamHost <ipamHostName> -o=jsonpath-as-json='{.status.netconfigCandidate}{"\n"}{.status.netconfigCandidateState}{"\n"}{.status.netconfigFilesStates}{"\n"}{.status.messages}'
```
Caution

The following fields of the ipamHost status are renamed since Container Cloud 2.22.0 in the scope of the L2Template and IpamHost objects refactoring:
- netconfigV2 to netconfigCandidate
- netconfigV2state to netconfigCandidateState
- netconfigFilesState to netconfigFilesStates (per file)
No user actions are required after renaming.

The format of netconfigFilesState changed after renaming. The netconfigFilesStates field contains a dictionary of statuses of network configuration files stored in netconfigFiles. The dictionary contains the keys that are file paths and values that have the same meaning for each file that netconfigFilesState had:
- For a successfully rendered configuration file: OK: <timestamp> <sha256-hash-of-rendered-file>, where a timestamp is in the RFC 3339 format.
- For a failed rendering: ERR: <error-message>.
- If the configuration is valid:
  - The netconfigCandidate field contains the Netplan configuration file candidate rendered using the modified objects
  - The netconfigCandidateState and netconfigFilesStates fields have the OK status
  - The netconfigFilesStates field contains the old date and checksum meaning that the effective Netplan configuration is still based on the previous versions of the modified objects
  - The messages field may contain some warnings but no errors
- If the L2 template rendering fails, the candidate for Netplan configuration is empty and its netconfigCandidateState status contains an error message. A broken candidate for Netplan configuration cannot be approved and become the effective Netplan configuration.
Warning

Do not proceed to the next step until you make sure that the netconfigCandidate field contains the valid configuration and this configuration meets your expectations.
Approve the new network configuration for the related IpamHost objects:
```
kubectl patch IpamHost <ipamHostName> --type='merge' -p "{\"spec\":{\"netconfigUpdateAllow\":true}}"
```
Once applied, the new configuration is copied to the netconfigFiles field of the effective Netplan configuration, then copied to the corresponding LCMMachine objects.
Verify the statuses of the updated IpamHost objects:
```
kubectl get IpamHost <ipamHostName> -o=jsonpath-as-json='{.status.netconfigCandidate}{"\n"}{.status.netconfigCandidateState}{"\n"}{.status.netconfigFilesStates}{"\n"}{.status.messages}'
```
Caution

The following fields of the ipamHost status are renamed since Container Cloud 2.22.0 in the scope of the L2Template and IpamHost objects refactoring:
- netconfigV2 to netconfigCandidate
- netconfigV2state to netconfigCandidateState
- netconfigFilesState to netconfigFilesStates (per file)
No user actions are required after renaming.

The format of netconfigFilesState changed after renaming. The netconfigFilesStates field contains a dictionary of statuses of network configuration files stored in netconfigFiles. The dictionary contains the keys that are file paths and values that have the same meaning for each file that netconfigFilesState had:
- For a successfully rendered configuration file: OK: <timestamp> <sha256-hash-of-rendered-file>, where a timestamp is in the RFC 3339 format.
- For a failed rendering: ERR: <error-message>.
The new configuration is copied to the effective Netplan configuration and both configurations are valid when:
- The netconfigCandidateState and netconfigFilesStates fields have the OK status and the same checksum
- The messages list does not contain any errors
Verify the updated LCMMachine objects:
```
kubectl get LCMMachine <LCMMachineName> -o=jsonpath-as-json='{.spec.stateItemsOverwrites}'
```
In the output of the above command, hash sums contained in the bm_ipam_netconfig_files values must match those in the IpamHost.status.netconfigFilesStates output. If so, the new configuration is copied to LCMMachine objects.
Monitor the update operations that start on nodes. For details, see Update a managed cluster using the Container Cloud web UI.