Adding Dedicated Hosts to launch EC2 instances

Use Dedicated Hosts to launch Amazon EC2 instances and provide additional visibility and control over how EC2 instances are placed on a physical server; enabling you to use the same physical server, if needed.

Prerequisites

Configure the DuploCloud Portal to allow for the creation of Dedicated Hosts.

1. In the DuploCloud Portal, navigate to Administrator -> System Settings.

2. Click the System Config tab.

3. Click Add. The Add Config pane displays.

4. In the Config Type field, select Flags.

5. In the Key field, select Allow Dedicated Host Sharing.

6. In the Value field, select true.

7. Click Submit. The configuration is displayed in the System Config tab.

Creating Dedicated Hosts to launch EC2 instances

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts.

2. In the EC2 tab, click Add. The Add Host page displays.

3. After completing the required fields to configure your Host, select Advanced Options. The advanced options display.

4. In the Dedicated Host ID field, enter the ID of the Dedicated Host. The ID is used to launch a specific instance on a Dedicated Host. See the screenshot below for an example.

5. Click Add. The Dedicated Host is displayed in the EC2 tab.

Viewing Dedicated Hosts to launch EC2 instances

After you create Dedicated Hosts, view them by doing the following:

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts.

2. In the EC2 tab, select the Host from the Name column. The Dedicated Host ID card on the Host page displays the ID of the Dedicated Host.

DuploCloud supports various ways to scale Host workloads, depending on the underlying AWS services being used.

• Autoscaling Groups (ASG)

• ECS Auto Scaling

• Autoscaling in Kubernetes

Once an EC2 Instance is created, you connect it with SSH either by using Session ID or by downloading a key.

Connecting to an EC2 Linux instance using SSH

In the DuploCloud Portal, navigate to Cloud Services -> Hosts and select the host to which you want to connect.

Connect using session ID

After you select the Host, on the Host's page click the Actions menu and select SSH. A new browser tab opens and you can connect your Host using SSH with by session ID. Connection to the host launches in a new browser tab.

Connect by downloading a key

1. After you select the Host, on the Host's page click the Actions menu and select Connect -> Connection Details. The Connection Info for Host window opens. Follow the instructions to connect to the server.

2. Click Download Key.

Disable the option to download the SSH key

If you don't want to display the Download Key button, disable the button's visibility.

1. In the DuploCloud Portal, navigate to Administrator -> System Settings.

2. Click the System Config tab.

3. Click Add. The Add Config pane displays.

4. From the Config Type list box, select Flags.

5. From the Key list box, select Disable SSH Key Download.

6. From the Value list box, select true.

7. Click Submit.

Configuring admin-only access to the SSH key

Configuring the following system setting disables SSH access for read-only users. Once this setting is configured, only administrator-level users can access SSH.

1. From the DuploCloud Portal, navigate to Administrator -> Systems Settings.

2. Select the Settings tab, and click Add. The Update Config Flags pane displays.
3. From the Config Type list box, select Flags.

4. In the Key list box, select Admin Only SSH Key Download.

5. In the Value field list box, select true.

6. Click Submit. The setting is configured and SSH access is limited to administrators only.

DuploCloud AWS supports EC2, ASG, and BYOH (Bring Your Own Host) types. Use BYOH for any VMs that are not EC2 or ASG.

Adding a Host (VM)

1. Ensure you have selected the appropriate Tenant from the Tenant list box at the top of the DuploCloud Portal.

2. In the DuploCloud Portal, navigate to Cloud Services -> Hosts.

3. Click the tab that corresponds to the type of Host you want to create (EC2, ASG, or BYOH).

4. Click Add. The Host that you added is displayed in the appropriate tab (EC2, ASG, or BYOH).

To connect to the Host using SSH, follow this procedure.

Creating Kubernetes StorageClass and PVC constructs in the DuploCloud Portal.

See Kubernetes StorageClass and PVC.

Supported Host Actions

1. From the DuploCloud Portal, navigate to Cloud Services -> Hosts.

2. Select the Host name from the list.

3. From the Actions list box, you can select Connect, Host Settings, or Host State to perform the following supported actions:

Connect:

Host Settings:

Host State:

Adding custom code for EC2 or ASG Hosts

If you add custom code for EC2 or ASG Hosts using the Base64 Data field, your custom code overrides the code needed to start the EC2 or ASG Hosts and the Hosts cannot connect to EKS. Instead, use this procedure to add custom code directly in EKS.

