> For the complete documentation index, see [llms.txt](https://docs.acecloud.ai/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.acecloud.ai/knowledge-base/kubernetes-hosted/using-cloud-resources-in-acecloud-hosted-kubernetes.md). # 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 `` 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](https://github.com/kubernetes-csi/csi-driver-nfs) 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](https://github.com/kubernetes-sigs/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](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) is a common option, bundling Prometheus, Grafana, and Alertmanager together. * For centralized logging, options such as [Loki](https://github.com/grafana/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](https://docs.acecloud.ai/knowledge-base/kubernetes-hosted/troubleshooting-kubernetes-cluster)- Learn how to identify and resolve common issues encountered while managing a Kubernetes cluster.