NCP-CN practice question 7 of 25

[Conduct NKP Fleet Management] Some time ago, an EKS cluster was attached to be managed with NKP (Fleet Management). Now, a Platform Engineer has…

Full set: 108 questions
[Conduct NKP Fleet Management] Some time ago, an EKS cluster was attached to be managed with NKP (Fleet Management). Now, a Platform Engineer has been asked to disconnect the EKS cluster from NKP for licensing reasons. After disconnecting the cluster, the developers realized that application changes are still being reflected in the EKS cluster, despite the fact that the EKS cluster was successfully detached from NKP. How should the engineer resolve this issue?
Answer options
A: Forcefully detach EKS cluster: nkp detach cluster -c detached-cluster-name --force
B: Detached cluster must also be deleted from NKP: nkp delete cluster -c detached-cluster-name
C: Developers must have some bad configuration in the deployment config files. Ask for revision or call AWS technical support.
D: Detached cluster’s Flux installation must be manually disconnected from the management Git repository: kubectl -n kommmander-flux patch gitrepo management -p '{"spec":{"suspend":true}}' -- type merge Correct answer
Correct Answer:
D. Detached cluster’s Flux installation must be manually disconnected from the management Git repository: kubectl -n kommmander-flux patch gitrepo management -p '{"spec":{"suspend":true}}' -- type merge
Explanation

Nutanix Kubernetes Platform (NKP) uses a GitOps model, powered by Flux, to manage attached clusters. When a cluster is detached using the nkp detach command, NKP removes it from its central management plane. However, this process intentionally does not uninstall the Flux components or disable the GitOps configuration on the detached cluster itself. This ensures that running applications are not disrupted. As a result, the Flux controller on the EKS cluster remains active and continues to synchronize with the management Git repository, applying any new changes. To stop this behavior, the administrator must manually suspend the Flux GitRepository resource on the detached cluster, which halts the synchronization process.

Why Incorrect

A: The cluster was already successfully detached. Re-running the command, even with --force, is redundant and does not address the residual, active Flux synchronization on the cluster. B: The nkp delete cluster command is used to destroy clusters provisioned by NKP. It is not the correct command for an attached EKS cluster or for managing post-detachment configurations. C: The issue is not with application configuration files but with the platform-level GitOps mechanism (Flux) that is still actively applying those configurations from the repository to the cluster.

References

1. D2iQ Kommander Documentation (Foundation for NKP): The process of detaching a cluster is described in the D2iQ Kommander documentation

which NKP is built upon. It explicitly states that the GitOps configuration remains on the cluster after detachment. "When you detach a cluster... The GitOps configuration that synchronizes your cluster with your Git repository remains on the cluster." This confirms the scenario's premise.

Source: D2iQ Kommander Documentation

"Detach a Managed or Attached Cluster". (Specific URL varies by version

but the principle is consistent).

2. FluxCD Documentation (Core Technology): The command in the correct answer aligns with the official FluxCD documentation for managing resources. Suspending a GitRepository is the standard method to stop reconciliation.

Source: FluxCD Documentation

"Manage Resources > Suspend and resume resources".

URL: https://fluxcd.io/flux/components/source/gitrepositories/#suspending-and-resuming

3. Nutanix Kubernetes Platform Administration Guide: The guide describes the detach command's function as removing the cluster from management

noting that applications continue to run

which implies underlying configurations like Flux are left intact to prevent service disruption.

Source: Nutanix Kubernetes Platform 2.x Administration Guide

"Detaching a Cluster from Management".

Scroll to Top