Frequently Asked Questions (FAQs)
Common questions about regions, scale limits, autoscaling behavior, and cluster upgrades for Managed - FPT Kubernetes Engine.
1. Which regions does M-FKE support?
FPT Cloud currently supports 4 regions:
- HAN (Hanoi)
- SGN (Saigon/HCM)
- HAN2 (Hoa Lac)
- JPN01 (Japan)
M-FKE is available in all 4 regions.
2. Can an M-FKE cluster span multiple regions?
M-FKE does not support running a single cluster across multiple regions. Create a cluster in each region for the same application to implement BC&DR.
3. Does M-FKE support multiple VM configurations within a cluster?
Yes, through Worker Groups. Each Worker Group can have a different configuration. Worker Nodes within the same Worker Group share the same configuration (CPU, RAM, Disk).
4. How many Worker Nodes does M-FKE support per cluster?
Up to 100 Worker Nodes per Worker Group and 100 Worker Groups per cluster by default. Contact FPT Cloud to increase the Worker Node limit if needed.
5. Is M-FKE compatible with my existing Kubernetes applications?
Yes. M-FKE uses native Kubernetes, fully compatible with Kubernetes platforms on other clouds (AWS, Azure, GCP, DigitalOcean) and with clusters installed on your own infrastructure — migrating applications between FPT Cloud, your data center, and other clouds is straightforward.
6. How can I expose my application outside the cluster?
The simplest approach is a Service of type LoadBalancer — see Service Type Load Balancer for the full guide.
7. How can I monitor performance and configure alerts for the cluster?
Use FMON to monitor performance and configure alerts for the Kubernetes cluster. FMON also provides logging and tracing that integrates with FKE.
8. What is the base Worker Group? Can it be deleted?
Every M-FKE cluster has one base Worker Group that hosts system components in the kube-system namespace, such as CoreDNS, the CNI controller, and metrics-server. The base Worker Group cannot be deleted.
9. How can I change the flavor and disk configuration of an existing Worker Group?
M-FKE does not support changing the flavor or disk size of an existing Worker Group directly. Create a new Worker Group with the desired configuration, migrate applications to it, then delete the old Worker Group.
10. Nodes in a Worker Group are nearly out of CPU and memory, but the cluster isn't scaling out. Why?
Cluster Autoscaler (CA) scales based on Pod resource requests, not actual usage. CA scales out only when Pods are pending because no node has enough requested capacity to schedule them.
11. Nodes have very low CPU and memory usage, but the cluster isn't scaling in. Why?
Same mechanism as above: CA scales in nodes only after they stay under 50% utilization (requested / allocated resources) for 30 consecutive minutes.
12. Is cluster upgrade fully automated, and can it cause downtime?
Most upgrades are automated: M-FKE creates Worker Nodes on the newer version, then migrates Pods off the old-version nodes. Watch for cases where a Pod's PodDisruptionBudget (PDB) blocks automatic eviction. Downtime, if any, runs from when old Pods are deleted until new Pods are running — this window can extend when Pods use Persistent Volumes. Monitor the upgrade actively.
13. Can Taints be applied to the base Worker Group?
The base Worker Group supports Labels only, not Taints. Applying Taints without matching tolerations on system Pods causes cluster operational issues — deploy applications to other Worker Groups instead.
14. Which OS is my Worker Node running?
Open the Worker Group detail screen — the OS image and Version fields show the OS and version it's currently running.
15. I don't see Ubuntu 24.04 in the list, why?
Ubuntu 24.04 is only available for a cluster running Kubernetes v1.33 or later. If your cluster is on an older version, you need to upgrade the Kubernetes version first. This feature is also only available in the HCM 2 region for now.
16. If I enable Auto Patch OS Image, does the Worker Node automatically move to Ubuntu 24.04?
No. Auto Patch OS Image only applies security patches within the same OS version. To switch to a different version, select it from the Version dropdown.
17. Does changing the OS version disrupt my application?
Nodes are replaced one at a time, and Pods on a node being replaced move to another node. An application with multiple replicas and a PodDisruptionBudget usually isn't disrupted. An application with a single replica may be briefly disrupted.
18. Can I roll back to Ubuntu 22.04?
Yes. The system supports both upgrading and downgrading between valid versions, with no limit on how many times.
19. Can I cancel an OS version change while it's running?
No. Once the process starts, it runs until it succeeds or fails. On failure, the Worker Group keeps its previous OS version.
20. Can I change the OS version of several Worker Groups at once?
Yes. On the Worker Group screen, select the version you want for each Worker Group — the change applies as soon as you select it.