Fix links for k/design-proposals-archive
The contributors/design-proposals in k/community was removed. It's only available in k/design-proposals-archive repo now. This commit also changes https://github.com/kubernetes/repo/blob/master/file.md to https://git.k8s.io/repo/file.md for better consistency.pull/34155/head
Sean Wei
parent
f3a9d4a01b
commit
34155fed0b
|
|
@ -69,7 +69,7 @@ been deprecated. These removals have been superseded by newer, stable/generally
|
|||
|
||||
* [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information.
|
||||
* [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=).
|
||||
* In-tree provisioner to CSI driver migration: This applies to a number of in-tree plugins, including [Portworx](https://github.com/kubernetes/enhancements/issues/2589). Refer to the [In-tree Storage Plugin to CSI Migration Design Doc](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/csi-migration.md#background-and-motivations) for more information.
|
||||
* In-tree provisioner to CSI driver migration: This applies to a number of in-tree plugins, including [Portworx](https://github.com/kubernetes/enhancements/issues/2589). Refer to the [In-tree Storage Plugin to CSI Migration Design Doc](https://git.k8s.io/design-proposals-archive/storage/csi-migration.md#background-and-motivations) for more information.
|
||||
* [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/).
|
||||
* [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information.
|
||||
* [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint).
|
||||
|
|
|
|||
|
|
@ -654,7 +654,7 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
|
|||
|
||||
* Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node.
|
||||
* Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
* Read the [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
|
||||
section of the architecture design document.
|
||||
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
|
||||
|
|
|
|||
|
|
@ -203,4 +203,4 @@ to run, and in both cases, the network provides one IP address per pod - as is s
|
|||
|
||||
The early design of the networking model and its rationale, and some future
|
||||
plans are described in more detail in the
|
||||
[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
||||
[networking design document](https://git.k8s.io/design-proposals-archive/network/networking.md).
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ After a request is authorized, if it is a write operation, it also goes through
|
|||
|
||||
### Storage Plugins
|
||||
|
||||
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
|
||||
[Flex Volumes](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md
|
||||
) allow users to mount volume types without built-in support by having the
|
||||
Kubelet call a Binary Plugin to mount the volume.
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ This is a significant undertaking, and almost all Kubernetes users find they
|
|||
do not need to modify the scheduler.
|
||||
|
||||
The scheduler also supports a
|
||||
[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
|
||||
[webhook](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)
|
||||
that permits a webhook backend (scheduler extension) to filter and prioritize
|
||||
the nodes chosen for a pod.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 20
|
|||
<!-- overview -->
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
|
||||
Kubernetes provides a [device plugin framework](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)
|
||||
that you can use to advertise system hardware resources to the
|
||||
{{< glossary_tooltip term_id="kubelet" >}}.
|
||||
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ request headers as follows:
|
|||
|
||||
Kubernetes implements an alternative Protobuf based serialization format that
|
||||
is primarily intended for intra-cluster communication. For more information
|
||||
about this format, see the [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) design proposal and the
|
||||
about this format, see the [Kubernetes Protobuf serialization](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) design proposal and the
|
||||
Interface Definition Language (IDL) files for each schema located in the Go
|
||||
packages that define the API objects.
|
||||
|
||||
|
|
|
|||
|
|
@ -100,4 +100,4 @@ UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667.
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes.
|
||||
* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document.
|
||||
* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) design document.
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Neither contention nor changes to a LimitRange will affect already created resou
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
|
||||
Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for more information.
|
||||
|
||||
For examples on using limits, see:
|
||||
|
||||
|
|
|
|||
|
|
@ -697,7 +697,7 @@ and it is to be created in a namespace other than `kube-system`.
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
|
||||
- See [ResourceQuota design doc](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md) for more information.
|
||||
- See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
|
||||
- Read [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md).
|
||||
- Read [Quota support for priority class design doc](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md).
|
||||
- See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
|
||||
|
|
|
|||
|
|
@ -303,7 +303,7 @@ the Pod onto a node that is in the same zone as one or more Pods with the label
|
|||
same zone currently running Pods with the `Security=S2` Pod label.
|
||||
|
||||
To get yourself more familiar with the examples of Pod affinity and anti-affinity,
|
||||
refer to the [design proposal](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md).
|
||||
refer to the [design proposal](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
|
||||
|
||||
You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the
|
||||
`operator` field for Pod affinity and anti-affinity.
|
||||
|
|
@ -471,8 +471,8 @@ The above Pod will only run on the node `kube-01`.
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
|
||||
* Read the design docs for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
|
||||
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
|
||||
* Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
|
||||
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
|
||||
* Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
|
||||
resource allocation decisions.
|
||||
* Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).
|
||||
|
|
|
|||
|
|
@ -682,7 +682,7 @@ Claims use [the same convention as volumes](#volume-mode) to indicate the consum
|
|||
|
||||
### Resources
|
||||
|
||||
Claims, like Pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) applies to both volumes and claims.
|
||||
Claims, like Pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://git.k8s.io/design-proposals-archive/scheduling/resources.md) applies to both volumes and claims.
|
||||
|
||||
### Selector
|
||||
|
||||
|
|
@ -1021,7 +1021,7 @@ and need persistent storage, it is recommended that you use the following patter
|
|||
|
||||
* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
|
||||
* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
|
||||
* Read the [Persistent Storage design document](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/persistent-storage.md).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md).
|
||||
|
||||
### API references {#reference}
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Currently, the following types of volume sources can be projected:
|
|||
* [`serviceAccountToken`](#serviceaccounttoken)
|
||||
|
||||
All sources are required to be in the same namespace as the Pod. For more details,
|
||||
see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md) design document.
|
||||
see the [all-in-one volume](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md) design document.
|
||||
|
||||
### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ for provisioning PVs. This field must be specified.
|
|||
You are not restricted to specifying the "internal" provisioners
|
||||
listed here (whose names are prefixed with "kubernetes.io" and shipped
|
||||
alongside Kubernetes). You can also run and specify external provisioners,
|
||||
which are independent programs that follow a [specification](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)
|
||||
which are independent programs that follow a [specification](https://git.k8s.io/design-proposals-archive/storage/volume-provisioning.md)
|
||||
defined by Kubernetes. Authors of external provisioners have full discretion
|
||||
over where their code lives, how the provisioner is shipped, how it needs to be
|
||||
run, what volume plugin it uses (including Flex), etc. The repository
|
||||
|
|
|
|||
|
|
@ -1156,7 +1156,7 @@ to the [volume plugin FAQ](https://github.com/kubernetes/community/blob/master/s
|
|||
(CSI) defines a standard interface for container orchestration systems (like
|
||||
Kubernetes) to expose arbitrary storage systems to their container workloads.
|
||||
|
||||
Please read the [CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for more information.
|
||||
Please read the [CSI design proposal](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) for more information.
|
||||
|
||||
{{< note >}}
|
||||
Support for CSI spec versions 0.2 and 0.3 are deprecated in Kubernetes
|
||||
|
|
|
|||
|
|
@ -99,6 +99,6 @@ operator to use or manage a cluster.
|
|||
## Design Docs
|
||||
|
||||
An archive of the design docs for Kubernetes functionality. Good starting points are
|
||||
[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and
|
||||
[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
|
||||
[Kubernetes Architecture](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) and
|
||||
[Kubernetes Design Overview](https://git.k8s.io/design-proposals-archive).
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ controller on the controller manager.
|
|||
|
||||
Each valid token is backed by a secret in the `kube-system` namespace. You can
|
||||
find the full design doc
|
||||
[here](https://github.com/kubernetes/design-proposals-archive/blob/main/cluster-lifecycle/bootstrap-discovery.md).
|
||||
[here](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md).
|
||||
|
||||
Here is what the secret looks like.
|
||||
|
||||
|
|
|
|||
|
|
@ -761,7 +761,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
Requires Portworx CSI driver to be installed and configured in the cluster.
|
||||
- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in `csi.storage.k8s.io`.
|
||||
- `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)
|
||||
[CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md)
|
||||
compatible volume plugin.
|
||||
- `CSIServiceAccountToken`: Enable CSI drivers to receive the pods' service account token
|
||||
that they mount volumes for. See
|
||||
|
|
|
|||
|
|
@ -943,7 +943,7 @@ Default: ""</p>
|
|||
<td>
|
||||
<p>systemReservedCgroup helps the kubelet identify absolute name of top level CGroup used
|
||||
to enforce <code>systemReserved</code> compute resource reservation for OS system daemons.
|
||||
Refer to <a href="https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md">Node Allocatable</a>
|
||||
Refer to <a href="https://git.k8s.io/design-proposals-archive/node/node-allocatable.md">Node Allocatable</a>
|
||||
doc for more information.
|
||||
Default: ""</p>
|
||||
</td>
|
||||
|
|
@ -954,7 +954,7 @@ Default: ""</p>
|
|||
<td>
|
||||
<p>kubeReservedCgroup helps the kubelet identify absolute name of top level CGroup used
|
||||
to enforce <code>KubeReserved</code> compute resource reservation for Kubernetes node system daemons.
|
||||
Refer to <a href="https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md">Node Allocatable</a>
|
||||
Refer to <a href="https://git.k8s.io/design-proposals-archive/node/node-allocatable.md">Node Allocatable</a>
|
||||
doc for more information.
|
||||
Default: ""</p>
|
||||
</td>
|
||||
|
|
@ -970,7 +970,7 @@ If <code>none</code> is specified, no other options may be specified.
|
|||
When <code>system-reserved</code> is in the list, systemReservedCgroup must be specified.
|
||||
When <code>kube-reserved</code> is in the list, kubeReservedCgroup must be specified.
|
||||
This field is supported only when <code>cgroupsPerQOS</code> is set to true.
|
||||
Refer to <a href="https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md">Node Allocatable</a>
|
||||
Refer to <a href="https://git.k8s.io/design-proposals-archive/node/node-allocatable.md">Node Allocatable</a>
|
||||
for more information.
|
||||
Default: ["pods"]</p>
|
||||
</td>
|
||||
|
|
|
|||
|
|
@ -1879,7 +1879,7 @@ PodStatus represents information about the status of a pod. Status may trail the
|
|||
|
||||
- **qosClass** (string)
|
||||
|
||||
The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md
|
||||
The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: https://git.k8s.io/design-proposals-archive/node/resource-qos.md
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -329,7 +329,7 @@ Please note that:
|
|||
### Configure TLS-Bootstrapping for node joining
|
||||
|
||||
Kubeadm uses [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) for joining new nodes to an
|
||||
existing cluster; for more details see also [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
|
||||
existing cluster; for more details see also [design proposal](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md).
|
||||
|
||||
`kubeadm init` ensures that everything is properly configured for this process, and this includes following steps as well as
|
||||
setting API server and controller flags as already described in previous paragraphs.
|
||||
|
|
@ -420,7 +420,7 @@ Similarly to `kubeadm init`, also `kubeadm join` internal workflow consists of a
|
|||
|
||||
This is split into discovery (having the Node trust the Kubernetes Master) and TLS bootstrap (having the Kubernetes Master trust the Node).
|
||||
|
||||
see [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) or the corresponding [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
|
||||
see [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) or the corresponding [design proposal](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md).
|
||||
|
||||
### Preflight checks
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ The JSON and Protobuf serialization schemas follow the same guidelines for
|
|||
schema changes. The following descriptions cover both formats.
|
||||
|
||||
The API versioning and software versioning are indirectly related.
|
||||
The [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
|
||||
The [API and release versioning proposal](https://git.k8s.io/design-proposals-archive/release/versioning.md)
|
||||
describes the relationship between API versioning and software versioning.
|
||||
|
||||
Different API versions indicate different levels of stability and support. You
|
||||
|
|
@ -83,7 +83,7 @@ Here's a summary of each level:
|
|||
|
||||
## API groups
|
||||
|
||||
[API groups](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)
|
||||
[API groups](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md)
|
||||
make it easier to extend the Kubernetes API.
|
||||
The API group is specified in a REST path and in the `apiVersion` field of a
|
||||
serialized object.
|
||||
|
|
@ -124,4 +124,4 @@ Kubernetes stores its serialized state in terms of the API resources by writing
|
|||
|
||||
- Learn more about [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
|
||||
- Read the design documentation for
|
||||
[aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
||||
[aggregator](https://git.k8s.io/design-proposals-archive/api-machinery/aggregated-api-servers.md)
|
||||
|
|
|
|||
|
|
@ -603,7 +603,7 @@ Workarounds:
|
|||
|
||||
kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, ppc64le, and s390x
|
||||
following the [multi-platform
|
||||
proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md).
|
||||
proposal](https://git.k8s.io/design-proposals-archive/multi-platform.md).
|
||||
|
||||
Multiplatform container images for the control plane and addons are also supported since v1.12.
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ to define *Hard* resource usage limits that a *Namespace* may consume.
|
|||
A limit range defines min/max constraints on the amount of resources a single entity can consume in
|
||||
a *Namespace*.
|
||||
|
||||
See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
|
||||
See [Admission control: Limit Range](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)
|
||||
|
||||
A namespace can be in one of two phases:
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ The name of your namespace must be a valid
|
|||
|
||||
There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
|
||||
|
||||
More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers).
|
||||
More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers).
|
||||
|
||||
## Deleting a namespace
|
||||
|
||||
|
|
@ -314,7 +314,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
|||
|
||||
* Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
|
||||
* Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
|
||||
* See [namespaces design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/namespaces.md).
|
||||
* See [namespaces design](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -282,7 +282,7 @@ PersistentVolume are not present on the Pod resource itself.
|
|||
|
||||
|
||||
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md).
|
||||
|
||||
### Reference
|
||||
|
||||
|
|
|
|||
|
|
@ -83,5 +83,5 @@ kubectl delete secret user pass
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
|
||||
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md) design document.
|
||||
* Read the [all-in-one volume](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md) design document.
|
||||
|
||||
|
|
|
|||
|
|
@ -452,7 +452,7 @@ applied to Volumes as follows:
|
|||
|
||||
* `fsGroup`: Volumes that support ownership management are modified to be owned
|
||||
and writable by the GID specified in `fsGroup`. See the
|
||||
[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
[Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
|
||||
for more details.
|
||||
|
||||
* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
|
||||
|
|
@ -482,10 +482,10 @@ kubectl delete pod security-context-demo-4
|
|||
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
|
||||
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
* [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
|
||||
* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
|
||||
* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
* [Security Contexts design document](https://git.k8s.io/design-proposals-archive/auth/security_context.md)
|
||||
* [Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
|
||||
* [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/)
|
||||
* [AllowPrivilegeEscalation design
|
||||
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
|
||||
document](https://git.k8s.io/design-proposals-archive/auth/no-new-privs.md)
|
||||
* For more information about security mechanisms in Linux, see
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features) (Note: Some information is out of date)
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ repository. You must enable the [API aggregation layer](/docs/tasks/extend-kuber
|
|||
and register an [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)
|
||||
for the `metrics.k8s.io` API.
|
||||
|
||||
To learn more about the Metrics API, see [resource metrics API design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md),
|
||||
To learn more about the Metrics API, see [resource metrics API design](https://git.k8s.io/design-proposals-archive/instrumentation/resource-metrics-api.md),
|
||||
the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server) and the
|
||||
[resource metrics API](https://github.com/kubernetes/metrics#resource-metrics-api).
|
||||
|
||||
|
|
@ -237,7 +237,7 @@ To learn more about the metrics-server, see the
|
|||
|
||||
You can also check out the following:
|
||||
|
||||
* [metrics-server design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/metrics-server.md)
|
||||
* [metrics-server design](https://git.k8s.io/design-proposals-archive/instrumentation/metrics-server.md)
|
||||
* [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md)
|
||||
* [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md)
|
||||
* [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases)
|
||||
|
|
|
|||
|
|
@ -337,9 +337,9 @@ APIs, cluster administrators must ensure that:
|
|||
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
|
||||
|
||||
For more information on these different metrics paths and how they differ please see the relevant design proposals for
|
||||
[the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md)
|
||||
and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md).
|
||||
[the HPA V2](https://git.k8s.io/design-proposals-archive/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md)
|
||||
and [external.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/external-metrics-api.md).
|
||||
|
||||
For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
|
||||
and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
|
||||
|
|
|
|||
|
|
@ -124,7 +124,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.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s
|
|||
## Supported versions
|
||||
|
||||
Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
|
||||
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
|
||||
For more information, see [Kubernetes Release Versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md#kubernetes-release-versioning).
|
||||
|
||||
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue