ContainerServiceClient

Name: ContainerServiceClient API
Brand: ContainerServiceClient
Availability: InStock

★ Only Publicly Available OpenAPI DocumentCloud InfrastructureContainer Orchestrationoauth25 EndpointsREST

For Agents

Manage classic Azure Container Service clusters across DC/OS, Kubernetes, and Docker Swarm orchestrators — list, get, create, update, and delete.

Connect the ContainerServiceClient to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the ContainerServiceClient, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with ContainerServiceClient API.

List all classic ACS container service clusters in a subscription or resource group

Get a specific container service cluster by name to inspect orchestrator and agent pool configuration

Create or update a container service cluster with a chosen orchestrator (DC/OS, Kubernetes, or Swarm)

Delete an obsolete classic ACS cluster from a resource group

GET STARTED

Start building with ContainerServiceClient API

Explore with Jentic

View OpenAPI Document

Use for: List all classic Azure Container Service clusters in my subscription, Get the configuration of cluster 'legacy-cluster' in resource group ops-rg, Delete classic ACS cluster 'legacy-cluster' after migration to AKS, Find every container service running DC/OS in my subscription

Not supported: Does not manage AKS clusters, deploy Kubernetes manifests, or run individual containers — use for classic Azure Container Service (pre-AKS) cluster inventory and lifecycle only.

Jentic publishes the only available OpenAPI document for ContainerServiceClient, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for ContainerServiceClient, keeping it validated and agent-ready. The 2017-01-31 Container Service Client manages classic Azure Container Service (ACS) clusters — the pre-AKS managed cluster product that supported DC/OS, Kubernetes, and Docker Swarm orchestrators. Its 5 endpoints cover listing container services in a subscription or resource group, getting a single cluster, and creating, updating, or deleting one. Treat this API as the legacy entry point; new clusters should target AKS via the Container Service (Managed) API.

Use Cases

Patterns agents use ContainerServiceClient API for, with concrete tasks.

★ Audit classic ACS clusters before AKS migration

Teams running pre-AKS Azure Container Service clusters need to know exactly what they have before migrating to AKS. Listing classic container services in each subscription returns orchestrator type (DC/OS, Kubernetes, Swarm), agent pool sizes, and master configuration. The output feeds a migration plan that pairs each legacy cluster with an AKS replacement.

GET /subscriptions/{subscriptionId}/providers/Microsoft.ContainerService/containerServices and emit a CSV of cluster name, orchestrator, and agent pool count.

Inspect a specific cluster's configuration

Operators investigating an incident or planning a change on a classic ACS cluster fetch its full configuration via the per-cluster GET. The response covers orchestrator profile, master and agent pool VM sizes, custom DNS, SSH keys, and provisioning state — enough to reproduce the cluster on AKS with the same shape.

GET /subscriptions/{subscriptionId}/resourceGroups/ops-rg/providers/Microsoft.ContainerService/containerServices/legacy-cluster and return the orchestratorProfile and agentPoolProfiles.

Decommission obsolete clusters

After a successful AKS cutover, the classic ACS cluster needs to be deleted to stop billing for its VMs and storage. Issuing DELETE on the container service tears down the master, agent pools, and associated network resources in a single ARM operation. Operators typically chain this after confirming workloads have been redeployed.

DELETE /subscriptions/{subscriptionId}/resourceGroups/ops-rg/providers/Microsoft.ContainerService/containerServices/legacy-cluster and confirm provisioningState becomes Deleted.

Agent-driven cluster inventory through Jentic

An AI agent integrated through Jentic can walk every subscription, list classic container services, group them by orchestrator type, and emit a migration backlog. Jentic's intent search exposes the right Container Service operation and the AAD token is held in the vault so the agent never sees raw credentials.

Across all subscriptions, list every Microsoft.ContainerService container service and produce a backlog grouped by orchestratorType with each cluster's resourceGroup.

Key Endpoints

5 endpoints — jentic publishes the only available openapi specification for containerserviceclient, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/subscriptions/{subscriptionId}/providers/Microsoft.ContainerService/containerServices

List container services in a subscription

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/containerServices

List container services in a resource group

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/containerServices/{containerServiceName}

Get a single container service by name

GET

/subscriptions/{subscriptionId}/providers/Microsoft.ContainerService/containerServices

List container services in a subscription

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/containerServices

List container services in a resource group

GET

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/containerServices/{containerServiceName}

Get a single container service by name

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Azure AD OAuth tokens for the user_impersonation scope are stored encrypted in the Jentic vault. Agents receive scoped access tokens — refresh tokens never enter the agent's context.

Intent-based discovery

Agents search by intent (for example 'list azure container services' or 'delete legacy acs cluster') and Jentic returns the matching containerServices operation with its full input schema, so the agent doesn't have to navigate Microsoft.ContainerService ARM paths.

Time to first call

Direct integration: 1-2 days for AAD plumbing and per-cluster shape parsing across an estate. Through Jentic: under 1 hour — search, load schema, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

Container Instance Management Client

Serverless container groups for one-shot workloads that don't need a full cluster

Choose Container Instance Management when the workload is short-lived and a managed cluster is overkill

Complementary

Container Registry Management Client

Stores and builds the images that classic ACS clusters pull from

Choose Container Registry Management when the agent needs to inspect or rebuild the images that the legacy cluster runs

Complementary

Compute Management Client

Manages the VMs that back the ACS master and agent pools

Choose Compute Management when the agent needs to inspect or resize the underlying VMs that ACS provisioned

FAQs

Specific to using ContainerServiceClient API through Jentic.

Why is there no official OpenAPI spec for ContainerServiceClient?

Microsoft Azure deprecated the classic ACS surface in favour of AKS and does not publish a maintained OpenAPI specification for the 2017-01-31 Container Service Client. Jentic generates and maintains this spec so that AI agents and developers can call ContainerServiceClient via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the ContainerServiceClient use?

It uses Azure Active Directory OAuth 2.0 with the implicit flow at https://login.microsoftonline.com/common/oauth2/authorize and the user_impersonation scope. The caller needs at least Reader on the subscription to list and Contributor on the resource group to create or delete. Through Jentic the AAD token is held in the encrypted vault.

Can I create new clusters with the ContainerServiceClient?

The 2017-01-31 surface still exposes create-or-update PUT semantics on /providers/Microsoft.ContainerService/containerServices/{name}, but Microsoft has retired classic ACS for new deployments. For new clusters use the AKS-flavoured Container Service Managed Client; use this API only for inventory and decommissioning of existing classic clusters.

What are the rate limits for the ContainerServiceClient?

ARM applies subscription-level read and write throttling (typically 12,000 reads and 1,200 writes per hour per subscription). Classic ACS clusters do not have separate rate-limit headers beyond the standard ARM 429 behaviour.

How do I audit classic ACS clusters through Jentic?

Search Jentic for 'list azure container services', load the schema for GET /subscriptions/{subscriptionId}/providers/Microsoft.ContainerService/containerServices, and execute it. Run pip install jentic to get the SDK and pipe the output into your migration backlog.

Is the ContainerServiceClient free?

Calling the management API itself is free. Costs come from the master and agent pool VMs, attached storage, and load balancers each cluster runs — billing continues until the cluster is deleted.