Virtual Kubernetes (vK8s) API Compatability

Objective

In this document, you’ll get details about Virtual Kubernetes (vK8s) APIs supported in this release.
Further details can be found here at Virtual Kubernetes (vk8s) under VES concepts.

Volterra vK8s APIs

Volterra supports a Kubernetes compatible API for centralized orchestration of applications across a fleet of sites (customer sites or Volterra Regional Edge). This API is “Kubernetes compatible” because not all Kubernetes APIs or resources are supported. However, for the API(s) that are supported, it is hundred percent compatible. We have implemented a distributed control plane within our global infrastructure to manage scheduling and scaling of applications across multiple (tens to hundreds of thousands of) sites, where each site in itself is also a Volterra managed physical K8s cluster.

Further details can be found here at Virtual Kubernetes (vk8s) under VES concepts.

Workload APIs

Deployment v1 APPs

A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

Write Operations

Create POST /apis/apps/v1/namespaces/{namespace}/deployments
Patch PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}
Replace PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}
Delete DELETE /apis/apps/v1/namespaces/{namespace}/deployments/{name}
Delete Collection DELETE /apis/apps/v1/namespaces/{namespace}/deployments

Read Operations

Read GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
List GET /apis/apps/v1/namespaces/{namespace}/deployments
Watch GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name}
Watch List GET /apis/apps/v1/watch/namespaces/{namespace}/deployments

Status Operations

Read Status GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

Misc Operations

Read Scale GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}/scale

Job v1 batch

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot

Write Operations

Create POST /apis/batch/v1/namespaces/{namespace}/jobs
Patch PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}
Replace PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}
Delete DELETE /apis/batch/v1/namespaces/{namespace}/jobs/{name}
Delete Collection DELETE /apis/batch/v1/namespaces/{namespace}/jobs

Read Operations

Read GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}
List GET /apis/batch/v1/namespaces/{namespace}/jobs
Watch GET /apis/batch/v1/watch/namespaces/{namespace}/jobs/{name}
Watch List GET /apis/batch/v1/watch/namespaces/{namespace}/jobs

Status Operations

Read Status GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status

Pod v1 Core

A Pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers. A Pod’s contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific “logical host” - it contains one or more application containers which are relatively tightly coupled — in a pre-container world, being executed on the same physical or virtual machine would mean being executed on the same logical host.

Read Operations

Read GET /api/v1/namespaces/{namespace}/pods/{name}
List GET /api/v1/namespaces/{namespace}/pods
Watch GET /api/v1/watch/namespaces/{namespace}/pods/{name}
Watch List GET /api/v1/watch/namespaces/{namespace}/pods

Status Operations

Read Status GET /api/v1/namespaces/{namespace}/pods/{name}/status

Misc Operations

Read Log GET /api/v1/namespaces/{namespace}/pods/{name}/log

Proxy Operations

Create Connect Portforward POST /api/v1/namespaces/{namespace}/pods/{name}/portforward
Get Connect Portforward GET /api/v1/namespaces/{namespace}/pods/{name}/portforward
Create Connect Exec POST /api/v1/namespaces/{namespace}/pods/{name}/exec
Get Connect Exec GET /api/v1/namespaces/{namespace}/pods/{name}/exec

ReplicaSet v1 Apps

A ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.

Read Operations

Read GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}
List GET /apis/apps/v1/namespaces/{namespace}/replicasets
Watch GET /apis/apps/v1/watch/namespaces/{namespace}/replicasets/{name}
Watch List GET /apis/apps/v1/watch/namespaces/{namespace}/replicasets

Status Operations

Read Status GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status

Misc Operations

Read Scale GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/scale

StatefulSet v1 Apps (Roadmap)

StatefulSet is the workload API object used to manage stateful applications.Manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods.Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

Write Operations

Create POST /apis/apps/v1/namespaces/{namespace}/statefulsets
Patch PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}
Replace PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}
Delete DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}
Delete Collection DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets

Read Operations

Read GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}
List GET /apis/apps/v1/namespaces/{namespace}/statefulsets
Watch GET /apis/apps/v1/watch/namespaces/{namespace}/statefulsets/{name}
Watch List GET /apis/apps/v1/watch/namespaces/{namespace}/statefulsets

Status Operations

Read Status GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status

Misc Operations

Read Scale GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale

Service APIs

Service v1 Core

An abstract way to expose an application running on a set of Pods as a network service. With Kubernetes you don’t need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.

Write Operations

Create POST /api/v1/namespaces/{namespace}/services
Patch PATCH /api/v1/namespaces/{namespace}/services/{name}
Replace PUT /api/v1/namespaces/{namespace}/services/{name}
Delete DELETE /api/v1/namespaces/{namespace}/services/{name}

Read Operations

Read GET /api/v1/namespaces/{namespace}/services/{name}
List GET /api/v1/namespaces/{namespace}/services
Watch GET /api/v1/watch/namespaces/{namespace}/services/{name}
Watch List GET /api/v1/watch/namespaces/{namespace}/services

Status Operations

Read Status GET /api/v1/namespaces/{namespace}/services/{name}/status

Endpoints v1 Core

Endpoints track the IP Addresses of the objects the service send traffic to. When a service selector matches a pod label, that IP Address is added to your endpoints.

Read Operations

Read GET /api/v1/namespaces/{namespace}/endpoints/{name}
List GET /api/v1/namespaces/{namespace}/endpoints
Watch GET /api/v1/watch/namespaces/{namespace}/endpoints/{name}
Watch List GET /api/v1/watch/namespaces/{namespace}/endpoints

Config and Storage APIs

Secret v1 Core

Kubernetes secret objects let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Putting this information in a secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image. See Secrets design document for more information.

Write Operations

Create POST /api/v1/namespaces/{namespace}/secrets
Patch PATCH /api/v1/namespaces/{namespace}/secrets/{name}
Replace PUT /api/v1/namespaces/{namespace}/secrets/{name}
Delete DELETE /api/v1/namespaces/{namespace}/secrets/{name}
Delete Collection DELETE /api/v1/namespaces/{namespace}/secrets

Read Operations

Read GET /api/v1/namespaces/{namespace}/secrets/{name}
List GET /api/v1/namespaces/{namespace}/secrets
Watch GET /api/v1/watch/namespaces/{namespace}/secrets/{name}
Watch List GET /api/v1/watch/namespaces/{namespace}/secrets

ConfigMap v1 Core

ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.

Write Operations

Create POST /api/v1/namespaces/{namespace}/configmaps
Patch PATCH /api/v1/namespaces/{namespace}/configmaps/{name}
Replace PUT /api/v1/namespaces/{namespace}/configmaps/{name}
Delete DELETE /api/v1/namespaces/{namespace}/configmaps/{name}
Delete Collection DELETE /api/v1/namespaces/{namespace}/configmaps

Read Operations

Read GET /api/v1/namespaces/{namespace}/configmaps/{name}
List GET /api/v1/namespaces/{namespace}/configmaps
Watch GET /api/v1/watch/namespaces/{namespace}/configmaps/{name}
Watch List GET /api/v1/watch/namespaces/{namespace}/configmaps

PersistentVolumeClaim v1 Core (Roadmap)

Managing storage is a distinct problem from managing compute. The PersistentVolume subsystem provides an API for users and administrators that abstracts the details of how storage is provided from how it is consumed. To do this, K8s introduce two new API resources: PersistentVolume and PersistentVolumeClaim.

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).

Write Operations

Create POST /api/v1/namespaces/{namespace}/persistentvolumeclaims
Patch PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}
Replace PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}
Delete DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}
Delete Collection DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims

Read Operations

Read GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}
List GET /api/v1/namespaces/{namespace}/persistentvolumeclaims
Watch GET /api/v1/watch/namespaces/{namespace}/persistentvolumeclaims/{name}
Watch List GET /api/v1/watch/namespaces/{namespace}/persistentvolumeclaims

Cluster APIs

Node v1 Core

A node is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster. Each node contains the services necessary to run pods and is managed by the master components. The services on a node include the container runtime, kubelet and kube-proxy.

Read Operations

Read GET /api/v1/nodes/{name}
List GET /api/v1/nodes
Watch GET /api/v1/watch/nodes/{name}
Watch List GET /api/v1/watch/nodes

Status Operations

Read Status GET /api/v1/nodes/{name}/status

Namespace v1 Core

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.

Read Operations

Read GET /api/v1/namespaces/{name}
List GET /api/v1/namespaces
Watch GET /api/v1/watch/namespaces/{name}
Watch List GET /api/v1/watch/namespaces

PersistentVolume v1 Core (Roadmap)

Managing storage is a distinct problem from managing compute. The PersistentVolume subsystem provides an API for users and administrators that abstracts the details of how storage is provided from how it is consumed. To do this, K8s introduce two new API resources: PersistentVolume and PersistentVolumeClaim.

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).

Read Operations

Read GET /api/v1/persistentvolumes/{name}
List GET /api/v1/persistentvolumes
Watch GET /api/v1/watch/persistentvolumes/{name}
Watch List GET /api/v1/watch/persistentvolumes

Status Operations
Read Status GET /api/v1/persistentvolumes/{name}/status


Concepts


Kubernetes References