API Server Communication

kubectl communicates with the Kubernetes API server over HTTPS using REST calls. Understanding this layer helps debug connectivity issues and optimize performance.

REST Calls

Every kubectl command translates to one or more HTTP requests against the API server:

# See the exact HTTP requests kubectl makes
kubectl get pods -v=8 2>&1 | grep -E "GET|POST|PUT|PATCH|DELETE"

# Make raw REST calls directly
kubectl get --raw /api/v1/namespaces/default/pods

# Create a resource via raw API
kubectl get --raw /api/v1/namespaces/default/pods/myapp

# List with label selector
kubectl get --raw "/api/v1/pods?labelSelector=app%3Dmyapp"

HTTP Methods Mapping

Content Negotiation

The API server supports multiple serialization formats. kubectl negotiates the most efficient one:

# See content type in request/response headers
kubectl get pods -v=8 2>&1 | grep -i "content-type"

# JSON (default for human-readable output)
kubectl get pods -o json

# The API server and kubectl also support protobuf
# for more efficient binary serialization
kubectl get pods -v=8 2>&1 | grep "application/vnd.kubernetes.protobuf"

Protobuf

For internal communication, kubectl prefers protobuf over JSON because it is faster to serialize and smaller on the wire:

# kubectl automatically uses protobuf when available
# Verbose output shows the Accept header
kubectl get pods -v=8 2>&1 | grep Accept

# Force JSON response
kubectl get --raw /api/v1/pods | python3 -m json.tool | head -20

Debugging Connectivity

# Test API server connectivity
kubectl cluster-info

# Check authentication
kubectl auth whoami

# Verify TLS certificate
kubectl get --raw /healthz -v=8 2>&1 | grep "TLS"

# Measure API response time
time kubectl get pods > /dev/null

This REST-based architecture means any HTTP client can interact with Kubernetes, not just kubectl.