If you’re a virtualization or infrastructure administrator moving into Kubernetes, the biggest challenge isn’t learning new tools; it’s treating Kubernetes like a form of virtualization using VM-style operations.
Nutanix Kubernetes Platform (NKP) is a CNCF-certified, 100% upstream-compatible Kubernetes platform designed to help platform teams transition from VM-style operations to fully automated, declarative platform engineering. NKP bundles lifecycle management, GitOps, disaster recovery, storage, networking, security, and multi-cluster operations into a single supported distribution, eliminating the need to assemble and operate a large DIY Kubernetes toolchain.
These practices are often referred to as Day-2 Kubernetes operations, Kubernetes lifecycle management, and platform engineering best practices.
Before we dive into the anti-patterns, here are the most important mindset shifts to keep in mind.
- Kubernetes nodes are immutable and replaceable, not assets to restore.
- GitOps should be the primary deployment model, not manual
kubectlusage. - Production Kubernetes requires multi-cluster disaster recovery, not stretched clusters.
- Enterprise Kubernetes platforms should include RBAC, PKI, storage, and lifecycle automation out of the box.
Let’s walk through the anti-patterns we encounter most often when VM operations meet Kubernetes.
At a Glance: The Mindset Shift
| Anti-Pattern | Risk Introduced | NKP Capability | Operational Outcome |
| VM snapshots for nodes | Configuration drift and failed restores | Cluster API lifecycle | Nodes replaced automatically |
| SSHing into nodes | Drift and non-reproducible fixes | Declarative config with CAPI | Consistent fleet configuration |
| “kubectl apply” deployments | No audit trail | Built-in Flux CD GitOps | Self-healing deployments |
| Static node IPs | Scale-out and upgrade failures | Dynamic IPAM and load balancing | Safe scaling and upgrades |
| Stretched clusters | etcd quorum risk | Multi-cluster DR with NDK | Site-level resiliency |
| “cluster-admin” everywhere | High blast radius | RBAC roles + IdP integration | Secure multi-tenancy |
| Manual certificates | Expiry outages | Auto-renewal with cert-manager | Automated PKI lifecycle |
| Local node storage | Data loss | Nutanix CSI + NDK | Durable persistent storage |
Anti-Pattern 1 — Backing Up Nodes Instead of Protecting State
The Anti-Pattern: Treating a Kubernetes node like a traditional VM by taking snapshots and backups. In virtualization, a failed server is “restored” from a snapshot. In Kubernetes, nodes are cattle, not pets. The node itself is a disposable resource; its “soul” lives in etcd and persistent storage, not the local OS disk. Restoring node snapshots is not recommended, as it can introduce configuration drift and potentially destabilize the cluster.
Do this instead
Protect what actually matters:
- The cluster state: Back up your etcd database using Velero (included with NKP).
- The application data: Use Nutanix Data Services for Kubernetes (NDK) to provide enterprise-grade storage-layer replication for your persistent volumes.
For your nodes, Nutanix Kubernetes Platform (NKP) utilizes Cluster API (CAPI) to manage the machine lifecycle. Instead of “restoring” an old snapshot, NKP uses a declarative manifest to define the desired state. If a node fails, CAPI simply deploys a fresh copy based on your defined OS image template.
The following snippet is an excerpt that describes the topology of an NKP cluster.
[...]
topology:
controlPlane:
replicas: 3
variables:
- name: clusterConfig
value:
nutanix:
machineDetails:
image:
name: nkp-ubuntu-24.04-release-cis-gpu-1.34.1
memorySize: 16Gi
systemDiskSize: 80Gi
vcpuSockets: 4
[...]Anti-Pattern 2 — Manual SSH for Fixes Instead of Declarative Automation
The Anti-Pattern: Logging into nodes to manually “fix” configurations or restart runtimes. Manual intervention creates configuration drift. Your manual fixes won’t be applied to new nodes created during a scale-out or upgrade.
What is declarative automation? In the VM world, we often use imperative commands (e.g., “Step 1: SSH in. Step 2: Update the config. Step 3: Restart.”). Declarative automation flips this: you simply define the desired state (e.g., “This node must have this specific OS version and memory.”). The system (Kubernetes) then works continuously to ensure the current state always matches that definition. If a node drifts, the system automatically fixes it.
Do this instead
NKP treats nodes as declarative objects. If you need an OS-level change, update the NKP Cluster configuration. CAPI ensures every node in the fleet matches that spec automatically.
Pro tip: For collecting logs for troubleshooting or opening a support case, use
nkp diagnose.
Anti-Pattern 3 — CLI Push Instead of GitOps Pull
The Anti-Pattern: Using kubectl apply -f as your primary deployment method. Manual “pushes” create a single point of truth failure and leave no audit trail.
What is GitOps? Think of GitOps as “Infrastructure as Code” but with an autopilot.
- Code: You store your desired cluster state (YAML files) in a Git repository.
- Sync: A software agent in your cluster (e.g., Flux) continuously compares the cluster’s actual state with the desired state in Git.
- Action: If there is a difference (e.g., you commit a change or the cluster drifts), the agent automatically updates the cluster to match the Git state. No manual commands required.
Do this instead
Version control everything. Let Git be your “Undo” button.
In NKP, Flux CD is delivered as a supported, preconfigured component, enabling immediate GitOps adoption without additional platform integration work.
The following YAML is an example of a GitRepository resource in NKP that Flux is “watching” and synchronizes the cluster to keep it up to date.
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: nkp-demo-catalog-applications
namespace: kommander
spec:
interval: 1m0s
ref:
branch: main
timeout: 1m0s
url: https://github.com/nutanixdev/nkp-demo-catalog-applicationsAnti-Pattern 4 — Static IPs Instead of Dynamic IPAM
The Anti-Pattern: Manually configuring static IP addresses on the node OS. Hardcoding IPs prevents auto-scaling and self-healing.
Why are static IPs a scaling and upgrade bottleneck? In a virtualized environment, a server might keep its IP for years. In Kubernetes, nodes are ephemeral and frequently cycled. Designing for static IPs introduces three major risks:
- The scaling friction: Every time you want to scale out, you must manually “carve out” IPs from your subnet and hardcode them into your automation. This prevents the Cluster Autoscaler from working autonomously.
- The upgrade trap: During a cluster upgrade, NKP uses a rolling update strategy. Before CAPI decommissions an old node, it must deploy a brand-new node to prevent a capacity drop. If you are using static IPs, you must have additional addresses pre-reserved and ready for these new nodes, or the upgrade will fail for lack of available IPs.
- The blast radius: If a node fails, its replacement shouldn’t have to wait for a human to reassign a “fixed” address. Static designs turn a sub-second self-healing process into a manual ticket.
Do this instead
Only use static IPs for the control plane VIP and your load balancer pool (managed via MetalLB, included in NKP).
Rely on DHCP or IPAM for your nodes. In NKP, you define an IP pool, and the platform handles the “plumbing.”
Anti-Pattern 5 — Stretched Clusters Instead of Multi-Cluster DR
The Anti-Pattern: Stretching a single cluster across two sites for disaster avoidance. While this works for VMs, it creates a single point of failure (SPOF) in the etcd quorum. High latency between sites can take down your entire cluster API.
As a rule of thumb, Kubernetes clusters should remain single-site control planes. Site-level resilience should be achieved using multiple independent clusters and replicated data, not a stretched etcd quorum.
Do this instead
Detect site failures via global server load balancing (GSLB) and reroute traffic to a completely independent, healthy Kubernetes cluster.
While NKP components can be deployed across multiple failure domains, this often creates an SPOF if not well-architected. Instead, use a multi-cluster, replicated-data strategy. Deploy independent clusters at sites A and B. Use NDK for synchronous or asynchronous volume replication.
Anti-Pattern 6 — cluster-admin Instead of RBAC
The Anti-Pattern: Using the high-privileged cluster-admin role for daily operations. An exposed admin token is far more dangerous than a stolen password; it can wipe your entire fleet of clusters in seconds.
Do this instead
Use Kubernetes roles to sandbox developers and automated processes, ensuring they see only what they need.
NKP Multi-Tenancy eliminates the complexity of manual Role-Based Access Control (RBAC) by providing a library of pre-defined common roles. Instead of writing complex security policies from scratch, you can apply curated permissions to Workspaces (for clusters) or Projects (for namespaces) directly from the UI.
NKP integrates with your existing identity providers (Active Directory, Okta, GitHub, …), allowing you to delegate admin power to specific project teams without ever handing over the “keys to the kingdom.”
Anti-Pattern 7 — Self-Signed Certs Instead of Automated PKI
The Anti-Pattern: Manually generating self-signed certificates or ignoring expiration dates. Internal Kubernetes communication (API to Kubelet) relies on TLS. If a cert expires, the cluster goes “brain dead.”
Do this instead
Connect your cluster to a trusted CA (like your internal CA or Let’s Encrypt).
NKP includes cert-manager, the industry standard for certificate lifecycle management. It automatically requests, issues, and renews certificates before they expire.
Anti-Pattern 8 — Local Disks Instead of Persistent Storage
The Anti-Pattern: Avoiding stateful apps because containers are “ephemeral” or writing data to local node disks. If a pod restarts in a new node, local data is lost.
Do this instead
Use Persistent Volume Claims (PVCs) backed by a storage backend and let the StorageClass handle disk provisioning.
NKP uses a high-performance CSI Driver to connect pods to Nutanix AOS storage. With NDK, your persistent volumes are not only durable but protected by enterprise-grade snapshots and replication.
Frequently Asked Questions
When is SSH acceptable?
Limit SSH to exceptional troubleshooting scenarios. Routine changes should be declarative.
Does NKP include GitOps?
Yes, Flux CD is integrated and ready to use.
Does NKP include DR and backups?
Yes, Velero for cluster state and NDK for persistent volumes.
Do I need cluster-admin?
No, NKP provides RBAC roles integrated with enterprise identity providers.
Can NKP run stateful apps?
Yes, with CSI and NDK providing durable storage.
How are node failures handled?
Failed nodes are automatically recreated from the cluster template by Cluster API.
Next Steps
Ready to evaluate how an integrated Kubernetes platform simplifies Day-2 operations?