From a326f8ff17b3d4a3d150587660cb87fdf0d24825 Mon Sep 17 00:00:00 2001 From: Wendy Shaffer Date: Sun, 14 May 2017 15:49:45 -0700 Subject: [PATCH] Write the Docs: Adding template and editing --- docs/concepts/overview/components.md | 118 +++++++++++---------------- 1 file changed, 49 insertions(+), 69 deletions(-) diff --git a/docs/concepts/overview/components.md b/docs/concepts/overview/components.md index 6e7f78ed3c..b0bf493545 100644 --- a/docs/concepts/overview/components.md +++ b/docs/concepts/overview/components.md @@ -6,72 +6,56 @@ redirect_from: - "/docs/admin/cluster-components/" - "/docs/admin/cluster-components.html" --- - -This document outlines the various binary components that need to run to +{% capture overview %} +This document outlines the various binary components needed to deliver a functioning Kubernetes cluster. +{% endcapture %} +{% capture body %} ## Master Components -Master components are those that provide the cluster's control plane. For -example, master components are responsible for making global decisions about the -cluster (e.g., scheduling), and detecting and responding to cluster events -(e.g., starting up a new pod when a replication controller's 'replicas' field is -unsatisfied). +Master components provide the cluster's control plane. Master components make global decisions about the +cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller's 'replicas' field is unsatisfied. -In theory, Master components can be run on any node in the cluster. However, -for simplicity, current set up scripts typically start all master components on -the same VM, and does not run user containers on this VM. See +Master components can be run on any node in the cluster. However, +for simplicity, set up scripts typically start all master components on +the same VM, and do not run user containers on this VM. See [Building High-Availability Clusters](/docs/admin/high-availability) for an example multi-master-VM setup. - -Even in the future, when Kubernetes is fully self-hosting, it will probably be -wise to only allow master components to schedule on a subset of nodes, to limit -co-running with user-run pods, reducing the possible scope of a -node-compromising security exploit. - ### kube-apiserver -[kube-apiserver](/docs/admin/kube-apiserver) exposes the Kubernetes API; it is the front-end for the -Kubernetes control plane. It is designed to scale horizontally (i.e., one scales -it by running more of them-- [Building High-Availability Clusters](/docs/admin/high-availability)). +[kube-apiserver](/docs/admin/kube-apiserver) exposes the Kubernetes API. It is the front-end for the +Kubernetes control plane. It is designed to scale horizontally -- that is, it scales by deploying more instances. See [Building High-Availability Clusters](/docs/admin/high-availability). ### etcd -[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. -Proper administration of a Kubernetes cluster includes a backup plan for etcd's -data. +[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster. ### kube-controller-manager -[kube-controller-manager](/docs/admin/kube-controller-manager) is a binary that runs controllers, which are the -background threads that handle routine tasks in the cluster. Logically, each -controller is a separate process, but to reduce the number of moving pieces in -the system, they are all compiled into a single binary and run in a single -process. +[kube-controller-manager](/docs/admin/kube-controller-manager) runs controllers, which are the background threads that handle routine tasks in the cluster. Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process. These controllers include: -* Node Controller: Responsible for noticing & responding when nodes go down. -* Replication Controller: Responsible for maintaining the correct number of pods for every replication + * Node Controller: Responsible for noticing and responding when nodes go down. + * Replication Controller: Responsible for maintaining the correct number of pods for every replication controller object in the system. -* Endpoints Controller: Populates the Endpoints object (i.e., join Services & Pods). -* Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces. -* ... and others. - + * Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods). + * Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces. + ### cloud-controller-manager -`cloud-controller-manager` is a binary that runs controllers that interact with the underlying cloud providers. The `cloud-controller-manager` binary is an alpha feature introduced in Kubernetes release 1.6. +cloud-controller-manager runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6. -`cloud-controller-manager` runs cloud provider-specific controller loops only. As such, you must disable these controller loops in the `kube-controller-manager`. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager. +cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager. -`cloud-controller-manager` allows cloud vendors and kubernetes core to evolve independent of each other. In prior releases, the core Kubernetes code was dependent upon cloud provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to `cloud-controller-manager` while running Kubernetes. +cloud-controller-manager allows cloud vendors code and the Kubernetes core to evolve independent of each other. In prior releases, the core Kubernetes code was dependent upon cloud-provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to cloud-controller-manager while running Kubernetes. The following controllers have cloud provider dependencies: -* Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding -* Route Controller: For setting up routes in the underlying cloud infrastructure -* Service Controller: For creating, updating and deleting cloud provider load balancers -* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider - to orchestrate volumes + * Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding + * Route Controller: For setting up routes in the underlying cloud infrastructure + * Service Controller: For creating, updating and deleting cloud provider load balancers + * Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes ### kube-scheduler @@ -81,27 +65,23 @@ selects a node for them to run on. ### addons Addons are pods and services that implement cluster features. The pods may be managed -by Deployments, ReplicationContollers, etc. Namespaced addon objects are created in -the "kube-system" namespace. +by Deployments, ReplicationControllers, and so on. Namespaced addon objects are created in +the `kube-system` namespace. -Addon manager takes the responsibility for creating and maintaining addon resources. -See [here](http://releases.k8s.io/HEAD/cluster/addons) for more details. +Addon manager creates and maintains addon resources. See [here](http://releases.k8s.io/HEAD/cluster/addons) for more details. #### DNS -While the other addons are not strictly required, all Kubernetes -clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it. +While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it. -Cluster DNS is a DNS server, in addition to the other DNS server(s) in your -environment, which serves DNS records for Kubernetes services. +Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services. -Containers started by Kubernetes automatically include this DNS server -in their DNS searches. +Containers started by Kubernetes automatically include this DNS server in their DNS searches. #### User interface -The kube-ui provides a read-only overview of the cluster state. Access -[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +The kube-ui provides a read-only overview of the cluster state. For more information, see [Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) + #### Container Resource Monitoring @@ -115,41 +95,41 @@ saving container logs to a central log store with search/browsing interface. ## Node components -Node components run on every node, maintaining running pods and providing them -the Kubernetes runtime environment. +Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment. ### kubelet -[kubelet](/docs/admin/kubelet) is the primary node agent. It: +[kubelet](/docs/admin/kubelet) is the primary node agent. It watches for pods that have been assigned to its node (either by apiserver or via local configuration file) and: -* Watches for pods that have been assigned to its node (either by apiserver - or via local configuration file) and: -* Mounts the pod's required volumes -* Downloads the pod's secrets -* Runs the pod's containers via docker (or, experimentally, rkt). -* Periodically executes any requested container liveness probes. -* Reports the status of the pod back to the rest of the system, by creating a - "mirror pod" if necessary. -* Reports the status of the node back to the rest of the system. + * Mounts the pod's required volumes. + * Downloads the pod's secrets. + * Runs the pod's containers via docker (or, experimentally, rkt). + * Periodically executes any requested container liveness probes. + * Reports the status of the pod back to the rest of the system, by creating a *mirror pod* if necessary. + * Reports the status of the node back to the rest of the system. ### kube-proxy [kube-proxy](/docs/admin/kube-proxy) enables the Kubernetes service abstraction by maintaining network rules on the host and performing connection forwarding. + ### docker -`docker` is of course used for actually running containers. +docker is used for running containers. ### rkt -`rkt` is supported experimentally as an alternative to docker. +rkt is supported experimentally for running containers as an alternative to docker. ### supervisord -`supervisord` is a lightweight process babysitting system for keeping kubelet and docker +supervisord is a lightweight process monitoring and control system that can be used to keeo kubelet and docker running. ### fluentd -`fluentd` is a daemon which helps provide [cluster-level logging](#cluster-level-logging). +fluentd is a daemon which helps provide [cluster-level logging](#cluster-level-logging). +{% endcapture %} + +{% include templates/concept.md %}