#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh duploinfra-MYINFRA --kubelet-extra-args '--node-labels=tenantname=duploservices-MYTENANT'

# Custom user code:
echo "hello world"

Configure Autoscaling Groups (ASG) to ensure the application load is scaled based on the number of EC2 instances configured. Autoscaling detects unhealthy instances and launches new EC2 instances. ASG is also cost-effective as EC2 Instances are dynamically created per the application requirement within minimum and maximum count limits.

Creating Autoscaling Groups (ASG)

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts.

2. In the ASG tab, click Add. The Add ASG page is displayed.

3. In the Friendly Name field, enter the name of the ASG.

4. Select Availability Zone and Instance Type.

5. In the Instance Count field, enter the desired capacity for the Autoscaling group.

6. In the Minimum Instances field, enter the minimum number of instances. The Autoscaling group ensures that the total number of instances is always greater than or equal to the minimum number of instances.

7. In the Maximum Instances field, enter the maximum number of instances. The Autoscaling group ensures that the total number of instances is always less than or equal to the maximum number of instances.

8. Select Use for Cluster Autoscaling.

9. Select Advanced Options.

10. Select the appropriate Image ID.

11. From the Agent Platform list box, select Linux Docker/Native to run a Docker service or select EKS Linux to run services using EKS. Fill in additional fields as needed for your ASG.

12. Optionally, enable Spot Instances.

13. Optionally, for EKS only, enable Scale from zero.

14. Click Add. Your ASG is added and displayed in the ASG tab.

Viewing Hosts in Autoscaling Groups

View the Hosts created as part of ASG creation from the ASG Hosts tab.

Creating an Amazon EC2 Autoscaling Policy

Refer to AWS Documentation for detailed steps on creating Scaling policies for the Autoscaling Group.

Creating Services using Autoscaling Groups

The DuploCloud Portal provides the ability to configure Services based on the platforms EKS Linux and Linux Docker/Native. Select the ASG based on the platform used when creating services and Autoscaling groups. Optionally, if you previously enabled Spot Instances in the ASG, you can configure the Service to use Spot Instances by selecting Tolerate spot instances.

are spare capacity priced at a significant discount compared to On-Demand Instances. Users specify the maximum price (bid) they will pay per hour for a Spot Instance. The instance is launched if the current Spot price is below the user's bid. Since Spot Instances can be interrupted when spare capacity is unavailable, applications using Spot Instances must be fault-tolerant and able to handle interruptions.

Enabling Spot Instances when Creating Autoscaling Groups

Follow the steps in the section . Before clicking Add, Click the box to access Advanced Options. Enable Use Spot Instances and enter your bid, in dollars, in the Maximum Spot Price field.

Creating Services using Spot Instances

Tolerations will be entered by default in the Add Service page, Advanced Options, Other Container Config field.

ECS Autoscaling has the ability to scale the desired count of tasks for the ECS Service configured in your infrastructure. Average CPU/Memory metrics of your tasks are used to increase/decrease the desired count value.

Step 1: Add Auto-Scaling for Targets

Navigate to Cloud Services -> ECS. Select the ECS Task Definition where Autoscaling needs to be enabled > Add Scaling Target

Set the MinCapacity (minimum value 2) and MaxCapacity to complete the configuration.

Step 2: Add Scaling Policy

Once Autoscaling for Targets is configured, Next we have to add Scaling Policy

Provide details below:

• Policy Name - The name of the scaling policy.

• Policy Dimension - The metric type tracked by the target tracking scaling policy.. Select from the dropdown

• Target Value - The target value for the metric.

• Scalein Cooldown - The amount of time, in seconds, after a scale in activity completes before another scale in activity can start.

• ScaleOut Cooldown -The amount of time, in seconds, after a scale out activity completes before another scale out activity can start.

• Disable ScaleIn - Disabling scale-in makes sure this target tracking scaling policy will never be used to scale in the Autoscaling group

This step creates the target tracking scaling policy and attaches it to the Autoscaling group

Step 3: View Scaling Target and Policy

View the Scaling Target and Policy Details from the DuploCloud Portal. Update and Delete Operations are also supported from this view

Create Virtual Machine (VM) snapshots in the DuploCloud Portal.

Creating a Virtual Machine(VM) Host Snapshot

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts. The Hosts page displays.

2. From the Name column, select the Host you want to backup.

3. Click Actions and select Snapshot.

Using VM Snapshot as an Image for creating a new host

Once you take a VM Snapshot, the snapshot displays as an available Image ID when you create a Host.

can be issued by Kubernetes when a becomes unreachable or not tolerated by certain workloads. As Kubernetes can initiate Taints, you can as well. For example, to isolate a node for the purpose of applying maintenance, such as an upgrade, using the kubectl taint command.

In the DuploCloud Portal, Taints are displayed in the Status column on the EC2 Hosts page.

Displaying Taints in the DuploCloud Portal

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts.

2. In the EC2 tab, check for hosts with a Status of stopped and tainted. If these statuses are present, the connection to the underlying Node is lost and you should take appropriate action to restore the connection. See the for available commands, flags, and examples to resolve the Taint.

You can enable shared Hosts in the DuploCloud Portal. First, configure one Tenant to allow K8s Pods from other Tenants to run on its Host(s). Then, configure another Tenant to run its K8s Pods on Hosts in other Tenants. This allows you to break Tenant boundaries for greater flexibility.

Configuring Tenants to allow Host sharing

Enabling a Tenant to allow Host sharing

1. In the DuploCloud Portal, navigate to Administrator -> Tenant.

2. From the Tenant list, select the name of the Tenant to which the Host is defined.

3. Click the Settings tab.

4. Click Add. The Add Tenant Feature pane displays.

5. From the Select Feature item list, select Allow hosts to run K8S pods from other tenants.

6. Select Enable.
7. Click Add. This Tenant's hosts can now run Pods from other Tenants.

Enabling a Tenant to run Kubernetes Pods on another Tenant's Host

1. In the DuploCloud Portal, navigate to Administrator -> Tenant.

2. From the Tenant list, select the name of the Tenant that will access the other Tenant's Host (the Tenant not associated with a Host).

3. Click the Settings tab.

4. Click Add. The Add Tenant Feature pane displays.

5. From the Select Feature item list, select Enable option to run K8S pods on any host.

6. Select Enable.

7. Click Add. This Tenant can now run Pods on other Tenant's Hosts.

Creating a Service that uses a shared Host

1. From the Tenant list box at the top of the DuploCloud Portal, select the name of the Tenant that will run K8s Pods on the shared Host.

2. In the DuploCloud Portal, navigate to Kubernetes -> Services.

3. In the Services tab, click Add. The Add Service window displays.

4. Fill in the Service Name, Cloud, Platform, and Docker Image fields. Click Next.

1. In the Advanced Options window, from the Run on Any Host item list, select Yes.
2. Click Create. A Service running the shared Host is created.

Once you have the Infrastructure (Networking, Kubernetes cluster, and other standard configurations) and an environment (Tenant) set up, the next step is to launch EC2 virtual machines (VMs). You create VMs to be:

• EKS Worker Nodes

• Worker Nodes (Docker Host), if the built-in container orchestration is used.

You also create VMs if Regular nodes are not part of any container orchestration. For example, a user manually connects and installs apps, as when using Microsoft SQL Server in a VM, Running an IIS application, or such custom use cases.

While all the lower-level details like IAM roles, Security groups, and others are abstracted away from the user (as they are derived from the Tenant), standard application-centric inputs must be provided. This includes a Name, Instance size, Availability Zone choice, Disk size, Image ID, etc. Most of these are optional, and some are published as a list of user-friendly choices by the admin in the plan (Image or AMI ID is one such example). Other than these AWS-centric parameters, there are two DuploCloud platform-specific values to be provided:

Agent Platform: This is applicable if the VM is going to be used as a host for container orchestration by the platform. The choices are:

• EKS Linux: If this is to be added to the EKS cluster. For example, EKS is the chosen approach for container orchestration

• Linux Docker: If this is to be used for hosting Linux containers using the Built-in Container orchestration

• Docker Windows: If this is to be used for hosting Windows containers using the Built-in Container orchestration

• None: If the VM is going to be used for non-Container Orchestration purposes and contents inside the VM will be self-managed by the user

Allocation Tags (Optional): If the VM is being used for containers, you can set a label on it. This label can then be specified during docker app deployment to ensure the application containers are pinned to a specific set of nodes. Thus, you can further split a tenant into separate server pools and deploy applications.

