Fix broken links after moving proposals to subdirs.
This commit is contained in:
Slava Semushin
committed by
Zach Corleissen
Zach Corleissen
parent
e9065a984c
commit
67c0fcd274
@@ -58,7 +58,7 @@ Authorization: Bearer 07401b.f395accd246ae52d
|
||||
|
||||
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/community/blob/{{page.githubbranch}}/contributors/design-proposals/bootstrap-discovery.md).
|
||||
[here](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
|
||||
|
||||
Here is what the secret looks like. Note that `base64(string)` indicates the
|
||||
value should be base64 encoded. The undecoded version is provided here for
|
||||
|
||||
@@ -385,4 +385,4 @@ if required.
|
||||
|
||||
## For more information
|
||||
|
||||
* [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md) details use cases that motivated this work.
|
||||
* [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation/federation.md) details use cases that motivated this work.
|
||||
|
||||
@@ -70,7 +70,7 @@ kubelet
|
||||
--enable-custom-metrics Support for gathering custom metrics.
|
||||
--enable-debugging-handlers Enables server endpoints for log collection and local running of containers and commands (default true)
|
||||
--enable-server Enable the Kubelet's server (default true)
|
||||
--enforce-node-allocatable stringSlice A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md for more details. (default [pods])
|
||||
--enforce-node-allocatable stringSlice A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md for more details. (default [pods])
|
||||
--event-burst int32 Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10)
|
||||
--event-qps int32 If > 0, limit event creations per second to this value. If 0, unlimited. (default 5)
|
||||
--eviction-hard string A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default "memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%")
|
||||
@@ -80,7 +80,7 @@ kubelet
|
||||
--eviction-soft string A set of eviction thresholds (e.g. memory.available<1.5Gi) that if met over a corresponding grace period would trigger a pod eviction.
|
||||
--eviction-soft-grace-period string A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction.
|
||||
--exit-on-lock-contention Whether kubelet should exit upon lock-file contention.
|
||||
--experimental-allocatable-ignore-eviction When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md for more details. [default=false]
|
||||
--experimental-allocatable-ignore-eviction When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md for more details. [default=false]
|
||||
--experimental-allowed-unsafe-sysctls stringSlice Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk.
|
||||
--experimental-bootstrap-kubeconfig string deprecated: use --bootstrap-kubeconfig
|
||||
--experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount
|
||||
|
||||
@@ -11,7 +11,7 @@ title: Running in Multiple Zones
|
||||
Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
|
||||
(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
|
||||
This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
|
||||
nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation.md)).
|
||||
nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation/federation.md)).
|
||||
Full Cluster Federation allows combining separate
|
||||
Kubernetes clusters running in different regions or cloud providers
|
||||
(or on-premises data centers). However, many
|
||||
|
||||
@@ -7918,7 +7918,7 @@ Appears In <a href="#pod-v1-core">Pod</a> </aside>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>qosClass <br /> <em>string</em></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://git.k8s.io/community/contributors/design-proposals/resource-qos.md">https://git.k8s.io/community/contributors/design-proposals/resource-qos.md</a></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md">https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>reason <br /> <em>string</em></td>
|
||||
|
||||
@@ -5951,7 +5951,7 @@ Appears In:
|
||||
</tr>
|
||||
<tr>
|
||||
<td>manualSelector <br /> <em>boolean</em></td>
|
||||
<td>manualSelector controls generation of pod labels and pod selectors. Leave <code>manualSelector</code> unset unless you are certain what you are doing. When false or unset, the system pick labels unique to this job and appends those labels to the pod template. When true, the user is responsible for picking unique labels and specifying the selector. Failure to pick a unique label may cause this and other jobs to not function correctly. However, You may see <code>manualSelector=true</code> in jobs that were created with the old <code>extensions/v1beta1</code> API. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/selector-generation.md">https://git.k8s.io/community/contributors/design-proposals/selector-generation.md</a></td>
|
||||
<td>manualSelector controls generation of pod labels and pod selectors. Leave <code>manualSelector</code> unset unless you are certain what you are doing. When false or unset, the system pick labels unique to this job and appends those labels to the pod template. When true, the user is responsible for picking unique labels and specifying the selector. Failure to pick a unique label may cause this and other jobs to not function correctly. However, You may see <code>manualSelector=true</code> in jobs that were created with the old <code>extensions/v1beta1</code> API. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/apps/selector-generation.md">https://git.k8s.io/community/contributors/design-proposals/apps/selector-generation.md</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>parallelism <br /> <em>integer</em></td>
|
||||
@@ -8018,7 +8018,7 @@ Appears In:
|
||||
</tr>
|
||||
<tr>
|
||||
<td>qosClass <br /> <em>string</em></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md">https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md</a></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md">https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>reason <br /> <em>string</em></td>
|
||||
@@ -41943,7 +41943,7 @@ Appears In:
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>finalizers <br /> <em>string array</em></td>
|
||||
<td>Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers">https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers</a></td>
|
||||
<td>Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers">https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -41965,7 +41965,7 @@ Appears In:
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>phase <br /> <em>string</em></td>
|
||||
<td>Phase is the current lifecycle phase of the namespace. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases">https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases</a></td>
|
||||
<td>Phase is the current lifecycle phase of the namespace. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases">https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@@ -169,7 +169,7 @@ you may need even more clusters. Kubernetes v1.3 supports clusters up to 1000 n
|
||||
|
||||
{% capture whatsnext %}
|
||||
* Learn more about the [Federation
|
||||
proposal](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation.md).
|
||||
proposal](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation/federation.md).
|
||||
* See this [setup guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) for cluster federation.
|
||||
* See this [Kubecon2016 talk on federation](https://www.youtube.com/watch?v=pq9lbkmxpS8)
|
||||
{% endcapture %}
|
||||
|
||||
@@ -234,4 +234,4 @@ CNI-Genie also supports [assigning multiple IP addresses to a pod](https://githu
|
||||
|
||||
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/networking.md).
|
||||
document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
||||
|
||||
@@ -40,7 +40,7 @@ Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the o
|
||||
|
||||
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
|
||||
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://git.k8s.io/community/contributors/design-proposals/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
|
||||
|
||||
You can verify that it worked by re-running `kubectl get nodes --show-labels` and checking that the node now has a label.
|
||||
|
||||
@@ -142,7 +142,7 @@ If you specify multiple `matchExpressions` associated with `nodeSelectorTerms`,
|
||||
If you remove or change the label of the node where the pod is scheduled, the pod won't be removed. In other words, the affinity selection works only at the time of scheduling the pod.
|
||||
|
||||
For more information on node affinity, see the design doc
|
||||
[here](https://git.k8s.io/community/contributors/design-proposals/nodeaffinity.md).
|
||||
[here](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md).
|
||||
|
||||
### Inter-pod affinity and anti-affinity (beta feature)
|
||||
|
||||
@@ -183,7 +183,7 @@ value V that is running a pod that has a label with key "security" and value "S1
|
||||
rule says that the pod prefers to not schedule onto a node if that node is already running a pod with label
|
||||
having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then
|
||||
it would mean that the pod cannot schedule onto a node if that node is in the same zone as a pod with
|
||||
label having key "security" and value "S2".) See the [design doc](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md).
|
||||
label having key "security" and value "S2".) See the [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
|
||||
for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution`
|
||||
flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
|
||||
|
||||
@@ -296,7 +296,7 @@ Highly Available database statefulset has one master and three replicas, one may
|
||||
[Here](https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) is an example of zookeper statefulset configured with anti-affinity for high availability.
|
||||
|
||||
For more information on inter-pod affinity/anti-affinity, see the design doc
|
||||
[here](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md).
|
||||
[here](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
|
||||
|
||||
You may want to check [Taints](/docs/concepts/configuration/taint-and-toleration/)
|
||||
as well, which allow a *node* to *repel* a set of pods.
|
||||
|
||||
@@ -10,7 +10,7 @@ requests specified, the scheduler can make better decisions about which nodes to
|
||||
place Pods on. And when Containers have their limits specified, contention for
|
||||
resources on a node can be handled in a specified manner. For more details about
|
||||
the difference between requests and limits, see
|
||||
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md).
|
||||
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md).
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -238,7 +238,7 @@ The amount of resources available to Pods is less than the node capacity, becaus
|
||||
system daemons use a portion of the available resources. The `allocatable` field
|
||||
[NodeStatus](/docs/resources-reference/{{page.version}}/#nodestatus-v1-core)
|
||||
gives the amount of resources that are available to Pods. For more information, see
|
||||
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md).
|
||||
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
|
||||
|
||||
The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured
|
||||
to limit the total amount of resources that can be consumed. If used in conjunction
|
||||
@@ -405,7 +405,7 @@ all Containers in a Pod, such as
|
||||
Kubernetes version 1.5 only supports Container requests and limits for CPU and
|
||||
memory. It is planned to add new resource types, including a node disk space
|
||||
resource, and a framework for adding custom
|
||||
[resource types](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/resources.md).
|
||||
[resource types](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/scheduling/resources.md).
|
||||
|
||||
Kubernetes supports overcommitment of resources by supporting multiple levels of
|
||||
[Quality of Service](http://issue.k8s.io/168).
|
||||
|
||||
@@ -28,7 +28,7 @@ Complete API details are documented using [Swagger v1.2](http://swagger.io/) and
|
||||
|
||||
Starting with Kubernetes 1.4, OpenAPI spec is also available at [`/swagger.json`](https://git.k8s.io/kubernetes/api/openapi-spec/swagger.json). While we are transitioning from Swagger v1.2 to OpenAPI (aka Swagger v2.0), some of the tools such as kubectl and swagger-ui are still using v1.2 spec. OpenAPI spec is in Beta as of Kubernetes 1.5.
|
||||
|
||||
Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
|
||||
Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
|
||||
|
||||
## API versioning
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ Even though Kubernetes provides a lot of functionality, there are always new sce
|
||||
|
||||
[Labels](/docs/concepts/overview/working-with-objects/labels/) empower users to organize their resources however they please. [Annotations](/docs/concepts/overview/working-with-objects/annotations/) enable users to decorate resources with custom information to facilitate their workflows and provide an easy way for management tools to checkpoint state.
|
||||
|
||||
Additionally, the [Kubernetes control plane](/docs/concepts/overview/components/) is built upon the same [APIs](/docs/reference/api-overview/) that are available to developers and users. Users can write their own controllers, such as [schedulers](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/devel/scheduler.md), with [their own APIs](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/extending-api.md) that can be targeted by a general-purpose [command-line tool](/docs/user-guide/kubectl-overview/).
|
||||
Additionally, the [Kubernetes control plane](/docs/concepts/overview/components/) is built upon the same [APIs](/docs/reference/api-overview/) that are available to developers and users. Users can write their own controllers, such as [schedulers](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/devel/scheduler.md), with [their own APIs](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/api-machinery/extending-api.md) that can be targeted by a general-purpose [command-line tool](/docs/user-guide/kubectl-overview/).
|
||||
|
||||
This [design](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/architecture/principles.md) has enabled a number of other systems to build atop Kubernetes.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user
|
||||
|
||||
## Names
|
||||
|
||||
Names are generally client-provided. Only one object of a given kind can have a given name at a time (i.e., they are spatially unique). But if you delete an object, you can make a new object with the same name. Names are used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`. By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions. See the [identifiers design doc](https://git.k8s.io/community/contributors/design-proposals/identifiers.md) for the precise syntax rules for names.
|
||||
Names are generally client-provided. Only one object of a given kind can have a given name at a time (i.e., they are spatially unique). But if you delete an object, you can make a new object with the same name. Names are used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`. By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions. See the [identifiers design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) for the precise syntax rules for names.
|
||||
|
||||
## UIDs
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ Objects of type `PodSecurityPolicy` govern the ability
|
||||
to make requests on a pod that affect the `SecurityContext` that will be
|
||||
applied to a pod and container.
|
||||
|
||||
See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) for more information.
|
||||
See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/auth/security-context-constraints.md) for more information.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
@@ -157,7 +157,7 @@ spec:
|
||||
|
||||
### Capacity
|
||||
|
||||
Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/resources.md) to understand the units expected by `capacity`.
|
||||
Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) to understand the units expected by `capacity`.
|
||||
|
||||
Currently, storage size is the only resource that can be set or requested. Future attributes may include IOPS, throughput, etc.
|
||||
|
||||
@@ -311,7 +311,7 @@ Claims use the same conventions as volumes when requesting storage with specific
|
||||
|
||||
### 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/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/community/contributors/design-proposals/scheduling/resources.md) applies to both volumes and claims.
|
||||
|
||||
### Selector
|
||||
|
||||
@@ -442,7 +442,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://git.k8s.io/community/contributors/design-proposals/volume-provisioning.md)
|
||||
which are independent programs that follow a [specification](https://git.k8s.io/community/contributors/design-proposals/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 [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage)
|
||||
|
||||
@@ -466,7 +466,7 @@ Currently, the following types of volume sources can be projected:
|
||||
- [`downwardAPI`](#downardapi)
|
||||
- `configMap`
|
||||
|
||||
All sources are required to be in the same namespace as the pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/all-in-one-volume.md).
|
||||
All sources are required to be in the same namespace as the pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/node/all-in-one-volume.md).
|
||||
|
||||
#### Example pod with a secret, a downward API, and a configmap.
|
||||
|
||||
|
||||
@@ -166,9 +166,9 @@ See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/garbage-collection.md)
|
||||
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
|
||||
|
||||
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/synchronous-garbage-collection.md)
|
||||
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -318,7 +318,7 @@ $ export no_proxy=$no_proxy,$(minikube ip)
|
||||
|
||||
Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [localkube](https://git.k8s.io/minikube/pkg/localkube) (originally written and donated to this project by [RedSpread](https://redspread.com/)) for running the cluster.
|
||||
|
||||
For more information about minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/local-cluster-ux.md).
|
||||
For more information about minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
|
||||
|
||||
## Additional Links:
|
||||
* **Goals and Non-Goals**: For the goals and non-goals of the minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
|
||||
|
||||
@@ -67,7 +67,7 @@ Exponential restart back-off for a failing container is currently not supported.
|
||||
|
||||
## Experimental NVIDIA GPU support
|
||||
|
||||
The `--experimental-nvidia-gpus` flag, and related [GPU features](https://git.k8s.io/community/contributors/design-proposals/gpu-support.md) are not supported.
|
||||
The `--experimental-nvidia-gpus` flag, and related [GPU features](https://git.k8s.io/community/contributors/design-proposals/resource-management/gpu-support.md) are not supported.
|
||||
|
||||
## QoS Classes
|
||||
|
||||
|
||||
@@ -33,7 +33,7 @@ multiple API versions, each at a different API path, such as `/api/v1` or
|
||||
The version is set at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-life and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes; all descriptions below cover both formats.
|
||||
|
||||
Note that API versioning and software versioning are only indirectly related. The [API and release
|
||||
versioning proposal](https://git.k8s.io/community/contributors/design-proposals/versioning.md) describes the relationship between API versioning and software versioning.
|
||||
versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and software versioning.
|
||||
|
||||
Different API versions imply different levels of stability and support. The criteria for each level are described
|
||||
in more detail in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions).
|
||||
@@ -60,7 +60,7 @@ The criteria are summarized here:
|
||||
|
||||
## API groups
|
||||
|
||||
[*API groups*](https://git.k8s.io/community/contributors/design-proposals/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.
|
||||
[*API groups*](https://git.k8s.io/community/contributors/design-proposals/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.
|
||||
|
||||
Currently, there are several API groups in use:
|
||||
|
||||
@@ -73,7 +73,7 @@ There are two supported paths to extending the API with [custom resources](/docs
|
||||
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
|
||||
is for users with very basic CRUD needs.
|
||||
1. Coming soon: users needing the full set of Kubernetes API semantics can implement their own apiserver
|
||||
and use the [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/aggregated-api-servers.md)
|
||||
and use the [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
||||
to make it seamless for clients.
|
||||
|
||||
|
||||
|
||||
@@ -1096,7 +1096,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">phase</p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">Phase is the current lifecycle phase of the namespace. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases">https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases</a></p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">Phase is the current lifecycle phase of the namespace. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases">https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases</a></p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td>
|
||||
<td class="tableblock halign-left valign-top"></td>
|
||||
@@ -1185,7 +1185,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">finalizers</p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers">https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers</a></p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers">https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers</a></p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
|
||||
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#_v1_finalizername">v1.FinalizerName</a> array</p></td>
|
||||
<td class="tableblock halign-left valign-top"></td>
|
||||
|
||||
@@ -1217,7 +1217,7 @@ Appears In <a href="#pod-v1-core">Pod</a> </aside>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>qosClass <br /> <em>string</em></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://git.k8s.io/community/contributors/design-proposals/resource-qos.md">https://git.k8s.io/community/contributors/design-proposals/resource-qos.md</a></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md">https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>reason <br /> <em>string</em></td>
|
||||
|
||||
@@ -997,7 +997,7 @@ Appears In:
|
||||
</tr>
|
||||
<tr>
|
||||
<td>manualSelector <br /> <em>boolean</em></td>
|
||||
<td>manualSelector controls generation of pod labels and pod selectors. Leave <code>manualSelector</code> unset unless you are certain what you are doing. When false or unset, the system pick labels unique to this job and appends those labels to the pod template. When true, the user is responsible for picking unique labels and specifying the selector. Failure to pick a unique label may cause this and other jobs to not function correctly. However, You may see <code>manualSelector=true</code> in jobs that were created with the old <code>extensions/v1beta1</code> API. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/selector-generation.md">https://git.k8s.io/community/contributors/design-proposals/selector-generation.md</a></td>
|
||||
<td>manualSelector controls generation of pod labels and pod selectors. Leave <code>manualSelector</code> unset unless you are certain what you are doing. When false or unset, the system pick labels unique to this job and appends those labels to the pod template. When true, the user is responsible for picking unique labels and specifying the selector. Failure to pick a unique label may cause this and other jobs to not function correctly. However, You may see <code>manualSelector=true</code> in jobs that were created with the old <code>extensions/v1beta1</code> API. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/apps/selector-generation.md">https://git.k8s.io/community/contributors/design-proposals/apps/selector-generation.md</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>parallelism <br /> <em>integer</em></td>
|
||||
@@ -1315,7 +1315,7 @@ Appears In:
|
||||
</tr>
|
||||
<tr>
|
||||
<td>qosClass <br /> <em>string</em></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md">https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md</a></td>
|
||||
<td>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: <a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md">https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>reason <br /> <em>string</em></td>
|
||||
@@ -4873,7 +4873,7 @@ Appears In:
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>finalizers <br /> <em>string array</em></td>
|
||||
<td>Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers">https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers</a></td>
|
||||
<td>Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers">https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -4895,7 +4895,7 @@ Appears In:
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>phase <br /> <em>string</em></td>
|
||||
<td>Phase is the current lifecycle phase of the namespace. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases">https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases</a></td>
|
||||
<td>Phase is the current lifecycle phase of the namespace. More info: <a href="https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases">https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@@ -10,7 +10,7 @@ This page shows how to migrate data stored in a ThirdPartyResource (TPR) to a Cu
|
||||
|
||||
Kubernetes does not automatically migrate existing TPRs.
|
||||
This is due to API changes introduced as part of
|
||||
[graduating to beta](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md)
|
||||
[graduating to beta](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/thirdpartyresources.md)
|
||||
under a new name and API group.
|
||||
Instead, both TPR and CRD are available and operate independently in Kubernetes 1.7.
|
||||
Users must migrate each TPR one by one to preserve their data before upgrading to Kubernetes 1.8.
|
||||
|
||||
@@ -29,7 +29,7 @@ the rescheduler tries to free up space for the add-on by evicting some pods; the
|
||||
|
||||
To avoid situation when another pod is scheduled into the space prepared for the critical add-on,
|
||||
the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
|
||||
(see [more details](https://git.k8s.io/community/contributors/design-proposals/taint-toleration-dedicated.md)).
|
||||
(see [more details](https://git.k8s.io/community/contributors/design-proposals/scheduling/taint-toleration-dedicated.md)).
|
||||
Each critical add-on has to tolerate it,
|
||||
while the other pods shouldn't tolerate the taint. The taint is removed once the add-on is successfully scheduled.
|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ A namespace can be in one of two phases:
|
||||
* `Active` the namespace is in use
|
||||
* `Terminating` the namespace is being deleted, and can not be used for new objects
|
||||
|
||||
See the [design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases) for more details.
|
||||
See the [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) for more details.
|
||||
|
||||
## Creating a new namespace
|
||||
|
||||
@@ -93,7 +93,7 @@ Note that the name of your namespace must be a DNS compatible label.
|
||||
|
||||
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/namespaces.md#finalizers).
|
||||
More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers).
|
||||
|
||||
## Deleting a namespace
|
||||
|
||||
@@ -346,7 +346,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
||||
{% capture whatsnext %}
|
||||
* 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/{{page.githubbranch}}/contributors/design-proposals/namespaces.md).
|
||||
* See [namespaces design](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/architecture/namespaces.md).
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
@@ -99,7 +99,7 @@ It is recommended that the kubernetes system daemons are placed under a top
|
||||
level control group (`runtime.slice` on systemd machines for example). Each
|
||||
system daemon should ideally run within its own child control group. Refer to
|
||||
[this
|
||||
doc](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md#recommended-cgroups-setup)
|
||||
doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
|
||||
for more details on recommended control group hierarchy.
|
||||
|
||||
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
|
||||
|
||||
@@ -300,6 +300,6 @@ Check that:
|
||||
{% capture whatsnext %}
|
||||
* If you need assistance, use one of the [support channels](/docs/tasks/debug-application-cluster/troubleshooting/) to seek assistance.
|
||||
* For details about use cases that motivated this work, see
|
||||
[Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md).
|
||||
[Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation/federation.md).
|
||||
{% endcapture %}
|
||||
{% include templates/task.md %}
|
||||
|
||||
@@ -196,7 +196,7 @@ PersistentVolume are not present on the Pod resource itself.
|
||||
{% capture whatsnext %}
|
||||
|
||||
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/persistent-storage.md).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
|
||||
|
||||
### Reference
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ the Pod:
|
||||
|
||||
{% capture whatsnext %}
|
||||
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
|
||||
* Read the the [all-in-one volume](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/all-in-one-volume.md) design document.
|
||||
* Read the the [all-in-one volume](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
@@ -323,7 +323,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/volume-ownership-management.md)
|
||||
[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
for more details.
|
||||
|
||||
* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
|
||||
@@ -343,7 +343,7 @@ label given to all Containers in the Pod as well as the Volumes.
|
||||
* [SecurityContext](/docs/api-reference/{{page.version}}/#securitycontext-v1-core)
|
||||
* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
|
||||
* [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/volume-ownership-management.md)
|
||||
* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
|
||||
|
||||
|
||||
|
||||
@@ -379,4 +379,4 @@ Check that:
|
||||
|
||||
## For more information
|
||||
|
||||
* [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md) details use cases that motivated this work.
|
||||
* [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation/federation.md) details use cases that motivated this work.
|
||||
|
||||
@@ -8,7 +8,7 @@ You can use a `podpreset` object to inject certain information into pods at crea
|
||||
time. This information can include secrets, volumes, volume mounts, and environment
|
||||
variables.
|
||||
|
||||
See [PodPreset proposal](https://git.k8s.io/community/contributors/design-proposals/pod-preset.md) for more information.
|
||||
See [PodPreset proposal](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md) for more information.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
@@ -49,7 +49,7 @@ controlled by the php-apache deployment we created in the first step of these in
|
||||
Roughly speaking, HPA will increase and decrease the number of replicas
|
||||
(via the deployment) to maintain an average CPU utilization across all Pods of 50%
|
||||
(since each pod requests 200 milli-cores by [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/user-guide/kubectl/kubectl_run.md), this means average CPU usage of 100 milli-cores).
|
||||
See [here](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
|
||||
See [here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
|
||||
|
||||
```shell
|
||||
$ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
||||
|
||||
@@ -16,7 +16,7 @@ which in turn uses a
|
||||
For more information, see
|
||||
[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
|
||||
|
||||
To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/v1.6/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
|
||||
To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/v1.6/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
|
||||
|
||||
Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
|
||||
consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates
|
||||
@@ -156,7 +156,7 @@ spec:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) to specify the new image:
|
||||
To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) to specify the new image:
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update my-nginx --image=nginx:1.9.1
|
||||
|
||||
@@ -4,7 +4,7 @@ assignees:
|
||||
title: Rolling Update Demo
|
||||
---
|
||||
|
||||
This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) for more information.
|
||||
This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) for more information.
|
||||
|
||||
The files for this example are viewable in [our docs repo
|
||||
here](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/update-demo).
|
||||
|
||||
Reference in New Issue
Block a user