From ff93b4398e48e649ddc35b5fad5507654d459db4 Mon Sep 17 00:00:00 2001 From: John Mulhausen Date: Fri, 4 Mar 2016 11:29:36 -0800 Subject: [PATCH] Revamped Reference section with proper landing page --- _data/reference.yml | 50 +++++++++++------------ docs/reference.md | 26 +++++++++++- docs/roadmap.md | 2 +- docs/user-guide/ingress.md | 2 +- docs/user-guide/replication-controller.md | 2 +- 5 files changed, 53 insertions(+), 29 deletions(-) diff --git a/_data/reference.yml b/_data/reference.yml index 0516f033a9..b4ad4acf88 100644 --- a/_data/reference.yml +++ b/_data/reference.yml @@ -20,6 +20,24 @@ toc: - title: Extensions API Definitions path: /docs/api-reference/extensions/v1beta1/definitions/ +- title: kube-apiserver + section: + - title: Overview + path: /docs/admin/kube-apiserver/ + - title: Authorization Plugins + path: /docs/admin/authorization/ + - title: Authentication + path: /docs/admin/authentication/ + - title: Accessing the API + path: /docs/admin/accessing-the-api/ + - title: Admission Controllers + path: /docs/admin/admission-controllers/ + - title: Managing Service Accounts + path: /docs/admin/service-accounts-admin/ + +- title: etcd + path: /docs/admin/etcd/ + - title: kubectl section: - title: kubectl Overview @@ -95,37 +113,19 @@ toc: - title: kubectl version path: /docs/user-guide/kubectl/kubectl_version/ -- title: kube-apiserver - section: - - title: Overview - path: /docs/admin/kube-apiserver/ - - title: Authorization Plugins - path: /docs/admin/authorization/ - - title: Authentication - path: /docs/admin/authentication/ - - title: Accessing the API - path: /docs/admin/accessing-the-api/ - - title: Admission Controllers - path: /docs/admin/admission-controllers/ - - title: Managing Service Accounts - path: /docs/admin/service-accounts-admin/ +- title: JSONpath + path: /docs/user-guide/jsonpath/ + +- title: kube-proxy + path: /docs/admin/kube-proxy/ - title: kub-scheduler path: /docs/admin/kube-scheduler/ - title: kubelet - path: /docs/admin/kubelet.md + path: /docs/admin/kubelet/ -- title: kube-proxy - path: /docs/admin/kube-proxy/ - -- title: JSONpath - path: /docs/user-guide/jsonpath/ - -- title: etcd - path: /docs/admin/etcd/ - -- title: Concept Definitions +- title: Glossary section: - title: Container Environment path: /docs/user-guide/container-environment/ diff --git a/docs/reference.md b/docs/reference.md index 8283b2c785..19a098405e 100644 --- a/docs/reference.md +++ b/docs/reference.md @@ -1,3 +1,27 @@ --- --- -This is the landing page for the reference section. \ No newline at end of file +In the reference section, you can find reference documentation for Kubernetes APIs, CLIs, and tools, as well as our glossary and design docs. + +## API References + +* [Kubernetes API](/docs/api/) - The core API for Kubernetes. +* [Extensions API](/docs/api-reference/extensions/v1beta1/operations/) - Manages extensions resources such as Jobs, Ingress and HorizontalPodAutoscalers. +* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers. +* [etcd](/docs/admin/etcd/) - Highly-available key value store which Kubernetes uses for persistent storage of all of its REST API objects. + + +## CLI References + +* [kubectl](/docs/user-guide/kubectl-overview/) - Runs commands against Kubernetes clusters. + * [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl. +* [kube-proxy](/docs/admin/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of backends. +* [kube-scheduler](/docs/admin/kube-scheduler/) - A policy-rich, topology-aware, workload-specific function that significantly impacts availability, performance, and capacity. +* [kubelet](/docs/admin/kubelet/) - The primary "node agent" that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy. + +## Glossary + +Explore the glossary of essential Kubernetes concepts. Some good starting points are the entries for [Pods](/docs/user-guide/pods/), [Nodes](/docs/user-guide/pods/), [Services](/docs/user-guide/services/), and [Replication Controllers](/docs/user-guide/replication-controller/). + +## Design Docs + +An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md) and [Kubernetes Design Overview](https://github.com/kubernetes/kubernetes/tree/release-1.1/docs/design). \ No newline at end of file diff --git a/docs/roadmap.md b/docs/roadmap.md index 67c8ca45d6..e80294eb42 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -42,7 +42,7 @@ The following features will be part of 1.1 if complete, but will not block the r We're in the process of prioritizing changes to be made after 1.1. -Please watch the [Github milestones] (https://github.com/kubernetes/kubernetes/milestones) for our future plans. +Please watch the [Github milestones](https://github.com/kubernetes/kubernetes/milestones) for our future plans. diff --git a/docs/user-guide/ingress.md b/docs/user-guide/ingress.md index 0f51c041e3..83e53f1615 100644 --- a/docs/user-guide/ingress.md +++ b/docs/user-guide/ingress.md @@ -247,5 +247,5 @@ You can expose a Service in multiple ways that don't directly involve the Ingres * Use [Service.Type=LoadBalancer](https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/services.md#type-loadbalancer) * Use [Service.Type=NodePort](https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/services.md#type-nodeport) -* Use a [Port Proxy] (https://github.com/kubernetes/contrib/tree/master/for-demos/proxy-to-service) +* Use a [Port Proxy](https://github.com/kubernetes/contrib/tree/master/for-demos/proxy-to-service) * Deploy the [Service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). This allows you to share a single IP among multiple Services and achieve more advanced loadbalancing through Service Annotations. \ No newline at end of file diff --git a/docs/user-guide/replication-controller.md b/docs/user-guide/replication-controller.md index 722e0a2d58..ec001fc5a9 100644 --- a/docs/user-guide/replication-controller.md +++ b/docs/user-guide/replication-controller.md @@ -40,7 +40,7 @@ The replication controller simply ensures that the desired number of pods matche The replication controller is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the replication controller. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). -The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Spinnaker] (http://spinnaker.io/) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc. +The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Spinnaker](http://spinnaker.io/) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc. ## Common usage patterns