Role of kube-apiserver

The Kubernetes API-Server (kube-apiserver, apiserver) is at the heart of a Kubernetes cluster.
Generally, components connect to apiserver, not the other way around.
This is also true for Kubernetes control plane components, such as controller-manager and scheduler.

Exceptions are:

  • Custom webhooks for admission requests (ValidatingWebhookConfiguration, MutatingWebhookConfiguration)
    • Here, apiserver will connect to endpoints in the cluster (e.g. a Service) or even an external address.
  • Requests, where apiserver creates a tunnel to a Pod (kubectl exec | logs | port-forward | cp | attach | debug)
    • For this, apiserver directly issues an RPC at the Kubelet endpoint of a node. See Konnectivity for details.

Where is my cluster's apiserver?

MetaKube fully manages the control plane components, including apiserver.
Apiserver runs replicated in SysEleven managed infrastructure (hint: we're using Kubernetes under the hood ourselves).


  • There's a dedicated address (host + port) for each MetaKube cluster's apiserver endpoint, e.g. https://a1b2c3d4e5.fes1.metakube.syseleven.de:31234.
  • You can find the address of your cluster in the kubeconfig.

In your cluster you can alternatively use the Service kubernetes in the default namespace.
Valid addresses are kubernetes.svc.cluster.local or the Service's ClusterIP which is always the first IP in the service subnet (default
The external address is the only endpoint of the Service.

Network topology

  • Your cluster nodes (or Pods) connect to apiserver over the internet.
  • Apiserver connects to your cluster via Konnectivity.

Known issues

  • We continuously deploy updates, move the apiserver instances or resize them, so when you have a watch request running, it may get cancelled.
    Most libraries or frameworks (e.g. controller runtime) backing Kubernetes applications such as operators automatically retry the watch.
  • Connections to apiserver from SysEleven Stack datacenters dbl or cbk are subject to the known network problem with our Cloud's SDN Midonet.
    This only affects connections staying idle for more than 60 seconds.
    The Go library client-go which most operators use, sends pings over http which resets idle timers on the connections.
    Other implementations might not implement such behavior. Connections may then be reset.