Merge pull request #6690 from Sea-n/design-proposals-archive
Fix links for k/design-proposals-archive
This commit is contained in:
commit
317f798301
|
@ -73,7 +73,7 @@ Guide](http://kubernetes.io/docs/admin/).
|
|||
Authorization applies to all HTTP requests on the main apiserver port.
|
||||
This doc explains the available authorization implementations.
|
||||
|
||||
* **Admission Control Plugins** ([admission_control](/contributors/design-proposals/api-machinery/admission_control.md))
|
||||
* **Admission Control Plugins** ([admission_control](https://git.k8s.io/design-proposals-archive/api-machinery/admission_control.md))
|
||||
|
||||
|
||||
## Building releases
|
||||
|
|
|
@ -62,7 +62,7 @@ When you're writing controllers, there are few guidelines that will help make su
|
|||
|
||||
This lets clients know that the controller has processed a resource. Make sure that your controller is the main controller that is responsible for that resource, otherwise if you need to communicate observation via your own controller, you will need to create a different kind of ObservedGeneration in the Status of the resource.
|
||||
|
||||
1. Consider using owner references for resources that result in the creation of other resources (eg. a ReplicaSet results in creating Pods). Thus you ensure that children resources are going to be garbage-collected once a resource managed by your controller is deleted. For more information on owner references, read more [here](/contributors/design-proposals/api-machinery/controller-ref.md).
|
||||
1. Consider using owner references for resources that result in the creation of other resources (eg. a ReplicaSet results in creating Pods). Thus you ensure that children resources are going to be garbage-collected once a resource managed by your controller is deleted. For more information on owner references, read more [here](https://git.k8s.io/design-proposals-archive/api-machinery/controller-ref.md).
|
||||
|
||||
Pay special attention in the way you are doing adoption. You shouldn't adopt children for a resource when either the parent or the children are marked for deletion. If you are using a cache for your resources, you will likely need to bypass it with a direct API read in case you observe that an owner reference has been updated for one of the children. Thus, you ensure your controller is not racing with the garbage collector.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Generation and release cycle of clientset
|
||||
|
||||
Client-gen is an automatic tool that generates [clientset](/contributors/design-proposals/api-machinery/client-package-structure.md#high-level-client-sets) based on API types. This doc introduces the use of client-gen, and the release cycle of the generated clientsets.
|
||||
Client-gen is an automatic tool that generates [clientset](https://git.k8s.io/design-proposals-archive/api-machinery/client-package-structure.md#high-level-client-sets) based on API types. This doc introduces the use of client-gen, and the release cycle of the generated clientsets.
|
||||
|
||||
## Using client-gen
|
||||
|
||||
|
|
|
@ -223,7 +223,7 @@ item that has duplicates will delete all matching items.
|
|||
|
||||
`setElementOrder` directive provides a way to specify the order of a list.
|
||||
The relative order specified in this directive will be retained.
|
||||
Please refer to [proposal](/contributors/design-proposals/cli/preserve-order-in-strategic-merge-patch.md) for more information.
|
||||
Please refer to [proposal](https://git.k8s.io/design-proposals-archive/cli/preserve-order-in-strategic-merge-patch.md) for more information.
|
||||
|
||||
### Syntax
|
||||
|
||||
|
@ -302,7 +302,7 @@ containers:
|
|||
|
||||
`retainKeys` directive provides a mechanism for union types to clear mutual exclusive fields.
|
||||
When this directive is present in the patch, all the fields not in this directive will be cleared.
|
||||
Please refer to [proposal](/contributors/design-proposals/api-machinery/add-new-patchStrategy-to-clear-fields-not-present-in-patch.md) for more information.
|
||||
Please refer to [proposal](https://git.k8s.io/design-proposals-archive/api-machinery/add-new-patchStrategy-to-clear-fields-not-present-in-patch.md) for more information.
|
||||
|
||||
### Syntax
|
||||
|
||||
|
|
|
@ -111,7 +111,7 @@ its sole use. When choosing a group name, we recommend selecting a subdomain
|
|||
your group or organization owns, such as "widget.mycompany.com".
|
||||
|
||||
Version strings should match
|
||||
[DNS_LABEL](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/identifiers.md)
|
||||
[DNS_LABEL](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md)
|
||||
format.
|
||||
|
||||
|
||||
|
@ -1670,7 +1670,7 @@ called `Fooable`, not `IsFooable`.
|
|||
|
||||
### Namespace Names
|
||||
* The name of a namespace must be a
|
||||
[DNS_LABEL](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/identifiers.md).
|
||||
[DNS_LABEL](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md).
|
||||
* The `kube-` prefix is reserved for Kubernetes system namespaces, e.g. `kube-system` and `kube-public`.
|
||||
* See
|
||||
[the namespace docs](https://kubernetes.io/docs/user-guide/namespaces/) for more information.
|
||||
|
|
|
@ -361,7 +361,7 @@ Conformance test results, by provider and releases, can be viewed in the
|
|||
[testgrid conformance dashboard]. If you wish to contribute test results
|
||||
for your provider, please see the [testgrid conformance README]
|
||||
|
||||
[kubernetes versioning policy]: /contributors/design-proposals/release/versioning.md#supported-releases-and-component-skew
|
||||
[kubernetes versioning policy]: https://git.k8s.io/design-proposals-archive/release/versioning.md#supported-releases-and-component-skew
|
||||
[Conformance Test Review board]: https://github.com/orgs/kubernetes/projects/9
|
||||
[Conformance test reviewers]: https://github.com/kubernetes/kubernetes/blob/master/test/conformance/testdata/OWNERS
|
||||
[conformance test requirements]: #conformance-test-requirements
|
||||
|
|
|
@ -23,9 +23,9 @@ progression to augment CRI to serve container metrics to eliminate a separate
|
|||
integration point.
|
||||
|
||||
*See the [core metrics design
|
||||
proposal](/contributors/design-proposals/instrumentation/core-metrics-pipeline.md)
|
||||
proposal](https://git.k8s.io/design-proposals-archive/instrumentation/core-metrics-pipeline.md)
|
||||
for more information on metrics exposed by Kubelet, and [monitoring
|
||||
architecture](/contributors/design-proposals/instrumentation/monitoring_architecture.md)
|
||||
architecture](https://git.k8s.io/design-proposals-archive/instrumentation/monitoring_architecture.md)
|
||||
for the evolving monitoring pipeline in Kubernetes.*
|
||||
|
||||
# Container Metrics
|
||||
|
|
|
@ -112,7 +112,7 @@ The general labeling process should be consistent across artifact types.
|
|||
referring to a release MAJOR.MINOR `vX.Y` version.
|
||||
|
||||
See also
|
||||
[release versioning](/contributors/design-proposals/release/versioning.md).
|
||||
[release versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md).
|
||||
|
||||
- *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone.
|
||||
|
||||
|
|
|
@ -16,10 +16,10 @@ The vendor and driver names must match flexVolume.driver in the volume spec, wit
|
|||
|
||||
## Dynamic Plugin Discovery
|
||||
Beginning in v1.8, Flexvolume supports the ability to detect drivers on the fly. Instead of requiring drivers to exist at system initialization time or having to restart kubelet or controller manager, drivers can be installed, upgraded/downgraded, and uninstalled while the system is running.
|
||||
For more information, please refer to the [design document](/contributors/design-proposals/storage/flexvolume-deployment.md).
|
||||
For more information, please refer to the [design document](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md).
|
||||
|
||||
## Automated Plugin Installation/Upgrade
|
||||
One possible way to install and upgrade your Flexvolume drivers is by using a DaemonSet. See [Recommended Driver Deployment Method](/contributors/design-proposals/storage/flexvolume-deployment.md#recommended-driver-deployment-method) for details, and see [here](https://git.k8s.io/examples/staging/volumes/flexvolume/deploy/) for an example.
|
||||
One possible way to install and upgrade your Flexvolume drivers is by using a DaemonSet. See [Recommended Driver Deployment Method](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md#recommended-driver-deployment-method) for details, and see [here](https://git.k8s.io/examples/staging/volumes/flexvolume/deploy/) for an example.
|
||||
|
||||
## Plugin details
|
||||
The plugin expects the following call-outs are implemented for the backend drivers. Some call-outs are optional. Call-outs are invoked from Kubelet and Controller Manager.
|
||||
|
|
|
@ -213,7 +213,7 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md).
|
|||
[SIG Lifecycle]: /sig-wg-lifecycle.md
|
||||
[We have them!]: /values.md
|
||||
[Kubernetes code of conduct]: /code-of-conduct.md
|
||||
[design principles]: /contributors/design-proposals/architecture/principles.md
|
||||
[design principles]: https://git.k8s.io/design-proposals-archive/architecture/principles.md
|
||||
[scope]: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
|
||||
[community members]: /community-membership.md
|
||||
[sig governance]: /committee-steering/governance/sig-governance.md
|
||||
|
|
|
@ -119,13 +119,13 @@ Establishing and documenting design principles, documenting and evolving the sys
|
|||
|
||||
Establishing and documenting conventions for system and user-facing APIs, define and operate the APl review process, final API implementation consistency validation, co-own top-level API directories with API machinery; maintaining, evolving, and enforcing the deprecation policy
|
||||
|
||||
* [Kubernetes Design and Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md)
|
||||
* [Design principles](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/principles.md)
|
||||
* [Kubernetes Design and Architecture](https://git.k8s.io/design-proposals-archive/architecture/architecture.md)
|
||||
* [Design principles](https://git.k8s.io/design-proposals-archive/architecture/principles.md)
|
||||
* [API conventions](/contributors/devel/sig-architecture/api-conventions.md)
|
||||
* [API Review process](https://github.com/kubernetes/community/blob/master/sig-architecture/api-review-process.md)
|
||||
* [Deprecation policy](https://kubernetes.io/docs/reference/deprecation-policy/)
|
||||
|
||||
Please see the [API Reviews](https://github.com/orgs/kubernetes/projects/13) tracking board to follow the work of this sub-project. Please reach out to folks in the [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/OWNERS) file if you are interested in joining this effort.
|
||||
Please see the [API Reviews](https://github.com/orgs/kubernetes/projects/13) tracking board to follow the work of this sub-project. Please reach out to folks in the [OWNERS](https://git.k8s.io/design-proposals-archive/architecture/OWNERS) file if you are interested in joining this effort.
|
||||
|
||||
## Enhancement Proposals
|
||||
|
||||
|
|
|
@ -119,7 +119,7 @@ Prior discussions:
|
|||
- `--endpoint-reconciler-type master-count`
|
||||
- ...probably more
|
||||
|
||||
[architecture]: https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#architecture
|
||||
[architecture]: https://git.k8s.io/design-proposals-archive/architecture/architecture.md#architecture
|
||||
[wg-naming-thread]: https://groups.google.com/g/kubernetes-wg-naming/c/VqrBCdUHdPc
|
||||
[sig-arch-thread]: https://groups.google.com/u/1/g/kubernetes-sig-architecture/c/ZKUOPy2PNJ4/m/q3dC6pNtBQAJ
|
||||
[framework]: https://git.k8s.io/community/wg-naming/language-evaluation-framework.md
|
||||
|
|
|
@ -404,8 +404,8 @@ See the sig-cli [community page] for points of contact and meeting times:
|
|||
[communication]: /sig-cli/README.md#contact
|
||||
[community page]: /sig-cli
|
||||
[design proposal]: #design-proposals
|
||||
[design repo]: /contributors/design-proposals/cli
|
||||
[design template]: /contributors/design-proposals/Design_Proposal_TEMPLATE.md
|
||||
[design repo]: https://git.k8s.io/design-proposals-archive/cli
|
||||
[design template]: https://git.k8s.io/design-proposals-archive/Design_Proposal_TEMPLATE.md
|
||||
[development guide]: /contributors/devel/development.md
|
||||
[existing issue]: #adopt-an-issue
|
||||
[feature repo]: https://github.com/kubernetes/features
|
||||
|
|
|
@ -275,8 +275,8 @@ See the sig-multicluster [community page] for points of contact and meeting time
|
|||
[community page]: /sig-multicluster
|
||||
[contributors guide]: /contributors/guide
|
||||
[design proposal]: #design-proposals
|
||||
[design repo]: /contributors/design-proposals/multicluster
|
||||
[design template]: /contributors/design-proposals/Design_Proposal_TEMPLATE.md
|
||||
[design repo]: https://git.k8s.io/design-proposals-archive/multicluster
|
||||
[design template]: https://git.k8s.io/design-proposals-archive/Design_Proposal_TEMPLATE.md
|
||||
[development guide]: /contributors/devel/development.md
|
||||
[existing issue]: #adopt-an-issue
|
||||
[feature repo]: https://github.com/kubernetes/features
|
||||
|
|
|
@ -85,7 +85,7 @@ Control Plane for newer Multicluster-specific APIs. Discussions are ongoing to f
|
|||
| Meeting Agenda | https://docs.google.com/document/d/1v-Kb1pUs3ww_x0MiKtgcyTXCAuZlbVlz4_A9wS3_HXY |
|
||||
|
||||
### Cluster Registry
|
||||
Common abstraction for a Registry of Clusters that can store per-Cluster metadata and supports Kubernetes label selection. The Cluster Registry can be deployed as a standalone or an aggregated API server and currently provides a Registry of Clusters without any actively reconciling Kubernetes controller. The API design is documented [here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multicluster/cluster-registry/api-design.md) and is intended to serve as a basis to develop multicluster controllers.
|
||||
Common abstraction for a Registry of Clusters that can store per-Cluster metadata and supports Kubernetes label selection. The Cluster Registry can be deployed as a standalone or an aggregated API server and currently provides a Registry of Clusters without any actively reconciling Kubernetes controller. The API design is documented [here](https://git.k8s.io/design-proposals-archive/multicluster/cluster-registry/api-design.md) and is intended to serve as a basis to develop multicluster controllers.
|
||||
|
||||
| | |
|
||||
| -------------- |:-------|
|
||||
|
|
Loading…
Reference in New Issue