Revamped Reference section with proper landing page
This commit is contained in:
John Mulhausen
parent
e668a0be11
commit
ff93b4398e
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -1,3 +1,27 @@
|
|||
---
|
||||
---
|
||||
This is the landing page for the reference section.
|
||||
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).
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue