Skip to main content

Web Service

Web services are continuously running services that handle HTTP-based interactions, such as serving web pages, processing API calls, or managing user authentication. In Kubernetes, each Web Service runs in one or more pods that stay active to respond to external requests at any time.

FAQs​

What is the difference between Public, Private, and Internal service schemas?​

  • Public: Accessible over the internet and is open to anyone.
  • Private: Restricted access, available only when connected to the VPN.
  • Internal: Only accessible within the same Kubernetes cluster and is used for internal communication between services.

How do I set up auto-scaling for my Web Service?​

To enable auto-scaling, you can set the Autoscaling option to enabled and define the Memory Target and CPU Target. These targets determine the resource usage thresholds that trigger auto-scaling. You must also specify the minimum and maximum number of replicas to be maintained when auto-scaling is enabled.

What are the default success codes for a Web Service, and can I change them?​

The default success code is 200, indicating the service is healthy. You can change this code based on your application’s requirements, as some services might return different success codes based on specific actions.

What happens if my health check fails repeatedly?​

If the health check fails consecutively and reaches the Failure Threshold (default is 60), the service is marked as unhealthy, and Kubernetes might restart or terminate the service instance to attempt a recovery.

How can I configure memory and CPU settings for my Web Service?​

You can configure the CPU Min and CPU Max values to set the minimum and maximum CPU resources each instance in your cluster can use. Similarly, you set Memory Min and Memory Max for memory allocation per instance.

What are some best practices when configuring a Web Service in SleakOps?​

  • Always set a minimum of 2 replicas to avoid downtime.
  • Ensure your health check paths and success codes are correctly configured to reflect the true health of your service.
  • Use auto-scaling where possible to optimize resources dynamically based on demand.
  • Review and set memory and CPU usage targets appropriately to prevent overloading your infrastructure.

What should I do if my service shows response times longer than 10 seconds?​

Long response times may indicate issues such as resource constraints, application inefficiencies, or network problems. You should check your service logs, ensure your resources (CPU, memory) are adequately allocated, and review your application code for potential optimizations.

How can I deploy my static web service?​

At the moment, Sleakops doesn’t natively support static sites, but you can still deploy them using the same flow as other sites, by containerizing them with a web server like Nginx. Below is a simple example of a Dockerfile and the corresponding nginx.conf to serve your static content.

FROM node:20.11.0-alpine AS base

WORKDIR /app

FROM base AS build

ARG BACKEND_URL

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm install

COPY . ./

RUN npm run build

FROM nginx:1.25.3-alpine AS production

COPY --from=build /app/config/nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /app/dist /usr/share/nginx/html

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

And here is a sample config/nginx.conf:

server {
    listen 80;

    location = /health {
            access_log off;
            add_header 'Content-Type' 'application/json';
            return 200 '{"status":"OK"}';
    }

    location / {
        root /usr/share/nginx/html;
        index index.html index.htm;
        try_files $uri $uri/ /index.html =404;

        add_header Last-Modified $date_gmt;
        add_header Cache-Control 'no-store, no-cache';
        if_modified_since off;
        expires off;
        etag off;
    }
}

Using this Docker-based approach, you can serve your static site with Nginx, all within a container.

Lets add a Web Service for your Project​

1. Navigate to create Web Service section​

Into the Left Pane, access Workloads. Then select the Web Services tab and then, at the top right corner, click on the Create button.

workloads-list

2. Select a Project and a Name for the web service​

Start with the basic information, complete these attributes and click Next to continue.

AttributeDescription
NameIdentify your web service.
ProjectSelect between the existent projects.
CommandThe command that runs the service.
PortThe port number where the service runs. Default: 8000

Once those attributes are completed, click the Next button to move forward.

webservice-create-p1

3. Define the connection​

Select how will be your connection and click on Next.

AttributeDescription
Service SchemaDefines the accessibility of the service: public, private, or internal.
URLThe URL assigned to the service based on the environment and project settings. Format: name.myenv.sleakops.com.
webservice-create-p2

4. Specify your workload settings​

You’ll see the following for to specify the conditions.

webservice-create-p3
AttributeDescription
PathThe path where Kubernetes checks if the web service is operational. Default: /
Success CodeThe HTTP success code indicating the service’s health. Default: 200.
Initial Delay SecondsNumber of seconds after startup before health checks begin. Default: 10.
Timeout SecondsNumber of seconds after startup before health checks begin. Default: 1.
Period SecondsInterval (in seconds) between each health check probe. Default: 5.
Success ThresholdMinimum number of consecutive successes required for the probe to be considered successful after it has failed. Default: 1.
Failure ThresholdNumber of consecutive failures before the probe is considered to have failed. Default: 60.

Once those attributes are completed, click the Next button to move to the next step.

5. Finish the set up​

This step outlines the key attributes for configuring the resources of a Web Service in SleakOps, allowing for flexible management of CPU, memory, and scaling behaviors.

AttributeDescription
CPU MinThe minimum amount of CPU resources allocated for each instance in the cluster. This ensures that each instance always has this amount of CPU available.
CPU MaxThe maximum CPU resources that each instance in the cluster can use. This cap helps prevent any single instance from consuming too much CPU.
Memory MinThe minimum amount of memory allocated for each instance in the cluster. This guarantees that the instance has enough memory to operate efficiently.
Memory MaxThe maximum amount of memory each instance in the cluster can utilize. It limits the memory usage to prevent any single instance from overconsuming resources.
AutoscalingToggle to enable or disable auto-scaling. When enabled, it allows the service to adjust the number of replicas based on demand and resource usage.
CPU TargetThe CPU usage percentage target that initiates auto-scaling. If usage exceeds this target, additional replicas may be deployed to balance the load.
Memory TargetThe memory usage percentage target that triggers auto-scaling adjustments. When instances exceed this target, the system scales up to accommodate demand.
Replicas MinThe minimum number of replicas to maintain when auto-scaling is active. A minimum of 2 replicas ensures high availability and prevents downtime.
Replicas MaxThe maximum number of replicas that can be deployed when auto-scaling is enabled. It sets an upper limit on the number of instances to avoid over-provisioning.
webservice-create-p4

Submit to create and Deploy your web service.