Revert "Diffs for top-level docs, flown in from master"

This reverts commit 5de1faad02.
This commit is contained in:
John Mulhausen
2016-02-25 16:16:09 -08:00
parent 8ff26badb4
commit f8a5f14a74
4 changed files with 83 additions and 72 deletions
+7 -9
View File
@@ -47,7 +47,7 @@ in more detail in the [API Changes documentation](/{{page.version}}/docs/devel/a
- Support for the overall feature will not be dropped, though details may change.
- The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens,
we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating
API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
API objects. The editing process may require some thought. This may require downtime for appplications that rely on the feature.
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have
multiple clusters which can be upgraded independently, you may be able to relax this restriction.
- **Please do try our beta features and give feedback on them! Once they exit beta, it may not be practical for us to make more changes.**
@@ -68,19 +68,17 @@ Currently there are two API groups in use:
`apiVersion: v1`.
1. the "extensions" group, which is at REST path `/apis/extensions/$VERSION`, and which uses
`apiVersion: extensions/$VERSION` (e.g. currently `apiVersion: extensions/v1beta1`).
This holds types which will probably move to another API group eventually.
1. the "componentconfig" and "metrics" API groups.
In the future we expect that there will be more API groups, all at REST path `/apis/$API_GROUP` and
using `apiVersion: $API_GROUP/$VERSION`. We expect that there will be a way for [third parties to
create their own API groups](design/extending-api.md), and to avoid naming collisions.
using `apiVersion: $API_GROUP/$VERSION`. We expect that there will be a way for (third parties to
create their own API groups](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/extending-api.md), and to avoid naming collisions.
## Enabling resources in the extensions group
DaemonSets, Deployments, HorizontalPodAutoscalers, Ingress, Jobs and ReplicaSets are enabled by default.
Jobs, Ingress and HorizontalPodAutoscalers are enabled by default.
Other extensions resources can be enabled by setting runtime-config on
apiserver. runtime-config accepts comma separated values. For ex: to disable deployments and jobs, set
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/jobs=false`
apiserver. runtime-config accepts comma separated values. For ex: to enable deployments and disable jobs, set
`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/jobs=false`
## v1beta1, v1beta2, and v1beta3 are deprecated; please move to v1 ASAP
@@ -88,7 +86,7 @@ As of June 4, 2015, the Kubernetes v1 API has been enabled by default. The v1bet
### v1 conversion tips (from v1beta3)
We're working to convert all documentation and examples to v1. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec.
We're working to convert all documentation and examples to v1. A simple [API conversion tool](/{{page.version}}/docs/admin/cluster-management/#switching-your-config-files-to-a-new-api-version) has been written to simplify the translation process. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec.
Changes to services are the most significant difference between v1beta3 and v1.