kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

move access/auth content to reference folder, add TOC (#8624)

pull/8428/merge
Jennifer Rondeau 2018-05-23 13:58:32 -04:00 committed by k8s-ci-robot
parent f4158d642b
commit 1f557bde2c
24 changed files with 51 additions and 489 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
content/en/docs/reference/access-authn-authz/_index.md Normal file
View File

@ -0,0 +1,5 @@
---
title: Accessing the API
weight: 20
toc-hide: true
---

3
content/en/docs/admin/authorization/abac.md → content/en/docs/reference/access-authn-authz/abac.md
View File

@ -4,8 +4,9 @@ reviewers:
- lavalamp
- deads2k
- liggitt
title: ABAC Mode
title: Using ABAC Authorization
content_template: templates/concept
weight: 80
---
{{% capture overview %}}

1
content/en/docs/admin/admission-controllers.md → content/en/docs/reference/access-authn-authz/admission-controllers.md
View File

@ -7,6 +7,7 @@ reviewers:
- janetkuo
- thockin
title: Using Admission Controllers
weight: 30
---
{{< toc >}}

1
content/en/docs/admin/authentication.md → content/en/docs/reference/access-authn-authz/authentication.md
View File

@ -6,6 +6,7 @@ reviewers:
- deads2k
- liggitt
title: Authenticating
weight: 10
---
{{< toc >}}

3
content/en/docs/admin/authorization/_index.md → content/en/docs/reference/access-authn-authz/authorization.md
View File

@ -4,8 +4,9 @@ reviewers:
- lavalamp
- deads2k
- liggitt
title: Overview
title: Authorization Overview
content_template: templates/concept
weight: 60
---
{{% capture overview %}}

1
content/en/docs/admin/bootstrap-tokens.md → content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
View File

@ -2,6 +2,7 @@
reviewers:
- jbeda
title: Authenticating with Bootstrap Tokens
weight: 20
---
{{< toc >}}

1
content/en/docs/admin/accessing-the-api.md → content/en/docs/reference/access-authn-authz/controlling-access.md
View File

@ -4,6 +4,7 @@ reviewers:
- erictune
- lavalamp
title: Controlling Access to the Kubernetes API
weight: 5
---
Users [access the API](docs/tasks/access-application-cluster/access-cluster/) using `kubectl`,

1
content/en/docs/admin/extensible-admission-controllers.md → content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
View File

@ -6,6 +6,7 @@ reviewers:
- caesarxuchao
- deads2k
title: Dynamic Admission Control
weight: 40
---
{{< toc >}}

1
content/en/docs/admin/authorization/node.md → content/en/docs/reference/access-authn-authz/node.md
View File

@ -5,6 +5,7 @@ reviewers:
- liggitt
- ericchiang
title: Using Node Authorization
weight: 90
---
{{< toc >}}

1
content/en/docs/admin/authorization/rbac.md → content/en/docs/reference/access-authn-authz/rbac.md
View File

@ -4,6 +4,7 @@ reviewers:
- deads2k
- liggitt
title: Using RBAC Authorization
weight: 70
---
{{< toc >}}

1
content/en/docs/admin/service-accounts-admin.md → content/en/docs/reference/access-authn-authz/service-accounts-admin.md
View File

@ -5,6 +5,7 @@ reviewers:
- lavalamp
- liggitt
title: Managing Service Accounts
weight: 50
---
*This is a Cluster Administrator guide to service accounts. It assumes knowledge of

1
content/en/docs/admin/authorization/webhook.md → content/en/docs/reference/access-authn-authz/webhook.md
View File

@ -6,6 +6,7 @@ reviewers:
- liggitt
title: Webhook Mode
content_template: templates/concept
weight: 95
---
{{% capture overview %}}

226
content/en/docs/reference/feature-gates.md
View File

@ -1,226 +0,0 @@
---
title: Feature Gates
content_template: templates/concept
---
{{% capture overview %}}
This page contains an overview of the various feature gates an administrator
can specify on different Kubernetes components.
{{% /capture %}}
{{% capture body %}}
## Overview
Feature gates are a set of key=value pairs that describe alpha or experimental
features.
An administrator can use the `--feature-gates` command line flag on each component
to turn a feature on or off.
The following table is a summary of the feature gates that you can set on
different Kubernetes components.
- The "Since" column contains the Kubernetes release when a feature is introduced
or its release stage is changed.
- The "Until" column, if not empty, contains the last Kubernetes release in which
you can still use a feature gate.
| Feature | Default | Stage | Since | Until |
|---------|---------|-------|-------|-------|
| `Accelerators` | `false` | Alpha | 1.6 | 1.10 |
| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 |
| `AdvancedAuditing` | `true` | Beta | 1.8 | |
| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 |
| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | |
| `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
| `APIListChunking` | `true` | Beta | 1.9 | |
| `APIResponseCompression` | `false` | Alpha | 1.7 | |
| `AppArmor` | `true` | Beta | 1.4 | |
| `BlockVolume` | `false` | Alpha | 1.9 | |
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
| `CPUManager` | `true` | Beta | 1.10 | |
| `CRIContainerLogRotation` | `false` | Alpha | 1.10 | |
| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
| `CSIPersistentVolume` | `true` | Beta | 1.10 | |
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
| `CustomPodDNS` | `true` | Beta| 1.10 | |
| `CustomResourceSubresources` | `false` | Alpha | 1.10 | |
| `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 |
| `CustomResourceValidation` | `true` | Beta | 1.9 | |
| `DebugContainers` | `false` | Alpha | 1.10 | |
| `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
| `DevicePlugins` | `true` | Beta | 1.10 | |
| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | |
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | |
| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | |
| `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.8 |
| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | |
| `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | |
| `HugePages` | `false` | Alpha | 1.8 | 1.9 |
| `HugePages` | `true` | Beta| 1.10 | |
| `HyperVContainer` | `false` | Alpha | 1.10 | |
| `Initializers` | `false` | Alpha | 1.7 | |
| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | |
| `MountContainers` | `false` | Alpha | 1.9 | |
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
| `MountPropagation` | `true` | Beta | 1.10 | |
| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
| `PersistentLocalVolumes` | `true` | Beta | 1.10 | |
| `PodPriority` | `false` | Alpha | 1.8 | |
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | |
| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
| `ReadOnlyAPIDataVolumes` | `true` | Deprecated | 1.10 | |
| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
| `RotateKubeletClientCertificate` | `true` | Beta | 1.7 | |
| `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | |
| `RunAsGroup` | `false` | Alpha | 1.10 | |
| `ScheduleDaemonSetPods` | `false` | Alpha | 1.10 | |
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | |
| `StreamingProxyRedirects` | `true` | Beta | 1.5 | |
| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | |
| `SupportPodPidsLimit` | `false` | Alpha | 1.10 | |
| `TaintBasedEvictions` | `false` | Alpha | 1.6 | |
| `TaintNodesByCondition` | `false` | Alpha | 1.8 | |
| `TokenRequest` | `false` | Alpha | 1.10 | |
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
| `VolumeScheduling` | `true` | Beta | 1.10 | |
## Using a Feature
### Feature Stages
A feature can be in *Alpha*, *Beta* or *GA* stage.
An *Alpha* feature means:
* Disabled by default.
* Might be buggy. Enabling the feature may expose bugs.
* Support for feature may be dropped at any time without notice.
* The API may change in incompatible ways in a later software release without notice.
* Recommended for use only in short-lived testing clusters, due to increased
risk of bugs and lack of long-term support.
A *Beta* feature means:
* Enabled by default.
* The feature is well tested. Enabling the feature is considered safe.
* 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.
* Recommended for only non-business-critical uses because of potential for
incompatible changes in subsequent releases. If you have multiple clusters
that can be upgraded independently, you may be able to relax this restriction.
{{< note >}}
**Note:** Please do try *Beta* features and give feedback on them!
After they exit beta, it may not be practical for us to make more changes.
{{< /note >}}
A *GA* feature is also referred to as a *stable* feature. It means:
* The corresponding feature gate is no longer needed.
* Stable versions of features will appear in released software for many subsequent versions.
### Feature Gates
Each feature gate is designed for enabling/disabling a specific feature:
- `Accelerators`: Enable Nvidia GPU support when using Docker
- `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit)
- `AffinityInAnnotations`(*deprecated*): Enable setting [Pod affinity or anti-affinitys](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
- `AllowExtTrafficLocalEndpoints`: Enable a service to route external requests to node local endpoints.
- `APIListChunking`: Enable the API clients to retrieve (`LIST` or `GET`) resources from API server in chunks.
- `APIResponseCompression`: Compress the API responses for `LIST` or `GET` requests.
- `AppArmor`: Enable AppArmor based mandatory access control on Linux nodes when using Docker.
See [AppArmor Tutorial](/docs/tutorials/clusters/apparmor/) for more details.
- `BlockVolume`: Enable the definition and consumption of raw block devices in Pods.
See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
for more details.
- `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
- `CRIContainerLogRotation`: Enable container log rotation for cri container runtime.
- `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
[CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
compatible volume plugin.
Check the [`csi` volume type](/docs/concepts/storage/volumes/#csi) documentation for more details.
- `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
for more details.
- `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
- `CustomResourceValidation`: Enable schema based validation on resources created from
[CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
- `DebugContainers`: Enable running a "debugging" container in a Pod's namespace to
troubleshoot a running Pod.
- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
based resource provisioning on nodes.
- `DynamicKubeletConfig`: Enable the dynamic configuration of kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/).
- `DynamicVolumeProvisioning`(*deprecated*): Enable the [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/) of persistent volumes to Pods.
- `EnableEquivalenceClassCache`: Enable the scheduler to cache equivalence of nodes when scheduling Pods.
- `ExpandPersistentVolumes`: Enable the expanding of persistent volumes. See [Expanding Persistent Volumes Claims](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims).
- `ExperimentalCriticalPodAnnotation`: Enable annotating specific pods as *critical* so that their [scheduling is guaranteed](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
- `ExperimentalHostUserNamespaceDefaultingGate`: Enabling the defaulting user
namespace to host. This is for containers that are using other host namespaces,
host mounts, or containers that are privileged or using specific non-namespaced
capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled
if user namespace remapping is enabled in the Docker daemon.
- `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE.
- `HugePages`: Enable the allocation and consumption of pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
- `HyperVContainer`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers.
- `Intializers`: Enable the [dynamic admission control](/docs/admin/extensible-admission-controllers/)
as an extension to the built-in [admission controllers](/docs/admin/admission-controllers/).
When the `Initializers` admission controller is enabled, this feature is automatically enabled.
- `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file.
See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details.
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
- `MountContainers`: Enable using utility containers on host as the volume mounter.
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
- `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
Pod affinity has to be specified if requesting a `local` volume.
- `PodPriority`: Enable the descheduling and preemption of Pods based on their [priorities](/docs/concepts/configuration/pod-priority-preemption/).
- `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
being deleted when it is still used by any Pod.
More details can be found [here](/docs/tasks/administer-cluster/pvc-protection/).
- `ReadOnlyAPIDataVolumes`: Set Secret, ConfigMap, DownwardAPI and projected volumes to be mounted in read-only mode.
This gate exists only for backward compatibility. It will be removed in 1.11 release.
- `ResourceLimitsPriorityFunction`: Enable a scheduler priority function that
assigns a lowest possible score of 1 to a node that satisfies at least one of
the input Pod's cpu and memory limits. The intent is to break ties between
nodes with same scores.
- `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
See [kubelet configuration](/docs/admin/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
- `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet.
See [kubelet configuration](/docs/admin/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
- `RunAsGroup`: Enable control over the primary group ID set on the init processes of containers.
- `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller.
- `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
A node is eligible for exclusion if annotated with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key.
- `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
PersistentVolumeClaim objects if they are still being used.
- `StreamingProxyRedirects`: Instructs the API server to intercept (and follow)
redirects from the backend (kubelet) for streaming requests.
Examples of streaming requests include the `exec`, `attach` and `port-forward` requests.
- `SupportIPVSProxyMode`: Enable providing in-cluster service load balancing using IPVS.
See [service proxies](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) for more details.
- `SupportPodPidsLimit`: Enable the support to limiting PIDs in Pods.
- `TaintBasedEvictions`: Enable evicting pods from nodes based on taints on nodes and tolerations on Pods.
See [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/) for more details.
- `TaintNodesByCondition`: Enable automatic tainting nodes based on [node conditions](/docs/concepts/architecture/nodes/#condition).
- `TokenRequest`: Enable the `TokenRequest` endpoint on service account resources.
- `VolumeScheduling`: Enable volume topology aware scheduling and make the
PersistentVolumeClaim (PVC) binding aware of scheduling decisions. It also
enables the usage of [`local`](/docs/concepts/storage/volumes/#local) volume
type when used together with the `PersistentLocalVolumes` feature gate.
{{% /capture %}}

5
content/en/docs/reference/issues-security/_index.md Normal file
View File

@ -0,0 +1,5 @@
---
title: Kubernetes Issues and Security
weight: 10
toc-hide: true
---

6
content/en/docs/reference/issues-security/issues.md Normal file
View File

@ -0,0 +1,6 @@
---
title: Kubernetes Issue Tracker
weight: 10
---
Work on Kubernetes code is tracked using [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/).

1
content/en/docs/reference/security.md → content/en/docs/reference/issues-security/security.md
View File

@ -7,6 +7,7 @@ reviewers:
- erictune
- philips
- jessfraz
weight: 20
---
## Security Announcements

0
content/en/docs/reference/labels-annotations-taints.md → content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
View File

5
content/en/docs/reference/using-api/_index.md Normal file
View File

@ -0,0 +1,5 @@
---
title: Using the Kubernetes API
weight: 10
toc-hide: true
---

1
content/en/docs/reference/api-concepts.md → content/en/docs/reference/using-api/api-concepts.md
View File

@ -6,6 +6,7 @@ reviewers:
- lavalamp
- liggitt
content_template: templates/concept
weight: 20
---
{{% capture overview %}}

1
content/en/docs/reference/api-overview.md → content/en/docs/reference/using-api/api-overview.md
View File

@ -6,6 +6,7 @@ reviewers:
- lavalamp
- jbeda
content_template: templates/concept
weight: 10
---
{{% capture overview %}}

1
content/en/docs/reference/client-libraries.md → content/en/docs/reference/using-api/client-libraries.md
View File

@ -3,6 +3,7 @@ title: Client Libraries
reviewers:
- ahmetb
content_template: templates/concept
weight: 30
---
{{% capture overview %}}

1
content/en/docs/reference/deprecation-policy.md → content/en/docs/reference/using-api/deprecation-policy.md
View File

@ -4,6 +4,7 @@ reviewers:
- lavalamp
- thockin
title: Kubernetes Deprecation Policy
weight: 40
---
Kubernetes is a large system with many components and many contributors. As

261
content/en/docs/reference/workloads-18-19.md
View File

@ -1,261 +0,0 @@
---
title: Workloads API changes in versions 1.8 and 1.9
approvers:
- steveperry-53
- kow3ns
---
## Overview
The Kubernetes core Workloads API includes the Deployment, DaemonSet, ReplicaSet, and StatefulSet kinds. To provide a stable API for users to orchestrate their workloads, we are prioritizing promoting these kinds to GA. The batch Workloads API (Job and CronJob), while also important, is not part of this effort, and it will have a separate path to GA stability.
- In the 1.8 release, we introduce the apps/v1beta2 API group and version. This beta version of the core Workloads API contains the Deployment, DaemonSet, ReplicaSet, and StatefulSet kinds, and it is the version we plan to promote to GA in the 1.9 release provided the feedback is positive.
- In the 1.9 release, we plan to introduce the apps/v1 group version. We intend to promote the apps/v1beta2 group version in its entirety to apps/v1 and to deprecate apps/v1beta2 at that time.
- We realize that even after the release of apps/v1, users will need time to migrate their code from extensions/v1beta1, apps/v1beta1, and apps/v1beta2. It is important to remember that the minimum support durations listed in the deprecations guidelines are minimums. We will continue to support conversion between groups and versions until users have had sufficient time to migrate.
## Migration
This section contains information to assist users in migrating core Workloads API kinds between group versions.
### General
- If you are using kinds from the extensions/v1beta1 or apps/v1beta1 group versions, you can wait to migrate existing code until after the release of the apps/v1 group version.
- If your deployment requires features that are available in the apps/v1beta2 group version, you can migrate to this group version before the apps/v1 release.
- You should develop all new code against the latest stable release.
- You can run `kubectl convert` to convert manifests between group versions.
### Migrating to apps/v1beta2
This section provides information on migrating to the apps/v1beta2 group version. It covers general changes to the core Workloads API kinds. For changes that affect a specific kind (for example, default values), consult the reference documentation for the kind.
#### Default selectors are deprecated
In earlier versions of the apps and extensions groups, the spec.selectors of the core Workloads API kinds were, when left unspecified, defaulted to a LabelSelector generated from the spec.template.metadata.labels.
User feedback led us to determine that, as it is incompatible with strategic merge patch and kubectl apply, defaulting the value of a field from the value of another field of the same object is an anti-pattern.
#### Immutable selectors
We have always cautioned users against selector mutation. The core Workloads API controller does not, in the general case, handle selector mutation gracefully.
To provide a consistent, usable, and stable API, selectors are immutable for all kinds in the apps/v1beta2 group and version.
We believe that there are better ways to support features like promotable canaries and orchestrated Pod relabeling, but if restricted selector mutation is a necessary feature for our users, we can relax immutability before GA without breaking backward compatibility.
The development of features like promotable canaries, orchestrated Pod relabeling, and restricted selector mutability is driven by demand signals from our users. If you are currently modifying the selectors of your core Workloads API objects, please tell us about your use case in a GitHub issue or by participating in SIG-apps.
#### Default rolling updates
Before apps/v1beta2, some kinds defaulted the spec.updateStrategy to a strategy other than RollingUpdate. For example, apps/v1beta1 StatefulSet specifies OnDelete by default. In apps/v1beta2 the spec.updateStrategy for all kinds defaults to RollingUpdate.
#### Created-by annotation is deprecated
"kubernetes.io/created-by" is deprecated in version 1.8. Instead, you should specify an object’s ControllerRef from its ownerReferences to determine object ownership.
## Timeline
This section details the timeline for promotion and deprecation of kinds in the core Workloads API.
### Release 1.8
In Kubernetes 1.8, we unify the core Workloads API kinds in a single group and version. We address consistency, usability, and stability issues across the API surface. We have deprecated portions of the apps/v1beta1 group version and the extension/v1beta1 group version and replaced them with the apps/v1beta2 group version. The table below shows the kinds that are deprecated and the kinds that replace them.
<table style="width:100%">
<tr>
<th colspan="3">Deprecated</th>
<th colspan="3">Replaced By</th>
</tr>
<tr>
<td>Group</td>
<td>Version</td>
<td>Kind</td>
<td>Group</td>
<td>Version</td>
<td>Kind</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta1</td>
<td>Deployment</td>
<td>apps</td>
<td>v1beta2</td>
<td>Deployment</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta1</td>
<td>ReplicaSet</td>
<td>apps</td>
<td>v1beta2</td>
<td>ReplicaSet</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta1</td>
<td>StatefulSet</td>
<td>apps</td>
<td>v1beta2</td>
<td>StatefulSet</td>
</tr>
<tr>
<td>extensions</td>
<td>v1beta1</td>
<td>Deployment</td>
<td>apps</td>
<td>v1beta2</td>
<td>Deployment</td>
</tr>
<tr>
<td>extensions</td>
<td>v1beta1</td>
<td>DaemonSet</td>
<td>apps</td>
<td>v1beta2</td>
<td>DaemonSet</td>
</tr>
<tr>
<td>extensions</td>
<td>v1beta1</td>
<td>StatefulSet</td>
<td>apps</td>
<td>v1beta2</td>
<td>StatefulSet</td>
</tr>
</table>
### Release 1.9
In Kubernetes 1.9, our goal is to address any feedback on the apps/v1beta2 group version and to promote the group version to GA. The table below shows the kinds that we plan to deprecate and the kinds that will replace them.
<table style="width:100%">
<tr>
<th colspan="3">Deprecated</th>
<th colspan="3">Replaced By</th>
</tr>
<tr>
<td>Group</td>
<td>Version</td>
<td>Kind</td>
<td>Group</td>
<td>Version</td>
<td>Kind</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta2</td>
<td>Deployment</td>
<td>apps</td>
<td>v1</td>
<td>Deployment</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta2</td>
<td>DaemonSet</td>
<td>apps</td>
<td>v1</td>
<td>DaemonSet</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta2</td>
<td>ReplicaSet</td>
<td>apps</td>
<td>v1</td>
<td>ReplicaSet</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta2</td>
<td>StatefulSet</td>
<td>apps</td>
<td>v1</td>
<td>StatefulSet</td>
</tr>
</table>
### Post 1.9
Because users will continue to depend on extensions/v1beta1, apps/v1beta1, and apps/v1beta2, we will not completely remove deprecated kinds in these group versions upon GA promotion. Instead, we will provide auto-conversion between the deprecated portions of the API surface and the GA version. The table below shows the bidirectional conversion that we will support.
<table style="width:100%">
<tr>
<th colspan="3">GA</th>
<th colspan="3">Previous</th>
</tr>
<tr>
<td>Group</td>
<td>Version</td>
<td>Kind</td>
<td>Group</td>
<td>Version</td>
<td>Kind</td>
</tr>
<tr>
<td rowspan="3">apps</td>
<td rowspan="3">v1</td>
<td rowspan="3">Deployment</td>
<td>apps</td>
<td>v1beta1</td>
<td>Deployment</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta2</td>
<td>Deployment</td>
</tr>
<tr>
<td>extensions</td>
<td>v1beta1</td>
<td>Deployment</td>
</tr>
<tr>
<td rowspan="2">apps</td>
<td rowspan="2">v1</td>
<td rowspan="2">Daemonset</td>
<td>apps</td>
<td>v1beta2</td>
<td>DaemonSet</td>
</tr>
<tr>
<td>extensions</td>
<td>v1beta1</td>
<td>DaemonSet</td>
</tr>
<tr>
<td rowspan="3">apps</td>
<td rowspan="3">v1</td>
<td rowspan="3">ReplicaSet</td>
<td>apps</td>
<td>v1beta1</td>
<td>ReplicaSet</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta2</td>
<td>ReplicaSet</td>
</tr>
<tr>
<td>extensions</td>
<td>v1beta1</td>
<td>ReplicaSet</td>
</tr>
<tr>
<td rowspan="2">apps</td>
<td rowspan="2">v1</td>
<td rowspan="2">StatefulSet</td>
<td>apps</td>
<td>v1beta1</td>
<td>StatefulSet</td>
</tr>
<tr>
<td>apps</td>
<td>v1beta2</td>
<td>StatefulSet</td>
</tr>
</table>

12
static/_redirects
View File

@ -484,3 +484,15 @@ https://kubernetes-io-v1-7.netlify.com/* https://v1-7.docs.kubernetes.io/:spl
/docs/reference/generated/kubeadm/ /docs/reference/setup-tools/kubeadm/kubeadm/ 301
/editdocs/ /docs/home/contribute/ 301
/docs/admin/accessing-the-api/ /docs/reference/access-authn-authz/controlling-access/ 301
/docs/admin/admission-controllers/ /docs/reference/access-authn-authz/admission-controllers/ 301
/docs/admin/authentication/ /docs/reference/access-authn-authz/authentication/ 301
/docs/admin/bootstrap-tokens/ /docs/reference/access-authn-authz/bootstrap-tokens/ 301
/docs/admin/extensible-admission-controllers/ /docs/reference/access-authn-authz/extensible-admission-controllers/ 301
/docs/admin/service-accounts-admin/ /docs/reference/access-authn-authz/service-accounts-admin/ 301
/docs/admin/authorization/abac/ /docs/reference/access-authn-authz/abac/ 301
/docs/admin/authorization/node/ /docs/reference/access-authn-authz/node/ 301
/docs/admin/authorization/rbac/ /docs/reference/access-authn-authz/rbac/ 301
/docs/admin/authorization/webhook/ /docs/reference/access-authn-authz/webhook/ 301
/docs/admin/authorization/ /docs/reference/access-authn-authz/authorization/ 301