Using Cloud Resources in AceCloud Hosted Kubernetes

Overview

Your AceCloud Hosted Kubernetes cluster is pre-configured to provision cloud infrastructure for you automatically, using standard Kubernetes objects. There's no need to create load balancers or storage volumes through the AceCloud portal separately you request them through kubectl, and the cluster provisions the underlying infrastructure on your behalf.

All cloud resources provisioned this way nodes, load balancers, and persistent volumes draw from your project's quota, visible on your AceCloud dashboard. Keep this in mind as you scale node groups, provision load balancers, or request storage.

This article covers:

• Exposing a service externally with a Load Balancer, and routing multiple services through an Ingress controller

• Requesting and resizing persistent storage for your workloads

• How cluster autoscaling works

• What you'll need to set up yourself for pod autoscaling (HPA), monitoring, and logging

Load Balancers

No installation is required. Every cluster already has the component needed to provision load balancers through AceCloud's infrastructure.

To expose a workload externally, create a Service of type LoadBalancer:

apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
type: LoadBalancer
selector:
app: my-app
ports:
- port: 80
targetPort: 8080

AceCloud automatically provisions a cloud load balancer for this service. You can check its status with:

kubectl get service my-app

The EXTERNAL-IP column will show <pending> briefly while the load balancer is provisioned, then populate with the address you can use to reach your service.

When you delete the Service, the associated load balancer is deprovisioned no separate cleanup as well is required.

Each LoadBalancer Service provisions a separate cloud load balancer, drawing from your project's quota (see Overview). If you're exposing many services, consider using an Ingress controller instead (see below) to route them through a single load balancer.

Ingress Controller

If you need to route traffic to multiple services through a single load balancer for example, by hostname or URL path use an Ingress resource instead of provisioning a LoadBalancer Service for each one.

An Ingress controller is not installed by default on AceCloud Hosted Kubernetes clusters. You will need to install one yourself then create Ingress resources as usual to route traffic to your services.

Persistent Storage (Persistent Volumes)

The storage driver required to provision cloud storage is also pre-installed, so requesting persistent storage works the same way it would on any standard Kubernetes cluster.

AceCloud currently provisions block storage only, which supports the ReadWriteOnce access mode a volume can be mounted by a single node at a time (multiple pods on that node can still use it). File storage, and its integration with AceCloud Hosted Kubernetes, is under development. If your workload requires a volume that can be mounted read-write across multiple nodes (ReadWriteMany), see Need shared (ReadWriteMany) storage? below.

To request storage for a workload, create a PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-app-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi

This automatically provisions a cloud volume and binds it to your claim, drawing from your project's quota (see Overview).

The default StorageClass: acecloud-block-sc

Every cluster comes with a default StorageClass named acecloud-block-sc, which provisions block storage with a reclaim policy of Delete. If you don't specify a storageClassName in your PersistentVolumeClaim, this is the one that's used automatically so the example above works out of the box, with no setup required.

You can confirm this yourself with:

kubectl get storageclass
acecloud-block-sc 

will be listed and marked as (default).

Default reclaim policy: Delete

Because acecloud-block-sc has a reclaim policy of Delete, deleting a PersistentVolumeClaim also deletes the underlying volume and its data. If you need volumes to persist after their claim is deleted for example, to inspect or reattach the data later create your own StorageClass with a reclaim policy of Retain, using the same provisioner as acecloud-block-sc:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: retain-storage
provisioner:
reclaimPolicy: Retain
volumeBindingMode: Immediate
allowVolumeExpansion: true

Reference it in your PersistentVolumeClaim using storageClassName: retain-storage. To find acecloud-block-sc's provisioner name, run:

kubectl get storageclass acecloud-block-sc -o yaml

With a Retain policy, deleting the PVC leaves the underlying volume in place. You will need to delete it manually once it's no longer needed, to avoid ongoing storage costs.

Need shared (ReadWriteMany) storage?

Block storage cannot be mounted read-write from multiple nodes simultaneously. If your workload requires this for example, several pods on different nodes writing to the same volume we recommend the following approach:

1. Provision an NFS server within the same VPC as your cluster.

2. Install the NFS CSI driver in your cluster.

3. Use the NFS CSI driver's StorageClass to create PersistentVolumeClaims with the ReadWriteMany access mode, backed by your NFS server.

This provides ReadWriteMany support ahead of native file storage integration which is under development.

Cluster Autoscaling

If autoscaling is enabled for your cluster, it automatically adds or removes nodes based on demand:

• When pods cannot be scheduled due to insufficient capacity (they remain in a Pending state), the autoscaler adds nodes to accommodate them.

• When nodes are underutilized and their workloads could be consolidated elsewhere, the autoscaler removes them.

This always occurs within the minimum and maximum node count configured for your node group the cluster will not scale below the minimum or above the maximum, regardless of load. Nodes added by the autoscaler also draw from your project's quota (see Overview), so the effective ceiling is whichever of the two your configured maximum or your remaining quota is reached first.

Note that autoscaling responds to pending pods, not directly to metrics such as CPU or memory usage. If your pods are not requesting more resources than are available, autoscaling will not be triggered even under high load. For that kind of responsiveness at the pod level, see Horizontal Pod Autoscaling below.

Default autoscaler settings

Here's how your node group's autoscaler behaves out of the box:

Setting	What it does	Default
Minimum node count	The smallest your node group will ever shrink to	Set per node group
Maximum node count	The largest your node group will ever grow to	Set per node group
Check frequency	How often the autoscaler looks for pods waiting on capacity	Every 10 seconds
Underused window	How long a node has to sit underused before it's considered for removal	10 minutes
Usage threshold	How empty a node needs to be to count as "underused"	Below 50%
Cooldown after scale-up	How long the autoscaler waits after adding a node before it starts looking to remove one	10 minutes
Keeps nodes running system pods	Won't remove a node if it's running cluster-critical (kube-system) pods	On
Keeps nodes with local storage	Won't remove a node if a pod on it is using emptyDir or hostPath storage	On

You can change the minimum and maximum node count yourself, directly from the AceCloud portal, under your node group's settings.

Everything else in the table above is fixed and can't be changed from the portal. If your workload needs different behavior, raise a support ticket with AceCloud Support describing what you're trying to achieve, and our team will help set up a custom configuration.

Worth knowing: since nodes running system pods or using local storage are protected by default, a node can look idle and still not scale down that's usually why, and it's expected behavior rather than something going wrong.

Horizontal Pod Autoscaling (HPA)

Kubernetes' built-in Horizontal Pod Autoscaler can scale the number of pod replicas for a workload based on observed metrics such as CPU or memory usage. This requires a metrics source, which is not installed by default on AceCloud Hosted Kubernetes clusters you will need to install it yourself before HPA can be used.

Install the standard Kubernetes metrics-server by following the installation instructions in its repository. Once it is running, you can create HorizontalPodAutoscaler resources as usual.

In-Cluster Monitoring and Logging

AceCloud does not currently provide in-cluster monitoring (dashboards, metrics history, or alerting) or centralized logging. If you require either, you can install a stack of your choice:

• For monitoring, kube-prometheus-stack is a common option, bundling Prometheus, Grafana, and Alertmanager together.

• For centralized logging, options such as Loki or an EFK stack (Elasticsearch, Fluentd, Kibana) are commonly used.

Refer to each project's repository for installation instructions.

Summary

Capability	Provided by AceCloud	Draws from project quota	What you need to do
Load balancers	Yes, pre-installed	Yes	Create a Service of type LoadBalancer
Ingress controller	No	No	Install one yourself, such as ingress-nginx
Persistent storage (block, ReadWriteOnce)	Yes, pre-installed	Yes	Create a PersistentVolumeClaim; create a custom StorageClass if you need Retain instead of the default Delete, or allowVolumeExpansion to resize volumes
Shared storage (ReadWriteMany)	Not yet under development	N/A	Provision an NFS server in your VPC and install the NFS CSI driver
Cluster (node) autoscaling	Yes, if enabled on your cluster	Yes	Set appropriate resource requests on your pods so pending pods are detected correctly
Pod autoscaling (HPA)	No	No	Install metrics-server yourself
In-cluster monitoring and logging	No	No	Install a stack yourself, such as kube-prometheus-stack and Loki

Related Articles

Troubleshooting Kubernetes Cluster- Learn how to identify and resolve common issues encountered while managing a Kubernetes cluster.