Skip to main content

Kubernetes API and Section

Section allows you to use standard Kubernetes tooling to deploy applications to Section's Distributed Platform.

For more information about Kuberbetes please refer to the Kubernetes Documentation.

Using the Kubernetes API with Section allows you to implement important Kubernetes Resources that are supported by Section.

What can you use the Kubernetes API to do with Section?

Once you've created a containerized application, you can use the Kubernetes API to do the following on the Section platform:

  • Deploy your container to multiple locations
  • Configure service discovery, so that your users will be routed to the best container instance
  • Define more complex applications, such as composite applications that consist of more than one container
  • Define the resource allocations for your system
  • Define scaling factors, such as the number of containers per location, and what signals should be used to scale in and out
  • Maintain your application code, configuration and deployment manifests in your own code management systems and image registries
  • Control how the Adaptive Edge Engine schedules containers, performs health management, and routes traffic

How can you use the Kubernetes API with Section?

Because Section is compatible with the Kubernetes API, you can use standard Kubernetes tools to interact with the system.

The most common tool is kubectl, which is the tool that this documentation is centered around.

When you use kubectl you will create a configuration context, which will connect your tool to Section. From there you can continue to use kubectl as you normally would with a single cluster.

As Section is Kubenetes API compatible, you'll find that many existing tools work without complication. For example, you could use helm to manage your system.

Check out Getting started with Kubernetes API for a step-by-step guide.

What Kubernetes resources are supported by Section?

In your manifests you can use the following Kubernetes Resources

  • Deployment
  • ConfigMap
  • Secret
  • Service (ClusterIP and ExternalName, but not types NodePort nor LoadBalancer)
  • HorizontalPodAutoscaler (example)

Section will create and manage the following resources for you, i.e. you cannot create them yourself:

  • Namespace
  • NetworkPolicy
  • ReplicaSet
  • Pod

For specification of location strategies, Section recognizes a particular ConfigMap resource with a specific name of location-optimizer.

For engaging Section's HTTP Ingress, Section recognizes a particular Service resource with a specific name of ingress-upstream.

Container Resources

When you define your Deployment objects, you can specify the CPU and RAM requests or limits for each container instance.

Use the standard Kubernetes methods for specifying your container's requirements.

Some notes:

  • Please refer to the product pricing information to understand how your requests can impact your billing.
  • Section may alter your YAML to ensure that request = limit.
    • If request and limit are not equal, Section will use the higher of the two values.
    • If only one of request or limit is specified, that value will be used for both request and limit.
  • You cannot request ephemeral storage directly. Section will automatically apply the ephemeral storage limits when the deployment is created.

What storage systems are available for Section workloads?

Section only supports ephemeral storage.

Section will automatically apply ephemeral storage limits to your containers based on the container size you've selected.

Your application can use the ephemeral storage in its local filesystem to perform disk IO activities.

"Ephemeral" means that there is no long-term guarantee about durability. You should take this into consideration in your application design.