Extending Kubernetes [page]deterministic

Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or submit patches to the Kubernetes project code.

This guide describes the options for customizing a Kubernetes cluster. It is aimed at [cluster operators](#gloss:cluster-operator) who want to understand how to adapt their Kubernetes cluster to the needs of their work environment. Developers who are prospective [Platform Developers](#gloss:platform-developer) or Kubernetes Project [Contributors](#gloss:contributor) will also find it useful as an introduction to what extension points and patterns exist, and their trade-offs and limitations.

Customization approaches can be broadly divided into [configuration](#configuration), which only involves changing command line arguments, local configuration files, or API resources; and [extensions](#extensions), which involve running additional programs, additional network services, or both. This document is primarily about _extensions_.

## Configuration

*Configuration files* and *command arguments* are documented in the [Reference](/docs/reference/) section of the online documentation, with a page for each binary:

* [`kube-apiserver`](/docs/reference/command-line-tools-reference/kube-apiserver/) * [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/) * [`kube-scheduler`](/docs/reference/command-line-tools-reference/kube-scheduler/) * [`kubelet`](/docs/reference/command-line-tools-reference/kubelet/) * [`kube-proxy`](/docs/reference/command-line-tools-reference/kube-proxy/)

Command arguments and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster operator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.

Built-in *policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs that provide declaratively configured policy settings. APIs are typically usable even with hosted Kubernetes services and with managed Kubernetes installations. The built-in policy APIs follow the same conventions as other Kubernetes resources such as Pods. When you use a policy APIs that is [stable](/docs/reference/using-api/#api-versioning), you benefit from a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, policy APIs are recommended over *configuration files* and *command arguments* where suitable.

## Extensions

Extensions are software components that extend and deeply integrate with Kubernetes. They adapt it to support new types and new kinds of hardware.

Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters come with extensions pre-installed. As a result, most Kubernetes users will not need to install extensions and even fewer users will need to author new ones.

### Extension patterns

Kubernetes is designed to be automated by writing client programs. Any program that reads and/or writes to the Kubernetes API can provide useful automation. *Automation* can run on the cluster or off it. By following the guidance in this doc you can write highly available and robust automation. Automation generally works with any Kubernetes cluster, including hosted clusters and managed installations.

There is a specific pattern for writing client programs that work well with Kubernetes called the [controller](#gloss:controller) pattern. Controllers typically read an object's `.spec`, possibly do things, and then update the object's `.status`.

A controller is a client of the Kubernetes AP …(trimmed)