You can create Amazon Machine Images (AMIs) in the DuploCloud Portal. Unlike EC2 Hosts, which are fully dedicated physical servers for launching EC2 instances, AMIs are templates that contain the information required to launch an instance, such as an operating system, application software, and data. EC2 is used for creating a virtual server instance. AMI is the EC2 virtual machine image.

Adding an AMI

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts. The Hosts page displays.

2. Select the Host on which you want to base your AMI from the Name column.

3. Click the Actions menu and select Host Settings -> Create AMI. The Set AMI pane displays.
4. In the AMI Name field, enter the name of the AMI.

5. Click Create.

Viewing an AMI

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts. The Hosts page displays.

2. Select the AMI tab. Your AMIs are displayed on the AMI page. Selecting an AMI from this page displays the Overview and Details tabs for more information.

Disabling Host creation for custom AMIs

You can disable host creation by non-administrators (Users) for custom AMIs by configuring the option in DuploCloud.

Configuring the Disable Host Creation with Custom AMI option

1. In the DuploCloud Portal, navigate to Administrator -> System Settings.

2. Click the System Config tab.

3. Click Add. The Add Config pane displays.

4. In the Config Type list box, select Flags.

5. In the Key list box, select Disable Host Creation with Custom AMI.

6. In the Value list box, select true.

7. Click Submit.

When this setting is configured, the Other option in the Image ID list box in the Add Host page, will be disabled, preventing hosts with custom AMIs from being created.

When you hibernate an instance, Amazon EC2 signals the operating system to perform hibernation (suspend-to-disk). Hibernation saves the contents from the instance memory (RAM) to your Amazon Elastic Block Store (Amazon EBS) root volume. Amazon EC2 persists the instance's EBS root volume and any attached EBS data volumes.

For more information on Hibernation, see the AWS Documentation.

Hibernating an EC2 Host

Prerequisites

Before you can hibernate an EC2 Host in DuploCloud, you must configure the EC2 host at launch to use the Hibernation feature in AWS.

Follow the steps in the AWS documentation before attempting Hibernation of EC2 Host instances with DuploCloud.

After you configure your EC2 hosts for Hibernation in AWS:

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts.

2. In the EC2 tab, select the Host you want to Hibernate.

3. Click the Actions menu, and select Hibernate Host. A confirmation message displays.

1. Click Confirm. On the EC2 tab, the host's status displays as hibernated.

Prerequisites

Before autoscaling can be configured for your Kubernetes service, make sure that:

1. Autoscaling Group (ASG) is setup in the DuploCloud tenant

2. Cluster Autoscaler is enabled for your DuploCloud infrastructure

Kubernetes Horizontal Pod Autoscaler (HPA)

Horizontal Pod Autoscaler (HPA) automatically scales the Deployment and its ReplicaSet. HPA checks the metrics configured in regular intervals and then scales the replicas up or down accordingly.

Configuring Services with HPA

You can configure HPA while creating a Deployment Service from the DuploCloud Portal.

1. In the DuploCloud Portal, navigate Kubernetes -> Services, displaying the Services page.

2. Create a new Service by clicking Add.

3. In Add Service - Basic Options, from the Replication Strategy list box, select Horizontal Pod Scheduler.

4. In the Horizontal Pod Autoscaler Config field, add a sample configuration, as shown below. Update the minimum/maximum Replica Count in the resource attributes, based on your requirements.

5. Click Next to navigate to Advanced Options.

6. In Advanced Options, in the Other Container Config field, ensure your resource attributes, such as Limits and Requests, are set to work with your HPA configuration, as in the example below.
7. At the bottom of the Advanced Options page, click Create.

When your services are running, Replicas: Auto is displayed on the Service page.

Stopping a running Kubernetes service that is using an HPA

If a Kubernetes Service is running with a Horizontal Pod AutoScaler (HPA), you cannot stop the Service by clicking Stop in the service's Actions menu in the DuploCloud Portal.

Instead, do the following to stop the service from running:

1. In the DuploCloud Portal, navigate to Kubernetes -> Containers and select the Service you want to stop.

2. From the Actions menu, select Edit.

3. From the Replication Strategy list box, select Static Count.

4. In the Replicas field, enter 0 (zero).

5. Click Next to navigate to the Advanced Options page.

6. Click Update to update the service.

Allowing real-time alerts for autoscaling Kubernetes nodes

When the Cluster Autoscaler flag is set and a Tenant has one or more ASGs, an unschedulable-pod alert will be delayed by five (5) minutes to allow for autoscaling. You can configure the Infrastructure settings to bypass the delay and send the alerts in real-time.

1. From the DuploCloud portal, navigate to Administrator -> Infrastructure.

2. Click on the Infrastructure you want to configure settings for in the Name list.

3. Select the Settings tab.

4. Click the Add button. The Infra - Set Custom Data pane displays.
5. In the Setting Name list box, select Enables faults prior to autoscaling Kubernetes nodes.

6. Set the Enable toggle switch to enable the setting.

7. Click Set. DuploCloud will now generate faults for unschedulable K8s nodes immediately (before autoscaling).

The AWS Cloudformation template contains a that ensures that an EC2 Host instance is either the source or the destination of any traffic the instance receives. In the DuploCloud Portal, this parameter is specified as true, by default, enabling source and destination checks.

There are times when you may want to override this default behavior, such as when an EC2 instance runs services such as network address translation, routing, or firewalls. To override the default behavior and set the SourceDestCheck parameter to false, use this procedure.

Disable SourceDestCheck in the DuploCloud Portal

Set AWS CloudFormation SourceDestCheck to false for an EC2 Host:

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts.

2. In the EC2 tab, select the Host for which you want to disable SourceDestCheck.

3. Click the Metadata tab.

4. Click Add. The Add Metadata pane displays.

5. In the Key field, enter SourceDestCheck.

6. In the Value field, enter False.

7. Click Create. The Key/Value pair is displayed in the Metadata tab.

DuploCloud allows you to scale to or from zero in Amazon EKS clusters by enabling the Scale from Zero option within the Advanced Options when creating an . This feature intelligently adjusts the number of instances in your cluster, dynamically scaling up when demand increases and down to zero when resources are not in use. Reducing resource allocation during idle periods leads to significant cost savings.

When to Use Scale to Zero

Autoscaling to zero is ideal for Kubernetes workloads that don’t always require 100% availability such as:

Non-Critical Workloads: Batch processing jobs, data analysis tasks, and other non-customer-facing services that can be scaled down to zero during off-peak hours (e.g., nights or weekends).

Dev/Test Environments: Development and testing environments that can be scaled up when developers need them and scaled down when not in use.

Background Jobs: Workloads with background jobs running in Kubernetes that are only needed intermittently, such as those triggered by specific events or scheduled at certain times.

When Autoscaling to Zero Should Not Be Used

Autoscaling to zero is not suitable for all workloads. Avoid using this feature for:

Customer-Facing Applications: Frontend web applications that must always be available should not use autoscaling to zero, as it can cause downtime and negatively impact user experience.

Workloads Outside Kubernetes: If background jobs or other processes are not running in Kubernetes, autoscaling to zero will not apply. Different scaling strategies are required for these environments.

Advantages of Scaling to Zero

Scaling to or from zero with AWS Autoscaling Groups (ASG) offers several advantages depending on the context and requirements of your application:

• Cost Savings: By scaling down to zero instances during periods of low demand, you minimize costs associated with running and maintaining instances. This pay-as-you-go model ensures you only pay for resources when they are actively being used.

• Resource Efficiency: Scaling to zero ensures that resources are not wasted during periods of low demand. By terminating instances when they are not needed, you optimize resource utilization and prevent over-provisioning, leading to improved efficiency and reduced infrastructure costs.

• Flexibility: Scaling to zero provides the flexibility to dynamically adjust your infrastructure in response to changes in workload. It allows you to efficiently allocate resources based on demand, ensuring that your application can scale up or down seamlessly to meet varying levels of traffic.

• Simplified Management: With automatic scaling to zero, you can streamline management tasks associated with provisioning and de-provisioning instances. The ASG handles scaling operations automatically, reducing the need for manual intervention and simplifying infrastructure management.

Advantages of Scaling from Zero

• Rapid Response to Increased Demand: Scaling from zero allows your infrastructure to quickly respond to spikes in traffic or sudden increases in workload. By automatically launching instances as needed, you ensure that your application can handle surges in demand without experiencing performance degradation or downtime.

• Improved Availability: Scaling from zero helps maintain optimal availability and performance for your application by ensuring that sufficient resources are available to handle incoming requests. This proactive approach to scaling helps prevent resource constraints and ensures a consistent user experience even during peak usage periods.

• Enhanced Scalability: Scaling from zero enables your infrastructure to scale out horizontally, adding additional instances as demand grows. This horizontal scalability allows you to seamlessly handle increases in workload and accommodate a growing user base without experiencing bottlenecks or performance issues.

• Elasticity: Scaling from zero provides elasticity to your infrastructure, allowing it to expand and contract based on demand. This elasticity ensures that you can efficiently allocate resources to match changing workload patterns, resulting in optimal resource utilization and cost efficiency.

Configure hosts to be rebooted automatically if the following occurs:

• EC2 Status Check - Applicable for Docker Native and EKS Nodes. The Host is rebooted in the specified interval when a StatusCheck fault is identified.

• Kubernetes (K8s) Nodes are disconnected: Applicable for EKS Nodes only. The Host is rebooted in the specified interval when a Host Disconnected fault is identified.

You can configure host Auto Reboot features for a particular Tenant and for a Host.

Configuring Auto Reboot per Tenant

Use the following procedures to configure Auto Reboot at the Tenant level.

Configuring Auto Reboot for EC2 Status Check per Tenant

Configure the Auto Reboot feature at the Tenant for Docker Native and EKS Node-based Hosts, to reboot when a StatusCheck fault is identified.

1. In the DuploCloud Portal, navigate to Administrator -> Tenant. The Tenant page displays.

2. Select a Tenant with access to the Host for which you want to configure Auto Reboot.

3. Click the Settings tab.

4. Click Add. The Add Tenant Feature pane displays.

5. From the Select Feature list box, select Enable Auto Reboot EC2 status check.

6. In the field below the Select Feature list box, enter the time interval in minutes after which the host automatically reboots after a StatusCheck fault is identified. Enter zero (0) to disable this configuration.

7. Click Add. The configuration is displayed in the Settings tab.

Removing or Editing an Auto Reboot Tenant configuration

Configuring Auto Reboot for Kubernetes (K8s) Node disconnection per Tenant

Configure the Auto Reboot feature at the Tenant for EKS node-based Hosts, to reboot when a Host Disconnected fault is identified.

1. In the DuploCloud Portal, navigate to Administrator -> Tenant. The Tenant page displays.

2. Select a Tenant with access to the Host for which you want to configure Auto Reboot.

3. Click the Settings tab.

4. Click Add. The Add Tenant Feature pane displays.
5. From the Select Feature list box, select Enable Auto Reboot K8s Nodes if disconnected.

6. In the field below the Select Feature list box, enter the time interval in minutes after which the host automatically reboots when a Host Disconnected fault is identified. Enter zero (0) to disable this configuration.

7. Click Add. The configuration is displayed in the Settings tab.

Configuring Auto Reboot per Host

Use the following procedures to configure Auto Reboot at the Host level.

Configuring Auto Reboot for EC2 Status Check per Host

Configure the Auto Reboot feature on the Host level for Docker Native and EKS Node-based Hosts, to reboot when a StatusCheck fault is identified.

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts. The Hosts page displays.

2. Click the appropriate tab for your Host type and select the Host for which you want to configure Auto Reboot.

3. Click the Actions menu and select Host Settings -> Update Auto Reboot Status Check. The Set Auto Reboot Status Check Time pane displays.​

4. In the Auto Reboot Status Check field, enter the time interval in minutes after which the host automatically reboots after a StatusCheck fault is identified. Enter zero (0) to disable this configuration.

5. Click Set.

Configuring Auto Reboot for Kubernetes Node disconnection per Host

Configure the Auto Reboot feature on the Host level for EKS node-based Hosts, to reboot when a Host Disconnected fault is identified.

1. In the DuploCloud Portal, navigate to Cloud Services -> Hosts. The Hosts page displays.

2. Click the appropriate tab for your Host type and select the Host for which you want to configure Auto Reboot.

3. Click the Actions menu and select Host Settings -> Update Auto Reboot Disconnected. The Set Auto Reboot Status Check Time pane displays.​

4. In the Auto Reboot Time field, enter the time interval in minutes after which the host automatically reboots when a Host Disconnected fault is identified. Enter zero (0) to disable this configuration.

5. Click Set.