Additional settings

Upgrade to the Target K3s Version. Replace <<K3s_VERSION>> below with the desired version string retrieved from Upgrade Strategy. The following command will upgrade K3s to that version with customized install options:

curl -sfL https://get.k3s.io | sudo INSTALL_K3S_VERSION="<<K3s_VERSION>>" INSTALL_K3S_EXEC="--flannel-backend=none --disable traefik --disable servicelb --write-kubeconfig-mode 644" sh -s -

Post-upgrade verification. To display the current Kubernetes version managed by K3s and the nodes' health, run:

sudo k3s kubectl version
sudo k3s kubectl get nodes
sudo k3s kubectl get pods -n kube-system

K3s relies on a set of TLS certificates to secure communication between the Kubernetes control plane, the kubelet, and cluster components. You can check the certificate validity, interpret expiration warnings, and manually rotate certificates when automatic renewal is not sufficient.

To check the expiration dates of your certificates, run the following command:

sudo k3s certificate check --output table

The following table provides the details that you must check for the relevant certificate:

You can manually rotate certificates using the K3s CLI with the following command:

sudo k3s certificate rotate
sudo systemctl restart k3s

The host Linux bridge acts as a software switch, connecting VM network interfaces directly to the host's physical NIC. This allows VMs to appear as first-class nodes on the physical network, enabling full Layer 2 connectivity without NAT.

The following diagram illustrates the traversal of network packets through the host’s physical NIC, VLAN interfaces, and bridges before reaching the VM, and how traffic originating from the VM flows back to the external network.

GV VM (10.10.60.101) -> vnet12 (tap) -> Bridge-60 -> enp7s0.60 -> physical switch/router -> DNS (10.10.2.6/7)
Return: 10.10.2.6 -> router -> VLAN 60 -> enp7s0.60 -> Bridge-60 -> vnet12 -> VM

Pod (10.43.A.B) -> kube-proxy/iptables -> CoreDNS service (10.43.0.10) -> CoreDNS pod
-> GV VM kernel routing -> vnet12 -> Bridge-60 -> enp7s0.60 -> physical switch/router -> External DNS
Return: External DNS -> router -> VLAN 60 -> enp7s0.60 -> Bridge-60 -> vnet12 -> GV VM -> CoreDNS pod -> kube-proxy -> Pod

virbr0 uses NAT, so external systems cannot directly reach VMs unless port forwarding is configured. Use the host Linux bridge for production-like setups where VMs need routable IPs.

VM -> vnet -> virbr0 (DHCP + NAT) -> Host NIC -> Switch -> Internet

Unlike a host-managed bridge, virbr0 does not integrate VMs as full participants in the physical network. Instead, it keeps them in an isolated network environment.

This setup is useful for testing and development scenarios. However, it is not ideal for production environments, where VMs need routable IP addresses and full network visibility.

GV OVA is delivered as a hardened, appliance-style VM with clearly defined ownership and support boundaries.

Virtana follows a structured approach that combines Helm-based application upgrades with coordinated vulnerability remediation, ensuring that you can keep your Global View deployment current and secure with minimal operational effort.

The table below defines responsibilities between you and Virtana after deploying the GV OVA. Since the OVA is deployed in your environment, you may need to execute certain tasks. Virtana provides guidance, scripts, and support.